Keywords

1 Introduction

Modern vehicles are often connected to the Internet, and they contain more than 100 Electronic Control Units (ECUs) that control brakes, airbags, parts of the engine, and so on. This combination of ECUs, sensors, and network buses creates a computerized system. Vehicles seem to be vulnerable to exploits in several ways, and a malicious actor getting access to vital ECUs can have dire safety consequences. Vehicle vulnerabilities have been reported numerous times, e.g. in the National Vulnerability Database (NVD)Footnote 1. One famous example of exploiting vehicle vulnerabilities is when two ethical hackers acquired remote control of a 2014 Jeep CherokeeFootnote 2.

To improve the security of Internet-facing systems e.g. vehicles, one approach is to use methods for modeling and analysis. One can with this understand what parts of the system are the most weak ones, and how they can be secured. Threat modeling is one such way of working with proactive cyber security and security by design [34], moreover, the most recent trend is to combine it with attack simulations to provide quantitative security measurements [13, 33], e.g. Time-To-Compromise (TTC) [7, 10]. This fairly new approach has been applied successfully in domains like energy [30]. This paper serves as a proof of concept of the approach on connected vehicles.

A threat modeling and risk management tool called securiCADFootnote 3 is used in this work, where users can model e.g. home Local Area Networks (LANs), large corporate networks, and SCADA systems. In securiCAD, different defense strategies are assigned to different assets, and the built-in simulation engine is used to show the probabilities of different attacks succeeding. Some attack types that can be simulated include Denial of Service (DoS), device compromise, and replay attacks [6]. Furthermore, our literature review and practical tests using securiCAD show that threat modeling and attack simulations for vehicles is promising, while some aspects need to be further considered in future research for it be more efficient and successful.

This paper is an extension of the paper presented at the 5th International Conference on Information Systems Security and Privacy in Prague, Czech Republic [33]. The extension includes: 1) related work on vehicle privacy is added in Sect. 2; 2) more detailed vehicle threat modeling steps and one more vehicle model is added in Sect. 3; 3) further described simulation results for the vehicle models in Sect. 4; 4) further discussed proof of concept in vehicle threat modeling and attack simulations in Sect. 5, and more detailed conclusions in Sect. 6.

2 Related Work

2.1 Threat Modeling and Attack Simulations

Threat modeling is proposed as a solution for secure application development and system security evaluations, and it aims to be more proactive and make it more difficult for attackers to accomplish their malicious intents. The work by Shostack [26] and the Microsoft Threat Modeling toolFootnote 4 are commonly used in this area. In [31], the authors studied the usefulness of the Microsoft Threat Modeling tool and showed that the tool improved their work on threat modeling. However, it is mainly used for designing secure software applications, and often not for considering the system from a holistic point of view. In [27], SPARTA was proposed to combine Data Flow Diagram (DFD)-based threat modeling with security and privacy solutions. Risk analysis simulations based on concrete element value estimates, countermeasure strengths, and attacker types provide a prioritized list of threats that should be elicited.

Another way of working with threat modeling is to use attack trees or attack graphs [14, 23, 25]. Attack graphs are widely accepted and used, while there are plenty of known problems. For instance, in [19] the authors stated that previous work on attack graphs has not provided an account of the scalability of the graph generating process, and there is often a lack of logical formalism in the representation of attack graphs, which results in the attack graph being difficult to use and understand by human beings. As a response to these known problems in threat modeling and attack simulations, some approaches have been proposed. For example, pwnPr3d [10] and MAL (the Meta Attack Language) [7] were proposed focusing on providing probabilistic security measures.

2.2 Vehicle Security and Privacy

Previously, vehicle Original Equipment Manufacturers (OEMs) did not consider cyber attacks that much, since an attack was only possible if an attacker had physical access to the vehicle. However, as modern vehicles have multiple wireless connections to both outside networks and devices (e.g. Bluetooth, Internet), they are vulnerable to cyber attacksFootnote 5. Some vehicle vulnerabilities are recorded in NVD, and each of them is associated with a CVEFootnote 6 number and CVSS scoreFootnote 7 for analyzing its severity.

To help improving the security of modern vehicles, [32] conducted an empirical study to identify common security vulnerabilities discovered in vehicles. The vulnerability information was gathered for 60 vehicle OEMs and common vehicle components from NVD. The analysis results showed that about 50% of the vulnerabilities fall into the medium severity category, and the three most common software weaknesses reported are protection mechanism failure, buffer errors, and information disclosure.

