[Servercert-wg] Ballot SC39: Definition of Critical Vulnerability

Tue Dec 15 17:27:23 UTC 2020

Ryan,

Sorry I didn't have time to address this earlier.

Some observations on the points below. Under the old definitions, over 
2020, there were 3024 vulnerabilities [*] disclosed at CVSS 2.0 level 
7.0 or higher; under CVSS 3.0, there would be 7385 High Level or 
Critical levels to address (ie, >= 7.0). This represents a significant 
increase in the number of vulnerabilities which would need  to be 
patched in the 96 hour window.

Now - I know that not all of those vulnerabilities would actually be 
present in many CA systems, but it's reasonable to conclude that 
maintaining the 7.0 threshold for CVSS 3.0 would probably double the 
patching workload on CAs. That is not necessarily a Bad Thing: but it is 
something which CAs would need to consider in adopting/rejecting this 
ballot.

In order to keep the number of vulnerabilities (more or less) the same, 
the equivalent CVSS v3.0 threshold would be 8.8: in 2020, there were 
3065 such vulnerabilities disclosed. Perhaps that would be the 
appropriate level to set the trigger for 96 hour patching? Agreed, it's 
diverging from what the CVSS 3.0 ranking calls "Critical", but should 
that be a significant concern? At least it would cover everything which 
is considered "Critical" by the rest of the world, and also includes a 
lot of "this is very, very serious" issues.

Of course, to make the thresholding neutral we could adjust it to be 
CVSS 2.0 >= 7.0; my concern is that there are several CVSS 3.0 
vulnerabilities which are rated critical (>= 9.0) which have a CVSS 2.0 
of < 7.0. In other words, we would allow what the world considers a 
"patch now" scenario to be a "patch within 6 months" one. It's not a 
step _backwards_, but it does seem like a missed opportunity to step 
forwards.

At the very least - can we agree that changing the URL to point to the 
correct definitions is uncontroversial?

 From a structural standpoint: I agree wholeheartedly that a markedly 
improved remediation strategy, aligning with high quality threat 
modelling, is what we should be aiming for (and it's why NetSec has a 
threat modelling thread in its deliberations). That will need to form 
the bases of future ballots.

Just some thoughts,

Neil

[*] My capture of the NVD was done a week or so ago - so it'll be a bit 
out of date.

