EP241 From Black Box to Building Blocks: More Modern Detection Engineering Lessons from Google

Secure running.

Hi there, welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Timothy Peacock, the Senior PM for Detection, UEBA, and Risk in Google CycOps, 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 have a longtime listener, first-time caller today. Super fun, but you were notably curious, and I think your curiosity at one point kind of transitioned into the kind of curiosity that a puppy might have about what's inside the couch cushions.

Correct, yes. I feel like I prodded an area where maybe I've prodded before, just not on air. And it was just like unfortunate. And I think I had the— I probably did probably with a little bit of a puppy energy, puppy that had been told to not prod this anymore a few times, but puppy who would be like, oh yeah, I can go and prod there. And then the puppy just went and prodded there. So I know we're kind of over puppy metaphors today, but yeah, that's how it feels. I mean, it's not the curiosity killed the cat vibe. No, no, no, no, no, no, no. It was not that. It was more of a puppy curiosity of what's inside The laptop charger.

Exactly.

Oh, no.

Listeners, Anton and I both currently have puppies, and I think they're on our minds quite a bit, but it's forgivable because both of our puppies are quite cute. So what else do we want to say about today's episode? I mean, it's such a fun talk about the challenge of detection engineering and scaling a corpus from 70 to almost 5,000 rules in the span of just a couple of years, making those rules universally accessible and useful through our product. I mean, there's a lot of great content in here.

I think there are lessons for people that are running operations of various maturities where they create detection rules. I almost didn't say detection engineering because your operation may not quite be as robust as an engineering function, but if you write rules for some detection product, they're probably useful things for you. They're not just the elite top 1% lessons. They're lessons that you can use. And to me, that's probably the big part of the value of this episode is that you can use some things for a detection program.

Whether you are engaged in, say, home detection creating, artisanal detection creation, or truly industrial-scale detection engineering.

And I'm just thinking more of a space station with a robotic factory kind of industrial. Like, not just industrial, but like really futuristic industrial.

Yeah, yeah, yeah. So, okay, I think we need to come up with some model for detection maturity that we'll use on the show going forward.

Which escalates all the way to robotic space station factory, I think.

And starts out with making— what was your metaphor the other day? Spoiled homemade bathtub vodka? Maybe with that, listeners, let's turn things over to today's guest. I'm delighted to introduce today's guest. I know I always say that, but today I really mean it because Rick and I have been working together for what feels like a very long time now, Rick. So delighted to introduce Rick Correa, the uber TL for Google SecOps on our content side. And Rick, it is such a pleasure to have you. Over the last 3 years of working together, you've taken your group from about 70 rules to about 4,700 rules, which just on like a rules-per-day basis, given how small your team is, seems impossible. And so could you walk us through that journey? Like, what were the inflection points? What were the lessons? How did we actually go on that kind of scaling journey with our, with our content?

Yeah, great question, Tim. So I think it started off with us. It was just a small group of people when we first launched. It was actually pre-Mandiant. And when Mandiant and Google merged, I think one of the things that we recognized early on was that, hey, now we have Hundreds of people that are security engineers that can contribute content to us. So we focused on, like, kind of shifting our work model. Instead of us just building detections as one team, we focused on continuing to build detections. We actually pivoted into doing a lot of cloud detections, and we also focused on building tooling and extending our tooling to make it easier for folks on the Mandiant side to contribute. And that really kind of also pushed the envelope to enable us to kind of, like, focus more on Detection as code, not just as building a CI/CD pipeline, but really kind of building tools that are a little bit more IDE-like. So, our Mandiant partners could write rules in a way that was testable, it would fit our coding standards, dot, dot, dot, but also, when they submitted, it would look like it was coming from one entity versus several. And I think today, I think we have, like, over 100-ish partners.

Wow.

unique authors to our corpus, which is pretty awesome.

And those are people all around the company, and because you've created, like, linting standards and all of these other things, it's actually pretty easy for people to plug in, right?

Yeah, yeah, it's just as easy as, like, pointing you at a website, giving you, like, an ID, what-you-see-is-what-you-get interface, and then hitting a button that's similar to play, which is, you know, test. And then once folks are to the point where they're happy with the rule, it's another button that's, like, submit, which has been a huge enabler for us. We've also done a lot of stuff on the automation front. Given where we are in the org and our relationship with VirusTotal, we actually have access to labeled telemetry, and we can automatically generate rules from that content as well, which has been another big enabler.

