The widespread adoption of the (Industrial) Internet of Things (IoT/IIoT) has increased the attack surface for malicious attackers who exploit smart devices as entry points for accessing the internal systems of industries, institutions, and home networks. The need to carry out vulnerability assessment and to assign vulnerabilities a severity score as accurate as possible, is therefore of primary importance also in the IoT/IIoT domain. The current reference scoring system is the Common Vulnerability Scoring System (CVSS) [1]. It is used to assign a severity score to vulnerabilities and misconfigurations - often found in MITRE's Common Vulnerability and Exposures (CVE) database [2] [3] - on both commercial and open-source software products. The CVSS assigns a severity score based on several metrics, which model the characteristics of vulnerabilities in a general-purpose manner. However, IoT/IIoT software products operate in environments with unique characteristics that require dedicated contextualization. Prioritizing and resolving a vulnerability using a calculated level of risk that does not consider the technical specificities of the context in which software product operates - in our case IoT/IIoT - means spending resources and time incorrectly either overestimating or underestimating the problem. The following paper intends to present a context-aware scoring system for IoT/IIoT environment that, taking CVSS as starting point, extends its scope by presenting an overall assessment method of the severity and risk of vulnerability that best reflects the peculiarities of this environment.
The (Industrial) Internet of Things refers to the increasingly widespread practice of connecting
everyday objects to the network in order to create systems for monitoring and controlling the
physical environment around them [
One of the main characteristics of the IoT/IIoT is its extraordinary applicability in both the
industrial and domestic fields, which at the same time determines a strong application
heterogeneity. Today, we live in smart homes, wear smart devices, and largely work with automated
systems. This wide difusion also arouses lavish interest from malicious actors who exploit these
new access points to enter the systems of industries, institutions, and home networks and take
control of them [
Up to now, in fact, the few relevant attempts to set security requirements are represented by (i)
the OWASP IoT Security Verification Standard (ISVS) (2021) [
Nowadays, the de facto standard is the CVSS, a calculation system designed by the National
Infrastructure Advisory Council (NIAC) [
Thus, strong inconsistencies arise between what is reported in the final analysis deliverable and the actual severities of the issues identified. This strong gap is certainly linked to the diference between the need to generalize of CVSS - as a reference standard for scoring generic software products - and the strong specialization of the IoT/IIoT context - which requires ifner-grained parameters for calculating the final score.
This paper makes the following contributions: • Describes the need to expand the modelling scope of CVSS in order to encompass also those contextual technical features that afect the severity of a vulnerability, specifically for the IoT/IIoT world; • Proposes IoT Context-Aware Scoring System (ICASS), a context-aware CVSS-based risk scoring system for IoT/IIoT, defining new technical context metrics and equations for the corresponding calculation. • Performs a comparison between results of the proposed scoring system and CVSS, considered in its entirety (base, temporal, environmental, and overall score), emphasizing similarities and diferences.
The research carried out and the experience gained over the years in the field of Vulnerability Assessment and Penetration Testing (VAPT) of IoT/IIoT devices, show that they should be treated with specific techniques and methods compared to generic IT technologies. This also leads to the issue of how to accurately quantify the risk associated with a vulnerability. Traditional CVSS is too general-purpose to capture the complexity of IoT/IIoT environments and to precisely model the vulnerability risks, motivating several research eforts to revise current CVSS solutions to better adapt to the specific operating characteristics of IoT/IIoT devices.
The CVSS is the current reference risk scoring system. In its newest released version 3.1 it presents three diferent scoring metrics: base, temporal, and environmental. The base score measures both the exploitation dificulty level and the vulnerability impact in case it is exploited and remains constant over time and space. The temporal score, on the other hand, considers characteristics of the vulnerability that change over time such as the level of maturity of available remediation techniques, the current state of exploitation techniques, and the public availability of information related to the vulnerability itself. Finally, the environmental score provides a fine-grained parameterization of the severity beyond the base score, also considering the nature of assets potentially afected. The CVSS also provides an overall score that combines the results of the previous three scores. However, some metrics are not properly aligned with the IoT/IIoT context, while other ones should be added to better address the specific context, so it is important to understand the motivations that led us to reconsider and expand the scope of CVSS metrics.
The base score considers, among the exploitability metrics, the Attack Vector (AV) which measures the "distance" from which an attacker can carry out an attack. However, the operating conditions in which IoT/IIoT devices operate are often more limited. It may often happen that these devices are not connected to the Internet, are physically protected, and/or are dificult to access from the outside. The concept expressed by the AV must therefore be reconsidered based on the operating context in which the vulnerability is detected. If "Network" is assigned to AV, but the device is never connected to the public network, the final base score must certainly be leveled to be more accurate compared to the generic case. The same argument can be repeated for the values "Adjacent", "Local", and "Physical": the device can prevent others from establishing connections with it even in the local network, it can have shell-based access disabled by design, and it can be protected through physical mechanisms that prevent an attacker from touching it, respectively. Continuing on, the temporal metrics take into account the existence of appropriate remediations (i.e. Remediation Level, RL) decrementing the base score depending on the maturity level of the fixes. However, the mere availability of a remedy does not justify a decrease in the severity score. It should also be added that most maintainers of supported software products provide oficial fixes shortly after the publication of the related CVEs. This means that of the available values to assign to RL, "Oficial fix" is probably the most relevant (i.e. no base score decreases). Similarly, for products with longer maintenance and replacement times - such as IoT/IIoT devices and firmware - the mere presence of fixes does not provide information about the actual time of their adoption: proceeding with a decrease in the base score therefore would only create misunderstandings during the correction prioritization phase, resulting in an incorrect allocation of time and resources. Likewise, the Report Confidence parameter, which measures the level of confidence in the technical details related to the vulnerability, determines a negative change in the base score: the less details there are, the more the score decreases. Factors such as the reputation of the source, the quality of the information provided, and the level of testing performed can all afect the level of confidence in a vulnerability report, but these factors may be dificult to quantify or compare across diferent reports and may introduce subjective judgement. Furthermore, neither vulnerability discovered and not been (yet) published in the MITRE CVE database nor a known CVE with a dubious source are necessarily less severe and less worthy of being prioritized than oficial and confirmed ones. In light of this, the only relevant temporal metric remains the exploit code maturity, since it is reasonable to assign a higher priority to vulnerabilities with publicly available exploits and lower the score of issues without them. The same issues described for base metrics also apply to the environmental score, since a part of this score reflects the same metrics of the base score (i.e. exploitability metrics) and the remaining part is strictly related to asset company CIA (Confidentiality, Integrity, and Availability) requirements and are heavily based on subjective requirements, which do not represent the focus of this work as described in Section 4.1.
At the end of the day, therefore, by taking the CVSS and considering it in light of the peculiarities of IoT/IIoT, the shortcomings and criticalities described previously are highlighted. This leads us to fine-tune the risk scoring system in a way it is tailor-made to the IoT/IIoT context and therefore to propose and compute new overall scoring values more adherent to the considered environment.
Several articles have highlighted the incompleteness of CVSS in accurately modeling a
vulnerability in several contexts. In [
This paper presents a diferent scoring system called IoT Context-Aware Scoring System (ICASS) which proposes a set of new IoT/IIoT context-based metrics - derived from the contextual analysis of related software product - and a formulation that, starting from the CVSS base score of a vulnerability, better adapts the score associated with the application context.
Below, we propose metrics grouped into semantically related categories based on external exposure degree of the device. One aspect to emphasize is the type of metrics introduced. The proposed system adds purely technical parameters related to the peculiarities of the IoT/IIoT context. For this reason, neither metrics such as confidentiality, integrity, and availability requirements are touched in their definition, nor safety metric is introduced (i.e. the measure of the software’s danger in terms of physically damaging individuals and things). Although very interesting, this is not the focus of this work.
Internet Exposure As many IoT devices often do not have access to a large number of resources and/or do not require external services, it is common to find IoT devices that are not exposed on the Internet network (e.g. printers, smart meters, PLCs, etc.). Therefore, a vulnerability that can be exploited only via the public network has a diferent impact compared to the generic IT context. For this reason, the associated risk requires more precise modeling. The following two metrics belong to this semantic group: • is_exposed_to_internet: indicates whether the device is exposed to the public Internet network through listening ports (True if the device has one or more exposed services; False otherwise). • can_connect_to_internet: indicates whether the device, in turn, invokes services exposed by others on the Internet network (True if the device invokes one or more exposed services; False otherwise).
Intranet Exposure The discussion for the Internet Exposure group is repeated for local
networks. The possibility to have an IoT device not connected to the local network - acting as
an embedded device - exists as well. There are two parameters identified:
• is_exposed_to_lan: indicates if the device is exposed on a local network (True if the device
has one or more services; False, otherwise).
• can_connect_over_lan: indicates if the device, in turn, invokes services exposed on a local
network (True if the device invokes one or more exposed services; False, otherwise).
Shell Exposure The heterogeneous nature of IoT/IIoT devices and their limited computational
capabilities mean that they are not necessarily equipped with the conventional resources that a
generic IT system provides. In the case of bare-metal as well as real-time operating systems
described in [
Exploit Code Maturity The "Exploit Code Maturity" parameter defines the likelihood of the
vulnerability being exploited and is typically based on the current state of the art about exploit
techniques and general availability of exploit code and software. The heterogeneous hardware
components, the use of custom-designed boards and proprietary protocols and standards, makes
it very dificult to prepare custom exploits, adapt existing exploits, and use ready-to-use exploits.
We then understand how this parameter represents a good metric for contextualizing the final
score. Since CVSS 3.1 already provides d values for the Exploit Code Maturity, we simply reuse
them in our scoring system [
The final score calculation is performed as follows. Firstly, given one vulnerability, the corresponding CVSS base score is calculated. Secondly, the new metrics are evaluated based on well-defined rules available in Table 2. Depending on their occurrence, the weights included in Table 1 are considered or not in the final calculation. Finally, the initial CVSS base score is multiplied by each valid weight. The result is represented by the approximation to the first decimal place of the smallest value between the product and 10 or the largest value between 0 and the product. The final weights are the result of an analysis done in the field with the help of feedback from CryptoNet Labs S.r.l. (Milan, Italy) internal pentesters. The goal is to find the right balance between appreciating significant changes (e.g. moving from one severity to another) and not completely altering the base score. As a result, all chosen weights change the starting score by a value close to 10% for each, when applied. Regarding the exploitability code maturity, the contextual aspects described in Section 2.1 are also considered. As a result, each associated weight starts from the definition of CVSS given by FIRST and is decremented by one or more decimal points, highlighting the practical complexities of exploitability of IoT/IIoT devices.
In this Section, an evaluation of the described scoring system is performed once applied to existing vulnerabilities identified during VAPT activities on a commercially available device whose details, for confidentiality reasons, are anonymized. Specifically, the results are compared with both the base, temporal, environmental, and overall score of CVSS. × ℎ
× ℎ × ×
The software product under examination is a real-world Linux-based firmware designed for embedded devices. The device it runs on has a LAN port which enables access to a local network where it exposes several services. Moreover, the device is never connected to the Internet and is physically unprotected. Finally, it is classified as critical with respect to the CIA requirements. The results of the software composition analysis activities revealed various components afected by numerous CVEs. Forty-six of them were selected as a case study in order to have a heterogeneous sample to evaluate all the introduced metrics. The list of selected vulnerabilities with scores is available in the Appendix A and summarized in the Table 3.
In this section, we calculate the temporal and environmental score of CVE-2022-23304, stepbystep. The same procedure is repeated for the other vulnerabilities under examination, but for brevity, the results are directly available in Appendix A.
The CVE-2022-23304 afects version 2.9 of a software named hostapd, used for creating wi-fi access points and setting up authentication servers, and has a base score vector of AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Below is the calculation: • Temporal Score: there is no evidence of existing exploits for the vulnerability, neither on the network, nor in the hyperlinks related to the corresponding NIST page, nor on exploitdb, nor finally on the Rapid7 Vulnerability & Exploit Database. At the same time, among the hyperlinks available on the corresponding NIST page, there is a URL to the oficial fix for the vulnerability. Finally, being included in the CVEs, this vulnerability can be considered confirmed. Final values: ’Unproven’ (exploitability code maturity), ’Oficial ifx’ (remediation level), and ’Confirmed’ (report details). • Environmental Score: given that the device cannot communicate with the public network, it is necessary to modify the attack vector. Being a vulnerability that afects a wi-fi access point creation tool, we overwrite with the value ’Adjacent’. The device also requires high levels of confidentiality, integrity, and availability. With respect to the reference context, all other metrics are confirmed. Final values: ’Adjacent’ (attack vector), High, High, High (confidentiality, integrity, and availability requirements).
The temporal score is 8.5, while the environmental and overall scores are 7.7. For the calculation of all the other CVEs, newer versions with corresponding vulnerability resolutions are always identified and no exploits are detected from the sources mentioned above except for CVE-2021-23017 for which a public exploit is found on exploit-db. Additionally, all CIA requirements metrics are setup to ‘High’ value and modified AV environmental metric is decreased to ‘Adjacent’ just in those cases it is equal to ‘Network’.
Continuing with the metrics proposed in this paper, evaluating the resulting conditions, and applying the formula presented, we proceed with the calculation of the new score. Given the assumptions defined in Section 5.1, we assign the values for each metric as shown in Table 4.
We now proceed with the calculation of ICA Score on CVE-2022-23304. Since the device does not expose or use services exposed on the public network, and at the same time has a base score attack vector set to ’Network’, the rule (4) in Table 2 applies. The corresponding weight of 0.88 is multiplied by the CVSS base score which is 9.8. This results in IoT Context-Aware Exploitability = 8.6. As stated in Section 5.2, there is no evidence of exploits for the vulnerability. Consequently, the exploit code maturity is ’Unproven’. The corresponding weight is multiplied by IoT Context-Aware Exploitability.
The same calculation is summarized as follows:
= × 0.88 × 0.84 = 7.2
From the table presented in the Appendix A, we note that Severity CVSS score range Critical ICASS consistently reclassifies scores of CVEs downward compared to CVSS. The reason behind this is related to a more precise modeling of both the exploitability complexity and technical exposure characteristics of IoT/IIoT devices. Specifically, the percentage decrease of the ICA score in reference to the CVSS base score – calculated as the percentage of the CVSS score of the absolute diference between the scores in question - is equal to 23.4%, which is a significant diference. Since other CVSS parameters’ goal is to better contextualize the CVSS base score, a comparison between them and the new ICA score is useful. The values difer in a percentage ranging between 12.5% and 15.8%, which again is significant. This is because CVSS parameters are not designed with the IoT context in mind, but with a general-purpose goal. On the contrary, ICASS uses custom built parameters for the IoT context, so its score is helpful in risk analysis activities and represents a key indicator for prioritizing fixes and allocating resources for IoT/IIoT companies.
Let us now consider the score with respect to the severity categories defined by FIRST and
assigned to vulnerabilities based on their numerical score (Table 5). From the graph in Figure 1,
we note that severities obtained from the temporal and environmental metrics vary the severity
of the base CVSS by at most one level. They are designed "to produce a severity more accurate
for their organizational environment" [
Finally, Figure 3 summarizes the results obtained with respect to severity levels. The overall image reflects what has been previously discussed, with a general decrease in severity level compared to all scores for forty-six CVEs under examination. In particular with respect to this case study, one of the most evident benefits is the shift of the severity average from the high/critical categories of the CVSS base severity to the medium/low of the ICA severity. This leads to a more efective prioritization of vulnerabilities and resource allocation, and at the same time to less waste of time and money.
This paper proposes a method for quantifying the severity of vulnerabilities in IoT/IIoT devices, which builds upon the de facto standard CVSS and introduces context-specific metrics to improve the accuracy of the resulting score. The proposed scoring system overcomes shortcomings and limitations of CVSS with respect to the IoT/IIoT field. It begins by calculating the CVSS base score, then by applicating correctives based on the values chosen for the introduced metrics. These metrics are quantified based on weights derived from real-world cases and scenarios and reflect the IoT/IIoT context. Experiments conducted show that without revolutionizing the de facto standard CVSS but simply making corrections and additions related to the IoT technical context, we can obtain a greater degree of accuracy in evaluating vulnerabilities severities. The consequences of a better severity attribution are reflected in benefits in terms of prioritization of vulnerabilities and, thus, in a better allocation of economics and time resources.