The Standard for Vulnerability Test Data

Typically, the vulnerability information used by a particular vendor of a VM scanner or analyzer is stored in a database that is designed to work seamlessly with the software. Since standards are usually a few to several years behind industry, none of these databases are alike. The vulnerability data and method of identification vary widely from one product to another—that is, there is no standard.

However, MITRE has driven the idea of a standard for just this type of data structure. It is called the Open Vulnerability and Assessment Language or OVAL^®. As the name implies, it is a language that is structured using XML to record the details of the state of a machine (target) that has a particular vulnerability. It employs the state machine approach to identifying a vulnerability, which is a highly structured way of indicating the vulnerable state and the non-vulnerable state. So, let’s examine the OVAL process in Figure 1 to understand its benefits.

Figure 1: The OVAL process.

We start with the security researcher who discovers a new vulnerability in product X. Having firsthand knowledge of the vulnerability and how it can be identified in a vulnerable target, the researcher encodes the details of that vulnerability in an OVAL-standard-formatted XML document. This document describes exactly how to identify the vulnerability on a target by providing the information of the state of particular items that constitute a vulnerable machine. This method of vulnerability identification is called a test.

Definitions Schema

At a higher level, OVAL consists of three types of documents called schemas. The definitions schema is used to encode the state of various parts of a computer system that must exist in order to be subject to a particular vulnerability. For example, a target system may need to have a Windows 2003 server with Service Pack (SP) 2, IIS, and anonymous Web access configured to be vulnerable to vulnerability XYZ. These schemas provide the framework for encoding such conditions.

Other definitions exist to capture other important information to help round out the VM process. Patch definitions record the specific conditions that must be present in order to be eligible for a patch. The idea is to avoid haphazardly applying patches to a system inappropriately. So, the ability is provided to specify, for example, that a vulnerability that is fixed by Windows 2003 SP 2 is only applied when the target system is in fact Windows 2003 and has only SP1 installed. The patch definition capability can go far beyond this, but this understanding is sufficient for the scope of this book.

An OVAL inventory definition is just what it sounds like: a description of what defines a particular inventory item. If you want to specify that the SNMPv3 service is installed on a router, certain items must be checked to be certain it is present. The inventory definitions provide the XML schema to achieve exactly this. Since vulnerability scanning and automated configuration discovery are so closely related, it makes sense that OVAL should include this capability.

One additional area where the VM industry has very sensibly gone is compliance management. The MITRE team has understood this, and OVAL includes a schema for compliance definitions. Similar to the other schema, compliance specifies the conditions under which a system is compliant with a particular policy. Again, this is a natural extension to VM tools and processes.

System Characteristics Schema

This schema is designed to provide a standard definition of target system characteristics. These system characteristics, once collected, can be analyzed to identify vulnerabilities. When all of the target characteristics are collected, the vulnerability analyzer would compare them to the details in the definitions data to discover vulnerabilities. The design of the system characteristics schema is roughly parallel to that of the definitions schema. Although this schema is vulnerability focused, it also amounts to a list of configuration items in a configuration management database.

Results Schema

This third and final high-level schema is designed to provide a standard structure for recording the results of the vulnerability assessment. The primary benefit is that once a vulnerability is discovered, the details are captured in a format that many other security tools can interpret to properly apply patches, update configurations, initiate change processes, and take other mitigation actions as necessary. The results schema very specifically captures the details of a particular vulnerability on a specific target.

Nuts and Bolts^[*]

In the OVAL specification, tests are formatted in the OVAL definitions schema and are defined by a tag. Tests are recorded using three key XML elements: , which is the item being tested; are the values of the objects to be tested; and are the tests to be performed against those objects using the previously mentioned . An ID is assigned to each definition, object, state, and test using a notation resembling reverse DNS entries. Let’s take a look at a partial example of an OVAL definition, which is a check to see whether Windows XP^® is installed. This is an abbreviated version, so we do not spend time on details that are not instructive on this topic:

------------------------------------------------
1
2 version="3" class="inventory">
3
4