ENISA good practices for security of Smart Cars

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS Security and Resilience for NOVEMBER 2019 Smart Health Service and Infrastructures

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

ABOUT ENISA

The European Union Agency for Cybersecurity (ENISA) has been working to make Europe cyber secure since 2004. ENISA works with the EU, its member states, the private sector and Europe’s citizens to develop advice and recommendations on good practice in information security. It assists EU member states in implementing relevant EU legislation and works to improve the resilience of Europe’s critical information infrastructure and networks. ENISA seeks to enhance existing expertise in EU member states by supporting the development of crossborder communities committed to improving network and information security throughout the EU. Since 2019, it has been drawing up cybersecurity certification schemes. More information about ENISA and its work can be found at www.enisa.europa.eu.

CONTACT

For contacting the authors please use iot-security@enisa.europa.eu. For media enquiries about this paper, please use press@enisa.europa.eu.

AUTHORS

ENISA

ACKNOWLEDGEMENTS

Charalambos Tsitlakidis, European Commission – DG Communications Networks, Content and Technology Christophe Jouvray, Valeo Markus Tschersich, Continental Gianmarco Baldini, European Commission – DG Joint Research Center Jasja Tijink, Kapsch Trafficcom AG Erwan Broquaire, Cerema Jocely Delatre, ACEA Ba Sadio, the National Cybersecurity Agency of France (ANSSI) Dimitri Havel, Aston Martin Lagonda Andy Davis, NCC Group Carsten Maple, University Of Warwick, UK Timo Van Roermund, NXP Semiconductors Alessandro Farsaci, CNH Industrial - Iveco Commercial Vehicle Ian Smith, GSMA Reda Yaich, IRT SystemX Johan Lindqvist, Volvo Cars

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Christian Wieschebrink, the Federal Office for Information Security (BSI), Germany Jan Muenther, Here Technologies Christian Urban-Seelmann, Wabco Horst Klene, Volkswagen AG Mouhannad Alattar, Alliance Renault-Nissan-Mitsubishi Lorenzo Perrozzi, Garrett Advancing Motion Achim Fahrner, ZF Friedrichshafen AG Michael Feiri, ZF Friedrichshafen AG Jan de Meer, Association for Computing Machinery Eetu Pilli-Sihvola, the Finnish Transport and Communications Agency Traficom Jacques Kunegel, ACTIA Group Joachim Lueken, Nokia Bell Labs Julien Burlet, National Gendarmerie, Ministry of the Interior, France Thomas Born, Vodafone

LEGAL NOTICE

Notice must be taken that this publication represents the views and interpretations of ENISA, unless stated otherwise. This publication should not be construed to be a legal action of ENISA or the ENISA bodies unless adopted pursuant to the Regulation (EU) No 2019/881. This publication does not necessarily represent state-of the-art and ENISA may update it from time to time. Third-party sources are quoted as appropriate. ENISA is not responsible for the content of the external sources including external websites referenced in this publication. This publication is intended for information purposes only. It must be accessible free of charge. Neither ENISA nor any person acting on its behalf is responsible for the use that might be made of the information contained in this publication.

COPYRIGHT NOTICE

© European Union Agency for Cybersecurity (ENISA), 2019 Reproduction is authorised provided the source is acknowledged. ISBN 978-92-9204-317-9, DOI 10.2824/17802

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

TABLE OF CONTENTS

1. INTRODUCTION 6

1.1 OBJECTIVES 7

1.2 SCOPE 8

1.3 EU AND INTERNATIONAL POLICY CONTEXT 8

1.4 TARGET AUDIENCE 10

1.5 METHODOLOGY 11

1.6 STRUCTURE OF THE DOCUMENT 12

2. SMART CARS: CONNECTED AND (SEMI-) AUTONOMOUS CARS 13

2.1 DEFINITIONS 13

2.2 HIGH-LEVEL REFERENCE MODEL 15

2.3 SMART CARS INFRASTRUCTURE AND BACKEND SYSTEMS: 16

3. THREATS AND ATTACK SCENARIOS 18

3.1 THREATS TAXONOMY 18

3.2 EXAMPLES OF SMART CARS CYBER SECURITY ATTACK SCENARIOS 21

4. SECURITY MEASURES AND GOOD PRACTICES 27

4.1 SECURITY MEASURES CATEGORISATION 27

4.2 POLICIES 28

4.2.1 Security by design 28 4.2.2 Privacy by design 28 4.2.3 Asset Management 28 4.2.4 Risk and Threat Management 29

4.3 ORGANISATIONAL PRACTICES 29

4.3.1 Relationships with Suppliers 29 4.3.2 Training and Awareness 29 4.3.3 Security Management 30 4.3.4 Incident Management 30

4.4 TECHNICAL PRACTICES 30

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

4.4.1 Detection 30 4.4.2 Protection of Networks and Protocols 31 4.4.3 Software Security 31 4.4.4 Cloud Security 32 4.4.5 Cryptography 32 4.4.6 Access Control 32 4.4.7 Self-Protection and Cyber Resilience 32 4.4.8 (Semi-) Autonomous Systems Self Protection and Cyber Resilience 33 4.4.9 Continuity of Operations 33

5. ABBREVIATIONS 34 6. BIBLIOGRAPHY/REFERENCES 37 ANNEX A: ASSET TAXONOMY 48 ANNEX B: THREAT TAXONOMY 54 ANNEX C: SECURITY MEASURES MAPPING 63 ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

EXECUTIVE SUMMARY

This report defines good practices for security of smart cars, namely connected and (semi-) autonomous vehicles, providing added-value features in order to enhance car users’ experience and improve car safety. Taking stock of all existing standardization, legislative and policy initiatives, this report aims to serve as a reference point to promote cybersecurity for smart cars (connected and automated cars) across Europe and raise awareness on relevant threats and risks with a focus on “cybersecurity for safety”.

The automotive industry is undergoing a paradigm change towards connected and autonomous vehicles . Smart cars already available today provide connected, added-value features in order to enhance car users’ experience or improve car safety. With this increased connectivity (that the emergence of 5G is expected to further promote) novel cybersecurity risks and threats arise and need to be managed.

It is undeniable that there is a rapid pace when it comes to technological advancements in the area of connected and autonomous cars. With the emergence of semi-autonomous and autonomous cars, which make use of advanced machine learning and artificial intelligence techniques, the potential risks and cybersecurity challenges increase. Moreover, Vehicle-to- Vehicle (V2V) and Vehicle-to-Infrastructure (V2I) interfaces needed for the deployment of intelligent transport systems and autonomous cars, further exacerbate security risks since they largely expand the potential attack surface and attack vectors.

With the increasing smart cars connectivity and the emergence of (semi)-autonomous cars, novel cybersecurity challenges, risks and threats are arising. Attacks targeting smart cars may lead to vehicle immobilization, road accidents, financial losses, disclosure of sensitive and/or personal data, and even endanger road users’ safety. Thus, appropriate security measures need to be implemented to mitigate the potential risks, especially as these attacks threaten the security, safety and even the privacy of vehicle passengers and all other road users, including pedestrians.

It is therefore important to analyse the relevant threats and cybersecurity risks pertaining to smart cars and put forward security measures to address these risks taking into account the particularities of this highly complex, heterogeneous and volatile environment.

Accordingly, this ENISA study provides the following information:

 High level reference model of connected and autonomous vehicles.  Detailed asset and threat taxonomy for the connected and autonomous vehicles ecosystem.  Concrete and actionable good practices to improve the cybersecurity posture of connected and autonomous vehicles.  Mapping to existing legislative, standardization and policy initiatives to foster harmonization.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

1. INTRODUCTION

Over the last few years, the automotive industry has undergone a paradigm change towards increasingly connected and autonomous cars. Smart cars available today are vehicles equipped with systems providing connected and added-value features in order to enhance car users experience and/or improve car safety. Within the next few years, smart cars’ connectivity is expected to expand and smart cars will become connected to other vehicles, pedestrians and their surrounding infrastructure through information exchanges via Vehicle-to-Everything (V2X) communications . Semi-autonomous and autonomous cars (i.e. levels 4 and 5 of autonomy as defined in SAE J3016 ), which make use of advanced Machine Learning (ML) and Artificial Intelligence (AI) techniques, are also emerging. Indeed, several smart cars stakeholders (including car manufacturers, system suppliers, road operators and other providers) are already carrying out trials of supervised autonomous vehicles, with a driver on board ready to take control of the car if necessary.

In recent years, there has been a growing interest in autonomous cars both from end users and manufacturers and deployment of smart cars has a growing rate in the automotive market . According to a survey of 5,500 global city dwellers from all around the world , 58% of global respondents are willing to take a ride in a driverless vehicle. Acceptance rates are higher in emerging markets such as China (75%) and India (85%) than in European countries such as United Kingdom (49%) and Germany (44%). However, the European economy is expected to benefit from autonomous vehicles , as EU gathers 23% of global motor vehicle production. Moreover, almost 72% of inland freight is transported by road in Europe, and trust in Original Equipment Manufacturers (OEMs) is strong. While optimistic predictions mention that fully automated vehicles could be widely deployed by 2030 , scientific experts are more cautious and underline that further research is still required to build a fully autonomous vehicle, mostly in the fields of AI and cybersecurity .

Cybersecurity is a crucial aspect that will affect the evolution of smart cars. There have already been several research publications on attacks targeting smart cars. One of the most known attacks is the spectacular proof-of-concept remote attack where the researchers took control of a vehicle and sent it off-the-road, thus leading to the recall of over a million cars. Lately, some researchers also demonstrated that it was possible to locally or remotely take control of smart

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

cars infotainment system by exploiting diagnostic services to manipulate smart cars functions. Moreover, security specialists succeeded to hijack cars using their smart alarm, thereby illegitimately performing actions such as enabling/disabling the immobilizer or cutting the engine . Towards the objective to provide a generic development and evaluation environment for vehicle cybersecurity technologies, an open-source testing platform called PASTA (Portable Automotive Security Testbed with Adaptability) was recently released; it simulates the remote operations of vehicle wheels, brakes, windows, and other features to learn more about the electronic communications features and find vulnerabilities as well as test exploits. However, such a platform may also be used by an attacker, thus facilitating their tasks.

With the increasing smart cars connectivity and the emergence of (semi)-autonomous cars, novel cybersecurity challenges, risks and threats are arising. For instance, there have been 14,15 some experimental remote attacks on autonomous cars’ cameras and Light Detection and Ranging (LiDAR) systems showing effective camera blinding, making real objects appear further than their actual locations or even creating fake objects. In addition to malicious sensor manipulations, other attack vectors have been practically demonstrated such as Global 16 17 Navigation Satellite Systems (GNSS) spoofing and fooling AI-based functions with the famous example of trapping a self-driving car by just drawing a chalk circle around the vehicle. Attacks targeting smart cars may lead to vehicle immobilization, road accidents, financial losses, disclosure of sensitive and/or personal data, and even endanger road users’ safety. Thus, appropriate security measures need to be implemented to mitigate the potential risks, especially as these attacks threaten the security, safety and even the privacy of vehicle passengers and all other road users, including pedestrians.

1.1 OBJECTIVES

This ENISA study aims at addressing the security and privacy challenges related to the evolution of smart cars. The main objectives were to collect good practices to ensure the security of smart cars, while mapping the relevant security and privacy challenges, threats, risks and attack scenarios.

More specifically, the aim of this study is to identify the good practices in order to ensure smart cars security against cyber threats, while focusing on V2X communications and (semi-) autonomous cars . Towards this end, the following objectives have been set:

 Analyse smart cars architecture and define a high-level reference model  Identify smart cars sensitive assets  Identify potential and main cyber threats, risks and attack scenarios targeting smart cars  Map identified threats to assets  Identify relevant security measures based on the threats and assets, and map the identified security measures to the relevant threat(s).

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

This ENISA study aims to serve as a reference point to promote collaborative automotive cybersecurity across the European Union and raise awareness of the relevant threats and risks with a focus on “security for safety”.

1.2 SCOPE

This ENISA study outlines good practices for the security of smart cars. It is building on the previous ENISA study on smart cars entitled “Cyber Security and Resilience of Smart Cars” and mainly focuses on V2X communications and (semi-)autonomous cars as these technologies were not previously considered.

During this study, ENISA identified available documentation and standards on smart cars cyber security, with a focus on connected and autonomous cars. ENISA also collected inputs from a number of automotive security experts through a structured questionnaire and a series of interviews. Following a thorough analysis of the identified material and the review of security experts feedbacks, ENISA identified the main assets and threats targeting smart cars. Based on these threats, a set of security measures and good practices were defined to ensure smart cars security.

The study highlights three groups of security measures to address security challenges in terms of technologies, policies and processes. A risk-based and holistic approach to security was undertaken. ENISA considered the cybersecurity of smart cars throughout their lifecycle (from conception to end-of-life) and addressed all the essential elements of automotive cybersecurity. Particular attention was paid to the overall supply chain while considering the different stakeholders involved in the smart cars manufacturing (i.e. OEM, software and hardware components providers, etc.).

1.3 EU AND INTERNATIONAL POLICY CONTEXT

 EU Policy: o Early 2014, the Commission's Directorate-General for Mobility and Transport (DG MOVE) set up a C-ITS deployment platform. This latter was conceived as a cooperative framework including national authorities, Cooperative Intelligent Transport Systems (C- ITS) stakeholders and the European Commission with the objective to identify and agree on how to ensure interoperability of C-ITS across borders and along the whole value chain, as well as to identify the most likely and suitable deployment scenario(s). o In 2017, the Directorate-General for Internal Market, Industry, Entrepreneurship and Small and Medium-sized Enterprises (SMEs) (DG GROW) launched an initiative on safety regulations with the aim to contribute to a further decrease of the number of road fatalities and injuries considering amendments to the General Safety Regulation and the Pedestrian Safety Regulation.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

o In 2018, the Directorate-General for Communications Networks, Content and Technology (DG CONNECT) launched an initiative on Cooperative, Connected and Automated Mobility (CCAM) with the aim to:  provide further guidance on a governance framework for access and sharing of data generated by connected vehicles  clarify cybersecurity requirements for the connected car environment  provide guidance on the use of pioneer spectrum for 5G connectivity for large scale testing and experimentation for connected vehicles o In 2019, the European Commission has set up an informal group of a hundred experts named “the Single Platform for open road testing and pre-deployment of cooperative, connected, automated and autonomous mobility” in order to provide advice and support regarding testing and pre-deployment activities for CCAM . o The protection of road users’ privacy and personal information is also addressed by the recent EU General Data Protection Regulation (GDPR) which officially went into effect in May 2018. o The Network and Information Security directive (NIS) also addresses autonomous vehicles’ cybersecurity issues as it intends to provide generic security measures in order to enhance cybersecurity across EU.

 International Context: o The European OEMs published a set of cybersecurity principles, through the ACEA Principles of Automobile Cybersecurity , which are already implemented by OEM companies. o The National Highway Traffic Safety Administration (NHTSA) from the U.S. government issued in late 2016 a document introducing several cybersecurity best practices for smart cars . o The US Automotive Information Sharing and Analysis Center (Auto-ISAC) has been maintaining since 2016 a series of Automotive Cybersecurity Best Practices which provide guidance on the implementation of automotive cybersecurity principles. o Several cybersecurity standards and recommendation documents are also under development. In particular, the United Nations Economic Commission for Europe (UNECE) is currently drafting a proposal for a recommendation on Cyber Security with a focus on key cyber threats and vulnerabilities against vehicles as well as measures to be considered in order to mitigate the identified threats. UNECE is also introducing a United Nations regulation on cybersecurity which defines a set of requirements that shall be fulfilled by vehicle manufacturers, suppliers and service providers, covering the entire vehicle lifecycle (i.e. from the vehicle development to its decommissioning).

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

 Standards: o The British Standards Institution (BSI) Group published in December 2018 two Publicly 32 33 Available Specifications (PAS), namely PAS 1885 and PAS 11281 . The former, which is entitled “The fundamental principles of automotive cyber security”, provides high-level guidance to provide and maintain cybersecurity. As regards to PAS 11281, entitled “Connected automotive ecosystems – Impact of security on safety – Code of practice”, it provides recommendations for managing security risks in a connected automotive ecosystem. o The European Telecommunications Standards Institute (ETSI) has been developing a set of technical specifications, ETSI TS 102 940 to 102 943 , which define an Intelligent Transport System (ITS) security architecture along with services specification to ensure information confidentiality and prevent unauthorized access to ITS services. They also address the trust and privacy management for ITS communications. o The standard of Society of Automotive Engineers SAE J3061 , officially published in January 2016, is considered as the first standard addressing automotive cybersecurity. It provides a set of high-level cybersecurity principles and guidance for cyber-physical vehicle systems. o The International Organization for Standardization (ISO) and SAE collaborated to supersede the SAE J3061 recommended practice and propose the ISO/SAE 21434 . This standard is also under development and focuses on automotive cybersecurity engineering by specifying requirements and providing recommendations for cybersecurity risk management for cars (including their components, software and interfaces) all along their entire lifecycle. Concurrently, the SAE is working on another document, SAE J3101, which aims to define common requirements for security to be implemented in hardware for ground vehicles.

In 2016, ENISA performed a study on smart cars security issues which resulted in a document entitled “Cyber Security and Resilience of smart cars” . It has also established the Cars and Roads SECurity (CaRSEC) working group which addresses smart cars cybersecurity threats, challenges and solutions so as to protect road users’ safety. CaRSEC group members are car manufacturers with focus on cybersecurity, suppliers and developers of embedded hardware/software for smart cars, road authorities and academia, as well as standardisation bodies and policy makers.

1.4 TARGET AUDIENCE

This study provides a set of good practices and security measures to improve smart cars security and mitigate the potential threats and risks. Therefore, similarly to the previous ENISA smart cars study, the target audience of this study is mainly:

 Car manufacturers: also referred to as OEMs, they design new cars and handle the assembly of the various car components. In particular, most of the various car components are not produced by the car manufacturer itself, but rather by their suppliers according to a set of functional, safety and security requirements defined by the car manufacturers.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

 Tier 1 and Tier 2 car components suppliers: provide the different car components required to produce the car. Tier 1 refers to the entities having direct contractual relationships with the car manufacturers, whereas Tier 2 refers to the entities having contractual relationships with Tier 1 suppliers. For instance, car seats are manufactured by Tier 1 suppliers whilst electronic components or software are usually provided by Tier 2 suppliers.  Aftermarket suppliers: provide added-value aftermarket products, such as smart dongles or third-party GNSS systems, which can be bought by customers and connected to the car to provide additional features.

1.5 METHODOLOGY

ENISA has developed this study following a five-step methodological approach as depicted in Figure 1.

Figure 1: Methodology

1. Project scope definition: the first step consisted in establishing the scope of the project and identifying the main topics to be considered during the study. 2. Desktop research and experts’ identification: extensive research of relevant documents to gather as much information as possible about (semi-)autonomous cars and V2X communication technologies. The identified documents and standards were used as references for the development of this report. During this step, subject matter experts were also invited to validate scope and provide feedback. Experts from car manufacturers, tier-1 and tier-2 suppliers as well as other organisations, such as Government Authorities and ITS system suppliers were invited. Additionally, experts from ENISA’s CaRSEC informal expert group were also invited to contribute. 3. Questionnaire and interviews with identified experts: ENISA got in touch with the identified experts in order to get their point of view. To this end, a structured

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

questionnaire covering various security aspects, such as critical assets, key threats targeting smart cars and awareness with respect to smart cars standards and guidelines, was developed. The questionnaire was completed by some of the identified experts, and interviews were conducted to collect additional valuable inputs to prepare the report. 4. Analysis of collected material and report development: all the collected information, either through desktop research or directly from the identified experts, was thoroughly analysed. This led to the development of the first draft of this report. 5. Review and report validation: ENISA shared the draft of the report with its relevant stakeholder communities and reference groups for review. Taking into account the stakeholders feedbacks, the proposed final version of the report was issued and a validation face-to-face workshop was organized to present the results of the study.

1.6 STRUCTURE OF THE DOCUMENT

The study is structured as follows:

 Chapter 1 – Introduction: provides introductory information on the objectives, scope, relevant EU and international policies, target audience, followed methodology and the structure of this study.  Chapter 2 – Smart cars: Connected and (semi-)autonomous cars: first defines V2X communications, semi-autonomous and autonomous cars. Then, it provides a high-level reference architecture of smart cars and lists the sensitive assets to be protected.  Chapter 3 – Threats and risk analysis: identifies the main threats against smart cars and indicates the affected assets. Some examples of significant smart cars attack scenarios are also detailed.  Chapter 4 – Security measures and good practices: describes the security measures and good practices to mitigate the aforementioned attacks.

