An alchemists view from the bar

Network Security Alchemy

Archive for June 2008

Automated IDS alert thresholding

leave a comment »

A question was posted to the Snort forums a short while back asking if Snort had the ability to accept how “dirty” a network is today, and then be alerted to only new threats that have never been seen before.

The idea behind this is quite simple, make an assumption that the network is “secure” as it is and operating fine today, then work out how much IPS noise it generates under this normal operation. In the future only alarm on events that have not been previously discovered during the “normal” period.  This type of difference analysis commonly requires a reporting tool that analyses the output from network sensors, but the way that the question was phrased got me thinking about this as a tuning process.

So lets summarize the steps involved to achieve this as a tuning goal.

  • Sensor must be deployed into the target network
  • Sensor must be run for a period of time to generate an alert “base line”
  • The Alerts must be investigated to check that they are all “acceptable” and normal for a network of this type (make sure you don’t accept an already p0wned network)
  • All alerts that were raised then need to be suppressed based on the assumption that they have no interest to the analyst now or in the future.
  • Sensor must be restarted with a new “suppressed” configuration.

It turns out that this is a simple thing to achieve, and after thinking about it for a while also raises two very interesting points:

  • The bulk trade off between F+ and F- . Is there an acceptable ratio, and what is it?
  • IDS for forensic use vs IDS for enhancing current security

I will approach both of the above points in another blog entry when I get some time.

Anyway, here is a dirty bit of perl that achieves what the above. It parses Snort’s fast alert output, and creates a suppression entry for each gid:sid that has generated an alarm. The suppression decision is made either on the event source IP, destination IP, or both IPs depending on what type of event is discovered.

For example, it is more common that policy-violations will need to be suppressed on the IP address that was the source of the event, and therefore the source of the “non policy violating policy-violation” that you don’t want to know about in the future (there is logic there, you just need to look for it).

Execution of the script is simple, and instructions are included in the source.

Download here.


Written by leonward

June 6, 2008 at 6:07 pm

Posted in Security

Tagged with ,