EP242 The AI SOC: Is This The Automation We've Been Waiting For?

Security running.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Tim Peacock, the Senior PM for Detection, UEBA, Risk in Google SecOps, and of course, Anton Chuvakin, a reformed analyst and senior staff in Google Cloud's Office of the CISO. You can find and subscribe to this podcast wherever you get your podcasts, as well as at our website, cloud.withgoogle.com/cloudsecurity/podcast. If you enjoy our content and want it delivered to you piping hot every Monday, please do hit that subscribe button. You can follow the show, argue with us and the rest of our Cloud Security Podcast listeners on the Google Cloud Security Community page. Anton, we are talking about AI SOC today. What goes right? What could go wrong? It's a lot of fun.

Yes, this was a really fun one, and I feel like AI SOC has been exploding, not like physically exploding, but exploding in people's minds, at least if you believe the RSA Vendor Expo and social media. But we wanted to talk to somebody who kind of actually knows this and who maybe isn't as biased as some other people's opinion on this. I'll be like super mellow.

He certainly passed the ethical bar, as we will see later on in the episode. Yes. And so this is such a fun topic that maybe without any further ado, let's turn things over to today's guest. Today we are joined by Augusto Barros, a principal product manager at Prophet Security. Augusto, thank you so much for joining us today. We're talking about, I feel, a very 2025 topic, which is AI SOC. And could you just start us out by telling us what is an AI SOC?

Well, thanks, Tim and Anton, for having me. Well, what is the AI SOC? I think we're probably going to hear some different definitions, but from everything that we've been looking in the cybersecurity space where definitions definition is going to get a little fuzzy. I think in this case, it's becoming kind of more clear than usual. I think these are the tools that will do some of the triage and investigation on your behalf in an automated mode. Kind of how much of automation, that's still, of course, open for debate, but using some of the AI technologies that we've been seeing kind of using everywhere else.

And that's pretty broad. Maybe help paint a picture. Like, let's imagine a world I used to work at Stripe, and one of my favorite questions that Patrick and John Collison would ask in product reviews was, what if this goes right? Not what if this goes wrong? And so imagine that AI SOC goes right. What does that look like? What does the post-AI SOC world look like if it goes right?

I love the question because this is kind of what I've been working on kind of in the past kind of few weeks, because you were talking about the funnel, right, in some of the past episodes and how you hate the funnel kind of analogy.

I don't hate the funnel. It's Anton who hates the funnel.

No, I didn't hate the funnel. I said funnel is Yeah, funnel gives me flashbacks. Yeah.

But I think the fact is the SOC has been operating with a funnel mentality for a long time, right? And a very narrow funnel in the end, by the way, right? Because everything that you're generating from a detection point of view will go through the hands of a human most of the times, right? And I think that if AI SOC gets things right, we are really kind of expanding in an absurd manner your throughput or your capacity of handling detection events, right? So today, every time that you're going to kind of write a new detection, one of the things that you're going to have in mind is, okay, will this overwhelm my SOC?

Hmm.

And I think that AI SOC, I wouldn't say eliminates that type of question, but it reduces that concern in a substantial manner, in a way that many of the detections that you may not want to do, either because base rates are too high or kind of you cannot reduce the false positive to an acceptable level, I think you're going to have far more room to build detections without having to be that concerned about the impact kind of downstream.

Okay. So AI SOC lets us be noisy as detection engineers. I love it.

He didn't say that, though. He said that it's the— I mean, Augusto, do you feel like it's a decent summary or not?

Well, I think it is good. It's a good definition. And I'll say there is an asterisk there, right? Kind of sometimes we have to be noisy. Because I think what I've been seeing circulating in social media recently is that idea of, well, why are we doing that? Just let's be less noisy. And well, if that was easy, we would have done that probably a long time ago. And we know that's not easy. So we have to handle, right, and learn to deal with, live with that noise. And I think AI SOC really helps in that sense.

