IBM Center for Applied Insights

Highlights: Security incidents happen. The key is whether you’re properly prepared. Building a first-class system for incident response requires the right staff, expertise, processes, and enterprise-wide coordination. At IBM, we use a set of general principles to direct our internal actions and external communications when an incident occurs.

Security Essentials for CIOsResponding to the inevitable incident

Executive Series

It could come tomorrow, or perhaps two years from now. It could arrive in many forms, perhaps as a distributed denial of service attack or malware siphoning off company secrets. Whatever its shape or nature, the first question is not whether an enterprise-threatening incident will come, but instead when. And the same goes for the one after that. The vital question, of course, is whether you’re prepared.

An enterprise built to thrive must have a team ready and on call every hour of the day to respond to a major incident. In a sense, this unit functions like a hospital emergency room. Everyone must know his or her documented processes and procedures. And much like an emergency at an ER, the challenge is to identify the threat quickly, assess its gravity and potential to spread, and take prompt measures to contain it.

The trouble is that incidents, unlike those at an ER, can affect every branch of business. Some incidents threaten customers, others employees or products. Some might leak sensitive data on partners, relations with governments or intellectual property. The possibilities range as wide as the enterprise itself. This means, daunting as it might sound, that the incident-response team must draw on expertise from virtually every area of the enterprise.

So what steps should a CIO take to build a top-notch system for incident response? We’ve put together a list.

2

Security IntelligenceExecutive Series

If, on the other hand, an errant password belongs to a senior executive who was busy negotiating a multi-billion-dollar deal overseas, it could represent a dangerous breach. The response team should jump into action, both at the home office and in the region where it occurs. Keep in mind that the incident may not be resolved in a work day, which means that another team several time zones away might be picking up the work within hours. They should be in the loop, the sooner the better.

5. “Small” incidents matter, too. Say, for example, that outsiders penetrated the corporate network through an unsecured Wi-Fi connection. They may have done no harm. But it’s vital to respond to such incidents, and keep careful records of them. First, they may be indications that some employees are not observing security procedures—that the culture of vigilance may be slackening. That’s a wake-up call. Further, a number of seemingly small incidents can fit into a larger pattern, and perhaps a serious threat. Without taking note of all incidents, following up on them, and keeping records, a big threat could arrive unnoticed. An enterprise that does not maintain trained incident response teams on call is, in many senses, asleep at the wheel.

6. Trust the team to make crucial decisions in real time. Once an incident is spotted, the next job is to determine the possible damage, and to take the appropriate action. This can involve a series of momentous decisions. One early question is whether to alert the user who appears to be the target of an attack or to cut off his or her network access. If the incident shows signs of a possible insider attack, the answer is anything but clear. The team must also determine if local law enforcement authorities should be alerted.

Experts on the response team must understand all of the issues. Under the pressure of a crisis, the team must map out a course that will protect the company’s interests. This requires broad expertise, along with the confidence and power to make tough decisions quickly. Again, these matters involve the entire enterprise, and the expertise on hand—whether in-house or through a service provider—must extend far beyond the technical team.

1. Commit to a full and talented staff.Response teams naturally include technical security and legal experts. But they should also extend to marketing, human resources, finance, and government affairs. Each region in which a company does business should field a security team, as well as back-ups. This global deployment allows work on incidents to revolve with the earth, twenty-four hours a day, seven days a week. What’s more, teams in each region can tap experts who understand the requirements in each country, and the business at stake. During emergencies, these people face tough decisions whose consequences can reverberate through the entire company. In such a situation, there is no place for an inexperienced team.

2. Build a documented and auditable process. Whether you choose to build it in-house or hire outside professionals, the enterprise should have a system to monitor operations and collect accurate and timely reports from the field. Every step taken should follow procedures, which can be monitored and, later, studied and fine-tuned. And remember, an established communications strategy, with the appropriate channels, team members and process, is one of the key elements of a documented plan.

