Showing results for 
Search instead for 
Did you mean: 

Help! I Need to Respond to All These Cisco IOS Software Vulnerabilities and I Cannot Scale!!!

Omar Santos
Cisco Employee

No software is immune to security vulnerabilities. The time between the discovery and disclosure of security vulnerabilities and the availability of an exploit is getting shorter. This imposes pressures on network security professionals and information technology (IT) managers to quickly respond to security vulnerabilities or apply mitigation in their network. Many organizations are struggling to keep up-to-date with the constant release of new vulnerabilities and software fixes. At the same time, they are under pressure to provide near 100% availability of key business services and systems.

Note: Cisco has a very robust vulnerability management process. This process is described in detail at Cisco’s Security Vulnerability Policy. The Cisco Product Security Incident Response Team (PSIRT) manages the receipt, investigation, and public reporting of security vulnerability information that is related to Cisco products and networks.

As an example, every time Cisco discloses a security vulnerability for Cisco IOS Software (or any given product), network security administrators have to identify affected devices and (in numerous cases) upgrade such devices. These activities can take hours, days, or even weeks depending on the size of the organization. For instance large enterprises and organizations may have thousands of routers and switches that need to be assessed for the impact of any given vulnerability.

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

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:


  • 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

  • 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

  • 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:

  • 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

  • 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

    Note: Two emerging languages are Asset Summary Reporting (ASR) and the Open Checklist Reporting Language (OCRL). More information about ASR is available at


  • 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. More information about CVE is available at

  • 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

  • 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 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 Another emerging enumerator is the Common Remediation Enumeration (CRE). More information about CRE is available at



Cisco’s New OVAL Support

Cisco is committed to protect customers by sharing critical, security-related information in different formats.As you may remember in a recent blog post, Automating Cisco IOS Vulnerability Assessment, the Cisco PSIRT is including OVAL definitions in Cisco IOS security advisories.The following are some of the major benefits that OVAL offers:

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

The following 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. of Cisco IOS Devices Using OVAL

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

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). Currently only Cisco IOS Software is supported. 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.

Please Provide Us Feedback and Comments!

Whether you are exploring security automation capabilities such as OVAL/SCAP; or have already implemented solutions that support OVAL/SCAP (or any other security automation standard or offering), please post your comments here or ask any questions.

Lisa Latour
Frequent Contributor

Excellent Blog, Omar! Thank you so much for your contribution!

Omar Santos
Cisco Employee

Thank you!


Alright... +1 street cred given back to Cisco.  It is releiving to see that there are aspects of Cisco, admittadly a massive entity and as cumbersome as any its size... releiving to see that some places are organized and in healthy running order.

That was a wonderful article to read.  I've recently been working with some Linksys product line devices and am wondering now if I should be using some parts of the process/infrastructure you took us through to report and describe various issue that I am experiencing.  Only a handful of them could be written from the perspective of exploitable security vulnerabilities.  Most of the items I want to disclose are bugs of a not so dangerous, but increadibly unsettling... well, let's just say I've been taking streat credit quite a bit throughout my evaluation.  I'm glad that I came across this post and had a little faith restored.

Content for Community-Ad