By using threat modeling for vehicles, the process proposed by [20] starts with defining automotive security use cases, then identifying assets and threats by using the STRIDE method, and finally rating risks and evaluating the threat level and impact level against the found threats. Besides, for assessing the risks of exploiting vehicular on-board networks, [24] automatically generated and analyzed attack graphs, which could aid vehicle development by automatically re-checking the architecture for attack combinations. In [12] the authors adapted two threat modeling methods - TARA and STRIDE from the computer industry to fit the needs of the automotive industry. Also, in [16] an approach to threat modeling to better fit the automotive systems was proposed, a proof of concept implementation of their approach was implemented but without further validation.

Possible security mechanisms to secure vehicles internal communications were addressed in the Holisec projectFootnote 8, including message authentication codes (MAC) for traffic integrity, firewalls both for external traffic and for internal traffic implemented in gateway ECUs, use of Intrusion Detection Systems (IDSs) to detect unusual activities on the networks, and certificates for identification of various devices. Security mechanisms were also addressed in [3] to mitigate the threats on assets, which include access control, packet filter firewall, message authentication, etc. Considering the privacy issues of vehicular data, the work by [35] presented a privacy specification for vehicles, which used MAL [7] to assess the security of connected vehicles with a special focus on the privacy aspect.

3 Vehicle Threat Modeling

According to a survey conducted by Miller and Valasek [17], the two most hackable vehicle models are the 2014 Jeep Cherokee and 2015 Cadillac Escalade. Therefore, these two models are used for our proof of concept work.

The threat modeling is done using securiCAD, a tool that can automatically generate probabilistic attack graphs from a given system specification, and serves as an inference engine that produces predictive security analysis results. The threat models can be built by using drag-and-drop functionality with pre-defined assets and associations. Each asset has certain security properties and attack types associated with it. For example, a Network asset has e.g. DoS, ARP cache poisoning, and compromise attacks listed.

3.1 Creating Threat Models

For modeling and analyzing vehicles, the first thing is to understand the internal network of a vehicle, and the main assets in it. The main assets in a connected vehicle include ECU, SoftwareProduct, Dataflow, Protocol, and Network. The most common Protocols in vehicle communication include CAN, LIN (Local Interconnect Network), MOST (Media Oriented Systems Transport), and FlexRay.

A Host is described as a kernel of an operating system in securiCAD, and is used to represent PCs or servers, thus here it is used to represent ECUs. In order to model the associations between the assets, a Service and a Client can be connected to each ECU, while an ECU does not require both of them, e.g. an ECU will be connected to a Client only if it is required to send data to other ECUs.

The software used on these ECUs is either made entirely by the OEMs, or applies existing architecture standards to define the functions of each ECU, e.g., AUTOSARFootnote 9, which is a standardized software framework for vehicles and offers a multi-level security architecture among others. Many OEMs and third-party developers are members of AUTOSAR today and the number of members is still growing [5, 11]. Therefore, a SoftwareProduct that represents AUTOSAR is connected to each ECU, as well as its Services and Clients. Moreover, Dataflow is connected to each Network, and is also connected to Services and Clients of ECUs to represent the communication between them. The communication here denotes the access that Service and Client have to the commands and function calls in the kernel. The following two examples show how we created the threat models and the reasoning behind it.

Fig. 1.
figure 1

2014 Jeep Cherokee threat modeling.

Full size image

2014 Jeep Cherokee Model. The 2014 Jeep Cherokee threat model is created according to its network topology [17]. As is shown in Fig. 1(a), the vehicle network topology contains two CAN Networks (CAN-C, CAN-IHS) and one LIN Network. CAN-C is a Low Speed CAN Network that connects ECUs e.g. steering controls, brakes, tire pressure monitoring system (TPMS) that are considered safety-critical. CAN-IHS is an Interior High Speed CAN Network that connects the comfort systems e.g. radio, climate controls. The LIN Network connects ECUs e.g. rear view mirror, and lamps. Also, a RADIO box is connected to these two CAN Networks.

A Body Control Module (BCM) connects both of the two CAN Networks and the LIN Network. It ensures the information exchange in spite of different of data transmission rates in each network. Also, we connect it to Dataflow (see in Fig. 1(b)) as it controls and sends commands to other ECUs, which acts as a gateway among different networks and can be compared to an Ethernet switch.

Besides, the dataflow viewpoint in Fig. 1(b) shows that the network Protocols are connected to their corresponding Dataflows, which regulate the communication between ECUs within the Networks, and also reflect that all messages from ECUs connected to the CAN Network are broadcast.

Furthermore, an Attacker is added to the Internet Network that connects with RADIO to make the threat model complete, with connection type “Compromise” (see in Fig. 1(a)), which indicates the entry point of this attack.

2015 Cadillac Escalade Model. Similarly, the 2015 Cadillac Escalade threat model is created according to its topology [17]. As is shown in Fig. 2, the network topology consists of three CAN Networks (i.e. PT-CAN, Low Speed GMLAN, and High Speed GMLAN), one LIN Network, and one MOST Network, where PT-CAN is the power train CAN protocol, and GMLAN is a CAN protocol for lower layer services.