Further details are provided in the appendix:

 Annex A – Asset Taxonomy: presents the different assets and provides a brief description of them  Annex B – Threat Taxonomy: provides a brief description of the different threats and maps each threat to the asset(s) that may potentially be affected  Annex C – Mapping of security measures to threats, standard and good practices: details the security measures mentioned in chapter 4 and maps them to the corresponding threats.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

2. SMART CARS: CONNECTED AND (SEMI-) AUTONOMOUS CARS

2.1 DEFINITIONS

The SAE J3016 standard defines six levels of driving automation for on-road vehicles, ranging from level 0 with no driving automation at all to level 5 with full driving automation and no need for a driver, as shown in Figure 2.

Figure 2: SAE vehicles automation levels as defined in SAE J3016

Even though the provided recommendations and good practices can apply to all vehicles (i.e. no matter their automation level), this study focuses on semi-autonomous and autonomous cars, which are also referred to as Automated Driving System-Dedicated Vehicle (ADS-DS) in SAE J3016 standard, as well as on V2X communications, defined as follows:

 Semi-autonomous cars (level 4 of automation): refers to highly automated cars that are equipped with a multitude of sensors in order to be able to autonomously (i.e. without any human driver intervention) perform all driving functions under certain conditions (e.g. on a given type of roads).  Autonomous cars (level 5 of automation): refers to fully automated cars that are equipped with a multitude of sensors in order to be able to autonomously perform all driving functions under all conditions (i.e. at any time and on any road). Those cars may not even include a steering wheel or accelerator/brake pedals.  V2X communications: refers to data exchanges between a vehicle and any other entity (e.g. a road infrastructure, another vehicle, a pedestrian, etc.). It covers the notions of V2V (Vehicle-to-Vehicle) communications and V2I (Vehicle-to-Infrastructure) communications. In this study, the term V2I refers to all communications between the vehicle and its

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

surrounding, aside from V2V communications. Thus, V2I includes V2P (Vehicle-to- Pedestrian) and V2N (Vehicle-to-Network) communications. To enable V2X communications, vehicles are equipped with different wireless communication systems such as Dedicated Short Range Communications (DSRC ), Visible Light Communication (VLC), Image Sensor Communication (ISC), Wi-Fi or mobile communication technologies, such as 3G, 4G and 5G. This study is meant to be agnostic about the communication technologies actually used.

Figure 3 gives an overview of the smart car ecosystem depicting systems and application both in-vehicle and outside the car.

Figure 3: Smart cars ecosystem

In this study, we focus on smart cars that, as connected systems, have the necessary capabilities to autonomously perform all driving functions under certain (or all) conditions, and are able to communicate with their surroundings including other vehicles, pedestrians and Road-Side Units (RSU).

Good practices discussed in this report do not only concern passenger cars but also commercial vehicles (e.g. buses, coaches, etc.), including self-driving ride-sharing vehicles which can be

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

shared with other users. This study does not focus on specific use cases such as connected infotainment and specific intra-vehicular communications.

To achieve enhanced autonomous driving capabilities, smart cars rely on various technologies including:

 Sensors and Actuators: devices that have various capabilities, such as sensing and detecting objects, actuating, etc.  Artificial Intelligence: algorithms that enable ECUs and computers to perform tasks typically associated with intelligent human beings.  Machine Learning: algorithms that enable computers to act and enhance their ability to predict events or situations.  Cloud Computing: solutions enabling access to shared sets of resources such as servers and applications with minimal requirements concerning managerial effort and service provider interaction.  Communications and/or Networks: radio technologies and communication protocols that allow data exchange between different entities.

2.2 HIGH-LEVEL REFERENCE MODEL

Smart cars and especially (semi-)autonomous cars, which include several ECUs and components, may seem unduly complicated at first glance. Although smart cars functions (e.g. braking, steering, door locking, etc.) are the same throughout vehicles, nevertheless each OEM has its own in-vehicle architecture and there is no common and unique architecture that can be used as a reference model. Figure 4 presents the high-level functional model that ENISA

Figure 4: High-Level Smart Cars Reference Model

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

defined for the study based on an extensive review of relevant efforts and having validated it with the experts. The model’s aim is to provide a generic overview of the smart cars technologies and their interplay. It needs to be noted that the model is only indicative and does not reflect the complexity of the various automotive architectures; it aims at encapsulating the main elements of the latter in a high-level view. This model provides a general overview of the different functionalities, used technologies and most important components providing smart cars major features.

The high-level reference model consists of four layers arranged in order, with the three lowest layers being part of the smart car, whereas the upper layer represents components that are outside the actual containment of the car, but which are part of its environment such as RSUs and map servers for instance. In addition to the components and technologies depicted in Figure 4, smart cars also include critical functions (e.g. acceleration, braking, object detection, navigation, etc.) that ought to be protected against cyberattacks. Indeed, altering the operations of those functions may lead to unexpected situations (e.g. vehicle collision or crash) that could endanger road users’ safety.

Hereinafter, we provide a brief description of the different layers:

 Car sensors and actuators: the lowest layer of the architecture comprises the various smart cars sensors used to monitor the driving environment by collecting data on the vehicle surroundings, such as road conditions, distance to other objects and vehicles, Global Navigation Satellite Systems (GNSS) positions, as well as the different actuators that execute the necessary actions.  Car ECUs, processing and decision making components: this layer comprises all the hardware and software components, including AI, that are used for the processing of the data received from layer Car sensors and actuators (i.e. data collected by the smart cars sensors) and In-vehicle communication components (e.g. data received from other C-ITS stations), as well taking the appropriate decision and transmitting it to the relevant actuator.  In-vehicle communication components: this layer includes the different in-vehicle communication components used for both in-vehicle communications (e.g. Head-Unit which is also referred to as In-Vehicle Infotainment (IVI), or in-vehicle gateway) as well as communications with external components such as other vehicles or RSUs.

2.3 SMART CARS INFRASTRUCTURE AND BACKEND SYSTEMS:

This layer comprises the different external communication components (e.g. RSU, traffic signs) or systems (e.g. other vehicles, access points, pedestrian smartphone) that communicate directly with the smart cars, as well as servers and systems that remotely provide services to smart cars. It includes, amongst others, OEM back-end systems used for over-the-air (OTA) updates, map data servers and third party service provider’s systems.assets taxonomy.

To address smart cars cybersecurity issues, it is essential to identify assets of such a complex ecosystem. A taxonomy of the key assets that should be protected in order to ensure highly secure vehicles is depicted in Figure 5, and a brief description of the different assets is provided in Annex A. Especially, smart cars functions (e.g. obstacle detection) are of utmost importance as they directly influence smart cars behaviours and may endanger passengers’ safety. These functions are at the crossroads between different technologies from sensors to AI-based algorithms by way of infrastructure components, listed in the asset taxonomy. This highlights that securing smart cars requires a multidisciplinary approach, as assets domains are quite diversified.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Figure 5: Asset taxonomy

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

3. THREATS AND ATTACK SCENARIOS

3.1 THREATS TAXONOMY

Smart cars increased connectivity and automation expose them to several crucial cyber threats. Those threats may directly target smart cars or their surroundings such as RSUs, traffic signs/lights or even remote servers of the OEM or third-party service providers.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Figure 6: Threat taxonomy

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS 3.2 EXAMPLES OF SMART CARS CYBER SECURITY ATTACK SCENARIOS

During the interviews, automotive experts assessed the criticality of several attack scenarios based on their potential impacts and the aforementioned threats, so as to enable the identification of critical attack scenarios. For each attack scenario, experts were asked to indicate whether they consider its potential impact (i.e. severity level) as high, medium or low. Table 1 depicts the different attack scenarios along with the interviewees’ perceived severity level.

Table 1: Smart cars attack scenarios

ATTACK SCENARIOS SEVERITY

1. Vulnerability exploit in a communication stack: exploitation of a vulnerability in a communication stack of an in-vehicle network (e.g. no protection mechanism against replay attacks, lack of authentication, etc.) can lead to severe issues such as High critical ECU reprogramming and taking control the vehicle over the Controller Area Network (CAN bus).

2. Mobile car application being hacked/attacked allowing access to the car: by hacking the mobile application, an attacker could order a car to drive him High somewhere although he is not allowed to do so.

3. Attack on remote servers to influence car behaviours: several attack scenarios exist regarding remote servers. For instance, an attacker could

High

compromise map data with the aim to affect plausibility checks, or even alter data on traffic conditions to change the current car itinerary resulting in an inefficient service.

4. Fake communication unit to compromise telematics unit and deploy rogue

firmware: use of malicious communication unit, such as Base Transceiver Station

High

(BTS), Wi-Fi router, RSU, with the objective to spread a malware or just disrupting the infrastructure communications.

5. Large scale deployment of rogue firmware after hacking OEM back-end

servers: penetration of OEM back-end servers with the aim to initiate malicious

High

firmware updates could lead to devastating results as this kind of attacks is highlyscalable.

6. Hacking an RSU with the aim to spread wrong traffic and safety

messages: as RSUs constitute an important part of the autonomous vehicles’ High – Medium ecosystem, they could be the target of hackers in order to create traffic jams or other kind of disruptions.

7. Rogue vehicle sending wrong information through V2V interfaces: vehicles unknown from the infrastructure (e.g. counterfeit cars) that are deployed to decrease

Medium

the safety level by sending wrong information about traffic conditions and other functionalities (i.e. fake information with the aim to update map data).

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

8. Sensor fooling by adversarial perturbation: attack scenarios to disrupt the sensors’ proper functioning by different means depending on the targeted sensor Medium – Low (e.g. flash the camera, relay the light waves from the LiDAR).

9. Communication jamming: producing radio interferences to disrupt wireless

Low

networks so the vehicles cannot emit or receive V2X messages.

10. GNSS spoofing: by replacing GNSS signals, an attacker can fool a third-party service into thinking that the vehicle is elsewhere in either time or location. This can Medium lead to accident or vehicle theft.

11. Blocking critical messages at automation level 4: an attacker can block critical messages, such as Denial of a Service (DoS) attack, and prevent the semi-

High

autonomous vehicle (or driver) from reacting appropriately to the situation (e.g. apply the brakes, warn the driver that he needs to take control of the vehicle, etc.).

Hereinafter, we detail three types of attack scenarios encompassing various use-cases. The first attack scenario (Large scale deployment of a rogue firmware after hacking OEM back-end servers) is typical of the threats lying over connected cars. The second one (Hacking/altering a V2X mobile application that allows access to the car) is extracted from V2X use-cases. The third one (Sensor fooling by adversarial perturbation) is more related to (semi- )autonomous features. These three attack scenarios were selected so as to represent different families of attacks linked with connected cars and automation levels 4 & 5, which are the focus of this study. The impact is an overall estimation based on the outcome of the interviews.

Attack scenario 1: Large scale deployment of a rogue firmware after hacking OEM back-end servers

DESCRIPTION

This attack scenario refers to deployment of malicious firmware from back-end servers. This could be initiated by OEMs employees (e.g. developers) or by external attackers capable of penetrating back-end servers. Malicious OTA updates could then be executed so that autonomous vehicles think it is a legitimate one, as it is initiated from a trusted server.

IMPACT

High – Crucial: Remote servers might communicate with numerous vehicles at the same time. Thus, compromising such a centralised server could affect the entire ecosystem, including passengers’ safety.

EASE OF DETECTION CASCADE EFFECT RISK

Medium: Remote servers should have enough High: Such attacks are resources to implement advanced monitoring highly-scalable as they techniques. However, the deployment of many can be executed remote servers increases the attack surface to be remotely and affect a protected. fleet of vehicles instantly.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

STAKEHOLDERS ASSETS AFFECTED INVOLVED

Back-end system Software and Licenses OTA Updates OEMs Vehicle functions Information (User, Device, Keys and Certificates)

ATTACK STEPS

1. To perform this attack scenario, the attacker needs first to penetrate the targeted OEM back-end server. This may be carried out by leveraging a known vulnerability of used software, a misconfiguration on the server side or by spoofing the administrator account for instance. 2. Once the attacker gets access to the OEM back-end server, the attacker can request the execution of an OTA firmware update for a given fleet of vehicles. To this end, he follows the same steps required to perform a legitimate OTA firmware update. 3. Upon receiving the OTA update request, vehicles acknowledge and accept the request as it is initiated by a legitimate OEM server. 4. Next, the attacker uploads a rogue firmware on the OEM back-end server and launches the OTA update process to deploy this firmware. 5. Once the rogue firmware is installed on smart cars, the attacker can take remote control of a fleet of vehicles by exploiting a backdoor introduced in the rogue firmware.

GAPS AND RECOVERY TIME / EFFORT CHALLENGES

Medium – High: Depending on the nature of the deployed firmware, cancelling the update Lack of awareness and knowledge by returning back to the retro version can be Lack of a secure boot process challenging if the attacker was able to change Lack of proper product lifecycle update related information (e.g. certificates, management policies). Use of logging can help to identify the attack origin.

COUNTERMEASURES

1. Regularly assess the security controls and patch vulnerabilities. 2. Deploy Intrusion Detection Systems (IDS) at vehicle and back-end levels. 3. Introduce a new device or software change into the vehicle only according to an established, accepted and communicated change management process. 4. Consider establishing a CSIRT. 5. Apply security controls at back-end servers. 6. Establish an incident handling process. 7. Incident report to back-end servers. 8. Conduct periodic reviews, of authorization and access control privileges for instance. 9. Software authenticity and integrity checked before installation. 10. Use of secure OTA firmware updates.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

11. Protect OTA update process.

12. Use of secure boot mechanisms.

13. Application of security controls to back-end servers.

14. Apply least privileges principle and use individual accounts to access devices and systems.

15. Maintain properly protected audit logs.

16. Allow and encourage the use of strong authentication mechanisms.

Attack scenario 2: Hacking/altering a V2X mobile application that allows access to the car

DESCRIPTION

IMPACT

High: Such attacks can result in illegitimate access to the smart car or even its theft through the compromise or hacking of a V2X mobile application.

EASE OF DETECTION CASCADE EFFECT RISK

Medium: Individual should pay Medium: This attack scenario attention to the different target individuals and allows applications installed on their compromising many vehicles at smartphone (e.g. avoid installing once using V2X application suspicious applications).

ASSETS AFFECTED STAKEHOLDERS INVOLVED

Mobile application User information OEMs Keys and certificates Third-party service providers Mobile devices (smartphones and Tablets)

ATTACK STEPS (SAMPLE BASED ON A REAL-CASE ATTACK SCENARIO)

1. The attacker manages to retrieve user’s credentials associated to a V2X application (e.g. car, traffic or platooning application) by one of the following means: by making the honest user install a fake application instead of the real one, via a phishing attack, or by leveraging an existing or a new discovered vulnerability in the V2X application. 2. Once the attacker has retrieved the user’s credentials, he installs the legitimate V2X application and uses stolen credentials to login successfully; thus impersonating the honest user. 3. Finally, the attacker can use the V2X application to get access to the smart car, and potentially steal the smart car if keyless driving is allowed and the hacked application enables to start the engine.

RECOVERY TIME / EFFORT GAPS AND CHALLENGES

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Medium: As soon as the flaw in the application that allow such attacks is discovered, a security patch should be applied. Depending on the vulnerability, it Response to zero-day vulnerabilities might take days or weeks. Lack of awareness and knowledge If V2X application user has informed OEM about Insecure design or development credential compromise, they should revoke the disclosed credentials for that particular user.

COUNTERMEASURES

1. Perform vulnerability surveys. 2. Third party testing of V2X applications. 3. Regularly assess the security controls and patch vulnerabilities. 4. Information sharing between different actors. 5. Adopt a holistic approach to security training and awareness among the employees. 6. Raise users’ awareness. 7. Allow and encourage the use of strong authentication (e.g. multi-factor authentication). 8. Consider establishing a Computer Security Incident Response Teams (CSIRT). 9. Mitigate vulnerabilities or limitations of software libraries. 10. Protect mobile applications against reverse engineering and tampering of their binary code. 11. Securely store sensitive data on mobile devices.

Attack scenario 3: Sensor fooling by adversarial perturbation

DESCRIPTION

IMPACT

High: The impact depends on the introduced perturbation. However, abusive detection, or lack of detection of stop signs could entail major accidents endangering road users’ safety and leading to driver, passenger, or pedestrian deaths.

EASE OF DETECTION CASCADE EFFECT RISK

Medium: Without appropriate Low: The perturbation is local, countermeasure, the and may affect only the cars modifications brought to the signs passing by the modified or could be undetected by human spoofed sign. eyes before an accident occurs.

ASSETS AFFECTED STAKEHOLDERS INVOLVED

Decision Making algorithms OEMs Sensors for autonomous vehicles Road infrastructure Vehicle functions

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

ATTACK STEPS (SAMPLE BASED ON A REAL-CASE ATTACK SCENARIO)

1. The attacker first analyses the capabilities of the targeted versions of cameras and AI-based image classifier to ensure detection and classification as desired of the modified sign. This setup phase can require trying multiple perturbation patterns or display parameters. The attacker needs to perform some experimentation as well, to test the adversarial perturbation and ensure that his attack will succeed. 2. At a next step, the attacker attaches a set of black and white stickers to a physical road sign to cause misclassification of the traffic sign. 3. Due to the added stickers, the cars passing by the altered traffic sign will erroneously classify it into the attacker’s targeted class (e.g. interpret a stop sign as a speed limit sign) and react accordingly (e.g. reduce speed instead of stopping the vehicle).

RECOVERY TIME / EFFORT GAPS AND CHALLENGES

Traffic sign authentication would be an Medium: Sensor fooling attacks appropriate countermeasure but is can go unnoticed. Once detected, complicated to deploy modified traffic signs can be repaired in hours. Collaboration of vehicles

COUNTERMEASURES

1. Protect critical sensors in order to prevent attacks that may alter their perception of the environment. 2. Hardening against Adversarial Machine Learning. 3. Use of hardware redundancy mechanisms. 4. Use of data redundancy mechanisms, such as sensors information fusion. 5. Perform data validation, for instance by comparing sign information collected by sensor with information from digital maps stored in the vehicle.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

4. SECURITY MEASURES AND GOOD PRACTICES

4.1 SECURITY MEASURES CATEGORISATION

Security measures and good practices development is one of the major objectives of this study. Indeed, a considerable effort was expended to identify all relevant security measures in order to help mitigate the potential threats and risks, thus improving smart cars security.

The list of security measures has been established by analysing relevant documents and standards identified during desktop research . This analysis allowed the identification of frequently mentioned topics regarding smart cars security and their classifications into different security domains. The resulting list consists of seventeen security domains grouped into three main categories, namely Policies, Organisational practices and Technical practices as shown in Figure 7. The latter provides a comprehensive view of smart cars security landscape, and points out the areas to be protected.

Figure 7: Cybersecurity Good Practices Overview

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS 4.2 POLICIES

This first category of security measures encompasses the different policies and procedures to be established within organizations to ensure an appropriate cybersecurity level.

Policies-related security measures cover both security and privacy aspects, and have been classified into four main security domains, namely Security by design, Privacy by design, Asset management and Risk and threat management.

The security measures in this section are addressed at both OEMs and suppliers, due to the tight links between them.

4.2.1 Security by design

These security measures emphasize the need to consider security aspects from the very beginning of product development, throughout the supply chain and all over smart cars lifecycle.

 PS-01: Adopt a security by design approach where smart cars cybersecurity is considered from both the vehicles as well as the infrastructure perspective.  PS-02: Address security in each relevant specification document to ensure that security aspects are considered from the very beginning of the concept phase, and not as an afterthought.  PS-03: Promote the use of methodologies that consider security in every stage of the development phase and operations phases (e.g. DevSecOps , Secure Development Lifecycle (SDL) , etc.).  PS-04: Consider including a security role within the product engineering team to lead security related tasks.

4.2.2 Privacy by design

This security domain includes a set of security measures related to the protection of private data that are collected, processed and/or stored by smart cars stakeholders.

 PS-05: Consider applying local and international privacy related regulations, such as the GDPR, to prevent privacy issues.  PS-06: Conduct Privacy Impact Assessments (PIA), taken into account the context of use, in order to identify any privacy related risk, and define appropriate countermeasures to mitigate it.  PS-07: Perform Privacy Audits during smart cars development and over back-end systems on a regular basis, e.g. at least once year, in order to ensure compliance with privacy related policies.

4.2.3 Asset Management

Hereinafter, security measures pertaining to assets discovery, monitoring, administration and maintenance are outlined.

 PS-08: Use tools supporting asset management that can automatically discover, identify and enumerate assets specific to the organization and smart cars ecosystem.  PS-09: Ensure that the organization maintains a consistent and up-to-date asset inventory.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

 PS-10: Introduce a new device or software change into the vehicle only according to an established, accepted and communicated change management process.

4.2.4 Risk and Threat Management

This security domain gathers the security measures related to the process of risk and threat management.

 PS-11: Adopt an approach to risk management dedicated and suitable for automotive sector, considering emerging threats and attack scenarios targeting smart cars.  PS-12: Perform a cybersecurity risk analysis from the very early stages of the design process, and which should be revised at least annually and upon any major change or in case of critical security vulnerability detection or critical security incident.  PS-13: Monitor security vulnerabilities with a focus on vehicles that are on the market on a regular basis, e.g. every 6 months or more frequently based on risk assessment.  PS-14: Conduct security evaluations, such as penetration testing, during the development phase and then, on a regular basis following an event driven approach, e.g. in the case of new threats or vulnerabilities and after major updates.  PS-15: Consider establishing a threat intelligence process in order to be informed on emerging attack types and sources as well as new relevant vulnerabilities.  PS-16: Regularly assess the security controls at least once a year overall smart cars lifecycle, and deploy patches (after testing them) to mitigate vulnerabilities.  PS-17: Regularly check, at least every six months over smart cars lifecycle, that the security assumptions (e.g. operational environment assumptions) are still valid. In particular, consider defining procedure for communication and handling of end-of-life/out-of-warranty status for cybersecurity.

4.3 ORGANISATIONAL PRACTICES

Organisational and governance processes are of utmost importance to ensure smart cars security. In what follows, a set of organisational rules and best practices are detailed. They cover several aspects such as relationships with suppliers, employees training, incident management, etc.

4.3.1 Relationships with Suppliers

 OP-01: Foster security-related information sharing between the different stakeholders while protecting intellectual property.  OP-02: Define cybersecurity relevant aspects of the partnerships along the supply chain, and develop security requirements and procurement guidelines for suppliers .

4.3.2 Training and Awareness

 OP-03: Share relevant information between all organisations, including subcontractors, suppliers and third parties to enhance smart cars security, by following the examples of existing Information Sharing and Analysis Centers (ISACs) for instance.  OP-04: Adopt a holistic approach to security training and awareness among the employees, including employees on all levels of the organization, as well as consider expanding it to suppliers.  OP-05: Ensure that security trainings are continuous, regular and frequently updated.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

 OP-06: Raise vehicle owners’, drivers’ and passengers’ awareness with respect to security issues and how to prevent them, on a regular basis.

4.3.3 Security Management

 OP-07: Consider establishing an OEM Security Operations Center (SOC) with clearly defined roles, responsibilities and cybersecurity competences to centralize knowledge on cybersecurity, monitor and anticipate potential threats.  OP-08: Designate one or several dedicated security team(s) with security specialists having diversified and broad range of competencies in security related topics (e.g. risk assessment, penetration testing, secure design, etc.).  OP-09: Define a dedicated Information Security Management System (ISMS) that covers smart cars entire lifecycle.  OP-10: Consider defining an internal task force, which involves board-level management, to guide security-related strategic decisions and facilitate accountability.

4.3.4 Incident Management 4.4 TECHNICAL PRACTICES

Besides to the policies and organisational practices listed above, a set of technical security measures should be implemented to protect both smart cars and the associated back-end systems. Hereinafter, we provide an overview of these technical practices which covers several aspects such as software security, cloud security, detection, access control and so on.

4.4.1 Detection

 TM-01: Deploy Intrusion Detection Systems (IDSs) both at vehicle and back-end levels to enable the detection of malicious activities or policy violations.  TM-02: Maintain properly protected audit logs to prevent their disclosure to unauthorised entities, while clearly defining their storage location and retaining period.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

 TM-03: Consider periodically reviewing network logs, access control privileges and assets configuration.  TM-04: Perform data validation to check the correctness of incoming information.  TM-05: Define appropriate forensics procedures to enable event reconstruction, facilitate crash investigation, prevent similar attacks and/or for accountability purposes.

4.4.2 Protection of Networks and Protocols

 TM-06: Protect remote monitoring and administration interfaces through mutual authentication and access control mechanisms to prevent illegitimate access to smart cars systems.  TM-07: Protect the integrity and authenticity of all critical in-vehicle internal communications.  TM-08: Protect the integrity and authenticity of all external communications between the smart cars and all the different entities it is interacting with.  TM-09: Enforce session management policies for the different communication sessions (e.g. administration, ) to avoid session hijacking.  TM-10: Timestamp all exchanged messages using reliable time sources (e.g. provided by secure embedded component or coming from satellite system) to mitigate replay attacks.  TM-11: Manage radio frequencies and the frequency of beaconing and other repeated messages in order to prevent Distributed DoS (DDoS) attacks.  TM-12: Implement frequency agility feature to prevent signals jamming, if applicable.  TM-13: Perform packet filtering at the different layers (e.g. ECU and sensors, mobile network communications, etc.) to analyse incoming and outgoing packets and discard illegitimate traffic.  TM-14: Provide end-to-end protection of sensitive data in terms of confidentiality and integrity using secure protocols.

4.4.3 Software Security

 TM-15: Secure the default configuration of devices and services and ensure that the most secure operation mode of device (or service) is used by default.  TM-16: Ensure software authenticity and integrity before its installation, to ensure that only legitimate software is used.  TM-17: Implement and document changes in configuration according to a change management policy developed by the organisation based on risk analysis.  TM-18: Secure OTA firmware updates to avoid firmware manipulation, disclosure or rollback to vulnerable versions.  TM-19: Define a secure OTA update process.  TM-20: Implement secure boot processes that ensure systems integrity and authenticity. A risk-based approach may be used to identify when secure boot is actually needed.  TM-21: Ensure that vulnerabilities and limitations of software dependencies, especially open source libraries, are mitigated or addressed in a risk assessment.  TM-22: Protect mobile applications against reverse engineering (e.g. through code obfuscation techniques) and against tampering of their binary code (e.g. by signing it).  TM-23: Securely store sensitive data (e.g. passwords) on mobile devices, and protect local files created by the mobile application.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS 4.4.4 Cloud Security

 TM-24: Cover security and availability aspects in agreements with cloud security providers, if applicable.  TM-25: In the context of cloud-based application and centralised systems, ensure that single points of failure are prevented. 56 57  TM-26: Operate critical systems and applications within the private or at least hybrid deployment models.  TM-27: Protect all data within the cloud and during transfer while ensuring that cloud services providers do not have access to the decryption keys, so as to mitigate any potential risk stemming from cloud attacks.

4.4.5 Cryptography

 TM-28: Encrypt all sensitive, personal and private data to prevent its disclosure to illegitimate entities. Moreover, authenticated encryption may be used to avoid the manipulation of personal data while ensuring their confidentiality.  TM-29: Use well-known and standardized cryptographic schemes and protocols that are widely considered as secure, and avoid the use of proprietary schemes.  TM-30: Use of storage encryption to protect both users’ data as well as data needed to enforce smart cars security (e.g. used keys, security credentials, etc.).  TM-31: Implement a secure key management process. The process should cover all the steps of key lifecycle: key length choice in relation with key lifetime, key generation using an appropriate level of entropy from a reliable source, secure key storage, key rotation and revocation, etc.  TM-32: Consider the use of dedicated and tamper resistant hardware security modules for secure execution of cryptographic algorithms and secure key storage.

4.4.6 Access Control

 TM-33: Apply security controls at back-end servers; covering policies, physical and logical security aspects as well as the security of internal networks and data.  TM-34: Apply least privileges principle and use individual accounts to access devices and/or systems.  TM-35: Segregate remote access by developing a set of rules for the control and monitoring of remote communications.  TM-36: Allow and encourage the use of strong authentication mechanisms, e.g. Multi-Factor Authentication (MFA), define an account lockout functionality, etc.

4.4.7 Self-Protection and Cyber Resilience

 TM-37: Implement differential monitoring on the GNSS system, to ensure accurate localisation data.  TM-38: Apply a hardening approach on the different level (i.e. devices, network, back-end, etc.) to reduce the attack surface.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

 TM-39: Reinforce interfaces robustness, e.g. to cope with buffer overflows or fuzzing.  TM-40: Consider strengthening applications isolation at runtime, using trusted software technologies.  TM-41: Apply system, sub-domain and network segregation using physical and logical isolation techniques where appropriate (based on risk assessment).

4.4.8 (Semi-) Autonomous Systems Self Protection and Cyber Resilience

 TM-42: Consider using inboard Inertial Navigation System (INS) or existing dead-reckoning methods to get localisation data, even in case of GNSS failure.  TM-43: Protect critical autonomous sensors to prevent the different attacks aiming to alter smart cars environment perception.  TM-44: Harden against Adversarial attacks, to prevent AI and ML components from being tricked.  TM-45: Prevent data falsification or manipulation in regard to AI and ML.  TM-46: Use of data redundancy mechanisms (e.g. sensor data fusion) that correlate data acquired from the different sensors in the vehicle and data obtained via V2X communications before making a decision.  TM-47: Use of hardware redundancy mechanisms by adding extra hardware components able to carry out the required operations and perform self-driving tasks.

4.4.9 Continuity of Operations

 TM-48: Ensure that notifications are easy to understand, and help users find a remediation or workaround.  TM-49: Create a Business Continuity Plan (BCP) and a Business Recovery Plan (BRP) that cover third-party aspects and are periodically tested, at least annually, to ensure the resilience of smart cars systems.  TM-50: Define important parameters for the business continuity of the organisation, e.g. Recovery Time Objective (RTO), Maximum Tolerable Outage (MTO), etc.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

5. ABBREVIATIONS

ACRONYM DEFINITION

ADS-DV Automated Driving System-Dedicated Vehicle AI Artificial Intelligence AP Access Point Auto-ISAC Automotive Information Sharing and Analysis Center BSI British Standards Institution BSM Basic Safety Message BTS Base Transceiver Station CaRSEC Cars and Roads SECurity working group CCAM Cooperative, Connected and Automated Mobility CSIRT Computer Security Incident Response Team C-ITS Cooperative Intelligent Transport Systems Directorate-General for Communications Networks,

DG CONNECT

Content and Technology Directorate-General for Internal Market, Industry,

DG GROW

Entrepreneurship and SMEs DG MOVE Directorate-General for Mobility and Transport DSRC Dedicated Short-Range Communications ECU Electronic control Unit E/E Electrical and Electronic ETSI European Telecommunications Standards Institute GDPR General Data Protection Regulation GNSS Global Navigation Satellite System

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

IDS Intrusion Detection System ICE In Car Entertainment IMU Inertial Measurement Unit IPS Intrusion Prevention System ISC Image Sensor Communication ISO International Organization for Standardization IT Information Technology ITS Intelligent Transportation System IVI In-Vehicle Infotainment LiDAR Light Detection and Ranging LIN Local Interconnect Network MFA Multi-Factor Authentication MITM Man-In-The-Middle ML Machine Learning MOST Media Oriented Systems Transport NFC Near-Field Communication NHTSA National Highway Traffic Safety Administration NIS Network and Information Security directive OBD On-Board Diagnostic OEM Original Equipment Manufacturer OS Operation System OTA Over-The-Air OT Operational Technology PAS Publicly Available Specifications PIA Privacy Impact Assessment RSE Road Side Equipment

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

RSU Road-Side Unit SAE Society of Automotive Engineers SME Small-Medium Enterprises SOC Security Operation Center TCU Telematic Control Unit UNECE United Nations Economic Commission for Europe UTC Universal Coordinated Time V2I Vehicle-to-Infrastructure V2N Vehicle-to-Network V2P Vehicle-to-Pedestrian V2V Vehicle-to-Vehicle Vehicle-to-Everything. Includes the notion of V2V,

V2X

V2I, V2P and V2N communications VLC Visible Light Communication

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

6. BIBLIOGRAPHY/REFERENCES

SAE J3016 “Taxonomy and Definitions for Terms Related to Driving Automations Systems for On-Road Motor Vehicles”: http://sae.org/standards/content/J3016_201806/

ENISA (2016) “Cyber Security and Resilience of smart cars – Good practices and recommendations”: https://www.enisa.europa.eu/publications/cyber-security-and-resilience-ofsmart-cars

“Self-Driving Vehicles in an Urban Context”: http://www3.weforum.org/docs/WEF_Press%20release.pdf

European Commission “On the road to automated mobility: An EU strategy for mobility of the future”: https://ec.europa.eu/transport/sites/transport/files/3rd-mobilitypack/com20180283_en.pdf

“Rethinking Transportation 2020-2030 – The disruption of Transportation and the Collapse of the Internal-Combustion Vehicle and Oil Industries”: https://static1.squarespace.com/static/585c3439be65942f022bbf9b/t/591a2e4be6f2e1c13df930 c5/1494888038959/RethinkX+Report_051517.pdf

“Self-driving Ubers could still be many years away, says research head”: https://nationalpost.com/pmn/news-pmn/canada-news-pmn/self-driving-ubers-could-still-bemany-years-away-says-research-head

“Hackers remotely kill a Jeep on the highway – with me in it”: https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/

“Experimental security assessment of BMW cars: A summary report”: https://keenlab.tencent.com/en/whitepapers/Experimental_Security_Assessment_of_BMW_Car s_by_KeenLab.pdf

“Hacking smart car alarm systems”: https://www.kaspersky.com/blog/hacking-smart-car-alarmsystems/26014/

“PASTA: Portable Automotive Security Testbed with Adaptability”: https://i.blackhat.com/eu- 18/Wed-Dec-5/eu-18-Toyama-PASTA-Portable-Automotive-Security-Testbed-with-Adaptabilitywp.pdf

“PASTA 1.0 L and F Software Development Tools – Product details”: https://www.chip1stop.com/USA/en/view/dispDetail/DispDetail?partId=LANF-0000001

“Remote attacks on Automated Vehicles Sensors: Experiments on Camera and LiDAR”: https://pdfs.semanticscholar.org/e06f/ef73f5bad0489bb033f490d41a046f61878a.pdf

“Self-driving and connected cars: fooling sensors and tracking drivers”: https://www.blackhat.com/docs/eu-15/materials/eu-15-Petit-Self-Driving-And-Connected-Cars- Fooling-Sensors-And-Tracking-Drivers.pdf

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

“All Your GPS Are Belong To Us: Towards Stealthy Manipulation of Road Navigation Systems”: https://www.usenix.org/node/217477

“Meet the Artist Using Ritual Magic to Trap Self-Driving Cars”: https://www.vice.com/en_us/article/ywwba5/meet-the-artist-using-ritual-magic-to-trap-selfdriving-cars

“Remote Attacks on Automated Vehicles Sensors: Experiments on Camera and LiDAR”: https://pdfs.semanticscholar.org/e06f/ef73f5bad0489bb033f490d41a046f61878a.pdf

“Illusion and Dazzle: Adversarial Optical Channel Exploits against LiDARs for Automotive Applications”: https://eprint.iacr.org/2017/613.pdf

“Fast and Vulnerable: A Story of Telematic Failures”: https://www.usenix.org/system/files/conference/woot15/woot15-paper-foster.pdf

“Robust Physical-World Attacks on Deep Learning Visual Classification”: https://arxiv.org/pdf/1707.08945.pdf

“European Commission Launches CCAM Single Platform”: https://connectedautomateddriving.eu/mediaroom/european-commission-launches-ccam-singleplatform/

EU “General Data Protection Regulation”: https://eur-lex.europa.eu/legalcontent/EN/TXT/PDF/?uri=CELEX:32016R0679

Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union”: https://eur-lex.europa.eu/legalcontent/EN/TXT/HTML/?uri=CELEX:32016L1148&from=EN

Cybersecurity Best Practices for Modern Vehicles – NHTSA : https://www.nhtsa.gov/staticfiles/nvs/pdf/812333_CybersecurityForModernVehicles.pdf

Auto-ISAC “Automotive Cybersecurity Best Practices – Executive summary”: https://www.automotiveisac.com/best-practices/

UNECE “Proposal for Recommendation on Cyber Security”: https://www.unece.org/fileadmin/DAM/trans/doc/2019/wp29grva/ECE-TRANS-WP29-GRVA- 2019-02e.pdf

“PAS 1885:2018 - The fundamental principles of automotive cyber security. Specification”: https://shop.bsigroup.com/ProductDetail?pid=000000000030365446

“PAS 11281:2018 - Connected automotive ecosystems. Impact of security on safety. Code of practice”: https://shop.bsigroup.com/ProductDetail?pid=000000000030365540 ETSI TS 102 940 v1.3.1, “Intelligent Transport Systems (ITS); Security; ITS communications security architecture and security management”: https://www.etsi.org/deliver/etsi_ts/102900_102999/102940/01.03.01_60/ts_102940v010301p.p df ETSI TS 102 941 V1.2.1 “Intelligent Transport Systems (ITS); Security; Trust and Privacy Management https://www.etsi.org/deliver/etsi_ts/102900_102999/102941/01.02.01_60/ts_102941v010201p.p df

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

ETSI TS 102 942 V1.1.1 “Intelligent Transport Systems (ITS); Security; Access Control” https://www.etsi.org/deliver/etsi_ts/102900_102999/102942/01.01.01_60/ts_102942v010101p.p df ETSI TS 102 943 V1.1.1 “Intelligent Transport Systems (ITS); Security; Confidentiality services” https://www.etsi.org/deliver/etsi_ts/102900_102999/102943/01.01.01_60/ts_102943v010101p.p df

ETSI TS 103 097 v1.3.1, “Intelligent Transport Systems (ITS); Security; Security header and certificate formats”: https://www.etsi.org/deliver/etsi_ts/103000_103099/103097/01.03.01_60/ts_103097v010301p.p df

ETSI TR 102 893 “Intelligent Transport Systems (ITS); Security; Threat, Vulnerability and Risk Analysis (TVRA) https://www.etsi.org/deliver/etsi_tr/102800_102899/102893/01.02.01_60/tr_102893v010201p.pd f

SAE J3061 “Cybersecurity Guidebook for Cyber-Physical Vehicle Systems”: https://www.sae.org/standards/content/j3061_201601/

ITF/OECD “Safer Roads with Automated Vehicles”, https://www.itf-oecd.org/sites/default/files/docs/safer-roads-automated-vehicles.pdf

ISO/SAE CD 21434 “Road Vehicles – Cybersecurity engineering”: https://www.iso.org/standard/70918.html

“ENISA Threat Taxonomy” (2016): https://www.enisa.europa.eu/topics/threat-riskmanagement/threats-and-trends/enisa-threat-landscape/threat-taxonomy/view

“Tesla cars can be stolen by hacking the app”: https://promon.co/security-news/hacking-teslaapp-stolen-car/

“MobilBye: Attacking ADAS with Camera Spoofing”: https://arxiv.org/pdf/1906.09765.pdf

“Robust Physical-World Attacks on Deep Learning Models”: https://arxiv.org/pdf/1707.08945.pdf

“Self-driving Ubers could still be many years away, says research head”: https://nationalpost.com/pmn/news-pmn/canada-news-pmn/self-driving-ubers-could-still-bemany-years-away-says-research-head

“Domain Controlled Architecture – A new approach for large scale software integrated automotive systems”: https://pdfs.semanticscholar.org/65ff/f1cd276736bc5cf67d0cb30db269cd08b5f5.pdf

“VCIDS: Collaborative Intrusion Detection of Sensor and Actuator Attacks on Connected Vehicles”: http://php.scripts.psu.edu/muz16/pdf/PG-ea-Comm17.pdf

“Work-in-Progress: Road Context-aware Intrusion Detection System for Autonomous Cars”: https://sudiptac.bitbucket.io/papers/raids.pdf

“Intelligent Intrusion Detection in External Communication Systems for Autonomous Vehicles”: https://www.tandfonline.com/doi/full/10.1080/21642583.2018.1440260

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

“Hopping on the CAN Bus – Automotive Security and the CANard Toolkit”: https://www.blackhat.com/docs/asia-15/materials/asia-15-Evenchick-Hopping-On-The-Can- Bus.pdf

“DEFCON – Connected Car Security”: https://securingtomorrow.mcafee.com/otherblogs/mcafee-labs/defcon-connected-car-security/

“Spatially Clustered Autonomous Vehicle Malware: Producing New Urban Geographies of Inequity”: https://journals.sagepub.com/doi/full/10.1177/0361198118794057

“Fast, Furious and Insecure: Passive Keyless Entry and Start in Modern Supercars”: https://www.esat.kuleuven.be/cosic/fast-furious-and-insecure-passive-keyless-entry-and-startin-modern-supercars/

“All your GPS Are Belong to Us: Towards Stealthy Manipulation of Road Navigation Systems”: https://www.usenix.org/node/217477

“Analyzing and Enhancing the Security of Ultrasonic Sensors for Autonomous Vehicles”: https://ieeexplore.ieee.org/document/8451864

