Incident response plans help minimize business risks, and they're mandatory in today's computing environments. However, incident response is often ignored at many enterprises because they think that it doesn't serve any significant purpose. Rather, their main focus is on recovering from disasters and keeping critical business systems and processes running during a disaster. And even though hack attacks and malicious internal use are forms of disaster in a company, they still end up as an afterthought.
Even with the general lack of incident response adoption, no one can say it's not a visible component of information risk management. Many government and industry regulations have sections and requirements on incident response: HIPAA (section 164.308(6)(i)), GLBA (section 314.4(b)(3)) and PCI DSS (section 12.9). Even the widely accepted ISO/IEC 27002:2005 information security framework has a section dedicated to the subject titled "Information Security Incident Management."
A good incident response plan will outline the who, what, when, where and how to respond to data security breaches. Just like disaster recovery/business continuity plans, incident response procedures provide invaluable guidance when you really need it: in the midst of, or just after a data security breach. Arguably the most important aspect of incident response documentation is the process for determining what constitutes an "incident." It may be an external hack attempt or perhaps a type of insider abuse. Incidents may be technical in nature such as a denial of service attack or a Web application hack, or they can be higher level phishing or social engineering attempts. It's up to you and your IT/security/governance committee to decide what types of data security breaches should fall under the incident response umbrella.
An incident response plan would ideally exist as a standalone document. However, you may want to incorporate it into other contingency procedures you may already have such as your business continuity plan. Regardless, you need to document it and place it wherever it's most easily retrievable. The NIST Computer Security Incident Handling Guide has some great information on creating and formatting incident response procedures.
Also, keep in mind that timing is critical during a data security breach. Within seconds, critical information can be lost, and you need to be ready to respond. So ask yourself, "How long will it take me to respond to a data security breach? Seconds? Minutes?" A great way to see where things stand in your organization is to run test drills such as simulated hack attacks, malware outbreaks and lost mobile devices. You may realize that even though you have a disaster recovery/business continuity plan, your incident response plan may need more work.
Data security incidents can have just as grave an impact on your business as a physical disaster. Incorporating incident response into your DR/BC plan is important to keep you away from disasters and incidents that may harm your company. Anything less is akin to ignoring the realities of today's threats and hoping for the best.
About the author: Kevin Beaver is an information security consultant, expert witness, as well as a seminar leader and keynote speaker with Atlanta-based Principle Logic, LLC. With over 20 years of experience in the industry, Kevin specializes in performing independent security assessments for businesses who take security seriously and incident response for those who don't. He has authored/co-authored seven books on information security including "The Practical Guide to HIPAA Privacy and Security Compliance" and the newly-updated "Hacking For Dummies, 3rd edition." In addition, he's the creator of the Security On Wheels information security audio books and blog providing security learning for IT professionals on the go. Kevin can be reached at www.principlelogic.com.
This was first published in January 2010