Risk Triage for Security Vulnerability

Announcements
Contents

Introduction
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
            Output Urgency Levels
      Using the Model
Conclusion
Acknowledgments
Sidebar: Creating the Incident Response Team
Sidebar: Learning About Vulnerabilities

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

The organization is not susceptible to
0 No action required
this vulnerability.
A vulnerability of level 1 urgency
poses a potential risk. Such a
vulnerability should be mitigated as
part of an organization's standard
1 Standard maintenance process 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.
A vulnerability of level 2 urgency
poses a likely risk to the organization.
Such a vulnerability should be
mitigated during the organization's
2 Priority maintenance process
next priority maintenance cycle.
IntelliShield alerts with an urgency
level of 3 typically fall in this
category.
A vulnerability of level 3 urgency
poses an imminent risk to the
organization. Actions to mitigate such
3 Immediate mitigation process 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?
Does the product run a version or combination of software (or,
Running affected version?
occasionally, hardware) that contains the vulnerability?
Vulnerable component Is the product configured in such a way that the vulnerability is
enabled? exposed, through either explicit configuration or default condition?
Are methods to prevent exploitation of the vulnerability readily
Workaround feasible? available and practical to implement? Consider both the vulnerable
hosts and the surrounding infrastructure.
Are methods to prevent exploitation of the vulnerability already in
Workaround implemented?
place?
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.
Attack confidence?
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.
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.
Significant collateral
damage? 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.