Disclaimer: Opinions expressed are solely my own and do not reflect the views or opinions of my employer or any other affiliated entities. Any sponsored content featured on this blog is independent and does not imply endorsement by, nor relationship with, my employer or affiliated organisations.

This is Part 2 of the SOC Reality Check series. In Part 1, I explained how we've made incredible progress on the middle (investigation/triage) and we're improving the left (detection engineering), but this success revealed a new bottleneck: the right side of the IR cycle. Now let's talk about what it actually takes to solve it, and what becomes possible when you do.

Let me start where Part 1 ended: We're actually winning at AI-powered security operations.

The middle is getting better and better, and the left is improving. But the right side, forensics, response, and recovery, is still the bottleneck.

In Part 1, I showed you what that bottleneck looks like. But here's what I didn't talk about: what becomes possible when you solve it.

Because the right side isn't just about faster response. It's about unlocking an entirely different way of operating your SOC, one where your team actually has time to hunt for threats proactively, validate your detections continuously, and improve your security posture measurably.

This edition is sponsored by Binalyze

Let me be very clear: AI is incredibly valuable for the right side, but only if you have the forensic automation infrastructure underneath it.

I keep seeing vendors pitch "AI-driven response" and "autonomous remediation." Here's what they usually mean: automated containment like blocking an IP, quarantining an endpoint, or disabling a user account.

Here's what they don't mean: Actually collecting forensic evidence. Understanding the full scope of the compromise. Hunting for related activity across the environment. Preserving artifacts before they're overwritten.

AI can help you decide what to investigate and recommend actions. It can correlate patterns and suggest attack paths. That's the brainwork, and AI is genuinely good at it.

But AI cannot collect memory dumps before the evidence is overwritten. It can't preserve forensic artifacts across Windows, Linux, macOS, and cloud consistently. It can't ensure chain of custody. It can't guarantee complete evidence instead of just whatever happened to be available.

AI is the brain that decides what to do. Forensic automation is the hands that actually do it. You need both, and right now most organizations only have the brain.

Most people think forensic automation is just about "collecting evidence faster", cutting the collection time from 4 hours to 15 minutes.

That's only 20% of the value. The other 80% is what it unlocks downstream.

Your AI SOC platform does an amazing job. It investigates 1,000 alerts per day, closes 700 as benign, and escalates 100 as True Positive or Inconclusive. Your dashboards look fantastic.

But here's what's actually happening: Your team looks at those 100 escalated alerts and realizes manual evidence collection takes 2-4 hours per incident. With 6-8 analysts on shift, they can properly investigate maybe 10-15 incidents with complete forensics.

So what happens to the other 85? You triage, you prioritize, you make judgment calls. "This one is probably just noise, close it." "This one is non-critical, deprioritize."

You're rationing investigation capacity.

Now, imagine the math changes completely. Evidence collection happens automatically in 5-15 minutes, triggered by alert severity. By the time an analyst looks at the incident, all forensic artifacts are already collected and waiting.

Suddenly you can be thorough with everything. You're no longer choosing which threats are "worth" deep investigation, you investigate all of them.

Related to this blog, there is a podcast episode, check it out:

Here's what keeps me up at night: How do you actually know if your AI is making correct decisions?

