Re: Required information for CVE entry submissions

["Adinolfi, Daniel R" <dadinolfi@mitre.org>]

Dave Waltermire and Harold Booth,

 

Do you agree with Kurt's suggestion that the email quoted in the link below is sufficient for your analysts at NIST to understand and describe the issue as required by NIST's processes?

 

I ask because I have heard from CVE consumers that they rely on the plain-language description since often non-technical people are reading them to get an understanding of how to react to the vulnerability. If it turns out that those people cannot understand the info in the quote, would those people be able to get what they need out of NIST's enriched version of the vulnerability description? For that to be, NIST would have to be able to write the description for them.

 

Thanks.

 

-Dan

 

From: Kurt Seifried <kurt@seifried.org>
Date: Wednesday, September 13, 2017 at 11:31
To: "Adinolfi, Daniel R" <dadinolfi@mitre.org>
Cc: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: Re: Required information for CVE entry submissions

 

One note: in order to supply the full description/information needed so that references are not we will need some basic formatting, at an absolute minimum line breaks. 

 

It's hard to find a good example because the distros emails are private, but a spice thing posted to the distros list was forwarded to a public list, and is a good example of a description that would have all the details:

 

http://lists.gnu.org/archive/html/guix-commits/2017-07/msg00709.html

 

As you can see the quoted email includes code patches, explanation of the issue, etc. Being able to simply drop a CVE into MITRE's database when the embargo lifts and not have to wait for URL's would be advantageous, and as you can see fromt he quoted email above the level of detail is sufficient to understand the issue and even fix it.

 

 

 

 

On Wed, Sep 13, 2017 at 9:15 AM, Adinolfi, Daniel R <dadinolfi@mitre.org> 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/cve_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/issues/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

 

 

 

--

Kurt Seifried
kurt@seifried.org