“Jamming and Spoofing Attacks: Physical Layer Cybersecurity Threats to Autonomous Vehicle Systems”: https://tlpc.colorado.edu/wp-content/uploads/2016/11/2016.11.21-Autonomous- Vehicle-Jamming-and-Spoofing-Comment-Final.pdf

UNECE- ECE/TRANS/WP.29/GRVA/2019/2 -- Automated/autonomous and connected vehicles:Cyber security and data protection -- Proposal for a Recommendation on Cyber Security : https://www.unece.org/fileadmin/DAM/trans/doc/2019/wp29grva/ECE-TRANS-WP29- GRVA-2019-02e.pdf

Safety First for Automated Driving : https://www.aptiv.com/docs/default-source/whitepapers/safety-first-for-automated-driving-aptiv-white-paper.pdf

SCOUT - Report on the state of the art of connected and automated driving in Europe : https://connectedautomateddriving.eu/publication/scout-deliverable-3-2-report-on-the-state-ofthe-art-of-connected-and-automated-driving-in-europe-final/

PAS 1885:2018 The fundamental principles of automotive cyber security specification, bsi : https://shop.bsigroup.com/ProductDetail/?pid=000000000030365446&_ga=2.267667464.70490 2458.1545217114-2008390051.1545217114

GSMA (Global System for Mobile Communications) - GSMA CLP.11 IoT Security Guidelines Overview Document : https://www.gsma.com/iot/wp-content/uploads/2016/02/CLP.11-v1.1.pdf

Autonomous DevSecOps: Five Steps to a Self-Driving Cloud (ENT214-S) - AWS re:Invent 2018 : https://www.slideshare.net/AmazonWebServices/autonomous-devsecops-five-steps-to-aselfdriving-cloud-ent214s-aws-reinvent-2018

Redhat DevSecOps : https://www.redhat.com/en/topics/devops/what-is-devsecops

What is DevSecOps? Developing more secure applications : https://www.csoonline.com/article/3245748/what-is-devsecops-developing-more-secureapplications.html

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Champions Playbook : https://www.owasp.org/index.php/Security_Champions_Playbook Avoid Unnecessary Pain with a Security Champion : https://www.csoonline.com/article/3299430/avoid-unnecessary-pain-with-a-securitychampion.html IoT Alliance Australia - Internet of Things Security Guidelines v1.2 : https://www.iot.org.au/wp/wp-content/uploads/2016/12/IoTAA-Security-Guideline-V1.2.pdf Privacy Impact Assessment : https://gdpr-info.eu/issues/privacy-impact-assessment/ Data Protection Impact Assessment (DPIA) : https://gdpr.eu/data-protection-impactassessment-template/ GDPR: How to Perform a Data Audit : https://www.thesslstore.com/blog/gdpr-data-audit/ GDPR checklist for data controllers : https://gdpr.eu/checklist/ Cloud Security Alliance - Identity and Access Management for the Internet of Things - Summary Guidance : https://downloads.cloudsecurityalliance.org/assets/research/internet-ofthings/identity-and-access-management-for-the-iot.pdf Cloud Security Alliance - Security Guidance for Early Adopters of the Internet of Things : https://downloads.cloudsecurityalliance.org/whitepapers/Security_Guidance_for_Early_Adopter s_of_the_Internet_of_Things.pdf IEC - IEC 62443-3-3:2013 System security requirements and security levels : https://webstore.iec.ch/publication/7033 ISO - ISO/IEC 27001:2013 Information technology -- Security techniques – Information security management systems -- Requirements : https://www.iso.org/standard/54534.html ISO - ISO/IEC 27002:2013 Information technology -- Security techniques -- Code of practice for information security controls : https://www.iso.org/standard/54533.html NIST - NIST SP 800 53r4: Security and Privacy Controls for Federal Information Systems and Organizations : https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf NIST - NISTIR 8183: Cybersecurity Framework Manufacturing Profile : https://nvlpubs.nist.gov/nistpubs/ir/2017/NIST.IR.8183.pdf SANS Institute - Vulnerability Management: Tools, Challenges and Best Practices : https://www.sans.org/reading-room/whitepapers/threats/paper/1267 Huawei - IoT Security White Paper 2017 : https://www.huawei.com/minisite/iot/img/hw_iot_secutity_white_paper_2017_en_v2.pdf NIST - Draft NISTIR 8228: Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks : https://csrc.nist.gov/publications/detail/nistir/8228/final

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

LNS - Putting Industrial Cyber Security at the top of the CEO agenda : https://www.honeywellprocess.com/en-US/online_campaigns/lns-cyberreport/Pages/Honeywell-LNS-Study_PuttingIndustrialCyberSecurityattheTopCEOAgenda.pdf

NIST - NIST SP 800 30r1 - Guide for Conducting Risk Assessments : https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf

NIST - NIST SP 800 82r2: Guide to Industrial Control Systems (ICS) Security : https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r2.pdf

Safety First for Automated Driving” (SaFAD) : https://www.daimler.com/innovation/case/autonomous/safety-first-for-automated-driving-2.html

European Commission -- Access to In-vehicle Data and Resources : https://ec.europa.eu/transport/sites/transport/files/2017-05-access-to-in-vehicle-data-andresources.pdf

ENISA - Cyber Security and Resilience of Smart Cars : https://www.enisa.europa.eu/publications/cyber-security-and-resilience-of-smart-cars

ETSI - ETSI TR 102 893 V1.2.1 -- Intelligent Transport Systems: Security, Threat, Vulnerability and Risk Analysis : https://www.etsi.org/deliver/etsi_TR/102800_102899/102893/01.01.01_60/tr_102893v010101p. pdf

Auto ISAC - Automotive Cybersecurity Best Practices - Executive Summary : https://www.automotiveisac.com/best-practices/

IIC (Industrial Internet Consortium) - IoT Security Maturity Model: Description and Intended Use : https://www.iiconsortium.org/pdf/SMM_Description_and_Intended_Use_2018-04-09.pdf

International Telecommunications Union - Security capabilities supporting safety of the Internet of things : https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Y.4806-201711-I!!PDF- E&type=items

Five Star Automotive Cyber Safety Program : https://www.iamthecavalry.org/domains/automotive/5star/

Securing the Modern Vehicle : https://www.synopsys.com/content/dam/synopsys/sigassets/reports/securing-the-modern-vehicle.pdf

Security Development Lifecycle (SDL) : https://www.microsoft.com/enus/securityengineering/sdl/practices

COLLABORATION AND ENGAGEMENT WITH APPROPRIATE THIRD PARTIES : https://www.automotiveisac.com/wpcontent/uploads/2018/08/2018_01_18_Best_Practice_Guide_Third_Party_Collaboration_Engag emen.pdf

ENISA - Good practices for Security of Internet of Things in the context of Smart Manufacturing : https://www.enisa.europa.eu/publications/good-practices-for-security-of-iot

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

IEC - IEC 62443-2-1:2010 Establishing an industrial automation and control system security program : https://webstore.iec.ch/preview/info_iec62443-2-1%7Bed1.0%7Den.pdf

Insecurity in the Internet of Thing : https://www.symantec.com/content/dam/symantec/docs/security-center/white-papers/insecurityin-the-internet-of-things-15-en.pdf

IoT Security Awareness : https://resources.infosecinstitute.com/iot-security-awareness/#gref

Consumers don't care if their connected car can get hacked - here's why that's a problem : https://www.businessinsider.com/smart-car-hacking-major-problem-for-iot-internet-of-things- 2016-3?IR=T

Shifting gears in cyber security for connected cars: https://www.mckinsey.com/~/media/mckinsey/industries/automotive%20and%20assembly/our% 20insights/shifting%20gears%20in%20cybersecurity%20for%20connected%20cars/shiftinggears-in-cyber-security-for-connected-cars.ashx

CSIRTs in Europe:https://www.enisa.europa.eu/topics/csirts-in-europe?tab=articles

ACEA Principles of Automobile Cybersecurity: https://www.acea.be/publications/article/aceaprinciples-of-automobile-cybersecurity

Securing the Modern Vehicle: A Study of Automotive Industry Cybersecurity Practices: https://www.synopsys.com/content/dam/synopsys/sig-assets/reports/securing-the-modernvehicle.pdf

30% of Automotive Companies Lacking a Dedicated Cybersecurity Team : https://www.bleepingcomputer.com/news/security/30-percent-of-automotive-companies-lackinga-dedicated-cybersecurity-team/

Security Champions Playbook : https://www.owasp.org/index.php/Security_Champions_Playbook

Avoid Unnecessary Pain with a Security Champion : https://www.csoonline.com/article/3299430/avoid-unnecessary-pain-with-a-securitychampion.html

SAE J3061: https://www.researchgate.net/publication/307585960_Using_SAE_J3061_for_Automotive_Secu rity_Requirement_Engineering

Security Operations Center : https://securityaffairs.co/wordpress/47631/breaking-news/socsecurity-operations-center.html

MITRE :Cybersecurity Operations Center : https://www.mitre.org/sites/default/files/publications/pr-13-1028-mitre-10-strategies-cyber-opscenter.pdf

Survey and Classification of Automotive Security Attacks - MDPI : https://www.mdpi.com/2078- 2489/10/4/148/pdf-vor

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

PRESERVE - Security Requirements of Vehicle Security Architecture v1.1 : https://www.preserve-project.eu/sites/preserve-project.eu/files/PRESERVE-D1.1- Security%20Requirements%20of%20Vehicle%20Security%20Architecture.pdf C-ITS Platform, WG5: Security & Certification - Final Report - Annex 2: Revocation of Trust in C-ITS : https://smartmobilitycommunity.eu/sites/default/files/Security_WG5An2_v1.0.pdf ACEA Principles of Automobile Cybersecurity : https://www.acea.be/publications/article/aceaprinciples-of-automobile-cybersecurity ENISA - Baseline Security Recommendations for IoT : https://www.enisa.europa.eu/publications/baseline-security-recommendations-for-iot IIC (Industrial Internet Consortium) - IIC Endpoint Security Best Practices : https://www.iiconsortium.org/pdf/Endpoint_Security_Best_Practices_Final_Mar_2018.pdf IoT Security Foundation - Connected Consumer Products. Best Practice Guidelines : https://iotsecurityfoundation.org/wp-content/uploads/2016/12/Connected-Consumer- Products.pdf OWASP (Open Web Application Security Project) - IoT Security Guidance : https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project SANS Institute - An Abbreviated History of Automation & Industrial Controls Systems and Cybersecurity : https://ics.sans.org/media/An-Abbreviated-History-of-Automation-and-ICS- Cybersecurity.pdf A survey on open automotive forensics : https://forschung-sachsenanhalt.de/publication/survey-open-automotive-forensics-1002323053 Log your car: the non-invasive vehicle forensics : https://ieeexplore.ieee.org/document/7847047 “My autonomous car is an elephant”: A Machine Learning based Detector for Implausible Dimension : https://ieeexplore.ieee.org/document/8556651 AUTOMOTIVE WORKING GROUP : https://www.w3.org/blog/auto/ OWASP: Session Management Cheat Sheet : https://www.owasp.org/index.php/Session_Management_Cheat_Sheet OWASP: Session fixation : https://www.owasp.org/index.php/Session_fixation CAR 2 CAR Communication Consortium - FAQ regarding Data Protection in C-ITS v1,0,0 : https://www.car-2-car.org/service/privacy/ Secure Device Configuration Guideline : https://security.berkeley.edu/secure-deviceconfiguration-guideline ISA-95.01 MODELS & TERMINOLOGY : https://isa-95.com/isa-95-01-models-terminology/ Siemens - Industrial Security: Applying IoT Security Controls on the Industrial Plant Floor : https://www.industry.usa.siemens.com/automation/us/en/formsdocs/Documents/2016%20MIA-

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

%2023%20Industrial%20Security%20Applying%20IoT%20Security%20Controls%20on%20the %20Industrial%20Plant%20Floor.pdf

Gowling WLG & UK Autodrive - Connected and Autonomous Vehicles: A Hacker's Delight? : https://gowlingwlg.com/GowlingWLG/media/UK/pdf/autodrive/170907-cyber-security-whitepaper.pdf

Cybersecurity Solutions for Connected Vehicles : https://www.trendmicro.com/us/iotsecurity/content/main/document/IoT%20Security%20for%20Auto%20Whitepaper.pdf

Securing Self-Driving Cars : http://illmatics.com/securing_self_driving_cars.pdf?_sm_au_=iqs579QRrj9HP44Q

Using Open Source for security and privacy protection : https://security-and-privacy-referencearchitecture.readthedocs.io/en/latest/10-using-oss.html

Federal Office for Information Security: Business Continuity Management : https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/BSIStandards/standard_ 100-4_e_pdf.pdf?__blob=publicationFile&v=1

GSMA (Global System for Mobile Communications) - GSMA CLP.12 IoT Security Guidelines for IoT Service Ecosystems : https://www.gsma.com/iot/wp-content/uploads/2016/02/CLP.12v1.0.pdf

Online Trust Alliance - IoT trust framework 2.5 : https://www.internetsociety.org/resources/doc/2018/iot-trust-framework-v2-5/

NIST - NIST SP 800-146 Cloud Computing Synopsis and Recommendations : https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-146.pdf

SANS Institute - Building the New Network Security Architecture for the Future : https://www.sans.org/reading-room/whitepapers/internet/paper/38255

Cloud Security Alliance - Future Proofing the connected world : https://downloads.cloudsecurityalliance.org/assets/research/internet-of-things/future-proofingthe-connected-world.pdf

Federal Office for Information Security (BSI) - BSI-Standards 100-4 - Business Continuity Management : https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/BSIStandards/standard_ 100-4_e_pdf.pdf?__blob=publicationFile&v=1

FAQ: CAR 2 CAR Communication Consortium - FAQ regarding Data Protection in C-ITS v1,0,0 : https://www.car-2car.org/fileadmin/documents/General_Documents/C2CCC_TR_2051_Data_Protection.pdf

European Commission - Certificate Policy for Deployment and Operation of European Cooperative Intelligent Transport System (C-ITS) : https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_policy_release_1.pdf

What is physical security? How to keep your facilities and devices safe from on-site attackers : https://www.csoonline.com/article/3324614/what-is-physical-security-how-to-keep-your-facilitiesand-devices-safe-from-on-site-attackers.html

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Principle of least privilege (POLP) : https://searchsecurity.techtarget.com/definition/principle-ofleast-privilege-POLP

Improving security through least-privilege practices : http://techgenix.com/improving-securitythrough-least-privilege-practices/?_sm_au_=iqs579QRrj9HP44Q

GSMA (Global System for Mobile Communications) - GSMA CLP.13 IoT Security Guidelines for Endpoint Ecosystems : https://www.gsma.com/iot/wp-content/uploads/2016/02/CLP.13-v1.0.pdf

Autonomous integrity monitoring of navigation maps on board intelligent vehicles : https://www.researchgate.net/publication/278826487_Autonomous_Integrity_Monitoring_of_Na vigation_Maps_on_board_Intelligent_Vehicles

Symantec - Insecurity in the Internet of Things : https://www.symantec.com/content/dam/symantec/docs/security-center/white-papers/insecurityin-the-internet-of-things-15-en.pdf

OWASP Internet of Things Project – OWASP : https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project

OWASP Top Ten Project – OWASP : https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

Secure hypervisor versus trusted execution environment : http://www.divaportal.se/smash/get/diva2:1120483/FULLTEXT01.pdf?_sm_au_=iqs579QRrj9HP44Q

Isolated Execution in Many-core Architectures : https://eprint.iacr.org/2014/136.pdf

An Autonomous Vehicle Navigation System Based on Inertial and Visual Sensors : https://www.researchgate.net/publication/327470347_An_Autonomous_Vehicle_Navigation_Sy stem_Based_on_Inertial_and_Visual_Sensors

Security Innovation - Remote Attacks on Automated Vehicles Sensors: Experiments on Camera and LiDAR : https://pdfs.semanticscholar.org/e06f/ef73f5bad0489bb033f490d41a046f61878a.pdf

Towards deep learning models resistant to adversarial attacks : https://openreview.net/pdf?id=rJzIBfZAb

Explaining and harnessing adversarial examples : https://arxiv.org/pdf/1412.6572.pdf

Pixeldefend: Leveraging generative models to understand and defend against adversarial examples. In International Conference on Learning Representations (ICLR),2018 : https://openreview.net/forum?id=rJUYGxbCW

The robust manifold defense: Adversarial training using generative models : https://arxiv.org/abs/1712.09196

Thermometer encoding: One hot way to resist adversarial examples. In International Conference on Learning Representations (ICLR), 2018 : https://openreview.net/pdf?id=S18Su-- CW

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Securing the Future of AI and ML : https://docs.microsoft.com/en-us/security/securing-artificialintelligence-machine-learning

Groupe PSA - Attacker model for Connected and Automated Vehicles Security Innovation - Remote Attacks on Automated Vehicles Sensors: Experiments on Camera and LiDAR : https://pdfs.semanticscholar.org/e06f/ef73f5bad0489bb033f490d41a046f61878a.pdf

Duo Security - The Internet of Fails ; Where IoT Has Gone Wrong : https://www.slideshare.net/markstanislav/the-internet-of-fails-where-iot-has-gone-wrong-andhow-were-making-it-right

A Hard Problem with No Easy Answers | Decipher - IoT Security : https://duo.com/decipher/iotsecurity-hard-problem-no-easy-answers

Center for Internet Security (CIS) - Critical Security Controls : https://www.cisecurity.org/controls/

oneM2M - Standards for M2M and the Internet of Things - TR 0008 Security V2.0.0 - Security. Technical Report : http://www.onem2m.org/images/files/deliverables/Release2A/TR-0008- Security-v_2_0_1.pdf?_sm_au_=iqs579QRrj9HP44Q

OWASP – Mobile Application Security Verification Standard: https://github.com/OWASP/owaspmasvs/releases/download/1.1.4/OWASP_Mobile_AppSec_Verification_Standard_1.1.4_Document.pdf

ENISA – Smartphone Secure Development Guidelines: https://www.enisa.europa.eu/publications/smartphone-secure-development-guidelines-2016

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

ANNEX A: ASSET TAXONOMY

Annex A lists the different assets mentioned in Figure 5, and provides a brief description of each asset.

Asset Group Assets Description

These devices are common sensors (e.g. tire pressure, air bag impact, GNSS, speed, powertrain, seat belt, passenger occupancy, temperature, oil, water coolant, parking and climate control sensors) Standard Sensors usually embedded in cars to measure some parameters and/or monitor or detect some events. The collected data is transmitted to ECU for processing purposes.

These devices are relatively new sensors embedded in autonomous vehicles to provide self-driving capabilities (e.g. localization, enabling the detection and identification of objects and people). This category of sensors mainly includes the following Sensors for autonomous sensors: vehicles Car sensors and actuators  Light Detecting and Ranging (LiDAR)  Lasers  Cameras  Radars  Ultrasonic sonars

These devices are an important part of vehicles. They interact with the environment by converting an electrical signals received from the ECU into an action (e.g. apply the brake when a red light or a pedestrian crossing the road is detected, speed Actuators reduction on bad weather conditions, change of direction to get around an obstacle). The engine control unit, suspension, transmission, brake system and steering system are some examples of actuators.

These software components provide smart cars with

Decision Making

the capability to perform tasks that are typical for Algorithms intelligent beings, such as reacting to an

(Car ECUs, processing

unanticipated and new situation based on previously and decision making ML and AI algorithms collected data. ML and AI algorithms are components implemented inside smart cars to enable them to Smart cars Infrastructure react in real time whenever required, but they may and Backend systems) be implemented outside the vehicle in remote servers as well.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Asset Group Assets Description

These software components combine data acquired Data fusion algorithms from different sensors (e.g. LiDAR and camera) and V2X communications.

Vehicle Functions

This term refers to the different vehicle functions (such as braking, acceleration, operating the

Car sensors and actuators

Vehicle functions steering wheel, route planning, etc.) which rely on Car ECUs, processing and one or several sensors data as well as processing decision making and actuating nodes to operate correctly.

components

This term refers to the different software components of the vehicle. It includes on-board operating systems (which manage the resources of a given smart car hardware device and provides common services for other computer programs to run), programs and codes (which are written to perform a given task or technological objective, such as AIbased algorithms as well as real-time monitoring algorithms, or even protocol stacks/cryptographic algorithms’ software implementations), mobile applications (which correspond to programs running Software management on mobile devices such as smartphones and tablets Software and Licenses Car ECUs, processing and that are used to communicate with the smart car, to decision making unlock the doors for instance) and antivirus (which is components a particular software that monitors a device or network to detect and identify malwares, and prevent

In-vehicle communication

them from infecting devices) as well as on-board

