For 15 years (!), many of us who have touched cloud security have struggled with the shared responsibility model for cloud security. As with many “cyber things,” the theory is simple. Multiple vendors, consulting firms, and industry bodies have published deceptively clear matrices that depict exactly who is doing what for cloud security.

Everyone likes to present trivial cases: for example, the cloud provider is entirely responsible for the physical security of the data center, while the client is responsible for the application they just built and deployed within that cloud provider’s IaaS. In reality, many of the edge cases continue to cause pain to a lot of organizations.

Ok, so none of this is fundamentally new. However, in recent years, similar and more complex - dare I say sinister?- questions have emerged: What does shared responsibility look like for AI security?

Those who haven’t studied this topic in depth might assume there is no difference. Yet, there are fascinating, critical differences between shared responsibility for AI security and traditional cloud security, along with older related challenges like the shared security of outsourcing (that predate cloud).

Add AI with its probabilistic behaviors, untrusted user inputs, and nested vendor dependencies -and that finger-pointing cycle doesn’t just continue, it scales exponentially. When a customer-facing chatbot goes off the rails, the model provider blames your prompt engineering, the platform provider claims infrastructure isolation worked perfectly, and your internal application team swears it’s an upstream model limitation…

Put simply, what are the top 3 differences between shared responsibility for AI vs cloud? In my opinion:

1. A Broader Spectrum of Risk: The range of harms and risks we must consider is much wider. Shared responsibility for AI security frequently touches upon safety, privacy, ethical use, and the unique risk surfaces that emerge specifically in conversations about AI.
2. The Multi-Party Supply Chain: AI security is typically far more multi-party than traditional cloud security. For instance, one company builds the foundational model, another company fine-tunes it, a third party builds a Retrieval-Augmented Generation (RAG) architecture for you, and yet another party builds the consumer-facing application.
3. Non-deterministic Behavior: Unlike traditional cloud infrastructure where secure configurations yield predictable, deterministic outcomes, AI systems are non-deterministic. Because outputs can vary significantly based on user inputs, customers bear increased responsibility for implementing robust guardrails, continuous monitoring, and input/output filtering.

Early attempts to create a logical foundation for AI shared security responsibility produced some answers — and more questions.

In light of this being a tricky problem, here I really want to focus on one thing — a post-incident scenario. While shared responsibility covers numerous use cases (and numerous sources of confusion…), let’s examine a fairly straightforward situation: I am an enterprise end-user company that uses (maybe builds, maybe tunes, etc) AI in some form, then something blows up (digitally, as this is not IoT/ICS security blog). So:

• Who takes a loss vs who is to blame?
• Do I blame the model creator? The application developer? The model hosting platform? Or do I ultimately blame myself?

If you recall, many early challenges with the cloud shared responsibility model began with customers trying to blame the provider, only to discover they were actually at fault in the end. We tried to change this dynamic by introducing a “shared fate” model. While that specific terminology has seemingly fallen out of favor lately, the underlying philosophy remains: providers can probably do more to make AI usage inherently secure.

I was recently involved with a CoSAI (Coalition for Secure AI) working group to develop a paper covering the shared responsibility framework for AI security. As others on the team humorously pointed out, my voice was one of the loudest calling for the paper to be kept simple, crisp, and highly usable. You can judge based on the final result whether we succeeded.

We recently wrapped up and approved Version 1.0 of the CoSAI AI Shared Responsibility Framework (AI SRF) through the Coalition for Secure AI and OASIS Open. The core mission here wasn’t to build more abstract compliance theater, but to solve a practical, glaring operational pain point: Who actually owns what when an AI system fails?

Under the CoSAI framework, accountability traces down the stack with absolute clarity:

• The AI Model Provider (L5) is accountable for the base model’s inherent susceptibility to prompt injection and must document those boundaries explicitly within the model card.
• The Cloud/Platform Provider (L4) is accountable for the blast-radius containment, ensuring infrastructure-level tenant process isolation held firm during the exploitation.
• The Application Developer (L3) is accountable for failing to enforce application-level guardrails, input filtering, and localized data access controls that allowed the chatbot to hit the PII repository in the first place.
• The Deploying Organization (L1/L2) is accountable for the ultimate governance failure: they did not properly classify the data or restrict the chatbot’s system-level access boundaries before pushing it live.

Also, the paper included a phased Implementation Playbook in the document to give security teams a somewhat specific path forward:

1. Phase 1 (Days 1–30): Map your entire AI system inventory and cross-reference vendor contracts against these five layers to highlight immediate responsibility gaps.
2. Phase 2 (Days 31–90): Establish a cross-layer governance committee and formally update vendor procurement contracts with clean, explicit accountability matrices.
3. Phase 3 (12 Months): Run layer-specific tabletop simulations to stress-test your incident response playbooks before an actual threat actor tests them for you.

Fun quotes:

• “Ambiguous ownership is a growing liability for Al system deployments.” [A.C. — filed under ‘no shit, Sherlock’]
• “Without explicitly assigned owners for detection, containment, and remediation, teams default to the finger-pointing cycle” [A.C. — this will get worse, then MUCH worse, then eventually better…]
• “The framework turns ‘whose fault is this?’ into ‘which layer’s controls failed, and who owns remediation for each?’” [A.C. — this is beautifully, I probably wrote this :-)]
• “There should be exactly one accountable party per component to prevent overlaps.” [A.C. — ideal world called, it wants its problem back! Real world picked up and said ‘get lost’]
• “Clear accountability eliminates finger-pointing during incidents” [A.C. — clear evidence that Captain Obvious is alive!]

More seriously, read the paper!

In the end, I hope this work enlightens people on just how complex this problem truly is. This paper is definitely not a silver bullet that solves everything overnight; we have years of discussions and evolving challenges ahead of us down this path. However, I think this paper serves as an excellent first step. Please make sure to check out the resources listed at the end of the paper as well (a lot of gems there!)

Related blogs:

• Who’s Responsible When AI Goes Wrong? A New Framework Aims to Answer That Question
• Where Does Shared Responsibility Model for Security Breaks in the Real World?
• No Snow, No Flakes: Pondering Cloud Security Shared Responsibility, Again!
• EP203 Cloud Shared Responsibility: Beyond the Blame Game with Rich Mogull
• EP145 Cloud Security: Shared Responsibility, Shared Fate, Shared Faith?
• Who Does What In Cloud Threat Detection?
• The Cloud Shared Irresponsibilities Model

From Cloud to Chaos: Defining Shared Responsibility for AI Security was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

My Anton’s Security Blog Quarterly covers both Anton on Security and my posts from Google Cloud blog, Google Cloud community blog, and our Cloud Security Podcast (subscribe on Spotify, now with VIDEO).

Top 10 posts with the most lifetime views (excluding paper announcement blogs):

1. Anton’s Alert Fatigue: The Study [A.C. — wow, this is still #1 now! Awesome! Perhaps I need more of such deep studies]
2. Security Correlation Then and Now: A Sad Truth About SIEM
3. Can We Have “Detection as Code”?
4. Detection Engineering is Painful — and It Shouldn’t Be (Part 1)
5. Revisiting the Visibility Triad for 2020 (update for 2025 is here!)
6. Beware: Clown-grade SOCs Still Abound
7. Why is Threat Detection Hard?
8. Top 10 SIEM Log Sources in Real Life?
9. A SOC Tried To Detect Threats in the Cloud … You Won’t Believe What Happened Next
10. Log Centralization: The End Is Nigh?

Top 5 posts with paper announcements:

1. New Paper: “Future of the SOC: SOC People — Skills, Not Tiers” (paper 2 of the series)
2. New Paper: “Future of the SOC: Evolution or Optimization — Choose Your Path” (Paper 4 of 4.5) (one more paper coming later in 2026 … we are in reviews now!)
3. New Paper: “Future of the SOC: Forces shaping modern security operations”
4. New Paper: “Future Of The SOC: Process Consistency and Creativity: a Delicate Balance” (Paper 3 of 4)
5. New Paper: “Autonomic Security Operations — 10X Transformation of the Security Operations Center” (Our classic 2021 ASO paper! Still epic, still relevant)

3 random fun posts, must-read:

• Stop Building a 2003 SOC with AI: A Modern People & Process Framework (Part 1)
• Shadow Agents: A New Era of Shadow AI Risk in the Enterprise
• Anton’s Vibe Coding Experience: A Reflection on Risk Decisions

Top 7 Cloud Security Podcast by Google episodes (excluding the oldest 3!):

1. EP150 Taming the AI Beast: Threat Modeling for Modern AI Systems with Gary McGraw
2. EP75 How We Scale Detection and Response at Google: Automation, Metrics, Toil
3. EP47 “Megatrends, Macro-changes, Microservices, Oh My! Changes in 2022 and Beyond in Cloud Security”
4. EP153 Kevin Mandia on Cloud Breaches: New Threat Actors, Old Mistakes, and Lessons for All
5. EP109 How Google Does Vulnerability Management: The Not So Secret Secrets!
6. EP17 Modern Threat Detection at Google
7. EP156 Living Off the Land and Attacking Critical Infrastructure: Mandiant Incident Deep Dive

Now, fun posts by topic.

Security operations / detection & response:

• “Security Correlation Then and Now: A Sad Truth About SIEM”
• “Migrate Off That Old SIEM Already!” (VIDEO, a 2026 update is coming soon!)
• “Measuring the SOC: What Counts and What Doesn’t in 2025?” (Google Cloud Blog)
• “Can We Have “Detection as Code”?”
• “Revisiting the Visibility Triad for 2020” and “SOC Visibility Triad is Now A Quad — SOC Visibility Quad 2025”
• “Beware: Clown-grade SOCs Still Abound”
• “Why is Threat Detection Hard?”
• “A SOC Tried To Detect Threats in the Cloud … You Won’t Believe What Happened Next”
• “Stop Trying to Take Humans Out of SOC … Except … Wait… Wait… Wait…” and “A Brief Guide for Dealing with ‘Humanless SOC’ Idiots”
• “Top 10 SIEM Log Sources in Real Life?” (NEWER VERSION)
• “Debating SIEM in 2023, Part 1” and “Debating SIEM in 2023, Part 2”
• “Log Centralization: The End Is Nigh?”
• “Living with Multiple SIEMs”
• “Decoupled SIEM: Brilliant or Stupid?” and “Decoupled SIEM: Where I Think We Are Now?”
• “How to Make Threat Detection Better?”
• “SIEM Content, False Positives and Engineering (Or Not) Security”

Cloud security:

• “Secure cloud. Insecure use. (And what you can do about it)”
• “Using Cloud Securely — The Config Doom Question”
• “Who Does What In Cloud Threat Detection?”
• “How to Solve the Mystery of Cloud Defense in Depth?”
• “Does the World Need Cloud Detection and Response (CDR)?”
• “How to Think about Threat Detection in the Cloud”
• “Use Cloud Securely? What Does This Even Mean?!”
• “How CISOs need to adapt their mental models for cloud security” [GCP blog]
• “Who Does What In Cloud Threat Detection?”
• “AI Adoption: Learning from the Cloud’s Early Days”
• “Cloud Migration Security Woes”
• “Move to Cloud: A Chance to Finally Transform Security?”

How Google Does Security (HGD) — the new master site How Google Does It: An inside look at cybersecurity:

• “How Google Does It: Making threat detection high-quality, scalable, and modern” (Google Cloud blog)
• “How Google Does It: How we secure our own cloud” (Google Cloud blog)
• “How Google Does It: Securing production services, servers, and workloads”
• “How Google Does It: Finding, tracking, and fixing vulnerabilities” (Google Cloud blog)
• “How Google Does It: Collecting and analyzing cloud forensics”
• “How Google Does It: Red teaming at scale” (Google Cloud blog)
• “How Google Does It: Security programs at global scale” (Google Cloud blog)
• “How Google Does It: Securing production services, servers, and workloads”
• “How Google Does It: Collecting and analyzing cloud forensics”
• “How Google Does It: Applying SRE to cybersecurity”
• “How Google Does It: Building an effective AI red team”

(if you only read one, choose this one! BTW, we also have a lot of fun HGD podcasts)

AI security:

• “Implementing Secure AI Framework Controls in Google Cloud”
• “Office of the CISO 2025 Year in Review: 3 Key AI Security & Governance Themes”
• “Shadow Agents: A New Era of Shadow AI Risk in the Enterprise”
• ““Risk Tiering AI Use Case — A Practical Guide” (Google Cloud Community blog)
• “Securing AI Supply Chain: Like Software, Only Not”
• “Spotlighting ‘shadow AI’: How to protect against risky AI practices” (Google Cloud blog)
• “Shadow AI Strikes Back: Enterprise AI Absent Oversight in the Age of Gen AI”
• “Cloud CISO Perspectives: How Google secures AI Agents”
• “New Paper: “Securing AI: Similar or Different?“
• “The Prompt: What to think about when you’re thinking about securing AI” (Google Cloud blog)
• “Gen AI governance: 10 tips to level up your AI program” (Google Cloud blog)
• “AI Adoption: Learning from the Cloud’s Early Days” (Google Community blog)
• “How Google secures AI Agents” (Google Cloud blog)
• “Demystifying AI Security: New Paper on Real-World SAIF Applications”
• “To securely build AI on Google Cloud, follow these best practices” (Google Cloud blog)
• “Oops! 5 serious gen AI security mistakes to avoid” (Google Cloud blog)
• “3 new ways to use AI as your security sidekick” (Google Cloud blog)
• “Shadow Agents: A New Era of Shadow AI Risk in the Enterprise” (Google Cloud Community blog)

Fun presentations shared (nothing much new here):

• SecureWorld 2025 Keynote Déjà Vu All Over Again: Learning from Cloud’s Early Misadventures to Secure AI (2025)
• Detection Engineering Maturity — Helping SIEMs Find Their Adulting Skills (2024)
• Future of SOC: More Security, Less Operations (2024)
• SOC Meets Cloud: What Breaks, What Changes, What to Do? (2023)
• Meet the Ghost of SecOps Future (2023)
• The Future of Log Centralization for SIEMs and DFIR — Is the End Nigh? (2023)
• 20 Years of SIEM (2022) — should I do 25 years of SIEM in 2027?

Enjoy!

Previous posts in this series:

• Anton’s Security Blog Quarterly Q1 2026
• Anton’s Security Blog Quarterly Q4 2025
• Anton’s Security Blog Quarterly Q3 2025
• Anton’s Security Blog Quarterly Q2 2025
• Anton’s Security Blog Quarterly Q1 2025
• Anton’s Security Blog Quarterly Q4 2024
• Anton’s Security Blog Quarterly Q3 2024
• Anton’s Security Blog Quarterly Q2 2024
• Anton’s Security Blog Quarterly Q1 2024 Lite
• Anton’s Security Blog Quarterly Q3 2023
• Anton’s Security Blog Quarterly Q2 2023
• Anton’s Security Blog Quarterly Q1 2023
• Anton’s Security Blog Quarterly Q4 2022
• Anton’s Security Blog Quarterly Q3 2022
• Anton’s Security Blog Quarterly Q2 2022
• Anton’s Security Blog Quarterly Q1 2022
• Anton’s Security Blog Quarterly Q4 2021
• Anton’s Security Blog Quarterly Q3 2021
• Anton’s Security Blog Quarterly Q2 2021
• Anton’s Security Blog Quarterly Q1 2021
• Anton’s Security Blog Quarterly Q3.5 2020

Anton’s Security Blog Quarterly Q2 2026 was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

One particular aspect of an agentic or AI-powered SOC (but NOT “humanless SOC”) has bothered me over the last few months: specifically, the people and process side of such a SOC. If you recall my blog posts (part 1, part 2 and this video) about AI SOC readiness, I hinted at certain elements of a traditional process stack and legacy personnel profiles (both technical and leadership) that make AI adoption inside SOC incredibly difficult.

So we (me and Augusto Barros @ Prophet Security) want to create a modernized people and process framework for a SOC powered by AI and intelligent agents. Otherwise, what I am observing is a lot of “robotic horse pulls a buggy” kind of operations — where everything is kept exactly the same as it was in 2003, but “AI SOC” tools are simply tacked on to perform some of the tasks.

I believe that people and process components must change far more dramatically, and such changes are a critical requirement for achieving “step change” SOC with AI capabilities. Simply adding AI tools and Ai agents to a 2003-style SOC will produce, at best, marginal results. Things would get better, but not better enough to counter the feared “bad guy with AI.”

The SOAR Analogy

The analogy I want to use here is SOAR adoption from 10+ years ago. Back then, organizations simply shifted a few processes — or even just specific tasks — to a machine, and then kept the rest of their operations exactly the same. Because of that, I observed a lot of SOAR tools being used strictly for alert enrichment or for dealing with one specific, isolated type of alert, like phishing. To follow this analogy to the present day, I now frequently see an “AI SOC” being utilized only for EDR alerts or only for phishing alerts (wow, what a coincidence!)

A First-Principles Approach

What I really want to build is a first-principles approach to the specific personnel, skills, processes, and practices required to run a true agentic SOC in the late 2020s.

Now, if you prefer incremental change, that is OK, I won’t judge. However, you must be aware that the same principles caused organizations to struggle with cloud adoption. People often hear that “lift and shift” is bad. Most consultants will tell you that “lift and shift” is fine as a first step, but you eventually need to modernize and take more steps. Unfortunately, many organizations never make that second step. The same risk applies to the AI SOC. 2003 SOC + AI = somewhat better 2003 SOC.

BTW, many artifacts of the modern, engineering-powered SOC — which we covered in our now-famous ASO (Autonomic Security Operations) paper back in 2021s — apply here as well. In fact, if you recall, one of our core principles was: Humans build machines; machines do the work.

In the context of an agentic SOC, that evolves into:

Today, humans build the machines with the help of other machines, and then the machines do the heavy lifting.

So, our questions so far:

• What do humans do in an agentic SOC?
• What do entry-level humans do?
• What SOC processes stay the same despite AI?
• What SOC processes can just go and vanish (triage)?
• What processes get handed to machines?
• Are there new processes for humans?
• What is the new human role for validation?
• How do we check AI quality without fully redoing the work?
• How SOC metrics must change due to AI and agents? (some ideas)
• What do humans and machines do jointly? What does it mean, practically?
• How to HITL in a SOC without breaking the humans or machines?
• What is the effective mechanism for the human-to-AI feedback loop so that corrections actually improve future SOC performance?
• Is “fully automated” detection engineering a realistic goal, or does the dependency on local, inconsistent environment context make it inherently a hybrid human-machine effort?
• What do humans do before SOC (TI) and after SOC (IR)?
• What is the first step to move from a legacy SOC to an agentic SOC?
• Can we run legacy and agentic SOC structures in parallel during transition, or does this duplication create operational friction?
• Is it easier to move from a modern non-AI SOC (aka “SOCless D&R”) to an AI SOC?

Looking Ahead

This blog post is just the first part of the series. My goal here is simply to collect the right questions we need to be asking, but I promise we will provide concrete answers in upcoming posts. This research is being undertaken together with my former colleague, Augusto Barros, now at Prophet Security

Related blogs:

• Beyond “Is Your SOC AI Ready?” Plan the Journey!
• Simple to Ask: Is Your SOC AI Ready? Not Simple to Answer!
• WTH is Modern SOC, Part 1
• Baby ASO: A Minimal Viable Transformation for Your SOC
• Beware: Clown-grade SOCs Still Abound
• EP264 Measuring Your (Agentic) SOC: Two Security Leaders Walk into a Podcast
• New Paper: “Future of the SOC: Evolution or Optimization — Choose Your Path” (Paper 4 of 4.5)
• The Gravity of Process: Why New Tech Never Fixes Broken Process and Can AI Change It?

Stop Building a 2003 SOC with AI: A Modern People & Process Framework (Part 1) was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

So, you read my previous blog post about breaking the patch sound barrier, but it left you wanting more? Well, this is that “more.”

Here are three useful ideas to advance the conversation.

1. Defining the “Vulnerability Apocalypse”

People love to throw around terms like vulnerability apocalypse, but what does it actually mean? What is the crisp definition? Here:

Anton’s Vulnerability Apocalypse (VulnPocalypse) is …

… a rapid step increase in:

1. The number of software vulnerabilities (including zero-days i.e. vulnerabilities not known to defenders),

2. Speed of exploit development,

3. Volume of exploitation based on them,

4. Resulting incident damage.

With some help from the fine folks on Twitter and LinkedIn — and Gemini, naturally — the above is what I got.

Note that for a situation to truly qualify as “an apocalypse”, all four of these factors must be present simultaneously:

1. Massive Volume: A staggering influx of new vulnerabilities.
2. Rapid Exploit Development: Attackers weaponizing flaws nearly immediately.
3. Evident Exploitation: AI and automated tools scanning and exploiting at scale.
4. Severe Incident Damage: Widespread, material business impact resulting directly from these compromises.

The key? The fourth factor: incident damage. If you have a massive spike in vulnerabilities, but it doesn’t result in actual, widespread related damage, it isn’t an apocalypse — it’s just a high-volume vuln Tuesday.

How do we track that this is indeed coming? This is Part 3 of this saga, coming soon!

2. The Polarization of “Patch Faster”

Ever since advanced models capable of hunting down vulnerabilities emerged, the traditional advice of “just patch faster” has become incredibly polarizing.

Ultimately, my take aligns closely with a recent Cloudflare post: “Patching faster does not change the shape of the pipeline that produces the patch. If regression testing takes a day, you cannot get to a two-hour SLA without skipping it, and the bugs you ship when you skip regression testing tend to be worse than the bugs you were trying to patch.”

So, yes, do patch faster. And, no, patch faster won’t save you.

What will? This!

3. A Thought Experiment: The 15-Minute Magic Wand

Let me leave you with a useful thought experiment I recently used in a presentation.

Imagine you wake up tomorrow morning and, by pure force of magic, any vulnerability in your systems, applications, and operating systems can be patched within 15 minutes of patch release. The dream has come true!

Now for the fun part: Reverse engineer that reality.

What fundamental changes had to happen in your environment to make that 15-minute window physically possible?

If you actually run through this exercise, you will discover a goldmine of hidden opportunities. You’ll identify exactly where you can boost asset discovery, streamline software updates, automate testing, eliminate legacy roadblocks, and modernize your architecture. Fun!

Will it actually get your entire enterprise to a 15-minute patch cycle? No, probably not — and definitely not for every legacy application. But it will give you a concrete, actionable roadmap for modernizing your IT.

Let’s hope this was both fun and useful.

Related blog:

• Breaking the Patch Sound Barrier: Your Vulnerability Remediation Will Not Keep Up With AI Exploit Speed. So?

Breaking the Patch Sound Barrier Part 2: So Is The Apocalypse Coming and What Is It? was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Breaking the Patch Sound Barrier: Your Vulnerability Remediation Will Not Keep Up With AI Exploit Speed. So?

Many years ago while at Gartner, I wrote a blog post where I defined the concept of the “Patch Sound Barrier.” (original via Archive if you don’t believe that I was that smart back in 2013 :-)) This was an idea of a maximum speed that a given organization could fix a given vulnerability. If you full throttle beyond that, the engines will whirr louder, but the plane won’t fly faster, essentially.

