Friday, September 18, 2026

Can AI Let You Jump SOC Maturity Levels? (Spoiler: Only the Boring Half)

Back in my analyst days, I built maturity models for a SOC (2018), a SIEM (2018), vulnerability management (2017) and threat intel (201?). Later, just for fun, I cooked up a simple SOAR adoption maturity model (2022). All of them were vaguely CMM-shaped: you start ad hoc, you get defined, you get measured, you get optimizing, magic! The ordering was not decorative. Each level existed because the one below it produced something the next level needed. Largely, you cannot jump levels, and if you do jump, you land in clown realm.

this is how Gemini imagines this blog

2026, now the pitch has changed. With AI (agentic, of course!), the story goes, a low maturity SOC can leap to maturity Level 3 or 4 “because AI”. No slog through the “defined process” desert, no “organic” growth through stages. Buy the agents, skip the years!

If you attended my RSA 2026 peer session, you saw the buyer-side version of this: “AI in a SOC sounds great, we will just wait for our SIEM/SOAR vendor or MDR to give it to us.” Same assumption, that the new version of the tool carries the maturity boost with it. Sadly, in reality AI can generate the paperwork of a mature SOC in an afternoon. It cannot give you the institutional memory to know what your own systems actually do.

Ten years ago, in “Jumping Security Maturity Fail”, I endorsed a reader’s line that you can jump technologies, but you can’t jump maturity. I’d like to re-examine that in the age of agents. Because some of it has changed. Just not the part vendors are selling. Think of this as “Jumping Security Maturity Fail, Part 2. 10 Years Later.”

Where this post sits

This is a bridge between two things I’ve been writing about. On one side, the AI-ready SOC pillars and how to plan the journey to them. On the other, the “Stop Building a 2003 SOC with AI” series (Part 2, Part 3), which argues the target SOC in 2026 should look nothing like the 2003 one (more on “SOC 2026” from scratch in a few days…)

The question in between: if the destination has changed, does the path still have mandatory stops? That is what “jumping maturity” is really asking.

The claim, restated so it can be tested

“AI lets you skip maturity stages” quietly conflates two different things:

  1. Stage outputs — the artifacts a mature SOC has: playbooks, parsers, detections, runbooks, dashboards, workflows for various humans, skill profiles for humans to hire, etc
  2. Stage prerequisites — the organizational state a mature SOC is in: it knows its environment, owns its processes, trusts its data, has a working feedback loop.

AI can generate the outputs of Level 3 for a Level 1 SOC in an afternoon. You can always say “add automation”, “make this playbook better faster”, “more AI…add even more AI…MOAR AAAIII!!!”

Still, it cannot generate the organizational prerequisites, because those are not documents. They are things an organization has learned about itself by operating. Once you split the journey along that line, the “jump” question mostly answers itself.

Typical SOC Maturity Journey (Woefully Oversimplified)

  • Level 1 — Ad hoc. Some logs, some alerts, heroics. “Nobody knows what server4 does, but Joanna might, let’s call her.”
  • Level 2 — Defined. SIEM with intentional use cases (hopefully, output-driven, not “what data do we have? Let’s shove it in!”), documented triage and (some) IR runbooks, named owners (for some things, some are even the right owners…), basic metrics.
  • Level 3 — Managed. SOAR playbooks beyond “baby’s first phishing playbook”, some threat-informed detection, log source health monitoring (logs volume drop? alert!), MTTx that is tracked and acted on (sometimes).
  • Level 4–5 — Optimizing. Detection engineering as a discipline (the DE series), a continuous detection / continuous response loop, hunting that feeds detection, an improvement culture. This sets you on a path to ASO end state.

So, let’s get “an AI jumprope” and start jumping!

Part A: What AI genuinely lets you jump

