Security Automation Using OVAL

Contents

The Importance of Security Automation
Security Content Automation Protocol
      Languages
      Enumerations
      Metrics
      Integrity
Streamlining Cisco IOS Software Vulnerability Assessment with OVAL
      How OVAL Helps Security Automation
      Downloading Cisco OVAL Content
      OVAL Definitions
      Scanning a Cisco IOS Device
         Before You Begin
         Network Topology
         Using jOVAL to Scan the Cisco IOS Router
Summary
References

The Importance of Security Automation

Most security and network administrators are seeking ways to leverage standards and available tools to reduce the complexity and time necessary to respond to security advisories, assess devices, and ensure compliance. Administrators have many systems to patch and configure securely, with numerous versions of software and features enabled.

All these challenges make it almost impossible for a security or network administrator to decide what changes are needed on endpoints or networking devices. Additionally, administrators must determine how to implement those changes quickly, correctly, and consistently.

The security community has struggled to make these tasks easier. The Security Content Automation Protocol (SCAP) was developed to address most of these challenges.

Security Content Automation Protocol

SCAP was created to provide a standardized solution for security automation. The SCAP mission is to maintain system security by ensuring security configuration best practices are implemented in the enterprise network, verifying the presence of patches, and maintaining complete visibility of the security posture of systems and the organization at all times.
The current SCAP specifications include the following:

Languages

  • Open Vulnerability and Assessment Language (OVAL): OVAL is an international community standard to promote open and publicly available security content and to standardize the transfer of this information in security tools and services. More information about OVAL is available at http://oval.mitre.org.
  • Extensible Configuration Checklist Description Format (XCCDF): XCCDF is a specification for a structured collection of security checklists and benchmarks. More information about XCCDF is available at http://scap.nist.gov/specifications/xccdf.
  • Open Checklist Interactive Language (OCIL): OCIL is a framework for collecting and interpreting responses from questions offered to users. More information about OCIL is available at http://scap.nist.gov/specifications/ocil.
  • Asset Identification (AI): AI is a specification designed to quickly correlate different sets of information about enterprise computing assets. More information about AI is available at http://scap.nist.gov/specifications/ai.
  • Asset Reporting Format (ARF): ARF is a specification that defines the transport format of information about enterprise assets and provides a standardized data model to streamline the reporting of such information. More information about ARF is available at http://scap.nist.gov/specifications/arf.

Note: Two emerging languages are Asset Summary Reporting (ASR) and the Open Checklist Reporting Language (OCRL). More information about ASR is available at http://scap.nist.gov/specifications/asr/, and more information about OCRL is available at http://ocrl.mitre.org/.

Enumerations

  • Common Vulnerabilities and Exposures (CVE): CVE assigns identifiers to publicly known system vulnerabilities. Cisco assigns CVE identifiers to security vulnerabilities according to the Cisco public vulnerability policy at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html.
    More information about CVE is available at http://cve.mitre.org.
  • Common Platform Enumeration (CPE): CPE is a standardized method of naming and identifying classes of applications, operating systems, and hardware devices. More information about CPE is available at http://cpe.mitre.org.
  • Common Configuration Enumeration (CCE): CCE provides unique identifiers for configuration guidance documents and best practices. The main goal of CCE is to enable organizations to perform fast and accurate correlation of configuration issues in enterprise systems. More information about CCE is available at http://cce.mitre.org.

Note: Other community-developed enumerators, such as the Common Weakness Enumeration (CWE), are currently being expanded and further developed. CWE is a dictionary of common software architecture, design, code, or implementation weaknesses that could lead to security vulnerabilities. More information about CWE is available from http://cwe.mitre.org. Another emerging enumerator is the Common Remediation Enumeration (CRE). More information about CRE is available at http://scap.nist.gov/specifications/cre.

Metrics

Note: Two emerging metrics specifications are the Common Weakness Scoring System (CWSS) and the Common Misuse Scoring System (CMSS). CWSS is a methodology for scoring software weaknesses. CWSS is part of CWE. More information about CWSS is available at http://cwe.mitre.org/cwss. CMSS is a standardized way to measure software feature misuse vulnerabilities. More information about CMSS is available at http://scap.nist.gov/emerging-specs/listing.html#cmss.

Integrity

Figure 1 illustrates the existing specifications:

Figure 1. Examples of Security Automation Specifications

languages, enumerations, metrics, integrity acronyms listed as a graphic

Streamlining Cisco IOS Software Vulnerability Assessment with OVAL

