The incident response process is necessarily a reactive one. You can only respond to an incident once it has been detected.  

This makes it difficult to predict or optimize incident response outcomes. If an organization has never experienced a ransomware attack, how will it know when it’s ready to face one? 

Incident response frameworks enable organizations to address this problem by creating standardized response plans. These frameworks are developed by reputable cybersecurity leaders and informed by industry expertise. 

With an incident response framework in place, your organization can develop a set of incident response playbooks. These playbooks provide a structured, step-by-step response to certain threats. Having a comprehensive set of playbooks ensures your organization can reliably protect itself from a wide range of threats. 

Why adopt an incident response framework? 

Nothing stops a security team from building their own set of incident response playbooks without adhering to any specific framework. Many organizations do not adhere fully to any specific framework, and some only adhere partially. 

 However, this approach can generate problems: 

• Your playbooks may not be consistent with one another. Incident response frameworks provide consistent structure, terminology, and objectives for all security incidents. Without these, some tasks and processes may be counterproductive to others — especially in complex threat scenarios. 

• You may have trouble responding to a security incident that doesn’t fit neatly into an existing playbook. Without a framework to build on, expanding an existing incident response playbook beyond its original scope is difficult and risky. If attackers use an innovative or unexpected approach, your team may be unable to coherently respond. 

• If your security team needs to improvise, there is no further guidance on what they should do. Predicting every possible contingency is not always feasible. Your security team may face issues it hasn’t planned ahead for. When that happens, a framework provides structure that helps keep security tasks from veering off into uncharted territory. 

• Learning from security incidents becomes much harder. Without a foundation in place for describing incident response operations, documenting them becomes a tedious and time-consuming effort. It may not even be done at all, making continuous improvement impossible. 

Building incident response playbooks around a consistent framework enables your security team to respond quickly and decisively to unauthorized activity. 

The benefits of adopting a standardized incident response framework 

Incident response frameworks provide significant benefits to organizations that adopt them. Building a set of response plans on a uniform foundation allows them to complement one another in ways that considerably improve operational security. 

Some of the benefits to building incident response workflows around an established framework include: 

• Increased predictability. Security incidents are filled with uncertainty. Standardization helps reduce uncertainty and improve outcomes across the board. 

• Better reputation. Demonstrating compliance with trusted frameworks tells users, partners, and stakeholders that your organization is competent and secure. 

• Smoother communication. Sharing a standard terminology for describing security incidents helps security practitioners, IT team members, and executive leaders communicate effectively about security risks. 

• Improved security event outcomes. Frameworks can help you design incident response plans that reduce downtime, limit damage, and scale response resources when needed. 

• Regulatory compliance. Many security regulations include requirements that overlap with well-known incident response frameworks. Achieving compliance often means structuring your detection and response workflows accordingly. 

 Adopting a framework doesn’t always mean building it yourself. Many security leaders standardize their incident response processes by collaborating with managed detection and response vendors that already adhere to a well-known framework. 

Two Incident Response Frameworks: NIST and SANS 

Many different organizations have published incident response frameworks, but two stand out in the cybersecurity community: NIST and SANS. 

• NIST SP 800-61 is published by the National Institute of Standards and Technology. It describes a six-phase incident response process that includes guidelines for building security policies and communicating with external stakeholders. 

• The SANS Incident Handler’s Handbook provides in-depth technical guidance for building incident response plans. It is published by the SANS Institute, a private company that specializes in cybersecurity training and certification. 

What makes NIST different from SANS? 

Both NIST and SANS are reputable organizations with a strong track record of cybersecurity leadership. Neither organization’s incident response framework is “better” than the other. 

However, there are key differences that might make one a better fit for your organization. 

• Since NIST is a government organization, its framework is designed to provide uniform guidance that applies to a variety of industries. That means you won’t find detailed technical requirements you can immediately implement at your organization in the NIST framework. 

• The SANS Institute offers training and certification to cybersecurity professionals. As a result, its incident response framework is more technical in nature. It provides deep insight into how incident response plans should identify, contain, and eradicate security threats using the latest technology. 

The NIST incident response lifecycle explained 