I like that. And I think I like that your definition is quite crisp. And I think that the way it works and the way the future looks is kind of both exciting, yet at the same time, not crazy. There's no fire all humans kind of story and some other stuff that we, of course, didn't expect from you specifically. Of course, hey, you're smarter than that. You're a former Gartner analyst. How about that? But that sometimes shows up in discussions. So, you also brought up the point about triage, and we'll try to probe around triage a little bit. But what are the mechanisms and what are What are the tools and what are the capabilities of AI SOC that would make dwell time decrease, mean time to respond to shrink as well? Like, what are the mechanisms? And also, how are you applying those mechanisms without losing fidelity? Because I always have this fear of suppressing too far, suppressing too much.

Right. And I think that we are going actually to an opposite level. We are not suppressing. I think that what we provide is actually kind of an ability to suppress less. I think that's kind of one of the things that I see as one of the biggest values. But you asked a question a few days ago on LinkedIn about, well, how does this compare to a perfectly implemented SOAR, right? I'm happy with my SOAR, et cetera. I think if you look at the outcome only, it'll probably be similar. The thing is, for you to build, right, all the playbooks and maintain all those playbooks for SOAR in a way that you get to the same levels of what I'm seeing from these AI SOC solutions, It is very hard and it's very costly. There is a lot of writing of playbooks. Every small variation is a new playbook. The way that you call kind of different tools depending on kind of how the integration works. And you see, AI SOC puts a lot of flexibility in that point in a way that the pain of building playbooks that I'll say is the main reason why organizations do not get enough value from SOAR.

Mm-hmm.

Kind of, it's eliminated. So what we are doing, right, kind of, let's take a Get Profit security-specific case, right? We write a lot of investigation steps, right? Our humans, our security operations specialists. And what the AI really provides to us is the ability to write those steps in a far easier manner than normally kind of putting together a playbook and also combining all those steps for each specific individual alert that we investigate. And I think that's kind of really kind of the big difference, right? Kind of you out of the box, you start investigating alerts. There is all the knowledge there and all that kind of concern. I think you remember when we are kind of studying this, right? Kind of in our Gartner times, right? Kind of we're always asking the SOAR vendors, how are your customers using your pre-built playbooks? And it was almost like, oh, just as a reference, right? Just to understand the abilities of the tool, but they were never using the out-of-the-box tools, right? What I'm seeing in this new world is our content, right, if I can define it that way, is fully used, right? Kind of as soon as we start getting the alerts, we start investigating with that knowledge without having to ask the customers anything. Yeah.

So let me, before Tim asks the next question, I'm getting, like, really weird flashbacks to pretty much to a different part in our past at Gartner when we were looking at Yuba vendors.

Oh, no.

And some of the Yuba vendors overdid this whole no rules theme is that there was a particularly offensive, like really offensive, okay, like really, really offensive human vendor that just printed these little stickers that said no rules. And as if from that day, you would never write a human-written rule. So, I'm not trying to blame that this is the IISoC thinking. But what I'm trying to say is that there's an analogy in people saying, SIEM rule writing is too hard. We're just going to get ML instead. But is this a bit of a similar fallacy here or not? And then maybe actually don't answer it because Tim's next question is almost the same question.

Well, I think, you know, maybe in fairness to that no rules vendor, they were making a reference to Salesforce's no software, right?

We should not be fair to that vendor, by the way. We should really not be fair to that vendor.

Because I still have on my desk here a Shape Security no bots pin from back in the day. which is very similar in spirit to a no rules or no software pen. But I do want to pick at this, and I want to make another observation here. It kind of sounds like you're describing the AI as a tier 1 analyst who doesn't have boredom or frustration and has infinite tolerance for tedium. Is that accurate to say?

It is to a large extent. And I say kind of really, I say kind of in ideal, in a SOC of ideal conditions, when AI SOC 2 is working Well, I don't think a tier 1 type of organization within the SOC is necessary. It is really kind of a boring job, right? There's no reason for humans— Oh, it's a terrible job. There's really kind of no reason for having humans doing that, right? They are following a script, right? So, and technology is pretty good at following scripts. But what we learned with SOAR is that writing the scripts and making the technology follow the scripts, it was not that trivial with the typical, say, workflow technology, because kind of the scripts are being rewritten all the time, right?

