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
Requires Free Membership to View
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.
- 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 editor@searchcompliance.com. Follow @ITCompliance for compliance news throughout the week.
This was first published in January 2010
Join the conversationComment
Share
Comments
Results
Contribute to the conversation