Very Important Message for the Editorial Board

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Very Important Message for the Editorial Board

Joe Sain

Dear Members of the CVE Editorial Board,

 

CVE has come under significant pressure to expand its reach well beyond the current list of products and services; at the same time, the demand for CVE IDs has risen dramatically. As a result, other initiatives and especially our communications with the Editorial Board and with the community took a back seat, which is counterproductive. For that, we offer our apologies. 

 

The world has changed significantly since CVE was released in 1999, and we are moving out rapidly to satisfy the needs of security researchers who need ready access to vulnerability IDs. To that end, MITRE will begin a pilot program to address rapid-response CVE-IDs on Monday, 21 March 2016. We wish to underscore that this is in no way an attempt to circumvent the Editorial Board but is rather an experimental step toward the federated vulnerability ID methodology that the community has been discussing over the past several years. We will work closely with the Board to evaluate the results of the pilot and to work together to develop a long-term solution that continues to expand coverage moving forward.

 

Details of the pilot program are provided in the Press Release below, which will be published to the CVE-ANNOUNCE email list and to the CVE web site later today. It is important to note that this approach was chosen to avoid any conflict with the existing CVE process as it is currently operating, and that the IDs issued under the federated scheme during the pilot will not be analyzed and incorporated into the CVE list or feeds. There will be no effect on external operations; all in-scope vulnerabilities will be handled as they are now.

 

We are also planning to continue the discussion with the Board regarding the scope, sources, and products that CVE currently covers and that the Board feels that CVE should cover in the future. We look forward to discussing these issues with you over the coming week, and formulating solutions so that we can take immediate action.

 

Thank you for your continued support.

 

Joe Sain

CVE Communications and Adoption Lead

The MITRE Corporation

 

 

MITRE Announces the Launch of a Federated-Style CVE ID Pilot Effective Monday, March 21, 2016

 

CVEs are valuable to cybersecurity risk management because they underpin the vulnerability management infrastructure and contain (1) a unique identifier, (2) a description, and (3) associated references. CVEs have historically been published with all three fields fully populated in order to effectively serve multiple CVE’s use cases.  

As the number of vulnerabilities and associated requests continue to increase, the traditional operating model for the CVE Program has not been able to keep pace with the growing demands of the vulnerability management community; a different scale is required. In addition, the researcher and discloser communities have identified a need for rapid, early assignments of CVE IDs to enable early-stage vulnerability coordination and mitigation.  The immediacy of this use case means that the requirement for traditional references and descriptions is, at times, less important than the rapid issuance of unique identifiers.

To address this need, MITRE will begin assigning federated CVE IDs using a new format as of Monday, 21 March 2016. The new format will not have any impact on either direct or downstream uses of the current-format CVEs. MITRE also recognizes that it is critical for the community and stakeholders to be able to easily differentiate between traditional CVE entries and those IDs that have been assigned for the rapid-response use case.

MITRE has been participating as a member of the vulnerability management community on the concept for a federated vulnerability identifier scheme to enable cooperating vulnerability ID assignments. As such, MITRE is taking this opportunity to experiment with and pilot a federated CVE identifier syntax to provide a clear indicator that rapid-assignment IDs are different from traditional CVEs.

The new, rapid-response federated ID scheme has been carefully designed so that it does not disrupt existing processes and their attendant use cases, and allows for future compatibility with existing CVE identifiers. Federated CVE Identifiers will allow for rapid experimentation with new types of assignments and use cases so that CVE, the CVE Editorial Board, and the community can work together to determine what best serves the needs of the community.

The federated ID syntax will be CVE-CCCIII-YYYY-NNNN…N, where “CCC” encodes the issuing authority’s country and “III” encodes the issuing authority. At its launch, MITRE will be the only issuing authority, but we expect to quickly add others to address the needs of the research and discloser communities, as well as the cybersecurity community as a whole. This new federated ID system will significantly enhance the early stage vulnerability mitigation coordination, and reduce the time lapse between request and issuance.

MITRE is continuing to refine CVE operational capabilities so that automated vulnerability identification, description, and processing are incorporated over time. As both the Federated Pilot and the next phase of CVE operational capabilities are scaled and automated, traditional CVEs can be merged with federated CVEs.

The CVE Team looks forward to working with members of the CVE Editorial Board and the broader community to rapidly expand CVE coverage and implement the federated CVE identification scheme, so that the CVE capability keeps pace with the increasing demand for well-recognized vulnerability identifiers.

Reply | Threaded
Open this post in threaded view
|

Re: Very Important Message for the Editorial Board

Kurt Seifried


The new, rapid-response federated ID scheme has been carefully designed so that it does not disrupt existing processes and their attendant use cases, and allows for future compatibility with existing CVE identifiers. Federated CVE Identifiers will allow for rapid experimentation with new types of assignments and use cases so that CVE, the CVE Editorial Board, and the community can work together to determine what best serves the needs of the community.


