EP222 From Post-IR Lessons to Proactive Security: Deconstructing Mandiant M-Trends

Security warning.

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 Risk Analytics and all things 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 our Cloud Security Podcast listeners, all on the Google Cloud Security Community page. Anton, we are talking about mTrends today, and not to dwell on things for too long, but what are some of the highlights?

Admittedly, the report itself is hugely fun, but this episode is about some of the coolest, funnest things, and of course, some of the challenges about how the report is made. I feel like maybe this intro is even unnecessary because the report and the episode speak for themselves.

Well, listeners, this is an episode and a report that need no introduction. So without any further introduction, let's turn things over to today's guests. Today, we are joined by Scott Runnels from Mandiant Incident Response, and 2 guest episodes today, listeners. We've got Kirstie Fahey from the Google Threat Intelligence Group. I want to just start off with, everybody loves the MTrends report, we know that, but creating it, bringing it to life, what is the hardest part about turning all of these distinct IR reports into something fun and useful like MTrends? How do you actually go from, we've done a giant pile of incident response engagements, to, we've got a trends report the world can benefit from? How does that happen?

There's a lot of challenges to that. Primarily, consultants are simply just trained to write in a very specific manner. Consultants will write hundreds of reports in their career. We teach them to focus on descriptive forms as opposed to prescriptive forms or normative forms. So they only, only really ever talk about what is or what was as opposed to like what ought to be. But on the other side of the spectrum, you can't get 3 management consultants into a room without it turning into a therapy session and just telling all the cool war stories that they've like engaged in over the last couple years.

Hmm.

But because interns has that more formal narrative, style, those types of storytelling just don't really fit. So, a lot of times, authors have to write a draft, and then it has to be revised quite heavily. So, I mean, you get really good at writing in descriptive forms, and you get really good at telling, like, a really cool story, but those simply just won't fit into Imtrends. In the former case, narratives are incomplete without that prescriptive statement that tells us why something is important. And in the latter case, you simply just can't swear in Imtrends.

You are allowed like one or two swears on the podcast, by the way, but we try to keep our not mature rating on Apple Podcasts. So fair warning.

Fair warning.

So yes, this is exactly right. Yeah, I think you can swear on YouTube, I've heard, but not on Apple Podcasts. So weirdly enough, I was afraid— I had this moment, brief moment of fear that you'd say, oh, it's the bureaucracy, oh, it's this. But ultimately, It makes sense that the distillation process is the hard part, is the consultants who do the work, do some write-ups, and then beautiful prose at the end. There's a bit of a big journey in the middle. That makes sense to me.

Yeah. So one thing that I would say as well, coupled with like many incident responders are really good report writers, maybe not great narrative writers, is that we also have to have the data to back whatever they're saying, right? And one of the biggest components of that is working with the intel teams to get that before they go through the whole drafting process. So Scott is really good about making sure that we're connecting the dots to, from the consultant's brain, something that happened during a war story conversation into, hey, is this actually factual? Do we have evidence to support it? Is it going to source some other big cool story that we can put into MTrends.

Yeah. And I think that makes sense. And I think that that's why I'm just constantly impressed. I've recommended the report pretty much to everybody and anybody for many, many years. But sometimes when I do this, I get a really weird criticism. Like I would say, hey, MTrends report says that most incidents involved things like X or Y or Z, and you should really fix those things because if you don't have them, you won't be in a report, meaning, like, you won't have an incident. And while it's a reasonable argument to an extent, other people say that using the report as kind of a sole guidance to what to do in security is wrong because obviously everybody in mTrans is an incident victim or incident subject to an incident. So presumably, other people would counter sometimes that the right things to do is to talk to people who never had a call with Mandiant because they've not been hacked.

Yeah.

And this is an interesting debate, which I think would be a bit of a theme today. Do we learn how to build houses that are fireproof from observing fires or from physics? So the question— my rant is over.

Oh, good. I was wondering where the question was, listeners.

So how much of the lessons people extract from N trends skewed by the fact that they're all post-IR stories?