By the way, we have, of course, the prepared questions, but I want to quickly obsess about one thing that's obviously not your fault. Why do we say curated? What does curated mean, and what is the logic behind Curated rules. Yeah. Why is Tim laughing? I didn't really mean to make Tim laugh. Tim is laughing in the background, probably muted and all that, but he's laughing. I mean, this is—

Rick, please answer the question. This is a great one.

Yeah. So with curated detection, we actually try to do that. So you can imagine me virtually with a pair of scissors in a Zen garden, just kind of snipping the branches where, you know, if Something happens in an environment, we can tune it. So, for example, a piece of malware may adopt, or maybe a piece of legitimate software may change its logging, and all of a sudden, the detection that we had looking for something malicious might start flagging benign software, and it would end up with an alert explosion for our customers, which is not what we want.

Hmm.

I think one of the things is, is a lot of people on the team have actually been customers, so we understand the pain points of, like, Bombarding our users with stuff that's not relevant.

And so Anton, do you have a word you would prefer over curated for that? Because I really like this image of Rick in a Zen garden with scissors cutting up little bonsai trees of detection content.

I don't actually. It was not, I promise, Tim, despite my presumed negative ex-analyst mind, it is not the criticism. It's a genuine confusion about the word curated. It created some genuinely positive vibes in my head, but it also created a bit of a confusion. Like, rules were— we created them. We didn't really curate them. We didn't go on an archaeology trip, found some rules, picked 3 of them, and these are the curated rules. Like, that's the picture I have. But they were created by humans and machines. They were not found in an archaeological dig, right?

Yeah, yeah. Less of the archaeological term and more of the, like, us continuing to own and maintain them. And we do have 2 sets of rules. We have— SecOps also manages a GitHub repository where we do have rules that customers can take and build on their own. I think the curated set actually has an active set of Googlers that are actively making sure that the rules are kind of fitting within our predefined performance boundaries.

So are these kind of like guaranteed rules? Oh, like rules that are guaranteed to work? I mean, that would be kind of nice to have.

Yeah, guaranteed is a big word.

Well, I think now we're getting into a rabbit hole. Guaranteed to work is— you're bringing out the PM in me. Instead of the podcast hosting me, which means I think it's time to go to our next planned question and save that for a whole different episode.

Okay, fine. Yes.

Yeah, I mean, I will say guaranteed. It sounds like a very legal term. And, and, you know, going back to, yeah, going back to like my customer days, like, I just, that reminds me a lot of the breach word, you know, you just don't use that word.

Okay. So, I mean, I would leave this be. I mean, it's not, uh, yeah, I would leave this be and it's not an attempt to prod anybody. I'm just genuinely being curious. So the next question is also, frankly, no less incendiary. So sorry, it's not going to get better. So initially, some of the curated detections we shipped were opaque, which means people couldn't see the logic of what is in them.

Right.

We would just say that we are going to detect this, and that's it. And maybe, I think, what telemetry we would use. So we recently moved almost all of the content to a marketplace so it's more transparent and editable. Tell me about this story. And I mean, if you want to omit some of the politically sensitive details, that's fine, but just tell us the story. I think it's very useful and I think there are lessons in there for many people.

Also, I think it's worth just mentioning on the show, listeners, if you're a SecOps customer, all your curated content, it's now in Marketplace.

Yeah. And so it was a journey, right? So much like any product, we had to do this iteratively. We were forced to make a decision. It's like, well, product, do we build something that enables opaque rules, or do we build something that enables fully transparent rules? And there are a lot of decisions that went— a lot of bullet points that went into this decision. I think one is, one of the really cool things is even from day one, we worked very closely with other internal Googler teams, like the incident response teams, the TAG team at Google, which is phenomenal. And I think they're currently merging with GTIG.

Yeah.

