Risk assessment and control selection for cyber-physical systems: a case study on supply chain tracking systems

2.1.1. CPE

The Common Platform Enumeration^[14] catalog is a structured naming scheme for information technology systems, software, and packages. Utilizing CPE-recorded products makes it easier to map the various components residing in systems, and various scanners used for enumeration utilize the CPE catalog for their output. Finally, for each product recorded in the CPE catalog, linked entries might reside in the CVE and CWE catalogs. In the proposed methodology, we utilize CPE to assist in the mapping of CPS components to actual vulnerabilities.

2.1.2. CVE

The Common Vulnerabilities and Exposures (CVE) ^[15] list contains publicly known cybersecurity vulnerabilities. A vulnerability is defined as a "weakness in the computational logic (e.g., code) found in software and hardware components that, when exploited, results in a negative impact to confidentiality, integrity, or availability". Each CVE entry, i.e. vulnerability, contains an identification number, a description, and at least one reference for publicly known cybersecurity vulnerabilities. Additional entry information can include mitigation information, severity scores, and impact ratings according to the Common Vulnerability Scoring System (CVSS). We utilize CVE in the identification of low-level software vulnerabilities for the system components.

2.1.3. CVSS

The Common Vulnerability Scoring System (CVSS) ^[16] provides a framework and a methodology, through which security experts and vulnerability researchers may define specific exploitability metrics of a vulnerability that include: The attack vector (AV) that is required to exploit the vulnerability, with possible values physical (P), local (L), adjacent network (A), and network (N); the attack complexity (AC) required for exploiting the vulnerability, either low (L) or high (H); the privileges required (PR) to exploit the vulnerability, taking the value none (N), low (L), or high (H); the required user interaction (UI) with possible values none (N) and required (R); and finally the scope (S), which denotes whether the vulnerability affects only the system in question or changes to affect other software. Furthermore, the impact metrics define the potential effect on confidentiality (C), integrity (I), and availability (A), all taking the value none (N), low (L), or high (H). The available labels for these characteristics are supported by weights, which can be utilized to produce numerical scores reflecting the severity and impact of the vulnerability. These scores can then be translated into a qualitative representation to help organizations properly assess and prioritize their vulnerability management processes. In our methodology, we extensively use CVSS to measure and map the cumulative vulnerability level for each identified interaction between system components.

2.1.4. DREAD and STRIDE

DREAD ^[17] is a cybersecurity risk assessment approach that stands for damage, reproducibility, exploitability, affected users/systems, and discoverability. The aforementioned aspects characterize the risk associated with different attack scenarios, and in particular, they aim to answer questions such as "what is the damage of a potential attack or threat to a system", "how an attack may be reproduced", "how easy an adversary may attack to a system", "how many systems or people may be affected", and "how easy it is for the attacker to identify the relevant vulnerabilities". Additionally, STRIDE^[18] is a threat modeling approach that facilitates the process of threat identification and analysis of six types of threats: spoofing (violation of authenticity), tampering (violation of integrity), repudiation (violation of non-repudiability), information disclosure (violation of availability), and elevation of privileges (violation of authorization). Both approaches have been developed by Microsoft aiming at the comprehensive security analysis of the targeted systems, since STRIDE identifies and analyzes the cybersecurity threats, while DREAD analyzes the accordant risks of the aforementioned cybersecurity threats. Although both approaches have been developed to analyze the security of software-related systems, their application in domains where the application of CPS is prominent is popular ^[19–21]. In the proposed methodology, we utilize STRIDE in threat analysis and DREAD in risk evaluation and propagation.

2.1.5. Genetic algorithms

Genetic algorithms (GAs) facilitate the randomized search by leveraging the structures of natural genetics and natural selection mechanisms ^[22]. Particularly, GAs aim to solve problems for which the solution cannot be found with exhaustive search mechanisms due to the very large solution space. The main attributes of GAs are the coding scheme, a set of operators, and a fitness function ^[23]. Overall, a GA addresses unconstrained optimization problems, including the one this study aims to address.

2.2.1. A methodology to assess IoT-enabled, cyber-physical attack paths^[11]

The methodology of Stellios et al.^[11] is a CPS-specific risk assessment methodology, whose goal is to assess cyber-physical attack paths which are IoT-enabled, i.e. the attack involves the exploitation of inter-connected IoT-IT systems. The methodology is target-oriented and source-driven. For each run of the methodology, a critical system is defined as the attack target. For all the systems/devices in range, their interactions, i.e. connectivity or other dependencies, are defined. Then, based on the interactions, a recursive algorithm is executed to construct all the attack paths and thus identify all the effective sources for all the attack paths. To assess the vulnerability of each interaction and each attack path, it utilizes CVSS-like vectors to indentify specific interactions and assess their exploitability characteristics in cyber-physical systems. Ultimately, the vulnerability level of components is also calculated in a CVSS vector and compared with the interaction capabilities to produce validated results. Furthermroe, this approach enables the assessor to map and express all the interactions in a source–destination format, , which are then combined to generate probable attack paths to later be assessed.

