ISO/SAE 21434: Software certification for automotive cybersecurity

Embedded automotive applications have traditionally been isolated, static, fixed-function, device-specific implementations, and development practices and processes have relied on this 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 potential security and economic risks from cyberattacks, but standardization guidelines for developers in the automotive industry are struggling to follow.

The ISO 26262 “Road Vehicles – Functional Safety” standard was published in 2012 to give vehicle manufacturers a way to adopt functional safety best practices throughout the development cycle. ISO 26262 requires that any threat to functional safety be adequately addressed. It implicitly includes those relating to security threats, but it does not provide any explicit guidance relating to cybersecurity. At the time of publication of ISO 26262, this was perhaps to be expected.

But the rate of change in the industry meant that when it was released four years later, SAE J3061 Cybersecurity Guide for Cyber-Physical Vehicle Systems was eagerly awaited. However, SAE J3061 was always intended as a stopgap, allowing time for the development of a more formal standard to address the issue more broadly. So SAE J3061 was replaced by ISO/SAE 21434:2021 in 2021.

ISO/SAE 21434 can be seen as complementary to ISO 26262 in that it provides guidance on development best practices from a cybersecurity perspective, just as ISO 26262 provides guidance on development practices. to ensure functional safety. At the same time, the new UNECE WP.29 R155 regulation for Cyber ​​Security Management System (CSMS) was adopted by the UNECE World Forum for Harmonization of Vehicle Regulations, making compliance mandatory for vehicle approval from June 2022. ISO/SAE 21434 is cited in R155 as an appropriate benchmark for cybersecurity skills.

So what does ISO/SAE 21434 mean for automotive development teams? The first part of this series of articles explains the details and implications of changing standards for automotive developers. The second part of the series will review the stages of a traditional V-model of development to explain how the principles set out by the standard can be applied to each stage.

A missed opportunity or increased flexibility?

While ISO/SAE 21434 supersedes J3061, the two documents differ in style: SAE J3061 ties safety and security processes together, while ISO/SAE 21434 separates them. Despite this distinction, ISO 26262 remains closely linked to the new standard and is referenced to it several times.

But ISO/SAE 21434 is seen by many as a missed opportunity.

A simple page count comparison suggests why. ISO 26262 has 12 parts, many of which have a direct impact on how compliant application software is developed. Part 6 alone, titled “Product development at the software level”, has 66 pages. In contrast, the entire ISO/SAE 21434 standard is 81 pages long and its scope extends to all aspects of electrical and electronic systems in road vehicles throughout the supply chain.

Developers can expect to find details of what needs to be achieved in ISO 26262 from a functional safety perspective, and ISO/SAE 21434 from a cybersecurity perspective. However, while ISO 26262 also presents details on exactly how to achieve its objectives, ISO/SAE 21434 does not.

ISO/SAE 21434’s inability to provide detailed guidance on how to achieve its objectives means that, from a software perspective, the standard does little more than ratify the document it supersedes. However, ISO/SAE 21434, and SAE J3061 before it, presents a worthy set of goals for software developers. From an optimistic point of view, the lack of details provides flexibility in how they are achieved.

Beyond Functional Safety

Despite the obvious synergy between ISO/SAE 21434 and ISO 26262, it is important to note that ISO/SAE 21434 does more than just formalize the need to include safety considerations in functional safety requirements. The importance of malicious intent in defining these requirements should not be underestimated.

Perhaps less obviously, introducing cybersecurity into a formal ISO 26262-style development process involves the use of equally rigorous techniques in applications that are not security-critical, and perhaps in organizations having no prior obligation to apply them. ISO/SAE 21434 deals with privacy in general and personally identifiable information (PII) in particular, and highlights the risks to both as being no less significant than the potential compromise of security systems.

Concretely, ISO 26262-like rigor is now required in the defense of personal data accessible via a connected car, including personal contacts, browser and location history, as well as credit card information and other information. financial.

ISO 26262, HARA and ASIL

The Hazard Analysis and Risk Assessment (HARA) required by ISO 26262:3 is used to identify malfunctions that could lead to hazards, to assess the risks of relevant hazards and to formulate safety objectives. 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 commensurate levels of effort to prevent dangerous events.

Each hazardous event is assigned a severity classification (S0-S3), an exposure classification (E0-E4) and a controllability classification (C0-C3). Higher numerical values ​​represent the least desirable characteristic in each case. The likelihood of harm is a combination of these factors, and this is reflected in the assigned ASIL.

ISO 26262 requires the level of exertion to be proportional to ASIL, not just severity. Even if a hazardous event is potentially fatal, it is not necessary to invest heavily in its prevention if it is extremely unlikely to occur.

Table 1 This is how “Software Integration Verification Methods” are specified by Table 10 of 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 for determining the most critical exposures while considering mitigating controls and accepted risk levels.

Calculating a “risk value” is similar to calculating an ASIL in that it takes into account the severity and likelihood of a successful attack, based on several factors:

  • Identification of the threat scenario
  • Impact
  • Path of attack
  • Attack feasibility for this path

“Impact ratings” for safety damage are taken from ISO 26262 definitions. They use the same impact metric used to determine ISO 26262 ASIL ratings. This principle is extended in ISO/SAE 21434 to address threats that can cause financial damage, operational damage, and privacy breaches.

Table 2 Abbreviated descriptions of impact ratings are taken from tables F.1 to F.4 inclusive of ISO/SAE 21434. Source: LDRA

Not only does ISO/SAE 21434 bring formal development to less safety-critical areas, it also extends the scope of that development well beyond the traditional project development lifecycle. Examples include establishing an incident response process to deal with vulnerabilities that become apparent in the field, consideration of over-the-air (OTA) updates, and cybersecurity considerations when a vehicle changes ownership .

Looking for an ASIL equivalent

ISO/SAE 21434 is less prescriptive of the TARA approach to be adopted than ISO 26262 HARA. More importantly, it stops before setting an ASIL equivalent. Unlike ISO 26262, ISO/SAE 21434 does not match the level of validation and verification effort to the criticality of the software being developed.

However, these notations lend themselves to the mapping of ASIL categories presented in the ISO 26262 standard.

Table 3 shows a reproduction of the example table overlaid with risk values, with numerical values ​​depending on the calculation approach. If this represents best practice when security is critical, it seems logical that the same approach would also be appropriate when the application is critical in other respects.

Table 3 The overlay of ISO/SAE 21434 criticality groups on “Software integration verification methods” is specified in Table 10 of ISO 26262-6:2018. Source: LDRA

Cybersecurity ISO/SAE 21434 in tandem with ISO 26262

SAE J3061 has explicitly linked its development process to that of ISO 26262. Although ISO/SAE 21434 is less closely linked, it makes many references to ISO 26262 and there will be many instances where two standards will apply. Indeed, standards lend themselves to the integration of the two at every stage of the product lifecycle, even to the extent that the same test team might be deployed to fulfill both roles.

For example, it is possible to perform hazard analysis, security risk assessment, threat analysis and security risk assessment simultaneously using a single integrated model and method.

Even where there are no security considerations, adopting the proven best practices of ISO 26262 to meet the high-level requirements of ISO/SAE 21434 is a pragmatic approach that allows development teams to apply known tools and techniques that are probably already available to them.

Editor’s note: Part two of this automotive cybersecurity article series takes a modified V-model approach to illustrate the relationships between the ISO/SAE 21434 sections that have the most impact on software development, and explains in more detail how the principles set out in the standard can be applied. .

Marc Pitchfordtechnical specialist at LDRA Software Technology, has worked with development teams seeking 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.

Related content