CVE Team notes from ITSAC Discussions on the Future of Global Vulnerability Reporting

["Boyle, Stephen V." <sboyle@mitre.org>]

 

 

Recently, members of the MITRE CVE team attended and participated in a conference track hosted by the US Department of Homeland Security (DHS), CVE’s sponsor. The occasion was the US Government-hosted 2011 Information Technology Security Automation Conference (ITSAC), and the topic of the track was the "Future of Global Vulnerability Reporting.”

 

Not unexpectedly (given its level of maturity and adoption), much of the conversation centered on CVE.  We believe it is important to keep the full Board apprised of the discussions that occurred in this part of the cybersecurity community and want to provide our observations and thoughts. It is critical to note that these discussions occurred in one portion of the community and need to be shared and discussed among the larger community. Below we provide our summary and thoughts on the ITSAC discussions to both keep you all informed and spur dialogue here on the Editorial Board list. Several other members of the CVE Editorial Board were also in attendance and/or participated, and we encourage each of them to summarize their thoughts on the discussion to the full Board, as well as any and all similar or related efforts of which they may be are aware.

 

The CVE team sees 3 primary issues coming out of the ITSAC discussions:

 

1.      Many people expressed a need for a system of non-coordinated identifiers that

a.       Share a standardized syntax

b.      Can be assigned by vulnerability researchers with minimal or no coordination

c.       Can be used to support the early reporting of non-confirmed vulnerabilities.

 

2.      There was discussion of the need for an international, global system of identifiers that

a.       Provide CVE-like deconflicted vulnerability ID assignment

b.      Provide IDs for software that is out-of-scope for CVE (primarily, non-English based software).

 

3.      There was little to no discussion of the need to continue to evolve CVE's ID assignment and documentation processes to keep pace with vulnerabilities disclosed in the information sources considered "must-haves" by the CVE Editorial Board (i.e. the discussions we've been having over the past several weeks on this list).

 

We actively seek and encourage all input, experience, and wisdom. To help begin the discussion, the CVE team's initial opinions are:

 

1)      We are supportive of the idea of an early reporting ID structure; however we see this use case as being inconsistent with the 3 previously-identified CVE use cases and out of scope for CVE.

 

2)      We believe that the design of an international vulnerability ID scheme is beyond the scope of MITRE's CVE program, however we recognize that MITRE, the entire CVE Editorial Board and all CVE-stakeholders must monitor and (where appropriate) engage with such efforts, not only to provide input and experience, but to ensure that any such system avoids creating expectations or demands on CVE that are unreasonable and/or unachievable.

 

3)      We continue to see the evolution of CVE ID assignment and documentation processing to cover the "must-have" information sources to be the most critical area of current concern for the MITRE CVE team and the Editorial Board.

 

 

We give more details on each of the three areas.

 

EARLY REPORTING IDs

 

The need for "promiscuously" assigned, non-deconflicted IDs that share a common syntax dominated much of the discussion.  Many people stated that there is a need for some sort of ID to be used against early reports of issues prior to the assignment of an official CVE ID.  One example presented was the need to have IDs for high-volume results from automated test tools, which may or may not turn out to be real vulnerabilities.  The general consensus among the participants was that there appeared to be a need for researchers to be able to create their own IDs for such issues.  There was also a general recognition that researchers are currently free to assign their own, proprietary IDs today and, in fact, nearly all information sources use them.  But, it was also argued that existing non-deconflicted proprietary IDs don't share a common syntax, which creates some problems.

 

The CVE team noted that CVE has 3 primary use cases that it supports, as discussed on this list last year:

1)      Patch triage analysis

2)      Vulnerability scanning and reporting

3)      Threat and incident analysis

 

We also noted that in all 3 of these use cases, there is a need for a CVE ID to be associated with a "known" issue. In the early days of CVE, the status of "known" was a result of Editorial Board voting.  Today, it is a result of the CVE team's judgment regarding the number and credibility of information sources as reflected in CVE ID issuance.  In contrast, we argued that the issues discussed in early reporting lack this level of validation, and, as a result, warrant a different identifier scheme.  More to the point, we argued that early reporting was a fundamentally different (albeit related) use case that should be handled separately.  We believe that this argument was accepted by most in the room and believe that it persisted "on the white board" at the close of the session.

 

