Taking our breach response plan for a test-drive

[Audrey McNeil <audrey () riskbasedsecurity com>]

http://www.computerworld.com/article/2921238/security0/taking-our-breach-response-plan-for-a-test-drive.html

One thing that we security managers can be sure of is this: There is no
guarantee that our company will not suffer a security breach. In fact, the
odds are increasing all the time, helped along by the proliferation of
mobile devices, companies’ heavy use of software as a service and the
consumerization of IT. And let’s face it: Creating a culture that fosters
innovation and attracts talent exacts a cost in defensibility.

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.

_______________________________________________
Dataloss Mailing List (dataloss () datalossdb org)
Archived at http://seclists.org/dataloss/
Unsubscribe at http://lists.osvdb.org/mailman/listinfo/dataloss
For inquiries regarding use or licensing of data, e-mail
        sales () riskbasedsecurity com 

Supporters:

Risk Based Security (http://www.riskbasedsecurity.com/)
YourCISO is an affordable SaaS solution that provides a comprehensive information security program that ensures focus 
on the right security.  If you need security help or want to provide real risk reduction for your clients contact us!