Yuval HashaviaMost SOCs assume alerts are inevitable: something will fire, and when it does, the job is to move fast. But watch what actually happens during an investigation and a lot of it doesn’t look like response. It looks like archaeology.
Most “response work” isn’t really response
An alert fires, and the analyst’s first move isn’t deciding how to handle it, it’s figuring out what they’re even looking at. Where did this come from? What system is it tied to? Is this behavior normal for this user or this asset?
So teams add enrichment, correlation, threat mapping, and tuning. All genuinely useful. But a significant chunk of investigation time is spent reconstructing context that didn’t disappear. It was never properly carried forward. The data existed somewhere. Its relationship to the detection logic existed somewhere. It just never made it to the analyst’s screen.
The problem starts way earlier than the alert
A lot of the friction during response traces back to decisions (or the absence of decisions) made much earlier. Data arrives without clear lineage. Detections run without reliable accounting of their inputs. Coverage is assumed rather than measured, and gaps stay hidden until something slips through.
The natural instinct is to make investigation faster. The more uncomfortable question is: why is the investigation doing this much work in the first place?
Why federated analytics changes the visibility equation
Most teams describe visibility in terms of their stack: what’s deployed, what’s sending logs. That conflates having tools with actually having visibility.
Visibility comes down to whether you have the data you need, know where it lives, and can work with it coherently. Federated data models change that. You run analysis across data where it already lives. Instead of moving data to compute, you move compute to data. As we’ve written elsewhere on this blog, that inversion unlocks coverage centralized architectures can’t match without prohibitive cost.
Coverage gaps: why they stay hidden
Stop thinking in terms of tools and start thinking in terms of data: not “what do we have deployed,” but “what are we actually capable of detecting given the telemetry we have.”
Most teams have some sense of their coverage, often mapped to a framework, but it’s rarely grounded in the actual relationship between telemetry and detection logic. Gaps stay hidden. You don’t notice missing data until a detection fails to fire. And you don’t know what data you should have or use in order to cover a threat you care about.
Some detection programs start by threat model, and then look at what’s the required data for that model. We cover this approach as well.
When coverage is continuously measured against real telemetry - not frameworks, not assumptions - those gaps become visible early, and you can do something about them before they matter.
Detection drift: the silent quality problem
Detection quality degrades quickly without active maintenance. Environments change. Data schemas change. User and system behavior evolves. The detection logic, more often than not, doesn’t keep up. The result is detection that technically runs but no longer reflects reality. The symptoms show up as noise, as fatigue, as tuning work that never quite stays done.
This isn’t hypothetical. We saw it play out in a real environment last week.
A customer was onboarded, existing detections were converted automatically, and the system began evaluating them against live data. A small set of detections immediately stood out: they were responsible for the vast majority of signal volume. Not because they were “high fidelity,” but because they didn’t fit the environment they were running in.
The system surfaced this misalignment and generated tuning suggestions based on actual behavior. The result: some detections went completely silent. Others dropped sharply.
Noise from those detections dropped by 94.5%, without a manual tuning cycle.
That’s detection drift, identified and corrected before it turns into analyst workload.
Using threat intelligence earlier
Most teams use threat intel during investigations to explain what happened. But applied upstream, it can do much more: project a threat’s MO against your current coverage, reveal what data you need to bring in, and drive action to close exposure before an incident occurs. Treating intel as a continuous input into detection engineering (instead of a reference resource consulted after the fact) is one of the highest-leverage shifts a security team can make.
When the upstream is clean, investigations feel different
Fix enough upstream and investigations stop feeling like a scramble. The context is already there - the alert carries meaning, tells you what it’s connected to and why it fired. You skip the reconstruction and go straight to deciding what to do.
Why AI-native detection requires a unified context layer
Coverage, detection, threat intel, investigation, enrichments - they all need the same underlying data and shared context. When that gets unified (not centralized, but unified) the whole system behaves differently. As we explored in our post on the agentic SOC: AI assistance becomes useful when there’s enough coherent context to work with. Without it, AI just accelerates the same reconstruction work you started with.
Closing thoughts
The real goal isn’t faster response. The real goal is reducing how much work needs to happen during response in the first place. Alerts stop being puzzles you solve under pressure and start being signals you act on immediately.
If this resonates, we’d love to walk through how federated analytics and AI-native detection make this possible in practice. Get in touch.
