Wazuh False Positive Reduction and Rule Tuning

Why a New Wazuh Deployment Is Noisy

Wazuh ships with more than 5000 default rules covering Windows event logs, Linux syslog, web servers, databases, firewalls and cloud services. Those rules are written to fire across the widest possible range of environments, which means they are deliberately broad. When they meet your specific estate for the first time, perfectly normal behaviour trips alerts that were never tuned for your patch schedules, your service accounts, your vulnerability scanners or your backup windows.

The classic culprits are authentication rules firing on expected service-account churn, web rules flagging your own monitoring probes, FIM alerts on directories that legitimately change every deploy, and integrity rules tripping on automated patch runs. None of these are attacks. They are the cost of a generic ruleset meeting a specific reality.

Left untuned, this noise produces alert fatigue. Analysts start ignoring a category of alert, and the one genuine intrusion buried in that category gets ignored with it. Tuning is therefore not cosmetic housekeeping. It is the single highest-leverage activity for making a SOC detection programme actually work.

The Golden Rule: Tune in local_rules.xml, Never the Stock Files

Wazuh stores its shipped ruleset under /var/ossec/ruleset/rules/. You must never edit those files. Every Wazuh upgrade overwrites them, so any change you make there is silently lost on the next update, and your carefully tuned environment regresses to noisy defaults.

All custom tuning belongs in /var/ossec/etc/rules/local_rules.xml and, where you need to reshape parsing, in /var/ossec/etc/decoders/local_decoder.xml. These files are preserved across upgrades. The Wazuh analysis engine loads local rules after the stock ruleset, so your local rules can override, extend or suppress the defaults.

To override an existing rule you reference it with <rule id="5710" level="0" overwrite="yes">, keeping the same id and supplying your changes. To layer a more specific rule on top, you write a child rule with <if_sid> pointing at the parent. Either way the change is isolated, reversible and upgrade-safe.

Lever One: Rule Level Adjustment

Wazuh alert levels run from 0 to 16. Level 0 means the event is logged but never alerts. Levels 1 to 6 are low severity, 7 to 11 are medium, and 12 and above are high. Your alerting threshold (the <alerts><log_alert_level> in ossec.conf) determines which levels actually generate alerts and forward to the indexer.

The cleanest way to silence an expected-but-noisy rule without deleting detection value is to override it to level 0. The event still flows into the archives for forensic search, but it stops generating an alert. This is preferable to disabling the rule entirely, because you retain the raw record if you ever need to investigate retrospectively.

Conversely, you raise the level of rules that matter more in your environment. A failed login on a public-facing jump host deserves a higher level than the same event on an isolated lab box. Level adjustment lets you encode that context so the alerts that reach analysts are already prioritised by real business risk rather than generic defaults.

Level adjustment also drives downstream routing. Because the level determines whether an event becomes an alert and how it is treated by integrations, you can wire high-level alerts to immediate escalation paths (a page, a TheHive case, a SOAR playbook) while low-level events simply accumulate for trend analysis. Tuning the level is therefore not only about volume control; it is how you map each detection to the right operational response, so that the events demanding human attention are the only ones that ever interrupt an analyst.

Lever Two: Field-Based Exclusions

Blanket-silencing a rule is crude. The precise approach is to suppress only the specific conditions that are false positives while keeping the rule live for everything else. Wazuh lets you match on decoded fields using <field name="..."> with regular expressions, and the negate attribute or a higher-priority override lets you carve out exceptions.

A concrete example: rule 5710 fires on attempted SSH logins for non-existent users. Your internal vulnerability scanner trips it constantly. Rather than killing 5710, you write a child rule with <if_sid>5710</if_sid> that matches <srcip> equal to the scanner's address and sets level 0. Genuine attacker probes from any other source still alert at full severity; only the scanner is excused.

The same pattern handles noisy web rules (exclude your uptime monitor's user-agent), noisy process rules (exclude a known automation account by <dstuser>) and noisy FIM rules (exclude a directory by path). Field-based exclusions are surgical: they remove the specific false positive without blinding you to the broader threat the rule was written to catch.

Lever Three: Allowlists and CDB Lists

When the same set of known-good values recurs across many rules (a list of scanner IPs, a set of admin jump hosts, a roster of service accounts) inline exclusions become unmanageable. Wazuh solves this with Constant Database (CDB) lists: a simple key-value file you reference from rules with <list> and match against using the lookup condition.

You maintain the allowlist in one place, for example etc/lists/known-scanners, compile it with ossec-makelists, and reference it from any rule that needs it. Adding a new approved scanner means editing one file rather than hunting through dozens of inline exclusions. This is the scalable way to manage allowlists across a growing estate.

CDB lists also drive the opposite use case: blocklists of known-bad indicators. The same mechanism that excuses good traffic can elevate or alert on bad traffic, which is how threat-intelligence-driven detection (covered when you integrate MISP) plugs into the rule engine. Allowlists and blocklists are two faces of the same CDB capability.

One operational caution: a CDB list is only as trustworthy as its change control. Because a single entry can silence detection across many rules, an allowlist is an attractive target and an easy place for a well-meaning engineer to over-broaden an exception. Keep the list files in version control alongside the rules, require review for additions, and audit them on the same quarterly cadence as the rest of your tuning. A stale or sloppily-maintained allowlist quietly erodes detection coverage in a way that is hard to notice until an incident exposes it.

Baseline First, Then Operationalise Tuning

The discipline that separates a tuned SOC from a guessing one is baselining. Before you suppress anything, run Wazuh in observation mode for two to four weeks and profile what 'normal' looks like for your environment: which rules fire most, from which sources, at which times. Tuning decisions then rest on evidence rather than hunches, and you avoid the catastrophic mistake of suppressing a rule that was actually catching a slow intrusion.

Operationally, build a feedback loop. Every false positive an analyst closes should carry a tuning note. Once a week, the SOC lead reviews the highest-volume false positives and writes the corresponding local rule. This converts triage effort into permanent noise reduction rather than the same alert being dismissed a thousand times.

Finally, version-control local_rules.xml and local_decoder.xml in Git, record the reason for each change in the commit, and review the full tuning set quarterly. Environments drift: new applications appear, old exclusions become stale, and an exclusion written for a decommissioned scanner can become an attacker's blind spot. Codesecure runs this exact cadence as part of every managed SOC engagement so the ruleset stays both quiet and trustworthy.