Home > Information Security, Intrusion Detection, Intrusion Prevention > IDS: Vitamins Or Prophylactic?

IDS: Vitamins Or Prophylactic?

September 25th, 2008 Leave a comment Go to comments

Ravi Char commented on Alan Shimel's blog titled "IDS – The Beast That Just Won't Die."

Ravi makes a number of interesting comments in his blog titled
"IDS/IPS – is it Vitamins?"  I'd like to address them because they offer what I maintain is a disturbing perspective on the state and implementation of IDS today by referencing deployment models and technology baselines from about 2001 that don't reflect reality based on my personal experience.

Ravi doesn't allow comments for this blog, so I thought I'd respond here.

Firstly, I'm not what I would consider and IDS apologist, but I do see the value in being able to monitor and detect things of note as they traverse my network.  In order to "prevent" you first must be able to "detect" so the notion one can have one without the other doesn't sound very realistic to me.

Honestly, I'd like to understand what commercial stand-alone IDS-only solutions Ravi is referring to.  Most IDS functions are built into larger suites of IDP products and include technology such as correlation engines, vulnerability assessment, behavioral anomaly, etc., so calling out IDS as a failure when in reality it represents the basis of many products today is nonsensical.

If a customer were to deploy an IPS in-line or out-of-band in "IDS" mode and not turn on automated blocking or all of the detection or prevention capabilities, is it fair to simply generalize that an entire suite of solutions is useless because of how someone chooses to deploy it?

I've personally deployed Snort, Sourcefire (with RNA,) ISS, Dragon, TippingPoint, TopLayer and numerous other UTM and IDP toolsets and the detection, visibility, reporting, correlation, alerts, forensic and (gasp!) preventative capabilities these systems offered were in-line with my expectations for deploying them in the first place.

IDS can capture tons of intrusion events, there is so much of don't
care events it is difficult to single out event such as zero day event
in the midst of such noise. 

Yes, IDS can capture tons of events.  You'll notice I didn't say "intrusion events" because in order to quantify an event as an "intrusion," one would obviously have already defined it as such in the IDS, thus proving the efficacy of the product in the first place.  This statement is contradictory on face value.

The operator's decision to not appropriately "tune" the things he or she is interested in viewing or worse yet not investing in a product that allows one to do so is a "trouble between the headsets" issue and not a generic solution-space one.  Trust me when I tell you there are plenty of competent IDS/IPS systems available that make this sort of decision making palatable and easy.

To take a note from a friend of mine, the notion of "false positives" in IDS systems seems a little silly.  If you're notified that traffic has generated an alert based upon a rule/signature/trigger you defined as noteworthy, how is that a false positive?  The product has done just what you asked it to do!  Tuning IDS/IPS systems requires context and an understanding of what you're trying to protect, from where, from whom, and why.

People looking for self-regulating solutions are going to get exactly what they deserve.

Secondarily, if an attacker is actually using an exploit against a zero-day vulnerability, how would *any* system be able to detect it based on the very description of a zero-day?

It requires tremendous effort to sift through the log and derive meaningful actions out of the log entries.

I again remind the reader that manually sifting through "logs" and "log entries" is a rather outdated concept and sounds more like forensics and log analysis than it does network IDS, especially given today's solutions replete with dashboards, graphical visualization tools, etc.

IDS needs a dedicated administrator to manage. An administrator who
won't get bored of looking at all the packets and patterns, a truly
boring job for a security engineer. Probably this job would interest a
geekier person and geeks tend to their own interesting research!

I suppose that this sort of activity is not for everyone, but again, this isn't Intrusion Detection, Shadow Style (which I took at SANS 1999 with Northcutt) where we're reading through TCPDUMP traces line by line…

There are companies that do without IDS, and they do just fine. I
agree with Alan's assessment that IDS is like a Checkbox in most
cases.  Business can run without IDS just fine, why invest in such a

I am convinced that there are many companies that "do without IDS."  By that token, there are many companies that can do without firewalls, IPS, UTM, AV, DLP, NAC, etc., until the day they realize they can't or realize that to be even minimally compliant with any sort of regulation and/or "best practice" (a concept I don't personally care for,) they cannot.

