Practitioner notes. Grounded in SY0-701 Domain 4 study material and an in-progress Wazuh home SIEM lab. No vendor affiliation; no production telemetry reproduced here.
Ask a SOC how good its detection is and you will usually get a rule count. Ask the analysts on shift and you will get a different number: how many alerts they closed today without reading them properly. Those two numbers are connected, and the second one is the one that decides whether a real intrusion gets caught. Most SOCs do not have a detection problem — they have a signal-to-noise problem, and tuning is the only thing that fixes it.
The arithmetic that creates alert fatigue
The core issue is base rates. Suppose a rule is 99% accurate and fires on an event class where genuine malice is 1 in 10,000 occurrences. Run 100,000 events through it and you get roughly 10 true alerts buried in about 1,000 false ones. The rule is "99% accurate" and 99% of what it produces is noise. No analyst triages that honestly for long — they habituate, and habituation is precisely the failure mode: the classification you care about is not the false positive, it is the false negative an exhausted analyst creates by skimming.
The four outcomes are worth keeping in front of you, because the dangerous quadrant is the quiet one:
| Outcome | Alert? | Real event? | Cost |
|---|---|---|---|
| True positive | Yes | Yes | The job working as intended |
| False positive | Yes | No | Analyst time, habituation |
| True negative | No | No | None — steady state |
| False negative | No | Yes | A missed attack — and FP load manufactures these |
That last cell is the whole argument. Untuned rules do not just waste time; they convert true positives into effective false negatives by burying them.
Why "more rules" makes it worse
Rule count is a vanity metric. Every rule you enable ships with a false-positive rate, and those rates are additive across the queue while analyst attention is fixed. Importing a 500-rule community pack into a SIEM that was coping yesterday is how you get a queue that nobody trusts tomorrow. The uncomfortable discipline is the opposite one: a detection that nobody has reviewed, that converts to an incident 0% of the time, and that fires forty times a day is not coverage — it is camouflage for the alert that matters. Retire it or fix it.
The tuning loop
Tuning is not a one-off cleanup; it is the operating rhythm of a functioning SOC. The loop is short:
- Validate — confirm what the alert actually reflects before acting. Acting on an unvalidated alert wastes effort and can cause a self-inflicted outage (blocking a VIP's account on a travel-login anomaly is the classic).
- Classify — TP, FP, or benign-true-positive (the event happened, and it is authorised: a pentest, a backup job, an admin doing admin things).
- Adjust — and here order matters. Prefer, in sequence: add context (asset criticality, user role, known-maintenance windows) → narrow scope (this rule should never have applied to the build servers) → raise thresholds (5 failures, not 3) → suppress as a last resort, with an expiry date.
- Measure — did the change move the per-rule numbers, and did detection still fire in the next purple-team or simulated run?
The distinction in step 3 is the one that separates tuning from decay. Suppression hides output; fixing logic improves it. A suppression without an expiry is a detection gap with a clear conscience.
What to measure — per rule, not per SOC
SOC-wide MTTD is a useful executive number and a useless engineering one. The numbers that drive tuning are per-detection:
- False-positive rate per rule — the direct measure of noise contribution.
- Alert-to-incident conversion — of everything this rule fired, how much became a real investigation? Rules near 0% need work or retirement.
- Time-to-triage — if analysts consistently park a rule's alerts, they have already told you what they think of it.
- Detection latency per technique — how long from event to alert, measured by replaying the attack, not by assumption.
That last one only exists if you test detections deliberately: run the technique in a controlled way, confirm the rule fires, record how long it took. This is exactly what I am building a home Wazuh lab around — scenario-by-scenario detection validation with per-scenario time-to-detect tracking — because a rule that has never been exercised against its own technique is a hypothesis, not a detection.
Where SOAR and UEBA actually fit
Two technologies get sold as the cure for fatigue, and both help only after tuning, not instead of it. SOAR automates the repetitive halves of triage — enrichment, reputation lookups, ticket creation, containment playbooks for the high-volume, low-ambiguity alert classes like commodity phishing. Automating an untuned queue just generates noise faster and occasionally automates the self-inflicted outage. UEBA attacks the problem from the other side: instead of static thresholds it baselines per-user and per-entity behaviour, which catches the "valid credentials, wrong behaviour" class that fixed rules are structurally bad at. Its trade-off is the training period and a new flavour of false positive (people change roles, travel, and work odd hours).
The takeaway
Detection engineering is a feedback discipline. The rule you write is the start of its life, not the end: it earns its place in the queue by converting to incidents, it gets context and scope adjustments as the environment changes, and it gets retired when it stops paying rent. A SOC that tunes relentlessly with 80 rules will catch more than one that hoards 800 — because the constraint was never rule coverage. It was analyst attention, and tuning is how you spend that attention on the alerts that are real.