Guest

Security Automation Using OVAL

Contents

The Importance of Security Automation
Security Content Automation Protocol
      Languages
      Enumerations
      Metrics
      Integrity
Streamlining Cisco IOS and IOS XE Software Vulnerability Assessment with OVAL
      How OVAL Helps Security Automation
      Downloading Cisco OVAL Content
      OVAL Definitions
      Scanning a Cisco IOS or IOS XE Software Device
Conclusion
References

The Importance of Security Automation

Most security and network administrators seek 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 was developed to address most of these challenges.

Security Content Automation Protocol

The 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. 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 https://oval.cisecurity.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 user responses to a set of questions. More information about OCIL is available at http://scap.nist.gov/specifications/ocil.
  • Asset Identification (AI): AI is a specification that defines constructs for correlating 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 a transport format for information about enterprise assets and provides a standardized data model to streamline reporting the information. More information about ARF is available at http://scap.nist.gov/specifications/arf.

Two additional, emerging languages are Asset Summary Reporting (ASR) and OVAL Reporting, formerly referred to as the Open Checklist Reporting Language (OCRL). More information about ASR is available at http://scap.nist.gov/specifications/asr/. More information about OVAL Reporting is available at http://oval.mitre.org/language/about/reporting.html.

Enumerations

  • Common Vulnerabilities and Exposures (CVE): CVE assigns identifiers to publicly known security vulnerabilities. Cisco assigns CVE identifiers to security vulnerabilities according to the Cisco Security Vulnerability Policy. 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://nvd.nist.gov/cpe.cfm.
  • 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, accurate correlation of configuration issues in enterprise systems. More information about CCE is available at http://nvd.nist.gov/cce/index.cfm.

Other community-developed enumerators, such as Common Weakness Enumeration (CWE), are currently being expanded and further developed. CWE is a dictionary of common software architecture, design, code, and implementation weaknesses that could lead to security vulnerabilities. More information about CWE is available at 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

  • Common Vulnerability Scoring System (CVSS): CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine the urgency and priority of response. For each vulnerability disclosed about a Cisco product via a Cisco Security Advisory or other disclosure method, Cisco provides a CVSS Base score. Customers can additionally compute Temporal and Environmental scores to help determine the impact of a vulnerability on individual networks. For each vulnerability disclosed for a vendor product via a Vulnerability Alert or other disclosure method, Cisco provides a Base and a Temporal score. Cisco also provides a CVSS calculator to help customers compute the environmental impact and temporal parameters for individual networks, and a CVSS FAQ. More information about CVSS is available at http://www.first.org/cvss.
  • Common Configuration Scoring System (CCSS): CCSS is a set of measures for the severity of software security configuration issues. More information about CCSS is available at http://csrc.nist.gov/publications/nistir/ir7502/nistir-7502_CCSS.pdf.

Two additional, 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 and 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

The Trust Model for Security Automation Data (TMSAD) is a trust model to maintain the integrity, authentication, and traceability of security automation data. More information about TMSAD is available at http://csrc.nist.gov/publications/nistir/ir7802/NISTIR-7802.pdf.

Streamlining Cisco IOS and IOS XE Software Vulnerability Assessment with OVAL

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

How OVAL Helps Security Automation

Vulnerability and patch management is the process of identifying the vulnerabilities in a system and prioritizing them by severity. Ensuring that systems are patched properly 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 a patch or fix was implemented correctly. Figure 1 provides an overview of the patch-management process.

Figure 1. 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 address such vulnerabilities were installed successfully.

In addition to vulnerability assessment, OVAL can 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. For example, an administrator can use an OVAL scanner to connect to several Cisco IOS Software routers via the Secure Shell (SSH) protocol and check those routers for the presence of vulnerabilities, configuration issues, and installed software. The input for these products or systems is the information in an 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. Overall, some of the major benefits that OVAL offers are: scalability, a single point of control, a reduction of risk due to human error, and breadth of coverage.

Downloading Cisco OVAL Content

OVAL content, often called OVAL definitions, can be downloaded directly from Cisco Security Advisories for Cisco IOS Software and Cisco IOS XE Software. Each of these advisories includes a link to one or more corresponding OVAL definitions. All Cisco Security Advisories are available from https://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 (CVE ID).

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 specific software installed on the system
  • Patches: Find a specific patch on the system

Figure 2 illustrates the four main OVAL definition classes.

Figure 2. OVAL Definition Classes

definition classes also listed below figure in the text

