You also have to worry about whether the system can handle the load you're placing on it. I've been handed snort sensors that were dropping 60% of the packets that crossed the wire, and the administrator wasn't sure why the IDS didn't seem to be working.
Luckily I haven't run into many problems with tuning OSSEC. The biggest task I've had is decoding "rule 1002" alerts. Rule 1002 reads as follows (Oct. 6, 2010):
<rule id="1002" level="2">The $BAD_WORDS variable is:
<description>Unknown problem somewhere in the system.</description>
<var name="BAD_WORDS">core_dumped|failure|error|attack|bad |illegal |denied|refused|unauthorized|fatal|failed|Segmentation Fault|Corrupted</var>Rule 1002 basically looks for one of the bad words in all syslog messages that do not have a better match. If one of those words is found an alert is sent. This rule in particular has started a number of discussions on the user mailing list. There have been numerous instances where someone did not seem to understand the importance of Rule 1002 and wanted to ignore all Rule 1002 alerts.
Rule 1002 can catch a lot of log messages that are worth looking at, and probably shouldn't be removed or ignored. Instead use that opportunity to create a new rule. We understand that rules and decoders for internal applications probably couldn't (or shouldn't) be released to the public, but the OSSEC project welcomes new log samples and rules/decoders from the user community. Posting them to the user or dev mailing lists is always appreciated. The userbase can also provide feedback, or help debug if you have issues.
I'll be going through the steps to create and debug decoders and rules in the future. Until then here's a blog post that details writing decoders and rules. That blog post has also been incorporated into the OSSEC documentation here. Hopefully I can add something meaningful to it.