When was the last time you tested your organization's security incident response plan? All the response plans in the world -- however effective they may be -- won't do your organization any good if the plan doesn't work. Mike Mullins tells you how to put your response plan to the test.
When was the last time you tested your organization's security incident response plan? I've written extensively on the importance of creating such a response plan -- how to create a security incident response policy, specific steps to take in response to a security incident, and even specific steps to take in response to a malware incident.
So, I'll ask again: When was the last time you tested your incident response plan? I'm not talking about the part of your disaster recovery plan in which you restore your network to a known good backup. I'm talking about the crisis management phase where you're under the gun to stop something that's trying to destroy your network.
All the response plans in the world -- however effective they may be -- won't do your organization any good if the plan doesn't work. That's why you need to test it before you need to use it.
Don't make the mistake of creating a paper-only security response plan just to satisfy regulatory requirements. You might as well figure out a strategy to stop localized problems before they shut down your corporate network.
Let's walk through an example: A new virus is circulating in the wild -- a common enough occurrence. Now, let's look at two scenarios.
After either receiving alerts or observing anomalous behavior, two administrators recognize the virus. First, they implement the virus response plan by taking the infected machine off the network, cleaning the machine, and restoring it to operation. They then write a report and notify management about the incident. The elapsed time from recognition to report takes one hour.
The same two administrators recognize the virus. They notify management that there's a virus loose on the network, request authority to shut down the infected systems, brief a nontechnical manager about the virus and its effects, and justify the necessary interruption to business services to stop the outbreak. Finally, they remove multiple machines from the network, clean the machines, and restore the affected files and operating systems. They then write their report and brief management (perhaps multiple times during the operation). The elapsed time from recognition to report takes four hours -- if not more.
It should be obvious which of these scenarios is more efficient and better serves the business. However, the second scenario will be all too familiar to some of you. If so, you need to initiate a test.
Test the plan
Testing a security response plan is easy. The person who has decision-making authority for the systems involved in the test is the one responsible for initiating the test. Using the same virus example, you would follow these steps:
- Select a viral threat that poses the greatest risk to your network, and pick a target machine (critical or non-critical).
- Inform the security administrator that the virus is loose on that machine, and ask him or her to implement the security response plan.
- Sit back with the current security response plan, and see if the action follows the plan.
After the test has concluded with the required report, it's time to perform an after action review. The after action review should focus on the tasks accomplished according to the current plan as well as obstacles that prevented or delayed the execution of the plan. Here are the questions this review needs to answer:
- Was the plan readily available to the people involved in the test?
- Were all the necessary items available and accessible (e.g., software, licenses, people, permissions, contact information, machine information)?
- Could the least experienced person follow and implement the plan?
- What deviations from the plan occurred and why?
Once you've answered these questions, rewrite your security response plan and make any necessary modifications.
Security response plans are no different than any other crisis management plans you have for your network. A plan isn't a plan until it has survived an actual test. Test your security response plan now before an actual incident "tests" it for you.
Miss a column?
Check out the Security Solutions Archive, and catch up on the most recent editions of Mike Mullins' column.
Worried about security issues? Who isn't? Automatically sign up for our free Security Solutions newsletter, delivered each Friday, and get hands-on advice for locking down your systems.
Mike Mullins has served as an assistant network administrator and a network security administrator for the U.S. Secret Service and the Defense Information Systems Agency. He is currently the director of operations for the Southern Theater Network Operations and Security Center.