Incident Response Plan

Forrester 7 steps to building an effective incident response program

Forrester Senior Analyst Rick Holland identifies the keys to an effective incident response program.

This article, available through TechTarget, is a good tool for communicating with your executive team.

The article references an interesting point. According to the Forrester Forrsights Security Survey, after a breach has occurred, 25% of organizations increase spending on breach prevention technologies, while 23% increase spending on the incident response program itself.

(1) Be self-aware.

Know your capabilities and constraints. Avoid overestimating your abilities. An outside perspective may provide clarity.

(2) Technology – understand its benefits and limitations.

Technology spending outweighs investments in incident response programs, but technology does not equal a solution.

(3) Establish realistic reporting metrics.

Time-to-detect, time-to-contain, and time-to-re-mediate are good results-oriented metrics. Think of others. Consider trending and its implications.

(4) Make the program scalable.

Larger organizations have larger challenges addressing incident response. Consider a contingency team as well as internal and external specialists.

(5) Collaborate internally and externally.

Incident response teams should not work in isolation. Involve your vendors and suppliers.

(6) Engage executives.

Align security programs, including incident response, with the business value chain. Connecting the response plan to an enterprise risk assessment is key.

(7) Operate with autonomy.

To avoid micro-management, establish rules of engagement that identify the need for approval balanced against the need to act.

Coordinated Response

This article provides a good set of principles to apply as you build or enhance your incident response program.

Let us help you with a response plan review that applies and expands on the ideas presented by Forrester.

NIST Incident Impact Assessment – Revised

NIST Revised their guidance on Incident Impact Assessment in The Computer Security Incident Handling Guide, SP 800-61 Revision 2, August 2012.

Revision 1 provided a complex measure for incident impact assessment that might provide insight in hindsight, but one that was not practical, applicable, or useful in the midst of an incident response. The new measures, suggested in the table above, are really quite useful, applicable, and discernible. There are 3 important impact areas with associated metrics:

  • Functional impact
  • Information Impact
  • Recoverability Effort

Functional Impact

This measures loss of system functionality. NONE – No loss of functionality. LOW – no loss of functionality, but loss of efficiency. MEDIUM – Critical services lost to a subset of users. HIGH –  Critical services lost to all users.

Information Impact

Here NIST stops short of measuring impact – so the above diagram is not colored for this Impact Area except in the case of NONE – no information was exfiltrated, modified, or deleted. An impact measure is needed for each of the three information impact areas. PRIVACY BREACH – personally identifiable information was compromised. PROPRIETARY BREACH – unclassified proprietary data was compromised. INTEGRITY LOSS – sensitive or proprietary information was changed or deleted. A level of impact measure is needed in each of these areas. The loss of a single document or individual’s data is low, but what defines medium or high?

Recover-ability Effort

This is an interesting and useful metric: Is the data/system recoverable? If so, what is the level of recovery effort? NOT RECOVERABLE – the data or system cannot be recovered. REGULAR – time-to-recover is predicable with existing resources. SUPPLEMENTED – time-to-recover is predictable, but with additional resources. EXTENDED – time-to-recover is unpredictable and additional resources including outside help are needed.

Coordinated Response

This new approach agrees with the Coordinated Response Impact Assessment in the Response Management Framework. The table below shows the 5 possible impact areas with associated impact metrics.

 NIST Impact Areas

Coordinated Response can help you review and improve your Incident Response Plan.

Incident Response – 3 Big Mistakes

Dark Readings identifies 3 Big Mistakes in Incident Response, May 13, 2013.

By recognizing and avoiding these common mistakes, Kelly Jackson Higgins provides a quick set of best practices backed by interviews with security experts. The article should be in every Response Teams must-read library. A response plan should identify the practices to avoid these mistakes:

  1. Assuming It’s an APT; don’t confuse expectations with facts.
  2. Not Monitoring Traffic; beyond detection, supports investigation.
  3. Focusing Only on the Malware; eradication is important, but so investigation.

Assuming It’s an APT

Not all attacks start with an Advanced Persistent Threat. Apply an objective lens to the data. Look for a 2 stage attack: (1) Phishing, (2) Command and Control.

Not Monitoring Traffic

The article makes a good point. Monitoring is not just for protection and detection. When a breach or intrusion is discovered, audit records provide clues as to what happened, when, and what may be ex-filtrated. Not monitoring, even insufficient monitoring increases potential impact.

Focusing Only on the Malware

Containment and eradication are important, but determining outcomes – data theft, sabotage, other long-term damage – may be more important.

Avoid Tunnel Vision

This was not called out as a 4th mistake, but the article led with an example of a team that was focused on the malware and missed a shift to control of an administrative tool. The admonition to “avoid tunnel vision” applies more broadly than just “focusing on malware”.
The example also identified a good practice. An outside firm reviewed the outcome of the incident and discovered the control shift – the true intent of the attack.

Coordinated Response

Coordinated Response can help to broaden your view and t0 improve your incident response plan.

Risk Assessment and Incident Response

Align your Incident Response plan with your information security risk assessment.

An effective risk assessment, regardless of the technique employed, identifies impact areas and potential impact levels. Then, given the probabilities an attack, risk strategies are defined: avoid the risk; mitigate the risk; share the risk; accept remaining risk.

Ultimately, unless you choose to avoid the risk, some residual risk is accepted. Then, when an unlikely incident occurs, an incident response plan is the last line of defense.

Risk Assessment – Incident Response – Impact Assessment

The key to an effective impact assessment rests with two key questions:
• What areas of your business are at risk when an incident occurs?
• How do you measure the impact?

These two questions are first asked during the risk assessment – the theoretical question: what if? When an incident occurs, they are asked again, only it is no longer in theory. What areas of your business are affected? To what level?

Impact Areas

While most organizations evaluate the financial impact, the majority view reputational impact as the more important. Other areas to measure include operational impact and legal impact. If your organization is regulated, you might measure legal impact, policy impact, and regulatory impact as separate areas.

Impact Levels

For each impact area, it is important to provide metrics or descriptions that differentiate the impact level. Low, medium, and high are not enough as impact measures. Without metrics different people assign different meanings to the terms low, medium, and high.

An Incident Response Plan Review

It’s worth stressing that the impact component of the risk assessment can and should be used during the Incident Impact Assessment. The Response Team measures adverse impact to determine the needed response.

With this information the response team makes informed decisions on what resources to apply and what actions to take. Refer to our Response Management Framework for added insight.

Let us help you with a response plan review that considers your information security risk assessment.

Does SIEM Meet Your Incident Response Needs?

Security Information & Event Management (SIEM) systems provide real-time monitoring and advanced analytics and generate automatic alerts for potentially adverse events.

Most SIEM vendors from HP and IBM to LogRythm and LogLogics offer tools that support incident response, but in the words of one research organization the response is IT-focused and tightly coupled to the SIEM. The enterprise is not involved. Artifacts are limited to SIEM records. Incidents derived from outside the SIEM – help desk tickets, third party alerts, etc. – are not tracked at all.

There is a need to manage incidents at an enterprise-level. In addition to IT, there is involvement and support from:

  • Risk Management Operations
  • Corporate Counsel and outside legal counsel
  • Public Affairs, Public Relations, and/or Media Relations
  • Executive Leaderships
  • Security Operations – Physical Security and Facilities Management
  • Third party experts – IT, Forensics, Cybersecurity, Legal, etc.

SIEM vendors provide no interface supporting these enterprise actors. The researchers suggest connecting with an enterprise process automation platform, for example, Microsoft (TM) SharePoint, a platform that provides:

  • Content and records management for Incident Documentation and Evidence
  • Process automation with Alerts, Notifications, Approvals, and Assignments
  • Change management records and audit trails

Coordinated Response embraces the SIEM response capability, but extends it to the Enterprise level.


What Else Does NIST Say?

The National Institute of Standards and Technology (NIST) released The Computer Security Incident Handling Guide, SP 800-61 Revision 2, in August, 2012.

The guide puts incident handling activities in the context of the above diagram. The table below provides the first level of detail.

