How do we fix this?

["Waltermire, David A. (Fed)" <david.waltermire@nist.gov>]

I have been following the coverage discussion and a couple thoughts strike me.

1) We should be looking at ways to have CNAs provide coverage for areas of products that can be managed by a community. This would involve assigning a CNA as a coordinating body within each identified community. This type of approach could allow for greater scalability overall. The CNAs could each handle CVE assignments using assigned blocks of CVEs or a centralized assignment service to get new CVE ids. This would take some load off of MITRE in the assignment process. We would need to think about how to handle dups in this way. If the CNAs/communities can be partitioned well, they can be made responsible for coordination and de-duping within their scope.

2) MITRE should be focused not on the low-hanging fruit of CVE assignment, but on the areas of coverage that no one else is willing to cover. This could have the effect of improving overall coverage.

Is this something that could work?

It would be good to get some conversation going around re-thinking the processes and mechanisms to allow them to scale. It is clear that the current solution does not accomplish that. I also don't see why we need to wait for MITRE to host a meeting to have this conversation.

Sincerely,
Dave

> -----Original Message-----
> From: owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cve-
> editorial-board-list@lists.mitre.org] On Behalf Of jericho
> Sent: Friday, March 04, 2016 10:56 PM
> To: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
> Subject: Fwd: RE: Delays with numerous CVE-IDs assignments (fwd)
> Importance: High
> 
> Following up on Kurt's mail.
> 
> I'd ask that MITRE respond in a fashion that does not blame the CVE Editorial
> Board for these delays, and outright refusals to issue IDs.
> 
> Please note that MITRE also refused to issue IDs to HTBridge for
> vulnerabilities in OsCommerce, with over 250,000 deployed stores, calling it
> "out of scope", as seen below.
> 
> https://cve.mitre.org/data/board/archives/2012-05/msg00032.html
> 
> This thread clearly shows that the Editorial Board were not given a real choice
> as far as sources, just picking the most important of a tiny subset of sources.
> To wit:
> 
>     As you consider these groups, understand that we are discussing
>     prioritization, not feasibility.  It may be the case that CVE's current
>     practices will need to be changed to provide the stated coverage goals
>     for some of these sources.  We'll address that issue in later email
>     discussions.
> 
>     We'll give some indications as to why we think the second group should
>     be only partially covered below.
> 
> MITRE's failure or unwillingness to issue IDs is not really as "agreed upon with
> the CVE Editorial Board". We were given a few absolutely horrible options to
> pick from, and now you claim to be enforcing what we agreed on? That is
> shifting blame entirely.
> 
> Next, consider that I emailed CVE-assign about a potential duplicate
> assignment on 2016-01-29, received an auto-reply of sorts on 2016-02-02, had
> to poke MITRE again on 2016-03-02 to remind them that the two vendors in
> question were IBM and Apache, both on the primary list. Only then did they
> reply with the details needed to help figure out the confusion in assignment,
> which is still outstanding (but now squarely looking to be on the shoulders of
> the researcher, not MITRE or a CNA).
> 
> Further note that the archives are not updating, magically again, when a
> negative post about the MITRE process appears. It's getting hard to write this
> off as coincidence.
> 
> .b
> 
> 
> -------- Forwarded Message --------
> Subject: RE: Delays with numerous CVE-IDs assignments
> Date: Thu, 18 Feb 2016 23:01:37 +0000
> From: Coffin, Chris <ccoffin@mitre.org>
> CC: CVE ID Requests <cve-assign@mitre.org>
> 
> I am very sorry for the delays in responding to these requests. The CVE team
> is actively working towards providing more timely responses to all CVE-
> related communications.
> 
> The MITRE CVE team has started enforcing the scope and coverage
> requirements previously agreed upon with the CVE Editorial Board, and
> outlined in http://cve.mitre.org/cve/data_sources_product_coverage.html.
> MITRE and the CVE Editorial Board agreed upon this scope several years ago,
> but only recently put it into effect by declining to assign CVE IDs to products
> that are out of scope.  We are currently working with the CVE Editorial Board
> to define a more up to date list of products, as well as a process that would
> allow products to be added or subtracted as appropriate, but do not know
> when this will be completed.
> 
> With the exception of the Exponent CMS issue that was already assigned a
> CVE-ID, the listed advisories affect products that do not appear within our
> published or in-development products lists and would therefore be out of
> scope at this time. If you feel that this is in error and that these products
> should be within the CVE scope, please feel free to provide justification (i.e.,
> large install base, used in many IT shops, etc.). If you do provide justification,
> we will add the products to a list for a later review and possible inclusion
> within the CVE product lists.
> 
> If you have any further questions or concerns, don't hesitate to ask and I am
> happy to help.
> 
> Best regards,
> 
> Chris Coffin
> The CVE Team
> The MITRE Corporation