Every vendor pitch in this industry ends the same way: “and it’ll give you even more visibility.” More rules. More sensors. More alerts flowing into the queue. It sounds like progress. In most SOCs, it’s the opposite.
Here’s the take that gets pushback every time we say it out loud: most SOCs don’t have a detection problem. They have a signal-to-noise problem, and buying more detection makes it worse, not better.
The Math Nobody Wants to Do
Take a mid-sized SOC running 300-500 alerts a day, which is a conservative, common number. If each alert takes even 3-5 minutes to triage properly — and most take longer — that’s 15-40 hours of analyst time per day just deciding what to ignore.
Now add a new detection rule. Then another. Each one feels like a win in a sprint review. Each one also adds more volume to a queue that was already unsustainable — and the analyst has the exact same number of hours in a shift they had before.
At some point, “we have more visibility now” stops being true. What you actually have is more noise, the same headcount, and a team that’s learned to move faster past every alert — including the one that matters.
Why This Keeps Happening
1. Detection engineering gets rewarded for coverage, not precision. A new rule shipping against a fresh MITRE ATT&CK technique looks great on a slide. A rule that got tuned down or deleted because it wasn’t actionable does not.
2. “Better safe than sorry” sounds responsible. Nobody wants to be the person who turned off the rule that would have caught the breach. So low-fidelity rules survive indefinitely, because removing them feels riskier than keeping them — even when keeping them is the actual risk.
3. Alert fatigue is invisible until it isn’t. A SOC drowning in noise looks functional right up until the day it misses something, and by then it reads as an individual analyst’s mistake instead of what it actually was: a systemic failure that had been building for months.
What “Fewer, Better” Actually Looks Like
This isn’t an argument for less visibility. It’s an argument for ruthless curation of the visibility you already have.
- Kill rules with a false-positive rate above a set threshold (we use 90%+ over 30 days as an automatic review trigger) unless there’s a specific, documented reason to keep them.
- Tier alerts by confidence, not just severity. A “critical” alert that fires constantly and is wrong most of the time should be worth less analyst attention than a “medium” alert with a 95% true-positive rate.
- Correlate before you alert, not after. Push more of the noise reduction into detection engineering and SOAR playbooks, so a human only sees the alert once it’s already been enriched and correlated against related events.
- Measure “alerts closed with no action” as a KPI, not just “alerts triaged.” A high number here isn’t proof your team is thorough — it’s a sign the rule generating them needs to be retired or rewritten.
- Give analysts explicit permission to delete rules. If the person closest to the noise doesn’t have the authority to remove a bad rule, the noise never actually gets fixed — it just gets tolerated.
The Uncomfortable Part
Doing this well means accepting that your SOC will, on paper, have “less coverage” than it did before. Fewer rules. Fewer sensors screaming for attention. To anyone measuring security maturity by rule count, that looks like a step backward.
It isn’t. A SOC that triages 50 high-confidence alerts a day thoroughly will catch more real incidents than one that triages 500 alerts a day exhausted, cynical, and two hours behind by lunch.
The goal was never “catch everything.” It was always “catch the thing that matters, in time to act on it.” Every alert you add that doesn’t move you toward that goal is actively working against it.
The Next Step
If you want a starting point, don’t add anything this week. Pull your last 30 days of alert data and calculate the true-positive rate per rule. Whatever’s sitting below 10% is your first candidate for retirement — not because it’s never once been right, but because the analyst hours it costs are no longer worth what it occasionally catches.
Want our alert-tuning framework? Download the free Alert Tuning Worksheet — the exact scoring model we use to decide which rules to keep, tune, or kill. [Download it here →]
Related reading: 5 Log Sources That Would Have Stopped the Attack (But Weren’t Monitored) — because the fix for alert fatigue isn’t just fewer alerts, it’s better data feeding the ones you keep.
Leave a Reply