return
Incident response is a critical part of cybersecurity risk management and, in a cybersecurity mature organization, it must be integrated into all operations.
NIST has released a first public draft of its SP 800-61r3, this maturing model provides recommendations and considerations for incident management and includes a "Community profile of the NIST Cybersecurity Framework (CSF) 2.0".
This publication is intended to assist organizations in incorporating better response processes throughout their cybersecurity risk management activities.
Prepare for, reduce the number and impact of incidents that occur, and improve the efficiency and effectiveness of detection and recovery activities.
This publication, once finalized, will replace SP 800-61r2 "Computer Security Incident Handling Guide".
Incident Life Cycle
The previous version (SP800-61r2) has long guided us, although at the time of its development (2012) incidents were relatively rare and the scope was better defined, incident recovery was usually completed in a day or two.
Under those ideas, it was realistic to treat incident response as a separate set of activities performed in turn by a separate team of people. All incident response activities could be dumped into a circular life cycle. Post-incident activities would identify all "improvements" and feed into the preparedness stage, thus starting the cycle all over again.
Incident response activities were typically intermittent rather than continuous.
This model no longer reflects the current state. Today, incidents occur more frequently, cause more damage, and recovering from them often takes weeks or months due to their scope, complexity and dynamic nature. Incident response is now considered a critical part of cybersecurity risk management; it cannot be divorced from business operations.
There are instances where the order must change, lessons learned should generally be shared as soon as they are identified, without delay or waiting for recovery to finish. It goes without saying that continuous improvement is necessary for all facets of cybersecurity risk management in order to keep up with modern threats.
In a step towards this integration, this draft proposes stages fully aligned to the CSF 2.0 functions, which organize the stages at the highest level as:
• Govern (GV): The organization's cybersecurity risk management strategy, expectations and policy are established, communicated and monitored.
• Identify (ID): The organization's current cybersecurity risks are understood.
• Protect (PR): Safeguards are used to manage the organization's cybersecurity risks.
• Detect (DE): Potential attacks and cybersecurity compromises are found and analyzed.
• Respond (RS): Actions are taken with respect to a detected cybersecurity incident.
• Recover (RC): Assets and operations affected by a cybersecurity incident are restored.
Within these six functions are vital roles in incident response. Govern, Identify and Protect help organizations prevent incidents, and prepareto handle incidents that do occur, reduce the impact of those incidents and improve incident response and cybersecurity risk management practices based on lessons learned. Detect, Respond and Recover help organizations discover, manage, prioritize, contain, eradicate and recover from cybersecurity incidents, as well as perform incident reporting, notification and other incident-related communications.
The top half reflects that Govern, Identify, and Protect preparedness activities are not part of the incident response lifecycle. Rather, they are much broader cybersecurity risk management activities that also support incident response
The new response lifecycle, for each incident, is noted in the bottom half of the model - Detect, Respond and Recover. In addition, continuous improvement is indicated within the Identify function and the green dotted lines.
Lessons learned then emerge from all functions, these are analyzed, prioritized and used to in turn inform all functions. This reflects that organizations should be learning new lessons at all times (e.g., detecting the presence of a new threat and characterizing its behavior) and communicating those lessons to appropriate personnel so that the organization's incident response policies, processes and practices and other aspects of cybersecurity risk management can be adjusted as needed.
If we would like to connect the known with the new, we can map the phases of the previous SP 800-61 to those of the new draft:
Community Profiles
Community Profiles provide a way for groups of organizations, who share a common context and cybersecurity posture, to describe a joint view on cybersecurity risk management.
The National Cybersecurity Center of Excellence (NCCoE) provides examples of these profiles and other resources to help communities understand and develop. A CSF Community Profile functions as a baseline of results.
These profiles are typically developed for a specific sector, subsector, technology, threat type, or other use case (CSF2.0). Revision 3 is then defined as a CSF 2.0 community profile specific to incident response. It uses the CSF Core as a basis for highlighting and prioritizing outcomes that are important to incident response, makes recommendations, and provides other supporting information for certain CSF outcomes within the incident response context.
You can see that the community profile in the guide is divided into two tables: the first table covering Preparedness (Govern, Identify and Protect), while the second covers the Incident Response Lifecycle (Detect, Respond and Recover).
The relative priority of each row is indicated with:
• High: Functions as a core incident response activity for most organizations.
• Medium: Directly supports incident response activities for most organizations.
• Low: Indirectly supports incident response activities for most organizations.
The last column may contain one or more items that recommend what to do or describe additional considerations or supporting information for some rows. Each item in that column has an ID that begins with one of the following:
• “R” (recommendation: something the organization should do).
• “C” (consideration: something the organization should consider doing).
• “N” (note: additional information, in addition to recommendations and considerations).
An R, C, or N designation and its number can be added to the CSF ID of the row to create an identifier that is unique within the Community Profile (e.g., "GV.OC-03.R1" is recommendation 1 for CSF Subcategory GV.OC-03). The recommendations and notes are not exhaustive, and not all will be applicable to every organization.
The Community Profile is intended for use by most organizations, regardless of sector, size or other factors.
Conclusions
The scope of Revision 3 is significantly different from previous revisions. Because the details of how to perform incident response activities change so often and vary so much between technologies, environments, and organizations, it is no longer feasible to capture and maintain that information in a single static publication. Instead, this revision focuses on continuous improvement of cybersecurity risk management for all NIST CSF 2.0 functions. This better supports organizations' incident response capabilities and addresses the growing volume of damaging incidents with extended recovery periods.
While it is true that each organization should use the incident response lifecycle framework or model that best suits them. The proposed model leverages the wealth of resources available and allows it to be easily adopted by organizations already using the CSF. Each organization should consider incident response in the context of its risk management and its own business.
