Why Do IDS Deployments Often Fail?
It seems the number of disgruntled IDS owners exceeds the number of satisfied customers. Why are IDS deployments prone to failure? The answer lies in the comparison among "must-have" products of the 1990s. The must-have security product of the mid-1990s was the firewall. A properly configured firewall implements access control (i.e., the limitation of access to systems and services based on a security policy). Once deployed, a firewall provides a minimal level of protection. If told to block traffic from the Internet to port 111 TCP, no one need ever check that it is doing its job. (The only exception involves unauthorized parties changing the firewall's access control rules.) This is a technical manager's dream: buy the box, turn the right knobs, and push it out the door. It does its job with a minimum amount of attention.
After the firewall, security managers learned of IDSs. In the late 1990s the IDS became the must-have product. Commercial vendors like Internet Security Systems, the Wheel Group (acquired by Cisco in February 1998), and Axent (acquired by Symantec in July 2000) were selling IDS software by fall 1997. Articles like those in a September 1997 issue of InternetWeek praised IDSs as a "layer of defense that goes beyond the firewall."  Even the Gartner Group, now critical of intrusion detection products, was swept up in the excitement. In that InternetWeek article, the following opinion appeared:
In the past, intrusion detection was a very labor-intensive, manual task, said Jude O'Reilley, a research analyst at Gartner Group's network division, in Stamford, Conn. "However, there's been a leap in sophistication over the past 18 months," and a wider range of automated tools is hitting the market, he said.
Technical managers treated IDS deployments as firewall deployments: buy, configure, push out the door. This model does not work for IDSs. A firewall performs prevention, and an IDS performs detection. A firewall will prevent some attacks without any outside supervision. An IDS will detect some attacks, but a human must interpret, escalate, and respond to its warnings. If you deploy an IDS but never review its logs, the system serves no purpose. Successful IDS deployments require sound products, trained people, and clear processes for handling incidents.
It is possible to configure most IDSs as access control devices. Features for implementing "shunning" or "TCP resets" turn the IDS from a passive observer into an active network participant. I am personally against this idea except where human intervention is involved. Short-term incident containment may merit activating an IDS's access control features, but the IDS should be returned to its network audit role as soon as the defined access control device (e.g., a filtering router or firewall) is configured to limit or deny intruder activity.