The discussion arose from people constantly asking about the “optimal” or “desired” speed of patching. In my time as an analyst, I reviewed plenty of policies as well as “operational practices” (which is what people call it when they don’t actually follow their own policy “because reasons” :-)). BTW, I utterly hated “30 days flat” policies that say that vulnerabilities are fixed within 30 days no matter what, and always steered people to more nuanced risk-based policies.

One concept emerged: Given a particular IT environment, there is often a maximum physical speed at which an organization can patch. That is my Patch Sound Barrier.

Why bring this up now? Because the speed of vulnerability discovery is accelerating and so does exploit dev speed, but for many organizations, the speed of remediation simply cannot be accelerated. It is not accelerating, because it cannot. Full stop.

In the past, my guidance was to focus on better vulnerability prioritization so that you fix “real risks” using CISA KEV, EPSS, CVSS (OK, maybe not in the 2020s) and various tools that analyze the data and give you a ranked list.

But today we will have more vulns and prioritization tools won’t save you. If you have 1,000,000 vulns and 1000 are “risky for you” (however defined, let’s say you have the magical tool that reveals the true and real risk for your organization … ha), you can reduce the risk enough by fixing the 1000, if you have the bandwidth to fix the 1000 (in theory). Now, imagine you have 10m vulns (thanks AI!) and say 5000 are risky. But your bandwidth is there to only fix the 1000. So your risk goes up anyway, while you work as hard as before.

Now, you might say, “Anton, you’re making absolute statements. Surely things are flexible given enough money, enough talented engineers, and these days, enough LLM tokens?”

This is true in theory. But notice I said, “given the IT environment.”

There are definitely methods for accelerating remediation in a modern, beautifully and carefully designed environment (check our podcast episode 109 for those ideas).

But let’s review the scoreboard:

• The speed of vulnerability discovery? Increased.
• The speed of exploit development? Increased.
• The speed of remediation in legacy environments? Unchanged.

OK, some of you might still think “cannot” is too harsh. But people at modern organizations — all DevOps, CI/CD, open source and now AI agents — sometimes cannot comprehend what it takes to deal with a 1990s-era “DBA from Hell” who views his beloved database as a pet, not cattle, and will only allow a patch twice a year on a rigid schedule. Don’t even get me started on OT or the sea of unpatched edge appliances out there (there are “forti” millions of them there, I hear …)

So, yes, I spent years providing recommendations on how to deal with this “vulnerability flood.” This isn’t just about the current fascination with AI; at one point, the “boogeyman” was Metasploit, or something else. Or, as old people told me, SATAN / SANTA in the mid-1990s.

The fact remains: there are more risky vulns than you have time / capability. Today. AI can find the bugs in milliseconds, but it still can’t convince a legacy middleware admin to reboot a production server on a Tuesday. Or in July. Or in 2026. Or this freakin’ century …

So far it sounds like a rehash of my past ideas, but I actually want to leverage some thoughts from Phil Venables’ blog series about speed (“Things Are Getting Wild: Re-Tool Everything for Speed” and “Cybersecurity’s Need for Speed & Where To Find It”)

Before we go there, we must remember about reducing risk without remediating vulnerabilities. This was often the most insightful bit I shared with clients back in my analyst days: Sometimes your focus must be on reducing your risk, rather than fixing the bug. Kinda “assume the breach”, but for vulns: “assume you can’t patch” then what?

So, how do you get speed to break through the sound barrier (alert: these do NOT apply to everybody):

• Brutally destroy legacy systems; if it cannot be patched quickly and safely, don’t use it. Think “SaaS and Chromebooks” (and cloud) world. Don’t think 1980s ERP crap.
• Modernize. Kill pets. Grow cattle. Ideally, get replaceable tiny insects as cattle. They are simpler, more replaceable and less cute. Think “pets -> cattle -> insects.” [P.S. I do not recall where I got this idea, if I stole this from you, I am sorry — happy to restore credit if you tell me]
• Evolve IT culture to accept automatic patching, everywhere. If Chrome can autopatch 1b systems safely for 10 years, perhaps there is a way to do it, eh?
• Eliminate the risk entirely (e.g., via micro-segmentation or data avoidance) when patching is impossible. If you cannot remove the vuln, remove the connection, the system or the entire business process.
• Shift focus from patching to overall IT lifecycle velocity by decoupling the application from infrastructure. In faster IT, patching is faster. Fight friction, just like you fight toil.

These are some ideas on how to shift from “floor the gas” to “build a supersonic plane” to break the patch sound barrier! Are you still debating patch cycles, or are you architecting your way out of the need for them? Please share more!

Enjoy … living in interesting times!

Breaking the Patch Sound Barrier: Your Vulnerability Remediation Will Not Keep Up With AI Exploit… was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

OK, RSA 2026 is over. If my record keeping is correct, I first attended RSA in 2006. At that time, I was annoyed by … AI? XDR? NIDS? …. noooo… I was annoyed by NAC (“As many other RSA observers agreed, under each tree you now see a NAC.” NAC rapidly arose from the “wormy” early 2000s and quickly vanished inside network infrastructure devices).

Anyhow…

If the RSA Conference is the annual, sprawling theme park of the cybersecurity industry, then RSA 2026 was the year the park owners unveiled the shiny, terrifying, and utterly bewildering “AI Rollercoaster.” But as my co-host Tim Peacock and I sniffed around the expo floor, a familiar suspicion crept in: half the queue signs were blatant fabrications, and the ride itself might only be half-built.

For decades, we’ve attended this annual security pilgrimage expecting consolidation, disruption, and an industry growing up. And every year, we leave with the same truth: the more things change, the more they stay the same (and no, I am not old enough to be called “a curmudgeon”). This year, the force of AI agents was everywhere, yet the industry’s response — the good, the bad, and the baffling - revealed more about our collective inability to do the fundamentals than it did about the technology itself.

The first thing you notice about the AI Rollercoaster is the marketing. It’s less about engineering excellence and more about colorful claims that would make a 1890s snake oil salesman blush. Our first, unavoidable observation was the sheer breadth of the AI Hype Spectrum, a problem of which AI washing is one of the levels.

We saw vendors across the spectrum: from those quietly using AI for genuine, impactful security tasks to those who merely “spray painted an AI” onto their 2021 marketing materials and called it a new platform. This latter group — the “AI touch-up” artists — are everywhere, simply adding a comma and the word “agents” to their identity management tools description, firewalls, anti-virus and calling it a day (I have booth pictures, yes)

Look, you are not an AI native company if you launched in 2003 and have a “talk to docs / manuals” chatbot in 2026. BTW, your chatbot can be easily convinced to spout political propaganda because your RAG sucks and you think “restrict via system prompt” is AI security…

This brings me to the first core truth of RSA 2026: to succeed, the buyer must be the expert. It is profoundly disappointing — though not surprising — that in an industry claiming to be on the cusp of a technological revolution (AI AI AI!), our most potent advice for a CISO is a throwback to the days of dial-up: due diligence. BTW, see this quote: “The problem is that most of the people attending the RSA Conference can’t understand what the products do or why they should buy them.” This is…. OH HORROR! .. Bruce Schneier in 2008.

The genuine use of AI in a product is now almost entirely disconnected from the glossy message on the vendor’s booth. You, the buyer, need to dig deep, get technical, and understand what they are actually selling. If they claim AI makes their firewall (or: your SOC) better, tell them to show you the numbers (Better how? Better where? By how much? Depending on what?). If they can’t produce data and solid metrics on how AI improved their thing, you must assume they are not credible and are essentially lying. Sorry, but “cloud native firewall” is not a thing.

And speaking of gloss, a related phenomenon was what we called the “Wiz Effect.” We saw a notable rise in whimsical, information-free booths — lots of pinks, purples, superheroes, and non-security-related sports figures. While a tasteful aesthetic is welcome, this strategy only works if you are already a $32 billion company named Wiz. It did work- and it still does work — for Wiz! Wiz can have soup cans in the booth, and it will sell CNAPP by the million. For others, a fantastical booth merely meant your booth was remembered, but your message was utterly lost. Goats! Also, its low-information density approach compounds the problem of AI washing.

