Incident Response Process: The 6 Steps and How to Test They Work

Incident Response Process Approaches

A key difference between various incident response processes is the type of triggers initiating a response. Some triggers involve the tangible effects of an attack, while other triggers provide an early warning based on indirect indications of compromise. The first trigger usually responds to zero-day threats, with users already noticing performance issues. The second type usually preempts issues before they impact the end-users—however, these triggers are more prone to false positives.

These triggering approaches determine the main types of incident response processes:

• Front-loaded prevention—collect threat intelligence data and indicators of compromise to prevent attacks early. This approach helps address threats before they cause damage, but their higher rate of false positives can increase costs. However, the high number of false-positive responses is often an acceptable price to protect critical assets.

• Back-loaded recovery—collect data on visible threats and incidents, which may already be successful. This approach minimizes false positives but cannot stop attacks early on. It is unsuitable for critical infrastructure or high-stakes applications.

• Hybrid incident response—combine front-loaded and back-loaded data processing to enable early detection and urgent response. This approach offers a more comprehensive response strategy, but it usually demands a larger investment in time and resources. A hybrid approach should emphasize prevention, with the back-loaded response reserved for non-critical components.

The Incident Response Process

Incident response plans detail how organizations should respond to cyberattacks. There are six steps to address when developing an incident response plan. This process is inspired by the popular incident response framework developed by the SANS Institute.

Related content: Read our guide to the NIST incident response process

1. Preparation

In the case of a cyber attack, the incident response team needs to be fully prepared. Organizations need step-by-step guidance to define how incident response teams will handle incidents, including internal and external communications and incident documentation.

2. Identification

Identification is the detection of malicious activity. This can be based on security and monitoring tools, publicly available threat information, or insider information. An important part of identification is to collect and analyze as much data as possible about malicious activity.

Incident response teams must distinguish between benign activity and true malicious behavior. This requires a major effort in reviewing security alerts and determining whether alerts are “false positives” — not real security incidents — or “true positives,” which indicate malicious activity.

3. Containment

Containment is an attempt to stop the threat from spreading in the environment and doing more damage. There are two types of containment:

• Short-term containment—immediate action to prevent the threat from spreading. For example, quarantining an application or isolating a system from the network.

• Long-term containment—restores systems to production in a clean state before the threat was introduced.

4. Eradication

This process includes identifying the point of intrusion, assessing the attack surface, and removing any remaining backdoor access. At this stage, the incident response team neutralizes any remaining attacks. As part of this step, the team determines the root cause of the incident, to understand how to prevent similar attacks.

5. Recovery

At this stage, the incident response team returns systems to normal operation. Compromised accounts are given new, more secure passwords, or replaced with a more secure access method. Vulnerabilities are remediated, functionality is tested, and normal operations resume.

6. Lessons Learned

There are lessons to learn from any cybersecurity incident, both at the process level, and because threats are constantly changing and evolving. Learning from experience and pinpointing what went wrong is an important step in improving your ongoing incident response plan. It is a good practice to perform a post-mortem meeting with the entire team to provide feedback on what worked and what didn’t, and raise suggestions for process improvement.

Related content: Read our guide to incident response plan

Putting Your Incident Response Processes to the Test

Incident response testing determines whether an in-house or outsourced incident response process is effective and identifies critical gaps. These gaps could be in the form of ineffective integrations between technology tools, misconfigured security controls, process issues, or miscommunications between team members. Any of these issues could be disastrous if a real attack occurred, so it is critical to discover them early.

There are three common ways to test an incident response system:

• Paper-based testing—a theoretical exercise for testing "what if" scenarios. Paper-based testing has limited effectiveness, but it can still reveal obvious gaps and missing processes.

• Tabletop exercises—a scheduled activity in which all key stakeholders of the company and incident response provider are seated around a table to respond to a hypothetical security incident. Activity should be planned in advance, including moves by the external attackers. If you have a large team, you can divide them into a "blue team" that represents incident responders and a "red team" that represents the attackers.

• Simulated attacks—you can perform a realistic, fake attack on your network by contracting with external penetration testers or by using security testers from your own security team. Attacks might be either pre-coordinated with your internal team and incident response provider, or blind attacks without prior notice. A simulated attack is very useful in showing what went wrong and identifying gaps in your internal security systems, processes, or integration with an external incident response provider.