If you work in vulnerability management, it’s not uncommon to come across an odd situation where your vulnerability scanners pick up issues that lack CVE or CWE data.
In fact, we get asked all the time, “How do I filter out vulnerabilities that don’t have CVE data?” And we get it – when you’re dealing with hundreds of thousands of vulnerabilities at a time, it’s tempting to dismiss or deprioritize these issues in order to focus on those with CVE data – but by doing so, you could be missing some of the most notable vulnerabilities in your system. The question that you should really be asking instead is, “Why is my scanner picking up these issues in the first place?”
Let’s dive into some of the most common reasons why vulnerability scanners will detect issues that do not have CVE data associated with them and what you should do about them… apart from ignoring the notifications.
Top Reasons Why Your Vulnerability Scanner Didn’t Pull CVE Data
1. Your Operating System is Pending Reboot
The most common scan result without CVE data is a pending operating system reboot. Frequently, people conclude that they should ignore these alerts entirely, but the reality is they are all too often an indicator of a bigger problem that’s looming. Windows loves to reboot, and vulnerability remediation activity isn’t the only activity that can trigger this reboot requirement. However, you ignore this one at your own peril.
When you spot-check a few of the systems with this finding, they often have an abnormally large number of vulnerabilities, suggesting that these systems weren’t necessarily getting rebooted during their monthly maintenance window. We recommend producing a list of systems and asking the remediation teams to make sure every system on this list gets rebooted, and to prioritize that over deploying updates for the month.
2. You’re Running an End-of-Life Operating System
Most vulnerability scanners also have a finding that tells you when an asset is running an end-of-life operating system. This is how you find the proverbial Windows NT 3.1 server that’s been running in your network since the summer of 1993, when UB40’s reggae cover of “Can’t Help Falling in Love” was on the radio everywhere and the original Jurassic Park was setting box office records.
But if you analyze those findings, you’ll find that Windows NT 4.0, that OS from the summer of 1996 that grooved to the Macarena, is far more common. Not everyone still has those laying around, but if you do, you need to know about them. If nothing else, because of a dirty secret about vulnerabilities and vulnerability scanners.
That end-of-life operating system finding serves as a placeholder for CVE findings. When an operating system goes end of life, vulnerability scanners will flag them for new vulnerabilities for a time. But eventually, reliable data about whether this month’s vulnerabilities still exist in long discontinued operating systems will dry up, and the scanners will stop trying to report on them. Dropping a CVE-less finding and marking it critical is how they handle the situation.
3. Your Scanner has Flagged CVE-2008-4250 (MS08-067) and Windows NT
CVE-2008-4250, also known as MS08-067, is a particularly notorious remote code execution vulnerability that we most frequently associate with Windows 2000 and Windows Server 2003. It was a vulnerability in the Server service itself, a fundamental piece of the Windows operating system that, despite its name, you can’t disable on a workstation without serious side effects. Officially, this vulnerability existed in Windows 2000, 2003, XP, and Vista.
If you know where to look, you can find evidence that Windows NT 4.0 had this same vulnerability, and if you had the right support agreement with Microsoft, they provided an update to fix it. But does your vulnerability scanner report that NT4 has MS08-067? Maybe. Will the detection be as reliable? No, it won’t.
It is a standard security practice to assume that all vulnerabilities in current Windows operating systems also exist in the end-of-life versions of those operating systems. That is why the vendors that report on end-of-life operating systems generally rate those findings as critical. They have to go with the worst-case scenario.
4. A Signature is Causing Your Vulnerability Scanner to Leave the CVE Field Blank
It doesn’t happen very often, but sometimes a scanner vendor writes a signature to detect a vulnerability and the signature doesn’t report the relevant CVE. The detection otherwise works as expected, but they leave the CVE field blank. That’s going to disrupt your workflows.
With no threat intelligence data, it will probably mean it goes into the wrong workflow and ends up with an incorrect due date. That’s annoying. When the scanner vendor revises the signature to include the CVE, Nucleus will recover. Or, worst case scenario, since it has a due date, it means someone is going to notice it and ask questions. As a security analyst, you can intervene, adjust the due date, add comments to note what you are doing and why, and then adjust.
However, if you choose to implement a processing rule that sets a finding to informational if it doesn’t have a CVE, that can end up putting a critical vulnerability into a workflow that gets ignored and could result in a significant risk to the organization.
How to Handle Vulnerability Findings Without CVEs
Vulnerability findings without CVE’s need to be handled on a case-by-case basis. Tracking the problem, reviewing it, and educating the decision makers is the correct way to handle these types of findings, rather than sweeping them under the rug and calling them informational.
While more serious issues like end-of-life operating systems require a larger discussion about lifecycle planning, sometimes there is a business case for not upgrading certain systems. When that business case exists, the correct practice is to document it, accept the risk, and review that decision annually. What may have been an acceptable risk in 2021 may not be acceptable in 2022 and beyond.
Nucleus can automate a great deal of the tedious work that goes into vulnerability management, including handling tickets and tracking and reporting on due dates. We can even aid in the security analysis part of the job, correlating vulnerability intelligence at scale to whatever findings your scanner brings in. Not only do we make it easier to manage and remediate your vulnerabilities, but we also reduce the number of things that you need to look at to do so when you get to the point when your vulnerability management requires some form of human analysis, as it sometimes does.
