Re: Announcement: Alert Verification for Snort

[Martin Roesch <roesch () sourcefire com>]

Hi Aaron,

I've been calling the "real attack, not vulnerable" detection case  
"nontextuals" lately which is the one word way of saying "it was a real  
attack that was contextually irrelevant against the target due to lack  
of a suitable vulnerability existing on that target". :)

I've been calling them that for a few months now, people seem to get it  
but maybe people at large on the focus-ids list and in industry won't  
want to adopt it since I'm "a vendor" these days.  I guess we'll see.

     -Marty


On Oct 23, 2003, at 5:58 AM, Aaron Temin wrote:

> Marty,
>
> Thanks for laying out all eight possibilities (your numbers 3 and 6  
> each
> representing two each).  I have seen a lot of text written to this list
> trying to get at the difference between an attack one cares about and  
> an
> attack one doesn't care about.  I agree that the latter is still an
> attack, it's "ineffective" or something, but it's impact on a given
> network is different than it's intent (which is to attack).
>
> Would you care to suggest a succinct way (word or phrase) we can agree
> to use to describe a true but ineffective attack?  (They are two
> different dimensions, and perhaps explicitly giving a new name here
> would help get over the red herring of whether an attack that has no
> impact is an attack.)
>
> Thanks,
>
> Aaron
>
> Aaron Temin
> Ringneck Technologies
>
> On Wed, 2003-10-22 at 23:22, Martin Roesch wrote:
> > Hi Chris,
> >
> > Just to make a point of semantics, I'd like to comment on the "reduce
> > the large number of false positives produced by intrusion detection
> > systems such as Snort" quote from your post.
> >
> > I spent some time a couple months ago talking about the misconceptions
> > of "false positives" in Snort on this very list and I think there's a
> > valid point to be made here.  Let me enumerate the cases you can have
> > as I see it:
> >
> > 1) Detect, Attack Present, Vulnerable:  True Positive
> > 2) Detect, Attack Present, Not Vulnerable: Nontextual (i.e. detect
> > requiring contextual data to resolve)
> > 3) Detect, No Attack, [vuln|not vuln]: false positive
> > 4) No Detect, Attack Present, Vulnerable: False Negative
> > 5) No Detect, Attack Present, Not Vulnerable: ?
> > 6) No Detect, No Attack, [vuln|not vuln]: Don't care (true negative?)
> >
> > 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.
> >
> > Case 3 is where we have the true false positives, the NIDS is  
> > detecting
> > attacks that aren't occuring on the network.  I think that case 2
> > happens far more than case 3 with systems like Snort, which is why I
> > think it's important to make the distinction between "real" false
> > positives (i.e. the IDS screwed up) and nontextuals where the IDS has
> > done its job, it just needs more information to properly evaluate the
> > reality and priority of the event.
> >
> > I hope this is making sense to everyone here, please let me know if  
> > you
> > have any questions.  Looks like a neat tool Chris!
> >
> >
> >       -Marty
> >
> > On Oct 21, 2003, at 9:16 PM, Christopher Kruegel wrote:
> >
> > > [Please excuse multiple copies of this message]
> > >
> > > Alert Verification is a technique to reduce the large number of false
> > > positives produced by intrusion detection systems such as Snort. The
> > > idea is to actively probe for the vulnerability that is exploited by  
> > > a
> > > certain detected attack. When the victim is not vulnerable, the alert
> > > can be simply discarded or tagged with a low priority.
> > >
> > > William Robertson has implemented an extension for Snort that
> > > implements Alert Verification. Patches for the current version of
> > > Snort (2.0.2) and additional information are available under
> > >
> > > http://www.cs.ucsb.edu/~wkr/projects/ids_alert_verification/
> > >
> > >
> > > Please send any comments or bug reports to
> > >
> > > snort-av () cs ucsb edu
> > >
> > >
> > > --------------------------------------------------------------------- 
> > > --
> > > ----
> > > FREE Whitepaper: Better Management for Network Security
> > >
> > > Looking for a better way to manage your IP security?
> > > Learn how Solsoft can help you:
> > > - Ensure robust IP security through policy-based management
> > > - Make firewall, VPN, and NAT rules interoperable across  
> > > heterogeneous
> > > networks
> > > - Quickly respond to network events from a central console
> > >
> > > Download our FREE whitepaper at:
> > > http://www.securityfocus.com/sponsor/Solsoft_focus-ids_031015
> > > --------------------------------------------------------------------- 
> > > --
> > > ----
--
Martin Roesch - Founder/CTO, Sourcefire Inc. - (410)290-1616
Sourcefire: Snort-based Enterprise Intrusion Detection Infrastructure
roesch () sourcefire com - http://www.sourcefire.com
Snort: Open Source Network IDS - http://www.snort.org


---------------------------------------------------------------------------
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
http://www.securityfocus.com/sponsor/RSA_focus-ids_031023 
and use priority code SF4.
---------------------------------------------------------------------------