I'm really, really interested in understanding how it is that these companies "…do just fine."  Against what baseline and using what metrics does Ravi establish this claim.  If they don't have IDS and don't detect potential "intrusions," then how exactly can it be determined that they are better off (or just as good) without IDS?

Firewalls and other devices have built in features of IDS, so why invest in a separate product.

So I misunderstood the point here?  It's not that IDS is useless, it's just that standalone IDS deployments from 2001 are useless but if they're "good enough" functions bundled with firewalls or "other devices," they have some worth because it costs less?

I can't figure out whether the chief complaint here is an efficacy or ill-fated ROI exercise.

IDS is like Vitamins, nice to have, not having won't kill you in
most cases. Customers are willing to pay for Pain Killers because they
have to address their pain right away. For Vitamins, they can wait.
Stop and think for moment, without Anti-virus product, businesses can't
run for few days. But, without IDS, most businesses can run just fine
and I base it out of my own experience.

…and it's interesting to note the difference between chronic and acute pain.  In many cases, customers don't notice chronic pain — it's always there and they adjust their tolerance thresholds accordingly.  It may not kill you suddenly, but over time the same might not be true.  If you don't ingest vitamins in some form, you will die.

When an acute pain strikes, people obviously notice and seek immediate amelioration, but the pain killer option is really just a stop-gap, it doesn't "cure" it simply masks the pain. 

By this definition it's already too late for "prevention" because the illness has already set in and detection is self-evident — you're ill.  Take your vitamins, however, and perhaps you won't get sick in the first place…

The investment strategy in IDS is different than that of AV.  You're addressing different problems, so comparing them equliaterally is both unfair and confusing.  In the long term, if you don't know what "normal" looks like — a metric or trending you can certainly gain from IDS/IPS/IDP systems — how will you determine what "abnormal" looks like?

So, sure, just like the vitamin example — not having IDS may not "kill" you in the short term, but it can certainly grind you down over the long haul.

Probably, I would have offended folks from the IDS camp. I have a
good friend who is a founder of an IDS company, I am sure he will react
differently if he reads my narratives about IDS.  Once businesses start
realizing that IDS is a Checkbox, they will scale down their
investments in this area. In the current economic climate, financial
institutions are not doing well. Financial institutions are
big customers in terms of security products, with the current scenario
of financial meltdown, they would scale down heavily on their spending
on Vitamins.

Again, if you're suggesting that stand-alone IDS systems are not a smart investment and that the functionality will commoditize into larger suites over time but the FUNCTION is useful an necessary, then we agree.

If you're suggesting that IDS is simply not worthwhile, then we're in violent disagreement.

Running IDS software on VMware sounds fancy.  Technology does not
matter unless you can address real world pain and prove the utilitarian
value of such a technology. I am really surprised that IDS continues to
exist. Proof of existence does not forebode great future. Running IDS
on VMware does not make it any more utilitarian. I see a bleak future
for IDS.

Running IDS in a virtual machine (whether it's on top of Xen, VMware or Hyper-V) isn't all that "fancy" but the need for visibility into virtual environments is great when the virtual networking obfuscates what can be seen from tradiational network and host-based IDS/IPS systems. 

You see a bleak future for IDS?  I see just as many opportunites for the benefits it offers — it will just be packaged differently as it evolves — just like it has over the last 5+ years.


  1. September 25th, 2008 at 18:07 | #1

    i check out this blog every once and a while. this is an interesting post.

  2. September 30th, 2008 at 06:42 | #2

    Hoff, I'm glad you posted this. This basically details every thought I've had about IDS, and reasons why I will never say it is dying or bad.
    Hell, I will go so far as to say I consider an IDS a crucial piece to any actual security practioner. The information is extremely valuable, even if it is tuned so tightly that it only alerts on what turn out to be real intrusions and those happen only once every 6 months.
    But yes, Ravi has a point about needing a dedicated or at least very experienced admin in charge of the IDS. But you're equally correct that too many people expect turn-key security approaches where you stand it up and walk away forever. That's a failing in someone's definition or expectation of what the process of "security" really is. Technology or devices will never truly remove that need for some human decisions-making.
    Why else do we still have security guards? We still also need cyber security guards.

  1. No trackbacks yet.