Lack of incident response plan leaves hole in compliance strategy

I'm not a believer that security and compliance are the same thing. Nor is compliance a goal that, once reached, we're clear to move past to get to better things. Nothing I see in my work underscores compliance shortcomings more than the lack of an incident response plan.

Kevin Beaver

The reactive nature of many businesses once a data breach occurs further highlights the fact that many -- if not most -- organizations are simply not prepared to respond to a hack attack, a malware outbreak, insider abuse or related security incident. In fact, a common mode of operation is to ignore the problem, then react.

The Health Insurance Portability and Accountability and Gramm-Leach-Bliley acts both have incident response requirements. So does PCI DSS. Even the HITECH Act and state breach notification laws have reporting components that fall into the realm of incident response.

Even if you're not required to document incident response procedures by law or industry regulation, a business partner or client will undoubtedly eventually ask how you're handling this area. Given this, there are two things you must do:

• Acknowledge that an incident response plan is not only a compliance requirement for most businesses, but also a necessity to manage risks effectively;
• Understand what makes up a reasonable incident response plan.

The former requires you to get management on board and sell security to them -- arguably the hardest part of all this. The latter is as simple as getting started documenting your plan using a template such as the following:

• An overview that states the plan's purpose, scope, and goals.
• An incident preparation plan that outlines the team members and security controls currently in place to assist with incident response.
• An incident response "toolbox" that outlines specific computer and network security/forensics tools you'll use.
• An incident response detection process that outlines what constitutes an incident along with specific detection methods such as antimalware software and audit log alerts, social engineering attempts and network traffic abnormalities.
• An incident investigation and containment process such as securing the network, contacting ISPs and/or hosting providers, taking notes and gathering evidence if you intend to prosecute.
• An incident eradication process that includes malware cleanup, network traffic analysis and running follow-up vulnerability scans.

• More regulatory resources

  HIPAA-covered entities, business associates confront HITECH rules

  HIPAA-covered entities' first step should be a quality assurance plan

  FTC pursuing HIPAA violations as a matter of consumer protection

• An incident recovery process including re-imaging workstations, resetting passwords, tweaking firewall rules and implementing new or improved security controls.
• An incident follow-up plan that can produce reports on lessons learned and areas that need improvement

You can document all of this as a standalone incident response plan document or integrate these steps in your business continuity plan. However you handle it, documenting sound procedures is a must. That will help you prepare for the inevitable and ensure you handle those tough situations with poise and grace. Good for compliance, good for business.

Kevin Beaver is an information security consultant and expert witness, as well as a seminar leader and keynote speaker at Atlanta-based Principle Logic LLC. He can be reached at www.principlelogic.com. Let us know what you think about the story; email [email protected]. Follow @ITCompliance for compliance news throughout the week.