Re: CVE ID Syntax Vote - results and next steps

[<Kent_Landfield@McAfee.com>]

So what types of things could POTENTIALLY impact CVE in the future? All listed below are potentials only…

1. Increased CNAs in the existing US speaking countries
2. Potential global expansion with other geo-regions using CVE (global CNAs)
3. Automated vulnerability identification means.
4. Expansion to other evolving technologies such as tablet, mobile, etc.

I am sure there are others but you get the point.

The CVE format cannot be decided based on the landscape today.  There are future technologies and issues that will directly affect the landscape as we know it.  The traditional PC based world is becoming a much smaller component of our computing world. We need to do our job and envision this new reality so we can make an intelligent decision and be better prepared for what is to come.

Kent Landfield

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

From: Art Manion <amanion@cert.org>
Date: Thursday, April 18, 2013 1:51 PM
To: security curmudgeon <jericho@attrition.org>
Cc: Kent Landfield <Kent_Landfield@McAfee.com>, "cve-editorial-board-list@LISTS.MITRE.ORG" <cve-editorial-board-list@LISTS.MITRE.ORG>
Subject: Re: CVE ID Syntax Vote - results and next steps

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

On 2013-04-18 12:43 , security curmudgeon wrote:

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.

I don't predict significant changes to CVE's scope and level of

abstraction that would directly result in 1M per year IDs.  My initial

thought was therefore to vote for A.

What caused me to reconsider was the idea of more and more active

CNAs.  Now, MITRE is careful to hand out modest allocations of IDs,

generally sequentially, to dozens(?) of CNAs.  I don't think there's

much waste.

What I wanted to future-proof is the world with more CNAs (100s?) with

more assignment authority (like a modulo slice or big sequential block

of the year's CVE ID space).  In this world, there still may still not

be more than 1M CVE IDs published per year, but there may be more than

1M CVE IDs allocated to CNAs.  Allocation != publication.

Now, I don't see any strong indicators of this particular new world.

But it seemed reasonable enough to want to plan in advance for.

Another future scale issue:  Automated ways to find vulnerabilities

could overwhelm the current 10K/year human-scale size of the problem.

- Art

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.13 (Darwin)

Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlFwQKUACgkQk/8FEDbCaKMQUQCfapzSbyRZrGJHKEFA6YY9dl1M

R8AAmgKw5YUdQX4QCGHgKzQdk+F9uWZv

=lQ+f

-----END PGP SIGNATURE-----