Sometimes there's content that is embargoed that may have vulnerabilities that are not yet public. So, we wanted to continue receiving content from those groups without having to worry about how we not share that with users. And so, we just made the decision point of, like, okay, we're just going to launch opaque for now, and we're going to add the ability to see the content in the future. And that's the path that we've been going towards. But yeah, now today, The majority of our rules, people can see the logic. I think it's great because they can not only see how the rule is working in case they need to tune it, but also be able to take the content and extend and build their own rules. And then we can kind of talk into like the bottoms-up versus top-down detection strategies. But, you know, I think kind of enables those larger conversations.

I think the rules that use secret intel, but they detect something useful is a legitimate reason to not show the logic. Like, look, I'm not the guy who is like an absolute absolutist about like, no, no, no, you have to open. Like, the logic behind the rule uses something that we know and nobody else does, and we plan to detect something useful. We promise, maybe not guarantee, that it's going to work, but we're not going to show you the logic for now. That to me is legit. I don't want to be like philosophical about it. So that makes sense.

Yeah, yeah, yeah, yeah.

The one thing we did try to do like from like day zero was to make sure that any alert that we gave to a customer was both explainable and actionable. Even though we couldn't necessarily extend the rule logic in the product just yet, we at least wanted to make sure that when folks saw an alert, they knew what to do, and not just that something looks funny, go spend some cycles and figure it out, because that wouldn't be cool.

I feel like that's the ultimate time-wasting alert. That's like, something bad happened.

Yeah.

Crickets.

Exactly.

Yeah, yeah, yeah, yeah. So this idea of doing a podcast together, and Rick, listeners, has been a listener for years. I often get text messages from him in the afternoon while he's watching his son run track, being like, Tim, I hated your latest episode. You were too easy on that guest. You should have pressed them harder. Literally, this is my text thread with Rick. But recently you listened to an episode about detection as code.

Yeah.

And you wanted to talk about software engineering for detection engineering. And so could you talk about what gets better there? Why should detection teams start thinking about a CI/CD pipeline? And then Anton, it occurs to me that we should ask a follow-up question based on our conversation this morning. Rick, tell us about this.

Yeah, I assume you're talking about David French's episode.

Yeah, French's episode.

I love David, he's awesome. And, you know, it really kind of got me thinking. I know a lot— he's done a lot of work on building tools to enable customers to kind of build out CI/CD pipeline for detection as code. It got me thinking, I was like, well, you know, the journey we've been on to enable detection, I venture to say very few companies have actually claimed that they can have over 100 detection Authors in their pipeline. And that led us to kind of look at some of the problems that we faced as part of this journey. And very early on, everyone had a slight different interpretation of things. So we had some standard guidelines that are saying, this is how you use a language, this is how you use it for contributing content, these are the variables that you use, the ranges that you use for different scoring, dot, dot, dot. And that was great. But then we started seeing people deviate. So we created a linter, and the linter would flag when people would try checking code. Of saying, hey, this is outside of guidelines, or, hey, you forgot to add this MITRE tag, or, maybe you're using a MITRE tag that doesn't really exist, or maybe the MITRE tag has evolved. I think we see that MITRE gets updated twice a year or so. So, it really kind of forced us to add more and more features. And then more recently, we kind of built this internal IDE for raw authorship. And then we started thinking about performance and being able to get Not just once you write the code and check it in, but being able to continuously monitor the effectiveness of the code, or adding the dreaded, when something starts misbehaving, automatically create a ticket so someone on the team could look at it. And all these things, there's a lot of parallels between that and software engineering practices, because in essence, that's what people do when they develop software and stuff. And even more recently, with composite rules, we're actually adding the ability to treat code as, more modular and being able to treat it more as a library-ish experience. I think one of the things that comes to mind is sometimes a customer will share a detection with us that came from a different vendor, and it's literally 5 pages worth of printed out code, and they're like, help us port this.

Oh, yes.

That's not a dig at the language or the platform, because you could write a 5-page document on a Wild2 rule as well. But you kind of realize how unmaintainable that is, and you realize that these are these special rules that when someone leaves, that rule quickly stops being used.

Right.

And so I think that's kind of the challenge for us is how do we continue to make detection that's very fluid, that's very like code, that's easy to maintain, that's easy to understand, that's easy to kind of provide feedback and dot, dot, dot, all the things that you would want from an actual software paradigm.

Can you say more about the modularity in the composite detection world?

