The connected ecosystem of software-defined vehicles continues to expand and mature at a rapid pace. Automotive OEMs, Tier 1 and 2 suppliers, and others with roles in smart mobility are devoting considerable resources and effort to developing and refining the parts, components, connected vehicles, and systems, that make up this realm. The rate of expansion is almost exponential. As this domain grows, the demand for solutions rises, and the risk of cyberattacks against this realm increases. What are the automotive cybersecurity processes used to help protect these vehicles and the systems in their supporting infrastructure?
Automotive cybersecurity is a subset of overall cybersecurity. Even though it is a segment of the greater picture, the realm of automotive cybersecurity itself is a broad topic with many requirements and considerations. To best understand automotive cybersecurity, it is helpful to review the unique requirements of the automotive realm, compare them to the more typical cybersecurity considerations that tend to be common across most connected devices and systems, and then walk through an overview of the standards that govern this work.
To start, let’s briefly examine modern vehicles. Long gone are the days of fully or mostly analog mechanical vehicles operating as isolated individual machines, solely under the control of the driver’s input and attention. Today’s modern mechatronic machines combine a dizzying array of sensors, data communications systems, wired and wireless networks, processors, sensors, and mechanical actuators. They have infotainment systems, advanced driver-assistance systems (ADAS), and a variety of modern electric vehicle systems.
Common to all of these connected systems is their reliance on digital technologies in one form or another. Interwoven digital systems working together enable amazing capabilities that can greatly increase safety and reliability, but they also carry risks.
Properly functioning digital systems are inherently safer than their analog predecessors. Cybersecurity helps keep the system secure, so it can perform as intended. To safeguard the security of these connected vehicles and their supporting systems, a standard was developed to guide developers and manufacturers through the process of implementing effective measures and strategies. ISO/SAE 21434:2021 “Road vehicles — Cybersecurity engineering” was published in August 2021. It delineates the engineering requirements for automotive cybersecurity risk management and provides a framework for the processes and common terms for communicating and managing cybersecurity risks in the automotive realm.
There is much to protect. The vast number of ECUs and lines of code, and the degree of connectivity, create an extensive and tempting number of vectors for cyberattacks, not only on the vehicle itself but also on all the elements in the overall automotive ecosystem.
Modern vehicles can have up to 150 electronic control units (ECUs) of various types, including those for engines, powertrains, transmissions, brakes, central control, central timing, body control, suspension, and general electronics control. Connected units provide communication, geolocation sensors and reporting, voice controls, and connectivity to cloud platforms. By 2030, it is expected that many vehicles will have approximately 300 million lines of software code. This is more than 1,100% greater than the number of lines of code in an F-35 stealth fighter!
Managing the increasing complexity and sheer quantity of these elements has become a significant and critical challenge for vehicle manufacturers. But the importance of cybersecurity is difficult to overstate. At its heart, this digital ecosystem is built on trust. If the data or code is altered or corrupted to even a slight degree, the ecosystem can perform erroneously or not at all. Some or all portions of the ecosystem could fail to provide the intended safety, or worse, could even be subverted to deliberately cause harm. In other words, greater capability can equal greater exposure, if the risks are not managed methodically and systematically.
This entire digital ecosystem must be accurate, complete, and secure as defined by formal industry standards adopted across the industry so that the various vehicles and their systems can interact effectively with each other. This ecosystem must be able to be thoroughly interrogated for trustworthiness via vetted processes, and we must be able to validate that the entire system is secure.
The scope of automotive cybersecurity is delineated by the automotive realm, but it is important to remain aware that the automotive realm interacts with other digital realms, as all of our automotive requirements and considerations must mesh smoothly with the overall cybersecurity efforts taking place beyond the automotive realm. This is important, because automotive cybersecurity is not just automotive alone, and the world beyond automotive is under perpetual change while simultaneously, it constantly carries the risk of impacting automotive. For example, an exploit in a cloud server used for supporting GPS in many different systems could impact a vehicle just as readily as it could impact hikers, surveyors, boats, airplanes, and other vehicles and systems that utilize it.
Within the automotive realm, the National Highway Traffic Safety Administration (NHTSA) defines automotive cybersecurity as follows:
“Cybersecurity, within the context of road vehicles, is the protection of automotive electronic systems, communication networks, control algorithms, software, users, and underlying data from malicious attacks, damage, unauthorized access, or manipulation.”
Source: https://www.nhtsa.gov/crash-avoidance/automotive-cybersecurity
In the case of the autonomous automotive environment, cybersecurity helps to safeguard the power of digital processing to greatly increase the speed, accuracy, completeness, capacity, and effectiveness of digital communication among drivers, vehicles, and roadside elements. These elements enable simultaneous awareness of all the vehicle states and near-term intentions, enabling the group to work in concert as a cohesive whole.
So, the overarching requirements define cybersecurity, the art and science of protecting data, devices, and networks from criminal use or unauthorized access. And its application within the automotive realm narrows the scope to automotive cybersecurity, that which impacts the automotive realm. There is overlap and a great degree of interconnectivity. But the automotive standards and processes themselves are scoped to just the automotive realm.
ISO/SAE 21434 specifies engineering requirements for cybersecurity risk management regarding the conceptualization, product development, production, operation, maintenance, and decommissioning of electrical and electronic (E/E) systems in road vehicles, including their components and interfaces. It builds on SAE J3061, Cybersecurity Guidebook for Cyber-Physical Vehicle Systems. ISO/SAE 21434 applies to series production road vehicle E/E systems, including their components and interfaces, whose development or modification began after the initial publication of the standard.
ISO/SAE 21434 does not prescribe specific technology or solutions related to cybersecurity.
ISO/SAE 21434 organizes the processes into groups called clauses. The clauses are fulfilled in an order that can vary based on the nature of the item. The primary influences on the selection of the clauses to be performed, and the order dependency in which they are performed, are based on prerequisites and further supporting information. The clauses clearly define these considerations, taking the guesswork out of deciding which clause needs to be performed, and in what order.
A good analogy for the clauses is to compare them to tools, such as the pieces in a socket set. You don’t need every handle and socket and extension in the tool kit for every bolt you encounter. A given bolt (item) might require the use of a specific socket (clause), plus an extension and handle (other clauses added as subsets). Whereas the same type of bolt in a different location performing a different function might only require the socket and the handle.
Likewise, a given clause might stand alone, or it might call for a few other clauses to be added as subsets; these can vary depending on the nature of different clause implementations, which is a fancy way of saying “It depends”.
In other words, a given clause might be utilized in isolation, or under certain other conditions, that same clause might be performed as a subset task, depending on the requirements of the overarching clause. A given clause might be fulfilled as a subset of another clause, or it might be fulfilled standing on its own. It all depends on the nature of the item being addressed.
While the overarching recipe-like combination of clauses might vary depending on the unique characteristics of the item being addressed, the processes within each clause are performed in a much more rigid and organized order within that clause.
This standard starts with Clause 4. This clause is informational in nature. It details the context and perspective of the approach that the standard takes regarding cybersecurity engineering for road vehicles.
Clause 4 starts with fundamental information, defining common terms used throughout the rest of the standard. It also details the scope of the standard by explaining what is in scope and out of scope. It reinforces that the standard describes cybersecurity from the perspective of a single item, illustrates the workflow of overall cybersecurity risk management, and the relationships between items, functions, components, and related items.
This clause includes a host of practical information about cybersecurity management, and the specification of organizational cybersecurity policies, rules, and processes.
The common term used here is governance. Cybersecurity governance is the process of setting policies and procedures, implementing actions to maintain situational awareness, protecting systems and information from cyber threats, and allocating the resources required to fulfill these tasks.
Cybersecurity governance is typically divided into five types:
Clause 5 defines what a cybersecurity policy is, and the organizational rules and processes that are used for cybersecurity. It assigns responsibilities and authority, and details the provision of resources and the management of the interactions that occur between cybersecurity processes and related processes. This clause also explains other practical matters, such as how to manage the cybersecurity risk, and how to implement and maintain a cybersecurity culture within an organization.
Clause 5 also explains how to support and manage the sharing of cybersecurity information, and how to establish and manage various management systems for the maintenance of cybersecurity. It explains how to provide evidence that the use of tools does not adversely affect cybersecurity, and how to perform an organizational cybersecurity audit.
This clause details the cybersecurity management and cybersecurity activities at the project level. It explains how to create a cybersecurity case; how to perform assessments when applicable; and how to determine whether, from a cybersecurity perspective, the item or component can be approved and released for post-development, aka production.
Clause 6 also defines, for a specific project, the allocation of responsibilities and the planning of the project’s cybersecurity activities. Requirements are defined in a generic manner so that the guidance can be applied to a variety of items and components.
In addition, this clause also details the process of tailoring, a powerful process for potentially increasing efficiency. It explains how tailoring is based on a rationale, and details how that rationale must be defined in the cybersecurity plan. Tailoring is typically considered in instances of reuse, components that are out-of-context, and the use of off-the-shelf components. Tailoring can also be useful for updates.
Sometimes, the responsibilities for cybersecurity activities are not wholly contained within just one organization. The interactions, dependencies, and responsibilities for distributed cybersecurity activities between customers and suppliers, must be clearly defined. This clause addresses these needs and includes requirements for assigning responsibilities in distributed cybersecurity scenarios, where cybersecurity activities are dispersed between a customer and their supplier.
In scope, Clause 7 applies to the components and items developed by distributed activities. It details the interactions between a customer and a supplier, and the management of all phases where an agreement applies to the customer/supplier interface. In some instances, internal suppliers can be managed in much the same way as external suppliers, so these processes can be applied in that scenario as well.
This clause includes information about the continual activities that are performed during all phases of the cybersecurity lifecycle, including those that can be conducted outside of a specific project. This includes activities that provide information for ongoing risk assessments. This clause also defines the vulnerability management of E/E systems until the end of cybersecurity support is reached for that item.
Clause 8 provides guidance on monitoring cybersecurity information in order to identify cybersecurity events; how to evaluate cybersecurity events to identify weaknesses; how to identify the vulnerabilities that arise from those weaknesses; and how to manage those vulnerabilities once they have been identified.
Each clause fulfills a purpose. Sometimes, the outputs from two or more clauses are combined in order to produce the foundation for the next steps in the chain of cybersecurity practices. One of the fundamental steps that must be taken is to consider the functionality of items at the vehicle level. In Clause 9, the outputs from multiple clauses are combined to answer the simple question, “What does this thing do, and how does it impact the vehicle?”
In this clause, this question is answered by identifying the item and defining its operational environment. Together, these elements form the Item definition, which in turn forms the basis for all the cybersecurity activities that follow.
For this purpose, the cybersecurity risks are assessed. This is achieved by using the threat analysis and risk assessment methods found in Clause 15, in combination with the inputs gathered by performing the tasks in Clause 9.4 that govern quantifying the cybersecurity goals. This combination of threat analysis, risk assessment, and cybersecurity goals, brings specificity to the cybersecurity claims, which are in turn used to explain why the risk retention (also called risk sharing or risk treatment in the standard) in a given instance is considered adequate.
At this point, another term is introduced, the cybersecurity concept. This concept is a combination of the cybersecurity requirements and the requirements that have been placed on the operational environment. Both of these are derived from the cybersecurity goals and are based on a comprehensive view of the item that can also include supporting information from the Threat Analysis and Risk Assessment (TARA).
The processes in Clause 9 take into account:
These descriptions can also support the evaluation of designs and help to determine the appropriate targets for the validation of cybersecurity.
The activities in Clause 9 can go into a great depth of detail. For example, it can include specific features of the item, such as the capability of implementing updates, or the ability to obtain user consent during operations.
Lastly, these activities can also take into account monitoring those cybersecurity claims that occur when the decision is made to not treat a given risk and instead, the choice is made to either accept, share, or avoid it.
This clause details the specification of the cybersecurity requirements and the architectural design of the item, as well as the integration and verification activities. This is a phase where clarity and polish are achieved. Cybersecurity activities are performed iteratively in this phase until no further refinements of cybersecurity controls are required.
Clause 10 is where the V-model workflow comes into significant prominence, bridging the activities of the concept phase of Clause 9, down through the detailed product development phase of Clause 10, and then upward to the cybersecurity validation activities in Clause 11. (Of course, this description is rather abstract, basically illustrating the component level and sub-component level. In practice, the workflow can be extended in detail to cover any level of abstraction required; this flexibility and adaptability are some of the most powerful aspects of the V-model.)
However, the team is not restricted to just using the V-model alone. Depending on the circumstance, teams also have the option of employing appropriate development approaches or methods that differ from the V-model, such as agile software development.
Regardless of the approaches used, the objectives of Clause 10 remain consistent:
In addition to defining the specifications, considerable consideration should be given to how these specifications interface with other elements. This can include the identification of configuration and calibration parameters that are relevant for fulfilling the cybersecurity requirements, settings or permitted range of values, and the correct configuration of the hardware security module.
These specifications should also capture any interfaces between sub-components of the defined architectural design that are related to the fulfillment of the cybersecurity requirements, including their static and dynamic aspects, and their usage.
Consideration should also be given as to how these specifications can also impact downstream post-development phases, including:
In addition, the capabilities of the components that are required to implement the cybersecurity controls can also be taken into consideration, such as processor performance and memory resources. But if design, modeling, or programming notations or languages are used for the cybersecurity specifications or their implementation, there are additional considerations that come into play when such a notation or language is selected:
Weaknesses in the design of the architecture should be actively sought out so that they can be addressed. There is always a risk that weaknesses can be introduced inadvertently. To help counter this risk, established and trusted design and implementation principles should be utilized.
The result of all of these detailed efforts is to create a robust and comprehensive specification. Once it is created, it has to be applied. This is where integration and verification activities come into play. They verify that the act of implementing and integrating the components fulfills the defined cybersecurity specifications.
When creating and specifying the integration and verification activities, certain elements must be taken into consideration, and then tested:
The standard defines several acceptable specific methods for testing these elements.
Progressing from the more detailed testing prescribed in Clause 10, Clause 11 encompasses the activities necessary for the item to achieve cybersecurity validation at the vehicle level.
In order to accomplish these activities with the greatest degree of accuracy and realism, the item is evaluated in its operational environment at the vehicle level, and the evaluation includes all of the configurations intended for series production.
Once properly completed, Clause 11:
At this stage, validation encompasses confirming the adequacy of the cybersecurity goals with respect to the various threat scenarios and their corresponding risks. It also proves and provides evidence that the cybersecurity goals of the item were actually achieved (thus confirming the validity of the cybersecurity claims), and ensures that the requirements are appropriate for the operational environment. This last point helps ensure that the validation and testing designed for an arctic environment, for example, is not also blindly applied to a desert environment where the stresses of heat exposure can have a significantly different impact on the power consumption requirements for sustaining cooling systems, as well as the impact of high heat exposure on the typical life of electronic components. Specifications must reflect the real-world environments where the items are going to be used, and the validation process must align.
This clause is the first in a series of post-development phases.
“Production” is defined in scope as encompassing the manufacturing and assembly of an item or component, including its manufacture at the vehicle level.
The purpose of a production control plan is to ensure that the cybersecurity requirements defined for the post-development phase are properly applied to the item or component, and to ensure that vulnerabilities cannot be introduced during production.
The production control plan includes:
Despite all of these efforts and safeguards, there can still be a degree of risk. What happens if something goes wrong?
Clause 13 is the domain for such contingencies. This clause describes the cybersecurity incident responses, and details how updates are applied to items or components in the field.
Updates are defined as changes made to an item or component during post-development. Updates can include additional information such as technical specifications, integration manuals, and user manuals.
Organizations might issue updates for a variety of reasons, such as correcting vulnerabilities, addressing safety issues, or implementing functional improvements.
(To clarify, the modifications of items or components that are in the concept, product development, or production phases, are encompassed by the change management processes governed in Clause 5 “Organizational cybersecurity management”, rather than this clause.)
The objectives of Clause 13 are straightforward:
A variety of information contributes to fulfilling these objectives. This can include general information about the vulnerabilities that caused the response and more formal vulnerability analyses.
A cybersecurity incident response plan must be created for each cybersecurity incident. It includes:
Decommissioning is something different than the end of cybersecurity support. An organization can end cybersecurity support for an item or component, but that item or component can remain functioning as designed in the field. Both decommissioning and end of cybersecurity support can result in cybersecurity implications, but those implications must be considered separately.
The objective of this clause is to effectively communicate the end of cybersecurity support and to enable the decommissioning of items and components from a cybersecurity perspective. But there is a unique challenge encompassed in this clause. The act of decommissioning itself can occur without the organization’s knowledge and in such a way that decommissioning procedures cannot be enforced, therefore the act of decommissioning is out of the scope of the standard. For example, when a piece of equipment that is owned by a customer reaches the end of its useful life and the customer has it scrapped, rarely is the original organization that manufactured it notified so they can “close their books”.
So, with decommissioning out of scope because it is out of the hands of the organization, Clause 14 turns its focus to the end of cybersecurity support. It directs that a procedure be created to communicate to customers when an organization decides to end cybersecurity support for an item or component. Such communications can be governed under contract requirements between suppliers and customers, and they can be communicated directly to the vehicle owners by an announcement. This clause provides specific guidance for creating these communications and their procedures.
One of the most important functions of the cybersecurity process is to determine the extent to which a road user can be impacted by a given threat scenario, and then detail the methods for managing those threats. These methods and their resulting work products are collectively known as a Threat Analysis and Risk Assessment (TARA).
The TARA is a powerful tool. They are performed from the viewpoint of all of the stakeholders, including the Original Equipment Manufacturers (OEMs) and the road users. The methods defined in this clause are generic modules that can be invoked in a systematic manner, and they can be applied at any point in the lifecycle of an item or component.
The TARA includes, but is not limited to:
Because these are generic modules, the work products defined in this clause are documented as parts of work products produced by other clauses.
Organization-specific scales for the impact rating, the attack feasibility rating, and the risk value determination, are defined as part of Clause 5 and can be applied and mapped to corresponding scales defined in the standard.
The specific objectives of Clause 15 are:
Automotive cybersecurity is a broad and detailed subset of the greater cybersecurity realm. It interacts with digital elements beyond the pure automotive envelope. Cybersecurity processes are detailed but straightforward. They are documented in ISO/SAE 21434, which specifies the engineering requirements for the cybersecurity risk management of electrical and electronic (E/E) systems in road vehicles, including their components and interfaces. It is organized into clauses, each with a specific scope and job to do. The topic can at first seem overwhelming, but if an organization takes a systematic approach and enlists the aid of an experienced team like those provided by LHP, the important work of successfully implementing trustworthy cybersecurity is absolutely achievable. Properly accomplished, automotive cybersecurity is the key that unlocks the full potential of functional safety.