Blog Fixed SOC thresholds
Blog · SOC operations
Why fixed SOC thresholds bake in human error
Every SOC runs on numbers someone once chose: five failed logins, twenty requests in five minutes, severity above medium. Those numbers feel objective. In practice they are a snapshot of past judgement, mistakes included, frozen into code.
Where the numbers come from
Thresholds are necessary. A detection rule has to fire at some point, a triage queue has to be sorted by something, and an escalation policy needs a line between "handle it" and "call someone". The question is not whether to have cut-offs but how they were set and whether they still describe the environment they are applied to.
Most cut-offs in a SOC were set in one of three ways: copied from a vendor default, tuned by an engineer to make a noisy rule quiet, or derived from what analysts historically marked as true or false. Each of these carries a hidden assumption. A vendor default assumes your environment looks like an average one. A noise-driven tune assumes that what was annoying was harmless. A label-driven tune assumes the historical labels were right.
How human error gets frozen in
Analysts close large volumes of alerts under time pressure. They develop shortcuts, and most shortcuts are sensible. Some are not. A family of alerts that has been closed as benign a hundred times will be closed the hundred-and-first time, even when that one is real. If the threshold for that family is then tuned to match historical closures, the miss is no longer an occasional human slip: it is now policy, applied automatically, every time.
This is the core problem with learning a fixed number from history. History includes the cases the team got wrong, and the cases nobody looked at closely enough to know. A threshold fitted to those outcomes reproduces them faithfully. It looks well calibrated against the past while staying blind to the attacks that the past also missed.
Fixed numbers also age badly. Environments change: a new application doubles login volume, a migration moves workloads to the cloud, a business unit starts working nights. A cut-off that was reasonable last year can now fire constantly or never. Because nobody owns the number, it rarely gets revisited until it causes an incident or an outage.
Common fixed thresholds and what they assume
| Fixed rule of thumb | Hidden assumption | How it fails |
|---|---|---|
| N events in M minutes | Attackers are fast and loud | Slow, spread-out attempts never cross the line |
| Only alert above severity X | Severity reflects real risk | A low-severity signal on a critical asset is ignored |
| Auto-close after N benign closures | Past closures were correct | A real incident in a "noisy" family is closed automatically |
| Same limit for every tenant or site | All environments behave alike | Too loud for one, too quiet for another |
| Fixed budget of queries per case | Every case needs the same depth | Complex cases are under-investigated |
The alternative: context, then verification
The answer is not to throw thresholds away and let a model decide everything. That simply replaces a visible fixed number with an invisible one. The more robust pattern has two parts.
First, judgement should depend on context. How unusual is this behaviour for this specific host, account or application, at this time of day and week? How critical is the asset? Is this part of a story that already has other confirmed signals? The same raw count can be routine for a backup server and alarming for a receptionist’s laptop.
Second, every judgement should be checked against independent evidence rather than against what people decided before. If an alert is closed as benign, there should be a reason grounded in raw records, not just "this kind is usually benign". When a rule or model and an independent check disagree, that disagreement is a signal worth looking at, not something to average away.
Principles for safer cut-offs
- Separate safety limits from tuning knobs. Some lines, such as never auto-containing a domain controller, should stay fixed by design. Most others should adapt.
- Do not treat historical labels as ground truth. Screen suspicious dismissals before learning from them, and never let a system learn from its own outputs.
- Measure misses, not just noise. A change that cuts alert volume but loses one real incident is a bad trade.
- Make every adjustment visible: what changed, why, on which evidence, and how to roll it back.
- Introduce changes gradually. Observe what a new judgement would have done before it is allowed to decide.
- Keep people in the loop where it matters, and record their decisions as labels that improve the system over time.
What this changes for analysts
Moving away from fixed thresholds does not remove human expertise; it changes where it is applied. Instead of tuning numbers in rule files, analysts review conclusions that come with their reasons and evidence. Instead of clearing a queue sorted by a static severity, they see the cases that are unusual for the entity involved. Their decisions, recorded with care, become one of the strongest inputs for improving the system, alongside independent verification that catches the cases people miss.
How ApexAI approaches it
ApexAI is built on the principle that judgement should follow context and evidence, not frozen numbers. The ApexAI Autonomous SOC weighs behaviour against each entity’s own normal pattern, verifies its conclusions against raw records in your SIEM, and keeps a small set of safety limits that never move. Changes are observed before they decide, recorded with their reasons, and reversible. People’s decisions improve the system, and suspected misses are screened rather than learned as truth.
Questions
Are fixed thresholds always bad?
No. Safety limits, such as which systems may never be contained automatically, should be fixed on purpose. The problem is tuning knobs that were fitted once to past behaviour and never revisited.
Why not learn thresholds from analyst labels?
Labels include human error and unreviewed closures. A threshold fitted to them reproduces those misses automatically. Labels are valuable, but they should be screened and combined with independent evidence.
Does adaptive judgement make the SOC less predictable?
It should not, if every adjustment is recorded with its reason, bounded by fixed safety limits, introduced gradually and reversible. Predictability comes from transparency, not from the number staying still.
See ApexAI on your own alerts.
A walkthrough with your team, in observe mode first: ApexAI scores and proposes, nothing acts on its own.