Yeah. So what we're doing with composite rules— and I think John Stoner has written a couple of blogs on the Google Security Community page— and what we're doing is we've added the ability for folks to be able to take snippets of detection logic and then collapse them into separate rules. And that's really powerful because you can— yes, you can do that today in a lot of languages as a multi-event rule, including YARA L. But I think that the challenge becomes large and unmaintainable.

Yeah.

But if you can have it break down into modular components, you could create a really easy-to-maintain rule, but also a rule that is more robust. I'll give you a good example. I'll take something that's in the news. I don't know, the IT worker scams that are going on right now. How do you detect that?

How do you detect that?

How do you detect that? What I can say is, okay, well, let's say you want to detect a laptop farm. So you can say, well, I have an EDR running on this machine. Great. Can I detect someone logging in using a VPN or using a Tor network into that machine using a remote access tool? Yeah, I could detect that. We actually have a feed that enables folks to detect that. Now, what if you want to detect someone doing work, which is like logging into their IDP provider or logging into their cloud account, whatnot. Yes, you can detect that too. And these are all 3 separate things, right? You could build that into one single rule. That's great. But what happens if, like, you know, you have to support another cloud environment, or you want to detect something beyond Tor, you want to detect, you know, another VPN? It quickly turns into this, like, combinatorial explosion. Different rules kind of detecting different things. It's very unmanageable. So with composite rules, what you can say is you can have a rule saying, okay, well, this rule is just detecting Tor. And I'm going to emit, like, an event. The way we chain these together is using what we call outcome variables. And basically, it's just a label. And you can say, okay, well, when this fires, trigger a suspicious IP. Now you can have a whole set of rules that's residing on the next stage saying, okay, well, anytime that someone emits a suspicious event, fire off and see if I can detect this additional action. And you can quickly build these very modular rules that work without you ever having to touch all these other downstream rules. So let's say, for example, you have something that's poor and then you build a VPN, or build— maybe you build another rule that's detecting unusual ASNs to your environment. You don't necessarily need to revive your entire corpus anytime you're looking for additional events. You just fix this one rule and you output the same event, and guess what? Magically, all these other downstream detections can fire from that.

Hmm. I think that structure makes sense to me.

Yeah. We had a conversation this morning, Anton and I, we were talking about advanced practices in organizations, and we were talking about how a lot of organizations will get pretty far ahead of others in a particular direction because it seems cool, it seems new, it's exciting, it's the latest and greatest tech, and they've got engineers that are capable of chasing a trend. And I want to pick at this software engineering for detection paradigm a little bit and ask, do you think this is reasonable for most people to do, or do you think this is the kind of thing that only the security haves will have to do?

I think that's a good question. I think, kind of channeling my customer view, you know, when I was a customer, I would say that it depends a lot on org maturity. And there's some orgs that they're earlier in their journey and their folks are relying on their vendors to provide detection logic. And eventually they graduate where they're writing their own detection logic. Eventually then they graduate on building detection logic on modeling some of the things that make that company special. So obviously I think On the latter stage is really where you want to have a little bit more formal software engineering practices. And I think this is where really that comes into play. It's not necessarily where you need to be a Fortune 100 or a well-known technology company. I think that to me, the pivot point is when you start writing your own detection logic that is more than 2 or 3 people, very similar to when do you create your own GitHub page? It's like when you're having to interview some people. Yeah.

I think that makes sense. And I think it's a really good answer because there's a range within the detection engineering field from a robust operation with solid lifecycle, large teams, and people who, well, occasionally make their own detections and they're happy with them and they retire them eventually. So, there's a lightweight detection engineering, like a baby's first detection engineering effort versus something quite robust. And I think that range is quite useful. I want to switch gears to the number of rules. Back in my analyst days, I've seen a lot of vendors who kind of competed on the number of rules. And when you prod them, you realize that they just shove a big list of bad IP addresses into detections. And they say, oh yeah, we have 6,700 rules. And you say, oh wow, that's kind of impressive. And you look and it's like 6,700 IP addresses they've heard of or maybe saw somewhere online as bad. Like, I'm quite allergic to that. But at the same time, people who promise the broad patterns rules occasionally suffer from high FPs. Because a lot of legitimate activities trigger those. So is there any kind of Goldilocks magical number? Like if somebody wakes you up at 3 AM and says, what's the right number of rules? Would you give an answer or would you give like, it depends answer?

