New CVE-ID Format as of January 1, 2014 — learn more
2013 Industry News Coverage (Archive)
Below is a comprehensive monthly review of the news and other media’s coverage of CVE. A brief summary of each news item is listed with its title, author (if identified), date, and media source.
MITRE Corporation Web Site, December 9, 2013
MITRE Corporation issued the news release below on December 9, 2013, which is available on the MITRE Web site at: http://www.mitre.org/news/press-releases/cve-vulnerability-dictionary-to-adopt-the-common-vulnerability-reporting.
CVE Vulnerability Dictionary to Adopt the Common Vulnerability Reporting Framework (CVRF) Standard
MCLEAN, Va., December 9, 2013 – The MITRE Corporation announced today that the Common Vulnerabilities and Exposures (CVE®) List will now publish data using the Common Vulnerability Reporting Framework (CVRF). The CVE List is a dictionary of common names for publicly known information security vulnerabilities in software.
"Presenting the CVE List in CVRF format will make it easier for people to access CVE content instead of having to use our custom format," said Steve Christey Coley, principal information security engineer at MITRE and editor of the CVE List. "We hope this will encourage others in the security community to share vulnerability information using a standardized machine-readable format."
Developed by the Industry Consortium for Advancement of Security on the Internet (ICASI), CVRF is an XML-based standard that enables software vulnerability information to be shared in a machine-parsable format between vulnerability information providers and consumers. Having vulnerability information in a single, standardized format speeds up information exchange and digestion, while also enabling automation. CVRF is currently used by major vendors, including Red Hat, Microsoft, Cisco Systems and Oracle Corporation, which issue their security advisories in CVRF format:
The CVE dictionary, sponsored by the office of Cybersecurity and Communications at the U.S. Department of Homeland Security (DHS), contains more than 58,000 unique entries and is considered an international standard. Products, services and organizations around the world use CVE-IDs to help enhance information security, and CVE is formally recommended by the International Telecommunication Union (ITU-T) standards body for worldwide use.
"Because vulnerability information comes from many diverse sources, a common format makes it easier to analyze and import data without having to create custom tools or to do so manually," added Christey. "Encouraging the use of CVRF means CVE and other vulnerability information consumers can reduce the effort needed to support the wide variety of formats currently in use. And because of its adoption by major vendors, CVRF has a better chance of success compared to earlier efforts, particularly as the need grows for automated exchange of vulnerability data."
About The MITRE Corporation
The MITRE Corporation is a not-for-profit organization that provides systems engineering, research and development, and information technology support to the government. It operates federally funded research and development centers for the Department of Defense, the Federal Aviation Administration, the Internal Revenue Service and Department of Veterans Affairs, the Department of Homeland Security, the Administrative Office of the U.S. Courts, and the Centers for Medicare & Medicaid Services, with principal locations in Bedford, Mass., and McLean, Va. To learn more, visit www.mitre.org.
High-Tech Bridge Web Site, July 2, 2013
CVE and Common Weakness Enumeration (CWE™) were the main topics of a July 2, 2013 press release by High-Tech Bridge SA entitled "ImmuniWeb Web Security Assessment SaaS is certified CVE and CWE Compatible" about their ImmuniWeb product achieving both Official CVE-Compatible status and Official CWE-Compatible status.
The release also includes a quote by CVE Compatibility Lead Robert A. Martin, who states: "We are always excited about having the CVE and CWE efforts adopted and used within commercial offerings but it is especially gratifying when it is by companies in other countries and markets, like High-Tech Bridge. Leveraging CVE and CWE in ImmuniWeb clearly makes business sense and it is directly helping their customers improve the speed and directness as they address vulnerabilities and weaknesses that are putting their organization's at risk."
Government Computer News, June 17, 2013
CVE and Open Vulnerability and Assessment Language (OVAL®) are mentioned in a June 17, 2013 article entitled "NIST, DHS push security automation to the next stage" on GovermentComputerNews.com. The main topic of the article is that automation is the future of network security and how "Agencies face challenges in getting to an automated environment, however, whether because of tight budgets, complex systems or automated tools that don't necessarily work together. The federal government is supporting the effort by developing the standards that are necessary for interoperable tools and offering intrusion detection and prevention as a service to agencies."
CVE and OVAL are mentioned in a section listing the components of the U.S. National Institute of Standards and Technology's (NIST) "Security Content Automation Protocol (SCAP), a suite of interoperable specifications developed at the National Institute of Standards and Technology in collaboration with the public- and private-sector security community. Although NIST's agenda for security automation goes beyond vulnerability management, SCAP in its present form, Version 1.2, deals primarily with endpoint compliance for configuration requirements. The specifications, contained in Special Publication 800-126, support automated configuration, vulnerability and patch checking, technical control compliance and security measurement." CVE is mentioned in the article as one of the enumerations used by SCAP as "standard nomenclatures and an official dictionary of items expressed using that nomenclature" and OVAL is mentioned as one of the languages used by SCAP for "expressing security policy, technical check mechanisms and assessment results."
The article was written by William Jackson.
NetworkWorld.com, June 14, 2013
CVE and Common Weakness Enumeration (CWE™) were mentioned in a June 14, 2013 article entitled "Breaking down the OWASP Top 10 security flaws for 2013: What's changed from OWASP's 2010 list and why" on NetworkWorld.com's "Security Blanket" blog.
CVE and CWE were mentioned in a section about why web application denial-of-service attacks (DoS) attacks were not included on the OWASP list in quotes by CVE/CWE Technical Lead Steve Christey, as follows: "Regarding application DoS – I don't know if we should be so dismissive of it. The (negative) commentary I've seen on application DoS is concentrating on network-based attacks. (However,) there are other resource-consumption vulnerabilities that are gaining popularity in CVE, such as unrestricted XML entity expansion, a.k.a. "billion laughs" (CWE-776) (that causes a DoS due to) memory consumption. Another example is algorithmic complexity involving hash collisions that slow down hash-table lookups, which was all the rage about a year ago, (that causes a DoS due to) CPU consumption. More recently, Ruby and/or Ruby-based applications have been getting hit with a number of other resource-consumption issues, such as a memory DoS by forcing the creation of a large number of symbols."
Christey continued, "While I don't know how often these are exploited, and they may be difficult to detect, or how often they'll be exploited in the future, these kinds of application DoS issues are becoming popular. As code-execution vulnerabilities get harder to find, I suspect we will see more of these. This might not be enough to merit inclusion in the OWASP Top Ten, but is definitely something to watch out for."
The article was written by Jonathan Lampe
DarkReading.com, June 13, 2013
CVE was mentioned in a June 13, 2013 article entitled "Don't Take Vulnerability Counts At Face Value" on DarkReading.com about unreliable vulnerability data and statistics. The article is a preview of a briefing entitled "Buying into the Bias: Why Vulnerability Statistics Suck" by Open Source Vulnerability Database (OSVDB) content manager Brian Martin and MITRE CVE Technical Lead Steve Christey currently scheduled for presentation on July 31, 2013 at Black Hat Briefings 2013.
CVE is mentioned in a section about the impact of the uncertainty in vulnerability statistics, when the author states: "A major source of confusion is the wide range of flaw counts. Recent reports from Sourcefire and Symantec, for example, were based on vulnerabilities tallied from the National Vulnerability Database and its collection of flaws that have a Common Vulnerability and Exposures (CVE) identifier. Thus, the two reports had very similar numbers: 5,281 and 5,291, respectively. On the other hand, the Open-Source Vulnerability Database (OSVDB) seeks out a large number of additional vulnerability reports and posts the highest bug counts -- 9,184 for 2012, 75 percent higher than that reported by Sourcefire. Other vendors that have their own sources of vulnerability data typically land between the two extremes. Hewlett-Packard's Zero-Day Initiative, which buys information on serious software security issues, claimed to have found 8,137."
The article also quotes Steve Christey, who states: "At the very least, it is important that people understand the limitations of the data that [is] being used and be able to read reports based on that data with a sufficient dose of skepticism."
The article was written by Robert Lemos.
Network World, May 28, 2013
CVE, Trusted Automated eXchange of Indicator Information (TAXII™), and Structured Threat Information Expression (STIX™) are mentioned in a May 28, 2013 article entitled "Feds Take A Leadership Role Toward Self-Defending Networks: Push for standards, continuous monitoring, and security automation may encourage industry and commercial sector collaboration and support" on NetworkWorld.com.
CVE, TAXII, and STIX are mentioned with regards to standards when the author discusses what he says are the three steps that are needed to realize "self-defending networks," including embracing standards, continuous monitoring, and acceptance of security automation: "Embracing standards. The secure cyber ecosystem concept is built on top of the Secure Content Automation Protocol (SCAP) leveraging a number of standards like Common Vulnerabilities and Exposures (CVE, Common Configuration Enumeration (CCE), and Common Platform Enumeration (CPE). These provide a foundation on the vulnerability and configuration side but self-defending networks need standard data formats and transport protocols for threats like the MITRE Trusted Automated eXchange of Indicator Information (TAXII) and Structured Threat Information eXpression (STIX). It's likely that some of the Trusted Computing Group (TCG) standards for chain-of-trust, platform authentication, and data exchange will also come into play."
The author concludes the article by stating: "It's nice to see that the Federal government recognizes this and is willing to push for technology innovation and change. This effort has the potential to bear fruit if the Feds can build security community awareness and push vendors and the commercial market to join the effort."
The article was written by Jon Oltsik.