Right.

I think kind of with AI, kind of that flexibility is there. And even kind of put kind of my— every time that I say AI, I put kind of the current set of technologies that we describe as AI, right? Because there's a lot of hype around what AI is, as well, that I do not want to get in. You guys kind of covered that multiple times before. But I say the first kind of probably kind of big value is really eliminating that level 1 need, right? But depending on how deep you go into some investigations, I notice, right, a few customers saying, well, you're not doing only level 1. You're going kind of sometimes kind of beyond level 1. that on my environment you're also doing kind of level 2 type activity. I don't like the levels thing, but if you define level 3 as the point where no one knows what to do and had to put in the hands of someone that will think out of the box about how to investigate that or something that is not easily scriptable, I think we are still far from that point. So that's where we would stop. And that's why we wouldn't eliminate the humans in the SOC.

Yeah, I don't think people want to eliminate the humans in the SOC. I go back to what Maneja said on her episode about Enabling the humans to do the things that humans are good at and take advantage of their talents rather than force them into toilsome, tiresome work. I do want to pick at the SOAR side of the equation though, because Anton and I had the observation at RSA this year, and feel like others had this observation at Black Hat this year, that a lot of the AI SOC vendors, you could have been, you know, a time machine from 12 years ago and it would have been the same messaging as the SOAR vendors. And I don't think the SOAR vendors really lived up to fully what they promised. And so why is it different this time? Why is it not Saur V2 of ultimately unfulfilled promise?

I left the acronym and naming wars a long time ago, but I would say that kind of a Saur, a next-gen Saur, wouldn't be a completely inaccurate description of this space, right? I think that we end up kind of really kind of using a lot of AI just because it's the hype now, right? But I wouldn't be very annoyed if we were describing this as next-gen SOAR. And I think the big difference is, I mentioned before, is really implementation and maintenance effort, right? Kind of the AI SOC solutions have the ability to deliver what is being promised by SOAR, right? Kind of a long time ago without all the heavy weight of planning, writing scripts, kind of putting the processes in a kind of flowchart format. And I remember, right, kind of taking calls with Anton, and we were telling people, like, if you don't know your process, don't even buy SOAR because you won't kind of have where to start. That's a big difference here. We have— I've seen cases of kind of organizations that did not have a process of about how to investigate alerts, and they got an immediate benefit from the solution.

That's kind of interesting that you back in the day would have advised somebody you can't take advantage of a process automation tool without understanding your process. That kind of gets back, though, to what Maneja was talking about, again, to bring up Maneja, about migration versus transformation. Was the point of the SOAR to migrate your process from in your head to in the playbook, or was the point of SOAR to open the possibility of automation in the first place? So, I wonder if I would disagree with Anton of many years ago.

This is actually really— Anton would disagree with Anton of many years ago.

Oh, wonderful.

This is really interesting because in this notorious discussion on LinkedIn that Augusto mentioned, and we'll put a link in the notes, I had an epiphany.

You did.

And that was the exact epiphany, is that if you say for AI-built agentic SOC to work, you need to have robust playbooks, a lot of people very correctly pointed out that it's not true. And the opposite is in fact true, is where you have playbooks, rule-based work can be fine. But in case you don't have a playbook, then the agents can figure things out and do the right thing. I, at this 2025 Anton, maybe doesn't quite believe that, but really wants to believe that. And so, I would not push, if your process is broken, don't automate. Because with AI agents, if your process is broken, you may succeed with automation. And that's a genuine kind of, I'm making a weird gesture to my head. Like, it's a switch.

Anton has some really old school switches in his head.

Well, the relays, right?

Yeah, right. That's right. Oh God, they're not that old. I'm sorry.

You heard them clicking.

So it turns out he's actually a telegraph network from the 1800s. Okay, Anton, the next question is yours, and I really like it as a metrics question. And so the PM in me is sad to not ask this one, but you should ask it.