I think the narratives themselves, at least in their original drafts, they're very heavily skewed. The authors are writing from experience, and frankly, recency bias hits them much like everyone else really, really hard. Everyone has to learn to step away from the content itself and just inspect the context to ensure the reader really isn't being left behind. We have a page limit that we give the authors, and it is really, really difficult to fit all the juicy, sexy details of incident response or a threat actor behavior into that page limit. while including all of the context to make sure that we're not really just kind of slicing away part of the audience. The lessons themselves, I think they really do depend on the reader. The audience for mTrends is really, really broad. A CISO might be looking at mTrends, and they're looking at the broader narrative because what they're trying to do is they're trying to justify funding for their department. Whereas a frontline defender, they might be looking really for the more discrete information, like, very, very specific technical details that are going to help them identify similar activity or defend, like build detections for that kind of activity. I think there's a lot of value in it being post-IR, but we do have to work pretty hard to make sure that we're bringing in a lot of context that surrounds it.

But wouldn't the advice be, if you do every recommendation that you recommend, will you be secure? Like, that's like, be secure, of course, is an insane position. So Would it be a good use of everybody's time to just do what the post-incident lessons say?

I think if you do every recommendation that we would put into MTrends, I don't know that that would be a thing that we could promise because there are still very customized environments. Taking all of our cloud recommendations when you have an entirely on-prem, like, ICS type of environment, that's not really going to be a big, you know, return on your investment. The things that probably boil down to things like, basic security hygiene, those are very valuable and do have repeated return on the investment.

But it seems like Anton's kind of setting up a false dichotomy here. It's not as if we would ever say to a CISO, read the MTrends report of IR lessons, and that's how you learn to be secure. We would say, this is one of many things you read in order to be secure. I think Anton's premise might be provocative needlessly.

No, not kind of yes, but also no. And what I mean by this is that if you have more generic recommendations like do firewalls right, patch faster, or something more fundamental like limit do-list privilege, and contrasting to this, you may have very crisp, very beautifully written by you, Mindy and crew, a report that says, this is what led to an incident.

Yeah.

you'd be very tempted to just do the latter, not the former. Like, even to me, deep in— again, 3 AM test. If you wake me up at 3 AM and say, which lessons are more useful, general security good advice or something you learned from the field? I'd say, well, learn from the field, obviously.

Yeah. Well, so let me interject here.

Yeah, please.

So, my background is very interesting. I started out in, like, the policy world doing, like, PCI assessments, which was— God bless those individuals because they are patient saints. It was not for me. And then I moved into incident response, and then I jumped into intel.

Mm-hmm.

And the very interesting component about this is over my, like, gosh, now nearly a decade of time in the industry doing this stuff, is no matter how many recommendations you give a customer or an organization, right, they're going to enforce that. They're going to do the best that they can, but attackers are just going to keep doing what they do. And what they do is break into things. A lot of times they're— they have unlimited budget when we're looking at like those espionage-related actors. And then financial crimes really has such an opportunistic lens that they are going to go so far and so wide that they're going to keep finding people on the internet I guess, to compromise, right? And they're gonna find new and interesting ways to break in. You're never going to be able to completely defend against that. You're never gonna be able to give a boilerplate, like, security recommendation. However, more often than not, whenever, you know, Scott and the incident response team respond to any of those incident responses that we talk about in mTrends, a lot of times, there is at least one or two of those boilerplate, like, Hey, we've said this for like ten years. Why was it not in place? And they're like, oh well, we thought that was, or oh, we missed one, or oh yeah, that makes sense. We should do that. And I don't think that the post IR you know bias is really that big, only because we also have a red team that does you know engagements with. Folks that have, as the red team likes to tell me, a far superior security response team than what the IR team sees. And I'm like, but do they? How are you breaking into these organizations? And they're like, well, we have to use compromised passwords. And I was like, oh, got it, got it. So you're acting like an actual attacker to break in. You're finding passwords on the internet and then you're breaking in that way. You're social engineering. them. Awesome. Like, you're doing the same exact thing as the attackers. So it's not, it's really just like, from an attacker perspective, they're trying to give as little effort into what they're doing to break into these places. So it really does boil down to whatever is like, almost Occam's razor, right? Like, basically, like, the bad thing is probably the reason why they came in.

This does make sense to me. And I think that it also logically values those lessons higher than some other lessons. But it doesn't make An exclusive source of truth. I think that makes sense.

So, I want to pick at another bias that I think might be present in the report, which is size bias. And the report is predicated on companies having called you and had the resources to call Mandiant in the first place. And so, is there a rotation in the report towards issues that the largest companies on Earth face? And are those the same as the issues faced by smaller companies on Earth? In other words, If I want to learn how to fly Cessnas, should I really read about accidents that happen to 747s?

I think the answer is yes. You should look at both small and large scale because the problems can consistently overlap. The threat profile could be wildly different between, like, a Fortune 100 and, say, someone in the Fortune 500, or even someone like a mom-and-pop type of store. For a long time, you know, small organizations really thought, like, we don't do anything interesting, we don't have any interesting data. But Ransomware and ransomware as a service blew that premise wide open simply just because it scales so well.

Hmm.

So learning from larger ones, especially, you know, Christy was just talking about our lovable danger nerds who like to use compromised passwords. We've got a whole article this year about info stealers where passwords are simply being harvested and sold. It really does not matter how large you are if someone's, say, personal system has— it gets infected with info stealer, and maybe they're syncing passwords between corporate and personal because you have a BYOD policy. Those types of things definitely affect large organizations but can also affect smaller organizations that maybe have— they're maybe more reliant on things like BYOD.

I think that the original idea behind this question was that we wanted to explore the kind of sense of hopelessness a little bit. And not to go into existential dread too quickly, but the idea was that if somebody with a security team of 500 and a budget in tens of millions suffers an incident based on the fact that they use, I don't know, Active Directory or something, like the smaller companies would have like no chance. That's our fear. But I think also the large companies have larger complexity. So in that sense, there are certain perhaps vulnerabilities and issues that are more common in large companies. I don't know. Am I pushing it too far?

That's an interesting thought process, I think. And, you know, Scott probably has more familiarity with this currently because I've been out of the game for a couple of years. But a lot of times when we are responding to engagements, many consultants do become kind of a therapist. And you see whether it's like a small organization or a large organization or like one of those Fortune 50s or whatever, everyone's kind of having a bad day. So like comparing the traumas may not be the best way to like talk about this, but Mm-hmm. One thing for, like, folks that are reading mTrends and, like, saying, hey, like, we would never be able to call Mandiant. We don't even have the ability to hire our own internal security team. We have to outsource everything, right? When you're looking at mTrends from that perspective, you're thinking, hey, what am I going to do if my external security partner that's managing all of my security tools tells me that they've been hacked? Because at that point, that's a third-party compromise, right? You have to understand the scope. You have to understand, you know, how is my data impacted? But then also, you have to understand, how are you able to detect things in my environment if you weren't able to detect things in your own environment, right? And so, those conversations get very interesting very quickly, but all of it goes back to the interpersonal relationships that you have with your points of contact there, especially like the SLAs that are involved with getting logs, getting the investigation underway. Because most of the time, especially like if you are familiar with the report, we talk about notification sources, external notification versus internal notification. This is a very interesting thing and people get very heated about it. But for Mandiant, we classify an external security team that you have paid to do all of your security as an external notification source. Because more often than not, your external security team is not able to go in and completely contain the environment. So—

Mm-hmm.

There is a notification time, like, tree that has to go out. And most of the time, that's going to be longer than an in-house organization, right? An in-house organization is going to be able to hit the, like, break the glass, push the button and contain everything. A third party is not going to be able to do that. So organizations that are smaller and may not have the funding that these other bigger companies have, like Fortune 500s, really have to take that into consideration when they're reading MTrends, right? Because if you're going to measure yourself against, you know, what we're seeing for, let's say, dwell time, and you're like, hey, we don't even have the ability— like, our SLA for response time from our third-party security organization is 2 weeks. Well, dwell time is, I think this year's 11 days. I don't have the report in front of me. I should probably know this, but there's too many metrics in that. I know that's my fault, but that is now pushing the standard, the quote unquote baseline that Mandiant is seeing, right? Does that matter for you from a risk tolerance perspective? Who knows? So, I think it's kind of a different way to think about it, I guess, as opposed to the existential dread that Anton is trying to give us.

Yeah, yeah, yeah. You know, maybe trying to give us a bit too strong, but, uh, yeah.

Anton would never give us existential dread. He wouldn't do that.

