Putting Automotive Security to the Test

Themenbild Testing

Putting Automotive Security to the Test

At a time when the connectivity of vehicles and the number of automated driving functions are increasing all the time, it is vitally important to ensure effective protection of vehicles against unauthorized access, manipulation, and data spying. For OEMs and suppliers, comprehensive security testing is therefore increasingly becoming part of their standard repertoire for the preventative protection of sensitive systems in the vehicle.

Ideally, security testing follows a holistic approach. That is, the testing should encompass all the relevant technical systems in and around the vehicle (ECUs, network components, interfaces, connected apps and services, etc.). And it should take place throughout the life cycle and across the entire supply chain.

 Testing Lifecycle

Figure 1: Security testing has to accompany the entire product life cycle.

In security testing, there is a fundamental distinction between automated and manual test procedures. The one can certainly complement the other: automated tests can be run quickly, repeated as often as required, and easily incorporated into a fixed test routine, and they are cost-efficient. They can also be fully integrated into the development process in order to identify and remove weaknesses as early as possible. However, automated testing tools are usually blind to customer-specific adaptations – which are extremely common in the automotive sector. Automated tests also reach their limits when confronted with logical errors in the program code, complex attack vectors, or attacks on hardware. In these cases, manual tests carried out by security experts are a meaningful and necessary complement.

Wide variety of automotive security test procedures

Leaving this issue aside, there is a whole range of security test methods that are used in the automotive industry: penetration tests, code audits, functional security tests, fuzzing tests, vulnerability scans, and side-channel analyses.

  • Penetration test

In a penetration test – “pen test” for short – the tester interrogates the target system with all its components and applications by trying to identify and overcome the system’s defense mechanisms in the way a hacker would. In the automotive sector, pen tests are typically employed to test the IT security of individual ECUs, or groups of ECUs in conjunction, or entire vehicles. These tests bring to light weaknesses or potential errors in the implementation, which may be attributable to faulty technical implementation, components from third-party providers, the imperfect interaction of system components, or deviations from the concept.


Figure 2: Pen tests comprise a multi-stage, iterative process.

  • Code audit

In code audits, security testers search at the source code level for programming errors or security gaps that a hacker could exploit. They pay particular attention to the correct behavior of implemented security measures and to code that might possibly be processing hostile input from potential hackers, such as parsers, crypto-implementations, or communication stacks (e.g. for network, radio, user interface). Code audits can also identify errors that are revealed during implementation, such as the incorrect validation of inputs and storage problems (e.g. buffer overflows).

  • Functional security test

Functional security tests are used to verify whether the specifications of the security mechanisms used are correctly and fully implemented. Moreover, it is necessary to validate correct integration on the target platform, as the latter often behaves differently than the development system or involves additional restrictions. In vehicle environments, integration tests are often very complex and demanding. If we take the example of typical bus protocols such as CAN, sometimes no direct answer messages are sent, making it hard to recognize whether the test messages were correctly processed. Often it is necessary to generate and monitor several signals on various vehicle buses simultaneously – for example, when testing a security protocol or a gateway filter function.

  • Fuzzing test

Fuzzing is a powerful testing technique for checking the robustness of the system being tested. Using a piece of test software known as a fuzzer, a high number of atypical or invalid inputs are generated in order to run through the system’s many different internal states. The goal is to provoke unexpected malfunctions, anomalies, or unforeseen information disclosures that could allow a cyberattack on the system. With a good fuzzing tool, it is possible to cover virtually all automotive-relevant protocols: CAN, ISO-TP, UDS, USB, Bluetooth, Wi-Fi, and many Ethernet-based protocols (IP, TCP, UDP, FTP, TLS, etc.).

  • Vulnerability scan

In vulnerability scanning, the target systems are tested for known vulnerabilities, exposures, and security gaps. For such a scan, the testers generally utilize a database with the weaknesses currently known for the test object. The scanner “senses” the system, working its way through this database. In the ECU environment, for example, it scans the Unified Diagnostic Services (UDS) protocol for typical weak points such as seed values that are too low or key calculation algorithms that are too weak.

  • Side-channel attacks

Side-channel attacks are a technique for attacking components involved in the physical implementation of the system. We distinguish between passive and active side-channel attacks. In a passive side-channel attack (also known as side-channel analysis), the testers seek to draw conclusions about internal data processing by measuring physical characteristics of the target system (such as time behavior, power consumption, and electromagnetic emissions). By contrast, active side-channel attacks aim to deliberately manipulate the system. A typical method here is fault injection attacks, where testers attempt to provoke processing errors in a microprocessor by means such as temporarily interrupting the power supply or electromagnetic injections.

Summary: OEMs and suppliers need a security test strategy

When the impending ISO/SAE 21434 standard and UNECE WP.29 regulations come into effect, at the latest, security testing will become an indispensable component for OEMs and their suppliers in a framework of security measures, organization, and processes with which they will fulfill the security requirements needed for the type approval of their vehicles in the future. It should be noted that the earlier that IT security tests are carried out in the development and life cycle of the product, the easier and more cost-effective it is to fix any weaknesses that are identified. Cost-saving automated testing is often possible specifically during the development stage, before manual tests are then used to identify and close further possible paths of attack. Fixing security gaps at a later stage – after SOP, when the vehicle is already in the field, or in the worst case after a cyberattack – is a great deal more difficult and costly, with a risk of product recalls and liability claims. Automotive manufacturers and suppliers should therefore possess a security testing strategy that is efficient and complies with all relevant standards and regulations in its type and scope.


ISO 9001:2015 Home