Intrusion Detection in the Age of Compliance Dr. Anton Chuvakin WRITTEN: 2004 DISCLAIMER: 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. While intrusion detection technologies are clearly not a ―hot new thing‖ anymore, they are still a subject of an active industry debate. Since the infamous ―IDS is Dead‖ piece was published by Gartner in 2003, the discussion about IDS relevance on today’s world of commercial malware and web exploits rages on. Further, IDS relationship to newer technologies such as intrusion prevention systems (IPS) and network-behavior anomaly detection (NBA) systems is also commonly discussed in the security community. At the same time, everybody who is even slightly involved with security knows that prevention technologies will fail at one point and having an additional layer to detect the consequences of a breach is needed (note that detection will also fail at some point, leading us into incident response – subject of my previous article). Similarly, few question the need for comprehensive network monitoring aimed at increasing control over what should be ―your network,‖ but is sometimes ―owned‖ by the attackers as well. A good conclusion to this debate is that no matter what technologies become fashionable, you still need to detect intrusions. Whether you choose to implement an intrusion detection technology is less important than having a process to enable you to know what is going on and to detect intrusions. Thus, enlightened companies will consider even their end users to be a ―kind of IDS‖ since users will sometimes serve as indicators of suspicious behavior. On the opposite end of the spectrum are those less enlightened companies who will chose to go with ―CNN is our IDS‖ and will only learn that their network was compromised when it shows up in the media … Also, it is interesting to note that intrusion detection technologies are actually mandated by a few regulations. Organizations under such mandates should look at deploying such technologies with no regards to any industry debate. In my last two articles (links), I described the way in which FISMA, HIPAA, and PCI-DSS affect incident response procedures and log management processes. It should come as no surprise, then, that these same regulations mandate intrusion detection capabilities. To demonstrate the complexity of intrusion detection and prevention and the need for a multi-faceted approach to the issue, note the common themes that run through these regulations—that intrusion detection mechanisms not only be in place, but that these systems also must be kept up to date and monitored for signals and alerts. (FISMA) NIST SP 800-53 lists a variety of security controls (including intrusion detection controls) that need to be in place to protect a Federal information system. ―Intrusion detection controls‖ simply means that tools and techniques be used to monitor for and detect unauthorized information system activity and/or attacks, without specifying any specific method of doing so. More specifically, 800-53 calls for an organization to: Network individual intrusion detection tools into a systemwide intrusion detection system using common protocols Employ automated tools to support near-real-time analysis of events in support of detecting system-level attacks. Employ automated tools to integrate intrusion detection tools into access control and follow control mechanisms for the rapid response to attacks by enabling reconfiguration of these mechanisms in support of attack isolation and elimination. Once these tools are in place, they (and all security controls) must be monitored continuously for unusual, unauthorized, or illegal activities. In addition to observing outbound communications (that might point to the presence of malicious code, spyware, adware, etc.), monitoring activities include ongoing assessment of security controls, status reporting, configuration management and control of information system components, and security impact analyses of system changes. Thus, one can deploy a wide range of technologies (IDS, IPS, NBA or others) to accommodate this requirement. The Health Insurance Portability and Accountability Act of 1996 (HIPAA) HIPAA requires that organizations detect and prevent reasonably foreseeable threats from malicious or criminal acts, system failures, and/or employee errors (among other sources). NIST SP 800-66 outlines the way in which intrusion detection functionality (an implied ―technical safeguard‖) can protect against these threats. Appendix A of 800-66 provides a list of intrusion- detection-related questions that should be used to assess their intrusion detection policy: Are intrusion detection tools installed on the system? Are the intrusion detection reports routinely reviewed and suspected incidents handled accordingly? Is system performance monitoring used to analyze system performance logs in real time to look for availability problems, including active attacks? (This also ties into log collection and review, another key issue, covered in the previous article in the series) Thus, the above implies that some kind of intrusion detection tool needs to be in use as per HIPAA, but again, no specific technology is recommended. The Payment Card Industry Data Security Standard (PCI-DSS) Requirement 11 of PCI-DSS (―Regularly Test Security Systems and Processes‖), mandates, in section 11.4, that an organization use and maintain network intrusion detection systems, host- based intrusion detection systems, and intrusion prevention systems in order to monitor network traffic and alert employees to potential breaches. It doesn’t get much more clearly delineated than that. Further, Requirement 12 (―Maintain a Policy that Addresses Information Security for Employees and Contractors‖) mandates, in section 12.9.5, that incident response plans include alerts from intrusion detection and intrusion prevention systems (as well as file integrity monitoring systems). This implies the importance of monitoring the intrusion-related security systems, which is also called for in Requirement 10’s (―Track and Monitor All Access to Network Resources and Cardholder Data‖) section 10.6 mandate to review at least daily logs for all system components (including those that perform intrusion detection functions). In the case of PCI, the level of useful details is certainly higher; PCI DSS is pretty unambiguous that host and network IDS and IPS needs to be deployed and updated to satisfy the requirements and that their logs needs to be monitored and reviewed. The aforementioned regulations imply that an organization needs to ―do intrusion detection,‖ but the amount of detail is usually not sufficient to make a technology choice. Still, the common theme is the need to deploy some technology for intrusion detection, keep it updated and monitor the logs that it produces. They also highlight that while technology fashions and regulations change, the need to maintain awareness of your environment and detect intrusions never ―goes out of style.‖ 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.
Pages to are hidden for
"paper=ID-age-compliance_D3"Please download to view full document