- Fred Avolio
Like most security-conscious IT professionals, you've probably looked into using an intrusion detection system (IDS). Maybe you actually deployed an IDS and experienced what most first-time users get: a boatload of false positives. Now, like many others disappointed by their excursion into intrusion detection land, you're disappointed and ready to toss it out the window.
OK, so you can't get what you want: a never-sleeping, all-knowing guard for your systems and networks. You can't get a monitor that tells you of a suspected intruder's intent, or one that takes into account all possible attack scenarios, especially those nobody's thought of yet. Lots of people blame the vendors for this, but maybe all it means is that we've come to expect too much from today's IDSes. Maybe all that's needed is some adjusted expectations and a bit more planning.
To illustrate this point, here's an analogy from the physical security world. Building managers use motion detectors to prevent unauthorized entry. These detectors work great when the building is supposed to be empty, producing few if any false positives. But when deployed during the day, motion detectors are useless, producing tons of false positives. The point is that building managers don't expect them to work well during the day.
In the same way, it's possible to set up and use both a network-based IDS (NIDS) and a host-based IDS (HIDS) to limit false positives while still gaining a measurable security benefit.
Some IDSes actually detect intrusions -- after the bad guy is inside. Others detect attacks (these are called attack detection systems, or ADSes). Some systems do both. If you're putting an IDS on the outside of your network, you should be most interested in ADS functionality. But, to prevent being buried in false alarms, you'll want to tighten up what you look for (and at). Configure the NIDS with the IP addresses you care about -- your gateways, Internet-facing servers and internal networks, for example. If you can't configure a NIDS in this fashion, it may not be much use to you.
Don't enable every sensor in your NIDS. In fact, just turn on a few of the obvious ones. Turn on additional sensors for any new attacks when you hear about them. You don't want to sound an alarm every time an errant packet brushes past your sensors. Nor do you want a klaxon to sound at every ping or attempted Telnet connection.
Doesn't that mean you might miss an attack attempt? Perhaps. The alternative is getting buried in data or alert conditions that require action. For most of us, it's good enough to know that someone is trying to jimmy the lock on the network door.
Security 101 dictates that the ideal default firewall installation starts with no services permitted; required services are added one at a time. The ideal NIDS installation sounds similar, but is logically opposite: Start by enabling as few sensors as possible. Then selectively add them until you get too many false positives.
The philosophy for host-based IDSes is similar. Set up a HIDS like a selective burglar alarm. First, harden your servers by disabling all unused services and keeping patches up to date. Then, to meet the goal of "security usefulness" without "data overload," deploy HIDS on critical servers devoid of interactive users. (This should describe all sensitive servers on your network, by the way.) This makes the task of defining what "should never happen" much easier.
For example, you can configure a HIDS to tell you when critical files have been modified, when logs files get smaller instead of larger, or when the process table grows larger than normal (or at too fast a rate). You'll fine-tune it over the course of a few days to fit your configuration. For instance, some files are supposed to change daily, while others should never change without your knowledge. Once it's set up properly for a particular host, you should get very few false alarms.
Getting What You Need
To get the highest benefit from an IDS without all the heartburn, you must have reasonable expectations. IDSes are very good motion detectors, but they're not so good at data reduction and analysis. Know what your IDS's limitations are. Plan where you'll deploy it. And lastly, be very selective in what you look for, concentrating on specific known bad things that should never happen. With this approach, you just might find you get both what you want and what you need.
About the author: Fred Avolio is president and founder of Avolio Consulting, a Maryland-based computer and network security consulting firm.