Re: Rough Drafts of CVE Counting Documents

[Pascal Meunier <pmeunier@cerias.purdue.edu>]

On 08/24/2016 04:54 PM, Kurt Seifried wrote:
> Some feedback:
>
> A vulnerability in the context of the CVE program, is code that can be
> exploited, resulting in a negative impact to confidentiality, integrity,
> and availability, and that requires a code change to mitigate or 
> address.
>
> Some vulns are internal to the protocol and the only code change that
> "fixes" it is to remove the code/functionality altogether. Could we add
> "typically requires" instead? I'm worried about the intersection of
> software/API vulns that will become increasingly common (more instances 
> of
> this, and people will start looking for them).

Indeed there have been CVEs issued against protocols (e.g., 
CVE-2014-3566 against SSLv3) so that's not even code per se.  However, I 
think "typically" would make the definition impractical for deciding if 
a particular instance is a vulnerability or not.  I suggest:

"A vulnerability in the context of the CVE program, is indicated by code 
that can be exploited, resulting in a negative impact to 
confidentiality, integrity, OR availability, and that requires a coding 
change, specification change or specification deprecation to mitigate or 
address."


> INC4: can we better define public/private? E.g. what if a medical device
> maker plans to use a CVE for an issue that they will then inform ever 
> user
> of directly? Ditto for aerospace/SCADA/etc.

I'm not sure I understand what you would like to have happen.  Limited 
diffusion?  As a customer, I'd be confused to receive a notice referring 
to a CVE I couldn't lookup on a public web site, if that's what you 
meant.  If you meant embargoed issues, doesn't the CVE do that already?

> INC5: "CVE IDs are assigned to products that are customer-controlled or
> customer-installable." what about on premises solutions that are locked
> down? I know many medical devices, high end manufacturing, etc you buy 
> it,
> but you don't touch it, the company tech services it. Ditto for other
> regulated items like elevators (contractually most elevator maintenance
> involves a "if anyone but us touches it, your warranty is totally 
> void").

I'm guessing the intent of INC5 is to determine if a customer can patch 
or mitigate the vulnerability.  However, I would think it is equally 
useful to be able to track if the provider of a managed solution has 
applied the patches or mitigated the vulnerabilities, so I'd be in favor 
of a wider use of CVEs.  This applies regardless of whether it's an open 
source solution someone manages on your behalf or something else like 
firmware or an entirely closed solution.

Pascal