As previously mentioned, OVAL is designed to assist security administrators by accelerating the process of analyzing a system for the presence of vulnerability or configuration best practices. OVAL expedites information exchange and processing of such security-related information. Cisco is committed to protecting Cisco customers by sharing critical security-related information in appropriate formats. The Cisco Product Security Incident Response Team (PSIRT) includes OVAL definitions in Cisco IOS Software security advisories.

How OVAL Helps Security Automation

Vulnerability and patch management is the process of identifying the vulnerabilities in a system and prioritizing them according to their severity. Ensuring that systems are properly patched is a major concern among organizations because unpatched systems are a leading cause of system compromise. It is difficult to consume vulnerability information (that is, security advisories), identify affected devices and workarounds, and ensure the patch or fix has been implemented correctly.
Figure 2 provides a high-level overview of the patch-management process.

Figure 2. High-Level Overview of the Patch-Management Process

vendor announce, ID affected, ID workarounds, get patch, test patch, apply patch

 

OVAL provides a structured and standard machine-readable format that allows system security administrators to quickly consume security vulnerability information and identify affected devices. OVAL can also be used to verify that the patches or fixes that resolve such vulnerabilities were successfully installed.

In addition to vulnerability assessment, OVAL can also be used to verify whether a system is configured according to a validated and approved configuration. In other words, it can be used for configuration compliance checks. Security and network administrators can use configuration compliance or vulnerability management products (often called OVAL "scanners") to automate assessment of configuration compliance. Input for these products or systems is the information provided in the OVAL definition. This definition is an XML file that contains information about how to check a system for the presence of vulnerabilities, configuration issues, patches, installed applications, or other characteristics.

Note: OVAL definitions are discussed in detail later in this document.
The following are some of the major benefits OVAL offers:

  • Scalability
  • Single point of control
  • Reduction of risks due to human error
  • Breadth of coverage

Figure 3 provides a simple example of how an administrator can use an OVAL scanner to connect to several Cisco IOS routers over SSH and check them for the presence of vulnerabilities, configuration issues, and installed software.

Figure 3. OVAL Scanning

scanner SSH-ing to routers

Downloading Cisco OVAL Content

OVAL content (often called "definitions") can be downloaded directly from Cisco IOS Software security advisories. Each of these advisories includes a link to the corresponding OVAL definition(s). All Cisco Security Advisories are available at http://www.cisco.com/go/psirt.

OVAL Definitions

OVAL definitions are XML files that contain information about how to check a system for the presence of vulnerabilities, configuration issues, patches, installed applications, or other characteristics. For vulnerability checks, definitions are written to check for a vulnerability identified by a specific CVE identifier.
There are four main use cases, also called "classes," of OVAL definitions:

  • Vulnerability: Determine the presence of a vulnerability on the system being tested
  • Compliance: Validate a device configuration against a known or approved valid configuration
  • Inventory: Check for a specific software installed on the system
  • Patches: Find a specific patch on the system

Figure 4 illustrates the four main OVAL definition classes.

Figure 4. OVAL Definition Classes

definition classes also listed below figure in the text

Each OVAL definition includes at least the following information:

  • Metadata: The metadata includes the OVAL identifier (ID), status of the definition, OVAL version, and schema, references (such as CVE IDs and URLs for security advisories).
  • High-level summary: The high-level summary includes information about the existence of the vulnerability in the device, the name of the vulnerability in the definition, patch information, configuration settings, and workaround.
  • Detailed test: The detailed test describes the logic for checking the system configuration, software version information, and other system characteristics.

Because OVAL definitions are XML files, a schema is needed. An XML schema describes the structure of an XML document. It defines how the XML document should be constructed. More information about XML schemata is available at http://www.w3.org/standards/xml/schema.

OVAL definitions must comply with the OVAL Definition Schema and should be written in accordance with the Authoring Style Guide defined by MITRE. The MITRE OVAL Definition Lifecycle website has a detailed description of the OVAL definition process: http://oval.mitre.org/repository/about/stages.html.

Note: There may be rare instances in which a configuration check may not be possible for a given vulnerability because of limitations in the OVAL language and the current schema. In these cases, , only version checks may be possible. Cisco is working with MITRE and the OVAL community to enhance and develop new schemata to better support Cisco IOS Software and possibly other Cisco products. OVAL enables interoperability between security and network management products from different vendors in different vertical markets, allowing them to quickly and automatically perform vulnerability and compliance assessment of network infrastructure and networking devices. Many vendors are working on integrating Cisco IOS Software schemata support into their products. An example of an open source tool that supports the Cisco IOS OVAL schema is jOVAL. For more information about jOVAL, visit http://joval.org.

