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

Security running.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your host here, as ever, myself, Tim Peacock, the senior PM for, well, a bunch of stuff in Google SecOps. And of course, the one and only Anton Chuvakin, 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 wherever you get your podcasts, as well as at our website, cloud.withgoogle.com/cloudsecurity/podcast. If you enjoy our content and want it delivered to you piping hot every Monday, please do hit that subscribe button. You can follow the show, argue with us and the rest of our Cloud Security Podcast listeners on the Google Cloud Security Community page. Anton, we are talking about vulnerability management today. And we open with a guest 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 eye-opening moments. So if anybody has any kind of second doubts that because it's EM, 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 that are absolutely current today are older than 2 of the people present in the discussion, which is a huge shock because it's not like we've definitely veered into the 1990s practices. And I think at least one question we veered into almost like the early '90s.

Yes.

Where the question that it was, kind of really 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.

A quarter of a century. And yes, the episode does get quite depressing, but it's also very real. And people who show up and say, containers, CI/CD 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— listeners, this is a fun episode to me because it's the culmination of 2 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 2, it's also a Mandiant episode, which also do well in the stats. Neither Anton nor I work at Mandiant, but we obviously respect our Mandiant colleagues tremendously and stoked to have them on the show always. So maybe without any further ado, let's bring together VM, Mandiant, Things that predate my existence on this earth. And let's turn things over to today's guest. Today we are joined by Caleb Hoke, Consulting Manager for Transformation Services in the Mandiant 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 want to talk about VM. We've done a couple of vulnerability management episodes on the show already, but I'm delighted to have somebody from Mandiant come and talk about it. And so maybe let's start off with, you know, the kind of 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, 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, you know, 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 attack surface reduction. How do we get in front of some of these? Looking at, you know, vendor, you know, management, configuration management and how these are configured. So kind of getting ahead of some of that.

Mm-hmm.

A lot of that is starting to stick and a lot of organizations are starting to see the benefits of doing that, of 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, and you mentioned 2005, and my running joke about this when I see some of the practices and when I saw it in my Gartner 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 were 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 and response or AppSec to an extent and a few others, like, things have changed in the last 5 years, 10 years, but vulnerability management does have a lot of things that are almost exactly the same from 20, 25, and maybe 30 years ago. You're right 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 funny in 2010 when I started doing some of this work. And I mean, it was kind of a joke that, hey, haha, 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 because I'm actually—

What, configuring 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 it 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 SIEM and EDR and what's the latest and greatest, you know, insert your 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 new emerging technologies. While 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.

Please, please.

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, I used to in my analyst days, say mitigations instead of remediation, instead of fixing, you put some other security control that stops the risk. This was really contentious and very confusion-rich. And you are 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 3 days. And it's like, no, no, no, we have 5 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 have a patch, you need to mitigate, here are the choices. Okay, let's pick number 3. 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, inside 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—

No, it never happens.

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 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, it 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.

Again?

Does this question predate Tim's birthdate? This question probably is older than Tim. This is like, let's just have like a short 2-second 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 a podcast with Anton.

No, no, it's true.

I promise I'm an adult. I own a home. I'm a real person.

Yeah, this, 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 '93 kind of question. It is not the late '90s.

If it helps, I would've been 1 or 2 years old at that point, so it almost predates me as well. So I think I'm right there with you, Tim. I just got the beard going, so that helps make me look a little older right now.

It certainly does compared to your Momo picture. I looked up our guest on our internal website, listeners, ahead of this, and the guy who shows up to our call looks like he could be maybe the older brother, the uncle, or the guy who actually pictured on the internal page. So, Caleb, what's the deal with this? Why are people still struggling to do this the quote unquote right way?

Honestly, I think a lot of it comes down to— we're going to come back to this term again. You don't use this term liberally, but the FUD, right? I think there is still the fear, uncertainty, doubt that if you let them log in, there is this unknown thing that's going to happen on X server. And they say, hey, this is critical, like say if we put it on an edge device, it's going to take down our edge 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 want to get down into the amount of time it takes to kind of validate like, okay, this is what the scanner is going to 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 going to log into 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, you know, 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. Oh, no. You know, they're 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 It's literally only bringing back like port information. Yeah, it's bringing back basically nothing. Like, yeah, that is— that's happened twice in my personal experience in my time with Mandiant.

