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.

I’ll take some responsibility here. Maybe I started this movement, maybe not, but I’ve definitely been pushing it for a while. So now I’ll give it a proper name and see if I get some credit for it. In the end, it’s not about who said it first. It’s about sharing knowledge and helping the community make sense of what’s happening.

It's been a couple of years now since AI really started hitting the cyber field, especially in Security Operations. We started with AI copilots, then the focus moved to the sweet spot, investigations, and now we're seeing a push to "shift left" and "shift right."

And if you’re wondering what I mean by shifting left or right in this context, let’s clear that up. Unlike the messy attempts of “shift left” in SDLC, here it’s simple: shifting left or right means asking which stage of the IR cycle you are applying AI to. For me, that’s the best way to evaluate, identify, and understand AI’s true capabilities for SecOps.

So let’s give this framework a name: The SecOps AI Shift Map.

This edition is sponsored by Exaforce

If you break down the IR cycle into three stages, left, middle, and right, you can start mapping where AI is actually being used. On the left side, we have data ingestion, log processing, and detection engineering. Think of it as the foundation: we set up controls like EDR, network protection, IAM, cloud guardrails, email security, the usual stack. 

Then comes logging. You centralize everything in a SIEM, prioritize sources, and slowly build toward the impossible dream of “100% visibility.” 

After that comes detection engineering: choosing the right log sources, building threat profiles, and designing detections based on expected TTPs. That’s the left side of the house, and it ends with a detection firing.

The middle side is where things get interesting, and honestly, where most of the industry is today. Once a detection fires, you need procedures. Call them SOPs, runbooks, or playbooks, they all serve the same purpose: guiding what you need to look at. Here comes enrichment, and I know there are strong opinions on whether this should sit at the detection layer or the investigation layer. In reality, it depends. Some enrichments definitely make detections stronger, but many, like CTI lookups, alert similarity, correlation, or even tribal knowledge, make more sense during investigation.

Once enriched, the investigation starts. I like to map this stage to the 5Ws: Who, What, When, Where, and Why. Answering those questions leads you to a conclusion, a verdict.

We have a few types of verdicts:

Note that we are measuring metrics on alerts here, not incidents. Incidents are a different bucket. They can start directly in the investigation phase without an alert, and that’s where we might find a False Negative, no alert was generated, but someone (an employee or an external party) identified a compromise.

And now for the right side of the house. This is where remediation, recovery, and lessons learned happen. It’s also the hardest part to automate or apply a lot of AI to, especially remediation.

You’ll hear many people say this is where SOAR failed. I’d say no, it didn’t, we failed here because our processes are a mess. True automation hits a wall when it runs into a lack of API coverage for critical internal tools, undocumented tribal knowledge, a culture of risk aversion, and of course, the dreaded change management process. Remediation isn't always straightforward. The larger and more regulated the organization, the more you run into these roadblocks. You can’t just go wild and do what you want. No one wants to give a service account to a SOAR or AI SOC solution that has full write access. Even if some actions are pre-approved, the risk is just too high.

The idea is that you don't have many compromises, so you shouldn't need to run these actions often. This beats the purpose of building automations that run only a few times a year. (And if you're an org that needs to run these actions often, I think you should go back to the left side and fix your issues there).

Recovery is a bit easier to automate, and this is where IT and DevOps automation usually comes into play. And lessons learned? This is where AI shines. It’s great at writing a summary, getting you an executive report, and formatting it nicely. The part we need to improve is how we feed this information all the way back to the left side to constantly get better. We’re not doing a great job there. Where we fall short is feeding those lessons back to the left side to improve detections and logging. And let’s be honest: for many vendors, fewer problems don’t translate into revenue, so the feedback loop rarely gets prioritized.

When AI for SecOps first showed up, vendors went straight for the middle, the investigation. It’s like getting a fancy cake. You ignore the heavy fondant on the outside (the broken detections) and go for the sweet, sugary center. It gives you a quick sugar rush (hundreds of alerts closed fast!), and you feel great.

(Weird analogy, I know).

But you're not fixing the real problems. The fondant still tastes bad, and the sugar crash is coming. The "lessons learned" are that you ate too much cake, but a week later, you forget and just remember the sweet part. You want that good feeling of eating the sweet middle part (all those 100 alerts closed fast).

So yeah, a long way of saying it started in the middle because it was the easiest part. It's the main area where we don't need as many deterministic things, and we can easily use GenAI to do analysis and come up with a verdict.

But now we're realizing that just doing the investigation isn't enough. What about our broken or incomplete detections? What about the log sources that are missing key logs? What about the simple response actions?

That's what we need to actually fix the problem. I want to get recommendations on which detections should be fixed and which log sources should be improved. I want my AI to be able to reach out to a user and ask for more information if needed, and then quarantine their machine and reset their password. 

Simple, right?

Sad story is, not many are doing it yet.

The SecOps AI Shift Map is a way to frame where AI is being applied across the IR cycle. It helps us evaluate vendors, set expectations, and identify gaps.

We started in the middle, because it was easy and satisfying. But the real progress ,the real SOC of the future ,is in shifting left and right. That’s how we’ll build AI SOCs that don’t just close alerts faster, but actually make security operations stronger end to end.

Just before I jump to the vendor spotlight, I wanted to reassure you, the audience: all the vendors I mention here are ones I've had a demo with to understand their capabilities. It’s not just for the sake of having a vendor highlight; it's something I've seen and evaluated, and I'm giving you my insight on what they're good at.