RE: Announcement: Alert Verification for Snort

["Andrew Hall" <andrew.hall () m5networks com au>]

I think what you are really after is to be found in a good security
information management (SIM) tool.  

An IDS is good at what it does ... ie in raw detection of "events" ...
by what ever means that is (string matching, heuristics, protocol
anomaly etc) but as mentioned by others on the list the context is
critical to determine if the event is really an "incident".  And again,
without context the priority of an incident can not be determined.

Integration with a VA tool or passive fingerprinting is only a partial
solution - and many IDS tools have been able to do that for a while now
(either plugging in with Nessus - Snort, Dragon or their own proprietary
VA scanner - ISS, Symantec).   Yes, combining VA and IDS will
drastically reduce the number of alerts to see on a console, but you
will still suffer from false positives and false negatives.

No externally probing or passively finger printing tool is going to be
100% accurate across your network.  Accuracy drops even further if you
are relying on the tool to determine specific versions of an
application.  The vast majority of remote exploits are highly version
specific, and a VA tool is not going to give that level of reliable
accuracy to determine if an "event" is really an attack likely to cause
impact.

Where passive finger printing and VA is better suited is in trying to
determine attacks leaving your network - where you have no idea about
that what is running on the other side of the world, but you are happy
for the VA tool to make an educated guess as to whether it is apache or
IIS running somewhere. 

The only machine on your network which knows exactly what software /
versions etc is running and the time of attack AND the impact of an
attack is the machine in the network which has received the attack.  To
determine if an attack is truly effective you need to correlate logs on
actual hosts with the other sources of network information.

Ie consider a buffer overflow attack to a web server.

1. External IDS pattern matches overflow to web server
2. Firewall logs an accept
3. Inner (different vendor) IDS pattern matches overflow to web server
4. Syslog on web server shows apache to has restarted
5. Host based IDS on web server says whole bunch of noops recieved
5. Asset register shows that this web server is the most important asset
in the company

Each line item above means nothing in itself ... but drawn together they
show a true critical incident in your network.

So why not just rely on host based IDS?  Because each of the above
mentioned security tools in a network will detect different things in
different manners.  What one misses the other may pick up - security in
depth. They also provide a better context to the ultimate event - ie you
can trace the path of the attack back through your network, and you can
correlate that particular attack characteristics (attack type, source
IP, etc) across your other network devices.

Finally, there is the good old debate of why an IDS is even being
deployed in a network. I argue that an IDS has three main purposes all
of which are essential;

- Real time event notification
- Trending analysis
- Forensics 

If you want "real time" event notification you need heavy filters and
good event correlation to determine when an event is really an incident

If you want trending you need to store certain meta data information
about events viewed which goes to assist in your security device tuning
- and in report generation

If you want forensics you need to be capturing and storing as much data
as possible, since what an IDS does not pick up today as an attack may
actually be an attack - those 1000's of "false positives" may not be so
false when they are analyzed in detail and put in context with a
successful attack

I argue that the only way to get this flexibility is to use a SIM tool
... something which can store large amounts of raw data / logs, yet
present a highly filtered and highly correlated view of all the data in
your network.

Sorry for the length of the post ... 

Andrew



-----Original Message-----
From: Sam f. Stover [mailto:sstover () atrc sytexinc com] 
Sent: Thursday, 23 October 2003 8:54 PM
To: Martin Roesch
Cc: Sam f. Stover; Christopher Kruegel; focus-ids () securityfocus com
Subject: Re: Announcement: Alert Verification for Snort

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


Just my $0.02
____
S.f.Stover
sstover () iwc sytexinc com

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