Share my own as opposed to like give you this. There's a subtle difference between sharing existential dread and giving you one. But okay, so let's— you mentioned dwell time, and dwell time is of course causes, as you pointed out, a lot of people to be kind of anxious and measure things and do sometimes act on it. So Let's kind of explore dwell time. And I'm going to go on a very short rant. It's like basically 5 questions together. So what is the magic behind how are we doing dwell time calculations? Because of course, some people say dwell time is before you kick the attacker out. So it's sort of the same to response time, but it's really not. I mean, I read the report, so I know it's not. So that's one question is like, how does it— affect, like, where does it end? I mean, the other side question to this is, of course, some people treat it as some kind of unalloyed good, like if it goes down, it's good. But then ransomware agent calls you up and says, hey, you have ransomware. So your dwell time may be shortened because the attacker notified you, and it isn't, clearly isn't a win. So just demystify the whole dwell time for us. Yeah.

Yeah, this is— my friends will always make fun of me at security conferences because people are like, oh, I hate dwell time. It's awful. It's an awful metric. And most of the conferences that I go to are an intel conference. And I'm like, well, that metric's not for you. Dwell time is really a marker of, you know, what Mandiant saw for that year. So dwell time has also been kind of co-opted by other organizations. So let me define it real quick for those of you at home that haven't been able to read the, like, 100-page report that we put out. Dwell time is the time period between the initial infection that the attacker got onto the system to the point where that attacker has been identified. So—

Oh, identified, but identified as a fact of an attack, not, like, by name and home address. Identified, you need to be careful, right?

Correct. That something is wrong. That is the notification point, right? So that could be, you know, hey, FBI just emailed our security, like our help desk or something to say like, hey, you have FIN7 activity in your environment, it's beaconing out. Or it could be, hey, there was a security alert that said someone clicked a phishing link and it tried to go out, right? Those are 2 vastly different notification types, but they still are capturing the dwell time of—

Mm-hmm.

the incident, right? Now, the nuance here is that for dwell time to actually mean something, and from like our perspective anyway, the way that I view it, I've written this report for, gosh, I think it's 4 years now. I think this—

Mm-hmm.

Maybe it's my 5th year. I don't remember. Time is a construct, right? Dwell time is really measuring how fast Mandiant and co are able to detect things in an environment within that calendar year, right? Specifically for 2024 calendar year.

Mm-hmm.

We've changed our scope timeframe a little bit, which is why it gets a little hairy when we talk about it. But when we say that dwell time is going down, what we really mean is that defenders are catching malicious activity within their environment faster than they have previously. So this becomes more important when we look at things like dwell time distribution. We have a nice heat graph that shows It's starting to get darker at the 0 to 7 days timeframe, right? Which that means that more investigations are being identified then. Because we measure median dwell time, we are looking at the dataset that is a non-normalized dataset. So we're using median over average. That's a very important distinction.

Mm-hmm.

So we're looking at, like, the midpoint of the dataset. You're always going to have those outliers. I think in 2020's report, maybe 2021's report, we broke out the ransomware dwell time versus non-ransomware dwell time.

Ah, very thoughtful.

To showcase this is a huge, huge impact to the data. It skews the data so much. And last year, we introduced something called an attacker notification for detection by source. So this year, we break it out a little bit more. To show a true external notification from, like, an external entity or an external partner. And then, we have our internal notification, which, of course, is staying the same. And then, we have the attacker notification. An attacker notification can happen in a ransomware investigation as well as a non-ransomware investigation. However, it is going to be more prominent in the ransomware investigation because that notification is coming from a completed ransomware encryption. Which is also kind of something that confuses people because people are like, well, I identified that the attacker was in there. It was me, an internal party of the, you know, organization. They didn't call me out. It's like, well, the mission has been completed though. Like the, their objectives are done. They have encrypted you.

Mm-hmm.

So unfortunately that's, you know, something that we have to consider as well. So going back to, you know, dwell time is going down. Is this a good thing or a bad thing? It's not really any, it's just a fact, right? Like, this is just how the numbers crumble, right? Nick Carr, a former Mandiant person, famously said, like, stats are funny. You, if you squeeze them hard enough, they'll say whatever you want.

Yeah.

And math is kind of implicitly just math and it just like doesn't say anything. It's whatever we put onto it. So like numbers going down, most of the time people are thinking that's good. when we're talking about dwell time specifically, other times not so much. But I think boiling it back to, hey, this is what Mandiant's seeing. This is a baseline for, like, where our measurement baseline internally should be. If we can beat that, fabulous, but keep going. And if you're not there yet, get there as soon as possible because ransomware is not slowing down and exploits are not going anywhere either. So being able to detect things faster is going to set you up in the long run. And that's the good part.

