ISO/SAE 21434: Software certification for automotive cybersecurity
Article By : Mark Pitchford
Find out the details and implications of the ISO/SAE 21434 standard for automotive cybersecurity and how it complements ISO 26262.
Automotive embedded applications have traditionally been isolated, static, fixed-function and device-specific implementations, and development practices and processes have relied on that status. But the explosion in demand for connectivity now sees non-critical systems such as entertainment systems sharing the same communications infrastructure as steering, braking, and control systems. These changes bring the potential for safety and economic risks resulting from cyberattacks, but standards guidance for developers in the automotive industry has struggled to keep up.
The ISO 26262 “Road vehicles – Functional safety” standard was published in 2012 to give automotive manufacturers a way to embrace best functional-safety practices throughout the development lifecycle. ISO 26262 requires any threats to functional safety to be adequately addressed. It implicitly includes those relating to security threats, but it gives no explicit guidance relating to cybersecurity. At the time of ISO 26262’s publication, that was perhaps to be expected.
But the rate of change in the industry meant that by the time of its publication four years later, SAE J3061 Cybersecurity Guidebook For Cyber-Physical Vehicle Systems was much anticipated. SAE J3061 was always intended to be a stopgap, however, allowing time for the development of a more formal standard to address the issue more broadly. So, SAE J3061 was superseded by ISO/SAE 21434:2021 in 2021.
ISO/SAE 21434 can be considered complementary to ISO 26262 in that it provides guidance on best development practices from a cybersecurity perspective, just as ISO 26262 provides guidance on practices to address functional safety. During the same time, the new UNECE WP.29 regulation R155 for Cyber Security Management System (CSMS) was adopted by UNECE’s World Forum for Harmonization of Vehicle Regulations, making compliance obligatory for vehicle type approval from June 2022. ISO/SAE 21434 is cited in R155 as an appropriate reference for cybersecurity skills.
So, what does ISO/SAE 21434 mean for automotive development teams? Part one of this article series explains the details and implications of the evolving standards for automotive developers. Part two of the series will walk through the steps of a traditional development V-model to explain how the principles outlined by the standard can be applied at each stage.
A missed opportunity or increased flexibility?
While ISO/SAE 21434 supersedes J3061, the two documents differ in style: SAE J3061 relates the security and safety processes to each other, while ISO/SAE 21434 decouples them. Despite that distinction, ISO 26262 remains closely linked to the new standard, and is referenced repeatedly by it.
But ISO/SAE 21434 is seen by many as a missed opportunity.
Simply comparing the number of pages suggests why. ISO 26262 runs to 12 parts, many of which have a direct impact on how compliant application software is developed. Part 6 alone, entitled “Product development at the software level,” runs to 66 pages. In contrast, the whole of ISO/SAE 21434 is 81 pages long, and its scope stretches across all aspects of electrical and electronic systems within road vehicles throughout the supply chain.
Developers can expect to find details of what needs to be achieved in ISO 26262 from the perspective of functional safety, and ISO/SAE 21434 from the perspective of cybersecurity. However, whereas ISO 26262 also presents details of exactly how to achieve its aims, ISO/SAE 21434 does not.
The failure of ISO/SAE 21434 to give detailed guidance on how to achieve its objectives means that from a software perspective, the standard does little more than ratify the document it replaces. However, ISO/SAE 21434—and SAE J3061 before it—presents a worthy set of goals for software developers to achieve. From an optimistic perspective, the lack of detail affords flexibility on how they are achieved.
Beyond functional safety
Despite the clear synergy between ISO/SAE 21434 and ISO 26262, it’s important to note that ISO/SAE 21434 does more than simply formalize the need to include security considerations in functional safety requirements. The significance of malicious intent in the definition of those requirements should not be underestimated.
Perhaps less obviously, the introduction of cybersecurity in an ISO 26262-like formal development process implies the use of similarly rigorous techniques in applications that are not safety-critical, and perhaps in organizations with no previous obligation to apply them. ISO/SAE 21434 discusses privacy in general and personally identifiable information (PII) in particular, and highlights risks for both as being of no less significance than the potential compromise of safety systems.
In practical terms, ISO 26262-like rigor is now required in the defense of personal details that can be accessed via a connected car, including personal contacts, browser and location history, and credit card and other financial information.
ISO 26262, HARA and ASILs
Hazard Analysis and Risk Assessment (HARA) required by ISO 26262:3 is used to identify malfunctions that could lead to hazards, to rate the relevant risks of hazards, and to formulate safety goals. The resulting derivation of Automotive Safety Integrity Levels (ASILs) is a key concept in the development process defined by ISO 26262. ASILs are designed so that developers can invest proportionate levels of effort to preventing hazardous events.
Each hazardous event is assigned a severity classification (S0-S3), an exposure classification (E0-E4), and a controllability classification (C0-C3). The higher numerical values represent the least-desirable characteristic in each case. The likelihood of harm is a combination of these factors, and that is reflected in the assigned ASIL.
ISO 26262 requires the level of effort to be proportionate to ASIL, and not just to severity. Even if a hazardous event is potentially life-threatening, there is no need to invest heavily in its prevention if it’s incredibly unlikely to happen.
Table 1 This is how “Methods for verification of software integration” are specified by Table 10 in ISO 26262-6:2018. Source: LDRA
ISO/SAE 21434, TARA and what?
Threat Agent Risk Assessment (TARA) suggested by ISO/IEC 21434 is analogous to HARA in ISO 26262. TARA is a threat-based methodology to help identify, assess, prioritize, and control cybersecurity risks. It is a practical method to determine the most critical exposures while taking into consideration mitigation controls and accepted levels of risk.
The calculation of a “risk value” is like the calculation of an ASIL in that it accounts for the severity and likelihood of a successful attack, dependent on several factors:
- Threat scenario identification
- Impact
- Attack path
- Attack feasibility for that path
The “impact ratings” for safety damage are taken from the definitions in ISO 26262. They use the same impact metric as that used to ascertain ISO 26262 ASIL ratings. That principle is extended in ISO/SAE 21434 to address threats with the potential to cause financial damage, operational damage, and privacy damage.
Table 2 Abbreviated impact rating descriptions are taken from ISO/SAE 21434 tables F.1 to F.4 inclusive. Source: LDRA
Not only does ISO/SAE 21434 bring formal development to less safety-critical domains, but it also extends the scope of that development far beyond the traditional project-development lifecycle. Examples include establishing an incident-response process to address vulnerabilities that become apparent in the field, consideration for over-the-air (OTA) updates, and cybersecurity considerations when a vehicle changes ownership.
Seeking an ASIL equivalent
ISO/SAE 21434 is less prescriptive of the TARA approach to be taken compared with ISO 26262 HARA. More significantly, it stops short of defining an ASIL equivalent. Unlike ISO 26262, ISO/SAE 21434 does not map the level of validation and verification effort to the criticality of the software under development.
However, these ratings do lend themselves to mapping to the ASIL categories presented in ISO 26262.
Table 3 shows a reproduction of the example table superimposed with risk values, with numeric values that are dependent on the calculation approach. If this represents best practice where safety is critical, it seems logical that the same approach would be equally appropriate when the application is critical in other ways.
Table 3 Superimposing ISO/SAE 21434 criticality groupings onto the “Methods for verification of software integration” are specified by Table 10 in ISO 26262-6:2018. Source: LDRA
ISO/SAE 21434 cybersecurity in tandem with ISO 26262
SAE J3061 explicitly tied its development process to that of ISO 26262. Although ISO/SAE 21434 is less tightly bound, it does repeatedly reference ISO 26262 and there will be many cases where both standards apply. Indeed, the standards lend themselves to the integration of the two at each stage of the product lifecycle, even to the extent that the same test team could be deployed to fulfil both roles.
For example, it is possible to perform hazard analysis, safety risk assessment, threat analysis, and security risk assessment concurrently using a single integrated template and method.
Even where there is no safety consideration, adopting proven ISO 26262 best practices to address the high-level demands of ISO/SAE 21434 is a pragmatic approach that lets development teams apply known tools and techniques that are likely already available to them.
Editor’s Note: Part two of this article series about automotive cybersecurity takes a modified V-model approach to illustrate the relationships between ISO/SAE 21434 sections that have the most impact on software development, and explains in more detail how the principles outlined by the standard can be applied.
This article was originally published on EDN.
Mark Pitchford, technical specialist with LDRA Software Technology, has worked with development teams looking to achieve compliant software development in safety and security critical environments, while working on standards such as DO-178, IEC 61508, ISO 26262, IIRA and RAMI 4.0.