CVE and International Standards Bodies

["Mann, Dave" <damann@mitre.org>]

All,

We want to inform you all of some recent discussions in the international and global standards arena that may have a future impact on CVE.  As we understand things, there have been no formal actions taken and discussions, to date, have been preliminary. Nevertheless, it is important that we keep you as up to date as possible so that you can inform your own organization and so that we, together as the CVE Editorial Board, have adequate time and information to reach consensus on how what actions to take, if any.  

To adequately capture and frame things, this email will be on the long side, for which I apologize.  It consists of 3 parts:

1) A Summary of Recent Discussions

2) A Review of the CVE Editorial Board Process

3) The MITRE CVE Team's Initial Guidance 



1) A Summary of Discussions
---------------------------
In mid February, a memo was sent from Kent Landfield (McAfee, CVE Editorial Board Member) and Kathleen Moriarty (EMC, IETF Managed Incident Lightweight Exchange Working Group Co-Chair) to several of MITRE's US Government sponsors advocating that MITRE-managed "security content automation specifications" be transfered to the IETF.  This memo was joined with letters of recommendation from the following organizations: EMC Corporation, Juniper Networks, Tripwire Inc., SecPod Technologies, nCircle, ThreatGuard, RedHat, Hitachi Data Systems, McAfee, Inc., Rockport Technology LLC, Symantec, DTCC, C3iSecurity, and Saint Corporation.  Around the same time, we (MITRE) had an initial meeting with Kathleen Moriarty to discuss the recent IETF activity. The issues were further discussed in an informal "pre-meeting", prior to the IETF-83 meetings held in Paris, France.  Attendees of this pre-meeting included, Kent Landfield, Kathleen Moriarty, Adam Montvale (Tripwire), Dave Waltermier (NIST) and Jon Baker (MITRE).  

One of the possibilities discussed in this meeting was codifying the syntax of CVE IDs as an IETF standard.  

The basic position taken by MITRE in these discussions (and prior discussions on the global vulnerability reporting issue) were:

a) Changes to the CVE ID syntax could prevent MITRE (or any other organization) from being able to operate the CVE Registry as it is currently defined.  

b) By charter, the primary decisional body for CVE is the CVE Editorial Board.  To that end, no decisions will be made without consensus of the Editorial Board.

We see adoption of CVE by international standards bodies to be a logical and desired outcome of CVE.  That said, we advise careful consideration be given regarding the future of CVE.  CVE is comprised of several sub-components and it may be beneficial for different sub-components to be adopted by different standards bodies.  Some components may not fit in any standards body.  

Obviously, we will work to keep you all informed as more information becomes available and we strongly encourage vigorous discussion here, on the CVE Editorial Board list. 



2) A Review of the CVE Editorial Board Process
----------------------------------------------
As a non-government, non-competitive Federally Funded Research and Development Center (FFRDC) status, the MITRE Corporation manages CVE as a neutral 3rd party. This ensures that sensitive information shared with us can be adequately protected and ensures that CVE IDs are assigned in a manner that is free from any competitive bias.

The MITRE Corporation holds the copyright on many of its work products (including CVE) and routinely transfers its intellectual property to other organizations in fulfillment of its FFRDC charter. MITRE has an established Technology Transfer Office and well established practices to effect a full range of legal transfer and licensing options. [See: http://www.mitre.org/work/tech_transfer/ ] 

In managing CVE, we seek the consensus across all stakeholders, most particularly as expressed in the deliberations of the CVE Editorial Board.  When consensus is not achievable, MITRE makes final decisions in the public's best interest in accordance with our FFRDC charter. In fulfillment of our directed 3rd party role in managing CVE, the MITRE Corporation regularly enforces its copyright, trademarks and other mechanisms to protect the intellectual property from abuse and misuse. 

To this end, MITRE will consider possible transfer (or license) of the intellectual property of CVE to  appropriate standards bodies while following our established consensus making process with the Editorial Board.



3) The MITRE CVE Team's Initial Guidance
----------------------------------------
We, collectively, as the CVE Editorial Board, need to discuss and reach consensus on the matter of which portions of the CVE effort should be adopted as international standards and under what conditions.  The MITRE CVE team offers the following as initial guidance on the subject, and as starting point for our collective deliberation.

CVE has three primary components with respect to standardization: 
a) the registry (or list) of officially published CVE IDs and descriptions, 
b) the syntax of the CVE ID namespace and, 
c) the definition of proper usage. 

Of these, the primary consideration must be given to the registry. The central question is, "How should the operation of the registry be structured to best serve the needs of the security industry?" 

Considerations regarding the potential for standardization of the CVE namespace and acceptable usage can then be considered as means to support the desired ends of the CVE registry. To this end, MITRE recommends that it continue to operate the CVE Registry as a non-competitive, non-governmental neutral 3rd party and, in support of this, that MITRE license the use of the CVE name to standards bodies to codify the syntax of the namespace and definitions of proper usage while ensuring that these efforts do not negatively impinge on the operation of the CVE Registry.



The CVE Registry
----------------
CVE IDs are used in over 650 products and services from over 60 countries. MITRE believes that for the CVE registry to sustain this level of effectiveness and adoption, it needs to be managed by an organization that does not compete with industry and is not a part of any government organization. There are many commercially operated repositories of vulnerability information, most of which have their own proprietary name or ID scheme for vulnerabilities. But, security vendors regularly report that they cannot and will not use IDs from other commercial products and services for fear of providing advantage to their competitors. Additionally, commercial products and services tend to count and discriminate among vulnerabilities in ways that are well aligned to their internal processes. In contrast, CVE's counting principles have evolved to minimize competitive bias. 

In a similar manner, because CVE IDs are issued by a non-government entity, vendors can incorporate CVE IDs into the products without any potentially negative associations with or perceived obligations to any government. In particular, the MITRE Corporation regularly receives and processes proprietary information regarding vulnerabilities that is shared under explicit or implicit non-disclosure agreements. Security vendors report that certain nation states have attempted to demand access to their proprietary security information as a condition of doing business in or with that country. The fact that the MITRE Corporation is an independent not-for-profit organization allows these vendors to support the CVE process, while giving security information directly to nation states. 

Other industries and disciplines benefit from the existence of registries operated by non-competing, non-government organizations. However, they are typically not operated by international standards bodies.  Aside from demonstrable neutrality, any organization that would be a candidate to operate the CVE Registry would also need sufficient technical expertise in the field of vulnerability analysis and well established business model and funding stream. 

At the present time, we do not see viable alternatives to MITRE's current operation of the CVE registry and for this reason, recommend that MITRE continue with its operation. If and when such an organization becomes identified, the MITRE Corporation will seek input from the CVE Editorial Board to consider whether or not it is in the public interest to transfer control and operation of the CVE Registry.


The CVE Namespace
-----------------
We recognize the need for the CVE namespace to be codified as a recognized standard. At the same time, changes to the CVE namespace could undercut the ability of MITRE (or any other registry operator) to produce CVE IDs in a timely and cost effective manner. We are particularly concerned about two long-standing requests that have been proposed that would fundamentally alter CVE.  The first is the request that the CVE namespace included some form of hierarchical classification information to describe the vulnerability. MITRE and the CVE Editorial Board have researched many vulnerability classification systems and have concluded that a) no single taxonomy supports all communities and b) the taxonomies are in need of constant evolution because programming and attack practices continue to evolve. The CVE Editorial Board has firmly decided to keep any sort of descriptive information out of the CVE namespace and the MITRE Corporation strongly concurs with the consensus. A second request is that the namespace be federated to allow multiple parties to issue CVEs in a non-coordinated fashion.  While we recognize some value in a standard ID format for non-coordinated vulnerability IDs, this would fundamentally change CVE's ability to act as a tool for correlation. At the same time, we recognize the very real issues of timeliness and scalability, and are working on a proposal to address them.

It is reasonable to expect that if the CVE namespace were to be fully and unconditionally transferred to a standards body that these basic questions would be asked again and that the namespace could be altered in a way that either impacted the viability of the registry or destroyed the utility of the current system. For this reason, MITRE recommends that the CVE trademark be licensed to an appropriate standards body so that the standards body can reference the CVE namespace as an external dependency while allowing the MITRE Corporation, as the operator of the registry, to retain control of the namespace (on behalf of the public interest as reflected by the Editorial Board) to ensure that registry operations remain viable.


CVE Usage and Product Testing
-----------------------------
Different and creative uses of CVE IDs should be expected and encouraged and as a result, it should be expected that multiple sets of norms and practices will emerge as "standards" for different communities. At the same time, inappropriate use and misrepresentation of CVE could undercut the value and utility of the CVE registry. For this reason, MITRE recommends that a) MITRE continue to define basic primary usage best practices as a part of its on-going outreach and engagement efforts [see: http://cve.mitre.org/compatible/process.html] and b) that MITRE license the use of the CVE trademark for use in appropriate usage and product testing standards.



-Dave
==================================================================
David Mann | Principal Infosec Scientist | The MITRE Corporation
------------------------------------------------------------------
e-mail:damann@mitre.org | cell:781.424.6003
==================================================================