Use Cases Guide

The OVAL Adoption Program was established to:

  • Enable interoperability among security products.
  • Educate vendors on best practices regarding the use and implementation of OVAL.
  • Provide vendors with an opportunity to make formal self-assertions about how their products utilize OVAL.
  • Allow MITRE to gain deeper insights into how OVAL is, or could be, utilized so that OVAL can evolve in a way most useful to the community.

The current set of supported OVAL Use Cases is detailed below. Additional use cases will be documented as they emerge through the continued operational application of OVAL.

OVAL Capabilities

OVAL enables interoperability between security products by allowing them to exchange information through a standard XML language. It allows products in different vertical markets to leverage other products that accomplish different tasks. For example, a vulnerability assessment product can leverage a vulnerability research service to quickly and automatically check for the latest vulnerabilities. A compliance checking engine can leverage government security guidance to automatically monitor compliance without the need to translate traditional prose based guidance.

In order to allow organizations to implement only those parts of OVAL that make the most sense for their products, a set of OVAL Capabilities has been defined to create logical functionality groupings. The advantage of this is that OVAL is available to a wider range of security products, thus enabling greater interoperability within the industry. This set of OVAL Capabilities is mapped to the supported OVAL Use Cases to ensure that a clear connection is made between a given Use Case and the related OVAL Capabilities. Specific requirements, for each Capability, are described in the OVAL Adoption Requirements.

Five OVAL Capabilities have been defined:

  • Authoring Tool — A product that aids in the process of creating new OVAL files (including products that consolidate existing OVAL Definitions into a single file).
  • Definition Evaluator — A product that uses an OVAL Definition to guide system evaluation and produce an OVAL Results document (full results) as output.
  • Definition Repository — A repository of OVAL Definitions made available to the community (free or pay).
  • Results Consumer — A product that accepts an OVAL Results document as input and either displays the results to the user, or uses the results to perform some action.
  • System Characteristics Producer — A product that generates a valid OVAL System Characteristics file based on the details of a system.
Back to top

Use Cases

OVAL Use Cases define the intended best practice usage of the standard. Eight current use cases for OVAL are detailed below, including a list of the relevant OVAL Capabilities for each.

  1. Security Advisory Distribution
  2. Vulnerability Assessment
  3. Patch Management
  4. Configuration Management
  5. Auditing and Centralized Audit Validation
  6. Security Information Management Systems (SIMS)
  7. System Inventory
  8. Malware and Threat Indicator Sharing

Security Advisory Distribution

Security advisories are published by vendors and security researchers as product vulnerabilities are discovered. Security advisories generally contain the information needed to detect the presence of the vulnerable product on a system. These advisories are leveraged by alerting services and vulnerability scanning products to raise awareness of the latest issues that might affect individuals and organizations using the vulnerable products. One acknowledged need within the security industry is for application and operating system vendors, and other authoritative organizations, to publish vulnerability information in a standard, machine-readable format. The benefit of this is two-fold. First, it provides scanning products with immediate access to actionable content that can be used to assess the security posture of a system. Second, it moves the authoring of the technical details of a vulnerability from the reverse engineering efforts of the scanner-product developer to a more authoritative source: the developer of the vulnerable product.

Use Case Scenario
Publishing an Advisory

In this scenario, a software vendor receives a report of an undisclosed vulnerability along with exploit code from a member of the security community. The vendor examines the report and exploit code and confirms that there is a vulnerability in their software. The vendor further investigates the vulnerability to determine what versions of the software are affected and on what platforms. The vendor reserves a Common Vulnerabilities and Exposures (CVE) Identifier (also called CVE Identifiers, CVE-IDs, and CVEs) for the vulnerability and creates a standardized check for the vulnerability in the form of an OVAL Definition. This new OVAL Definition includes the list of affected platforms and products, a reference to the reserved CVE Identifier, and a description of the vulnerability. The software vendor adds tests to check for the vulnerable software on the relevant platforms. Once complete, the OVAL Definition is signed to ensure integrity and authenticity and tested to ensure that it accurately detects all known vulnerable versions of the software. Finally, the software vendor publishes a new security advisory for the vulnerability including the reserved CVE Identifier and the OVAL Definition that will detect the presence of the vulnerability.

