5 IDS mistakes that companies make

Network intrusion-detection systems (IDS) are becoming a standard information security safeguard. Together with firewalls and vulnerability scanners, intrusion detection is one of the pillars of modern computer security.

In this article, I'll examine five mistakes that companies commonly make while planning and deploying their IDS systems. In addition to the obvious mistake of not evaluating the IDS technology at all, these mistakes will decrease or eliminate the added value that companies would derive from running an IDS.

While the IDS field is still in motion, several classes of products have formed. Most IDS products loosely fall into network IDS. Network IDS 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. Alerts and attacks analysis would be handled by a different machine that collects the information from several sensors.

1pixclear.gif
Anton Chuvakin
1pixclear.gif
Signature-based network IDS is the most widely deployed type of intrusion detection. Simplified management and the availability of inexpensive network IDS appliances, together with the dominance of network-based attacks, are believed to be the primary reasons for that.

Now let's take a look at the top five mistakes and what can be done to avoid them.

1. Using an IDS without giving it an ability to see all the network traffic. In other words, deploying the network IDS without sufficient infrastructure planning. Network IDS should 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. 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 that use special switch capabilities such as port mirroring or spanning.

2. The IDS is deployed appropriately, but nobody is looking at the alerts it generates. It's 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 a deployment scenario never works for 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.

3. No response policy. The network IDS is deployed, it "sees" all the traffic, and there is somebody reviewing the alert stream. But what is the response for each event type? Does the person viewing the alerts know the best course of action needed for each event? How do you tell normal events from anomalous and malicious events? 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? Unless these questions are answered, it is likely that no intelligent action is being taken based on IDS alerts -- a big mistake by itself.

4. The IDS isn't tuned to its environment. All the previous pitfalls are avoided, and the network IDS 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 can they take action after receiving the 10,000th alert on a given day? 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:

  • The first approach is to enable all possible IDS rules and to 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. Not accepting the inherent limitations of network IDS technology. While anomaly-based IDS systems might detect an unknown attack, most signature-based IDS will miss a new exploit if there is no rule written for it. IDS systems must frequently receive vendor signature updates. Even if updates are applied on a schedule, exploits that are unknown to the IDS vendor will probably not be caught by the signature-based system. Attackers may also try to blind or evade the network IDS by using many tools available for download. There is a constant battle between the IDS developers and those who want to escape detection. IDS is becoming more sophisticated and able to see through the old evasion methods, but new approaches are constantly being developed 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.

Related:

Copyright © 2003 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon