RE: CVE for hosted services

[jericho <jericho@attrition.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?

It is definitely useful to some organizations. I could only speculate 
on 
the number.

: > 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?

I am saying that CVE vs CAN was two prefixes for the same fundamental 
item 
being tracked (end-user software and hardware vulnerabilities). It was 
useful in the very early years, but became obsolete. MITRE eventually 
agreed with several people that pointed it out and dropped the CAN 
prefix.

The current discussion is about mixing site-specific issues with the 
current scope of CVE, which I feel would be a horrible choice. To me, 
it 
doesn't matter if it stays among the CVE project/team and uses a 
different 
prefix, or MITRE spins it off to a different project with a different 
prefix. As long as it is a different prefix, I think that is the wise 
move.

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

In the context of CVE, the early CAN model was useful because of the 
unvalidated reports early on *and having the board provide input, 
cross-refs, and vote on each entry.

If the new site-specific intiative uses that type of model, even if the 
input comes from within MITRE, that might be beneficial yes.

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

No. Medical devices and IoT falls within the scope of CVE, and always 
have. Just that the historical medical entries are pretty rare compared 
to 
the overall volume. I believe the first 'medical' CVE is 2001-1594, and 
a 
loose query in VulnDB says there are ~ 175 CVEs assigned to medical 
equipment or software.

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

That isn't a viable solution in my opinion. It still mixes the two 
fundamental ideas (site specific vs end-user software), and will be 
overlooked come yearly "let's generate stats on this data we don't 
understand". Companies do a horrible job on that as is, without the 
confusion that designated blocks introduces. 

I hate to even suggest it because I still don't want to see them mixed, 
but using a six digit ID scheme for them would be better than randomly 
reserved blocks. So 4 - 5 digits are the base, 6 would be 
site-specific, 
and 7 would be the DWF hierarchy.

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

Not sure how you can say that. If we have a new project (e.g. CSE), 
then 
all site-specific vulns under it would be distinct and NOT mixed in 
with 
CVE when people generate statistics. People don't mix CWE or CME with 
CVE 
when generating these stats. No reason to think they would mix a new 
one. 
(By that I mean truly mix, not include two or more projects in a single 
report with separate stats).

: 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 

Agreed. Everyone who supports MITRE tracking this should explain why 
they, 
or their org, would be interested in it. Seeing how each org would 
potentially use that data would help gauge interest and further guide 
the 
process as needed. For someone like CERT, that is an obvious use-case 
given the external reports they receive. But for some other board 
members, 
definitely curious.

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

There is potential overlap too. For example, we hear that MITREbook, 
the 
great new social platform has a vuln. There is a CSE assignment to 
cover 
it. Later, they publish a blog that says yes it was a vulnerability, 
but 
then they attribute it to KenLib, a third-party component that is open 
source. At that point you would have a CSE and could issue a CVE. 
Cross-referncing them would make for interesting long-term stats.

: - 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?

This is tricky. It clearly gets a CVE due to scope. I can argue either 
way 
if it would get a CSE. On one hand, it caused a vulnerability that 
impacted users of a given application / site / service. On the other 
hand, 
do you want to issue a CVE *and* CSE for every single OpenSSL vuln? 
What 
about the tons of other library vulns that invariably impact services?

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

Are you thinking Amazon AWS as an example?

: - The affected software is a hybrid with some client code and some 
hosted code. It isn't clear which is affected in each case.

We already deal with these. OSVDB / VulnDB calls them 'hybrid' issues 
and 
deals with them on a case-by-case basis. For example, a consumer app 
that 
lets you pull back too much data from a service via their API. Is the 
vuln 
in the consumer app? Not really, because you could do the same outside 
of 
it. The flaw is in the API for not limiting that data in some way. 
Fixing 
it on the server side closes the hole w/o the need for client update. 
In 
that case, it is site-specific and skipped. But in that same scenario, 
if 
the fix required an application update AND an API update to fix it, it 
is 
hybrid and covered. The "where is the fix" rule has seemed to work well.

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

First, if there is no way to change the code, then it isn't a 
site-specific or service vulnerability. If Internet connected, and you 
can 
attack thousands of customers that own that device, that is a classic 
end-user vulnerability that isn't much different than hardcoded default 
credenetials (where the user can't change them and fix the vuln). If 
the 
device has an update mechanism, which a large majority of IoT devices 
have, then this argument is largely invalid.

.b