As illustrated in Figure 1, the methodology consists of four phases. In the first phase, the interaction modeling is executed, which aims to map all of the potential cyber and physical interactions that reside in the context of the infrastructure under duress and target towards a designated system. The algorithm developed for this phase essentially iterates over cataloged device and network classes, which contain connectivity configurations and input/output capabilities, to enumerate applicable interactions amongst the components. In the second phase, the calculated interactions are further assessed based on the vulnerabilities of the target component. Essentially, the previously enumerated interactions are extended with a so-called cumulative vulnerability vector (CVV), derived from a combination of the CVEs identified for the active devices acting as targets. This cumulative score is refined by environmental information such as networking information and related security controls. In the third phase, the attack paths are built through the exhaustive combination of the assessed interactions enumerated in Phase 2. This algorithm builds attack paths that may vary in length, involving one or more interactions; in this case, loops that do not offer elevated exploitability characteristics are considered as noise and removed. In the fourth phase, the previously enumerated attack paths are assessed and a risk value per path is assigned. This risk is produced using the CVV of each interaction tuple, the vulnerabilities of the initial nodes, and the characteristics of adversaries that are applicable to the infrastructure and capable of initiating the attack path.

Figure 1. An overview of the underlying CPS RA methodologies of Stellios $$\textit{et al. }$$^[11] (left) and Kavalieratos $$\textit{et al.}$$^[13] (right)

On the positive side, the methodology in ^[11] allows for detailed cyber and physical interaction modeling. In addition, it takes into account low-level vulnerability input by utilizing de facto standards such as CPE, CVE, and CVSS. Finally, by targeting the analysis to a specific "critical target system", it allows for an efficient computation of risks for all the attack paths that may lead to the critical target system. On the negative aspects, it does not support detailed risk management and control selection, which is only possible through a repeated "what-if" analysis that requires sequential re-execution of the methodology.

2.2.2. A CPS methodology for risk propagation and control selection^[13]

Kavalieratos et al.^[13] proposed a methodology to analyze the propagation of the security risks among complex CPS infrastructures. By leveraging a genetic algorithm approach, the most effective and efficient security controls per CPS component are identified. Building upon the results of the aforementioned work, we extend the methodology to analyze attack paths between CPSs and improve the security control selection process to identify a set of security controls that minimizes both the residual risk and the cost ^[12]. Overall, the phases of the aforementioned works are the stepping stones for the methodology proposed herein.

In the environment analysis, the system model is described in terms of components. The CPS components are identified along with their interconnections, dependencies, and inter-dependencies. By leveraging this information, the CPS coefficients are estimated and their values represent the effects of each component on the other components and the overall system. The rest of the process defined as Cybersecurity analysis consists of different stages of the risk management process, as specified in ISO 31000 ^[10]. In the Threat analysis stage, the cybersecurity threats are identified per component and CPS using the STRIDE methodology. In the Risk assessment stage, the risk value associated with each threat from the previous step is estimated by leveraging the DREAD methodology. Having estimated the risk values, the risk per component, CPS, and path is evaluated. Consequently, in the Attack path analysis step, the risk aggregation between components and CPSs are analyzed, and the most critical attack paths are identified. Finally, in the Risk treatment step, a genetic algorithm s decides the most effective and efficient set of cybersecurity controls. The applicability, effectiveness, and cost of each control is considered.

The aforementioned approach analyzes the target environment following a system of systems perspective. Namely, the security analysis of each component is performed towards the overall analysis of the targeted ecosystem, also considering the total effect of each component on the targeted ecosystem. This approach facilitates the analysis of ecosystems under development to ensure their overall security. However, the correlations between the components are estimated considering only the information and control flows without taking into account cyber interactions. Additionally, the system and component vulnerabilities are not considered in this approach.

3.4.1. Risk propagation

The aggregate risk $$ R^{agg_{c_j}}_t $$ of component $$ c_j $$ is calculated using Equation (5).

where direct risk $$ R^{dir_{c_j}}_t $$ is the risk of $$ c_j $$ without considering the possible connections with other components and is estimated using Equations 2-4, while the propagated risk $$ R^{prop_{c_j}}_t $$ is calculated considering the connections to other components that $$ c_j $$ has. The fraction of the impact that an event has on any $$ c_k $$ on any path $$ p_l $$ from $$ c_i $$ to $$ c_j $$ is represented by $$ eff^T_{p_l} $$ and is calculated as

