What is CVSS Severity?

The Common Vulnerability Scoring System (CVSS) offers a way to capture the major features of a vulnerability and produce a numerical score showcasing its severity. The numerical score can then be translated into a qualitative representation such as low, medium, high and critical to assist companies to effectively assess and prioritize their vulnerability management processes.

Severity Levels

This severity level is based on a self-calculated CVSS score for each specific vulnerability. CVSS is an industry-standard vulnerability metric and they are:

• Critical
• High
• Medium
• Low

For CVSS v3, security experts make use of the following severity rating system:

CVSS V3 Score Range            Severity Advisory

0.1-3.9                                                                            Low

4.0-6.9                                                                            Medium

7.0-8.9                                                                            High

9.0-10.0                                                                          Critical

Severity Level: Critical

• Exploitation of the vulnerability may result in the root-level compromise of infrastructure devices or servers.
• Exploitation is normally straightforward, in the sense that the attacker does not need any special authentication credentials or knowledge about individual victims and does not need to persuade a target user, for instance via social engineering, into performing any special functions.

For critical vulnerabilities, it’s advised that you upgrade or patch quickly, except if you have other mitigating measures that are put in place. For instance, a mitigating factor may be if your installation is not accessible from the internet. 

Severity Level: High

Vulnerabilities that score in the high range usually have some of the following features:

• Exploitation could result in elevated privileges.
• The vulnerability is difficult to exploit.
• Exploitation could result in downtime or a significant data loss.

Severity Level: Medium

Vulnerabilities that score in the medium range normally have some of the following features:

• Denial of service vulnerabilities that are difficult to set up.
• Vulnerabilities that require the attacker to manipulate individual victims via social engineering tactics.
• Vulnerabilities where exploitation provides only very limited access.
• Vulnerabilities that require user privileges for successful exploitation. 
• Exploits that require an attacker to reside on the same local network as the victim.

Severity Level: Low

Vulnerabilities in the low range normally have little impact on a company’s business. The exploitation of such vulnerabilities typically needs local or physical system access. 

How Vulnerability Score and Risk Management Interact

(A) The Scores Do Not Measure Risks 

The scores measure the probability that a component will be compromised and will not behave according to specifications. They neither measure the probability nor the severity of the damage. Therefore, they do not measure risk as defined by ISO 1491.

(B) The Scores Help To Assess Risks

The scores offer a metric to assess the probability of damage or system malfunctions. The adaptation of these metrics by the environmental metric group helps in this assessment.

(C) Scores in the Post-Market Phase

The CVSS is mainly significant for manufacturers in the post-market phase. Manufacturers must always keep an eye on the messages about vulnerabilities and decide whether measures need to be taken. It’s in this decision-making process and when prioritizing measures that the scores are useful.

Obviously, a product with a vulnerability that can only be exploited by accessing the product does not have the same priority as a product that can be attacked remotely through the network without the input of a user. 

Tip

The MDR demands that criteria be established in the PMS plan whereby manufacturers take preventative and corrective measures. The metrics of the CVSS lend themselves to this. 

In inspections, inspectors and auditors will choose the vulnerabilities with the highest score so as to check whether the manufacturer has detected and eliminated the vulnerability effectively and efficiently. Notifying the user and the authorities of the measures in compliance with the law is part of the inspections.

Vulnerabilities in the Risk Management File

There is no point in documenting every vulnerability reported in the risk table. This would be too excessive. But manufacturers should check the following for the vulnerabilities:  

1. Integrity of Components Analyzed

The malfunctioning of the affected parts has already been analyzed in the risk table. Otherwise, it would need to be included. 

2. Accuracy of the Estimated Probabilities

The probabilities estimated in the risk table agree with the actual events and the CVSS assessment. Otherwise, they need to be corrected and the risks re-evaluated. 

3. Accuracy of the Anticipated Malfunction

The malfunction of components that may occur because of the vulnerabilities is carefully evaluated in the risk table. For instance, it may be the case that the manufacturer has already detected that in a cyber attack the components offer corrupt data but have not considered that the attack may cause a memory leak, which causes the whole system to crash. This would also be included to the risk table and the risks would be re-evaluated.

Be Careful 

If the vulnerabilities reported may lead to system malfunctions that have not been looked into, manufacturers must evaluate the effects on users, patients and third parties. 

Work Instructions or Procedure Specifications 

It’s ideal to work in two steps and, if necessary, with two work instructions or procedure specifications:

1. The first is how to proceed in the event of the above analysis. It should demand written information on each vulnerability and whether or not  the current risk analysis covers everything. If so, the reference to the risk I.D is enough. If it’s not sufficient, information on the risk management file is needed. This description is mainly for IT security.
2. The second specifies how new or changed risks are to be documented in the risk management file. To some extent, this specification is not mainly for IT security. 

 

Photo by Darby Lee on Unsplash