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

RE: Required information for CVE entry submissions

Responses inline



Regards, 


Beverly M Finch, PMP
PSIRT Program Manager
Product Security Office

7001 Development Drive
Office 3N-C1
Morrisville, NC  27560

+1 919 294 5873
beverlyfinch@lenovo.com



Lenovo.com 
Twitter | Facebook | Instagram | Blogs | Forums







-----Original Message-----
From: Pascal Meunier [mailto:pmeunier@cerias.purdue.edu] 
Sent: Wednesday, September 20, 2017 12:42 PM
To: Beverly Finch; Adinolfi, Daniel R; cve-editorial-board-list
Subject: Re: Required information for CVE entry submissions

Thanks Beverly that helps but I'm still having problems with these 
proposals.  If you don't provide all these details ahead of your 
disclosure then you are open to having CVE IDs in use at large while 
the CVE record is unavailable.  This shouldn't happen.  It's even 
possible for the CVE record to never be available from MITRE as a CNA 
is holding on to information because some required bit hasn't been 
filled.

>>CNA/vendor/publisher should include all details at time of their 
>>disclosure and immediately submit the required information to MITRE 
>>to publish on their site.  MITRE is measuring this and providing it 
>>in quarterly report to the CNAs.  I believe MITRE is also measuring 
>>CVE issues like you mention where there is incomplete information.  I 
>>believe we must assume that CNAs/vendors don't want to disclose all 
>>the details to MITRE or anyone else until they have gone public with 
>>the information themselves.

i) First problem is latency and the use of CVE IDs in advisories and 
publications without the record being available for reference from 
MITRE at that time, only some time after the CNA finishes filling in 
the fields.  I believe this removes value from CVEs for both users of 
CVE information and for publishers of information.

It seems to me that would also put the first people to respond to 
advisories or a publication of some sort at a disadvantage, or it might 
encourage delayed responses or slow response processes.  These are not 
conducive to improved security.  

>>I agree with you and we've suffered as a result when opening issues 
>>to our development teams.  They frequently complain 'not enough 
>>information' or we hold opening the ticket because it's not published 
>>on MITRE site yet.  Again, MITRE is measuring and reporting back to 
>>the CNAs.  


ii) Second problem is enforcement and responsibility.  How is the 
requirement enforced, is that by withholding the release of CVE 
records?  Who's being punished?  Once someone got a CVE identifier from 
a CNA or MITRE and started using it in advisories and publications, 
whose responsibility is it to complete the required information, the 
CNA (or MITRE if it acted as CNA) or the software developer?  From the 
point of view of a software developer, if I need to come back after 
having had my identifier and publishing my info, will I bother or will 
I have the time?  If not, some may ask why bother with the CVE anyway? 
If it is the responsibility of the CNA, how will the CNA notice and act 
upon this?  This proposed 2-phase process, due to the requirement for 
information only available after publication, is cumbersome.

>>The CNA should have an established process whereby they assign CVE, 
>>track publish date and submit CVE details to MITRE immediately after 
>>disclosure.

I propose that IDs should be given out only when the release of the CVE 
record can not be blocked or unduly delayed.  It would make most sense 
to extract all strictly required information from the requester of a 
CVE ID at the time of the request.  

>>A major value of CVE is the ability to identify/distinguish one vuln 
>>from another so it's important to assign them earlier rather than 
>>later.  I think the issue is between vendor disclosure and 
>>availability on MITRE site.

The second phase and further updates can greatly improve CVE quality 
but requiring too much is conducive to phantom RESERVED records used at 
large but not available as proper CVE records.

Pascal