Scanning a Cisco IOS Device

The following sections provide step-by-step instructions for using OVAL content with the jOVAL open source tool.

Before You Begin

Prerequisites

This example configuration uses the jOVAL open source tool. Refer to the jOVAL Quick Start Guide (PDF) for instructions for installing jOVAL on a Windows or Linux system.
http://joval.org/wp-content/uploads/2012/02/Quick-Start-Guide.pdf

Components Used

The information in this document is based on a Cisco IOS device running Cisco IOS Software version 15.1(3)T.

To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the show version command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software release name. Other Cisco devices do not have the show version command or may provide different output.

The following example identifies a Cisco product that is running Cisco IOS Software Release 15.1(3)T with an installed image name of C2800NM-ADVSECURITYK9-M:

R1#show version
Cisco IOS Software, 2800 Software (C2800NM-ADVSECURITYK9-M), Version 15.1(3)T, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Mon 15-Nov-10 21:41 by prod_rel_team
ROM: System Bootstrap, Version 12.4(13r)T, RELEASE SOFTWARE (fc1)

!--- output truncated

Additional information about Cisco IOS Software release naming conventions is available in White Paper: Cisco IOS and NX-OS Software Reference Guide: http://www.cisco.com/web/about/security/intelligence/ios-ref.html
Note: The information presented in this OVAL document was created from devices in a specific lab environment. If you are working in a live network, ensure that you understand the potential impact of any command before using it.

Network Topology

The following examples use the network topology illustrated in Figure 5.

Figure 5. Network Topology

host with scanner, corp network, router

The network topology is very simple. A host with the OVAL scanner is connected to the corporate network. The Cisco IOS router (R1) is also connected to the corporate network. In this example, the host is running the jOVAL open source OVAL scanner. R1 is configured with the IP address 172.18.122.246.

Note: The IP addressing schemes used in this configuration are not routable on the Internet. They are RFC 1918 addresses, which have been used in a lab environment.

Using jOVAL to Scan the Cisco IOS Router

jOVAL can connect to a Cisco IOS device using the SSH protocol. Alternatively, jOVAL can use a local file with the output of the Cisco IOS show tech-support command. In this example, jOVAL will connect to R1 using SSH.

Note: To find additional information about the Cisco IOS commands used in this document, use the Command Lookup Tool (registered customers only).

jOVAL uses the definition interpreter called jovaldi. The following example shows the output of the jovaldi.bat -h command, which lists all the command-line options of the jOVAL command-line interface (CLI).


D:\joval>jovaldi.bat -h

----------------------------------------------------
jOVAL Definition Interpreter
Version: 5.10.1.1_Dev
Build date: Mon May 21 00:00:04 CDT 2012
Copyright (c) 2011, 2012 - jOVAL.org

Plugin: Default Plugin
Version: 5.10.1.1_Dev
Copyright (C) 2011, 2012 - jOVAL.org
----------------------------------------------------

Start Time: Sat Sep 01 21:25:25 2012


Command Line: jovaldi [options] MD5Hash

Options:
   -h           = show options available from command line.

Definition Evaluation Options:
   -o   = path to the oval-definitions xml file.
                  DEFAULT="definitions.xml"
   -v   = path to external variable values file.
                  DEFAULT="external-variables.xml"
   -e   = evaluate the specified list of definitions. Supply definition
                  ids as a comma separated list like: oval:com.example:def:123
   -f   = path to a file containing a list of definitions to be
                  evaluated. The file must comply with the evaluation-id
                  schema.

Input Validation Options:
   -m           = do not verify the oval-definitions file with an MD5 hash.
   -c   = perform Schematron validation on the input OVAL Definitions.
                  Path to an xsl may optionally be specified.
                  DEFAULT="xml/oval-definitions-schematron.xsl"

Data Collection Options:
   -a   = path to the directory that contains the OVAL schema.
                  DEFAULT="xml"
   -i   = path to input System Characteristics file. Evaluation will be
                  based on the contents of the file.

Result Output Options:
   -d   = save data to the specified XML file.
                  DEFAULT="system-characteristics.xml"
   -g   = path to the oval directives configuration file.
                  DEFAULT="directives.xml"
   -r   = save results to the specified XML file.
                  DEFAULT="results.xml"
   -s           = do not apply a stylesheet to the results xml.
   -t   = apply the specified xsl to the results xml.
                  DEFAULT="xml/results_to_html.xsl"
   -x   = output xsl transform results to the specified file.
                  DEFAULT="results.html"
   -j   = perform schema/schematron validation on the output OVAL
                  System Characteristics. Path to an xsl may optionally be
                  specified.
                  DEFAULT="xmloval-system-characteristics-schematron.xsl"
   -k   = perform schema/schematron validation on the output OVAL
                  Results. Path to an xsl may optionally be specified.
                  DEFAULT="xml/oval-results-schematron.xsl"

