The Importance of a Living Database
March 24, 2021 • RBS
How much time are you currently spending researching and vetting vulnerability disclosures? In the current landscape, it seems that many organizations are forced to spend more time on vulnerability assessment than on the actual vulnerability management. Backlogs continue to grow, and it can be hard to prioritize. In an environment where one missed vulnerability can lead to a data breach, you need to know everything you can, as fast as you can.
To effectively make risk-based decisions, organizations require the most accurate, detailed and timely information. Unfortunately, the data that is publicly available is often none of those things. In our latest 2020 Year End Vulnerability QuickView Report we found that CVE failed to report 29% of the disclosed vulnerabilities aggregated by RBS last year, increasing the total number of vulnerabilities missing CVE IDs to over 80,000.
That kind of gap is hard to justify to auditors and management. But even if your team isn’t basing their risk decisions directly from CVE/NVD entries, could you say the same for your current Vulnerability Intelligence (VI)?
Where Does Your Data Come From?
A poorly kept secret in the security industry is that many security tools almost exclusively base their data and signatures on CVE/NVD entries. So even though what you see and use on a daily basis doesn’t look like CVE, chances are it is heavily based on CVE, or is even a direct copy.
This is most likely the reason as to why your team is often forced to search for vital information such as the status of an exploit. Even where such critical detail is available, it is not always accurate or timely. Unfortunately, it will most likely stay that way as many databases are treated as static entities.
This is a major problem with the typical “one and done” approach that CVE/NVD and other vulnerability databases typically adopt. The vast majority of vulnerability entries are treated like an episode of “The First 48”, where the providers move on to the next thing after disclosing. Using this approach negatively impacts the consumer as vital information such as the availability of a patch, exploit location and exploit availability doesn’t get included once that data is released after the disclosure.
Databases Should be a Living Entity
Risk Based Security operates under the belief that vulnerability databases need to be considered living entities. This is because like the times, vulnerabilities are always a-changin’. The disclosure date is not the sole determinant of whether a vulnerability requires action. What really matters is whether new information comes to light that offers more context and/or facilitates remediation. By following this ‘living database’ mentality we are able to better fast-track remediation for our clients, enabling them to spend less time performing research tasks and more time managing and mitigating.
A living database provides value by helping users to:
If your organization is paying for a VI service, it seems counterintuitive if you have to validate the majority of entries. Isn’t VI supposed to make life easier? Sadly, this is a commonplace problem that many security and vulnerability management teams face.
Security teams are often flooded with vulnerabilities affecting major applications like Windows, or are forced to immediately address unexpected situations like the SPECTRE/Meltdown vulnerabilities. Oftentimes the initial disclosure information lacks the level of detail needed to actually prioritize remediation, resulting in teams spending many hours searching for actionable details.
However, that’s the case if organizations rely on a static data source. A proactive approach allows us to find those details for you as well as provide up-to-date references and more accurate CVSS scores than what is publicly available.
“RBS provides its own security ratings, and they don’t just consume what vendors or what NVD says. All these elements improve the quality of information, and the ratings.“Stéphane Grundschober, Vulnerability Manager at Swisscom
You can’t move to the next step of prioritizing vulnerabilities if you don’t have all the details, and sometimes we end up finding vulnerability entries that just don’t make sense. For those using CVE/NVD or tools that repurpose that data, you may have occasionally stumbled across some baffling entries too.
Microsoft Defender Remote Code Execution Vulnerability
Speaking of vulnerabilities that don’t make sense, consider CVE-2021-1647:
When it comes to serious vulnerabilities, CVE-2021-1647 checks all the boxes. It has a public exploit, has been reported as being actively exploited in the wild, affects a wide range of commonly used products, has low access complexity, and potential to inspire future attacks.
But despite the advisory and being explicitly described as allowing remote code execution, the vendor scored this vulnerability with a local attack vector and NVD blindly copied their score. Something doesn’t add up.
If something doesn’t make sense our research team sets out to find the answers. We quickly reached out to the Microsoft Security Response Center for clarification, added all relevant references, and added technical information to notify our users. We also rescored the vulnerability based on all the newly known details, updating the CVSS score from 7.2 to 10.0.
A simple mistake in labeling vulnerabilities can have serious consequences. This is why treating vulnerability databases as a living entity is essential in providing the most value to its end users. You may want to make sure that this vulnerability didn’t get relegated to a backlog.
VulnDB clients can find all of those details here: VulnDB ID: 246736.
Over 23,000 vulnerabilities were disclosed in 2020. With disclosure numbers like this, how are organizations supposed to handle such an incredible volume? If your end goal is remediation, you need to be able to effectively prioritize which vulnerabilities get top priority. For threat intelligence and monitoring teams, that may mean remotely exploitable vulnerabilities are on top of the list. For the managers that direct these teams, they may place more or additional emphasis on the availability of a public exploit.
Regardless, making truly risk-based decisions in a timely fashion could be incredibly difficult as most VI platforms don’t provide exploit status. CVE/NVD doesn’t have a reliable method for exploit location other than mining NVD’s CVSS scores, meaning that tools copying that data likely won’t have it either.
It is important to have patch information, exploit location, and exploit availability. With all three pieces of information, an organization better focus on the most critical vulnerabilities.
“Old” Vulnerabilities Can Still Be a Risk
In many cases, those important details often come after the initial disclosure date. The disclosure date is not, and should not be the sole determinant of whether a vulnerability requires action. Things change all the time within the vulnerability disclosure landscape and organizations need to be completely aware.
For some vulnerabilities like POODLE, our research team has refined its details over 1,200 times. That’s a ton of data, but the good news is that all of it is already indexed for display in our portal or formatted in JSON or XML via API so that it is easy for organizations to consume and automate for remediation. A living database approach ensures that our researchers are constantly updating VulnDB entries for the following:
- Adding caveats and restrictions for exploitation
- Updating with additional technical details released after-the-fact or from third-party analysis
- Updates with solution information
- Adding additional products that are impacted
- Changing the status of the exploit or adding details about it being used in malware campaigns
- Revising the CVSS scores based on new technical details
- Flagging it as “not a vulnerability” if it is determined to be incorrect
The goal is to provide organizations with the most up-to-date and actionable VI so that organizations don’t have to waste time or resources. You can’t achieve that if your database is static.
3. Remediate faster with VulnDB
In addition to comprehensive data, VulnDB allows users to get real-time alerts on the vendors and products that they care about. By being proactive, we ensure that by the time VulnDB users get the notification, the data contained within the entry is valid and actionable. From there, organizations can map these vulnerabilities to their assets, prioritize, notify the teams responsible for remediation, and then follow up in a timely manner to verify that the issue has been resolved.
Can you say the same about your current data source?