I think that it's less of a metrics. I think I'm gonna just like vent for a little bit. Like when we were wandering around RSA, We tried to find the proof that AI SOC works. And proof would be some kind of metrics of success.

Yeah, we didn't find that proof.

We did not find that proof. That's correct. But I also want to know, if I am on a journey to AI SOC, how do I measure progress? So maybe give us both. Give us how do you measure that it works and how do you measure your transition to it? Like, I am 1% AI SOC, I'm 10% AI SOC, I'm AI SOC. Which SOC metrics would show improvement? Like, sorry, we are bundling all this, piling all this stuff on Augusto, hoping he will figure it out.

Yeah, let me see if I kind of won't kind of have a buffer overflow and forget a piece of the question, right? But I'd say the most obvious ones, right, are kind of the mean time to something metrics, right? Kind of mean time to investigate, mean time to respond, because you have automation there, you're going to investigate those alerts quite fast, right? So you can obviously reduce the time that it takes for you to investigate and thus respond to something. Now, you can also look into the number of alerts that you can investigate with the same team, right? Just the absolute number is meaningless, right? But if you realize that the same team is investigating 10 times more alerts than before, it really kind of is a very strong indication that kind of you increase the efficiency, right? Kind of the throughput of that organization.

Mm-hmm.

Now, there are more things that you can start measuring later that I think kind of can show the additional value of these tools. One of those, for example, is how much or what types of alerts you ignore, right? If you look at our reports, right, kind of from— we released on kind of the AI State of the SOC, we talk about kind of sometimes 30%, 40% of alerts that are ignored by SOCs, right?

Mm-hmm.

And what they do is essentially put in that line there and say, okay, there's too much. I will not bother looking into anything that is under this line, either of severity or possibility of being, right, kind of a true positive, but they put the line somewhere and say, I won't look into anything under this line. And I think kind of either reducing or eliminating that line is a very strong indicator that your AI SOC is giving you results.

Hmm.

And the last one that I find kind of more interesting, but it's really kind of probably kind of really kind of down the maturity journey for the organizations that are using this is the expansion of your detection coverage, right? Because you're naturally, because of kind of limitations you have in investigations, you will look for less stuff, right? Because kind of every time that you put a new detection in place, you're going to generate more alerts. So there are many detection engineers there that are, right, kind of constrained by their ability or their capacity, the investigation capacity. Right. So if you increase that investigation capacity, I would expect, right, kind of over time that the organization will be able to look for more things, either in more places or more threats.

This is— you almost have to caveat with increase the capacity without sacrificing quality or with increasing quality or anything, because ultimately I can remember the intern example from our Gartner days. Oh, MSSP is great. We just had to hire an intern to delete all the alerts and we are fine. This is a real story. I think we even put it in the paper at the time. But we don't want that intern now on our staff if it's a robot, especially if it's a robot.

Yes, I think tracking the accuracy metric is a must. It is a metric of the quality of the service. If you're doing all that I was mentioning, investigating very fast, but half of the time you have to revert the result of my investigation because it was inaccurate, then there's no point. You should probably compute the time that you spent and also the exposure that you have. filing something as benign, right, that was malicious in the end, right, the level of exposure that you have during that time is considerable. But then, I would say one of the things that you have to keep track of is the accuracy of the solution that you're implementing. And I think that one big part of this is on the shoulders of the vendors to have an ongoing quality control process. So, you know, kind of all the— kind of we— I remember sometimes you look into some of the ISO standards, right, that kind of can come from the assembly line and be used in an operation like a SOC, for example. Okay, kind of for— let's get a sample of the alerts and look at them, right, manually and determine if kind of the AI kind of arrived at the right conclusion, right? And keep, right, kind of improving and tracking that metric because accuracy is a must.

Well, I feel bad that you're getting negative reactions on your answer from both of us, but The PM in me doesn't like this answer.

Not negative. No, no, no. I don't think I was negative. I felt like—