components

firmware (which is a class of software that are stored Smart cars Infrastructure on a device read-only memory and provides and Backend systems instructions on how the device should operate). A smart car can include several OSes embedded on different devices. As for programs, antivirus and firmware, they can be found at every level: from ECUs to back-end servers.

This term refers to software updates (including Over- The-Air (OTA) updates) that are used by the OEM to Software updates remotely or locally deploy new firmware or software on smart cars.

This electronic module is the vehicle main communication unit. It provides the capability to connect to the cellular communication networks and Inside vehicle Telematics box enables other short and long range communications

Communication

based on several technologies, such as Near Field

Components

Communications (NFC), Bluetooth, WiFi, etc.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Asset Group Assets Description

In-vehicle communication

This device enables wireless V2V and V2I components Vehicle ITS station communications.

This device plays a crucial role in smart cars. It interconnects the various in-vehicle networks to the In-Vehicle Gateway telematics box and ITS station. It also provides physical isolation between the different functional domains.

This asset, also known as Head Unit or In-car Entertainment (ICE), refers to a vehicle system combining information exchanges (between the vehicle and the drivers/passengers through a touch In-Vehicle Infotainment screen-based tablet like device) and entertainment (IVI) (i.e. audio and video). Smartphones can also be paired with such unit, allowing remote connectivity. It provides a hardware interface for the entire vehicle.

The OBD-II port, also called diagnostics plug, is an OBD-II port external interface that allows plugging different maintenance and diagnostic devices to smart cars.

The interface used to plug an electric or hybrid EV charging connector smart car to a charging station.

In-vehicle communications and domain

Communication Networks

subnetworks rely on several protocols such as

and Protocols

In-Vehicle networks Controller Area Network (CAN), Local Interconnect

