Safety Meets Security: Using IEC 62443 for a Highly Automated Road Vehicle

Abstract

In this work, we conduct and discuss a consensus-based risk analysis for a novel architecture of a driverless and electric prototype vehicle. While well-established safety standards like ISO 26262 provide frameworks to systematically assess risks of hazardous operational situations, the automotive security field has emerged only in the last years. Today, SAE J3061 provides recommendations and high-level guiding principles of how to incorporate security into vehicle systems. ISO/SAE 21434 is a novel automotive security standard, which, however, is still under development. Therefore, we treat the aforementioned architecture as a single Industrial Automation and Control System (IACS) and provide an implementation of the IEC 62443 series. We collaboratively identify threats in a three-round process and define a scoring scheme for automotive risks. As a result, we obtain a tailored bundle of compensating security mechanisms. Based on our work, we suggest improvements for future automotive security standards when it comes to the co-engineering of safety and security.

1 Introduction

The increasing connectivity and the growing computational power of road vehicles come along with great potential, but likewise lead to security concerns as demonstrated by prior works [6, 15, 25]. Beside new security challenges, the field of safety is also affected by vehicle automation, because a human being cannot be assumed anymore as a fallback layer. As modern road vehicles are typically complex cyber-physical systems and need to meet legal requirements, a standardized process for risk identification and mitigation is typically applied. Currently, the ISO/SAE 21434 [5] is the most promising candidate for an automotive security standard. It provides risk assessment methods for Intelligent Transportation Systems (ITS). After identifying and decomposing threat scenarios into attack paths, Cybersecurity Assurance Levels (CAL) indicate the estimated security requirements for given items. Moreover, SAE J3061 [3], published in 2016, provides general guidelines for the development of secure automotive components. It is inspired by the ISO 26262 [1] safety standard and reuses techniques from existing security models such as EVITA [10] and HEAVENS [2]. Schmittner et al. [20] demonstrate the security analysis of an automotive communication gateway by applying the concept phase of SAE J3061. They derive high-level security requirements, using the Confidentiality, Integrity, and Availability (CIA) triad. While their work focuses on a single component, our objective is to analyze an automated vehicle as a whole. For that purpose, we apply the IEC 62443 standards [4] to a recently announced novel vehicular architecture [24]. We argue, that IEC 62443 overlaps with the main idea of the unpublished ISO/SAE 21434. That is, it provides a risk-based security analysis process, takes into account interfaces to external components (e.g., V2X), identifies and assesses threats, and eventually uses Security Levels (SL) to describe security requirements. When it comes to threats, Petit and Shladover [17] identified 12 sources of potential attacks on automated vehicles and evaluated each one regarding its feasibility, occurrence probability, consequences and mitigation techniques. Beside the goal of a systematic security requirement analysis, our research question concerns the possibility of co-engineering security and safety demands in a vehicular system. In the following, we aim at sharing our lessons learned and suggest improvements for future automotive security standards.

2 Overview of a Novel Vehicular Architecture

In 2018, seven German universities and industry partners announced the development of four fully automated and driverless vehicles [24]. These vehicles are supposed to serve as an evaluation platform for new concepts in various fields, such as automation, modularization, verification, validation, safety, and security. Unlike contemporary vehicles, that typically consist of dozens of Electronic Control Units (ECUs), the novel E/E architecture follows a centralized approach, which is inspired by the human nervous system. That is, four sensor modules collect and preprocess radar, Lidar, and camera data. They hand them over to the cerebrum, which is responsible for the trajectory and for behavioral planning based on the sensor data. The brainstem, in turn, implements and tracks the trajectory and instructs the spinal cord to eventually move the vehicles. The latter provides all necessary steering angles and both braking and acceleration torques to four dynamic modules, which drive the wheels. In case of failures, the brainstem reflexively enforces an emergency trajectory, by which a safe halt is usually triggered. All aforementioned modules are connected over BroadR-Reach in a ring topology, allowing communication even if a switch breakes down. The dynamic modules are additionally wired over FlexRay, which serves as a supplementary fallback layer. In total, 26 ultrasonic and 2 radar sensors, denoted as platform sensors, allow for near-field sensing and are directly connected to the brainstem over CAN. For in-vehicle communication, the Automotive Service-Oriented software Architecture (ASOA) [11] is deployed, a new modular framework, that enables flexible communication, fast and secure updates of ECUs, and easy replacement of hardware components.

Fig. 1.

Overview of the proposed vehicular architecture [12]

Beside the prototype vehicles, a new infrastructural concept provides environmental information such as traffic updates via V2I communication. A cloud serves as a collective memory, such that vehicles can incorporate predictive driving behavior by learning from each other. Drones collect and share additional traffic information which helps the vehicles to create a realistic environmental model. This information is fed into trajectory planning algorithms on the cerebrum. A control room enables the remote control by a human in case automatic maneuvering is not possible anymore. It is only called into action in exceptional situations, in order to meet European legal requirements.

