Re: Simplified Draft Counting Paper for CVE Editorial Board Review

[Kurt Seifried <kseifried@redhat.com>]

On Wed, Mar 30, 2016 at 3:07 PM, Art Manion <amanion@cert.org> wrote:

On 2016-03-28 12:24, Common Vulnerabilities & Exposures wrote:

> Please find attached to this note a copy of the draft CVE Simplified
> Counting Paper. The paper was originally prepared as an internal piece
> to help the CVE analysts orient their thinking, and we thought that it
> would be useful to share it with the Board as background before the
> Board meeting Wednesday afternoon.

Comments added.

At a high level, even more tolerance for assignment criteria, increased
assignment (by MITRE and/or CNAs) is necessary to keep up with reality.
 A direct affect is an increased need for split/merge/reject cleanup.

Perhaps, vaguely reminiscent of CAN/CVE days, CVE entries get a flag
that can be set by MITRE or a CNA to distinguish "claimed
vulnerabilities, report looks plausible, public reference" from "vendor
acknowledged, or otherwise substantiated claim, public reference."

 - Art

One thing to keep in mind I think is that at a high level CVE stands for "Common Vulnerabilities and Exposures", so obviously it's used to track vulns, but on the other side CVE is also heavily used to track remediation, be it software updates, workarounds, compensating controls, whatever. A good example of this is the search results:

http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=incomplete+fix+for

I'm not sure we need to cover it much beyond the "incomplete fix == another CVE", thoughts/comments?

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