Each OVAL definition minimally includes the following information:

  • Metadata: The metadata includes the OVAL identifier (ID), status of the definition, OVAL version and schema, and references such as CVE IDs and URLs for associated security advisories.
  • High-level summary: The high-level summary includes information about the existence of the vulnerability on the device, the name of the vulnerability in the definition, patch information, configuration settings, and workarounds.
  • 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, an XML schema is needed to describe the structure of the OVAL definition files. The schema defines how the file should be constructed. OVAL definitions must comply with the OVAL Definition Schema and should be written in accordance with the guidance defined by resources in the OVAL repository in GitHub.

There may be rare instances in which a configuration check is not possible for a given vulnerability due to limitations in the OVAL language and the current schema. In these cases, only version checks may be possible. Cisco is working with the OVAL community to enhance and develop new schemata to better support Cisco IOS Software, Cisco IOS XE Software, and possibly other Cisco products. OVAL enables interoperability between security and network management products from different vendors in different vertical markets, allowing organizations to quickly and automatically perform vulnerability and compliance assessment of network infrastructure and networking devices. Many vendors are working to integrate support for Cisco IOS Software and Cisco IOS XE Software schemata in their products. Joval is one example of a tool that supports the OVAL schema for Cisco IOS Software and Cisco IOS XE Software. For more information about the Joval tool, visit the Joval website.

Scanning a Cisco IOS or IOS XE Software Device

The following sections provide step-by-step guidance for using OVAL content and the Joval tool to scan a device that is running Cisco IOS Software.

Before You Begin

The examples in this section were created by using 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.

Prerequisites

The examples use the Joval tool. For information about installing the tool on a Windows or Linux system, see the Joval Support website.

Components Used

The examples are based on a device that is running Cisco IOS Software Release 15.1(3)T.

To determine which Cisco IOS Software release is running on a device, administrators can log in to the device, issue the show version command in the CLI, and then refer to the system banner that appears. If the device is running Cisco IOS Software, the system banner displays text similar to Cisco Internetwork Operating System Software or Cisco IOS Software. The banner also displays the installed image name in parentheses, followed by the Cisco IOS Software release number and release name. Some Cisco devices do not support 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) . . .

For information about the naming and numbering conventions for Cisco IOS and IOS XE Software, see White Paper: Cisco IOS and NX-OS Software Reference Guide.

Network Topology

The examples use the network topology illustrated in Figure 3.

Figure 3. Network Topology

host with scanner, corp network, router

The network topology is very simple. A host with an OVAL scanner is connected to the corporate network. The host is running the Joval OVAL scanner. A router (R1) is also connected to the corporate network. The router (R1) is running Cisco IOS Software Release 15.1(3)T and is configured with the IP address 172.18.122.246. Note that the IP addressing schemes used in these examples are not routable on the Internet. They are addresses defined by RFC 1918 and they were used in a lab environment.

Using Joval to Scan the Router

The Joval tool can connect to a Cisco IOS or IOS XE Software device by using either SSH or a local file that contains the output of the show tech-support command. In this example, the tool will connect to R1 by using SSH. For information about configuring SSH on devices running Cisco IOS Software, see Configuring Secure Shell on Routers and Switches Running Cisco IOS.

The Joval tool uses an OVAL definition interpreter named jovaldi. The following example shows the output of the interpreter's jovaldi.bat -h command, which lists all the command-line options of the Joval 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 by using the -config <file> option of the jovaldi interpreter. Note that the Joval help system provides excellent information about each of the configuration options for the Joval remote plugin, as shown below.

Configuration Options for the Remote Plugin:
   The remote plugin is configured using the program's -config <file> 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 these examples, 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.

In addition, the examples use the OVAL definition for the vulnerability with the CVE ID CVE-2012-0381, which addresses a vulnerability in the implementation of Internet Key Exchange (IKE) functionality in Cisco IOS Software. The name of the OVAL definition file is cisco-sa-20120328-ike-CVE-2012-0381_oval.xml and the file is in a directory named DEFINITIONS. R1 is configured for IPsec and is running an affected release of the software.

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. The following example shows the use and output of the command:

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 command output indicates that R1 is vulnerable (Result = true). In addition, an HTML file was created and the file provides detailed information about the results of the scan. The contents of this file are shown in Figure 4.

Figure 4. Scan Results for a Vulnerable Device

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

 

The following example shows the use and output of the jovaldi.bat -plugin remote -m -o DEFINITIONS\cisco-sa-20120328-ike-CVE-2012-0381.xml command after IPsec was disabled on R1. After this change, the device was not vulnerable.

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 command output indicates that R1 is not vulnerable (Result = false). In addition, an HTML file was created and the file provides detailed information about the results of the scan. The contents of this file are shown in Figure 5.

Figure 5. Scan Results for a Device That Is Not Vulnerable

OVAL definition results at the bottom of the screen show false

Conclusion

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 security challenges.


This document is part of the Cisco Security portal.

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