Who will be issuing these? Have any been assigned/announced?
 


The federated ID syntax will be CVE-CCCIII-YYYY-NNNN…N, where “CCC” encodes the issuing authority’s


Oh dear. So this breaks every piece of CVE tooling/software currently in existence. Before the industry collectively puts a few tens/hundreds of thousands of hours of work and quite a lot of money into supporting this is there any guarantee from Mitre that this is a long term project? There is no mention of how widespread or long this pilot project is going to go for. Can you please provide concrete details?
 

country and “III” encodes the issuing authority. At its launch, MITRE will be the only issuing authority, but we expect to quickly add others to address the needs of the research and discloser communities, as well as the cybersecurity community as a whole. This new federated ID system will significantly enhance the early stage vulnerability mitigation coordination, and reduce the time lapse between request and issuance.

MITRE is continuing to refine CVE operational capabilities so that automated vulnerability identification, description, and processing are incorporated over time. As both the Federated Pilot and the next phase of CVE operational capabilities are scaled and automated, traditional CVEs can be merged with federated CVEs.


Are there any specific goals/timeframes here? We're still waiting for an ETA on a possible solution for the robots.txt on the CVE web site (http://cve.mitre.org/robots.txt) that blocks all indexing of the CVE content on the web site. 
 


The CVE Team looks forward to working with members of the CVE Editorial Board and the broader community to rapidly expand CVE coverage and implement the federated CVE identification scheme, so that the CVE capability keeps pace with the increasing demand for well-recognized vulnerability identifiers.


I'm a bit worried as the board was never consulted on this as far as I know (no emails, nothing mentioned in the phone call I had). Can anyone on the board confirm that they suggested this/supported this strategy by Mitre? 


--

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Very Important Message for the Editorial Board

Landfield, Kent B
I agree with Kurt here.  100%

This breaks just about everything.  When I have mentioned federated CVE support I was imaging the Board, I and others that have operational responsibility for using and distributing CVEs would have some say in what it looked like. I fully understand you are under pressure but this is not the right way to do this.  I really would have liked this to be one of the topics we discussed at the CVE Improvement Summit instead of having this hoisted on us this way. It would be in the best interest to hold off in my mind since these Ids have NO usefulness in product and this will totally confuse the market, researcher and those with operational needs for a consistent CVE.

This really needs to be discussed before you make the problem worse…
---
Kent Landfield
+1.817.637.8026

From: <[hidden email]<mailto:[hidden email]>> on behalf of Kurt Seifried <[hidden email]<mailto:[hidden email]>>
Date: Thursday, March 17, 2016 at 4:26 PM
To: "Sain, Joe" <[hidden email]<mailto:[hidden email]>>
Cc: cve-editorial-board-list <[hidden email]<mailto:[hidden email]>>
Subject: Re: Very Important Message for the Editorial Board


The new, rapid-response federated ID scheme has been carefully designed so that it does not disrupt existing processes and their attendant use cases, and allows for future compatibility with existing CVE identifiers. Federated CVE Identifiers will allow for rapid experimentation with new types of assignments and use cases so that CVE, the CVE Editorial Board, and the community can work together to determine what best serves the needs of the community.

Who will be issuing these? Have any been assigned/announced?


The federated ID syntax will be CVE-CCCIII-YYYY-NNNN…N, where “CCC” encodes the issuing authority’s

Oh dear. So this breaks every piece of CVE tooling/software currently in existence. Before the industry collectively puts a few tens/hundreds of thousands of hours of work and quite a lot of money into supporting this is there any guarantee from Mitre that this is a long term project? There is no mention of how widespread or long this pilot project is going to go for. Can you please provide concrete details?

country and “III” encodes the issuing authority. At its launch, MITRE will be the only issuing authority, but we expect to quickly add others to address the needs of the research and discloser communities, as well as the cybersecurity community as a whole. This new federated ID system will significantly enhance the early stage vulnerability mitigation coordination, and reduce the time lapse between request and issuance.

MITRE is continuing to refine CVE operational capabilities so that automated vulnerability identification, description, and processing are incorporated over time. As both the Federated Pilot and the next phase of CVE operational capabilities are scaled and automated, traditional CVEs can be merged with federated CVEs.

Are there any specific goals/timeframes here? We're still waiting for an ETA on a possible solution for the robots.txt on the CVE web site (http://cve.mitre.org/robots.txt) that blocks all indexing of the CVE content on the web site.


The CVE Team looks forward to working with members of the CVE Editorial Board and the broader community to rapidly expand CVE coverage and implement the federated CVE identification scheme, so that the CVE capability keeps pace with the increasing demand for well-recognized vulnerability identifiers.

I'm a bit worried as the board was never consulted on this as far as I know (no emails, nothing mentioned in the phone call I had). Can anyone on the board confirm that they suggested this/supported this strategy by Mitre?


--

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]<mailto:[hidden email]>