Re: Announcement: Alert Verification for Snort

From: Martin Roesch (
Date: 10/24/03

  • Next message: Martin Roesch: "Re: Announcement: Alert Verification for Snort"
    Date: Thu, 23 Oct 2003 21:57:01 -0400
    To: "Sam f. Stover" <>

    On Oct 23, 2003, at 6:53 AM, Sam f. Stover wrote:

    > On Wednesday, October 22, 2003, at 11:22 PM, Martin Roesch wrote:
    >> 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.
    > In the not too distant past I would have agreed with this - but I
    > think as IDS implementations grew, the way people describe FPs has
    > changed. I think today's IDS *needs* to know "the additional
    > information about the context and relevance" - because the event you
    > are referring to is what I'll call an "effective FP". Effective
    > because any time I spend trying to track down an IIS attack on an
    > apache box is wasted effort. I completely understand your point
    > Marty, because an attack did occur, and the IDS did log it. However,
    > if it is going to log it, then I want it to tell me that the severity
    > of the attack is lessened because it didn't succeed. Even better, I
    > want to see the 404 or 403 error, so I can show my boss why I didn't
    > even bother to look into it.

    I agree and we're building new technology at Sourcefire to address it,
    and I know other companies are either building new stuff or adapting
    old stuff (e.g. vuln scanners) to get the same sort of data. I was
    just pointing out that systems like Snort as it currently exists don't
    have this notion built into them so saying that alert verification
    reduces false positives when it's actually addressing nontextuals is
    something that I want to discuss, especially since it's my code that's
    producing the "false postives". :)

    > 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.


    > 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.

    Yes. Separating the wheat from the chaff is becoming increasingly
    important in IDS as we all know, I'll be interested to see how the
    different techniques and approaches people are using to address this
    problem actually work in production.


    Martin Roesch - Founder/CTO, Sourcefire Inc. - (410)290-1616
    Sourcefire: Snort-based Enterprise Intrusion Detection Infrastructure -
    Snort: Open Source Network IDS -
    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: Martin Roesch: "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: Announcement: Alert Verification for Snort
      ... >> that your IDS is detecting exactly as it was asked to. ... > and an IIS attack on an IIS box. ... There is a third method that hasn't been mentioned yet: Automating the ...
    • 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 ...