where $$ eff^T_{c_ic_{i+1}} $$ values are extracted from the CVV interaction scores of Equation (1) after the values have been normalized in the range [0, 1].

The risk propagated over path $$ p_l $$, originating at component $$ c_i $$ and terminating at component $$ c_j $$, is calculated by:

The whole system is described by $$ c_0 $$ and the global risk of threat $$ t $$ for the system is calculated by:

where the direct risk for the system is not applicable ($$ R^{dir_{c_0}}_t = 0 $$) and the propagated risk for the system is calculated as for any other node ($$ R^{prop_{c_0}}_t = \max_{p_l} R^{prop^{p_l}_{c_0}}_t $$). Thus,

To summarize, our risk analysis method is able to capture the effect of both the cyber and physical interactions between components. This is due to the fact that the $$ CVV $$ value of each interaction has the ability to chain vulnerabilities and interactions of different types, as illustrated in Equation (1). The $$ CVV $$ is then utilized in Equation (6) to compute the coefficient $$ eff^T_{c_ic_{i+1}} $$. The paths along which the risk is propagated consist of potential one-to-one interactions between different system components, which can be physical or cyber-related. As the global risk computed in Equations 8 and 9 is based on the propagated risk over paths [Equation (7)], this enables our model to capture the impact reflected from the cyber to physical components and vice versa.

Further details about the method used and the aforementioned equations are omitted in the interest of saving space and can be found in ^{[12, 13]}.

4.2.1. System threat and vulnerability analysis (supply chain)

To initiate and execute the system threat and vulnerability analysis, a combination of the calculated interactions and the enumerated vulnerabilities was implemented. For the destination nodes of the recorded interactions, the applicable vulnerabilities were initially enumerated in a list as SingleCVSS vectors, and then the same vulnerabilities were combined to produce ChainedCVSS vectors, which were also added to the list. From each list, a single or chained vulnerability with the highest exploitability and impact values was selected to act as the CVV. Table 6 illustrates the CPE identifiers of the assets included in the scenario along with a set of enumerated vulnerabilities that acted as the SingleCVSS vectors.

Table 7 contains the initial interaction vector $$ IntCVSS $$ (modified based on existing network security controls), the resulting $$ CVV $$ of the interaction resulting from $$ IntCVSS $$, and the existing vulnerabilities, as described by Equation (1). For each $$ CVV $$ value, we present its CVSS vector, the exploitability and impact subscores, and the overall score. In the context of this table, we observe a set of interesting interactions: For the interaction $$\texttt{(Sensor, Phone, C2)}$$, we observe that the sensor has write privileges in the database of the phone application that forwards the data to the VendorDB. If the sensor is compromised, this data flow can be abused to inject malicious messages into the phone. For interaction $$\texttt{(Phone, Sensor, P3)}$$, we observe that both the sensor and the phone utilize Bluetooth frequencies; in this spectrum, both jamming and packet injection attacks are applicable. By compromising the phone in this case, an attacker could both send falsified data to the VendorDB about the sensor readings and send confirmations to the sensor that the data are received. Furthermore, by installing a small jammer on the truck, an attacker could disrupt the communication throughout transfer, which could result in product spoilage. This fact is confirmed by the high values of the calculated integrity and availability impact for the observed interaction. For interaction $$\texttt{(AzureOS, AzureCompute, C3)}$$, we observe that all the initial impact values are mitigated from high to low based on the existing network security controls; nevertheless, the impact is increased due to the vulnerabilities found on the destination system and the final $$ CVV $$ impact is shifted to high. A similar case holds for the interaction $$\texttt{(VendorDB, AzureCompute, C4)}$$. Finally, for interaction $$\texttt{(VendorDB, Phone, C4)}$$, we observe that an attacker that has compromised the phone network, through either the phone or the service provider, could intercept and inject the confirmation messages sent from the vendor database towards the phone application. In such a scenario, neither the phone application nor the VendorDB would be able to identify the loss of integrity of the relevant supply chain tracking data.

