Open Vulnerability Assessment Language (OVAL) in a Nutshell

Before diving into the OVAL, we shall quickly brief the project from where it has evolved.

Overview of SCAP
Security Content Automation Protocol (SCAP), a project from NIST is widely adopted by many software and hardware manufacturers as a sophisticated framework of specifications for management and governance programs that can fall into the scope of automation such as configuration management, vulnerability management, system inventory identification, auditing and so on.

An organization can adopt SCAP standards by generating or consuming SCAP content which would be in an XML format where each of the SCAP components will have its own XML namespaces.

This framework of interoperable specifications encompassed several standards otherwise called SCAP Components. As we are unable to elucidate all of the components in this series of blog posts, we will be mainly focusing on “OVAL”, hence this brief.

SCAP components include many standards such as:

• Languages

• XCCDF: An “Extensible Configuration Checklist Description Format” to describe the security checklists, organize & manage the policies or compliance definitions defined in “OVAL”, another component of standards.
• OVAL: Open Vulnerability Assessment Language, most essential component in the SCAP framework. OVAL has become a community standard which allows interoperability among several security products and also among the software/hardware manufacturers.
• ARF: Asset Reporting Framework, a standard to describe the sharable information of assets.

Supporting these components, there are several tools available which we can leverage to automate the derived definitions. One of them would be “OpenSCAP (oscap)” which we would be using later to perform the scan in this series of blogs posts.

Introduction of OVAL

OVAL (Open Vulnerability Assessment Language), a community standard from MITRE can be used to define the expected configuration aspects of the system under tests and report the actual state of the systems. The flexibility of using logical assertions on a state of an endpoint makes OVAL much more powerful and significant.

The OVAL not only enables interoperability between security products but also sets a standard for turning the information into an actionable format.

The use cases of OVAL capabilities help different verticals to achieve different tasks and some of those are as follows:

• System Inventory
• Configuration Management
• Vulnerability Management
• Patch Management
• Security Information Exchange System
• Auditing – Compliance Management

OVAL is not only limited to these but also a myriad other use cases. We would be sharing our research and another interesting avenue where we can fully leverage OVAL and its capabilities in upcoming blog posts.

Who is using OVAL

Through OVAL Adoption Program, many organizations and security products adopted OVAL complying interoperability between a wide variety of products and services which helps to secure the enterprise. You can find the organizations using OVAL in this list.

Since the OVAL community engagement and maintenance transitioned to CIS security, any individual or an organization could leverage CIS- security repository to find the updated OVAL content.

Anatomy of OVAL

The OVAL language is a pre-defined standard that can be used to describe the expected state of resources such that the tools function as OVAL interpreter could understand and scan the desired targets (there are a few OVAL interpreters such as “OpenSCAP (oscap)”, “jOVAL” which we would be discussing further). These expected states are a set of instructions defined in a standard XML schema called “OVAL Definitions” and the file be called an OVAL Definitions file.

A file can comprise one or more OVAL definitions and each of these definitions can have one or more tests describing desired configuration of a system by using logical assertions as shown in Fig-1.

Primarily there are four types of OVAL Definitions denoted in an attribute ‘Class’ while writing the definitions, as follows:

• Vulnerability Definitions – which defines a system is vulnerable when specific conditions are met.
• Patch Definitions – which defines the condition whether a patch is appropriate for the system.
• Inventory Definitions – which defines if a particular software is installed or identified on a system.
• Compliance Definitions – which defines if a system complies with specific policy or configuration.

Based on these classes the OVAL interpreter collects the details of a system and compares the defined instructions with the collected system characteristics of a targeted system.

Writing an OVAL definition can be tricky if the standard XML schema and various parts of the definition is not understood. This following section will review the elements of a definition using an example

We will be using one of the definitions from the OVAL Definitions file produced by Canonical Security Team. For ease of understanding, we will breakdown the OVAL definition into the parts

Objective: Check if the Ubuntu system is vulnerable to CVE-2021-23971

  



Ubuntu 20.04


When processing a redirect with a conflicting Referrer-Policy, Firefox would have adopted the redirect's Referrer-Policy. This would have potentially resulted in more information than intended by the original origin being provided to the destination of the redirect. This vulnerability affects Firefox < 86.

Medium
https://bugzilla.mozilla.org/show_bug.cgi?id=1678545
https://www.mozilla.org/security/advisories/mfsa2021-07/
https://ubuntu.com/security/notices/USN-4756-1












  

OVAL Definitions

