Network Computingwww.networkcomputing.com

Network Computing has followed the IDS revolution over the past several years--and it has been a wild ride. The IDS product space has exploded; there are now more than 12 vendors offering more than 20 products (see "IDS Specifications"). In addition, acquisitions have occurred at a dizzying pace: Symantec Corp. is merging with Axent Technologies; Cabletron/Enterasys Networks acquired Network Security Wizards; ODS Networks spun off Intrusion. com, acquired SecureNet Pro and renamed Computer Misuse Detection System to Kane Security Enterprise. Confused? So were we.

That's why, when IDS once again appeared on our scopes, our partner labs in Chicago embarked on the painful but necessary prep work to relentlessly pound these things into the ground. This time, however, we realized we need to look at more than just packet blasting and acknowledgement thresholds. We are examining more of the management and deployment issues, and are developing better ways to demonstrate them. We also are taking a good look at some of the harder issues, such as management, scalability, false positives, response and shunning mechanisms, and deployment nightmares. And this time, we realized that if we wanted to tell the story--the whole story--there was no way in hell we'd be able to fit it all into a single article. Hence, we'll be reporting the results of our tests in a future issue. Many of the challenges we discuss here, such as deployment problems and hidden costs, will help you grasp what lies ahead. Read, absorb and brace yourself--there is more in the works.

Challenges of Intrusion Detection

Today's intrusion-detection systems fill a number of needs quite well but fall flat on their faces when trying to satisfy many others. If you're considering deploying intrusion-detection technology in your enterprise, you must know where it will help and where it will not. Equally important is understanding the myriad issues and problems surrounding the technology's adoption.

Before diving into those surrounding issues, we should clarify terminology. As much as we wish there were a governing body for IDS lingo, there isn't. Marketing juggernauts are tossing terms such as hybrid and stateful and multitiered around faster than we can route press releases to /dev/null. Worse, it appears intrusion detection itself is now mandated in the parlance of our times, as security-product vendors attempt to inject the phrase into all their literature--regardless of application.

So for clarity's sake, we separate the IDS product space into three models: host based, network based and procedural based. (For a brief primer on IDS types, see "Intrusion Detection in a Nutshell," page 138.) We also separate the IDS modules into three components: network sensors--that is, NIDS (network IDS) machines; host agents (the host-based components); and management consoles (centralized points of control and monitoring). We do not consider products that parse only Web logs or perform solely binary integrity checks to be IDSes. Intrusion-detection tools? Yes. Systems? Not really.

Vendor-speak aside, IDS products also have some gnarly obstacles to overcome. Regardless of what approach you take--deploying host or network, or a combination of the two--there are some common problems that plague each. For starters, organizations are continually deploying intrusion-detection systems that become as neglected as network-management "frameworks." We've spoken to a wide range of consultants that have seen organizations adopt the "fire and forget" model for IDS deployment. Unfortunately, that's like dropping an unemployed street dweller off at an Ivy League campus and hoping he or she gets an education. IDSes are far from self-supporting and even further from running themselves unattended.

Before embracing IDS, organizations need to ask a few questions up front. Who is going to manage and monitor the IDSes? Do they have the proper skill sets to do so? Who is going to stay on top of product updates? Do they have enough time to do so? And, finally, what will the incident-response procedures be if the IDS actually detects something? If, for example, your IDS deployment is incredibly successful and you start noticing the fleets of hackers that are attacking or successfully burrowing into your infrastructure, do you have the resources to deal with them? The tools? The personnel? Surprising as this might sound, some organizations deploy intrusion-detection technology only to realize they are ill-equipped to handle even basic security breaches. They are then forced to come up with a game plan using a partially depleted budget.

Let's take a look at why some of these issues are so critical. First off, intrusion-detection technology suffers from the same problems with which the virus-scanning industry struggles: They're both based on a purely reactionary model. As new vulnerabilities and attacks continue to surface at an increasing pace, current IDSes can detect these new threats only after the systems have been instructed to do so. This usually involves upgrades of some sort, provided by the vendors.

Although a few products, such as Enterasys' Dragon line and Network Flight Recorder's NFR, are flexible enough to allow custom signature development, few IT organizations can staff employees who can sit around coding IDS signatures all day. Although admittedly an "anomaly-based" IDS (one that could theoretically identify illegal/irregular traffic without specified signatures) could solve this problem, we have yet to see anything close to a shipping product based on this model that can operate in an enterprise environment. For now, network-based IDS signature updating is a very important issue if you want to compete in the race against intruders.

At the end of the day, managers must realistically budget not only for IDS software and hardware costs, but for staffing costs as well. Unlike switches, routers and hubs, IDS technology calls for human attention. A few network sensors and a console may cost between $30,000 and $60,000 in licensing fees, depending on the vendor and technology, but if you do not have the staff to monitor, maintain and use the options that IDS technology brings to the environment, the attention might be better focused elsewhere first. Hammering out threat-identification efforts, making sure all systems and services have been patched to current revision levels, and finishing up any needed policy and procedural work are all worthy efforts that most organizations should have mastered.