...continued

One option is to forget entirely about tuning your IDS and leave it running with its full set of signatures. In other words, "give in to the noise" and just let the sensors generate as much data as they want, then forward it to a Security Information Management (SIM) or Security Event Management (SEM) tool and perform the alert filtering there. There are some huge potential advantages to this approach, as well as some possible disadvantages.

The main advantage to the "tune it in the back-end" approach is that it effectively centralizes your IDS alert tuning into a single location. If your organization's policy is consistent across the network (that may be a big "if"), then it's pretty likely that an alert that is significant on one subnet is going to be significant if it's on another - and vice versa. So if you get an alert and decide it's unimportant enterprise-wide, you can filter it out in the SIM tool. Conversely, if the alert is important enough, you can raise its priority in the SIM tool and you've just tuned your alerts enterprise-wide with a single action.

More importantly, you can now instantly "adopt" a new sensor without having to do anything to configure it beyond a default install. Imagine an IDS deployment consisting of a mix of sensor types (some commercial, some open source, some firewall logs). Tuning them all at the back-end would allow you to add any new device of the supported types without any additional tuning. This could be a significant time-saver for organizations doing large deployments or those that might come under audit requirements. Suppose that one day you're required to audit all firewall logs (you know, those things you currently throw away and don't look at?). If you've pre-tuned filtering for a single firewall in your SIM, then that filtering will most likely apply to the other firewalls as well.

The disadvantage of this approach is also noteworthy. You really need to understand the data load-out that your firewalls and IDS are likely to send to your SEM. To do this, you basically need to measure alerts/sec generated by the IDS with it in a tuned or untuned configuration and then attempt to discover if the difference is going to be too great. For example, if your SEM can handle 300 alerts/sec and your IDS generates 500 alerts/sec untuned, then you're potentially going to throw more data at it than it can handle and have to fall back to tuning your IDS. You also need to make sure your SEM can handle the load of normal traffic (firewall and system logs) before you throw your untuned IDS logs at it. At the Institute forums, we've been hearing a mixed bag of reports about how the various SIM products fare under high loads. But as long as your SIM can handle the load and you are not congesting any network links with alert traffic, the back-end tuning approach will work fine.

Network congestion is another problem that a lot of organizations worry about when dealing with logs. At one of the forums we had a member who was really worried about the tens of thousands of alerts per day that his IDS generated and whether they'd bog down his gigabit switch. He probably should find something else to worry about! It's important to understand your traffic patterns and load-outs, but don't be scared of getting your money's worth out of your network.

So, consider back-end tuning instead of front-end tuning. I talked with one practitioner who was experimenting with it and getting terrific results. They had tuned a back-end system for their local SNORT configuration and were able to tell everyone who wanted to, "Go ahead and set up SNORT. Don't bother tuning it -- just send all the logs to us!" That represents a lot of saved time. Your mileage may vary depending on how your network is configured, how centralized your management is, and so on. But as long as your SIM passes the stress test, it may be the solution for you, too.

Marcus J. Ranum is a member of the Institute faculty, a scientist and a well-known security technology visionary. Reach him at mranum@ianetsec.com.