I love that question because it's something we struggled with internally as well. And so I think going back, it's the earlier part of your question. It's like, you know, as far as I know, we're not encoding IoCs in any of our rules because I think that would be cheating. But like what we try to do is Even internally, as folks on the team, when we're talking about performance metrics for individuals, one of the conversations we've always had that we've always struggled with is, do we ask people to deliver a number of roles every quarter, every planning cycle? We really struggle with that answer. I think the right answer is, we try to do what's the right thing, and the number of roles where that takes us, that's just a side effect. I will say that even our own internal reporting, we've kind of struggled to say, okay, well, do we Do we use number of rules as a benchmark, or do we use number of alert feedback or whatnot? And I think that it really kind of depends, right? So I think the approach that we're starting to take more is we're looking at actionable alerts that we provide to customers, especially as we're going down this composite chain. Because number of rules and number of alerts are both— a high number of rules and a high number of alerts that are generated from those rules is probably not what you want to give to a customer, because they're just going to get frustrated and turn you all off.

Yes.

I think actionable is probably a little bit more of a Goldilocks zone.

So it's not about the number of alerts, it's about the quality of the alerts, and not about the number of rules, but the quality of the rules.

Yeah. And, you know, I think a good question to ask is, you know, if you put an average person in front of what you're detecting, are they going to feel comfortable? Are they going to, like, want to continue looking at that data source and saying, okay, well, you know, maybe there's a false positive here and there, I'm okay with that, but it provides enough true positives for us. I think even true positives is an interesting conversation that we sometimes see, which sometimes people's definition of a true positive or false positive tends to differ a little bit. That's also kind of a fun thing. It's like, oh yeah, you caught Mimikatz, but don't worry, it was me running it. I forgot what my password was, but we're good. We're good. It's a false positive.

Yeah. By the way, as a side comment to this, which is, of course, a very useful discussion, What really pushes me over the fence is when people say, but did you count false negatives? And I'm like, stop, stop, stop. Do you know what you're talking about? Like, in general, even loosely speaking, do you have a clue? And the answer is occasionally funny, but yes, I do see sometimes people who say that they require a solid metric on false negatives. And I'm like, what?

That's very like Rumsfeldian. Unknown unknowns. Like, I don't know what's going on there.

Yeah.

That's a lot to think about. Rick, I want to ask about this building blocks approach that you're proposing. We've got lots of curated content. It's now transparent. Now that it's transparent, now that we have composites, customers could in theory put our stuff together as Lego pieces. And so could you talk about how you're making that easier for people or how they should be thinking about doing that?

Yeah, totally. We kind of consider it like building blocks, is that like, you know, part of this corpus of rules that we're delivering, we can consider those signal rules. Do you want to create a detection where someone— where it fires every time someone logs in to their admin console on their cloud console?

Probably not.

No, I don't know, probably not. But what if you can combine that together with another signal rule that says, okay, well, if someone does this from an ASN they normally don't Do business with, and then they do some kind of admin action like disable MFA or create a new admin account. It becomes interesting, right? Now, if you're a customer, how do I build that detection? Yes, I can try to replicate this and then do it myself. I could say, hey, what do I have to work with in my building block box? So I can take these blocks that already exist and then build the last mile for myself. Maybe the last mile for myself is an identity provider that we don't support, or maybe it's an internal application of your company, your admin panel, whatnot. And so now, instead of that multi-stage problem, you just have to worry about the last stage. And that's really kind of what we're hoping to provide users, both with composite roles and also with making our roles transparent.

Hmm. Okay. That actually makes sense. And I think that the logic behind building blocks on one side kind of makes things a little harder to explain, but also adds a lot of power to people who say, oh yeah, I want to have 50 detections. And you say, well, we have that many, and these are building blocks. These are really finished detections. So it takes a little bit more to explain, but the power is increasing quite a bit. So I think I like that. And I think that teaches people to go beyond just like counts. Oh yeah, I have 6,700.

Yeah.