Fig. 2.
figure 2

2015 Cadillac Escalade threat modeling.

Full size image

The Low Speed CAN Network connects ECUs e.g. keyless entry control module, and telematics communication interface module (TCIM), etc. The High Speed CAN Network connects ECUs e.g. engine control module, braking system, steering control, etc.

Also, the Clients of both BCM and TCIM are connected to the low and high speed CAN Dataflows (not shown in the figure), because BCM includes ECUs e.g. steering control, pedals, and meters that need to send commands. Besides, we connect the Service of TCIM to both the Low Speed CAN Network and Dataflow (not shown in the figure), as TCIM contains a cellular connection required by the keyless entry control ECU within the Low Speed CAN Network.

Furthermore, we add an Attacker to the keyless entry control ECU, to simulate a scene where an attacker performs a keyless entry attack to gain unauthorized access and manipulate the vehicle. Note that an Attacker can be connected to other assets, modeling different entry points.

3.2 Security Settings

Based on the threat models we created, we assign security settings for each asset. This also includes the consequence for each attack, where the value ranges from 0 to 10 (with 10 being the most severe). Using the system model with security settings and the consequences of attacks securiCAD calculate quantitative measurements, e.g. risks according to the following equation:

$$\begin{aligned} Risk = Consequence \times Probability\; \end{aligned}$$
(1)
Table 1. ECU security settings.
Full size table

As both the two vehicle models apply a SoftwareProduct called AUTOSAR, which also defines the function of the ECUs. Thus, we set the security settings for ECU and SoftwareProduct (i.e. AUTOSAR) of both the two threat models according to AUTOSAR classic documentationFootnote 10, and the reasons behind can be seen in Table 1 and Table 2, respectively.

Table 2. SoftwareProduct security settings.
Full size table

A Network has countermeasures including DNSSec, PortSecurity andStatic ARP Tables that are TCP/IP related. For the two CAN Networks, DNSSec settings are disabled. Both Services and Clients connected to ECUs have a countermeasure named Patched that is enabled.

Besides, a Protocol is connected to Dataflow, which gives options to choose different security implementations to apply on the communication over the networks, and the security measurements available are Authenticated, Encrypted and Nonce, where Authenticated is disabled from the security settings of CAN network ProtocolFootnote 11.

2014 Jeep Cherokee Model. Here we assign the consequence for each attack under this model, and their underlying reasons. For example,

  • Consequences of compromising Engine control, Transmission and Brake control ECUs are set to 10, because these ECUs are safety-critical, and the compromises of them could lead to fatal road accidents.

  • Consequence of compromising RADIO is set to 3, as it is not so safety-critical.

  • Consequence of a DoS attack on CAN-C Network is set to 9, because a DoS attack can shut down the access to ECUs of the network, and lead to fatal road accidents.

  • Consequence of a replay attack on CAN-C Network is set to 10, which represents the actual attack [18].

2015 Cadillac Escalade Model. Similarly, we assign consequences for attacks in the threat model. Since there is no public information showing the exact consequence value we instead provide arguments for our decisions. For example,

  • Consequences of compromising Engine control, Braking system and Steering control ECUs are set to 10.

  • Consequence of compromising TCIM is set to 3, as it is not so safety-critical.

  • Consequence of a DoS attack on Low Speed CAN Network is set to 9, because a DoS attack can shut down the access to ECUs of the network, and lead to fatal road accidents.

  • Consequence of compromising the keyless entry control ECU is set to 8, as it (in itself) should not lead to fatal road accidents compared to the former one. To prevent an attacker accessing the vehicle through compromising the keyless entry control ECU and then steal it, we can add AccessControl to the ECU, and see how it can change the attack path.

4 Vehicle Attack Simulations

After assigning the security settings to the created threat models, we are able to run the attack simulations. The simulation results include risk matrix, attack path, and Time to Compromise (TTC) graph, where the TTC graph presents the probability distribution based on a certain attack path of the expected time for an attacker to compromise an asset.

4.1 Risk Matrix

With the threat model and the security settings of the 2014 Jeep Cherokee Model, when we disable the HostFirewall of the RADIO, and the resulting risk matrix (shown in Fig. 3(a)) according to Equation (1) shows that the vehicle is not under critical risks. However, when the HostFirewall is disabled, the replay attack on CAN-C Dataflow is ranked Critical (shown in Fig. 3(b)), which reflects that the firewall is quite important to secure the network.

Fig. 3.
figure 3

Risk matrix from simulations performed on the 2014 Jeep Cherokee model. [33].