These are the labor-intensive artifacts of each level — the things that took quarters to write, not the things that took years to learn.

  • Runbook and playbook authoring. Fifty credible playbooks, one afternoon. The writing effort that used to gate Level 2→3 is gone. This one you can jump. There are caveats, like that some of the playbooks will suck, but for many teams fixing a 80% playbook is not 20% faster than making one from scratch, but essentially 5X faster… SOC process docs, playbooks, etc is where jumping is legit.
  • Parsers and normalization. Onboarding long-tail log sources was a classic Level 2 grind. Largely shortcut-able now (with lots of caveats; for tricky log sources the “fully machined” parser will suck). You can jump here, but you may trip and fall.
  • Baseline detection content. “Reasonable coverage of common threats that matter to you” no longer requires a detection engineering team to bootstrap. You can “machine” some custom detection quick, and some will even work. Keep in mind, here you can jump but not very far: you won’t arrive on “full auto” process for turning intel into detections that work well for you.
  • Tier 1 triage as a stage. Here is the one real skip: the stage where you staff a Tier 1 can be omitted entirely if enrichment and investigation are agentic from day one. You shouldn’t build the 2003 shape at all — triage must die. This is kinda a side-jump from “classic SOC” to modern D&R function, SOCless (if you wish); some aspect thereof. This won’t make you Google or Netflix if you can barely spell “MDR.”
  • Documenting existing processes. AI can watch tickets and chat and reverse-engineer what people actually do. This shortcuts the “write down what we do” part of Level 2. It does not shortcut the “decide what we should do” part. This is magical!
  • Metrics plumbing. Dashboards, reporting, the presentation layer of Level 3. (Which metrics matter is a separate, non-jumpable question — see the ASO metrics piece.)
  • Cross-SOC knowledge transfer. Mature-SOC practice encoded in models and skills means you don’t reinvent detection hygiene from scratch. This jump can get your from “almost nothing” to “pretty damn good” , and it probably won’t suck. Jump away!
  • Ordering between tracks. The SOAR model already noted that dimensions get mixed up across organizations but each dimension matures in order. AI makes this more true: you can advance the data, detection and response tracks in parallel rather than serially.

So yes — AI compresses the time within a stage, and lets you run some stages in parallel. It also allows some real jumps (yay, those marketing people didn’t lie… this time). That is real, and it is not nothing.

However…

Part B: What must be followed in sequence, AI or not