In the following, the term vehicular architecture refers to the novel E/E architecture in combination with its external components as illustrated in Fig. 1.

3 Introduction to IEC 62443

The IEC 62443 [4] is a series of standards and technical reports that provide a structured risk assessment and mitigation process for Industrial and Automation Control Systems (IACS), alongside with management guidances, policies, and terminology. An IACS typically describes a complex system consisting of various computing units, sensors, actuators, temporarily connected devices, and a human interface, that all collaboratively work on the outcome of a specific product. The overall objective is to identify threats, assess resulting risks, and come up with protection techniques.

As shown in Fig. 2, the actual risk assessment process is described in IEC 62443 -3-2 in consecutive steps, denoted as Zone and Conduit Requirements (ZCR). In the first step, all relevant assets of the System Under Consideration (SUC ) are identified (ZCR 1). A high-level security analysis (ZCR 2) gives indication about the worst-case unmitigated risk on each asset and whether further investigation is necessary. Based on the results of this high-level analysis, the SUC is partitioned into zones and conduits (ZCR 3), whereas a zone contains assets with the same or similar security requirements. A conduit is a special zone type, that connects two other zones and therefore, usually describes a network. In ZCR 4, the tolerable risk $r^{\text {tol,max}}_{}$ of each zone is compared with the unmitigated risk $r^{\text {u}}_{}$. If $r^{\text {tol,max}}_{}$ is below $r^{\text {u}}_{}$, no further action is required. Otherwise, a detailed security risk assessment follows in ZCR 5.

Fig. 2.

Simplified workflow of IEC 62443 -3-2

The main objective of ZCR 5 is to iteratively reduce the unmitigated security risk of identified threats ($\mathcal {T}$) by applying compensating countermeasures. Threats are associated with seven Foundational Requirements ($\mathcal {FR}$). That is, Identification and Authentication Control (IAC), Use Control (UC), System Integrity (SI), Data Confidentiality (DC), Restricted Data Flow (RDF), Timely Response to Events (TRE), and Resource Availability (RA). Since the security of a system refers to the mitigation of threats, an exhaustive list of threats and exploitable vulnerabilities is crucial (ZCR 5.1–5.2). Both the impact and the likelihood of each threat (ZCR 5.3–5.4) is determined, in order to compute the unmitigated security risk $r^{\text {u}}_{}$ of each threat (ZCR 5.5). Based on these results, a target security level SL-T for each zone is computed. IEC 62443 differentiates between four levels, SL-1, SL-2, SL-3, and SL-4. While SL-0 is implicitly defined as no requirements, SL-1 demands for protection against coincidental violations. SL-2 - SL-4 cover intentional violation with an increasing level of skills, resources, and motivation. Both impact and likelihood are reevaluated (ZCR 5.9) after applying changes to the SUC, e.g., after introducing a new countermeasure. Ideally, this leads to a reduction of the residual risk (ZCR 5.10). A reassessment of the high level risk, however, is not caused. Once the unmitigated risk of all threats is below the tolerable risk, the SUC is considered secure.

4 Application of IEC 62443

We consider the presented vehicular architecture as our System Under Consideration (SUC). Since it shares most IACS properties like sensors, actuators, and computing units, we use the IEC 62443 standards for a full security risk analysis. We demonstrate how to implement the generic guidelines ZCR 1–5 of IEC 62443 -3-2 with the ultimate goal to create a tailored bundle of security means for a secure and safe operation of the automated vehicles. Our findings may inspire future automotive security standards. As discussed in Sect. 5, all assessments are the results of an expert committee.

4.1 High-Level Risk Analysis (ZCR 1 - ZCR 4)

In ZCR 1, our expert team identified a total number of 19 assets in the SUC , i.e., functional components with a potential impact on security and safety. These include both in-vehicle assets (e.g., brainstem, radar) and external ones (e.g., drones, control room).

In ZCR 2, a high-level security risk analysis was performed for each asset $a_i$. For this, IEC 62443 -3-2 requires to assess the high-level likelihood $L^{\text {HL}}_{a_i}$ and the high-level impact $I^{\text {HL}}_{a_i}$ of a potential attack on $a_i$. Since it does not state how this is supposed to happen, we apply a multi-criteria decision making process. More precisely, we implement a Simple Additive Weighting (SAW) approach [19], where predefined evaluation criteria are scored and then ranked according to their importance. As demonstrated in the subsequent paragraphs, evaluation criteria for both likelihood and impact are represented as vectors $\textit{\textbf{L}}^{\text {HL}}_{a_i} = (L_1~L_2~...~L_n)^\intercal$ and $\textit{\textbf{I}}^{\text {HL}}_{a_i} = (I_1~I_2~...~I_m)^\intercal$, respectively. The ranking of each criterion is done with the normalized weight matrices $\textit{\textbf{W}}_\text {L}$ and $\textit{\textbf{W}}_\text {I}$, respectively. We compute the scores $L^{\text {HL}}_{a_i}$ and $I^{\text {HL}}_{a_i}$ by summing up the products of each score and its weight, i.e., $L^{\text {HL}}_{a_i} = \textit{\textbf{L}}^{\text {HL}}_{a_i} \cdot \textit{\textbf{W}}_\text {L}$, respectively $I^{\text {HL}}_{a_i} = \textit{\textbf{I}}^{\text {HL}}_{a_i} \cdot \textit{\textbf{W}}_\text {I}$, where $\cdot$ is the dot product. Due to normalization, a score of $L^{\text {HL}}_{a_i}$ =1 indicates the highest possible likelihood, while $I^{\text {HL}}_{a_i}$ =1 stands for the worst-case impact. The high-level risk $r^{\text {HL}}_{a_i} =(I^{\text {HL}}_{a_i}, L^{\text {HL}}_{a_i},)$ is mapped to a risk class, using the weighted normalized decision matrix in Table 3. We argue that such a scoring scheme is compliant with current automotive guidelines, as SAE J3061 recommends additive scoring for the assessment of impact factors.

