How do you test an incident response plan?

It’s highly likely that your organization will experience a cybersecurity incident. When that happens, an up-to-date incident response plan can make a big difference in how quickly and effectively you mitigate risk, contain threats, and recover from a breach or attack.

An incident response plan documents procedures and processes that should be followed—and the people who should execute them—in the event of a cyber incident. While any type of response to a cyber incident has the same goals, following a formal, written, and tested plan is far superior to relying on ad hoc actions. In other words, it pays to be prepared.

Benefits of an incident response plan range from cost and time savings to better damage mitigation and regulatory compliance. Using a plan can also help an organization gain insights and experience from dealing with an incident to guide future responses.

To help organizations create a plan, the National Institute of Standards and Technology (NIST) developed a detailed guide. It presents an incident response framework that comprises four stages:

1. Preparation
2. Detection and analysis
3. Containment, eradication and recovery
4. Post-incident activity

The SANS Institute developed a similar guide with six steps:

1. Preparation
2. Identification
3. Containment
4. Eradication
5. Recovery
6. Lessons learned

To these lists many organizations add another step: testing the process on a regular basis.

A robust, comprehensive plan begins with a mission statement and a list of actionable goals. To support the mission and goals, the plan typically covers:

• Incident response team structure: For instance, the NIST guide proposes three different team models: centralized, distributed, and coordinated
• Roles and responsibilities of the incident response team members
• Training guidelines for the incident response team
• Incident classification and prioritization based on severity and potential impact
• Specific, standardized steps (playbooks) for each phase of the incident response process
• Escalation requirements
• Business continuity procedures for restoring systems and data
• Communications plan to inform leadership, employees, shareholders, customers, partners, and other audiences about the incident
• Vendor management protocols
• Post-incident review, analysis, and documentation
• Vulnerability management
• Regulatory disclosures, if required

At a high level, this process involves recognizing and assessing an incident, responding to it based on its urgency and severity, notifying stakeholders about it, advising the U.S. Securities and Exchange Commission within four business days, if the organization is a publicly traded company, and restoring normal systems and operations.

At a tactical level, based on the NIST framework, there are a number of activities associated with each of the four stages.

Preparation

This stage focuses on creating and refining incident response policies, procedures, and escalation rules, forming and training the incident response team, and drafting and formalizing the incident response plan.

Because cyberthreats can affect many aspects of the business, the incident response team should have representatives from key cross-functional areas, including IT, security, legal/regulatory, and communications/public relations.

Detection and analysis

The second stage concentrates on detecting security incidents using continuous monitoring, intrusion detection solutions, and other tools. Once an incident is detected, it should be analyzed to determine its scope and severity, the importance of the data and systems involved, and potential effects on the organization.

Containment, eradication, and recovery

The next stage centers on incident mitigation to prevent additional impacts and minimize damage. To contain the threat, the incident response team may need to isolate affected systems, deactivate compromised user accounts, or block malicious network traffic. Then, to eradicate the threat, the team may have to patch vulnerabilities and reimage systems to remove malicious code or malware that has been introduced into the environment. Recovery means restoring systems, data, and assets to a known good state.

Post-incident activity

Following any cybersecurity incident, it’s essential to conduct a review of what occurred and how well the incident response plan worked. Only by learning from the experience, and applying these lessons to the process, can an organization strengthen its security posture for the future.

Post-incident activities may include:

• Review of the incident by the full team to understand its root cause/s and full implications
• Assessment of all users and systems affected by the incident
• Documentation of incident metrics such as mean time to discovery (MTTD) and mean time to repair (MTTR)
• Documentation of containment and remediation measures
• Communication with stakeholders, including senior leadership, about the resolution of the incident
• Compliance reporting
• Retention of data associated with the incident

As we mentioned earlier, it’s wise to add a step to the NIST or SANS framework by conducting periodic incident response plan testing. This exercise helps the incident response team figure out whether processes and procedures laid out in the plan are effective and comprehensive.

The main goal of regular testing is to pinpoint shortcomings or weaknesses in the current plan to guide improvements, adjustments, or enhancements—particularly in the face of evolving threats, changes in the organization’s attack surface, and other variables. Issues uncovered during testing could include insufficient team training, poor communication or coordination among team members, or slow response times.

Following are benefits of testing:

• Higher readiness: Regular testing enables the incident response team to become familiar with their roles and responsibilities in the process ahead of time to avoid a learning curve during an actual incident. Testing also offers a way to practice dealing with different types of scenarios.
• Less downtime: Familiarity with the plan can help teams carry out their duties in a smooth, coordinated way, thereby shortening the time required to detect, respond to, and recover from an incident. Greater speed and efficiency can help minimize system downtime and other negative impacts on the business caused by an incident.
• Greater confidence: Regular testing—and subsequent modifications to the plan—build confidence in its robustness and effectiveness, not just within the team, but also among senior leaders.
• Stronger compliance: By conducting regular tests, organizations can demonstrate to regulators that they are prepared for security incidents and compliant with requirements.

An incident response plan may look great on paper, but testing will reveal whether it works as it should. There are a number of ways to test an incident response plan, including team discussions, simulations, penetration testing, and red teaming.

• Tabletop exercises: During these sessions, the incident response team members discuss a security incident by walking through one or more example scenarios, such as an insider threat, a ransomware attack, or a data breach. Typically, a facilitator presents each scenario and asks the participants questions about it, including their roles and responses, team coordination, and communications. The advantages of this approach are low risk to the organization, and minimal preparation and resources.
• Simulation exercises: These live, choreographed exercises test both the technical and procedural aspects of the plan. They allow incident response teams to validate their preparedness by performing their assigned roles in a simulated, yet realistic, environment. A simulation gives team members invaluable hands-on experience regarding how the incident response process actually unfolds—for better or worse.
• Functional drills: As their name indicates, these drills test different functional aspects of the incident response plan, such as detection, analysis, or communications. By breaking down the plan into its components, functional drills help ensure that each one is fine-tuned and ready for an actual situation. They are particularly helpful for evaluating changes or updates without having to test the entire plan.
• Penetration testing and red teaming: These methods use simulated attacks to identify security vulnerabilities and assess the effectiveness of the incident response plan.

Recommendations for testing frequency range from annually to quarterly to “as needed.” Some standards, such as PCI DSS and Service Organization Control Type 2 (SOC 2), call for yearly testing of the plan. An organization’s cyber insurance plan may require annual testing and/or updating of their incident response plan, as well.

The arguments for less-frequent testing include avoiding costs, time, and the need to engage outside facilitators or penetration testers. Test preparation, execution, and follow-up divert people from their regular duties and can disrupt operations.

The case for more-frequent testing includes:

• Familiarizing new members of the incident response team so they are on the same page as the rest of the team
• Reinforcing the team’s understanding of the plan’s strategy and tactics
• Keeping pace with changes in the organization’s security posture, infrastructure, risks, and priorities
• Obtaining timely feedback on weaknesses in the plan so it can be improved or expanded