EP254 Escaping 1990s Vulnerability Management: From Unauthenticated Scans to AI-Driven Mitigation

(upbeat music) - Hi there, welcome to the Cloud Security Podcast by Google, thanks for joining us today. Your host here is ever myself, Tim Peacock, the senior PM for, well, a bunch of stuff in Google Psychops, and of course, the one and only, Anton Zhuvakin, a now long-reformed analyst, and actually also for a long time, senior staff in Google Cloud's Office of the CISO. You can find and subscribe to this podcast for ever you get your podcasts as well as on our website. Cloud.withgoogle.com/cloudsecurity/podcast. If you enjoy our content and want it delivered to you piping hot every Monday, please do hit that subscribe button. You can follow the show, argue with us, and the rest of our Cloud Security Podcast listeners on the Google Cloud Security Community page. Anton, we are talking about vulnerability management today, and we open with the guests saying, I don't think this is the most exciting topic for many people. I feel like it's an absolutely fascinating episode. It had a lot of high-opening moments. So if anybody has any kind of second-ouset because of the PM you shouldn't listen, no, you absolutely should. And moreover, some of the things people in our industry in cybersecurity kind of keep saying, rapid change of progress, you need to learn if you're out for a year, you're useless, but VM is actually the case where some of the topics we discussed, there should absolutely be current today, are older than two of the people present in the discussion, which is a huge shock. Because it's not like we definitely veered into the 1990s practices, and I think at least one question we veered into almost like the early '90s, where the question that it was kind of very hot in the very early days of vulnerability management remains to be hot, it remains to be tricky, remains to be troublesome today. So the time lag is measured in fractions of a century. - Oh, that's depressing. - Quarter of a century. And yes, the episode does get quite depressing, but it also very real, and people who show up and say, container, CICD pipelines, rapid stuff, rapid this, developers, DevOps, and then they're like, oh yeah, we try to patch things in 90 days and it's tricky, so we're gonna just go back to 180. It's like, what, no! But it is real, sorry, I'm rambling because it was kind of exciting for horrible reasons. - You are certainly rambling, but I won't hold it against you. It is, listen, there's this is a fun episode to me because it's the culmination of two kinds of episodes that we really love. One kind of episode we really love is actually VM episodes. Those in the stats do surprisingly well, given that neither Anton nor I is a VM expert, or really, frankly, all that, like thinking that VM is that exciting, but then too, it's also a mandient episode which also do well in the stats, neither Anton nor I work at the end, but we obviously respect our mandient colleagues tremendously and soak to have them on the show always. So maybe without any further ado, let's bring together VM mandient, things that predate my existence on this earth and let's turn things over to today's guest. Today, we're joined by Caleb Hoke, consulting manager for transformation services in the mandient cyber defense team. That is a mouthful of a title, but I love that it's about transformation and not migration. So that's kicking us off on the heels of a wonderful episode earlier this year, talking all about transformation, not migration. And so I wanna talk about VM. We've done a couple of vulnerability management episodes on the show already, but I'm delighted to have somebody from mandient come and talk about it. And so maybe let's start off with the history of this. How have you seen this evolve from the sort of basic scanning and reporting and what does modern look like? Maybe give us the bad and the good to start out with. - Sure, so the bad is that there are still a lot of organizations out there that are scanning and reporting only, right? So there is unfortunately a significant amount of organizations that still do what you would think of back in 2005 even 20 years later. So that's kind of the bad. The good is that there are also a lot of other organizations that are transforming into a little bit more proactive, right? We're looking at a tax surface reduction. How do we get in front of some of these looking at vendor management, configuration management and how these are configured. So it's kind of getting ahead of some of that. A lot of that is starting to stick and a lot of organizations are starting to see the benefits of doing that. I'm having solid standards and looking at, hey, if you look at a lot of the zero days that have been exploited, right? A lot of those could have been avoided purely by having outdated old protocols and such disabled and moved to something newer and more secure, so. - So you mentioned 2005 and I, in my running joke about this when I see some of the practices and when I saw it in my garden days was that these are people who seem to be stuck in the '90s, but then I've heard the comments that you guys have seen organizations that are better in the '90s than some organizations are today. So like if you pick any other area of security, if you pick even if you pick detection response or abstract to an extent and a few others, like things have changed in the last five years, 10 years, but vulnerability management does have a lot of things that are almost exactly the same from 2025 and maybe 30 years ago. You write about that scan and report, like this whole picture about a security team spraying with a scanner, then cooking up a 10,000 page PDF and sending it to ops admittedly, it sounded really sad and finding in 2010 when I started doing some of this work. And I mean, it was kind of a joke that, hey, ha ha, scan and throw the 10,000 page report. And then 15 years have passed and the joke is as funny and as sad as it was back then. My mind is blown from that. Like what is special about this domain? Why is this that stuck? - Honestly, in my opinion, it's the least cool, right? And that's actually the opposite 'cause I'm actually, what's considered the firewall is cool? - What? - I mean, but you look at the other areas in security, right? I mean, what are the big terms, right? Detection and response, you mentioned that before, right? There is a lot more emphasis put on those areas. You know, whether right or wrong, that's more of a, I guess you'd call like a theoretical, theological debate, right? But that is, I think that is a reason is it's just not quite fun enough for a lot of organizations and fun might not be the right word, but I think that kind of says it, like there's other things that are more high priority, like, oh, I can go detect this and you know, you have things like a SIM and EDR and what's the latest and greatest, you know, insert your, you know, endpoint control here that you can do, those are great. But sometimes they're not always the compensating to those and also there's also some, I think some fear uncertainty, doubt or fud, right? Around what compensating controls you can do. And so they think, oh, we have EDR, like, why do we need to patch? We have EDR, well, that's not necessarily the case. So I think there's a lot of misconception around that area specifically. So that's at least my opinion is that there's other, there's new emerging technologies, well, cool, right? They're really, you know, hot topic. I think that VM for whatever reason never got, you know, updated with it, right? So I'm going to stick my nose briefly before Tim's next question. You brought up another pet peeve of mine. So we feel like it looks like we are kind of on the same mental wavelength or something. And that was the compensating controls, which of course is a PCI DSS term. Generically, I tend to use to in many of these days, say mitigations instead of like remediation, instead of fixing, you put some other security control that stops the risk. This was really contentious and very confusion rich. And you're, again, alluding that it is still very contentious and still very confusion rich. And sometimes both ways, sometimes people say, I have strong mitigations, I don't need to patch. And sometimes people just confuse that mitigations are possible. And they say, no, no, no, you have to patch within three days. And it's like, no, no, no, we have five layers of firewalls and whatever, blah, blah, blah controls. No, but there's no risk. So why is mitigations thinking so difficult? Why can't this be, hey, you don't patch? We need to mitigate here the choices. Well, okay, let's pick number three, done. - I think it could come down to one word, validation, right? If you're not able to validate those compensating controls, which is frankly, it's a very hard thing to do, right? Like coming through and saying, hey, I'm going to fully validate this outside of to your point of, hey, I can tell you for sure, I have an endpoint firewall that says, port 445 is blocked outbound, right? Whatever, you know, instant port, unless you have that where you can say, yep, I proved this. But even then, you have to look at like the whole breadth, right? As time has grown, organizations, IT infrastructure has grown, right? So now it's, you know, there are a few organizations that can say they are 100% certain that every single endpoint has their gold standard configuration. It just doesn't happen, right? Like it's different. - No, never. - There's always those ones that come through. So I think that's kind of where it comes in. At least in my, that's always my issue when it comes to compensating controls and mitigation. If you can get the validation piece, correct? I think mitigations and compensating controls, you know, for the PCI term in 100% is a valid way to do business. However, there's very few that can also have the time and resources to actually do that, right? And to do it correctly. - So one of the things that we wanted to talk about was the difference between unauthenticated and authenticated scanning. Could you tell our listeners about that and maybe talk about some of the struggles that organizations see with getting to an auth world? - I'm gonna stick my nose briefly again. - That's his birthday, Tim's birthday. This question probably is older than Tim. This is like, let's just have like a short two seconds pause about it, like I bet that this question is older than Tim. - Listeners, y'all are gonna think that I'm like some 18 year old punk that joined the podcast with Tim. - No, no, I'm a seven adult. I own a home, I'm a real person. - Yeah, but this question is probably the early 90s question. I don't think it's quite the 80s, but I think that the, do I run this script on my Solaris server or do I scan? Probably is like 1992 or three kind of question. Is not the late 90s. - If it helps, I would have been one or two years old at that point. But it almost predates me as well. So I think I'm right there with you. I just got the beer growing so that helps make the look a little older right now. So. - He certainly does compared to your momo picture. I looked up our guest on our internal website listeners ahead of us. And the guy who shows up to our call looks like he could be maybe at the older brother, the uncle of the guy who actually, you know, pictured on the internal page. So, so Caleb, what's the deal with this? Why are people still struggling to do this the quote-unquote right way? - I honestly, I think a lot of it comes down to, we're gonna come back to this term again. I don't use this term liberally, but the fud, right? I think there is still the fear and certainty doubt that if you let them log in, there is this unknown thing that's gonna happen on X server. And they say, hey, this is critical, like say, if we put it on an edge device, it's gonna take down our devices and shut down the network, right? While that's not never happened, it is very infrequent, right? That doesn't happen often, especially then when you wanna get down into the amount of time it takes to kind of validate, like, okay, this is what the scanners are gonna go in there and do. The scanning tools as well, I haven't found any that actually do a really great job at laying that out. Hey, I'm gonna log in to this F5 load balancer, and I'm going to run specifically these commands. It's usually there somewhere in documentation. I just don't haven't found it to be super easy, at least my personal experience finding that information to provide to the asset owners, right? So I think that is probably the biggest reason, and then I think there's also the other one of, I can say there's been a few organizations that we've come in to do some assessments, and they were under the thought that they were running authenticated scans, and they were not, you know, they were like, hey, our scanner was, you know, it's set up for authenticated. We just never get anything, we're so good, we don't get anything, and then you go and look, and it's literally only bringing back like port information. Yeah, it's bringing back basically nothing. Like, yeah, that's happened twice in my personal experience, in my time with Manian, so. I'm just having my phone moment here in this. Like, yeah, I believe you, but it's so, so, no. I know, but I think if we tie this back to the first question, vulnerability management is a historically undersourced area, not only just in an organization, but even within the security team, right? You typically say, hey, there's, you know, a part-time, maybe analyst who, you know, a lot of times, it's not even a very technical person to be able to go and tell that, right? It could be a governance person running this. That's not uncommon as well, where, you know, if you're not able to kind of have that technical acumen to go in there and look through the logs and say, oh, this is actually not happening, or, you know, knowing the right places to look, so there's a bit of resource management issues that I think play into that as well. So, this makes sense, this makes me kind of depressed, and also kind of more depressed. I wanted to say something biffy and funny, but like, no, I'm sorry. This is just going into the deep dark, black hole center of the. - Especially when you look at the emphasis on N and zero-day exploitation and what that leads to, you know, as the initial infection vector, you know, Manny and Google Cloud, we posted a few blogs that have shown that, you know, there's a couple of years running now where that tops the cake for what's the initial infection vector, right? So, I think that is, it is kind of crazy to me that even after these big events, right, let's look back at early 2024, it was helping some clients with all the Avanti zero days that came out, right? There are still conversations happening after all of that that there's still resource issues, and those were all highlighted during that, you know, quote, call it, you know, crisis for some organizations. It was very hard to manage, and frankly, when you come back and look at it, there's still not didn't add any resources, right? They didn't add, you know, or increase their capabilities, right, they still have, you know, ex-scanner, they didn't add something, a layer on top that helps automate something, right, that's, it's, yep. - By the way, for people in the back row who are very excited, we should tell them this explicitly, otherwise they would go crazy. The AI agents would not fix this one. - Yes. - No. - Yeah. (laughs) - I'm sorry, I'm sorry, but no, that is not the problem that AI agents would fix. So, only one serious note. This was all very much part of my daily existence in my analyst days, and I felt like a lot of people observed the lack of resources, observed the friction with IT, and they tried to say that, okay, we're gonna fix VM differently. We're just gonna prioritize better, and we're gonna look at all this 10,000 pages of VM, and we'll run some kind of a magic prioritization algorithm, and it would give us what real risk is. And this idea probably originated back in the early 2010s when this became kind of a big deal. Some companies were started, you know, a gutter analyst did a lot of dork on, like what's the best prioritization? And again, 15 years passed. The exploitability, yes, attack surface, yes, is all pretty well known. But in your experience, what is the best gold standard? So to say, prioritization, algorithm, or prioritization method today? I mean, obviously, it's not just CVSS, but if you go meet a client who does it well, how do they prioritize? - So, I'll say that we have our own methodology. I have not been faced with an organization yet that has says that they have it down-path. You know, there are some that do better than others, and I think when we look at what really like the gold standard would be, right, it's a mix of your business priorities, valid commercial threat intelligence, or even some open source intelligence, I would say asset exposure, and then even sometimes you have to take in compliance scope. Right, so for example, is this, we'll go back to PCI, I had a whole PCI hat for three years, before I came to Mandiant and Google Cloud. - Oh, man, I'm sorry. - So I am well familiar with a large e-commerce platform. If you look up my LinkedIn, you'll be able to tell what it was. But yes, I dealt with that. That was my every day for three years, as part of being the security manager there. But essentially, it takes all those, right? So, and I want to take the threat intelligence even one step further, right? So, you have what we would call a cyber threat profile. And that really in cyber defense, that's kind of our gold book, right? That's what helps drive prioritization for everything. Not only vulnerability management, but also what detections are we writing, what are we threat hunting for, et cetera. But when you take the threat profile, you say, because of these industry verticals and these regions, right? These are the threat actors that are most likely to target my organization. And then when you take that and look at what vulnerabilities they're known to exploit, you pair that with the asset exposure, right? For example, if it meets my threat profile, plus it's being widely exploited, plus it comes up on an asset that actually does, is externally facing. You can reach it from the internet, right? That becomes a critical. And that's like, hey, you need to drop what you're doing right now and go and pass this and figure out a plan, right? There are actually very few scenarios where I think that like the critical, I always say, I reserve critical for the top five, really, if not less. - Like, that would be really critical. - Yeah, but when I say critical, you know, that's part of it is, it's kind of writing the shift on what does critical mean. And when we say, hey, critical means, you know, more than likely, there's not many exceptions allowed, right, no risk exceptions. This is an all hands-on deck. You need to start reporting this up. Like, hey, we have this out here. You know, this thing is exposed. We need to get this patched fix or we need to, you know, frankly stop the services, right? We, and CyberDefense, have been on a few of our clients where we said, hey, this being exposed is more critical. Like your business has more of a chance of getting taken down or, you know, impacting from a breach than it does just, just leaving it up, right? You really should shut the service down. That's a common recommendation that we get. But also, it's-- - How often do they follow it though? 'Cause you might recommend it all the time, but how often do you get listened to? - No, in maintenance consulting, we actually have a term that we have to be very careful with what we say to our clients, 'cause a lot of times they'll listen to us, right? So it is, you know, and it's happened. My personal experience, and I've been with Manit just under five years, we've done that twice and they've listened both times. - Really? - Yeah, and so which is good. But again, it's, I think I've only said, where I recommended it twice as well. So it's not a light taking that says, hey, like this is, you know, there's basically no mitigations. We can say for sure that this could be exploited. We looked at the configuration, right? We do all that analysis and it comes up, but it's absolutely something we would recommend, especially look at some of these secure file zero days that have come out. Those are ones that, I mean, with the amount of data that's in there and what they could access, it absolutely have to be considerations for taking down until it could be resolved. - So a lot of this is useful. And I mean, a lot of this is very useful. Okay, I'll stress this. - Very useful. That's high praise from Anton Calvo, you know that. - It is very useful, yes. And yet, most of it in some shape of form existed even 10 years ago, except for possibly one dimension. I feel like, at least when I was given advice on this, we tended to prioritize TI less, because we were afraid that if you just say, look, threat and tail vendors report that these five bounds have been exploited actively, just takes these fives. We feel like we're gonna miss the number six, which no TI vendor picked on yet, but you need to start the work now. So maybe is there a risk of over pivoting on TI based threat and tail based prioritization? Is there any way to overdo the current burning dumpster type bounds only? - Sorry, yeah, no, that's, I mean, that's a great point. And yes, there is a way, because if you look at some of them, right, I'm trying to think of an example right now, but say something was reported yesterday, and it was came through a security researcher, right? It has not had any signs of exploitation, but it's an unauthenticated type of exploit. That's still, even without the threat intelligence, without it being exploitable. If you look at that, plus the fact of, you know, it's an exposed and externally accessible asset, that needs to be passed in same deal. It can't be left out there, 'cause as soon as that discloses, and I know there's some trends out there for how quickly from disclosure, until when you actually see the exploitation, that timeline is very short. So you all have to look at like the consequence and the way that the exploits are written, right? If it's just a vulnerability, and there's been no exploit code, you can probably give it some time, but then if it comes and says, "Yep, this is out there, it's unauthenticated." I mean, exploit code is minutes behind, especially when you look at, you know, you said to come on one of the buzzwords, AI, right? That stuff is coming out faster than ever, right? And it's to your point, just because it hasn't been X-Water, nobody's reported it's been X-Water yet. It's a ticking time by matter of time, especially for those that are externally exposed. - So I want to shift gears away from AI, 'cause we talk about that. - Wait, we haven't really gone to AI. - No, yeah, no AI, don't know the AI. Friday, we're recording this kind of Friday listeners, I've had enough AI this week. I want to talk about human factors and org factors. And so, you're a consultant, you show up, you say, "Hey, this is what we think." How do you overcome or how do you work around the human and org challenges in VM? - Yeah, honestly, I always, I like to say I know great areas, no lines of communications. We want to minimize any chance for lines of communication to get misconstrued or someone to miss it, right? And so, a lot of times what we do is we'll take, so, for example, well, we have a volume management policy that says that the server must be patched within three days if it's critical. Okay, have you run through that with your team that's actually patching, right? Have you gone through what we would call a TTX or a tactical technical exercise? Where you say, "Hey, here's a scenario." For example, a zero day was found on this checkpoint VPN that's externally exposed, right? Okay, IT, VPN management team, what's your process? What are you gonna do? How are you gonna go through your cycles? That doesn't occur, right? So, a lot of times we take it and we say, "Hey, these are, you need to run through these scenarios with your team." And the other part is just taking things and making them in a consumable format, right? So, if you give me a 10-page policy document that says, "I need to patch my servers within three days," and there's all these other, you know, items in there, that's not, nobody's gonna read that just frankly, from a human perspective, whereas if you go through and you take that policy and you put it into one slide, this is what it's expected of you to do. So, a lot of times we pair that, we call them playbooks, right? So, for these teams, we'll take that policy and you turn it, transform it into a playbook and that makes it a lot more consumable. I mean, I've seen that successful both before Mandient and, you know, at Mandient, when we've done, like, kind of a consulting engagement, so. - So, is it the kind of table tops for VM, which is kind of interesting, because people do talk about this a little bit, but table tops for IR take massive amount of mind share. Whether people do them on order in your life and all that, we had an episode on that, but table tops for VM is kind of a obvious idea that nobody does, which is kind of, I think this pays for the price of this episode, to be honest. We had a lot of fun and we'll have more in a few minutes, but like this to me, this bit is hugely valuable. And I feel like people who say, "Well, we'll scan, we'll rank, IT would patch," is not that process misses. Well, if this happened with the checkpoint, let's just not say checkpoint, let's say, Yvanti VPN, okay, no, sorry, it's the kind of an inside joke. So, Yvanti VPN appliance is vulnerable, and then the IT says, well, some guy in IT says, "Yeah, we'll patch it," and the other guy says, "No, this appliance cannot be turned off because of this reason." And it's like, "Whoa, wait a second, what about?" And it's like suddenly it unravels, and people realize that their plan to patch it within whatever number of days is not gonna fly. Yeah, absolutely, I agree, yeah, it's not something, you know, the idea is typically new when we bring it up and saying, "Hey, you really should run through this." You know, and really, I would reserve it honestly for those, you know, really critical services. These things, like, well, without this, the business can't operate. Okay, well, we really should run through what if this happens? How do we go through and patch this? What's our testing procedures, right? What does the business and the, like, you know, the IT asset owner, what do y'all need to do to feel comfortable with flipping the switch within a day, right? And a lot of times there are still obvious concerns around, well, what if the vendor provides a bad patch? That's never happened before, right? Not ever. It happened very rarely, given the number of patches though. Absolutely. That's provide billions of patches by now, probably, right? Absolutely, yeah, it's not common, but a lot of folks have been burned by it, right? So there's still that, you have to get through that. Okay, well, that's fine, but that's why we test, and then that's also why we have a rollback, right? And we never would recommend not having a rollback because if you have a rollback, then you need to get to the conversation of, do we take this down or not, right? Obviously, you want to patch, and the patching would be the minimum amount of downtime, but if you need to take it down and only have it up for four hours a day or something, right? Like those are conversations where you kind of step through those, but if you don't, if you wait for a crisis, then you're asking for pain and it's going to confuse everyone. No one thinks, you know, expertly, clearly, during a crisis like that, where you're getting business, and you're getting pressure from five different angles, right? You want to go through that and kind of have that muscle memory to say, we know what to do. We've done this before because we practice what we're going to do for these services, right? And most of the time I would imagine is probably less than, you know, depending on the size of your organization, three, four, five services that they really would need to go through that that truly could take down, you know, the organization. So it's not, you're saying not to do it for everything, but be specific, right? What do you want to test it for? What is that critical and what potentially could be the issues with the business continuing to operate, right? So, yep, yep. Yeah, it reminds me of a filled, minimal viable business argument, right? Where if you really take everything down, everything's blown up, exploited by zero days, what you must keep running and still have a business. And I think that to me is probably used to be a show up in this discussion. So this is the obligatory AI question. And I feel like the logic for using the AI in this domain is there, like prioritization comes up, like possibly an LLM can judge the context available better, but like, is there any reality? Like, we can dream up good AI use cases, but like, is there any reality behind it? Do people actually use Gen AI or AI, other types of AI for vulnerability management for improving the image in general? I mean, I haven't seen AI specifically used yet. I have some ideas, right? But actually, I think the opposite, right? Like, I think it actually makes the VM job harder, right? 'Cause we talked, but it briefly talked to this. The time for exploit to be developed is going to increase exponentially, you know? If you're throwing this into AI instead of days to do it, it's minutes or hours, right? To get a viable, you know, POC exploit, you know? And this is obviously some of the, you know, what we call the bad guys are evil out there, right? They're doing this as their full time, right? This isn't some part time, I'm going to do this for fun. This is what they do, right? And they're not going to wait for anybody else, so they're just going to keep on going. And it makes all the prioritization questions and the reaction, all the things we just talked about makes it all much more important because it's coming faster than ever, right? Yep. That's a perfect, nice little depressant touch towards them. I feel like. Big size. Big size. Yeah, big size. And now figured Calib would now reveal the deal. Well, I'd have AI would just like magically make it better. And agents would just scatter and fix things. And he's like, you don't know if there's bones in the AI, right? Yeah, it's happening. People are not using the AI only for good, right? No, that's the reality. Sorry. And here I just thought it was nano-banana. From you side to side. Yes, yeah. So I hate to do it because this has been eye-opening and wide-ranging and fun. All the things you look for in an episode, but I have to ask our traditional closing questions. One, do you have any advice to help organizations get better at VM? And two, do you have a recommended resource? It could be reading. It could be technical reading, non-technical reading, it could be anything. Yeah, so my one tip is to figure out automation wherever you can, especially with VM, right? How are you automatically prioritizing? How are you automatically closing out scan reports? How are you automatically validating that asset was truly patched, right? Automation, there's too many manual steps. There's too many times where it takes an analyst to go into the tool and download a report and then attach that to an email, right? It really, I would say, get as much automation as you can. Fit VM into the work practices that are already established. Don't create net new ones for VM and try to make this as seamless and easy as possible for the ones that need to go click the buttons to patch. And for my one resource, I would probably say, there are a number that of Mandient and Google HOD blogs that the Google Threat Intelligence team has put together around the speed of end day and zero day expectation. Those are great, great resources to read, as well as just to kind of give a good look at the landscape. I mean, if you go back that and as well as the Mtrends report, all of those statistics in there are very valuable, especially if you're out there trying to build a business case to put more emphasis into vulnerability management. That is typically how we help build business case that hey, we need to go buy X tool to help us with automation or to help integrate Threat Intelligence. That is absolutely the first place that we start is a lot of those statistics are saying time to exploit has dropped by 30 plus days in the last year, right, those are valid reasons to put some more emphasis here. Time to pledge did not change, or maybe changed by a couple of days. And I think it's mostly down, but not by a lot. So it's very a very clear mismatch. If we see very crisp convincing data that exploitation is faster, then we also have very clear data patching is not faster. Correct, yeah, it's basically going the opposite directions, right, if anything patching because the groups and everything is, you know, the number of asses is growing, patching is still not done correctly. So it's taking even longer because the ass more asses are missed. So gosh, I thought it was going to end on a lightly depressing note. Now it's ending on a deeply depressing note. Caleb, I'm obligated to say thank you for joining us today, but you know, thanks for depressing us today as more like it. That's what that's our main job in cyber security and such, isn't it, right? Kind of come depressing. Think it might be, yeah. But honestly, thank you for being a great guest. This really worked out super well. And I haven't been lost at the loss of words in a show for maybe 70, 80 episodes. And today it happened again. So this is super impressive. And it's a kind of a high bar to cross. So I really love it. Great. Well, I'm happy to be here. And so, yeah, thank you all for having me. And now we are at time. Thank you very much for listening. And of course, for subscribing. Please subscribe so you can get new episodes piping hot. And if you love our content, please drop us a review on your platform of choice. You can find this podcast on YouTube, Apple podcast, Spotify, or wherever you get your podcasts. Also, you can find us on our website, cloud.withgoogle.com/cloudsecurity/podcast. You can argue with us on the Google Cloud Security Community site, googlecloudcommunity.com. You can follow us on xx.com/cloudsecpodcast. Treat us, email us, argue with us. And if we like or hate what we hear, we can invite you to the next episode. See you on the next episode of the Cloud Security Podcast by Google. [MUSIC] Thank you, everybody.