Impact: We describe $\textit{\textbf{L}}^{\text {HL}}_{a_i} = (\text {PS}\,\text {FL}\,\text {OL})^\intercal$ as a vector of three impact criteria, where PS represents Passenger Safety, FL Financial Loss, and OL Operational Limitations [10]. Each criterion is independently scored by the experts, who use a set of exclusive parameters $(\mathcal {P})$ for this task. Based on its severity, each parameter is mapped on a distinct integer value according to the rules of SAW. That is, the least severe parameter is associated with 1, which is then incremented by 1 for subsequent parameters. For instance, we differentiate between $\mathcal {P}_{\text {PS}} = \{\textit{fatal},\textit{seriously injured}, \textit{slightly injured}, \textit{no injuries}\}$ for passenger safety. The parameter $p_0$ = no injuries is associated with 1, $p_1$ = slightly injured with 2, $p_2$ = seriously injured with 3, and $p_3$ = fatal with 4. Following SAW, we normalize these integer scores with $\widetilde{\text {p}_i} = \frac{\min \text {p}_j\forall p_j\in \mathcal {P}}{\text {p}_i}$ and then rank them with predefined weights. In our case, we use probabilistic weights, yielding 0.3 for both operational limitations and financial loss. As we consider passenger safety the most valuable criterion for an automotive system, we prioritize it with a weight of 0.4. We define $\mathcal {P}_{\text {OL}} = \{\textit{massive},\textit{high}, \textit{medium}, \textit{low}, \textit{none}\}$ to assess operational limitations of a potential attack. A massive limitation occurs if all traffic comes to an halt. This, for instance, may happen if the control room is taken over by an adversary. High limitations lead to traffic jams in a designated area, e.g., when sending fake traffic information. Medium constraints occur in case a vehicle can only operate at reduced speed, e.g., when hijacking or deceiving sensors. Finally, low limitations are the result of hijacking non-critical assets such as the chassis. Regarding the financial loss, we distinguish between four monetary classes as shown in Table 1. The so-called Value of a Statistical Life (VSL) [22] served as a reference value to determine these classes. The VSL indicates the mortality risk reduction benefit for the U.S. government. In 2016, the U.S. Department of Transportation indicated a VSL of $9.6 million. Since the VSL is not a universal constant, we assume $\text {VSL} = \$10\text {M}$ for simplicity. Table 1 shows the normalized and weighted scores for each impact parameter.

Table 1. Impact criteria with their normalized and weighted scores

During our impact assessments, we encountered the problem of transitive attack relations. Theoretically, every asset $a_i$ may be accountable for a worst-case attack if an adversary manipulates a safety-critical asset $a_j$ through $a_i$, $i\ne j$. As a consequence, all assets would receive the highest impact score, which eventually could result in over-engineering. Therefore, for the assessment of $a_i$, we focus solely on its functional description, without considering propagating side effects. This, however, does not mean that transitive attacks are left out from the risk analysis, since they are covered by conduits in later steps.

Likelihood: We describe the high-level likelihood ${\textit{\textbf{L}}^{\text {HL}}_{a_i} = (\text {IC}\,\mathrm {WC}\,\mathrm {P}\,\mathrm {EI}\,\mathrm {B}\,\text {TP})^\intercal }$ as a six dimensional Boolean vector. That is, we decide for each asset $a_i$, whether an Internet Connection (IC) can be established, a Wireless Communication (WC) is possible, $a_i$ is re-Programmable (P), $a_i$ has External Interfaces (EI) such as ODB2, USB, $a_i$ is directly connected to the in-vehicle Bus (B), and whether $a_i$ is produced by a Third Party (TP). For instance, $\textit{\textbf{L}}^{\text {HL}}_{a_i} = (1~0~1~0~1~0)^\intercal$ describes a re-programmable asset, which is connected to the in-vehicle bus and has the ability to establish an Internet connection. The order of the above criteria implicitly shows their ranking, i.e., to what extent they facilitate an attack. Similar to the high-level impact, we assign each criterion a distinct integer. As an Internet connection enables a potential attack the most, it receives the largest value of 6. For each subsequent criterion, we subtract 1 from the value, such that Third Party is eventually associated with 1. After normalization, we obtain $\textit{\textbf{W}}_\text {L} =(0.286~0.238~0.19~0.143~0.095~0.048)^\intercal$. Table 2 gives an overview of the weighted evaluation criteria for both impact and likelihood of a selected number of assets.

