Managing Cyberthreats in a Standard Fashion
Industry heavyweights release a framework designed to cut through the report clutter.
The cybercommunity has a new resource at its disposal to identify and mitigate issues across networks and systems. This standardization tool can make reporting problems more uniform, which should result in faster response times. Developers designed an open format that will be machine- and human-readable to automate processes, marking a divergence from standards presented in the past.
Dubbed the Common Vulnerability Reporting Framework (CVRF) Version 1.0, the resource is an XML-based language designed to enable members of the different organizations in the cybercommunity to share security-related information in a single format. The framework was created by the Industry Consortium for Advancement of Security on the Internet’s (ICASI’s) CVRF working group, which includes the consortium’s founding members Cisco Systems, Intel Corporation, IBM, Juniper Networks, Microsoft Corporation and Nokia. These companies invited nonmembers Red Hat and Oracle to participate as well to round out the expertise.
The group also surveyed enterprise users about similarities and differences they notice in vulnerability reporting and what future reporting methods should address. After considering responses, group members expanded existing security documentation formats and integrated a best-of-breed solution into the common, open XML-based framework. Michael Caudill, the ICASI executive director when the CVRF was put together and an incident manager at Cisco, says the CVRF “brings consolidation and consistency to the security vulnerability documentation space and is expected to grow organically among stakeholders.”
Caudill says members of the information technology community have called attention to a need for a way to take in and understand vulnerability information. “ICASI took this up because we needed to lead as an industry and provide this,” he explains. He continues that the power and utility of the framework are bringing together members of industry to agree on and define the common elements of data necessary for understanding a vulnerability. “CVRF can be used by vendors, researchers, customers, government organizations and others to quickly disseminate information around a vulnerability so that automated systems can help analyze the risk involved,” Caudill says.
Currently, document creators generate their vulnerability advisory information in a visual format such as HTML or PDF. “But, the documents are not organized such that a computer can easily discern what the information is,” Caudill states. This leads to confusion about what the computer is reading. It might be a title or a software version, for example. If it is a software version, the machine has to determine if the version is vulnerable or fixed or might have features that could help mitigate the problem. “You need to have a defined format, which is what CVRF accomplishes by defining common data elements that are needed,” Caudill explains. He adds that defining common field names that can be used industrywide, thus preventing each organization from having to invent its own names, “is the accomplishment.”
Caudill uses an analogy with technology more familiar to most people to illustrate his point. “Let’s say you create a flyer in something like Microsoft Publisher and save it as a PDF file. That way, the folks whom you want to share it with do not have to have Microsoft Publisher on their system; they only have to be able to view a PDF file. Then the consumers of your document can read that PDF file within some Web browsers or via the Adobe PDF reader,” or other compatible programs, he explains. 
The CVRF uses XML as its common file format by putting the information to be conveyed in an arrangement that can be understood by other programs. Both in the Publisher example and the case of the CVRF, the recipient of the documents must be able to consume the information in a relevant manner.
“Existing software can easily build in the capabilities to read in the XML,” Caudill says. “But much like the PDF example, looking at the text of a PDF file is not as useful as looking at the PDF in a rendered visual format. Similarly, looking at the XML document in the CVRF format can be done. However, it will be most useful to feed information in an automated form to a program or capability at the other end that can consume that information and make use of it at the speed” enabled by computer automation. Organizations that want to produce CVRF files can download and follow the schema available on the ICASI CVRF website.
Other categorizing and ranking systems such as the Common Vulnerabilities and Exposures (CVE) dictionary and the Common Vulnerability Scoring System were made available in the past, but such documents lacked standardization, Mike Schiffman of Cisco writes in a white paper about the topic that is also available through the ICASI CVRF site. The new framework takes an approach that resembles predecessors such as the Incident Object Description Exchange Format, or IODEF, developed to help computer security incident response teams better share incident information among themselves. Another existing framework is the Common Announcement Interchange Format, which also uses an XML format to exchange security information.
However, according to Caudill, no format currently is in widespread use. He explains that the “CVRF is important because it helps to provide a common framework or format for security vulnerability reports and documentation. If you look at the security advisories that are posted every day by vendors and security researchers, you will see a variety of formats with some common informational elements, but the formats are designed for human readability and visual presentation.”
To address threats, humans must absorb and understand the information before determining the other actions necessary to ensure security. “By creating a common framework that everyone can use, CVRF describes in a machine-readable format standard informational elements that are needed to understand vulnerabilities, their risk to an organization and what can be done to mitigate those vulnerabilities,” Caudill says.
The XML format in the framework will allow for more automation of responses, though neither the XML nor the CVRF itself actually automates actions to address potential dangers. “Today there are many tools that exist to help manage networks,” Caudill explains. “There are vulnerability scanners that report on vulnerabilities that exist within a network. There are network management tools that attempt to provide security risk and policy compliance information within an enterprise.”
Many of those resources have people behind the scenes who are manually updating the information about the vulnerabilities that they are examining. Even if some form of automation is possible for those advisories, a solution often is required for each vendor because a single format is not used, he adds.
Using XML provides a standard way of representing data elements as they are transferred between systems. No proprietary data formats are necessary. This enables easier sharing among people who produce vulnerability documents and helps those who accept them to take action no matter the organizations involved. For example, using current reporting methods, a variety of software users could identify a problem and report it back to the manufacturer each using a different format. The professional handling the issue for the manufacturer has to read through each one and extract the necessary information to understand and mitigate the risk. With the CVRF, groups could make their reports in the same format, and machines as well as humans could use the information to resolve the complaints.
“The CVRF schema is the Rosetta Stone that explains the elements of the document to a consumer in order to parse the data,” Caudill says. He believes the framework will benefit users because instead of many groups reporting issues using their own 60 to 80 individual data elements, one set of elements exists for everyone. “Really, it’s agreeing about the data elements that people need to know about a vulnerability so they can act on it,” he explains.
Unlike HTML, XML is not designed to showcase information in a visual format, nor does it have rigid tags. With XML, users can define their own tags for whatever data elements they choose to include. These tags tell the machine applications what they can expect.
Because companies that lead their industry produced the framework, writers hope that it will catch on in other organizations. However, even among those responsible for the framework, implementation is voluntary and falls under different time frames. Mark J. Cox, the director of security response at Red Hat, announced via his blog his company’s plan for the framework on May 18, 2011, a day after the official release of the CVRF. According to Cox, Red Hat is not yet providing an official archive with CVRF representations of its advisories, but it has created internal tools to support the framework and to create framework documents automatically based on the company’s advisory database. ICASI is pushing for the adoption and increased use of the framework among stakeholders.
Caudill says any organization responsible for a software or hardware product could and should consider using the new framework. “That responsible party could be a commercial vendor or could be an open source community maintaining particular code,” he adds. The research community also can use the tool to communicate vulnerability information to vendors. In addition, vulnerability management or vulnerability scanning systems could make use of the information.
“For example, many vulnerability scanners will scan a server and will report that some service is vulnerable to a certain CVE identification,” Caudill explains. “Often that product will contain information around that CVE number, such as the product affected and steps to mitigate the problem. CVRF could be used to automatically update the knowledge base of information around a particular CVE.”
Though it took more than two years from the time the working group formed to the release of the CVRF, work on it is not finished. “ICASI’s intention is that CVRF be a living framework that will be enhanced and revised as necessary,” Caudill explains. “ICASI plans to continue supporting CVRF to ensure that it will remain both stable and free for use by all.” No plans are in place now to publish the next version of the resource. However, as it gains wider adoption and users gain experience with it, improvements and revisions will be considered, and future revisions planned as applicable.
WEB RESOURCES
CVRF: www.icasi.org/cvrf
Cisco: www.cisco.com
Mark J. Cox CVRF Blog: www.awe.com/mark/blog/20110518.html
