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.

September 2009

Government Computer News, September 23, 2009

An article about CVE’s 10-year anniversary entitled "CVE: Ten years and more than 38,000 vulnerabilities catalogued" was published in Government Computer News on 23 September 2009. The article talks about the origins of CVE, how it has grown over since it launched on 29 September 1999, and how it has inspired new efforts such as CWE and its Top 25 list. The article also includes quotes from CVE Co-Creator and Technical Lead Steve Christey and CVE Compatibility Lead Robert A. Martin. The article was written by William Jackson.

CrossTalk, The Journal of Defense Engineering, September/October 2009

An article entitled "Making Security Measurable and Manageable" by CVE Compatibility Lead and CWE/CAPEC Program Manager Robert A. Martin was published in the September/October 2009 issue of CrossTalk, The Journal of Defense Engineering.

The article explains how measurable security and automation can be achieved by having government and public efforts address the creation, adoption, operation, and sustainment of their information security infrastructures in a holistic manner and by using common, standardized concepts to define the data (CVE, CCE, CPE, CAPEC, CWE, etc.), communicating this information through standardized languages (OVAL, XCCDF, CEE, etc.), sharing the information in standardized ways (OVAL Repository, NVD, etc.), and adopting tools and services that adhere to these standards.

May 2009

Computerworld, May 11, 2009

CVE was mentioned in an article entitled "How SCAP Brought Sanity to Vulnerability Management" in Computerworld on May 11, 2009. The main topic of the article is the U.S. National Institute of Standards and Technology’s (NIST) Security Content Automation Protocol (SCAP).

CVE is mentioned when the author explains that "SCAP is part of the Information Security Automation Program and is made up of a collection of existing standards. These standards include some that many of us are already familiar with, such as the Common Vulnerabilities and Exposures (CVE) and the Common Vulnerability Scoring System (CVSS). Additionally, it includes the Common Platform Enumeration (CPE), a standard to describe a specific hardware, OS and software configuration. This is helpful for enumerating assets, giving you your baseline information to apply all of this data; the Common Configuration Enumeration (CCE), very similar to CVE but dealing with misconfiguration issues; the Open Vulnerability and Assessment Language (OVAL) to provide schemas that describe the inventory of a computer, the configuration on that computer and a report of what vulnerabilities were found on that computer; and Extensible Configuration Checklist Description Format (XCCDF), a description language to help you apply your technical policies and standards to your scanning tools."

The author also provides an example of SCAP in action: "Let’s see how this helps me in building a real solution. As a head of a vulnerability management program as discussed earlier, I am sitting on data from application security assessment tools, host and network scanners, and database vulnerability and configuration scanners. In reality, this includes multiple products and services for application security, as well as multiple tools for host and network assessments. I set out by taking advantage of APIs when available from the assessment tool providers as well as XML data feeds. Utilizing the code I’ve just written to automate the movement of the data, I now need to map this information to a normalized schema, taking advantage of the SCAP standards. This is a big deal! I now have a common way to describe the vulnerabilities. I can eliminate duplicates that reference the same CVE on the same platforms."

The article was written by Ed Bellis.

Government Computer News, May 7, 2009

CVE was mentioned in an article entitled "Draft guidelines issued for using SCAP to automate security validation" in Government Computer News on May 7, 2009. The main topic of the article is the U.S. National Institute of Standards and Technology’s (NIST) Special Publication 800-117: Guide to Adopting and Using the Security Content Automation Protocol that specifies how enterprises can use its Security Content Automation Protocol (SCAP), and a revised version of its testing requirements that security products using SCAP must meet to achieve SCAP validation entitled Draft NIST Interagency Report 7511: Security Content Automation Protocol Validation Program Test Requirements, Revision 1.

CVE is mentioned in the article as one of the six open standards SCAP uses for enumerating, evaluating, and measuring the impact of software problems and reporting results: "Common Vulnerabilities and Exposures, a dictionary of names for publicly known security-related software flaws." The other five standards are Open Vulnerability and Assessment Language (OVAL), Common Configuration Enumeration (CCE), Common Platform Enumeration (CPE), Extensible Configuration Checklist Description Format (XCCDF), and Common Vulnerability Scoring System (CVSS). CVE is mentioned a second time when discussing NIST’s recommended guidelines for using SCAP: "Organizations should use SCAP for vulnerability measurement and scoring. SCAP enables quantitative and repeatable measurement and scoring of software flaw vulnerabilities across systems through the combination of the Common Vulnerability Scoring System (CVSS), CVE, and CPE."

Comments on draft guidelines 800-117 are due to NIST by June 12, 2009 and should sent to 800-117comments@nist.gov and include "Comments SP 800-117" in the subject line.

The article was written by William Jackson.

April 2009

DarkReading.com, April 8, 2009

CVE was mentioned in an article entitled "The Rocky Road To More Secure Code" on DarkReading.com on April 8, 2009. CVE is mentioned as follows: "Steve Christey, principal information security engineer for MITRE, who also works on the Common Vulnerability and Exposures (CVE) program, says CVE data shows vulnerabilities in major software products, such as those from Microsoft, are becoming less rampant. "Vulnerabilities in products from major vendors like Microsoft still get announced every month. But it’s often very difficult to detect [these vulnerabilities], and they require a large amount of time and investment from the people who discover them. That’s one way to measure that software is becoming more secure: It’s taking longer to find significant vulnerabilities in software." Christey says the good news is these more obscure bugs are more difficult to detect and, therefore, more difficult and expensive to exploit. The bad news is that has put the bull’s eye on third-party applications, especially in the Web 2.0 space: "Web 2.0 doesn’t have a culture of security from the moment of conception of an idea all the way to deployment," he says. "Software assurance needs to be a holistic approach that crosses all phases of development. But many of the third-party developers have not gone down this road."

January 2009

SANS Web Site, January 23, 2009

CVE was mentioned in Draft 1.0 of the "Twenty Most Important Controls and Metrics for Effective Cyber Defense and Continuous FISMA Compliance" consensus list released by a consortium of federal agencies and private organizations on February 23, 2009. The document, which uses "knowledge of actual attacks and defines controls that would have stopped those attacks from being successful," includes 15 critical controls that are subject to automated measurement and validation and an additional 5 critical controls that are not.

CVE is mentioned as follows in a section about why the list is so important for chief information security officers (CISOs), chief information officers (CIOs), federal inspectors general, and auditors: "This effort also takes advantage of the success and insights from the development and usage of standardized concepts for identifying, communicating, and documenting security-relevant characteristics/data. These standards include the following: common identification of vulnerabilities (Common Vulnerabilities and Exposures-CVE), definition of secure configurations (Common Configuration Enumeration-CCE), inventory of systems and platforms (Common Platform Enumeration-CPE), vulnerability severity (Common Vulnerability Scoring System-CVSS) and identification of application weaknesses (Common Weaknesses Enumeration-CWE). These standards have emerged over the last decade through collaborative research and deliberation between government, academia and industry. While still evolving, several of these efforts in standardization have made their way into commercial solutions and government, industry, and academic usage. Perhaps most visible of these has been the Federal Desktop Core Configuration (FDCC) which leveraged the Security Content Automation Program (SCAP)."

The draft is available for public review and comment at www.sans.org/cag, www.csis.org, and www.gilligangroupinc.com until March 23, 2009.

 
Page Last Updated: January 06, 2010