Guest

Risk Triage for Security Vulnerability Announcements

Contents

Summary
Challenge: Determining the Appropriate Response to a Vulnerability Announcement
      Preparing for “Day Zero” Threats—Without Panicking
The Risk Triage Solution: Right Urgency, Right Understanding
      Understanding the Model
      Using the Model
Conclusion
References

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

Summary

The security team in your organization knows that it needs to stay current on 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 and determine the relevance of any single vulnerability to your specific technology architecture?

Based on customer input, Cisco developed the Security Impact Rating (SIR) and vulnerability risk triage methods that customers can use 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 security policies and vulnerability management procedures, the Risk Vulnerability Response Model 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 can be used by attackers to compromise the confidentiality, availability, or integrity of your infrastructure, regardless of whether the vulnerabilities are caused by an unintentional bug or by design, such as a default administrative password.

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

Unfortunately, the vulnerability-to-exploit time period has been decreasing steadily. In the past, the time between a vulnerability announcement and the availability of a corresponding exploit could be measured in months or years. For example, when Microsoft announced a vulnerability on October 17, 2000 (Microsoft Security Bulletin MS00-078), the exploit came in the form of the Nimda worm on September 18, 2001, which effectively gave security teams 336 days to patch their systems. In 2004, this timeframe decreased to 17 days when the Sasser.A worm exploited a vulnerability that Microsoft announced in Microsoft Security Bulletin MS04-011. Similarly, an exploit for the vulnerability disclosed in Microsoft Security Bulletin MS05-051 was available only 16 hours after Microsoft announced the vulnerability. More recently, in the December 2015 Microsoft security update, exploits were available for two of the eight disclosed vulnerabilities when Microsoft made the public announcement. Of course, this trend is not limited to vulnerabilities in Microsoft products. The trend applies to 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 is available. However, 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—the attackers have a working exploit for a vulnerability and only the attackers knew the vulnerability existed. This situation is becoming far more common as vendors integrate open source and common third-party software packages. Consequently, public information about vulnerabilities and exploits is often available before the vendor has 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 makes it easier for organizations to obtain vulnerability information about lower-severity vulnerabilities. However, it also increases the amount of information that security team members must triage. To help organizations deal with this increase, Cisco also made advisories available to registered customers through the openVuln API, a web-based application programming interface.

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 too. If the security team’s procedures for handling vulnerabilities assume a comfortable margin of time between vulnerability disclosure and exploitation, 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 vulnerabilities are relevant to your organization. This prevents overreaction and the mistakes that can be inherent to 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 not 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 on 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 the Common Vulnerability Scoring System (CVSS) to understand vulnerability severity. Maintained by the Forum of Incident Response and Security Teams (FIRST), CVSS is an open framework for communicating the characteristics and severity of vulnerabilities. CVSS scoring helps customers prioritize vulnerabilities by vendor-defined severity, environmental impact, and exploitability.

If customers are not using CVSS, the following vulnerability response model can help customers make quick, informed decisions about a particular security vulnerability based on the severity, relevance, and effect that the vulnerability may have on their organization. The model helps prioritize vulnerabilities so that limited resources can focus on the most impactful issues.

This Risk Vulnerability Response Model is one method of performing triage on a security vulnerability, regardless of vendor. Cisco encourages customers to examine the model, modify it if necessary, and use it to determine the appropriate action for the security team or other affected teams in their organization.

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

Figure 1 illustrates the Risk Vulnerability Response Model. The next section of this paper describes each decision point.

Figure 1. Risk Vulnerability Response Model

Vulnerability Response Model flowchart graphic

 

Understanding the Model

The Risk Vulnerability Response Model is straightforward to use. It allows members of the frontline security team 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 who 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 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 a customer determines that the cost of installing a 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 that the vulnerability may have on any specific organization. In the Risk Vulnerability Response Model, however, several crucial questions address the relevance of a vulnerability to an organization. Consequently, it is possible that two organizations with two different technical architectures might use the model and 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 derive from the Security Impact Rating (SIR) provided in the applicable Cisco Security Advisory and they can direct an 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 the vulnerability.
1 Standard maintenance process The vulnerability poses a potential risk to the organization. The 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 The vulnerability poses a likely risk to the organization. The vulnerability should be mitigated during the organization’s next priority maintenance cycle.
3 Immediate mitigation process The vulnerability poses an imminent risk to the organization. Actions to mitigate the vulnerability should be implemented immediately.

Using the Model

Using the model is straightforward. By answering a set of questions for a vulnerability announcement, an organization arrives at one of the four urgency levels defined in Table 1.

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, including the following.

  • Vendor announcements: Software and hardware vendors, including Cisco, publish security advisories and other types of announcements about their products. The 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 review Cisco Security Advisories, visit www.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, which is available at www.securityfocus.com.
  • Vulnerability intelligence services: An increasing number of intelligence services are 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 www.cisco.com/security.
  • CVSS: Maintained by the Forum of Incident Response and Security Teams (FIRST), CVSS is an industry-standard method of rating vulnerabilities. Cisco recommends that customers adopt CVSS and encourage their vendors to adopt it too. To learn more about CVSS, visit www.first.org/cvss.

Because vulnerability announcements can arrive from any number of sources, Cisco makes security advisories available in a variety of formats—for example, email, RSS feeds, the Cisco Notification Service, public web pages, and an API—as described in the Cisco Security Vulnerability Policy. Cisco also publishes advisories for some products in machine-readable format, using the Common Vulnerability Reporting Framework (CVRF) and the Open Vulnerability and Assessment Language (OVAL).

The next step in the Risk Vulnerability Response Model is to answer a set of questions about the vulnerability to determine the appropriate urgency level (see Table 1). Table 2 lists and describes each question.

Table 2. Determining Urgency Levels

Question Description
Running affected product? Does the organization use the affected product in its environment?
Running affected version? Does the product run a version or combination of software or, occasionally, hardware that has 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. These vulnerabilities typically score 9.0 or higher in CVSS Version 3 (CVSSv3).

High: The vulnerability has the potential of significant impact to the organization, often resulting in outages or loss of confidential information. These vulnerabilities typically score from 7.0 through 8.9 in CVSSv3.

Medium: The vulnerability has potential impact, often as part of phishing attacks or in conjunction with another vulnerability. Examples include cross-site scripting attacks, cross-site request forgeries, and privilege escalations. These vulnerabilities typically score from 4.0 through 6.9 in CVSSv3.

Low: The vulnerability has minimal impact, often providing information that can be used for reconnaissance. These vulnerabilities typically score 3.9 or lower in CVSSv3. Cisco publishes information about these vulnerabilities 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 or collateral damage to other systems 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 the router, and so on. A DoS attack against a manufacturer’s extranet VPN concentrator can prevent shipping products 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 an organization answers these questions, they arrive at one of the four conclusions about the urgency level for responding to the vulnerability and they can then initiate the appropriate predefined response process.

Conclusion

Managing vulnerabilities is an increasingly complex process. There are more vulnerabilities that have to be examined and there is less time to determine the threat posed by any given vulnerability. Underreacting and overreacting both carry significant risks and, 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 for an organization. Managers can adapt the Cisco Risk Vulnerability Response Model, along with other industry best practices and effective uses of technology, to fit the needs of their organization and manage this challenge.


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

Cisco Security portal