I had a discussion with somebody this week about vulnerabilities that don’t have CVEs. I learned from this conversation that there are a lot of misconceptions about those. So let’s talk about vulnerabilities without CVEs, and what to do about them.
What CVE means
Any vulnerability scanner will find vulnerabilities without a CVE. That’s part of their job. But overgeneralizing about them or ignoring them are not the way to handle them.
CVE stands for common vulnerability enumeration. It is the industry standard tracking number for vulnerabilities. All CVEs are vulnerabilities. But not all vulnerabilities have CVEs.
Sometimes it’s just because they’re too old, and sometimes it’s because whoever discovered them never bothered to submit them. But for whatever reason there are large numbers of vulnerabilities that don’t have CVEs.
I know of one security vendor who claims to have knowledge of tens of thousands, if not hundreds of thousands a vulnerabilities that the vulnerability scanners don’t know about. I’ve never paid them much mind, because I’ve seen how much difficulty organizations have getting a clean Qualys or Nessus scan. They don’t need 200,000 more low severity vulnerabilities to worry about. The problem isn’t lack of motivation, although that stance seems to be controversial for some reason.
Also, the scanner vendors are motivated to have large numbers of findings. So if they know about something that isn’t a CVE, they produced signatures for them. This was something of an arms race, because when trying to win business, some companies just put all three of them in a lab and scan the same machines. The one that finds the most is the automatic front-runner. It’s not the best way to evaluate, but it sounds credible.
Informational findings
Some non CVE vulnerabilities are informational. One scanner vendor tells you to ignore those, and plays up their lack of informational findings as a strength. As an analyst, I use those informational findings. If nothing else, I need them for troubleshooting occasionally. When a system won’t take patches, frequently there are some clues as to why in those informational findings. My favorite one is the pending reboot finding. While not a vulnerability in itself, when I see that, I know the patching team left money on the table. Rebooting the system is going to clear at least one random vulnerability off that system. But probably more.
So you don’t want to ignore informational findings, at least not all the time.
What to do about non CVE vulnerabilities
The person I was talking to thought that vulnerabilities that don’t have CVEs can’t be patched, and therefore there’s nothing you can do about them. That is over generalizing.
Some of them simply warn you about end of life software. That means that software isn’t getting updates anymore, but that doesn’t mean there isn’t anything you can do about them. You can upgrade to the new version. Yes, it may require some testing, but the perception that you still have to run one version of Microsoft office forever is one of the things that causes the security issues that keep making headlines today. We have life cycle management for our car fleets and our elevators. We need to do the same for our computer software. And the longer we put it off, the more expensive the problem gets to fix. Letting old software fester isn’t thrifty, it’s shortsighted. Just like outfitting your car fleet with surplus cars you bought from Rent-A-Wreck.
But a large number of them fall into other categories. Almost every windows system has a handful of non CVE vulnerabilities on it. They tend to be fairly minor, so few people pay them much mind, but they require changing some default permissions or a registry setting. They aren’t difficult to fix, but they aren’t a matter of just deploying an update either. The unquoted search path finding is a good example of this.
And some of them are just obsolete crypto. The crypto we used in the mid-nineties isn’t powerful enough to still use today. There’s no specific CVE for it, it’s just we knew what the shelf life was for that crypto when we started using it, and we’re beyond that shelf life. The solution is to reconfigure your system so it’s not using that anymore. Again, it’s usually not a patch. But it’s a configuration change, whether that’s in a text file, or in the registry.
Dealing with vulnerabilities without CVEs
There’s no one-size-fits-all solution to this. People like common sense easy fixes, but frequently in life, solutions to problems don’t fit on a bumper sticker. Sometimes it’s complicated, and this is one of those cases. That’s why people specialize in vulnerability management. That’s what this field is called.
And it is management. That means taking stock of the problems, prioritizing, and ideally, not reinventing the wheel. There are some ways to go about doing this. One trick is to hire an MSSP. The quality of help you get will vary, but at the very least, you have someone who has seen problems from more than one company. It’s a fairly inexpensive way to learn from other companies’ experience.
I’m also a big advocate of building solutions that consist of more than just a scanner. I’ve worked for a scanner vendor and for an aggregator vendor, and having an aggregator can solve some problems for you by correlating data that’s otherwise difficult to correlate on your own.