Re: Required information for CVE entry submissions

["kseifried@redhat.com" <kseifried@redhat.com>]

One thing to keep in mind, I'm not against having descriptions, I think
they serve a useful purpose (pre-written 10 second elevator pitch is a
handy thing to have). I'm just against requiring the CNA create them if
they have enough info, and especially if that info is much more in
depth. As well once we have formatting someone can easily update the CVE
to include a traditional description at the top (or ideally have it auto
generated from the data).

On 2017-09-15 12:41 PM, Adinolfi, Daniel R wrote:
> 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
> <mailto: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 <mailto:dadinolfi@mitre.org>>  Phone:
>     781-271-5774 <tel:(781)%20271-5774>
> 
>      
> 
>      
> 
> 
> 
>  
> 
> -- 
> 
> Kurt Seifried
> kurt@seifried.org <mailto:kurt@seifried.org>
> 

-- 

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@redhat.com