The Queue That Never Empties
Picture a two-analyst SOC at a mid-market logistics company, around 1,200 endpoints, AWS workloads in three regions, Okta for identity. On a typical Tuesday overnight shift, the Falcon console surfaces 580 alerts. By 4 AM, the outgoing analyst has cleared maybe 90 of them. The incoming analyst arrives to a queue of 490 unreviewed events — and the new day's detections are already stacking on top.
This is not a staffing story. Hiring a third analyst into that same queue does not meaningfully change the math. You now have three analysts clearing 135 alerts each instead of two clearing 90. The queue still does not empty. The deeper problem is that the detection layer is generating signal at a rate no human triage process can match — and the vast majority of that signal does not represent a real threat.
Alert fatigue is the predictable outcome when a detection tool's sensitivity is tuned for breadth rather than confirmation. EDR tools like CrowdStrike Falcon and SentinelOne are designed to detect — to flag any behavior that pattern-matches against known bad or statistically anomalous process trees. They are not designed to determine whether the flagged behavior, viewed alongside identity and cloud data from the same 10-minute window, constitutes an actual attack in progress. That correlation step is absent by design — and it is exactly the gap that produces the 500-alert shift.
Why Alert Volume Is a Detection Architecture Problem
When an EDR console fires an alert for LSASS credential dump activity (MITRE ATT&CK T1003.001), that is a legitimately suspicious event. But consider what that event looks like in three different contexts:
- Context A: The same host ran a scheduled Windows Defender update 90 seconds earlier, the user account is a known IT admin, and there is no associated CloudTrail AssumeRole event or Okta authentication from an anomalous geography in the same window. Probability of active attack: low. Appropriate action: log and monitor.
- Context B: The same host showed a PowerShell download cradle (T1059.001) six minutes prior, the account has no prior credential-dump activity in its 90-day behavioral baseline, and an Okta System Log entry shows a failed MFA push on the same account from a new device. Probability of active attack: elevated. Appropriate action: escalate immediately.
- Context C: The LSASS access came from a service account that never runs interactive processes, followed 40 seconds later by a CloudTrail
CreateAccessKeyevent under that account's federated role. Appropriate action: page your Tier-2 lead right now.
All three generate the same EDR alert. In a queue of 500, a Tier-1 analyst spending an average of 90 seconds per alert has no realistic path to differentiating them. Context B and C get treated the same as Context A — which means the real threats are statistically likely to be missed on overnight shifts, when cognitive load is highest and queue depth is greatest.
The Correlation Layer the SOC Is Missing
The detection architecture problem has a structural fix: a correlation layer that ingests events from multiple sources simultaneously, applies entity resolution across those sources (matching the same user account whether they appear as a CrowdStrike principal, an Okta subject, or an AWS IAM identity), and evaluates patterns across a defined time window before surfacing an alert to the analyst queue.
This is not the same as SIEM correlation. Most SIEM deployments in the mid-market run a handful of correlation rules written by the original deployment team, rarely updated, and tuned conservatively to avoid noise — which means they miss the multi-step patterns that require dynamic entity resolution. A Splunk search for "failed Okta login + LSASS dump within 10 minutes" requires someone to have written that SPL rule, tested it against real event data, and kept the Okta field names current with schema changes. In a two-person security team, that maintenance backlog has a predictable fate.
Kill-chain correlation engines work differently. Rather than requiring pre-written rules per technique pair, they build behavioral baselines per entity — per user, per host, per cloud role — and detect when a sequence of events across multiple sources deviates from that baseline in a pattern consistent with known kill-chain stages. The MITRE ATT&CK framework provides the technique taxonomy; the correlation engine maps multi-source event sequences to those technique sequences and scores them by chain completion.
What 97% Noise Suppression Actually Means
The claim that cross-source correlation can suppress 97% of alert volume tends to prompt a reasonable concern: are you just burying alerts? The short answer is no — but it requires understanding what "suppression" means in this context.
An alert that is suppressed by a correlation engine is not deleted or ignored. It is classified as a single-event signal without corroborating evidence from other sources within the defined detection window (typically 5–30 minutes). These events are logged, accessible for retrospective investigation, and can resurface if a subsequent corroborating event is observed. What they do not do is enter the analyst queue as an actionable item requiring immediate triage.
This is not to say that single-source alerts are never worth investigating. Certain high-confidence detections — particularly those matching known malware signatures, active ransomware encryption behavior, or direct exploitation of critical vulnerabilities — should bypass correlation gating entirely and escalate immediately. The correlation layer should have an override mechanism for defined high-severity single-event signals. The 97% suppression figure applies to the mid-confidence behavioral detections that comprise the bulk of daily alert volume, not to the high-confidence single-event catches that any competent detection policy already handles.
The Analyst Experience After Correlation
When analysts receive a correlated escalation rather than a raw alert, the triage workflow changes qualitatively. Instead of opening alert 247 of 580 and asking "what context do I need to find to decide if this matters?", the analyst receives a pre-assembled kill-chain bundle: three events from three sources, with entity resolution already applied, timestamp deltas shown, and a technique-chain classification that maps the sequence to ATT&CK tactics.
The analyst's job shifts from context gathering to context evaluation. They are no longer asking whether the event matters — they are reviewing a machine-assembled hypothesis and deciding whether the hypothesis is correct. That decision still requires human judgment: familiarity with the specific environment, knowledge of whether a flagged service account has a legitimate reason to query AD (T1087), whether the detected lateral movement path makes sense given the network topology. Experienced Tier-2 analysts earn their keep precisely in that final evaluation step.
What changes is the ratio of that high-quality work to the low-value queue clearing. An analyst who was spending 70% of a shift triaging benign EDR noise can redirect that attention to the 15–20 correlated escalations that actually need human judgment. MTTD (mean time to detect) drops because real threats are escalated within minutes rather than waiting for their position in the queue. MTTR (mean time to respond) drops because the analyst arrives at the event with context already assembled.
Where Correlation Does Not Substitute for Human Judgment
The limit cases matter. Kill-chain correlation works well against known technique sequences — the patterns that appear in the ATT&CK framework because they have been observed in real intrusions. Novel techniques, zero-day exploitation chains, and insider threats that deviate from typical kill-chain patterns will not necessarily trigger multi-source correlation alerts. A motivated insider slowly exfiltrating data via authorized cloud sync (T1537) at volumes within their normal behavioral baseline may produce no correlating signals at all.
This is not an argument against correlation engines — it is an argument for understanding their scope. Correlation suppresses the confirmed-noise category and elevates the confirmed-pattern category. The residual investigation work — hunting for the low-and-slow threats that do not announce themselves through kill-chain signatures — remains the domain of experienced threat hunters with time to run proactive queries against retained log data.
The practical implication: when your Tier-1 analysts stop drowning in benign EDR noise, the Tier-2 and Tier-3 analysts they report to can spend more time on the hunting work that correlation engines cannot do. The organizational benefit is not just analyst retention — it is the reconstitution of an investigative capability that got crowded out by the queue.
Measuring the Before and After
Any SOC considering a correlation layer change should instrument the transition carefully. The metrics that matter are not just alert volume reduction. Track: escalation-to-confirmed-incident ratio (are the correlated escalations actually real?), mean time between correlation escalation and analyst acknowledgment, and the true negative rate on suppressed events (periodic review of suppressed events to verify no real threats were filtered). These three numbers together tell you whether the correlation engine is calibrated correctly — or whether it needs adjustment to the detection window, the entity baseline period, or the technique chain scoring thresholds.
Alert fatigue is a measurement problem before it is a staffing problem. You cannot hire your way out of it. But you can instrument your way to a clear picture of where the noise is coming from — and build a correlation layer that handles it before it reaches the analyst queue.