Wazuh Alert Tuning: A Practical Guide to Reducing False Positives

Out of the box Wazuh ships 4,000+ rules. On day one, expect 70% of alerts to be noise. Tuning is not a one-time project, it is a weekly loop. Here is the loop our SOC runs across every customer environment.

1. Baseline before you touch anything

Run the new Wazuh deployment for 7 full days untouched. Export top-50 rule IDs by alert count from the dashboard. These are your tuning candidates.

Dashboard --> Discover --> wazuh-alerts-* --> aggregate by rule.id, sort desc

2. Classify every noisy rule

• True positive, attack signal. Keep, maybe raise level.
• False positive (always noise), suppress or write exception.
• Context-dependent, benign on some assets, malicious on others. Use rule overrides scoped by agent group.

3. Override, do not edit built-in rules

Never edit files under /var/ossec/ruleset/rules/. They get overwritten on upgrade. Always add overrides to /var/ossec/etc/rules/local_rules.xml using the same rule id with overwrite="yes".

<rule id="5710" level="3" overwrite="yes">
  <if_sid>5710</if_sid>
  <user>backup_svc</user>
  <description>SSH login (backup service account, expected)</description>
</rule>

4. Use rule levels intentionally

Levels 0-3 are informational, 4-9 are warnings, 10+ are real alerts that should page. Lower noisy rules to level 3 instead of disabling, you still get the data, you just stop the pager.

5. Scope exceptions with agent groups

A SQL injection alert on a dev box is noise. On a prod web server it is a P1. Use <if_group> and agent groups so the same rule fires differently per asset class.

6. Test every rule change with wazuh-logtest

sudo /var/ossec/bin/wazuh-logtest

Paste a representative log line. Confirm the matched rule + level are what you expect before you restart the manager.

7. Measure signal-to-noise weekly

Track two numbers each week: total alerts at level >= 10, and how many became real incidents. A healthy SOC runs at 70%+ true-positive rate on high-level alerts. If you are below 50%, your tuning loop is broken.

Common pitfalls

• Disabling rules with <disabled_rule> instead of overriding, you lose audit trail of why.
• Editing rules directly in /ruleset/, gone after upgrade.
• Tuning by deleting, you can never get the data back. Lower the level instead.