RE: Rough Drafts of CVE Counting Documents

["Coffin, Chris" <ccoffin@mitre.org>]

Kurt,

Thanks a ton for the feedback... I very much appreciate it.

FYI... I hadn't taken into account Pascal's feedback in the comments 
below, but I added Pascal's definition of vulnerability as I think it 
works very well. Thanks Pascal!


> Could we add "typically requires" instead?

I added some text to the definition. Take a look and let me know if 
this works for you.

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

I would be concerned with putting strict verification requirements at 
the inclusion stage. For vendor CNAs, I think they will most likely do 
some or all of this, and maybe we can insert this language here that 
mentions it. However, there may also be other CNAs reading this 
decision who are not the vendor or maintainer of the product/code and 
assembling this data or getting it from the vendor could take time if 
it happens at all. My feeling is that the inclusion steps should 
emphasize speed in assigning CVE IDs as opposed to getting things 
perfect up front. If a mistake is made, it can be cleaned up after the 
fact. Thoughts?

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

Similar to the above, for a vendor CNA following this it is probably 
not much of an issue. For a CNA who is not the vendor or maintainer, 
such as yourself, this becomes more important obviously. I think you 
have said yourself that you get lots of garbage already. In my mind, 
"demonstrated" means can the requester properly describe the 
vulnerability and explain what it's impact is. I think if we force the 
requester to provide a PoC we may be asking for too much at this stage. 
As the bolded text states, this one is about trusting the researcher in 
their claim to a certain extent.

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

Are you saying that we should soften language now to start including 
room for CVEs issues that will only be released to a limited group of 
users? I know we have had these discussions in the recent past, but my 
understanding was that we would wait to make this kind of change until 
CVE actually brought on some of these domains where this issue will 
come up.

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

This is a really great point! This is another area that I haven't 
really put much thought into and I don't think anyone else on the board 
has brought up in the recent past. Outside of the "sort of" similar 
idea of SaaS (and possibly other xaaS), I imagine there could be IT 
products (e.g., appliances and such) produced now or in the future that 
could fall into this category. Similar to the above comments though, 
should we account for this in the current rules, or should we wait 
until presented with this problem such as when we bring on the medical 
devices domain?

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

One thing that I noticed is that the decision language did not direct 
the CNA to defer the report to the appropriate CNA in the case of a 
shared codebase that doesn't apply to the receiving CNA (i.e., the CNA 
following the decisions based on the report). Are you looking for more 
process explanation in this case or maybe more examples? If you have 
anything specific please feel free to pass along.


Chris


From: Kurt Seifried [mailto:kseifried@redhat.com] 
Sent: Wednesday, August 24, 2016 3:55 PM
To: Coffin, Chris <ccoffin@mitre.org>
Cc: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: 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 
<mailto: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: mailto:owner-cve-editorial-board-list@lists.mitre.org 
[mailto: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 
<mailto: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: mailto:secalert@redhat.com

Attachment: CVE Counting for CNAs_v0.5.docx
Description: CVE Counting for CNAs_v0.5.docx