NIST SP 800-61 Revision 3 describes the incident response lifecycle in four stages: 

1. Preparation

NIST recognizes that security leaders must plan for incidents, and that the quality of preparation deeply impacts the likelihood of a positive outcome. The first phase of the incident response life cycle involves identifying the assets and resources required to successfully conduct incident response tasks. 

Some of the actions security teams carry out at this stage include: 

• Establishing the organization’s incident management capabilities. 

• Creating detailed incident response policies and procedures. 

• Training security personnel and IT professionals to respond to incidents effectively. 

• Acquiring purpose-built security technologies that enable incident response. 

• Deploying a system for tracking security incidents. 

• Establishing processes and reporting policies. 

2. Detection and analysis

Once your organization has the capacity to detect incidents, it can detect and analyze indicators of compromise across its network. 

This phase involves configuring the organization’s security tools and monitoring systems. Depending on the tools you equipped your security team with in the first step, this might include: 

• Configuring firewall policies to detect known indicators of compromise and protect against modern threats. 

• Deploy intrusion detection systems to catch attackers as they attempt to breach the network perimeter. 

• Configure your network detection and response (NDR) solution to report on anomalous behaviors throughout your environment. 

• Enhance your security information and event management (SIEM) platform with contextual alerts and automation. 

3. Containment, eradication, and recovery

Once a security incident is confirmed, your team must contain the damage and regain control of your systems. This requires identifying compromised systems and eliminating threats from your environment. 

NIST recommends creating detailed containment strategies in advance. These plans should follow the broad categories that most security threats fall into — email threats, network threats, malware, and so on. 

This makes it easier to make the right decision in a confirmed threat scenario when every second counts. You may need to remove malware, quarantine infected systems, and recover compromised devices from an earlier backup. 

4. Post-incident activity

Post-incident activity provides clear, actionable insight on how to improve the incident response process moving forward. Professional security teams use after-action reports to drive the value of incident response workflows and improve outcomes over time. 

This is the right time to ask important questions, like: 

• Which security policies or configurations failed? 

• Which staff roles were involved and how did they perform? 

• Were mistakes made during the incident response process? Did they impede recovery? 

• How can security policies and procedures be improved? 

The SANS incident response framework explained 

The SANS Institute has its own set of incident response guidelines that focus more on the technical requirements associated with operational security excellence. These fall into six categories: 

1. Preparation

Preparation revolves around reviewing and codifying security policies. It includes performing risk assessments so that your team can identify sensitive assets and take steps to protect them. 

It also includes defining potential security incidents and categorizing them based on their severity. This will help you decide which security incidents have priority in complex threat scenarios where more than one asset or application may be impacted, or multiple threat actors may be involved. 

2. Identification

This step involves detection workflows that alert analysts when users, assets, and applications deviate from normal operations. It includes investigations, which provide guidance on when and how analysts should escalate their findings. 

The framework also stipulates methods for collecting additional evidence when investigating security events. The goal is for analysts to establish the type and severity of security breaches and document every detail associated with the unauthorized activity. 

3. Containment

The SANS framework recommends performing short-term containment immediately upon detecting and confirming a security threat. An example of short-term containment might be isolating the network segment that a compromised endpoint device belongs to. 

After that, the incident response team can focus on long-term containment. This involves deploying temporary fixes to allow impacted systems to continue functioning while rebuilding systems for clean performance. 

4. Eradication

This step is all about removing malware from impacted systems, identifying the root cause of the security breach, and acting in response. It may involve blocking malicious processes and terminating unauthorized executions throughout the network. 

Without thorough completion of the preceding steps, eradication can become overly complicated. For example, the incident response team could overlook a compromised credential without enough visibility into the organization’s IT infrastructure. 

5. Recovery

During recovery, the incident response team works to bring impacted production systems back online. The framework recommends doing this cautiously, in distinct phases. This reduces the risk of bringing compromised or misconfigured systems online and making the incident worse. 

The recovery process includes testing and verifying affected systems to make sure they exhibit normal behavior. It includes guidance on exactly what technical metrics to use when qualifying post-incident system behavior. 

6. Lessons learned

