@Risk: The Consensus Security Alert

About the CVA Process and CVA Priority Ratings

The CVA consists of the following process:

• Phase 1:
  TippingPoint's Digital Vaccine group scours security mailing lists, spiders vendor web sites, and monitors its private honey pot networks to determine the most critical vulnerabilities disclosed each week, based on the criteria below. In most situations, the team will verify a vulnerability discoverer's findings, and further research potential attack vectors or exploitation ramifications in a controlled lab environment. These additional observations and results are included in the @RISK analysis.
• Phase 2:
  Very technical security managers at fifteen of the largest user organizations in the United States each reviews the "immediate action" vulnerabilities and describe what they did or did not do to protect their organizations. Council members include banks and other financial organizations, government agencies, universities, major research laboratories, ISPs, health care, manufacturers, insurance companies and a couple more. The individual members have direct responsibility for security for their systems and networks. All were concerned that information about their security configuration would leak out, and agreed to serve only if their identities were not revealed.
• Phase 3:
  SANS compiles the responses and identifies the items on which the Council members took or are taking action, produces the weekly @RISK, and distributes it via email to all eligible persons.

Critical Vulnerability Analysis Scale Ratings

In ranking vulnerabilities several key factors are taken into account and given varying degrees of weight, such as:

• Is the affected product widely deployed?
• Is this a server or client compromise? At what privilege level?
• Is the problem found in default configurations/installations?
• Are the affected assets high value (e.g. databases, e-commerce servers)?
• Is the network infrastructure affected (DNS, routers, firewalls)?
• Is exploit code publicly available?
• How difficult is it to exploit the vulnerability? Remote/Local? Without Credentials or Physical Access?
• How trivial is it for an informed attacker to devise his own exploit?
• Are technical vulnerability details available?
• Does the attacker need to social engineer his victim? (e.g. clicking a link, visiting a site, connecting to a server, etc.).
• Is the vulnerability being actively exploited in the wild?

Based on the answers to these questions, vulnerabilities are run through an algorithm and ranked as Critical, High, Moderate, or Low.

CRITICAL vulnerabilities are those vulnerabilities that typically affect default installations of very widely deployed software, result in root compromise of servers or infrastructure devices, and the information required for exploitation (such as example exploit code) is widely available to attackers. Further, exploitation is usually straightforward, in the sense that the attacker does not need any special authentication credentials, knowledge about individual victims, and does not need to social engineer a target user into performing any special functions.

HIGH vulnerabilities are typically those that have the potential to become CRITICAL, but have one or a few mitigating factors that make exploitation less attractive to attackers. For example, vulnerabilities that have many CRITICAL characteristics but are difficult to exploit, do not result in elevated privileges, or have a minimally sized victim pool are usually rated HIGH. Note that HIGH vulnerabilities where the mitigating factor arises from a lack of technical exploit details will become CRITICAL if these details are later made available. Thus, the paranoid administrator will want to treat such HIGH vulnerabilities as CRITICAL, if it is assumed that attackers always possess the necessary exploit information.

MODERATE vulnerabilities are those where the scales are slightly tipped in favor of the potential victim. Denial of service vulnerabilities are typically rated MODERATE, since they do not result in compromise of a target. Exploits that require an attacker to reside on the same local network as a victim, only affect nonstandard configurations or obscure applications, require the attacker to social engineer individual victims, or where exploitation only provides very limited access are likely to be rated MODERATE.

LOW vulnerabilities by themselves have typically very little impact on an organization's infrastructure. These types of vulnerabilities usually require local or physical system access or may often result in client side privacy or denial of service issues and information leakage of organizational structure, system configuration and versions, or network topology.

Alternatively, a LOW ranking may be applied when there is not enough information to fully assess the implications of a vulnerability. For example, vendors often imply that exploitation of a buffer overflow will only result in a denial of service. However, many times such flaws are later shown to allow for execution of attacker-supplied code. In these cases, the issues are reported in order to alert security professionals to the potential for deeper problems, but are ranked as LOW due to the element of speculation.

Remediation Timescale

A vulnerability rating corresponds to the "threat level" of a particular issue. Critical threats must be responded to most quickly, as the potential for exploitation is high. Recommended response times corresponding to each of the ratings is below. These recommendations should be tailored according to the level of deployment of the affected product at your organization.

CRITICAL: 48 hours
HIGH: 5 business days
MODERATE: 15 business days
LOW: At the administrator's discretion