The Common Vulnerability Scoring System (CVSS) provides software developers, testers, and security and IT professionals with a standardized process for assessing vulnerabilities. You can use the CVSS to assess the threat level of each vulnerability, and then prioritize mitigation accordingly.
This article explains how the CVSS works, including a review of its components, and describes the importance of using a standardize process for assessing vulnerabilities.
What is a software vulnerability?
A software vulnerability is any weakness in the codebase that can be exploited. Vulnerabilities can result from a variety of coding mistakes, including faulty logic, inadequate validation mechanisms, or lack of protection against buffer overflows. Unprotected APIs and issues contributed by third-party libraries are also common sources of vulnerabilities.
Regardless of the source of the vulnerability, all present some risk to users and organizations. Until vulnerabilities are discovered and patched, or fixed in a software update, attackers can exploit them to damage systems, cause outages, steal data, or deploy and spread malware.
How vulnerabilities are reported
The way in which vulnerabilities are reported depends on the type of software they are discovered on and the type of vulnerability they appear to be. In addition, the perceived importance of the vulnerability to the finder is a factor in how it’s reported.
Typically, vulnerabilities are found and reported by security researchers, penetration testers, and users themselves. Security researchers and penetration testers may work full-time for organizations or they may function as freelancers working under a bug bounty program.
When vulnerabilities are minor or can be easily fixed by the user without vendor or community help, issues are more likely to go unreported. Likewise, if a severe issue is discovered by a black hat researcher, or cybercriminal, it may not be reported. Generally, however, vulnerabilities are reported to organizations or developers when found.
If a vulnerability is found in proprietary software, it may be reported directly to the vendor or to a third-party oversight organization, such as the non-profit security organization, MITRE. If one is found in open-source software, it may be reported to the community as a whole, to the project managers, or to an oversight group.
When vulnerabilities are reported to a group like MITRE, the organization assigns the issue an ID number and notifies the vendor or project manager. The responsible party then has 30 to 90 days to develop a fix or patch the issue before the information is made public. This reduces the chance that attackers can exploit the vulnerability before a solution is available.
What is CVSS?
The Common Vulnerability Scoring System (CVSS) is a set of free, open standards. These standards are maintained by the Forum of Incident Response and Security Teams (FIRST), a non-profit security organization. The standards use a scale of 0.0 to 10.0, with 10.0 representing the highest severity. The most recent version released is CVSS 3.1, released in June 2019.
These standards are used to help security
researchers, software users, and vulnerability tracking organizations measure
and report on the severity of vulnerabilities. CVSS can also help security
teams and developers prioritize threats and allocate resources effectively.
How CVSS scoring works
CVSS scoring is based on a combination of several subsets of scores. The only requirement for categorizing a vulnerability with a CVSS is the completion of the base score components. However, it is recommended that reporters also include temporal scores and environmental metrics for a more accurate evaluation.
The base score of the CVSS is assessed using
an exploitability subscore, an impact subscore, and a scope subscore. These
three contain metrics for assessing the scope of attacks, the importance of
impacted data and systems, and the scope subscore assesses the impact of the
attack on seemingly unaffected systems.
Base score
The base score is meant to represent the
inherent qualities of a vulnerability. These qualities should not change over
time nor should qualities be dependent on individual environments. To calculate
the base score, reporters must calculate the composite of three subscores.
Exploitability
subscore
The exploitability subscore measures the
qualities of a vulnerable component. These qualities help researchers define
how easily a vulnerability can be exploited by attackers. This subscore is
composed of the following metrics:
| Metric | Measurement | Scale (low to high) |
| Attack vector (AV) | How easy it is for attackers to access a vulnerability | Physical (presence) Local (presence) Adjacent (connected networks) Network (remote) |
| Attack complexity (AC) | What prerequisites are necessary for exploitation | Low High |
| Privileges required (PR) | The level of privileges needed to exploit the vulnerability | None Low High |
| User interaction (UI) | Whether exploitation requires actions from a tertiary user | Binary—either None or Required |
Impact
subscore
The impact subscore measures the effects that
successful exploitation has on the vulnerable component. It defines how a component
is affected based on the change from pre to post exploit. This subscore is
composed of the following metrics:
| Metric | Measurement | Scale |
| Confidentiality (C) | Loss of data confidentiality in the component or wider systems | None Low High |
| Integrity (I) | Loss of data integrity throughout the component system | None Low High |
| Availability (A) | Loss of availability of the component or attached systems | None Low High |
Scope
subscore
The scope score measures what impact a vulnerability may have on components other than the one affected by the vulnerability. It tries to account for the overall system damage that an attacker can execute by exploiting the reported vulnerability. This is a binary scoring with scope being changed or unchanged.
Temporal score
The temporal score measures aspects of the
vulnerability according to its current status as a known vulnerability. This
score includes the following metrics:
| Metric | Measurement | Scale (from low to high) |
| Exploit code maturity (E) | The availability of tools or code that can be used to exploit the vulnerability | Proof of concept Functional Unproven High Not defined |
| Remediation level (RL) | The level of remediation currently available to users | Official fix Workaround Temporary fix Unavailable Not defined |
|
Report confidence (RC) |
The degree of accuracy of the vulnerability report | Unknown Reasonable Confirmed Not defined |
Environmental metrics
Environmental metrics measure the severity of the vulnerability adjusted for its impact on individual systems. These metrics are customizations of the metrics used to calculate the base score. Environmental metrics are most useful when applied internally by security teams calculating severity in relation to their own systems.
The importance of standardization
CVSS provides comprehensive guidelines for assessing vulnerabilities. This scoring system is used by many and has a wide range of applications. However, perhaps the most important aspect of the CVSS is that it provides a unified standard for all relevant parties. Standardization is crucial when responding to risks and prioritizing mitigation.
CVSS scores are more than just a means of standardization. These scores have practical applications and can have a significant impact in helping security teams and product developers prioritize their efforts.
Within an organization, security teams can use CVSS scores to efficiently allocate limited resources. These resources may include monitoring capabilities, time devoted to patching, or even threat hunting to determine if a vulnerability has already been exploited. This is particularly valuable for small teams who may not have the resources necessary to address every vulnerability.
CVSS scores can also be useful for security researchers. These scores can help highlight components that are especially vulnerable or tactics and tools that are particularly effective. Researchers can then apply this knowledge to developing new security practices and tools to help detect and eliminate threats from the start.
Finally, CVSS scores can be informative for developers and testers in preventing vulnerabilities in the first place. Careful analysis of high ranking vulnerabilities can help software development teams prioritize testing. It can also help highlight areas where code security best practices can be improved. Rather than waiting until their own product is discovered to be vulnerable, teams can learn from other’s mistakes
The post How CVSS works: characterizing and scoring vulnerabilities appeared first on Malwarebytes Labs.