Prioritization

Once vulnerabilities have been identified, the next important step is the prioritization of each in order to judge their impact to your organization. Guidelines and criteria must be developed in order to set expectations on when and what will be done when new vulnerabilities come to light based on their priority. These guidelines must be based on the risk associated with a particular threat, and the impact to the affected systems if the vulnerability were to be exploited.

With over 50 new security vulnerabilities being disclosed on a weekly basis, this is no small task. In order to adequately prioritize vulnerabilities, it is critical that an organization have a solid understanding of the technologies and assets that they have deployed.

In order to prioritize the vulnerability management process, we must look at two distinct variables . These are (a) the severity and impact of each individual vulnerability and (b) the criticality of the assets being protected. Ultimately, these both need to be weighed, resulting in the most critical assets possessing the most critical vulnerabilities rising to the top. From this, we can infer those vulnerabilities that will require the most immediate attention.

While the prioritization of assets is something that must be determined internally, information to facilitate the prioritization of vulnerabilities is something that can be obtained externally. While some public information on new security vulnerabilities may not contain the ratings required to determine the severity, urgency, and impact of a particular vulnerability, commercial services do provide this (another argument for these services). Many vendor releases also provide some measure of the severity of the associated vulnerability.

To assist in determining the severity of a given vulnerability NIAC has also created a vulnerability scoring system, known as the Common Vulnerability Scoring System or CVSS. CVSS takes as its input a number of different metrics that reflect the characteristics of the vulnerability and, through a formula, provides an overall set of ratings. This rating provides for the comparison of one vulnerability to another, and the overall severity of that vulnerability. It does not reflect how relevant that vulnerability is to your organization. That is clearly something that must still be determined internally. Many of the traits developed by NIAC can also be applied internally for the purpose of prioritization.

The NIAC CVSS takes into account a number of metrics to arrive at a final score. These metrics are broken down into three distinct classes:

1. Base metric group

2. Temporal metric group

3. Environmental metric group

Each of these classes then further encompasses individual metrics.

Base Metric Group

This group of metrics includes those traits of a vulnerability that will never change once they have been defined. They are the most fundamental traits of a vulnerability.

• Access Vector Measures whether a vulnerability is exploitable locally or remotely.

• Access Complexity Measures the complexity of attack required to exploit the vulnerability once an attacker has access to the target system. If High, then specialized access conditions exist, such as the requirement for specific circumstances to exist for exploitation to occur (such as client interaction). If Low, then no access conditions exist, meaning, for example, that exploitation can occur without any interaction and that no specific circumstances are required in order to exploit the vulnerability.

• Authentication Measures whether or not an attacker needs to be authenticated to the target system in order to exploit the vulnerability.

• Confidentiality Impact Measures the impact of a successful exploit of the vulnerability on the confidentiality of the target system.

• Integrity Impact Measures the impact of a successful exploit of the vulnerability on the integrity of the target system.

• Availability Impact Measures the impact of a successful exploit of the vulnerability on the availability of the target system.

• Impact Bias Allows a score to convey greater weighting to one of three impact metrics over the other two. In a rating of Normal, Confidentiality Impact, Integrity Impact, and Availability Impact are all assigned the same weight. In a rating of Confidentiality, Confidentiality Impact is assigned greater weight than Integrity Impact or Availability Impact. In a rating of Integrity, Integrity Impact is assigned greater weight than Confidentiality Impact or Availability Impact. In a rating of Availability, Availability Impact is assigned greater weight than Confidentiality Impact or Integrity Impact.

Temporal Metric Group

Temporal metrics include those metrics that may increase or decrease over time. As vulnerabilities age, some of their core traits change accordingly .

• Exploitability Measures how complex the process is to exploit the vulnerability in the target system once it has been accessed.

• Remediation Level Measures the level of solution available.

• Report Confidence Measures the degree of confidence in the existence of the vulnerability and the credibility of its report.

Environmental Metric Group

The environmental aspects of a vulnerability capture the environment-specific attributes of a vulnerability. In this context, environment is defined as the world at large, and as such will require refinement for a given organization.

• Collateral Damage Potential Measures the potential for a loss in physical equipment, property damage, or loss of life or limb.

• Target Distribution Measures the relative size of the field of target systems susceptible to the vulnerability.

Existing Security Posture Analysis

The first step in building a patch management process is to have mechanisms in place to discover systems that do not have adequate patches installed. There are several approaches that can be taken in order to identify these systems, each encompassing different solutions from a technology standpoint, and each possessing its own set of benefits.

When discussing the discovery of vulnerabilities and the discovery (or lack thereof) of installed patches, it is important to consider that both acts are a subset of an overall policy compliance process. Much like security-relevant configuration and policy settings are managed across an organization, so can be the patch state of individual assets.

The end goal of this type of analysis, whether it be performed through asset discovery, vulnerability discovery, or patch discovery, is to identify vulnerable or affected systems.

Asset Discovery

Traditional asset discovery can serve to provide a knowledge base of known assets (both hardware and software) that can be correlated with known vulnerabilities (and associated patches) at some time in the future. An up-to-date asset database can provide an immediate analysis when presented with a set of affected platforms and applications to which a particular patch may apply. For the purposes of this chapter, we classify asset discovery as being nonvulnerability and nonpatch specific.

To the best of our knowledge, today's vulnerability and patch management systems do not use asset databases to drive their core function. The difficulty in discovering and maintaining a standard index of all applications company-wide introduces unforeseen complexity. One such difficulty is standardizing on product nomenclature between discovery capabilities and platforms associated with a given patch.