So I think we need to mention AI, right, Tim? Do we have— I mean, we are not renaming the podcast to AI Security Podcast, Not quite yet.

Not yet.

Probably not at all. But this is probably the time when LLM should peek its head in and ask, well, what about me? So, you are using some of this, of course, in your processes in rule design. And I don't know if LLMs help you curate things, but can you expand about what the LLM role is and what have you found the kind of like ripe areas for AI in detection engineering? And are there stories where it worked beautifully and the stories maybe where it, what's the polite term, failed?

Yeah, no, a great question. I think we're still exploring that. I think there are some things I found a lot of personal, again, maybe this is my personal answer, not the Google official answer, but I have found AI is great at reducing tech debt and making it easy for me to focus on that 20% problem if I can handle the 80% problem. So, yeah, I've vibe-coded a Wild2 parser that would go through and parse an average Wild2 roll and then give us metrics. And I did that in, like, what, 30 minutes of vibe coding, and then an hour and a half of tuning. That normally would take me 2 to 3 days. And so, that enabled me to be faster and focus on other things that freed up some cycles on it. I think kind of the question you're probably asking is, have you all had success on using Gemini to auto-generate rules? Yeah, I think that's still kind of a work in progress. I think there's some things that initially, if you were to ask me that a year ago, I probably would laugh along with you. But I think now, if the answer is a little bit more bounded and you're able to provide more guardrails and saying, maybe here's some telemetry, here's a rule corpus, build a rule that aligns to this rule corpus that can detect this telemetry. We get a little further on. And I think that's as the models continue to improve and we get better at prompting, I think some problems are going to be better solved than others. But I don't think I'm out of a job just yet.

Yeah. And I think that part makes sense because people sort of assume that this is like, yeah, we're just going to ask LLM to do it and then LLM does it. But the result is not always what they actually needed, wanted, or expected. So it's not a question, can LLM do it? Oh yeah, LLM can do it.

It's not like asking a puppy to do a command. It might do it, but it might not be what you wanted it to do.

No, you're absolutely right. And sometimes, like, at first, maybe when you get— it's a puppy, maybe you ask them to fetch their favorite toy, they come back with your slipper, you know, and they get a little older and you've kind of trained them a little bit more and you know what to ask for, maybe they get better and they fetch that toy for you more reliably.

More likely they would fetch half of your laptop charger with the other half being left wherever it was.

So yeah, that sounds Sounds like you're talking from experience.

So it is unfortunately now the time where I have to do my least favorite thing, which is ask our closing questions. And Rick, thank you for joining us and being such a good sport about our unscheduled questions. One, do you have one tip to help people get started with their detection engineering through software engineering journey? I don't want to call it detections code. I want to call it detection engineering through software engineering journey. And 2, do you have recommended reading? And that recommended reading could be anything.

Yeah. I think my first tip is always start with first principles. I tend to approach detection engineering and software engineering as like, you know, the science fair project, right? Start with a small problem, start with like logging the time you perform the action, and then determine what normal is. I think those are all kind of the 3 building blocks to being a good security engineer in general. I think, like, recommended reading, I think having heard enough of the episodes, I know Anton's blog is not an acceptable answer.

You did do that to yourself. You didn't even need Kim to do it to you. You did it to yourself.

You'll notice I didn't even tell you. I knew you would know.

No, I think, obviously, I think LinkedIn, there's a few people I follow that are great. They're always posting amazing content. Josh Neal's stuff pops to mind. I think, you know, Zach Allen's, like, detection.

Friend of the show.

Yeah, both awesome things. I think as far as books, there's 2. Megan Roddy wrote a great detection engineering book that focuses more on the theory. There's another detection engineering book that I am drawing a blank on. I will find it in a second. I think when we were talking about this, you mentioned not to look at my screen, and I'm doing that now. I'll have to get back to you. It'll be in the show notes, but it's definitely Biggest thing is just get your hands dirty. Try, set up a small experiment, set up a small lab, try to perform an action, see if you can detect it. Don't worry about running like Stuxnet on your environment. Start off small and kind of work your way up.

Awesome. Well, Rick, I can't thank you enough for joining us today.

Yeah, anytime, Tim. Anton, it was great seeing your puppy earlier.

Perfect. Thank you.

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. Security.