Use Cases

The OVAL Language enables interoperability between security products by providing a standard XML language with which to exchange information. It allows tools in different vertical markets to leverage other tools that accomplish different tasks. For example, a vulnerability assessment tool can leverage a vulnerability research service, or a compliance checking engine can leverage Government security guidance.

Dividing the OVAL Language into three distinct schemas that represent the three phases of the checking process enables organizations to implement only those parts of the OVAL Language that truly make sense for their tool(s). The advantage of this is that the OVAL Language is available to a wider range of security tools, thus enabling greater interoperability within the industry. The cases below exemplify some of the needs for a standard like OVAL Language, and its potential uses within the security community.

Security Advisory Distribution

One acknowledged need within the security industry is for application and operating system vendors to publish vulnerability information in a standard, machine readable format. The benefit of this is two-fold; first, it provides scanning tools with immediate access to content that can be used to assess the security posture of a system, and second, it moves the authoring of the technical details of a vulnerability from the reverse engineering efforts of the scanner tool developer, to a more authoritative source, the developer of the vulnerable software.

Vulnerability Assessment

Currently, organizations that develop vulnerability assessment tools also need to employ a team of content developers. The role of this team is to investigate vulnerabilities as they become known, gather all of the available information for a given vulnerability, run various tests against live systems to examine the parameters that indicate the presence of a vulnerability, develop the tests in the language of the tool in question, and do this all under a very strict time requirement. The final requirement obviously runs counter to those before it, and results in the potential for analysis to not be completely fulfilled before a test absolutely has to be disseminated to the vendor's customers.

For vendors, having vulnerability information structured in a standard format allows them to quickly consume data from multiple sources, and lets them refocus some of their resources away from content generation, and onto tasks to enhance the functionality of their tool.

From the tool customer's perspective, the primary requirement for having a standard content format is that it demystifies the vulnerability assessment process, and provides them with the ability to do apples-to-apples comparisons of tools. Having a well-documented, standard format provides users with the information they need to be able to understand the details of an issue, and to determine how a specific tool is conducting its business. The open standard also provides users with the opportunity to generate their own statements in the language and, if a tool allows, interpret them. When conducting tool comparisons, given a specific set of definitions, each tool tested should return the same result. If this is not the case, it is no longer a result of tools taking different approaches to detecting a vulnerability, and removes the burden from the customer to determine which they think returns the most accurate results. The end result is that the customer can focus more on selecting a tool with the features that best meet their needs, and less on the more difficult problem of which does the correct job of detecting vulnerabilities.

Patch Management

The needs of the patch management vendors are similar to those of the vulnerability assessment vendors. There is some amount of reverse engineering that must be done in order to generate content for their tool to be able to apply a patch. Having this information generated by the software vendor, and formatted in a standard format removes the reverse-engineering requirement, and allows content to be provided to the end customers in a more timely fashion. A second requirement for this class of tools is to be able to easily consume vulnerability assessment results from a variety of scanning tools. If these results were offered in a standard format, interoperability between tools would no longer be an issue.

Configuration Management

Configuration management tools concern themselves with examining a machine's configuration state, comparing it against a known good or mandated configuration state, and reporting the results. There are a number of publicly available best practice configuration guides (e.g., The National Security Agency (NSA) Configuration Guides), and many more developed specifically for individual organizations. In many cases, these guides exist in paper form only, and it is up to the IT Staff to translate the document into something that can be applied, and enforced on a consistent basis. There are also automated solutions available, most notably the Center for Internet Security's Benchmark tools, which can scan a system for compliance against a given configuration, and offer tailoring capabilities to suit the specific needs of an organization. Unfortunately, these tools often rely upon proprietary data formats, making it difficult to introduce new policies to the tool, or move data from one tool to another.

Having a standard language for expressing system configuration issues offers many benefits in this area. Firstly, a single configuration specification need only be written once. At this point it can be consumed by any configuration management tool. Secondly, organizations can more easily develop and maintain their own configuration standards, as it only requires learning a single language, and not a language specific to a particular tool. Finally, as with some of the cases above, divesting the language from the tool provides the tool vendor with a wider repository of content, and allows them to focus more on functionality and features.

Auditing and Centralized Audit Validation

Audit validation is responsible for providing reports about the state of a machine at any given time in the past. There are two basic needs in this area; first and foremost is capturing machine configuration information at a level of granularity that allows an organization to monitor, track, and reconstruct the transition of a system's configuration from one state to another. The second need is that the data be stored in a standardized, data-centric format, thus ensuring that it is not bound to a specific tool, which may or may not be available at the time it is necessary to review the data.

Security Information Management Systems (SIMS)

SIMS rely upon the output of a variety of security, auditing, and configuration tools, as well as their own agents, to build a comprehensive view of the security posture of an organization's network. Clearly, the fewer data formats the SIM needs to understand, the more flexible and powerful this tool can be. As with the Patch Management class of tools, standardizing the data exchange formats between tools greatly simplifies the interoperability requirements, and provides the end-users with a wider array of applications from which to choose.

System Inventory

A common issue that exists, not only for security tools, but any tool that is trying to conduct some sort of evaluation of a computer system, is determining the attributes of that system (e.g., operating system, patch level, installed applications etc.), and being able to convey those attributes clearly and consistently. Currently, there is no universally accepted method for gathering the attributes from a system, nor is there a common way to express those attributes such that they can be easily consumed by another application. The need for this capability is widely acknowledged, and its use would be widespread.

Page Last Updated: June 13, 2006