EP219 Beyond the Buzzwords: Decoding Cyber Risk and Threat Actors in Asia Pacific
14 Apr 2025 · 32 min
Steve Ledzian, CTO of Google Cloud Security at Mandiant APAC, explains why boards misunderstand cyber risk as a purely technical problem. In the Asia-Pacific region, non-ransomware dwell time averages 26 days, double the global average. Security jargon like "hunting" and "breach" lack standard definitions, making communication between technical teams and boards nearly impossible.
Chapters
Security.
Hi there.
Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here, as ever, are myself, Timothy Peacock, the Senior PM for Risk Analytics and Detection in Google SecOps, and 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 the Cloud Security Podcast listeners on the Google Cloud Security Community page. Anton, we— well, I have a really fun conversation this week and you are MIA because you were not in Singapore.
So sad.
That's right. Yes. I'm also quite envious because I'm sure it was a fun trip and it looks like it was a fun conversation as well because I was trying to understand from the notes what you talked about, and I see boards, I see threat actors, I see synergies. Did you really talk about synergies?
No, I don't think we used that word. I think I kicked him under the table when he looked like he was going to. This was a fun one, listeners, because we actually recorded in person, just me and Steve. And so maybe without giving anything else away, let's turn things over to myself and my buddy Steve. With that, listeners, I'm delighted to introduce today's guest. Today we are coming to you live from— well, not live, but we're coming to you from Singapore. I wish it was live. Today we're joined by Steve Ledzian, the CTO for Google Cloud Security at Mandiant across Asia Pacific and Japan. Steve, thank you for joining us today. Super stoked to have you on the show. It's been a long time coming, so finally happening.
Great, Tim. I'm happy to be here.
I want to start off talking at a really high level and then we'll get into it from there. We've seen over the last 10 years, 5 years, a continuing shift in how boards engage with cyber. From your perspective, what's the biggest misconception that boards, particularly in the region, are still seeing, and how is that impacting their decision-making?
Yeah, we've been briefing boards for, I would say, about 10 years now. And so there's a long, I would say, a long evolution on how the boards have matured in how they see cybersecurity.
So it's getting better?
It is definitely getting better.
What's changed?
The boards have more awareness. You know, the boards are made up of very smart people, very good decision makers, very accomplished people, but they are still, I would say, not very educated on cybersecurity. And so they still have a lot of misconceptions. I would say one of the big misconceptions is that they see the problem of cyber risk as a technical problem, right? And technical problems should have technical solutions. And that kind of leads them down this path of believing there's some sort of silver bullet, which can make the problem of cyber risk go away.
Oh yeah, that'd be nice.
Yeah. But of course it is not a technical problem. It's a human creativity problem. And like any other risk, you can reduce the risk, but you probably can't eliminate it. And so to give one specific example, we were talking with a board and they saw encryption as a silver bullet.
Oh yeah.
Encryption is very hard to brute force. My data is encrypted, and therefore everything should be fine, right?
Of course. Therefore.
I asked the board, well, you know, if it's encrypted, how do your employees use it? And they thought about that, and they said, well, of course they have the access to decrypt it. And I said, well, what if an attacker had that access also? And light bulb went off, and they kind of realized it's not taking the defenses on directly, but hacking is the art of finding a way around those defenses. And so I think that's still a big misconception. One of the things we do also in these board briefings is we have a really good demo, visual demo.
Oh yeah? What do you show them?
We show them a ghost rat attack from one Windows machine to another, and it does things like steals files and captures passwords. turns on the webcam. And I've had boards come and say, you know, we've seen a dozen cybersecurity presentations and we thought we understood the content in those presentations, but after seeing the demo, we're shocked.
Huh.
So we really didn't understand what was being presented to us. So I think there's still a long way to go for boards, but it's definitely improving. They're definitely getting better. The frequency with which we are asked to brief boards has gone up tremendously. We're briefing boards probably every week or so across JPAC region. And yeah, so it's getting better. The boards are certainly interested.
That's encouraging.
And there's a lot of regulation that I think requires the boards to have these sorts of briefings. So I think that's driving some of it as well.
So good regulation there.
Yeah.
Yeah. So one of the things I imagine you run into is like the jargon problem. You know, when I was A wee lad working in DC, I remember, I'll never forget trying to explain the difference to a Cold Warrior between an ISP and an ICBM and why they were not similar. I don't know why this Cold Warrior guy had gotten them mixed up, but he was very confused about the difference. There's a lot of jargon. What jargon has been most problematic for you in this region and what would you like to see our industry do differently to deal with our jargon problem? Or do you even agree there's a jargon problem?
Yeah, I definitely agree there's a jargon problem. In security, we have these words that are so overloaded with meaning that they lose all meaning when you try and use them.
Like, what's an example of that? What's overloaded in particular? Well, because I bet listeners are thinking of 12 things and shouting at their cars right now.
Sure, sure. You know, hunting, I think, is probably— you know, if you ask 12 people what the definition of hunting is, you'll get 12 different answers.
Maybe 13 even.
Very likely. You know, I think hunting— I think the words we use, we want to be able to differentiate them from the words we already have, right? So hunting should be different than detection.
Sure, it is, isn't it?
For some of those definitions, yes, but for others, no. You've seen— I've seen organizations and even vendors use rule-based detection and call that hunting, right? So there should be a difference. between standard rule-based detection and what hunting's doing.
Sure.
Hunting should be able to accomplish something that that rule-based detection wouldn't be able to. So hunting, for example, might be a group of analysts who take weak signals that you couldn't put in an automated system because they would generate way too many false positives, take all those weak signals, comb through them, and analyze them. Manually, right? And come up with net detections that a technology otherwise couldn't accomplish on its own. I think that would be a good definition.
I can see how people would mix those up, though, because they both have the goal of catching bad guys, but they're so different. Yeah.
So maybe even worse—
It's kind of like, oh my gosh.
Maybe even worse than hunting is detection or prevention, or—
Yeah.
Those get overlooked. But I think another good example is even the word breach, right? So at Mandiant, long ago, we said breaches are inevitable. And so at that time—
You all were a cheery bunch, weren't you?
Yeah, that wasn't— if you listen to what Kevin says about that, it wasn't received so well in the markets. But when we said breaches were inevitable, what we really meant was intrusions.
Sure.
Intrusions are inevitable. So you can't always have 100% effective prevention. Prevention will fail from time to time. And that's what we were saying when We said breaches are inevitable. But today the word breach has sort of morphed into, you know, the whole end-to-end cyberattack, including all the impact.
Yeah, yeah, yeah.
So if you say breaches are inevitable, you're kind of taking a defeatist stance and saying, you know, there's nothing we can do to stop these cyberattacks. And that wasn't the original intent of that statement of breaches are inevitable. It was intrusions are inevitable.
That's such a subtle point for a lot of people though. And I think one of the interesting things is how well that lines up with the conversation we had I don't think it's aired yet, but it'll come out soon with Google's vulnerability team, where we were talking about how vulnerabilities are inevitable. And if you take a mindset that, yeah, we build software, software has vulnerabilities, we're going to take steps to do what we can to minimize them, we're going to take steps to have a bounty program, we're going to take steps to remediate quickly, but vulnerabilities are inevitable. I actually think that's a very reasonable approach to take to breach as well, even in the modern SEC-mandated reporting meaning of the word breach.
Absolutely. I think that thinking is a thinking that leads to a resilience posture, right?
Say more about that.
Well, maybe we can talk a bit about the attack lifecycle.
Yeah.
But the idea is that, you know, prevent as much as you can prevent, except that, you know, you won't be able to prevent everything. A sophisticated, motivated attacker with enough time will get in, and when they get in, you want to be able to spot them quickly.
Yeah.
Which is something that maybe we take for granted is already happening. But if you look at the MTrends reports and the statistics on dwell time— and just let me define dwell time as the time an intrusion occurs to the time the intrusion's discovered— the dwell time is measured in days. So organizations aren't doing such a good job on spotting intrusions quickly.
But is dwell time down?
Dwell time is trending down. It used to be over a year in Asia Pacific. We're down now to days, which is a substantial improvement. And actually, I would attribute that to the mindset of, we need to do more than prevention. We need to do detection and response. And there's that overloaded term again, detection, meaning not detection of malware, but detection of a prevention failure, detection of an intrusion.
Detection of a prevention failure. I like that. My mother, I love talking about my mom on the show, listeners. Don't read anything into it. She had a mousepad from her job that said on it, preparing for the inevitable. And she worked in AT&T's disaster recovery division for a very long time.
Wow.
And I think this mindset of failure is inevitable. Failure is not the worst thing that can happen. The worst thing that can happen is not being ready to recover from that failure and have a plan in place. That's very interesting to me, and this dovetails nicely with the conversation that we were having with Phil at the end of last season as well, actually. So you mentioned the ATT&CK lifecycle. Let's talk about that. How does that work, and how does that help people be more secure? What's the theory there?
Yeah, so the ATT&CK lifecycle is a bit like the MITRE ATT&CK framework. And by the way, to just roll back a little bit to one of the previous questions you asked, what could we do in the industry to make things better in the area of all the jargon we use and the overloaded meanings. You know, MITRE has done such a great job in giving us a common language for classifying types of attacks.
Yes.
If we could do something similar like that on the marketing end, right? So prevention had a specific definition, protection had a specific definition, detection, hunting all had very specific standardized definitions in the way that MITRE has done for ATT&CK. I think that would be pretty interesting and helpful.
Yeah, it's always interesting. One of my favorite episodes we do every year is when Anton and I walk around the floor at RSA, and we have so many times looked at a booth and shaken our head at the marketing copy because of how badly some vendor is abusing some term of art that used to have meaning, and we just see the erosion of clarity happening. I think that's a really hard set of incentives to break for marketing as an industry. It's so tempting to want to make your splash and get your message out there, and there's such a— just like a— it's like beating the tide back almost of these terms losing meaning. And so tell me about the ATT&CK lifecycle that Mandiant describes, and we'll talk about why that's good.
Sure.
I suspect there's meaning there.
Yeah, yeah. So the ATT&CK lifecycle is a bit like the MITRE ATT&CK framework. The tactics specifically. So it's a more condensed version. It starts with the first stage of initial reconnaissance, moves on to initial compromise. Beyond that, the attacker establishes a foothold. From there, they'll escalate privileges, do internal reconnaissance, lateral movement, maintain persistence, and they may cycle along that.
I was going to say, those stages sound connected. Yeah.
As they move from network segment to network segment, ultimately getting where they want to be in the victim network, and then they complete their mission wherever it is. But that's a— it's a really good model for understanding what we were talking earlier about prevention, detection, response, and resilience, because you can draw a line across those stages, and that line is at the second stage of initial compromise.
Hmm.
To the left-hand side of the line, the attacker is not inside your network.
Mm-hmm.
To the right-hand side of the line, the attacker is inside your network.
That's a phase change.
And you can model all sorts of things around that line, right? And so there are security controls, which are prevention controls on the left-hand side of the line, things like firewalls and antivirus. And then there are security controls on the right-hand side of the line that are aligned more to detection and response, like EDR and MDR and managed detection and response services. You can look at other things as well. So I heard on an earlier episode of the podcast you were talking about the defender's dilemma.
Yeah.
Of, you know, attacker has to be right only once and the defender needs to be right every time. That's true.
You know, Anton and I both hate that.
Yeah, I know. I know you hate it. That's why I brought it up.
Yeah.
Good.
Listeners, it's 9 AM in a time zone that I arrived in yesterday, so Steve's getting me fired up here.
That defender's dilemma is true on the left-hand side of that line.
Yeah.
On the right-hand side of the line, it turns to a defender's advantage because now the attacker's in your network, and you have the home-field advantage. And all it takes is one misstep of that attacker to land on the— trigger the wrong EDR alert or the wrong NDR alert, and one alert is enough to reveal their presence. And so that dynamic flips on its head across that line. I'd say enough.
That's a really good insight. I really like that.
I'd say another interesting thing along that line is that a lot of the prevention technologies are set and forget. So you can buy a technology, rack it, and let it do its blocking. But on the right-hand side of the line, on the detection and response, many of the technologies need to be piloted by analysts, right?
Yes.
The EDR technologies, once it triggers, there needs to be an analyst who does an investigation. And so that detection and response in the post-exploitation stages of the ATT&CK lifecycle requires people. And that's a different mindset than what we were doing with prevention, I would say. And that's why detection response is a lot harder than prevention, but they're both necessary to achieve this end goal of resilience. Yeah.
Yeah.
That's really interesting. I think my vulnerability program management friends will be grumbling in the background when we say that DNR is harder than prevention, but I'm tempted to buy that argument myself. So, I want to shift gears and pick at something that I've been noticing throughout our conversation, which is the almost eerie similarities between how old Mandiant thinking and old Google thinking line up. So, it's been 2 years post-acquisition, post-Mandiant coming on board. Obviously, the organizations both brought a ton of talent and a ton of expertise in the security space. We all expected this to be great, and I think it's exceeded everybody's expectations. But what's been, for from your perspective, surprising about the acquisition and its benefits?
Yeah.
And don't tell me it hasn't been great.
No, it has been great. So I have, I guess, maybe 3 points to make here. The first is around cyber threat intelligence. And one of the surprising things to me was how quickly the teams were able to take the various intelligence offerings like VirusTotal. And of course, Mandiant has its own threat intelligence. and combine them into a single offering that's customer-facing and generally available today called Google Threat Intelligence.
Shout out to podcast guest and friend of the show Vijay, and of course also friend of the show Sandra, on bringing those 2 teams together.
Yeah, well, and it's the products is one, but also correctly, as you said, it's the teams, right? And so those teams now within Google, we have Google Threat Intelligence Group, which has been restructured in a way to optimize all the talent across those teams and across the company into a single threat intelligence organization. And that happened very quickly as well.
It really did. And seemingly smoothly too. And I think what's so interesting is, I tell this story all the time. I talk to users, and I've been talking to users about Google's threat intelligence since long before the Mandiant acquisition. I compare it to the difference of like, we used to have the Hubble Space Telescope, which was really impressive, but now bringing Mandiant into that and putting it all together, It's much more like the Webb Space Telescope. You have these deeper, richer, much better views of the world.
They're very complementary, right?
They are, yeah.
So you've got crowdsourced, very broad threat intelligence coming in from VirusTotal, and you've got curated, very deep threat intelligence coming in from Mandiant. So there's not a lot of overlap across them as well.
No, they're very complementary. The other way I put it to people is I talk about, you know, you've got VirusTotal for It's history and crowdsourced. You've got safe browsing for protecting billions of devices a day. So you've got a depth, you've got a breadth. But the critical thing, especially with cyber, where you've got adversaries who are operationally changing all the time, is you need currency and recency. And because so much of the Mandiant intel comes from our world-leading IR engagements, you get that there as well. And it's really a piece that was missing before.
You teed up my second point.
Oh, good.
Exactly with the currency, which is a feature inside of Google Security Operations powered by threat intelligence called Breach Analytics. So particularly with IOCs, IP-based domain hash IOCs, you know, have a very short usefulness in terms of time to live.
Oh, yeah.
One of the things we're doing is taking the IOCs and active Mandiant investigations— and we're active in hundreds of investigations, you know, around the world at any given time— taking those active indicators we see in breaches that we're currently responding to and using them as detections within Google SecOps. So that's something that we couldn't necessarily do before, but because of the cloud nature of Google SecOps and Mandiant and Google coming together, it's something we're able to do today, which I've seen a lot of customers see a lot of value in.
Yeah, the mission there is really avoid having patient number 2.
Yes, yes, yes. And then the third point was, if you're following any of the Mandiant threat intelligence blogs, you know, subscribe to them or join the RSS feeds.
We'll have the link in the show notes, listeners.
Those blogs now, at the very bottom, are talking about the threat intelligence offerings, the collections within VirusTotal, the curated detections going into SecOps. So all that Mandiant intelligence and research, you and frontline discovery is making its way back into the Google products, as well.
But it's also making its way into VT and the blogs, which means we're open-sourcing it in a way.
Yeah, I would say so. I mean, some of the— on the VT side, some of the collections are publicly available, and then—
And then there's also private.
And then there's also the curated detections, which would be private to Google SecOps customers. Yeah.
Fascinating. Fascinating. I love that. I love that we're doing both sides of that coin. One thing you mentioned earlier is dwell time. Tell me about what's going on with dwell time, especially here in the Asia-Pacific region. What are the factors influencing that? Why is it going down? Is it going down fast enough? Tell me all about that.
I think there's many factors, and it's hard to tease out what the, the true root causes are for the decline. It is declining substantially, which is good news for all of us, but it's still At APAC, if you look at the dwell time for all of the intrusions that Mandiant investigated over 2023, our 2024 data will be released soon. It was 9 days.
That's quick.
It's still over a week to have it. Imagine an attacker in your home.
Yeah, somebody hiding in my home for over a week.
That would be scary.
I think my dog would notice.
We hope someone would notice.
Yes.
But, you know, in these digital networks, no one's noticing. Tools aren't noticing, the SOCs aren't noticing, the MSSPs aren't noticing for 9 days. And that's— it's still a long time. Much better than 1 year, but still a long time. Now, it turns out that that's better than the global average, which is 10 days. So APAC beat the global average by 1 day.
Nice.
Congratulations, APAC. But when you dive into the data, It's not so nice a picture.
So you've built me up. Now you're going to throw me down. What's the not so nice?
Well, we were measuring dwell time before there was a significant ransomware problem. And as ransomware came on the scene, we started responding to ransomware incidents, and those ransomware incidents started contributing to the dwell time. Of course, if it's not a ransomware incident, or a cybercrime incident, it's a nation-state incident, espionage incident, where the attacker is motivated to stay hidden for as long as possible. But that's not the case with ransomware.
Right.
The ransomware threat actor reveals their presence when they give you a ransom note. So in a way, we're sort of— the ransomware actors are helping to reduce the dwell time. So you might want to ask the same question of dwell time. Well, what were the dwell times in Asia Pacific And global, if we subtract out all of the ransomware. Yes, that's my next question. And so the numbers for those are, the global number is 13 days. So global rises from 10 days to 13 days if you pull out the ransomware attacks. Asia Pacific and Japan raises from 9 days to 26 days. So we're about at a month for detecting attacks where the attacker doesn't reveal themself. And so now Asia-Pacific, Japan is double the global number, not one day less.
And what do you think contributes to that?
Well, it's—
is there more espionage activity here? Is there lower rates of internal monitoring? What do you think is leading that?
I think—
Ooh, I asked a hard question.
Yeah, that's a hard question. That's a hard question.
Yes, finally I got one.
I'd say probably a couple things. I think Asia Pacific is a little bit slower in cloud adoption. And cloud adoption helps you monitor more easily. And I would argue is also more secure than trying to do everything yourself on-premise.
I have argued that many times.
I think there's also countries in Asia Pacific are slower to adopt breach detection or breach disclosure.
Oh, sure.
And so the awareness of it is generally lower. That's not to say that there aren't good efforts going. There certainly are. And Asia-Pacific dwell time is dropping dramatically. But we're still at a dwell time for non-ransomware attacks of 26 days, which is a month. So there's still— while great work has been done, there's still a lot of work to be done on top of that.
Well, that's good. It sounds like we're making progress and you and I will continue to have jobs at least for another couple of years.
Hopefully.
One of my favorite things about those disclosure laws, did you see the ransomware gang that not only ransomed an org, but when it looked like the org wasn't going to pay, the ransomware gang threatened to disclose to the SEC that they'd been breached?
Yes.
Did you see that?
Yes.
That blew my mind.
Yeah. So there's really interesting ransomware trends as well. So To go to a regulator and say, hey, this organization is not following your regulation. They've been hacked and they haven't disclosed it to you. Never mind that we were the ones to hack them, but you may want to take a look at it. That's a pretty interesting topic.
Imagine trying to collect the whistleblower award on that one.
Well, I think they went right to the whistleblowing website in order to report it. So yeah, really, really interesting things. Attackers will also, as they pull information from their victims, one of the sets of information they might pull is customer records.
Mm-hmm.
And so they might go and communicate with the victim's own customers and tell those customers, your company, your vendor, whatever it may be, has lost your data, and you should be contacting them to figure out how they can protect you.
What? Oh my God.
And they're essentially positioning themselves as, you know, stand up for yourself and protect your data that we have stolen as the attackers. Yeah. So that's another—
That's phenomenal.
That's another quite interesting one as well. And the other thing we've seen is attackers who, when they collect the data, they might collect the data of executives and send letters or even flowers to the home addresses. Of those executives as an intimidation tactic. That makes a cyberattack very personal.
That's extremely personal.
So getting the leverage to extort the victims, that's taking it to a whole nother level.
That's terrifying. That reminds me of a conversation that we were having with Dave Hannigan about express kidnapping. So check out the Hannigan episode, listeners, for the express kidnapping operations and what that means for people. So unfortunately, we're getting close to time, and I'm going to ask one more question, then I'll ask our traditional closing questions. No 3 AM test today, listeners, because Anton's not here with us. But my favorite question, which is predicting the future. So what do you see as the biggest challenge facing customers in your region going forward, you know, like say next 5 years, and what should people be doing now to get ready for that?
Yeah, I don't see it changing. I think today the biggest problem is ransomware, and I think immediate future, the biggest problem will continue to be ransomware. Right next to that is business email compromise, which doesn't get a lot of the attention that ransomware does.
Can you tell everyone what BEC is? Because I'm not sure everybody knows.
Sure. So business email compromise is—
Is that just they read my email? Because I don't like to read my email. They can read it.
No, it's kind of— it's kind of the old scamming, the individual 419 scams grown up and attacking corporations.
Really?
So it's tricking someone in a financial part of the organization to make a payment into an attacker-controlled account under the guise of—
So this is the mom and dad, I've been arrested, I need $30,000 to bail out, but for a corporation?
A little bit like that. I'd say not so much high pressure like that. It's more deceptive.
Oh, really?
I am your vendor, and I've just changed banks. And so you're sending me monthly invoices, and for this month's invoice, please remit payment to my new bank.
That's so subtle.
Yeah.
Wow.
And some of the attacks involve the attacker compromising the legitimate email account of that vendor, reading the email to see when the invoices are sent, what the invoices look like, what are the tone of the communications, So they can craft things which are very compelling.
That's incredible.
And they're tricking organizations out of tens of millions of dollars in a single go. So it's just as impactful as ransomware.
That's even worse than ransomware. You don't have an opportunity for your ransomware prevention tool to catch that.
Well, that's a great observation, is that the business email compromise is scams, right? And so we have lots of controls which are good at detecting malware.
Yeah.
But there's really no malware involved here.
No malware.
What you really need is a lie detector.
Yeah.
And we don't have those in our networks yet.
No, on the internet, nobody knows you're a dog. In an email inbox, nobody knows you're a scammer.
Yeah. So that's BEC. Wow.
So listeners, I can't believe we've done the show for over 4 years and I can't think of an episode where we talked about BEC before, but how about that? So breaks my heart to do this, but I have to ask our traditional closing questions. One, do you have one piece of advice? And I think I want to go all the way back to the beginning. One piece of advice for communicating with boards about cybersecurity. And then 2, recommended reading.
Yeah, so the advice is the communication is important. We deal with technical aspects every day. We talked about all the terminology and acronyms and jargons earlier. When you talk with the board, you have to drop all of that, right? And you need to talk in their language, which is risk, or at the very least, just talk in plain language. You have to monitor what you're saying and filter out Be very conscious that you're not using technical language when you're talking to the board. If you can communicate plainly and clearly, I find the board's very receptive to it. And then for reading, you know, I would like to point your listeners to what's called the Risky Bulletin, which—
The Risky Bulletin?
Yes. So there's a media outlet out of Australia called Risky Business. They do a podcast as well. Hopefully no competition here.
We're all friends. They're like the granddaddy of security podcasts. We would never compete with them. We look up to them.
Yeah. And so, some time back, they brought aboard Katelyn Campanu, who's just a master at gathering everything that's happening in the security landscape— cybercrime, espionage, just everything across the board. And he releases a 2 to 3 times a week newsletter called the Risky Bulletin, which covers everything that you need to know as a security professional. I think the content's great. There's also a podcast version of it, so if you prefer to listen than read, but it's—
I bet our listeners like podcasts.
Yeah, I would think so. And yeah, it's a great resource if you're a cybersecurity professional.
Well, Steve, thank you so much for joining us today.
Tim, it was a pleasure.
And now we are at time. Thank you very much for listening and of course for subscribing. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever else you get your podcasts. Also, you can find us at our website, cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes. You can follow us on Twitter, twitter.com/cloudsecpodcast. Your hosts are also on Twitter at Anton_Chuvaikin and _TimPico. Tweet at us, email us, argue with us, and if you like or hate what we hear, we can invite you to the next episode. See you on the next Cloud Security Podcast episode.
Secure running. Secure running.
More from Anton


EP289 Software Engineering vs. Software Craft: How Google Scalably Eliminates Classes of Vulnerabilities


EP288 CISO Tested, Board Approved: Cloud Resilience with General Mills CISO Noah Korba


EP287: Creating Trust at Global Scale with Local AI: Reken-ing with Shuman Ghosemajumder


EP286 Building an AI-pilled, solo vibe-coded, Clickhouse-based SIEM with Dan Lussier


EP285 Scaling Lessons from Leading the NSA to Defending the World with Morgan Adamski


EP284 Closest Alligator to the Canoe: How Transforming SOC Became P0 for Lloyds Bank


EP283: How Google Cloud CISO Chris Betz Uses LLMs to Defend Billions of Users from Vulnerablities


EP282: Debating Coupled or Decoupled SIEM with Alex Hurtado and Christopher Witter


EP280 Hyperscaling Cloud Security: Wiz Joins the Cloud Security Podcast by Google