Network intrusion detection systems are becoming a required information security safeguard. Together with firewalls and vulnerability scanners , IDSs can form one of the pillars of modern computer security. In this section, we examine five mistakes organizations commonly make while planning and deploying their IDSs. In addition to the obvious mistake of not evaluating the IDS technology at all, these mistakes 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 the category of network IDSs. A 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 attack analysis are handled by a different machine that collects the information from several sensors.
Signature-based network IDSs are the most widely deployed type of intrusion detection system. 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.
Now let's take a look at the top five IDS mistakes and what can be done to avoid them.
The IDS cannot see all the network traffic. The problem here is deploying the network IDS without sufficient infrastructure planning. A 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. On shared Ethernet-based networks, the IDS should see all network traffic within the Ethernet collision domain or subnet and traffic destined to and from the subnet, but no more. For switched networks, there are several IDS deployment scenarios that use special switch capabilities, such as port mirroring or spanning .
The IDS is deployed appropriately, but nobody looks at the alerts it generates. It's well known that the 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.
There is no IDS 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 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.
The IDS isn't tuned to its environment. All the previous pitfalls have been avoided, and your 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 ten-thousandth alert on a given day? Current network IDSs have to be tuned for the environment. While a detailed guide for IDS tuning is beyond the scope of this chapter, 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 ruleset 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 .
The inherent limitations of network IDS technology aren't recognized. While anomaly-based IDSs might detect an unknown attack, most signature-based IDSs miss a new exploit if there is no rule written for it. IDSs 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. IDSs are becoming more sophisticated and are able to see through old evasion methods , but attackers are constantly developing new approaches. Those deploying network IDS technology should be aware of its limitations and practice "defense- in-depth " by deploying multiple and diverse security solutions.
IDS technology matures every day, and new advances (including for Snort) are coming soon. Hybrid IDSs combining anomaly and signature coverage appear to be poised for market dominance, at least for the near future. To help improve the state of the art, we also encourage researchers to develop Bayesian deployment schemes and graphical displays of data, as we have described in this chapter.