Preparation Detection & Analysis Containment, Eradication, & Recovery Post-Incident Activity
  • Response Team Communications & Facilities
  • Analysis Tools: Hardware & Software
  • Analysis Resources: Hardware & Software Inventory
  • Incident Mitigation Software: OS Images for recovery
  • Attack Vectors
  • Signs of an Incident
  • Sources: Alerts & Logs
  • Sources: People & Public Information
  • Incident Analysis
  • Profiles & Norms
  • Event Correlation
  • Internet search tools
  • Packet Sniffers
  • Third Party Resources
  • Incident Documentation
  • Incident Prioritization
  • Incident Notification
  • Select a Containment Strategy
  • Gather & Handle Evidence
  • Identify Source of Attack
  • Eradicate the Intruder & Recover the Assets
  • Lessons Learned
  • Analyze Collected Incident Data
  • Retain Evidence as Appropriate

The above activities represent a useful checklist for evaluating an incident response plan as well as incident handling in action.

Of course, recognize that the response to an incident is fluid, often with unclear boundaries. Containment may start in the early stages of analysis. Prioritization may change and notification may continue throughout the incident. But, the insight provided by the NIST publication goes beyond Federal agencies.

Federated Cybersecurity: A Hybrid Approach to Safety

I attended the CSO Perspectives event in Alexandria, Virginia on March 21st. This event was produced by CSO Magazine and CSO Online. Publisher Bob Bragdon was the host and moderator. During the course of the day, there was an extensive discussion of the Federal Government’s role in Cybersecurity.

Over lunch, with Bob and a number of others, I suggested we need a federated approach to cybersecurity.

Consider highway safety for a moment and all the factors that make it safe to drive:

  1. Highways are built to a standard of safety. Interstate highways meet Federal standards. The standard defines safe lane widths, median strips, shoulders, guard rails when necessary, on and off ramps and more.
  2. State and local laws dictate speed limits.
  3. State and local police enforce the laws.
  4. Federal regulations direct automotive manufacturers to build safe cars with seat belts and air bags, signal lights, brake lights, and more.
  5. Automotive manufacturers add crash zones and other details competing for the moniker of safest.
  6. You and I are required to get a driver’s license by passing a written test and a driving test (though I confess it’s been a few decades since I last took the test).
  7. Young drivers need to meet a higher standards in most states to get their drivers permit.
  8. Our insurance companies encourage us to drive safely with threat of higher premiums when we don’t.
  9. Of course, there are incident response services: from emergency response to AAA.

This federated approach to safety and security is needed on the information highway (now there is a dated term). We expect hardware and software manufacturers to build safer products. But, we need to be trained to use them properly and not to turn off safety features or, in some cases, we need to be trained to turn them on. The network service providers and internet service providers need to build safer “highways”. We still need government regulations and enforcement.

How do we protect against malicious drivers? This is a metaphor worth exploring.

What Does NIST Say About Incident Response?

The National Institute of Standards and Technology (NIST) produced a list of Security Controls for Federal Information Systems. Incident Response is one of the controls.

In Special Publication 800-53, revision 3 NIST included Incident Response as 1 of 18 families of security controls. For the complete list see the end of this item. Much of the material is useful beyond the Federal government.

First, NIST provides a useful framework for considering Incident Response (IR). Please don’t let the control numbers confuse things. I started with preparation, but NIST considers IR Planning as IR-8.

NIST IR Controls

Incident Response preparation starts with Policies and Procedures and the preparation of an incident response plan. With the plan in hand, train users how to recognize and report incidents, train the response team how to organize and react. For some incidents, actually testing the plan with field exercises may be needed.

Incident response execution includes handling, monitoring, reporting, and possibly additional assistance from specialists. NIST suggests each organization consider these controls and determine when or whether they apply.
In SP800-53, Revision 4 Draft, two additional controls were identified: IR-9 Information Spoilage Response and IR-10 Integrated Information Security Cell. The first addresses the additional needs for damaged or leaked information. The latter describes the organization of a specialized element of the Incident Response Team.

While the Incident Response Plan is just one of 8 controls, it touches all the other controls. NIST declares a good Incident Response Plan:

  • Provides road map for implementing incident response capability.
  • Describes the structure and organization of the incident response capability.
  • Provides a high-level approach for how the incident response capability that fits into the overall organization.
  • Meets the unique requirements of the organization, which relate to mission, size, structure, and functions.
  • Identifies reportable incidents.
  • Provides metrics for measuring the incident response capability within the organization.
  • Defines the resources and management support needed to effectively maintain and mature an incident response capability.
  • Is reviewed and approved at an appropriate level.

