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
Dateiformat: PDFKopierschutz: Adobe-DRM (Digital Rights Management)
Systemvoraussetzungen:
Das Dateiformat PDF zeigt auf jeder Hardware eine Buchseite stets identisch an. Daher ist eine PDF auch für ein komplexes Layout geeignet, wie es bei Lehr- und Fachbüchern verwendet wird (Bilder, Tabellen, Spalten, Fußnoten). Bei kleinen Displays von E-Readern oder Smartphones sind PDF leider eher nervig, weil zu viel Scrollen notwendig ist. 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.