Table 2. High-level assessments (ZCR 2) and SUC partitioning (ZCR 3)

Table 3. Weighted normalized risk matrix with acceptance ranges

In ZCR 3, we partition the SUC into zones and conduits, using the results of the high-level security analysis. We obtain nine zones and conduits $\mathcal {ZC} = \{\textit{Z}_A , \textit{Z}_B ,..., \textit{Z}_F , \textit{C}_A, \textit{C}_B, \textit{C}_C \}$. Instead of putting all assets with the same high-level risk into one zone, we additionally differentiate between safety-critical and remote assets. For instance, $\textit{Z}_A$ consists of highly safety-critical in-vehicle assets (brainstem, cerebrum, sensors, router), while the (remote and safety-critical) control room resides in $\textit{Z}_F$ . In that way, we are able to better address specific safety and security demands. Although the dynamic modules are highly safety-critical, they are put into the dedicated zone $\textit{Z}_E$ , because they are additionally connected between each other over a fallback bus (cf., Fig. 1) and thus, have a significantly different attack surface. The fallback bus is treated in a dedicated conduit ($\textit{C}_C$) as well. $\textit{C}_A$ describes the in-vehicle Ethernet-based communication and $\textit{C}_B$ is the wireless network that connects external components such as the cloud and the control room. Table 2 shows the zones to which an asset belongs.

In ZCR 4, a detailed security analysis follows for a zone $\textit{Z}_i \in \mathcal {ZC}$, if there is an asset $a_i$ with a high-level risk $r^{\text {HL}}_{a_i} >r^{\text {tol,max}}_{\textit{Z}_i }$, where $r^{\text {tol,max}}_{}$ denotes the maximum tolerable risk. Since IEC 62443 -3-2 does not prescribe how to determine $r^{\text {tol,max}}_{}$, we define both a maximum tolerable impact $I^{\text {tol,max}}_{}$ and likelihood $L^{\text {tol,max}}_{}$. We exclude passenger harm and financial loss, but find low operational limitations tolerable, resulting in $I^{\text {tol,max}}_{}$ = $\textit{\textbf{I}}^{\text {HL}}_{a_i} \cdot \textit{\textbf{W}}_\text {I}$ = 0.1 + 0.085 + 0.075 = 0.26. Similarly, we define the tolerable likelihood. That is, we only consider it non-critical if an asset is manufactured by a third party and/or is connected to the vehicle bus, while all other criteria are excluded. These considerations lead to $L^{\text {tol,max}}_{a_i }$ = $\textit{\textbf{L}}^{\text {HL}}_{a_i} \cdot \textit{\textbf{W}}_\text {L}$ = $(0~0~0~0~1~1)^\intercal \cdot (0~0~0~0~0.095~0.048)^\intercal$ = $\mathbf {0.143}$. The grayed fields of the risk matrix in Table 3 correspond to the tolerable risk. Since no asset has a tolerable high-level risk, a detailed security analysis is required for all zones and conduits.

4.2 Detailed Risk Analysis (ZCR 5.1 - ZCR 5.10)

The objective of ZCR 5 is to move the unmitigated risk $r^{\text {u}}_{\textit{Z}_i }$ of potential threats in a zone $\textit{Z}_i \in \mathcal {ZC}$ below the maximum tolerable zone risk $r^{\text {tol,max}}_{\textit{Z}_i }$. This is achieved by applying compensating security countermeasures, which lower $r^{\text {u}}_{\textit{Z}_i }$ and thus, move the achieved security level closer to the target security level . A security level measures security demands arising from risks, whereas a risk results from a threat on a given asset in combination with at least one vulnerability. Thus, a crucial step for a reasonable risk analysis is the thorough determination of a threat and adversary model, taking into account known vulnerabilities and both the impact and likelihood of the identified threats.

