Re: Required information for CVE entry submissions

[Pascal Meunier <pmeunier@cerias.purdue.edu>]

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/iss
> 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://github.
> 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
> 
>