Re: Rough Drafts of CVE Counting Documents

[Kurt Seifried <kseifried@redhat.com>]

On Thu, Aug 25, 2016 at 10:02 AM, Pascal Meunier <pmeunier@cerias.purdue.edu> wrote:

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."

Yours is much better!

 

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?

So Red Hat has 1000+ CVEs we've assigned and are not in the MITRE database. So that bridge has already been crossed. Also I'm assuming the CVE's will be available in the vendor database/website, e.g.:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-2438

We have a page with limited info (mostly because we're not affected =)

https://access.redhat.com/security/cve/cve-2002-2438

A CVE being in the MITRE or any public database is certainly nice to have, especially for high profile issues, but I wouldn't make it a requirement. 

 

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.

Exactly.

 

Pascal

--

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@redhat.com