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