Full size image

Besides, if we change the security setting for RADIO from Disabled (see in Table 1) to Enabled, all possible attacks are ranked below Medium according to the simulation results.

4.2 Attack Path

The simulation results also show the attack path of an attack, which represent the possible composition of vulnerabilities used by an attacker. For the 2014 Jeep Cherokee Model, Fig. 4 indicates the attack path of the replay attack on CAN-C Network, where the unknown service indicates the D-bus service accessed in an actual attack [18], and they discovered that D-bus was running as root, which enabled them to get access to the vehicle remotely. Also, the green circle shows the countermeasures that could be implemented in this vehicle. We can see that most of the attack steps are related to RADIO, and we infer that the Hardened setting of RADIO is very important as it can be (is) the entry point for an attack. Besides, the width of the lines between attack (defense) steps indicates the likelihood of the attack path.

Fig. 4.
figure 4

Attack path of the Jeep replay attack. [33].

Full size image
Fig. 5.
figure 5

Attack path of a keyless entry attack on Cadillac Escalade.

Full size image

Similarly, with the threat model and the security settings, we can get the simulation results for the 2015 Cadillac Escalade Model. For example, the attack path of a keyless entry attack is shown in Fig. 5(a). If we add an AccessControl to the keyless entry control ECU it will be much more difficult for the attacker to compromise the keyless entry control ECU and steal the vehicle, the attack path for this can be seen in Fig. 5(b).

4.3 Time-To-Compromise (TTC)

TTC is used as a measurement of the effort for an attacker to conduct a successful attack. We assume that the attacker will take the shortest path, i.e. the least time-consuming way to the end node. The TTC of the replay attack on CAN-C Dataflow can be seen in Fig. 6, which indicates how many days it takes to reach a certain probability of successfully compromising an asset. In this case, TTC for the replay attack to compromise the Dataflow is 20 days with a 50% probability, or is 10 days with a probability above 40%.

Fig. 6.
figure 6

TTC of a Jeep replay attack. [33].

Full size image

Overall, the attack simulation results show that the modeled vehicles are not fully secure (as we also know from the real attacks we mimic). According to the risk matrix, we can infer the risk level of the vehicle. Also, we can change the security settings to see how it could influence the overall security level (e.g. Fig. 3). According to the attack path, we know what other countermeasures that can be implemented. At last, TTC provides a measurement of how secure the vehicle is in terms of attack resilience, which provides us a quantitative way of comparing vehicle architecture designs.

5 Discussion

In this paper, holistic threat modeling and quantitative attack simulations are conducted for the two most hackable vehicle models [17]-2014 Jeep Cherokee and 2015 Cadillac Escalade.

The simulation results works as a proof of concept of the approach. As creating large attack graphs for complicate systems manually is time-consuming and error-prone, this approach allows holistic identification and ranking of security-related threats that are likely to affect the vehicles. Also, the set of attack types and associated countermeasures (defenses) related to each asset in a vehicle could be explored and validated further. There are plenty of attacks known to the public for e.g. web applications and Windows-based systems, however, most of them might not be relevant for vehicles [4, 28]. On the other hand, there might be certain attacks only related to vehicle systems. When it comes to countermeasures, a vehicle has certain limitations regarding performance, cost, and functionality that might not appear in other larger systems.

It appears that having a firewall is quite important to secure the vehicle [21]. Also, other assets e.g. the keyless entry control ECU can be entry points of attackers and therefore access control could be implemented as a countermeasure [1, 2]. Therefore, designing network architectures is also important to vehicle security [9, 29].

Furthermore, in order for the approach to be more efficient and for simulation results to be more useful, a metamodel that describes the fundamental assets and their associations of systems [8, 15, 22] needs to be tailored to fit the internal architecture of vehicles. Also, vehicle-specific statistical studies relating attacks and defenses quantitatively are still needed. This can be realized through hacking exercises or expert studies. Another important step is to validate and test the approach with case studies by modeling vehicles and iteratively enhancing the approach, similar work has been done in the energy domain [30]. Quantitative measures of security (e.g. TTC) require quantitative inputs in order to provide reasonable and useful output. Although it has been done for other system types, vehicle-specific statistical studies relating attacks and defenses are still need to be done.

6 Conclusion

This paper presents a proof of concept of an approach for connected vehicles using threat modeling coupled with attack simulations. Two vehicle models and publicly known attacks were modeled with a tool called securiCAD, showing that the approach is useful in its current state and allows holistic identification and ranking of vehicle security flaws, whereas a more vehicle-specific metamodel would be useful to describe the fundamental assets and associations of vehicles. Future work also includes studying vehicle-specific vulnerabilities, weaknesses, and countermeasures to provide more accurate attack simulation results.