EP216 Ephemeral Clouds, Lasting Security: CIRA, CDR, and the Future of Cloud Investigations

Security.

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 Risk Analytics and Cloud Threat 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.google.com/podcasts. 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 all on the Google Cloud Security Community page. Anton, we are talking about an unpronounceable acronym because it has ambiguity in the first letter. Is it CIRA? Is it CIRA? CIRA?

I mean, it is one more of my former colleagues' creations. Yes, it is the CIRA, and it's one of the acronyms where apart from doubts about the first letter pronunciation, you also have doubts about the need for it.

Oh, I certainly have doubts about it. But I think what's interesting about this episode, listeners, is it assuages many of my doubts.

I feel this way as well. I feel like sometimes the market making is a fun game, but then real people have to live with the results. Real CISOs have to spend money. Startup founders have to kill years of their lives working hard on building something, and it should not be taken lightly. So sometimes you may not need a separate market, but there's very real innovation. In this case, there's very real need for innovation.

You know what's so funny to me about this episode is while we were taping it, I realized my first 2 projects at Google were CDR and CIRA. I owned the cloud threat detection product. and something we never launched that we were working on for a while called Cloud Threat Investigation. And so this for me was a very full circle moment.

Huh.

And so maybe with that, listeners, let's turn things over to today's guests. Today we are joined by James Campbell, the CEO of Cato Security, and Chris Doman, the CTO of Cato Security. James, Chris, thank you both so much for joining us today. We're talking about CDR and CIRA? CIRA? The CIRA makes me think of Death Note, so maybe we don't want to go there.

CIRA, yeah.

What is this R in CIRA, and why isn't it just a part of CDR? What's the difference, and what's going on there?

So CIRA referring to Cloud Investigation and Response Automation, and obviously CDR on the cloud detection response side, which is kind of a follow-on for, I guess, for EDR, a bit more familiar with the audience probably. And CIRA is something, you know, I would say is relatively new. And I think if you have a look at kind of what we've focused on as an industry, you know, a lot of it has started with kind of a little bit of the posture management side and then very much the detection side. But we haven't focused a lot, or we haven't, I guess, matured a lot on the kind of the depth side of things. So that's kind of investigating what's happening post-detection.

Right.

So kind of right on the boom of a detection. And this is kind of where Sierra comes into play here. So it's kind of acknowledgement that, okay, that's cool, you've detected something, but what's next? And really this is kind of what Sierra, I think here is trying to address. And so that's kind of like automating that data capture and using the cloud to kind of do a lot of that automation side of things. And then it's about diving in deep, understanding exactly what's going on here, and then responding accordingly from there.

If my memory serves me right, Lawrence Pingree at Gartner made the acronym. And when I was talking to him about this, it came to me that I think that CDR with just a bigger, stronger R would have sufficed. And he violently argued against it. So, why not double down on CDR and say, we are a CDR with a really strong R? You know, with EDR, some people have stronger D than R. Back in the very, very, very early days of EDR, in the days of Mandy and MIR, some of the tools were really strong on response and did almost no detection, yet those gave birth to the EDR concept. So why not just be a CDR with hard R, with big R?

Yeah, I mean, some people kind of talk about SIEM as a subset of CDR. I think it's fair to say more people probably talk about CDR than they do about SIEM, given it's kind of a wider spectrum there. I mean, what James is saying about having that word and investigation, that really is key. If you're jumping straight from kind of proactive detection through response, kind of acknowledge that there's something in the middle. You need to make a decision. I mean, that might be an automated investigation. It might be the more kind of manual forensics type of thing. But it kind of makes that more explicit. But I'm not an analyst. If you want to say it's a subset of CDR, I'm not going to argue with you. You know something about EDR, I think. So, I mean, you've got some background there.

Yeah. And I think what's really important here, as well, is, it's not just about detecting and going and wiping an EC2, right? Like, that context is important. And I think one of the unique— we have the on-premise kind of world, kind of back in the day when we used to go and pull hard drives out of data centers, right? And go do imaging, kind of sleeping for 12 hours while your imaging was being done so you can do your forensic investigation. The one great thing about cloud is that it changes it. It changes the possibilities here of how we can investigate. And so once upon a time, we used to fly people to the different different country and grab the physical hard drive, right, to do our investigation. But now I can literally, you know, click a few buttons and hey presto, I've got the same depth of data right in front of me. And cloud really enables that. And I guess to your point, the big R, right? And, you know, the big R or, or Sierra in this case, cloud kind of bringing attention that cloud brings the benefits of being able to do that along with being able to automate that as well, which we traditionally couldn't have done with on-premise. It's really good kind of almost, you know, flag it as its own thing, I guess, from that perspective. So, because not a lot of people think about it.

