The NIST Cybersecurity Framework identifies five cybersecurity functions. Two of the functions are Respond and Recover.

Separating Recovery from Incident Response

Working with our clients, we see Recovery as separate from Incident Response. The National Institute for Standards and Technology (NIST) Cybersecurity Framework confirms that view: Respond and Recover are separate functions.

Recovery might involve a wide range of activities from restoring a data set or a system to pursuing legal action to recover damages. These activities are the province of specific organizational elements well beyond the scope of incident response. Recovering a data set or a system is likely the responsibility of an operational unit in the information systems organization. This unit recovers components impacted for many reasons, not just cyber incidents.

The Incident Response team might initiate the recovery process, but the incident is often closed before recovery is complete.

Earlier NIST Guidance

In SP 800-61 Rev 2 Computer Security Incident Handling Guide, 2012, NIST identified 4 phases for incident response. The third phase includes Contain, Eradicate, and Recover. Thus, treating Recover as an integral part of the response effort.

For a copy of the incident handling guide use the following link:

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf

Incident Response Plan

Whether or not your organization includes Recovery as part of Incident Response the relationship between Respond and Recover needs to be defined in the Incident Response Plan.

The English language is spoken with different accents and different vocabularies while still saying the same thing.

The standards for Incident Handling use different vocabularies, but they also say the same thing.

The table below compares the language used by 4 authorities to describe the incident handling phases. The authorities employ 4, 5, or 6 phases.

National Institute of Standards and Technology

NIST SP 800-61 Rev 2 Computer Security Incident Handling Guide, 2012.
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf

International Standards Organization

ISO/IEC 27035:2011 Information technology — Security techniques — Information security incident management, 2011.
http://www.iso.org/iso/catalogue_detail?csnumber=44379

SANS Institute

The Incident Handler’s Handbook, 2011.
http://www.sans.org/reading-room/whitepapers/incident/incident-handlers-handbook-33901

ISACA

Incident Management and Response, 2012.
http://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/Incident-Management-and-Response.aspx

Coordinated Response

The Response Management Framework aligns well with all of these approaches. Let us apply the framework in a response plan review.

NIST Special Publication 800-30 identifies Respond as 1 of 4 risk management processes. In order to properly complete the Risk Assessment, an incident Response Plan needs to be considered in parallel.

Four Risk Management Processes

Respond is 1 of the 4 Risk Management Processes identified in the Guide. Respond includes pre-emptive security controls to mitigate risk, but it also includes Incident Response Planning, Management, and Execution. Respond receives input from and provides input to the other 3 processes: Frame, Assess. and Monitor.

The Assess process has a number of key dependencies on the approach to incident response. I will look at these in my next post.

Coordinated Response

Coordinated Response can work with you to align your response plan with your Risk Assessment. Let us help you with a response plan review that considers your information security risk assessment.

For more information on how we see risk assessment linked with incident response refer to an earlier highlight: https://coordinatedresponse.com/risk-assessment-and-incident-response/.

NOTE: The graphic above is from NIST SP 800-39 Managing Information Security Risk page 32. It is similar to the graphic in SP 800-30 Rev 1 on page 4, but in SP 800-39 the graphic provides more information. Specifically the 3 organizational tiers are identified.

For access to NIST Special Publications: http://csrc.nist.gov/publications/PubsSPs.html, SP 800-30 Rev 1, “Guide for Conducting Risk Assessments,” Sep. 2012.

Cybersecurity incidents double in 5 years

In a report of recent congressional testimony, GAO provides statistics that provide insight. The report is available from the GAO Web Site.

Incidents over Time

Incidents by Category

Coordinated Response

How does this compare with your experience? Does your response plan address this range of cybersecurity incidents? At Coordinated Response we use this type of information to inform our response plan development and response plan reviews.

The GAO in Congressional testimony made the recommendations

A report of the testimony is available from the GAO Web Site. For some interesting statistics from this report refer to GAO Statistics on Cyber Security.

Key Management Practices

• Establish a data breach response team;
  rely on IT security staff for technical remediation;
  identify an extended team that includes the information owner, the CIO,
  the CISO, the privacy officer, public affairs, and legal counsel among others.
• Train employees on their role;
  train of employees with access to sensitive data on their responsibilities;
  train the response team on their role in the incident response plan.

Key Operational Practices

• Submit reports to appropriate entities;
  prepare and submit reports for internal use, to the US-CERT within 1 hour of discovery,
  and to other external entities as appropriate.
• Assess the impact both in breadth and in depth;
  identify the nature of the data, the number of individuals, the likely potential for harm,
  and the possibilities for mitigation; this assessment determines incident actions and reports.
• Offer affected individuals assistance;
  as appropriate and as required, help  mitigate the individual’s risk
  through credit monitoring for example.
• Analyze the breach response; identify lessons learned.

Coordinated 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.

The Response Management Framework extends the NIST Framework

The Preliminary Cybersecurity Framework is available on the National Institute of Standards and Technology (NIST) Web Site. Next week the final version is due. The preliminary paper identifies 5 core functions. The Response Management Framework compliments the NIST framework and extends three of the core functions.

Some experts have been critical of the framework, but others support it. See Taylor Amerding’s article “NIST’s finalized cybersecurity framework receives mixed reviews”, January 31, 2014, in CSO Online.

Identify, Protect, Detect, Respond, Recover

1. Identify – Identify Systems, Assets, Data, and Capabilities at Risk for Cyber Incidents.
   
2. Protect – Implement Access Controls, Awareness & Training, Data Security, and Protective Technologies.
3. Detect – Detect Anomalies and Events; Employ Continuous Monitoring and Detection Processes.
4. Respond – Include Response Planning,  Analysis, Mitigation, and Improvements.
5. Recover – Address Recovery Planning, Improvements, and Communications.

Of course, Detect, Respond, and Recover are the context for your incident response plan.

• In Detect, potential incidents are analyzed to determine their nature.
• Respond encompasses additional analysis, containment, more analysis, and eventually eradication.
• Then Recover proceeds unhindered to restore impacted capabilities.

Coordinated Response

The Response Management Framework provides the details of who, what, when, where, and how.

Of course, Coordinated Response uses the information provided from the Identify function to help build the Impact Assessment and to properly Prioritize the Incident.

This definition may not explain how to get there, but it tells you where you want to go. It provides a descriptive definition of an effective incident response plan.

An Incident Response Plan:

• is an implementation road map;
• describes the team structure and organization;
• is reviewed and approved at the right level;
• provides organizational context;
• defines reportable incidents;
• identifies key metrics; and
• defines needed resources and management support.

This makes a good list of New Year’s resolutions for improving an incident response plan and program.

Many readers may recognize this description. This description paraphrases the description of the Incident Response Plan security control (IR-8) in the NIST Publication SP 800-53. For more information on SP 800-53 refer to What Does NIST Say about Incident Response?, March 2013.

Coordinated Response

Let us help you with a response plan review that moves forward on these valuable measures.

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.

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

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.

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.

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.

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.