Agree with everything Kent said.
One important change I would like to see is the addition of a “Comments” feature on each CVE page at cve.mitre.org. The Comments feature could be used by Editorial
Board members (and other vetted individuals?) to add info such as corrections, additional references, vendor responses, etc.
Thanks and regards,
Ken Williams, Director
Product Vulnerability Response Team
Business Unit Operations
email@example.com - 816-914-4225
From: firstname.lastname@example.org [mailto:email@example.com]
On Behalf Of Kent_Landfield@McAfee.com
Sent: Wednesday, March 07, 2012 1:53 PM
Subject: Counting on CVEs
We have problems with CVE reporting that are known issues but which are becoming apparent to many more and could easily undermine the usefulness of CVE identification if left unchecked.
We discussed this at the ITSAC conference in the Future of Vulnerability Reporting Workshop and at the follow-on Vulnerability Reporting day at the Software Assurance event a month later. (There were action items
out of the latter that I am not aware have been completed…)
I have just had a very concerning discussion about the usefulness of CVEs as a means to measure vulnerabilities today and the decay of its value if the trend continues. The discussion centered around the accuracy
of the numbers of CVEs identified compared to those reported in the community as a whole. If we looked at just the CVE numbers, it appears that the numbers of vulnerabilities have been dropping since a high in 2008. This is a rather important error. As
we all know, this is not accurate. Vulnerabilities have not been dropping, they are growing, not dropping by 30%.
For the vendor community, these trends have rather concerning potential impacts on us. First, our vulnerability research databases use CVE as a primary reference. The CVE Id has been authoritative in the past.
It is used internally as a means to communicate vulnerability record information between fielded products and between research analysis teams. As the numbers decline, it means we are forced to look elsewhere to provide the identification and communication
that CVE provided in the past. More proprietary ids are becoming more the norm.
The more serious concern is what it is showing to executives of companies.
"If the vulnerabilities have dropped 30% since 2008, why do I need to be funding the security staff and efforts at the rate I am? I see that MITRE is reporting an overall drop each year since 2008 but yet
you folks keep coming to me saying that the threats are much worse and we may be in the same relative situation we were when malware spiked a couple years past…"
For those that actively work in this environment, we know vulnerabilities have not dropped 30% since 2008. Quite the contrary, our internal numbers indicate an increasing trend similar to a 30% rise. Symantec
has also reported a similar trend.
One of the major problems is that MITRE funding is not what it should be. On multiple occasions we have been asked to target the classes of products where vulnerabilities are considered the most critical and which
sources should be monitored. The view of what to target and monitor gets smaller and smaller as funding is held level or reduced.
At one point the intent of the effort was to cover all published vulnerabilities that could be corroborated in some fashion. Over the years the reality has set in that this is a very resource intensive operation.
As such the focus of the effort has reduced what is reported on to assure CVEs can be assigned for the types of products most important to the Editorial Board participants and their sponsor. This gives an artificial view of the numbers of existing vulnerabilities
and that is being recognized outside the vulnerability community.
Another problem is the CVE format itself. There has been an active discussion about the format limitations as well. The CVE format is CVE-YYYY-NNNN. This means that currently we cannot have more than 10,000 CVEs
reported in a single year. At the rates we are seeing internally, we are already there.
Then there are the limitations of CVE process in general. The focus is English only although some non-US vulnerabilities do get assigned from time to time. CVE does not support the international community and
software written for non-English geo-centric areas are not included. While this has not been a concern for US-only software vendors, there is a great deal of regional software written for major emerging markets. None of those vulnerabilities are identified
by a CVE.
Given these constraints, it seems like it is time to figure out how to address the issues in a more of a creative way. We know the constraints. Is there something we can do to augment the MITRE staff in certain
areas that would help? I can see the format issue being a rather easy one to attack but it is the coverage issue that is most concerning. Or we should ignore it and slowly let the value of CVE to the community and vendors decay…
Director Content Strategy, Architecture and Standards
McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024