We observe that, while interactions $$\texttt{(VendorDB, AzureCompute, C4)}$$ and $$\texttt{(VendorDB, Phone, C4)}$$ share the same interaction type and initial IntCVSS vector, their final CVV vectors, exploitability, and impact values deviate. This occurs due to Equation (1), which combines the IntCVSS vector, the SingleCVSS vectors, and the ChainedCVSS vectors to output a single CVV per interaction. The initial IntCVSS vector for interaction $$\texttt{(VendorDB, AzureCompute, C4)}$$ is $$\texttt{AV: N/AC: L/PR: N/UI: N/S: C/C: N/I: N/A: N}$$; the component has one cataloged vulnerability, so the ChainedCVSS and the SingleCVSS vectors are identical, namely $$\texttt{AV: N/AC: L/PR: N/UI: N/S: U/C: N/I: H/A: N}$$. Combining these vectors through Equation (1), we can see that, in the final CVV vector $$\texttt{AV: N/AC: L/PR: N/UI: N/S: C/C: N/I: L/A: N}$$, the interaction has inherited part of the impact caused by the vulnerability. The high impact of the vulnerability, which would mean a total loss of integrity or protection, was not fully passed on to the interaction due to network controls mitigating part of the effect. The derived low integrity impact means that data modification might be possible from an attacker as per CVSS ^[16].

4.2.2. System risk analysis (supply chain)

As mentioned in Section 3, the system security analysis is quantified using STRIDE and DREAD methodologies to thoroughly identify the risk to each component and each threat. For each individual component, the initial impact and likelihood values associated with the STRIDE threats were computed by DREAD, as depicted in Tables 8 and 9. Damage represents the damage that a cyber attack may provoke to the systems; along with the affected users/systems, it represents the impact of the attack. Additionally, reproducibility represents the ability of the adversary to reproduce the attack, exploitability refers to the ability of the attacker to exploit the component's vulnerabilities, and discoverability refers to the capacity of the adversary to identify system vulnerabilities. The sum of reproducibility, exploitability, and discoverability represents the likelihood of a cyber attack. Each column of Tables 8 and 9 represent individual components, indicated by their corresponding initials, as defined in Section 4.1. The values inside the cells are the corresponding impact and likelihood values per STRIDE threat and per individual component; these were calculated by Equations 2 and 3. Each of the DREAD variables - damage, reproducibility, exploitability, affected users/systems, and discoverability - accepts an integer value in [0, 3], the value being assigned by considering the specific DREAD criteria described in ^[4].

4.2.3. Towards system security architecture (supply chain)

For each STRIDE threat, a set of security controls was selected by applying the methodology described in Section 3 to reduce the initial risk. The primary set of controls is listed in NIST guidelines for Cybersecurity Supply Chain Risk Management Practices ^[1]. In this report, cybersecurity supply chain risk management (C-SCRM) is integrated into risk management activities by applying a multilevel, C-SCRM-specific approach, including guidance on the development of C-SCRM strategy implementation plans, C-SCRM policies, C-SCRM plans, and risk assessments for products and services. ^[1] The first column represents the global initial risk that would occur without any security controls, as calculated in the risk analysis step. The second column represents the optimal set of security controls that reduce the risk, which is represented as the residual risk in the third column.

The optimal set of security controls towards the security architecture of the supply chain architecture depicted in Figure 4 are described in Tables 10-15. Particularly, the optimal set of security controls per STRIDE threats and per system are depicted along with the associated risks per threat. The security risks represent both the initial risk value - prior control selection - and the residual risk value - post control selection. Denial of service and elevation of privileges threats are characterized as the most critical threats for the targeted supply chain infrastructure. Tampering, repudiation, and information disclosure threats are characterized as medium level threats, while spoofing is a low level threat since the initial risk is the lowest with the value 1.34.

The security controls depicted in the tables below were identified by leveraging an automated decision support tool proposed in this work. Although the security controls reduce the initial risks of each component and each threat, their applicability is should be verified by domain experts and stakeholders together. The proposed methods enable the execution of what-if scenarios by modifying the initial list of the available security controls from NIST ^[1] and/or the parameters of the genetic algorithm.

By observing Tables 10-15, it is obvious that the optimal security controls for the reference supply chain management system consist of a large number of controls.

For the spoofing threat, the component that is in need for more security controls is the Vendor DB, as all collected data are stored there, and any successful spoofing attempt would result in a high-impact security incident, which could pose a significant risk to the entire system. For all other components of the system, it is also required to apply a number of spoofing-related security controls to limit the propagated risk for the system. For the tampering threat, the same holds for the Vendor DB because of the significance of the data stored therein. In general, it is observed that controls are significantly required in total to achieve similar risk reduction with the spoofing threat. For the repudiation threat, even fewer controls are required for the same risk reduction effect. For information disclosure, it should be noted that the phone must be more protected than other components (with three controls), as it seems that more vulnerabilities on the phone may be exploited for improper retrieval of information. For the denial of service threat, endpoint components such as sensors and phone produce low impact slightly on the system in general, and thus no controls are selected for them. The Azure components (OS and compute) are more vulnerable and need to be more protected to mitigate high risk propagation to the system. Finally, regarding the elevation of privileges threat, it is not highly critical to protect the endpoint components and the most prominent issues are identified for the AWSCompute component.