Threat Modeling: A core prerequisite of a risk analysis is an exhaustive list of threats $\mathcal {T}$, since compensating security techniques may not protect the SUC from unidentified threats. During threat identification, we face two core problems: First, it remains impossible to prove completeness for $\mathcal {T}$, even though numerous identification techniques, such as CIA, STRIDE, and Threat Trees have been proposed [21]. Since threats are identified by the expert committee, we claim to have diverse views on the SUC and to obtain a reasonable number of threats. Additionally, we acknowledge the work by Petit and Shladover [17], who identified potential attack surfaces on road vehicles, that inspired our threat identification. Second, a collaborative threat identification process requires a common notion of a threat, when it comes to the granularity level. For instance, $\textit{t}_{1}$ = “The attacker triggers the vehicle brakes.” and $\textit{t}_{2}$ = “A network man-in-the-middle attacker injects forged braking commands.” are both candidates for threats with the same outcome. However, $\textit{t}_{1}$ is phrased on a purely functional level, while $\textit{t}_{2}$ already addresses one potential attack scenario. While the author of $\textit{t}_{1}$ may view the SUC at a coarser granularity level, he potentially misses attack vectors, as more than one vector can lead to the same outcome. In order to obtain threats with a comparable granularity level, we apply a three-round iterative threat identification process, as illustrated in Fig. 3. In a first round, we identify top-level threats on a purely functional level, having in mind what consequences are possible. After that, each top-level threat is split up into intermediate threats, taking into account how they can be realized, i.e., a precise attack vector. Since an attack vector can be used to realize more than one attack, an intermediate threat may appear multiple times. For instance, threats $\textit{t}_{\text {0-2}}$ and $\textit{t}_{\text {2-2}}$ in Table 4 are identical and are thus treated equally in succeeding steps.

Fig. 3.

Three-round iterative threat identification process

In the last round, each intermediate threat is associated with at least one zone or conduit $\textit{Z}_i \in \mathcal {ZC}$ and at least one foundational requirement $\textit{fr} \in \mathcal {FR}$, resulting in $\mathcal {T} _{\textit{Z}_i }^{\textit{fr}}\subseteq \mathcal {T}$. We formally model $\mathcal {T} _{\textit{Z}_i }^{\textit{fr}}= \{\textit{t} \in \mathcal {T}: \pi _1(frzc(\textit{t} ))=\textit{fr} ~\wedge ~\pi _2(frzc(\textit{t} ))=z\}$ with $frzc: \mathcal {T} \rightarrow (\mathcal {FR} ^{\le 7}\times {\mathcal {ZC}}^{\le 9})$ and $\pi$ the projection operation. In that way, we identified 63 intermediate threats.

Computation of Zone-Based Security Levels: Based on the identified threats, we derive a target security level $\mathrm{{SL}\text {-}\mathrm {T}}_{Z_{i}}$ for each zone $\textit{Z}_i \in \mathcal {ZC}$ (ZCR 5.6). The security model HEAVENS [2] combines a threat level with the impact level to derive a security level. In contrast, IEC 62443 -3-2 has no prescribed method to compute a security level. It only recommends to either represent $\mathrm{{SL}\text {-}\mathrm {T}}_{Z_{i}}$ as a scalar or as a vector. A scalar value minimizes the effort during verification, because the total number of possible states is kept low. In turn, a scalar may lead to over-engineering, since it does not allow a fine-grained requirement analysis. For instance, a zone requiring a confidentiality level of SL-4 would obtain $\mathrm{{SL}\text {-}\mathrm {T}}_{Z_{i}}$ as an overall security level, although precautions regarding other security goals may not be necessary. We express the security level of a zone $\textit{Z}_i \in \mathcal {ZC}$ as a seven dimensional vector, where each dimension takes into account the unmitigated risks $r^{\text {u}}_{\textit{t}_{i} } \in \mathcal {T} _{\textit{Z}_i }^{\textit{fr}}$ for a given $\textit{fr} \in \mathcal {FR}$. In other words, we assign a security level to each foundational requirement and thereby, express to what extent it is affected in $\textit{Z}_i$ . Precisely, we determine ${\text {SL}_{Z_{i}} = (\text {SL}_{Z_{i}}^\mathrm{IAC}\,\text {SL}_{Z_{i}}^\mathrm{UC}\,... \, \text {SL}_{Z_{i}}^\mathrm{RA})^\intercal }$ where ${\text {SL}_{Z_{i}}^\mathrm{fr} = \max (<r^{\text {u}}_{\textit{t}_{0} }, r^{\text {u}}_{\textit{t}_{1} }, ..., r^{\text {u}}_{\textit{t}_{n} } >),\,r^{\text {u}}_{\textit{t}_{i} } \in \mathcal {T} _{\textit{Z}_i }^{\textit{fr}},\,\textit{fr} \in \mathcal {FR}}$. As an example, for the achieved security level of zone $\textit{Z}_A$ , we obtain ${\mathrm{{SL}\text {-}\mathrm {A}}_{Z{A}}=(\mathrm {SL}\text {-}{2}\,\mathrm {SL}\text {-}{3}}$ $\mathrm{{SL}\text {-}{4}\,\mathrm {SL}\text {-}{3}\,\mathrm {SL}\text {-}{2}\,\mathrm {SL}\text {-}{4}\,\mathrm {SL}\text {-}{3})^\intercal }$.

Table 4. Mapping of intermediate threats on zones and foundational requirements

