Detection rules decay like software — treat them that way
SOCs measure alert volume and response time while their detection logic silently rots. Rule health — coverage, breakage, drift — is the metric that decides whether you see the intrusion at all.
Every security operations center can tell you how many alerts it closed last month and how fast. Almost none can tell you what fraction of their detection rules still work. Not “are enabled” — work: parse the fields they expect, receive the log sources they assume, and fire on the behavior they were written to catch. In the estates we assess, the honest answer is unsettling, and it is unsettling for a structural reason: detection content is software, running against an environment that changes constantly, maintained with none of the discipline we apply to software.
How rules die
Rules rarely die dramatically. A log source migrates and a field gets renamed; the rule keys on the old name and silently matches nothing. An upgrade changes an event’s format; the parser degrades; the rule starves. A noisy detection gets a “temporary” suppression during an incident that becomes permanent by forgetting. Licensing pressure drops a data source the coverage map still claims. The SIEM dashboard shows green — queries execute, no errors — while the estate’s actual detection surface shrinks month by month.
The cruel property of this failure mode is its silence. A broken preventive control often announces itself; a broken detective control produces exactly what a healthy, quiet one does: nothing. You discover the difference during an incident, or during the post-incident review, which is the most expensive test environment in the industry.
Coverage claims deserve evidence
The same discipline gap shows up one level up, in coverage. Most programs can produce a MITRE ATT&CK heat map; far fewer can say when each claimed detection last fired on a real or simulated event, or which techniques are covered by a single fragile rule keyed to a single log source. Coverage that has never been exercised is a hypothesis, not a control.
The fix is the software-engineering loop, applied to detection: version control for rules; test cases — recorded or synthesized events that must trigger each rule — run continuously, so a schema change breaks a build instead of a breach; telemetry-dependency mapping, so when a log source changes, you know which detections it starves; and lifecycle metrics that treat a rule that has neither fired nor been tested in six months as technical debt to be triaged, not inventory to be counted.
This conviction is not abstract for us: it is why our group built ThreatLens, a platform devoted to detection-rule health across Splunk and Sentinel estates. But the practice matters more than any product — a team with version control, rule tests, and a monthly breakage review is ahead of most of the industry with or without tooling.
The metric that changes behavior
If you adopt one number, adopt detection integrity: the percentage of your rule base with evidence of function — a test pass or a true positive — within a defined window. Reported beside alert volume, it reframes the SOC conversation from “how busy are we” to “how much of what we claim to see can we actually see.” Boards understand it instantly, which is precisely why it is uncomfortable.
What to do about it
Run a breakage audit this quarter: for your fifty highest-severity rules, verify end to end that the log source flows, the fields parse, and the rule fires on a simulated event. Expect surprises; budget remediation time in advance. Then wire the verification into routine — every telemetry change reviewed against dependent detections, every rule shipped with its test. Your detection estate is a codebase. It has been running without CI for years.