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.
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:
Building incident response playbooks around a consistent framework enables your security team to respond quickly and decisively to unauthorized activity.
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:
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.
Many different organizations have published incident response frameworks, but two stand out in the cybersecurity community: NIST and 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.
NIST SP 800-61 Revision 3 describes the incident response lifecycle in four stages:
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:
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:
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.
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:
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:
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.
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.
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.
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.
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.
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 Institute has published a separate set of guidelines that emphasize the technical requirements of effective incident response. These fall into six categories:
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.
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:
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.
