Re: CVE ID Syntax Vote - results and next steps

[<Kent_Landfield@McAfee.com>]

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

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 so integral to all we do, is not free.  The level of QA needed is staggering. Each and every one of those areas, be it a customer product 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.  

As for the limitations of MITRE, in the earlier days not all that long ago, they would not have thought they could handle the level of vulnerabilities they are today.  Things change and evolve and their ability to so will as well if there is a need.  The CVE format changes should not be viewed by today's limitations of the implementation of the CVE team. We are not trying to address today's issues as much as we are the future issues.  And there are other pressures on the CVE effort as well with the global vulnerability identification work that is just starting. I am not linking the two today but I am also not going to vote to put us in a situation where that will not be possible if that is what is decided.

Sorry but I politely disagree with your opinion based on today's reality. This impacts the community as a whole. This change will cause problems in areas we have no idea of today. Unexpected consequences  is also historically relevant here. I want CVE positioned for the future moving forward and I do not what to be here again. It is too expensive and too disruptive and does little to assist the image and adoption of the CVE.  Let's not be shortsighted and do what's the right thing for the future of CVE. 

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 11:43 AM
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:

: Thank you for the comment as I think it is spot on.  I too think a more

: expanded Option A is an reasonable alternative. I have stated before

: McAfee felt that 6 digits was just too short for the future proofing and

: if extended to 7 or more we may have changed our vote.  I see problems

: with option B but future proofing was really the driving factor for our

: decision. I'd like to second Harold's request to reconsider Option A

: length.

Could McAfee, or anyone who voted for 'B' due to the 'future proofing'

concern please address the repeated comments about how that is absurd?

In case you missed it in Steve Christey's CVE vote email:

   It should be noted that the team feels that any circumstance(s) that

   would require the issuance of (on average) over 2,700 CVE IDs per day

   (999,999 IDs per year) would reflect a fundamental change in the

   meaning and usage of CVE IDs.  Put another way, the "CVE" that requires

   the issuance of over 2,700 IDs would not be the CVE of today.

As Carsten Eiram from RBS noted:

   1) A purely theoretical explosion in vulnerability reports and coverage

   (keeping in mind that MITRE currently has trouble keeping up with the

   existing trend and don't guarantee all vulnerabilities will be assigned

   CVEs). A change from 8K-10K vulnerabilities reported per year to > 1

   million is simply unrealistic. Even if someone starts auditing a ton of

   projects with automated code scanning tools and without any manual

   follow-up analysis just dumps the results on some mailing list, we

   would be hard-pressed to exhaust 6 digits. We would be discussing

   resource problems long before hitting those numbers, as neither CVE nor

   any CVE processors will be able to keep up with such a load.

So I politely request that anyone voting against 'A' and cited this

concern please discuss it first. I can't understand how this is a real

concern, especially in conjunction with several companies that basically

said "option B is much easier on our current system, we will have to

change less" which seems exceedingly selfish, and not in the interest of

the community so much as the interest of your specific company.

Thank you,

Brian