Immediately after publication, organizations begin to download the security advisory’s OVAL Definition, verify its signature to ensure that it was not modified in transit, and use it in their vulnerability scanning tool of choice to determine whether or not their systems are vulnerable.

Relevant OVAL Capabilities:

  • Authoring Tool — Organizations publishing security advisories may utilize an Authoring Tool to assist in the development of the security advisories as OVAL Definitions.
  • Definition Repository — Organizations publishing security advisories as OVAL Definitions can be considered a repository of OVAL Definitions.
  • Definition Evaluator — Products that implement the Definition Evaluator capability can consume OVAL Definitions for the security advisories and report any vulnerabilities found on a set of hosts.
Back to top

Vulnerability Assessment

Vulnerability management is the process of identifying the vulnerabilities in a system and prioritizing them according to their severity. Currently, organizations that develop vulnerability management products need to employ a team of content developers. This team investigates vulnerabilities as they become known, gathering all of the available information for a given vulnerability, and running various tests against live systems to examine the parameters that indicate the presence of a vulnerability. Once a vulnerability is understood, this team develops a check that will indicate the presence of the vulnerability on a system for use in their product. The resulting checks are then distributed to vendor’s customers so that they can assess their systems and take action based on the vulnerability assessment results. All of these tasks must be completed under a very strict time requirement and are repeated across nearly every organization that develops and offers a vulnerability management product.

For vulnerability management product vendors, having vulnerability information structured in a standard format allows them to quickly consume data from multiple sources. These vendors can share vulnerability checks with each other and collaborate on developing the best possible check for a given issue. If the initial security advisory includes a standardized check for the issue, these vendors can automatically consume that data. This will allow the vendor to refocus resources away from content generation to tasks that enhance the functionality of their product while distributing higher quality checks more quickly to their customers.

From the product 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 an apples-to-apples comparison of the products. When conducting product comparisons, given a specific set of definitions, each product tested should return the same result. If this is not the case, it is no longer a result of the products taking different approaches to detecting a vulnerability, and removes the burden from the customer to determine which product they think returns the most accurate results. The end result is that the customer can focus more on selecting a product with the features that best meet their needs, and less on the more difficult problem of which product does the correct job of detecting vulnerabilities. Lastly, 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 product is conducting its business.

Use Case Scenarios
Leveraging a Standardized Security Advisory

An operating system vendor releases a new set of security advisories for its platform as OVAL Definitions. A system administrator runs the organization’s vulnerability management tool which retrieves the OVAL Definitions and verifies its signature. The vulnerability management tool then collects the attributes required to make an assertion about whether or not the system is in a vulnerable state and includes this information in the OVAL System Characteristics. Next, the vulnerability management tool evaluates the OVAL System Characteristics against the OVAL Definitions and expresses the findings in the OVAL Results.

Collaborating on the Development of a Vulnerability Check

A new critical vulnerability is disclosed by an application vendor and the initial security advisory does not include an authoritative standardized check for the vulnerability. A vulnerability management product vendor quickly develops and distributes an OVAL Definition with a check for the presence of the vulnerability on the platforms the vendor supports for its customers. The vendor shares this new check with a forum of other vulnerability management vendors and industry experts in the form of an OVAL Definition. The OVAL Definition is extended by another vendor to include detailed checking information for additional platforms in order to make the vulnerability check complete for all known vulnerable platforms. The resulting OVAL Definition is again shared with the industry forum. A security expert participating in the forum notices that under some circumstances the OVAL Definition will detect the vulnerability when in fact it does not exist (a false positive). The security expert corrects this defect in the OVAL Definition and once again shares this information with the forum. The forum members have collaborated in developing a thorough, accurate, standardized check for the vulnerability and leveraged the resulting OVAL Definition in their products and services.

