Re: CVE for hosted services

[jericho <jericho@attrition.org>]

On Mon, 27 Feb 2017, Art Manion wrote:

: On 2017-02-24 17:30, jericho wrote:
: 
: > Do NOT, uner any cicumstance, use 'CVE' as part of the ID scheme. 
There is 
: > absolutely no logical or beneficial reason to do so.
: 
: I had assumed not changing the scheme, but hadn't given it a lot of 
: thought.  Not sure I see a logical or beneficial reason to create a 
: separate "service" scheme, but I'm not necessarily against it either.

Honestly, not sure how you could say that today. To wit...

: > - CVE supported two prefix schemes for a decade (CVE and CAN).
: 
: There was a reason for two schemes, the world changed, and CVE 
evolved. 
: I recall it being cumbersome at best (although it was probably 
: worthwhile in the early years of CVE).

*WAS* a reason... "the world changed"... "CVE evolved"

How can you say all of that, and not see the benefit of using a 
different 
designation. This is a text-book list of reasons to change the prefix.

: What does CAN/CVE mean in this discussion?
: 
: > - 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)
: 
: Seems reasonable.  Is there another way to flag "service" vulns?

Uh... yeah. Virtually no one does it now. And if you find someone that 
does it, and is actively updating it, they do NOT do it in the context 
of 
CVE, VulnDB, XF, BID, CERT, or any other traditional vulnerability 
database.

I say this as someone who helped try to start a 501c3 version to track 
site-specific vulns (originally in the context of outages, then in 
vulns). 
Either we were ahead of the curve, or no one really cares.

In 2017? I know a few care, I understand why we're having this 
conversation. We figured tracking that many years ago was a thing, 
before 
it actually was. So... as someone way ahead of the curve? Track it, all 
day long. Just don't try to do it in the same context of CVE.

: > - 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.
: 
: Counting is broken, for many reasons, which you know better than most.

I do. It might be the single thing that I would EVER accept someone 
else 
calling me an 'expert' on.

: That's as much a function of the nature of vulnerabilities as it is 
the 
: effort anybody puts in to counting.
: 
: Identification, identification, identification.

True, and also 'cute'. Not many of us out there that track vulns to a 
specific degree. A large part of my disconnect from the board over the 
years is that most "do CVE" for their own purposes. I have called that 
out 
too in the past.

To quote your line, which *absolutely* speaks to the point:

: Identification, identification, identification.

But.. that isn't predicated upon combining two radically different 
concepts, into a unified ID scheme. And no one, at all, on this board 
can 
argue they are not radically different concepts (in our world).

17 years of CVE, no site-specific other than when ignorant resaerchers 
requested an ID, got an assignment, and later disclosed a site-specific 
issue. Oh, yeah, sorry... not counting IBM, a CNA, who did it once or 
twice =) (love you Scott!)

17 years of *firm* rules... well, mostly firm until the CVE board 
itself, 
who didn't really read the rules in some cases, suggested such 
site-specific assignments should be a thing... and I had to call out 
MITRE 
on that policy, who specifically said "no site-specific"... and then a 
few 
months later said "well... maybe site-specific"...

My point is, let's just be clear what was hardcoded rules for 
approaching 
two decades... and what was introduced in the last 12 months (not for 
the 
first time)... and now there is a growing discussion of changing the 
scope 
of CVE radically... (and hey, if this is evolution, fine!), but no one 
immediately speaking up to support the stupidly logical evolution of 
"make 
it a new C*E project".

Seriously.

CVE, CWE, CME, CPE, and several other C*E that didn't make it. That is 
the 
MITRE way. While many joke about it, including me, it is actually the 
logical, efficient, and practical way to expand CVE scope.

Anyone who suggests that site-specific vulns should be wrapped into CVE 
rather than being split into a new C*E project? 

This is where I draw the line. Feel free to step over it.

: > - Did I mention there is no logical reason to mix them under a 
unified CVE 
: >   identifier? =)
: 
: You did, but I throw the tautology flag :)

Yeah, the tautology (great word!), was by design, to help ensure that 
no 
one made a quick emotional vote, withouth consider the impact.

.b