Topics

Proposal: Use CVSS version 3, not version 2, in CII Best Practices measures

David A. Wheeler
 

A very few of our criteria mention CVSS (a method for estimating the risk from a vulnerability). For example, [dynamic_analysis_fixed] says this:
CRITERION: "All medium and high severity exploitable vulnerabilities discovered with dynamic code analysis MUST be fixed in a timely way after they are confirmed."
DETAILS: A vulnerability is medium to high severity if its CVSS 2.0 base score is 4. If you are not running dynamic code analysis and thus have not found any vulnerabilities in this way, choose "not applicable" (N/A).

I'd like to update from CVSS version 2 to version 3. CVSS version 3 has been around for a while, but we didn't use it because the NIST National Vulnerability Database (NVD) only provided version 2 data, and not version 3 data. However, NIST has since added support for version 3 & has supported it for a while. More info:
https://nvd.nist.gov/vuln-metrics/cvss

This should have no effect in practice. CVSS version 3 rates some vulnerabilities more risky than version 2 did (in particular, Heartbleed gets a higher risk score under version 3 compare to version 2). That said, if a project has that many vulnerabilities where the CVSS version change matters, that's a problem in itself.

If you think that's a bad idea, please let us know. This is already an issue on GitHub:
https://github.com/coreinfrastructure/best-practices-badge/issues/1076

Thanks!

--- David A. Wheeler

Kevin W. Wall
 

I have no objections, but how will moving from CVSSv2 to CVSSv3 affect things if NVD only has CVSSv2 scores available for the particular CVE? Would there be an expectation that we would need to deal with MITRE or maybe NIST to get them to assign a new CVSSv3 score? Because I don't even want to go there.

-kevin
--
Blog: http://off-the-wall-security.blogspot.com/  |  Twitter:  @KevinWWall
NSA: All your crypto bit are belong to us.

On Mon, Nov 4, 2019, 09:04 David A. Wheeler <dwheeler@...> wrote:
A very few of our criteria mention CVSS (a method for estimating the risk from a vulnerability). For example, [dynamic_analysis_fixed] says this:
CRITERION: "All medium and high severity exploitable vulnerabilities discovered with dynamic code analysis MUST be fixed in a timely way after they are confirmed."
DETAILS: A vulnerability is medium to high severity if its CVSS 2.0 base score is 4. If you are not running dynamic code analysis and thus have not found any vulnerabilities in this way, choose "not applicable" (N/A).

I'd like to update from CVSS version 2 to version 3. CVSS version 3 has been around for a while, but we didn't use it because the NIST National Vulnerability Database (NVD) only provided version 2 data, and not version 3 data. However, NIST has since added support for version 3 & has supported it for a while. More info:
https://nvd.nist.gov/vuln-metrics/cvss

This should have no effect in practice. CVSS version 3 rates some vulnerabilities more risky than version 2 did (in particular, Heartbleed gets a higher risk score under version 3 compare to version 2). That said, if a project has that many vulnerabilities where the CVSS version change matters, that's a problem in itself.

If you think that's a bad idea, please let us know.  This is already an issue on GitHub:
https://github.com/coreinfrastructure/best-practices-badge/issues/1076

Thanks!

--- David A. Wheeler



David A. Wheeler
 

Kevin Wall:
I have no objections, but how will moving from CVSSv2 to CVSSv3 affect things if NVD only has CVSSv2 scores available for the particular CVE? Would there be an expectation that we would need to deal with MITRE or maybe NIST to get them to assign a new CVSSv3 score? Because I don't even want to go there.
Good point. I think that shouldn't be required, & it wasn't intended. I think we can solve that.

But first, I think I'm required to note that anyone can calculate a CVSS score.
NVD has a little calculator: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator
FIRST does too: https://www.first.org/cvss/calculator/3.0 and https://www.first.org/cvss/calculator/3.1
That said, there's a judgement call on a few questions like "privileges required" that are used to do the calculation. In most cases that won't matter, but I imagine people would rather get some "official" ruling on them. There's also the issue that people want to just use someone's calculation instead of doing it themselves; nobody wants to fight over that stuff.

Your question about versioning & clarity also raises a few related issues (which I think can also be resolved):
1. I posted about "version 3", but I really meant the "latest version in the 3 series" which is actually 3.1. We really don't want to be changing the text every time a new CVSS edition comes out. Using "most recent published" should resolve it.
2. When I say “CVSS scores” I really just mean the *base* score. NVD does the same thing, they only use base scares (see https://nvd.nist.gov/vuln-metrics/cvss ). The “temporal score” varies by time, and the “environmental score” varies by environment, so neither are useful for our purposes. Most people just look at NVD score (and thus "do what was intended" anyway), but that should be clearer than it currently is.

The simple solution is to let people use the vulnerability's base CVSS value as (1) published in a widely-used vulnerability database with the most-recent version of CVSS for that vulnerability, or (2) calculated themselves using the current version of CVSS (with the calculation publicly revealed if the vulnerability is publicly known). That means projects might not always use the current version of CVSS, but that's okay. Over time the old values will become irrelevant (through aging out), without requiring a lot of unnecessary work.

CVSS isn't a be-all/end--all. I think of it more as a simple heuristic. Ideally projects would fix all vulnerabilities, but there are some "vulnerabilities" which are very low risk & in some cases it's debatable that they even *are* vulnerabilities. We're simply using CVSS as a mechanism to let projects focus on the "vulnerabilities that are more likely to matter".

--- David A. Wheeler

David A. Wheeler
 

Here's a pull request that tries to resolve the CVSS issues:
https://github.com/coreinfrastructure/best-practices-badge/pull/1367

It's more text than I'd like, but my goal was to be 100% clear.
For example, instead of "medium or high" it was changed to
"medium or higher" (because we REALLY want critical vulnerabilities fixed!).
Below is the (simplified) diff of criterion vulnerabilities_fixed_60_days.

My goal was to be future-proof and precise.
CVSS is not a perfect system, but we just want a way to let projects
lower the priority of low-importance vulnerabilities, and for task that I
think it does okay.

Comments welcome.

--- David A. Wheeler

=============================================

There MUST be no unpatched vulnerabilities of medium
- or high severity that have been publicly known for more
+ or higher severity that have been publicly known for more
than 60 days.

(In details)
- A vulnerability
- is medium to high severity if its
- <a href="https://nvd.nist.gov/cvss.cfm">CVSS
- 2.0</a> base score is 4 or higher.
+ A vulnerability is considered medium or higher severity if its <a
+ href="https://www.first.org/cvss/"
+ >Common Vulnerability Scoring System (CVSS)</a>
+ base qualitative score is medium or higher.
+ In CVSS versions 2.0 through 3.1, this is
+ equivalent to a CVSS score of 4.0 or higher.
+ Projects may use the CVSS score
+ as published in a widely-used vulnerability database (such as the
+ <a href="https://nvd.nist.gov">National Vulnerability Database</a>)
+ using the most-recent version of CVSS reported in that database.
+ Projects may instead calculate the severity
+ themselves using the latest version of
+ <a href="https://www.first.org/cvss/">CVSS</a> at the time of
+ the vulnerability disclosure,
+ if the calculation inputs are publicly revealed once
+ the vulnerability is publicly known.