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

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.

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.  


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.

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.  

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