SecConcept - CVE and NVD

Posted Nov 11, 2020 Updated Oct 30, 2022

By Grace L

11 min read

[toc]

CVE Common Vulnerabilities and Exposures

a program launched in 1999 by MITRE
to identify and catalog vulnerabilities in software or firmware into a free “dictionary” for organizations to improve their security.
CVE is sponsored by US-CERT, within the Department of Homeland Security (DHS) Office of Cybersecurity and Information Assurance (OCSIA).
MITRE, maintains the CVE dictionary and public website. It also manages the CVE Compatibility Program, which promotes the use of standard CVE identifiers by authorized CVE numbering authorities (CNAs).

CNAs

organizations that identify and distributes CVE IDs to researchers and information technology vendors for inclusion in first-time public announcements of new vulnerabilities.
They are part of what MITRE and the CVE board have termed a “federated system,” in which dozens of other organizations – 62 at current count – help identify vulnerabilities and assign them an ID number without directly involving MITRE, which is the primary CNA, in the details of the specific vulnerabilities.
Organizations that are CNAs include Adobe, Apple, Cisco, Google, Hewlett Packard Enterprise, Huawei, IBM, Intel, Microsoft, Mozilla, Oracle, Rapid 7, Red Hat, Siemens, Symantec and VMWare, plus organizations like CERT/CC (Computer Emergency Response Team/Coordination Center) and the DWF Project.

CVE listing

