CVRF v1.0

1. Introduction and Impetus

In recent years, significant progress has been made in information system vulnerability categorization and severity ranking. These advancements have tangibly benefited security operations such as cross-domain security analysis, first response planning, and patch management. The missing link is a single common framework for encoding security information, and the most obvious benefactor is the creation of vulnerability reports and similar documents to distribute across different organizations.

1.1 Problem Statement

Conventionally, the documentation of vulnerabilities is an ad hoc, producer-specific, and overtly nonstandard process. Document producers compile, collate, and produce their own versions of a vulnerability document that may or may not be similar to comparable reports by other vendors. To see an example of this, consider the 2009 multivendor “Outpost24 TCP” vulnerability report from major document producers such as Cisco [4], Microsoft [5], CERT [6], and Secunia [7]. Because each producer employs a unique and non-cooperative document structure, document consumers must manually parse individual reports to find information that is germane to their environments. Additionally, the documents are typically flat and do not facilitate or support automated processing.

1.2 Vulnerability Report Differences

For a solid example of this dissimilarity, see tables 1.1 through 1.4. Four vulnerability reports that detail the previously referenced Outpost24 TCP vulnerability are procured from the Internet. The reports are stripped bare of content and format and reduced to their core constituent components. Only a field title and a corresponding data type remain.

Table 1.1 Cisco Systems Vulnerability Report

Table 1.2 Microsoft Vulnerability Report

Table 1.3 CERT-FI Vulnerability Report

Table 1.4 Secunia Vulnerability Report

When examining vulnerability reports from different document producers, the differences are vast and the issues of correlation become clear. Because no vendor, research organization, or coordinator works within the same framework, vulnerability report formats vary wildly. This lack of a common documentation framework causes multiple problems.

1.2.1 Multiple Formats Mean More Complexity

First and most obviously, when there is more complexity, there is extra effort and overhead introduced. The attributes defined in one format need to be interpreted correctly, mapped (or partially mapped), and then converted into the attributes of another format.

For example, when multiple reports are compared, any unintentional misuse or subjective interpretations could trigger potential flaws when addressing vulnerability issues. Theoretically, the complexity of interpretations and mappings is O(n2)when sharing vulnerability information among ndifferent formats. This is the same sort of complexity encountered with the classically flawed computer-science sorting algorithm known as a bubble sort. This algorithm requires multiple passes and comparisons over a list of items. As the input grows, the complexity grows quadratically, which is the same situation a user would encounter with multiple uncorrelated reporting formats.

1.2.2 Organizational Compatibility Issues

Additionally, multiple reporting formats create a substantial compatibility issue. When one format is updated by either the removal of an existing field or the addition of a new one, any organization that uses multiple formats must cope with these changes.

1.2.3 Stunted Extensibility

Finally, without the common framework for adding new attributes, each format has to be modified to satisfy the needs of any potential future attributes. It is nontrivial to make the same new attribute consistently defined and understood across all formats. This makes expansion of existing multiple frameworks extremely difficult.

Back to Index