Podcast: Common Vulnerabilities and Exposures or CVEs Explained. What They Are and How They’re Used
The Common Vulnerabilities and Exposures (CVE) system is a critical tool for the cybersecurity industry. CVEs provide consistency in naming and clarity on the nature and impact of various vulnerabilities. In this week’s Linux Security Podcast, Atomicorp CEO Mike Shinn discusses the origin and management of the CVE process, how it’s used by cybersecurity professionals and why it’s so important. He also discusses how vulnerability management systems are perpetually hobbled by the limitations of the CVE system.
Atomicorp provides unified workload security for cloud, data center or hybrid platforms. Built on OSSEC, the World’s Leading Open Source Server Protection Platform. See our products.
Podcast Transcript: Common Vulnerabilities and Exposures or CVEs Explained. What They Are and How They’re Used
Bret Kinsella: [00:00:00] This is the Linux Security Podcast episode number nine. Today we talk about CVE. What they are, how they’re used and why they’re important.
Bret Kinsella: [00:00:18] Ok. Welcome back to the Linux Security Podcast. I’m here again today with Mike Shinn, CEO of Atomicorp… a longtime cybersecurity expert, started out in the White House, was at Wheel Group, built a lot of the tools that we used today was the precursors of them and one of the things he’s dealt with a lot over the years are CVEs. So, Mike, why don’t you tell the audience what is a CVE? Why are they important?
Mike Shinn: [00:00:44] So “CVE” stands for Common Vulnerabilities and Exposures. It is an encyclopedia that Mitre maintains. Mitre is a non-profit here in the D.C. area that’s been around for a long time and they run this project for the purposes of giving a unique numerical identifier to every publicly known vulnerability. There’s some caveats there. The first one is the vulnerability has to be public. And the second one is that they have to know about it. So just because a vulnerability is you know maybe known to the hacker community… let’s say… doesn’t mean that Mitre knows about it. So typically the sources that Mitre relies upon to find out about a particular vulnerability is the vendors and a vendor will say we have a vulnerability in this particular product. And Mitre as well as some other organizations will issue that particular vulnerability a number. And the idea is that from that point forward there is a standardized way for everyone in the world to talk about a particular vulnerability. So you don’t have to have a cool name for the vulnerability. You can just look it up CVE 2018-12345 whatever the number is that’s issued to it. So there’s it helps. And being able to get everybody on the same sheet of music to know what we’re all talking about if we say CVE 2018-1187. We all know what that is.
Mike Shinn: [00:02:28] And you know if we say we want to talk about -1189 we know we’re talking about a different vulnerability may be in fundamentally different products. They may be wildly different vulnerabilities one may be really critical one may not be critical so the CVE is just its name basically and then within the taxonomy that they’ve created they’ve got a scoring system where they try to help people identify how important this particular thing is and that scoring system has some limitations but that’s basically what the Mitre CVEs are.
Bret Kinsella: [00:03:02] OK. So who uses the CVE and then how do they use it?
Mike Shinn: [00:03:07] Yeah. So the CVEs are used primarily within the cybersecurity and supporting communities as a way of identifying to people that there is potentially some action that they need to take that this product has the following vulnerabilities in it. Here’s what those numbers are and Mitre will try to collect as much information as they can about that vulnerability and that may include references perhaps to the vendor who has instructions maybe how to address that particular vulnerability or patches that need to be installed or maybe that the product has been discontinued perhaps because of a particular vulnerability. You know one of the limitations with the CVE system of course is that it is only telling you what’s known. So sometimes people misuse the CVE database and will use it to look at a particular product, in a particular version and say “Are there any CVE for that?”. It’s not a bad thing to do. Right. It’s important to understand that there’s vulnerabilities you need to address. But just because there aren’t any CVEs doesn’t mean that there isn’t a vulnerability in the product right. The encyclopedia is only as good as the information that it gets.
Mike Shinn: [00:04:35] So somebody has to care to both find the vulnerability and tell somebody at Mitre that the vulnerability exists. So again if a bad guy finds a vulnerability in something typically they don’t have a motive to tell the rest of the world that they found a vulnerability in it. You know and maybe it’s a good guy that found a vulnerability in something and they’re still in the process maybe of communicating this information to the vendor or maybe the vendors ask for more time to fix this particular issue. It’s also important to remember that the CVEs are really only a point in time so a product potentially could be discontinued and maybe it has a whole slew of vulnerabilities in it and nobody’s ever bothered to test or report them because the product is discontinued. And everybody’s moved on to something else. So it’s really just a way for us all to be able to talk about a vulnerability and use the same label. So that’s how it should be used. It can be used in other ways that are not as constructive.
Bret Kinsella: [00:05:45] OK. So if there’s a known vulnerability. Very often we would expect the vendor to have a patch for it but sometimes they don’t have a patch for it or sometimes it’s not a vendor backed software. Sometimes it’s an open source software. So how do you address vulnerabilities in those cases where there is no there is no patch or there is no vendor to call up and say “When are you going to fix this?”.
Mike Shinn: [00:06:12] Well there’s a few ways to address that. Probably the oldest one is to get rid of it and replace it with something else that doesn’t have a vulnerability in it. Right. It’s probably why I am more in the camp of more information is better than less. Right. There is a school of thought in this world of talking about vulnerabilities and it’s a reasonable school of thought that maybe we shouldn’t talk about vulnerabilities and things if we don’t have a fix. Right. We don’t want the bad guys to know that there’s a vulnerability there. You know but like I said one way to address a vulnerability is to replace the product with maybe another vendor’s product or another version of the product or or maybe a different product. So that’s that’s one way to address vulnerabilities where you don’t have a patch or anything. Another way to address vulnerabilities is it is kind of a general category of things while mitigating controls or are there other things you can do to prevent a vulnerability from being exploited. So maybe a simple example is you have an old legacy system lots of vulnerabilities in it. You can’t replace it. So you put it on its own dedicated network behind a firewall. Only one person is allowed to get to a you limit the scope of its exposure. You know if you can’t do that then there are some technologies that you can use that are pretty powerful that can help you to address vulnerabilities.
Mike Shinn: [00:07:37] Now one of those is the general category of mitigation called Virtual Patching or Just In Time Patching. It’s kind of a sad thing that we use the word patching in there because people think. There’s a patch. But really what this is is a technology and there’s many ways to do it that would allow you to either address that vulnerability somehow external to the system or device or application you put something in place that blocks this particular type of attack or there’s some virtual patching and technologies that will try to actually patch the software and sort of rewriting the binary if you will. So not a not a normal patch in the normal sense. Those technologies have a lot of utility because they decouple the task of patching a system from the risks of patching the system. But for systems like you described where maybe there isn’t a patch available or maybe the product isn’t supported anymore. Those are really your choices. Either replace it or limit the exposure that the system has or use some virtual patching technology. The latter one though is that there’s a lot of great solutions out there to do that. That’s a very popular solution because the first two aren’t really practical. Right. If you if you’ve got something they can’t patch there’s probably some reason you still have it. So simply pointing at it and saying let’s replace it with something better begs the question why are we using it anyway. So in most cases some kind of virtual patching technology gets used.
Bret Kinsella: [00:09:17] Are most of your patch management software solutions really working off of that CVE list and just making sure you’ve checked all the boxes?
Mike Shinn: [00:09:25] Yes. Yeah that’s it exactly. That’s one of the weaknesses of the whole CVE program is that it’s only as good as the data that goes into it and not everybody appreciates that. So just because there isn’t a CVE for something doesn’t mean that it doesn’t have a vulnerability. Again, it’s only going to end up in the CVE database if somebody is motivated to communicate that to Mitre. And for some products there is very little interest maybe from the community of people that work with it or enough knowledge to understand a vulnerability. And again maybe a bad guy found it. They don’t have any motivation for that to either. Or, it could be you know there is a type of vulnerability that is so general that it might affect… you know… thousands of products and that’s not something that’s easily captured in the CVE program. You know if you if you’ve got some generic flaw that affects a lot of things it can be challenging to sort of fit it into one definition. Sometimes you can because you can pin it to a thing like Meltdown or Spectre but other times it could be something truly generic like SQL injection. Right. Well, probably every web application has that vulnerability in it. So the the downside for any type of security management that’s driven by CVEs is you can end up in a condition of overconfidence where you think well we’ve addressed all the CVEs so we’re OK.
Mike Shinn: [00:11:03] That’s why we have vulnerability scanners. That’s why we have tools that are designed to actually beat up the products that we have to try and find vulnerabilities in them. The CVE is reactionary. Everyone should always remember that by the time it has a CVE the time for talk is over. Everyone knows about it. There’s probably exploits for it already. If you’re not already patched bad things are probably already happening to you.
Bret Kinsella: [00:11:28] Yeah absolutely. Thank you very much. There was a great summary of CVEs. Mike Shinn.
Mike Shinn: [00:11:31] Thank you.
Atomicorp provides unified workload security for cloud, data center or hybrid platforms. Built on OSSEC, the World’s Leading Open Source Server Protection Platform. See our products.