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

[Ryan Sleevi]

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> 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), 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), 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
>
> 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
> 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/90ca2b3d/attachment-0001.html>