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.
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:
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 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.
|Phase||NIST SP 800-61||ISO 27035||SANS||ISACA|
|Before||Prepare||Planning & Preparation||Preparation||Preparation|
|During||Detect & Analyze||Identify & Report||Identification||Detect, Triage, & Investigation|
|Contain, Eradicate, & Recover||Assess||Containment||Containment, Tracking, Analysis, & Recover|
|After||Review Incident||Learn||Lessons Learned||Post Incident Assessment|
|Total||4 Phases||5 Phases||6 Phases||5 Phases|
NIST SP 800-61 Rev 2 Computer Security Incident Handling Guide, 2012.
ISO/IEC 27035:2011 Information technology — Security techniques — Information security incident management, 2011.
The Incident Handler’s Handbook, 2011.
Incident Management and Response, 2012.
The Response Management Framework aligns well with all of these approaches. Let us apply the framework in a response plan review.
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 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.
In a report of recent congressional testimony, GAO provides statistics that provide insight. The report is available from the GAO Web Site.
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.
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 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.
Of course, Detect, Respond, and Recover are the context for your incident response plan.
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 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.
Let us help you with a response plan review that moves forward on these valuable measures.
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:
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.
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?
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.
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 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|
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.
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:
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.