Ruslan Rakhmetov, Security Vision
We have already talked about how the CVSS vulnerability assessment system ( Common Vulnerability Scoring System ). In the previous review, we talked about how this standard came about and why unification became a convenient tool. The methods for assessing vulnerabilities were supplemented and improved, each new version of the standard sought not only to correct the shortcomings of the previous one, but to make the vulnerability assessment more accurate, granular and relevant to the modern threat landscape. We will focus on the most recent version, and you can read about the evolution in detail from our partners.
- Great detail.
New metrics have been added for more detailed assessment. For example, attack complexity (Attack Complexity ) is now supplemented with attack requirements (Attack Requirements (AT), which describe the preconditions for a successful attack on a vulnerable component.
- Eliminating ambiguity.
Some metrics from v3.1 have been reworked for greater clarity. For example, the User Interaction (UI) metric now has a value of Passive (P), when the user is only required to visit the malicious site, and Active (A), when more complex actions are required.
- New metric groups.
This is essentially a more formalized and expanded version of the "Time Metrics" from v3.1 with the addition of an exploit availability metric (E), a "threat" metric. Threat modeling, which can be done, for example, in the Risk modules Management (RM) and Compliance Management (CM) Security Vision also uses the threat database to update various metrics over time. Compared to earlier versions, the differences are even more dramatic, with version 3 adding the Scope metric , and 3.1 refining definitions and wording to improve clarity and consistency in assessments, making the standard even more usable and accurate.
The transition to CVSS v4.0 will be gradual, but it marks an important step in the evolution of vulnerability scoring, making it more flexible and informative for all stakeholders in the cybersecurity process. But while it is incredibly useful, it is not a silver bullet for prioritizing vulnerabilities; it is a severity score, not a risk score. Risk can be quantified as severity multiplied by probability. CVSS does a great job of scoring severity, but it does not take into account the true likelihood of exploitation in the wild. For example, a vulnerability with a score of 10.0 that is not being exploited may be less risky than a vulnerability with a score of 7.5 that is already being targeted by a massive attack campaign.
Most databases (NVD, CVE) show only a basic score, which may be far from the real danger for your specific infrastructure. CVSS evaluates vulnerabilities in isolation, but will not show how a combination of three vulnerabilities with a medium severity level can lead to a complete takeover of the system. In the process of incident management, we call this an attack chain (Kill - chain), the formation of which is an important part of the SV module's work. SOAR is on par with dynamic playbooks and AI assistants.
During the installation of VS/VM modules and during operation we encounter several questions from customers who are beginning to formalize the processes of searching for and eliminating vulnerabilities.
1) For example, about the difference between CVSS and CVE, we can say the following: CVSS is a rating system that assigns a numeric severity score (from 0 to 10) to CVE (Common Vulnerabilities and Exposures). This, in turn, is a unique identifier for a specific vulnerability. In fact, this is its "serial number" (for example, CVE-2021-44228). Simply put, CVE is the name of the vulnerability, and CVSS is its danger rating.
2) CVSS scores can be assigned by different organizations. The most common is NVD (National Vulnerability Database), which analyzes CVE. Also, assessments can be provided by software manufacturers themselves, security researchers or specialists within the company who conduct their own risk analysis. In Russia, vulnerabilities are also processed by FSTEC, which publishes separate materials.
3) CVSS is not a legally binding standard for everyone, but it has become a de facto industry standard. Many regulators and security standards (such as PCI DSS) require a vulnerability management process, where CVSS is a key component for scoring and prioritization.
4) Major updates (such as v2 to v3 or v3.1 to v4.0) occur every few years. This process is overseen by a dedicated team within the FIRST organization, which collects feedback from the community and adapts the standard to the changing cyber threat landscape.
These issues lead to periodic updates of the scanner and vulnerability management modules, the progress of which you can follow on our blog. That is why modern approaches to vulnerability management are supplemented with information from Threat Intelligence (data on current threats), information on the importance of assets and business logic (in the resource-service model SV AM) and transmit data to response centers to ensure the elimination of incident consequences (e.g. SV module SOAR).
In conclusion of the review, we would also like to give an example of calculating metrics for a specific vulnerability in the popular collaboration platform Atlassian Confluence: It allowed an unauthenticated attacker to execute arbitrary code on the server.
Vector for calculating the base score: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.
Let's break it down into parts:
- Attack Vector (Attack Vector) – AV:N (Network): The vulnerability is exploited by sending a specially crafted HTTP request to a vulnerable server. The attacker only needs to have network access to the Confluence web interface .
- Attack Difficulty (Attack Complexity) – AC:L (Low): the attack is extremely easy to perform. The malicious command is placed directly in the request URL. No complex manipulations or bypassing of protective mechanisms are required.
- Necessary Privileges Required) – PR:N (None): this is one of the most dangerous scenarios. To exploit the vulnerability, you do not need to be an authorized user of the system. The attack can be carried out by absolutely anyone who can "reach" the server.
- User intervention (User Interaction) – UI:N (None): the attack is aimed directly at the server application. No legitimate user involvement (for example, forcing him to click on a link) is required.
- Scope – S:U (Unchanged): this is an important difference from Log4Shell. Despite gaining full control over the server, the scope of influence is considered unchanged. This means that the attacker executes code with the rights of the same user on behalf of which the Confluence application itself runs. The attack does not allow "jumping out" from under the control of the application and capturing, for example, another virtual machine on the same hypervisor.
Next comes the classic triad of influence:
- Confidentiality – C:H (High): Having the ability to execute code, an attacker can read any data available to the application: the contents of all Confluence pages, configuration files, database access keys, etc.
- Integrity – I:H (High): an attacker can change any files, modify pages, inject malicious code, or completely delete data.
- Availability – A:H (High): an attacker can stop the Confluence service, delete key files for its operation, or run ransomware, making the system completely inaccessible.
If we enter these parameters into the CVSS calculator, we get a base score (Base Score): 9.8 (Critical), but let's also consider how this score is affected by time and context metrics:
- Literally a day after the vulnerability was published, working exploits and scanners for finding vulnerable servers appeared in the public domain, the E metric became H (High). This left the rating at a critical level.
- However, when Atlassian quickly released patches, the RL metric became O (Official), signaling to administrators that a robust solution existed and the final time estimate for their systems could be reduced after installing the patch.
- Let's imagine that in company "A" the Confluence server is accessible only from the internal network and is isolated from the Internet, then the administrator can change the attack vector to MAV:A (Adjacent), which will dramatically reduce the threat assessment for their environment.
- In company "B" there is a modern Web in front of the Confluence server Application Firewall (WAF) that blocks suspicious URLs. This can be countered by increasing the attack difficulty to MAC:H ( High ), as the attacker now needs to find a way to bypass the WAF.
Both of these examples show how a general score of 9.8 turns into a much lower, organization-specific score. CVSS-BTE (Base + Threat + Environmental), the most comprehensive and accurate all-in-one score, takes into account all three metric groups we discussed earlier. This example clearly shows why it is necessary to use all three metric groups to accurately assess risks.
Of course, our company, which specializes in process automation, has not left aside the vulnerability metrics assessment procedures. However, in addition to our tools, you can also use, for example, the official CVSS Calculator, supported by FIRST. This is an interactive web tool where you can select values for each metric (AV, AC, PR, etc.) and instantly get the final base, time and context scores, as well as the corresponding vector. Using an automated method is the best way to understand the relationship between different metrics and how they affect the final result.
Mastering CVSS is an investment in a more mature, effective, and ultimately more secure vulnerability management process. It is an indispensable tool for any vulnerability professional.
.jpg)