So on that front, I guess what I'm struggling with is this kind of sounds like you've built a SOAR that knows how to call gcloud.

That's a very sad take too.

That's a very sad take. What's the delta there? What's the difference between those 2 things?

I'll go first, Chris, and then happy for you to kind of chime in on that one. But I guess, A good example would be, I love the fact that everybody's embracing cloud. That's great, right?

Me too.

But there's a lot of, it's a lot of new technologies. It's a lot of complexity. It's a lot to get your head around, right? And you know, your day job as a security analyst, right? When are you gonna find the time to learn about all the things and how you plumb things in and how you connect all the APIs and, you know, and it's forever changing as well, right? So, you know, I talked to one of the big kind of US insurers once upon a time. He's like, James, I've been doing security for 20 years, right? I know how to pull out a hard drive. I know how to look at log files. He's like, but, you know, how the hell do I automate grabbing data from this specific type of container technology running in this specific cloud? He's like, I just, I just don't know. I don't know how to do that. And so that's where we thought, actually, you know what, like cloud is ripe for the picking in the sense of you could bake a lot of that automation in out of the box.

Mm-hmm.

Let people focus on what they do best, right? And that's investigate security incidents. rather than trying to work out how the hell do I get there. And that's where I think cloud really brings that power to the industry. It's like, actually, you know what, you can actually kind of set this all up out of the box so things are automated and you give people a view that they are used to seeing, right? The things that they've been taught.

I think that— wait, wait, wait, this came up probably in the show we had with somebody from a CDR where he described himself, I think, as a translation layer between the SOC that's cloud ignorant and the cloud that's ultimately modern, new, and isn't aware of the classic DNR and SOC techniques. So, this is kind of stuck in my head as a vision that it's a bridge, a translation layer between the world of classic SOC and the world of modern cloud.

Yeah, it's definitely a great description.

This works for me too. I had a very memorable meeting with a team at a leading hedge fund where they sat down and said, hi, we're the cloud response team. We've got 20 years' experience investigating Windows on-prem issues. We know registry keys in our sleep. Could you explain what IAM stands for?

Oh, yeah.

That's telling.

Yeah.

So, despite this very useful discussion, I still want to ask my question, which I've been kind of meaning to ask, and I want to try it not in an annoying test-reformed energy manner.

Good luck.

Okay, fine. I'll try. So, can't my SIEM do that? And I think that if you say that your 1998 SIEM cannot do that because it cannot even know what's a resource ID, what about my modern SIEM? Can I just use my more modern SIEM, maybe built in the 2020s, late 2010s, that is cloud-aware, runs in the cloud, can collect the logs, can collect other data. Can't I do cloud investigation and response in my SIEM, or SIEM and SOAR, really?

Yeah. I mean, you can do a lot. And obviously, most SIEMs now have SOAR baked in, as well, and stuff like Google SecOps going further down the line with AI, as well, and doing some of that kind of automated investigation, as well. I guess there's a couple of things to Pick out one is it depends on what the investigation is. So if you're looking at the control plane management events, things we're dealing with logs, which hopefully have been turned on and being forwarded, et cetera, then a lot of that will be in the SIEM and typically have some pretty good investigations in there. We start getting to the compute layer. I mean, and the data layer, things get a little bit different. So you may be forwarding logs from those systems. The logs often, if for cost reasons or other reasons, aren't going to be super complete. And also a lot of things you need to look at in investigation to work out what actually happened. They're not going to be logs. So there might be the malware on the system, which again might get detected, becomes a log, but it's not the same as the actual malware file. It might be stolen credentials, a lot of commands that attackers execute on systems, even in functions. So not just like VMs and containers, they may not actually get logged. You need to look at some other more kind of forensic artifacts. So that's when things get more complicated. I actually don't entirely disagree though with What Tim said around a bit like teaching SAW G Cloud is just going down to that depth rather than breadth, that there's just a lot in there. So, it wouldn't be fair to expect, you know, every SAW to be able to do everything in massive depth. And there's that kind of trade-off between those things and where you choose to, I guess, invest a bit more time on.