I think that makes sense. And I think that it provides a great nuanced take on this, right? Like, it's not about something— it's not something you push down, or it's not something you want to necessarily go down to zero. But actually, maybe this is a little philosophical, but still interesting. It's definitely just intellectual curiosity, it may not reduce the risk. Do you think there's an optimal dwell time? Because I feel like Naive take is you want zero, which you want attacker to be like instantaneously detected. But it's like a bit of an absurd concept and likely would A, be impossible, and B, be so expensive that nobody ever would do it. So, yeah. And of course, if you hit me with it depends, as you probably would, depends on what then? Like, what is the— how to think about the optimal dwell time for my company?

So, gosh, that is That is a question that you should ask not an intel nerd because intel nerds like myself are— we have a very interesting relationship with these types of scenarios because for me to understand what's happening, I need attacker data. So realistically, one day, hopefully, we'll get to a point where all of that data is coming from a honeypot and it's not actually like coming from attacker compromised infrastructure. for like a hospital, like it has been. But I need all of that information. So, I need the dwell time to be shorter, but I need the containment time to be longer almost.

Hmm.

I need to see what the attacker's doing. Now, if I go into a boardroom and say that, like, I'll get laughed out of there and be like, they're gonna fire me. Obviously, I don't want an attacker to be in an environment for a long time doing bad things. But unfortunately, the nature of security organizations is just that's what we have to. So, it's kind of like, Cancer research, right? Like we wouldn't know anything about cancer if we didn't have people that had cancer, right? And we're getting better every single day, right? And it's that's a bad you know kind of analogy because security at the end of the day until probably 2020 there was limited actual impact to organizations. But then we started seeing attackers. compromise hospitals. And we finally saw, like, a very big bubble pop of, like, we can now target, or we can now tie, like, human cost of life to an incident, which is absolutely insane to even think about. Because, you know, no one wants to think about that. So, in that case, optimal time is you want as soon as possible, right?

Yeah.

From a business owner, you want it to be zero, but that's never going to happen.

Correct.

And honestly, like, from my perspective, it's a silly thing to think about because dwell time is just detecting it, right? It's not containment. It's not, you know, eradication even. Dwell time is just detecting it. So if you can get a full, like, phishing email investigation done in 11 days, you are probably further than most organizations, right? Because a lot of times, people are not even able to fully scope their environment in 11 days, let alone detect what's happening on Joe in finance's laptop, right, in 11 days. Because unfortunately, with the way that organizations work nowadays with all the remote capabilities and bring your own device, it's really hard to get that visibility. So, in a perfect world, what's the dwell time? Like a second, right? But realistically, it's as soon as possible.

Yes, I think that's a great, it depends. I love that. I think that clearly you wouldn't say, oh, the optimal is 13.5 minutes or something. Like, it wouldn't be. There is no flat number for everybody. But I think that it is kind of back to the risk. Well, it depends on the risk, right? And the environment and the type of system. That part makes sense to me.

Dwell time also has the ability to inform. And again, we use median dwell time. So, Basically the center point of an ordered list. On the individual side, it does a better job of informing like, okay, if I'm seeing dwell time go down and I feel like I have a relatively mature organization, and let's say last 5 years it's been at 15 days for non-ransomware actors, do I have 15 days of logs that I can go hunt through? Like, there's a lot of different stages that this can be applied of the detection or the stopping of a thing versus the supporting the larger investigation though. what would occur once that is identified. If you've only got like a day of logs and the farthest back we're ever gonna be able to tell you is, you know, what we can interrogate out of just bare forensics. But if your environment is very bare of that type of information for analysts to kind of swim in, that's detrimental to being able to answer the larger questions. How that incident started is very, very important, but what happened after it is always the more important question of where did it go? What were the impacts? What's our risk? exposure to this type of thing? How are our customers going to respond? And what kind of information can we provide to them? That dwell time can help inform those kind of secondary categories of a security system.

So, I want to move us along from dwell time because ironically, we've dwelt on it for quite some time here. And I want to ask a question, which is, we seem to have a tendency to make the same mistakes again and again. And I'm not sure you could pick up an MTrends and look at the lessons in it and know what year you were in, because so often we have the same lessons. So why, as an industry, do we repeat the mistakes we make so much? What's up with that?

