[BreachExchange] The Importance of a Living Database

[Destry Winant]

https://www.riskbasedsecurity.com/2021/03/24/the-importance-of-a-living-database/

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:

1. VALIDATE
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.

2. PRIORITIZE
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?

Request a Demo <https://www.riskbasedsecurity.com/contact/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20210324/482e0987/attachment.html>