On 15/12/2020 16:53, Ryan Sleevi wrote:
> Hi Neil,
>
> Just capturing on the list some of the discussion.
>
> One of the significant changes here is this meaningfully reduces the 
> security of the ecosystem, by moving the window in which CAs need to 
> patch from CVSS scores of 7.0 to the much more rarer 9.0. During the 
> call, it was highlighted that CVSS 1.0 only had three levels (Low, 
> Medium, and High), with the CA/B Forum determining that any thing at 
> High or above (7.0+) was, in fact, Critical for CA systems. This new 
> ballot reduces security, although perhaps unintentionally, by 
> determining that the only Critical bugs to CA systems are those that 
> CVSS 3.0, which has four levels (Low, Medium, High, Critical), deems 
> as critical; that is, 9.0+
>
> As discussed, and obviously captured above, this seems like a step 
> backwards for security, and there did not seem to be a compelling 
> reason to allow CAs an additional 6+ months of patch time simply to 
> align the terminology. For example, this ballot could redefine 
> "Critical Vulnerability" to "High-Risk Vulnerability", in order to 
> align terminology. Alternatively, we could continue with acknowledging 
> that Critical Vulnerabilities are, due to CAs special nature, anything 
> that is High or above.
>
> There was some suggestion that 96 hours is too short a window to 
> address these events, but we also discussed how, for better or worse, 
> the NCSSRs afford significant, non-transparent leeway to CAs to ignore 
> such patch requirements, by simply requiring CAs either "Create and 
> implement a plan to mitigate the Critical Vulnerability" (giving no 
> such timeline to remediation - 4.f.ii) or "Document that the factual 
> basis for the CA's determination that the vulnerability does not 
> require remediation" (with the only requirement being documentation, 
> and no consideration whatsoever if the factual basis was wrong or the 
> CA's determination was incorrect - 4.f.iii).
>
> These are such significant "get out of responsibility free" cards that 
> it does not seem to justify increasing the barrier to patching. Recall 
> that, in the absence of something being deemed a Critical 
> Vulnerability, CAs are afforded six months to either patch, or 
> determine that they don't want to patch (1.l).
>
> Thus, it seems the definition is perhaps the least important of the 
> things to change, given the structural security issues with the NCSSRs 
> of the lack of transparency and accountability required of CAs in 
> keeping their systems secure. However, if it's urgent to correct this 
> editorial issue, rather than the underlying security issues, it seems 
> best to ensure this change is merely editorial in nature, by 
> continuing to define those events that are critical --for CAs-- as 
> those that are 7.0 or higher. We know that CVSS scores provide a 
> baseline metric, but that specific environments and use cases can 
> either mitigate (as the NCSSRs seem to give significant deference to) 
> or amplify (as we know from CA incidents in the past) those scores. As 
> such, it doesn't seem necessary or desirable to further relax 
> requirements on CAs' need to maintain a secure-by-default posture.
>
> On Wed, Dec 9, 2020 at 5:44 AM Neil Dunbar via Servercert-wg 
> <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org>> wrote:
>
>     This begins the discussion period for Ballot SC39: Definition of
>     Critical Vulnerability
>
>
>     The following motion has been proposed by Neil Dunbar of TrustCor and
>     endorsed by Ben Wilson (Mozilla) and Corey Bonnel (DigiCert).
>
>     The NetSec discussion document for this ballot is attached to this
>     email.
>
>     Purpose of Ballot:
>
>     It was brought to the attention of the NetSec Subgroup that the
>     URL in
>     the NCSSRs which points to the definitions of the CVSS security
>     scoring
>     system is no longer the appropriate one; moreover the definition of
>     “Critical Vulnerability” is no longer strictly correct by the
>     definitions currently posted by NIST.
>
>     Definitions of terms should always be consistent, especially when the
>     term is canonically defined by an external body; references should be
>     updated as and when they change on the canonical source.
>
>     -- MOTION BEGINS --
>
>     This ballot modifies the “Network and Certificate System Security
>     Requirements” based on Version 1.5.
>
>     Under the section “Definitions”:
>
>     Remove the current definition:
>
>     Critical Vulnerability: A system vulnerability that has a CVSS
>     score of
>     7.0 or higher according to the NVD or an equivalent to such CVSS
>     rating
>     (see http://nvd.nist.gov/home.cfm <http://nvd.nist.gov/home.cfm>),
>     or as otherwise designated as a
>     Critical Vulnerability by the CA or the CA/Browser Forum.
>     Insert a new definition:
>
>     Critical Vulnerability: A system vulnerability that has a CVSS v3.0
>     score of 9.0 or higher according to the NVD or an equivalent to such
>     CVSS rating (see https://nvd.nist.gov/vuln-metrics/cvss
>     <https://nvd.nist.gov/vuln-metrics/cvss>), or as
>     otherwise designated as a Critical Vulnerability by the CA or the
>     CA/Browser Forum.
>
>     -- MOTION ENDS --
>
>     * WARNING *: USE AT YOUR OWN RISK. THE REDLINE BELOW IS NOT THE
>     OFFICIAL
>     VERSION OF THE CHANGES (CABF Bylaws, Section 2.4(a)):
>
>     A comparison of the changes can be found at:
>
>     https://github.com/cabforum/servercert/compare/8f63128...neildunbar:54c201f
>     <https://github.com/cabforum/servercert/compare/8f63128...neildunbar:54c201f>
>
>     This ballot proposes one Final Maintenance Guideline.
>
>     The procedure for approval of this ballot is as follows:
>
>     Discussion:  (7+ days)
>     Start Time: 2020-12-09 17:00 UTC
>     End Time:  not before 2020-12-16 17:00 UTC
>
>     Vote for approval    (7 days)
>     Start Time: TBD
>     End Time: TBD
>
>     _______________________________________________
>     Servercert-wg mailing list
>     Servercert-wg at cabforum.org <mailto:Servercert-wg at cabforum.org>
>     https://lists.cabforum.org/mailman/listinfo/servercert-wg
>     <https://lists.cabforum.org/mailman/listinfo/servercert-wg>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20201215/fb3b18fb/attachment.html>