Menu
Over the past two decades, innovation, competition and customer demand have greatly increased the automotive industry’s dependence on software and connectivity. Rapid innovation has transformed motor vehicles from mostly mechanical machines into highly complex, highly connected cyber-physical systems.
Unfortunately, this huge increase in software and connectivity has made automobiles inviting targets for unscrupulous software hackers. The massive growth in attack surfaces in automotive systems has already resulted in some high-profile cyberattacks on motor vehicles.
In response to this growing threat against its industry, the Society of Automotive Engineers (SAE) and ISO have responded with ISO/SAE 21434: Road Vehicles – Cybersecurity Engineering, an ISO-approved standard aimed at addressing automotive cybersecurity in a systematic way.
This post is Part 1 of a 3-part series derived from TrustInSoft’s new white paper, “ISO/SAE 21434 from a Software Development Perspective: How sound, exhaustive static analysis can help ensure air-tight automotive cybersecurity while lowering its costs.”
To get your FREE copy, CLICK HERE
ISO/SAE 21434 is a framework for developing a comprehensive risk management system that spans the full motor vehicle lifecycle. The specifics of how to implement that process, however, are largely left up to the automotive manufacturer. Naturally, since the standard is relatively new (published August 2021), many in the industry are struggling with its requirements.
In this article, we’ll look at:
We’ll also indicate where you can find more information on meeting those challenges.
The automotive industry is undergoing enormous change. Digitization (the capture of information within the automotive system and its conversion to digital messages), power train electrification (electric vehicles), advanced driver assistance systems (ADAS), autonomous driving (AD), car sharing, and other new mobility concepts are among the megatrends that are reshaping the sector.
All of these trends are software-driven and rely heavily on vehicle connectivity. Sufficient mobile connectivity bandwidth is now available to support a variety of complex use cases. Vehicles can be connected to back-end systems and to other vehicles. They exchange large volumes of data.
Connectivity has enabled a wide range of new customer services, which include:
On the downside, connectivity has also greatly expanded the attack surfaces hackers can exploit to gain access to the vehicle’s systems.
Under heavy time-to-market pressure, Automotive OEMs are depending on many new players to bring software expertise to the sector. They’re also relying on numerous open-source technologies to facilitate interoperability between systems and suppliers. These factors have made their latest vehicles ideal targets for hackers looking to exploit cybersecurity vulnerabilities.*
* MITRE defines a cybersecurity “vulnerability” as “a flaw in a software, firmware, hardware, or service component resulting from a weakness that can be exploited, causing a negative impact to the confidentiality, integrity, or availability of an impacted component or components.”1
Software security is now a key challenge in the automotive industry. The potential consequences of a cyberattack upon a vehicle have become significantly more severe. These consequences include:
To meet this new challenge, software developers in the sector must adopt a robust cybersecurity management process. In addition, they must adapt their software verification activities to better identify and eliminate the vulnerabilities that software hackers typically exploit.
It is to address the first of these needs that SAE and ISO developed ISO/SAE 21434, a standard cybersecurity management process for the industry.
ISO/SAE 21434 provides a structured approach to define and manage cybersecurity goals and risks. It establishes a rigorous framework to enable organizations to design vehicles that are protected against cybersecurity threats. In addition, it is designed to ensure that cybersecurity is considered at every stage of the product’s development, from inception through retirement.
Compliance with ISO/SAE 21434, while mandatory for all ISO members, is technically voluntary for the industry as a whole; ISO/SAE 21434 is a standard, not a regulation. However, automotive OEMs and suppliers must be compliant with UN regulation no. 155 (UN R155).2
UN R155 requires automotive firms to implement a Cybersecurity Management System (CSMS) and meet other specific requirements related to cybersecurity. For the automotive industry, the requirements of UN R155 are binding and must be complied with in order to obtain type approval and market access. Failure to comply can lead to a sales ban in the corresponding area of application. More than 60 countries have already committed to adopting the regulation.
Regulations like UN R155 often refer to various standards as a thematic point of reference. UN R155 refers to ISO/SAE 21434. A published interpretation document of late 2020 directly relates the requirements of the regulation to the various requirements of the standard.3
ISO/SAE 21434 thus provides support for meeting the requirements of UN R155. Put another way, for companies who must comply with UN R155, ISO/SAE 21434 has become a de facto requirement.
To prove their compliance with ISO/SAE 21434, automotive suppliers must demonstrate their products’ cybersecurity at initial delivery and are equally liable for that cybersecurity throughout the entire product lifecycle.
They must define cybersecurity activities that support the initial product delivery and the entire life cycle of the product. They must demonstrate good cyber security practices in accordance with the cyber risk analysis. They must identify, assess, and mitigate product vulnerabilities.
Furthermore, they are liable for any damages in the event of a product vulnerability being exploited by an attacker.
To minimize their overall costs, suppliers need to define efficient cybersecurity activities at the beginning of each project to minimize the cost of those activities over the product’s lifecycle.
From a software development perspective, ISO/SAE 21434 is a process-centric standard focusing on cybersecurity risk management. It leaves a fair amount of freedom to suppliers in the methods they use to demonstrate the security of their products. The standard enumerates various verification techniques but provides no guidance on how they should be employed.
ISO/SAE 21434 puts the onus on suppliers to identify potential attack vectors and vulnerabilities and determine how to protect against them. They must do so through their own specific implementation of the mandatory risk assessment process the standard defines.
In the context of ISO/SAE 21434, cybersecurity risk analysis involves assessing the attack surface of automotive systems. The term “attack surface” refers to the sum of all potential entry points—direct or indirect—or vulnerabilities within the system that could be exploited by malicious actors.
Attack surface analysis includes analyses of hardware components, software modules, network interfaces, external connections, and communication channels.
The recent industry trends discussed earlier are causing a rapid expansion of automotive attack surfaces driven by the immense volumes of data these new technologies require. In electric vehicles, for example, the large volume of vehicle-to-infrastructure (V2I) messaging required for power management and charging point billing creates a very broad attack surface.
Car sharing relies on a direct mobile network link between the vehicle and backend servers for the car to report its position and other data to the server. Through this connection, hackers can realize a number of attack scenarios, like spoofing GPS signals to redirect the car or attacking the communication between the head unit of the car’s infotainment system and the backend server.
ADAS and autonomous driving rely on many sensors for navigation, including radar, lidar, and cameras. They also require advanced, high-definition maps that provide not only the normal two-dimensional map of the environment but also information on the vertical dimension, like road borders, guardrails, signage, and other obstacles. The storage and frequent exchange of the large volumes of data required for ADAS and AD creates a large attack surface for potential exploitation.
Connected cars, in general, are continuously expanding their attack surfaces. Trip data—like moving maps and real-time status on traffic, weather, and the availability of local services—must be updated frequently. The over-the-air (OTA) updating mechanisms needed to refresh this data broaden the attack surface considerably.
One weakness that affects all automotive electronics systems its internal communication network.
There are several network communication protocols used in automotive systems. The most widely used of these protocols is the Controller Area Network (CAN) bus. Others include FlexRay, Automotive Ethernet, MOST and Wireless CAN.
Like other network protocols (HTTP, Ethernet, Wi-Fi, Bluetooth, etc.), these automotive protocols are implemented in both hardware and software. For example, the CAN bus protocol implementation in an ECU consists of a CAN Controller implemented in hardware (a chipset) and a CAN services module implemented in software written in C or C++ (typically in C).
Though their communications are internal to system, these networks can be accessed from outside a vehicle. Any hacker willing to spend a couple of hundred dollars for a CAN bus analyzer and an interface cable, for example, can access a vehicle’s CAN bus and explore an ECU’s CAN services implementation for vulnerabilities.
The ease with which a vehicle can be breached in this way was demonstrated by researchers Charlie Miller and Chris Valasek in 2013.4 By monitoring the CAN bus via the OBD-II port used by repair shops to retrieve fault codes and diagnostic data, they were able to reverse engineer the CAN bus communications of a Ford Escape and a Toyota Prius.
Miller and Valasek demonstrated to journalists how they could take control of a wide range of vehicle functions ranging from mere annoyances like blasting the horn, changing the speedometer and gas gauge readings, and tightening seat belts, to serious safety hazards that included causing the engine to accelerate, jerking the steering wheel, disabling the power steering, and slamming the brakes at any speed.
Other research has shown that it is quite easy to trigger a Write Buffer Overflow error—a common error in C and C++ —using a simple API to connect to the CAN bus.5 Buffer overflows are frequently exploited by hackers to gain access to systems.
In 2015, Miller and Valasek demonstrated that the attacks they had demonstrated in 2013 could be carried out remotely as well.6 Experts determined that 83% of the flaws Miller and Valasek identified “can be exploited for CAN bus access, compromising telematics communications, escalation or attack chains, and compromising or disabling electronic control units (ECUs).”7
More recently, in late 2022, researchers were able to exploit vulnerabilities in the vehicles of 16 different automakers, as well as the connected vehicle services of SiriusXM, Spireon and Reviver.8 The consequences of the vulnerabilities exploited included:
Connected cars, in general, are continuously expanding their attack surfaces. Trip data—like moving maps and real-time status on traffic, weather, and the availability of local services—must be updated frequently.
Many customer services rely on connectivity as well. These include:
In addition, automotive OEMs and suppliers are beginning to rely on OTA updates for an ever-increasing volume of applications.
All of these features add attack potential vectors that must be accounted for and neutralized.
While there is much that can be done to secure a vehicle at the system level, a vast portion of the overall attack surface just described consists of source code. Software hackers will probe a vehicle’s code for vulnerabilities they can exploit. Therefore, automotive ECUs and other components that rely on software and firmware must be secured at the source code level as well.
Much of that software and firmware is written in the C/C++ programming language.
Because C/C++ code can run high-level structured programming on low-level mechanisms, it allows programmers to directly manipulate the hardware on which it runs. This characteristic—along with its flexibility, and its extensive support in terms of knowledge and programming resources—has made C/C++ the language of choice for automotive ECUs and for embedded systems in general.9
Most of the software and firmware for automotive applications—including ADAS, OTA updating, EV charging and billing protocols, vehicle connectivity, infotainment and many others—are written in C or C++. The services software for networking protocols like CAN and FlexRay are programmed in C. The AUTomotive Open System Architecture (AUTOSAR) adaptive platform is realized in C++.
What’s more, all of those applications rely on real-time operating systems (RTOS) or sequencers written in C.
To meet ISO/SAE 21434 and ensure the cybersecurity of their systems, it is imperative that automotive software developers ensure the elimination of vulnerabilities from all these applications. Unfortunately, eliminating vulnerabilities in C/C++ code is made difficult by the inherent security weaknesses of the language. We’ll examine those weaknesses in our next post.
This post is Part 1 of a 3-part series derived from TrustInSoft’s new white paper, “ISO/SAE 21434 from a Software Development Perspective: How sound, exhaustive static analysis can help ensure air-tight automotive cybersecurity while lowering its costs.”
To get your FREE copy, CLICK HERE
To deny hackers access to automotive systems, software developers must ensure their code is absolutely free of the types of vulnerabilities hackers most often exploit.
In Part 2 of this series, we’ll examine those vulnerabilities, why they are so prevalent in automotive software and firmware, and why they’re so dangerous. We’ll also look at an example of how one such vulnerability created a serious safety risk in vehicles of many of the world’s top automakers.
If you find this post useful, our new white paper, ISO/SAE 21434 from a Software Development Perspective, contains a more detailed discussion of all the topics covered in this blog series, and several examples and case studies as well.
To download your FREE copy, CLICK HERE.