I'm going to be negative. I feel like if you're saying the metric that gets better is mean time to whatever, and we're talking about an automated system, that's like cheating at metrics almost to the scale of Goodhart's Law cheating at metrics.

Really?

It's not quite— well, yeah, of course automation makes your mean time to investigate better. That's like a no-brainer. Of course, the automated system responds faster than the human does. I'm curious if there are higher-level business metrics we could talk about here, because we had Dominic on. He aired this week that we're recording this, and he was talking about risk reduction through the use of agents in Google.

Right. But Dominic is an extreme outlier.

And I think his was maybe too high level. So is there a middle ground here where we can feel good about what the AI SOC is improving without it being super obvious or super high level?

I think that what I was pointing, for example, like the detection surface, right? Kind of how much you're covering from detection. I think it goes in that direction because you can link your increased detection capabilities to how much risk you're reducing, right? When you reduce the time to respond, you're also reducing kind of exposure in a certain manner, right? So I think you can link those metrics to risk-based metrics and metrics that are closer to the business.

That's fair.

Right. And I'll go back to your mean time kind of metric point is, I think if you look at specific use case, like this investigation, how long it takes for a human versus how long it takes with the tool, yes, that's almost cheating because it's obvious that you're going to have kind of an improvement on automating versus non-automating something. But I think these metrics need to be looked in a broader sense, right? Kind of as an average, right? As you say, in a mean time, Right? Kind of in a broader group of use cases, because then you can see, for example, that the organization that is being able to automate more types of investigations will get a better benefit than those that, for example, are trying to do the same thing with SOAR. And because SOAR is harder to use and set up, some of those use cases will never be either automated or fully automated.

Well, they never happen because the burden is so high. Yes.

Okay. So I do want to come back to the organization thing and talk about kind of the misconceptions that you're seeing. So what are kind of the mental stumbling blocks people are running into with this? Because there are so many ways to think about AI wrong. What are the common ways you're seeing to think about AI wrong?

Right. I think there are those when they look into the proposition of the tool, like, okay, you're going to eliminate my people, my SOC people, and you're going to have this robot here.

Yeah, fire the SOC. That's a bad idea.

Right. The technology has limits today. You cannot do it. I think the other one is related to how these things operate, right? And I would say there are multiple approaches to the problem, right? But I think that many people approach this believing that you get an alert and you throw into a single huge LLM and say, hey, go figure this out, right? And it's rarely that case, right? I think there are a few vendors trying to do that, and I doubt that they will succeed.

But we—

We normally can have a more complex architecture in terms of separating kind of all the challenges in the investigation, like kind of building an investigation plan, converting a question into a specific query into different tools. And each one of those questions can be a separate call to a separate model, right, in a different approach. Sometimes you're going to use a deterministic approach. Sometimes you're going to use the LLMs. So I think kind of the separating this idea, like, oh, the magic big model, they're going to throw the alert in and it's going to come with a magical answer versus this more nuanced and complex architecture that is really the truth for most implementations out there.

Hmm. That to me makes sense. And it does give me like minor flashbacks to SOAR, but I also see the differences. So that part is, I have kind of a compassion with this solving some old problems. and creating a smaller number of new problems. Is this fair? Like a smaller number of new problems and solving enough of the old problems of, you know, not having playbooks, playbook design, or asking experts to write and then update playbooks all the time. All this stuff is solved, but maybe some of this new stuff is still problematic a little bit.

Yeah, I think it's that typical optimization effort that when you go through, and you remove a constraint in the system, you start finding where the others are. So I say that finding the issues on the detection side, right? If you look and say, hey, you have 99% of accuracy, right? And when you look at kind of those determinations that you've done, right, kind of almost 100% were false positives.

Mm-hmm.

Okay. You probably have a problem on detection, right? And then you have to look there and then understand, right? With all those caveats about kind of being able to be right, kind of to look into more uncertain situations that will naturally generate more false positives, et cetera. If you have those levels, there is a problem, right? I think that's one of the challenges that they'll figure out, right, if they solve the investigation triage part. And the other is, what do you do after, right, kind of you arrive at that determination? Okay, we either define this as benign or malicious. What are the next steps? Right. Because the customers out there, they still do not want the full automation most of the time.