I also totally see the argument about, like, yeah, sure, a SIEM could do this, but do you expect every SOC team on the planet to know that when you're doing a Kubernetes investigation, You actually want to grab the base image for the node. You want to grab the container images as they were deployed. You want to grab the pod config. There's a lot of depth that if you're not a Kubernetes person and you're not a that cloud's implementation of it person, you're gonna miss.

Exactly. Yeah.

And I think that if you miss something during IR, you will never fix it. Because some of the stuff, you have one shot, which I think is a new thought that just came to me, is that With some of these tasks, doing them half-assedly means they're not worth doing. They need to be done right.

There's a reason we used to fly people to grab hard drives rather than just letting the local person do it. Same thing in the cloud. There's actually a depth of expertise here. Who knew?

Yeah, exactly. And people spend millions investing in the posture and the detection side only to let themselves down after that. And I think it's really important to recognize that. Hey, there's still more to be done post-detection, right? It's really important, and you need to kind of close that loop so you're getting the most out of the investment that you've put into your security.

So one of the questions I love asking on the show, and I think I invented this question, so it's like Anton's got his 3 AM test, I've got this question. What gets better for an organization when they deploy a CIRA CIRA, or in particular, what gets better when they deploy your Yeah, I guess I can start with that.

I mean, one of the immediate values, which kind of surprised me because it wasn't the main idea at first, is just getting access to data. And I've been really surprised at how many large enterprises weren't entirely sure if they had a container compromise, how to get all that data, whether it be that they didn't actually have permissions set up, whether it be that they didn't know how to get both the logs and the compute and the node, et cetera, as well, all in one place. That's quite a basic thing, but it turns out it can be— there's a lot of process that you need to set up. And the next thing is, obviously, we process all that data too, so getting that into a valuable format that you can investigate automatically or manually. So the other value is kind of getting answers to those questions. So as you were saying a minute ago, actually properly, not half-assedly doing an investigation, so then you don't have another one pop up, particularly if that system's disappeared and then it keeps getting recompromised and all those. those kind of issues that can happen.

Which, by the way, reminds me, I think that one of the fun things that you mentioned during the prep to this podcast is, of course, that cloud is ephemeral. And sometimes this debate about having a one shot at investigating is also very like physical truth. You literally have just one shot. There's absolutely no way to do it. Oh yeah, sorry, I kind of didn't do it right.

Let me do it again.

So, ephemerality and security together, I feel like these are fun things that crash in very interesting ways. We had it mentioned on the show as part of the DAI model. Tim, do you remember what was it? Dynamic something ephemeral?

Distributed immutable ephemeral.

Yes. Sorry, I confused— I forgot 2 of the letters, but I did remember the ephemerality.

That's the most important one, in my opinion.

Okay. Yeah, I agree. Thank you for saving me from embarrassment. But how does it work? I mean, I'm not even talking about compliance. How does ephemerality and security merge and change each other?

I don't know. That's philosophical. Yeah, I guess, like, say there's quite a lot to unpick there, but kind of, you know, one of the great things about cloud, right, is your ability to use ephemeral infrastructure to kind of scale with your usage of your compute, right? And the kind of resources you need. And I think that's one of the great things. You can actually do a lot of cost savings there as well, right? Like by using ephemeral infrastructure, by using auto scaling groups and kind of growing and shrinking exactly what you need. And that's great. On the flip side of that, but however, if you have a detection in said ephemeral system, like a container running in Kubernetes, and you have that detection and your analyst goes to investigate what's happening here because it looks serious, but that container's gone. It's like, oh, cool. Okay. Now I'm in an even worse position because now I have a detection and I'm not able to investigate it because that data's disappeared. A lot of the customers we have actually have come to us with those problems. They're like, we're loving the cloud, but hey, one of my customers said, we've had a detection for 6 months in our Kubernetes environment. We haven't worked out what it is because every time we go and have a look at that data, it's gone. This is where the zero concept and the automation concept and getting cloud to almost solve this new or enable this new problem space, and that's through automation because once you have that detection, you have you've got literally moments to go and grab that data, pull it back, and then you can safely get rid of that container or whatever that might be. On the flip side, obviously, it does provide some level of security because, hey, I compromise a container, the container only has an average lifecycle of, say, 15 minutes for some of our customers. That compromise is relatively short-lived. But the issue is, unless you can investigate or you've grabbed that data at that moment in time, which is what you need the automation part for. You don't know if they've moved on to something else. You don't know if they've dumped out the database, you know, all those sorts of, you know, lovely security problems you need to solve. And so this is where kind of the irony is cloud solves its own problem through automation.