In order to be comprehensive, asset discovery needs to include detailed information on the applications deployed in your organization. This includes the following:

• The IP address(es), MAC address(es), and computer names associated with the asset

• The operating system, version, service pack, and patch level of the asset

• The applications running on that operating system, and their respective versions and patch levels

Gathering this information is nontrivial and there are specific technologies (and an entire industry for that matter) focused specifically around the managing of an organization's network assets. New technologies developed specifically to manage the vulnerability lifecycle seek to tie together this information from existing asset management applications, or by introducing their own network discovery technologies. In order to adequately map new vulnerabilities to the appropriate systems within your network, this step is a necessity.

Vulnerability Discovery

We classify vulnerability discovery as the detection or discovery of a particular vulnerability on a software or hardware asset. In the early 1990s an entire industry focused on the discovery of vulnerabilities blossomed and resulted in the creation of vulnerability assessment (VA) applications. Vulnerability assessment can be broken down into two particular strains: network-based vulnerability assessment (NVA) and host-based vulnerability assessment (HVA).

Network vulnerability assessment applications detect the presence of particular vulnerabilities through the act of probing remote networked computers for specific vulnerabilities. Today, open source tools exist that serve to fill this need for those familiar with their use. The open source application Nessus is one such example that, while freely available, provides excellent remote detection of software vulnerabilities.

While probing for vulnerabilities remotely provides for quick and easy network-wide assessment, it also has a number of inherent drawbacks. Results from this probing can often be unpredictable, sometimes even misleading. The presence of false positives and false negatives can oftentimes not be avoided, due to the overwhelming reliance on version numbers presented by applications, the dependence on protocol nuances , and the occasional need to actually attempt to exploit a vulnerability in order to determine a system's susceptibility.

While NVA products have drawbacks, they also have the benefit that they can provide a view of your network that parallels that of an attacker performing their own reconnaissance and scanning. In doing so, they can help to identify and prioritize those vulnerabilities that require immediate attention. In addition, NVA products allow for the quick, widespread discovery of a particular vulnerability (even on unmanaged systems) that may otherwise present difficulties using the other solutions mentioned here.

Host-based vulnerability assessment technologies differ from their network-based counterparts in that they commonly rely on the presence of a specialized agent in order to perform the scanning and detection on the remote host. Due to this requirement, this capability works well when all systems are managed by the security (or IT) organization allowing the deployment of such agents . In some applications host-based vulnerability discovery capabilities may be encompassed in agent-based patch-discovery solutions, as both capabilities go hand in hand.

Host-based solutions provide the benefit of consistent reliable results due to their ability to determine the exact posture of a given system based on the system's actual state (rather than trying to infer vulnerabilities and version numbers by probing network services).

Patch Discovery

Patch discovery solutions rely largely on agent-based technology (sometimes transient) in order to scan an organization's system for the presence (or lack thereof) of individual patches. They focus entirely on known patches rather than specific vulnerabilities. Arguments can be made for both; however, the ultimate problem that many organizations are trying to tackle today is the management and deployment of vendor-approved security patches as they become available.

As a result, the act of specific patch discovery for many may go to the core of their problems more so than the asset discovery and vulnerability discovery solutions discussed previously. Ultimately, you must make a decision on your own in terms of which direction you wish to pursue , and make an informed decision based on available vendor solutions. Patch discovery can be performed in several ways:

• Detection of specific patches via registry keys (Windows) This is a fairly straightforward mechanism and is the easiest and most commonly used. While effective in many cases, it may be subverted if it is the only mechanism used and the application's files have been overwritten or modified again after the patch has been installed.

• Detection of specific patches via file checksum (Windows and UNIX) This mechanism is more reliable, as it ensures that a given file has been installed. It requires more maintenance and testing on the vendor's side, and as a result may be avoided by some vendors entirely.

• Operating systemssupported package management (UNIX) For UNIX-based systems, APIs exist in order to detect the installation of particular patches and versions of packages.

Ultimately, a perfect solution would combine all of the mechanisms discussed above and leave the discovery and detection mechanisms to the end user . Unfortunately, the sheer effort and maintenance overhead of maintaining such a solution precludes this from being a reality.

Tools

A number of freely available tools exist that can be used to expedite the discovery and assessment of a network's patch posture. For Windows-based networks, Microsoft has made a free tool availablethe Microsoft Baseline Security Analyzer.

"MBSA is the free, best practices vulnerability assessment tool for the Microsoft platform. It is a tool designed for the IT Professional that helps with the assessment phase of an overall security management strategy'. MBSA Version 1.2.1 includes a graphical and command line interface that can perform local or remote scans of Windows systems."http://www.microsoft.com/technet/security/tools/mbsahome.mspx

Microsoft Baseline Security Analyzer includes a valuable command line tool called HfNetChk. HfNetChk allows an administrator to remotely determine the patch status of Windows-based computers from a single location. It retrieves updated security patch details from Microsoft automatically, and will detect the absence of patches for the following platforms:

• Windows NT 4.0

• Windows 2000

• Windows XP

• Windows Server 2003

• All system services, including Internet Information Server 4.0 and 5.0

• SQL Server 7.0 and 2000

• Internet Explorer 5.01 and later

• Exchange 5.5 and 2000

• Windows Media Player 6.4 and later

While it does not in itself deploy patches, HfNetChk can serve as an invaluable tool for the discovery of absent patches on your network.