Why a SOC cannot read ten thousand alerts

A team receiving ten thousand alerts a day usually reaches one of two conclusions: we need more people, or we need automation. Neither is right.

The real question is how many of those ten thousand are real events. If the answer is one in ten, adding people solves nothing — it puts more people in front of the noise.

Precision is a property of a rule, not of an analyst. And until it is measured, it never improves.

Detection has two errors. A false positive is an alert where no attack occurred. A miss is an attack that produced no alert.

They are not equal. A miss costs more and is invisible. A false positive is cheap and is visible every day — which is exactly why it breaks the process.

The real cost of false positives lies elsewhere: they consume the analyst’s trust. A rule that came up empty a hundred times will be ignored on the hundred-and-first, when it fires for real.

A practical rule: every detection rule is managed as a product. It has an author, a version, and two numbers — how often it fired and how often it was real.

To collect the second number, an analyst has to press one button when closing an alert: real or false. That single action carries the whole process.

At the end of the month a list is produced: which rules generate most of the noise. Typically ten rules produce more than half of all false positives.

The easiest fix is to switch the rule off, and it is usually the wrong one. The right path is to narrow it: on which system, at which hours, for which account is it genuinely meaningful?

The second technique is aggregation. If one attack produces dozens of alerts, they belong in one incident. An analyst should not read the same thing ten times.

The third is tiering. A weak signal is not an alert, it is context. On its own it goes nowhere; combined with another signal, the two together raise one.

Adding rules is easy and looks good: "we have 1,200 detection rules" reads well in a report.

But a working rule needs someone to maintain it: to fix it when a source format changes, to extend it when a system is added, to narrow it when noise grows.

So the right goal is fewer rules, each measured and each owned. An unmaintained rule loses trust and is eventually switched off — at exactly the wrong moment.

There are two primary measures: time from the start of an event to detection, and time from detection to response.

The first measures detection quality, the second measures process quality. They improve separately, and adding them into one number is meaningless.

A third measure is rarer and useful: how long an alert waits in the queue. If it is growing, volume has exceeded the team’s capacity — which is the signal to revisit the rules.

Automation does not reduce noise. It accelerates the check: gathering context on an address, showing an account’s recent sign-ins, asking an external source about a file.

That is most of the analyst’s manual work. Automating it cuts the time per alert several times over.

But if a rule’s precision is one in ten, automation only gives you faster noise. The order is fixed: precision first, speed second.

The first step is to start measuring. Require a "real or false" mark whenever an alert is closed. Two weeks of that produces your first honest list.

The second step is to take the ten noisiest rules and make one decision about each: narrow it, aggregate it, demote it to context, or retire it.

The third step is a limit: how many alerts per analyst per shift is acceptable. In our practice up to twenty are read; above a hundred they are not read at all, only closed.