Mm-hmm.

So if you want to embrace cloud, you should be embracing ephemeral infrastructure. You should be embracing auto scaling groups. Like this is how cloud should be used. It's great technologies. Um, some really kind of innovative stuff there to help organizations kind of, be cutting edge using cloud. But yeah, from the flip side of that, this is where that automation piece comes in, is cloud enables you to automate that data capture and to grab that data at that moment the detection happens. And so you're not missing it. So your analyst can come back a day, 2, even a week later and have a look at that data and go, what actually happened there? And then kind of close that loop and make sure, you know, it's mitigated and fixed and resolved for another day, right?

But let me ask you a strange sub-question to this. I think I love this. And by the way, it also reminded me how different cloud is from many environments people know and where they train their AI skills. But many clouds, unfortunately, aren't cloudy. They're basically a bunch of sad VMs pushed up, right? So if my cloud is just like extreme lift and shift, do I need all that? Or can I still live in the 1990s IR and be okay-ish? Yeah.

I mean, a lot of it ends up looking kind of similar. So Linux forensics from on-prem environments can look a lot like kind of classic lift-and-shift forensics. And then sometimes even the cloud-level forensics can look a bit like classic log analysis. But again, still capturing the data is going to look pretty differently. You can't just hopefully break into the Google Cloud data center and rip out the disks. So things are still different. And then there's 80% is very different too, when it actually goes into a— it still connects to IAM, you still have different kinds of ways of doing encryption, there's a ton of different things there still. It's also why cloud sysadmins are often fantastic investigators, because they do have that knowledge.

Yeah, I do talk to customers when they're doing that lift and shift thing to say, look, it is different. You are going— it's not like on-premise, right? You've got the control plane level, as an example, that's like the equivalent of allowing someone to walk into your data center, right, and just go pull stuff out, or pull plugs, et cetera, out, and kind of go from there. And so, you know, they might think, oh, okay, I've lift and shifted this server from the data center. And they might think the risk around that server doesn't include physical security, right? Like they've kind of not thought about that, someone actually having access to that. But what happens if someone got access to your control plane and then kind of go from there? And so there are some extra elements which we try and tell customers to kind of think about when they're doing lift and shift and just kind of taking into account that You know, there are multiple layers to cloud security, not just the kind of server or itself and the applications running on it. There's a lot more to it.

So wait a second. That means even if my cloud is literally racks, well, virtual racks of VMs, I may still get bitten by the cloud bug.

Absolutely.

And not be in a data center. That's an interesting thought, which perhaps we should probably print a poster with it because we do see a fair number of people who say, Yeah, yeah, all this stuff you talk about cloud-native, we're not cloud-native. We are in the cloud, but we replicated our data center in the cloud. So, we are kind of on-prem in our minds, but they're not really on-prem. They are in the cloud. Tim is looking at a sad, cringy face. I think he's right.

I am very sad about these people, but I was thinking about something else. I was thinking about this moment of compromise and the collecting of forensic evidence about it. And it occurred to me why this automated response in the cloud is so important. If you have a truly cattle cloud, like a properly ephemeral distributed immutable cloud, the moment a piece of that gets compromised and you have to operate that by hand, that's like a fundamental phase shift back to a pets model rather than a cattle model. And if you're able to automate the gathering of evidence and the nuking and the rebuilding, you can maintain a cattle world. And so there's like an interesting not just security breakdown, but operational breakdown that you're at risk of if you're not able to automate the backside of the compromise moment. I actually, I've been sitting here thinking about this for a moment. I actually think this is, it makes me appreciate why CIRA is important. So, maybe to help make this concrete for people, could you share a couple of interesting examples of where cloud investigations, aside from the Kubernetes one I made up earlier, are potentially harder, or more difficult or have a degree of complexity that would be surprising to a novice? Like, where does this get really hard or special?

Or where are the differences? Maybe focus on where the differences are harsher from on-prem. Where what you knew from on-prem just goes out of the window.

Or what you know from on-prem will mislead you.

Oh, yes, that's right.

Or lead you astray from the herd.

I guess astray from the herd. I like that.

This is nice, right?