Of those alerts your AI closed as "benign" with 95% confidence, how many did you validate with forensic evidence? Most organizations have no idea. The AI says "95% confident," you trust it (because you don't have capacity to investigate manually), and the alert gets closed.

This is flying blind with extra steps.

With automated forensic collection, you can close this loop. AI flags True Positive → Forensics collected automatically → Human validates with evidence → Results feed back to improve AI. Without forensic automation, this loop is broken.

When your team isn't drowning in manual evidence collection, something amazing becomes possible: they can finally do proactive work that actually improves security posture.

Let me show you what I mean.

Your analyst arrives at 8:00 AM, checks overnight alerts. Spends the morning manually collecting evidence, SSH into systems, running scripts, hoping logs haven't rotated. By lunch, they've collected partial evidence from a few systems. Afternoon brings more alerts, more manual collection, more coordination. By 5:00 PM, they go home exhausted.

Time spent on proactive threat hunting: zero.

Same analyst, different infrastructure. By 9:00 AM, they've reviewed pre-collected evidence for all overnight incidents. Five are malicious, containment actions executed. Three are false positives, feedback logged. By 10:00 AM, incidents are handled.

Now they actually have time for proactive work.

10 AM to 12 PM: Hypothesis-driven threat hunting. 1 PM to 3 PM: Detection engineering based on findings. 3 PM to 5 PM: Purple team validation exercises.

5:00 PM: They go home having actually improved security posture, not just responded to what already happened.

Let me walk you through a real scenario. In January 2025, security researchers disclosed Glassworm, the first self-propagating worm using "invisible code" that hit VSCode marketplaces. This is a supply chain attack targeting developer environments.

What makes Glassworm nasty: it spreads through malicious VSCode extensions that look legitimate. Malicious code is hidden using zero-width characters. Once installed, it can steal credentials, propagate through git repositories, and establish persistence.

The problem: Most organizations have zero visibility into what VSCode extensions developers install. It's not something EDR monitors closely. Developers install extensions all the time, it's normal behavior.

Someone reads about Glassworm on Twitter. "We should probably check if we're vulnerable." Added to backlog.

Two weeks later, a developer tickets IT: "My system is acting weird." The ticket sits in the queue for days, it's not high priority.

Eventually, an analyst investigates. They check EDR logs for that one system. VSCode is making unusual network connections, but is that malicious? They don't have forensic artifacts to tell. They ask the developer what extensions are installed, the developer lists five they remember, but there are actually twelve installed.

How do you investigate a VSCode extension? They're just directories of JavaScript files. Is the code malicious? This investigation is going nowhere.

Meanwhile, the worm has been propagating for three weeks through git repositories. Other developers got infected. Nobody knows the full scope.

This is what happens when you're purely reactive.

It's Monday morning, January 20th. The security team reads about Glassworm disclosed over the weekend. Instead of adding it to backlog: "Let's hunt for this right now."

Now, you might be thinking: "Wait, can't I do this hunt with my EDR?" And you'd be partially right. Yes, your EDR has some of this telemetry, process execution logs, network connections, maybe even some file system activity if you're collecting it.

But here's where it gets complicated:

Your EDR covers the 347 Windows and Mac developer workstations with agents installed. Great. But what about the 45 Linux developer boxes that use a different EDR agent with a different console? Or the 20 cloud development environments that don't have traditional endpoints? Or the containerized dev environments that spin up and down?

You're already in three different tools.

Now let's say you start hunting in your EDR console. You query for VSCode process execution across all endpoints. Your EDR retention is 90 days if you're lucky (and paying premium for that). The Glassworm disclosure mentions extensions installed three months ago. You might be outside your retention window for the initial infection.

You find some VSCode processes making unusual network connections. Good! But to investigate the actual extension code, you need file system artifacts, the extension directories, the JavaScript files, the package.json configs. Does your EDR collect that level of disk forensics? Maybe for specific directories you've configured, but did you tell it to monitor VSCode extension folders six months ago? Probably not.

Now you want to check persistence mechanisms. You pivot to your SIEM to search Windows event logs for scheduled tasks. Oh, but you need to correlate those with the specific VSCode processes you found in EDR. You're copy-pasting process IDs and timestamps between tools.

You want to see what git repositories the infected systems accessed, because the worm propagates through git. That data might be in your network monitoring tool or proxy logs. Now you're in a fourth tool, trying to correlate timestamps again.

And let's say you find evidence of compromise. Now you need to preserve it properly for potential legal proceedings with proper chain of custody. Your EDR wasn't really designed for that, it's a detection and response tool, not an evidence management system.

This is what I mean by "might be limited and you need to jump to multiple tools."

With forensic automation platform collecting data across all your systems, not just endpoints with EDR agents, the hunt looks different:

First query: What VSCode extensions are installed across all developer systems?

One query. One platform. Covers Windows, Mac, Linux, cloud instances, containers, everything. Results in minutes: 1,240 unique extensions across 412 total systems (not just the 347 your EDR covers).

The forensic platform has been collecting file system artifacts continuously, not just process executions, but actual extension files, configuration, modification timestamps. You can see exactly what's installed, when it was installed, and examine the actual code if needed.

Second query: What network connections are VSCode processes making?

Same platform. Network forensics correlated automatically with process data. No pivoting to another tool. You're seeing unusual patterns on 12 systems.

Third query: What persistence mechanisms were created by VSCode processes?

Same platform. Scheduled tasks, startup items, cron jobs, all correlated with the processes that created them. You don't need to manually match timestamps across three different tools.

All of this in one investigation workspace. The forensic artifacts are preserved with proper chain of custody. Retention isn't limited to 90 days, you have historical data going back as far as you need for compliance.

You find 12 compromised systems across all your development infrastructure, including three Linux boxes and two cloud instances your EDR doesn't cover.

This is why "EDR has logs" isn't the complete answer. EDR is fantastic for what it does, but it's not designed to be a comprehensive forensic investigation and hunting platform. It's designed for endpoint detection and response.

Here's what hunting looks like in most organizations today, even with good EDR:

When you hunt, you're pivoting across all of these, manually correlating timestamps and indicators. Copy-paste investigation. It works, but it's slow, error-prone, and doesn't scale when you need to hunt across thousands of systems in two hours.

Forensic automation platforms consolidate this. Not by replacing your EDR or SIEM, but by providing a unified collection and investigation layer on top of them. You're still using your EDR for real-time detection and response. But when you need to hunt or do deep investigation, you have one place where all the forensic artifacts live, properly correlated, with extended retention.

After the hunt, the team asks: "Why didn't our detections fire for this?" They had EDR monitoring, but weren't specifically looking at VSCode extension installations or obfuscated code execution from extension directories.

New detection built: Monitor for VSCode extensions from non-verified publishers making unusual network connections or creating persistence. Tuned using the forensic data they collected, tested against the twelve confirmed infections and 335 clean systems.

This is security posture improvement in action, each hunt makes your detection coverage broader and your blind spots smaller.

Solving the right side requires a fundamental shift in how SOC teams think about their work.

Most SOCs operate with a reactive mindset: Alerts come in, you respond. Success = how fast you clear the queue. You're constantly behind, always catching up.

When you solve the right side with forensic automation, you can shift to a proactive mindset: You assume threats are already in your environment that your detections missed. Your job is to actively hunt for them. Success = how much you improve detection coverage and validated security controls.

This shift doesn't happen automatically. It requires leadership commitment, restructuring how analyst time is allocated (dedicating 20-30% to hunting), changing what metrics you track, and training your team on hunting methodologies.

But the organizations that make this shift? They're the ones who find supply chain attacks like Glassworm before they spread through the entire organization.

Everything depends on this. You need a system that can remotely collect comprehensive forensic evidence across all OS types, triggered automatically based on alert severity, preserving chain of custody properly.

This doesn't mean ripping out your EDR. Your EDR is still critical for real-time detection and response. But you need a forensic layer that:

Tools like Binalyze are purpose-built for this problem. You're not replacing your SIEM or EDR, you're filling the gap between "alert fired" and "comprehensive evidence collected for hunting and investigation."

Allocate dedicated hunting time (20-30% of each analyst's week). Make it protected time, not "hunt when you have spare cycles." Define a hunting cadence, weekly TTP-based hunts, monthly purple team exercises, quarterly baseline deviation hunts.

From hunting to detection engineering: What gaps exist? What new rules should be built? The Glassworm hunt should result in new detections for supply chain attacks.

From response to AI improvement: Was the AI's verdict correct? Validate with forensic evidence.

From forensics to threat intelligence: Share what you're actually seeing in the wild.

The right side isn't just about responding faster to incidents. It's about fundamentally transforming how your SOC operates.

When you solve the right side with forensic automation, the response becomes faster and the evidence is complete. But those are just the table stakes.

The real transformation is that proactive hunting becomes feasible. Your team can actually hunt for threats when intel drops, instead of hoping your detections catch it. Detection engineering gets continuous feedback. Your security posture improves measurably over time.

Yes, your EDR gives you telemetry. Yes, you can do some hunting with it. But when you need to hunt across your entire infrastructure, endpoints, cloud, containers, systems without agents, and correlate findings without pivoting through five tools, that's where forensic automation makes the difference.

This is the shift from a SOC that fights fires well to a security operation that prevents fires from starting. From reactive response to proactive defense. From hoping your detections work to validating they work and continuously improving them.

We did great work solving the middle with AI triage. We're making real progress on the left with better detection engineering. But the right side is what unlocks the SOC everyone actually wants to work in, one that hunts threats proactively and improves security posture measurably.

Don't just close alerts faster. Build a SOC that actually gets ahead of threats.

That's what the right side is really about.