Sharing Vulnerability Assessment Results

A vulnerability management product, using an OVAL Definition, detects the presence of a vulnerability on a system and generates the OVAL Results that record this finding. The OVAL Results are provided to the organization’s security dashboard where it is processed. Due to the severity of the vulnerability and availability of a patch it is determined that the affected system must be patched. The OVAL Results are then provided as an input to the organization’s patch management tool where the affected system is identified and the appropriate patch, for the vulnerability, is identified by its CVE Identifier and applied to the system. The system is no longer in a vulnerable state.

Relevant OVAL Capabilities:

  • Authoring Tool — Vendors may use an Authoring Tool to assist in the development of vulnerability content to provide to their customers. End users may use an Authoring Tool to assist in developing their own checks.
  • Definition Repository — The logic required to determine the presence of a vulnerability can be expressed in an OVAL Definition and published in a Definition Repository along with the original security advisory as soon as the vulnerability is discovered. Providing vulnerability detection information in a structured format allows end users to more quickly assess their systems and take action as needed.
  • Definition Evaluator — A product that implements the Definition Evaluator Capability can consume vulnerability checks from many Definition Repositories. This will significantly reduce the size of the vendor’s content team as well as reduce time it takes to get a vulnerability check out to end users. Additionally, the end user may supply custom developed OVAL Definitions to a Definition Evaluator.
Back to top

Patch Management

Patch management is the process of identifying the security issues and software updates that affect a system, applying the patches that resolve these issues, and verifying that the patches were successfully installed. Ensuring that systems are properly patched is a major concern among organizations as it’s a leading cause for compromised systems. Patch management tools must have a detailed understanding of what it means for a given patch to have been properly installed on a system to ensure that systems are properly patched. As a result, patch management vendors employ teams of analysts to reverse engineer patches and fully understand the impact of applying a given patch to a system. These analysts must develop and maintain checks for each patch their product supports.

For the patch management vendor community, having patch checking information structured in a standard format allows them to quickly consume data from multiple sources. These vendors can share patch checks with each other and collaborate on developing the best possible check for a given patch. If the patch is distributed with a standardized check for the patch these vendors can automatically consume that data. This will allow the vendor to refocus resources away from content generation to tasks that enhance the functionality of their product while distributing higher quality patch checks more quickly to their customers.

Use Case Scenarios
Leveraging a Standardized Patch Check

An operating system vendor releases a new set of patches for its platform and includes standardized patch checks as OVAL Definitions. A system administrator runs the organization’s patch management tool which retrieves the OVAL Definitions and verifies its signature. The patch management tool then collects the attributes required to make an assertion about whether or not the system needs to be patched and includes this information in the OVAL System Characteristics. Next, the patch management tool evaluates the OVAL System Characteristics against the OVAL Definitions and expresses the findings in the OVAL Results. The patch management tool examines the OVAL Results and determines that a patch should be installed. The patch is installed and the system is no longer vulnerable.

Patching a Known Vulnerability

An organization’s patch management tool examines the OVAL Results generated by a vulnerability management tool. The OVAL Results include summary information about all vulnerabilities that were checked and full details about the vulnerabilities that were found during a vulnerability assessment. The patch management tool uses the CVE Identifier associated with each OVAL Definition, included in the OVAL Results, to enumerate the available patches for the vulnerable software found on the system.