Of course.

Especially not to resolution. Right.

But then that requires them to do something. And then the question is, are they ready to do something? I think that's kind of, I think, the next— if someone comes to this without anything figured out, that's the next stumbling block that they will have.

Right.

Okay. We're getting kind of these responses. Okay. This is malicious. I have to do something. How do we do something, right?

And how do you do something with confidence if you're not the one that did all the preceding steps?

Right. This is an excellent point. And the ethically challenged AI SOC vendors who I met at RSA would immediately say, oh, we are working on the full automation to resolution. Just hold on for a bit and we'll build it. That to me is a classic bad faith answer. It's basically do whatever you want now and then later we'll magically fix all of it. That to me is a classic bad faith answer. It's not a good answer. Don't accept that answer if your vendor says that.

I don't think Prophet says this, but so listeners, I just love when Anton refers to a category of vendors as ethically challenged. No, no, no.

I am referring to a specific vendor.

Oh, a specific vendor.

No, it is not about the category. It's about the vendor who literally I said, oh, so you automate everything and said, no, no, no, not remediation. What about remediation? Oh, we'll do it really soon. We're going to just like write this and it's going to automate remediation as well. Whoa, no.

It seems perhaps unfair to a vendor to categorize them as ethically challenged based on one booth interaction, but—

Okay, fair. They may be ignorant. Ignorant is better. I think it's fine.

They may be ignorant, or they might have just been scared talking to the famous Anton Chuvakin and some guy next to him.

They did not know who I was. I just was a random dude asking questions.

I was holding on to anecdotes that would inflate Anton's ego, and then you go there and ruin everything. Thank you.

No, the best, Augusto, we were at RSA a couple years ago. We're talking to a vendor at a booth. The 2 of us are standing there. This guy, he says, you 2 look familiar. Oh, I listen to your show. This is great. I can tell everybody I've met Anton Chuvakin. And that was the end of the sentence. I'm standing right there. It's really, I felt great that day. It was awesome. But Anton, you have the last question before we close and you should, you should ask it. Because we're coming up on time.

Yeah, this is a— yeah, my ego doesn't need enough boosting at this point. But I have a source of nervousness, and it's kind of like a good nervousness about AI SOC. So imagine that you built what you want and everything works out like Tim wanted to structure it, as like things worked out, and triage is just much better. When I think of using AI in a SOC, my mind goes to things beyond triage. I want to help with refining detection rules. I want to help with detection engineering. Maybe I want some help with remediation and response. So what's next in AI SOC after triage? And what's the timeline for it?

Great question. I think kind of you already mentioned one that is really kind of improving detection, right? And also streamlining the steps after, right? Kind of the determination of something is bad and you have to respond to, right? So essentially kind of those 2 other sides from this piece, right, that we are solving, right? Kind of there are things that happen before, there are things that happen after, right? Those, I'll say, would be the target, right, kind of for improvement after that. Now, one thing that I really like from what is happening with AI SOC is when I was, like, kind of working for a SIEM vendor, I was trying to find ways to identify how efficient certain detection content pieces were or kind of how certain data sources would lead you more into real cases or kind of real kind of more true positives, for example, all those types of questions about the detection engineering in general.

Right.

And one of the challenges that we had was once it generated a detection, even if the tool had kind of all the case management capabilities there, most customers will treat that out of the SIEM, right? Or do that manually and never update the SIEM in terms of what happened with that alert. So you had a lot of detections, but you didn't have the information about the outcome of that detection. Was that a true positive? Was that a true negative? Was that, was that a kind of a false positive? Was that irrelevant? Right. Kind of how long did it take? Kind of what was the impact? All those questions about what happened after. And I think that with AI SOC being adopted, you are generating that mass of data that you can use to tie back to the detections and say, hey, these detections here have more value. You have a gap in detections here because I'm not seeing— Right.

