[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: CVE for hosted services

: > 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 
: >  (e.g. companies that exist for cloudy services themselves)
: I think you agree that there are some organizations that would 
: 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 
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 
: am wrong then let me know. I see the older CAN/CVE scheme as quite a 
: different since it was more about having a quality control check and 
: so much about separating different types of vulnerabilities. Am I 
: understanding your bullet correctly, or are you pointing out 
: different here?

I am saying that CVE vs CAN was two prefixes for the same fundamental 
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 

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, 
doesn't matter if it stays among the CVE project/team and uses a 
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 

: If a new C*E effort was to be stood up to handle hosted service 
: specifically, I could see using a CAN/thing model since the use 
: 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 
: 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 
: >   make that very painful for 'coverage [metrics|percentage]' etc.
: > - Some orgs may be more interested in cloud/service offering 
: >  (e.g. companies that exist for cloudy services themselves)
: The Board has discussed expanding CVE into other domains such as 
: devices, Iot, transportation, etc. I believe we would run into the 
: problem in those areas as well right? Maybe this gets solved very 

No. Medical devices and IoT falls within the scope of CVE, and always 
have. Just that the historical medical entries are pretty rare compared 
the overall volume. I believe the first 'medical' CVE is 2001-1594, and 
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 
: 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 
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 
: >  this will forever make ALL stats they generate entirely worthless. 
: >  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 
: 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), 
all site-specific vulns under it would be distinct and NOT mixed in 
CVE when people generate statistics. People don't mix CWE or CME with 
when generating these stats. No reason to think they would mix a new 
(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 
: to change course if and when needed. One of the things I'd like to 
: is a more defined set of use cases to support this effort. There are 
: 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 
or their org, would be interested in it. Seeing how each org would 
potentially use that data would help gauge interest and further guide 
process as needed. For someone like CERT, that is an obvious use-case 
given the external reports they receive. But for some other board 
definitely curious.

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

There is potential overlap too. For example, we hear that MITREbook, 
great new social platform has a vuln. There is a CSE assignment to 
it. Later, they publish a blog that says yes it was a vulnerability, 
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 
: 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 
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 
do you want to issue a CVE *and* CSE for every single OpenSSL vuln? 
about the tons of other library vulns that invariably impact services?

: - The affected software is offered as vendor-hosted only, but the 
: 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 
deals with them on a case-by-case basis. For example, a consumer app 
lets you pull back too much data from a service via their API. Is the 
in the consumer app? Not really, because you could do the same outside 
it. The flaw is in the API for not limiting that data in some way. 
it on the server side closes the hole w/o the need for client update. 
that case, it is site-specific and skipped. But in that same scenario, 
the fix required an application update AND an API update to fix it, it 
hybrid and covered. The "where is the fix" rule has seemed to work well.

: - Many hardware/embedded devices contain software that cannot be 
: by the customer (e.g., Iot and appliances). You could argue that this 
: falls into the category of vendor-hosted/controlled since the 
: 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 
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 
device has an update mechanism, which a large majority of IoT devices 
have, then this argument is largely invalid.


Page Last Updated or Reviewed: February 28, 2017