IDS: RE: Announcement: Alert Verification for Snort

["Craig H. Rowland" <crowland () cisco com>]

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