Taking our breach response plan for a test-drive
Recognizing that a breach could very well lie in our future isn't the same thing as surrendering. When something is nearly inevitable, you should prepare for it. That's the philosophy behind disaster recovery, and I think it should apply to data security as well. So, just as we do testing for disaster recovery, why not do a trial run of our breach response
But I saw no point in testing the incident response plan that was in place when I joined the company. Covering less than a page and lacking even basic substance, it was completely inadequate; I really don't know why the auditors gave it the green light. I would have to write a new one.
Although the old incident response plan was worthless, there was no need to start from scratch. I decided to base my policy on the National Institute of Standards and Technology's guide for incident handling. In part, this is because the NIST process is sensible and straightforward, but it's also because it makes sense to use an industry-standard template for something like this. Auditors (and customers who might request to see your security policy) appreciate when those documents seem familiar. A Google search for incident response documents told me that a lot of policies look like the NIST incident handling guide. No need to reinvent the wheel.
I focused on the core areas. The preparation stage includes maintaining a current list of team members, their expertise and their responsibilities during a breach. I secured and documented the location of a conference room that would serve as the "War Room" in the event of a breach. I obtained a dedicated conference bridge line and obtained the current contact numbers for all team members. I identified the tools that would commonly be used during incident triage, such as packet sniffers, malware scanners and forensic tools. I obtained a contact list of local and federal law enforcement agencies. I also met with customer support to ensure that we have a list of current customer contacts and that we have proper notification templates on the ready in the event we have to contact customers.
The most important aspect of the next phase, detection and analysis, includes a comprehensive list of tools and methods that are used to detect a breach and what is required to be collected (the who, what, when, why and how), and clear criteria as to the various severity levels of a breach, how to prioritize and whom should be notified.
The next phase, containment, hinges on making quick decisions. For example, if a public-facing, revenue-generating website is under attack, or has been otherwise compromised, a decision may have to be made to take a machine off the network, thereby impacting revenue. I'm planning on listing some of the common types of attacks and listing the criteria and proper response. Once an incident is contained, the next step is to eradicate any malware or other foreign activity from the environment. This may be a simple as running anti-malware, re-imaging systems or utilizing advanced forensics tools to identify and remove malware and any other foreign objects. Of course, depending on the nature of the incident a mirror image of the system may need to be made for future evidence.
Once the environment has been cleared, the next step is business resumption or recovery, which may include restoring backups and removing firewall rules that may have been put in place during the containment phase. And finally, once the incident is complete, it's important to get everyone in a room for a post-incident analysis to determine what activities went well and where there is room for improvement.
Once the incident response process document is complete, I will review the document with appropriate representatives from IT, system operations, marketing, public relations, customer support and the executive staff and ensure that they all understand their roles in the event of a major breach -- at my company, one that would involve an exfiltration of customers' sensitive data to the point that makes the news, affects shareholders or requires customer notification and remediation.
Then comes the test. I'll devise various scenarios for a tabletop exercise with the incident response team and see just how well they respond.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.
Click here for more security articles.