On Wed, 2017-09-20 at 15:36 +0000, Beverly Finch wrote:
> CNA can assign CVE internally and would only submit the required 
> information after it's been made public.
> The intention is not to provide all these details ahead of your 
> public 
> disclosure.
> 
> 
> 
> Regards,
> 
> 
> Beverly M Finch, PMP
> PSIRT Program Manager
> Product Security Office
> 
> 7001 Development Drive
> Office 3N-C1
> Morrisville, NC  27560
> 
> +1 919 294 5873
> beverlyfinch@lenovo.com
> 
> 
> 
> Lenovo.com
> Twitter | Facebook | Instagram | Blogs | Forums
> 
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cv 
> e-editorial-board-list@lists.mitre.org] On Behalf Of Pascal Meunier
> Sent: Wednesday, September 20, 2017 11:29 AM
> To: Adinolfi, Daniel R; cve-editorial-board-list
> Subject: Re: Required information for CVE entry submissions
> 
> In ref to REFERENCES, URLs, this is problematic because we'd like 
> CVEs 
> to be used in all public information.  Or at least, it's my position 
> that this would be the ideal case.  That requires creating a CVE 
> before it's made public.  Requiring public information to create a 
> CVE 
> makes this impossible.
> 
> Likewise, PUBLICATION DATE is problematic because we'd like to be 
> able 
> to assign CVEs before publication.  If it's not known for sure then 
> you'd have to accept an estimate, which may be incorrect and never 
> get 
> corrected.  If a future date is estimated it should be identified as 
> such, e.g., by containing something like (ETP, Estimated Time of
> Publication)
> 
> Likewise, Issue #26 "The CVE List cannot be the first point of 
> publication for any information" should be rejected as long as 
> provenance is identified.  Referencing a CVE in a publication is not 
> as useful if the matching CVE record isn't available.  Alternatively, 
> enforcing that rule by doing simultaneous publication would require 
> close coordination for little benefit, all around this rule seems 
> more 
> trouble than it's worth.
> 
> For DESCRIPTION I vehemently disagree with the assertion that "all 
> the 
> same information would be available in the required fields".  The 
> required information is insufficient to distinguish separate 
> instances 
> of similar flaws in different sections of the code, which could 
> result 
> in a bunch of CVEs "similar to CVE-wxyz but different", especially if 
> discovered at different times -- there would be no basis on which to 
> differentiate between the CVEs, and to identify the actual code flaws.
>  Please keep DESCRIPTION required.
> 
> I would like to suggest an additional optional but strongly desired 
> fields that would identify source code location areas that enable the 
> flaw, or commit IDs for any bug fixes.
> 
> Pascal
> 
> On Wed, 2017-09-13 at 15:15 +0000, Adinolfi, Daniel R wrote:
> > Folks,
> > 
> > I wanted to summarize the proposed changes to the CNA Rules that 
> > affect what information will be required when submitting a request 
> > to populate a CVE entry in the CVE List. In other words, what 
> > should 
> > the required minimal CVE entry request look like? I want to make 
> > sure the community finds these useful and minimally sufficient.
> > 
> > None of these are set in stone, yet, so any feedback is appreciated.
> > 
> > Currently, the CNA Rules require:
> > CVEID
> > PRODUCT, including vendor/project
> > VERSION, describing what versions are and are not affected 
> > PROBLEMTYPE, a free-form bit of data, though some use CWEs here 
> > REFERENCES, URLs pointing to public information about the 
> > vulnerability that includes all the information that may be in the 
> > CVE entry DESCRIPTION, a human-readable description of the 
> > vulnerability
> > 
> > The related JSON minimum schema is here:
> > <https://github.com/CVEProject/automation-working-group/blob/master
> > /c
> > ve_json_schema/CVE_JSON_4.0_min.schema>
> > and it has a few extra bits of meta-information for those using 
> > JSON.
> > 
> > To summarize the proposed changes, the following information would 
> > be required under the proposals:
> > 
> > CVEID
> > PRODUCT
> > VERSION
> > PROBLEM TYPE
> > PUBLICATION DATE (of the vulnerability information becoming public; 
> > or a timeline of specific events related to the vulnerability being 
> > made
> > public) ASSIGNING CNA (or chain of assigning CNAs if there is a 
> > Sub-CNA under a Root doing the assignment) IMPACT
> > 
> > There is also a proposal to remove REFERENCES from required 
> > information if all the required information can be included in the 
> > description. There is a related discussion as to whether the CVE 
> > List can include vulnerability information not found anywhere else, 
> > acting as a first publication point. 
> > <https://github.com/CVEProject/docs/i
> > ss
> > ues/26>
> > 
> > DESCRIPTION would also become optional, the argument being that all 
> > the same information would be available in the required fields.
> > 
> > We do not currently have a proposed categorization or taxonomy of 
> > "IMPACT".
> > 
> > Note, as one can see in the full JSON v4 description <https://githu 
> > b.
> > com/CVEProject/automation-working-
> > group/blob/master/cve_json_schema/DRAFT-JSON-file-format-v4.md>,
> > there is a lot more information that one can submit to CVE, and 
> > that 
> > information can be submitted whether or not it is included in a 
> > required field, so this minimum does not limit what can be included 
> > optionally. Also, individual CNAs can choose to make additional 
> > fields required if they wish. But if a CVE request is submitted 
> > with 
> > only the required fields, it will be accepted and considered 
> > "complete".
> > 
> > We are working on the CNA Rules revision for another two and a half 
> > weeks. I hope to have this key set of changes finalized by then.
> > Please take a moment to consider these and let us know if you 
> > believe it will work or not. Though it would be useful, you don't 
> > need to discuss the formatting or content of these fields. Right 
> > now, I want to focus on only if the information is required or not.
> > 
> > Thanks.
> > 
> > -Dan
> > _________________________
> > Daniel Adinolfi, CISSP
> > Lead Cybersecurity Engineer, The MITRE Corporation CVE Numbering 
> > Authority (CNA) Coordinator
> > Email: <dadinolfi@mitre.org>  Phone: 781-271-5774
> > 
> > 
> 
>
Page Last Updated or Reviewed: September 21, 2017