We want to emphasize that while the MITRE CVE team believes that an early reporting ID structure is out of scope for the CVE effort, we affirm the legitimacy of the use case and are supportive of others attempts to create and codify such an ID scheme.

 

 

GLOBAL DECONFLICTED VULNERABILITY ID STANDARD

 

The need for a global-scale identifier scheme that assigns CVE-style, deconflicted IDs to known vulnerabilities was discussed at the ITSAC meetings. This discussion was, in part, triggered by the publication of the paper “IVDA: International Vulnerability Database Alliance,” Chen Zheng et al.  

 

First, the feasibility of having a single analytical capability that is capable of assigning IDs for all software and all disclosures written in all languages was discussed.  MITRE asserted that this not feasible for MITRE to attempt and we have strong doubts that any such centralized capability could be created in a cost-effective manner.  We argued and firmly believe that any such system would need to rely on multiple ID assignment functionaries, each serving a role that is similar to the MITRE CVE function.

 

Second, there was a discussion of spreading the ID assignment function across multiple (notionally) regional entities. The issue of how to define the "swim lanes" for each "regional" ID assignment capability was discussed but not resolved.  The hope of such a scheme is that areas of responsibility can be defined for each ID assigner that would minimize duplicates across a global system.  This is an issue that will require much more discussion and clarification if such a global system is to be realized.   On further reflection, it occurs to us that the CVE Editorial Board discussion on identifying the "must-have" and "nice-to-have" information sources for vulnerability disclosures may be of some benefit here. If each "regional" ID assignment capability had different, well-chosen disclosure information sources that it was responsible for covering, it could be the case that the resulting global identifiers would contain a relatively small and manageable number of duplicates.  Obviously, this is conjecture and is something that would need to be investigated much more fully.

 

Third, the question of which organization or standards body should define a global ID structure and should oversee the set of "regional" ID assignment capabilities.  In this context, IANA was specifically mentioned as having an established track record in coordinating ID and naming registries.  The MITRE CVE team has no opinion at this time on which international or global standards body is used. 

 

Fourth, the question of syntax of such a broad-scope identifier scheme was discussed.  MITRE argued that so long as appropriate "swim lanes" can be defined for each assignment functionary, then there are several successfully federated ID namespaces that could serve as inspiration including ISBN and VIN.  These ID schemes typically encode 3 pieces of information

1)      The name of the ID scheme (e.g. ISBN)

2)      The identity of the recognized ID issuer (e.g. country or vendor codes)

3)      An arbitrary, nominal ID number

 

So long as any adopted large-scale ID scheme stays within this convention, the MITRE CVE team sees no technical issue that would prevent us from adopting the new convention for CVE ID issuance.  If, on the other hand, the resulting ID scheme attempted to create a classification-style ID structure (e.g. Library of Congress Numbers) that encoded descriptive information based on some classification system, it will be very unlikely that the MITRE CVE team be able to produce such identifiers.   Members on our team have been tracking vulnerability classification schemes for 15 years and have yet to see a stable, universally accessible classification scheme for vulnerabilities. Based on our experience, we very strongly believe that any system that attempts to encode semantics in the ID namespace will be problematic.

 

 

EVOLUTION OF CVE

 

This issue was mentioned briefly at the ITSAC meetings but received no significant discussion.  However, one message came through loud and clear from all stakeholders at the meeting: CVE works, and regardless of what happens in the future, CVE (as we currently understand it) needs to keep working for their processes to stay sustainable. To a large extent, the criticality of CVE, combined with the challenges involved with keeping abreast of the "must-have" information sources, and the growing complexity of vulnerabilities often forces the MITRE CVE team to consider other issues as something like external distractions or even, at times, threats.   We know that CVE's content production processes need to evolve; at this point in time, believe this is ball that we need to keep our eye on. 

 

 

CONTINUING CVE EDITORIAL BOARD DISCUSSIONS

 

We suggest that all member of the CVE Editorial Board become engaged in or, at the very least aware of, discussions regarding the future of global vulnerability reporting. We believe it is an important and necessary discussion for the community as a whole, and encourage Board members and others to be cognizant of such efforts. 

 

Finally, we again express our gratitude for all of you have provided thoughtful and helpful feedback on the recent discussion of information sources, and we ask for your on-going input and guidance as we look to pick up that thread again shortly.

 

 

Thank you for your continuing participation in the activities and discussions of the CVE Editorial Board.

 

Best Regards,

Steve Boyle

MITRE CVE Project Lead