CVRFÂ v1.0
2. Proposed Solution
As described above, while wildly different, each reporting format does contain certain portions of similar or even identical types of information (date fields, overview-type fields, impact and remediation fields).
The issue is that there is no common format or nomenclature among the reporting formats. To speed up the document production and consumption, a common, machine-readable format for security information exchange is required.
The proposed solution, the Common Vulnerability Reporting Framework (CVRF) is an XML-based framework that predefines a large number of fields designed with extensibility and robustness in mind. These fields will be consistent in naming and data type across the board, so any organization that adopts and understands CVRF will have no problem in producing or reading CVRF documents from another CVRF-equipped organization. Resulting documents based on this framework will all adhere to a common format that will become commonplace and familiar for all users.
2.1 From Standardization Comes Cohesion
The Industry Consortium for the Advancement of Security on the Internet (ICASI), a vendor-neutral, industry-wide think tank that tackles international and multivendor security challenges, has adopted the CVRF project. Chaired by Cisco, the ICASI CVRF working group has assembled a team of experts that collectively have written, published, and studied many forms of vulnerability documentation.
The goal has been to establish a core team that could expand existing security documentation formats and subsequently integrate a best-of-breed solution into a common XML-based framework. The outcome of this goal is to create an open standard that brings consolidation and consistency to the security documentation space and grows organically among stakeholders.
When complete, CVRF will standardize security 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, and end users of security response efforts worldwide will be able to write CVRF documents to share critical vulnerability-related information. CVRF will enable the acceleration of information dissemination and exchange as well as incident resolution. Ultimately, producers of vulnerability documents will benefit from a faster and more consistent report creation process, and users of the documents will be able to find relevant information more quickly and easily.
2.2 CVRF Roles
There are two contextual roles that users of CVRF will assume: a document producer and a document consumer. A given CVRF user may assume one or both of these roles.
2.2.1 Document Producer
Document producers are the top-level CVRF role. They create one or more CVRF documents and distribute them in a one-to-many fashion. The document producer handles all the details of production, including responsibility for the veracity of the information as well as the actual distribution (using such methods as HTTP, SOAP, or automated feeds). Typical document producers are the following:
- Vendors
- Coordinators
- Researchers
One or more document consumers are the assumed recipients of CVRF documents.
2.2.2 Document Consumer
A document consumer is any end user who examines and acts on information in CVRF documents. Typical document consumers are the following:
- Security practitioners
- Administrators
2.3 Approach
The CVRF working group used a two-pronged approach. The first part was based on industry outreach to collect a wide sample of reports from the industry. The second part was to survey end users about the similarities and differences in current vulnerability reporting as well as what future reporting should address.
With this information, the working group defined a syntax that incorporates an array of elements to define structures typically found in conventional vulnerability reports or security advisories. Items such as vulnerability information, exploit status, affected platform, and remedial information are all cleanly and discretely represented.
Additionally, some existing element definitions are being incorporated. These definitions are already defined by other markup languages, such as Security Content Automation Protocol (SCAP) [8] standards, and include the Common Product Enumeration (CPE) [9], the Common Weakness Enumeration (CWE) [10], and the Open Vulnerability and Assessment Language (OVAL) [11].
