Risk Triage for Security Vulnerability Announcements

Introduction

According to Carnegie-Mellon's CERT Coordination Center (CERT/CC), almost 4300 security vulnerabilities were disclosed in 2005. 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 upon.

The security team in your organization knows that it needs to keep up to date about the latest security vulnerabilities that threaten your 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 a vulnerability risk triage method 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, this 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. 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.

There is usually a period of time between when a security vulnerability in a particular technology is announced and when a method of attack—the exploit—becomes available. Within this time period, system administrators can take action to protect their systems against an attack, because at this point the public knows a flaw exists, but hackers are still trying to find a way to take advantage of that vulnerability.

Unfortunately, the vulnerability-exploit time period has been steadily deceasing. A few 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. By 2004, this time period had diminished considerably. The Sasser.A worm was released only 17 days after MS04-011 was announced on April 13, 2004. Near the end of 2005, that time period had further shrunk to 16 hours for MS05-051, announced on October 11, 2005. Of course, this trend is not just limited to vulnerabilities with Microsoft products, but includes operating systems, applications, and hardware from other vendors as well.

The vulnerabilities previously discussed went through the established industry practice of responsible disclosure by the vendor 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-exploit time period is "reversed," in that the attackers have a working exploit for a vulnerability that nobody aside from the attackers knew existed.

Preparing for “Day Zero” Threats—Without Panicking

Security teams must prepare for new threats that emerge with little to 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 application software. Proper use of these features can go a long way toward stopping a major outbreak before it occurs.

But even as organizations evolve their technology infrastructure to deal with these threats, a security team's operational procedures must evolve as well. If the security team's procedures for handling a vulnerability announcement 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 that are inherent in rapid, poorly planned upgrades or configuration changes.

At Cisco, we have seen this behavior occasionally when a new Cisco security vulnerability is 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

Similar to Rapid Risk, which is the internal Cisco method of determining security risk for IT infrastructure projects, vulnerability management also requires a triage method. This allows customers to make quick, informed decisions about a particular security vulnerability based on its relevance to and effect on the organization.

The Cisco Rapid Risk Vulnerability Response Model is one method of performing triage on a security vulnerability, whether the vulnerability announcement comes from Cisco or another 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 within their organization.

The model should be considered an adjunct to other best common practices for vulnerability management. Additionally, Cisco recommends that customers evaluate CVSS for the purposes of understanding vulnerability severity. If customers are using CVSS, certain questions in the model can be answered based on the output from CVSS.

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

Figure 1. Rapid Risk Vulnerability Response Model

 

Understanding the Model

The Cisco Rapid Risk Vulnerability Response Model is simple 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.

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 risk 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 Rapid Risk Vulnerability Response Model, several crucial questions are affected by the relevance of the vulnerability to the organization itself. It is therefore 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 urgency levels provided by the Cisco IntelliShield service 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. IntelliShield alerts with an urgency level of 1 or 2 typically fall in this category.
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. IntelliShield alerts with an urgency level of 3 typically fall in this category.
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. IntelliShield alerts with an urgency level of 4 or 5 typically fall in this category.

 

Using the Model

Using the model is simple. Start with a valid vulnerability announcement, which can arrive through any number of sources, such as a security mailing list. By going through the questions, the organization will arrive at one of the four previously defined urgency levels (Table 2).

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 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?
Attack confidence?	Based upon 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, risk to life and limb, and so on. For example, a denial-of-service attack against a core router can affect the overall stability of the network, disrupt traffic that would transit that router, and so on. A denial-of-service 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.

 

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

Conclusion

Managing vulnerabilities is becoming 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 the incoming barrage of vulnerabilities and determine their potential severity to the organization. Applying the Cisco Rapid Risk Vulnerability Response Model can help an organization manage this challenge in conjunction with other industry best practices and the smart use of technology.

Acknowledgments

Rakesh Bharania is a Network Consulting Engineer with Cisco Advanced Services for Network Security and specializes in network security, web architecture security, and risk assessments.

 

Back to Top