Random IDS musings

I've seen alot of traffic lately on the snort-users list about how to clean out a database periodically and it got me thinking..

Basically the basis of the story is that people want to clean out the events from their DB on a periodic basis, 1 month, 2 months, whatever. Basically I look at it like this then, why are there events in your database that are that old?

If you have events in your IDS DB, you should look at them. That's the reason you have an IDS/IPS. To review the events (and in the case of IPS, prevent the attacks) and make sure the evil hax0rs are not getting you. If you have events in your current DB that are a month old, that tells me either one of two things:
A) You don't care about your alerts
B) You have too many alerts, and you don't have a system.

So let me help you get a system.

Make an archive DB (for the people using BASE, then this is pretty simple), now, you have two db's. One current, and one archive.

1) Events come in from Snort via barnyard into your current DB.
2) You review these events. Any events that you skip over, take note of them. Do you need this alert? Is applicable to your network? Do you KNOW if it's applicable to your network?
3) Any events that you take a look at, did it actually affect your network or was it someone banging on the door (script kiddie)? If it was a skript kiddie, what are you going to do about it? Block them at your firewall? Send their ISP a cease and desist letter? If you are going to do nothing then DELETE THE ALERT. Why keep it? You aren't going to do anything about it, so who cares?
4) Now, say when you are reviewing alerts, you come across something you need to investigate. Good. Take note of it and come back later. Leave it in your current db, get through the rest of your alerts.
5) Through your alerts? Good. Come back to the ones you still have in your current db. Do you need to take further action on these guys? Yes? Investigation time? Okay, well then you need to save the alert, so move it to your archive db. When you are done with your investigation in your archive db, then delete the alert.

Basically my point here is, don't keep alerts for no reason. Now, let's go back to #2.
For instance, if you are running web-php rules, but aren't running any webservers that run PHP on them, do you need the rules? Don't subscribe to the philosophy of "if the IDS isn't alerting, then how do I know it's working?". If you want to make sure your IDS is working, then write some kind of script to email you the statistics or something from the Snort process to make sure it's analyzing traffic. If you ALWAYS skip over a particular event, then WHY are you making your IDS run the rule? Shut it off!

Let's take a look at a network. Small one. One bsd box, 2 osx boxes, 2 windows boxes, and 1 linux box. Now, in your network these may be thousands of machines on tons of subnets. The network size doesn't matter, you can take the same philosophy.

Your frag3 and your stream5 preprocessors need to be tuned to the OSes. Done? k.

Now, take your network and look at it. What services are you running, what versions of those services? What OSes? What vulnerabilities are present on your network? Now, figure those things out and turn off the rules in Snort you don't need.

Now, this is where you say to me that this is a pain in the butt, and Snort has tens of thousands of rules, with more coming out each month, blah blah, etc. etc.

Well, that's where Sourcefire comes in. We have things like RNA, we have things like Adaptive IPS/IDS that will do all that FOR YOU, leaving you with the relevant alerts, things you HAVE to look at! But rather than this turning into a sales pitch, I am simply trying to get you to think about how to work with your data. Do you need to keep all that data? or can you fine tune it?