These are states the organization has to reach. No artifact substitutes for them. Worse, AI amplifies whatever state you are in — mature or clown-grade. If you have read the AI-ready SOC pillars, you will notice this list is the pillars in disguise. That is not a coincidence; readiness and maturity are the same thing viewed from two angles.

  • Environmental knowledge. Asset context, identity context, ownership. AI cannot tell you what server4 does; it can only ask Joanna faster. If your teams don’t know who owns what, neither will your agents (pillar #2). This is the single hardest prerequisite and it precedes everything else. Part 3 of the 2003 SOC series is essentially a whole post on why local context is the thing agents can’t bring with them. Yes, some fun startups are working on this, so maybe my 2027 assessment will change!
  • Data foundations before analytics. Collect → trust → detect → automate, in that order (pillar #1, still my favorite). An agent investigating over gappy, untrusted telemetry produces confident nonsense at scale. Low awareness of removed or failed log sources was already a top failure mode in Detection Engineering and SOC Scalability Challenges in 2023; with agents on top it gets worse, not better. And federated SIEM does not exempt you: federation is a topology choice, not a data-quality shortcut.
  • Process definition before process automation. SOAR proved this and agentic AI is re-proving it. Automating an undefined process gives you an undefined process that runs faster, crazier, with more stochastic chaos (fun!). And, yes, an AI-drafted playbook still needs a human who can say “no, that’s not how we do containment here” — which requires someone who knows how you do containment… Also, here agents may enable speed-up, but not truly a jump over this stage.
  • Trust calibration. “AI suggests” → “AI acts with approval” → “AI acts, humans audit.” This is inherently sequential because trust is earned from an observed track record in your environment. Vendors cannot ship trust! This is our ASO’s CD/CR applied to the agent itself, and it is also why the “humanless SOC” crowd keeps soiling their pants: they skip the calibration stage and call it a feature.
  • Ownership and accountability. Someone owns detection quality; someone owns response outcomes. Low maturity SOCs lack this. AI does not create owners. Here you jump — you die.
  • Feedback loops. The actual magic of ASO sparkles here: incidents feed tuning, false positives feed detection, hunting feeds detection. AI can run the loop faster, but the loop must exist and be wired to real outcomes. In the Deloitte/Google “consistency and creativity” paper we argued you build consistency through the lower levels first, then let creativity loose inside processes that already exist. Substitute “agents” for “creativity” and it reads as if written for 2026.
  • Organizational stamina. Budget, executive sponsorship, staff retention, tolerance for change, “change budget. Every failed SOAR program died here, not on technology. The ghost of SOAR comes back with vengeance here. Agents do not fix this one. At all.

Wait — didn’t I say you can’t cross a chasm in two small jumps?

Yes I did. In Baby ASO and its sequel I argued that incremental improvement of a “1980s-NOC-DNA” SOC mostly fails, that the fix is radical, and that simply buying modern tools changes nothing if people and process stay put. In, our Deloitte/Google “Evolution or Optimization”, we made the same point with a decision matrix.

So am I now saying “go slow, climb every rung”? Who wants this in 2026?

No. These are two different questions, and conflating them is exactly how “AI lets you jump maturity” gets sold.

  • Which ladder? Transformation (ASO, engineering-led D&R, the 2003-SOC-must-die argument) is about changing the shape of the SOC. It is a different ladder, not a shortcut up the old one. You absolutely should choose the new ladder, and you should do it in one decisive move rather than two timid ones. Transformation is not incremental.
  • Can you skip rungs? Whichever ladder you pick, the learning-cost prerequisites in Part B are the rungs. The new ladder has fewer rungs (no Tier 1 stage, no swivel-chair triage stage), which is the genuine good news. But the rungs it keeps — know your environment, trust your data, own your processes, earn trust in automation — are the same ones, and they are still climbed in order. Remember our “AI in security can be magical, but it isn’t magic; It’s a marathon of focused engineering”? This is true!

Put differently: “cross the chasm in one jump” means commit to the transformation and dump the incrementalism/optimizing what you have. This works IRL.

It does not mean the far side of the chasm has no ground rules. AI shortens the new ladder — it does not let you levitate over any chasm obstacle.

The AI-specific failure mode: skipped stages become invisible

The old cargo-cult SOC — a 1-out-of-5 low maturity SOC copying “ninja moves” from a 6-out-of-5, as I described in Clown-grade SOCs — at least failed visibly, funnily and embarrassingly. Get the popcorn! Hunting before you do logging was obviously silly.

The new one is worse. AI papers over the gap with slop. You cannot cross the chasm if you put some slop over it. Agents produce plausible investigations, tickets close, MTTR looks wonderful, and nobody notices that the environment context was hallucinated and the “containment” hit the wrong host. Skipped maturity used to fail loudly. Now it fails quietly.

A usable test: jump vs. borrow

For any element of any stage, ask one question: does this exist because someone had to spend time, or because someone had to learn something about us?

  • Time-cost elements are jumpable. AI does them.
  • Learning-cost elements are not. AI can make you learn faster, but you still have to learn.

Corollary for vendor conversations, in the spirit of the RSA 2026 “show me the numbers” advice: when someone claims a stage skip, ask which bucket their claim falls in.

Most “1→3 with AI” pitches are quietly selling the artifacts of Level 3 to a Level 1 organization, and then blaming “process gaps” or vaguely point at “customer immaturity” (right?) when it fails.

So, can you jump?

You can jump the artifacts. You can run tracks in parallel and get through each level in months instead of years. You can — and, perhaps, should — pick the transformation ladder instead of the optimization one. That is a genuinely better deal than the one we had in 2016.

But you cannot jump knowing your environment, owning your processes, trusting your data, or earning trust in your automation. Those are the maturity. The rest was always just the paperwork…

Related posts

Can AI Let You Jump SOC Maturity Levels? (Spoiler: Only the Boring Half) was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Originally published at Medium.

Posted by at
Labels: , , ,

Tuesday, September 08, 2026

Survival of the Basics: Which Security Fundamentals Were Secretly Relying on Lazy Attackers?

A few weeks ago I asked on X and LinkedIn a deceptively simple question: which “security basics” matter more against AI-armed attackers, and which ones don’t matter anymore?

What Gemini think of this blog

[before you freak out about ‘…but Anton, we don’t even have a consensus definition of “security basics’, read on — I gracefully sidestep this critical issue :-)]

I got about 60 answers. Most of them converged on the same reasonable, practitioner-approved, completely unsurprising consensus: the basics aren’t dead, AI just punishes sloppy execution faster. This is true. It has also been true of every attack trend since 1998 (hi Satan! hi Metasploit! hi fuzzing!). If that were the whole story, this post would end here.

But one reply challenged the premise, and it turned out to be the most useful comment in the thread: what can an “AI attacker” actually do that a skilled human attacker couldn’t?

The honest answer today is: nothing.

Still, this has implications related to scale, speed, coverage and a whole lot of other things. Sometimes changing the speed on the attack side should NOT lead to “well, defense should also run faster” arguments. We should “do different”, not run “almost as fast” as the attacker. Let’s think about it!

The scarce resource was never technology. It was attention.

This is also the “secret” why “luck-based” security works for some organizations. Even if they have glaring holes, DMZ CVSS 10s unpatched since 2016, Windows 2003, Red Hat Linux 9 and PHP (oh god, so much PHP!) they may still be in business, and doing sort of OK. That is why I always say that people with 10K unpatched HIGHs do NOT fear Mythos-induced “vuln-apoc” of having 300K unpatched HIGHs. The lift won’t change risk for them (IMHO) So let’s say 30x more vulnerabilities leads to … I dunno … 3% more risk?

Anyhow, for the entire history of this field, the single scarcest resource on the offensive side was skilled (defined broadly, perhaps semi-skilled too) attacker hours. There were never enough competent humans to exploit every reachable vulnerability at every company, craft a convincing lure for every employee, abuse every public S3 bucket and work through every organization’s attack surface.

The attackers did what any rational actor does with a scarce resource: they allocated it. They went after the easiest targets, the juiciest ones, or the ones that happened to be in front of them.

Here is the uncomfortable part. Perhaps you think it is obvious? A surprising share of what we call “security basics” were never really about stopping attackers. They were about not being worth the effort at the moment:

  • Patch cadence was about closing the window before someone got around to you. Not before someone could, before someone would (This is a profound idea, IMHO. Thanks Claude Fable 5.1!)
  • Phishing awareness training worked, to the extent it ever did, because mass phishing was sloppy. Crafting a good lure was expensive, so most lures were bad, so “spot the typo” was a real signal.
  • “We’re not a target” was a risk-acceptance strategy that only made sense if the attacker was choosing targets. Again, “luck based security” was very much a thing.
  • Coverage metrics like “80% of assets patched within SLA of 30 days” implicitly assumed the remaining 20% was hiding in a pile the attacker wouldn’t bother to sift through. IT sure couldn’t ;-)

