RE: Announcement: Alert Verification for Snort

From: Craig H. Rowland (
Date: 10/24/03

  • Next message: Robin Sommer: "Re: Announcement: Alert Verification for Snort"
    To: "'Sam f. Stover'" <>, "'Martin Roesch'" <>
    Date: Fri, 24 Oct 2003 11:23:07 -0500

    > > In case 2 the "nontextual" isn't a false positive but I think that
    > > most people are calling it an FP these days. I *personally* think
    > > that's a misconception. What we have in that case is a
    > *real attack*
    > > that your IDS is detecting exactly as it was asked to.
    > Just because
    > > it doesn't have the additional information about the context or
    > > relevance of the event isn't a problem with the IDS, it's a side
    > > effect of the way that NIDS have been built for the past 10 years.

    > I want my IDS to differentiate between an IIS attack on my apache box
    > and an IIS attack on an IIS box. I don't really care how it
    > does it.
    > The two main methods, as I see it, are passive fingerprinting or
    > integration with another tool like a vuln scanner. Both have their
    > drawbacks w/ relation to different environments - which could
    > probably
    > fuel a complete thread.

    Biased opinion coming up...

    There is a third method that hasn't been mentioned yet: Automating the
    on-host investigation of the attack.

    I've written a large number of attack libraries and exploits in the past
    for commercial scanners and there are a many ways for them to completely
    miss a vulnerability or flag something as relevant when it isn't (or
    even worse you can crash the host). In the end you're simply going to
    have to look at the system directly to see if the problem exists. Not
    only is this the lowest impact way to approach the problem, but you can
    then do neat things such as grab evidence before it can be tampered with
    and present it to the admin so they can evaluate the situation directly.
    With the large number of attacks today, and the large amount of
    knowledge to know what to investigate for each one, you need to automate
    the process.

    > The IDS landscape has changed. Ten years ago, the type of event
    > mentioned was probably not considered a FP. But at that
    > time, IDS was
    > an infant and people weren't dealing with events on the scale of
    > millions per day like they are today. Current-day NIDS need
    > to evolve
    > to solve the problems that current-day users are facing.
    > IMHO 10 years
    > ago, NIDS administrators could afford to be a bit more interested in
    > all kinds of attacks. IDS was a new and exciting technology.
    > I think
    > it's lost some of it's glamour since then and people have to
    > use it as
    > just another tool. And the people I talk to don't have the time nor
    > resources to run down half of the "real" attacks, much less look into
    > attacks that will never succeed.

    Exactly. An IDS only gets you so far and what you're left with after the
    detection is a *huge* amount of manual work even if you have only a
    small number of alarms a day. Consider that after the attack has been
    seen you have to:

    1) Verify the attack
    2) Investigate the attack
    3) Cleanup and isolate the affected host
    4) Etc.

    You need to eliminate as much of the remaining manual process as
    possible to be useful. For me this means automating as much of the
    post-attack investigation and evidence collection as you can. Not only
    is the level of expertise required to do this very high even for those
    who do this stuff daily, but having the repeatability and 24/7 response
    is critical to most admins.

    -- Craig

    Network with over 10,000 of the brightest minds in information security
    at the largest, most highly-anticipated industry event of the year.
    Don't miss RSA Conference 2004! Choose from over 200 class sessions and
    see demos from more than 250 industry vendors. If your job touches
    security, you need to be here. Learn more or register at
    and use priority code SF4.

  • Next message: Robin Sommer: "Re: Announcement: Alert Verification for Snort"

    Relevant Pages

    • IDS Assessment (was: Intrusion Prevention... probably something else at one point)
      ... scrutiny of all IDS features/technologies. ... Anomaly-type detection engines can ... weaknesses of each detection methodology (which is described in much ... attack d'jour with a cool sounding name and/or press ...
    • Re: Target based IDS review and discussion in Information Security
      ... This all began in 2000 when Marty lead the IDS development effort at ... > describes alerts as they pop out of IDS consoles. ... > Roesch names two other components as integral to target based NIDS: ... > an attack on a system that cannot succeed should be demoted. ...
    • RE: IDS Informer
      ... Subject: IDS Informer ... The main difference with IDS Informer and other testing tools (such ... While the attack is happening we have a network ...
    • RE: IDS Informer
      ... quickly answer you question we can target any ip address. ... on the same segment as the IDS without harming that machine. ... I was looking at the IDS Informer and noticed ... While the attack is happening we have a network ...
    • RE: Thinking about Security rules...
      ... > Subject: Re: Thinking about Security rules... ... >>rules for the IDS. ... by which you attack. ... firewalls in series isn't nearly as nice as a stateful firewall coupled ...