3. Involve the entire enterprise. Employees in every role and division are vital for incident detection and response. They must be educated not only to take necessary precautions, but also to spot and report incidents through established channels. In this sense, everyone is part of the response team. This fact should be hammered home, in practice drills and structured walk-throughs. It is part of creating a risk-aware culture.

4. Spot the really dangerous incidents — and focus on them.Large enterprises might handle numerous incidents in a single day, from a laptop left at an airport to phishing attacks in corporate email. The initial challenge is to determine which ones pose the greatest potential danger and to put a team on them quickly. Returning to the emergency-room analogy, this is like the triage unit. In the case of a junior employee who foolishly shared his password, security analysts will quickly study that employee’s network activity in recent weeks, and the areas of the enterprise he has access to. They may determine that it is only a minor threat.

3

Security IntelligenceExecutive Series

7. Close the loop. Some incidents are handled in a single morning. Others, from malware attacks to insider threats, may take longer. Even after an incident is addressed, it is advisable to proceed to a root cause analysis. The enterprise must determine what was it about the company’s procedures or systems that allowed such

What to do when bad things happen — External communications challenges for security incidents

A security breach can also pose external communications challenges. Damage can spread quickly, tarnish an organization’s reputation and undermine its business. Keys to a successful communications program are the ability to respond quickly to shifting media focus and to realize that anything can happen and usually does. Here are some tips to consider before a security incident happens:

• Developing a good back story. An organization must be able to communicate clearly and convincingly that it has good processes in place to help secure its systems, detect incidents, and limit their impact. If an organization doesn’t have this back story of responsible data stewardship, then the public will quickly assume that everything said after the breach is simply public relations posturing.

• Planning for the worst. It could be a reporter calling you to say that a hacker group has publicly posted information it is claiming that it stole from your organization. It could be any of the new forms of malware that seemingly appear out of nowhere. Scenario planning can be useful, but the key is not to overdo. The thick notebook on the shelf filled with various scenarios usually won’t contain the one that befalls you.

• Determining who to call. There are reporters, bloggers, and public policy groups who will either transmit the detailed and accurate information you provide, or repeat the rumors that are sure to be rampant. Make a list of the reporters who cover your organization on a regular basis, bloggers who cover your industry and the various social media sites on which you are already participating.

• Timing an initial statement. This is the single differentiating factor between a successful communications program and one that fails to prevent damage to the brand. It is understandable to want to quiet the rumor mill by making a quick statement. It also is understandable to want to know all the facts before making a statement so that you have 100 percent accuracy. Both are wrong. Rushing leads to statements based on supposition and inaccurate early assessments. Delaying means inaccurate reports could gain traction and legitimacy.

• Communicating details. Look to the National Traffic Safety Board (NTSB) as an organization to emulate. The NTSB communicates as quickly as possible the known facts, cautions against speculation, and follows up with regular updates. When communicating about a breach discovered by internal measures, focus on what has happened, what potentially impacted persons should be doing, and steps being taken to prevent a repeat of the incident. Do not be afraid to take credit for what you are doing to address the problem, such as cooperation with law enforcement, forensics investigation, installation of help lines, and special support to customers.

• Monitoring the press and social media. A successful monitoring program can judge the effectiveness of specific messaging and get a jump on what information reporters will be seeking next. Many organizations mistakenly assign media monitoring responsibilities to a junior level professional or an administrative staffer, thereby failing to capitalize on trends apparent to a more experienced person.

an incident to take place, and how it can be avoided in the future. Addressing the root cause might require changes in work-force communication, more training, or perhaps a technical fix. In this sense, responding to each incident becomes part of a continuous improvement process--one that never ends.

Security IntelligenceExecutive Series

Please Recycle

© Copyright IBM Corporation 2012

IBM Global Services Route 100 Somers, NY 10589 U.S.A.

Produced in the United States of America August 2012 All Rights Reserved

IBM, the IBM logo and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at “Copyright and trademark information” at ibm.com/legal/copytrade.shtml Other company, product and service names may be trademarks or service marks of others.

References in this publication to IBM products and services do not imply that IBM intends to make them available in all countries in which IBM operates.

WGW03011USEN-00