CVE isn`t just another vulnerability database.
It is designed to allow vulnerability databases and other capabilities to be linked together, and to facilitate the comparison of security tools and services.
A CVE listing only contains the standard identifier number with status indicator, a brief description and references to related vulnerability reports and advisories.
It does not include risk, impact, fix or detailed technical information.
The US National Vulnerability Database (NVD) does include fix, scoring, and other information for identifiers on the CVE List.

New CVE ID Syntax

  
CVE prefix + Year + Arbitrary Digits

- no limit on the number of arbitrary digits.
- Leading 0’s will only be used in IDs 1 to 999, as shown in column one below.

IDs with 4 digits	IDs with 5 digits	IDs with 6 digits	IDs with 7 digits
CVE-2014-0001	    CVE-2014-10000	    CVE-2014-100000	    CVE-2014-1000000
CVE-2014-3127	    CVE-2014-54321	    CVE-2014-456132	    CVE-2014-7654321
CVE-2014-9999	    CVE-2014-99999	    CVE-2014-999999	    CVE-2014-9999999

NVD

NVD CVSS Calculators

Vulnerability Metrics

The Common Vulnerability Scoring System (CVSS) is an open framework for communicating the characteristics and severity of software vulnerabilities.
- owned and managed by FIRST.Org, Inc. (FIRST), a US-based non-profit organization, help computer security incident response teams across the world.
CVSS consists of three metric groups: Base, Temporal, and Environmental.
The Base metrics produce a score: 0 - 10, which can then be modified by scoring the Temporal and Environmental metrics.
A CVSS score is also represented as a vector string, a compressed textual representation of the values used to derive the score. Thus, CVSS is well suited as a standard measurement system for industries, organizations, and governments that need accurate and consistent vulnerability severity scores.
Two common uses of CVSS are
- calculating the severity of vulnerabilities discovered on one’s systems and as a factor in prioritization of vulnerability remediation activities.
The National Vulnerability Database (NVD) provides CVSS scores for almost all known vulnerabilities.

The NVD supports both Common Vulnerability Scoring System (CVSS) v2.0 and v3.X standards.

The NVD provides CVSS base scores: the innate characteristics of each vulnerability.
The NVD does not currently provide
- temporal scores (metrics that change over time due to events external to the vulnerability)
- or environmental scores (scores customized to reflect the impact of the vulnerability on your organization).
However, the NVD does supply a CVSS calculator for both CVSS v2 and v3 to allow you to add temporal and environmental score data.

NVD Vulnerability Severity Ratings

1. Metrics

3 metric groups: Base, Temporal, and Environmental

The Base metric group represents the intrinsic characteristics of a vulnerability that are constant over time and across user environments. It is composed of two sets of metrics: the Exploitability metrics and the Impact metrics.

The Exploitability metrics reflect the ease and technical by which the vulnerability can be exploited. represent characteristics of the thing that is vulnerable, vulnerable component.
The Impact metrics reflect the direct consequence of a successful exploit, and represent the consequence to the thing that suffers the impact, impacted component.
- the vulnerable component: software application, module, driver, etc. (or possibly a hardware device),
- the impacted component: software application, a hardware device or a network resource.
- This potential for measuring the impact of a vulnerability other than the vulnerable component, was a key feature introduced with CVSS v3.0.

The Temporal metric group reflects the characteristics of a vulnerability that may change over time but not across user environments.

For example, the presence of a simple-to-use exploit kit would increase the CVSS score, while the creation of an official patch would decrease it.

The Environmental metric group represents the characteristics of a vulnerability that are relevant and unique to a particular user’s environment.

Considerations include the presence of security controls which may mitigate some or all consequences of a successful attack, and the relative importance of a vulnerable system within a technology infrastructure.

Each of these metrics are discussed in further detail below. The User Guide contains scoring rubrics for the Base Metrics that may be useful when scoring.

2. Base Metrics

CVSS 3.x Severity and Metrics: NIST CVSS score NIST: NVD Base Score: 10.0 CRITICAL Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

2.1. Exploitability Metrics

the characteristics of the thing that is vulnerable, vulnerable component.
Therefore, each of the Exploitability metrics listed below should be scored relative to the vulnerable component, and reflect the properties of the vulnerability that lead to a successful attack.

2.1.1. Attack Vector (AV) - Network/Adjacent/Local/Physical

This metric reflects the context by which vulnerability exploitation is possible.
the larger, the more remote (logically and physically) an attacker can be in order to exploit the vulnerable component.
the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater Base Score. The list of possible values is presented in Table 1.

Metric Value	Description
`Network (N)`	The vulnerable component is bound to - the network stack - and the set of possible attackers up to and including the entire Internet. - remotely exploitable, attack being exploitable at the protocol level one or more network hops/routers away. - Example: DoS: sending a specially crafted TCP packet across a wide area network (e.g., CVE‑2004‑0230).
`Adjacent 邻近的 (A)`	The vulnerable component is bound to - the network stack, - but the attack is limited at the protocol level to a logically adjacent topology. - an attack must be launched from the same shared physical (e.g., Bluetooth or IEEE 802.11) or logical (e.g., local IP subnet) network, or from within a secure or otherwise limited administrative domain (e.g., MPLS, secure VPN to an administrative network zone). - Example: ARP (IPv4) or neighbor discovery (IPv6) flood leading to a denial of service on the local LAN segment (e.g., CVE‑2013‑6014).
`Local (L)`	The vulnerable component is not bound to the network stack and the attacker’s path is via read/write/execute capabilities. - Either: the attacker exploits the vulnerability by accessing the target system locally (e.g., keyboard, console), or remotely (e.g., SSH); - or the attacker relies on User Interaction by another person to perform actions required to exploit the vulnerability (e.g., social engineering to trick a user into opening a malicious document).
`Physical (P)`	The attack requires the attacker to physically touch or manipulate the vulnerable component. - Physical interaction may be brief (e.g., evil maid attack[^1]) or persistent. - Example: cold boot attack: attacker gains access to disk encryption keys after physically accessing the target system. - Example: peripheral attacks via FireWire/USB Direct Memory Access (DMA).

Network and Adjacent if an attack can be launched over a wide area network or from outside the logically adjacent administrative network domain, use Network. Network should be used even if the attacker is required to be on the same intranet to exploit the vulnerable system (e.g., the attacker can only exploit the vulnerability from inside a corporate network).

2.1.2. Attack Complexity (AC) - Low/High

This metric describes the conditions beyond the attacker’s control that must exist in order to exploit the vulnerability.

such conditions may require the collection of more information about the target, or computational exceptions.
Importantly, the assessment of this metric excludes any requirements for user interaction in order to exploit the vulnerability (such conditions are captured in the User Interaction metric).
If a specific configuration is required for an attack to succeed, the Base metrics should be scored assuming the vulnerable component is in that configuration.

Metric Value Description

Low (L) Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success when attacking the vulnerable component.

High (H) A successful attack depends on conditions beyond the attacker’s control.
- a successful attack cannot be accomplished at will, but requires the attacker to invest in some measurable amount of effort in preparation or execution against the vulnerable component before a successful attack can be expected.
- For example, successful attack may depend on overcome following conditions:
- gather knowledge about the environment in which the vulnerable target/component exists. (collect details on target configuration, sequence numbers, or shared secrets)
- prepare the target environment to improve exploit reliability. (repeated exploitation to win a race condition, or overcoming advanced exploit mitigation techniques).
- The attacker must inject themselves into the logical network path between the target and the resource requested by the victim in order to read and/or modify network communications (e.g., a man in the middle attack).

Metric Value	Description
`Low (L)`	Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success when attacking the vulnerable component.
`High (H)`	A successful attack depends on conditions beyond the attacker’s control. - a successful attack cannot be accomplished at will, but `requires the attacker to invest in some measurable amount of effort in preparation or execution` against the vulnerable component before a successful attack can be expected. - For example, successful attack may depend on overcome following conditions: - gather knowledge about the environment in which the vulnerable target/component exists. (collect details on target configuration, sequence numbers, or shared secrets) - prepare the target environment to improve exploit reliability. (repeated exploitation to win a race condition, or overcoming advanced exploit mitigation techniques). - The attacker must inject themselves into the logical network path between the target and the resource requested by the victim in order to read and/or modify network communications (e.g., a man in the middle attack).

2.1.3. Privileges Required (PR) - None/Low/High

This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability.

Metric Value	Description
`None (N)`	The attacker is unauthorized prior to attack, does not require any access to settings or files of the the vulnerable system to carry out an attack. an attacker has the ability to access only non-sensitive resources.
`Low (L)`	The attacker requires privileges that provide basic user capabilities normally affect only settings and files owned by a user.
`High (H)`	The attacker requires privileges that provide significant (e.g., administrative) control over the vulnerable component allowing access to component-wide settings and files.

Privileges Required is usually None for hard-coded credential vulnerabilities or vulnerabilities requiring social engineering (e.g., reflected XSS, cross-site request forgery, or file parsing vulnerability in a PDF reader).

2.1.4. User Interaction (UI) - None/Required

This metric captures the requirement for a human user, not attacker, to participate in the successful compromise of the vulnerable component.

determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.

Metric Value	Description
`None (N)`	The vulnerable system can be exploited without interaction from any user.
`Required (R)`	Successful exploitation of this vulnerability requires a user to take some action before the vulnerability can be exploited. - Example, a successful exploit only during the installation of an app by system admin

2.2. Scope (S) - Unchanged/Changed

whether a vulnerability in one vulnerable component impacts resources in components beyond its security scope.

Formally, a security authority is a mechanism (e.g., an application, an operating system, firmware, a sandbox environment) that defines and enforces access control in terms of how certain subjects/actors (e.g., human users, processes) can access certain restricted objects/resources (e.g., files, CPU, memory) in a controlled manner.

All the subjects and objects under single security authority are considered to be under one security scope.
If a vulnerability in a vulnerable component can affect a component which is in a different security scope than the vulnerable component, a Scope change occurs.
Intuitively, whenever the impact of a vulnerability breaches a security/trust boundary and impacts components outside the security scope in which vulnerable component resides, a Scope change occurs.

The security scope of a component encompasses other components that provide functionality solely to that component, even if these other components have their own security authority.

For example, a database used solely by one application is considered part of that application’s security scope even if the database has its own security authority, e.g., a mechanism controlling access to database records based on database users and associated database privileges.

Metric Value	Description
`Unchanged (U)`	An exploited vulnerability can only affect resources managed by the same security authority. the `vulnerable component and impacted component` are either the same, or both managed by the same security authority.
`Changed (C)`	An exploited vulnerability can affect resources beyond the security scope managed by the security authority of the vulnerable component. the `vulnerable component and impacted component` are different and managed by different security authorities.

2.3. Impact Metrics

C I A

ref

10SecConcept, VulManage

SecConcept CVE

This post is licensed under CC BY 4.0 by the author.