Talk to anyone who knows anything about running an intrusion detection system (IDS), and he will tell you one of the most important processes during the initial deployment is tuning. It's also one of the important operational tasks that go on as new rules are released to make sure they are relevant to the environment you're tasked to protect.I bookmarked two blog entries last month because they had different, yet valid and interesting approaches to IDS tuning. The first approach is very utilitarian. You know you've patched everything, you know which operating systems and applications are being used, and you care only about signatures that will reveal anomalous events indicative of an attack or compromise.

The two examples used in that blog's approach is too many events of a particular class from certain machines, like excessive 404 return messages from a Web server or use of an IP space that's not in use on your network. I'd also include hosts using external DNS servers and Windows command shells between systems.

The second approach applies the "Getting Things Done" methodology to IDS rule selection. It breaks down to disabling all rules, slowing enabling categories of rules, and determining whether the rules being triggered need action done as result. If they do require action, then complete the action and move on to the next rule. If you don't need to do anything with it because it's part of an allowed activity, then get rid of it.

I like both approaches and I could see how the second one would eventually feed into a configuration much like the first one. The first approach requires you really know and understand your environment, and that you have other security mechanisms in place to keep systems patched and secure. The second is better for a less mature environment where you're getting to know what's out on your network -- maybe IT is a bit decentralized and multiple groups are doing their own thing (like in many academic institutions).

The bottom line is if you're using rules that are relevant to your environment, then your IDS will run leaner and faster. And when something fires, you know you need to look into it immediately. Sounds easy, right? It is ... it just takes a lot of that elusive thing we call time, so don't expect to start this process and wrap it up in a day or two.

John H. Sawyer is a senior security engineer on the IT Security Team at the University of Florida. The views and opinions expressed in this blog are his own and do not represent the views and opinions of the UF IT Security Team or the University of Florida. When John's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading.