RE: Views and Correlation in Intrusion Detection

From: adam.w.hogan <adam.w.hogan(at)delphi.com>
Date: Tue Jun 24 2003 - 09:23:37 EDT

>To be really effective, I'd like to see a system that looks at packets

>*then* sends an alert.

Then you may be in luck, there are a number of companies working on a solution like this. Actually, one week I heard the same presentation about this very idea from three different vendors - this idea's quite the buzz-word right now. I'll warn you, it may be awhile before any of these products are reasonably priced. I am looking forward to hearing more about Sourcefire's RNA, though.

>I don't want to know if an attacker is trying an overflow attack on my
IMAP
>server if my IMAP server isn't vulnerable to that attack. I could care

>less. I also don't want to know if some box somewhere with Code Red is

>hitting my network *unless* I have a box that's susceptible to Code
Red.

I feel differently, if anybody is on my network trying to use /any/ exploit /anywhere/ I'd like to know about it. Especially on the inside. Perhaps there's a difference between trying to follow this data for a large company than a university?

The most prominent reason that I don't consider this solution, however, is that it would be ridiculously difficult, if not impossible, to identify every server on the network here. I don't even know how many servers we have, let alone what OS, patch level, and services they have. There are tools being developed to passively scan the network and try to determine these things, but the ones I've seen cost a small fortune.

>So it takes a combination of knowledge to alert "intelligently". 1)
What
>is the attack? 2) Is the box vulnerable to that attack? 3) Did the
attack
>reach that box? 4) Was the attack successful?

I think #3 and #4 are the real gems I'm looking for. #1 is easy, most IDSes already do this. And I've already stated why I don't think #2 is a good idea (at least on the network here, I understand why it would help others). So how do we track if an attack reaches the box? If it's coming from the outside, we need to know if it gets through the firewall. And for anything on the inside we need to be able to track the IP back to which ever segment it originated in. Nothing's worse than discovering the source IP for an attack is a '192.168' address - I have no idea where that came from. Cisco's Netflow can help solve this, but only Cisco hardware (and only if the "owners" of said hardware want to help :-\). Does anybody know of a better way to do this, or is it necessary to put a sensor on every subnet? As for correlating data from the firewall with data from the internal IDS I've made a lot of progress with Open's [0] SysWatch and Management Console. But this still requires data to be in a certain format (syslog) and isn't very flexible once within the Management Console. If the data's stashed away in a MySQL database, or some proprietary format, how do we correlate it with the rest of our event data?

(Sorry if I come off as ranting, just trying to chip away at the issue so we can start to tackle smaller bits. Thanks to everybody has, and will, contribute to the discussion - your ideas are very helpful.)

-Adam W. Hogan

[0] - www.open.com

---

Attend the Black Hat Briefings & Training, July 28 - 31 in Las Vegas, the world's premier technical IT security event! 10 tracks, 15 training sessions, 1,800 delegates from 30 nations including all of the top experts, from CSO's to "underground" security specialists. See for yourself what the buzz is about! Early-bird registration ends July 3. This event will sell out. www.blackhat.com

---

Received on Wed Jun 25 10:02:42 2003