For one thing, I mean, Google's great at this, but in some clouds, the logs aren't turned on by default, and they often are on-prem, and that's bitten a few people. One really cool kind of, well, it was bad if it hit you, I guess. One really interesting attack from last year was someone was going around pretending to be cloud vendors, emailing them, asking them to deploy some infrastructure as code, which then give them access.

Yeah, that's crazy.

And they would then do, of course, the still boring crypto mining, but compare that to an on-prem kind of situation, and you couldn't like, write a letter to the data center, and then they'll then go and start up a machine for you. So that's quite different as well. But there are lots of different things there too. Decrypting data in the cloud, that can work quite differently to on-prem. You can't re-encrypt to get access without diving into the encryption details. So you can have some nice opportunities there too in cloud. I mean, also just the defaults in cloud are often better, so it's kind of harder to bite you sometimes too.

Yeah, it's, I mean, kind of one of the examples, one of the interesting examples we actually, actually saw were from a particular hacker group that we monitor was breaking out of systems in the cloud. So if you can think of, it's really weird to compare with on-premise. If you could imagine someone that was, you know, hacked your computer in a data center and then literally jumped out of the computer and was in your data center, like that's a bit of a weird concept to picture. But if you think of in the cloud, right, we saw, I know exactly, right?

It's very Snow Crash.

Yeah, exactly. But if you—

I'm getting like, Scared.

Exactly.

But that's a great analogy. That's actually what happens if you get a service account key off of an instance.

Yeah, exactly. So we've seen compromises happen of a cloud resource, whether it be a container or a virtual machine, and actually take advantage of mismanagement around IAM. They go and create a root account, and then they log into the console, and therefore have control plane access, which is essentially like someone literally jumping out of a physical computer. And appearing in the data center, which is pretty crazy. And that's, you know, we've seen people taking advantage of that. And then at that point, as a hacker, you don't need to run at the runtime. Like, you can have all the endpoint agents you want, you can do anything like that, but then no one is going to see you because they can just go and grab data at the control plane level. So it's quite interesting to see that kind of shift. And it's a little bit of a weird concept when you think about it from a physical perspective.

I like that because, you know why I also like that a lot? Because it takes me away from this sad vision that our Mendiant colleagues have painted for us, namely that whatever you do in the cloud, what kills you is AD. Whatever you do in the cloud, wherever you are, whatever you plan, what kills you is Active Directory. Nothing else matters. And this to me made me such a horrible ghost of the '90s coming up and just bites you in the cloud. I'm sorry. And now I feel better a little bit.

I'd take Cloud IAM over on-prem Active Directory any day.

So Anton, you have a good next question. I want you to ask it.

I do, actually. I think that this is maybe my reformed analyst mind talking, but lately Gartner has been trying to create longer, bigger, fatter acronyms. And of course, they made CNAPP. So do you think the investigation and response components like CIRA would become part of the broader bundle like CNAPP? But the other part of the question is, How does this connect to posture assessment? Because CSPM is a default baseline cloud security purchase for many organizations. They probably would own CSPM if they buy you, but how do you work together? And would you be part of the bigger whole later, in your opinion?

Yeah, I mean, CSPM is typically the start of the cloud security journey, and most people are beyond that now. And the definitions I've seen of CNAPP seem to keep getting wider and wider. So now it's basically all cloud security on some of the definitions there. If you're looking at, I guess, cloud workload protection, if you're looking at cloud detection and response, I mean, those obviously have elements of doing investigations in there. Everything in the cloud should have elements of automation in there as well. So yeah, you can stick it in CNAPP, I guess, but still you kind of talk about it separately as well.

I think it's also about reminding people there is, you know, when it comes to cloud, you know, that layered defense-in-depth approach is still required, right? You've got products that, you know, help you from a posture management perspective, products that help you at the runtime level, and products that help you in that kind of, response kind of element, the investigation response side. So, you know, just to remind everybody that there is a layered approach, not kind of like a one silver bullet, so to say, similar to the depth defense in depth approach from an on-premise perspective too.

Ah, so it's— yeah, I think you're— well, I mean, I didn't expect like a kind of hard yes or no because it's about the future, but it sounds like there's merit in CIRA being separate from the posture plus hygiene plus traditional practices bundle, right? Is that— so it's kind of like a weak vote for no. Yeah, yeah.

So I think— I still think it has merit in being its own thing, but certainly to Chris's point, like, the definitions are almost broadening every day to include all sorts. And I guess one of the things which you could certainly take from CERA and put into kind of more of the earlier stage, such as posture management, is like, am I set up to respond? Am I set up to grab the data when I have a detection? Like, is that already— like, am I in a position to do that? Because doing it post-incident is just— you can't do that, right? The data is going to be gone, especially in the ephemeral nature. So, so perhaps maybe as part of, you know, that kind of early phase of this ESPM's world, and even CNAPP a little bit, is You know, do I actually have a solution that's plugged in and I can do all my checks and make sure I have the right permissions and the right access to grab the data once something is detected? When something has gone bad, can I do XYZ?

That permissions piece is huge, and it's one of the reasons I encourage users to practice this response piece so much. Yeah, we're getting close to the end, and before I ask our traditional closing questions, you know, listeners, one of the reasons that Anton and I started this podcast in the first place is for a sense of editorial independence. And we've been very lucky to have that respected in our time at Google. But unfortunately, yesterday I was speaking to my skip level, and he required that I ask James and Chris, who was your best and most effective board member?

Oh, that's cheeky.

No, so shout out to Chris, who was An advisor for these guys, a full board member. I called him an advisor yesterday, he got very upset with me. He said, no, no, I'm a full board member.

Yeah, no, he's, he's been excellent for us and, you know, a wealth of knowledge in the cloud space, it goes without saying.

So that's not a direct answer though.

Yeah, I'm not sure anybody's ever called him that before.

Shout out to Mr. Cord there.

Yeah, yeah, a wealth of knowledge, Chris. That might be the first time anybody said that about him. So I, I do have to ask the traditional closing questions. One, do you have a recommended tip to help people like prepare maybe for their cloud incident response investigation? And then 2, recommended readings so that we don't leave listeners empty-handed.

I guess on the tip side, and, you know, one tip could be don't take tips from Australians, but on a more serious note, it's all about being prepared, right? You know, Chris and I have got a long career in cyber incident response and digital forensics, and those who are prepared and ready to respond are the ones that just come out the best every time, right? And the same goes for cloud. So, you know, if you have a detection and let's say you've got the Wild West of clouds, like thousands of root accounts and thousands of resources spinning up and down all over the place, it can be quite complicated. And when you have a detection, do you know you're ready to go and grab that data at a moment's notice and have a look at what's going on within minutes? Chances are you're probably not. So it does pay to be ready. It does pay to have that automation in place. It does pay to spend a bit of time on that and make sure you're ready because the last thing you want to do is have a detection and then the CISO goes to you, hey, like what happened with that detection? You're like, ah, it was ephemeral, it's gone, so I can't tell you anything. And you know, next thing you know, you're in quite a tricky position. So get ahead of that, get that automation in there. Cloud is absolutely ripe to allow us to do that. So take advantage of it.

I guess on the reading, don't take reading tips from an Aussie either. I love reading incident response reports from the cloud. It's great to kind of see lessons learned, and there's a couple. So there was the Cloud Compromises talk by Mandiant at CloudNext last year. That was good, went through quite a lot of detail. And also there's a researcher called Rami McCarthy. He compiles a massive list of lessons learned from incidents. So both those are really worth checking out.

I like both of those answers a lot. Chris, I like your answer because I think we had those Mandiant guys on the show. And James, I like your answer because growing up, my mother worked in incident response for AT&T and she had a mousepad.

Oh, really?

That said, wow, preparing for the inevitable.

Yeah, exactly. Yeah.

Now, but her incident response was like a central office has been blown up or fallen over. We're going to deploy a fleet of trucks to restore service, not we're going to capture some software.

No, exactly.

Different kind of IR.

Yeah, exactly. But to be honest, like, I used to work in Australian government doing incident response for national government. And I remember one of the best laughs I ever got in a cybersecurity conference was, you know, for those that know me, I'm sorry. And for those that don't know me, I'll see you soon. So, you know, it is the win. And, you know, time and time again, we've done, you know, hundreds and hundreds of investigations over our careers, but the organizations that have done the best are the ones that were prepared and ready and tried and tested. And I know we sound like a broken record when everybody in the industry says that, but It's true. It is absolutely true.

Well, James, Chris, thank you so much for joining us today.

Yeah, guys, thanks for having us. I really appreciate it.

Thank you.

Thanks, everybody, for listening.

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.

Thank you, Ronnie.