Drowning in Signal: Why More Data Is Making Your Incident Responders Functionally Blind
Photo by Photo by Nevin Ruttanaboonta on Unsplash on Unsplash
There is a particular kind of blindness that comes not from darkness but from too much light. Stare directly into a floodlamp and you will see nothing useful. Modern security operations centers have recreated this phenomenon at enterprise scale, deploying SIEMs, EDR platforms, network traffic analyzers, cloud-native logging pipelines, and threat intelligence feeds—and then wondering why their analysts cannot find the breach that happened three weeks ago.
The architecture of contemporary detection is, at its core, an architecture of accumulation. The prevailing assumption is that more data produces better visibility, and better visibility produces faster response. That assumption deserves serious scrutiny.
The Inversion Nobody Planned For
When security information and event management platforms first entered widespread enterprise adoption in the mid-2000s, the promise was straightforward: centralize logs, correlate events, surface anomalies. For a period, that promise held. Organizations operating with relatively narrow telemetry sources—firewalls, domain controllers, a handful of critical servers—found genuine value in aggregation.
Two decades later, the telemetry surface has expanded by orders of magnitude. A mid-sized organization running hybrid cloud infrastructure might ingest tens of billions of log lines per day. The SIEM sees everything. The analyst sees a queue of 2,000 alerts and a shift that ends in eight hours.
This is not a staffing problem, though it is frequently misdiagnosed as one. It is an architectural problem. The system was designed to collect comprehensively but was never redesigned to present selectively. The result is an inverted information hierarchy: the platform is data-rich while the human operator is context-poor.
Alert Fatigue Is a Symptom, Not the Disease
The security industry has spent considerable energy discussing alert fatigue as though it were a psychological condition requiring analyst resilience training. This framing is not only unproductive—it obscures the actual failure mode.
Alert fatigue is the predictable output of a detection model that optimizes for recall over precision. When a SIEM rule is tuned to catch every possible instance of a behavior, it will also catch every benign approximation of that behavior. Over time, analysts learn through experience which alert types carry genuine signal and which are background noise. That knowledge lives in their heads, not in the platform. When those analysts leave—and in a labor market where security talent turns over at rates that would alarm any operations executive—the institutional knowledge walks out with them.
The asymmetry here is brutal. Adversaries invest once in a technique and reuse it across engagements. Defenders must rediscover the same noise patterns repeatedly, with each new cohort of analysts.
What Constrained Teams Are Getting Right
Here is where the analysis becomes genuinely interesting. Organizations that cannot afford to staff a 24/7 SOC with deep analyst benches have, out of necessity, developed triage methodologies that larger teams rarely adopt. Constraint has forced a kind of epistemic discipline that abundance discourages.
These teams share several observable characteristics.
They treat the alert queue as a hypothesis space, not a task list. Rather than processing alerts sequentially, they group by behavioral cluster and ask which hypothesis—if true—would explain the most alerts simultaneously. A spike in outbound DNS queries, a new scheduled task on a workstation, and a failed authentication attempt against a service account may be three separate alerts or one intrusion. The lean team asks the second question first.
They build context into the detection layer, not the response layer. When a rule fires, the alert should already carry asset criticality, user risk score, recent change history, and relevant threat intelligence associations. This is not novel advice, but the discipline to implement it consistently is rare. Teams that do it spend less time pivoting between tools and more time reasoning about what they are seeing.
They accept strategic blindness as a tradeoff. This is the counterintuitive piece. High-performing lean teams explicitly decide which telemetry sources they will not monitor in depth. They are not trying to see everything—they are trying to see the right things with clarity. Monitoring coverage is not a security metric. Detection fidelity is.
Redesigning for Signal Extraction
The practical path forward requires organizations to treat their detection architecture as a signal extraction problem rather than a data collection problem. The distinction matters enormously in practice.
Signal extraction begins with a threat model. Which adversary behaviors, if present in your environment, would represent genuine organizational risk? Map those behaviors to the smallest set of telemetry sources that would reliably surface them. Build detection logic against that telemetry. Tune aggressively for precision. Accept that you will miss some things—and document which things you have accepted missing, and why.
This approach is asymmetric in the best sense. It concentrates analytical attention where adversary activity is most likely to manifest, rather than distributing that attention uniformly across a surface too large for any team to meaningfully cover.
Some organizations are beginning to formalize this through detection engineering disciplines—treating detection logic as software, with version control, peer review, and deprecation cycles. The analogy is apt. A codebase that accumulates logic without refactoring becomes unmaintainable. A SIEM rule set that accumulates detections without pruning becomes a noise generator.
The Competitive Advantage of Clarity
There is a certain irony in the observation that the organizations best positioned to detect sophisticated intrusions are often not the ones with the largest security budgets. They are the ones that have been forced, by resource constraints, to think clearly about what they are actually trying to detect and why.
The SIEM that sees everything is not an asset if the team behind it sees nothing. Visibility without clarity is not a security capability—it is an operational liability dressed up as one.
The teams winning the detection war are not winning because they have more data. They are winning because they have made deliberate, sometimes uncomfortable decisions about which data matters. That discipline, more than any platform capability, is the asymmetric advantage available to every security organization willing to pursue it.