RE: CVE for hosted services

["Coffin, Chris" <ccoffin@mitre.org>]

> I won't argue if MITRE tracking online services in a CVE-style 
> capacity is the right or wrong thing to do today.
> ...
> - Some orgs may be more interested in cloud/service offering tracking
>  (e.g. companies that exist for cloudy services themselves)

I think you agree that there are some organizations that would benefit 
from having a central repository of hosted service security 
vulnerabilities, right? What about bad practice tracking (e.g., poor 
password handling)? Others?

> 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).
> ...
> 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.

Just so I am clear, I think you are saying that having a different 
prefix for CVEs has been tried in the past and wasn't successful. If I 
am wrong then let me know. I see the older CAN/CVE scheme as quite a 
bit different since it was more about having a quality control check 
and not so much about separating different types of vulnerabilities. Am 
I understanding your bullet correctly, or are you pointing out 
something different here?

If a new C*E effort was to be stood up to handle hosted service issues 
specifically, I could see using a CAN/thing model since the use cases, 
issues, and the problem space would in general be less understood and 
agreed upon. In other words, a CAN style model could be used early on 
to ensure quality.

See http://cve.mitre.org/about/faqs.html#cve_list_retire_term_cve for 
more info.
" Why did CVE retire the term CVE "candidates"?
When the CVE Initiative first began in 1999 and vulnerabilities were 
discovered and published less frequently than they are today, CVE 
Identifiers were issued "candidate" or "entry" status, where candidate 
status indicated that the identifier was under review for inclusion on 
the CVE List and entry status indicated that the identifier has been 
formally accepted to the list. CVE Identifiers with candidate status 
used the CAN-prefix (e.g., "CAN-1999-0067"), while CVE Identifiers with 
entry status used the CVE-prefix (e.g., "CVE-1999-0067"). This meant 
that the individual identifier numbers themselves would need to be 
changed once a candidate had been updated to entry status, placing a 
significant burden on the numerous vendors and organizations around the 
world that would in turn need to update their tools and processes to 
accommodate the replacement identifier numbers. This became especially 
burdensome as the volume of vulnerabilities being discovered and added 
to the CVE List increased dramatically each year (CVE Identifiers are 
now added to the CVE website on a daily basis). Therefore, at the 
request of the community, as of 2005 all CVE Identifiers now use the 
CVE-prefix and are immediately usable by the community. While 
references and other supporting information may be updated over time, 
the CVE Identifier number itself does not change once it has been 
assigned to an issue."

> - 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)

The Board has discussed expanding CVE into other domains such as 
medical devices, Iot, transportation, etc. I believe we would run into 
the same problem in those areas as well right? Maybe this gets solved 
very simple by way of a field that labels the domain of the CVE. One of 
those domains could be hosted/site-specific software. Additionally, Ken 
Williams mentioned another approach of using specific blocks to 
separate these CVEs from the others.

> - 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.

I understand your point, but it seems this will always be a problem and 
would never really go away regardless of what direction we take.

> - Did I mention there is no logical reason to mix them under a 
> unified CVE
>  identifier? =)

We are obviously not far along in this discussion and have lots of time 
to change course if and when needed. One of the things I'd like to see 
is a more defined set of use cases to support this effort. There are a 
number of folks on the Board that are interested in pursuing this 
discussion and I want to make sure we facilitate that discussion. I 
would like to hear more specifics regarding why we should NOT include 
them under the CVE umbrella. Does anyone else on the list have concerns 
similar to the general ones listed here? 

Separate from the above responses, here are a few related thoughts that 
come to mind when "separating" these programs (i.e., CVE and some other 
C*E to track hosted vulns). These situations might make assignments 
interesting to say the least. It was mentioned in another reply that 
the difference between products and services will continue to get more 
blurred going forward.

- The affected software is available in both customer-controlled AND 
vendor-hosted versions. Do you create an ID in both programs and assume 
it affects both, just the one that was reported, something else?
- The affected software is offered as vendor-hosted only, but the 
vendor has allowed a limited number of customer-controlled instances. 
Same problems as above.
- The affected software is a hybrid with some client code and some 
hosted code. It isn't clear which is affected in each case.
- Many hardware/embedded devices contain software that cannot be 
changed by the customer (e.g., Iot and appliances). You could argue 
that this falls into the category of vendor-hosted/controlled since the 
customer has no way of changing it.


Chris Coffin
The CVE Team


-----Original Message-----
From: jericho [mailto:jericho@attrition.org] 
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.