Use of the Common Vulnerability Reporting Format (CVRF) for Oracle’s Security Advisories
By Eric P. Maurice-Oracle on Jul 20, 2012
Hi, this is Reshma Banerjee. I am a member of the Security Alerts group within the Global Product Security Team at Oracle. My primary responsibilities include working with security researchers on the vulnerabilities they report to Oracle and engaging with the various engineering organizations at Oracle to ensure timely delivery of security fixes in the Critical Patch Updates and Security Alerts.
As announced in a previous blog entry, starting with the July 2012 Critical Patch Update, Oracle will be producing the security advisory in an XML format that conforms to Common Vulnerability Reporting Format (CVRF version 1.1). Of course, Oracle will also continue to produce its Security Alert and Critical Patch Update advisories using the existing format (As a reminder, all Security Alert and Critical Patch Update Advisories are published at http://www.oracle.com/technetwork/topics/security/alerts-086861.html).
The Common Vulnerability Reporting Framework is an XML-based standard that enables sharing of vulnerability information in a machine-readable format. Originally derived from the Internet Engineering Task Force (IETF) draft Incident Object Description Exchange Format (IODEF), this format was then developed by the Industry Consortium for Advancement of Security on the Internet (ICASI). ICASI is a non-profit forum which enables industry collaboration for the development of security solutions and practices to address global security challenges. Oracle is a member of ICASI.
CVRF is a good example of a useful work-product that can come up from such a pragmatic forum of security-dedicated organizations. It provides an XML format that may be used by any vendor to publish relevant information pertaining to vulnerabilities. This includes among other useful information CVE# to identify vulnerability, CVSS score to rate the relative severity of a vulnerability, affected products and versions, mitigation instructions. We believe that CVRF will help customers with diverse IT environments be more efficient in assessing and processing security vulnerability advisories from different IT vendors. Having been personally involved with CVRF since the summer of 2009, I believe CVRF provides two key benefits:
(1) It provides a consistent way to depict security information thus simplifying the interpretation of the advisories, and
(2) It provides a machine-readable format for the interpretation of security advisories, thus allowing automation (and integration of the advisories in, for example, vulnerability scanning tools).
In absence of common security advisory format, IT industry vendors publish their security advisories and bulletins using their own proprietary format. Most organizations have to contend with heterogeneous IT infrastructure and therefore need to deal with multiple vendors. Consequently, security-conscious organizations need to deal with interpreting security advisories from multiple vendors. While security advisories from the various different IT vendors may include similar information, the differences in format and terminology cause, at best, customers to waste a lot of time interpreting security advisories, and at worst, these differences create confusion and errors as a result of the different terminology being used. To a large extent, this problem is similar to the problem that existed prior to the wide adoption of the Common Vulnerability and Exposures number (CVE #) with the identification of individual vulnerabilities.
As IT vendors adopt CVRF, and use it in their security advisories and bulletins, it will become much easier for customers to interpret relevant security information. In addition, customers will be able to more easily write their own automation tools to get the pertinent information from the various advisories without having to cope with multiple formats. Customers will also be able to write tools to automate the action to be taken if they find information in the advisories that affects them. Oracle plans to continue contributing to the CVRF working group and providing CVRF advisories with future Critical Patch Updates and Security Alerts.
For more Information:
ICASI’s web site is located at http://www.icasi.org/
More information on CVRF 1.1 is located at http://www.icasi.org/cvrf-1.1