I heartily agree with NIST’s declaration.

NIST Security Controls
Here is the complete list of security control families identified in SP 800-53 and organized by the three control classes: Technical, Operational, and Managerial.

NIST Controls

New York Times Hacked Again

The New York Times incident response and incident handling provides examples of best practices, as well as, lessons learned.

According to the New York Times, Hackers in China Attacked the Times for Four Months. The Times Incident Response Plan provides examples of best practices as well as lessons learned.

  • Include your ISP in your response plan.
  • Identify appropriate specialists.
  • Malware detection is not enough.
  • Investigate, then eradicate.
  • Involve law enforcement when appropriate.
  • Get specialists involved early.
  • Enhanced monitoring is important.
  • Review the incident postmortem.

And the most important best practice is to make security improvements based on the postmortem and lessons learned

In the case of the New York Times, the hackers were able to crack the password for every Times employee. Then the hackers used the passwords to gain access to the personal computers of 53 employees. The attack was discovered on October 25. The investigation placed the initial compromise on or around September 13 or 6 weeks earlier.

First, the Times engaged their Internet Service Provider (ISP), AT&T, to watch for unusual activity as part of AT&T’s intrusion detection protocol. The Times received an alert from AT&T that coincided with the publication of a story on the Chinese Prime Minister’s family wealth.

The New York Times briefed the Federal Bureau of Investigation (FBI). The FBI has jurisdiction over cybercrimes in the United States.

At the start of week 9, when the response team, even with AT&T assistance, was unable to eliminate the malicious code, the Times engaged Mandiant, a firm specializing in cybersecurity breaches. This is both a lesson learned and a best practice. Expect to need additional help when a significant incident occurs, but it’s best to engage the specialists when the response plan is first developed.

The response team identified 45 pieces of malware that provided the intruders with an extensive tool set to extract information. Virus protection only identified 1 piece. This is an important lesson. Advanced or enhanced malware may be difficult to detect. Defense in depth requires added security controls. In this case, monitoring provided the alert.

At this point, the response team “allowed hackers to spin a digital web for four months to identify every digital back door the hackers used”. This allowed the Times to (1) fully eradicate the intruders, (2) determine the extent of the intrusion and data extraction, and (3) build improved defenses for the future. Again, this is a best practice – investigation precedes eradication.

I found the work habits of the hackers particularly interesting. They worked a standard day starting at 8 A.M. Beijing time. Occasionally they worked as late as mid-night including November 6, election night.

A Focus on Incident Response

Coordinated Response is an incident response planning and consulting firm. We help you create an incident response plan, improve upon it, automate it, and manage it.

My focus, my interest, my expertise are in the area of incident response planning and management. Seasoned in business process management & automation, I have helped numerous organizations build business response management solutions. Working with my key advisers – Jim Bothe and John Walsh (see About Us – Leadership) – I began focusing on cybersecurity incident response management.

Prepare, Protect, Respond

Where does response management fall in the realm of cybersecurity?

Most people asked about cybersecurity tools mention antivirus software or firewalls or intrusion detection systems. These important tools help to protect systems and information. But, if these tools fail, if an incident occurs, an organized, coordinated response to the incident is needed.

Other people think about the effort to prepare the security plan and architecture. Preparation starts with a risk assessment, includes the security architecture, but should include an incident response plan. To respond to an incident without a well thought out, well tested, well practiced plan increases the risk, the cost, and the overall impact of the incident.

Some organizations might consider any activity performed by the Computer Security Incident Response Team or CSIRT as incident response, but many CSIRT activities are pro-active. The CSIRT may participate in preparation and protection as part of incident management, not just the narrower incident response. In addition, legal, human resources, security may also participate as extended team members of the CSIRT.

The diagram above is based on one in the publication Defining Incident Management Processes for CSIRTs: A Work in Progress, Carnegie Mellon University / Software Engineering Institute, May, 2004. The publication, Technical Report CMU/SEI-2004-TR-015, is available at The authors provide both insight and useful guidance. Be not fooled by its publication date or the tag line “a work in progress”.