Re: Snort with an expert system

[Greg Shipley <gshipley () neohapsis com>]

I respect the spirited and intelligent conversation here, but at the 
risk of sounding like a) an old guy that's been following this stuff 
for too long and b) a complete jerk:

1. IDS vendor / IDS software engineer / uber-geek view: "it's not 
   technically a false-positive because if signature/ rule / 
   pattern-match/ neugent/ whatever fired on x and it was programmed 
   to identify q but you have to factor in y, and z, and..."

   <bang head here -----> X

2. Infosec operational person trying to do his job: "Was I attacked 
   and was the attack successful?  Yes or NO will suffice, thank you."

I submit that for the vast majority of consumers of IDS technology we 
really only give a crap about #2.  So if the device can give us a 
reasonably accurate answers to #2 we are happy.  And if it can't we 
are unhappy.

I think the fact we've been discussing these topics for close to 
twenty years now suggests that we aren't happy, but maybe I'm too old 
and being a jerk.  :)

My .01,

-Greg



On Thu, 25 Jun 2009, Joel Esler wrote:

> On Thu, Jun 25, 2009 at 10:04 AM, Tomas Olsson <tol () sics se> wrote:
> > Stefano Zanero wrote:
> > > > > Is it a false positive a case where there is no rule, or the traffic
> > > > > does not match with the rule, and the engine still fires?
> > >
> > >
> > > > This does not fit with the above definition since the alert must be
> > > > triggered by the traffic.
> > >
> > > You would be surprised in knowing that this is the only case where
> > > you're pretty sure it IS a false positive that you are looking at (a
> > > false positive of the engine itself, whereas the other examples are
> > > noncontextual alerts caused by careless configuration by the user)
>
>  Here's a topic for discussion, just to fan the flame, and basically
> just to get the discussion further along.
>
> <I work for Sourcefire>
>
> "There are no false positives in pure signature based intrusion
> detection". (Note I said signature based, not rule based, there is a
> difference, anyway....)  If a false positive is defined as you have it
> above, then there are no false positives.  If you have a rule that
> alerted on a piece of traffic that the rule should NOT have alerted
> on, whose fault is it?  You for writing the rule? or the engine's
> fault?  Its only doing what you told it to do. Confused?  Let me back
> up.
>
> For example, a rule fires because an IIS exploit is destined for your
> Apache server.  Is that a false positive?  In the pure IDS sense, no,
> because the traffic took place.  But when you put the alert in
> context, then yes, it is a false positive.  The rule should not have
> triggered because the end application base is incorrect as it pertains
> to the rule.  Put that scenario on a real network where IPs change and
> applications get installed all the time, and OSes come and go, ports
> open and close, services are on those ports, and on non-standard
> ports, and lets face it you don't know where or what those ports are
> etc.. and you see the problem.
>
> Which is why context given to Snort is so important, which is why
> Sourcefire developed things like RNA (
> http://www.sourcefire.com/products/3D/rna ) in order to solve that
> problem.  Which is also why things like Snort 3.0 are being developed,
> to be able to deal with adjustments in a more real-time fashion.
>
> That being said.  False positives do happen.  Which is why there are
> false positive reporting methods.  If someone ELSE wrote the rule,
> then its a duty to report those FPs, so those FPs can be corrected as
> much as possible. If you wrote the rule, then it's time to go back to
> the drawing board.
>
> An IPS should only alert when you need to go DO something.  IMO.  I
> hate having superfluous alerts.  Alerts = work = time = money = more
> work.
>
> These are my opinions and not the opinion of my company, but basically
> just to fuel the conversation a bit.   Sorry if it seemed like I
> plugged a bit.
>
> --
> Joel
>
> -----------------------------------------------------------------
> Securing Your Online Data Transfer with SSL.
> A guide to understanding SSL certificates, how they operate and their application. By making use of an SSL 
> certificate on your web server, you can securely collect sensitive information online, and increase business by 
> giving your customers confidence that their transactions are safe.
> http://www.dinclinx.com/Redirect.aspx?36;5001;25;1371;0;1;946;9a80e04e1a17f194
-----------------------------------------------------------------
Securing Your Online Data Transfer with SSL.
A guide to understanding SSL certificates, how they operate and their application. By making use of an SSL certificate 
on your web server, you can securely collect sensitive information online, and increase business by giving your 
customers confidence that their transactions are safe.
http://www.dinclinx.com/Redirect.aspx?36;5001;25;1371;0;1;946;9a80e04e1a17f194