RE: CVE for hosted services

Or we could keep the CVE prefix and just assign a publicly defined
block to online services, as SSN used to do with mapping the
leading 3 digits to geographical area, or as CC companies do with
the leading 6 digits for the IIN/BIN.

Using the CVE prefix for all vulnerabilities, both in software and
in services, doesn't have to be a problem.  It makes sense logically
because it identifies the number as belonging to a vulnerability.

Regards,
kw

> -----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, February 24, 2017 4:30 PM
> To: Coffin, Chris <ccoffin@mitre.org>
> Cc: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
> Subject: RE: CVE for hosted services
> Importance: High
>
> I will say this with all of the virtual emphasis I possibly can. I won't
> argue if MITRE tracking online services in a CVE-style capacity is the
> right or wrong thing to do today. But I will say that if you do this...
>
> Do NOT, uner any cicumstance, use 'CVE' as part of the ID scheme. There is
> absolutely no logical or beneficial reason to do so.
>
> - CVE supported two prefix schemes for a decade (CVE and CAN).
> - Many orgs will not want to track online services, and mixing them will
>   make that very painful for 'coverage [metrics|percentage]' etc.
> - Some orgs may be more interested in cloud/service offering tracking
>   (e.g. companies that exist for cloudy services themselves)
> - For the countless vuln tourists (both individual and companies) that do
>   yearly stats entirely based on CVE and not understanding CVE at all,
>   this will forever make ALL stats they generate entirely worthless. I
>   mean, they are already worthless, but this will make it more so.
> - Did I mention there is no logical reason to mix them under a unified CVE
>   identifier? =)
>
> I have been an outspoken critic of MITRE and CVE for a long time. I have
> spent a LOT more of that time trying to help via the board and behind the
> scenes. If MITRE opts to mix and not use diffferent prefix schemes, I
> fully believe that will be the biggest mistake MITRE has ever made in the
> 17+ years of maintaining the CVE project.
>
> .b
>
> p.s. This is coming from one of the few people who were strenously against
> the CNA/CVE prefix split and put significant pressure on MITRE to unify
> that.
>
>
> On Fri, 24 Feb 2017, Coffin, Chris wrote:
>
> : The CVE Team has discussed the inclusion of hosted service
> : vulnerabilities within the CVE program on multiple occasions in the
> : past. However, a decision was never made on how to proceed. The CVE
> : Board call on Feb 22 included a very informative and useful discussion
> : regarding this topic, and we feel this topic needs to move forward.
> : Based on Harold's valid use case, input from other Board members, and
> : the fact that more and more software is being offered via hosted
> : services, the CVE Team believes that these vulnerabilities should be
> : assigned CVE IDs and we have no objections in supporting these under the
> : CVE program.
> :
> : We believe that there are still decisions to be made on what kinds of
> : use cases should be supported, but these can continue to be identified
> : and discussed on the CVE Board list. Once we have agreement on a valid
> : set of use cases, the CVE Team and Board can decide on any needed rules
> : and guidelines. At that point, we believe that the best option would be
> : to pilot the idea through one or more of our existing CNAs who also
> : maintain hosted services. If anyone has any additional suggestions or
> : comments on a way forward then please offer them up.
> :
> : To answer the specific questions regarding the determination of risk
> : based on CVE, we agree with Art that CVE is the first step in the
> : process and should only be responsible for starting the conversation
> : (i.e., naming the thing). Other organizations can add additional value
> : on top of this, such as risk scores, mitigations, etc.