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

Re: CVE ID Syntax Vote - results and next steps

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

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
Version: GnuPG v1.4.13 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


Page Last Updated or Reviewed: October 03, 2014