Relevant OVAL Capabilities:

  • Authoring Tool — Vendors may utilize an Authoring Tool to assist in the development of patch applicability content to provide to their customers. End users may utilize an Authoring Tool to assist in developing their own checks.
  • Definition Repository — The logic required to determine patch applicability can be expressed in OVAL Definitions and published in Definition Repositories along with the original patch advisory. Vendors can then leverage these Definition Repositories, from multiple organizations, as input into their products.
  • Definition Evaluator — A product that implements the Definition Evaluator Capability can consume patch applicability checks from many Definition Repositories. This will significantly reduce the size of the vendor’s content team as well as reduce time it takes to get a patch check out to end users. Additionally, the end user may supply custom developed OVAL Definitions to a Definition Evaluator.
  • Results Consumer — A patch management product that implements the Results Consumer Capability might consume OVAL Results from a vulnerability assessment product in order to determine which patches a system might need. In this way, the results of a vulnerability assessment can feed into the patch management process.
  • System Characteristics Producer — A System Characteristics Producer might be used to provide detailed system configuration information to a patch management product.
Back to top

Configuration Management

The process of configuration management involves 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 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 products often rely upon proprietary data formats, making it difficult to introduce new policies to the product or move data from one product to another. Finally, as with some of the use cases above, divesting the language from the product provides the product vendor with a wider repository of content and allows them to focus more on functionality and features.

Use Case Scenarios
Policy Distribution

An operating system vendor releases a new version of its operating system. Along with the initial release of the operating system, detailed secure configuration guidance is included. This guidance is intended to act as a baseline for the operating system’s users to tailor for their own environments and security requirements. The operating system vendor includes the OVAL Definitions with this secure configuration guidance. Each OVAL Definition includes a reference to the relevant Common Configuration Enumeration (CCE) Identifier (also referred to as CCE Identifiers, CCE-IDs, and CCEs) for correlation with other policies and can be used to check that a system is compliant with the operating system vendor’s recommendation for that configuration item. A system administrator runs the organization’s configuration management tool and provides the OVAL Definitions as input. The configuration management tool then collects the attributes required to make an assertion about whether or not the system is complaint with the new operating system policy and includes this information in the OVAL System Characteristics. Next, the configuration management tool evaluates the OVAL System Characteristics against the OVAL Definitions and expresses the findings in the OVAL Results.

Authoritative Policy Reuse

An organization has decided to develop a secure configuration policy for its desktop systems. Rather than create a new policy from scratch the organization leverages the secure configuration guidance recommended by the desktop operating system vendor. Since this policy was published in a standardized format, with a collection of OVAL Definitions for checking compliance with the policy, the organization downloads the policy and tailors it to their environment. By way of example, the organization has a very strict password policy and needs to require a minimum password length of 14 characters on all desktop systems. Given that the operating system vendor recommended a minimum password length of 8 characters, there is already an OVAL Definition in the published secure configuration for check minimum password length. The organization is able to simply tailor the minimum password length value setting it to 14 and reuse the rest of the checking logic in the OVAL Definition. The organization applies several other customizations to the policy by editing the published OVAL Definitions. Once completed, the organization inputs the new policy into its configuration management tool which begins monitoring all desktop systems for compliance with the policy.

Compliance Reporting

An organization is required to be compliant with an official configuration policy and report on the policy in order to participate in an industry. This policy has been expressed and published as a collection of OVAL Definitions and digitally signed by the authority that developed it. Free from needing to translate the policy, the organization assesses its systems for compliance with the policy using the organization’s own configuration management tool and the OVAL Definitions. For each system, the configuration management tool collects the attributes required to make an assertion about the system and its compliance with the policy. The tool then includes this information in the OVAL System Characteristics to represent the current state of the system. The configuration management tool evaluates the OVAL System Characteristics against the policy defined in the OVAL Definitions and includes the differences between current system state and the desired policy in the OVAL Results. The OVAL Results are then forwarded to the organization’s compliance reporting tool where the results of the system’s compliance to the policy can be made available to the authorities to demonstrate compliance.

