To date, a major gap exists in vulnerability standardization: there is no standard framework for the creation of vulnerability report documentation. While the computer security collective has done a bang-up job in several other areas, including categorizing and ranking the severity of vulnerabilities in information systems with the widespread adoption of the Common Vulnerabilities and Exposure (CVE) dictionary and the Common Vulnerability Scoring System (CVSS), this lack of standardization is evident in every vulnerability report, best practice document, or security bulletin released by any vendor or coordinator. This blog post explores a nascent standard to close this gap.
Lack of Standard Promotes Chaos
Conventionally, the documentation of vulnerabilities is an ad hoc, producer-specific, and overtly non-standard process. Each vendor compiles, collates, and produces their own version of a vulnerability document that may or may not be similar to comparable reports by other vendors. To see examples of this, consider the 2008 multi-vendor “outpost24 TCP” vulnerability report from major producers such as Cisco, Microsoft, or CERT. Because each producer employs a unique and non-cooperative document structure, users must manually parse individual reports to find information that is germane to their environments. Additionally, the documents are typically flat and do not facilitate nor support any sort of automated processing.
From Standardization Comes Cohesion
Working towards fixing this industry-wide quandary, the Industry Consortium for the Advancement of Security on the Internet (ICASI) — a vendor-agnostic, industry-wide think tank that tackles international and multi-vendor security challenges — has adopted the Common Vulnerability Reporting Framework (CVRF) project. Chaired by Cisco, ICASI’s CVRF working group has assembled a team of experts that collectively have written, published, and studied many forms of vulnerability documentation. The short-term goal was to have a core team that could expand existing vulnerability documentation formats, and subsequently integrate a best-of-breed solution into a common XML-based framework. The fruit of this labor is intended to evolve into an open standard that brings consolidation and consistency to the vulnerability documentation space and grow organically among stakeholders. When complete, CVRF will standardize vulnerability documentation in the form of an XML-based framework that is available to anyone who chooses to use it. Independent discoverers of bugs, large vendors, security coordinators, as well as end users of security response efforts worldwide will be able to write CVRF documents in order to share critical vulnerability-related information, accelerating information dissemination, exchange, and incident resolution. At the end of the day, producers of vulnerability documents will benefit from a faster and more consistent report creation process, and users of the documents will gain the ability to find relevant information more quickly and easily.
The primary use case envisioned for CVRF is for the producer of a vulnerability report to construct an advisory using the CVRF grammar and make the raw XML available as well as transform it (using XSL style sheets, or some other method) into a variety of other formats (txt, HTML, etc.) that are distributed to their constituency. CVRF was not designed to be an “accompanying” document that is written along side the existing formatted advisories; it is a whole new solution to construct structured vulnerability documents intended to supplant all existing formats. Given that CVRF is XML-based, it is expected that advanced end users would subscribe to a CVRF-specific feed, which could be automatically parsed to be inserted into a database, ticket system, automagical-remediation sorcery-ware, etc.
Rather than trying to reinvent the wheel, the CVRF Working Group is defining a syntax that incorporates the various element definitions that are already defined by other markup languages. In particular, CVRF is building a grammar using DocBook for general page structure and advisory text, NVD’s XML syntax for vulnerability definition, and NIST’s XML definition of a CVSS Score. Additionally, the team is considering how to accommodate the embedding of other SCAP definitions, such as OVAL and CPE.
Once CVRF 1.0 is penned, it is hoped that CVRF will find a custodial home, akin to how FIRST took over CVSS when we completed that in 2004. While there are no current plans to relocate CVRF, as we draw closer to a finished product, the ICASI board will work to find the best place for CVRF to live and grow within the industry.
As of this writing, CVRF is in the final stages of its initial development. The CVRF format is nearly complete and the XML grammar is being developed alongside. The working group is on track for an end-of-year completion and an early 2010 release and subsequent evangelism. Those who wish to find out more about CVRF should check the ICASI CVRF website