Incident management in the age of compliance

The basics of doing what the laws tell you to do

Security incidents can wreak catastrophic results on organizations. Such incidents may involve hacking, malware outbreaks, economic espionage, intellectual property theft or loss, network access abuse, theft of IT resources, and many more problems.  Recent regulatory mandates directly affect how organizations should deal with such occurrences.

The well-known security maxim "prevention-detection-response" covers three components, all crucially important for an organization’s security posture.  "Prevention" seems favored by many as the primary component with "detection" following close behind.  However, "response" has a unique characteristic lacking in the other two components: It is impossible to avoid.  While it is not uncommon for an organization to have weak prevention and nearly nonexistent detection capabilities, response will always be necessary, since organizations are forced into response mode when they are attacked.

In light of this, being prepared for incidents via an incident response plan is likely to be one of the most cost-effective security measures an organization takes.  Timely and effective incident response is directly responsible for decreasing the incident-induced losses.  It can also help to prevent expensive and hard-to-repair reputation damage, which often occurs following a publicly disclosed security incident.

Incident response is fraught with many possible pitfalls, and organizations are known to commit glaring mistakes while trying to set up and execute their security incident response (IR), as I discussed in an April 2005 Computerworld article on the five mistakes of incident response.  The SANS Institute, which offers research and information security training and certification, has put forth a basic methodology to help give structure to the otherwise chaotic incident response workflow.  The six steps of the SANS methodology are clearly defined, easy to follow, and most important, work in the high-stress post-incident environments for which they were designed. More broadly, Mary K. Pratt has a discussion of basic areas of concern to address when putting a response plan together.

However, some recent government regulations and standards put forth by industry groups have explicitly highlighted the importance of having a repeatable incident response plan to guarantee security of key data; they even mandate specific details on how incident response should be performed.  Thus, some aspects of IR planning and procedures have, as a direct result of these regulations, moved from the "should" category to the "must" category.  Examples of such laws and standards include the Federal Information Security Management Act, the Payment Card Industry Data Security Standard, and Health Insurance Portability and Accountability Act (HIPAA).  Let’s review how these mandates affect incident response.


The Federal Information Security Management Act, which was created to strengthen government computer and network security, requires federal agencies to set up incident response capabilities in keeping with the guidelines put forth by the National Institute of Standards and Technology. 

These guidelines include the establishment of a protected central repository, preferably online, for all certification and accreditation documentation, acquisition-related information, risk and vulnerability assessments, compliance surveys, security incident reporting and remediation results, and external security audits.  NIST 800-61 (also known as the "Computer Security Incident Handling Guide") describes detailed technical, procedural and policy guidelines for federal agencies working to put into practice comprehensive incident response and computer forensics capabilities, including procedures for detecting, reporting and responding to security incidents.

Thus, organizations subject to FISMA should focus on studying the detailed FISMA incident guidance and on carefully documenting incidents.


The Payment Card Industry Data Security Standard takes a slightly different approach to incident response than FISMA does, since it strives to protect different types of data.  PCI DSS requires companies to maintain a clear and comprehensive information security policy that addresses security incident response.   It also offers a framework that addresses questions such as these:

  • Is a security incident response plan formally documented and disseminated to the appropriate responsible parties?
  • Are security incidents reported to the person responsible for security investigation?
  • Is there an incident response team ready to be deployed in case of a cardholder data compromise?

PCI DSS also requires that an individual or team be assigned these information security management responsibilities and distribute security incident response and escalation procedures.  In keeping with the type of security PCI standards strive to offer, these mandates also require organizations to be prepared to respond immediately to a breach by following a previously developed incident response plan that addresses business recovery and continuity procedures, data backup processes, and communication and contact strategies (which, for example, would address communication with credit card associations). 

According to PCI DSS, the plan must be tested at least annually, and thoroughly trained personnel must be available around the clock to respond to intrusion-detection and intrusion-prevention alerts.

Thus, organizations subject to PCI DSS should not only set up a documented response plan but also dedicate people to specific incident-related tasks


The Health Insurance Portability and Accountability Act, which strives to protect individuals' medical records, requires organizations to clearly determine the goals of incident response -- a process that should include a strong understanding of what constitutes a security incident (defined as attempted or successful unauthorized access, use, disclosure, modification or destruction of information and/or interference with system operations in an IT system).  Like PCI DSS, HIPAA requires the creation of a security incident response team or another reasonable and appropriate response and reporting mechanism.

Thus, among other things, organizations subject to HIPAA should have both an incident response plan and an IR team, as well as a method to classify security incidents.

Setting up a proper IR plan as mandated by the aforementioned regulations requires knowledge of your environment and implemented security measures as well as incident response skills.  Effective incident response fuses together technical and nontechnical resources, bound by the incident response policy. 

Such policy should be continually refined and improved and, as stated earlier, be based on the regulations with which an organization must comply.  Depending on the industry an organization is in and the regulations to which it is subjected, there will be different paths to take to achieve the level of incident response required.

In this article, I have outlined the basics of incident response and related them to three major regulations that directly affect the specifics of setting up incident response capabilities. This is the first in a series of articles. In the next installment, I will discuss log management in the age of compliance.

Anton Chuvakin (GCIA, GCIH, GCFA) is a recognized security expert and book author.  His current role is director of product management at LogLogic, a log management and intelligence company. He is an author of Security Warrior and a contributor to Know Your Enemy II, Information Security Management Handbook, Hacker's Challenge 3 and an upcoming book on PCI.

Copyright © 2007 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon