Re: Rough Drafts of CVE Counting Documents

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