RE: Counting on CVEs

[Russ Cooper <Russ.Cooper@rc.on.ca>]

Hi all, long time no see…;-] (btw, unemployed and interested)

 

Problem #1 is the definition of “vulnerability”, problem #2 is the understanding of the word “enumeration”, IMO…but then I am incredibly out of date since I see now that “E” stands for “Exposures”, not “Enumeration”…sigh, tough to get old.

 

For example, I have seen what appears to be the use different CVE numbers for the same vulnerability in different products…this over-inflates the CVEs unnecessarily. A vulnerability, which for all intents and purposes is the same as a previous vulnerability, gets a new CVE because products want to test for scenario A and scenario B…this equally inflates CVEs unnecessarily.

 

“In the beginning”…we talked about needing 1 CVE number to represent integer overflow, or another for  insufficient parsing…clearly that never stuck. But equally, it would seem that some vendors would like to assign a CVE per “threat”, which should also have never stuck.

 

I’m unaware of > 10,000 new vulnerabilities per year, at least not in what I would consider “new vulnerabilities”. That’s one heck of a lot of lines of code, but if you’re counting vulnerabilities in Android Apps, then I could also see that number be incredibly low. So perhaps the issues aren’t with vulnerabilities, but instead with exposures??

 

I remember that at some point the application for CVEs was more or less guaranteed if done by known organizations, but that was on the assumption that the issues would be validated and the CAN proven not required. With a lack of funding, that mapping (or vetting) surely isn’t getting the attention it needs. If it did, perhaps many CVEs could be saved or recalled…but then the way they are used today that would either lead to embarrassment, or significant investment by the people using their own CVEs.

 

One thing I would expect to see a “Comments” feature used for is to say that 2 (or more) different CVEs represent “more or less” the same thing…and then documents the way to address the issue across different platforms/products/vendors…

 

I’d say more, but I really gotta read up on just what the heck “exposures” are.

 

Cheers,

Russ – formerly NTBugtraq Editor…currently raising chickens and building a cheaper house.

 

From: owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of Williams, James K
Sent: Wednesday, March 07, 2012 3:45 PM
To: cve-editorial-board-list@lists.mitre.org
Subject: RE: Counting on CVEs

 

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

CA Technologies Product Vulnerability Response Team
CA Technologies Business Unit Operations

wilja22@ca.com - 816-914-4225

 

 

 

From: owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of Kent_Landfield@McAfee.com
Sent: Wednesday, March 07, 2012 1:53 PM
To: cve-editorial-board-list@lists.mitre.org
Subject: Counting on CVEs

 

All,

 

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…

 

Thoughts?

 

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com