So I'm just having my facepalm moment hearing this. Like, yeah, I believe you, but it's just so, so—

Yeah, I know it's— but I think if we tie this back to the first question, vulnerability management is a historically undersourced area, not only just in any organization, but even within the security team, right? You typically say, hey, there's, you know, part-time maybe analysts who, you know, a lot of times not even a very technical person to be able to go in and tell that, right? It could be a governance person running this. That's, 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, 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 pithy and funny, but like, no, I'm sorry. This is just going to send me in a deep, dark black hole center of the—

Especially when you look at the emphasis on end and zero-day exploitation and what that leads to, you know, as the initial infection vector. You know, Mandy and Google Cloud, we posted a few blogs that have shown that, you know, there's a couple years running now where that 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. I 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, they're still not— didn't add any resources, right? They didn't add Or increase their capabilities, right? They still have X-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. I'm sorry. I'm sorry. But no, that is not the problem that agents will fix. Yeah. So, on a more 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 those 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. Gartner and others did a lot of work on what's the best prioritization. And again, 15 years passed. Exploitability, yes. Attack surface, yes. It's 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 said that they have it down pat. There are some that do better than others. And I think when we look at what really 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 3 years before I came to Mandiant and Google Cloud.

Oh man, I'm sorry.

So I'm, I'm well familiar with a, I'll say 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, you know, 3 years as part of being the security manager there. But essentially it takes all those, right? So, and, and I wanna take the threat intelligence even one step further, right? So you have a, what we would call a cyber threat profile, and that really in cyber defense, that's like 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 that threat profile and you say, Mm-hmm. 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 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 patch this and figure out a plan, right? There are actually very few scenarios where I think that the critical, I always say, I reserve critical for the top 5, really, if not less.

Like, it better be really critical.

Yeah.

And that—

and but when I say critical, you know, that's, that's part of it is, is kind of riding the ship 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, fixed, or we need to, you know, frankly stop the services. Right. We, we in cyber defense have been on a few of our clients where we said, hey, this being exposed is more critical. Like your business is, you know, 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 this service down. That's a common recommendation that we get. But also it's—

How often do they follow it though? Because you might recommend it all the time, but how often do you get listened to?

No, in Mandiant Consulting, we actually have a term that we have to be very careful with what we say to our clients because 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 Mandiant just under 5 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, 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 has to be considerations for taking down until it can 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, Cal.

I want you to know that. It is very useful, yes. And yet most of it in some shape or 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 intel vendors report that these 5 vulns are being exploited actively, just fix these 5s, we feel like we're going to miss the number 6, 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 intel-based prioritization? Is there any way to overdo the current burning dumpster-type vulns?

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 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 patched in the same deal. It can't be left out there because as soon as that discloses, and I know that there are some trends out there for how quickly from disclosure until when you actually see an exploitation, that timeline is very short. So you often have to look at 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 said 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 exploited or nobody's reported it's been exploited yet, it's a ticking time bomb, matter of time, especially for those that are externally exposed.

So I want to shift gears away from AI because we talked about that enough.

Wait, AI? We haven't really gotten to AI.

No AI. No AI. Done with AI. Friday. We're recording this on a Friday. Listeners have had enough AI this week. I want to talk about human factors and org factors. And so, you know, you're a consultant, you show up, you say, hey, this is my— 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 no gray 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, you know, for example, like, well, we have a A vulnerability management policy that says that, you know, the server must be patched within 3 days if it's critical. Okay, have you run through that with your team that's actually patching, right? Have you gone through what, you know, we would call a TTX or a tactical technical exercise where you say, hey, here's a scenario. For example, zero-day was found on this Check Point VPN that's externally exposed, right? Okay, IT, you know, VPN management team. What's your process? What are you going to do? How are you going to 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 3 days, and there's all these other, you know, items in there, that's not— nobody's going to 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's expected of you to do. So a lot of times we pair that and we call them playbooks, right? So for these teams, we'll take that policy and you transform it into a playbook, and that makes it a lot more consumable. I mean, I've seen that as successful both before Mandiant and, you know, at Mandiant when we've done, like, kind of the consulting engagements.

