NIST Incident Response: Framework and Key Recommendations

What is NIST Incident Response?

Incident response is the practice of systematically responding to cybersecurity incidents. The process involves identifying if an incident is malicious, taking action to quickly contain it and minimize damage, eradicate the threat, and learn from the incident to improve the process.

The National Institute of Standards and Technology (NIST) is a US government organization that develops standards in many technical fields. It created one of the two most commonly used standards for incident response. The other is the SANS Incident Response process.

Under attack? Get help from the BlueVoyant incident response team.

Why Does NIST Provide Recommendations on Incident Response?

NIST has developed its incident response guidelines to help federal agencies, businesses, and non-profit organizations prepare and respond to cybersecurity incidents as quickly as possible.

The Federal Information Security Modernization Act (FISMA) obligates U.S. federal government agencies to demonstrate incident response capabilities, and these agencies must do so according to NIST guidelines. However, the NIST guidelines have been voluntarily adopted by many organizations from the private sector.

NIST published the second edition of its Guidelines for Handling Computer Security Incidents. The guidelines present a systematic process that organizations can follow to prepare for, identify, and handle cybersecurity incidents. The NIST incident response process is cyclical — after a cybersecurity incident occurs, the process is repeated, and the results of the incident are used to improve processes, systems, and practices.

The NIST guide is comprehensive and includes a checklist to prepare for security events, which can be used as you build your own audit checklist. The second edition also offers an extended section on how to share information between organizations in the case of a cybersecurity threat.

Related content: Read our guide to incident response policy

NIST Incident Response Framework: The 4 Steps

The NIST framework includes four stages: preparation and prevention; detection and analysis; containment, eradication, and recovery; and post-incident activity.

Related content: Learn about these and other aspects of incident response in our guide to incident response planning

Step 1: Incident Preparation and Prevention

The first phase of the NIST framework includes two important functions: preparation and prevention.

Preparation involves the following elements:

• Incident handler communications — contact information and assurance of identity for all team members and stakeholders.

• Incident analysis technology — including physical and virtual means for creating a case, sharing it, analyzing incidents, and enriching incidents with threat intelligence.

• Incident analysis resources — primarily refers to threat intelligence sources such as databases of known vulnerabilities or threat vectors.

• Incident mitigation software — including all security and operational tools that can be used to mitigate threats and recover from a cyberattack.

Prevention means that organizations should optimize their access control and risk assessment capabilities to monitor for suspicious activity minimizing potential harm. Other preventive measures include antivirus software and security training for employees.

Step 2: Detection & Analysis

The second step in the NIST process is to determine whether an event has occurred, its severity, and its type. This involves the following elements:

• Identify precursors and indicators of an incident — a precursor is an indicator that an incident is about to happen, while an indicator shows that suspicious activity is already occurring in the environment.

• Analyze precursors and indicators — once identified, incident responders must determine if the detected signals represent a real attack or are false positives.

• Incident documentation — in case of a real attack, incident responders must document all facts related to the incident, as well as any actions taken throughout the incident response process.

• Incident prioritization — according to the NIST guidelines, this step is the most important decision point in the process. Incidents should not be handled in the order of their detection. Instead, incidents should be scored based on their impact on business functions, the confidentiality of the information affected, and how difficult it would be to recover from the incident.

• Incident notification — after an incident has been analyzed and prioritized, incident responders must notify the appropriate people. An incident response plan must include specific reporting requirements, both within and outside the organization. This should also include compliance requirements for incident notification.

Step 3: Containment, Eradication, and Recovery

In this step, the incident response team determines the most appropriate containment strategy to stop an incident from spreading and reduce damage. The end goal is to completely eradicate the threat and recover systems. This involves:

• Gathering data — the data can also be used for forensic investigation and in subsequent legal proceedings.

• Identifying and neutralizing the attacker — before eradicating an incident, the incident response team should attempt to positively identify the attacking party and determine what steps are necessary to neutralize it.

• Eradication and recovery — this includes removing both active and inactive elements of the attack and taking any actions necessary to clean corporate systems. Finally, when a system is known to be clean, it can be recovered to resume operations. This is an ongoing process, which happens in parallel to other activities.

Step 4: Post-Incident Activity

Every event should be an opportunity to learn and improve. Attackers are constantly evolving, and so should an incident response team. There is a constant need to learn about new attacker techniques, and keep up with the latest technologies, strategies and procedures.

Regular post-mortem meetings with all stakeholders can help improve overall security and improve incident handling procedures. These should be mandatory after serious accidents and encouraged after less serious accidents. In the event of a large-scale attack, the post-mortem process should involve essential personnel across the organization, who can be consulted in case they are needed for future collaboration.

A post-mortem meeting should cover at least the following points:

• Chain of events, timeline, and precursors or indicators that were used, or could be used, to detect the incident.

• Performance of the incident response team.

• Whether the incident was handled according to planned procedures, and whether they were adequate.

• Information that was missing and needed to address the incident, and problems or issues that delayed recovery.

• Suggestions for better response to the same incident in the future.

• Suggestions for preventing similar incidents.

The results of these meetings can be an important educational tool for new hires. They can also be used to update policies and procedures and generate useful institutional knowledge for future events.

NIST Recommendations for Incident Response Teams

The NIST’s Computer Security Incident Handling Guide offers incident response guidelines for organizations. It involves using the following models for incident response teams:

• Central — a centralized body responsible for incident response across the organization.

• Distributed — several incident response teams, each responsible for a part of the IT infrastructure, a department, or a physical location (branch office).

• Coordinated — a central incident response team collaborating with distributed teams without authority over them. The central team provides a knowledge center and assistance with critical, organization-wide, or complex incidents.

The above models can employ full-time or part-time personnel, partially outsourced expertise, or fully outsourced staff.

Here are several considerations NIST recommends for choosing an incident response model:

• 24/7 incident response — do you require on-site incident responders or is phone contact sufficient? On-site presence and real-time availability are ideal for enabling immediate response to incidents but are not always viable.

• Part-time or full-time staff — part-time employees can serve as a virtual incident response team that performs an initial investigation during emergencies. They can then quickly call incident response team members available to respond to the incident.

• Security experts — incident response requires expertise and knowledge of communication protocols, IT systems, attack techniques, and the organization’s systems, procedures, and environments. Outsourced teams have strong security expertise, but employees typically better understand the organization’s IT environment and normal behavior.

• Incident response team cost — incident responders often need to be on-site 24/7, incurring a high level of investment. Other costs include security tooling, secure communication methods, and physical facilities.