In 2014, almost 10,000 vulnerabilities were disclosed worldwide. There were so many that the Common Vulnerabilities and Exposures (CVE) system was changed to accommodate up to 10 million disclosures a year in the future. Of course, not every one of those was used by attackers, and still fewer became exploits that could cause significant damage to an organization. The problem for security teams and IT organizations of all sizes rapidly becomes one of information overload: thousands of vulnerability announcements exist that must be tracked, validated, and—in some circumstances—acted on.

Summary

The security team in your organization knows that it needs to keep up to date about the latest security vulnerabilities that threaten your network infrastructure. But with the large quantity of new vulnerabilities from numerous vendors, how can the team analyze any single vulnerability and determine its relevance to your specific technology architecture?

Based on customer input, Cisco Systems has developed Security Impact Rating and vulnerability risk triage methods that can be used by customers to rapidly determine what action to take in response to a vulnerability report. Working in conjunction with vulnerability scoring methods such as the Common Vulnerability Scoring System (CVSS) and your organization’s own security policies and vulnerability management procedures, the vulnerability response method can help clarify a course of action in a minimal amount of time.

Challenge: Determining the Appropriate Response to a Vulnerability Announcement

Security vulnerabilities will continue to be discovered in technology products and services. These vulnerabilities, regardless of whether they are caused by an unintentional software bug or by design (such as a default administrative password), can be used by malicious persons to compromise the confidentiality, availability, or integrity of your infrastructure.

Hardware and software vendors typically provide software fixes when they announce vulnerabilities in their products. When there is no fix available, vendors attempt to provide a workaround or mitigation. This means there is usually a period of time between the announcement of a security vulnerability in a particular technology the availability of an attack method (an exploit). Within this time period, system administrators should take action to protect their systems against an attack because at this point the public knows a flaw exists, but attackers are still trying to find a way to take advantage of that vulnerability.

Unfortunately, the vulnerability-to-exploit time period has been steadily decreasing. Over 10 years ago, the time between a vulnerability announcement and the availability of the corresponding exploit could be measured in months or years. For example, when Microsoft announced a vulnerability on October 17, 2000 (MS00-078), the exploit came in the form of the Nimda worm on September 18, 2001, effectively giving security teams 336 days to patch their systems. In 2004, this time decreased to 17 days when the Sasser.A worm exploited MS04-011. An exploit for MS05-051 was available 16 hours after it was announced. Recently, in the December 2015 Microsoft security update, exploits for two of the eight disclosed vulnerabilities were available when the public announcement was made. Of course, this trend is not just limited to vulnerabilities with Microsoft products, but also includes operating systems, applications, and hardware from other vendors.

The vulnerabilities previously discussed went through the established industry practice of responsible vendor disclosure when a software fix or workaround was available, but this is not always the case. Sometimes information about a previously undisclosed vulnerability emerges on the Internet before the vendor is notified and has time to take action. In these situations, the vulnerability-to-exploit time period is “reversed,” in that the attackers have a working exploit for a vulnerability that no one except the attackers knew existed. This situation is becoming far more common as vendors integrate open source and common third-party software packages. The result is that public information about vulnerabilities and exploits is often available before the vendor has a time to patch images or provide clear guidance to customers.

In October 2015, the Cisco security vulnerability policy expanded to disclose vulnerabilities with medium, high, and critical impacts in a unified format. This change made it easier for managers to obtain vulnerability information about lower-severity vulnerabilities but also increased the amount of information that security staff members must triage. To help organizations deal with this increase, one month later, Cisco also made advisories available to registered customers through a web-based application programming interface (API).

Preparing for “Day Zero” Threats—Without Panicking

Security teams must prepare for new threats that emerge with little or no warning. Part of the solution to this problem lies in technology. It is increasingly common to include the ability to detect and mitigate attacks on various devices, including routers, switches, security appliances, and end hosts. Proper device hardening and use of security features on these devices can go a long way toward stopping a major outbreak before it occurs.