In the past, some clowns predicted that our industry will consolidate and only a dozen large vendors will remain. In 2026, many fear a different Vendor Apocalypse where the large AI labs will simply run over existing security vendors. If a massive LLM can run on an endpoint and perform vulnerability analysis, why do you need a standalone vulnerability scanner? To me, this risk is absolutely real, particularly for product categories like Static Analysis (SAST), which seems custom-made for LLM decimation (reminder: I am not an appsec expert). The same logic applies to firewall rule analysis, policy writing, and many simple IAM/PAM decisions. However, it is not yet clear (my gut says “no”, my brain says “wait for RSA 2027, then ask again”) that the entire industry is vulnerable though…

And this is where the industry’s legendary IT inertia kicks in. The persistence of “The Old” is a stunning, annual lesson in the industry’s resistance to disruption. We saw large booths from vendors whose heyday was decades ago — the fifth best firewall and antivirus vendors are still alive and well as if the calendar still shows 2006. Do you believe that Checkpoint sells “AI security”? They do now! Anyhow, they are still collecting hard-earned money from buyers. This proves that the promised AI disruption has not yet killed off even the “number six” player in a market., much less hurt the #1. “Last vendor on the list is … still ON the list” was my insight here.

Why such epic survival skills? I think it comes down to enterprise knowledge and IT inertia. We debated whether the security industry would survive based on the same concept that keeps human analysts relevant against a giant LLM: the possession of “tribal knowledge.” This is the accumulated, aggregated, and integrated gossip … eh … customer data…that good security vendors hold about their clients’ specific environments. This tacit knowledge, the context of why things are done, is not public, and an AI robot won’t have it today (theoretically, there are ways for them to gather it, to be sure). If your security operation relies on this copious chunk of tribal knowledge, a super-intelligent chatbot won’t replace your vendor — at least not yet.

Another odd observation here. For some vendors, promoting “openness” seems like a signaling maneuver for weakness, not strength. We walked past booths proclaiming “open data lake,” “open detection,” and “open ecosystem.” While I believe openness has inherently positive value, my cynical analyst brain immediately wondered: are they more open or are they just not better? See, vendor A sells EDR, and it is really good. Vendor B EDR sucks compared to vendor A. So they market it as “open EDR” because they cannot market it as “the better EDR” (it ain’t better, even according to them). Reactions?

While the hype around AI for security was overwhelming, there was a positive and genuinely exciting shift: the rise of securing AI and agents. Last year, I lamented the lack of focus on protecting AI systems. This year, I was pleasantly surprised to see vendors focusing on securing agents, securing agent identity, and doing data security for the AI supply chain and training data.

The third pilar of this is the bad guy with AI. To me, the real fear isn’t the “Bad Guy with AI” or even the coming “Bad AI”; the fear is the acceleration of the inevitable. If your security posture is bad before AI, it’s just going to be bad — and faster — after AI. As attackers modernize their business with AI, the average time to compromise will drop even further and — IMHO more importatny — a chance of a compromise will go up (ref this week suppy chain hits)

The ultimate takeaway here is the “boring” lesson: Get the fundamentals right (and, yes, AI can help here too). No amount of AI from a threat actor will exploit your cloud misconfiguration if you don’t have one (well, either cloud or misconfiguration). If your defenses against misconfigured systems, containers, and instances are robust, it doesn’t matter that the bad guy has AI; your stuff is more secure. The acceleration brought by AI will simply kill off “luck-based security.” The old adage is true: if your app has no obvious exploitable holes, there’s nothing for the AI-armed attacker to find. Magic!

So my single piece of advice for dealing with this reality, whether you are a buyer, a seller, or an analyst, is simple: demand the data. Do not let vendors get away with buzzword bingo. If a vendor says AI helps, make them prove it with solid metrics. The time for “trust-me-bro” security better be over!

Finally, some reactions from my 3 sessions. The most shocking reactions came from my “AI SOC” peer discussion on Thursday. I noticed a shocking, near-total lack of enthusiasm about AI SOC startups (total) and AI SOC concepts (near total). The best I got was “AI in a SOC sounds great, we will just wait for our SIEM/SOAR vendor or MDR to build it” and “this is better SOAR and we want this, but later.” And think about it: this was for people biased in favor of AI SOC (because they showed up for the session)… Not sure yet what to think of it!

Fun takes from other people(and there are many) are here (key quote: “Perhaps I’m being overly dramatic but I was surprised with the generally relaxed tone about the impending wave of vulnerabilities and the extent of industrialized attackers coming in the coming quarters. Everyone seems to know vulnerability management isn’t where it needs to be in most companies and what’s coming will pile on the pressure.”), here, here.

Related blogs:

• Our RSA 2026 recap podcast (EP269)
• RSA 2025: AI’s Promise vs. Security’s Past — A Reality Check
• RSA Conference 2025 Recap Podcast
• RSA (“RSAI”) Conference 2024 Powered by AI with AI on Top — AI Edition (Hey AI, Is This Enough AI?)
• EP172 RSA 2024: Separating AI Signal from Noise, SecOps Evolves, XDR Declines?
• RSA 2023: Not Under the GenAI Influence Yet!
• RSA 2023 — What We Saw, What We Learned, and What We’re Excited About
• RSA 2023 — How to Protect Your Organization from Cyberattacks in Time of Political Turmoil
• RSA 2022 Musings: The Past and The Future of Security
• RSA 2020 Reflection
• RSA 2019: Happily Not Over-AI’d
• RSA 2018: Not As Messy As Before?
• RSA 2017: What’s The Theme?
• RSA 2016: Musings and Contemplations
• RSA 2015: Rise of Chaos!!
• RSA 2013 and Endpoint Agent Re-Emergence
• RSA 2006–2015 In Anton’s Blog Posts!
• My Really Fun RSA 2026 Presentations!

RSA 2026: Agentic Future, Analog Fundamentals — The Paradox of Why the Old Guard Still Survives was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

My Anton’s Security Blog (And Podcast!) Quarterly this covers both Anton on Security and my posts from Google Cloud blog, Google Cloud community blog, and our Cloud Security Podcast (subscribe on Spotify, now with VIDEO).

Top 10 posts with the most lifetime views (excluding paper announcement blogs):

