What is CVSS and How Does Onapsis Use It?
What Is CVSS?
It is nearly impossible to create error-free software or hardware, and for complex systems, this is even more true. Not every bug is a vulnerability, but many bugs are. Vulnerabilities are discovered quite regularly, both by systematic research or by sheer coincidence. In an ideal world, every vulnerability would be fixed as soon as it became known, just as every implementation flaw would be fixed as soon as the developers became aware of it. However, many vulnerabilities are not just implementation flaws, but are rooted in misguided design, and fixing such vulnerabilities may require a major re-engineering. In any case, the world is not ideal since resources are limited, and therefore, findings must be dealt with according to their priority.
When discovering a vulnerability, it is necessary to determine its severity and its priority, because depending on the severity, a vulnerability should be fixed immediately or it can be deferred to a later time. For instance, it is commonly agreed that a remote code execution, a command injection or a SQL injection for an internet facing server should be fixed with very high priority, especially if the exploit is simple to conduct. Conversely, a subtle vulnerability that can be exploited only under rare conditions and requires local access to the affected system may be postponed—not indefinitely, but it is clear that such a vulnerability receives a much lower priority.
One of the major tasks for a security analyst or a security researcher is to classify vulnerabilities by severity. This knowledge forms the basis for security scanners, including the assessment framework within The Onapsis Platform. The core benefit of such a tool comes down to provide answers to questions like “Is there need for action?”, “Where is action needed?” and “What should be done?“. Given that an assessment tool may emit finding lists with hundreds or thousands of items, the question “What should be done first?” is also important for the system or application owner.
Now, the severity and the priority of a vulnerability are closely related but they are not the same, because the priority depends on other factors such as business criticality or the surrounding environment. For instance, a system that provides a vulnerable web-based administration interface might still enjoy a low priority if the interface is not accessible due to some other mechanism. Likewise, a vulnerability that could lead to the disclosure of documents is of lesser importance if the documents in the affected repository are public anyway. In the same way it makes a great difference if the exploit to a vulnerability requires a lot of manual work and advanced technical skills or if a point-and-shoot exploit script is readily available.
In order to prioritize the items on the list of findings, the typical procedure is to assign each item a numerical score. This way the order of actions is determined – simply start at the item with the highest score. The de-facto standard to rate vulnerabilities is the Common Vulnerability Scoring System (CVSS) that is maintained by FIRST. CVSS provides a score ranging from 0.0 (no issue at all) to 10.0 (most critical). More precisely, CVSS provides three scores, namey the Base Score, the Temporal Score and the Environmental Score. The Base Score is the score that one finds quite frequently, while the Temporal Score and the Environmental Score are rarely seen. This has to do with the statement that each score makes.
The Base Score is a purely technical score that, once determined, does not change over time and is independent from non-technical considerations like, “Is the vulnerability relevant for the affected system?“. Time dependency is introduced by the Temporal Score that considers questions like, “Is the vulnerability confirmed?”, “Is there a fix or workaround?” and “To which extent is exploit code available?“. It should be immediately clear that the answers to these questions (a) modify the severity of a vulnerability in a certain sense and (b) change over time (until they eventually converge to a final state), hence the name “Temporal” Score. Moreover, it is obvious why the Temporal Score rarely appears in vulnerability enumerations like CVE – Temporal Scores would require regular updates. However, it is quite reasonable for an organization to calculate the Temporal Scores for Findings in the course of a rigorous risk assessment, especially if it must focus on the high priority vulnerabilities.
Finally, the Environmental Score takes the security requirements into account. For example, a vulnerability with confidentiality impact is less exciting if there is no confidentiality requirement. However, such requirements are unique to the environment in which the assessment is conducted, and they are not intrinsic to the assessed targets. In fact, the application or system owners must provide this additional information, and as with the Temporal Score, the Environmental Score is meaningful only in specific environments or specific scenarios.
In the following we will consider only the Base Score, and “CVSS score” or simply “score” means CVSS Base Score, where CVSS means CVSS version 3.1.
Score Calculation and Vector Strings
The score depends on several factors to be discussed in a moment where each factor can be chosen from a list of discrete choices. Each choice is associated with a numerical value. The actual calculation of the score is quite involved and the process does not yield much insight of why the calculation is done this way or why the choices have these particular numerical values. It would exceed the purpose of this post to describe all of this here, see the specification document for such details. Suffice it to say that in the end the scoring is designed to yield “reasonable” results, such that high severity vulnerabilities get a high score and low severity vulnerabilities get a low score. In other words, for the very most or even all vulnerabilities the score should ideally be in accord with the verdict of an experienced security expert.
The factors that make up the score are
- Attack Vector (Network, Adjacent, Local, Physical)
- Attack Complexity (Low, High)
- Privileges required (None, Low, High)
- User Interaction (None, Required)
- Scope (Unchanged, Changed)
- Confidentiality (None, Low, High)
- Integrity (None, Low, High)
- Availability (None, Low, High)
For each factor one of a few values can be assigned, and that determines the numerical value and thus the score. Broadly speaking, these factors measure the exposure and the impact of a vulnerability. Also note that certain issues that The Onapsis Platform report are fundamentally not covered by CVSS. For instance, there is no score for logging being turned off. Although this might be an issue for compliance, this is not a vulnerability, and consequently, there cannot be a vulnerability score for it.
Although the scoring scheme looks pretty simple and apparently self-explanatory, and there are online calculators that allow one to “play” with the choices, there are some pitfalls. If used carelessly, the resulting score is meaningless. Once more it is beyond the scope of this post to describe that in detail. The reader is instead referred to the excellent CVSS User Guide and the list of examples; the scoring and the rationale for more than 30 cases are given there in detail.
An important feature of CVSS is that it provides not just the score but also the vector of its factors in compressed form, so instead of a plain number like 7.0 the score is accompanied by a string like CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:L. This is the terse form of: using CVSS 3.1, attack vector: network, attack complexity: high, privileges required: none, user interaction required: none, scope: unchanged, confidentiality impact: high, integrity and availability impact: low. This way it is possible to comprehend the issue better and to reproduce the score, as the score alone does not provide much information. The example vector expresses the following: the vulnerable target can be attacked from the network (possibly but not necessarily the internet), the attack requires some special conditions to be met, the attack can be conducted without authentication and does not require some user to do something a priori, a successful attack will strike the vulnerable target itself, a successful attack will breach confidentiality quite severely (in a suitable sense) and integrity and availability only moderately.
Where Do We Find CVSS in The Onapsis Platform?
The Onapsis Platform displays the CVSS score for applicable vulnerabilities. OP (Onapsis Platform) treats vulnerabilities as issues, a term that tries to encapsulate the variety of problems the platform is able to find on an ERP system. These problems can range from company-specific misconfigurations to what are known as common vulnerabilities.
The CVSS score can be easily found by navigating to the Issues in Assess. The Issue Summary panel, which displays key information for the issue, will show its CVSS score when applicable.
OP also uses the CVSS in the Assess Dashboard to give users a quick glance at three key metrics: the average CVSS score, the highest and the lowest. The CVSS for all unresolved issue occurrences is calculated taking into account all impacted assets in your landscape. The resulting number is mapped to a bar gauge that is color-coded to the Severity associated with the CVSS range.
The Average CVSS score helps understand if the number of unresolved issue occurrences leans more toward the lower or higher end of the CVSS scale. In the end – no unresolved issue occurrence should be overlooked, which is why the widget also includes the Highest and Lowest CVSS for unresolved issue occurrences.
Naturally, not all systems are the same, and some bear more criticality than others. Perhaps we care more about an unresolved issue with a Low CVSSS occurring on an important system more than we do about an unresolved issue with a High CVSS occurring on a less sensitive system. One way to hone in on those systems is to apply an Asset filter to the Assess Dashboard – or a Tag filter if you’ve labeled a group of critical assets using Tag.
This will limit these metrics to only the systems that are considered most relevant.
One way to use the CVSS as a progress indicator is to periodically export the Assess PDF Report and monitor the Lowest, Average and Highest CVSS score decreasing to 0 as the issue occurrences are remediated.
So, we would like to think our CVSS metrics decreasing to zero means we’ve fully driven risk out of our environment. But sadly, the answer is no. As mentioned above, the OP can find a wide variety of issues on ERP systems and CVSS is not applicable to all of them. This is why it’s important to complement remediation progress with tools like the Trend Analysis and Occurrences widget, which track if all issue occurrences found by the platform have been resolved.
The CVSS is widely accepted, used, and understood by the cybersecurity community as an indicator of the potential impact of a vulnerability. The Onapsis Platform leverages this score to help customers assess and prioritize the issues to remediate.
