Structure of the Language
The official OVAL Language consists of three different categories: system characteristics, definitions, and results. Each category contains a core schema and a number of component schemas.
OVAL Definition Schema
The OVAL Definition schema is used to define the XML framework for writing: (1) OVAL Vulnerability Definitions by defining the conditions that must exist on a computer for a specific vulnerability to be present, (2) OVAL Patch Definitions by defining the conditions on a computer that determine whether a particular patch is appropriate for a system, (3) OVAL Inventory Definitions by defining the conditions on a computer that determine whether a specific piece of software is installed on the system, and (4) OVAL Compliance Definitions by defining the conditions on a computer that determine compliance with a specific policy or configuration statement. Tools and services that leverage the Definition schema are listed as Authoring Tools, Definition Evaluators, and Definition Repositories in the OVAL Adoption section.
The OVAL Definition schema, along with the OVAL System Characteristics schema and OVAL Results schema, are not individual schemas unto themselves but are each composed of a "core" schema and a collection of "component" schemas. The core schema provides the general structure of an OVAL Definition, as well as a place for expressing metadata that is independent of the tests (e.g., CVE identifier, affected platforms, and descriptions), while the component schemas define the specific tests the OVAL Language uses to identify vulnerability, configuration, and security issues within an operating system (OS) or application.
OVAL System Characteristics Schema
The OVAL System Characteristics schema defines a standard XML format for representing system configuration information. This configuration information includes OS parameters, installed software application settings, and other security relevant configuration values. The purpose of this schema is to provide a "database" of system characteristics against which the OVAL Definitions can be compared in order to analyze a system for vulnerabilities, configuration issues, and patches. In essence, the schema defines a standard system characteristics exchange format that can be incorporated into a variety of tools, such as those listed as System Characteristics Producers in the OVAL Adoption section.
As with the OVAL Definition schema, the OVAL System Characteristics schema is composed of a core schema and a collection of component schemas. The function of the core schema is similar to that of the core schema in the OVAL Definition schema. The component schemas define the format and content of the configuration parameters that are collected, and roughly correspond to the tests specified within the OVAL Definition schema.
OVAL Results Schema
The OVAL Results schema defines a standard XML format for storing the results of an evaluation of a system. The results data contains the current state of a system’s configuration as compared against a set of OVAL Definitions. The OVAL Results schema allows applications to consume this data, interpret it, and take the necessary actions to mitigate the vulnerabilities and configuration issues (for example, install patches, alter system configuration settings, and/or take external precautions to limit access to the affected systems). This schema also defines a standard vulnerability and misconfiguration exchange format that can be incorporated into a variety of tools, such as those listed as Results Consumers in the OVAL Adoption section.
Again, the OVAL Results schema is composed of a core schema and a collection of component schemas. The primary difference between the component schemas in the OVAL Results schema versus the OVAL Definition schema, is that in the OVAL Results schema each test contains the information used to determine the presence or absence of a vulnerability or misconfiguration in addition to the specific system data analyzed to arrive at the final result.
Component Schemas
The component schemas consist of a collection of OVAL Tests that are related at some level by the software they describe. Tests that are identical across multiple different component schemas, and thus represent a more general class of test, are grouped together in a higher-level component schema. For example, there are different component schemas for Linux and Solaris, but these both have the same structure for a file test. Because of this similarity, the file test is located in a conceptually higher-level UNIX schema. The conditions that determine the level at which a test should be placed are outlined later in this document.
This hierarchical structure of schemas is purely conceptual, however, as there is no actual linking between them. For example, a package test in the Solaris schema does not inherit aspects from a package test in the UNIX schema. Note that all tests do inherit a standard set of attributes and a note element from the core schema. The conceptual hierarchy is a by-product of the way the OVAL Language has developed. While the need for a true hierarchy within the OVAL Language has not yet arisen, it has been recognized that this need may evolve at some point in the future.
Conceptual Breakdown of the OVAL Language
-----------------------------------------
OVAL Definition Schema
|
|--> Core Schema
|
|--> Independent Schema (family_test, variable_test, xmlfilecontent_test, etc.)
|
|--> UNIX Schema (file_test, process_test, uname_test, etc.)
| |
| |--> Solaris Schema
| |--> HP-UX Schema
| |--> MacOS Schema
| |--> Linux Schema (dpkg_test, rpminfo_test, etc.)
|
|--> Windows Schema (file_test, wmi_test, etc.)
|
|--> Apache Schema
OVAL Definitions can pull tests from multiple different schemas. For example, an individual definition might use the family_test from the independent schema (note that the independent schema defines a collection of tests that are not related to a specific piece of software), the process_test from the UNIX schema, and the rpminfo_test from the Linux schema. The validation of these definitions is guided by the namespace associated with each test.
An advantage of multiple component schemas is the separation of tests that describe different types of software (e.g., the tests that deal with Red Hat and Solaris), while at the same time grouping related tests together (e.g., the tests dealing with common aspects of UNIX). A software vendor who finds the need to create an addition to the OVAL Language in order to support their software can group the set of new tests into a new component schema. The ease with which a new component schema can be added to the OVAL Language allows the software vendor to focus their efforts on refining their own schema, instead of trying to modify existing schema(s) that contain tests that do not apply to their product.
Another advantage of this structure is that, as new software is supported by OVAL, previously written content using higher-level component schemas does not have to be modified. For example, in previous versions of OVAL, schemas were broken down by operating system and there was no concept of a higher-level UNIX schema, therefore, although the file_test was identical for the Red Hat, Solaris, and Debian platforms, an instance of the test had to be included in each schema. In some cases, this breakdown caused multiple, identical OVAL Definitions to be written to account for each of the platforms. To further compound the problem, addition of a new UNIX-based platform, such as HP-UX, would cause a new duplicate test to be created. Under the current approach, a single definition can be written to encompass all UNIX-based platforms, even those that are added after the definition has been created.
Finally, breaking the OVAL Language into component schemas allows tools to target a select set of applications or OSs and in doing so, reduce their process overhead and execution time. In versions of OVAL prior to 4.1 tools were forced to manage a single, large schema for their platform of choice. This sometimes meant that the schema included tests irrelevant to the tool, and increased the processing overhead.
The potential pitfall to this approach is a schema structure that is unwieldy and difficult for a user to navigate. Therefore, great care must be taken to ensure that considerable thought is put into the rules governing the structure of the schema, the rules are followed consistently, and the rules are well documented. By providing the user with a logical, fully documented format, they should be able to quickly locate any test within the schema.
Placement of a New Test
When a new test is created, there are a couple of questions that need to be answered in order to determine its placement in the language hierarchy. Does this test meet the needs of examining a specific software component on its own, or is there a collection of related new tests whose function is to describe the component in question? Is this test targeted at a specific application, or does it address a more general configuration issue?
The answer to the first question will determine whether the test should be incorporated into an existing component schema, or grouped with other new tests to form a new component schema. For example, a new test that examines the configuration of a specific Windows service will be incorporated into the existing Windows schema. A set of five new tests that examine the configuration of an Oracle Database would form the basis for a standalone Oracle schema.
The answer to the second question determines which component schema a test will be placed in. Tests that can be used more generally across a set of schemas are placed in a higher-level component schema, while tests that are more focused on a specific aspect of a system's configuration will be placed further down the conceptual hierarchy.
As with any decision of this type, there is bound to be debate over the merits of creating a new schema or not, and whether a test is truly general or not. In such cases, the members of the OVAL Community are encouraged to present their arguments, with the OVAL Board acting as the final arbiter. The goal is that this discussion will be incorporated into the documentation for the test, as well as provide precedents to refine the process in the future.
Relation to the Affected Family
In versions prior to 4.1 of the OVAL Language definitions were grouped by the value of the affected family. The list of values for the affected family, and hence the possible grouping, was tied to the different component schemas. Each valid affected family corresponded to an existing component schema. This relationship has been removed from version 4.1 and later. For example, it would not make sense to have an affected family of Apache. Note that the affected family is meant to describe the family of OSs that the OVAL Definition applies to. The purpose of the affected family has remained the same but the values are now declared independently of the component schemas.
Page Last Updated: January 11, 2012
