In recent years, we’ve been talking about the fundamental changes in the automotive industry, such as electrification, connectivity, autonomous driving, or software defined vehicles.

What is particularly interesting in these trends - especially from the perspective of this article - is that many of them are driven by information technology and connectivity.

Connectivity in the automotive industry refers to the integration of vehicles with digital networks, enabling communication between cars, infrastructure, and external systems. This connectivity facilitates features like navigation, real-time data sharing or autonomous driving. However, with this integration comes a critical need for robust cybersecurity measures to protect vehicles and their data from potential cyber threats, ensuring the safety and privacy of passengers and road users.

Cybersecurity is crucial to prevent unauthorized access, tampering, or malicious actions that could compromise vehicle functionality and jeopardize public safety or reputation of the brand.

More ECUs and more interfaces:

The number of interfaces between vehicles and their environments, the number of functionalities implemented in software, the number of in-vehicle and off-board systems started to increase dramatically. Connected car supports the drivers, passengers, enables remote maintenance or upgrade the vehicle’ software. As a result, high-end vehicle might have 70 to 100 small computers (known as ECU, Electronic Control Units) and approximately 100 million lines of software code.

You do not have to be a cybersecurity expert to immediately understand the significant challenge that the industry faces and necessity to ensuring the appropriate cybersecurity in such a complex system. Adding to this challenge, in the past, the automotive engineers did not have to focus on the cybersecurity, and the cybersecurity experts did not focus on vehicles, thus a knowledge gap existed between them when the change accelerated.

The automotive industry recognized this risk early and began working to close this knowledge gap, enhance the vehicle cybersecurity, and introduced two cybersecurity regulations in 2020.

Consequently, the ISO/SAE 21434:2021 (Road vehicles — Cybersecurity engineering) standard was also introduced. It describes the processes should be followed to ensure the proper cybersecurity risk management from the concept phase to decommissioning.

In the world of cybersecurity, penetration testing is seen as one of the most effective method to validate the implemented cybersecurity controls. The ISO 21434 standard also recommends it as one of the validation activities. However, integrating penetration testing in the automotive product development is not a straightforward task. Developing a new vehicle takes years, and the complexity of the connected vehicle ecosystem requires a lengthy and convoluted testing process, especially if the testing only starts close to the production phase. There are many questions that a well-designed penetration testing process should consider:

• High number of ECUs inside a vehicle.
• The complexity of in-vehicle bus system that connects the ECUs with different types of buses used for different purposes (e.g., CAN, FlexRay, Automotive Ethernet, LIN, MOS).
• Variability in subsystem readiness during development, leading to the need for repeated testing activities when another subsystem reaches the necessary maturity level.
• The use of wide range of technologies and security controls in the connected vehicle ecosystem, from the hardware level (e.g., HSM) through the automotive bus systems (e.g., SecOC ), through various wireless technologies (e.g., Bluetooth, Wi-Fi, GSM/3G/4G/5G, NFC), till applications running on the infotainment systems, mobile applications, server applications, APIs or various cloud technologies.
• Vehicles containing parts from wide range of suppliers who will be responsible for security controls, how much information of the innerworkings of an ECU will be shared with the OEM or who will be responsible for the penetration testing.
• Availability of testing targets can also be problematic in the typical product development process with strict deadlines.

Setting up a good penetration testing program is a complex task which requires specific capabilities in the company.

First, it requires a penetration testing team:

• That has experience in wide range of the used technologies, with specialized team members focusing on different topics (e.g., hardware level testing, mobile application testing).
• In addition to specialized knowledge, it requires a well-equipped lab with the necessary hardware and software tools (e.g., to have a rest bus simulation on a FlexRay bus)

Second, a penetration testing program should be established:

• It needs to be well integrated into the development process; the availability of the necessary time and resources should be planned early.
• Clear definition of responsibilities between the OEM and TierNs is crucial, determining who will be responsible for which kind of testing.
• It should incorporate into the test planning the result of the TARA (Threat and Risk Assessment) process, including the security concepts and goals. This helps to streamline the testing and focus on the most important ECUs and functionalities.
• Need to incorporate the previous testing results with caution. Unnecessarily repeat already conducted testing activities can seriously affect the available time and resources. However, the effect of newly introduced functionalities or small improvements should be carefully investigated regarding their cybersecurity relevance.
• Finding the right balance in information sharing with the testers. They should have enough information to streamline the testing time. For example, testers should not waste resources to find out what is the purpose of a given signal (e.g., a CAN message). The testing should focus on the security relevant signals and their protection, thus sharing the message catalogue with the testers is a good idea.
• OEMs and TierNs should be prepared to provide the necessary number of test targets and engineering support for the testers. For example, in case of hardware level testing, multiple ECUs should be provided, since hardware testing usually incorporates destructive testing.

The structure of penetration testing program should be able to handle the complex nature of the automotive development process.

Typical project types are:

A project, depending on the testing scope, can incorporate various testing types. The difference between the project types and testing types is that the project types use the testing types to fulfill goals as shown on the diagram below.

Deloitte is supporting its clients with a team of experts. Our extensive years of experience in automotive penetration testing, specially purposed Automotive Lab located at Budapest, Hungary and necessary software and hardware create unique value for many OEMs and Suppliers.
Through the Automotive / Hardware hacking lab, Deloitte provides:

• Technical testing services – for automotive, medical or IoT devices, any generic off the shelf or custom products
• A center of excellence – practices for device security investigation and testing
• An environment and secure location – to test multiple and complex projects, analyze, and pilot proprietary technology.

To be able to help our clients with this complex agenda Deloitte has developed unique training and demonstration environments which are ideal for practicing automotive security testing tools and techniques.

Specialized trainings are recommended for:

• OEMs or Tier 1 suppliers, automotive design engineers with the goal of designing secure automotive systems.
• Penetration testers who are interested in automotive security testing.
  
• Security professionals who want to develop their skills in the automotive domain.
• Red team members with embedded/IoT/other electronic components in focus
• Bug hunters who want to find vulnerabilities in vehicles or their connected infrastructure embedded systems.
• Anyone interested in automotive penetration testing.