Vulnerability risk assessment

Several initiatives have emerged with the purpose of assessing the risk of vulnerabilities. Microsoft defined a proprietary scoring system reflecting the difficulty of exploitation and the overall impact of vulnerabilities (Microsoft SecBulletin 2012). This scoring system consists in rating the vulnerability severity (Critical, Important, Moderate, and Low), and on the Microsoft Exploitability Index, which indicates the likelihood of a vulnerability to be exploited in the future. A similar approach is proposed by the SANS Institute (an organization that provides information security training and security certification) with the @RISK method (SANS @Risk 2012), which consists in ranking vulnerabilities by their criticality level (Critical, High, Moderate, Low). The problem of these approaches is that they lack a clear and detailed method on how the impact and exploitability of each discovered vulnerability is assigned.

The CVSS is an open framework aimed at standardizing the evaluation of vulnerability risk, mitigating the problem of having different impact scores for the same vulnerability (Mell, Scarfone, and Romanosky 2007). It is a vulnerability risk assessment approach that has been widely adopted by enterprises and that we use in the benchmark metric portion of our security benchmark methodology. CVSS is sponsored by the Forum of Incident Response and Security Teams (FIRST) and its popularity can easily be confirmed by browsing popular vulnerabilities databases. The importance of CVSS to our security benchmark methodology is that we use CVSS approach to estimate the risk of vulnerabilities in our security benchmark metric.

CVSS is composed of three metrics groups aimed at providing the definition and communication of the fundamental characteristics of vulnerabilities: base, temporal, and environmental. Each group of metrics (CVSS sub-equations) can vary from 0 (minimum) to 10 (maximum criticality of the reported vulnerability). A more specific group definition is as follows:

- Base. This refers to the vulnerability characteristics that are constant over time and across user environments. For example, the impact of a vulnerability to the security attributes of confidentiality, integrity and availability.

- Temporal. This refers to the vulnerability characteristics that change over time but not among user’s environments - such as remediation level and report confidence.

- Environmental. This refers to the vulnerability characteristics that are relevant and unique to a particular user’s environment. For example, the potential for loss of life or physical assets or the importance of the vulnerable component to the business.

CVSS framework has been improved over the time and there is a board responsible for receiving feedbacks from security community and adjusting and calibrating framework requirements, metric attributes and equations. From 2007 to 2015, CVSS version 2 was the official version and has been widely adopted by industry and academia. Most of the vulnerability scores provided in the US National Vulnerability Database, for example, have been reported in accordance with Version 2. However, in June 2015, CVSS Version 3 was announced, as a result of the work performed by the CVSS Special Group that started in 2012. This new version contains score adjustment, better description of framework criteria, updated vulnerability vector string, and etc. According to the authors, CVSS Version 3 explicitly states at which point of an attack the score should be

computed, reducing the variations in impact metrics between scorers. The fact that Version 3 is a very recent proposal, and also considering that the new version is in the process of being adopted by industry and academia, led us to keep our security measurements based on CVSS Version 2. We do recognize the improvements that were made on Version 3 and we do expect to provide in the future a new version of our security benchmark reflecting the changes that were recently proposed.

Within the base metric group of CVSS Version 2 there are 6 metrics covering two aspects: access and impact. The first includes the access vector (which indicates how the vulnerability is exploited), access complexity, and the authentication metrics that capture how the vulnerability is accessed and whether or not extra conditions are required to exploit it. The impact is measured by the three impact metrics (confidentiality impact, integrity impact and availability impact) measure how a vulnerability, if exploited, will directly affect the system. The impact is defined as the degree of loss of confidentiality, integrity, and availability independently from each other (e.g., a vulnerability exploit may cause a partial loss of integrity and availability, but no loss of confidentiality). These metrics and the equation to measure them are fully described in (Mell, Scarfone, and Romanosky 2007). The details on the attributes of the base metric group of CVSS are important as we use them to compute the benchmark metric of our security benchmark methodology. The attributes are:

- Access Vector (AV). This metric reflects how the vulnerability is exploited. The possible values for this metric are Local, meaning that the attacker needs either physical access to the vulnerable system or a local (shell) account, Adjacent Network, which means that the attacker needs access to either the broadcast or to the collision domain of the vulnerable software, and Network, meaning that the vulnerable software is bound to the network stack and the attacker does not require local network access or local access. Each one of these values has an associated CVSS score, defined as 0.395 (Local), 0.646 (Adjacent Network), and 1 (Network). The more remote an attacker can be from the target and still be able to attack it, the greater the vulnerability score: a vulnerability that is exploitable remotely (Network) will obtain the highest score in the access vector metric.

- Access Complexity (AC). This metric captures the complexity of the attack required to exploit the vulnerability once an attacker has gained access to the target system. The possible values for this metric are High: special conditions (such as a vulnerable configuration) are required but

they can hardly occur in practice, Medium: the required access conditions are somewhat specialized but are not commonly configured, (e.g., a non- default configuration), and Low: specialized access conditions do not exist, or if they exist they are ubiquitous (e.g., a default configuration). Each one of these values has an associated CVSS score, defined as 0.35 (High), 0.61 (Medium), and 0.71 (Low). The lower the required complexity, the higher the vulnerability score.

- Authentication (Au). This metric focus on the number of times an attacker must authenticate to a target in order to exploit a vulnerability. The possible values for this metric are Multiple, meaning that the attacker needs to authenticate two or more times, even if the same credentials are used each time), Single, meaning that only one instance of authentication is required to access and exploit the vulnerability), and None, which means that authentication is not required at all for the attacker to access and exploit the vulnerability). Each one of these values has an associated CVSS score, defined as 0.45 (Multiple), 0.56 (Single), and 0.704 (None). The fewer authentication instances that are required, the higher the vulnerability score.

- Confidentiality Impact (C). This metric reflects the impact on confidentiality of an exploited vulnerability. Confidentiality refers to limiting access and disclosure of information to authorized users, which means preventing access and disclosure to unauthorized users. The possible values for this metric are None: there is no impact on confidentiality, Partial: there is considerable information disclosure, and Complete: there is total information disclosure. The associated scores are 0 (None), 0.275 (Partial), and 0.66 (Complete) - the higher the confidentiality impact, the higher the vulnerability score.

- Integrity Impact (I). This metric focus on the impact an exploited vulnerability to integrity defined as the trustworthiness and guaranteed veracity of information. The possible values and score for this metric are None (0): there is no impact to the integrity of the system, Partial (0.275): it is possible to modify some information (e.g., files), but the attacker does not have control over what can be modified, or the scope of what the attacker can affect is limited, and Complete (0.66): there is a total compromise of system integrity - the attacker can modify any information on the target system). The higher the integrity impact, the higher the vulnerability score.

61 (accessibility of information resources) of an exploited vulnerability. The possible values and scores for this metric are None (0): there is no impact to the availability of the system, Partial (0.275): the availability of the system or its resources is reduced, but not completely, and Complete (0.66): there is a total unavailability of the affected resource - the attacker can render the resource completely unavailable). The higher the availability impact, the higher the vulnerability score.

The CVSS metrics can be used to assess the risk of software vulnerabilities. Because these metrics have clear and well-defined meanings and values, they can be helpful to obtain a method approaching a standard. For example, the IBM X- Force team has used CVSS to report the risk level of vulnerabilities, using the following scale: Critical (CVSS score is equal 10), High (CVSS score ranges from 7 to 9.9), Medium (4.0-6.9), and Low (0.0-3.9). Figure 2-3 presents the result of risk analysis for the vulnerabilities covered by X-Force Team during the year of 2011. It is worth noting that 2% of the disclosed vulnerabilities during 2011 were critical, while the major part had a medium risk (69%). This is a very important finding since it helps users and developers to concentrate their security efforts on the most critical vulnerabilities.