Finally it provides scoring examples to help

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

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 3.1.2.1 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.

Ask a homework question - tutors are online