1. Anton’s Alert Fatigue: The Study [A.C. — wow, this is still #1 now! Awesome! Perhaps I need more of such deep studies]
2. Security Correlation Then and Now: A Sad Truth About SIEM
3. Can We Have “Detection as Code”?
4. Detection Engineering is Painful — and It Shouldn’t Be (Part 1)
5. Revisiting the Visibility Triad for 2020 (update for 2025 is here!)
6. Beware: Clown-grade SOCs Still Abound
7. Why is Threat Detection Hard?
8. Top 10 SIEM Log Sources in Real Life?
9. A SOC Tried To Detect Threats in the Cloud … You Won’t Believe What Happened Next
10. SOC Visibility Triad is Now A Quad — SOC Visibility Quad 2025

Top 5 posts with paper announcements:

1. New Paper: “Future of the SOC: SOC People — Skills, Not Tiers” (paper 2 of the series)
2. New Paper: “Future of the SOC: Evolution or Optimization — Choose Your Path” (Paper 4 of 4.5) (one more paper coming later in 2026 … we are in reviews now!)
3. New Paper: “Future of the SOC: Forces shaping modern security operations”
4. New Paper: “Future Of The SOC: Process Consistency and Creativity: a Delicate Balance” (Paper 3 of 4)
5. New Paper: “Autonomic Security Operations — 10X Transformation of the Security Operations Center” (the classic 2021 ASO paper!)

3 random fun posts, must-read:

• Simple to Ask: Is Your SOC AI Ready? Not Simple to Answer!
• Shadow Agents: A New Era of Shadow AI Risk in the Enterprise
• Anton’s Vibe Coding Experience: A Reflection on Risk Decisions

Top 7 Cloud Security Podcast by Google episodes (excluding the oldest 3!):

1. EP75 How We Scale Detection and Response at Google: Automation, Metrics, Toil (our best episode! officially!)
2. EP150 Taming the AI Beast: Threat Modeling for Modern AI Systems with Gary McGraw
3. EP47 “Megatrends, Macro-changes, Microservices, Oh My! Changes in 2022 and Beyond in Cloud Security”
4. EP153 Kevin Mandia on Cloud Breaches: New Threat Actors, Old Mistakes, and Lessons for All
5. EP109 How Google Does Vulnerability Management: The Not So Secret Secrets!
6. EP17 Modern Threat Detection at Google
7. EP156 Living Off the Land and Attacking Critical Infrastructure: Mandiant Incident Deep Dive

(also see our NEW 2025 reflections blog about the show)

Now, fun posts by topic.

Security operations / detection & response:

• “Security Correlation Then and Now: A Sad Truth About SIEM”
• “Migrate Off That Old SIEM Already!” (VIDEO, a 2026 update is coming soon!)
• “Measuring the SOC: What Counts and What Doesn’t in 2025?” (Google Cloud Blog)
• “Can We Have “Detection as Code”?”
• “Revisiting the Visibility Triad for 2020” and “SOC Visibility Triad is Now A Quad — SOC Visibility Quad 2025”
• “Beware: Clown-grade SOCs Still Abound”
• “Why is Threat Detection Hard?”
• “A SOC Tried To Detect Threats in the Cloud … You Won’t Believe What Happened Next”
• “Stop Trying to Take Humans Out of SOC … Except … Wait… Wait… Wait…”
• “Top 10 SIEM Log Sources in Real Life?” (NEWER VERSION)
• “Debating SIEM in 2023, Part 1”
• “Debating SIEM in 2023, Part 2”
• “Log Centralization: The End Is Nigh?”
• “Living with Multiple SIEMs”
• “Decoupled SIEM: Brilliant or Stupid?”
• “How to Make Threat Detection Better?”
• “SIEM Content, False Positives and Engineering (Or Not) Security”
• “Modern SecOps Masterclass: Now Available on Coursera”

(if you only read one, choose this one!)

Cloud security:

• “Secure cloud. Insecure use. (And what you can do about it)”
• “Using Cloud Securely — The Config Doom Question”
• “Who Does What In Cloud Threat Detection?”
• “How to Solve the Mystery of Cloud Defense in Depth?”
• “Does the World Need Cloud Detection and Response (CDR)?”
• “Use Cloud Securely? What Does This Even Mean?!”
• “How CISOs need to adapt their mental models for cloud security” [GCP blog]
• “Who Does What In Cloud Threat Detection?”
• “Cloud Migration Security Woes”
• “Move to Cloud: A Chance to Finally Transform Security?”

(if you only read one, choose this one!)

How Google Does Security (HGD):

• “How Google Does It: Making threat detection high-quality, scalable, and modern” (Google Cloud blog)
• “How Google Does It: How we secure our own cloud” (Google Cloud blog)
• “How Google Does It: Securing production services, servers, and workloads”
• “How Google Does It: Finding, tracking, and fixing vulnerabilities” (Google Cloud blog)
• “How Google Does It: Collecting and analyzing cloud forensics”
• “How Google Does It: Red teaming at scale” (Google Cloud blog)
• “How Google Does It: Security programs at global scale” (Google Cloud blog)
• “How Google Does It: Securing production services, servers, and workloads”
• “How Google Does It: Collecting and analyzing cloud forensics”
• “How Google Does It: Applying SRE to cybersecurity”
• “How Google Does It: Building an effective AI red team”

(if you only read one, choose this one! BTW, we also have a lot of fun HGD podcasts)

AI security:

• “Implementing Secure AI Framework Controls in Google Cloud”
• “Office of the CISO 2025 Year in Review: 3 Key AI Security & Governance Themes”
• “Shadow Agents: A New Era of Shadow AI Risk in the Enterprise”
• ”Our Security of AI Papers and Blogs Explained” (2024)
• “Securing AI Supply Chain: Like Software, Only Not” (Google Cloud blog)
• “Spotlighting ‘shadow AI’: How to protect against risky AI practices” (Google Cloud blog)
• “Shadow AI Strikes Back: Enterprise AI Absent Oversight in the Age of Gen AI”
• “Cloud CISO Perspectives: How Google secures AI Agents”
• “New Paper: “Securing AI: Similar or Different?“
• “The Prompt: What to think about when you’re thinking about securing AI” (Google Cloud blog)
• “Gen AI governance: 10 tips to level up your AI program” (Google Cloud blog)
• “AI Adoption: Learning from the Cloud’s Early Days” (Google Community blog)
• “How Google secures AI Agents” (Google Cloud blog)
• “Demystifying AI Security: New Paper on Real-World SAIF Applications”
• “To securely build AI on Google Cloud, follow these best practices” (Google Cloud blog)
• “Oops! 5 serious gen AI security mistakes to avoid” (Google Cloud blog)
• “3 new ways to use AI as your security sidekick” (Google Cloud blog)
• “Shadow Agents: A New Era of Shadow AI Risk in the Enterprise” (Google Cloud Community blog)

(if you only read one, choose this one!)

Fun presentations shared (nothing much new here ):

• SecureWorld 2025 Keynote Déjà Vu All Over Again: Learning from Cloud’s Early Misadventures to Secure AI (2025)
• Detection Engineering Maturity — Helping SIEMs Find Their Adulting Skills (2024)
• Future of SOC: More Security, Less Operations (2024)
• SOC Meets Cloud: What Breaks, What Changes, What to Do? (2023)
• Meet the Ghost of SecOps Future (2023)
• The Future of Log Centralization for SIEMs and DFIR — Is the End Nigh? (2023)
• 20 Years of SIEM (2022)

Enjoy!

Previous posts in this series:

• Anton’s Security Blog Quarterly Q4 2025
• Anton’s Security Blog Quarterly Q3 2025
• Anton’s Security Blog Quarterly Q2 2025
• Anton’s Security Blog Quarterly Q1 2025
• Anton’s Security Blog Quarterly Q4 2024
• Anton’s Security Blog Quarterly Q3 2024
• Anton’s Security Blog Quarterly Q2 2024
• Anton’s Security Blog Quarterly Q1 2024 Lite
• Anton’s Security Blog Quarterly Q3 2023
• Anton’s Security Blog Quarterly Q2 2023
• Anton’s Security Blog Quarterly Q1 2023
• Anton’s Security Blog Quarterly Q4 2022
• Anton’s Security Blog Quarterly Q3 2022
• Anton’s Security Blog Quarterly Q2 2022
• Anton’s Security Blog Quarterly Q1 2022
• Anton’s Security Blog Quarterly Q4 2021
• Anton’s Security Blog Quarterly Q3 2021
• Anton’s Security Blog Quarterly Q2 2021
• Anton’s Security Blog Quarterly Q1 2021
• Anton’s Security Blog Quarterly Q3.5 2020

Anton’s Security Blog Quarterly Q1 2026 was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Look, I’m not a developer, and the last time I truly “wrote code” was probably a good number of years ago (and it was probably Perl so you may hate me). I am also not an appsec expert (as I often remind people).

Below I am describing my experience “vibe coding” an application. Before I go into the details of my lessons — and before this turns into a complete psychotherapy session — I want to briefly describe what the application is supposed to do.

We have a podcast (Cloud Security Podcast by Google), and I often feel that old episodes containing useful information aren’t being listened to and the insights from them go to waste. At the same time, for many organizations today, the answer to their current security problems may well have been discussed and solved in 2021. This may be strange to some, but for many organizations, the future is in the past. Somebody else’s past!

So I wanted “a machine” that turns old episodes into role-specific insights, without too much work by a human (me). This blog is a reflection on how things went.

First, my app is using public data — namely podcast transcripts and audio — to create other public data (social media posts). Since the inputs and outputs are public, this certainly made me at peace with vibe coding. Naturally, I needed to understand how the app would be coded, where it would live and what I should do to make it manifest in the real world. So I asked Gemini, and it suggested I use AI Studio by Google, and I did (non-critically) exactly that.

When I started creating the app, the question of storage immediately came up. Jumping a little bit ahead, you will see that authentication / credentials and storage were two security themes I reflected on the most.

You want to read a file from storage, but what storage? More importantly, whose storage? At this point, I had my first brush with anxiety of the “vibe process.” I didn’t want to just vibe code without a full understanding of the data access machinery. I immediately said, “No, I don’t want to store data in my Google Drive using my credentials.” I just didn’t trust it.

In fact, I didn’t trust the app with any credentials for anything — work or personal — at all! Given that I have public data, I decided to store it in a public web folder. AI Studio suggested ways to store data that people might not fully understand, and this is my other reflection: If I’m not a developer, and I don’t know the machinery behind the app, how do I decide? These decisions are risk decisions and “a citizen vibe coder” is very much not equipped to make them. Well, I sure wasn’t.

So what are the security implications of the decisions a developer makes — sometimes guided by AI and sometimes on their own? Can I truly follow an AI recommendation that I don’t understand? Should I follow it? If you don’t understand what happens, I can assure you, you certainly do not understand the risks!

As a result, I did not trust the app with any credentials or authenticated access. Of course, a solution may have been to use throwaway storage with throwaway credentials, but I think I do not need this in my life... Anyhow, many actions that you take during vibe coding, whether suggested by AI or not, have security implications.

In addition, the app interacts with the environment. If the app is being built in a corporate environment, it interacts with corporate security “rules and tools”, and some things you may want to do wouldn’t work. I’m not going into details, but I had a couple of examples of that. If you vibe code at work and you are doing it through, let’s say, shadow AI, there will be things your AI (and you) would want to do, but your employer security would not allow. And often with good reasons too! So you ask AI for more ways and hope it won’t say “just disable the firewall.”

The next conundrum, apart from storage, was output quality. What about quality and those hallucinatory mistakes? Now, I know my app uses an LLM to condense a summary of the podcast transcript into brief insights for social media. And before my app runs, another LLM turns MP3 into text. And it also uses an LLM to make the visual summaries. So, the question is: who handles the mistakes, and how?

For example, I tried to use a certain “well known” model to create a visual summary. Of course, the visual summary was incredibly accurate in most cases, but sometimes “mistakes were made” and words were corrupted (“verifigement” happened to me in one case). If an LLM powered tool can do something, it does not mean it will do it equally well every time (unless you build validators AND the things that you need to do can in fact be validated). So validate!

Further, I read somewhere that the process for dealing with AI mistakes is different from the process for dealing with human mistakes. I am sure I could write another module for the app to check if an image has correct text or add another validation technique, but it is interesting that I faced this very quickly.

Thus I have to deal with “AI-style mistakes”, and I cannot solve them by having a human review everything. I can tell you right away, even from my small project, that having a human review is a non-starter. It’s theoretically correct, but practically won’t happen. It absolutely will not happen if you take the koolaid and transform your business process to be “AI native.” Having humans review boring tasks like checking image text is completely insane. That’s not going to fly. HITL is DOA (for these tasks).

So: storage, credentials, trust, and quality all came up. Another decision arose when I needed to store intermediate results of my insight generation. Again, trust issues surfaced because data storage. AI Studio suggested choices, I asked AI about pros/cons, and made the decision. Again all these decisions are risk decisions.

Finally, certain mistakes come up all the time, repeatedly, and I have to tell AI Studio to write things multiple times because it doesn’t always “get” it (example: my podcast episode URLs). This is another lesson: sometimes it takes multiple prompts, and constant reminders (say to validate the links)

All in all, I’ll continue to experiment — got more ideas that I want. Here are some outputs of my app…

• On X: example example example
• On LinkedIn: example example

Now the explicit lessons for those who need this crisp and actionable:

1. You Make Implied Security Decisions with Every Prompt

When you “vibe code,” you aren’t just describing features; you are making risk and security decisions. If you ask an AI to “save this data,” and you don’t specify how or where, the AI may choose the path of least resistance — usually a public bucket or a local file with cleartext credentials. In the world of AI-generated code, silence is a security decision.

2. Credentials and Storage: The Boring Stuff is Still the Hard Stuff

Storage and credentials were the key themes for me. This is the great irony of modern development: AI can write a complex LLM orchestration layer in seconds, but it may struggle to help a novice set up a secure, encrypted secrets manager. The “plumbing” of security remains the primary friction point.

3. AI Mistakes Require a New Response Model

Traditional QA seems designed for deterministic human error. AI “style mistakes” (like corrupted words in a visual summary) are stochastic and weird. And common! Human review is a “non-starter” for these tasks. Security and quality validation for AI-generated content must itself be automated (AI-on-AI validation) because humans simply won’t do the “deathly boring” work of checking verbatim accuracy at scale. Turtles all the way down can happen to you.

4. Corporate Guardrails vs. AI Ambition

The AI you vibe code with may not know your corporate policy. It will suggest “awesome” features that would immediately trigger a compliance violation. A few times while vibe coding, I heard a subtle lawyercat meowing in the air duct… When vibe coding in a corporate environment, you quickly hit the wall where “what the AI wants to do” meets “what security allows.” This reinforces the need for platform-level guardrails rather than just merely developer education.

5. Public Data is the Only “Safe” Vibe

My “peace of mind” came from the fact that your inputs and outputs were already public. To me, this is the only way to vibe code safely without a full understanding of the underlying security stack. The moment you move from “public podcast audio” to “proprietary customer data,” the risk model shifts from “fun experiment” to “data breach.”

Anyhow, this was my mildly-AI-assisted stream of vibe consciousness.

Enjoy the show! Now with video!

Anton’s Vibe Coding Experience: A Reflection on Risk Decisions was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is my completely informal, uncertified, unreviewed and otherwise completely unofficial blog inspired by my reading of our next Cloud Threat Horizons Report, #13 (full version, no info to enter!) that we just released (the official blog for #1 report, my unofficial blogs for #2, #3, #4, #5, #6, #7, #8, #9, #10, #11 and #12).

My favorite quotes from the report follow below:

• [in Google Cloud] “software exploitation overtook credentials as the primary initial access vector for the first time.” and “Threat actors exploited third-party software-based entry (44.5%) more frequently than weak credentials.” [A.C. — some of you may say this is because AI is making more zero days, but a dozen more mundane answers may be correct instead]

• “While threat actors continued to use brute-force attacks against weak credentials, the increase in RCE represents a pivot toward more automated exploitation of unpatched application-layer vulnerabilities.” [A.C. — to some extent “creds or vulns” debate is rather pointless as the real answer is “both”, and it varies by environment too, see below]
• “Threat actors continued to transition from traditional phishing to voice-based social engineering (vishing), and credential harvesting from third-party SaaS tokens to facilitate large-scale, silent data exfiltration.” [A.C. — again, this means “AND” not “OR” because classic phishing still works well in many cases, but yes “credential harvesting from third-party SaaS” has become very fruitful too]
• [overall] Still “Identity compromise underpinned 83% of compromises. [A.C. — so, yes, “creds” still beat “vulns” on many environments]

• “High-volume data theft operations — executed through compromised but legitimate access channels — remained the primary goal for threat actors, with our metrics showing they targeted data in 73% of cloud-related incidents.” [A.C. — again, not new, but very useful data confirming the running trend. Beware!]
• “The window between vulnerability disclosure and mass exploitation collapsed by an order of magnitude, from weeks to days.” [A.C. — again, some of you may see the invisible robot hand of an AI here, but, as usual, the reality is more complicated…]
• “Trend analysis from 2008–2025 indicates cloud services will soon surpass email as the primary data exfiltration pathway.” [A.C. — $32B reasons to finally get serious about it across all clouds?]
• “45% of intrusions resulted in data theft without immediate extortion attempts at the time of the engagement, and these were often characterized by prolonged dwell times and stealthy persistence.”
• “The traditional incident response model is no longer viable when dealing with containerized workloads and serverless architectures where data can vanish in seconds.” [A.C. — a very useful reminder here! Cloud is cloudy! Don’t be that guy who thinks that cloud is a rented colo. Cloud is not JUST somebody else’s computer.]
• “Threat actors used large language models (LLM) to automate credential harvesting and transition from a developer’s local environment to full cloud administration access.” [A.C. — this really should not be news for anybody in 2026, but if it is, HERE IS SOME NEWS: BAD GUYS USE AI!]
• Thus “Prevent LLM exploitation as an extension of living-off-the-land (LOTL) by treating LLM activity with the same scrutiny as administrative command-line tools.” [A.C. — or, as I say, “with AI agents, every prompt injection is an RCE”]

Now, go and read the CTHR 13 report!

Related posts:

• Google Cloud Security Threat Horizons Report #12 Is Out!
• EP112 Threat Horizons — How Google Does Threat Intelligence podcast
• Google Cloud Security Threat Horizons Report #11 Is Out!
• Google Cloud Security Threat Horizons Report #10 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #9 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #8 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #7 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #6 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #5 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #4 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #3 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #2 Is Out!
• Illicit coin mining, ransomware, APTs target cloud users in first Google
• Cybersecurity Action Team Threat Horizons report

Google Cloud Security Threat Horizons Report #13 (H1 2026) Is Out! was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

This blog is perhaps a little bit more like an ad, so if you don’t want to check the ads, consider not reading it.

But this year at RSA 2026, I’m speaking on three topics: securing AI, using AI for SOC, and sharing lessons about how Google applies AI and other technologies to D&R.

Here are these 3 fun things!

First, I’m doing a presentation on governing shadow AI agents. Believe it or not, this presentation was created mostly before OpenClaw became a thing (but updated for it!). So you may be surprised how well the content aged (think wine!) Attend this if you are struggling with shadow AI, specifically shadow agents at work.

Shadow Agents: A Pragmatist’s Guide to Governing Unsanctioned AI — [STR-W08]

• Wednesday, Mar 25 1:15 PM — 2:05 PM PDT

It is not the APT! The new threat is the “shadow AI agents” employees already use for work, leaking data and making decisions. Banning them is a losing game. This session will offer a better way: turn this organic behavior into a catalyst for secure progress. Learn to discover, assess, and channel unsanctioned agents into a formal strategy that empowers a team rather than force it underground.

The second is probably the most detailed discussion about how we use AI for detection and response at Google. You probably read our blogs and listen to our talks (especially this), but this time we are revealing a lot more interesting details about the machinery and also how we arrived at the state we’re in. I promise you this will be fun! And detailed too.

This Is How We Do It: Building AI Agents for Cybersecurity and Defense — [PART3-M07]

• Monday, Mar 23 2:20 PM — 3:10 PM PDT

Presenters will share the playbook for building and scaling AI agents in cybersecurity. Attendees will learn four core lessons: Building trust with the team, prioritizing real problems, measuring value, and establishing solid governance foundations for the agentic SOC.

Finally, the third isn’t a presentation but a discussion that would help you understand the real state of AI in security operations / SOC. This would not be about the slides, but about sharing lessons on what works and what doesn’t.

AI in SecOps: Sharing Lessons Learned for Adoption Maturity — [CXN-R05]

• Thursday, Mar 26 12:20 PM — 1:10 PM PDT

Attendees in this peer-led discussion will share stories from the AI-powered SOC trenches. Explore real adoption journeys from manual processes to autonomous agents. Share practical use cases on analyst retraining, workflow auditing, malware analysis, remediation automation, RAG pipelines and more. Trade notes on what’s working, what’s breaking, trust gaps, AI hallucinations, and career redesign.

All in all, join me for securing AI and Shadow Agents, learning from Google about detection and response, and comparing the state of practice of AI in the SOC.

See you there!

P.S. Yes, we will also be podcasting from the show.

Related:

RSA 2025: AI’s Promise vs. Security’s Past — A Reality Check”

My Really Fun RSA 2026 Presentations! was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

You read the “AI-ready SOC pillars” blog, but you still see a lot of this:

How do we do better?

Let’s go through all 5 pillars aka readiness dimensions and see what we can actually do to make your SOC AI-ready.

#1 SOC Data Foundations

As I said before, this one is my absolute favorite and is at the center of most “AI in SOC” (as you recall, I want AI in my SOC, but I dislike the “AI SOC” concept) successes (if done well) and failures (if not done at all).

Reminder: pillar #1 is “security context and data are available and can be queried by machines (API, Model Context Protocol (MCP), etc) in a scalable and reliable manner.” Put simply, for the AI to work for you, it needs your data. As our friends say here, “Context engineering focuses on what information the AI has available. […] For security operations, this distinction is critical. Get the context wrong, and even the most sophisticated model will arrive at inaccurate conclusions.”

Readiness check: Security context and data are available and can be queried by machines in a scalable and reliable manner. This is very easy to check, yet not easy to achieve for many types of data.

For example, “give AI access to past incidents” is very easy in theory (“ah, just give it old tickets”) yet often very hard in reality (“what tickets?” “aren’t some too sensitive?”, “wait…this ticket didn’t record what happened afterwards and it totally changed the outcome”, “well, these tickets are in another system”, etc, etc)

Steps to get ready:

• Conduct an “API or Die” data access audit to inventory critical data sources (telemetry and context) and stress-test their APIs (or other access methods) under load to ensure they can handle frequent queries from an AI agent. This is important enough to be a Part 3 blog after this one…
• Establish or refine unified, intentional data pipelines for the data you need. This may be your SIEM, this may be a separate security pipeline tool, this may be magick for all I care … but it needs to exist. I met people who use AI to parse human analyst screen videos to understand how humans access legacy data sources, and this is very cool, but perhaps not what you want in prod.
• Revamp case management to force structured data entry (e.g., categorized root causes, tagged MITRE ATT&CK techniques) instead of relying on garbled unstructured text descriptions, which provides clean training data for future AI learning. And, yes, if you have to ask: modern gen AI can understand your garbled stream of consciousness ticket description…. but what it makes of it, you will never know…

Where you arrive: your AI component, AI-powered tool or AI agent can get the data it needs nearly every time. The cases where it cannot become visible, and obvious immediately.

#2 SOC Process Framework and Maturity

Reminder: pillar #2 is “Common SOC workflows do NOT rely on human-to-human communication are essential for AI success.” As somebody called it, you need “machine-intelligible processes.”

Readiness check: SOC workflows are defined as machine-intelligible processes that can be queried programmatically, and explicit, structured handoff criteria are established for all Human-in-the-Loop (HITL) processes, clearly delineating what is handled by the agent versus the person. Examples for handoff to human may include high decision uncertainty, lack of context to make a call (see pillar #1), extra-sensitive systems, etc.

Common investigation and response workflows do not rely on ad-hoc, human-to-human communication or “tribal knowledge,” such knowledge is discovered and brought to surface.

Steps to get ready:

• Codify the “Tribal Knowledge” into APIs: Stop burying your detection logic in dusty PDFs or inside the heads of your senior analysts. You must document workflows in a structured, machine-readable format that an AI can actually query. If your context — like CMDB or asset inventory — isn’t accessible via API (BTW MCP is not magic!), your AI is essentially flying blind.
• Draw a Hard Line Between Agent and Human: Don’t let the AI “guess” its level of authority. Explicitly delegate the high-volume drudgery (log summarization, initial enrichment, IP correlation) to the agent, while keeping high-stakes “kill switches” (like shutting down production servers) firmly in human hands.
• Implement a “Grading” System for Continuous Learning: AI shouldn’t just execute tasks; it needs to go to school. Establish a feedback loop where humans actively “grade” the AI’s triage logic based on historical resolution data. This transforms the system from a static script into a living “recipe” that refines itself over time.
• Target Processes for AI-Driven Automation: Stop trying to “AI all the things.” Identify specific investigation workflows that are candidates for automation and use your historical alert triage data as a training ground to ensure the agent actually learns what “good” looks like.

Where you arrive: The “tribal knowledge” that previously drove your SOC is recorded for machine-readable workflows. Explicit, structured handoff points are established for all Human-in-the-Loop processes, and the system uses human grading to continuously refine its logic and improve its ‘recipe’ over time. This does not mean that everything is rigid; “Visio diagram or death” SOC should stay in the 1990s. Recorded and explicit beats rigid and unchanging.

#3 SOC Human Element and Skills

Reminder: pillar #3 is “Cultivating a culture of augmentation, redefining analyst roles, providing training for human-AI collaboration, and embracing a leadership mindset that accepts probabilistic outcomes.” You say “fluffy management crap”? Well, I say “ignore this and your SOC is dead.”

Readiness check: Leaders have secured formal CISO sign-off on a quantified “AI Error Budget,” defining an acceptable, measured, probabilistic error rate for autonomously closed alerts (that is definitely not zero, BTW). The team is evolving to actively review, grade, and edit AI-generated logic and detection output.

Steps to get ready:

• Implement the “AI Error Budget”: Stop pretending AI will be 100% accurate. You must secure formal CISO sign-off on a quantified “AI Error Budget” — a predefined threshold for acceptable mistakes. If an agent automates 1,000 hours of labor but has a 5% error rate, the leadership needs to acknowledge that trade-off upfront. It’s better to define “allowable failure” now than to explain a hallucination during an incident post-mortem.
• Pivot from “Robot Work” to Agent Shepherding: The traditional L1/L2 analyst role is effectively dead; long live the “Agent Supervisor.” Instead of manually sifting through logs — work that is essentially “robot work” anyway — your team must be trained to review, grade, and edit AI-generated logic. They are no longer just consumers of alerts; they are the “Editors-in-Chief” of the SOC’s intelligence.
• Rebuild the SOC Org Chart and RACI: Adding AI isn’t a “plug and play” software update; it’s an organizational redesign. You need to redefine roles: Detection Engineers become AI Logic Editors, and analysts become Supervisors. Most importantly, your RACI must clearly answer the uncomfortable question: If the AI misses a breach, is the accountability with the person who trained the model or the person who supervised the output?

Where you arrive: well, you arrive at a practical realization that you have “AI in SOC” (and not AI SOC). The tools augment people (and in some cases, do the work end to end too). No pro- (“AI SOC means all humans can go home”) or contra-AI (“it makes mistakes and this means we cannot use it”) crazies nearby.

#4 Modern SOC Technology Stack

Reminder: pillar #4 is “Modern SOC Technology Stack.” If your tools lack APIs, take them and go back to the 1990s from whence you came! Destroy your time machine when you arrive, don’t come back to 2026!

Readiness check: The security stack is modern, fast (“no multi-hour data queries”) interoperable and supports new AI capabilities to integrate seamlessly, tools can communicate without a human acting as a manual bridge and can handle agentic AI request volumes.

Steps to get ready:

• Mandate “Detection-as-Code” (DaC): This is no longer optional. To make your stack machine-readable, you must implement version control (Git), CI/CD pipelines, and automated testing for all detections. If your detection logic isn’t codified, your AI agent has nothing to interact with except a brittle GUI — and that is a recipe for failure.
• Find Your “Interoperability Ceiling” via Stress Testing: Before you go live, simulate reality. Have an agent attempt to enrich 50 alerts simultaneously to see where the pipes burst. Does your SOAR tool hit a rate limit? Does your threat intel provider cut you off? You need to find the breaking point of your tech stack’s interoperability before an actual incident does it for you.
• Decouple “Native” from “Custom” Agents: Don’t reinvent the wheel, but don’t expect a vendor’s “native” agent to understand your weird, proprietary legacy systems. Define a clear strategy: use native agents for standard tool-specific tasks, and reserve your engineering resources for custom agents designed to navigate your unique compliance requirements and internal “secret sauce.”

Where you arrive: this sounds like a perfect quote from Captain Obvious but you arrive at the SOC powered by tools that work with automation, and not with “human bridge” or “swivel chair.”

#5 SOC Metrics and Feedback Loop

Reminder: pillar #5 is “You are ready for AI if you can, after adding AI, answer the “what got better?” question. You need metrics and a feedback loop to get better.”

Readiness check: Hard baseline metrics (MTTR, MTTD, false positive rates) are established before AI deployment, and the team has a way to quantify the value and improvements resulting from AI. When things get better, you will know it.

Steps to get ready:

• Establish the “Before” Baseline and Fix the Data Slop: You cannot claim victory if you don’t know where the goalposts were to begin with. Measure your current MTTR and MTTD rigorously before the first agent is deployed. Simultaneously, force your analysts to stop treating case notes like a private diary. Standardize on structured data entry — categorized root causes and MITRE tags — so the machine has “clean fuel” to learn from rather than a collection of “fixed it” or “closed” comments.
• Build an “AI Gym” Using Your “Golden Set”: Do not throw your agents into the deep end of live production traffic on day one. Curate a “Golden Set” of your 50–100 most exemplary past incidents — the ones with flawless notes, clean data, and correct conclusions. This serves as your benchmark; if the AI can’t solve these “solved” problems correctly, it has no business touching your live environment.
• Adopt Agent-Specific KPIs for Performance Management: Traditional SOC metrics like “number of alerts closed” are insufficient for an AI-augmented team. You need to track Agent Accuracy Rate, Agent Time Savings, and Agent Uptime as religiously as you track patch latency. If your agent is hallucinating 5% of its summaries, that needs to be a visible red flag on your dashboard, not a surprise you discover during an incident post-mortem.
• Close the Loop with Continuous Tuning: Ensure triage results aren’t just filed away to die in an archive. Establish a feedback loop where the results of both human and AI investigations are automatically routed back to tune the underlying detection rules. This transforms your SOC from a static “filter” into a learning system that evolves with every alert.

Where you arrive: you have a fact-based visual that shows your SOC becoming better in ways important to your mission after you add AI (in fact, you SOC will get better even before AI but after you do the prep-work from this document)

As a result, we can hopefully get to this instead:

The path to an AI-ready SOC isn’t paved with new tools; it’s paved with better data, cleaner processes, and a fundamental shift in how we think about human-machine collaboration. If you ignore these pillars, your AI journey will be a series of expensive lessons in why “magic” isn’t a strategy.

But if you get these right? You move from a SOC that is constantly drowning in alerts to a SOC that operates truly 10X effectiveness.

P.S. Anton, you said “10X”, so how does this relate to ASO and “engineering-led” D&R? I am glad you asked. The five pillars we outlined are not just steps for AI; they are the also steps on the road to ASO (see original 2021 paper which is still “the future” for many).

ASO is the vision for a 10X transformation of the SOC, driven by an adaptive, agile, and highly automated approach to threats. The focus on codified, machine-intelligible workflows, a modern stack supporting Detection-as-Code, and reskilling analysts as “Agent Supervisors” directly supports the core of engineering-led D&R. So focusing on these five readiness dimensions, you move from a traditional operations room (lots of “O” for operations) to a scalable, engineering-centric D&R function (where “E” for engineering dominates).

So, which pillar is your SOC’s current ‘weakest link’? Let’s discuss in the comments and on socials!

Related blogs and podcasts:

• “Simple to Ask: Is Your SOC AI Ready? Not Simple to Answer!” (Part 1 to this blog)
• “Modern SecOps: What an AI-ready SOC actually means with Anton Chuvakin” video
• “A Brief Guide for Dealing with ‘Humanless SOC’ Idiots” (the classic!)
• “SOC is Not Dead Yet It May Be Reborn As Security Operations Center of Excellence” (oddly related!)
• EP236 Accelerated SIEM Journey: A SOC Leader’s Playbook for Modernization and AI
• EP242 The AI SOC: Is This The Automation We’ve Been Waiting For?
• EP252 The Agentic SOC Reality: Governing AI Agents, Data Fidelity, and Measuring Success
• EP249 Data First: What Really Makes Your SOC ‘AI Ready’?

Beyond “Is Your SOC AI Ready?” Plan the Journey! was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Amazingly, Medium has fixed the stats so my blog / podcast quarterly is back to life. As before, this covers both Anton on Security and my posts from Google Cloud blog, Google Cloud community blog, and our Cloud Security Podcast (subscribe on Spotify).

Top 10 posts with the most lifetime views (excluding paper announcement blogs):

1. Anton’s Alert Fatigue: The Study [A.C. — wow, this is still #1 now! Awesome! Perhaps I need more of such deep studies]
2. Security Correlation Then and Now: A Sad Truth About SIEM
3. Can We Have “Detection as Code”?
4. Revisiting the Visibility Triad for 2020 (update for 2025 is here!)
5. Detection Engineering is Painful — and It Shouldn’t Be (Part 1)
6. Beware: Clown-grade SOCs Still Abound
7. Why is Threat Detection Hard?
8. A SOC Tried To Detect Threats in the Cloud … You Won’t Believe What Happened Next
9. Anton and The Great XDR Debate, Part 1
10. Log Centralization: The End Is Nigh?

Top 5 posts with paper announcements:

• New Paper: “Future of the SOC: SOC People — Skills, Not Tiers” (paper 2 of the series)
• New Paper: “Future of the SOC: Evolution or Optimization — Choose Your Path” (Paper 4 of 4.5) (one more paper coming later in 2026 … we are researching now!)
• New Paper: “Future of the SOC: Forces shaping modern security operations”
• New Paper: “Future Of The SOC: Process Consistency and Creativity: a Delicate Balance” (Paper 3 of 4)
• New Paper: “Autonomic Security Operations — 10X Transformation of the Security Operations Center” (the classic 2021 ASO paper!)
• New Paper: “Future of SOC: Transform the ‘How’” (Paper 5)
• New Paper: “Securing AI: Similar or Different?“
• New Office of the CISO Paper: Organizing Security for Digital Transformation” (paper)
• 10 ways to make cyber-physical systems more resilient” (paper)

NEW: recent 3 fun posts, must-read:

• Simple to Ask: Is Your SOC AI Ready? Not Simple to Answer! (is your SOC AI-ready?)
• Shadow Agents: A New Era of Shadow AI Risk in the Enterprise (see you at RSA 2026!)
• Decoupled SIEM: Where I Think We Are Now? (this is not over yet!)

Top 7 Cloud Security Podcast by Google episodes (excluding the oldest 3!):

1. EP75 How We Scale Detection and Response at Google: Automation, Metrics, Toil (our best episode! officially!)
2. EP47 “Megatrends, Macro-changes, Microservices, Oh My! Changes in 2022 and Beyond in Cloud Security”
3. EP153 Kevin Mandia on Cloud Breaches: New Threat Actors, Old Mistakes, and Lessons for All
4. EP8 Zero Trust: Fast Forward from 2010 to 2021
5. EP109 How Google Does Vulnerability Management: The Not So Secret Secrets!
6. EP150 Taming the AI Beast: Threat Modeling for Modern AI Systems with Gary McGraw
7. EP17 Modern Threat Detection at Google

(also see our NEW 2025 reflections blog about the show)

Now, fun posts by topic.

Security operations / detection & response:

• “Security Correlation Then and Now: A Sad Truth About SIEM”
• “Migrate Off That Old SIEM Already!” (VIDEO!)
• “Measuring the SOC: What Counts and What Doesn’t in 2025?” (Google Cloud Blog)
• “Can We Have “Detection as Code”?”
• “Revisiting the Visibility Triad for 2020” and “SOC Visibility Triad is Now A Quad — SOC Visibility Quad 2025”
• “Beware: Clown-grade SOCs Still Abound”
• “Why is Threat Detection Hard?”
• “A SOC Tried To Detect Threats in the Cloud … You Won’t Believe What Happened Next”
• “Stop Trying to Take Humans Out of SOC … Except … Wait… Wait… Wait…”
• “Top 10 SIEM Log Sources in Real Life?” (NEWER VERSION)
• “Debating SIEM in 2023, Part 1”
• “Debating SIEM in 2023, Part 2”
• “Log Centralization: The End Is Nigh?”
• “Living with Multiple SIEMs”
• “Decoupled SIEM: Brilliant or Stupid?”
• “How to Make Threat Detection Better?”
• “SIEM Content, False Positives and Engineering (Or Not) Security”
• “Modern SecOps Masterclass: Now Available on Coursera”

(if you only read one, choose this one!)

Cloud security:

• “Secure cloud. Insecure use. (And what you can do about it)”
• “Using Cloud Securely — The Config Doom Question”
• “Who Does What In Cloud Threat Detection?”
• “How to Solve the Mystery of Cloud Defense in Depth?”
• “Does the World Need Cloud Detection and Response (CDR)?”
• “Use Cloud Securely? What Does This Even Mean?!”
• “How CISOs need to adapt their mental models for cloud security” [GCP blog]
• “Who Does What In Cloud Threat Detection?”
• “Cloud Migration Security Woes”
• “Move to Cloud: A Chance to Finally Transform Security?”
• “It’s a multicloud jungle out there. Here’s how your security can survive“

(if you only read one, choose this one!)

How Google Does Security (HGD):

• “How Google Does It: Making threat detection high-quality, scalable, and modern” (Google Cloud blog)
• “How Google Does It: How we secure our own cloud” (Google Cloud blog)
• “How Google Does It: Securing production services, servers, and workloads”
• “How Google Does It: Finding, tracking, and fixing vulnerabilities” (Google Cloud blog)
• “How Google Does It: Collecting and analyzing cloud forensics”
• “How Google Does It: Red teaming at scale” (Google Cloud blog)
• “How Google Does It: Security programs at global scale” (Google Cloud blog)

(if you only read one, choose this one! BTW, we also have a lot of fun HGD podcasts)

AI security:

• ”Our Security of AI Papers and Blogs Explained” (2024)
• “Securing AI Supply Chain: Like Software, Only Not” (Google Cloud blog)
• “Spotlighting ‘shadow AI’: How to protect against risky AI practices” (Google Cloud blog)
• “Shadow AI Strikes Back: Enterprise AI Absent Oversight in the Age of Gen AI”
• “No Deep AI Security Secrets In This Post!”
• “Cloud CISO Perspectives: How Google secures AI Agents”
• “New Paper: “Securing AI: Similar or Different?“
• “The Prompt: What to think about when you’re thinking about securing AI” (Google Cloud blog)
• “Gen AI governance: 10 tips to level up your AI program” (Google Cloud blog)
• “AI Adoption: Learning from the Cloud’s Early Days” (Google Community blog)
• “How Google secures AI Agents” (Google Cloud blog)
• “Demystifying AI Security: New Paper on Real-World SAIF Applications”
• “To securely build AI on Google Cloud, follow these best practices” (Google Cloud blog)
• “Oops! 5 serious gen AI security mistakes to avoid” (Google Cloud blog)
• “3 new ways to use AI as your security sidekick” (Google Cloud blog)
• “Shadow Agents: A New Era of Shadow AI Risk in the Enterprise” (Google Cloud Community blog)

(if you only read one, choose this one!)

Fun presentations shared (nothing much new here):

• SecureWorld 2025 Keynote Déjà Vu All Over Again: Learning from Cloud’s Early Misadventures to Secure AI (2025)
• Detection Engineering Maturity — Helping SIEMs Find Their Adulting Skills (2024)
• Future of SOC: More Security, Less Operations (2024)
• SOC Meets Cloud: What Breaks, What Changes, What to Do? (2023)
• Meet the Ghost of SecOps Future (2023)
• The Future of Log Centralization for SIEMs and DFIR — Is the End Nigh? (2023)
• 20 Years of SIEM (2022)

Enjoy!

Previous posts in this series:

• Anton’s Security Blog Quarterly Q3 2025
• Anton’s Security Blog Quarterly Q2 2025
• Anton’s Security Blog Quarterly Q1 2025
• Anton’s Security Blog Quarterly Q4 2024
• Anton’s Security Blog Quarterly Q3 2024
• Anton’s Security Blog Quarterly Q2 2024
• Anton’s Security Blog Quarterly Q1 2024 Lite
• Anton’s Security Blog Quarterly Q3 2023
• Anton’s Security Blog Quarterly Q2 2023
• Anton’s Security Blog Quarterly Q1 2023
• Anton’s Security Blog Quarterly Q4 2022
• Anton’s Security Blog Quarterly Q3 2022
• Anton’s Security Blog Quarterly Q2 2022
• Anton’s Security Blog Quarterly Q1 2022
• Anton’s Security Blog Quarterly Q4 2021
• Anton’s Security Blog Quarterly Q3 2021
• Anton’s Security Blog Quarterly Q2 2021
• Anton’s Security Blog Quarterly Q1 2021
• Anton’s Security Blog Quarterly Q3.5 2020

Anton’s Security Blog Quarterly Q4 2025 was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

(written jointly with Tim Peacock)

Five years. It’s enough time to fully launch a cloud migration, deploy a new SIEM, or — if you’re a very large enterprise — just start thinking about doing the first two. It’s also how long Tim and I have been subjecting the world to our thoughts on Cloud Security Podcast by Google.

We finally got around to writing the annual “reflections blog.” And, honestly, looking back at Season 5, the state of the industry feels a lot like a chaotic Cybersecurity Garage Sale.

We’re all standing knee-deep in a pile of dusty, obsolete junk — the mid-2000s SIEMs, the 1990s unauthenticated vulnerability scans — while clutching shiny, still-in-the-box AI Agent gadgets we don’t quite know where to put. It’s a mess. But within this mess, a few essential, high-value items have emerged.

So, to all our listeners — the veterans and the newcomers — thank you for sorting through the chaos with us. For Season 6, we’re going all video, by default (opening January 5, 2026). Find us on our new YouTube home: Cloud Security Podcast by Google on YouTube.

Below you will find 3 fun sections: Anton’s faves, Tim’s faves and top 10 by listens (“data’s faves” of sorts, or perhaps listener faves)

Enjoy!

Anton: My selections are, perhaps, a bit predictable — but they were immense fun to record and, I believe, are absolutely essential listening! But, hey, I am biased a bit!

1. EP236 Accelerated SIEM Journey: A SOC Leader’s Playbook for Modernization and AI This fun episode provides a playbook for SOC leaders on accelerating their SIEM modernization journey. We go into the steps the bank took for moving beyond legacy systems, focusing on how to integrate AI for transformative results and build a truly modern Security Operations Center.
2. EP254 Escaping 1990s Vulnerability Management: From Unauthenticated Scans to AI-Driven Mitigation This essential episode with Caleb Hoch tackles the “fractions of a century” time lag in vulnerability management, moving beyond endless unauthenticated scans. We discuss how to establish a Gold Standard prioritization model and why running VM Tabletop Exercises is the vital, transformative practice needed for true modernization.
3. EP223 AI Addressable, Not AI Solvable: Reflections from RSA 2025 The single most important lesson from RSA 2025 was captured in this episode: AI is merely “Addressable, Not Solvable.” We cut through the hype to discuss where AI can deliver real, practical security value, and where we still need our smart human colleagues to lead the way. This is essential listening for anyone trying to navigate the flood of vendor claims.
4. EP242 The AI SOC: Is This The Automation We’ve Been Waiting For? This epic episode tackles the most pressing question for security operations: Can “AI SOC” deliver the transformative automation we’ve been waiting for? We discuss — with Anton’s former colleague — the real-world applications of AI in the SOC, focusing on practical gains (and how to know you “gained” anything) and what it means for the future role of the human analyst.
5. EP238 Google Lessons for Using AI Agents for Securing Our Enterprise This fun episode brings you practical lessons from Google’s own experience using AI agents to secure our enterprise at scale (see this blog also). We dive (not “delve”, mind you!) deep into the real-world application of this technology, focusing on the wins, the challenges, and what it took to adopt. This is essential listening for any leader looking to leverage AI agents effectively without falling into the hype cesspool.
6. BONUS: EP237 Making Security Personal at the Speed and Scale of TikTok This unique episode goes into what it takes to secure a hyper-scale, global platform like TikTok. We discuss how to move beyond legacy compliance while living in a modern microservices architecture, balance a consistent global security posture with localized regulatory demands, and, most importantly, empower every user with practical tips (like 2FA and strong passphrases) to make security personal.

Tim: My picks are almost entirely not overlapping with Anton, we started our lists separately, but then realized that we scooped each other on two episodes. We both liked our episode with Manija Poulatova enough to keep her on both of our lists!

1. EP256 Rewiring Democracy & Hacking Trust: Bruce Schneier on the AI Offense-Defense Balance This episode is a total delight for both of us. For me, I got to not only meet one of my security heroes, I got to see Anton do the same! We named Bruce in our early planning docs as somebody we’d like to have on the show someday when we’re all grown up. Not a bad way to wrap up five years of weekly podcasting!
2. EP236 Accelerated SIEM Journey: A SOC Leader’s Playbook for Modernization and AI Manija and I were on a panel together in Las Vegas during Google Cloud Next 2025. A few themes from that panel came through in our episode together that I love and think are vital for anyone. First, aim for transformation not migration. As an industry we are not doing so well compared to air transport safety. We cannot cling to our old ways and hope for a better set of outcomes. Second, AI is here to enable our human colleagues, not replace them. We can find greater meaning, joy, and productivity in our work, even as SOC analysts, once we embrace what AI can automate for us.
3. EP239 Linux Security: The Detection and Response Disconnect and Where Is My Agentless EDR Craig was introduced to me by Friend Of The Show (and friend of mine!) Vijay Ganti (EP196) as someone building an innovative approach to EDR security. Scheduling this episode ended up a little tricky, and I got to do an episode without Anton. That ended up ok, because in Craig I found a totally kindred spirit. We’ve both built systems to secure Linux without agents, though from two different approaches. His stories of finding badness in places we couldn’t previously look, and doing so scalably even for phone towers up the hill behind his house, really resonated with the part of me that spent four years building out Virtual Machine Threat Detection here at Google Cloud. This is definitely an episode for listeners who like to question conventional security thinking.
4. EP252 The Agentic SOC Reality: Governing AI Agents, Data Fidelity, and Measuring Success Another fun origin story: this episode was conceived in a karaoke booth in Singapore. Alex and Lars are two of our early design partners for the SecOps Triage Agent and their feedback to the team and on this episode is super valuable. Alex gets bonus points on this episode for using the word squelch which I’ve been pushing internally as a metaphor for our noise control systems. This is a must-listen for anyone interested in real AI adoption in their SOC. If Alex and Lars can do it across an unbelievable number of regulatory jurisdictions, you can too!
5. EP255 Separating Hype from Hazard: The Truth About Autonomous AI Hacking Bringing Heather back to the show has been a goal of ours for ages. When I read her article, coauthored with Gadi Evron and Bruce Schneier, I knew I’d found our topic. As I said on the show, if I’d seen this article written by anybody else I’d laugh, but with this trio of authors I knew it was something to take seriously. Read the article, listen to the episode, let us know in the comments if you’re as scared as I was!
6. BONUS: EP232 The Human Element of Privacy: Protecting High-Risk Targets and Designing Systems I get one bonus episode for our top ten, so I’m going to include my classmate Sarah Aoun. She is an amazing Googler and on this episode she offers advice that’s useful almost universally, but especially if you believe that you’re a person who is at risk of being targeted online. This is firmly outside of our “cloud security” wheelhouse, but well worth a listen to understand threat modeling and security response for individuals.

Top 10 episodes by listens (excluding the oldest 3)

1. EP75 How We Scale Detection and Response at Google: Automation, Metrics, Toil
2. EP47 “Megatrends, Macro-changes, Microservices, Oh My! Changes in 2022 and Beyond in Cloud Security”
3. EP153 Kevin Mandia on Cloud Breaches: New Threat Actors, Old Mistakes, and Lessons for All
4. EP8 Zero Trust: Fast Forward from 2010 to 2021
5. EP109 How Google Does Vulnerability Management: The Not So Secret Secrets!
6. EP150 Taming the AI Beast: Threat Modeling for Modern AI Systems with Gary McGraw
7. EP17 Modern Threat Detection at Google
8. EP103 Security Incident Response and Public Cloud — Exploring with Mandiant
9. EP156 Living Off the Land and Attacking Critical Infrastructure: Mandiant Incident Deep Dive
10. EP12 Threat Models and Cloud Security

Related blogs:

• 250 Episodes of Cloud Security Podcast by Google: From Confidential Computing to AI-Ready SOC

2025 Year in Review at Cloud Security Podcast by Google was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

So this may suck, but I am hoping to at least earn some points for honesty here. I wanted to write something pithy and smart once I realized our Cloud Security Podcast by Google just aired our 250th episode (“EP250 The End of “Collect Everything”? Moving from Centralization to Data Access?”). Yet nothing sufficiently pithy came to my mind …

… so I went around and asked a whole bunch of AIs and agents and such. Then massaged and aggregated the outputs, then ran more AI on the result. And then lightly curated it. Then deleted the bottom 2 stupidest points they made.

So, here it comes … in all its sloppy glory!

1. The Foundational Roots and Unchanging Mission: Our show started with foundational cloud security topics — like Zero Trust, Data Security, and Cloud Migration Security which drew the initial large audiences. The core commitment since Episode 1 has been to question conventional wisdom, avoid “security theater” (EP248) and explore whether security measures truly benefit the user and the organization.
2. The AI Transformation: We had a sizable shift with the last 50 episodes, where AI became a central theme, or at least one of the themes we always come back to (and, yes, this covers our 3 pillars of securing AI, AI for security and countering the AI-armed attacker). The focus has moved past general hype to practical applications, securing AI systems, and asking challenging questions like “Data readiness for AI SOC” (EP249).
3. The Enduring Popularity of Detection & Response (D&R): We highlight that D&R and modernizing the SOC continue to be extremely popular with the audience (EP236 is epic). Trace the evolution of this topic from foundational engineering (like the very popular EP75 on scaling D&R at Google) to the architectural questions in EP250.
4. “How Google Does Security” Sells the Tickets: We love the episodes offering a candid look behind Google’s security curtain on topics like internal red teaming, detection scaling, and Cloud IR tabletops. They consistently remain perennial audience favorites (the latest in this series is EP238 on how we use AI agents for security).
5. The Centrality of People and Process: We emphasize the recurring lessons that the most challenging aspects of large-scale cloud (and now AI) security transformations are often the “people” and “process” elements, not the technical “tech” itself. EP237 is an epic example of this.
6. The Call for Intentionality: We reinforce the importance of having a clear purpose for every security activity and following an engineering-led approach (EP117). The “magical” advice from EP236 is: to ask of every security element, “what is it in service of?”
7. The Persistence of Old Problems: We often lament with a touch of humor on the industry’s tendency to repeat fundamental security mistakes (the SIEM Paradox in EP234 for instance or EP223 in general), underscoring the ongoing need to cover “boring” basics. We will absolutely continue this (a new episode on vulnerability management “stale” problems is coming soon)
8. Community and Format Growth: We continue to “sorta-kinda” (human wrote this, eh?) the development of the podcast beyond a purely audio medium, including the launch of live video sessions and a Community site to foster more dialogue and feedback.
9. The Unique Culture and Authenticity of the Show Stays: We remain obsessed about selecting high-energy, vocal, and knowledgeable guests and fun topics. We will keep on with our “inside jokes” like not allowing guests to recommend Anton’s blog as an episode resource and pokes about firewall appliances in the cloud (they are there).
10. A Glimpse at 300: We want to tease future topics that will define the next 50+ episodes, such as deeper dives into Agentic AI, challenges of cross-cloud incident response and forensics, or the geopolitical aspects of cloud security. Give us ideas, will ya? Otherwise, you will get to hear about AI and D&R much of the time…

Top 5 popular episodes (excluding the oldest 3)

1. EP75 How We Scale Detection and Response at Google: Automation, Metrics, Toil
2. EP153 Kevin Mandia on Cloud Breaches: New Threat Actors, Old Mistakes, and Lessons for All
3. EP47 Megatrends, Macro-changes, Microservices, Oh My! Changes in 2022 and Beyond in Cloud Security
4. EP8 Zero Trust: Fast Forward from 2010 to 2021
5. EP17 Modern Threat Detection at Google

Enjoy the show!

• Subscribe at Spotify
• Subscribe at Apple Podcasts
• Subscribe at YouTube

250 Episodes of Cloud Security Podcast by Google: From Confidential Computing to AI-Ready SOC was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

In early 1900s, factory owners bolted the new electric dynamo onto their old, central-shaft-and-pulley systems. They thought they were modernizing, but they were just doing a “retrofit.” The massive productivity boom didn’t arrive until they completely re-architected the factory around the new unit-drive motor (metaphor source).

Today’s AI agent slapped onto a broken, 1990s-style SOC process stack is the same. Everyone is chasing the shiniest LLM or agentic system to “AI-enable” their existing, often sclerotic, processes. The result is an AI retrofit that instantly slams into deeper, systemic bottlenecks.

So, how to tell if your SOC is AI ready?

Five Pillars of MODEL OF AI-ready SOC:

1. SOC Data Foundations.
2. SOC Process Framework and Maturity
3. SOC Human Element and Skills
4. Modern SOC Technology Stack
5. SOC Metrics and Feedback Loop

Now, the details:

#1 SOC Data Foundations. Security context (why context?) and data are available and can be queried by machines (API, MCP, etc) in a scalable and reliable manner (Both! If unreliable, humans will need to fix it and the project dies). Scalable, fast and reliable matter, as agents can screen scrape well, but you probably won’t use this to get a gig of mainframe logs via tn3270. Federated often also means “not scalable and reliable” BTW. Because access to cheap/slow storage is, well, slow.

Of course, while availability and reliability are crucial, “AI ready SOC” also means data quality, structure, and governance. GIGO is still law! Scalability is necessary, but the quality of the ingested security context is the difference between this AI thing working … or not.

Questions to ask yourself:

1. Can all security telemetry and context data (logs, asset inventory, user context, etc) be quickly and reliably queried at scale?
2. Do we have formal data quality, structure, and governance processes in place to prevent “Garbage In, Garbage Out” from sabotaging our AI efforts?

#2 SOC Process Framework and Maturity. Common SOC workflows do NOT rely on human-to-human communication (“nobody knows what server4 does, let’s see if John knows, well, he does not, but he suggested Joanna does, and — WIN! — she really does” workflows are not agent-friendly) are essential for AI success. If your SOC has a lot of ad hoc activities, agents will (at least initially!) have trouble. Worse news: weak process (this pillar #2) is very often a close friend of weak data access (pillar #1) so they “double-team” your agentic effort to oblivion. This has sunk plenty of SOAR projects in its time.

Ultimately, “If your teams don’t know who owns what, neither will your Agents.” (source). Your SOC processes must be documented, validated, and capable of being scaled and learned from (see pillar #5 below). This includes a way to train AI on past work and SOC history.

Questions to ask yourself:

1. Can our most common investigation and response workflows be followed by an agent based purely on documentation, without the need for ad-hoc human-to-human queries?
2. Do we have a system in place to train AI agents on our past work/history of alert triage and resolution to enable learning and continuous process improvement?

#3 SOC Human Element and Skills: Cultivating a culture of augmentation, redefining analyst roles, providing training for human-AI collaboration, and embracing a leadership mindset that accepts probabilistic outcomes. You really, really need executives who support “augmented” AI SOC vision, not those who seek to “kill off” the humans.

Also, they should accept that machines will make mistakes, and that is OK. In fact, leaders must not just accept “probabilistic outcomes,” but explicitly be comfortable with the machine resolving some alerts, even if it’s sometimes wrong. This acceptance of necessary imperfection is a core readiness indicator. If they expect perfection, you will have AI SOC for a month. And then go back to printing logs and reviewing them with sad little human eyes :-)

Questions to ask yourself:

1. Are our leaders explicitly comfortable with the AI / machine autonomously closing alerts, even if it introduces an acceptable, measured error rate?
2. Have we redefined our analysts’ roles and provided training to shift their focus from manual alert triage to creative problem-solving and AI ‘shepherding’?

#4 Modern SOC Technology Stack: Implementing integrated and interoperable technologies that support intelligent systems and embed AI into existing workflows. This one is least critical of my pillar batch, but still it matters. Also, it is often a dependency for #1, so this matters as well.

The criticism is that a single “AI tool” is not the goal. The technology stack must ensure the entire security ecosystem is interoperable and flexible enough to support the other pillars. This means you can remediate, mitigate, etc.

Questions to ask yourself:

1. Is our security stack interoperable and flexible enough to allow new AI capabilities to integrate seamlessly, or are we reliant on siloed, single-function security tools?
2. Will any of our tools be overrun with agentic AI request volumes?

#5 Metrics and Feedback Loop: You are ready for AI if you can, after adding AI, answer the “what got better?” question. You need metrics and a feedback loop to get better. And to know you got better. If you “add AI” to a bad, old SOC, not only you won’t get better, you won’t even know you didn’t get better.

Metrics are a must here. Without a defined way to measure value and feed the results back into the AI models and processes, the transformation risks stalling into at best a “retrofit”, a nothing or even a worse situation…

Questions to ask yourself:

1. Can we quantify the value of AI by measuring the improvements that resulted from it?
2. Do we have an automated, continuous feedback loop to ensure AI model decisions and performance metrics are fed back into process documentation and model retraining?

The pillars should be framed not just as pre-requisites for AI adoption, but as the building blocks for a completely re-architected Security Operations Center. The transformation is about reimagining the whole way of doing things, not just accelerating one piece of an old process.

What do you think?

Related blogs:

• A Brief Guide for Dealing with ‘Humanless SOC’ Idiots
• WTH is Modern SOC, Part 1
• The Return of the Baby ASO: Why SOCs Still Suck?
• SOC Visibility Triad is Now A Quad — SOC Visibility Quad 2025
• SOC is Not Dead Yet It May Be Reborn As Security Operations Center of Excellence

Simple to Ask: Is Your SOC AI Ready? Not Simple to Answer! was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

It’s not every day you get to reflect on a journey that started as an odd “googley” startup and culminates in a shiny Leaders placement on a Gartner Magic Quadrant for SIEM 2025 (MQ).

When I joined Chronicle in the summer of 2019 — a name now rolled into the broader Google SecOps product (with SOAR by Siemplify and threat intel by Mandiant) — it was very much a startup. Yes, we were part of Alphabet, but the spirit, the frantic energy, the drive — it was a startup to its core.

And here’s the kicker (and a side rant!): I’m fundamentally allergic to large companies. Those who know me have heard me utter this countless times. So, in a matter of weeks after joining a small company, I found myself working for a very large one indeed.

To me, that pivot, that blending of startup momentum and big company scale, is, in many ways, the secret sauce behind our success today. It turns out, you need both the wild ambition of a young vendor and the solid foundation of a massive enterprise to truly move the needle (and the dots on the MQ … but these usually reflect customer realities).

The MQ and the Price of Poker

Now, as a reformed analyst who spent eight years in the Gartner trenches, I’ll clear up a misconception right away: the Magic Quadrant placement has precisely zero to do with how much a vendor pays Gartner. Trust me, there are vendors in highly visible SIEM MQ positions who’ve probably never sent Gartner a dime over the years.

Conversely, there are large organizations that have paid a fortune and have been completely excluded from the report. The MQ placement reflects customer traction and market reality (usually — there are sad yet very rare exceptions to this, and I will NOT talk about them; there is not enough whiskey in the world to make me). MQ placement is a measure of genuine success, not a destination achieved by writing a big check.

The Evolution of SIEM: Where Did the Brothers Go?

Reflecting on the last few years in SIEM (not 20 years!) and looking at the current MQ, a few things that were once controversial are now conventional wisdom:

1. SIEM must be SaaS and Cloud-Native. I’m old enough to remember when the idea of trusting your security data to the cloud was an existential debate. Today, with the relentless attack surface expansion, perhaps more people are realizing that the biggest risk is actually running a vulnerable, constantly-compromised on-prem SIEM stack. Data gravity shifted.
2. SIEM and SOAR are fully merged. They are, in essence, two inseparable brothers forming the core of modern SIEM — detection and response. SIEM is really SIEM/SOAR in 2025. Standalone SOAR vendors do exist and some “AI SOC” vendors are really “SOAR 3.0”, but these are — IMHO — outliers compared to the mainstream SIEM.
3. The UEBA brother got absorbed, but … Remember the mid-2010s, when User and Entity Behavior Analytics (UEBA) was the new shiny toy, all driven by cool machine learning? While it was an equal brother to SOAR for a moment, it has now largely been absorbed into the detection stack of the main SIEM product. Machine learning’s importance for basic threat detection has subtly decreased (odd…isn’t it?). UEBA has become a single, albeit important, feature within the engine, not a standalone platform.
4. Some XDR vendors graduated to real SIEM. EDR-centric SIEM vendors (XDR, if you have to go there), have landed. IMHO, these guys will do some heavy damage in the market in the next 1–2 years.

The Most Powerful Force in the Universe: IT Inertia

When I left Gartner, I famously outlined one key lesson from my analyst time: IT inertia is the most powerful force in the universe.

When you look at the MQ, you might see what looks like “same old, same old,” with certain large, established vendors still floating around. This is NOT about who pays, really! You might not believe it, but this placement absolutely reflects enterprise reality. Large vendors don’t die immediately.

Case in point: it took one particularly prominent legacy SIEM vendor (OK, I will name this one as it is finally dead for real, ArcSight) almost ten years to truly disappear from the minds of practitioners. Most companies were abandoning that technology around 2017–2018), but the vendor only truly died off in the market narrative in 2025. The installed base hangs on, dragging the demise out over a decade.

AI, Agents, and the Missing Tsunami

Finally, a quick note on the current darling: Generative AI and AI Agents.

While some vendors (and observers) expected a massive, dramatic impact from Generative AI on this year’s MQ, it simply hasn’t materialized — yet. As other Gartner papers will tell you, AI does not drive SIEM purchasing behavior today.

Why? Gartner’s assessment is based on customer reports. Vendors can yell all they want about how AI is dramatically impacting their customers, but until those customers report observable, dramatic improvements and efficiencies to Gartner, the impact is considered non-existent in the MQ reality.

The AI tsunami is coming, but for now, the market is still focused on the fundamentals: cloud-native scale, effective detection, and fast/good (AND, not OR) response. Getting those right is what puts you in the Leaders Quadrant. The rest is just noise…

Other SIEM MQ 2025 comments can be found here (more to be added as they surface…)

P.S. The “reformed” analyst reference comes from Tim and our Cloud Security Podcast by Google

SIEM, Startups, and the Myth (Reality?) of IT Inertia: A Reformed Analyst Reflects on SIEM MQ 2025 was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the world of security operations, there is a growing fascination with the concept of a “decoupled SIEM,” where detection, reporting, workflows, data storage, parsing (sometimes) and collection are separated into distinct components, some sold by different vendors.

Closely related to this is the idea of federated log search, which allows data to be queried on demand from various locations without first centralizing it in a single system.

When you combine these two trends with the emergence of AI agents and the “AI SOC,” a compelling vision appears — one where many of security operations’ biggest troubles are solved in an elegant and highly automated fashion. Magic!

Magical decoupled SIEM + magical federated log search + magical AI agents

=

90X the magic

(Is my math mathing? Cheap + good + fast + AI powered … pick any …ehh… I digress!)

However, a look at the market reveals a conflicting — dare I saw opposite — trend. Many organizations are actively choosing the very opposite approach: tightly integrated platforms where search, dashboards, detection, data collection, and AI capabilities are bundled together — and additional things are added on top (such as EDR).

Let’s call this “EDR-ized SIEM” or “SIEM with XDR-inspired elements” (for those who think they can define XDR) or “supercoupled SIEM” (but this last one is a bit of a mouthful..)

While some suggest this is a split between large enterprises choosing disaggregated stacks and smaller companies opting for closer integration, this doesn’t fully capture the success rates of these different models (one is successful and another is, well, also successful but at a very small number of extra-large, engineering-heavy organizations)

If one were to take a contrarian view (as I will in this post!), it might be that the decoupled and federated approach, with or without AI agents, is destined to be a secondary, auxiliary path in the evolution of SIEM.

Log Centralization: The End Is Nigh?

This isn’t a nostalgic vote for outdated, 1990s-era ideas (“gimme a 1U SIEM appliance with MySQL embedded!”), but rather a realistic assessment based on past lessons, such as the niche fascination with security data science.

Many years ago (2012), while at Gartner, I wrote a notorious “Big Analytics for Security: A Harbinger or An Outlier?” (archive, repost), and it is now very clear that late 2000s-early 2010s security data science “successes” remained a tiny, micro minority examples. A trend can be emergent, growing tenfold from a tiny base of 0.01% of companies, yet still only reach 0.1% of the market — making it an outlier, not a harbinger of the mainstream future.

Ultimately, the evidence suggests that a decoupled, federated architecture will not form the basis of the typical SIEM of 2027. Instead, the centralized platform model, enhanced and supercharged by AI, will reign supreme (and, yes, it will also include some auxiliary decentralized elements as needed, think of it as “90% centralized / 10% federated SIEM” — a better model for the future).

My conclusion:

1. SIEM has a future! If you hate SIEM so much that you … rename it, then, well, SIEM still has a future (hi XDR!)
2. Decoupled SIEM and federated log search belong in the future of SIEM.
3. However, decoupled SIEM and federated log search (In My NSHO) are not THE future of SIEM.
4. I think this because both are just too damn messy for many clients to make them work well. They also fail many compliance tests (well, the federated part, not the decoupled)
5. AI and AI agents are a very big part of the SIEM future. However, AI agents do not make decoupled SIEM and federated log search less messy enough (“I didn’t save any logs from X, hey AI agent .. get me logs from X” does not work IRL)

Put another way:

The Romantic Ideal: The theory is that scalable data platforms and specialized threat analysis are dramatically different, so they should be handled by specialists, and modern APIs should make connecting them “easy.” Magic!

The Real Reality: A natively designed, single-vendor, integrated SIEM is inherently simpler and easier to manage and support than a multi-component stack you have to assemble “at home.” It is also faster! AI integrated inside it just works better. With decoupling, also lose the benefit of having a “single face to scream at” when things break. Reality!

Here is my “decoupled SIEM reading list” (all fun reads, obviously not all I agree with):

• Security is about data: how different approaches are fighting for security data and what the cybersecurity data stack of the future is shaping up to look like
• Future of security operations isn’t interfaces like SIEM, it’s access to data
• Prepare for SIEM Evolution
• Building the SOC of the Future (video)
• Security Data Lakes: A Reality Check
• The SIEM Stack Is Breaking: What Comes After Splunk and Legacy Security Infrastructure
• Next generation of SIEM will be a focused security layer running on top of a commodity data layer
• A Year-End Reflection on the SIEM and SecOps Landscape
• Changes in SIEM Market
• Navigating the data current: Exploring Cribl.Cloud analytics and customer insights

Please argue on socials (X or LinkedIn) or in comments!

Related posts:

• Decoupled SIEM: Brilliant or Stupid?
• Log Centralization: The End Is Nigh?
• Debating SIEM in 2023, Part 1
• Debating SIEM in 2023, Part 2
• Why Your Security Data Lake Project Will … Well, Actually …
• EP190 Unraveling the Security Data Fabric: Need, Benefits, and Futures
• EP197 SIEM (Decoupled or Not), and Security Data Lakes: A Google SecOps Perspective
• Detection as Code? No, Detection as COOKING!
• Back to Cooking: Detection Engineer vs Detection Consumer, Again?

Decoupled SIEM: Where I Think We Are Now? was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Amazingly, Medium has fixed the stats so my blog / podcast quarterly is back to life. As before, this covers both Anton on Security and my posts from Google Cloud blog, Google Cloud community blog, and our Cloud Security Podcast (subscribe on Spotify).

Top 10 posts with the most lifetime views (excluding paper announcement blogs):

1. Anton’s Alert Fatigue: The Study [A.C. — wow, this is still #1 now! Awesome! Perhaps I need more of such deep studies]
2. Security Correlation Then and Now: A Sad Truth About SIEM
3. Can We Have “Detection as Code”?
4. Detection Engineering is Painful — and It Shouldn’t Be (Part 1)
5. Revisiting the Visibility Triad for 2020 (update for 2025 is here!!!)
6. Beware: Clown-grade SOCs Still Abound
7. Why is Threat Detection Hard?
8. A SOC Tried To Detect Threats in the Cloud … You Won’t Believe What Happened Next
9. Top 10 SIEM Log Sources in Real Life? (updated 2024 version)
10. Anton and The Great XDR Debate, Part 1

Top 5 posts with paper announcements:

• New Paper: “Future of the SOC: SOC People — Skills, Not Tiers” (paper 2 of the series)
• New Paper: “Future of the SOC: Evolution or Optimization — Choose Your Path” (Paper 4 of 4.5) (one more paper coming later in 2025 … we are researching now!)
• New Paper: “Future of the SOC: Forces shaping modern security operations”
• New Paper: “Future Of The SOC: Process Consistency and Creativity: a Delicate Balance” (Paper 3 of 4)
• New Paper: “Autonomic Security Operations — 10X Transformation of the Security Operations Center” (the classic 2021 ASO paper!)
• New Paper: “Future of SOC: Transform the ‘How’” (Paper 5)
• New Paper: “Securing AI: Similar or Different?“
• “New Office of the CISO Paper: Organizing Security for Digital Transformation” (paper)
• “10 ways to make cyber-physical systems more resilient” (paper)

NEW: recent 3 fun posts, must-read:

• A Brief Guide for Dealing with ‘Humanless SOC’ Idiots
• “Maverick” — Scorched Earth SIEM Migration FTW!
• “Shadow Agents: A New Era of Shadow AI Risk in the Enterprise”

Top 7 Cloud Security Podcast by Google episodes (excluding the oldest 3!):

1. EP75 How We Scale Detection and Response at Google: Automation, Metrics, Toil (our best episode! officially!)
2. EP153 Kevin Mandia on Cloud Breaches: New Threat Actors, Old Mistakes, and Lessons for All
3. EP8 Zero Trust: Fast Forward from 2010 to 2021
4. EP47 “Megatrends, Macro-changes, Microservices, Oh My! Changes in 2022 and Beyond in Cloud Security”
5. EP17 Modern Threat Detection at Google
6. EP109 How Google Does Vulnerability Management: The Not So Secret Secrets!
7. EP150 Taming the AI Beast: Threat Modeling for Modern AI Systems with Gary McGraw

Now, fun posts by topic.

Security operations / detection & response:

• “Security Correlation Then and Now: A Sad Truth About SIEM”
• “Migrate Off That Old SIEM Already!” (VIDEO!)
• “Measuring the SOC: What Counts and What Doesn’t in 2025?” (Google Cloud Blog)
• “Can We Have “Detection as Code”?”
• “Revisiting the Visibility Triad for 2020” and “SOC Visibility Triad is Now A Quad — SOC Visibility Quad 2025”
• “Beware: Clown-grade SOCs Still Abound”
• “Why is Threat Detection Hard?”
• “A SOC Tried To Detect Threats in the Cloud … You Won’t Believe What Happened Next”
• “Stop Trying to Take Humans Out of SOC … Except … Wait… Wait… Wait…”
• “Top 10 SIEM Log Sources in Real Life?” (NEWER VERSION)
• “Debating SIEM in 2023, Part 1”
• “Debating SIEM in 2023, Part 2”
• “Log Centralization: The End Is Nigh?”
• “Living with Multiple SIEMs”
• “Decoupled SIEM: Brilliant or Stupid?”
• “How to Make Threat Detection Better?”
• “SIEM Content, False Positives and Engineering (Or Not) Security”
• “Modern SecOps Masterclass: Now Available on Coursera”

(if you only read one, choose this one!)

Cloud security:

• “Secure cloud. Insecure use. (And what you can do about it)”
• “Using Cloud Securely — The Config Doom Question”
• “Who Does What In Cloud Threat Detection?”
• “How to Solve the Mystery of Cloud Defense in Depth?”
• “Does the World Need Cloud Detection and Response (CDR)?”
• “Use Cloud Securely? What Does This Even Mean?!”
• “How CISOs need to adapt their mental models for cloud security” [GCP blog]
• “Who Does What In Cloud Threat Detection?”
• “Cloud Migration Security Woes”
• “Move to Cloud: A Chance to Finally Transform Security?”
• “It’s a multicloud jungle out there. Here’s how your security can survive“

(if you only read one, choose this one!)

How Google Does Security (HGD):

• “How Google Does It: Making threat detection high-quality, scalable, and modern” (Google Cloud blog)
• “How Google Does It: How we secure our own cloud” (Google Cloud blog)
• “How Google Does It: Finding, tracking, and fixing vulnerabilities” (Google Cloud blog)
• “How Google Does It: Red teaming at scale” (Google Cloud blog)
• “How Google Does It: Security programs at global scale” (Google Cloud blog)

(if you only read one, choose this one! BTW, we also have a lot of fun HGD podcasts)

AI security:

• ”Our Security of AI Papers and Blogs Explained” [this has a whole lot of AI security fun links that you so want to click!]
• “Securing AI Supply Chain: Like Software, Only Not” (Google Cloud blog)
• “Spotlighting ‘shadow AI’: How to protect against risky AI practices” (Google Cloud blog)
• “Shadow AI Strikes Back: Enterprise AI Absent Oversight in the Age of Gen AI”
• “No Deep AI Security Secrets In This Post!”
• “New Paper: “Securing AI: Similar or Different?“
• “The Prompt: What to think about when you’re thinking about securing AI” (Google Cloud blog)
• “Gen AI governance: 10 tips to level up your AI program” (Google Cloud blog)
• “AI Adoption: Learning from the Cloud’s Early Days” (Google Community blog)
• “How Google secures AI Agents” (Google Cloud blog)
• “Demystifying AI Security: New Paper on Real-World SAIF Applications”
• “To securely build AI on Google Cloud, follow these best practices” (Google Cloud blog)
• “Oops! 5 serious gen AI security mistakes to avoid” (Google Cloud blog)
• “3 new ways to use AI as your security sidekick” (Google Cloud blog)
• “Shadow Agents: A New Era of Shadow AI Risk in the Enterprise” (Google Cloud Community blog)

(if you only read one, choose this one!)

NEW: fun presentations shared:

• Detection Engineering Maturity — Helping SIEMs Find Their Adulting Skills (2024)
• Future of SOC: More Security, Less Operations (2024)
• SOC Meets Cloud: What Breaks, What Changes, What to Do? (2023)
• Meet the Ghost of SecOps Future (2023)
• The Future of Log Centralization for SIEMs and DFIR — Is the End Nigh? (2023)
• 20 Years of SIEM (2022)

Enjoy!

Previous posts in this series:

• Anton’s Security Blog Quarterly Q2 2025
• Anton’s Security Blog Quarterly Q1 2025
• Anton’s Security Blog Quarterly Q4 2024
• Anton’s Security Blog Quarterly Q3 2024
• Anton’s Security Blog Quarterly Q2 2024
• Anton’s Security Blog Quarterly Q1 2024 Lite
• Anton’s Security Blog Quarterly Q3 2023
• Anton’s Security Blog Quarterly Q2 2023
• Anton’s Security Blog Quarterly Q1 2023
• Anton’s Security Blog Quarterly Q4 2022
• Anton’s Security Blog Quarterly Q3 2022
• Anton’s Security Blog Quarterly Q2 2022
• Anton’s Security Blog Quarterly Q1 2022
• Anton’s Security Blog Quarterly Q4 2021
• Anton’s Security Blog Quarterly Q3 2021
• Anton’s Security Blog Quarterly Q2 2021
• Anton’s Security Blog Quarterly Q1 2021
• Anton’s Security Blog Quarterly Q3.5 2020

Anton’s Security Blog Quarterly Q3 2025 was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

SOC Visibility Triad is Now A Quad — SOC Visibility Quad 2025

I will be really, really honest with you — I have been totally “writer-blocked” and so I decided to release it anyway today … given the date.

So abit of history first. So, my “SOC visibility triad” was released on August 4, 2015 as a Gartner blog (it then appeared in quite a few papers, and kinda became a thing). It stated that to have good SOC visibility you need to monitor logs (L), endpoint (E) sources and network (N) sources. So, L+E+N was the original triad of 2015. Note that this covers monitoring mechanisms, not domains of security (more on this later; this matters!)

5 years later, in 2020, I revisited the triad, and after some agonizing thinking (shown at the above link), I kept it a triad. Not a quad, not a pentagram, not a freakin’ hex.

So, here in 2025, I am going to agonize much more .. and then make a call (hint: blog title has a spoiler!)

How do we change my triad?

First, should we …

… Cut Off a Leg?

Let’s look at whether the three original pillars should still be here in 2025. We are, of course, talking about endpoint visibility, network visibility and logs.

My 2020 analysis concluded that the triad is still very relevant, but potential for a fourth pillar is emerging. Before we commit to this possibly being a SOC visibility quad — that is, dangerously close to a quadrant — let’s check if any of the original pillars need to be removed.

Many organizations have evolved quite a bit since 2015 (duh!). At the same time, there are many organizations where IT processes seemingly have not evolved all that much since the 1990s (oops!).

First, I would venture a guess that, given that EDR business is booming, the endpoint visibility is still key to most security operations teams. A recent debate of Sysmon versus EDR is a reflection of that. Admittedly, EDR-centric SOCs peaked perhaps in 2021, and XDR fortunately died since that time, but endpoints still matter.

Similarly, while the importance of sniffing the traffic has been slowly decreasing due to encryption and bandwidth growth, cloud native environments and more distributed work, network monitoring (now officially called NDR) is still quite relevant at many companies. You may say that “tcpdump was created in 1988” and that “1980s are so over”, but people still sniff. Packets, that is.

The third pillar of the original triad — logs — needs no defense. Log analysis is very much a booming business and the arrival of modern IT infrastructure and practices, cloud DevOps and others have only bolstered the importance of logs (and of course their volume). A small nit appears here: are eBPF traces logs? Let’s defer this question, we don’t need this answer to reassert the dominance of logs for detection and response.

At this point, I consider the original three legs of a triad to be well defended. They are still relevant, even though it is very clear that for true cloud native environments, the role of E (endpoint) and N (network) has decreased in relative terms, while importance of logs increased (logs became more load bearing? Yes!)

Second, should we …

Add a Leg?

Now for the additions I’ve had a few recent discussions with people about this, and I’m happy to go through a few candidates.

Add Cloud Visibility?

First, let’s tackle cloud. There are some arguments that cloud represents a new visibility pillar. The arguments in favor include the fact that cloud environments are different and that cloud visibility is critical. However, to me, a strong counterpoint is that cloud visibility In many cases, is provided by endpoint, network, and logs, as well as a few things. We will touch these “few things” in a moment.

YES?

• Cloud native environments are different, they suppress E and N
• Cloud visibility is crucial today
• Addresses unique cloud challenges
• Cloud context is different, even if E and N pillars are used for visibility
• CDR is a thing some say

NO?

• Cloud INCLUDES logs (lots, some say 3X in volume), and also E and N
• Too much overlap with other pillars (such as E and N)
• Cloud is a domain, not a mechanism for visibility.
• CDR is not a thing, perhaps

Verdict:

• NO, not a new pillar, part of triad already (via all other pillars)

Add Identity Visibility?

The second candidate to be added is, of course, identity. Here we have a much stronger case that identity needs to be added as a pillar. So perhaps we would have an endpoint, network, logs and identity as our model. Let’s review some pros and cons for identity as a visibility pillar.

YES?

• Identity is key in the cloud; we observe a lot of things via IDP … logs (wait.. we already have a pillar called “logs”)
• By making identity a dedicated pillar, organizations can ensure that it receives the attention
• ITDR is a thing

NO?

• But identity visibility is in the logs … we already have logs!
• Too much overlap with other pillars (such as logs and E as well)
• Identity is hugely useful and critical, but as context. This post is about activity streams
• ITDR is kinda a thing, but it is also not a thing

Verdict:

• Sorry, still a NO, but a weak NO. Identity is critical as context for logs, endpoint data and network telemetry, but it is not (on its own) a visibility mechanism.

Still, I don’t want to say that identity is merely just about logs, because “baby … bathwater.” Some of the emerging ITDR solutions are not simply relying on logs. I don’t think that identity is necessarily a new pillar, but there are strong arguments that perhaps it should be…

What do you think — should identity be a new visibility pillar?

Add Application visibility?

Hold on here, Anton, we need more data!

Here:

and

Now let’s tackle the final candidate, the one I considered in 2020 to be the fourth leg of a three legged stool. There is, of course, application visibility, powered by increased popularity of observability data, eBPF, etc. Application visibility is not really covered by endpoint orgs and definitely not by EDR observation. Similarly, application visibility is very hard to deduce from network traffic data.

YES?

• Application visibility is not covered by E and N well enough
• SaaS, cloud applications and — YES! — AI agents require deep application visibility.
• This enables deeper insights of the app guts, as well as business logic

NO?

• Is it just logs? Is it, though?
• Do organizations have to do application visibility (via ADR or whatever?) Is this a MUST-HAVE … but for 2030?
• Are many really ready for it in their SOCs today?

Verdict:

• YES! I think to have a good 2025 SOC you must have the 4th pillar of application visibility.
• And, yes, many are not ready for it yet, but this is coming…

So, we have a winner. Anton’s SOC visibility QUAD of 2025

1. Logs
2. Endpoint
3. Network
4. Application

Are you ready? … Ready or not, HERE WE GOOOO!

Related blogs:

• WhatDR or What Detection Domain Needs Its Own Tools?
• Revisiting the SOC Triad 2020
• Baby ASO: A Minimal Viable Transformation for Your SOC

SOC Visibility Triad is Now A Quad — SOC Visibility Quad 2025 was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is my completely informal, uncertified, unreviewed and otherwise completely unofficial blog inspired by my reading of our next Cloud Threat Horizons Report, #12 (full version) that we just released (the official blog for #1 report, my unofficial blogs for #2, #3, #4, #5, #6, #7, #8, #9, #10 and #11).

My favorite quotes from the report follow below:

• “Google Cloud’s latest research highlights that common hygiene gaps like credential issues and misconfigurations are persistently exploited by threat actors to gain entry into cloud environments. During the first half of 2025, weak or absent credentials were the predominant threat, accounting for 47.1% of incidents. Misconfigurations (29.4%) and API/UI compromises (11.8%) followed as the next most frequently observed initial access vectors.“

• “Notably, compared to H2 2024, we observed a 4.9% decrease in misconfiguration-based access and a 5.3% decrease in API/UI compromises (i.e., when an unauthorized entity gains access to, or manipulates a system or data through an application’s user-facing screen or its programmatic connections). This shift appears to be partly absorbed by the rise of leaked credentials representing 2.9% of initial access in H1 2025. ” [A.C. — It gently suggests that while we’re making some progress on configurations, the attackers are moving to where the fruit is even more low-hanging: already leaked credentials.]
• “Foundational security remains the strongest defense: Google Cloud research indicates that credential compromise and misconfiguration remain the primary entry points for threat actors into cloud environments, emphasizing the critical need for robust identity and access management and proactive vulnerability management.” [A.C. — it won’t be the magical AI that saves you, it would be not given admin to employees]
• “Financially motivated threat groups are increasingly targeting backup systems as part of their primary objective, challenging traditional disaster recovery, and underscoring the need for resilient solutions like Cloud Isolated Recovery Environments (CIRE) to ensure business continuity.” [A.C. — if your key defense against ransomware is still backups, well, we got some “news” got you…]
• “Advanced threat actors are leveraging social engineering to steal credentials and session cookies, bypassing MFA to compromise cloud environments for financial theft, often targeting high-value assets.” [A.C. — this is NOT an anti-MFA stance, this is a reminder that MFA helps a whole lot, yet if yours can be bypassed, then its value diminishes]
• “Threat actors are increasingly co-opting trusted cloud storage services as a key component in their initial attack chains, deceptively using these platforms to host seemingly benign decoy files, often PDFs.“ and “threat actors used .desktop files to infect systems by downloading decoy PDFs from legitimate cloud storage services from multiple providers, a tactic that deceives victims while additional malicious payloads are downloaded in the background” [A.C. — a nice example of thinking about how the defender will respond by the attacker here]
• “more traditional disaster recovery approaches, focused primarily on technical restoration, often fall short in addressing the complexities of recovering from a cyber event, particularly the need to re-establish trust with third parties.” [A.C. — The technical recovery is only half the battle. This speaks to the human element of incident response, and the broader impact of a breach.]

Now, go and read the THR 12 report!

Related posts:

• EP112 Threat Horizons — How Google Does Threat Intelligence podcast
• Google Cloud Security Threat Horizons Report #11 Is Out!
• Google Cloud Security Threat Horizons Report #10 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #9 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #8 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #7 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #6 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #5 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #4 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #3 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #2 Is Out!
• Illicit coin mining, ransomware, APTs target cloud users in first Google
• Cybersecurity Action Team Threat Horizons report

Google Cloud Security Threat Horizons Report #12 Is Out! was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.