IDS products generate too many false alarms to be useful. At least that's a complaint I frequently hear when I discuss IDS technology with people.
Well, I say that the ''black eye'' that IDS products have taken in the media and in the eyes of many customers is largely due to poor deployment and configuration, not the products themselves.
More often than not, I see IDS products deployed on externally pointing network segments, and configured to look for everything. Well, guess what? That's kind of like trying to take the proverbial sip from a fire hose -- you're going to get a lot more than you bargained for.
That's not to say that there's no value to this mode of deploying IDS products. To be sure, there are hundreds of companies today that run IDS products in just this way. IT administrators who have the processing power, analysis software, time, and inclination, can sift through the heaps of collected data and might actually find things they really need to know about.
That's not the real value of IDS, however.
I believe that if you're going to sip from a fire hose, you should use a really small straw. Instead of having your IDS products look for everything that could go wrong, consider the inverse: set them to look for a very small number of things that would really affect your network or the security of the company's information.
In my September column, I discussed Software Security. In designing an application -- or carefully deploying a third party application, for that matter -- you should be going through a threat and risk analysis process.
One outcome from that process should be a prioritized list of the high-risk modules and components of the application as a whole. This list might include things like customer-sensitive data, authentication modules, encryption libraries, and such. But what they all should have in common is that, if an attacker compromises their confidentiality, integrity, and/or availability, very bad things are likely to happen.
What does this have to do with IDSs?
Well, that prioritized list of high-risk items should serve as a starting point for fine-tuning your IDS products. If, for example, you know your application's security depends entirely on the integrity of an authentication module, then point your IDS products to look for any attempts to modify that module.
Now, I know that I've presented an overly simplified picture of tuning IDS products here. For one thing, not all IDS products are easily configured to look for custom triggering events, like overseeing the integrity of an authentication module. Secondly, this level of tuning requires you to really -- and I mean really -- understand your applications.
That is all true, most certainly. But I'd argue that you should understand your applications anyway. And, as for the products, you're probably already staring at intrusion detection capabilities in your operating systems event logging and/or existing IDS product base, if you take the time to really tightly set them up for your environment.
Lastly, I brushed over the threat and risk analysis process pretty quickly, didn't I? Doing both of these well requires a good amount of time and effort. For starters, check out Carnegie Mellon's OCTAVE process, NIST's ASSET process, and Microsoft's STRIDE/DREAD processes. We'll take a more in-depth view of threat and risk analysis in an upcoming column.
IDS products don't deserve the black eye that they've gotten.
Of course, the marketing people have been quick to jump on this opportunity and hail the benefits of Intrusion Prevention Systems. Well, while IPS might be a technology you need, there's still plenty of value that can be tapped from IDS by properly integrating it into your environment.
But, in either case, you're going to need to take the time to do it right.
Kenneth van Wyk, a 19-year veteran of IT security, is the prinicpal consultant for KRvW Associates, LLC. The co-author of two security-related books, he has worked at CERT, as well as at the U.S. Department of Defense.