Monday, January 29, 2007

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: , , ,

1 Comments:

At 4:04 AM, Blogger geek00L said...

Marty,

Adding flow attributes for the alert event seriously improve the workflow of performing analysis process and at the same time scale pretty well instead of having to log every single bits. This is pretty equalizer to running sguil without log_packets.sh(logging full content data). It really provides a big picture of the whole event. I use to follow this mechanism where I have developed myself when performing flow examination and analysis -

Flow -> Session -> Event/Activity -> Correlations

Some other interesting flow attributes that we can look at for example the time interval of each flow and jitter, initiator/responder application bytes.

NSM community still love to have the depth view of packet(payload insist). However sometimes when the environment is not allowed, the best we can do still down to logging as much data as possible .

Should be interesting piece when those are added into snort. And remember that flow beats encryption.

Just my thought, cheers ;]

 

Post a Comment

<< Home