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 athttp://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.

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 and accurate correlation of configuration issues in enterprise systems. More information about CCE is available at http://nvd.nist.gov/cce/index.cfm.

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

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. Cisco provides a base and temporal CVSS score for each vulnerability disclosed via security advisories and other disclosure methods. Customers can compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has a FAQ regarding CVSS at //www.cisco.com/web/about/security/intelligence/cvss-qandas.html.Cisco has also provided a CVSS calculator to compute the environmental impact for individual networks at http://intellishield.cisco.com/security/alertmanager/cvss.
More information about CVSS is available at http://www.first.org/cvss.

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.

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

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

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

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.

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:

Additional information about Cisco IOS Software release naming conventions is available in White Paper: Cisco IOS and NX-OS Software Reference Guide://www.cisco.com/web/about/security/intelligence/ios-ref.htmlNote: 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

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).

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.

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:

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

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:

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

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.