This preview shows page 1. Sign up to view the full content.
Unformatted text preview: lustrate the scoring process and the use of the equations.
3.1 Guidelines Below are guidelines that should help analysts when scoring vulnerabilities. These guidelines are
intended primarily for analysts that are creating base scores, although they may be of interest to many
others because of the insights they provide into the significance of the base scores and the assumptions
made when performing scoring.
3.1.1 General SCORING TIP #1: Vulnerability scoring should not take into account any interaction with other
vulnerabilities. That is, each vulnerability should be scored independently.
SCORING TIP #2: When scoring a vulnerability, consider the direct impact to the target host only. For
example, consider a cross-site scripting vulnerability: the impact to a user’s system could be much greater
than the impact to the target host. However, this is an indirect impact. Cross-site scripting vulnerabilities
should be scored with no impact to confidentiality or availability, and partial impact to integrity.
SCORING TIP #3: Many applications, such as Web servers, can be run with different privileges, and
scoring the impact involves making an assumption as to what privileges are used. Therefore,
vulnerabilities should be scored according to the privileges most commonly used. This may not
necessarily reflect security best practices, especially for client applications which are often run with rootlevel privileges. When uncertain as to which privileges are most common, scoring analysts should
assume a default configuration.
SCORING TIP #4: When scoring the impact of a vulnerability that has multiple exploitation methods
(attack vectors), the analyst should choose the exploitation method that causes the greatest impact, rather
than the method which is most common, or easiest to perform. For example, if functional exploit code
exists for one platform but not another, then Exploitability should be set to “Functional”. If two separate
variants of a product are in parallel development (e.g. PHP 4.x and PHP 5.x), and a fix exists for one
variant but not another, then the Remediation Level should be set to “Unavailable”.
3.1.2 Base Metrics 22.214.171.124 Access Vector
SCORING TIP #5: When a vulnerability can be exploited both locally and from the network, the
“Network” value should be chosen. When a vulnerability can be exploited both locally and from adjacent
networks, but not from remote networks, the “Adjacent Network” value should be chosen. When a
vulnerability can be exploited from the adjacent network and remote networks, the “Network” value
should be chosen.
SCORING TIP #6: Many client applications and utilities have local vulnerabilities that can be exploited
remotely either through user-complicit actions or via automated processing. For example, decompression
utilities and virus scanners automatically scan incoming email messages. Also, helper applications (office
suites, image viewers, media players, etc.) are exploited when malicious files are exchanged via e-mail or 13 THE COMMON VULNERABILITY SCORING SYSTEM (CVSS) AND ITS APPLICABILITY TO FEDERAL AGENCY SYSTEMS downloaded from web sites. Therefore, analysts should...
View Full Document
This document was uploaded on 03/19/2014 for the course IS 4799 at ITT Tech Flint.
- Spring '14