Week of OSSEC Day 6: Developing a Tuning Strategy

All IDS systems need to be tuned and OSSEC is no exception. An untuned IDS quickly falls into dissaray, not able to provide full value to the security analyst. As humans, when we get bombarded with too information information, our brain goes into selective tuning mode and attempts to filter out anything which might be irrelevant. See something too many times and your brain does the tuning for you.

When dealing with an IDS, this is not good. We want to put some logical analysis into the events we are seeing so we can align them with our sense of risk. Tuning is absolutely critical to a successful IDS deployment.

OSSEC can be chatty when first installed. The OSSEC developers have to make an educated guess about what events you might want to see. But no one environment is the same. Tuning makes OSSEC relevant for you.

The OSSEC documentation directs you to place your custom rules in rules/local_rules.xml. This tells you the technical “how” of tuning, but doesn’t say anything about the “how” of the tuning strategy–that is, what is the best way to tune OSSEC?

Here are some tips to make tuning work for you. They are designed with larger installations in mind, so adjust accordingly:

  1. Start with high severity events. By default, OSSEC will alert you to anything that is level 7 or higher. This is fully configurable. By starting at, say, level 12, you can be alerted to the highest severity events at the expense of missing other potentially important events. Start at level 12, then once the alerts are manageable, gradually lower the severity to level 7.
  2. Roll out to a few servers at a time. If monitoring logs on a central syslog server, select only a few logs at a time. Be particularly aware of domain controllers where thousands of events can occur per second. After you have tuned down the few servers or logs you have deployed, select a few more. Wash, rinse, repeat
  3. Include a subset of rules. By default, OSSEC comes out of the box ready to monitor dozens of applications with hundreds of rules. As always, OSSEC is configurable. Simply comment out most of the rules files in etc/ossec.conf and enable them as you tune down the alerts.
  4. Tune down, then up. Many people stop tuning once they get to the point where OSSEC alerts are manageable. But what else is OSSEC detecting that it isn’t alerting you on? Remember, OSSEC may not think it’s important enough to alert you on, however that may not align with your tolerance for risk
  5. Add new applications and rules. OSSEC is extensible and the custom application your company is using most likely can be monitored. As long as the output is in ASCII text, OSSEC can monitor those logs. Similarly, OSSEC may not have all of the rules out-of-the-box that you think it should have. It pays to manually inspect your logs every so often for interesting log entries that rules can be created from.

Again, tuning is absolutely critical to a successful OSSEC deployment. It’s not unheard of for this process to take several months in a medium-to-large environment. Tuning is an ongoing process and you will develop a feel for it over time. And as always, do what works best for you.

Tagged with:
3 comments on “Week of OSSEC Day 6: Developing a Tuning Strategy
  1. Eric Beaudry says:


    I setup some email_alerts in the ossec.conf file however some times when I receive email alerts, I get some alerts that I did not put in the conf file email_alert.

    Do you have any idea how to fix my problem?

    Thank you,


  2. Steve says:

    Er, I have the same issue even now. In my config (http://pastebin.com/kTXjqkHV) it says level 7.

Leave a Reply

Your email address will not be published. Required fields are marked *