Risk Triage for Security Vulnerability Announcements
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.
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
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
Finally, after the security team members have arrived at one of the four conclusions, initiate the appropriate predefined response process.
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.
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.
Creating the Incident Response Team
Your company's website has been defaced. Or perhaps your network has succumbed to mysterious anomalies that might (or might not) have been caused by a worm. You worry about the security of your intellectual property and the ability of your partners to effectively communicate with you across your VPN-based extranet. Previously, managing security was yet another task that your technologists handled in between many other duties.
For a long time, that sort of informal security team seemed to manage the problem well. But the threats keep evolving, and your technology people are starting to lose the battle for your own network. Before you start to manage the risks inherent in your infrastructure, you need to create the team that will bring focus to the problem and respond to incidents when they do occur.
Here are some resources to help your organization get started:
RFC 2196, Site Security Handbook
RFC 2350, Expectations for Computer Security Incident Response
RFC 3013, Recommended Internet Service Provider Security Services and Procedures
RFC 2828, Internet Security Glossary
Cisco Systems SAFE Blueprints and White Papers
Learning About Vulnerabilities
The first step in the Rapid Risk Vulnerability Response Model is to learn about new security vulnerabilities. There are many sources for learning about security vulnerabilities that threaten your enterprise.