The SANS incident response framework stipulates a two-week period for gathering and compiling data into an after-action report. This report should consist of all relevant data regarding the incident, along with insight into how to avoid similar incidents in the future. 

The SANS incident response framework explained 

The SANS Institute has published a separate set of guidelines that emphasize the technical requirements of effective incident response. These fall into six categories: 

• Preparation 

• Identification 

• Containment 

• Eradication 

• Recovery 

• Lessons learned

1. Preparation 

Preparation is about reviewing and codifying security policies. Performing risk assessments and identifying sensitive assets are some of the tasks performed at this step. 

It also includes researching potential security threats that may impact the organization and categorizing them based on their severity. This will help the team prioritize security tasks in complex threat scenarios that impact more than one asset or application, or those that involve multiple threat actors. 

2. Identification 

This step involves configuring detection rules that tell SOC analysts when network users or assets start acting abnormally. It provides structure to conducting event investigations, providing guidance on when and how to escalate an event to an incident. 

The framework also provides methods for collecting additional evidence when investigating security events. The goal is to establish the type and severity of security breaches and document every detail associated with unauthorized activity before taking action. 

3. Containment 

The SANS framework recommends completing short-term containment before focusing on long-term containment. Short-term containment might include isolating the network segment that a compromised endpoint device belongs to, or disconnecting compromised devices from the network. 

At that point the incident response team can focus on long-term containment. This might involve deploying patches and updates that allow impacted systems to continue functioning, or rebuilding compromised systems to ensure safe performance. 

4. Eradication 

Eradication means removing malware from impacted systems and identifying the root cause behind the breach. It also involves terminating malicious executions and blocking unauthorized processes throughout the network. 

This step can’t be completed if the first three steps were not carried out effectively. If the incident response team doesn't have enough visibility into the organization’s IT infrastructure, it might overlook a compromised credential or device and fail to fully remove threat actors from the network. 

5. Recovery 

This is when the incident response team brings impacted production systems back online. The SANS framework recommends doing this in gradual, distinct phases. This reduces the risk of making the incident worse by bringing compromised or misconfigured systems online directly. 

The recovery process includes testing affected systems to make sure they are operating normally. It offers guidance on the technical metrics security teams should use when analyzing post-incident system behavior. 

6. Lessons learned 

No more than two weeks after the incident, the team should compile all the information about that incident into an after-action report. It should provide complete documentation about the incident, including the steps that led to the original breach and recommendations for improving operational security. 

The best after-action reports include comparison benchmarks with metrics derived from past incidents faced by the same team. Team members, stakeholders, and users may have valuable suggestions for preventing similar breaches in the future. 

Beyond NIST and SANS: Other Incident Response Frameworks 

NIST and SANS are the most popular incident response frameworks in the United States, but they are not the only ones. Your organization may decide to structure its response procedures on other frameworks, or mix and match requirement criteria from multiple frameworks. 

Other incident response frameworks you should be familiar with include:  

• ISO 27035-1:2023 is published by the International Standards Organization. It overlaps with NIST in many areas, but has a greater focus on risk management. 

• The Institute of Electrical and Electronics Engineers (IEEE) maintains an incident response framework for hardware and operating technology. It includes highly technical guides for securing specific hardware products and toolsets, making it useful for manufacturers and industrial organizations. 

• The European Union Agency for Cybersecurity (ENISA) maintains a framework specifically designed for organizations operating in the European Union. It offers additional context and resources for meeting European data privacy laws and launching cross-border cybersecurity investigations 

Incident response frameworks are vital to operational security success 

Regardless of the specific incident response framework you choose, standardizing your approach to security operations is an excellent way to ensure positive outcomes consistently. The structure provided by these frameworks allows security practitioners to work faster and more confidently in uncertain scenarios where every second counts. 

Implementing a well-documented incident response strategy reduces uncertainty and mitigates the risk associated with known and unknown threats. Building incident response playbooks around an industry-standard framework empowers security teams to safeguard network assets and prevent catastrophic breaches effectively. 

Discover how Lumifi’s people, processes, and technology can help you scale your incident response capabilities to meet the demands of a challenging threat landscape. Talk to an expert about enhancing your security capabilities today.