[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rough Drafts of CVE Counting Documents

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

Can INC2 (Vendor acknowledgement) be expanded to include actual verification through a proof of concept/reproducer for example, or via source code examination?

INC3.1 "demonstrated" does this mean we need a reproducer? 

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. 

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

CNT4: I'd like to better define the embedded code situation, e.g. libxml/gzip situations (bits of those are everywhere!).











On Wed, Aug 24, 2016 at 2:19 PM, Coffin, Chris <ccoffin@mitre.org> wrote:

All,

 

Attached is a new version of the CVE Counting for CNAs document. I  have made some changes to the counting decisions as well as provided some clarifications in certain decisions based on feedback from the CVE Team.

 

Chris

 

From: owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of Coffin, Chris
Sent: Monday, July 25, 2016 5:03 PM
To: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: Rough Drafts of CVE Counting Documents

 

All,

 

Sorry for the delay, these were supposed to go out last week.

 

Attached is the latest marked up version of the Simplified Counting Rules, as well as the promised very rough version of a new CVE Vulnerability Counting for CNAs document. There is still plenty of work to be done on this new document, but the main focus so far has been to develop the decision trees. The included decision trees are meant to replace the older decision trees found at https://github.com/CVEProject/docs/blob/gh-pages/cna/application-guidance.md.

 

Current thinking is that the introduction of the “independently fixable” concept obsoletes many of the older counting decisions, but we’d be interested to hear others opinions on this. Also, the inclusion rules actually grew a bit, but these all seem to be fairly straightforward.

 

The Report Type decision is something that came up during internal discussions and is probably new to everyone. An earlier version of the doc didn’t have good coverage for how to count when independently fixable resulted in No or Not Sure. The Report Type allows for common reporting cases to be handled in a somewhat uniform way. The idea is to handle the most common reports and the recommended counting action for each. We are definitely interested in hearing others thoughts on this entire counting decision, as well as the common reports and actions that are defined.

 

Like I said before, this is a very early version so I am open to any and all feedback. Thanks in advance!

 

Chris Coffin

The CVE Team




--

--
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
Page Last Updated or Reviewed: August 26, 2016