Relevant OVAL Capabilities:

  • Authoring Tool — Organizations may utilize an Authoring Tool to assist in the development of configuration checking content. End users may utilize an Authoring Tool to assist in developing their own checks.
  • Definition Repository — When a best practice configuration is created, or a configuration policy is established, the checking logic that verifies that a given system is configured accordingly can be expressed as a set of OVAL Definitions and published in Definition Repositories. Vendors can then leverage these Definition Repositories, from multiple organizations, as input into their products. IT staff can leverage and tailor best practice configuration checking content for their own organizational needs.
  • Definition Evaluator — A product that implements the Definition Evaluator Capability can consume published configuration guidance from many Definition Repositories. Additionally, the end user may supply custom developed OVAL Definitions to a Definition Evaluator.
Back to top

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 product, which may or may not be available at the time it is necessary to review the data.

Use Case Scenario
Keeping Track of Change

An organization deploys a centralized audit validation system. When a new system joins the network, it is immediately scanned by the organization’s vulnerability management, patch management, and configuration management tools based on the most up-to-date security advisories, patches, and policies. The resulting OVAL Results, associated with the scans, serve as the system’s initial state in the centralized audit validation system. From then on, the system is scanned once a week to determine if anything has changed. If changes are discovered since the last update, the centralized audit validation system is updated with the latest OVAL Results. If at any point in time between the scheduled scans, the system falls into or out of compliance or a new patch has been installed, the centralized audit validation system is immediately updated with the new OVAL Results. The centralized audit validation system now contains multiple sets of OVAL Results documenting the various state changes to the system over time.

Relevant OVAL Capabilities:

  • Authoring Tool — An Authoring Tool might be used to assist in the development of audit checks.
  • Definition Evaluator — A product that implements the Definition Evaluator Capability can consume audit checks and store their results over time as OVAL Results. OVAL Results provide detailed system configuration information in a structured format independent from any specific product implementation.
  • Results Consumer — An auditing product that implements the Results Consumer Capability might consume OVAL Results from a number of other products in order to have a complete picture of an enterprise.
  • System Characteristics Producer — A System Characteristics Producer might be used to provide detailed system configuration information to an auditing product.
Back to top

Security Information Management Systems (SIMS)

SIMS integrate the output of a variety of security, auditing, and configuration products, as well as their own agents, to build a comprehensive view of the security posture of an organization’s network. The fewer data formats the SIM needs to understand the more flexible and powerful the product can be. Standardizing the data exchange formats between products greatly simplifies the interoperability requirements and provides the end users with a wider array of applications to choose from.

Use Case Scenario
Data Aggregation

A security information management system vendor utilizes the OVAL Results generated by vulnerability management tools, patch management tools, configuration management tools, and any other tool that produces OVAL Results as a primary format for data coming into their system. By doing so, the system can consume data from an entire range of tools in a straightforward manner without the need to translate different formats, of like data, into a single format before it can be analyzed.

Relevant OVAL Capabilities:

  • Results Consumer — SIMS that implement the Results Consumer Capability might consume OVAL Results from any number of other products that could be serving a variety of functions. In this way, the burden of integrating numerous output formats is greatly reduced.
Back to top

System Inventory

System inventory is the process of gathering a detailed listing of the applications installed on a given system. Large enterprises often have many versions of many applications running on wide variety operating systems. Organizations simply do not rely upon one vendor for all the software that is running in their enterprise. This raises a considerable challenge when tracking software for licensing, vulnerability management, compliance, and other purposes. Application and operating system vendors need a standardized way to describe how to check for the presence of an application and system inventory tool vendors need reach out to numerous application and operating system vendors for this information in order to accurately determine what is installed on a system. Currently, these system inventory tool vendors must develop their own checks for the presence of an application or operating system, often times based on a best guess rather than authoritative knowledge of the system.

Use Case Scenario
Operating System Upgrade

