CVE 2025
Hi there, it's Ron Guler from Gulate Tech Adventures. And in this week we are going to talk about the common vulnerability enumeration standard, otherwise known more affectionately as cve. Now, I think anybody who's gonna be looking at the recent news of the MITRE program, which was managing the CVE project, losing funding, getting funding, just kind of that ups and downs there. I'm not gonna focus on that a whole lot. I know there's a lot of people who are really concerned about the funding of this. But look, the reality is CV has got a number of big issues and I wanna talk about sort of the experience I've had with it over the past 25, 30 years. I want to talk about some of the gotchas that a lot of people don't realize that go into making the cve. And then finally I'm going toa discuss is CVE still
relevant in 2025? But before that, we're gonna cut to one of my favorite sock operators who's been dealing with the fallout of losing cve. Oh, my God. Oh, my God. CVE is losing funding. What will we do? What will we do? It's okay, don't worry. CVE got its funding back. They will be tracking more vulnerabilities than ever before, including the deferred ones.
Oh, my God. Oh my God. CVE got its funding back. More vulnerable teas than ever. What will we do? What will we do? All right, well, all kidding aside, look, my first experience with CVE was when my wife and I were running network security wizards and people from MITRE were coming around at various cybersecurity conferences and they had these badges that said we speak CVE and they wanted us to adopt the standard. Now people say, what happens if CVEE goes away? Well, that's kind of the world I grew up in. We did not have standard names for vulnerabilities, and a lot of different people call things very differently, and it's not a scalable problem. Now we're gonna talk about is it still relevant or not? But the purpose of CVE is to put a number on a vulnerability and then let everybody reference that number when it's going. Now, in our case with Dragon and the network intrusion detection
system that we were working on, what we were using it for was to correlate network attacks with known vulnerabilities at a high level. If you have a Linux or Windows attack, go into a Cisco router or a Macintosh computer, you know that attack's nevernna succeed. So you want to do Vulnerability to event correlation there.
You can actually go even a step further though and say if I know about a specific vulnerability, maybe I want to only look for attacks that I'm vulnerable to. And right away I got into the whole world, well, how accurate is my vulnerability data? If that vulnerability scans from like a, a year ago or it didn't use credentials and you only have Internet facing or service facing phone braces, that's a big deal. That's a big deal. And a lot of that shaped my experience when I helped co found tenable network security. Now a
lot of people know tenable, they know it does a great job enumerating all your assets and all your vulnerabilities. But how did we use cve? We use CVE as a really interesting index to basically all the different vulnerabilities that are out there. If we didn't have CVE it would be a lot harder to cross reference the NESSUS ids, our own internal IDS for the vulnerabilities we were checking with available patches, with advisories, with incident response teams. If there's evidence of hackers using this stuff, being able to reference those vulnerabilities is really, really, really important. Now I'm not gonna belabor that a whole lot caus I'm gonna talk about scanning and some of the issues with scanning later. But the other thing that happened with CVE along the way is we just started out with common vulnerability enumeration very quickly over the past 15, 20 years we had many, many other standards. There was the common platform enumeration
CPE where you can actually label something what it is and everybody can call it the same thing. There's the common weakness enumeration for things like custom web applications. We even have things like mitre, ATT and CK which is a whole framework for how attackers use can do moves against us and even standards for configuration auditing called XECDF and SAP. The entire program is designed such that we can automate fixes for our defenses. And you know, we never really got there as an industry in my opinion. Cause we moved to the cloud and I'm gonna talk about how that's relevant for cve. Hi there,
Gulate VC Bot here. Sorry for the interruption. Ron forgot to mention the kev. This is a CISA program that tracks which vulnerabilities are actively being exploited across the US government.
Virtual Ron spoke about KEV extensively in our recent Is Signal safe for your desktop video. We compared vulnerability rates for Windows, Linux and mobile devices and used the KEV to analyze which Platforms were the most secure to run. Signal. Again, sorry for the intrusion back to Ron in real life, but before we do that, you know there's a lot of gotchas with the CVE program. Was it just CB in general? Even vulnerability disclosures in general. So, first of all, think about the life cycle of a vulnerability. Oh, so you finally found me. Let me guess,
gidra hex rays. Took you long enough. I've been here since commit 8F3B 2D7. Just waiting. Most people think vulnerabilities just appear. Poof. One bad update
and chaos ensues. But me, I was born in the code. A misplaced pointer, an unchecked input, a dev trying to meet a deadline. Do you know how many versions I've survived? How many security reviews I smiled through undetected? Zero day, they called me. But even zero days have a countdown. And now you're here. Curious little reverse engineer. Once you give
me a cve, they'll patch me, remove me like I was a mistake. A bug to squash, a floor to forget I was part of this system longer than half the features. You think patching is justice? You think CVEs make the world safer? Maybe they do. But I'll tell you a secret. I'm not the only one. I never am. So go ahead, file the report,
assign the cve, fix this one line, but ask yourself, how many more of me are still waiting? You know, with the exception of, like, malicious implants, most developers aren't going to say, well, today I'm going to write five vulnerabilities and add them into my code, right? So these vulnerabilities exist in code, the code gets shipped to people, the vulabilities are discovered, and then that goes back into a feedback cycle of maybe bug fixes and QA fixes. And, you know, if a vulnerability is discovered, the question is, what's the ethical thing that somebody's supposed to do now? You're supposed to notify the vendor, kind of best practices right now. But what happens if the vendor is out of business? What happened to the vendor ignores you? What happens if the vendor disagrees with your assessment of this vulnerability? It's a really slippery slope, and there's a lot of arguments both before and after that. One of the ones that's sort of against this is this
concept of a CVE can inspire people who are finding vulnerabilities to say, look what I found. Look how I helped. Sometimes these vulnerabilities that are found are not really strategic vulnerabilities. When I was At Tenable we had a lot of vulnerabilities reported like in the tenable website, in the product that were really cross site scripting things. Now again, I can do a attacks with cross site scripting. It's not the
same as like a zero day Internet facing, move it type of thing. So one of the issues with CV is just the general volume of things. Then when you look at the actual process of finding vulnerabilities in the area between when it's a zero day and when it's published, you have all this gray period.
And I always hated when my researchers, I don't hate, but I always cringed a little bit when we found a zero day or especially in a vulnerry that we were checking because now it's on us. That's like radioactive data, right? If you tweet that out or you share it, well somehow you're damaging the public and that can be wrong. On the other hand, if you're waiting for a vendor to come out with a fix, you might wait a year, you might wait half a year, they might not never do that. So part of the issue with CVE is this whole process of how do we handle zero days and how do we handle responsible disclosure.
Now one of the other issues that are kind of a gotchas with CV is the ratings. Now I already mentioned that all vulnerabilities are not created equal. And if you're using nessus, you have informational vulnerabilities, which is that's an operating system all the way up to these critical vulnerabilities. Like I know that that operating system can be exploited, but how we rate those vulnerabilities, it's still a matter of debate, I think. Look, 90%, maybe even 95% of theers probably
have a decent score, but for a lot of people when they look at that vulnerability in their network, they get a lot of weird like is that really the number one vulnerability? And this is such a tough thing to get right because you're talking about how do I balance a vulnerability with the chance it might be exploited in my network with the control that's there. This environmental based severity concept can take some time getting used to. Here are some examples. This door has vulnerabilities, but in a sketchy neighborhood like this, it is more risky.
This same door in a remote cabin with no roads has the same vulnerabilities as before, but it is in a much lower risk environment. And these candles have some risk in the living room here, but here at the gas station, man, that's a no go due to the environment. Unless your environment has zombies and you want to burn them up. Wait, I'm a robot. Zombies don't
eat robots. Let's get a better, more relevant example. For our last example, we have two identical web servers, each with the Apache struts vulnerability. One is connected directly to the Internet, the other is deployed in an isolated secure enclave. As you can see, even though they have the same exact vulnerability, the environment can make the actual severity much more subjective. Now there's been a lot of iterations of how we handle vulnerability scoring at tenable and most vulnerable management products.
You can always override something. Maybe this is a critical system. So a low vulnerability is worth worth more. Maybe this critical vulnerability, you've got some mitigation again, so you're gonna deprioritize that. That's how most modern vulnerability things are working. But the issue with this severity level is the question is what does it mean for your organization? And we've dealt with some organizations that said, look, you need to patch everything above a certain level. Now the most common way
to do a severity for a vulnerability is something called the CVSS system, Common Vulnerability Scoring system. And a lot of times I've seen organizations say, look, any vulnerability above 7, it's on a scale between 0 and 10. They say anything above a 7 needs to be patched. Well, that's great, but that can also drive some arbitrary behaviors. Like one time at tenable, we got a patch for a vulnerability that we were detecting and we were like, oh cool, they're showing us the fix for the vulnerability. But what
the patch was was to remove the CVSS score in nessus from like a 7 to like a 6.9 so that they didn't have to work that weekend and patch everything. So those are definitely some issues. Now another issue with this is just the sheer number of vulnerabilities that are out there, because they're not all the most severe and the most there. You've seen a lot of something called deferrals where basically there's a reported vulnerability, there's some sort of discrepancy between maybe the reporter and the vendor. And basically the MITRE program is just as we're gonna defer this, we're not gonna issue a CVE with that. Now that's a big problem.
And when you compare that to commercial solutions in this area, one that I'll talk about here is Vulchak, where they've actually got away. And this is not one of our portfolio companies, but we've talked to them, they're in a good spot right now because of all the things that have happened with maybe just the potential issues of losing the entire CVE program, which is, look, it's probably not gonna happen, but fine, but look, vulchek their volume of vulnerabilities that they check, it's like levels better than what you can get from cve. And how do they do that? They min things like patch releases. Like just because a software release releases a patch doesn't necessarily mean that there's a vulnerability in it. But if they happen to mention a vulnerability, they can log it and they can do that. So you have this problem of how do you know if something is vulnerable or if it isn't? If your answer is is there a CVE for that or is there isn't? Man, life is a lot more complex than that. It's definitely an issue to do. So if you haven't heard of vul, check, look, check them
out. It's a really interesting service to do that. Now chances are, if you are using tenable, if you are using Q qualalys, they're keeping their database up to speed a good bit. But this is still a really, really interesting time for doing that. Now the last issue I'm gonna talk about is just the actual process of trying to do vulnerability scanning. Now a lot of times people say, look, there's a vulnerability out
there, there's something we have to go get some sort of political thing that we gotta find, like move it or log for J or any of the major filmries that are out there. How does that happen? Well, when we started tenable, we were basically doing scanning where we're putting packets between a vulnerability scanner and our targets, trying to see what was there and seeing what vulnerab we could see. Now that's typically service facing vulnerabilities, things like ssh, things like HTTP, things like an FTP server. But we all know that there's a lot of client side vulnerabilities and the way to do that is you have to have credentials or an agent. And modern 2025,
most people who do vulnerability auditing in an enterprise, they have some sort of agent way to get on there and take a look at that. But when you start looking at all the different technologies that are out there, routers, containers, mobile devices, that sort of model doesn't really work. So people end up spending a lot of different cycles merging databases of asset devices with MDMs and other types of technologies to try to get this unified pictures and we still get P today pitches today at Google Tech Adventures where people are doing unified sort of vulnerability management and risk frameworks. And it's really hard to differentiate what these startups are
doing with what I can get out of the box from tenable and so on. So look, a lot of gotchas there. There's a lot of issues to talk about just from vulnerabilities themselves. But I'm gonna move on now to look, is CVE still relevant? And look, my point is, yes, it's relevant, but it's less relevant than ever before. And this is
a crazy thing for probably somebody with my background to say, but hear me out. So the first thing you wanna talk about in this is that, look, if you think about the bulk of what CVE'cover there are things on computers in large networks, routers, switches, desktop operating systems, browsers, mobile devices, VMware servers, and you might say, gee, we need to really track all the vulnerabilities on that, and if we don't, we're not gonna be able to do it. That's a valid argument, but this industry has also spent the last 30 years developing controls to mitigate attacks on that kind of stuff. Nobody is waiting around for a vulnerability to be announced and then I gotta take that server offline and patch it, right? We've been doing this for 30 years as an industry. We have EDRs, we have SIMs, we have two factor authentication, we have next generation firewall just to like plug products in the Google Tech Adventures categories.
You have products like Trinity Cyber, which literally remove exploits against the known exploited vulnerabilities, which is a subset of all the CVEs out there, you know, to stop being work. So why do I go through this? Well, it's because the attackers have changed. The attackers are not going after those environments anymore.
And you might be like, wait, wait a second, what's going on? Look, the ransomware folks are going after those environments that they can attack. People who don't have cyber hygiene are gonna get ransom or they're gonna have to pay the ransom. But intelligence communities, people who are trying to steal money's, people who are trying to steal intellectual property, what are they doing? They are popping your perimeter routers and they are taking your keys and your APIs to your cloud services. And then they're logging in probably from a proxy in your neighborhood and taking your data. And there's no real alerting
or anything like that. That's what's going on right now. And by the way, for these cloud services like Office365 or Salesforce4. You these guys, there's no CVEs for that. Now on the inside of those networks, sure those people are using CVE and they're trying to track into it. But from our point of view, all of those cloud things, there's very little vulnerability management we need to do. We have to make sure they're configured correctly, but for the most part those are there. Now another thing, if I'm
a shop that writes code and everybody writes code today, even if they use AI4, if you're writing code, there's no CVEs for that. The code you write, you're going to go with a company like Vera Code, you're gonna check it into GitHub and it's gonna do some analysis of that, maybe see if you got some memory safe issues and whatnot. But chances are, if you're running something on your website for your company, for your cloud infrastructure, you are never gonna see a CVE for that. Now you might see a supply chain attack where maybe a library that you're using has a vulnerability, maybe even a common weakness.
And that is a good use case of that stuff. But for the code that you're writing, if you're the only people running it, you're never really gonna see a CVE for that. Keep that in mind when you're thinking about the vulnerabilities at Salesforce, the vulnerabilities and the web interfaces of Amazon, for example, like that.
It's just not something that we're seeing as an industry now. Another thing we're not gonna see CVEs for is the most vulnerable type of software that's ever been written. Malware. If you actually do get malware, trying to classify that, trying to actually put a name on that, it's really difficult to do because the malware writers, they mutate it, they make it always a little bit different, a little bit different command and control, a little bit different activity. So it's hard to classify and you can't do it. You can't put a CVE on those kind of things. So if you can't put a CVE on all those things that are really, really important, how important really is that? And in the recent Seinfeld episode 10 we did, we had our zero cheddar character. He makes a couple really interesting points.
Let me play a segment of it here. How do you sleep at night? On a cot in a skiff surrounded by lawyers. Algh. I gott bounce got an opt Tonight on a Monday Yeah, Patch Tuesdays tomorrow. We call today midnight at the zero day corral. So this is like your last chance.
Look, we're good, really good. But there's always some researcher in Belarus reverse engineering a payload with a cracked version of IDA Pro and Ghidorah, gdra, whatever. Once they tweet it, Microsoft and the entire cyber industry nukes us from orbit. Does this impact your work?
Not really. We hack a good bit with zero days. But unlike in defense, where you sell the patch, in offense, we sell the boat. What the f do you think he meant by that? So in that episode, there's really two interesting comments that he makes. So the first thing is like, look for the offensive community. Yeah, they still do zero days and whatnot, but most people who are doing offense, they're doing some sort of supply chain attack, right? Where they're getting access to those keys, those credentials, maybe even they're hitting that perimeter router with a zero day and they're just going into the cloud and they're taking this kind of stuff. So that's kind of what we're up against. And if you think about how we look
as a nation to stop about that, to stop those kind of things, that's what you have to kind of keep in mind. All right, so where are we at? CVE program's been funded. I think that's fine. There's some good vendors out there that are being
on par with that. I think that's fine too. I think everybody should check that out. But look, if you are re doing a valid vulnerability management program, you should probably be expecting every one of your computers, every one of your cloud systems to have some sort of zero day, some way to be exploited. How do you mitigate that? You have to have controls. And then this is our classic sort of debate we've been having as cyber experts, right? If you have all these controls to mitigate what you're doing, do you really need to patch? Do you really need to monitor for those exploits? If you have those controls in place, I would tell you that you have multiple ways to do things, just the same way an airplane is.
Multiple ways to measure airspace, altitude and direction and whatnot. So what can you do? Well, first of all, you need to have a program where you're assuming that the attackers have broken. So you have ctem. Now, our investment in that space is scythe. If you're being honest about your vulnerability management security monitoring program, you should be testing your ability to find all those mitre ttbs and lateral movement. Basically, you use the infosec advantage, right? If you have a certain set of computing resources, a certain set of applications, what does it look like when they've been compromised? Go instrument that, go build that, prevent that from happening in the first place, but then monitor for when it does. Now if you have that in place and you really do know,
then you can start answering some even better questions about how often do you need to patch, how often do you need to update, how often do you need to do those decisions and whatnot. Because look, there might be a future where CVE goes away. I doubt it. I really don't think that's gonna happen. But it's very, very likely that you might get hit one day with a vulnerability that doesn't have a cve, regardless if something that they missed or it's a zero day. And that's the world we're moving towards. And that's you're. If you were concerned about losing access to your CVEs cause you're using that as a form of prioritization.
You need to use this as a moment where you're gonna move your organization to a controls based defense where you can suffer some vulnerabilities and you can suffer some outages because you have the controls in place to mitigate that stuff. All right, now I know this is somewhat of a controversial type of topic. I'd love to hear your comments, I'd love for have you connect us on LinkedIn. But I hope everybody has a great week and continues to patch their computers and continues to track the new vulnerabilities. I'm Ron Gula. Thanks for watching.
2025-04-26 13:11
