Incident Management in the Age of Compliance Dr.
Anton Chuvakin WRITTEN: 2007
Security is a rapidly changing field of human endeavor. Threats we face literally change every day; moreover, many security professionals consider the rate of change to be accelerating. On top of that, to be able to stay in touch with such ever-changing reality, one has to evolve with the space as well. Thus, even though I hope that this document will be useful for to my readers, please keep in mind that is was possibly written years ago. Also, keep in mind that some of the URL might have gone 404, please Google around.
This paper covers how recent regulatory mandates affect security incident response (IR). Security incidents are known to wreak catastrophic results upon organizations and may involve hacking, malware outbreaks, economic espionage, intellectual property theft or loss, network access abuse, theft of IT resources and many other issues. Recent regulatory mandates directly affect how organizations should deal with such occurrences. The well-known security maxim, “prevention-detection-response” covers three components, crucially important for an organization’s security posture. “Prevention” seems favored by many as “the main” component with “detection” following close behind. However, “response” has something unique about it: 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 present, since organizations are forced into response mode by attackers. 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 loss to an organization. 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 setup and execute their security incident response (as I discussed in my April 2005 “ComputerWorld” paper “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 (LINK), easy to follow, and most importantly, work in the high-stress post-incident environments for which they were designed.
However, some recent regulations have explicitly highlighted the importance of having a repeatable incident response plan to guarantee security of key data and even mandated 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 FISMA, PCI DSS, and HIPAA. Let’s review how these regulations affect incident response. FISMA The Federal Information Security Management Act (FISMA), 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 (NIST). These guidelines include 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, external security audits. NIST 80061, (also known as the "Computer Security Incident Handling Guide,") describes detailed technical, procedural and policy guidelines for Federal agencies to put into practice a comprehensive incident response and computer forensics faculties, including procedures for detecting, reporting, and responding to security incidents. Thus, organizations subject to FISMA should focus more on studying the detailed FISMA incident guidance and on carefully documenting the incident. PCI DSS Payment Card Industry Data Security Standards (PCI DSS) take a slightly different approach to incident response than FISMA, since these regulations strive to protect different types of data. PCI DSS requires that companies maintain a clear and comprehensive Information Security Policy that addresses security incident response. It also offers a framework that addresses questions such as: • • • 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 data security PCI standards strive to offer, these regulations also mandate that an organization be prepared to respond immediately to a system breach based on a previously developed incident response plan that addresses business recovery and continuity procedures, data backup processes, and communication and contact strategies (e.g. to 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. Thurs, organizations subject to PCI DSS should not only have a documented response plan but also must dedicate people to specific incident-related tasks HIPAA The Health Insurance Portability and Accountability Act (HIPAA), which strives to protect patient information, requires that an organization clearly determine the goals of incident response, including 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 information system). Like PCI DSS, HIPAA requires the creation of an IR team or another reasonable and appropriate response and reporting mechanism. Thus, among other things, organizations subject to HIPAA should have both an IR plan and an IR team as well as a method to classify security incidents. Setting up a proper IR plan 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 non-technical resources, bound by the incident response policy. Such policy should be continuously refined and improved and, as we covered in this paper, be based on the regulations with which they must comply. Depending on the industry and the regulation to which an organization 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. As this is the first in a series of articles, look for the next installment, where I will discuss log management in the age of compliance.
ABOUT THE AUTHOR:
This is an updated author bio, added to the paper at the time of reposting in 2011. Dr. Anton Chuvakin (www.chuvakin.org) is a recognized security expert in the field of log management and PCI DSS compliance. Anton leads his security consulting practice www.securitywarriorconsulting.com, focusing on logging, SIEM, security strategy and compliance for security vendors and Fortune 500 organizations. He is an author of books "Security Warrior" and "PCI Compliance" (www.pcicompliancebook.info) and a contributor to "Know Your Enemy II", "Information Security Management Handbook"; and now working on a book about system logs. Anton has published dozens of papers on log management, correlation, data analysis, PCI DSS, security management (see list www.info-
secure.org). His blog www.securitywarrior.org is one of the most popular in the industry. In addition, Anton teaches classes (including his own SANS class on log management) and presents at many security conferences across the world; he recently addressed audiences in United States, UK, Singapore, Spain, Russia and other countries. He works on emerging security standards and serves on advisory boards of several security start-ups. Dr. Anton Chuvakin was formerly a Director of PCI Compliance Solutions at Qualys. Previously, Anton worked at LogLogic as a Chief Logging Evangelist, tasked with educating the world about the importance of logging for security, compliance and operations. Before LogLogic, Anton was employed by a security vendor in a strategic product management role. Anton earned his Ph.D. degree from Stony Brook University.