I think it's always going to feel cyclical. Technology just moves way too fast. Threat actors are motivated by a very disparate set of objectives, like, without Putting on my junior deputy intel hat, because really my lane is just incident response, the political landscape moves just as fast as the technological landscape, and nations are capable of responding through technological means now. Much as we're seeing with— we got 2 articles in this year's MTrends that are specific to regional or nation responses. So we have one on North Korea and one on Iran. There really is no set of necessary conditions that would define sufficient security. So that cyclical feeling is always going to be there. But in truth, it's not just like we're, you know, in Groundhog's Day of security. There's always going to be some degree of difference, whether it's a very, very nuanced difference or very, you know, simplistic difference. Like, you know, we've all moved from on-prem to the cloud. Now that changes things. We have to kind of relearn all of our lessons. The part of this just comes down to really like the fundamentals tend to work. Then that's both— that's true both on the security side and on the attacker side.

Yeah, this is, I think the cyclical nature is something that I haven't really pondered that much, or my mind goes to, we make a bunch of endpoint mistakes, then we more or less fix endpoint and start making network security mistakes. Then we make endpoint mistakes again, and then we make application security mistakes all the time. So, cyclical nature is unfortunately a sad reality, but you didn't want existential angst, so I'll shut up. The closing question. We typically end with a question, give us one resource and give us one tip. Resource here would obviously be mTrends, so we can skip this part. But the tip, I wanted to maybe turn it into, what is the one useful piece to learn from mTrends that would improve your security, would implement that if you implement it? Like, give us one tip each, Scott and Kevristy.

I tend to jump to the mapping of, like, intel's association of data to the MITRE ATT&CK framework. I think MITRE gives everyone a very good, like, common nomenclature If I was leading a security operations center or just like a CISO, I would be looking at that list because they do order it by like which attackers are using it the most commonly. And I would start asking my team, which of these are things that we can detect? And now show me that we can detect whether that includes bringing in pen testers or doing something like a custom threat hunt, ensuring that visibility is there, that visibility remains and is easily queryable. for us to be able to not only mandate, but for internal security to be able to find something, I think that would help drive my further investments in both technology and in people.

Yeah. And another resource sits at the very back of the book, but we map all of the seen Mandiant-related tactics to the MITRE ATT&CK framework and then put them in our fancy attacker lifecycle. So that's at the very end of the book. It's just like 20 pages. It's quite long. But from my perspective, you know, that intel-informed IR side, I always tell people that they have to have a plan and practice it. Whether that's, you know, you have an IR plan, cool, you wrote it, you got the checkmark for the compliance, right? But now, you have to go one step further and say, okay, MTrends has laid out all of these different scenarios. How are we going to respond to them? So for example, like, what do you do if you're notified that a business-critical network appliance has a new critical vulnerability and is actively being attacked by nation-state actors and financially motivated actors. What do you do? How do you survive without this appliance? Can you take it offline because there's no patch yet? Like, what do you do in that situation? That directly relates to the initial infection vector section in By the Numbers. Then you have like, okay, how is your security team going to handle external notifications from a third party? Like, a security researcher or law enforcement that there has been a compromise within your environment? That's something that we talk about a lot with customers at Mandiant, and that's— we address that in the notification by source section in By the Numbers. And then, you know, last but certainly not least for my example set here is, how do you handle passwords within your environment? Is everyone a domain admin, right? Or are you actually following the principle of least privilege? Because apparently that's an old name nowadays. I don't understand that, but it's an oldie but a goodie, apparently. But also, if they are— if a user is a domain admin, do they have a second set of credentials for that domain admin account, right? And then also, are you doing anything to look for those info stealers within your environment? Also, how are you making sure that that individual is not reusing passwords on their personal laptop or their personal phone that might be more susceptible to phishing or info stealer malware because it doesn't have the same level of security as their work computer. So those are things that you could do today to get a little bit ahead of the game, to ask your security professionals within your environment Well, this has been a wide-ranging, deep, and wonderful discussion, and I can't thank you two enough for joining us today.

This is great.

Yeah.

Thank you for inviting us.

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, Please subscribe so that you don't miss episodes. You can follow us on Twitter, twitter.com/cloudsecpodcast. Your hosts are also on Twitter, @Anton_Chuvakin 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.

Bye.