Re: CVE ID Syntax Vote - results and next steps

[<Kent_Landfield@McAfee.com>]

Not sure if you just wish to be confrontational or just not looking at realities.  We have exceeded 10,000 vulnerabilities as a community. If CVE did not wish to report them all that does not change the situation.  We can all decide to re-scope CVE so we will never get over 10K by putting on the brakes in June when we get to 5K. What service does that do the community?  Not reporting an issue just means that we as a community are deaf, dumb and blind to that attack vector.  

There are funding, process and resource issues as to why we decided to scope down and focus only on a set of products. I never have believed that was right for the community but you have to work within what you have. The value of CVE is in reporting vulnerabilities to the community.  What we are forced to do today because of the constraints given does not mean we should be shortsighted with the potential needs of the future.  

So what you are arguing about is a single digit?  Really?  By extending it a 'single' digit you can most likely get the votes to pass it. A single digit… 

As for being selfish…  you are sadly mistaken. This is a real cost to the entire community, All vendors and organizations that use CVE internally, they too will have to go through the same QA.  This is not selfish, this is a reflection of the costs that ALL in the community are going to have to deal with. We want CVE adoption to be universal.  I am voting for those that have to adopt this in their products, customers that have to use it in their  internal security databases and systems.  Selfish I am not, I am looking at the ENTIRE impact of this on the community not on a single database.

My opinion is more than clear. I am hoping we will hear from others as well.  We know where you stand as well.

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

From: security curmudgeon <jericho@attrition.org>
Date: Thursday, April 18, 2013 2:30 PM
To: Kent Landfield <Kent_Landfield@McAfee.com>
Cc: "cve-editorial-board-list@lists.mitre.org" <cve-editorial-board-list@lists.mitre.org>
Subject: Re: CVE ID Syntax Vote - results and next steps

On Thu, 18 Apr 2013, Kent_Landfield@McAfee.com wrote:

: History serves up lessons that if you ignore them, you are asking for

: problems. When we started CVE in 1999 we felt there was no way it was

: possible to get to 10,000 CVEs a year.  That was the consensus then of

: all involved.  Fast forward a decade and we had run into the problem.  

I would not have been among those for sure. Back then, many of us realized

that 10k a year was possible, even if improbable.

: Today we are in a position where we have to correct the

: problem/situation we once thought inconceivable.  Do we really want to

: be shortsighted and ignore what we have actively seen occur to us in the

: past?  Absurd it is not, conservative, yes.

Your comment is factually incorrect. As of this day, CVE has not hit

10,000 vulnerabilities in a year. We have not "actively seen [this] occur

to us in the past", or present.

CVE is almost 14 years old, and has not hit 10k in a given year. Even with

the creation of CNAs, increased awareness, a push for researchers to

obtain an ID before disclosure, educating vendors to do it, and pressing

Kurt Siefried into a CVE-labor camp, still no 10k.

Yes, there is a chance we will hit 10k, possibly this year. But I also

remind you of the board's decision to actually stop pursuing the goal of

issuing a CVE to all disclosed vulnerabilities. Instead of making an effor

to assign more, CVE has collectively decided to back off that, and only

focus on the 'priority' vendors and sources. This shift in CVE is part of

what I mentioned before in those quotes, that a 1MIL+ CVE-a-year is a

radically different CVE than we have today. It would fundamentally shift

the purpose of the effort, not to mention the way it operates.

: As a vendor that has to deal with this across many different product

: lines, many different research and development databases across

: differing security technologies, we really do not want to find ourselves

: in this situation again.  This type of effort, changing a format that is

And this speaks to my point about selfish desires. You are making this

decision based on YOUR company, and YOUR development cycles that will be

used to change the scheme internally. This is not voting in the interest

of the community at all.

: or internal development or research resources has to be verified that it

: will not have an issue with the format change.  This is not like having

: one database, this is very extensive and the costs to make this change

: and validate it will be too.

I will be the community advocate on this response:

So what? Your problem, not mine.

: This impacts the community as a whole. This change will cause

: problems in areas we have no idea of today.

This argument is just as valid for voting against 'B' as it is against

'A'.