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

Re: CVE for hosted services

Breaking this off to a separate discussion.

On Mon, 27 Feb 2017, Art Manion wrote:

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

I am truly, and honestly baffled, at this question.

The CNA/CVE abstraction from day one made sense. Historically, it was 
board voting on if an issue warranted a CVE assignment. It was a 
until the board voted, or MITRE made an execute decision. The MITRE/CVE 
site actually showed those votes for a decade.

If there were two schemes, for vuln in software (i.e. the context and 
purpose of CVE), for a *decade*...

How can you possibly ask what CAN/CVE means in this discussion?

Where we're (starting to) debate tracking site-specific vulns, which 
absolutely against CVE policy three weeks ago, that I had to clarify on 
list as some CNAs were "we're selfish, we want to use CVE to track 
site-specific crap".

This on the back of some CNAs voting against logic back during the epic 
renumbering scheme, moving past a four-digit identifier. That years 
MITRE arbitrarily said they were changing again, without a word to the 
board, until the news outlets called them on it.

Seriously Art, there are levels upon levels of history here, about 
changing the scope or numbering scheme of CVE. I can't begin to 
why anyone would casually dismiss that history and then argue, "lets 
in vulns that were against the rules for 17 years" without considering 
abstraction in prefix. 

The CNA/CVE choice, in 1999, made sense. But the board was radically 
different. After the board stopped voting on each CVE entry a year or 
three later, the CNA/CVE designation lost value. Years after that, it 
hitorical academic masturbation at best. OSVDB was the first VDB that 
publicly and loudly told MITRE "we're not playing that game", and 
the CVE/CNA designation. We started using the numeric identifer only, 
because it worked either way. Both schemes took you to the same entry. 
argued with Christey/Coley on that for years, and ultimately we told 
we were dropping it because it made no sense. Back when OSVDB had some 
measure of industry respect, that said something. Within a year, MITRE 
dropped that designation.

So now... we're faced with adding site-specific vulns, that again... 
against policy for 17 years. And you are really questioning the *idea* 
that they get a different designation?

Please. This isn't about CNA/CVE, at all, and it shouldn't be to anyone 
involved in this process.

This is about CVE / CME / CWE / CPE / [other C*E] projects. Spin it 
let it develop and evolve under a separate project [0]. If a CVE vuln 
impacts a site-specific service, they can cross reference. And there is 
some failed precedent here, as IBM has issued CVE IDs to site-specific 
issues in the past (IBM BlueMix junk, that later became a hybrid 
premise / SaaS offering, further convoluting things [1]). It caused 
problems back then, and the mix of site-specific vulns still plagues 
CVE offering to this day. Anyone can request a CVE ID with minimal 
information, and MITRE assigns. Then we find out it is a) not a vuln b) 
site specific or c) both!


[0] This may be problematic to MITRE to figure out funding, be it in 
scope of CVE / 2 other projects under that contract, or spin up a new 
contract and convince DHS to fund it. Don't care. They are a horrible
orgnaization wasting too many tax dollars as is. They can figure out 
to con the government out of more money. That is not the CVE board's 
concern. If you disagree, cite the threads where you challenged them on 
wasteful spending in the past decade. =)
[1] If anyone on the board is surprised by this bit, why? The CVE board 
about directing CVE in the context of the *industry*. Not just YOUR 
organization. I am getting really tired of pointing this out.

Page Last Updated or Reviewed: February 28, 2017