Skip to main content

Now that I have these IDS events, now what?

In my full-time job I work for Sourcefire, as a Sourcefire and Snort Professional Services Consultant.  I deal with a different customer every week (sometimes every day), and with each customer comes a separate set of IDS events.  Customers will often tell me "this network is unlike any you've ever seen before", and for the most part, they are right.  While all networks consist of servers, desktops, switches, routers, firewalls, antivirus, and even IDSes, all networks are essentially the same in that respect.  However, each of them pose their own unique set up and vulnerability attack-landscape.  Each network is unique in this way, it doesn't matter if you have 300,000 users on your network or 10.  All that does is make your life as a security person more difficult, this is essentially a number.  That number may increase lots of things, people hired to handle them, number of sensors needed, the amount of bandwidth needed, etc.

So, in dealing with the hundreds, perhaps hundreds of thousands, perhaps millions of IDS events that I see during the day on different networks, how do I deal with them?  How can I get into a customer engagement and turn 400,000 events a day into 100?   How do I help my customers deal with this?

My answer is: One at a time.

How do I do it?  Well, I take the same fundamentals as I have applied to Getting Things Done and Inbox Zero (mostly the latter) to IDS events.  In other words, for each IDS or IPS event, there is at least one (maybe multiple) outcome(s) to that event.  While yes, that may seem redundant, (and it is) my point in saying that is that there should always be an outcome to any IDS event.  It shouldn't just sit.  You shouldn't just be "moving events to archive".

You can kind of think this as a flow chart.

First -> Look at the event, let's use this event as an example:

POLICY Adobe FLV file transfer

Analyze it in context, what does this event mean?  It means someone is watching a flash video on the internet.  Okay, big deal right?  Is that allowed by policy?  Look at the packet data, is it from youtube?  Is watching YouTube from the corporate network allowed?  Perhaps if you are on a Government network, this isn't allowed, okay, so what next?  Do I need to look at the flows around it recorded by Netflow or RNA?  Do I need to look at my SIEM tool?

Second, Now comes where you ask "what relevancy does this have to my network?"  If it's a Sourcefire protected network (read: not Snort) then you might have RNA to help you perform this function.  How is the impact rating on the alert?  Is it high?  Is the end host vulnerable to this "exploit"?  The impact rating for the above event is probably pretty high, since every browser on every OS (for the most part) can watch a flash video.  How old is the rule or alert?  Does it cover a CVE that was patched in 2002?

Now that we know what the event is, and what relevancy it has to our network, what are we going to do about it?  Well, I view this has having about four possible outcomes.  Of course, this is related to Snort, so your IPS may vary.  But all IPSes get better with tuning, so...

  1. If you are in IPS mode, do you want to block it or not?

  2. Threshold or Surpress?

  3. Edit the rule manually?

  4. Shut the rule off?

  5. Does it provide relevance to other rules?

  6. DO something about the alert.

1.  Set the rule to drop.

This only works if you are in IPS mode, should you change the rule to drop?  Do you want the traffic to go into the big bit bucket in the sky?  Prevent that FLV file from being downloaded?  Prevent that PDF from being downloaded, prevent that newest browser exploit?  If you are in IPS mode, this is your second question after you analyze the event.

2. Threshold or Suppress?

Thresholding in Snort essentially means you still want the rule to alert, but not as much.  Or not until a certain threshold is reached (or both).  Suppressing means you want to turn off alerting to a certain IP or CIDR block.  Say for instance an SNMP alert going to your HP OpenView server.  Legit traffic, so tune it out.

3. Edit the rule.

Probably something you want to stay away from as much as possible, unless you editing your own rules.  But it's always an option to edit the rule manually to reduce false positives.

4. Turn the rule off.

Is the rule out of date?  Do none of the above apply?  Has it no relevance to your network?  For instance, using our above example, if watching flash videos is allowed on the network, and you don't want to track to see if people are doing that kind of thing, then shut the rule off.  If you aren't going to use the final step in this process (DO SOMETHING) then do you need the rule?

5.  Is the rule providing you contextually aware information?

Some rules will make no sense on their own, but they may provide a contextual awareness to other rules.  For instance, if there was a rule to watch for vulnerabilities within a certain flash video file format to exploit older versions of the flash player, that rule coupled with the above example, may provide better contextually aware alerts.  You know the video was bad, but now you can refer back to the above example and perhaps see where the alert came from.  Kind of a bad example, because you could do it either way, but hopefully you grasp my point.


This requires you to go mitigate the problem.  Whether that be to "file a ticket" for your helpdesk to clean off spyware, clean up a botnet, perhaps you'll need to pull forensics on the host machine, perhaps you'll need to pull web proxy logs to get better awareness.  But this is the step where you actually have to use the alerts generated by your IDS to do your job.  Find the bad guy, eradicate the badness from the network, and move onto the next alert.  After all, that's the point of having an IDS or IPS right?

Following these simple steps should allow you to have a greater awareness of the alerts on the network, and perhaps actually do something about them.  Getting an IDS alert and then "moving it to archive" or "marking it as reviewed" is doing nothing.  Following the above ACTION steps should give you a more streamlined IDS or IPS, and then only cause your system to alerts when you need to conduct step 6, above.  DO SOMETHING.


Popular posts from this blog

Offset, Depth, Distance, and Within

Without going off the deep-end here and discussing every single Snort rule keyword, I just wanted to touch on a few modifiers that people sometimes misunderstand.  They aren't difficult, and hopefully after this explanation and a few examples, I can clear some of the air around these five modifiers.

The five modifiers that I am talking about are
OffsetDepthDistanceWithinnocaseThese five modifiers are not keywords of themselves, but rather they apply as modifiers to another keyword.  That keyword is "content". The content keyword is one of the easiest pieces of the Snort rules language as all it does is look for a particular string.  So for instance if I wanted to look for the word "joel" within a packet.  A simple:
content:"joel";Would allow me to do that.  The interesting part comes into play when you want to specify where inside of a particular packet you want the string "joel" to be looked for.  If you are running just a plain content ma…

Writing Snort Rules Correctly

Let me start off by saying I'm not bashing the writer of this article, and I'm trying not to be super critical.  I don't want to discourage this person from writing articles about Snort rules.  It's great when people in the Snort community step up and explain some simple things out there.  There are mistakes, it comes with the territory.  If you choose to be one of the people that tries to write Snort rules, you also choose to be someone who wants to learn how to do it better.  That's why I write this blog post, not to bash the writer, but to teach.

I noticed this post today over at the "Tao of Signature Writing" blog, and to be honest I glanced over most of it figuring it was a rehash of things I've already read or things that have already been written from countless people about "Here's how you write Snort rules!".  I scrolled down quickly skimming, not reading at all really, and noticed this part:
Now, let us look at the second questio…

Safari 5.1.4 now available

Safari 5.1.4 now available, fixes issues and improves performance | TUAW - The Unofficial Apple Weblog:

Improve JavaScript performanceImprove responsiveness when typing into the search field after changing network configurations or with an intermittent network connectionAddress an issue that could cause webpages to flash white when switching between Safari windowsAddress issues that prevented printing U.S. Postal Service shipping labels and embedded PDFsPreserve links in PDFs saved from webpagesFix an issue that could make Flash content appear incomplete after using gesture zoomingFix an issue that could cause the screen to dim while watching HTML5 videoImprove stability, compatibility and startup time when using extensionsAllow cookies set during regular browsing to be available after using Private BrowsingFix an issue that could cause some data to be left behind after pressing the "Remove All Website Data" button