Similar to the high-level analysis, we express the unmitigated risk $r^{\text {u}}_{\textit{t}_{i} }$ of a threat $\textit{t}_{i}$ as a combination of likelihood (ZCR 5.4) and impact (ZCR 5.3). We suggest a cascading parameter approach, that evaluates likelihood and impact depending on further sizes like vulnerabilities and attacker’s capabilities. This means, any change in one of those parameters immediately propagates to $r^{\text {u}}_{\textit{t}_{i} }$. Precisely, the likelihood for a successful threat $\textit{t}_{i}$ is determined by the required capabilities for its implementation and by exploitable vulnerabilities (ZCR 5.2). We acknowledge, that the idea of incorporating the attacker’s capabilities into the threat likelihood has been already proposed in [16]. Similar to the HEAVENS project [2], we model the attacker’s capabilities $\mathcal {AC}$ as three factors, experience $\mathcal {E}$, knowledge $\mathcal {K}$, and resources $\mathcal {R}$, i.e., $\mathcal {AC} = \mathcal {E}\times \mathcal {K}\times \mathcal {R}$. We score each of them independently for all threats $\textit{t}_{i}$ . Afterwards, we assign each identified vulnerability a value from $\mathcal {V} = \{\textit{severe}, \textit{medium}, \textit{negligible}\}$. A severe vulnerability, for instance, may be a broken cryptographic protocol or a zero-day exploit, while a medium one requires user privileges. A negligible vulnerability is mostly theoretical, such as quantum attacks. Regarding the impact of $\textit{t}_{i}$ , we use the same criteria as we did for the high-level analysis, i.e., by ranking a threat according Personal Safety, Operational Limitations, and Financial Loss. Eventually, we receive a tuple for unmitigated risk $r^{\text {u}}_{\textit{t}_{i} }$ of every threat $\textit{t}_{i} \in \mathcal {T}$ as illustrated in Table 4, allowing us to compute a target security level for all zones.

4.3 Threat Mitigation and Results

After having computed a security level ${\mathrm{{SL}\text {-}\mathrm{A}}_{Z{i}}}$ for each zone $\textit{Z}_i \in \mathcal {ZC}$, we iteratively identify and apply compensating countermeasures, such that the unmitigated risk $r^{\text {u}}_{\textit{t}_{i} }$ of threat $\textit{t}_{i} \in \mathcal {T} _{\textit{Z}_i }^{\textit{fr}}, \forall \textit{fr} \in \mathcal {FR}$ shrinks below the tolerable risk $r^{\text {tol,max}}_{\textit{Z}_i }$. For this purpose, we constantly compare $r^{\text {u}}_{\textit{t}_{i} } \le r^{\text {tol,max}}_{\textit{Z}_i }$ by reassessing all parameters, that impact likelihood and impact (ZCR 5.7-5.10). For instance, a compensating countermeasure for the foundational requirement System Integrity in zone $\textit{Z}_A$ is data authentication. Assuming the verifiable authenticity of in-vehicle traffic, the required capabilities to inject fake braking commands without being recognized (c.f. threat $\textit{t}_{\text {0-0}}$ in Table 4) rise significantly, since an attacker would need to circumvent cryptographic protection. This, in turn, makes $\textit{t}_{\text {0-0}}$ less likely and consequently, $r^{\text {u}}_{\textit{t}_{\text {0-0}} }$ decreases. Beforehand, the expert committee defines a tolerable risk $r^{\text {tol,max}}_{\textit{Z}_i {,\textit{fr}}}$ for each zone $\textit{Z}_i \in \mathcal {ZC}$ and foundational requirement $\textit{fr} \in \mathcal {FR}$. Precisely, they determine the tuple $r^{\text {tol,max}}_{\textit{Z}_i {,\textit{fr}}} = (I^{\text {tol,max}}_{\textit{Z}_i {,\textit{fr}}}, L^{\text {tol,max}}_{\textit{Z}_i {,\textit{fr}}})$ and compare it with all $r^{\text {u}}_{\textit{t}_{i} }$, $\textit{t}_{i} \in \mathcal {T} _{\textit{Z}_i }^{\textit{fr}}$. For instance, the maximum tolerable likelihood of the foundational requirement Use Control for zone $\textit{Z}_F$ (control room) is set to extremely low, because only individuals with assigned privileges are allowed to remotely control a vehicle. According to Table 3, this leads to $L^{\text {tol,max}}_{\textit{C}_F {,\text {UC}}} = 0.191$. As the high-level analysis in Sect. 4.1 has revealed, the malicious operation of the control room can lead to life-threatening situations. Therefore, we set the maximum tolerable impact $I^{\text {tol,max}}_{\textit{Z}_F {,\text {UC}}}$ to extremely low, i.e., $I^{\text {tol,max}}_{\textit{Z}_F {,\text {UC}}} = 0.26$. As a result, we obtain $r^{\text {tol,max}}_{\textit{Z}_F {,\text {UC}}} = (I^{\text {tol,max}}_{\textit{Z}_F {,\text {UC}}}, L^{\text {tol,max}}_{\textit{Z}_F {,\text {UC}}}) = (0.26, 0.191)$.

