The Common Vulnerability Scoring System is used by companies, products and services as a metric for evaluation of vulnerabilities. Many of them are now switching to the latest version, number 3. This article discusses the transformation, and the challenges and opportunities it brings.

Introduction

CVSS is a standard for evaluation of the severity of vulnerabilities in computer systems. Although it competes with various other standards, its success is attributable to its transparency and ready availability. Anyone can use it to evaluate vulnerabilities by first reading the documentation and then carrying out an implementation.

The first and often only goal of CVSS is to determine a base score. This is a figure from 1 to 10 that defines generic severity – independent of temporal and individual factors – for a given vulnerability.

Various aspects are taken into consideration to determine this value. The Access Vector, for example, defines whether attacks might come through the internet, a local network, a local system or through purely physical access. These attributes form the foundation for the final calculation of the score.

Porting

CVSSv2 vectors and scores are still being used in many instances. These will need to be transferred to ‘CVSSv3’:https://www.first.org/cvss/specification-document. A mathematical transformation of scores does not make sense, as the metrics are based on different calculations.

So at first glance it may seem that every vector and score will have to be reallocated. Fortunately, however, only a certain amount of reallocation will be required, with the rest of the vector information being converted or derived. This makes it possible to recalculate scores with a high degree of accuracy, without reattributing every vector.

The best example is the Access Vector (AV). In CVSSv2, this can have a position of either Local (L), Adjacent (A) or Network (N). These three positions are also available in CVSSv3, with the addition of Physical (P). This value can now be used for the sake of simplicity. Only a small number of scores will have to be manually set to P. Most of these will be listed primarily as L, as these are closest to P both logically and mathematically. The following table shows the conversion in this type of transformation:

Another, more complex expansion occurs with the CVSSv2 attribute Access Complexity (AC). In CVSSv3, this is now split into attack complexity (AC) and User Interaction (UI). This expansion makes sense because attacks that require user interaction can be assessed differently. This includes certain forms of Cross Site Scripting (XSS), Cross-Site Request Forgery (CSRF) and poofing techniques (e.g. clickjacking).

Further expansion comes with Scope (S). This indicates whether a successful attack has the potential to spread beyond its anticipated context.

New vector

CVSSv2 stipulates that for each given score, the vector must also be shown. The vector CVSS2#AV:N/AC:M/Au:N/C:C/I:C/A:C results in 9.3, a typical score for a critical remote attack. If the temp score is shown, the attributes of the expanded vector must also be shown. A CVSS2#E:ND/RL:OF/RC:C will result in a temp score of 8.1.

This vector behavior has resulted in a number of changes in CVSSv3. For pure base scores, the vectorization of the temp attributes must also be shown. The same calculation results in a base score of 10.0, a temp score of 9.5 and CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A::X/RL:O/RC:C as a total vector.

The syntax of the vectors is slightly different, at least when it comes to versioning. In addition, CVSSv3 comes with amended and additional vectors. However, it is only the inclusion of the temp value that tends to appreciably extend the vector. From the original six attributes for a base score, there are now 11. This is due primarily to the fact that undefined values in the temp score must be set to X (ND was used previously).

With CVSSv2, one can comprehend the vector at a glance and identify the individual attributes. The length of the CVSSv3 means that one must take time and focus on a search for the individual attributes.

Changed calculation

If one looks at the underlying formula for calculating scores, some subtle changes can be seen. One is that a C/I/A of P is weighted marginally less than C than previously. For temp scores, the status of an exploit is weighted a little more, reflecting the growing exploit market. A similar shift is seen in reliability of disclosures.

Looking at CVSSv2 and CVSSv3 scores, it is immediately apparent that these are trending upwards. In recent years, base scores have risen from an average of 5.8 to 6.3 (+0.5) and temp scores from 5.2 to 6.0 (+0.8).

The graphic illustrates the distribution of base scores for all disclosed vulnerabilities in 2016 so far. Here, the shift to higher scores becomes clear. This can be seen in the deflections 7→8 and 5→6. Generally, however, averaging means that previously criticized gaps are less conspicuous in reality.

Conclusion

CVSSv3 is about to replace CVSSv2. Most companies, products and projects are starting to transform and in the future will only offer CVSSv3. The new version of the popular system offers improvements at almost every level. Scores can be defined with greater granularity since the complex data is better equipped to take modern attack scenarios into consideration. The only contentious factor is the increased complexity of the vectors, which now will always be shown with all temp attributes.

A transformation is recommended that adopts, adapts and adds to existing CVSSv2 attributes. Thus, with comparatively little effort, high quality new scores can be achieved without having to generate them completely from scratch.

About the Author

Marc Ruef has been working in information security since the late 1990s. He is well-known for his many publications and books. The last one called The Art of Penetration Testing is discussing security testing in detail. He is a lecturer at several faculties, like ETH, HWZ, HSLU and IKF. (ORCID 0000-0002-1328-6357)

Links

• http://security.stackexchange.com/questions/127335/how-to-convert-risk-scores-cvssv1-cvssv2-cvssv3-owasp-risk-severity/127447
• https://vuldb.com/?cvssv3.2016
• https://www.first.org/cvss/specification-document#i2.1.1
• https://www.first.org/cvss/specification-document#i2.1.2
• https://www.first.org/cvss/specification-document#i2.1.4
• https://www.first.org/cvss/v2/guide
• https://www.first.org/cvss/v2/guide#i2.1.1
• https://www.first.org/cvss/v2/guide#i2.1.2