The First.org defined the Common Vulnerability Scoring System (CVSS) to help describing and understanding vulnerabilities better. The CVSS specification is available currently in version 3.1 and can be found here.
In this specification a methodology is presented, that helps to judge a base score using further calculations, taking into consideration impact and exploitability. The Base score summarises the different aspects that describe the vulnerability. They either are represented in a figure between 0 and 10, with 10 being the most critical or detailed in a vectoral representation:
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
In this representation the first part indicates the version. This either is v3.1 or v2.0. The 2.0 is a bit shorter as it does not contain the version indicator, does not differentiate "privileges required" and "user interaction" (but applies Authentication) and does not contain the "scope". A v2 vector looks likeWas die vier :
AV:L/AC:L/Au:N/C:C/I:C/A:C
The Base Score is a simple, contextless representation of this vector using a lot of mathematics, that has been developed by a Special Interest Group (SIG) of First in co-operation with Deloitte. The vector of v3.1 is composed of the following values:
- AV = Attack Vector:
the access require to execute the attack. This could be over network (N) or through physical (P) access to the device. Other options are adjacent (A) - within the same network - or local (L), e.g. through a console. - AC = Attack Complexity:
describes the conditions required to successfully execute the attack. The two options low (L) and high (H) are possible. High is everything that must comply to allow success, which is beyond the control of the attacker. This could be a certain state of the system. - PR = Privileges required:
describes the level of access an attacker requires to hold before he'll execute the attack. There are three options {none (N), low (L), high (H)} - UI = User Interaction:
This defines whether the attacker may succeed with or without user interaction on the system. This must not be his own interaction but some. The options are none (N) and required (R). - S = Scope
describes the impact, the vulnerability will cause. In general, whatever can happen in a system is under a certain control, or within a security boundary. If the vulnerability allows to leave this boundary and to affect other parts or systems, a scope change ma occur. Therefor the values may be changed (C) and unchanged (U).
The next three parts describe the impact that may occur, when the attacker succeeds. It is measured against the three security goals Confidentiality (C), Integrity (I) and Availability (A). Potential values are {high (h), low(L), none (N)}. PLEASE NOTE: v2.0 uses a different alignment!
The formula of the Base Score depends on impact and scope. If there is no impact, then the score defaults to zero. In all other cases,
If Scope is "Unchanged":
Roundup ( Min (( Impact Score + Exploitability Score ), 10 ))
If Scope is "Changed":
Roundup ( Min ( 1.08 * ( Impact Score + Exploitability Score ), 10 ))
PLEASE NOTE: Roundup is defined as a function that returns the smallest decimal number equal or higher than its input, e.g. Roundup(4.02) will return 4.1., Roundup(5.56) will return 5.6.
Comments
0 comments
Article is closed for comments.