kras99 - stock.adobe.com
CISO's guide: How to test an incident response plan
Creating an incident response plan is only the beginning. Regular testing will help ensure it doesn't fall apart during a real cybersecurity event.
An incident response plan helps mitigate unexpected and potentially disruptive cybersecurity events. Testing that plan is very much like test-driving a new car. It's how a potential buyer confirms the experience lives up to the hype. Do all the features work as promised? Does it drive smoothly? Are there issues that could hinder the vehicle's performance and safety? These are things any conscientious driver would want to learn before driving off the lot.
Test-driving an incident response plan is equally important. It helps identify what in the plan works, what needs to be fixed, whether the resources are appropriate and if the incident response team can handle their roles and responsibilities when a real cybersecurity incident strikes.
Methods to test an incident response plan
Testing an incident response plan is not a one-size-fits-all proposition. Just as cybersecurity incidents take many forms, so do planning approaches.
Tabletop exercises
A popular option, tabletop exercises involve gathering members of the incident response team, on-site or virtually, with a designated facilitator who manages the operation. The facilitator defines a security scenario and participants discuss what they should do as the exercise unfolds, typically following the procedures outlined in the incident response plan and incident response playbooks. Throughout the process, the team identifies responses and actions to protect data and systems. To help the team learn from the exercise, an after-action report examines what worked and what didn't.
Functional exercises
Taking the tabletop exercise model to the next level, functional exercises involve team members performing their duties as if a real event were unfolding. While no production systems are involved, functional exercises help participants test specific activities, such as communication during an event or data recovery.
Full-scale simulations
To validate an incident response plan and determine whether team members can perform as needed, full-scale exercises launch seemingly real -- but simulated -- attacks on production systems. For instance, a simulation to test whether firewalls work properly would require teams to detect the attack and launch remediation activities. Setting up the exercise could require a suitable live test environment. To lend authenticity, internal leadership teams or external stakeholders might take part in the exercise.
Penetration testing and red team exercises
While pen tests are often performed independently to identify vulnerabilities in an enterprise security infrastructure, they can also be part of an incident response plan exercise. Red team exercises involve experienced ethical hackers who launch cyberattacks designed to exploit an organization's security ecosystem.
Cyberattack scenarios
Identifying one or more relevant scenarios for an incident response plan test is a critical activity. Following are some suggested scenarios:
- Ransomware attacks.
- Phishing attacks.
- Attacks that steal, destroy or corrupt data.
- DDoS attacks.
- Social engineering attacks.
- Power failures that shut down security systems.
- Fires in the data center.
- Gas or water leaks.
- Severe weather events that disrupt utility infrastructure.
- Loss of the internet.
- Insider attacks, e.g., a disgruntled or rogue employee.
- Unauthorized shadow IT activities.
- Supply chain attacks.
- Cloud service misconfigurations.
- Industrial control system attacks.
- Breaches that disrupt physical security systems.
- Attacks that compromise regulatory compliance.
- Data leaks to the media.
- Advanced persistent threats.
- Viruses on end-user systems.
Some scenarios simulate traditional security incidents while others involve disruptions to infrastructure, support systems and data security. Consider combining multiple scenarios to deliver even more challenging tests.
Steps to develop incident response plan tests
Preparing for, executing and reviewing the outcomes of an incident response plan test can take significant time and effort, but will pay off during an actual security incident.
- Assess the existing incident response plan and determine which aspects of the plan to test -- for example, anomaly detection, incident containment, or backup or data recovery.
- Outline the test plan and identify test parameters, who to involve and necessary resources.
- Determine what criteria and metrics -- e.g., time to detect, time to respond, time to remediate -- declare the test a success. Clear evaluation metrics will also inform the after-action report.
- Ask senior leadership to review the test to ensure objectives align with expectations.
- Prepare test scripts to facilitate the test, or invite cybersecurity vendors to contribute scripts.
- Ensure all resources -- e.g., network perimeter systems, anomaly detection and analysis -- work properly.
- Notify leadership and other departments -- especially in IT and business units that might be affected -- of the proposed incident response test.
- Discuss activities with all members of the test team in advance. Ensure each person knows their role and responsibilities.
- Conduct the test in an environment that will not affect production systems. If possible, schedule a dry run to uncover problems -- e.g., incorrect scripts or URLs -- that could affect success.
- Launch the test. Have the facilitator introduce the scenario, monitor progress and encourage participant discussions.
- Assign someone to take notes and track the time for test activities. Be prepared to pause or stop the test if activities and procedures do not proceed as planned.
- After completing the test and documenting results, conduct a debrief to gauge what worked, what didn't and any remediations required. If cybersecurity vendors participated, review test results to see how they can help resolve any issues.
- Prepare an after-action report for the test and submit it to management.
- Revise the incident response plan based on lessons learned from the test. If possible, conduct another test to see if the revised incident response plan and updated procedures result in a successful test.
Potential planning gaps
While testing an incident response plan is a highly valuable exercise, it is no substitute for what security teams can expect during an authentic cybersecurity incident. In a real-world event, many things can go wrong. For example, team members who perform well during tests might not perform as well in a real attack. The incident response plan could also be flawed, requiring team members to quickly assess and adapt if documented responses do not align with the topics covered in testing.
Preparation, however, is the best defense CISOs can mount in an expanding threat landscape. Testing an incident response plan, whether for cybersecurity or any other undesirable situation, is an essential way to increase the likelihood of enterprise survival in the wake of the unexpected.
Paul Kirvan, FBCI, CISA, is an independent consultant and technical writer with more than 35 years of experience in business continuity, disaster recovery, resilience, cybersecurity, GRC, telecom and technical writing.