• Any definition in OVAL should begin with “<definition>” and designated with a unique ID id=”oval:com.ubuntu.focal:def:2021239710000000″ for sake of reusability and to avoid conflicts among other definitions. This definition in the example is of type Vulnerability as defined in class=”Vulnerability” from the first line. </definition >
• The “< metadata>” section implies to metadata for the definition which includes title, description, target platform and any references. Out of these ‘family’ attribute indicates which of the OVAL supported families this definition relates to. < /metadata>
• The “< criteria>” section comprises set of instructions to be issued to evaluate the target system. Each criteria can contain one or more criterions. In this example, we have three criterions referenced to three different test objects to check the conditions of Firefox against the target system.< /criteria>

The <definition> elements have to be enclosed with < definitions> as per the standard.</definitions></definition>

OVAL Tests, Objects and States

• Aforementioned ‘test’ references in ‘criteria’ should have a ‘test_ref’ attribute with an ID which will be referenced in element. In this example the ID is referring to test_ref=”oval:com.ubuntu.focal:tst:2021239680000000″. Each test can have at least one ‘object’ reference and one or more ‘state’ references.
• The ‘check_existence’ attribute determines how many objects specified should meet the condition set to be true. In this example we expect “at_least_one_exists” at least one of the objects should exists.
• The ‘check’ attribute determines how many states specified should meet the condition set to be true. In this example we expect “at least one” at least one of the states should meet the condition.

• The OVAL objects indicate what characteristics in the system had to be checked by the OVAL interpreter. In this example the probe ‘dpkginfo_object’ probes for Firefox and its components which were referenced through a variable var_ref=”oval:com.ubuntu.focal:var:201447150000000″. In simple terms, the Object says what is to be checked in a system. OVAL also have a flexibility to use Regular Expressions to compare with the system characteristics output fetched by the interpreter using the attribute ‘operation’. In this example, we are expecting it to be exact match, not a pattern match hence operation=”equals”.

  
    
      0:86.0+build3-0ubuntu0.20.04.1
    
  
  

The OVAL states determine how a condition needs to be checked by the interpreter. As mentioned, any ‘state’ should have a reference mapped to a corresponding ‘object’ in a ‘test’. In this example, the ‘state’ determines the version of the package and it returns true when the version is less than ‘0:86.0+build3-0ubuntu0.20.04.1’.

Though we have a hardcoded value with the attribute, we can also make use of variables by referencing the variable “oval:com.ubuntu.focal:var:201447150000000” in an object or a state just like we saw in <objects> section. The <variables> elements can have one or more constant or local variables. As shown below, we have a constant variable with different values of Firefox and its components.</variables></objects>

  
    
      firefox
      firefox-geckodriver
      firefox-mozsymbols
    
  
  

The definition file which we used as an example can be downloaded from here

Using OpenSCAP (oscap) Scanner

In order to validate the written OVAL definition and scan against the target system, we require a utility called “oscap” a command-line scanner from OpenSCAP project, which is an open-source implementation of SCAP providing capabilities and potential features that are required for the organizations or software products that adopted OVAL definitions.

We will use ‘oscap’ scanner for our example which can be downloaded from the previous section. Though oscap have a great potential to perform other operations, we will be using it to evaluate the definition and scan the target system. More information on oscap can be read from their user manual.

This section demonstrates how to use different options of oscap command-line scanner.

• Print the information about SCAP file used as an input oscap info ubuntu-example.xml
  

• Validate the definition file to check if the file complies to SCAP standard
  oscap oval validate ubuntu-example.xml
  if the definition file consists of incorrect references or doesn’t comply with the standard, this command outputs the errors which we can use to trace
  

• Scan all the definitions in the definition file and generate the scan report.First, we need to collect the system characteristics using the following command
  oscap oval collect –syschar example_system_char.xml ubuntu-example.xml
  

• To compare the actual and desired state from the generated system characteristics file, we can use the following command which saves the results in the ’analyse_example.xml’ file
  oscap oval analyse –results analyse_example.xml ubuntu-example.xml example_system_char.xml
  To convert the generated XML report to an HTML report we can use following command
  oscap oval generate report analyse_example.xml > example_report.html
  

Here, we finish part-1 of this series of post on OVAL.

Unlike OpenSCAP there are commercial tools such as ‘jOVAL’ (which is now part of ARCTIC WOLF) that can be used to scan the local or remote targets.

Contributing to the Community

Our threat research team is always happy to contribute to the community, hence we published the OVAL content for some of CVEs assigned to Atlassian Products like Jira Server. You can download the content from our public repository here.

References:

• https://oval.mitre.org/documents/docs-07/Writing_an_OVAL_Definition.pdf
• https://ovalproject.github.io/getting-started/tutorial/
• https://community.cisco.com/t5/security-videos/how-to-use-cisco-ios-oval-machine-readable-content-with-joval/ba-p/3103066
• http://static.open-scap.org/openscap-1.3/oscap_user_manual.html
• https://security-metadata.canonical.com/oval/