Every SIEM rule base tells a story, just not always a flattering one. Rules get added during onboarding, after an incident, ahead of an audit, or because a vendor’s default content pack shipped with them. Almost nobody goes back and asks whether a rule written three years ago, for an environment that has since changed twice, is still earning its place.
The result is predictable. A rule base grows for years and is rarely pruned. Detection engineering teams end up managing accumulated history rather than current risk, and alert fatigue is often less a volume problem than a tuning problem wearing a volume problem’s clothes.
What drift actually looks like
Noisy rules that fire constantly and mean nothing. A rule tuned to an old baseline fires on normal activity that changed years ago. Analysts learn to dismiss it on sight, which trains exactly the instinct a SOC can’t afford.
Silent rules nobody remembers. A rule that hasn’t fired in a year might mean the threat it targets never materialized, or it might mean the rule is broken, disabled, or no longer matched to how the relevant log source reports data. Those are very different situations that look identical on a dashboard that only shows rule count.
Duplicate coverage. Multiple rules covering the same technique, often written at different times by different people, inflate alert volume without adding detection value.
Real gaps that are easy to miss. A rule base described by “number of rules” says nothing about which MITRE ATT&CK tactics are actually covered. Teams can have thousands of rules and still have no detection logic for techniques an attacker would realistically use against them.
Why this is hard to fix with good intentions alone
Detection engineers already know tuning matters. The problem is capacity, not awareness. Auditing a rule base of any real size by hand, rule by rule, against what each one has actually produced, competes directly with incident response, new detection development, and everything else on a security team’s plate. It rarely wins that competition, which is why rule debt accumulates for years at a time.
Annual reviews, where they happen at all, hit the same wall as annual penetration testing: they describe the rule base as it was during the review window, not as it exists the following month after the next onboarding wave or infrastructure change.
What a real audit actually needs to answer
A useful rule audit goes beyond “is this rule enabled.” It needs to answer, per rule:
- How often does it fire, and what happened to those alerts? Were they closed as false positives, escalated, or auto-resolved?
- Is the underlying log source still active and correctly mapped? A rule can be perfectly written and still useless if its data source stopped reporting the way the rule expects.
- What MITRE ATT&CK technique does it map to, and is that technique actually covered elsewhere if this rule is retired?
- Does its outcome history justify its presence? A rule that only ever produces confirmed false positives is a maintenance cost with no offsetting benefit.
Static rule counts and dashboard tiles don’t answer any of this. It requires cross-referencing each rule against what it has actually produced over time, which is exactly the kind of exhaustive, pattern-matching work automation is well suited to.
Coverage, not just count
The most useful output of a real audit isn’t a list of rules to delete. It’s a picture of coverage across the MITRE ATT&CK framework: which tactics have strong, validated detection logic, which have only weak or redundant coverage, and which have none at all. That last category is usually the most valuable finding in the entire exercise, because a gap nobody can see is a gap nobody can fix.
This connects directly to exposure management. A validated exploit path with no detection coverage behind it is a different risk than one that would trigger an immediate, well-tuned alert. For more on how reachability and coverage fit into a broader exposure program, see our guide to continuous threat exposure management.
Making tuning continuous instead of occasional
The fix for rule drift isn’t a bigger annual project. It’s treating detection coverage as something that gets monitored the same way uptime or alert volume does: continuously, automatically, and visibly.
- Track outcomes per rule, not just fire counts, so a rule’s true value shows up in how its alerts were actually resolved.
- Map every rule to ATT&CK so coverage and redundancy are visible at the tactic level, not just the rule level.
- Flag silent rules for review, distinguishing “nothing to detect” from “broken.”
- Revisit after every meaningful environment change, not on a fixed calendar that has nothing to do with when the environment actually changed.
This is also connected to the alert fatigue problem directly. A rule base with less noise and better-mapped coverage is a smaller part of why analysts are drowning in the first place. For the fuller picture of that problem, see SOC Alert Fatigue.
Where Rainier’s Detection Lens fits
Rainier’s Detection Lens module automates exactly this audit. It snapshots a client’s SIEM rule base, tested in one deployment against roughly 3,000 rules and 1,400 building blocks, and cross-references every rule against what Rainier’s own analysis concluded about the alerts that rule actually produced. The output shows which rules are earning their place, which are generating noise without signal, and where coverage is genuinely missing, mapped against MITRE ATT&CK tactics as a live heatmap rather than a once-a-year slide. For more on how this fits into the platform, see AI Case Investigation and Detection Lens, and for the broader Rainier platform it runs inside.
Curious what your own rule base audit would show? Talk to Network Intelligence.
