OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: IDS: IDS Comparison
From: Ron Gula (rgulanetwork-defense.com)
Date: Mon Mar 06 2000 - 07:30:33 CST


FAQ: See http://www.ticm.com/kb/faq/idsfaq.html
IDS: See http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
HELP: Having problems... email questions to ids-owneruow.edu.au
NOTE: Remove this section from reply msgs otherwise the msg will bounce.
SPAM: DO NOT send unsolicted mail to this list.
USUBSCRIBE: email "unsubscribe ids" to majordomouow.edu.au
---------------------------------------------------------------------------

---
John,

>I still think that you need 2 weeks of tinkering (on the low end) before >NFR can be usable in a customer environment. One of the real problems >with all IDSs to date is that they do not understand the difference >between a real attack against a vulnerable server and an attack that is >simply passing by on the wire. This is a serious drawback and one that >every single person looking at IDS technology should take into >consideration.

Do some research. ISS SafeSuite decisions supports this. So does the CMDS tool from ODS. So does L3/Symantec's Retriever/Surveyor product. There are also a *lot* of home grown back-end databases which do this in existence at various national labs, certain fortune 50 companies and in govt R&D shops. I don't want an IDS operating on a firewall or at T3 speeds to have to worry about weather some internal server is vulnerable or not. I would rather have it use those extra CPU cycles to a) look for more signatures and anomalies or b) operate faster.

Dragon does not automatically correlate attacks with vulnerabilities (yet) but it does recognize a wide variety of successful compromises. These are much more interesting because many of the attacks come from zero day exploits which I have a hard time believing any IDS can truly keep up with.

>For example, I can take a simple attack generation script and fire off >100 different web based attacks against each address in a Class B. Now, >even if there are only 3,000 hosts in this Class B and only 100 of them >are running a web server, every IDS on the planet will scream about >every one of the 65,535 * 100 web attacks [total] as if each attack were >of the same severity. This strikes me as completely stupid and totally >useless to the customer. I'll even quote Ranum directly:

If you want to log this data you should try Dragon. Many of our customers get this exact scenario every day. Yeah, it's a lot of data but its also a ton of evidence. And when they do find a vulnerable server (and there are many vulnerable web servers out there) Dragon can tell when the attacks were successful or at least provide enough forensic evidence to start an investigation. Having knowledge of your network's vulnerabilities is a great way to organize alerts from an IDS. But an IDS should still log these things.

Something your point also misses is not weather a particular server is vulnerable to a particular attack, but who owns those servers. For example, I may be very concerned if a hacker sends any attack to my CEO's computer. I may be even more concerned if the entire R&D department is singled out in a scan. I'd would really want to know the 'tell' that let the outsiders scan only those particular machines.

Ron Gula, CTO Network Security Wizards http://www.securitywizards.com