None of these controls fail because attackers got smarter. They fail because attacker labor became elastic. When the marginal cost of one more exploitation attempt, one more tailored lure, one more recon pass drops toward zero, there is no such thing as low-hanging fruit anymore. All the fruit gets picked. Ok, this is new! This is fun!

Still, we have seen a similar movie before, and I was there for the first showing. Network scanners in the late 1990s and Shodan in the 2010s did not invent new vulnerabilities. They removed obscurity from the discovery phase and forced everyone to admit that “nobody knows about that server” was not a control.

In my view, AI is doing the same thing one layer deeper: removing scarcity from the exploitation and social-engineering phases.

Whatever you believe about the exact numbers in the recent frontier-model evaluations (end-to-end corporate takeover chains, three-figure attack costs, and so on), the direction is not in dispute. The attacker is no longer rate-limited by their headcount and “attention count.”

The sorting rule

This gives us something better than a list. It gives us a rule.

A [security] basic survives if it works by physics or math. A basic dies if its risk reduction was proportional to attacker effort.

  • No wire, no access. Network isolation does not care whether the probe came from a bored teenager or an agent running 1,000 recon passes a second. Hey Cisco ;-)
  • No binary, no execution. Application allowlisting does not care how the entry point was found.
  • No phishable auth factor, no phish. FIDO2 does not care how convincing the lure is, or whether it arrived as a flawless email or a cloned voice. No chip — no access.
  • No software, nothing to patch. You cannot exploit what has been removed.