Depending on the security level, IEC 62443 -3-3 provides countermeasures for each foundational requirement. However, we argue, that most of them are not directly applicable to our SUC, since they have not been designed for automotive challenges. That is, real-time behavior, resource-constrained control units, and a high reliability. For example, a security level SL-2 of the foundational requirement Identification and Authentification Control demands for public key infrastructure certificates. This, however, is hardly applicable to in-vehicle communication, because public key certificates lead to unacceptable overhead, as they come along with long certification chains and demanding cryptographic operations. As a consequence, we looked for alternative, more lightweight, and resource-saving solutions. In particular, the work of El-Rewini et al. [9] inspired us, as they provide an extensive survey on automotive security frameworks. As a result, we obtain a detailed list of security mitigation techniques for each zone, that protect against the 63 identified threats. They can be summarized as follows:

Authenticated In-Vehicle Communication: A core prerequisite of safety-critical in-vehicle conduits and zones ($\textit{Z}_A$ , $\textit{Z}_E$ , $\textit{C}_A$, $\textit{C}_B$) is the ability to verify the authenticity of data streams. In this way, the injection of fake commands becomes difficult. A promising alternative technique are implicit certificates in combination with distinct physical memory characteristics [18], avoiding potentially long and resource-consuming certification chains. Related work [9] illustrates additional solutions for the wide variety of in-vehicle communication protocols.

Integrity of In-Vehicle Control Units: Since both the SUC and contemporary road vehicles possess an increasingly large number of external interfaces, and the ability to remotely update control units, adversaries, residing inside the ECUs, must be prevented. In our case, we propose to treat the brainstem as a trust anchor, that verifies the integrity of all control units before the vehicle start. For this purpose, we suggest Remote Attestation (RA), a technique, allowing to prove the integrity of a device to a third party. Kohnhäuser et al. [13] show how to use RA in the automotive domain.

Malicious Behavior Detection: During the security analysis, high-risk threats on safety-critical assets were associated with the foundational requirement Timely Response to Events (TRE). Specifically, adversaries connecting to the in-vehicle bus may be able to flood the in-vehicle network (DoS attack) and thus to cause failures. We find an anomaly-based intrusion detection system [8] for safety-critical in-vehicle traffic (i.e., conduits $\textit{C}_A$, $\textit{C}_B$) a suitable compensating countermeasure. Also, inter-vehicle communication (i.e., zone $\textit{C}_C$) is prone to DoS attacks, for which, however, many mitigation frameworks have been presented [23].

Data Separation: The initial design of the SUC provides a single in-vehicle bus for all data flows. Consequently, user input and potentially safety-critical data streams are mixed, which may lead to the delayed transmission of safety-critical demands. As our risk analysis revealed threats affecting the foundational requirement Restricted Data Flow for in-vehicle traffic, the presented vehicular architecture requires means to separate data flows. Both physical and virtual data separation achieve this goal. For our SUC, we configure VLAN priority levels for the Ethernet-based in-vehicle network and use the arbitration logic of the CAN bus. The FlexRay network inherently realizes a TDMA-based schedule, allowing to reserve dedicated time slots for critical data.

Access Control: An integral part of the SUC is the control room, that enables human remote control in case of emergency situations. In order to distinguish between legitimate and illegitimate remote control, an access control system is necessary at the vehicle’s edge. This is highlighted by the risk analysis, that exposes the importance of user authentication, in particular when it comes to the communication between the vehicle and its exterior. Since the router is the only gateway to the external world, access control mechanisms have to be implemented in the corresponding zone ($\textit{Z}_A$ ). This includes a strict deny-by-default policy and mutual identity checks.

5 Discussion

Our analysis particularly highlights the demand for system integrity and timely responses, since a significant number of threats are mapped on the corresponding foundational requirements. Both software and communication integrity are key factors for a safe driving state. This evidence coincides with related work [17], that considers the injection of fake messages as one of the severest attacks on modern vehicles.

Although our analysis yields effective means to protect against the identified threats, we lack techniques to handle actual security incidents during vehicle operation. We need means to assess them in real-time and to adopt appropriate (safety) measures. We plan to address this problem in future work. Regarding our security requirement analysis, we want to stress the following points:

Quality of Assessments: For our consensus-based risk analysis, we presented a scoring scheme, using Simple Additive Weighting (SAW) as a decision support system. In order to obtain reasonable and consistent assessments, and to ensure a broad insight into the SUC, we engaged an expert committee, consisting of eight computer scientists and mathematicians from the Securing Engineering Lab¹ of the Technische Univeristät Darmstadt. As a first step, the experts have been thoroughly introduced to the novel vehicular architecture in a Q&A session. Afterwards, we established the presented set of evaluation criteria based on related work and empirical values. As both the threat identification process and all assessments have been jointly accomplished by the expert committee, we argue to properly address subjectivity and vagueness. However, we admit, that a higher committee heterogeneity in terms of educational background may yield even better results. Regarding the proposed scoring scheme, we currently assign a fixed probabilistic weight to each evaluation criterion. We consider the Fuzzy Analytic Hierarchy Process (FAHP) [7] an effective alternative to determine preference weight, but leave this for future work.