Other Options:
   -l  = Log messages at the specified level. (DEBUG = 1, INFO = 2,
                  MESSAGE = 3, FATAL = 4)
   -p           = print all information and error messages.
   -y   = save the jovaldi.log file to a specific location.
   -z           = return md5 of current oval-definitions file.

Plugin Management Options:
   -plugin   = name of the jovaldi plugin to use for the scan. Valid
                       choices are "default", "remote" and "cisco".
                       DEFAULT="default"
   -config   = configuration information for the plugin.  See plugin
                       help for information on valid configuration parameters.
                       (To see help for a specific plugin, use the -plugin
 option to specify the desired plugin, followed by
                       the -h option for help text).
                       DEFAULT="config.properties"

Configuration Options for the Default Plugin:
   The default plugin has no configuration options.

D:\joval>

jOVAL's remote plug-in is configured using the -config <file> option of jovaldi. The help system for jOVAL provides excellent instructions for each of the configuration options for the Remote Plugin, as shown below. 


Configuration Options for the Remote Plugin:
   The remote plugin is configured using the program's -config  option.
   The  argument should point to a Java .properties file, which is a
   text file consisting of name/value property pairs delimited by line-breaks.
   Each line is of the format name=value. Comments may be placed in the file by
   beginning a line with a #-mark, which will cause the line to be ignored. The
   following property names are defined for the remote plugin:

   Property Name   Description
   -------------   ------------------------------------------------------------
   hostname        The hostname or IP address of the target to scan.
   user.name       The username to use to log into the host.
   user.password   The username's password.
   nt.domain       An optional property for Windows hosts.  If not specified,
                   the default will be the local hostname.
   key.file        An optional property for Unix hosts specifying the path to a
                   file containing an RSA SSH private key.
   key.password    An optional property for Unix hosts specifying the password
                   used to unlock the private key file.
   root.password   An optional property for Unix hosts specifying the password
                   for the root account.
   gw.host         The hostname or IP address of an SSH gateway, through which
                   the connection to the target host should be made.
   gw.user         The username for the SSH gateway.
   gw.pass         The password for the SSH gateway.
   gw.keyFile      The path to the file containing an SSH private key, if
                   needed to connect to the gateway.
   gw.keyPass      The passphrase required to read the private key.

In this example, the configuration file is very simple and includes the following information:

hostname=172.18.122.246
user.name=cisco
user.password=th1$isNoTSeCuR3

The hostname is the IP address of R1 (172.18.122.246), the router's SSH username is cisco and the password is th1$isNoTSeCuR3.

The document at the following link discusses how to configure and debug SSH on Cisco routers or switches that run a version of Cisco IOS Software that supports SSH:

http://www.cisco.com/en/US/tech/tk583/tk617/technologies_tech_note09186a00800949e2.shtml

In the following example, the OVAL definition for the vulnerability with the CVE ID CVE-2012-0381 will be used. The OVAL definition filename is cisco-sa-20120328-ike-CVE-2012-0381_oval.xml and it resides in a directory called DEFINITIONS. CVE-2012-0381 addresses a vulnerability that affects the Cisco IOS Software Internet Key Exchange (IKE) implementation. R1 is configured for IPsec and it is running an affected version. The following is an excerpt of the IPsec/IKE configuration of R1:

crypto isakmp policy 10
 encr aes 256
 authentication pre-share
!
crypto map test 10 ipsec-isakmp
 set peer 10.10.10.10
 match address 101
!
interface FastEthernet0/1
 ip address 14.4.1.126 255.255.255.0
 crypto map test

To scan R1, the jovaldi.bat -plugin remote -m -o DEFINITIONS\cisco-sa-20120328-ike-CVE-2012-0381.xml command was used, as shown in the following example:

D:\joval>jovaldi.bat -plugin remote -m -o DEFINITIONS\cisco-sa-20120328-ike-CVE-2012-0381.xml
----------------------------------------------------
jOVAL Definition Interpreter
Version: 5.10.1.1_Dev
Build date: Mon May 21 00:00:04 CDT 2012
Copyright (c) 2011, 2012 - jOVAL.org

