Standards and Threat Testing for Secure Autonomous Vehicles
Modern vehicles continue to progress through range levels, as defined by the Society of Automotive Engineers (SAE). These definitions have been widely adopted in the industry, and emerging automotive technology is measured against this scale (Figure 1).
Fig. 1: An illustration from the Society for Automotive Engineers shows range levels.
The closer we get to Level 5 of full autonomy, the more we surrender driving tasks and control to the vehicle’s advanced Driver Assistance Systems (ADAS) technology. The electronics must meet certain standards, including:
- Contain high quality, defect-free components and remain defect-free for many years
- Functional safety operation
- Works as intended
- Be safe and protect yourself against cybersecurity attacks
To ensure that all vehicle systems meet at least a minimum level against these requirements, several standards have emerged over the past few years. Figure 2 shows the different types of defects covered by each of the different standards. The ISO 26262 standard for functional safety in the automotive industry covers IC defects that are either present during manufacture or manifest during the life cycle of the vehicle. ISO 21448 is more focused on correctness of operation as it examines the function of the device within the system to ensure that it works as intended. The ISO 21434 standard guides the management of cybersecurity risks throughout the life cycle of silicon.
Fig. 2: Three key standards guide the development of autonomous vehicles.
Unlike the functional security risk landscape, which is essentially static for a given function, the security threat landscape is highly dynamic: the type and complexity of cyberattacks change throughout the lifecycle of the vehicle. Considering that by the time most vehicles hit the market, the electronic technology used is already several years old, the safety features built into the system today could be obsolete before the vehicle even enters production. This is the compelling reason to develop security technology that is also extremely dynamic and adaptable to any future threats that arise.
The cybersecurity of automotive electronics is guided by the ISO/SAE 21434 specification “Road vehicles – Cybersecurity engineering”, published in August 2021, and recommends the use of a methodology such as STRIDE, developed by Praerit Garg and Loren Kohnfelder at Microsoft, and/or “incitement to misuse”.
The core of an IC cybersecurity methodology is threat modeling. There are several out-of-the-box solutions for threat modeling, but in general, users have to do the real work to fully commit to and stick with a particular solution. Some of these solutions are rooted in the STRIDE methodology and framework, while others rely on proprietary threat and asset databases and structured (but not standardized) description language formats.
The reality is that threat modeling is difficult. It can be used as a design aid tool and to help design teams think more clearly about the kinds of problems they may face. However, without concrete experience of how systems are attacked at an engineering level, this can be far too abstract. It is critically important that the teams involved in this work truly understand the threat environment and are able to reasonably and dispassionately assess certain scenarios. The reason for this is that too high a threat or risk can increase the cost of development. Conversely, a score that is too low will starve funds and engineering resources from an area that badly needs attention. The overall result is the well-known “kitchen window open, front door triple locked” scenario.
Other threat modeling aids can be beneficial to help model other aspects of the attack – for example, the cost to an attacker of taking a particular route. Attack trees provide this capability and can be useful if they are modular and can be combined in a kind of puzzle to provide very useful information (Figure 3). The best way to work on attack trees is to have people on the team who really understand the situation on the ground both in terms of the technology and how it’s broken on the ground.
Fig. 3: The steps of the STRIDE process for automotive cybersecurity.
Threat modeling should not be static: it should not be obsolete. Everyone has to start somewhere, and the time invested in initial threat modeling is likely to pay off over time, as long as it is maintained and adhered to by development teams. There is unlikely to be an industry-wide threat pattern, but individual OEMs will have very similar patterns, as will their suppliers. Future developments will likely see more automation, but this discipline will still be one of critical thinking.
Connected and Autonomous Vehicles (CAV) are made up of several networked computers. These ECUs (Electronic Control Units) enable a wide range of functionality and functionality in the vehicle, from drivability and powertrain control to connectivity, sensing and body modules. ECUs are interconnected via on-board networks, usually comprising a data bus known as the Controller Area Network (CAN). As such, modern vehicles are an example of a cyber-physical system (CPS).
The increase in computing and connectivity capabilities of ECUs has introduced new cybersecurity challenges that can potentially affect the safety of an automobile and its occupants. Effective vehicle cybersecurity testing can play a crucial role in uncovering and resolving security vulnerabilities. However, testing an actual vehicle (involving cyber-physical components) itself carries security and economic risks. Therefore, researchers and practitioners often rely on test environments (commonly referred to as testbeds) to discover cybersecurity vulnerabilities. Effective and efficient security testing requires the application of appropriate and systematic testing methods.
The Secure-CAV Consortium, sponsored by Innovate UK, has developed a multi-component testbed representing a flexible and functional in-vehicle architecture for real-world trials to train, test, validate and demonstrate automotive cybersecurity solutions. This demonstrator aims to reproduce as precisely and faithfully as possible the behavior of a real vehicle (fidelity), while being reconfigurable, portable, safe and inexpensive to build. The testbed gives cybersecurity researchers and engineers a comprehensive assessment of the security of embedded network components providing:
- Integration of Siemens IP in an FPGA implementation for monitoring ECU behavior
- Support for multi-component architecture and a range of on-board communication protocols (including CAN and Automotive Ethernet)
- A ‘plug-and-play’ installation for customer ECUs (which can be telematics units, sensors, infotainment systems, in-cab connectivity and body modules)
- A traffic scenario simulator to generate sensor data and connectivity supporting threat use cases being demonstrated
- Configurability for repeatable test scripts and an interface for packet injection and tracing, to support attack vectors
- A data repository for data captured from emulated sensors, vehicle simulator, CAN/Automotive Ethernet payload, FPGA and attached ECUs for visualization, test calibration and machine learning. The repository can be in the cloud for remote analysis or on local storage.
Figure 4 shows the Secure-CAV Automotive Cybersecurity Testbed. It includes a car simulator, an on-board network simulator, a field-programmable gate array (FPGA) system, a physical network, data storage, and a dashboard of a real car. Most of the vehicle architecture and its CAN bus network is realized in a virtual environment using the Vector CANoe network simulator.
Fig. 4: Architecture diagram of the demonstrator.
The Secure-CAV demo vehicle’s IP address and anomaly detection software monitors protocols and transactions at the lowest level of hardware. This is supported by unsupervised machine learning algorithms and statistical analysis, with input from experts at the University of Southampton. This was integrated with FPGA technology and linked to two vehicle demonstrators developed by teams from Coventry University and cybersecurity specialists Copper Horse. A range of selected real threats were exercised, including the purchase and analysis of hacking equipment for existing vehicles.
The long lifespan of automobiles requires an innovative approach to cybersecurity. Many vendors and OEMs are constantly working on solutions to detect and mitigate new and upcoming attacks. Threat modeling and testing can be a challenge because it often needs to be done at the system level rather than the component level.
The Secure-CAV project has proven hardware-based security technology that will enable the automotive industry to stay ahead of today’s threats and as-yet-unknown threats in the future, putting the industry in a much-needed cybersecurity posture. more tenable than it is now. is holding.
To further ensure that cybersecurity detection and mitigation technologies are fully tested under all different conditions and scenarios, developers can move from the physical demonstrator of Secure-CAV to a fully digital realm with the Siemens PAVE 360 platform. , which can model and emulate a complete vehicle. systems in a digital environment. A complete digital twin of the electronic system can be created, allowing an extremely comprehensive set of real data to be applied. With this real data, it is possible to subject the vehicle system to the equivalent of millions of kilometers driven under different conditions. This approach means that with a high-fidelity model, a digital twin environment yields results equivalent to what would be seen on the track, and the digital model allows for easier exploration of more edge-case use scenarios than this that would be possible in the physical world.
As we strive to achieve full Level 5 autonomy, the way automotive systems are developed and certified within the supply chain will change. Adopting the latest tools and technologies ensures that new automotive electronic systems are both safe and secure against today’s and tomorrow’s cyber attackers. Without advanced Embedded Analytics technology, automotive ICs will remain a black box, making it difficult to determine overall vehicle system health, reducing overall vehicle reliability.