Attack Analysis Methodologies Attack Analysis Methodologies in the Automotive Industry Master’s thesis in Computer Systems and Networks Seyed Reza Esmaeili & Afshin Soltani Esterabadi Department of Computer Science and Engineering CHALMERS UNIVERSITY OF TECHNOLOGY Gothenburg, Sweden 2019 Master’s thesis 2019 Attack Analysis Methodologies Attack Analysis Methodologies in the Automotive Industry Seyed Reza Esmaeili Afshin Soltani Esterabadi Department of Computer Science and Engineering Division of Computer Systems and Networks Chalmers University of Technology Gothenburg, Sweden 2019 Attack Analysis Methodologies Attack Analysis Methodologies in the Automotive Industry SEYED REZA ESMAEILI & AFSHIN SOLTANI ESTERABADI © SEYED REZA ESMAEILI, AFSHIN SOLTANI ESTERABADI, 2019. Supervisor: Erland Jonsson, Department of Computer Science and Engineering Advisors: Christian Sandberg & Manne Engelke, Volvo Group Trucks Technology Examiner: Tomas Olovsson, Department of Computer Science and Engineering Master’s Thesis 2019 Department of Computer Science and Engineering Division of Computer Systems and Networks Chalmers University of Technology SE-412 96 Gothenburg Telephone +46 31 772 1000 Cover: Volvo FH 4x2 truck. © Volvo Truck Corporation. All rights reserved. Typeset in LATEX Gothenburg, Sweden 2019 iv Attack Analysis Methodologies Attack Analysis Methodologies in the Automotive Industry SEYED REZA ESMAEILI & AFSHIN SOLTANI ESTERABADI Department of Computer Science and Engineering Chalmers University of Technology Abstract In recent years, we have witnessed that technology has advanced dramatically. While new, hi-tech, automated devices entered our lives, a tendency of moving from the disjointed nature of objects to a more interconnected world has emerged. Although such need of interconnection was originated in the IT industry and with the Internet of Things (IoT), automotive industry was also affected by such a trend. Connected, electric, highly-automated and autonomous vehicles are making their way into our lives. As a result of this paradigm shift, new security challenges are introduced in the automotive industry. Vehicles are comprised of tens or sometimes a hundred of computers, also known as Electronic Control Units (ECUs) that need to communicate and be interconnected in order for the vehicle to function properly. Protecting vehicles from potential threats and attacks that may compromise the security and consequently the safety of both the vehicle and the passenger is of great importance. Hence, a comprehen- sible attack analysis methodology is needed to model the possible attacks in vehicles. Attack analysis is part of the risk assessment process. To have an accurate risk analysis, two factors are needed: first, the impact of an attack vector, which is not the subject of this thesis, and second, the feasibility of an attack path which is what we address as a part of our thesis using the nominated attack analysis methodology. In this thesis, we investigate existing methodologies for modelling attacks and try to nominate one that is most suitable for the automotive industry. This judgement is based on a list of criteria that are collected either through surveying previous related works or through interviewing industrial and academic experts. Once the methodology is nominated, we introduce a method for calculating the feasibility of different possible attack paths using the proposed methodology. Finally, we use some use cases by means of which we demonstrate how our nominated method can be used to model attacks against some assets and how the feasibility of each attack vector can be calculated for the use cases. Keywords: Automotive, Cybersecurity, Cyberattack, Attack surface, Attack analy- sis, Risk assessment, Threat analysis, Attack feasibility, Attack potentials. v Acknowledgements We would like to offer our special thanks to our industrial supervisors Christian Sandberg and Manne Engelke as well as our academic supervisor, Erland Jonsson and examiner, Tomas Olovsson for their unsparing and relentless help and support throughout our thesis project. We would also like to express our great appreciation to the following people for their assistance with the data collection process: Urban Thorsson, Volvo Group Trucks Technology Olayinka Oladele, Volvo Group Trucks Technology Nasser Nowdehi, Chalmers University of Technology Adi Karahasanovic, Combitech Seyed Reza Esmaeili Gothenburg, June, 2019 Afshin Soltani Esterabadi Gothenburg, June, 2019 vii Contents List of Figures xi List of Tables xiii List of Acronyms xv 1 Introduction 1 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Thesis scope and domain background . . . . . . . . . . . . . . . . . . 3 1.3 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 In-vehicle Common Architecture 5 2.1 ECU Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 AUTOSAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.1 Security Features . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3 Communication Bus System . . . . . . . . . . . . . . . . . . . . . . . 9 2.4 Communication Specifications . . . . . . . . . . . . . . . . . . . . . . 10 2.4.1 Internal Communication . . . . . . . . . . . . . . . . . . . . . 10 2.4.2 External Communication . . . . . . . . . . . . . . . . . . . . . 11 3 Taxonomy of Cybersecurity Concepts 13 3.1 Preliminary Security Definitions . . . . . . . . . . . . . . . . . . . . . 13 3.2 Automotive Cybersecurity Guidelines . . . . . . . . . . . . . . . . . . 15 3.2.1 Automotive Secure Development Life Cycle . . . . . . . . . . 15 3.2.2 EVITA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2.3 HEAVENS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.4 SAE - J3061 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.3 Attack Surfaces in Modern Vehicles . . . . . . . . . . . . . . . . . . . 21 3.3.1 Physical Access . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.3.2 Short Range Wireless Access . . . . . . . . . . . . . . . . . . . 22 3.3.3 Long Range Wireless Access . . . . . . . . . . . . . . . . . . . 23 3.3.4 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4 Attack Analysis Methodologies 25 4.1 TARA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2 STRIDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.3 DREAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 ix Contents 4.4 Attack Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.5 Attack Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.6 Miscellaneous Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5 Feasibility 41 5.1 Analysis parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.2 Parameter rating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 6 Use cases 47 6.1 Use case 1: GPS positioning and warning lights . . . . . . . . . . . . 50 6.2 Use case 2: Target cruise control speed . . . . . . . . . . . . . . . . . 55 7 Method 59 8 Results 61 9 Discussion 65 10 Conclusion 69 Bibliography 71 x List of Figures 1.1 Next generation of vehicular communication . . . . . . . . . . . . . . 2 1.2 Risk assessment process and the thesis scope . . . . . . . . . . . . . . 3 2.1 Different types of ECUs in in-vehicle common architecture . . . . . . 6 2.2 Overview of the AUTOSAR partnership program . . . . . . . . . . . 7 2.3 AUTOSAR software architecture - components and interfaces . . . . 9 3.1 The CIA triad model . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2 Mapping risk management process onto the V-model of product de- velopment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3 Workflow of HEAVENS security model . . . . . . . . . . . . . . . . . 19 3.4 Security level based on threat level and impact level . . . . . . . . . . 20 3.5 Impact parameters and impact level in the HEAVENS security model 20 3.6 Communication paths during the concept phase activities . . . . . . . 21 4.1 Attack analysis methodologies classification . . . . . . . . . . . . . . 26 4.2 Constriction of the field of attacks . . . . . . . . . . . . . . . . . . . . 28 4.3 Multiple stages of TARA process in detail . . . . . . . . . . . . . . . 29 4.4 DFD created with MS threat modelling tool . . . . . . . . . . . . . . 31 4.5 Attack tree example showing the data flow tampering . . . . . . . . . 31 4.6 DREAD algorithm’s equation for risk calculation . . . . . . . . . . . 32 4.7 Simple scenario for an attacker escalating its privileges . . . . . . . . 33 4.8 Attack graph modelling of the privilege escalation scenario . . . . . . 33 4.9 Modelling attacks trying to obtain a user’s password using attack tree 35 4.10 Three key aspects balanced by OCTAVE . . . . . . . . . . . . . . . . 36 4.11 PASTA model of threat and risk analysis . . . . . . . . . . . . . . . . 38 5.1 Linear formula for feasibility calculation . . . . . . . . . . . . . . . . 45 6.1 HoliSec reference architecture . . . . . . . . . . . . . . . . . . . . . . 48 6.2 GPS positioning scenario . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.3 Vehicle redirection attack . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.4 Broadcasting false information . . . . . . . . . . . . . . . . . . . . . . 53 6.5 Intra-vehicle communication hindrance . . . . . . . . . . . . . . . . . 53 6.6 Attacks toward the GPS and the warning lights in one picture . . . . 54 6.7 Example of feasibility calculation in GPS positioning use case . . . . 54 6.8 Cruise control scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 56 6.9 Cruise speed manipulation . . . . . . . . . . . . . . . . . . . . . . . . 57 xi List of Figures 6.10 Prevent the cruise control from functioning . . . . . . . . . . . . . . . 57 6.11 Big picture of the attack paths in the cruise control scenario . . . . . 58 6.12 Example of feasibility calculation in cruise control use case . . . . . . 58 8.1 Threat analysis VS Attack analysis . . . . . . . . . . . . . . . . . . . 62 xii List of Tables 2.1 VLANs in the HoliSec reference architecture . . . . . . . . . . . . . . 11 3.1 Severity classification scheme for security threats in EVITA . . . . . . 18 5.1 Attack potential values . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.2 Feasibility calculation framework . . . . . . . . . . . . . . . . . . . . 45 6.1 HoliSec reference architecture entities . . . . . . . . . . . . . . . . . . 49 6.2 Feasibility calculation for two paths of the GPS spoofing attack . . . 55 6.3 Feasibility calculation for speed manipulation . . . . . . . . . . . . . 58 xiii List of Acronyms API Application Programming Interface ASIL Automotive Safety Integrity Level AUTOSAR AUTomotive Open System ARchitecture BSW Basic Software CAL Crypto Abstraction Layer CAN Controller Area Network CANFD CAN Flexible Data rate CEL Common Exposure Library CIA Confidentiality, Integrity, Availability CSM Crypto Service Manager DFD DataFlow Diagram DoS Denial of Service ECU Electronic Control Unit EVITA E-safty Vehicle Intrusion proTected Applica- tions FTP File Transfer Protocol GPS Global Positioning System HEAVENS HEAling Vulnerabilities to ENhance Software Security and Safety HoliSec Holistic approach to improve data Security IL Impact Level IoT Internet of Things IPA Information Promotion Agency ITS Intelligent Transport Systems LIN Local Interconnect Network MOL Methods and Objectives Library MOST Media-Oriented System Transport xv List of Acronyms OBD On-Board Diagnostics OCTAVE Operationally Critical Threat, Asset, and Vul- nerability Evaluation OEM Original Equipment Manufacturer OWASP Open Web Application Security Project PASTA Process for Attack Simulation and Threat Analysis PATS Passive Anti-Theft System RKES Remote Keyless Entry/Start RSL Road Speed Limit RTE Run-Time Environment SAE Society of Automotive Engineers SecOC Secure On-board Communication SL Security Level SWC Software Component TAL Threat Agent Library TARA Threat Analysis and Risk Assessment TCP Transmission Control Protocol TL Threat Level TOE Target Of Evaluation TPMS Tire Pressure Monitoring System V2I Vehicle to Infrastructure V2V Vehicle to Vehicle V2X Vehicle to everything VLAN Virtual Local Area Network xvi 1 Introduction I think one of the biggest concerns for autonomous vehicles is somebody achieving a fleet-wide hack. Elon Musk - Tesla CEO Today, our evolution came toward a leap point where connectivity and automation play crucial roles in our daily life. Not only the advent of Internet of Things (IoT), but also the emergence of autonomous products including autonomous vehicles are giving rise to the ever-increasing need of security. The legacy definition of security in automotive was focusing on safety in physical sense, which means the ability to ensure that it is not possible to break into a vehicle or steal it in any way. However, this definition has been changed since in the modern automotive industry, depending on the brand and the type of vehicle, there can exist more than 100 computers (Electronic Control Units, ECUs) and about 100 million lines of code [1], [2]. Therefore, automotive security now also encompasses both computer and network security, which is also known as cybersecurity [3]. 1.1 Background The current automotive industry is leading toward producing vehicles with au- tonomous driving or an advanced driver-assistance system [4]. In order to fulfill such smart capabilities and also equip the vehicle with more functional features such as Intelligent Transport Systems (ITS), different levels of connectivity needs to be considered in the architecture level. Different communication channels are be- ing developed such as vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) in order to fulfill ITS different goals, including increase of roads safety and traffic 1 1. Introduction flow [5]. Moreover, vehicles also need to become connected to the Cloud services for remote diagnostics or remote software updates [6], [7]. Figure 1.1 illustrates this connection and communication. Although the evolution trend seems to bring more functionality and intelligence into the automotive sector, however, this can also make modern vehicles subject to various types of intrusion and malicious ac- tivities which could be considered as major threats to both the humans factor and the vehicle itself. In order to provide inter-connectivity, connected vehicles rely on wireless and cellular communication interfaces. This exposes them to a wide range of security risks. In 2015, Miller and Valasek [8] performed a research on possible remote attacks on vehicles and they succeeded in breaking into a Jeep Cherokee and consequently taking control over the steering and the braking systems. In the big rig truck’s scenario which happened in 2016, attackers succeeded to gain control over the accelerator and the braking system [9]. Lack of safety in a vehicle could lead to major disasters such as loss of life, therefore security breaches are highly intolerable in automotive industry. As a result, there is an ever-increasing public concern toward the cybersecurity of autonomous and connected vehicles [10]. Figure 1.1: Next generation of vehicular communication [10] In order to tackle cybersecurity concerns in the automotive industry, threat modeling and risk assessment frameworks have been developed [11]. Risk assessment methods usually start with the asset identification step where critical assets are identified. Then by considering standard damage scenarios, different threats to those assets are classified via threat analysis procedures. Thereafter, impact assessment is done by determining the impact levels associated with a compromised asset. As the security design process proceeds, different vulnerabilities may emerge through the vulner- 2 1. Introduction ability analysis stage. Eventually, by means of a comprehensive attack analysis method, potential attack paths and their associated feasibility are analyzed. The results derived from the risk assessment process are the basis upon which the risk treatment is applied as the closing stage [12]. 1.2 Thesis scope and domain background Nowadays, risk assessment plays a crucial role in the development process. Several threat modeling and risk assessment frameworks have been developed for the au- tomotive domain [13], however an alleged state-of-the-art study [11] performed by the HEAVENS project in 2016 indicated that “security design and architecture has only been addressed to some degree in vehicular systems” and “internal security is more or less absent”. The main goal of a risk assessment framework is to categorize possible threat scenarios according to their impact on a stakeholder considering the associated attack paths [13]. The scope of this thesis is defined over the risk assess- ment process where attack analysis plays a vital role in identifying potential attack paths and their associated feasibility. Various attack analysis approaches are be- ing used in different security frameworks. However, there is no standardized attack analysis methodology for the automotive industry. Therefore, after a comprehen- sive study of the state-of-the-art attack analysis methodologies and by considering automotive-specific criteria and security expectations in accordance to the latest automotive-specific risk assessment frameworks, which are closely aligned with the safety processes of ISO 26262 [14], we demonstrate the most suitable methodology for the automotive sector. Figure 1.2 demonstrates the risk assessment process and where attack analysis, upon which this thesis is based, stands. Figure 1.2: Risk assessment process and the thesis scope 3 1. Introduction 1.3 Approach The objective of attack analysis is to develop and/or update a set of attack paths by which vulnerabilities could be exploited to realize a threat scenario. In order to analyze the security of an information system, plenty of different approaches have been considered by different research articles so far. The most well-known attack modelling techniques used to analyse cyberattacks are Attack Graph [15], Attack Tree [16], Attack Vector [17], Attack Surface [18], Diamond model [19], OWASP’s threat model [20] and Cyber-Kill-Chain [21]. To the best of our knowledge, attack trees and graphs have been used so far to create a model to analyze attacks that occur in computer networks and the IT domain. Therefore, in order to discover the best practice among attack analysis methods for the automotive industry, we do further investigations to find the possible advantages of these two approaches compared to other methodologies, if any. In addition, in order to have a list of the most prominent criteria for evaluating our attack analysis methodology, we are aiming both to analyze existing related articles, and to conduct a series of interviews with cybersecurity experts at Volvo Group company. Afterwards, using some use cases, the feasibility of different types of attacks is assessed using mathematical calculations on attack paths. 1.4 Contribution The thesis focuses on finding the best answer for the following questions: 1- Among existing attack analysis methodologies, which one is best suited for auto- motive industry? 2- What are the criteria based on which the proposed solution is selected? Not only do we try to answer the aforementioned questions, but from the industrial perspective, we propose the most suitable method and modelling tool to perform attack analysis in a structured way that is applicable to the automotive industry. Afterwards, we suggest a framework by means of which the feasibility of attack paths can be calculated. The outcome of our work will later be used to find the corresponding risks generated by each attack. If the proposed solution is proved to be the most suitable among other available methodologies (this would be assessed based on the found criteria) and aligned with the needs in the automotive industry, it would be used as the basis for attack analysis methodology for the upcoming ISO standard in the area. 4 2 In-vehicle Common Architecture In the most recent architecture of modern vehicles, there exists a considerable num- ber of different ECUs, each responsible for a series of functionalities. To enumerate some of these functionalities, we can mention: engine control, anti-lock braking sys- tem, telecommunication, adaptive cruise control and the like. In order to provide each of the aforementioned functionalities, these ECUs need to communicate not only with each other but also with various objects throughout the whole vehicle. Hence, due to different types of messages and different requirements of the ECUs, diverse types of networks must be implemented and then integrated through mul- tiple gateways. Therefore, not only does the design phase of the inner architecture consider the transmission of signals among different controllers but also the accom- plishment of the following goals: 1) reducing cable cost, 2) saving package space, and 3) enhancing communication safety [22]. 2.1 ECU Classification As illustrated in Figure 2.1, ECUs can be classified into two categories of safety critical and non-safety critical based on their functionality [23]: • Powertrain ECUs are responsible for controlling safety-critical parts of the ve- hicle including braking system and engine control. Any failure on these ECUs could lead to varieties of malfunctioning which might cause inability to control the vehicle. • Vehicle Safety ECUs are responsible for providing safety-assisting functional- ity to the driver, namely collision avoidance system, airbags, anti-lock braking system, adaptive cruise control and tire pressure monitoring. These ECUs could be considered safety-critical since a failure could lead to life threats of the driver, the passengers and other vulnerable road users. 5 2. In-vehicle Common Architecture • Comfort ECUs provide different driver-assisting functionalities such as park- ing assistance, thermal management, and electric suspension. Failure of these components might not be considered as a direct threat to the safety of the driver, however the combination of failures still could affect the driver’s safety. • Infotainment ECUs are responsible for audio and video support system inside a vehicle. This category is comprised of non-safety functionalities including audio streams, digital broadcasting TV, navigation systems, etc. • Telematics ECUs also provide non-safety functionalities which could be briefly described as telecommunication and informatics integration. These compo- nents include those that receive information such as weather and traffic con- dition from external sources [24]. Figure 2.1: Different types of ECUs in in-vehicle common architecture Many changes happened, through the evolutionary trend, to the modern ECUs compared to legacy ones which were first introduced as a controller for adjustment of fuel/air mixture for combustion process. As mentioned earlier, current vehicles are utilizing multiple ECUs for different functionalities of the vehicle. Many of these ECUs have often been standardized and been utilized by many manufacturers. These standard ECUs are not built by manufacturers anymore but a third-party supplier such as Bosch is producing them. As a part of the standardization process, there is the AUTOSAR project on which we elaborate more in the following section. 6 2. In-vehicle Common Architecture 2.2 AUTOSAR AUTomotive Open System ARchitecture (AUTOSAR) project was lunched in 2003 as a collaboration among different companies within the vehicular industry. The main goal of this project was proposing an open and standardized software archi- tecture between manufacturers and suppliers for the sake of reducing the growing complexity rate of softwares [25]. There are nine core companies that are partici- pating in the evolutionary trend of the AUTOSAR including Ford, BMW, General Motors and many others like Volvo as premium partners [26]. Figure 2.2 shows this partnership program. Figure 2.2: Overview of the AUTOSAR partnership program [26] AUTOSAR defines the software architecture and interfaces together with the design flow and the way the software needs to be mapped to the ECUs during the product development phase. Hence, every company needs to follow the same process in or- der to be able to implement it on their products. However, the high configurability of this architecture allows it to be customized according to the specific needs of the manufacturer. This allows the involving company to “Cooperate on standards, compete on implementation” which is AUTOSAR official motto [27]. The basic software architecture consists of: • Service Layer - this is the highest level which provides operating system functions including ECU state management, logical and temporal program flow monitoring, communication services, memory services, and diagnostic ser- vices. This layer also offers the principal security mechanism of the AUTOSAR architecture, namely SecOC security module and CSM cryptographic module. 7 2. In-vehicle Common Architecture • ECU Abstraction layer - this layer acts as a medium between different functions of the application and the drivers of the micro-controller abstraction layer. It works as an Application Programming Interface (API) to different micro-controllers including both internal and external. In this way, higher lay- ers do not need to be concerned about the ECU design. • Micro-controller Abstraction layer - this layer provides accessibility to the micro-controller and internal parameter in a way that makes higher layers independent. • Complex Drivers layer - This layer helps to integrate drivers of special purpose devices which are not defined in the AUTOSAR standard. This layer also provides direct accessibility to the micro-controller layer. A more detailed map of the AUTOSAR software architecture can be seen in Figure 2.3. 2.2.1 Security Features For the sake of security, AUTOSAR provides significant security mechanisms in software level, which can be used by different modules and Software Components (SWCs). This standard also provides solution for securing on-board communication while the rest of the security consideration is outsourced to the original equipment manufacturers (OEMs). OEMs are usually responsible for utilizing different cryp- tographic protocols in order to be implemented on their vehicles [28]. Three principal security mechanisms provided by AUTOSAR are: • CSM - Crypto Service Manager, which according to layered structure of AU- TOSAR shown in Figure 2.3, resides in the service layer of Basic Software (BSW) and offers services to higher layers. It actually provides different appli- cations with a unified service for accessing different cryptographic primitives. For instance, one application may utilize SHA256 while the other one requests for MD5. It is worth noting that CSM service is only accessible locally inside an ECU [28]. • CAL - Crypto Abstraction Layer also provides very similar functionality as CSM does. This static library, provides direct cryptographic functionality through bypassing the Run-Time Environment (RTE). Different software mod- ules such as BSW/SWC can directly call different functions provided by CAL. It is worth noting that this library is not related to any layers of AUTOSAR architecture. • SecOC - Secure On-board Communication module offers an authentication mechanism for secure data communication for all ECUs that are handling critical data. The security mechanism provided by this module is not only 8 2. In-vehicle Common Architecture relatively light-weight but also highly compatible with all existing communi- cation protocols including both legacy and modern ones [26]. Figure 2.3: AUTOSAR software architecture - components and interfaces [26] Nowdays, AUTOSAR standard is widely used by most of the companies within the vehicular industry. Accordingly, the security of softwares that are being implemented on vehicles are highly dependent on the security scheme and route map provided by this standard. Therefore, in order to provide the best practice scheme for securing modern vehicles in the software level, there is a constant need for contribution of cybersecurity experts from these companies. This collaboration could help to improve the AUTOSAR framework not only according to the most recent needs of automotive industry but also, to some extent conforming to the most recent proprietary security goals of each company. 2.3 Communication Bus System There are five different network types for communication in vehicular systems: 1) Local Interconnect Network (LIN) which is dedicated to functions with the lowest data-rate such as mirror control, door locks, and climate control; 2) Media-Oriented System Transport (MOST) that is designed for high-speed bandwidth with 24.8 Mbps information rates which was used for Global Positioning System (GPS) and in general the navigation unit, media showcases and entertainment system [29]; 3) Controller Area Network (CAN), which is our main focus in this thesis, covers the highest proportion of the communication channels inside a vehicle and is used for communication between controllers, actuators and sensors. CAN supports 1Mb/s data rates. However, CAN Flexible Data rate (CANFD), which is a high speed CAN, supports a higher data rate and bandwidth [30]; 4) FlexRay is dedicated to deterministic communication and safety-critical applications including stability 9 2. In-vehicle Common Architecture control, brake-by-wire, and steer-by-wire [31]. FlexRay is designed to transfer event- triggered and time-triggered information in the same cycle. The high production cost of FlexRay makes it less popular among vehicular corporations [30]; and 5) Ethernet is considered as the future of communication inside vehicles. Due to its high-speed transmission limits of up to 10 Gbit/s, it is considered as the best alternative to other communication channels such as CAN which is prone to bottlenecks. Moreover, Ethernet provides high reliability and adaptability making it a good alternative for the backbone channel in future in-vehicle network architecture [32]. 2.4 Communication Specifications Today’s vehicles are enriched with wide varieties of functionality. Not only do this give a rise to the high rate of internal communication between different ECUs, sensors, and actuators but also increases the need to communicate with external points including back office, nomadic devices, infrastructures, other vehicles, and Cloud servers. Therefore, several communication channels need to be considered throughout the architecture design phase in order to fulfill different objectives. 2.4.1 Internal Communication As it is shown in Figure 2.2, modern vehicles use different communication channels to exchange data between various components inside the car such as different sen- sors, ECUs, and actuators. For this sake, different communication protocols such as LIN, CAN, FlexRay, MOST, and Ethernet are used in the physical layer. A common process among all corporations is to move from low bandwidth protocols like CAN toward technologies that provide a relatively higher bandwidth; Proto- cols such as FlexRay, CANFD and Ethernet which is able to provide up to 1Gbit/s of bandwidth. Generally, communications over internal buses take place through broadcast messages. Hence, every node situated on the same subnet as the sender, would be able to read broadcast messages. Most of the events inside a vehicle are considered as real-time events, thus there are many time-critical messages trans- ferred through communication buses where each of them guarantee criticality by means of different policies. For instance, CAN as a network with high portion of time-critical communications provides this guarantee by giving different priority IDs to the messages in a way that high priority messages can override low priority ones. Although CAN is providing so many good features which makes it the most suitable communication network for in-vehicle communications, it lacks providing a security mechanism. This results in different applications having to implement their own security mechanism for the sake of message authentication, otherwise any intruder can falsify a message and reach a malicious purpose by just broadcasting the mes- sage on the CAN bus [33]. There are many services running in modern vehicles requiring higher bandwidth as well as certain levels of isolation and security. This gives rise to more demands toward a high capacity channel with more networking abilities. As the Ethernet provides higher bandwidth for communication, it is possible to partition an Ethernet 10 2. In-vehicle Common Architecture LAN into multiple Virtual Local Area Networks (VLAN) to add different properties to the channel such as prioritization and security. This makes Ethernet the best option for the implementation of a high speed channel inside a vehicle. Table 2.1 shows the VLANs specifications provided by HoliSec architecture [33]. Table 2.1: VLANs in the HoliSec reference architecture VLAN ID Description VLAN 1 High priority communication between applications in connectivity ECU, V2X and Driver Display VLAN 2 Low priority communication between applications in connectivity ECU and Driver Display VLAN 3 Medium priority communication 2.4.2 External Communication By equipping modern vehicles with a broad range of functionalities, there is an ever increasing trend toward external communication. Initially, the first external channel has been established between the vehicle and the back office in order to provide ser- vices such as collecting diagnostic trouble reports, accident reports, and multimedia connectivity [33]. Gradually, more and more services were provided by the OEMs and the data exchange rate between the vehicle and the back office increased ac- cordingly. To enumerate some of such services, we can mention navigation system, fleet management system, diagnostics, remote vehicular functions, media streaming via nomadic devices, etc. Moreover, by the advent of V2V and V2I networks, soon there will be even more need for reliable and high-speed external communication channels. The potential communication channels for the aforementioned networks will most likely use 5G and wireless 802.11p. Nevertheless, there are still limitations such as cell coverage and signal strength associated with these technologies which need to be addressed for the sake of higher reliability and availability [33]. 11 3 Taxonomy of Cybersecurity Concepts Prior to our scientific approach towards the given problem, a complete understanding of preliminary cybersecurity concepts and definitions needs to be acquired. There- fore, in the following section we demonstrate some of the most common cybersecu- rity terms, concepts, and standards related to our research scope so that the readers could reach a better understanding and adaptation of the content when reading the following chapters. 3.1 Preliminary Security Definitions In this subsection we take a deeper look into some of the initial security definitions related to cybersecurity of vehicular section. • CIA: As shown in Figure 3.1, Confidentiality, Integrity and Availability form one of the most comprehensive triangular security models which is being used widely within the domain of information systems. These three are considered as the key factors needed to be guaranteed in order to assure the security of a system. – Confidentiality means that within a certain information network, only an authorized user should be able to access certain types of data. As this face is one of the most fundamental aspects of a secure system, it is commonly targeted by attackers. Cryptographic solutions are being developed as a main countermeasure toward assuring this aspect of in- formation systems. – Integrity means that in an information network, the data that is being sent by the sender should be received accurately and unchanged. In other words, the data needs to be protected from any unauthorized access and modification while being transferred across the network. 13 3. Taxonomy of Cybersecurity Concepts – Availability means to ensure that information-critical resources are ac- cessible to authorized users on demand. This face is taken into account due to the presence of different types of attacks that target an information resource and try to make it unavailable. Figure 3.1: The CIA triad model • Asset: An asset (system resource) within an information system could be any type of data, service, and equipment including both software and hardware [34]. This factor could be considered as a point of focus around which different security definitions are defined and developed. • Vulnerability: Any flaw or weakness in the system’s design and operation that can be considered as a potential leakage towards the violation of the CIA triad [34]. • Threat: A possible danger to the system that can exploit different vulnera- bilities of a system and consequently violate the CIA triad. • Attack: Any malicious activity caused by an unauthorized person threatening the CIA triad through exploiting the potential vulnerabilities of a system. Attacks could be classified into two main classes: 1) Active: any attempt to make alteration to system resources or intervene their operation. 2) Passive: any type of exploitation of system’s information resources without affecting its functionality. • Attacker: Any entity that performs the act of attack or could be considered as a threat to a system in anyway. • Risk: A risk is a probability and impact of a potential threat or attack within a system [12]. We will have a deeper look into this concept once demonstrating different security and risk assessment frameworks in section 4. 14 3. Taxonomy of Cybersecurity Concepts • Countermeasure: Any activity that strengthens a system against different vulnerabilities, threats, or attacks. This is usually done by a complete analysis of the system and reporting accordingly so that the consequent actions can be taken in order to mitigate the risk. • TOE: Target Of Evaluation is the product or the system that is the subject of evaluation. 3.2 Automotive Cybersecurity Guidelines As we pointed out in previous sections, because of a broad range of functionalities and services provided by modern vehicles, there is an ever increasing trend towards using more ECUs and connectivity media in order to fulfill those expected func- tionalities. The automotive industry has been implementing ISO 26262 [14] since 2011 to address functional safety requirements. However, because modern vehicles are also becoming prone to computer and network security risks, complementary guidelines have been developed to address cybersecurity. It is the matter of con- cern to go through these guidelines before demonstrating our approach since the provided approach is defined based on the cybersecurity risk assessment process. Time-wise, Esafety Vehicle Intrusion Protected Applications (EVITA) [35] was the first framework co-funded by the European Commission trying to complement the safety process with cybersecurity concerns. The primary design goal of EVITA was to provide a secure architecture for vehicular networks to prevent them from being tampered or compromised by an external source. Two years after the publication of EVITA, Information Promotion Agency (IPA), which is located in Japan, pro- posed another document with similar cybersecurity objectives but this time for Asian manufacturers. This trend continued until 2016, where two significant frameworks namely HEAVENS [12] and SAE-J3061 [3] were published by Volvo and Society of American Engineers (SAE) respectively. These two guidelines were published to formulate a set of recommendations on how cyber-threats need to be addressed by having the functional safety and the secure development life-cycle in mind. However, SAE is considered to be more comprehensive since it considers a more general case for the vehicle industry compared to HEAVENS that can be considered as Volvo’s proprietary cybersecurity guideline. In this section after a brief demonstration of the secure development life-cycle in vehicular industry, we will shortly discuss the most significant security recommendations and guidelines in vehicular systems. 3.2.1 Automotive Secure Development Life Cycle Automotive systems are considered to be safety-critical systems where different phys- ical or cyber-physical threats to the system could lead to life threatening hazards. Hence, most of the companies in automotive domain are following the common func- tional safety standard ISO-26262 [14] during the product development life-cycle. This standard has been extracted from the more general standard IEC 61508. Ac- cording to ISO-26262, every product needs to be developed according to a traditional 15 3. Taxonomy of Cybersecurity Concepts V-model that is shown in Figure 3.2. This model is comprised of three distinct phases where each consists of different sub-phases: • Concept phase: During this phase by developing initial system design, the safety life-cycle process is lunched. The most significant step in this phase is hazard identification and risk assessment where after careful assessment of potential safety risks, corresponding safety goals and Automotive Safety In- tegrity Levels (ASILs) are defined for every object in the system. Once the safety goals are defined, the concept phase ends [36]. • Product development phase: This phase is comprised of three nested v- models including i) product development at system level, ii) product develop- ment at hardware level, and iii) product development at software level. This phase ends once the product is released [37]. • Production and operation phase: The final stage handles validation and verification of the operation and the safety of the product. Figure 3.2: Mapping risk management process onto the V-model of product development In order to ensure the security and safety of a vehicle, risk assessment is a crucial stage during the development process. There exist many risk assessment frameworks where few of them are developed according to the needs of the automotive industry. HEAVENS [12], which was launched in collaboration with Volvo Trucks in 2013, provides a risk assessment framework closely aligned with ISO-26262 safety process. This project was a concrete step towards cybersecurity standardization for automo- tive systems and was referred to as “Cybersecurity Guidebook for Cyber-Physical Vehicle Systems” in the first international security guideline in automotive, J3061 [3]. 16 3. Taxonomy of Cybersecurity Concepts 3.2.2 EVITA E-safety Vehicle Intrusion proTected Applications (EVITA), was developed in col- laboration with European Commission from 2008 to 2011. The aim of this project was to formulate the fundamental security requirements of applications based on V2X and V2V communication. The significance of this project was not only to provide an automotive-specific cybersecurity risk analysis framework, but also to secure the in-vehicle architecture as well as the communication protocols. This project provided security in the sense that, safety-critical components of a vehicle need to be identified in the first step. Furthermore, security strategies need to be applied during the whole product development phase in order to protect different components against tampering and to protect sensitive data from any external in- terference. Moreover, the CIA aspects of a system need to be mostly fulfilled via cryptographic solutions. The risk analysis stage in EVITA suggests a model to as- sess both the risk associated with an attack and the severity of its impact on the stakeholders together with the likelihood of the attack to be successful [35]. In order to provide security during the development phase, EVITA suggests four different security requirements which need to be satisfied from the highest point of view, including: • Operational: maintaining the intended level of operational performance for all vehicles and ITS systems. • Safety: ensuring the functional safety of all persons who are affected by the vehicle operation, namely road users and the people inside the vehicle. • Privacy: preventing any sensitive data of the driver, manufacturer, and the supplier from being disclosed to an untrusted third party. • Financial: handles prevention of fraudulent commercial transactions and theft of vehicles. Different threats to the system then could be identified and classified according to the aforementioned security goals. EVITA provides a grading system according to the classification and the severity of the impacts as can be seen in Table 3.1. For the sake of risk analysis, EVITA needs to calculate a quantitative value corresponding to the probability of a successful attack which is a function of the amount of time that the attack needs to be performed together with the level of experience and knowledge that the attacker needs for a successful attack. Finally, the associated risk is derived from the combination of this probability and the severity level [3]. 17 3. Taxonomy of Cybersecurity Concepts Table 3.1: Severity classification scheme for security threats in EVITA Severity class Aspects of security threats Safety Privacy Financial Operational 0 No injuries. No unauthorized access to data. No financial loss. No impact on operational performance. 1 Light or moderate injuries. Anonymous data only Low-level loss. Impact not discernible to driver. 2 Severe injuries (survival probable). Light/moderate injuries for multiple vehicles. Identification of vehicle or driver. Anonymous data for multiple vehicles. Moderate loss. Low losses for multiple vehicles. Driver aware of performance degradation. Indiscernible impacts for multiple vehicles. 3 Life threatening or fatal injuries. (survival uncertain) Severe injuries for multiple vehicles. Driver or vehicle tracking. Identification of driver or vehicle for multiple vehicles. Heavy loss. Moderate losses for multiple vehicles. Significant impact on performance. Noticeable impact for multiple vehicles. 4 Life threatening or fatal injuries for multiple vehicles. Driver or vehicle tracking for multiple vehicles. Heavy losses for multiple vehicles. Significant impact for multiple vehicles. 3.2.3 HEAVENS HEAling Vulnerabilities to ENhance Software Security and Safety (HEAVENS) project was launched in 2013 and was delivered in 2016. This project, which was developed by a team of security experts from both academia and industry, pursue some important goals such as [12]: • Identify needs and requirements of security in automotive industry. • Study and identify state-of-the-art work of security in automotive industry. • Identify potential threats, threat agents and vulnerabilities to construct secu- rity models. • Map security issues from related domains (e.g. software engineering, computer networks, etc) into automotive domain. • Define methodologies and identify tool support for evaluating software security. • Investigate the interplay of safety and security according to the common archi- tecture, considering ISO 26262, AUTOSAR [26] and other relevant standards. • Demonstrate proof of concept. 18 3. Taxonomy of Cybersecurity Concepts HEAVENS security framework policy is comprised of two important factors: • Security Attributes: These attributes are inherited from STRIDE model that classifies security concerns into six different categories. We will elaborate on them in the upcoming sections of this chapter. • Security Objectives: Security objectives are adapted and categorised in four groups of operational, safety, privacy and financial, as it was done in EVITA. As illustrated in Figure 3.3, HEAVENS security model consists of three distinct phases [12]: • Threat analysis: Functional use cases are provided as input into the threat analysis stage which consequently produces two different types of output: i) mapping between threats and assets that is done per asset in the context of use case, ii) classification of threats based on the provided security attributes, in order to find out about the security attributes that are being violated by a particular threat. • Risk Assessment: After threat analysis, the next step is to rank the threats. The results derived from threat analysis stage together with Threat Level (TL) and Impact Level (IL) are inputs to the risk assessment phase. At the end of this stage, the Security Level (SL) of each threat and its associated asset are identified. • Security Requirements: Ultimately, the mapping between threat and asset together with the associated security level are used to formulate the security requirements of the asset and the TOE. Hence, the security requirements are a function of asset, threat, security attribute, and security level. Figure 3.3: Workflow of HEAVENS security model [12] 19 3. Taxonomy of Cybersecurity Concepts As shown in Figure 3.4, risk assessment process, as the main part of HEAVENS, takes two numerical grades, namely TL and IL into account in order to generate the security level factor. Figure 3.4: Security level based on threat level and impact level [12] The threat level factor represents the likelihood of the threat derived from attacker’s capabilities, required equipment for performing the attack, and the windows of op- portunity. The latter is a factor which derived from the time and the type of access (e.g. physical and/or remote) that attacker needs for a successful attack. The results, which affect the impact level, are evaluated according to EVITA’s security objectives, as depicted in Figure 3.5 (it is worth mentioning that threat analysis pro- cess in HEAVENS framework uses Microsoft STRIDE model in combination with EVITA’s threat classification). The impact level on the other hand is defined over the consequences that an attack posses to the users and stakeholders. For instance, an attack that tampers the normal operation of the break ECU, can cause a safety- critical situation which may consequently have a sever impact on the system. The security level factor represents the severity level of the vulnerability endangering the TOE. Figure 3.5: Impact parameters and impact level in HEAVENS security model [12] 20 3. Taxonomy of Cybersecurity Concepts 3.2.4 SAE - J3061 In 2016, the SAE-J3061 standard [3] was published as the most significant cyberse- curity guideline for cyber-physical vehicle systems. This standard was developed on top of the well-known functional safety standard ISO-26262 in order to integrate the cybersecurity consideration with functional safety objectives. This standard utilizes Threat Analysis and Risk Assessment (TARA) as a threat analysis framework for secure development process. It is worth mentioning that SAE-J3061 offers "Attack Tree" model for attack analysis stage in the risk assessment process. This standard coordinates a very good interaction between security and safety process. As Figure 3.6 shows, it can be inferred that SAE-J3061 is an information security standard tailored for the automotive safety process [38]. Figure 3.6: Communication paths of the concept phase activities [38] 3.3 Attack Surfaces in Modern Vehicles The attack surface of a vehicle is the sum of different vulnerable points (e.g. attack vectors) that can be leveraged by an attacker in order to perform malicious activities. Therefore, one of the basic security considerations is to keep the attack surface as small as possible [39]. After explaining the common architecture of modern vehicles, in this section we are going to elaborate on possible attack surfaces according to the modern architecture. In 2011, Chekoway et al. [2] provided the first taxonomy on attack surfaces. Thereafter, in 2014, Miller and Valasek [40] published an extensive list of possible attack surfaces by performing a study on 21 different car models . At the same time, in another paper published by Zhang et al. [41] different attack surfaces were studied while focusing on malwares. In this section, we elaborate more on the discovered attack surfaces according to the aforementioned articles. 21 3. Taxonomy of Cybersecurity Concepts 3.3.1 Physical Access All manufacturers equip their vehicles with several physical ports in order to pro- vide either direct or indirect access to the vehicle’s internal network. Among these existing interfaces, the followings are considered as potential attack surfaces: • OBD-II Port: On-Board Diagnostics port, which is installed in almost all modern vehicles, was designed for diagnostic purposes. It provides either di- rect access to the CAN bus, or indirect access via central gateway. In the past, special purpose devices were used for diagnosis through the OBD-II port, but nowadays inexpensive dongles can be connected to this port and most of garage servicemen can use regular computers or smart phones to connect to these dongles which makes this port prone to attacks. • Entertainment/removable media ports: Today, there is a rising trend in equipping vehicles with different entertainment systems including CD-players, USB ports, IPod connectors, etc. Since these interfaces are connected to the vehicle’s internal network to support, for instance, hands-free features, this makes them a potential attack surface. 3.3.2 Short Range Wireless Access Modern vehicles no longer provide entertainment services via physical ports, but instead they are equipped with different short range (e.g. 3 to 300 meters) media such as Bluetooth or Wireless. These are used not only for connecting smart phones but also for the remote key entry and tire pressure monitoring. • Passive Anti-Theft System (PATS): This feature is placed in most of new vehicles. It provides an anti-theft system by integrating a sensor in the steering column to the ignition key. The key is triggered by an RF signal gen- erated by one of the ECUs in the vehicle so that the vehicle checks whether the key is close enough to the vehicle and that is has not been started by an attacker. The potential attack surface related to this system is prone to De- nial of Service (DoS) attack in which the attacker tries to bombard the vehicle with intervening signals to prevent it from establishing a connection to the key. • Tire Pressure Monitoring System (TPMS): This system constantly checks the tires pressure and reports the status to the corresponding ECU. The at- tack surface in this case could be a false report to the ECU. However, Ishtiaq Roufa et al. [42] have shown that it is also possible to cause a DoS attack on the associated ECU. • Remote Keyless Entry/Start (RKES): Nowadays, most of the modern vehicles support remote key-less entry or even remote start system. This is done by establishing a sort of authenticated and encrypted channel between the key and the corresponding ECU. Here the attack surface is relatively small since it is only prone to DoS in the sense that the attacker may prevent the 22 3. Taxonomy of Cybersecurity Concepts vehicle from recognizing the key or being started remotely. • Bluetooth: Almost all of the modern vehicles are equipped with Bluetooth so that external smart devices can become synced with the vehicle. Although manual pairing protects Bluetooth protocol from being tampered, since it still provides a link to the in-vehicle network, this can be considered as a large attack surface. • WiFi: WiFi connectivity has recently been available in cars to serve as a hotspot for Internet usage of smart devices. Since this is done by bridging the vehicle’s Internet connection to the smart devices, therefore it can also be considered as an attack surface. • Emerging short range channels: By the advent of ITS and V2V/V2X, sooner or later vehicles will communicate with each other and the infrastruc- ture. This is possible via special wireless channels known as 802.11p. The short range channels are another attack surface which need to be considered as soon as this technology is widely used. 3.3.3 Long Range Wireless Access Today’s vehicles are also equipped with long range wireless systems in order to be able to communicate over distances further than 1 km. Within this range, we can categorize communication channels into broadcast (e.g. GPS, Radio) and address- able (e.g. 4G Internet connection) channels. • Radio Data System: Today, radio channels are capable of receiving both audio and data signals. Since there is no sign of a data parser in between, these receiver systems can be prone to code execution. However, because of low probability of such attacks, this attack surface is considered relatively small. • Global Positioning System: Nowadays, GPS is widely used in many smart devices and vehicles are not an exception. It is utilized for navigation and internal automation purposes. Moreover, GPS information is also useful for reporting traffic jam and road condition in the context of connected vehicles. However, it has been reported that such positioning devices are prone to spoof- ing attacks [43]. This attack could lead to diverting the vehicle or making it out of operation. • Telematics/Cellular: Modern vehicles are also equipped with telematic units and cellular channels in order to be able to receive information such as weather condition or traffic status. Since the telematic unit acts as a gateway that connects the vehicle to the Internet, it could be considered as a relatively large attack surface. Moreover, because of telematic’s higher bandwidth, they use media-Bus for internal communication while still connected to CAN-Bus 23 3. Taxonomy of Cybersecurity Concepts via bridging the ECU and the gateway. In a study done by Checkoway et al. [2] it has been shown that it is possible to cause malicious activities such as killing the engine or activating the windscreen wipers through the telematic gateway. • Internet/Apps: IoS and Android are offering different applications such as navigation for use inside the vehicles. This trend gives rise to a relatively wide attack surface ranging from Malwares to browsers’ vulnerabilities. 3.3.4 Sensors For a vehicle to be able to communicate with its environment and more importantly to function correctly, it must be equipped with various types of sensors. According to [44], these sensors can be tricked to generate false data. However, since these devices are outside the scope of the digital world, we consider them outside the scope of this thesis. 24 4 Attack Analysis Methodologies While a framework is more general in its nature, a model is a simplified developed and tested framework. A model tries to focus on the interesting parts and ignore all other unimportant and unnecessary details. Therefore, a threat model highlights the security details with respect to a particular type of system and the assets under consideration by addressing both treat’s capabilities and its intent. Fundamentally, threat modelling could be considered as a structured attempt of identifying cyber threats based on their objectives and related vulnerabilities and consequently pro- viding mitigation techniques addressing identified threats. There are wide variety of threat and attack modelling techniques that could be classified into three general categories [45], namely Attacker-centric, System-centric, and Asset-centric based on their behavior and identification strategy. Figure 4.1 shows this classification. • Attacker-centric: This approach focuses on attacker’s capabilities, motiva- tions, and goals and the way they can be achieved. It has been considered by some of the well-known models such as Intel’s TARA (Threat Analysis and Risk Assessment) and Cyber Kill Chain. • Asset-centric: Asset-centric approach focuses on the target information or resources of a system that an attacker tries to compromise. This approach is more common than the attacker-centric method. However, models that use this approach are considered as both time and resource consuming since they need more time and more resources to model different threats against the target system. The most well-known asset-centric models are PASTA and OCTAVE. 25 4. Attack Analysis Methodologies • System-centric: This approach, also known as ‘software-centric’or ‘design- centric’, focuses on a software being developed or a system being built. This model starts from the design phase of a software or system and investigates different possible threats against each component of the system through the whole development process. System-centric approach is commonly used in dif- ferent information systems and has become a legitimate standard in the scope of information systems. Two of the most well-known system-centric models are STRIDE, which has been developed by Microsoft, and DREAD. Figure 4.1: Attack analysis methodologies classification Not all of these techniques are applicable to the needs of automotive industry. Hence in this section, we elaborate more on those recently recommended and utilized by the cybersecurity guidelines described in Section 3.2. 4.1 TARA Threat Analysis and Risk Assessment (TARA) is a predictive attacker-centric threat modelling developed in order to assess, prioritize, and mitigate cybersecurity risks. This model has been designed in a way to provide easy understanding of the whole risk assessment process to different levels of decision makers without any prior knowl- edge of cybersecurity while being comprehensive enough to be effective [13]. Because of its comprehensibility and ease of use, this model is widely being used in many industries including the automotive section [12]. One of the main goals of TARA methodology is to reduce the cost of risk assess- ment by limiting the area of concern to the ones that are most critical and vulnerable within a system. This way the result becomes maximized with the minimum cost. 26 4. Attack Analysis Methodologies In order to determine the most exposed area within a system while having known vulnerabilities and corresponding mitigation techniques in mind. TARA needs to identify the most hazardous attackers and their intended goals as well as different techniques they use to reach their desired results. The Defense-in-Depth strategy [46], developed by Intel IT, is an attempt to optimize the security process by interlocking four different phases: • Prediction: An attempt to anticipate all possible and existing threats. • Prevention: An attempt to prevent threats from happening by utilizing dif- ferent limitations. • Detection: An attempt to identify actual threats by analyzing the system. • Response: An attempt to design mitigation techniques against actual and possible threats. TARA methodology can be mapped into the prediction phase. The main objective of this method is to implement an optimal mitigation strategy by identifying the most probable attack paths. Unlike other methodologies providing more general vulnerability treatment, TARA as mentioned before, offers a security strategy by focusing on areas having the highest overall risk [47]. Figure 4.2 illustrates the pro- cess of narrowing down the field of attacks. In this model, Intel provides a specific definition of attackers or the so-called threat agents as follows: “Threat agents are attackers who represent a security risk of loss, and they are clas- sified by characteristics including skills, capabilities, resources, intent, and access." In order to make a predictive conclusion, TARA relies on three different components: • Threat Agent Library (TAL): This factor defines eight different threat agent attributes whose combination generates 22 unique threat agent archetypes such as disgruntled employee or organized crime [47]. • Common Exposure Library (CEL): This factor maintains known security vulnerabilities and exposure of the system under consideration. • Methods and Objectives Library (MOL): This factor covers the list of known threat agent objectives including their goals and the most likely strate- gies they exploit in order to reach their goals [47]. In order to identify the likelihood of possible attacks, by considering many factors such as typical methods, preferred vulnerabilities, objectives, and resources, MOL factor is multiplied by TAL. In this way, an estimation of consequences is derived accordingly. 27 4. Attack Analysis Methodologies Figure 4.2: Constriction of the field of attacks By bringing CEL factor into the game, vulnerabilities with sufficient controls and low risks are removed from the process, and the remaining attack vectors are con- sidered as the area with the highest risk. Figure 4.3 shows TARA threat modelling process where a complete filtering of threats happens through six different stages. Through these stages, areas with lower risks are removed from the security experts spotlight while areas with the highest exposure remain. 28 4. Attack Analysis Methodologies Figure 4.3: Multiple stages of TARA process in detail 4.2 STRIDE STRIDE is a system-centric threat modelling approach, proposed by Microsoft in 1999, commonly used in their own product development process as well as many other industries including the automotive section [12]. This method is supported by some of the most prominent secure software schemes such as OWASP’s Comprehen- sive, Lightweight, Application, Security Program (CLASP) [48] and Microsoft’s SDL [49]. STRIDE is an acronyms induced from different classification of threats that might endanger the system under consideration, these classifications are as follow: • Spoofing: Attackers obtains illegitimate access to sensitive information by manipulating their identity. This threatens system’s confidentiality according to CIA triad. • Tampering: Manipulating the data traversing communication channels or stored in a database. This is considered as a violation of the Integrity accord- ing to CIA triad. • Repudiation: The inability to trace back an attack to identify the potential attacker. 29 4. Attack Analysis Methodologies • Information disclosure: Unauthorized access of the attacker to the data in transit or in a database. • Denial of Service: Any attempt of the attacker for disrupting the normal operation of the system and making it out of service. • Elevation of privilege: Attacker gains unauthorized access to a system en- abling him to perform critical operations by attaining root privilege in the system. The whole process of threat analysis by STRIDE model can be described in four consecutive steps [50]: Building the dataflow diagrams STRIDE model uses DataFlow Diagrams (DFDs) as an input to the threat analysis process. These DFDs are graphical representations of the system from the attacker’s perspective. This is used by security analysts in order to scan the levels of trust throughout a system [51]. Levels of trust are modelled in the DFD as a trust boundary, where the communication of data happens between trusted and untrusted components [52], [53]. Modelling different components in DFD is considered as the initial step that provides the scope for threat analysis [53]. Mapping the dataflow diagrams onto existing threat categories There are two different ways of performing threat modelling via STRIDE: (i) per ele- ment and (ii) per interaction. Comparatively, STRIDE-per-element is more complex to perform since every component of the DFD needs to be analyzed. On the other hand, STRIDE-per-interaction is easier to perform and its treatment strategies are considered as effective enough since most of the cybersecurity threats comprises ma- licious interactions among system components [54]. These transactions are shown in Figure 4.4. After building up the dataflow diagram, based on STRIDE-per-element, different components of the diagram need to be analyzed according to six different threat categories mentioned above. However, one might choose STRIDE-per-interaction as it is more convenient to deploy where different malicious interactions between differ- ent components need to be classified according to aforementioned threat categories. Threat Analysis After mapping system’s DFD onto provided threat categories in STRIDE, threat analysis comes into the process. In this stage, checklists provided by STRIDE for each of the six categories need to be examined. These checklists are provided in the form of an attack tree, as shown in Figure 4.5, presenting the hierarchy of 30 4. Attack Analysis Methodologies Figure 4.4: DFD created with MS threat modelling tool [55] threat patterns that can be mapped according to the system under investigation. STRIDE reference book [56] offers twelve different attack trees that each could be used as a checklist for a corresponding category [49]. The reason behind providing a tree-based checklist is to simplify the navigation and rationalization of the relation between different threats. The result derived from this stage is used as an input for the risk assessment process. Figure 4.5: Attack tree example showing the data flow tampering 31 4. Attack Analysis Methodologies 4.3 DREAD After the threat analysis stage, DREAD method, which is also a Microsoft model, can be utilized during the risk assessment process. This method actually influences the process of quantifying, prioritizing and consequently categorizing the associ- ated risks. It is comprised of five different categories for risk analysis. DREAD is an acronym derived from the initial letters of each of these five categories including [51]: • Damage potential: Quantifying the scope of a damage derived from ex- ploitation of a known vulnerability. • Reproducibility: Ranking the likelihood of a successful exploitation of a known vulnerability. • Exploitability: Quantifying the efforts that an attacker needs for a success- ful exploitation of a known vulnerability. This could also be considered as a precondition that an attacker might need in order to perform a successful attack. • Affected users: A value representing the number of installed instances of the system that would be affected if an exploit becomes widely available. • Discoverability: This factor specifies the probability that an unpatched vul- nerability can be found by external security researchers, hackers, etc. Each of the five aforementioned categories is valued by DREAD on a rating scale of 0-10. As the rate grows from 1 to 10, it represents higher probability of occurrence with a higher damage potential. Accordingly, the overall risk to the system could also be calculated based on the provided formula shown in Figure 4.6. This formula uses the average of the values of DREAD’s five categories. Trivially, the calculated risk always resides between 0-10 where a higher value represents higher risk to the system. Figure 4.6: DREAD algorithm’s equation for risk calculation 4.4 Attack Graph Attack graphs are a powerful modelling technique used for representing the paths through which attacks can be performed to reach a malicious goal [57]. In general, nodes in an attack graph depict the states of the system while an attack is hap- pening. These nodes are categorised into starting state, intermediate states and the 32 4. Attack Analysis Methodologies goal state. Edges, on the other hand, represent the actions taken by the attacker to transit from one state to another until reaching the final goal. For instance, as shown in Figure 4.7, consider a scenario in which the attacker (Eve) attempts to gain the root access on a target machine (Alice) by using vulnerabil- ities on the other hosts (Bob and Charlie) in the system. There is an open port on Charlie’s machine with a remotely-exploitable vulnerability. Furthermore, the firewall only allows the traffic destined to Bob’s machine to pass and all other traf- fic is dropped. Bob has the network address of Alice and can freely communicate with her. In addition, Alice’s machine does not have a tight security, namely the remote login feature and the FTP service are vulnerable and root access can also be acquired by exploiting buffer overflow. Figure 4.7: Simple scenario for an attacker escalating its privileges Figure 4.8 represents the attack graph corresponding to the scenario above. The attacker exploiting the vulnerability associated with the open port, gains remote ac- cess to Charlie’s machine. Once there, the attacker is allowed to communicate with Bob, as the firewall only permits incoming traffic destined to Bob’s machine. Subse- quent to compromising Bob’s machine, the attacker can either use the remote login feature or deploy a new hosts file using FTP to access Alice’s machine. Eventually, the attacker exploits buffer overflow to obtain the root access. Figure 4.8: Attack graph modelling of the privilege escalation scenario 33 4. Attack Analysis Methodologies 4.5 Attack Tree Attack trees are another popular attack modelling technique that are used to anal- yse different attacks or threats leading to those attacks in order to identify different possible paths to achieve a malicious goal [57]. In other words, they are used to structure the process of identifying attacks endangering a particular system or tar- get. There are three different types of nodes in an attack tree [57]. The first type are the leaf nodes that are located in the deepest level of the tree and play the role of the initiators of the attack paths. They are in fact attacks or actions that can be performed without any further requirement. The second type of nodes are the OR nodes. When an attack is represented by an OR node in an attack tree, it means that each of the immediate children of this node is a possible path for this attack to take place, in other words, OR nodes indicate possible options for an attack to occur. The third type of nodes are the AND nodes. When an attack is depicted by this node, it means that the immediate children of this node must all happen in order for the main attack to happen itself. Otherwise stated, AND nodes indicate constraints related to the attack on the layer above. Figure 4.9 illustrates a simple attack tree modelling possible attack paths to ac- quire a user’s password. The red node in the root of the tree represents the goal of the attacker, which in this case is obtaining the user’s password. To do so, four different options are available: online guessing, convincing the user to reveal the password, learning when user is typing the password and obtaining the password from the passwd file. Since online guessing can be considered as an atomic action, it is not further broken down into smaller steps. On the other hand, persuading the user and learning while typing can each be done in two distinct ways (this means that "persuading the user" and "learn while typing" are OR nodes). In contrast, to retrieve the password from the passwd file, two conditions must hold: accessing the password hash and performing a dictionary attack (this means that the "retrieve from passwd" is an AND node). Although attack trees look simple and straightforward in the first sight, there are some challenges associated with them that should be taken into consideration. For instance, the attack tree can be drawn in various versions. The root of the tree can be either an asset that is interesting for an attacker or the attacker’s goal, which is the attacker’s intention for performing the attack. It should be noted that each version will result in a different type and number of trees. The other issue is the depth of the tree. The atomic attacks and actions need to be identified in order to play the role of the leaf nodes, otherwise each node can be broken down infinitely many times and this can make the tree excessively deep. 34 4. Attack Analysis Methodologies Figure 4.9: Modelling attacks trying to obtain a user’s password using attack tree Attack tree design There are no predefined rules for drawing an attack tree and its design depends on the taste and the need of the designer. However, some steps can be considered when designing an attack tree: A) In the first step, the attacker’s goal and the threat scenarios endangering a sys- tem must be defined. Once the threat analysis and the asset identification processes are finished, the output is a list of threat scenarios. B) Each threat scenario can be translated into an attack path. In other words, in this step how an attack can be mounted is identified. To have an attack path that is as accurate as possible some knowledge regarding how the attack is actually performed is required. C) Next, the type of the nodes must be determined. To show the attack paths on an attack tree, nodes, except for the root, can either be the actions taken by the attacker to realize the attack or be the vulnerabilities exploited by the attacker to reach his goal. D) The process of drawing each attack path initiates with a top-down approach starting from the root. In each step, an attack is broken down into smaller steps until a point is reached where the node can not be further broken down. 35 4. Attack Analysis Methodologies 4.6 Miscellaneous Models • OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evalua- tion) is a risk-based strategic assessment and planning technique for security [58]. It is considered as a self-directed approach. Unlike most of the assess- ments of a system which focuses on technological risks and tactical issues, OCTAVE highlights organizational risk and focuses on strategic and practical issues. In order to address the security requirements, OCTAVE considers the whole organization and people from both information technology and other operational departments. According to Figure 4.10, OCTAVE claims to assist organizations in balancing three key aspects of any network infrastructure, namely operational risks, security practices, and technology. Figure 4.10: Three key aspects balanced by OCTAVE [58] OCTAVE is an asset-driven evaluation approach. Teams that perform an analysis on a specific system or infrastructure [12]: 1. Identify critical information-related assets (e.g. information and sys- tems). 2. Focus the risk analysis tasks on the assets that are being evaluated as the most critical to the organization. 3. Consider the vulnerabilities (both organizational and technological) of the critical assets, the threats against those vulnerabilities and the rela- tionship among associated assets. 36 4. Attack Analysis Methodologies 4. Evaluate risks from the operational point of view - how the assets are used in organization’s business and how they are at risk because of the security threats. 5. Create a practical defense mechanism for organizational improvement together with a mitigation strategy in order to reduce the risk concerning the critical assets. According to the aforementioned description, this strategy sheds more light on the organizational aspects rather than technological ones. However, vehicular industry needs a framework that focuses on the technological aspect during the whole product development process. Therefore, we find this strategy not applicable to the needs of automotive sector. • PASTA (Process for Attack Simulation and Threat Analysis) is a strategy that seeks to provide an attack simulation process together with a cyber threats analysis scheme and ultimately to reduce the cyber-crime risks derived from these threats by utilizing mitigation strategies. As shown in Figure 4.11, in order to reach the above goals, PASTA conducts seven consecutive steps for the sake of threat and risk analysis [59]. By following these seven stages, any business can characterize required mitigation factors to address the risks associated with the cyber-threats and consequent attacks to an application. PASTA combines system level or application level threat analysis with busi- ness objectives, business analysis, and compliance [59]. Despite the fact that it is possible to adapt this method to different environments, since this model focuses on shareholders and business impact of security threats, we consider it as mostly compatible with business models rather than product development process. Therefore, we classify this model as miscellaneous when it comes to the needs of the automotive industry. • Cyber Kill Chain has been developed by an American global aerospace, defense, security and advanced technologies company called Lockheed Martin [60]. This method focuses on different steps that an attacker needs to take in order to accomplish his malicious goals. In each stage, attacker needs to fulfill a specific objective in order to move to the next one. In this way, this method offers a step-wise concentration where the company is recommended to prepare security concerns by focusing on relevant assets in their system. The name of this method is derived from the seven consecutive steps or chain of actions needed to be passed by an attacker in order to penetrate and exploit a system [60]. These seven steps of Cyber Kill Chain are as follow: – Reconnaissance: Research, identification and selection of the target. – Weaponization: Creating a malicious package to be sent to the target. 37 4. Attack Analysis Methodologies Figure 4.11: PASTA model of threat and risk analysis – Delivery: The malicious package is delivered to the target by e-mail or other means, and this represents just one of many intrusion techniques the attacker can use. – Exploitation: Refers to the actual execution of the malicious package on the target system. – Installation: Refers to installing a backdoor trojan or similar which would grant remote access to the target machine over a longer period of time. – Command and Control: Establishing an outside connection or a chan- nel by which the attacker can gain “command and control” over the target machine from a remote location. – Actions on objectives: This is the final step of the attack which can take months to successfully be performed. The attacker performs actions that would accomplish his initial goal [60]. 38 4. Attack Analysis Methodologies One of the advantages that this method poses is that it tries to analyze the attacker’s behavior pattern and mindset while focusing on the target asset. In order to provide security countermeasures to the existing threats and defend the system from future possible attacks, the corporation needs to analyze the chains of attacks that were performed earlier. Hence, it is expected that if this method is performed correctly, the company can always be one step ahead of the attacker from the cybersecurity point of view. Again, like the two other methodologies described earlier in this section, Cyber Kill Chain is more useful for the business level rather than product development. Thus, we list this method as a miscellaneous one. 39 5 Feasibility Once the attack paths are determined, an estimation of how easy or hard it is to exploit an attack path should also be taken into account. This estimation is known as attack feasibility. Since feasibility calculation should be able to be done in both the concept phase, in which all details are not known, and the design phase, in which more concrete features of the system are known, some parameters must be defined to ease the estimation process. The definition of these parameters, also known as attack potentials, are explained in the following section. 5.1 Analysis parameters Several attack potentials can be considered when it comes to estimating how likely is for an attack to happen. The five prominent ones that will directly be used to calculate the feasibility of an attack are described in this section. Furthermore, in Chapter 9, the reason for excluding the rest of the parameters from the calculation process is explained. In order to ensure the compliance with the recent trend in the automotive industry, the names of these parameters are kept the same as in ISO/IEC 18045. Equipment (Eq) or the availability of resources refers to hardware or software equipment required for exploiting an attack path: • Standard. The equipment is readily available and easily accessible to the at- tacker. This equipment can also be a part of the TOE itself, e.g. a built-in debugger in the operation system. Examples for this type can be a notebook or a simple diagnostic device that can be purchased for a moderate amount of money. 41 5. Feasibility • Specialised. The equipment is not readily available to the attacker, but can be obtained without excessive effort. This equipment is more automotive specific and can be a developed script or program or even a standard tool but for a higher price. Examples for this type can be an automotive-specific debugger or an RF monitor or a costly diagnostic device. • Bespoke. The equipment is not readily available to the public and its distri- bution is restricted. This equipment is normally specially made and is consid- erably more expensive that the previous categories. Examples of this type are tools that are custom-made. • Multiple Bespoke. This type allows a situation in which various types of Be- spoke equipment is needed to exploit an attack path. Expertise (Ex) or the skill level refers to the amount of knowledge required to exploit an attack path: • Layman. The attacker has very limited knowledge about the vehicles. He has no expertise in the automotive domain and normally has only IT skills for domestic usage. In addition, he can only use ready-to-use tools with clear instructions. • Proficient. The attacker has general knowledge about the vehicles and is fa- miliar with security behavior of the product, as he is probably involved in the automotive industry. He can not develop new attacks, but can use available tools to exploit an attack path even if the instructions are not clear. • Expert. The attacker has knowledge about the existing algorithms, protocols, hardware, software, cryptographic approaches, security behaviors and concepts in the security domain and the automotive industry. He is able to develop new tools and methods to exploit attacks paths. • Multiple Experts. The attacker has multiple fields of expertise to exploit at- tack paths. Here, the fields of expertise must be distinct from one another for the attacker to fall under this category . Knowledge of the TOE (Kw) or awareness refers to specific expertise in terms of information about the system under scrutiny required by the attacker to exploit attack paths: • Public. The information related to the TOE is accessible by public. Informa- tion available on the Internet or in a book that can easily be purchased by everyone fall under this class. For instance, the information regarding com- munication protocols such as Transmission Control Protocol (TCP) or CAN. 42 5. Feasibility • Restricted. The information related to the TOE is shared and controlled by partners under a non-disclosure agreement. An example of this class can be information shared among involved organizations such as the supplier and the manufacturer. • Sensitive. The information related to the TOE is shared among teams within one organization and the access is only restricted to the members of those teams. Information such as source code or the vehicle configuration database fall under this category. • Critical. The information related to the TOE is shared among a few individu- als and access to this information is strictly restricted on a need to know basis to those individuals. Information such as security keys fall under this class. Window of opportunity (Wo) or opportunity refers to the amount of access re- quired by an attack to be carried out: • Unlimited. The attack does not need any opportunity to be realized as there is no risk of being detected during the access. In other words, the TOE is available without any time limitation. Unlimited physical access to the target or always-on Internet connection fall under this category. • Easy. The attack only requires less than a day of access to the TOE to be realized. • Moderate. The attack only requires less than a month of access to the TOE to be realized. • Difficult. The attack requires at least a month of access to the TOE to be realized. In case the window of opportunity is not sufficient enough, in other words, the available time to exploit an attack is less than the time required by the attack to be realized, the attack would not be possible to be performed. Elapsed time (Et) refers to the time required to exploit an attack path. Iden- tification of a vulnerability and exploitation of the corresponding attack path may need considerable time. However, since the time needed for identifying a vulnerabil- ity may significantly differ from the time needed for exploiting an attack path due to some probable intervals in the vulnerability identification phase, for the sake of accuracy, only the amount of time needed for exploiting an attack path is considered as the elapsed time. • Less than a day. The attack takes less than a day to be performed. • Less than a week. The attack takes less than a week to be performed. 43 5. Feasibility • Less than a month. The attack takes less than a month to be performed. • More than a month. The attack takes more than a month to be performed. 5.2 Parameter rating Likelihood estimation of an attack path is possible through assigning a value to each of the parameters explained in the previous section. Since each attack potential is classified into four levels, values 0-3 is assigned to each of them, as shown in Table 5.1. Value 0 is assigned to the worst case or the most relaxed condition while 3 is assigned to the least relaxed one. Table 5.1: Attack potential values Parameter Value Equipment Standard 0 Specialised 1 Bespoke 2 Multiple Bespoke 3 Expertise Layman 0 Proficient 1 Expert 2 Multiple Experts 3 Knowledge of the TOE Public 0 Restricted 1 Sensitive 2 Critical 3 Window of opportunity Unlimited 0 Easy 1 Moderate 2 Difficult 3 Elapsed time Less than a day 0 Less than a week 1 Less that a month 2 More than a month 3 44 5. Feasibility Once all the parameters are evaluated, the overall feasibility of an attack path must be calculated. A straightforward and linear formula, as shown in Figure 5.1, is used to ease the reasoning and the calculation of the feasibility. For each parameter, the final value corresponds to the multiplication of its value in its weight. However, due to complicated interrelation of the parameters, we do not assign weight (priority) to the parameters in this stage and assume that all of them are equally important (w=1). Figure 5.1: Linear formula for feasibility calculation The calculated Sum will be later mapped to the corresponding feasibility value in Table 5.2. It should be noted that a basic attack path, for instance an attack path having standard equipment, a non-expert attacker and public knowledge of the tar- get with no need for an opportunity to be realized, is more likely to be exploited, and consequently its feasibility would be higher. In contrast, higher required level of the attack potentials makes the exploitation of the attack paths more difficult, and consequently the corresponding feasibility would be lower. Table 5.2: Feasibility calculation framework Sum Feasibility 0 - 2 Very high 3 - 6 High 7 - 9 Moderate 10 - 12 Low >12 Very low In the following chapter, some scenarios are evaluated by means of the attack trees. Once the attack paths are discovered in each scenario, in order to present examples of feasibility calculation, the feasibility of some of the paths will be calculated. 45 6 Use cases In this section, we model two scenarios by means of attack trees to demonstrate how our nominated modelling technique works in the automotive world. It is worth mentioning that the reason for selecting attack trees over other methodologies is thoroughly explained in Chapters 7, 8 and 9. The type of the attack tree we use to model such scenarios is the one in which the root of the tree is the attacker’s goal and not the asset itself. There are two reasons behind this decision: first, if a scenario contains multitude of assets, using each asset as the root of the tree results in one attack tree for each asset. Given the real-world use cases where tens of assets are involved in a scenario, this would result in unnecessary many trees, which consequently makes the analysis difficult. Second, based on our experiments, selecting the attacker’s goal as the root of the tree results in a more comprehensive and realistic attack tree. Furthermore, in order to have a better alignment with the CIA triad classification, we decided to select the CIA triangle faces as the root of the tree in all scenarios. As a result, in both of the use cases, the attacker’s goal is violating one or more of the confidentiality, integrity or availability of the system, where applicable. Prior to explaining each use case, the reference architecture on which our scenarios are defined should be presented. Figure 6.1 depicts the HoliSec reference architec- ture [33] that inherits all of its attributes from HEAVENS, except for some features that have been improved [61]. As it can be seen in the figure, engine and brake ECUs that are categorized as power train ECUs are connected to the main gateway via CAN network. The connectiv- ity gateway which is responsible for infotainment and telematic is connected to the back office and is equipped with both physical and remote interfaces. The two other entities in the architecture are V2X ECU and the driver display that have remote 47 6. Use cases Figure 6.1: HoliSec reference architecture communication with other vehicles and the vehicle passengers, respectively. The driver control on the other hand is connected to the sensors, namely the camera and the radar to both serve the user with some information via the driver display and to send information to other components in the architecture. Finally, the ve- hicle ECU represents a general ECU in a vehicle that handles several responsibilities. There are two physical networks connecting ECUs and gateways in this generic ar- chitecture. The CAN network whose benefits were discussed in Section 2.3 and the Ethernet network which is automotive specific and is normally used where high bandwidth is needed [32]. Aside from the physical connections, as illustrated in Figure 6.1, some of the ECUs and gateways are also equipped with wireless inter- faces. All these interfaces can be categorized into two groups of internal and external. Table 6.1 lists the ECUs in addition to their software architecture, interfaces and a summary of their role in the system. 48 6. Use cases T ab le 6. 1: H ol iS ec re fe re nc e ar ch ite ct ur e en tit ie s U ni ts So ft w ar e ar ch it ec tu re In te rf ac es R ol e In te rn al E xt er na l Ve hi cl e EC U A U T O SA R C A N — Se nd s sp ee d sig na ls an d re sp on sib le fo r th e wa rn in g lig ht s En gi ne EC U A U T O SA R C A N — R es po ns ib le fo r th e en gi ne sy st em Br ak e EC U A U T O SA R C A N — R es po ns ib le fo r th e br ea ki ng sy st em V 2X EC U Li nu x Et he rn et W iF ia nd 4G C om m un ic at io n w ith ot he r ve hi cl es , in fra st ru ct ur e, et c. C on ne ct iv ity ga te wa y A U T O SA R (in te rn al ), Li nu x (E xt er na l) Et he rn et W iF i, Bl ue to ot h, 4G an d U SB G PS po sit io n, co lle ct s fle et in fo rm at io n to se nd to th e ba ck offi ce ,h as th e im m ob ili ze r st at us Ed ge no de ga te wa y A U T O SA R C A N an d Et he rn et C A N ,E th er ne t an d W iF i D ia gn os tic re sp on se to ex te rn al re so ur ce s, tr an sla te s an d fo rw ar ds sig na ls be tw ee n ne tw or ks D riv er co nt ro l A U T O SA R C A N an d Et he rn et Bl ue to ot h an d U SB Tr an sla te s an d fo rw ar ds sig na ls be tw ee n ne tw or ks D riv er di sp la y Li nu x Et he rn et — V isu al iz in g in fo rm at io n fo r th e dr iv er 49 6. Use cases Before explaining the use cases and how our proposed methodology is used to model attack paths, some general assumptions must be made that hold for both of the use cases: (1) Only the ECUs having a role in the scenarios are evaluated in each use case. (2) In the reference architecture we received, some ECUs were not ex- plained in details. Hence, we had to make some assumptions for each of them in terms of interfaces, software architecture and how they play their role in the sce- nario. Nevertheless, the assumptions are close to the real-world scenarios based on the interviews we had with the industrial experts. (3) Attack trees can be deepened almost indefinitely, however, as mentioned before, it is important to decide where to cut the tree. In our use cases, we deepened the trees based on the information we managed to acquire about each attack path and as long as each level was still in the automotive domain. (4) An attacker may have two different types of goal. First, the moral goals such as threatening passenger’s life, annoying the driver and the like and second, the technical goals such as disabling a service or manipulating a parameter. In the following use cases, the technical goals are addressed only. (5) Attacks are initiated from potential attack surfaces, hence, whenever possible, we tried to have the attack surfaces as the leaves of the tree, and (6) Wherever pos- sible, the attack path is divided into a path starting from a physical interface and a path starting from a remote interface. This separation is done because the feasi- bility of an attack path may differ when started from a physical or a logical interface. 6.1 Use case 1: GPS positioning and warning lights In this scenario, the vehicle gathers the GPS position from the connectivity ECU as well as the warning lights from the vehicle ECU. This information is broadcast from the V2X ECU to other nearby road vehicles. Figure 6.2 shows this scenario as well as the signal paths. Signals: warning light signals are broadcast from the vehicle ECU. They traverse the CAN network and are forwarded by the driver control to the Ethernet network. Later, the edge node gateway forwards the signals to another Ethernet network. Finally, they are received by the V2X ECU to be broadcast to other vehicles. On the other hand, GPS position signal is sent from the connectivity gateway over the Ethernet network. Edge node gateway forwards this signal to another Ethernet channel. Eventually, the signal is received by the V2X ECU to be broadcast to other vehicles. 50 6. Use cases Assumptions 1) In this scenario, we do not see violating confidentiality as an issue, as both the warning light signals and the GPS signal are going to be broadcast to other entities on the road. Hence, only attack paths violating integrity and availability are ad- dressed. 2) The OBD port is considered a physical interface, however nowadays there are some