But even as organizations evolve their technology infrastructure to deal with threats, a security team’s operational procedures must evolve as well. If the security team’s procedures for handling vulnerabilities assume a comfortable margin of time between vulnerability and exploit, the team might not have enough time to take action before the system is compromised.

It can be overwhelming to track all vulnerabilities; the solution is to have a good process to determine which ones are relevant to your organization. This prevents overreaction and mistakes inherent in rapid, poorly planned upgrades or configuration changes.

Cisco has seen this behavior occasionally when new security vulnerabilities are announced. For many customers, panic ensues. They often learn later that they were never affected by the vulnerability in the first place—either they did not run the affected platform, had other mitigation strategies in place to defeat the attack, or the effect to their organization from a successful attack was much less severe than their initial response indicated. A drawback to this type of panic response is that when a severe vulnerability is announced, the security apparatus of the organization may have become desensitized to the level of urgency that mitigation requires.

The Risk Triage Solution: Right Urgency, Right Understanding

Cisco recommends that customers evaluate CVSS for the purposes of understanding vulnerability severity. CVSS is an open framework for communicating the characteristics and severity of software vulnerabilities (https://www.first.org/cvss). CVSS scoring helps customers prioritize vulnerabilities by vendor-defined severity, environment impact, and exploitability.

If customers are not using CVSS, the following model allows customers to make quick, informed decisions about a particular security vulnerability based on its severity as well as relevance to and effect on the organization. The model helps prioritize vulnerabilities so that limited resources can be focused on the most impactful issues.

This Risk Vulnerability Response Model is one method of performing triage on a security vulnerability regardless of vendor. Customers are encouraged to examine the model, modify it if necessary, and use it to determine the appropriate action to be taken by the security team or other affected groups in their organization.

The model should be considered an adjunct to other best common practices for vulnerability management. One element of this model is the impact of the vulnerability. Cisco has provided a Security Impact Rating (SIR) to classify vulnerabilities into four categories: Low, Medium, High, and Critical.

Figure 1 illustrates the Risk Vulnerability Response Model. A later section of this paper describes each decision point in detail.

Figure 1. Risk Vulnerability Response Model

Understanding the Model

The Risk Vulnerability Response Model is straightforward to use. It allows frontline security team members to determine the relevance of a vulnerability and then initiate the appropriate response process. For each of the four outcomes, Cisco recommends that customers define policies and processes that permit systematic, repeatable responses to security advisories and other vulnerability disclosures.

This recommendation also extends to customers that traditionally have not been as eager to install security fixes. Although some customers might determine that there are valid reasons not to deploy changes to their infrastructure if a security vulnerability’s severity is below a certain threshold, it remains important that customers have a process to make informed and repeatable decisions. This holds true even if that decision is to determine that the cost of installing the fix is greater than the benefit to security.

A common criticism of vendor-defined risk categorizations is that the vendor sets the level of urgency, regardless of the effect by the vulnerability on any specific organization. In the case of the Risk Vulnerability Response Model, several crucial questions are affected by the relevance of the vulnerability to the organization itself. It is possible that two organizations with two different technical architectures might arrive at different conclusions about how to treat the same vulnerability.

Output Urgency Levels

Running a vulnerability announcement through the model will result in one of four possible outcomes. These outcomes are based on the SIR provided in the Cisco Security Advisory and will direct the organization to implement one of four predetermined action plans, based on the organization’s security needs, policies, and processes (Table 1).

Table 1. Urgency Levels

Level

Urgency

Description

0

No action required

The organization is not susceptible to this vulnerability.

1

Standard maintenance process

A vulnerability of level 1 urgency poses a potential risk. Such a vulnerability should be mitigated as part of an organization’s standard maintenance cycle. Standard maintenance ideally should occur at regular intervals.

2

Priority maintenance process

A vulnerability of level 2 urgency poses a likely risk to the organization. Such a vulnerability should be mitigated during the organization’s next priority maintenance cycle.

3

Immediate mitigation process

A vulnerability of level 3 urgency poses an imminent risk to the organization. Actions to mitigate such a vulnerability should be implemented immediately.

Using the Model

Using the model is straightforward. By answering the following questions in Table 2 for a vulnerability announcement, the organization will arrive at one of the four urgency levels defined in Table 1.

Does the product run a version or combination of software (or, occasionally, hardware) that contains the vulnerability?

Vulnerable component enabled?

Is the product configured in such a way that the vulnerability is exposed, through either explicit configuration or default condition?

Workaround feasible?

Are methods to prevent exploitation of the vulnerability readily available and practical to implement? Consider both the vulnerable hosts and the surrounding infrastructure.

Workaround implemented?

Are methods to prevent exploitation of the vulnerability already in place?

Security Impact Rating

Critical: The vulnerability has the potential of severe impact to the organization, often resulting in unauthorized access to the device or network. Typically, these score over 9.0 in CVSS.

High: The vulnerability has the potential of significantly impacting the organization, often resulting in outages or loss of confidential information. These typically score between 7.0 and 8.9 in CVSS.

Medium: The vulnerability has potential impact during phishing attacks or when combined with another vulnerability. Examples include cross-site scripting attacks, cross-site request forgeries, and privilege escalations. These typically score between 4.0 and 6.9 in CVSS.

Low: The vulnerability has minimal impact, often providing information that is used for reconnaissance. Typically, these score below 4.0 in CVSS and are published as a Bug Release Note Enclosure (RNE) instead of a Cisco Security Advisory.

Attack confidence?

Based on the best available information, are exploit methods available for the vulnerability, and is an attack likely?

Low: The vulnerability is considered difficult or impractical to exploit. Attacks are unlikely at this time.

Medium: Proof of concept or technically challenging exploit methods are known to be circulating for the vulnerability. Attacks are possible at this time.

High: Exploit methods are widely understood and circulated for the vulnerability. Attacks are likely and expected.

Significant collateral damage?

In a worst-case scenario, would there be substantial downstream/collateral damage to other systems that might result in addition to the initial compromise of confidentiality, integrity, or availability of the affected product? Consider technical operations, business processes, negative press, property damage, and risk to human life.

For example, a denial of service (DoS) attack against a core router can affect the overall stability of the network, disrupt traffic that would transit that router, and so on. A DoS attack against a manufacturer’s extranet VPN concentrator can prevent shipping product to customers, a core business function. The organization should answer this question relative to its business and technical goals as well as its infrastructure.

After the security team members have arrived at one of the four conclusions, initiate the appropriate predefined response process.

Conclusion

Managing vulnerabilities is an increasingly complex process. There are more vulnerabilities that have to be examined and less time in which to determine the threat any given vulnerability poses. Underreacting and overreacting both carry significant risks, which in some cases can be more damaging than an attack.

Vulnerability risk triage provides a quick way to evaluate incoming vulnerabilities and determine their potential severity to the organization. Managers can adapt the Cisco Risk Vulnerability Response Model to fit the needs of their organization, along with other industry best practices and effective use of technology, to manage this challenge.

References

The following references provide links to information about vulnerability discovery and incident response:

Learning About Vulnerabilities

The first step in the Risk Vulnerability Response Model is to learn about new security vulnerabilities. There are many sources for learning about security vulnerabilities that threaten your enterprise.

Vendor announcements: Software and hardware vendors (including Cisco) publish security advisories regarding their products. Announcements are often posted to mailing lists and websites. Check with your vendor to learn about its security announcement procedures and how to enroll in its process. To learn more about Cisco Security Advisories, visitwww.cisco.com/go/psirt.

Industry mailing list forums: There are numerous security mailing lists where vendors, independent researchers, and other interested persons discuss the latest vulnerabilities and countermeasures. Among the more well-known of these lists is BUGTRAQ, available at www.securityfocus.com.

Vulnerability intelligence services: There are an increasing number of intelligence services available from vendors that collate and analyze security vulnerability information from numerous sources and provide a continual feed of relevant security information to their customers. Cisco provides security information in the Cisco Security portal, which is available at https://www.cisco.com/security

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.