RE: CVE for hosted services

["Williams, Ken" <Ken.Williams@ca.com>]

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.