Schweitzer Fachinformationen
Wenn es um professionelles Wissen geht, ist Schweitzer Fachinformationen wegweisend. Kunden aus Recht und Beratung sowie Unternehmen, öffentliche Verwaltungen und Bibliotheken erhalten komplette Lösungen zum Beschaffen, Verwalten und Nutzen von digitalen und gedruckten Medien.
Explores how the automotive industry can address the increased risks of cyberattacks and incorporate security into the software development lifecycle
While increased connectivity and advanced software-based automotive systems provide tremendous benefits and improved user experiences, they also make the modern vehicle highly susceptible to cybersecurity attacks. In response, the automotive industry is investing heavily in establishing cybersecurity engineering processes.
Written by a seasoned automotive security expert with abundant international industry expertise, Building Secure Cars: Assuring the Automotive Software Development Lifecycle introduces readers to various types of cybersecurity activities, measures, and solutions that can be applied at each stage in the typical automotive development process.
This book aims to assist auto industry insiders build more secure cars by incorporating key security measures into their software development lifecycle. Readers will learn to better understand common problems and pitfalls in the development process that lead to security vulnerabilities. To overcome such challenges, this book details how to apply and optimize various automated solutions, which allow software development and test teams to identify and fix vulnerabilities in their products quickly and efficiently. This book balances technical solutions with automotive technologies, making implementation practical. Building Secure Cars is:
This book is written for software development process owners, security policy owners, software developers and engineers, and cybersecurity teams in the automotive industry. All readers will be empowered to improve their organizations' security postures by understanding and applying the practical technologies and solutions inside.
Dr. Dennis Kengo Oka is an automotive cybersecurity expert with more than 15 years of global experience in the automotive industry. He received his Ph.D. in Computer Science and Engineering, with a focus on automotive security, from Chalmers University of Technology in Sweden. In the past, Dennis has worked with Volvo Car Corporation in Sweden where he bootstrapped automotive security research for remote diagnostics and over-the-air updates on vehicles. He has also worked for the Bosch Group in Japan serving both Japanese and global customers. Specifically, Dennis co-launched the automotive security practice (ESCRYPT) in Japan and was the Head of Engineering and Consulting Asia-Pacific. Dennis has also been involved in several automotive standardization activities, including the development of fuzz testing guidelines and cybersecurity testing frameworks. He has over 60 publications consisting of conference papers, journal articles, and book chapters, and is a frequent public speaker at international automotive and cybersecurity conferences and events.
Preface xi
About the Author xiii
1 Overview of the Current State of Cybersecurity in the Automotive Industry 1
1.1 Cybersecurity Standards, Guidelines, and Activities 3
1.2 Process Changes, Organizational Changes, and New Solutions 6
1.3 Results from a Survey on Cybersecurity Practices in the Automotive Industry 8
1.3.1 Survey Methods 8
1.3.2 Report Results 9
1.3.2.1 Organizational Challenges 9
1.3.2.2 Technical Challenges 10
1.3.2.3 Product Development and Security Testing Challenges 11
1.3.2.4 Supply Chain and Third-Party Components Challenges 11
1.3.3 How to Address the Challenges 12
1.3.3.1 Organizational Takeaways 12
1.3.3.2 Technical Takeaways 13
1.3.3.3 Product Development and Security Testing Takeaways 13
1.3.3.4 Supply Chain and Third-Party Components Takeaways 13
1.3.3.5 Getting Started 14
1.3.3.6 Practical Examples of Organizations Who Have Started 15
1.4 Examples of Vulnerabilities in the Automotive Industry 16
1.5 Chapter Summary 18
References 19
2 Introduction to Security in the Automotive Software Development Lifecycle 23
2.1 V-Model Software Development Process 24
2.2 Challenges in Automotive Software Development 25
2.3 Security Solutions at each Step in the V-Model 26
2.3.1 Cybersecurity Requirements Review 27
2.3.2 Security Design Review 27
2.3.3 Threat Analysis and Risk Assessment 27
2.3.4 Source Code Review 28
2.3.5 Static Code Analysis 28
2.3.6 Software Composition Analysis 29
2.3.7 Security Functional Testing 29
2.3.8 Vulnerability Scanning 29
2.3.9 Fuzz Testing 30
2.3.10 Penetration Testing 30
2.3.11 Incident Response and Updates 31
2.3.12 Continuous Cybersecurity Activities 32
2.3.13 Overall Cybersecurity Management 32
2.4 New Technical Challenges 32
2.5 Chapter Summary 34
References 35
3 Automotive-Grade Secure Hardware 37
3.1 Need for Automotive Secure Hardware 39
3.2 Different Types of HSMs 41
3.3 Root of Trust: Security Features Provided by Automotive HSM 43
3.3.1 Secure Boot 44
3.3.2 Secure In-Vehicle Communication 45
3.3.3 Secure Host Flashing 46
3.3.4 Secure Debug Access 47
3.3.5 Secure Logging 47
3.4 Chapter Summary 48
References 48
4 Need for Automated Security Solutions in the Automotive Software Development Lifecycle 51
4.1 Main Challenges in the Automotive Industry 53
4.2 Automated Security Solutions During the Product Development Phases 55
4.2.1 Static Code Analysis 55
4.2.2 Software Composition Analysis 57
4.2.3 Security Testing 58
4.2.4 Automation and Traceability During Software Development 59
4.3 Solutions During Operations and Maintenance Phases 59
4.3.1 Cybersecurity Monitoring, Vulnerability Management, Incident Response, and OTA Updates 59
4.4 Chapter Summary 61
References 61
5 Static Code Analysis for Automotive Software 63
5.1 Introduction to MISRA and AUTOSAR Coding Guidelines 68
5.2 Problem Statement: MISRA and AUTOSAR Challenges 75
5.3 Solution: Workflow for Code Segmentation, Guideline Policies, and Deviation Management 79
5.3.1 Step 1: Segment the Codebase into Different Categories/Components Based on Risk 80
5.3.2 Step 2: Specify Guideline Policies (Set of Guidelines to Apply) Depending on Risk Categories 81
5.3.3 Step 3: Perform the Scan and Plan the Approach for Prioritization of Findings 82
5.3.4 Step 4: Prioritize Findings Based on the Risk Categories and Guideline Policies and Determine How to Handle Each Finding, e.g. Fix or Leave as Deviation 83
5.3.5 Step 5: Follow a Defined Deviation Management Process, Including Approval Steps 84
5.3.6 Step 6: Report on MISRA or AUTOSAR Coding Guidelines Compliance Including Deviations 86
5.4 Chapter Summary 87
References 88
6 Software Composition Analysis in the Automotive Industry 91
6.1 Software Composition Analysis: Benefits and Usage Scenarios 95
6.2 Problem Statement: Analysis of Automotive Software Open-Source Software Risks 98
6.2.1 Analysis Results 98
6.2.1.1 zlib 99
6.2.1.2 libpng 99
6.2.1.3 OpenSSL 99
6.2.1.4 curl 99
6.2.1.5 Linux Kernel 100
6.2.2 Discussion 100
6.3 Solution: Countermeasures on Process and Technical Levels 101
6.3.1 Fully Inventory Open-Source Software 101
6.3.2 Use Appropriate Software Composition Analysis Approaches 102
6.3.3 Map Open-Source Software to Known Security Vulnerabilities 102
6.3.4 Identify License, Quality, and Security Risks 103
6.3.5 Create and Enforce Open-Source Software Risk Policies 104
6.3.6 Continuously Monitor for New Security Threats and Vulnerabilities 104
6.3.7 Define and Follow Processes for Addressing Vulnerabilities in Open-Source Software 105
6.3.8 How to Get Started 106
6.4 Chapter Summary 107
References 108
7 Overview of Automotive Security Testing Approaches 111
7.1 Practical Security Testing 115
7.1.1 Security Functional Testing 117
7.1.2 Vulnerability Scanning 119
7.1.3 Fuzz Testing 121
7.1.4 Penetration Testing 122
7.2 Frameworks for Security Testing 125
7.3 Focus on Fuzz Testing 129
7.3.1 Fuzz Engine 130
7.3.2 Injector 134
7.3.3 Monitor 136
7.4 Chapter Summary 140
References 141
8 Automating Fuzz Testing of In-Vehicle Systems by Integrating with Automotive Test Tools 145
8.1 Overview of HIL Systems 147
8.2 Problem Statement: SUT Requires External Input and Monitoring 150
8.3 Solution: Integrating Fuzz Testing Tools with HIL Systems 152
8.3.1 White-Box Approach for Fuzz Testing Using HIL System 157
8.3.1.1 Example Test Setup Using an Engine ECU 159
8.3.1.2 Fuzz Testing Setup for the Engine ECU 161
8.3.1.3 Fuzz Testing Setup Considerations 165
8.3.2 Black-Box Approach for Fuzz Testing Using HIL System 166
8.3.2.1 Example Target System Setup Using Engine and Body Control Modules 168
8.3.2.2 Fuzz Testing Setup Using Duplicate Engine and Body Control Modules 171
8.3.2.3 Fuzz Testing Setup Considerations 175
8.4 Chapter Summary 176
References 177
9 Improving Fuzz Testing Coverage by Using Agent Instrumentation 179
9.1 Introduction to Agent Instrumentation 182
9.2 Problem Statement: Undetectable Vulnerabilities 183
9.2.1 Memory Leaks 184
9.2.2 Core Dumps and Zombie Processes 185
9.2.3 Considerations for Addressing Undetectable Vulnerabilities 187
9.3 Solution: Using Agents to Detect Undetectable Vulnerabilities 187
9.3.1 Overview of the Test Environment 188
9.3.2 Modes of Operation 189
9.3.2.1 Synchronous Mode 190
9.3.2.2 Asynchronous Mode 191
9.3.2.3 Hybrid Approach 192
9.3.3 Examples of Agents 193
9.3.3.1 Agent Core Dump 193
9.3.3.2 Agent Log Tailer 194
9.3.3.3 Agent Process Monitor 194
9.3.3.4 Agent PID 194
9.3.3.5 Agent Address Sanitizer 195
9.3.3.6 Agent Valgrind 195
9.3.3.7 An Example config.json Configuration File 196
9.3.4 Example Results from Agent Instrumentation 197
9.3.4.1 Bluetooth Fuzz Testing 198
9.3.4.2 Wi-Fi Fuzz Testing 199
9.3.4.3 MQTT Fuzz Testing 201
9.3.4.4 File Format Fuzz Testing 203
9.3.5 Applicability and Automation 206
9.4 Chapter Summary 207
References 208
10 Automating File Fuzzing over USB for Automotive Systems 211
10.1 Need for File Format Fuzzing 213
10.2 Problem Statement: Manual Process for File Format Fuzzing 215
10.3 Solution: Emulated Filesystems to Automate File Format Fuzzing 216
10.3.1 System Architecture Overview 217
10.3.2 Phase One Implementation Example: Prepare Fuzzed Files 219
10.3.3 Phase Two Implementation Example: Automatically Emulate Filesystems 223
10.3.4 Automating User Input 228
10.3.5 Monitor for Exceptions 231
10.4 Chapter Summary 236
References 237
11 Automation and Traceability by Integrating Application Security Testing Tools into ALM Systems 241
11.1 Introduction to ALM Systems 242
11.2 Problem Statement: Tracing Secure Software Development Activities and Results to Requirements and Automating Application Security Testing 245
11.3 Solution: Integrating Application Security Testing Tools with ALM Systems 248
11.3.1 Concept 249
11.3.1.1 Static Code Analysis - Example 249
11.3.1.2 Software Composition Analysis - Example 250
11.3.1.3 Vulnerability Scanning - Example 250
11.3.1.4 Fuzz Testing - Example 250
11.3.1.5 Concept Overview 251
11.3.2 Example Implementation 252
11.3.2.1 Defensics 252
11.3.2.2 code Beamer ALM 252
11.3.2.3 Jenkins 252
11.3.2.4 SUT 253
11.3.2.5 Implementation Overview 253
11.3.3 Considerations 258
11.4 Chapter Summary 262
References 264
12 Continuous Cybersecurity Monitoring, Vulnerability Management, Incident Response, and Secure OTA Updates 267
12.1 Need for Cybersecurity Monitoring and Secure OTA Updates 268
12.2 Problem Statement: Software Inventory, Monitoring Vulnerabilities, and Vulnerable Vehicles 271
12.3 Solution: Release Management, Monitoring and Tracking, and Secure OTA Updates 272
12.3.1 Release Management 273
12.3.2 Monitoring and Tracking 276
12.3.2.1 Solutions in Other Industries 276
12.3.2.2 Solutions in the Automotive Industry 277
12.3.2.3 Example Automotive SOC Overview 277
12.3.2.4 Example Automotive SOC Workflow 279
12.3.2.5 Newly Detected Vulnerabilities in Open-Source Software - Example 279
12.3.3 Secure OTA Updates 280
12.3.3.1 Identify Vulnerable Vehicles Targeted for OTA Updates 281
12.3.3.2 Perform Secure OTA Updates 281
12.3.3.3 Target Systems for OTA Updates 282
12.3.3.4 Overview of Secure OTA Update Process for ECUs 283
12.3.3.5 Standardization and Frameworks for OTA Updates 284
12.4 Chapter Summary 285
References 286
13 Summary and Next Steps 289
Index 293
BEFORE YOU START WALKING YOU MUST FIRST KNOW WHERE YOU ARE
Since the introduction of the first gasoline-powered automobiles in 1885, the automotive industry has gone through an amazing journey to create the technical marvels that are today's vehicles. But how did we get here? A quick review of the history of automotive technology trends shows the introduction of core electrical systems in the 1980s. These isolated systems were driven by innovation and new technologies such as airbags and anti-lock braking systems (ABSs). The main focus of these systems was on safety to help create safer vehicles. In the 1990s until the early 2000s, the automotive industry saw a widespread adoption of electronic control units (ECUs) in vehicles, mainly driven by efficiency in production and maintenance, to improve scalability and time to market, and support emerging communication types. Thus, besides safety, these systems focused on providing added capabilities. In the late 2000s and continuing into the 2010s, the automotive industry gradually introduced the notion of connected and autonomous vehicles, where vehicles were no longer isolated systems but instead have capabilities to communicate with external entities and partially control vehicle functionality. During the 2010s, there was a surge in the development of advanced driver assistance systems (ADAS), including emergency braking systems, predictive forward collision warning systems, lane keep assist systems, park assist systems, and autopilot functionality. This connected and autonomous vehicle trend is mostly driven by the introduction of high connectivity interfaces, improved cameras and sensors, advanced data processing and analytics, and by the development of new business models by providing value-added solutions, such as autopilot, remote diagnostics, and shared services. The main focus of these systems, besides safety and capabilities, is the need for security. For illustrative purposes the automotive technology trends are depicted in Figure 1.1.
Figure 1.1 Overview of automotive technology trends.
The automotive industry is going through a digital transformation with the rapid development of more advanced vehicles built on more software, including open-source software, to provide more complex functionality and autonomous driving capabilities, to enable more connectivity, and to offer more services. To ensure successful development and deployment of such vehicles it is imperative that safety and security are thoroughly considered during the development lifecycle. In particular, high-risk technologies such as wireless connectivity and autonomous driving functionality need to be both designed and developed securely, as well as properly security tested.
A modern vehicle can contain up to 150 ECUs and more than 100 million lines of software code, which is projected to rise to 300 million lines of code by 2030. For reference, Figure 1.2 shows a comparison of software on vehicles with that of other systems in order to highlight the enormous volume of software the automotive industry is engaged in. As can be seen in the figure, a modern vehicle contains more software than Facebook without the backend code (62 million lines of code). A vehicle also has more than double the code of Microsoft Office 2013, more than six times the code of the Android OS, more than 15 times the code of a Boeing 787, and more than 20 times the code of the Mars Curiosity Rover and a US military drone [1]. As more software is included in vehicles, there is a risk of introducing software bugs and vulnerabilities that, if abused by malicious attackers, could potentially have disastrous consequences, including on safety, privacy, and operation of the vehicles.
Figure 1.2 Comparison of software sizes of different systems in terms of lines of code. Source: Data from [1].
For reference, the statistical average for software used in critical systems (e.g. flight control and air traffic control) indicates 10-12 errors for every 1000 lines of code. However, this level of error rate is unacceptable for NASA regarding software used on space shuttles. It was shown that software for the unfortunate Space Shuttle Challenger had a latent defect rate of just 0.11 errors per 1000 lines of code [2]. Considering even this minuscule error rate of 0.11 errors per 1000 lines of code, mathematically speaking, a modern vehicle would contain more than 11?000 defects!
As highlighted by the technology trends and the large volume of software, cybersecurity is an ever-increasing important topic that the automotive industry must seriously consider. To this end, the automotive industry has been working on and has produced several cybersecurity related standards, best practices, and guidelines. A few examples of these are presented in this chapter to provide some background on the current state of cybersecurity. Additionally, automotive organizations are going through process changes and organizational changes based on these standards, best practices, and guidelines, which are explored further in detail. Moreover, some results from a survey conducted on the current state of cybersecurity practices in the automotive industry are presented to provide some further insight. Finally, this chapter discusses a few examples of vulnerabilities identified in the automotive industry to better understand the consequences caused by the lack of adequate cybersecurity activities during the development lifecycle.
The main points of this chapter are:
The automotive industry is well-known for following a rigorous development process based on standards such as ISO?26262 for functional safety [3], ISO?21448 for safety of the intended functionality (SOTIF) [4] and ASPICE (Automotive Software Process Improvement and Capability dEtermination) [5], and for following coding guidelines provided by MISRA (Motor Industry Software Reliability Association) for development of safety-relevant software [6]. However, besides safety, cybersecurity has become a major concern and, consequently, there are several standards, best practices and guidelines regarding cybersecurity. For example, the SAE J3061 [7], released in January 2016, is the world's first cybersecurity standard for the automotive industry. The SAE?J3061: Cybersecurity Guidebook for Cyber-Physical Vehicle Systems provides guidance and recommendations for designing cybersecurity into the system including product design, validation, deployment, and communication tasks. It also states that, for a system to be safe, it also needs to be secure. This concept is depicted in Figure 1.3, where all safety-critical systems also need to be cybersecurity-critical systems; highlighting the mantra that there is no safety without security.
Figure 1.3 All safety-critical systems are cybersecurity-critical systems.
The SAE J3061 has now been superseded by the ISO/SAE 21434 standard [8]. In previous years, there were several ongoing activities on automotive security in both ISO and SAE, so, in November 2016, the Partnership Standards Development Organization (PSDO) was created as a cooperation agreement between ISO and SAE in two areas: Road Vehicles and Intelligent Transportation Systems. As a result, SAE and ISO agreed to work together to develop a cybersecurity standard, namely the ISO/SAE 21434, which is the first standard to be created under this new agreement. This standard will be jointly released by both SAE and ISO. The DIS (draft international standard) version of ISO/SAE 21434 was released in February 2020, and the final document for publication is expected to be published sometime in the first half of 2021. Proposed contents of the ISO/SAE 21434 divided into different clauses include Overall cybersecurity management, Continuous cybersecurity activities, Risk assessment methods, Concept phase, Product development, Production, Operations and Maintenance, among others [9]. An overview of how the relevant clauses in ISO/SAE 21434 are mapped onto the product lifecycle is illustrated in Figure 1.4. Please note that clauses 1 through 4 are general clauses covering the Scope, Normative references, Terms and abbreviations, and General considerations. Clauses 5 through 15 contain specific cybersecurity requirements for the respective activities that automotive organizations need to fulfill.
Figure 1.4 Clauses in ISO/SAE?21434 mapped onto the product lifecycle. Source: Based on [8].
Moreover, there are currently ongoing activities for new UNECE (United Nations Economic Commission for Europe) regulations regarding cybersecurity and software updates. There are currently two groups in the World Forum for...
Dateiformat: ePUBKopierschutz: Adobe-DRM (Digital Rights Management)
Systemvoraussetzungen:
Das Dateiformat ePUB ist sehr gut für Romane und Sachbücher geeignet – also für „fließenden” Text ohne komplexes Layout. Bei E-Readern oder Smartphones passt sich der Zeilen- und Seitenumbruch automatisch den kleinen Displays an. Mit Adobe-DRM wird hier ein „harter” Kopierschutz verwendet. Wenn die notwendigen Voraussetzungen nicht vorliegen, können Sie das E-Book leider nicht öffnen. Daher müssen Sie bereits vor dem Download Ihre Lese-Hardware vorbereiten.Bitte beachten Sie: Wir empfehlen Ihnen unbedingt nach Installation der Lese-Software diese mit Ihrer persönlichen Adobe-ID zu autorisieren!
Weitere Informationen finden Sie in unserer E-Book Hilfe.
