☑️CVSS and CVE
CVSS
There are various ways to score or calculate severity ratings of vulnerabilities. The Common Vulnerability Scoring System (CVSS) is an industry standard for performing these calculations.
The CVSS is often used together with the so-called Microsoft DREAD. DREAD is a risk assessment system developed by Microsoft to help IT security professionals evaluate the severity of security threats and vulnerabilities. It is used to perform a risk analysis by using a scale of 10 points to assess the severity of security threats and vulnerabilities. With this, we calculate the risk of a threat or vulnerability based on five main factors:
Damage Potential
Reproducibility
Exploitability
Affected Users
Discoverability
Severity Scoring
The CVSS system helps categorize the severity associated with an issue and allows organizations to prioritize issues based on the rating. The CVSS scoring consists of the exploitability and impact of an issue. The exploitability measurements consist of access vector, access complexity, and authentication. The impact metrics consist of the CIA triad, including confidentiality, integrity, and availability.
Base Metric Group
The CVSS base metric group represents the vulnerability characteristics and consists of exploitability metrics and impact metrics.
The Exploitability metrics are a way to evaluate the technical means needed to exploit the issue using the metrics below:
Attack Vector
Attack Complexity
Privileges Required
User Interaction
The Impact metrics represent the repercussions of successfully exploiting an issue and what is impacted in an environment, and it is based on the CIA triad. The CIA triad is an acronym for Confidentiality, Integrity, and Availability.
Temporal Metric Group
The Temporal Metric Group details the availability of exploits or patches regarding the issue.
The Exploit Code Maturity metric represents the probability of an issue being exploited based on ease of exploitation techniques. There are various metric values associated with this metric, including Not Defined, High, Functional, Proof-of-Concept, and Unproven.
A 'Not Defined' value relates to skipping this particular metric. A 'High' value represents an exploit consistently working for the issue and is easily identifiable with automated tools. A Functional value indicates there is exploit code available to the public. A Proof-of-Concept demonstrates that a PoC exploit code is available but would require changes for an attacker to exploit the issue successfully.
The Remediation level is used to identify the prioritization of a vulnerability. The metric values associated with this metric include Not Defined, Unavailable, Workaround, Temporary Fix, and Official Fix.
A 'Not Defined' value relates to skipping this particular metric. An 'Unavailable' value indicates there is no patch available for the vulnerability. A 'Workaround' value indicates an unofficial solution released until an official patch by the vendor. A 'Temporary Fix' means an official vendor has provided a temporary solution but has not released a patch yet for the issue. An 'Official Fix' indicates a vendor has released an official patch for the issue for the public.
Report Confidence represents the validation of the vulnerability and how accurate the technical details of the issue are. The metric values associated with this metric include Not Defined, Confirmed, Reasonable, and Unknown.
A 'Not Defined' value relates to skipping this particular metric. A 'Confirmed' value indicates there are various sources with detailed information confirming the vulnerability. A 'Reasonable' value indicates sources have published information about the vulnerability. However, there is no complete confidence that someone would achieve the same result due to missing details of reproducing the exploit for the issue.
Environmental Metric Group
The Environmental metric group represents the significance of the vulnerability of an organization, taking into account the CIA triad.
The Modified Base metrics represent the metrics that can be altered if the affected organization deems a more significant risk in Confidentiality, Integrity, and Availability to their organization. The values associated with this metric are Not Defined, High, Medium, and Low.
A 'Not Defined' value would indicate skipping this metric. A 'High' value would mean one of the elements of the CIA triad would have astronomical effects on the overall organization and customers. A 'Medium' value would indicate one of the elements of the CIA triad would have significant effects on the overall organization and customers. A 'Low' value would mean one of the elements of the CIA triad would have minimal effects on the overall organization and customers.
CVE
Common Vulnerabilities and Exposures (CVE) is a publicly available catalog of security issues sponsored by the United States Department of Homeland Security (DHS). Each security issue has a unique CVE ID number assigned by the CVE Numbering Authority (CNA).
The following chart explains how a CVE ID may be assigned to a vulnerability. Any vulnerabilities assigned a CVE must be independently fixable, affect just one codebase, and be acknowledged and documented by the relevant vendor.
Stages of obtaining a CVE
Stage 1: Identify if CVE is Required and Relevant
Identify if the issue found is a vulnerability. According to the CVE Team, "A vulnerability in the context of the CVE Program is indicated by code that can be exploited, resulting in a negative impact to confidentiality, integrity, OR availability, and that requires a coding change, specification change, or specification deprecation to mitigate or address." Additionally, research should verify there is not a CVE ID already in the CVE database.
Stage 2: Reach Out to Affected Product Vendor
A researcher should ensure they have made a good faith effort to contact a vendor directly. Researchers can reference CVE's Documents on Disclosure Practices for additional information.
Stage 3: Identify if Request Should Be For Vendor CNA or Third Party CNA
If a company is a part of participating CNA's, they can assign a CVE ID for one of their products. If the issue is for a participating CNA, researchers can contact the appropriate CNA organization here. If the vendor is not a participating CNA, a researcher should attempt to reach out to the vendor's third-party coordinator.
Stage 4: Requesting CVE ID Through CVE Web Form
The CVE Team has a form that can be filled out online here if the methods above do not work for CVE requests.
Stage 5: Confirmation of CVE Form
Upon submitting the CVE Web Form mentioned in Stage 4, an individual will receive a confirmation email. The CVE team will contact the requestor if any additional information is required.
Stage 6: Receival of CVE ID
Upon approval, the CVE Team will notify the requestor of a CVE ID if the affected product's vulnerability is confirmed. Please note that the CVE ID is not public yet at this stage.
Stage 7: Public Disclosure of CVE ID
CVE IDs can be announced to the public as soon as appropriate vendors and parties are aware of the issue to prevent duplication of CVE IDs. This stage ensures that all associated parties are aware of the problem before being publicly disclosed.
Stage 8: Announcing the CVE
The CVE Team asks researchers who are sharing multiple CVEs to ensure each CVE indicates the different vulnerabilities. Additional information can be found here.
Stage 9: Providing Information to The CVE Team
At this stage, the CVE Team asks that the researcher help provide additional information to be used in the official CVE listing on the website. The U.S. National Vulnerability Database (NVD) maintains this information online in their database as well.
OVAL
Open Vulnerability Assessment Language (OVAL) is an international, standardized language designed to facilitate the exchange of security-related information. It helps define and share information about system configurations, vulnerabilities, and compliance policies in a structured format, ensuring consistency across tools and organizations.
Oval Process
The goal of the OVAL language is to have a three-step structure during the assessment process that consists of:
Identifying a system's configurations for testing
Evaluating the current system's state
Disclosing the information in a report
The information can be described in various types of states, including: Vulnerable, Non-compliant, Installed Asset, and Patched.
The OVAL definitions are recorded in an XML format to discover any software vulnerabilities, misconfigurations, programs, and additional system information taking out the need to exploit a system. By having the ability to identify issues without directly exploiting the issue, an organization can correlate which systems need to be patched in a network.
The four main classes of OVAL definitions consist of:
OVAL Vulnerability Definitions: Identifies system vulnerabilities
OVAL Compliance Definitions: Identifies if current system configurations meet system policy requirements
OVAL Inventory Definitions: Evaluates a system to see if a specific software is present
OVAL Patch Definitions: Identifies if a system has the appropriate patch
Additionally, the OVAL ID Format consist of a unique format that consists of "oval:Organization Domain Name:ID Type:ID Value". The ID Type can fall into various categories including: definition (def), object (obj), state (ste), and variable (var). An example of a unique identifier would be oval:org.mitre.oval:obj:1116.
Scanners such as Nessus have the ability to use OVAL to configure security compliance scanning templates.
Last updated