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 alerts 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 important 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 technology 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 likely 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 rule set 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, no doubt, 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.

Anton Chuvakin, Ph.D., GCIA, GCIH (http://www.chuvakin.org) is a Senior Security Analyst with a major information security company. His areas of infosec expertise include intrusion detection, UNIX security, forensics, honeypots, etc. In his spare time he maintains his security portal http://www.info-secure.org