Most security leaders focus on two incident response frameworks: 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.
The NIST incident response life cycle has 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.
