The Importance of Security Automation
Security Content Automation Protocol
Streamlining Cisco IOS Software Vulnerability Assessment with OVAL
How OVAL Helps Security Automation
Downloading Cisco OVAL Content
Scanning a Cisco IOS Software Device
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:
- 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 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.
- 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.
- 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.
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.
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 about Cisco IOS Software.
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
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.
OVAL content, often called OVAL definitions, can be downloaded directly from Cisco Security Advisories about Cisco IOS Software. Each of these advisories includes a link to one or more corresponding OVAL definitions. All Cisco Security Advisories are available at http://www.cisco.com/go/psirt.
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 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
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 XML files. The schema defines how the XML file should be constructed. OVAL definitions must comply with the OVAL Definition Schema and should be written in accordance with the Authoring Style Guide defined by MITRE. For details about the stages of the OVAL definition process, see the MITRE OVAL Definition Lifecycle.
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 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 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 schemata in their products. Joval is one example of an open source tool that supports the OVAL schema for Cisco IOS Software. For more information about Joval, visit the Joval website.
Scanning a Cisco IOS Software Device
The following sections provide step-by-step guidance for scanning a Cisco IOS Software device by using OVAL content and the Joval open source tool.
Before You Begin
The examples in this section were 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.
The examples use the Joval open source tool. For information about installing Joval on a Windows or Linux system, see the Joval Support website.
The examples are based on a device 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 Software, see White Paper: Cisco IOS and NX-OS Software Reference Guide.
The examples use the network topology illustrated in Figure 3.
Figure 3. Network Topology
The network topology is very simple. A host with an OVAL scanner is connected to the corporate network. The host is running the Joval open source 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 were used in a lab environment.
Using Joval to Scan the Router
Joval can connect to a Cisco IOS Software device by using either SSH or a local file that contains the output of the Cisco IOS Software show tech-support command. In this example, Joval 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.
Joval 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: 188.8.131.52_Dev Build date: Mon May 21 00:00:04 CDT 2012 Copyright (c) 2011, 2012 - jOVAL.org Plugin: Default Plugin Version: 184.108.40.206_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 resides 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 220.127.116.11 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: 18.104.22.168_Dev Build date: Mon May 21 00:00:04 CDT 2012 Copyright (c) 2011, 2012 - jOVAL.org Plugin: jOVALRemotePlugin by jOVAL.org(TM) Version: 22.214.171.124_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 is created and the file provides detailed information about the results of the scan. The content of this file is shown in Figure 4.
Figure 4. Scan Results for a Vulnerable Device
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: 126.96.36.199_Dev Build date: Mon May 21 00:00:04 CDT 2012 Copyright (c) 2011, 2012 - jOVAL.org Plugin: jOVALRemotePlugin by jOVAL.org(TM) Version: 188.8.131.52_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 is created and the file provides detailed information about the results of the scan. The content of this file is shown in Figure 5.
Figure 5. Scan Results for a Nonvulnerable Device
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.