The document discusses 5 common mistakes organizations make when deploying intrusion detection systems (IDS). 1. Not ensuring the IDS can see all network traffic by improperly planning its infrastructure placement. 2. Deploying an IDS but not reviewing the alerts it generates, diminishing its value as a detection system. 3. Deploying an IDS that generates alerts but having no response policy or understanding of normal vs anomalous activity. 4. Being overwhelmed by a high volume of alerts without properly tuning the IDS to the environment. 5. Not accepting the inherent limitations of signature-based IDS to detect new exploits without updated signatures.

1. Five IDS mistakes people make Anton Chuvakin, Ph.D., GCIA, GCIH WRITTEN: 2003 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. The article covers the typical mistakes organizations make while deploying an IDS. The network intrusion detection systems are in the process of becoming a standard information security safeguard. Together with firewalls and vulnerability scanners, intrusion detection is one of the pillars of modern computer security. While the IDS field is still in motion, several classes of products have formed. Most IDS products loosely fall into network IDS (NIDS) and host IDS (HIDS). Network IDS usually monitors the entire subnet for network attacks against machines connected to it, using a database of attack signatures or a set of algorithms to detect anomalies in network traffic (or both). Alerting and attacks analysis might be handled by a different machine that collects the information from several sensors, possibly correlating IDS alers with other data. It appears that stateful and protocol-aware signature-based network IDS is still the most widely deployed type of intrusion detection. Simplified management and the availability of inexpensive NIDS appliances together with dominance of network-based attacks are believed to be the primary reasons for that. In this brief article we will review several importnat mistakes companies make while planning and deploying the IDS systems. In addition to the obvious mistake (0th, I guess :-)) of not evaluating and deploying the IDS technolgy at all, the issues we cover often decrease or even eliminate the added value the companies might otherwise derive from running an intrusion detection systems. 1. Since we already covered the trivial case of
not using an IDS
, the first mistake we discuss is using it without giving it an ability to see all the network traffic. In other words, deploying the network IDS without sufficient infrastructure planning. Network IDS might be deployed on the network choke point (such as right inside or outside the firewall), on the appropriate internal network segment or in the DMZ to see important traffic. For the shared Ethernet-based networks IDS will see all the network traffic within the Ethernet collision domain or subnet and also destined to and from the subnet, but no more. For the switched networks, there are several IDS deployment scenarios which utilize special switch capabilities such as port mirroring or spanning. Additionally, one might procure an IDS integrated with a switch, such as Cisco IDS blade. 2. The second mistake occurs when the IDS is deployed appropriately, but nobody is looking at the alerts it generates. This one is actually much more common than it seems. It is well-known that IDS is a
detection
technology, and it never promised to be a
shoot-and-forget
means of thwarting attacks. While in some cases, the organization might get away with dropping the firewall in place and configuring the policy, such deployment scenario never works for the intrusion detection. If IDS alerts are reviewed only after a successful compromise, the system turns into an overpriced incident response helper tool - clearly not what the technology designers had in mind. It still helps, but isn't it better to learn about the attack from the IDS rather then from angry customers? Being the form of monitoring and network audit technology, IDS still (and likley always will, unless its intelligence improves by orders of magnitude) requires a skilled personnel to run. 3. Network IDS is deployed,
sees
all the traffic and there is a moderately intelligent somebody reviewing the alert stream. No more mistakes? Far from it! What is a response policy for each event type? Does the person viewing the alerts know what is the best course of action needed for each event (if any)? How to tell normal events from anomalous and malicious? What events are typically
false positives
(alerts being triggered on benign activity) and
false alarms
(alerts being triggered on attacks that cannot harm the target systems) in the protected environment? How to gather the required context information to answer the above? Unless the above questions are answered in advance by means of a response process, it is likely that no intelligent action is being taken based on IDS alerts - a big mistake by itself. 4. All the previous pitfalls are avoided and the NIDS is humming along nicely. However, the staff monitoring the IDS starts to get flooded with alerts. They know what to do for each alert, but how quickly they can take action after receiving the 10,000th alert on a given day? Unfortunately, current network IDS systems have to be tuned for the environment. While the detailed guide for IDS tuning is beyond the scope of this article, two general approaches are commonly used. One approach is to enable all possible IDS rules and spend several days flooded with alerts, analyzing them and reducing the rule set accordingly. This route is more appropriate for internal network IDS deployment. Another solution is to reduce the ruleset to only watch the
risky
services. This works better in a highly secure DMZ setup where all machines are carefully audited and hardened. 5. The last mistake is simply not accepting the inherent limitations of network IDS technology. While anomaly-based IDS systems might potentially detect an unknown attack, most signature based IDS will miss a new exploit if there is no rule written for it. IDS systems have to be frequently updated with vendor signature updates. Even if updates are applied on a timely schedule, the exploits which are unknown to the IDS vendor will likely not be caught by the signature-based system. Attackers may also try to blind or evade the NIDS using many tools available for download as well as, undoubtefully, a large collection of non-public tools. There is a constant battle between the IDS developers and those wishing to escape detection. IDS are becoming more sophisticated and able to see through the old evasion methods, but new approaches are created by attackers. Those deploying the network IDS technology should be aware of its limitations and practice
defense-in -depth
by deploying multiple and diverse security solutions. ABOUT THE AUTHOR: This is an updated author bio, added to the paper at the time of reposting in 2009. Dr. Anton Chuvakin (http://www.chuvakin.org) is a recognized security expert in the field of log management and PCI DSS compliance. He is an author of books
Security Warrior
and
PCI Compliance
and a contributor to
Know Your Enemy II
,
Information Security Management Handbook
and others. Anton has published dozens of papers on log management, correlation, data analysis, PCI DSS, security management (see list www.info-secure.org) . His blog http://www.securitywarrior.org is one of the most popular in the industry. In addition, Anton teaches classes 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 the advisory boards of several security start-ups. Currently, Anton is developing his security consulting practice, focusing on logging and PCI DSS compliance for security vendors and Fortune 500 organizations. 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.