In the “1990s speak”, AI cannot scan your ports, if you don’t have ports. Get rid of the TCP/IP stack while you are at it :-) Conversely, anything that reduces risk by making you slightly harder to attack than the next guy is on the wrong side of this line. So your zero-day laden security tool that runs “input filtering” is shot in the butt…

The matrix: AI resilience × modern feasibility

Back in my Gartner days, we wrote a paper on IT hygiene and which controls actually constitute a foundation. Oh those endless debates on whether NIDS is a basic control in 2016…. I recall you so fondly!

The list below is a first pass at re-running a similar exercise with two axes:

  • Does it hold against a tireless attacker, and
  • Can anyone actually deploy it in a modern environment?

BTW, the second axis matters more than people think. A control that is AI-proof, but undeployable is not a security basic. It is a wish at best…

Master table

From this, three things that are emerging as basics, done by a few now and needing to become universal:

  • Identity verification for humans at hiring and high-risk moments. In-person or equivalent anti-deepfake process for video hiring. This sounded paranoid in 2023. This sounds routine in 2026.
  • Anything that cuts off network access still works well. If you can gracefully limit connectivity, no attacker — with AI or without — can touch it. This of course wins some degree of Easier Said Than Done prize… but it is still real.
  • Identity and inventory for non-humans. If you cannot enumerate your agents and service identities, “intent enforcement” is a slide, not a control. Agent security (however defined) cannot be solved unless we solve agent identity.
  • AI-driven code and data discovery. If your data classification project has been “in progress” since 2019 (or:1989?), the attacker’s is not. So, here you do need to run faster than the attacker, yes.

The patching dilemma, properly stated

Now back to patching. According to many, patching is the ultimate “security basic,” so it deserves its own math. BTW, others say that it is neither security nor basic… Review these first, perhaps.

Under a human attacker, patch coverage was roughly linear. Going from 30% to 80% of assets patched within SLA removed 50 “points of exposure”, because the attacker was not going to find and exploit every one of the remaining gaps. Some of them were effectively hidden by the attacker’s own bandwidth.

Under a tireless attacker (read: AI), exposure stops being “what fraction is unpatched” and becomes “is there at least one reachable, usable, exploitable gap.” That number stays stubbornly close to 1 until coverage approaches 100% for reachable assets. Improving from 30% to 80% may produce close to zero risk reduction. The remaining 20% is not hiding anymore. This is new, and a bit scary. But this is an assumption to test, not a law. We need data!

But if it holds even partially, the levers change:

  • Shrink the denominator. Fewer things that need patching. This is why attack surface reduction jumps up in importance.
  • Make the gaps unreachable. Network isolation converts “unpatched” into “unpatched yet irrelevant.” This is why segmentation is back. Microsegmentation grows in importance.
  • Make patching a rebuild, not a maintenance window. If you cannot rebuild a workload from code in minutes, you are not going to win a speed contest against a vuln storm. This is less a security basic than an IT cornerstone, which is exactly the problem.

So “patch faster” and “patching doesn’t cut it” are both right. The goal survives. The implementation everyone recognizes as “patching” does not.

That pattern repeats across the table: many basics survive as objectives and die as the specific practice we associated with them. Similarly, awareness training survives as “humans exercise judgment” and dies as “annual click-through module.” Least privilege survives as a principle and dies as “someone reviews IAM policies quarterly.”

What this means, operationally

If you take one thing from this: subtract before you add. Before buying the AI-vs-AI tooling that every vendor is now pitching, remove the software you don’t need, cut the wires that don’t need to exist, and finish the asset inventory you’ve been not-finishing since your first CMDB project. These are not exciting. They are also the only controls on the list that a tireless attacker cannot outrun. Niels Provos reminds us of the same.

One more honest observation. Several of the “promoted” basics above (remove unnecessary software, segment aggressively, fix least privilege) have been recommended for 20 years, and no previous threat trend actually motivated organizations to do them. Maybe an attacker who never sleeps and never gets bored finally will. Or … maybe we will spend the budget on AI-powered SOC dashboards instead. I am, as always, an optimist…

Related:

Survival of the Basics: Which Security Fundamentals Were Secretly Relying on Lazy Attackers? was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Originally published at Medium.

Posted by at
Labels: ,
Subscribe to: Posts (Atom)

Dr Anton Chuvakin

Dr Anton Chuvakin