The Base Rate Problem Behind Managed Soc Services

By Author: Robert
Total Articles: 33
Comment this article

At 2:14 AM, an alert fires for suspicious PowerShell on a finance laptop. The rule behind it is a good one, honestly: it catches 99% of real attacks and misfires on only 1% of normal activity. Exactly the kind of rule you'd expect from solid managed SOC services.

Your on-call analyst spends a good forty minutes pulling process trees and login history, then closes it. A sysadmin was running a patch script, again.

Nobody had bad luck here. This is arithmetic, and it's probably the most overlooked reason SOCs burn out people and miss real intrusions. Most buyers of enterprise SOC services never think to ask about it, which is a bit strange given what they pay.

The base rate problem, in real numbers
Say your environment throws off 1,000,000 security events a day, and 10 are actually malicious. Run that 99%-accurate rule over all of them, the way most SOC services would.

About 10 malicious events get flagged, fine. But 1% of the 999,990 benign ones misfire too, roughly 10,000 false alarms. So your queue holds around 10,010 alerts, and only 1 in 1,000 is real. Even well-run managed SOC services see ...
... this exact pattern.

\text{Precision} = \frac{TP}{TP + FP} = \frac{9.9}{9.9 + 9{,}999.9} \approx 0.099\%

Every single spec sheet number looks great, and yet the precision still lands under one tenth of one percent. This is the base rate fallacy, and no enterprise SOC services team is immune to it. It's the same reason doctors don't screen a whole population for a rare disease with an imperfect test.

So when the thing you're hunting is rare, false positive rate matters way more than detection rate. Any SOC services provider quoting only detection rates is giving you half the story, and the less useful half.

Why more analysts and more rules make it worse
The instinctive fix is hiring. At 10 minutes per triage, 10,000 alerts is about 1,667 analyst hours a day, roughly 70 people working at once, nonstop. Not even the largest SOC for enterprise security staff for that.

So alerts get bulk-closed, sampled, or ignored, and that gap is exactly where intrusions hide. Adding detections for coverage doesn't help much either. Each new rule stacks its own false positives on the same tiny base rate, so coverage looks better on paper while the SOC monitoring services dashboard keeps getting louder.

And tightening thresholds? That just trades false positives for missed attacks, nothing more. You slide along the same curve instead of getting off it. This is where good managed SOC services separate from ones that mostly add bodies.

Three levers that actually change the math
You can't make attacks less rare. What you can change is the population you ask the question of, pushing the effective base rate up before a human sees anything. That, more than tooling logos, is the real engineering behind modern SOC services.

1. Correlate independent signals
Instead of alerting on one detection, require two loosely related signals on the same entity in a short window. Say, suspicious PowerShell and a new outbound connection to a rare domain within 15 minutes. It's a basic pattern in any SOC for enterprise security, or it should be.

If each misfires on 1% of benign activity and they're independent, the combined rate drops to about 0.01%. False alarms fall from roughly 10,000 to 100, and precision goes from 0.1% to around 9%. Real signals are rarely fully independent, so gains are smaller in practice, but tenfold isn't unusual. Mature managed SOC services run hundreds of these correlations quietly.

2. Enrich with context before alerting
The same event means very different things on a domain controller versus a dev sandbox. Joining each detection with asset criticality, identity, vulnerability exposure, and change records lets the system weigh it properly, which is what enterprise SOC services are paid for.

If an approved change ticket shows a patch window on that finance laptop, the 2 AM PowerShell sort of explains itself. Statistically, enrichment updates the prior probability of malice. Strong SOC security services build this into the pipeline, not as a lookup done afterward.

3. Score risk per entity, then alert
With risk-based alerting, detections stop being alerts on their own. Each adds a risk score to a user or host, and an alert fires only when that score crosses a threshold within a window. More managed SOC services should be working this way by now.

Low-fidelity rules turn from noise into supporting evidence. An attacker trips many small signals on one identity, while a noisy rule firing randomly across thousands of hosts rarely piles up on one. For a SOC for enterprise security watching tens of thousands of endpoints, this lever alone can reshape the queue.

Where AI agents fit, and where they don't
AI agents deserve the attention, to be fair. One can pull a process tree, check reputation, and query identity logs in seconds, cutting the cost of each investigation a lot. Nearly every vendor of managed SOC services now leads with them.

But it doesn't change the base rate. An agent triaging 10,000 junk alerts quickly is still triaging 10,000 junk alerts, and every automated closure is a decision that a fully managed SOC must be able to audit.

Agents work best on a pipeline that already correlates and enriches. Feed them noise, you get faster noise, simple as that. So ask any provider of SOC services exactly what its agents are being fed.

Six questions to ask whoever runs your SOC
In-house, co-managed, or fully outsourced, these questions show quickly whether a team manages the math or just soaks it up. Use them on your current managed SOC services partner too.

What's the measured precision of your top 20 detections over 90 days?
What share of alerts close as benign, and is it trending down?
How does coverage map to MITRE ATT&CK, and where are the gaps?
Do your managed SOC services measure MTTD and MTTR from the first malicious event or from alert creation?
Which business context feeds triage, and who keeps it current?
When automation closes an alert, can we see its reasoning?
Vague answers on the first two are the clearest warning sign you'll get. If a team can't state its precision, it isn't tuning against it, whatever the SOC monitoring services brochure says.

The takeaway
A SOC is a signal processing system before it's a staffing problem. Fix the math first through correlation, context, and entity-level risk, then scale with people and automation. Both work far better when one alert in ten matters, not one in a thousand. Buying managed SOC services should mean buying better math, not more eyes on the same noise.

That's the approach we take at Crest Data. Our teams build correlation and enrichment into the detection pipeline, tune rules against measured precision, and pair round-the-clock analysts with automation that actually shows its work. Whether you need support alongside your own team or a fully managed SOC running end to end, it all starts from this math.

Drowning in alerts, or weighing a new SOC partner? Let's talk about what your numbers look like - https://www.crestdata.ai/