Plugin: jOVALRemotePlugin by jOVAL.org(TM)
Version: 5.10.1.1_Dev
Copyright (C) 2011, 2012 - jOVAL.org
----------------------------------------------------

Start Time: Sat Sep 01 18:08:58 2012

 ** parsing D:\joval\DEFINITIONS\cisco-sa-20120328-ike-CVE-2012-0381.xml
     - validating xml schema.
 ** checking schema version
     - Schema version - 5.10
 ** skipping Schematron validation
 ** creating a new OVAL System Characteristics file.
 ** gathering data for the OVAL definitions.
      Collecting object:  FINISHED
 ** saving data model to system-characteristics.xml.
 ** skipping Schematron validation
 ** running the OVAL Definition analysis.
      Analyzing definition:  FINISHED
 ** OVAL definition results.

    OVAL Id                                 Result
    -------------------------------------------------------
    oval:cisco.oval:def:13                  true
    -------------------------------------------------------


 ** finished evaluating OVAL definitions.

 ** saving OVAL results to results.xml.
 ** skipping Schematron validation
 ** running OVAL Results xsl: xml\results_to_html.xsl.

The preceding example shows the output of the command. The results show that R1 is vulnerable (Result = true). An HTML file is also created with detailed information about the results of the scan. The output of this file is shown in Figure 6.

Figure 6. Scan Results of a Vulnerable Device

OVAL definition results at the bottom of the screen show true with vuln details

 

In the following example, IPsec was disabled on R1. After this change, the device was not vulnerable. The output of jovaldi.bat after IPsec was disabled on R1 is shown below:

D:\joval>jovaldi.bat -plugin remote -m -o DEFINITIONS\cisco-sa-20120328-ike-CVE-2012-0381.xml

----------------------------------------------------
jOVAL Definition Interpreter
Version: 5.10.1.1_Dev
Build date: Mon May 21 00:00:04 CDT 2012
Copyright (c) 2011, 2012 - jOVAL.org

Plugin: jOVALRemotePlugin by jOVAL.org(TM)
Version: 5.10.1.1_Dev
Copyright (C) 2011, 2012 - jOVAL.org
----------------------------------------------------

Start Time: Sat Sep 01 18:13:17 2012

 ** parsing D:\joval\DEFINITIONS\cisco-sa-20120328-ike-CVE-2012-0381.xml
     - validating xml schema.
 ** checking schema version
     - Schema version - 5.10
 ** skipping Schematron validation
 ** creating a new OVAL System Characteristics file.
 ** gathering data for the OVAL definitions.
      Collecting object:  FINISHED
 ** saving data model to system-characteristics.xml.
 ** skipping Schematron validation
 ** running the OVAL Definition analysis.
      Analyzing definition:  FINISHED
 ** OVAL definition results.

    OVAL Id                                 Result
    -------------------------------------------------------
    oval:cisco.oval:def:13                  false
    -------------------------------------------------------


 ** finished evaluating OVAL definitions.

 ** saving OVAL results to results.xml.
 ** skipping Schematron validation
 ** running OVAL Results xsl: xml\results_to_html.xsl.

----------------------------------------------------

The preceding example shows the output of the command. The results show that R1 is not vulnerable (Result = false). The HTML report was also created and the output is shown in Figure 7.

Figure 7. Scan Results of a Nonvulnerable Device

OVAL definition results at the bottom of the screen show false

 

Summary

Security automation is an evolving and exciting undertaking. Cisco is committed to protecting Cisco customers by sharing critical security-related information in different formats and will continue to work with the security community to enhance capabilities of existing and new languages and protocols to overcome today's security challenges.

References

SCAP website
http://scap.nist.gov

MITRE OVAL website
http://oval.mitre.org

Current version of the OVAL Language
http://oval.mitre.org/language

National Vulnerability Database (NVD)
http://nvd.nist.gov

Common Configuration Enumeration (CCE)
http://cce.mitre.org

Common Platform Enumeration (CPE)
http://cpe.mitre.org

Common Vulnerabilities and Exposures (CVE)
http://cve.mitre.org

Common Vulnerability Scoring System (CVSS)
http://www.first.org/cvss

Extensible Configuration Checklist Description Format (XCCDF)
http://nvd.nist.gov/xccdf.cfm

Open Vulnerability and Assessment Language (OVAL)
http://oval.mitre.org

Cisco public vulnerability policy
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

Cisco Security Intelligence Operations portal
http://www.cisco.com/security

 

This document is part of Cisco Security Intelligence Operations.

This document is provided on an "as is" basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information on the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document at any time.

Back to Top

Cisco Security Intelligence Operations