A Review of the Common Vulnerability Scoring System
by Joseph B. Abramson, Senior Engineering Analyst
The Common Vulnerability Scoring System (CVSS), Version 3.0, is the result of the computer technology industry’s efforts to quantify the severity of a vulnerability (exploit), and to represent the defining characteristics of each vulnerability in a terse, textual format called a “vector string”, or just “vector”. Computer security experts evaluate known vulnerabilities and upload their results to the National Vulnerability Database (NVD) which the National Institute of Standards and Technology maintains. These evaluations, in the terse form of the vector string and various metrics as well as a verbose form, are available for public use.
While the elements of computer system vulnerability analysis are not controversial, the central problem the designers of a scoring system face is how to map qualitative factors (or categorical variables) into numerical values, and from there how to combine these values into a meaningful metric by means of a coherent scoring system. It is this problem we are primarily concerned with here. We start with a brief description of the CVSS approach, and then follow it with an analysis of the numerical mapping problem.
Abstractly, various qualitative inputs are provided by security experts. The system converts these into numerical quantities. Then it transforms these inputs into two sets of outputs: the vector strong and the numerical metrics (CVSS Scores). The scoring scheme consists of three groups of metrics: Base, Temporal, and Environmental. The first is required, the latter two optional. Furthermore, each score uses its predecessor as input. The Base group measures the intrinsic qualities of the vulnerability, regardless of time or location. The Temporal metric takes the passage of time into account (patches, remediation, etc.) and the Environmental metric takes the specific production environment into account. The NVD only provides the Base metrics and associated information. Users can then build on the base metrics to flesh out their vulnerability assessments by adding the Temporal and Environmental scores, if desired. All of these metrics are of the Lower is Better type with respect to organizational and operational utility.
The CVSS Base Score considers both the exploitability and impact of each vulnerability. The exploitability variables (also called metrics) are Attack Vector, Attack Complexity, Privileges Required, and User Interaction. The impact variables are Confidentiality Impact, Integrity Impact, and Availability Impact. An additional variable, Scope Change, specifies whether the impact is limited to just the vulnerable component, or includes the larger application environment, to include data and other resources. The Temporal Score builds on the Base Score by incorporating variables concerned with the effects of the passage of time since the discovery of the vulnerability. These variables are called Exploit Code Maturity, Remediation Level, and Report Confidence. The Environmental Score includes the first two, but adds Requirement variables for Confidentiality, Integrity, and Availability. It also adds Modified Base Metrics.
All of these variables (so-called “metrics”) are categorical in nature, not numerical. For example, the first exploitability variable, the Attack Vector, can take on any one of the following values: Network (N), Adjacent (A), Local (L), or Physical (P). The idea here is that an Attack Vector with a value of N would add more to the severity score than any of the others because a remote attack could be carried out. A vulnerability with Attack Vector value of P would get a lower score because physical access would be required to carry out the attack. Similarly, Attack Complexity can be either Low (L) or High (H), and so on.
Viewed in this fashion, one can see a natural ordering of the possible values assigned to each variable. This implies a movement from the nominal level of measurement to the ordinal. The first permits only of mathematical operations of inclusion and exclusion (group membership). The second level permits comparison operations (greater or less than). This is not sufficient for a severity scoring system, however, since these values have to be synthesized via some mathematical function into a true metric. Therefore, it is required to put these values on at least an interval level, and preferably, a ratio level. CVSS accomplishes this by assigning fixed numerical values to the valuables. The complete set of variables (“metrics”), ordinal values, and numerical values is given below:
While the assignment of these particular numerical values may appear arbitrary, they were actually chosen to fit the larger scoring scheme. This will be discussed further in the sequel.
Once numerical values for the constituent elements of the scoring system are available, it remains to combine them into a meaningful severity score. Out of all possible ways to do this, the Special Interest Group decided upon the following scoring system. The full equations for the first two scores are given below:
Once the Base and Temporal Scores have been computed, the Environmental Score can be computed (shown below). The Overall Score is simply the last one calculated. The source for all these equations is the CVSS 3.0 Specification Document.
Even for the Base Score, the determination of the output scores is rather complex. For example, the determination of the numerical values for the Privilege Required variable is affected by the selection made for the Scope variable. Naturally, Scope affects the value of the Impact Sub-Score and then finally the Base Score. The calculation of the Exploitability Sub-Score is straightforward, by comparison, as is that of the Temporal Score.
The calculation of the Environmental Score is strongly affected by the Modified Scope value (see box below). Finally, note that all scores are rounded up to one decimal place.
Whichever score is ultimately used, the final output is a vulnerability severity metric on a numerical scale (from zero to ten). This score can then be mapped back to a qualitative (yet ordinal) severity rating scale. This mapping is given below:
This categorical Severity Rating need not be used, but it is important for our purposes because it is closely tied to the design and parameter specification of the entire scoring system. In fact, the experts started with a set of real vulnerabilities, rated them according to this severity rating scale, assigned numerical values to them, chose a functional form for the scoring metric, and then adjusted the formula parameters within certain limits to bring the model into alignment with their own ratings.
The scoring system itself can be seen as the result of extracting a great deal of subject matter expertise from a sizable group of computer security domain experts (drawn from industry, government, and academia) and encoding it in the form of certain mathematical functions and parameter values. The principal merit of CVSS 3.0 is that it is, in fact, common. This means that there is a single standard way to assess vulnerability severity within organizations, and to communicate about vulnerability severity between organizations. The vector string is a highly compact way of representing a vulnerability analysis. It is both machine readable and readily intelligible to human users. It is easily stored and transmitted for subsequent use, either in a manual or automated fashion. This facilitates the transmission and use of information about computer system vulnerabilities. This information can in turn be used to establish risk priorities and make more rational decisions about risk remediation or response. CVSS 2.0 had already begun to gain industry acceptance. With version 3.0, released in June 2015, NIST has achieved something like an industry standard. This surely contributes to the promotion of better computer system security nation-wide.
The scoring system is not without some drawbacks, however. Although the standard is indeed open, it is not simple. The scoring mechanism is quite complex and convoluted. While on-line calculators are available for human use, it is difficult to implement in software for machine use. More importantly, the metrics are not additive, which is counter-intuitive. Rather the scoring system uses a complex internal mechanism whereby outputs are fed back in at various stages. This means that the metrics are actually mutually (and serially) dependent. Furthermore, the various elements of vulnerability analysis have roughly equal weight. In general, one would prefer to see a scoring scheme that looks something like this:
where the Vulnerability Score is given as a simple scaled and weighted sum of the input variables. This would provide much greater flexibility should the entire system need to be re-evaluated at some future date. As it stands now, the relationships between the scoring system parameters and the final score are so inextricably intertwined that the entire system would have to be rebuilt from scratch. Also, it would be much easier to assess the individual weights this way rather than resorting to some more involved computational method to make the weight parameters fit the highly non-linear score model. Furthermore, the CVSS 3.0 Score has gaps in the output function. It would be preferable to have a continuous (and even differentiable) function that could in turn be embedded in some larger optimization model (say, one capturing the trade-off between security and scalability).
Another drawback is more conceptual. While the score has a clearly defined impact component, the exploitability component is not defined in a probabilistic way, which might be preferable. That is, the vulnerability score could have been the product of the probability of successful discovery, access, and exploitation and the value of the impact. This is ordinarily how risk scores are defined in other settings, such as investment and finance. In the given system, exploitability and impact are harder to tease apart. It would make more sense to evaluate each of them individually and then bring them together in the final score. The fact that the entire result is subjective would be more acceptable if the knowledge representation problem had been handled differently. Subjective inputs will always produce subjective outputs but the internal working of the scoring system should be not just open and logically consistent but also readily intelligible to the users, at least ideally. If human users treat CVSS 3.0 as a black box, just supplying the inputs and accepting the outputs (say, by using one of the on-line calculators) then everything is fine. But if the human users, who are presumably themselves subject matter experts in the area of computer security, see results that don’t conform to their own intuition, then the proposed standard will not be so readily accepted and thus lose value.
