Thoughts on Alerts

I've been thinking about my previous post regarding NSM methods and the "log everything" mentality that I believe is unworkable in medium to large environments. Given that I'm a guy who doesn't like to give people "it's impossible" for an answer and I don't like "unsolved" problems, I've been thinking about some of the other things that could be put into events that would make them more useful for NSM-style incident analysis. My thinking on this topic was further bolstered by Bejtlich's recent post on his NSM process.

Given that "alertocentrism" is a Bad Thing, what are some of the other things we could do with an engine like Snort that could add value to the events that it generates? I'm not going to recommend logging everything, although you certainly could do that pretty easily. I noticed from the post referenced above that flow analysis seems to constitute a large portion of the time that is spent performing NSM. Given that Snort 2.x (and 3.x) already have the ability to log flow information (albeit somewhat limited in stream4), what are the things that we could do to improve alerts?

A Snort unified alert typically contains the following information:

• An Event structure containing

• generator ID
• snort ID
• snort ID Revision number
• classification ID
• priority
• event ID
• event reference
• event reference time

• Event packet information containing

• packet timestamp
• source IP
• destination IP
• source port/Icmp code
• dest port/icmp type
• protocol number
• event flags

Additionally, flow records from Snort (stream4) look like this:

• start time
• end time
• server (responder) IP
• client (initiator) IP
• server port
• client port
• server packet count
• client packet count
• server byte count
• client byte count

I've been thinking that one thing that could be done that would be pretty easy and add some value would be to add "point-in-time" flow summary data to Snort events. The idea behind doing this would be to add the data for the flow that the event occurred upon to the event data. Something like this:

• Event structure (as above)
• Event packet info (as above)
• "Flow point" information including

• flow start time
• last packet time
• initiator packet count
• initiator bytes
• responder packet count
• responder bytes
• initiator TCP flag aggregate (if any)
• responder TCP flag aggregate
• last packet originator (initiator/receiver)
• alerts on flow (count)
• flow flags (bitmap)

I think that this kind of information could certainly be useful for putting an event into context within its flow, the analyst could see if there has been bidirectional interaction prior to the event, get a sense for the number of alerts on the flow prior to the current event, etc.

There are some other things that could be done along with this. I think that adding in flow point data along with doing things like post-event packet logging would probably be more useful than what we have today. I know post-event logging is not what you want in a full-blown NSM context but it certainly helps to constrain the data management issue associated with just logging every packet and it's better than nothing. I suppose we could also add things like persistent logging to the system as an option (thinking more in the Snort 3.0 timeframe) to allow continuous logging of selected packet traffic, of course this is a DoS waiting to happen so it'd have to be turned off by default and have some pretty serious constraint logic associated with it (in terms of port/protocol/IP filtering).

I'm going to think about this more, anyone NSM-heads have any thoughts on the topic?

Technorati Tags: alerts, NSM, programming, Snort