Yes, that's huge. That's huge. The gap analysis. Or the kind of like a coverage analysis is absolutely amazing. And we do want machines to do it. I don't want freaking auditors with magnifying glasses.

And checklists. Don't forget their clipboards.

And checklists. Thank you. Magnifying glasses and the checklist, both. Yes.

Okay. So Augusto, I hate to do this, but we're way over time today. So we got to ask our traditional closing questions. One, do you have a tip to help people with their AI SOC adoption? And 2, Do you have recommended reading? That reading could be anything from like Mary Oliver to Mary Shelley. It just cannot be Anton's blog.

Right. That's kind of a rule we have. Yes, unfortunately. It comes from the fact that I stuff my blog links to every podcast anyway. So it's like—

I don't need to point, right? Because it's already going to be in the notes.

It's already there.

Anyway. Well, kind of from a tip point of view, I'd say look very carefully in terms of kind of the transparency. of the investigations, right? Kind of because transparent— it's almost like on the path to the dark force, but kind of in an opposite manner— is transparency leads to trust, and then trust leads to adoption, right? No one will use a tool that they don't understand how the determinations are being generated. Even when they look at the determinations, they said, okay, that seems accurate. I don't have a clue about where they're coming from, but they seem accurate, right? When I think of the One of the keys in implementing this there is kind of looking for ways to have that work done in the most transparent manner, right? So you can look at that investigation and say, hey, the machine took the same steps, right, that I would do, or actually is taking steps that I never thought about doing, but they are pretty good ideas, right? And then that generates a level of trust that will help on the adoption. I think that's probably the number one tip. Now, on reading, because you're talking so much about data, right? And kind of the data generated by the AI SOC and looking into how to improve detection, et cetera. One book that I read some time ago and I love and always kind of keep connecting back to this is called Noise, right? Kind of by Dan Kahneman and kind of 2 other authors. Noise?

Just called Noise?

Noise, A Flaw in Human Judgment. That's the title of the book. It is kind of almost like a follow-up, right? Kind of from Run Things Fast, Think Slow, right? But very focused. That one is very focused on biases and Noise is focused on noise, of course, right? But it really kind of gives a lot of kind of good ideas when you look at noise separately from bias. So I really like—

Really?

Yeah, I really like reading that one. And I'll point to a separate one because yes, it's from one former guest from your show. That's Security Chaos Engineering by Kelly Shortridge.

Ah, nice.

Right. And why I'm mentioning that, because I'm really looking a lot into detection resilience, right? Our detection practice is usually a system, right? And every time you talk about resilience, you're talking about making a system resilient. And I think, yes, exactly that one. And I think that kind of trying to make our detection practice more resilient is really something that we don't see that happening very often. It's something that I love kind of I love that answer.

But you also have a report on this, which we'll link anyway. Thanks for being so modest. There's also a proper security report that you either released or will release, right, on some of this?

It's all there already.

Yes, it's there. Okay, good.

Excellent. Amazing. Listeners, you couldn't see it, but I pulled Kelly's book off of my shelf behind me and held it up, and everybody was happy to see it. So, Augusto, thank you so much for joining us today. This was a really wide-ranging discussion. I'm so grateful that you took my pushback on the metrics answer so kindly. I don't usually do that so directly with people, but I figured a former Gartner analyst could handle it. So, thank you very much for joining us today.

Thank you.

Thank you, guys.

And now we are at time. Thank you very much for listening, and of course, for subscribing. Please subscribe so you can get new episodes piping hot. And if you love our content, please drop us a review on your platform of choice.

You can find this podcast on YouTube, Apple Podcasts, Spotify, or wherever you get your podcasts. Also, you can find us on our website, cloud.withgoogle.com/cloudsecurity/podcast. You can argue with us on the Google Cloud Security Community site, googlecloudcommunity.com.

You can follow us on X, x.com/cloudsecpodcast. Tweet at us, email us, argue with us, and if we like or hate what we hear, we can invite you to the next episode.

See you on the next episode of the Cloud Security Podcast.

By Google.