(Car ECUs, processing

Network (LIN), Media Oriented Systems Transport

and decision making

(MOST), FlexRay and Ethernet.

components

In-vehicle communication Telematics box and ITS station provide different components Protocols and wireless communication technologies including communication 802.11p (DSRC), Cellular-V2X (C-V2X), cellular

Car sensors and actuators

technologies technologies (2G, 3G, 4G, 5G), NFC, Wi-Fi, Bluetooth.

These devices refers to nearby communication components interacting with smart cars. They include: Access Points (AP) which is a cellular networking Nearby External hardware device that supports cellular Components Communication communications and which directly communicates Smart cars Infrastructure Components with the smart car telematics box.

and Backend systems

Road Side Unit (RSU), also known as Road Side Equipment (RSE), which is a communication device located on the roadside to provide connectivity and enable communication between the road side infrastructure and smart cars.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Asset Group Assets Description

Traffic signs and lights provide road users and smart cars with the necessary safety instructions and are mainly used to regulate the speed and traffic flow. In particular, traffic signs give the driving Traffic signs and lights practices to follow and warn about dangerous conditions while traffic lights provide vehicles and drivers with the necessary instructions to follow at intersections and along roads. This asset includes lane marking as well.

This network security device or software monitors Firewall and controls incoming and outgoing network traffic based on a predetermined set of security rules.

It corresponds to a set of rules enabling to direct Routing table data packets to its destination or drop the packet if no match is found.

Network and Domain

Isolation Features These devices interconnect the different in-vehicle Car ECUs, processing and functional domains. They need to be powerful in decision making 59 Domain controllers terms of processing capabilities and real-time components, performance in order to support autonomous vehicles’ highly interconnected architecture.

In-vehicle communication components

Intrusion Detection Systems (IDS) allow automatic Smart cars Infrastructure monitoring of the happening events, and analyses and Backend systems them to detect any potential sign of intrusion. Intrusion Prevention Systems (IPS) can also IDS/IPS perform given actions whenever some specific events happen in attempt to stop the incident. Such systems can be found deployed at the vehicle 60,61 62 level as well as the infrastructure level .

This term refers to the back-end systems which Back-end Systems enable Over-The-Air updates among other services.

This term refers to a database back-end system

Servers, Systems and

which consists of both hardware and software used Cloud Computing to run a database. These servers may for instance Database servers Smart cars Infrastructure store and process in-vehicle data and resources to and Backend systems enable service providers to propose services such as software updates.

This term refers to remote servers that provide Maps servers longitudinal and lateral data to the smart cars, thus

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Asset Group Assets Description

enabling it to navigate and to decide the next trajectory to reach its destination. These servers may also provide a map database that can be locally stored on the vehicle.

This term refers to remote servers used by service Third- party service provider in order to propose added value services providers servers such as eToll for toll payments and breakdown call (bCall).

This asset refers to data that is gathered by the Sensors data different smart car sensors and which will be transmitted to the appropriate ECU for processing.

This asset refers to the different keys and certificates used for security purposes (such as authentication, securing the exchanges, secure Keys and certificates boot, etc.). Keys are stored in devices embedded in the vehicle (e.g. ECU) and/or in servers depending on their use.

This asset refers to the information about the car environment. Map data allow to increase the passenger safety by correlation its information with Map data the sensors perception. Contrary to GNSS which gives only information about the geolocalization,

Information

map data gives information about the surrounding

Throughout model

environment.

This asset refers to the different information exchanged via V2X communications (e.g. V2X information emergency vehicle approaching, roadworks/collision warning and traffic information).

This asset refers to the different information related to a device embedded in a smart car (e.g. ECU, Device information TCU) or connected devices (e.g. smartphones, tablet). This includes information such as type, configuration, firmware version, status, etc.

This asset refers to smart cars user (e.g. driver, User information passenger, etc.) information such as name, role, privileges and permissions.

This asset refers to all individuals who are entitled to drive the smart car. This asset is optional when Drivers considering SAE automation level 5 as such smart

Humans

car is fully automated.

Throughout model

This asset refers to all individuals that are onboard Passengers smart cars.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Asset Group Assets Description

This asset refers to OEM individuals who have physical or remote privileged access to the smart OEM staff car for several purposes (such as maintenance, adding features and performing updates).

This asset refers to non-OEM individuals who have Mechanics physical access to smart cars for maintenance purposes.

Mobile Devices

This term refers to portable devices that run mobile

(Smart cars Infrastructure

Smartphones and Tablets applications providing added value services to the

and Backend systems)

vehicle user.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

ANNEX B: THREAT TAXONOMY

Annex B provides a brief description of the different threats subcategories mentioned in Figure 6, and maps each threat to the asset(s) that may potentially be affected.

Threat Threat Description Impacted Assets Category

Smart cars and their infrastructure, may be subject to Distributed Denial of Service (DDoS) attacks, or even used to launch such attacks. DoS attacks may target (or originate from) RSUs or the IT systems. An attacker may for instance shut down the RSU (via physical Denial of Service All assets access or remotely), overload the system with messages to process or even jam radio communications, etc. In-vehicle components can also be the target of DoS attacks. For instance, overloading the CAN bus with malicious messages will alter the vehicle behaviour .

These malicious software aim at performing unwanted and illegitimate actions such as

Nefarious

disabling smart cars functions (e.g. prevent

activity/Abuse

car unlocking or immobilize the engine). Malware Malware can cause unexpected behaviours All assets of the smart car and even endanger passengers’ safety. Common examples or malwares are Ransomware , viruses, Trojan horses, Spyware and exploit kits.

This threat consists of unauthorized and illegitimate alteration of a component firmware, operations or configuration data by an attacker (e.g. malicious OTA updates). An Manipulation of attack might also access the binary file, hardware and All assets compromising the intellectual property. The software risk is emphasized when there are no security measures (e.g. secure boot) to protect the authenticity of critical hardware and software components. An attacker may also perform Man-in-the-middle attacks by

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Threat Threat Description Impacted Assets Category

manipulating the hardware. Potential consequences of this kind of threats may include inappropriate smart cars behaviours.

- Vehicle sensors and actuators - Decision making algorithms This threat consists of illegitimate and - Vehicle Functions unwanted data alteration by an attacker. To - Network and this end, the attacker may use various Domain Isolation technical means such injecting fake Basic Features Safety Message (BSM) , performing map - Information data poisoning, faking security-related information (e.g. keys, certificates, Certificate - In-vehicle Revocation List), tampering with RSU data or Communication Manipulation of OTA update exchanges, injection of packet Networks information 67 over CAN bus , repudiation of actions (e.g. - In-vehicle deny eToll), loss of data (e.g. erase of Communication vehicle history), etc. Components Information manipulation threats may result - External in inappropriate decisions that are based on Communication the altered/falsified data, and may also lead Components to information or intellectual values disclosure. - Servers, Systems and Cloud Computing - Mobile Devices - Humans

Cyberattacks targeting smart cars manufactured by a specific OEM or its backend systems during which the attackers typically use several attack methods and OEM Targeted entry points to achieve their goals. Such All assets attacks attacks are usually scalable and may lead to reputational damage and/or information or intellectual property disclosure (such as the knowledge of in-vehicle internal architecture).

A legitimate user may try to access Unauthorised unauthorized functions for various reasons: All assets activities they might want to circumvent DRMs on applications or media, or get an unauthorized

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Threat Threat Description Impacted Assets Category

access to features (geo-fencing, digital tachograph…), or they might simply want to tune the vehicle for comfort or performance purposes. Outside vehicles, manufacturers may also be confronted with garages using unauthorized or unlicensed professional tools and software. Unauthorised software may also be installed by an attacker. This threat also includes the notion of cloning, for example when an attacker copies the firmware of an existing device, in order to commercialize it without authorization.

Impersonation attacks in which an adversary successfully assumes the identity of one of the legitimate parties in the system or in a communication protocol. A common example is to impersonate a key fob to steal the associated car. This may, however, be completed for other purposes, such as fraud, for example if a user wants their car to display another identity when communicating with: Identity theft All assets - road infrastructures such as toll systems, thus leading to financial fraud; - manufacturer backend (to get access to paid services without subscription). An attacker may also impersonate a police car or ambulance in order to make other vehicles slow down or pull over. Thus, the attacker can reach his destination more quickly.

A disgruntled employee (backend services, garage) may use their authorizations to perform malicious actions (e.g. create illegitimate user accounts, or add malicious Abuse of software into the system). All assets authorizations A slightly different scenario would be for an infotainment application to abuse its authorizations (for example, to mine private data or perform surveillance activities).

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Threat Threat Description Impacted Assets Category

Smart cars autonomous sensors (like cameras, LiDARs and Radar sensors) may be subject to DoS attacks using several - Sensors for means such as presenting too many objects 69 autonomous vehicles Threats targeting to track, blinding camera and LIDAR/radar autonomous sensors jamming . - Vehicle Functions

GNSS spoofing attacks may also be - Information performed in an attempt to deceive a GNSS receiver through the broadcast of incorrect

Threats

GNSS signals.

against (semi-)

autonomous Attacks may be carried out against AI and systems ML features. For instance, the attacker may 72 - Sensors for perform adversarial perturbation in an intent to hide objects, fool auto-controls (e.g. autonomous vehicles radar/LIDAR confusion) and/or perceive fake Threats against AI - Decision Making data (e.g. fake crash sound or ultrasonic algorithms and ML 73 reflection , magnetic attacks targeting - Vehicle Functions odometric sensors). An attacker may also provide malicious inputs during the model - Information training phase in order to alter the classification.

Intentional tampering of a device by an attacker with the aim to alter the proper functioning of the vehicle, thus endangering the safety of smart cars passengers and roads users. The attacker may directly target smart cars components (e.g. by Sabotage compromising decision making algorithms or All assets brake system, replacing a car component with a malicious one), or alter/remove RSUs,

Physical

traffic signs and/or lights. The attacker may

attack

even compromise backend systems (e.g. eCall platform, database servers) in an attempt to execute unauthorized operations.

Intentional physical degradation of car - Vehicle sensors and actuators components (e.g. damage cameras), RSUs, Vandalism traffic signs or lights (e.g. alter or remove - Decision making traffic signs on the road). Such threat would algorithms impact the operations of the vehicle and - External

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Threat Threat Description Impacted Assets Category

make cause accidents and dangerous communication situations. components - Information - Humans

- Vehicle sensors and actuators - Decision making algorithms Theft of devices (e.g. car components, Theft RSUs) that may alter the vehicle proper - External functioning and endanger road users’ safety. communication components - Information - Humans

Side-channel attacks consist in exploiting physical characteristics of the computing - Vehicle sensors and platform (e.g. execution time, power actuators consumption) to recover security credentials - Functions (i.e. cryptographic keys and passwords) in order to bypass security mechanisms. Such - Software and Side-channel attacks attacks generally require a physical access licenses to the targeted device, but some of them - Information (e.g. timing attacks) may be performed - In-vehicle remotely. Side channel attacks could target communication critical ECUs or other devices that use networks security credentials (e.g. for V2X communications).

- Vehicle sensors and Fault injection threats consist in disrupting actuators the computational operations of a security - Functions mechanism (e.g. skipping a password verification) to bypass security mechanisms. - Software and Fault injection Such attacks generally require a physical licenses access to the targeted device, but some of - Information them (e.g. Rowhammer attacks) can be performed remotely. They would mainly - In-vehicle target critical ECUs. communication networks

Failures / This threat impacts the proper functioning of - Vehicle sensors and Malfunctions a sensor and/or actuator. It may accidentally actuators (Car sensors Failure or malfunction happen (e.g. as a result of improper use or - Functions and actuators of a sensor/actuator maintenance). It may also be intentional through software vulnerabilities (e.g. ability to - Software and

Car ECUs,

spread a malware on ECUs). licenses

processing

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Threat Threat Description Impacted Assets Category

and decision - Information

making

- In-vehicle

components)

communication networks - In-vehicle communication components - Decision making algorithms - Humans

Threats leveraging the use of outdated software versions, bugs, improper configurations, zero-day vulnerabilities or Software specific software components such as weak vulnerabilities cryptographic algorithms or vulnerable open All assets exploitation source libraries. Unsecure OTA updates might also be exploited in order to spread a malware or perform software downgrade to a version with known vulnerabilities.

- Decision making algorithms - Functions - Software and licenses This threat targets OEM services and/or third party services in order to limit the car - External Failure or Disruption features, or communication disrupt smart cars’ operations. It of service could be done by different means (e.g. DDoS components attack, malicious software updates). - Servers, systems and cloud computing - Information - Humans - Mobile devices

Cyberattacks that exploit flaws in communication protocols so as to perform Eavesdroppin impersonation attacks (e.g. rogue BTS attack g due to a lack of authentication), replay Communication attacks (e.g. performing an ECU software All assets /Interception protocol hijacking downgrade), or more generally the injection

/Hijacking

of malicious packets, the interception of information or the disruption of communications. Such threats may lead to

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Threat Threat Description Impacted Assets Category

the disclosure of sensitive and/or private information, including passwords.

-Decision making algorithms -Functions -External communication components Cyberattack that exploits data replay techniques. Such attack can occur at the -In-vehicle communication protocol level (e.g. lack of timestamp and/or Data replay authentication) but also at the sensor level networks (e.g. use a repeater to create a ghost -In-vehicle vehicle). communication components - Servers, systems and cloud computing -Information -Humans

Man-In-The-Middle (MITM) attacks exploit the lack of authentication to disrupt the Man-in-the-middle communications between legitimate entities attack / Session or to disclose/modify exchanged information All assets hijacking (e.g. provide fake information to RSUs to affect traffic conditions). They apply to both in-vehicle and V2X communications.

Unintentional modification of configuration or data by a legitimate entity leading to potential Unintentional vulnerabilities. It can arise from the change of data or misconfiguration of an equipment (e.g. by All assets car components mechanics or OEM staff during maintenance) configuration or simply because defined security procedures were not followed.

Unintentional Damages

This may typically concern administration

(accidental)

errors in back-end services or errors when (In-vehicle Information leakage - Information storing data intended for diagnostic in communication - Humans garages, for example.

components)

Unintentional damages may cascade from illdefined trust relationships: for example, Using information trusting a third-party cloud provider with poor and/or devices from All assets data protection, or failing to notify a Tier an unreliable source developer that the data they will store is sensitive.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Threat Threat Description Impacted Assets Category

-Vehicle sensors and actuators

- Decision making Unintentional damage to car components algorithms (e.g. cameras or autonomous sensors) due - Functions to an erroneous use or misconfiguration by - In-vehicle a smart cars’ users, insufficiently trained Erroneous use or OEM staff members (e.g. incompatibilities communication configuration of car components between components), mechanics (e.g. components when using diagnostic equipment), or lack - In-vehicle of adaptation to the changing threat communication landscape (the use of vulnerable networks cryptography is an example of this). - Information

- Humans

- Mobile devices

- Decision making algorithms

- External GNSS jamming that may be either communication performed by the smart car legitimate user components (e.g. to fraud GNSS tolls, avoid tracking Loss of GNSS signal mechanisms) or by an external attacker - Servers, systems and cloud computing aiming to disrupt the proper functioning of the vehicle. - Information - Humans Outages - Mobile devices

(Smart cars

Infrastructure This threat aims to partially or completely - Functions and Backend drain the smart car battery (e.g. through the systems) Car depleted battery use of a malware). The attacker’s goal is to - Humans decrease the overall performance of a car, - Mobile devices or immobilize it.

This threat aims to bring down internal (e.g. CAN bus) and/or external (e.g. C-V2X) networks so that the vehicle cannot operate normally. Such attacks can arise from Network outage All assets improper configurations (e.g. CAN bus overload due to multiple applications accessing data at the same time) or from targeted attacks (e.g. DDoS).

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Threat Threat Description Impacted Assets Category

Breach of contractual requirements by Tier Failure to meet 1 and/or Tier 2 car components or software contractual All assets suppliers. Such threat may lead to financial, requirements safety, privacy and/or operational impacts.

Lack of compliance with international or

Legal

European regulations and laws (e.g. GDPR and UNECE regulations). Such threat may have an impact on users’ privacy (e.g. disclosure of user’s personal information) or road users’ safety (e.g. no eCall feature). In Violation of rules and particular, the abuse of personal data regulations/Breach of consists in compromising sensitive and All assets legislation/ Abuse of private data (e.g. authentication credentials, personal data name and address, daily commutes) stored in the smart cars or in OEM/service providers backend servers. The attacker’s main goal is to retrieve individuals’ private information in order to sell it, or even use it for another attack vector (e.g. social engineering, phishing).

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

ANNEX C: SECURITY MEASURES MAPPING

Security Security Measures/ Good Practices Threat Groups References Domain

Adopt a Security by Design Approach.

Treat automotive cybersecurity as a cycle, and not as a one-off process. Take into consideration cybersecurity aspects in any activity of the development of the solution from the very beginning. Adopt -UNECE- ECE/TRANS/WP.29/GRVA/2019/2 -- Automated/autonomous security by design approach both from and connected vehicles: Cyber security and data protection -- Proposal for the vehicle as well as from the a Recommendation on Cyber Security infrastructure perspective. -Safety First for Automated Driving -US Department of Transportation - Cybersecurity Best Practices for In particular, the secure design should Security by Modern Vehicles demonstrate how the vehicle security All design -SCOUT - Report on the state of the art of connected and automated covers the threats identified in the risk driving in Europe assessment. Design should also take into account cybersecurity key principles such -PAS 1885:2018 The fundamental principles of automotive cyber security as defence in depth, principle of least specification, bsi privilege, disabling of test/debug features and ports, etc. Regarding critical services, more resilient/advanced solutions, such as hardware-supported Trusted Computing Base (TCB), may be used.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

-UNECE- ECE/TRANS/WP.29/GRVA/2019/2 -- Automated/autonomous

and connected vehicles: Cyber security and data protection -- Proposal for

Address security in relevant

a Recommendation on Cyber Security specification documents. In each -Safety First for Automated Driving design document, include a chapter that -GSMA (Global System for Mobile Communications) - GSMA CLP.11 IoT addresses the security of all information Security Guidelines - Overview Document Security by and control systems in the smart vehicle All design and the corresponding infrastructure. This -US Department of Transportation - Cybersecurity Best Practices for

ensures that security aspects are Modern Vehicles

considered from the very begining of the -SCOUT - Report on the state of the art of connected and automated

concept phase, and not as an driving in Europe

afterthought.

Promote the use of DevSecOps

methodology. The DevSecOps process -Autonomous DevSecOps: Five Steps to a Self-Driving Cloud (ENT214-S) aims at merging the security discipline AWS re:Invent 2018 within DevOps, thus considering security Security by in every stage of the development -Redhat DevSecOps All design process. By having security and -What is DevSecOps? Developing more secure applications development teams working together -PAS 1885:2018 The fundamental principles of automotive cyber security early in the development lifecycle, Specification security naturally finds itself in the product

by design.

-PAS 1885:2018 The fundamental principles of automotive cyber security -

Consider including a security role

Specification

within the product engineering team.

Bring Information Technology (IT) / -Autonomous DevSecOps: Five Steps to a Self-Driving Cloud (ENT214-S) -

Security by

All Operational Technology (OT) people, AWS re:Invent 2018

design

including people in charge of security -Security Champions Playbook topics, together in all phases. Making

security an equal consideration alongside -Avoid Unnecessary Pain with a Security Champion

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

development and operations is a must for any stakeholder of the supply chain.

Consider applying privacy regulations.

OEMs and all third parties should address privacy related issues based on applicable local and international -UNECE- ECE/TRANS/WP.29/GRVA/2019/2 -- Automated/autonomous regulations such as the GDPR. To meet privacy-related regulatory requirements, and connected vehicles:Cyber security and data protection -- Proposal for a several privacy-preserving rules should Recommendation on Cyber Security Privacy by be followed such as defining the purpose • Legal -Safety First for Automated Driving design of private data processing, only collecting -SCOUT - Report on the state of the art of connected and automated a minimal amount of personal data and driving in Europe avoid collecting private data if they are -PAS 1885:2018 The fundamental principles of automotive cyber security not necessary. Privacy protection Specification accountability aspects should be taken into account, enabling OEMs, Tier 1 and Tier 2 to demonstrate the implemented measures and their effectiveness.

Conduct PIA. Autonomous vehicles may collect private information about the owner and/or passengers of the vehicle -GSMA (Global System for Mobile Communications) - GSMA CLP.11 IoT for a variety of purposes (e.g. Security Guidelines Overview authorization, comfort customization, Privacy by • Nefarious activity/abuse -IoT Alliance Australia - Internet of Things Security Guidelines v1.2 entertainment settings), thus PIA need to design • Legal be conducted in line with GDPR -Privacy Impact Assessment requirements to identify any potential -Data Protection Impact Assessment (DPIA) privacy related risk and define appropriate countermeasures to mitigate it.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

Perform Privacy Audits. Perform privacy audits during smart car development and over back-end systems -GSMA (Global System for Mobile Communications) - GSMA CLP.11 IoT that focus on how individuals’ private data Security Guidelines Overview Privacy by are handled, collected, stored and • Nefarious activity/abuse -IoT Alliance Australia - Internet of Things Security Guidelines v1.2 design processed, to ensure compliance with • Legal -GDPR: How to Perform a Data Audit privacy-related policies. Privacy audits should be performed on a regular basis, -GDPR checklist for data controllers at least once a year or even more frequently depending on PIA.

-Cloud Security Alliance - Identity and Access Management for the Internet of Things - Summary Guidance

Cloud Security Alliance - Security Guidance for Early Adopters of the - Internet of Things

-IEC - IEC 62443-3-3:2013 System security requirements and security levels

Use tools supporting asset

-ISO - ISO/IEC 27001:2013 Information technology -- Security techniques – management. Asset management • Nefarious activity/abuse Information security management systems -- Requirements systems should be robust. Used asset

Asset

management tools should be able to • Hijacking -ISO - ISO/IEC 27002:2013 Information technology -- Security techniques --

management

dynamically discover, identify and Code of practice for information security controls • Failures/Malfunctions enumerate assets specific to the -NIST - NIST SP 800 53r4: Security and Privacy Controls for Federal organization and smart cars ecosystem. Information Systems and Organizations

-NIST - NISTIR 8183: Cybersecurity Framework Manufacturing Profile

-SANS Institute - Vulnerability Management: Tools, Challenges and Best Practices

-PAS 1885:2018 The fundamental principles of automotive cyber security - Specification

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

Ensure that there exists a consistent

-Cloud Security Alliance - Security Guidance for Early Adopters of the and up-to-date asset inventory. This Internet of Things inventory should include, among others,

current firmware/operation system (OS) -Huawei - IoT Security White Paper 2017 • Nefarious activity/abuse version, used hardware, supported -IEC - IEC 62443-3-3:2013 System security requirements and security Asset communication protocols, etc. Asset • Hijacking levels management inventory should also include gathered • Failures/Malfunctions known vulnerabilities related to particular -NIST - Draft NISTIR 8228: Considerations for Managing Internet of Things • Physical attacks assets. The responsibility for maintaining (IoT) Cybersecurity and Privacy Risks

an up-to-date asset inventory should be -PAS 1885:2018 The fundamental principles of automotive cyber security clearly defined and assigned to the Specification system owner.

Introduce a new device or software change into the vehicle only according

to an established, accepted and -IEC - IEC 62443-3-3:2013 System security requirements and security

communicated change management levels

process. Do not allow any changes or -ISO - ISO/IEC 27002:2013 Information technology -- Security techniques -introduction of a new device or software Code of practice for information security controls unless designated approvals are • Nefarious activity/abuse

received. Approved changes should be -LNS - Putting Industrial Cyber Security at the top of the CEO agenda Asset • Hijacking documented and the relevant -NIST - NIST SP 800 53r4: Security and Privacy Controls for Federal

management

documentation updated. • Unintentional damages Information Systems and Organizations Emergency changes may be carried out • Physical attacks -NIST - Draft NISTIR 8228: Considerations for Managing Internet of Things based on a verbal approval from the (IoT) Cybersecurity and Privacy Risks Change Management Committee Head and the system owner. However, post -PAS 1885:2018 The fundamental principles of automotive cyber security -

emergency, the standard procedure for Specification

documenting the change and risk

analysis is to be applied.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

Adopt an approach to risk

-ISO - ISO/IEC 27002:2013 Information technology -- Security techniques --

management dedicated to the

Code of practice for information security controls

automotive sector.

-NIST - NIST SP 800 30r1 - Guide for Conducting Risk Assessments The approach to risk management should -NIST - NIST SP 800 53r4: Security and Privacy Controls for Federal Risk and consider new parameters, threats and Information Systems and Organizations Threat attack scenarios targeting smart cars All -NIST - NIST SP 800 82r2: Guide to Industrial Control Systems (ICS) management ecosystem, and cover all Security interdependencies between cyber- -NIST - NISTIR 8183: Cybersecurity Framework Manufacturing Profile physical scenarios, cyber-physical -PAS 1885:2018 The fundamental principles of automotive cyber security – environmental and safety during the Specification assessment phase.

Risk and threat analysis. Perform risk and threat analysis involving cybersecurity experts from the very early stages of the design process of the -PAS 1885:2018 The fundamental principles of automotive cyber security vehicle to identify critical assets as well Specification as security risks and associated -Safety First for Automated Driving mitigations. -European Commission -- Access to In-vehicle Data and Resources

Risk and

Threat Cybersecurity risks targeting smart cars All -US Department of Transportation - Cybersecurity Best Practices for management should be assessed and prioritized to Modern Vehicles establish efficient security measures. - ETSI TR 102 893: Intelligent Transport Systems (ITS); Security; Threat, Risk and threat analysis should be Vulnerability and Risk Analysis (TVRA) revisited at least annually, and upon any major change or in case of critical security vulnerabilities detection or critical security incidents.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

Monitor security vulnerabilities. Once a vehicle is on the market, the OEM should consider the monitoring of security -UNECE- ECE/TRANS/WP.29/GRVA/2019/2 -- Automated/autonomous vulnerabilities and fix security flaws and connected vehicles:Cyber security and data protection -- Proposal for a accordingly. The vulnerabilities Recommendation on Cyber Security Risk and monitoring could include developer -Safety First for Automated Driving Threat findings, on-line researches, CSIRTs All -SCOUT - Report on the state of the art of connected and automated driving in Europe management advisories, as well as input from customers and security researchers. -ENISA - Cyber Security and Resilience of Smart Cars Vulnerabilities monitoring should be -PAS 1885:2018 The fundamental principles of automotive cyber security regularly performed, for instance every 6 Specification months or even more frequently based on risk assessment.

Penetration testing. Conduct security evaluations (e.g. penetrations tests) -UNECE- ECE/TRANS/WP.29/GRVA/2019/2 -- Automated/autonomous during the development phase and then and connected vehicles:Cyber security and data protection -- Proposal for a on a regular basis following an event • Nefarious activity / Abuse Recommendation on Cyber Security Risk and driven approach, e.g. after major updates • Failures/Malfunctions -ETSI - ETSI TR 102 893 V1.2.1 -- Intelligent Transport Systems: Security, Threat or in the case of new threats or Threat, Vulnerability and Risk Analysis • Hijacking management vulnerability. Such testing should cover all -Safety First for Automated Driving layers of the smart cars. To facilitate • Physical attacks evaluations, frameworks for validation -PAS 1885:2018 The fundamental principles of automotive cyber security and verification from external laboratories Specification should be provided.

Consider defining a threat intelligence -Auto ISAC - Automotive Cybersecurity Best Practices - Executive process. Consider incorporating a threat Summary Risk and intelligence process within the threat -Cloud Security Alliance - Security Guidance for Early Adopters of the Threat management approach of automotive All Internet of Things management organisations in order to be informed on -GSMA (Global System for Mobile Communications) - GSMA CLP.14 IoT emerging attack types and sources, as Security Guidelines for Network Operators well as new relevant vulnerabilities. -Huawei - IoT Security White Paper 2017

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

Organizations should rely on various -IIC (Industrial Internet Consortium) - IoT Security Maturity Model: sources of information (e.g. other OEMs, Description and Intended Use specilized entities, CWE and CVE -International Telecommunications Union - Security capabilities supporting common sources, etc.) and share safety of the Internet of things information with trusted industry partners, -NIST - NIST SP 800 30r1 - Guide for Conducting Risk Assessments ISACs and CSIRTs. -NIST - NIST SP 800 53r4: Security and Privacy Controls for Federal Information Systems and Organizations Determine the impact of threats detected through the threat intelligence process by performing a risk analysis.

-ENISA - Cyber Security and Resilience of smart cars

Regularly assess the security controls

-UNECE- ECE/TRANS/WP.29/GRVA/2019/2 -- Automated/autonomous and patch vulnerabilities. Smart cars and connected vehicles:Cyber security and data protection -- Proposal for a actors should define appropriate Recommendation on Cyber Security assessment procedures to regularly

Risk and

check, at least once a year or more -Five Star Automotive Cyber Safety Program Threat All frequently based on risk assessment or management -Securing the Modern Vehicle patch deployment, the effectiveness of their security measures, and patch them -Security Development Lifecycle (SDL) whenever needed. Patches should be -PAS 1885:2018 The fundamental principles of automotive cyber security tested before deployment. Specification

Regularly check the security assumptions over smart cars lifecycle.

Assumptions are made to ensure that the -ENISA - Cyber Security and Resilience of smart cars security requirements are sufficient based -UNECE- ECE/TRANS/WP.29/GRVA/2019/2 -- Automated/autonomous Risk and on risk and threat analysis. These and connected vehicles:Cyber security and data protection -- Proposal for a Threat assumptions include, but are not limited All Recommendation on Cyber Security management to, operational environment assumptions, -Five Star Automotive Cyber Safety Program limitations in the usage of the vehicle, -Securing the Modern Vehicle assumed properties of cryptographic schemes, etc. Vendors and users should be encouraged to regularly check, for

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

instance every 6 months or even more

frequently based on risk assessment, that these assumptions are still valid over

smart cars lifecycle.

Security assumptions need to be updated according to significant systems

changes/updates, support of new

technologies and/or communication mechanisms/technologies, etc. In particular, a procedure for communication

and handling of end of life/out of warranty status for cybersecurity may be defined.

Foster security-related information sharing between the different

-UNECE- ECE/TRANS/WP.29/GRVA/2019/2 -- Automated/autonomous

stakeholders while protecting

and connected vehicles:Cyber security and data protection -- Proposal for a intellectual property. Suppliers and Recommendation on Cyber Security service providers should provide -COLLABORATION AND ENGAGEMENT WITH APPROPRIATE THIRD Relationships evidences about the implementation of All PARTIES with suppliers their cybersecurity management system to a vehicle manufacturer, as stated in -Auto ISAC - Automotive Cybersecurity Best Practices

UNECE regulation. For transparency -PAS 1885:2018 The fundamental principles of automotive cyber security purposes, OEMs should consider Specification providing similar evidences to their suppliers and service providers as well.

Define cybersecurity relevant aspects -Auto ISAC - Automotive Cybersecurity Best Practices • Nefarious activity/abuse of the partnerships along the supply -UNECE- ECE/TRANS/WP.29/GRVA/2019/2 -- Automated/autonomous

Relationships

chain, and develop security • Failures/Malfunction and connected vehicles:Cyber security and data protection -- Proposal for a

with suppliers

requirements and procurement Recommendation on Cyber Security • Unintentional damages guidelines for suppliers. -European Commission -- Access to In-vehicle Data and Resources

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

To prevent security risks and threats that -PAS 1885:2018 The fundamental principles of automotive cyber security may stem from outsourced services or Specification components/systems provided by third party suppliers, organisations should define procurement guidelines as well as security requirements to be applied to their third parties suppliers. A security SLA may also be established between the organisation and its supplier to define the security level that the the supplier should meet.

Information sharing between different

actors. All organisations, including subcontractors, suppliers and third parties should work together to enhance the -UNECE- ECE/TRANS/WP.29/GRVA/2019/2 -- Automated/autonomous security of smart cars. and connected vehicles:Cyber security and data protection -- Proposal for a Recommendation on Cyber Security Organisations should consider

Training and

All -European Commission -- Access to In-vehicle Data and Resources communicating with other companies on

awareness

- Auto ISAC - Automotive Cybersecurity Best Practices a sector level including the supply chain and participate in international security -PAS 1885:2018 The fundamental principles of automotive cyber security events and working groups formed to Specification enable discussion, cooperation and intelligence sharing across organisations to improve security awareness.

Adopt a holistic approach to security -ENISA - Good practices for Security of Internet of Things in the context of • Nefarious activity / Abuse training and awareness among the Smart Manufacturing employees, including employees on all -IEC - IEC 62443-2-1:2010 Establishing an industrial automation and

Training and

levels of the organization. Security control system security program

awareness

• Unintentional damages training should cover smart cars relevant -ISO - ISO/IEC 27002:2013 Information technology -- Security techniques -threats and be tailored to the employees' Code of practice for information security controls roles and responsibilities and the different -NIST - NIST SP 800 53r4: Security and Privacy Controls for Federal

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

level of knowledge of the participants. For Information Systems and Organizations instance, all newly hired employees and -NIST - NIST SP 800 82r2: Guide to Industrial Control Systems (ICS) employees that change responsibilities Security should be provided with an appropriate -NIST - NISTIR 8183: Cybersecurity Framework Manufacturing Profile cybersecurity training when starting their -World Economic Forum - Industrial Internet of Things: Unleashing the new job. Potential of Connected Products and Services

-PAS 1885:2018 The fundamental principles of automotive cyber security - Specification

-ENISA - Good practices for Security of Internet of Things in the context of Smart Manufacturing -Cloud Security Alliance - Identity and Access Management for the Internet of Things - Summary Guidance

Ensure that security trainings are

-Cloud Security Alliance - Security Guidance for Early Adopters of the

continuous, regular and frequently

Internet of Things updated. Training programs should be • Nefarious activity / Abuse Training and -IEC - IEC 62443-2-1:2010 Establishing an industrial automation and updated after new important threats • Unintentional damages control system security program

awareness

disclosure and adjusted according to the -ISO - ISO/IEC 27002:2013 Information technology -- Security techniques -lessons learned from ongoing incident Code of practice for information security controls handling and recovery activities. -NIST - NIST SP 800 82r2: Guide to Industrial Control Systems (ICS) Security -NIST - NISTIR 8183: Cybersecurity Framework Manufacturing Profile

Raise vehicle users' awareness. -ENISA - Cybersecurity and resilience of smart cars Vendors and public authorities should • Nefarious activity / Abuse -Insecurity in the Internet of Thing explain to vehicle owners, drivers and

Training and

passengers which actions can contribute -IoT Security Awareness awareness • Unintentional damages to mitigate potential threats, such as how -Consumers don't care if their connected car can get hacked - here's why to securely use interfaced systems such that's a problem as smartphones and onboard tablets,

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

basic security best practices, etc. This -Shifting gears in cyber security for connected cars should be done on a regular basis, especially when significant changes/patches occur or when new threats emerge.

Consider establishing a Security

Operation Center (SOC). Consider the creation of a SOC consisting of OT and IT cybersecurity specialists with clearly defined roles, responsibilities and cybersecurity competences to centralize -ENISA - Good practices for Security of Internet of Things in the context of knowledge on cybersecurity, monitor and Smart Manufacturing Security anticipate potential threats by ensuring All -Security Operations Center management that potential security incidents are -MITRE :Cybersecurity Operations Center correctly identified, investigated and reported. Managing and acting upon the growing number of security alerts can become very complex, especially for large fleets. Therefore, a robust SOC is needed to ensure all alerts are analyzed and handled properly.

Designate one or several dedicated

security team(s). As dealing with cybersecurity issues requires a very -ENISA - Cybersecurity and resilience of smart cars narrow set of skills, actors of the smart Security car industry should rely on specialists to -Securing the Modern Vehicle: A Study of Automotive Industry All management perform several kinds of activities, notably Cybersecurity Practices risk management, secure design, training -30% of Automotive Companies Lacking a Dedicated Cybersecurity Team and awareness, penetration testing and corporate security. Whether this security team(s) should be in-house or a third-

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

party company is not indifferent in some cases; in particular, risk management and corporate security require a very good knowledge of the company to be easily outsourced.

Define a dedicated Information Security Management System (ISMS).

Vehicles in the wild cannot be completely protected if the company itself is not able to properly protect critical assets. For example, if vehicles or components have -ENISA - Cybersecurity and resilience of smart cars keys injected during production, the risk -NIST - NIST SP 800 53r4: Security and Privacy Controls for Federal

Security

All Information Systems and Organizations of leaking these keys may be more

management

important on the company site than on -SAE J3061 the vehicles side. For this reason, an effective ISMS is of utmost importance. The SAE J3061 describes such an ISMS, and provides references to standards often used for this purpose (ISO 27001 and NIST 800-53).

Consider defining an internal task force involving board-level management to guide security-related

strategic decisions. OEM should All -Avoid Unnecessary Pain with a Security Champion consider the definition of an internal task

Security

force which should gather on a regular -Security Champions Playbook

management

basis, e.g. once every 3 months or more frequently when necessary, to discuss security-related strategic decisions. Board-level management shall be involved in this task force so as to discuss

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

the different topics and make appropriate decisions. Such approach would help with accountability in case of security incidents.

-Auto ISAC - Automotive Cybersecurity Best Practices - Executive

Establish an incident handling

Summary process. Establish a process for incidents handling that enables the -Cloud Security Alliance - Identity and Access Management for the Internet of Things - Summary Guidance identification of affected assets, identification and classification of -ISO - ISO/IEC 27002:2013 Information technology -- Security techniques -vulnerabilities, escalation and notification. Code of practice for information security controls

Make a revision of the process at least -NIST - NIST SP 800 53r4: Security and Privacy Controls for Federal Incident annually and as soon as possible in case Information Systems and Organizations All management of a major change, e.g. change in -NIST - NIST SP 800 82r2: Guide to Industrial Control Systems (ICS) organizational hierarchy, contracts, etc. Security Update the process with lessons learned -NIST - NISTIR 8183: Cybersecurity Framework Manufacturing Profile from analysing and resolving -SANS Institute - Vulnerability Management: Tools, Challenges and Best security incidents. Practices Test the process at least annually and -PAS 1885:2018 The fundamental principles of automotive cyber security consider different possible incidents. Specification

Consider establishing a CSIRT and a

PSIRT. OEMs and third-party suppliers/providers (i.e. Tier 1and Tier 2) -Cybersecurity Best Practices for Modern Vehicles – NHTSA should consider building a CSIRT and

Incident

PSIRT. Working closely with the SOC, All -CSIRTs in Europe

management

the CSIRT and PSIRT ultimate goal is to -Cybersecurity Best Practices for Modern Vehicles minimize and control the damage resulting from an incident. They do not only consist in addressing the threat itself,

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

but also communicate to customers, the organisation board, and public relevant information about the incident.

Incident Report to back-end servers.

OEMs and third party providers should implement cybersecurity monitoring and • Nefarious activity / Abuse reporting to back-end servers to ensure UNECE- ECE/TRANS/WP.29/GRVA/2019/2 -- Automated/autonomous and

Incident

systems are secure over their lifetime. • Failures/Malfunctions connected vehicles:Cyber security and data protection -- Proposal for a

management

Incident reporting enables the correction Recommendation on Cyber Security • Hijacking of the situation, and through incident analysis and corrective action, similar incidents are avoided.

Relevant cyber incidents definition

and classification. Consider defining cybersecurity incidents relevant for your organisation based on the company's area and range of operation and classify -ENISA - Good practices for Security of Internet of Things in the context of them according to applicable standards. Smart Manufacturing Incident By ensuring the distinction between All -Survey and Classification of Automotive Security Attacks – MDPI management specific attack vectors and methods, the effects such incident may produce on the -PAS 1885:2018 The fundamental principles of automotive cyber security targeted networks, the financial impacts Specification or their broader effects on society, it will be easier to identify the most critical incidents, prioritise and respond to them in an efficient way.

Consider the establishment of a • Nefarious activity / Abuse -UNECE- ECE/TRANS/WP.29/GRVA/2019/2 -- Automated/autonomous Incident secure and reliable process for and connected vehicles:Cyber security and data protection -- Proposal for a • Failures/Malfunctions

management detecting and handling misbehaving

Recommendation on Cyber Security ITS stations. • Hijacking -PRESERVE - Security Requirements ofVehicle Security Architecture v1.1

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

ITS-S (e.g. vehicle) can misbehave, -ETSI - ETSI TR 102 893 V1.2.1 -- Intelligent Transport Systems: Security, either unintentionally due a system failure Threat, Vulnerability and Risk Analysis or intentionally as a result of malicious -C-ITS Platform, WG5: Security & Certification - Final Report - Annex 2: actions, and thus disrupt other vehicles Revocation of Trust in C-ITS and/or infrastructure. To prevent this, (https://smartmobilitycommunity.eu/sites/default/files/Security_WG5An2_v1 consider the establishment of a process .0.pdf) enabling to collect information provided by ITS Stations (e.g. through cooperation between the infrastructure and other vehicles), detect and handle any misbehavior. For instance, the credentials of misbehaving ITS-S may be revoked.

Deploy Intrusion Detection Systems (IDS) at vehicle and back-end levels.

An IDS is a device or software application designed to automatically detect malicious activities or policy violations. An IDS should be able to detect various -PRESERVE - Security Requirements ofVehicle Security Architecture v1.1 types of cyber-attacks (e.g. DDoS). • Nefarious activity / Abuse -Safety First for Automated Driving To do so, the IDS requires the ability to • Failures/Malfunctions -SCOUT - Report on the state of the art of connected and automated Detection capture and do a thorough examination of driving in Europe • Hijacking every packet which has been received or transferred between vehicles and • Physical attacks infrastructures, as well as packets exchanged over in-vehicle buses. Such systems can rely on artificial neural networks to classify malicious vehicles and sensors and exclude them from communicating with the system.

Maintain properly protected audit logs. -ENISA - cybersecurity resilience of smart cars Detection • Nefarious activity / Abuse Security events must be logged, and -UNECE- ECE/TRANS/WP.29/GRVA/2019/2 -- Automated/autonomous

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

access to the logs must be documented • Failures/Malfunctions and connected vehicles:Cyber security and data protection -- Proposal for a and protected from disclosure to Recommendation on Cyber Security • Hijacking unauthorized users. Logs are also -ACEA Principles of Automobile Cybersecurity needed for device integration. Typically, • Physical attacks -PAS 1885:2018 The fundamental principles of automotive cyber security - Tier-2 suppliers must provide Tier-1 • Unintentional damages Specification suppliers with the opportunity to understand security events happening in • Outages

their products. However, logs may also provide valuable information to an attacker, which is a serious security drawback. For this reason, the audit trail must be protected.

Since logs can be very resource-intensive and require a large storage space, OEMs should define where to store them (i.e. in the car or on a back-end server) and how long the stored data should be retained.

-Cloud Security Alliance - Security Guidance for Early Adopters of the Internet of Things -ENISA - Baseline Security Recommendations for IoT • Nefarious activity / Abuse -IEC - IEC 62443-3-3:2013 System security requirements and security Conduct periodic reviews. Consider • Failures/Malfunctions levels periodically reviewing network logs, • Hijacking -IIC (Industrial Internet Consortium) - IIC Endpoint Security Best Practices access control privileges and asset Detection -IoT Security Foundation - Connected Consumer Products. Best Practice configurations to detect any event that • Physical attacks Guidelines may represent a potential security threat • Unintentional damages -NIST - NIST SP 800 82r2: Guide to Industrial Control Systems (ICS) to smart cars ecosystem. Security • Outages -NIST - Draft NISTIR 8228: Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks -OWASP (Open Web Application Security Project) - IoT Security Guidance

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

-SANS Institute - An Abbreviated History of Automation & Industrial Controls Systems and Cybersecurity

Perform data validation. Data validation techniques, such as plausibility checks are non-cryptographic measures which use rules and other mechanisms to -“My autonomous car is an elephant”: A Machine Learning based Detector determine the correctness likelihood of for Implausible Dimension • Nefarious activity / Abuse received data. For instance, AI-based -Safety First for Automated Driving • Failures/Malfunctions -ETSI - ETSI TR 102 893 V1.2.1 -- Intelligent Transport Systems: Security, techniques can be used to measure the

Detection

likelihood of incoming information (e.g. Threat, Vulnerability and Risk Analysis • Hijacking node misbehaviour detection using -PAS 1885:2018 The fundamental principles of automotive cyber security - • Unintentional damages Specification machine learning based detector, "object existence" metrics) to counter spoofing attacks on V2X communications or malicious alteration of the physical world (e.g. fake speed limit sign).

Define forensic procedures. OEMs • Nefarious activity / Abuse should define forensics procedures for • Failures/Malfunctions incident investigation so as to enable events reconstruction, facilitate crash • Threats against (semi-) investigation, identify the leveraged autonomous systems -A survey on open automotive forensics Detection weakness and prevent similar attacks, as -ENISA - Cyber Security and Resilience of Smart Cars • Unintentional damages well as for accountability purposes. Such -Log your car: the non-invasive vehicle forensics procedure should follow proven principles • Outages to ensure that reconstructed traces are • Legal authentic, have not been altered and can be analysed. • Physical attacks

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

Protect remote monitoring and

administration interfaces. The protection of remote monitoring and administration interfaces is crucial since they often provide a highly-privileged • Nefarious activity / Abuse Protection of entry point into a device. Thus, -ENISA - Cyber Security and Resilience of smart cars networks and monitoring and administration interfaces • Failures/Malfunctions -AUTOMOTIVE WORKING GROUP protocols must not only be protected by whitelisting, • Hijacking but also through mutual authentication and access control mechanisms. This protection includes access control for both the gateway and ECU level and authentication mechanisms.

-UNECE- ECE/TRANS/WP.29/GRVA/2019/2 -- Automated/autonomous

Protect in authenticity and integrity all

critical internal communications. and connected vehicles:Cyber security and data protection -- Proposal for a Authentication is essential to prevent • Nefarious activity / Abuse Recommendation on Cyber Security Protection of spoofing or replay attacks. At the sensor -PRESERVE - Security Requirements of Vehicle Security Architecture v1.1 • Failures/Malfunctions -Safety First for Automated Driving networks and level, authentication mechanims can be • Hijacking -European Commission -- Access to In-vehicle Data and Resources protocols used to allow ECUs/TCUs to authenticate -SCOUT - Report on the state of the art of connected and automated each other over the CAN bus before • Physical attacks reacting on their commands or sensor driving in Europe

data.

Protect in authenticity and integrity all -UNECE- ECE/TRANS/WP.29/GRVA/2019/2 -- Automated/autonomous external communications. and connected vehicles:Cyber security and data protection -- Proposal for a • Nefarious activity / Abuse Authentication is essential to prevent Recommendation on Cyber Security

Protection of

spoofing or replay attacks. Regarding • Failures/Malfunctions networks and -PRESERVE - Security Requirements of Vehicle Security Architecture v1.1 V2V and V2X communications, • Hijacking protocols -European Commission -- Access to In-vehicle Data and Resources authentication is crucial to ensure the • Physical attacks trustworthiness of incoming/outgoing -SCOUT - Report on the state of the art of connected and automated information. driving in Europe

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

Enforce session management policies

to avoid session hijacking. Session management contributes to making sure that the authorized user is the one using a given session. This covers the different communication sessions such as administration sessions. Typically, the following rules should be followed: • Sensitive functions such as -ENISA - Cyber Security and Resilience of smart cars Protection of administration via web services should • Nefarious activity / Abuse networks and require re-authentication. -OWASP: Session Management Cheat Sheet • Hijacking

protocols

• No data should be transmitted before Session fixation authorization. • Strong (random) session handlers should be used to avoid replay. • The user must know at any time if, and why, they are logged on a particular service, meaning that no passive sign-up for third party services should be performed.

Timestamp all messages. Including a timestamp in all messages makes it easier for a receiving ITS-S to judge • Nefarious activity / Abuse -PRESERVE - Security Requirements of Vehicle Security Architecture v1.1 Protection of whether a message is recent, and thus networks and valid (or not). It also prevents replay • Failures/Malfunctions -ETSI - ETSI TR 102 893 V1.2.1 -- Intelligent Transport Systems: Security, protocols attacks. • Hijacking Threat, Vulnerability and Risk Analysis If the time is derived from an external source such as Universal Coordinated Time (UTC) or GNSS, it should be

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

ensured that each ITS-S uses the same time source as every other ITS-S. Consequently, it is quite simple for the plausibility of the timestamp in a message to be validated. The use of a precision timing source (e.g. hardware clock source, NTP) to provide accurate time may be considered as well.

Manage radio spectrum frequencies as well as the frequency of beaconing

and other repeated messages. The use of beaconing messages in V2V/V2X communications and the repetition of some non-beacon messages generates considerable background radio traffic in high-density road-traffic environments. • Nefarious activity / Abuse Protection of -ETSI - ETSI TR 102 893 V1.2.1 -- Intelligent Transport Systems: Security, In order to prevent DDoS attacks, • Failures/Malfunctions networks and Threat, Vulnerability and Risk Analysis consider reducing the frequency of the • Hijacking protocols -PRESERVE - Security Requirements of Vehicle Security Architecture v1.1 beacon and other safety-of-life messages • Physical attacks in order to reduce congestion. Adaptive frequency control, where messages would be sent at different frequencies depending upon the nature of the message and potentially other local conditions, may be a good alternative as well.

Implement frequency agility. A radio • Nefarious activity / Abuse

Protection of

transmission broadcast at the same -ETSI - ETSI TR 102 893 V1.2.1 -- Intelligent Transport Systems: Security,

networks and

frequency at all times can be easily Threat, Vulnerability and Risk Analysis

protocols

• Hijacking overwhelmed by a higher-power signal at

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

the same frequency. However, it is much -CAR 2 CAR Communication Consortium - FAQ regarding Data Protection more difficult to jam a transmission in in C-ITS v1,0,0 which the radio frequency changes frequently within its defined band. If the changes in frequency and the intervals between changes are both determined on pseudo-random basis, it becomes even more difficult to jam the signal. There needs to be synchronization between the legitimate transmitter and the receiver, and both need to use the same algorithms for determining frequency steps and the intervals between changes in frequency.

Packet filtering. Filter communications at each network layer: ECU and sensor -UNECE- ECE/TRANS/WP.29/GRVA/2019/2 -- Automated/autonomous networks, VANET, 2-5G communications. • Nefarious activity / Abuse Protection of and connected vehicles:Cyber security and data protection -- Proposal for a During network communication, a node networks and • Failures/Malfunctions Recommendation on Cyber Security transmits a packet that is filtered and protocols -SCOUT - Report on the state of the art of connected and automated matched with predefined rules and • Hijacking driving in Europe policies. Once matched, a packet is either accepted or denied.

Provide end-to-end protection in confidentiality and integrity using

secure protocols. Favor methods -ENISA - Cyber Security and Resilience of smart cars • Nefarious activity / Abuse Protection of providing forward secrecy whenever -ETSI - ETSI TR 102 893 V1.2.1 -- Intelligent Transport Systems: Security, networks and possible. This should be true even for the • Failures/Malfunctions Threat, Vulnerability and Risk Analysis protocols communication of already encrypted data; • Hijacking encryption must cover not only external -European Commission -- Access to In-vehicle Data and Resources communications (e.g. V2X), but also invehicle networks.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

The default configuration of devices

and services should be secured. The

operation mode of the device (or service) should be the most secure one by default. -ENISA - Cyber Security and Resilience of Smart Cars • Nefarious activity / Abuse A user might arguably want to disable a -Secure Device Configuration Guideline Software given security function, but this should be • Failures/Malfunctions

-Cybersecurity Best Practices for Modern Vehicles security the consequence of a deliberate action • Hijacking from the user, and the user should be -PAS 1885:2018 The fundamental principles of automotive cyber security - • Unintentional damages warned that this change reduces the Specification security of the solution. Default

passwords and usernames be changed on first use (of the vehicle, service, etc).

Software authenticity and integrity

checked before installation. By

validating the authenticity and integrity of

software it is possible to ensure that only -ETSI - ETSI TR 102 893 V1.2.1 -- Intelligent Transport Systems: Security, authorized updates and extensions can • Nefarious activity / Abuse Threat, Vulnerability and Risk Analysis

Software be downloaded and installed. • Failures/Malfunctions -PAS 1885:2018 The fundamental principles of automotive cyber security security Mechanisms for restricting the Specification applications that can be installed should • Hijacking

be in place. In general, a signature is

included over the application package together with a certificate of the signing trusted third party.

Implement and document changes in • Nefarious activity / Abuse -IEC - IEC 62443-3-3:2013 System security requirements and security

configuration according to a change

• Failures/Malfunctions levels

Software management policy developed by the

-ISA - ANSI/ISA-95 Part 1: Models and Terminology

security organisation based on risk analysis.

• Hijacking -ISO - ISO/IEC 27001:2013 Information technology -- Security techniques -- This policy should include responsibility • Physical attacks Information security management systems – Requirements (i.e. system owner, approvers, etc.) and -NIST - NIST SP 800 53r4: Security and Privacy Controls for Federal

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

security aspects. The business owners of Information Systems and Organizations

assets should approve all changes. -NIST - NIST SP 800 82r2: Guide to Industrial Control Systems (ICS)

Security

-NIST - NISTIR 8183: Cybersecurity Framework Manufacturing Profile

Siemens - Industrial Security: Applying IoT Security Controls on the

Industrial Plant Floor

Use of secure OTA firmware updates.

-UNECE- ECE/TRANS/WP.29/GRVA/2019/2 -- Automated/autonomous OTA updates are essential to patch and connected vehicles:Cyber security and data protection -- Proposal for a vulnerabilities identified once vehicles are Recommendation on Cyber Security in the field. They should rely on strong -Securing the Modern Vehicle: A Study of Automotive Industry authentication mechanisms (e.g. digital • Nefarious activity / Abuse Cybersecurity Practices signature) to ensure the authenticity and -Gowling WLG & UK Autodrive - Connected and Autonomous Vehicles: A Software integrity of the firmware to prevent the • Failures/Malfunctions Hacker's Delight? security installation of rogue firmware and the • Hijacking -SCOUT - Report on the state of the art of connected and automated

spread of malwares. Rollback to driving in Europe • Unintentional damages vulnerable versions should be prevented -Safety First for Automated Driving as well. Encryption is also a good practice -European Commission -- Access to In-vehicle Data and Resources to prevent binaries analysis in order to

protect the IP and the discovery of zero-

day vulnerabilities.

Protect OTA update process. Because -UNECE- ECE/TRANS/WP.29/GRVA/2019/2 -- Automated/autonomous poorly executed OTA updates can result • Nefarious activity / Abuse and connected vehicles:Cyber security and data protection -- Proposal for a in malfunctioning vehicles and significant Recommendation on Cyber Security inconvenience to consumers, as well as • Failures/Malfunctions

-Securing the Modern Vehicle: A Study of Automotive Industry Software reputational damage to the OEM, • Hijacking Cybersecurity Practices security dedicated security measures should be • Physical attacks -Gowling WLG & UK Autodrive - Connected and Autonomous Vehicles: A implemented to ensure a secure OTA Hacker's Delight? update process. Access controls to OEM • Unintenational damages -SCOUT - Report on the state of the art of connected and automated back-end servers as well as recovery driving in Europe measures in case of errors (e.g. reversion

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

if the OTA image fails to boot -Safety First for Automated Driving successfully) should be considered. -European Commission -- Access to In-vehicle Data and Resources

Use of secure boot mechanisms.

Secure boot is essential to ensure the trustworthiness (i.e. authenticity and integrity) of the executed software. Secure boot mechanisms essentially consist in signing the software with a private key owned by the manufacturer. • Nefarious activity / Abuse -Cybersecurity Solutions for Connected Vehicles The signature is verified during the Software • Failures/Malfunctions -Securing Self-Driving Cars secure boot procedure with the help of security -Safety First for Automated Driving • Hijacking the corresponding certificate. If -European Commission -- Access to In-vehicle Data and Resources verification fails because the software has • Unintentional damages been altered, the boot process should react accordingly (e.g. run emergency program to guarantee the functional safety of the vehicle). A risk-based approach may be used to identify when secure boot is actually needed.

Mitigate vulnerabilities and limitations of libraries for standard protocols, or address them in risk assessment.

• Nefarious activity / Abuse Using an open source security library (e.g. OpenSSL) or proprietary software • Failures/Malfunctions -ENISA - Cyber Security and Resilience of Smart Cars

Software

does not mean that the product will security -Using Open Source for security and privacy protection • Hijacking automatically be secure. Developers must be aware of the vulnerabilities (e.g. due to • Physical attacks a flawed implementation) and limitations (e.g. vulnerability of the protocol itself) of the used software. They should mitigate

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

them whenever possible by performing patching and by securing the configuration of the communication stacks.

Protect mobile applications against reverse engineering and tampering of

their binary code. Code obfuscation techniques may be used to prevent the • Nefarious activity / Abuse reverse engineering of smart cars mobile Software • Failures/Malfunctions - OWASP – Mobile Application Security Verification Standard applications. To enable the detection of security • Hijacking - ENISA – Smartphone Secure Development Guidelines the tampering of mobile application binary code, mobile applications should be • Physical attacks signed. Root detection mechanisms may be implemented as well to check if the device was rooted.

Securely store sensitive data on mobile devices, and protect local files

created by the mobile application. No sensitive data (e.g. passwords, credentials, cryptographic keys etc.) should be stored outside the application • Nefarious activity / Abuse container or mobile operating system Software credential storage facility (e.g. Keystore, • Failures/Malfunctions - OWASP – Mobile Application Security Verification Standard security Keychain). In particular, no sensitive data - ENISA • Hijacking – Smartphone Secure Development Guidelines should be written in application logs. • Physical attacks Access to data stored in the credential storage facility should be limited to authorized users. Local files created by the mobile application should also be protected and deleted when no longer needed.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

Include security and availability -Federal Office for Information Security (BSI) - BSI-Standards 100-4 -

aspects in agreements with cloud Business Continuity Management

security providers. Responsibilities for • Nefarious activity / Abuse -GSMA (Global System for Mobile Communications) - GSMA CLP.12 IoT cloud security aspects shall be clearly Cloud security • Outage Security Guidelines for IoT Service Ecosystems defined and allocated to particular parties -Online Trust Alliance - IoT trust framework 2.5 or persons. Availability of service shall be • Legal

measurable and defined through -PAS 1885:2018 The fundamental principles of automotive cyber security -

specified parameters. Specification

-NIST - NIST SP 800-146 Cloud Computing Synopsis and Avoid single points of failure. In the Recommendations context of cloud-based application and -Online Trust Alliance - IoT trust framework 2.5 centralised systems, single points of • Failures/Malfunctions -SANS Institute - Building the New Network Security Architecture for the Cloud security failure should be avoided. Redundancy • Outages Future techniques (e.g. several clusters) and

data replication may be used to avoid -PAS 1885:2018 The fundamental principles of automotive cyber security -

single points of failure. Specification

-Cloud Security Alliance - Future Proofing the connected world

Operate critical systems and

applications within the private or at -Cloud Security Alliance - Identity and Access Management for the Internet

of Things - Summary Guidance

least hybrid deployment models.

• Nefarious activity / Abuse -Cloud Security Alliance - Security Guidance for Early Adopters of the Privilege the use of a private cloud, or at Internet of Things Cloud security least a hybrid cloud which combines both • Hijacking

private and public cloud. When -GSMA (Global System for Mobile Communications) - GSMA CLP.12 IoT • Failure/Malfunctions -Online Trust Alliance - IoT trust framework 2.5 considering the use of a public cloud, a

risk analysis should be performed -PAS 1885:2018 The fundamental principles of automotive cyber security -

beforehand. Specification

• Nefarious activity / Abuse To mitigate the risk related to cloud -Federal Office for Information Security (BSI) - BSI-Standards 100-4 -

Cloud security

attacks, adopt a zero-knowledge • Hijacking Business Continuity Management

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

security approach. Cloud services -IoT Alliance Australia - Internet of Things Security Guidelines v1.2 providers should store and manage data -ISO - ISO/IEC 27001:2013 Information technology -- Security techniques -without access to the decryption keys. All Information security management systems – Requirements the data should be protected during -NIST - NIST SP 800 53r4: Security and Privacy Controls for Federal transfer as well as when at rest (i.e. Information Systems and Organizations stored within the cloud). Ideally, all data -NIST - NISTIR 8183: Cybersecurity Framework Manufacturing Profile should be encrypted to ensure its confidentiality. Application and interfaces should be secured as well.

Encrypt sensitive data as well as personal and private data.

Sensitive data include, amongst other, data needed to enforce security such as the configuration, different keys and certificates used for several purposes (e.g. encrypt/sign communications), as well as IP-related data. The disclosure of -ETSI - ETSI TR 102 893 V1.2.1 -- Intelligent Transport Systems: Security, keys and know-how for instance may be • Nefarious activity/abuse Threat, Vulnerability and Risk Analysis prevented through their encryption. •Εavesdropping/Interception Cryptography -CAR 2 CAR Communication Consortium - FAQ regarding Data Protection Moreover, authenticated encryption may /Hijacking in C-ITS v1,0,0 be used to additionally ensure data • Legal integrity. Personal and private data covers all pieces of information that can be used to positively identify a vehicle, an ITS user, the location and behavior of a particular vehicle or its route. By encrypting personal and private data it is possible to ensure that traffic analysis and eavesdropping alone cannot reveal

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

sufficient information to directly extract or indirectly deduce private information.

Do not use proprietary cryptographic schemes and protocols, but rather state-of-the-art standards instead.

Even a home-brewed implementation of a • Nefarious activity / Abuse standard is not a good practice when standard implementations are available. If • Failures/Malfunctions -ENISA - Cyber Security and Resilience of smart cars needed, consider getting advice from Cryptography -European Commission -- Access to In-vehicle Data and Resources • Hijacking security experts or your national cybersecurity agency. This applies also to • Physical attacks random number generation which is a • Unintentional damages critical part of the cryptographic support. A possible recommendation would be the use of cryptographically secure pseudorandom number generators.

Use storage encryption. Encrypted storage is not only useful to protect user data, but also to protect data that is needed to enforce smart cars security. Internal data may be just as sensitive as user data, but are often not protected • Nefarious activity / Abuse -ENISA - Cyber Security and Resilience of smart cars enough, leading for example, to situations Safety First for Automated Driving • Failures/Malfunctions Cryptography where hardcoded root credentials, API -ETSI - ETSI TR 102 893 V1.2.1 -- Intelligent Transport Systems: Security, • Hijacking Threat, Vulnerability and Risk Analysis keys, URLs never meant to be known to end-users, and manufacturing network • Legal configurations are found in cleartext and may be disclosed to unauthorised entities. As a general rule, configuration data should be encrypted at rest and in transit.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

Implement a secure key management

process. Cryptographic keys should be

securely generated, provisioned, used,

stored, and deleted/revoked. Badly

implemented key management can

introduce vulnerabilities that may easily -UNECE- ECE/TRANS/WP.29/GRVA/2019/2 -- Automated/autonomous be exploited. Devices without direct user and connected vehicles:Cyber security and data protection -- Proposal for a interfaces are particularly vulnerable to Recommendation on Cyber Security • Nefarious activity / Abuse PKI compromising. While users can -ETSI - ETSI TR 102 893 V1.2.1 -- Intelligent Transport Systems: Security, easily delete or install certificates on a • Failures/Malfunctions Threat, Vulnerability and Risk Analysis PC, embedded devices (e.g. ECUs) rely -European Commission -- Access to In-vehicle Data and Resources Cryptography • Hijacking mostly on remote administration, and do -SCOUT - Report on the state of the art of connected and automated not even allow end-users to perform such • Physical attacks driving in Europe administration tasks. For this reason, • Unintentional damages European Commission - Certificate Policy for Deployment and Operation of OEMs as well as Tier-1/Tier-2 should pay European Cooperative Intelligent Transport System (C-ITS) careful attention to the key management

system, especially when the key

provisioning and management are

performed over-the-air. If needed,

consider getting advice from security

experts or your national cybersecurity

agency.

Consider using dedicated and tamper -Safety First for Automated Driving

resistant hardware security modules.

• Nefarious activity / Abuse -UNECE- ECE/TRANS/WP.29/GRVA/2019/2 -- Automated/autonomous HW-based cryptographic solutions may and connected vehicles:Cyber security and data protection -- Proposal for a help avoid the incorrect implementation of • Failures/Malfunctions Recommendation on Cyber Security Cryptography cryptographic algorithms by software • Hijacking vendors, as well as the coexistence of -ETSI - ETSI TR 102 893 V1.2.1 -- Intelligent Transport Systems: Security, multiple implementations of the same • Physical attacks Threat, Vulnerability and Risk Analysis

algorithms. They eventually provide -European Commission -- Access to In-vehicle Data and Resources implementations that are more resource-

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

efficient. Choosing HW accelerated -SCOUT - Report on the state of the art of connected and automated cryptography means that a reasonable driving in Europe assurance must be obtained on the quality of the HW implementation, since “bad cryptography” on HW will be leveraged on all the SW using these functions. Devices vendors should be aware of tamper evident or tamperresistant mechanisms. While they are not mandated in any case, vendors should consider using them depending on the level of sensitivity of the assets stored on the device. In particular, even constrained devices could be able to implement some kind of tamper evidence, even if they are not able to implement resistance and response.

-UNECE- ECE/TRANS/WP.29/GRVA/2019/2 -- Automated/autonomous and Application of security controls to connected vehicles:Cyber security and data protection -- Proposal for a back-end servers. Such controls have to Recommendation on Cyber Security be at different levels: • Nefarious activity / Abuse -Secure Device Configuration Guideline • physical (e.g. physical and Access • Failures/Malfunctions -IoT Security Awareness environmental security) Control • Hijacking -Consumers don't care if their connected car can get hacked - here's why • logical (e.g. secure configuration using that's a problem system hardening, firewalls) • Physical attacks -Shifting gears in cyber security for connected cars • people (e.g. security training for OEMs staff) -What is physical security? How to keep your facilities and devices safe from on-site attackers

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

Apply least privileges principle and use individual accounts to access

devices and systems. Ensure that roles • Nefarious activity / Abuse (e.g. user, administrator, etc.) are clearly -Principle of least privilege (POLP) • Eavesdropping/ Access defined and that access rights are -Improving security through least-privilege practices Interception/ Hijacking provided following a need-to-know/access

Control

-PAS 1885:2018 The fundamental principles of automotive cyber security and least-privilege principles. • Unintenational damages Specification A distinct account should be created for • Physical attack

each user for accountability reasons (i.e. track performed actions).

-GSMA (Global System for Mobile Communications) - GSMA CLP.12 IoT Security Guidelines for IoT Service Ecosystems -GSMA (Global System for Mobile Communications) - GSMA CLP.13 IoT Security Guidelines for Endpoint Ecosystems • Nefarious activity / Abuse Segregate remote access. Develop a -NIST - NIST SP 800 53r4: Security and Privacy Controls for Federal set of rules for control of remote • Eavesdropping/ Information Systems and Organizations

Access

communication. Remote access should Interception/ Hijacking -NIST - Draft NISTIR 8228: Considerations for Managing Internet of Things

Control

be only limited to the required systems, • Unintentional damages (IoT) Cybersecurity and Privacy Risks and must be monitored. -OWASP (Open Web Application Security Project) - IoT Security Guidance • Failures/Malfunctions -PAS 1885:2018 The fundamental principles of automotive cyber security - Specification

Allow and encourage the use of strong -Cloud Security Alliance - Identity and Access Management for the Internet of authentication mechanisms. Rely on • Nefarious activity / Abuse Things - Summary Guidance

Multi-factor authentication (MFA) -ENISA - Baseline Security Recommendations for IoT Access • Eavesdropping/ mechanisms which require users to -GSMA (Global System for Mobile Communications) - GSMA CLP.12 IoT Control Interception/ Hijacking provide at least two different proofs of the Security Guidelines for IoT Service Ecosystems • Physical attacks claimed identity (e.g. password and -GSMA (Global System for Mobile Communications) - GSMA CLP.13 IoT security token) so as to be authenticated Security Guidelines for Endpoint Ecosystems

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

and granted access to the resource or -IoT Security Foundation - Connected Consumer Products. Best Practice service (e.g. authentication to cloud Guidelines services or mobile interfaces, -NIST - NIST SP 800 53r4: Security and Privacy Controls for Federal local/remote administration sessions). Information Systems and Organizations This mitigates the risks associated with -OWASP (Open Web Application Security Project) - IoT Security Guidance passwords-only authentication. An account lockout functionality should be implemented to automatically lockout an account for a given time period after a number of successive authentication failures.

Implement differential monitoring on

the GNSS system. Differential GNSS is a way of correcting various inaccuracies -ETSI - ETSI TR 102 893 V1.2.1 -- Intelligent Transport Systems: Security, in a GNSS system and, thus, providing • Nefarious activity / Abuse Threat, Vulnerability and Risk Analysis

Self

more accurate position information. The protection and - Autonomous integrity monitoring of navigation maps on board intelligent • Failures/Malfunctions benefit of differential GNSS is that it is resilience vehicles capable of positioning things very • Hijacking precisely and this feature can be used to detect even small anomalies in position errors.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

Perform hardening to reduce the

attack surface. Remove unused services or interfaces, integrate dedicated security

software, activate memory or control flow protections. For devices that have a

complete operating system, several -Cloud Security Alliance - Identity and Access Management for the measures can be considered to harden I+E68nternet of Things - Summary Guidance

the device, such as ASLR, non- -ENISA - Baseline Security Recommendations for IoT executable memory, process segregation

or sandboxing. Another measure is • Nefarious activity / Abuse -GSMA (Global System for Mobile Communications) - GSMA CLP.12 IoT removing unused tools, services and Security Guidelines for IoT Service Ecosystems • Failures/Malfunctions Self libraries. Unnecessary services should -GSMA (Global System for Mobile Communications) - GSMA CLP.13 IoT protection and not be present on the device (typically • Hijacking Security Guidelines for Endpoint Ecosystems resilience telnet must always be deactivated, but • Physical attacks even SSH or FTP can be deactivated in -IoT Security Foundation - Connected Consumer Products. Best Practice many cases). This type of measures is • Unintenational damages Guidelines

also applicable at a network level: the -NIST - NIST SP 800 53r4: Security and Privacy Controls for Federal device should not leave open ports, Information Systems and Organizations especially ports that could be exposed via plug-n-play protocols. The default -OWASP (Open Web Application Security Project) - IoT Security Guidance

configuration of the device should be

based upon the most secure parameters, and users should be warned if they have

the possibility to roll back to less secure parameters.

Reinforce interfaces robustness.

-ENISA - Cyber Security and Resilience of smart cars Software can contribute to self-protection • Nefarious activity / Abuse Self -Symantec - Insecurity in the Internet of Things measures, such as for robustness of protection and • Failures/Malfunctions interfaces against bad inputs. -OWASP Internet of Things Project – OWASP-

resilience

• Hijacking Secure implementation, thoroughly -OWASP Top Ten Project – OWASP

tested, will protect against common attack

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

vectors such as buffer/heap overflows or -PAS 1885:2018 The fundamental principles of automotive cyber security - OWASP’s Top Ten Web Vulnerabilities. Specification

This typically includes robustness of network interfaces against buffer overflows or fuzzing.

Consider strengthening applications isolation at runtime.

-ENISA - Cyber Security and Resilience of smart cars Trusted software technologies, such as • Nefarious activity / Abuse Self -Symantec - Insecurity in the Internet of Things Trusted Execution Environments (TEEs), protection and • Failures/Malfunctions -Secure hypervisor versus trusted execution environment hypervisors and virtualisation, may be

resilience

• Hijacking used to ensure secure execution of -Isolated Execution in Many-core Architectures applications in a segregated and trusted environment.

System, sub-domain and network

segregation. Use of logical and physical isolation techniques to separate processors (e.g. OS virtualization techniques, hypervisors), vehicle domains -U.S. Department of Transportation - Cybersecurity Best Practices for and networks (e.g. use of an in-vehicle Modern Vehicles gateway for physical separation between -UNECE- ECE/TRANS/WP.29/GRVA/2019/2 -- Automated/autonomous and • Nefarious activity / Abuse Self safety and non-safety related domains), connected vehicles:Cyber security and data protection -- Proposal for a protection and and external connections (e.g. firewall to • Failures/Malfunctions Recommendation on Cyber Security resilience filter all the incomming traffic received • Hijacking -European Commission -- Access to In-vehicle Data and Resources from outside the vehicle). These -PAS 1885:2018 The fundamental principles of automotive cyber security techniques should be used where Specification appropriate (based on risk assessment) to limit and control pathways from external threat vectors to cyber-physical features of vehicles, as well as ensure suitable separation of in-vehicle systems.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

Consider using INS or existing deadreckoning methods to provide

positional data. In order to have other

source of location information in the case • Nefarious activity / Abuse of GNSS failure, consider the use of an

(semi-)

onboard Inertial Navigation System (INS) -ETSI - ETSI TR 102 893 V1.2.1 -- Intelligent Transport Systems: Security, • Failures/Malfunctions

Autonomous

or dead-reckoning derived from simple Threat, Vulnerability and Risk Analysis systems self • Hijacking -An Autonomous Vehicle Navigation System Based on Inertial and Visual accelerometers such as those found in

protection and

modern mobile phones. Thus, it would be • Outages Sensors

cyber

possible for the ITS-S to determine its resilience • Threats against (semi-) position from purely internal sources with autonomous systems only brief and infrequent references to

GNSS for waypoint corrections. Such

security measure would prevent GNSS

jamming and other related attacks.

Protect critical sensors in order to prevent attacks that may alter their

perception of the environment. The

protection mechanisms are specific to each sensor type, and mainly depends on • Physical attack -Security Innovation - Remote Attacks on Automated Vehicles Sensors:

(semi-)

the type of threats targeting the sensor. Experiments on Camera and LiDAR Autonomous • Nefarious activity/abuse -SCOUT - Report on the state of the art of connected and automated driving For instance, Integration of near-infrared-

systems self

• Outage in Europe cut filters or photocromic lenses on

protection and

cameras could filter specific types of light -PAS 1885:2018 The fundamental principles of automotive cyber security - • Threats against (semi-)

cyber

to mitigate sensor blindness attacks. Specification autonomous

resilience

Regarding LiDARs, the emission of light features/components

pulse could be done in an unpredictable

manner (e.g. pseudo-randomly) so that it

will be harder for an attacker to inject a

fake echoe in the right window.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

-Towards deep learning models resistant to adversarial attacks Hardening against Adversarial (https://openreview.net/pdf?id=rJzIBfZAb) Machine Learning. Protect Artificial -Explaining and harnessing adversarial examples Intelligence (AI) and Machine Learning (http://arxiv.org/abs/1412.6572). (semi-) (ML) components in order to prevent Autonomous them from being tricked by adversarial -Pixeldefend: Leveraging generative models to understand and defend systems self attacks. The model need to be hardened • Threats against (semi-) against adversarial examples. In International Conference on Learning

protection and by using, for instance, adversarial data as autonomous systems Representations (ICLR),2018 cyber part of algorithm training, to make the (https://openreview.net/forum?id=rJUYGxbCW) resilience model more robust with regard to -The robust manifold defense: Adversarial training using generative models. adversarial attacks. Pre-processing (https://arxiv.org/abs/1712.09196). techniques may also be used as a protection mechanism. -Thermometer encoding: One hot way to resist adversarial examples. In International Conference on Learning Representations (ICLR), 2018

Prevent data falsification/manipulation (semi-) in regard to Artificial Intelligence

Autonomous (AI)/Machine Learning (ML). Ensure that -The robust manifold defense: Adversarial training using generative models. systems self data used to train the model are • Threats against (semi-) (https://arxiv.org/abs/1712.09196). protection and originating from a trusted entity. After any autonomous systems -Securing the Future of AI and ML cyber training cycle, the model should be tested resilience to ensure that there are no considerable changes in classifications for instance.

Use of data redundancy mechanisms.

-Groupe PSA - Attacker model for Connected and Automated Vehicles (semi-) Data redundancy mechanisms (e.g. • Physical attack Security Innovation - Remote Attacks on Automated Vehicles Sensors: Autonomous sensor data fusion) consist in correlating • Nefarious activity/abuse Experiments on Camera and LiDAR systems self data acquired from different sensors (e.g. -SCOUT - Report on the state of the art of connected and automated driving • Outage protection and LiDAR and camera) and V2X in Europe cyber communications so as to allow the • Threats against (semi-) -Safety First for Automated Driving resilience mitigation of the physical or DoS attacks autonomous systems against sensors.

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

Use of hardware redundancy -Groupe PSA - Attacker model for Connected and Automated Vehicles (semi-) • Physical attack Security Innovation - Remote Attacks on Automated Vehicles Sensors: mechanisms. Hardware redundancy

Autonomous

mechanisms consist in duplicating • Nefarious activity/abuse Experiments on Camera and LiDAR

systems self

-SCOUT - Report on the state of the art of connected and automated driving sensors (e.g. several cameras, several • Outage

protection and

sensors to collect the same data) in order in Europe cyber • Threats against (semi-) -Safety First for Automated Driving to mitigate physical attacks or DoS resilience autonomous systems attacks against sensors.

Notifications should be easy to understand and help users find a

remediation or workaround. HW and

embedded systems should provide clear

error data that can be leveraged upon by

the SW vendors. The user must be

notified in case of security errors, updates • Nefarious activity / Abuse -ENISA - Cyber Security and Resilience of smart cars or compromised data in a device or

Continuity of

service they use. In particular, users must • Failures/Malfunctions -Duo Security - The Internet of Fails ; Where IoT Has Gone Wrong

operations

be notified in the case of security events. • Unintentional damages -A Hard Problem with No Easy Answers | Decipher - IoT Security Notification might vary greatly depending

on the type of software considered.

Mobile applications notification,

messaging such as SMS or e-mail,

hardware interfaces such as LEDs,

dedicated error messages to a gateway,

etc.

Create a Business Continuity Plan -Center for Internet Security (CIS) - Critical Security Controls

(BCP) and a Business Recovery Plan

-Federal Office for Information Security (BSI) - BSI-Standards 100-4 - Continuity of • Failures/Malfunctions

to ensure the resilience of smart cars

Business Continuity Management operations systems. To ensure business continuity • Unintentional damages

-IEC - IEC 62443-2-1:2010 Establishing an industrial automation and control (even in the case of security crisis or system security program disaster situations), a Business Continuity

ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS

Security Security Measures/ Good Practices Threat Groups References Domain

Plan (BCP) and a Business Recovery -NIST - NIST SP 800 53r4: Security and Privacy Controls for Federal

Plan that cover third party aspects should Information Systems and Organizations be created and periodically tested, at -NIST - NIST SP 800 82r2: Guide to Industrial Control Systems (ICS) least annually, to ensure their Security effectiveness and improve them when required. Appropriate Third Party -NIST - NISTIR 8183: Cybersecurity Framework Manufacturing Profile

management and control over its

involvement is essential to ensure the

continuity of operations of the organisation.

Define Business Continuity

-IEC - IEC 62443-3-3:2013 System security requirements and security levels parameters. Define important -IIC (Industrial Internet Consortium) - IIC Endpoint Security Best Practices parameters for business continuity of the Continuity of organization, such as the recovery time -IoT Security Foundation - Connected Consumer Products. Best Practice All operations objective (RTO), recovery point objective Guidelines (RPO), maximum tolerable outage (MTO) -oneM2M - Standards for M2M and the Internet of Things - TR 0008 Security and minimum business continuity V2.0.0 - Security. Technical Report objective (MBCO).

-N -EN -881 -19 -02 TP

ABOUT ENIS A

The European Union Agency for Cybersecurity (ENISA) has been working to make Europe cyber secure since 2004. ENISA works with the EU, its member states, the private sector and Europe’s citizens to develop advice and recommendations on good practice in information security. It assists EU member states in implementing relevant EU legislation and works to improve the resilience of Europe’s critical information infrastructure and networks. ENISA seeks to enhance existing expertise in EU member states by supporting the development of cross-border communities committed to improving network and information security throughout the EU. Since 2019, it has been drawing up cybersecurity certification schemes. More information about ENISA and its work can be found at www.enisa.europa.eu.

ISBN: 978-92-9204-317-9 DOI: 10.2824/17802