Learning Center
Plans & pricing Sign in
Sign Out



Misc security dump

More Info
									Intrusion Detection in the Age of Compliance

Dr. Anton Chuvakin


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.

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
      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.‖

This is an updated author bio, added to the paper at the time of reposting in
Dr. Anton Chuvakin ( is a recognized security expert in the
field of log management and PCI DSS compliance. Anton leads his security
consulting practice, focusing on logging,
SIEM, security strategy and compliance for security vendors and Fortune 500
He is an author of books "Security Warrior" and "PCI Compliance"
( 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 His blog is one of the most popular in the
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.

To top