Safety and Security Co-Engineering: We pursued the question of what changes are necessary for a safety-aware security risk analysis in the automotive domain. As safety and security demands may contradict, the possibility of prioritization is crucial. We find the mapping of risks onto zones and foundational requirements a promising technique, because it allows fine-grained solutions for large-scale systems. The partition of the SUC into zones and conduits should take safety criteria into consideration. In addition, we suggest the following adaptions:

• So far, the seven foundational requirements are purely security-related. We suggest extending them with safety requirements such as reliability, redundancy, and real-time behavior. By doing so, the unmitigated risk of a threat or of a hazardous situation would take both safety and security dimensions into account. The presented vector-driven approach allows prioritization, by pointing out which foundational requirement is affected most by a set of threats. Appropriate countermeasures can be deduced in that way.

• The countermeasures listed in IEC 62443 -3-3 need to be adjusted for the automotive domain. Instead of user-oriented, potentially computationally heavy systems (e.g., PKI, multi-factor authentication, ...), lightweight and resource-saving techniques (e.g., implicit certification, hardware-based security, ...) are worthwhile. There has been extensive work on automotive security with numerous frameworks, covering many automotive challenges [8, 9, 14, 23], that should be included in a future standard.

• A common set of evaluation criteria and a consistent scoring scheme for automotive systems is desirable, in order to make analysis results comparable. We presented a scheme, that incorporates both security and safety criteria for risk assessment.

5.1 Comparison to ISO/SAE DIS 21434

The high-level risk analysis and the subsequent partition into zones and conduits allow for efficient identification of relevant assets. Besides, the analysis process becomes more scalable, since uncritical assets are excluded from further steps. The use of foundational requirements as a reference point enables the clear establishment of mitigation techniques.

While the detailed risk analysis of IEC 62443 -3-2 begins with the identification of threats, the novel ISO/SAE DIS 21434 starts from potential damage scenarios and traces them back to attack paths. More precisely, the risk assessment methods are comprised of seven steps (I-VII). Initially, damage scenarios are identified, which may occur through compromised assets (I). A damage scenario is triggered by a set of adverse actions, a so-called threat scenario, which are enumerated in (II). The impact of each damage scenario is assessed according to four core categories of consequences, Safety, Financial, Operational, and Privacy (III). Subsequently, each threat scenario is decomposed into attack paths in a top-down or bottom-up approach (IV). The feasibility of each path is assessed according to a pre-defined scale (V), resulting in a risk value (VI) for each threat scenario, which also incorporates the impact of the damage scenario. Finally, risk reduction methods shall be realized (VII). In case the risk for a threat scenario has to be reduced, a Cybersecurity Assurance Level (CAL) reveals requirements for the affected item.

At first glance, the risk analysis process of ISO/SAE DIS 21434 and IEC 62443 have little in common. On closer inspection, however, both standards do share similar concepts. The CAL is similar to the SL-T value, which is only determined if the risk is too large. Instead of our iterative threat identification process and conduits, attack paths cover propagating effects of adverse actions. While the idea of decomposing threat scenarios into attack paths is the most promising feature of ISO/SAE 21434, our work reveals requirements that are not yet met by ISO/SAE 21434. Unlike IEC 62443, the novel automotive standard prescribes assessment criteria and parameters. However, it insists on neither underlying cybersecurity requirements nor mitigation techniques, contrary to IEC 62443. For the sake of a common minimum security perception, suggestions of countermeasures for specific CALs would be helpful, in particular, because road vehicles are generally subjected to the same safety and legal requirements. Also, consistent scoring schemes and a dedicated process to identify relevant critical assets of a potentially complex architecture would be desirable.

6 Conclusion

In this work, we presented a consensus-based implementation of the generic IEC 62443 cybersecurity standard for a novel vehicular architecture. In particular, we identified risk evaluation criteria and developed an additive scoring scheme to assess automotive risks. Furthermore, we introduced a hierarchical threat model for a collaborative threat identification process. We used a cascading parameter approach to express risks as zone-based vectors, yielding fine-grained security levels, that express security requirements. We conclude that especially data and software integrity, the separation of safety-critical commands, and the ability to detect anomalies are crucial for automated vehicles. Based on our lessons learned, we find as essential for a future standard the systematic partition of a potentially complex vehicular architecture into relevant assets, the computation of security levels with regard to cybersecurity reference goals, the treatment of transitive adverse actions, and the suggestion of mitigation techniques. We also make suggestions on how to incorporate safety requirements into a future standard. In particular, a safety-aware automotive security standard should use a redefined set of foundational requirements, including safety objectives such as reliability, redundancy, and real-time behavior. Although IEC 62443 has been originally designed for IACS, we promote its applicability to the automotive domain in combination with the adaptions suggested in this work.