Wazuh Rule Tuning & False Positive Reduction

Quietening a noisy rule is easy. Any exclusion you write will reduce volume, and a SOC that has stopped reading its queue will approve almost anything that makes the number smaller. That is how detection dies: not switched off, but tuned into uselessness one defensible change at a time. The discipline that prevents it is a regression set — alerts that were investigated and confirmed as genuine incidents, kept precisely so that any proposed change can be replayed against them. A tuning is not measured by how much noise it removes. It is measured by how much noise it removes AND whether every known-true alert still fires. A change that scores brilliantly on the first and fails the second is worse than doing nothing, because now the SOC believes it is covered. Two failure modes are worth internalising because they look nothing alike. The first is excluding by what traffic LOOKS LIKE rather than by where it comes from: a path that a broken client hammers is also a path an attacker can probe, and an exclusion cannot tell them apart. The second is leaning on a frequency threshold — suppress the single event and keep only the composite that fires on repetition. That reads as elegant and removes the most volume of anything on the table, and it is blind by construction to the careful attacker who sends one request and stops. There is no Wazuh manager in this environment and no wazuh-logtest, deliberately: the work is arithmetic over a body of alerts, not running the engine. Evidence is in /var/log/soc — incident-brief.md, alerts.json, confirmed-incidents.csv, tuning-proposals.md and rules-excerpt.xml. jq is installed.