SRE gave us error budgets: a numeric tolerance for unreliability that converts arguments into arithmetic. Our SOC was drowning in the security equivalent of nines-worship — every detection someone proposed got deployed, because who wants to be the person who said no to the alert that would have caught the breach?
So we gave the SOC a noise budget, and it changed the conversation entirely.
The mechanics
The budget: each analyst shift can absorb 25 alerts of triage load, and the false-positive rate across the detection estate must stay under 40%. Every detection rule carries measured properties — firing rate, true-positive rate, triage minutes — and the sum has to fit inside the budget.
A new detection that wants deployment must fit the budget. If it does not fit, something has to be tuned, aggregated or retired to make room. Detection engineering stopped being an accumulation exercise and became a portfolio decision.
What changed
- Rules earn their keep with data — the quarterly review kills the bottom decile by precision, and nobody argues because the numbers are shared.
- Aggregation became the default — forty per-host alerts became one fleet-level alert with a host list, at no detection loss.
- Analysts trust the queue — when the false-positive rate dropped under 30%, median time-to-acknowledge dropped from 34 minutes to 6.
- New detections come with a fidelity plan — authors state the expected firing rate and the tuning path before deployment, not after the noise complaint.
The uncomfortable part
A noise budget means accepting, in writing, that you will not deploy every possible detection — that some marginal detection value is not worth the analyst attention it costs. That sentence makes security leadership flinch. But the alternative is not "we detect everything"; it is "we alert on everything and detect whatever the exhausted analyst happens to catch". The budget does not create the trade-off. It makes the trade-off visible and deliberate.