So is it the kind of tabletops for VM, which is kind of interesting because people do talk about this a little bit, but tabletops for IR take massive amount of mindshare. People do them on Ordinary Life and all that. We had an episode on that. But tabletops for VM, is kind of an 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 a Check Point— let's just not say Check Point. Let's say Ivanti VPN appliance. Okay. No, sorry. It's kind of an inside joke. So the Ivanti 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 going to fly. Yep.

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 because you think 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.

Vendors 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 kind of 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? 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?

Right.

Obviously you wanna patch and, and the patching would be the minimum amount of downtime, but if you need to take it down and only have it up for 4 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 gonna 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 5 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. And most of the time, I would imagine it's probably less than, depending on the size of the organization, 3, 4, or 5 services that they really would need to go through that truly could take down the organization. So it's not, you're saying not to do it for everything, but be specific. 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.

Yeah, it reminds me of a failed 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 to have a business. And I think that to me probably needs to show up in this discussion. So this is the obligatory AI question. And I feel like the logic for using AI in this domain is there. Like prioritization comes up, like possibly an LLM can judge the context available. But is there any reality? We can dream up good AI use cases, but is there any reality behind it? Do people actually use GenAI or other types of AI for vulnerability management, for improving VM in general?

I mean, I haven't seen AI specifically used yet. I have some ideas, right? But I actually think the opposite, right? I think it actually makes the VM job harder, right? Because we briefly talked about this. the time for exploits 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, uh, you know, what we call the bad guys or evil out there, right?

Mm-hmm.

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. It makes the All the prioritization questions and the reaction, all the things we just talked about, it makes it all much more important because it's, it's coming faster than ever, right? Yep.

That's a perfectly nice little depressing touch towards the end.

I feel like— Yeah, big sigh.

Big sigh.

Big excited eyes. And now figured Caleb would now reveal the deep truth about how AI would just like magically make it better and agents would just scatter and fix things. And he's like, You do know there's vulns in the AI, right?

Yeah.

No! It's happening. People are not using AI only for good, right? Like, that's, that's the reality. Sorry.

And here I just thought it was nano banana.

Ah, well. Modify the slide. Yes.

Yeah. So I, 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, you know, get better at VM? And 2, do you have a recommended resource? You know, it could be, could be reading, it could be technical reading, non-technical reading, 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 a 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 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 of Mandiant and Google Cloud blogs that the Google Threat Intelligence team has put together around the speed of end-day and zero-day exploitation. 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 like 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 cases. Hey, we need to go buy, you know, X tool to help us with automation or to help, you know, integrate threat intelligence. That is, is absolutely the first place that we start is a lot of those statistics just saying time to exploit has dropped by 30+ days in the last year, right? That's, those are valid reasons to put some more emphasis here.

Time to patch 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 that 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 assets is growing, patching is still not done correctly. So it's taking even longer because more assets 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 is more like it.

That's what, that's our main job in cybersecurity and such, isn't it? Right? Kind of depressing.

I think it might be.

But honestly, thank you for being a great guest. This really worked out super well. And I haven't been lost, at a loss for 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 out of time. Thank you very much for listening, and of course, for subscribing. Please subscribe so you can get new episodes piping hot. And if you love our content, please drop us a review on your platform of choice.

You can find this podcast on YouTube, Apple Podcasts, Spotify, or wherever you get your podcasts. Also, you can find us on our website, cloud.withgoogle.com/cloudsecurity/podcasts. You can argue with us on the Google Cloud Security Community site, googlecloudcommunity.com.

You can follow us on X, x.com/cloudsecpodcast. Tweet at us, email us, argue with us. And if we like or hate what we hear, we can invite you to the next episode.

See you on the next episode of the Cloud Security Podcast by Google.