An organization wants to upgrade its remaining systems to the newest version of an operating system. The organization tasks the system administrator with determining how many licenses need to be purchased. The system administrator downloads the OVAL Definitions that contain checks for all of the previous versions of the operating system along with references to CPE Identifiers that correspond to the specific platform associated with a check. The system administrator then runs the system inventory tools across the organization using the downloaded OVAL Definitions. The system inventory tool collects the attributes required to make an assertion about the software installed on the system and includes it in the OVAL System Characteristics as a snapshot of the observed state of the system. Next, the system inventory tool compares the OVAL System Characteristics to the OVAL Definitions, and records the findings in the OVAL Results. Finally, the system inventory tool forwards the OVAL Results to the organization’s reporting tool. The reporting tool leverages the Common Platform Enumeration (CPE) Identifiers (also called CPE Identifiers, CPE-IDs, and CPEs) in the OVAL Results to provide detailed information about the number and types of earlier versions of the operating system that were found allowing the system administrator to see how many licenses are required for the upgrade.

Relevant OVAL Capabilities:

  • Authoring Tool — An Authoring Tool might be used to assist in the development of system inventory checks.
  • Definition Evaluator — A product that implements the Definition Evaluator Capability can consume system inventory checks from a number of Definition Repositories and report inventory results in the form of OVAL Results which could be consumed by other products.
  • Results Consumer — A central asset database that implements the Results Consumer Capability might consume OVAL Results from a number of other products in order to have a complete picture of an enterprise.
Back to top

Malware and Threat Indicator Sharing

Incident coordination centers, organizations, and other members of the security community are actively discussing malware and sharing low-level system details that can be used to detect potentially compromised systems. These details are commonly shared as prose documents that require translation into actionable content prior to being used for system assessment. The need for a standard format to encode malware and threat indicators is widely acknowledged, and its use by incident coordination centers would be widespread.

Use Case Scenarios
Detecting Compromised Systems

An organization discovers that one of their systems has been compromised by some malicious software. Immediately, the organization tasks their forensics team with investigating the infected systems. During the investigation, the forensics team notices that the infected system contains certain files that have been modified and that a previously undisclosed vulnerability was used to gain access to the system. Realizing that there is no publicly available check for this vulnerability, the forensics team creates an OVAL Definition with tests to check for the presence of the modified files found during the investigation. Depending on the forensic team’s in house tools the resulting OVAL Definition may be automatically generated from numerous possible sources including static analysis tool outputs or possibly hand written in the case where a more manual process was used to investigate the incident. Once complete, the forensics team quickly pushes the new OVAL Definition to their host-based security system in order to determine how wide spread the attack on their infrastructure really is, before their anti-virus vendor has published updated signatures. The host based security system collects the attributes required to determine if a system has been compromised records this information in the OVAL System Characteristics to capture the system’s current state. Next, the host-based security system compares the OVAL System Characteristics against the OVAL Definitions and records the differences in system state in the OVAL Results. Finally, the host based security system forwards the OVAL Results to the organization’s reporting tool where the OVAL Results are leveraged to provide detailed information about the number of systems that have been compromised. Thus, enabling the forensics team to quickly quarantine and remediate the issue.

Sharing Threat Indicators

An organization has in-depth knowledge about a system compromise and exactly what artifacts reside on a system after compromise. The organization exports an OVAL Definition from its in house malware database with tests to check for the presence of these artifacts, modified files and new registry keys, shares the resulting OVAL Definition with their partners. The partners run the OVAL Definition on their systems. The partner organizations quickly learn that they too have compromised systems and begin collaborating with each other in developing a strategy to remediate the affected systems.

Relevant OVAL Capabilities:

  • Authoring Tool — An Authoring Tool might be used to assist in the development of checks for indications of a threat or particular piece of malware.
  • Definition Evaluator — A product that implements the Definition Evaluator Capability can consume checks for indications of a threat or particular piece of malware and report results in the form of OVAL Results for further analysis.

Additional Information

For additional information please see OVAL Adoption Process and OVAL Adoption Requirements, or contact us at oval@mitre.org.

Back to top

Page Last Updated: January 05, 2012