Taking a Deep Dive into ISO/SAE21434

ISO/SAE21434 is the de facto standard for ensuring cybersecurity in automotive engineering. It provides a comprehensive framework for managing cybersecurity risks throughout the product development life cycle, from planning and design to production and beyond. In Chapter 4, we introduced the ISO/SAE 21434 standard and asserted the importance of taking a systematic approach to engineering secure products. In this chapter, we will delve deeper into the various aspects of this approach and demonstrate why it is crucial for overcoming the technical and process-related challenges of developing a secure product. Rather than focusing on each requirement of the standard, we will instead provide a detailed summary of the objectives of each clause, along with best practices and practical examples to achieve those objectives. We will cover a broad range of topics, including the following:

• Organizational cybersecurity management
• Acquisition and...

Notations

As you read this chapter, we expect that you will frequently be consulting the ISO/SAE 21434 standard to better understand a process requirement or work product. When doing so, it helps to understand a few conventions that the International Organization for Standardization (ISO) standard uses. First, the standard denotes mandatory process requirements with [RQ-xx-yy], where xx is the section number and yy is the requirement number within that section. Failure to meet a process requirement will trigger a finding by an auditor, so it is important to pay attention to those requirements. On the other hand, recommended practices are denoted as [RC-xx-yy]. It is good practice to include all the recommendations within your cybersecurity engineering process. Note that assessors will question why a recommendation was ignored by a specific project. [PM-xx-yy] refers to project management-related process statements that can be considered when you’re conforming to a specific standard...

At a glance – the ISO 21434 standard

The ultimate goal of any cybersecurity engineering management system is to produce secure systems that are suitable for their intended use. This is achieved by accurately identifying and assessing cybersecurity risks that emerge throughout the product life cycle and providing mechanisms to reduce those risks to reasonable levels. Without the structured systematic engineering approach, engineers resort to an ad hoc approach to identifying risks as they become known and applying cybersecurity controls using a mixture of security best practices and expert knowledge. This commonly leads to three outcomes:

• Certain risks remain unknown as the program cannot claim with certainty that all risk sources have been accounted for or that all technical risks have been analyzed
• Inadequate cybersecurity controls are chosen, leaving residual risk that is not quantified or understood
• Cybersecurity controls are over-engineered, resulting in...

Organizational cybersecurity management

Like any good cybersecurity engineering process, ISO21434 starts with organizational-level expectations. Because the cybersecurity engineering approach is about managing risk, and because different organizations have different risk appetites, discussions about cybersecurity must start at the management level of any organization. This is captured through the cybersecurity policy, which sets the stage for managing the cybersecurity risk by defining processes and responsibilities and allocating resources. Typically, organizations are used to the security policy, which governs information security management systems (ISMSs). This policy can be leveraged to expand existing policies to govern operational technology (OT) through the CSMS:

Figure 5.2 – Relationship between the Cybersecurity Policy and Cybersecurity Management System Process Handbook

Briefly, the policy is the basis for requiring a cybersecurity management...

Planning

It may sound trivial, but preparing a cybersecurity plan is essential to guide teams on the overall required work that must be executed before the product is considered ready for release. The cybersecurity plan covers assigning cybersecurity roles and responsibilities, cross-relations to the project and safety plans, the cybersecurity activities that must be completed, tailoring any activities, rationale for reuse, and handling off-the-shelf components, as well as components out of context. Teams can leverage existing project plans and simply extend them to account for cybersecurity activities. Alternatively, a dedicated cybersecurity plan can be prepared to capture the cybersecurity activities. ISO/SAE 21434 requires that at least the concept phase, product development phase, validation phase, and Threat Analysis and Risk Assessment (TARA) activities are described in the cybersecurity plan. However, it can be useful to cover additional aspects, such as planning cybersecurity...

Acquisition and integration of supplier components

You’ve started planning project and cybersecurity activities and in the process of doing so, you’ve identified several components that you must source for your project. You have two choices: use an off-the-shelf component that has been developed for a wide range of use cases without consideration of your exact product or work with a third party on developing or adapting an existing component to fit your product needs. In both cases, you want to demonstrate that your integrated product is still compliant with ISO/SAE 21434, regardless of the security maturity level of such components. By integrating a new component, you are essentially exposed to the inherited cybersecurity risks of that component. To address those risks, you have to achieve the following objectives:

• Identify ISO/SAE 21434 compliance gaps in the component
• Assess whether the component is capable of fulfilling your allocated cybersecurity requirements...

The concept phase

You are in the concept phase if you are developing a new vehicle function in an item or a single component out of context and need to determine the cybersecurity goals and requirements that must be fulfilled by your item or component. As shown in Figure 5.3, you are on the top left-hand side of the V-development cycle and your objective is to identify and treat the risks related to your system:

Figure 5.3 – V diagram with a security overlay

To achieve this objective, you must rely on the TARA methods shown in Figure 5.1. In practice, this process is initiated whenever a new security-relevant feature is introduced into the system to ensure that any new cybersecurity risk is understood and the overall cybersecurity concept is adapted to handle this new risk. This is known as the secure by design approach and it promises to reduce the likelihood of expensive rework when issues are discovered late in the product life cycle.

Before...

Design and implementation

Revisiting the V-diagram from Figure 5.3, we can see that requirements from the cybersecurity concept are further refined into cybersecurity specifications, which are allocated to the architecture and its sub-components. The primary objective of the cybersecurity specifications is to ensure that the architecture fulfills cybersecurity requirements from the higher level (such as the concept or parent components). Here, existing architectural specifications may be leveraged to satisfy this work product by simply providing traceability to the parent cybersecurity requirements.

Next, you must refine the high-level security requirements and architectural details into component-level security requirements and architectural fragments. The set of security requirements and architectural fragments at the component level comprise the component cybersecurity specification. Let’s assume that you are developing software that provides key management services to...

Verification testing

Cybersecurity tests that cover all hardware and software cybersecurity requirements are necessary to determine if the hardware and software design matches the cybersecurity specifications. Traceability between security requirements and security test cases is an essential step to ensure that the security measures are implemented as intended.

Similarly, formal verification techniques can be employed to verify that a specific hardware module can achieve its security objectives. At the unit level, ISO/SAE 21434 does not make specific process requirements, besides standard unit verification. Following a common quality management system will ensure that software units are tested with the right level of coverage before they’re integrated into larger components. A good practice for unit testing is to apply tests that exercise unit inputs, outputs, data, and control flows. The tests should cover error handling, fault injection, and methods for recovery to ensure...

Validation testing

ISO/SAE 21434 defines validation as an activity to be performed at the vehicle level. The objective of this clause is to validate that the cybersecurity goals that were identified during the concept phase have truly been fulfilled now that the item has been integrated within the actual vehicle environment. A component supplier may perform cybersecurity goal validation by applying tests to an environment that emulates the vehicle. While it is not mandatory to do so, it is generally a good practice to validate that the cybersecurity goals that you’ve placed on your product are satisfied before the OEM discovers that they aren’t. Validation is usually carried out through penetration testing by attempting to violate cybersecurity goals through the discovery of unknown vulnerabilities. An OEM who is trying to prioritize ECUs for penetration testing may want all externally facing ECUs, such as telematics or infotainment, to be tested by a third party before...

Product release

At this point, you’ve performed all the cybersecurity activities defined in your cybersecurity plan. Now, you are ready to make an official product release. But before doing so, you must prove that the work products have been prepared as per the organization’s CSMS and that the objectives of the CSMS have been fully achieved by your product. Gaining release approval requires that you prepare a cybersecurity case and undergo a cybersecurity assessment.

Cybersecurity case

Fast forwarding to the end of the project, the argument for why the product has achieved an adequate level of cybersecurity for its intended use case must be captured within the cybersecurity case. Typically, the case relies on two types of arguments: a process argument and a technical argument. The process argument demonstrates that the product has followed the cybersecurity engineering process and presents any deviations, along with arguments for why those deviation-based risks...

Production planning

You’ve released the product, indicating that it is ready for production. At this point, it has to be physically produced in a manufacturing environment. Whether you are producing a single component or a completely integrated vehicle, applying cybersecurity measures during the manufacturing process is an essential part of protecting the system during normal operation. The post-development requirements that were identified during the design phase are applied during the production phase by the system integrator. All such activities must be captured through a production plan. For example, an MCU/SoC vendor may specify procedures for injecting secret keys during manufacturing or locking specific interfaces. These procedures must be captured within the production plan of the chip vendor if they are responsible for performing this step or in the corresponding integrator’s plan, such as the ECU vendor. Similarly, post-development requirements related to the...

Operations and maintenance

You produced your part and it is now on the road. Congratulations – you can celebrate! Oh, but not so fast – your job of cyber defense has now transitioned to incident response. During the first three phases, as shown in Figure 5.7, we aimed to eliminate or reduce risks wherever possible. Where risks could not be reduced, a rationale was provided to either accept the risk or transfer it to other parties. Once in the operations and maintenance phase, our goal is to respond to emerging risks by following a process that identifies and addresses those risks effectively and promptly.

When the system is in its real environment, it is exposed to all the hypothetical threats that you considered during the concept and design phases. Now, attackers from all domains may be actively attempting to subvert your systems, and therefore planning to maintain cybersecurity during operational mode is a must. This can be achieved through two main methods:

...

End of life

The product has reached its end of life. Now, you can rest assured that no one can attack your system, right? No – even when you are ready to bury that product in its final resting place, you must take care of active assets that may be “exhumed” by a determined attacker who wishes to launch attacks against the other still alive and functioning products. For example, intellectual property, or user private data, may still be accessible in a vehicle that is slated for the junkyard. It is common for hobbyists to buy such parts on eBay, so products must have procedures for transitioning such systems into a secure state in which the assets cannot be exposed. This can be achieved by invoking routines that randomize secret keys or wipe user secrets. End-of-life preparation must also include change of ownership events. An OEM must provide procedures for the removal of personally identifiable information (PII) when a change of ownership occurs:

...

Summary

This chapter has provided a comprehensive overview of the ISO/SAE 21434 standard and the crucial role it plays in implementing a systematic cybersecurity engineering approach to developing automotive systems. By delving into the intricacies of the V-model life cycle stages and demonstrating how they are interdependent, we have highlighted the importance of following the secure-by-design approach at every step of the product engineering process. As we have shown, cybersecurity activities must be embedded into that process from start to finish, rather than being bolted on as an afterthought. Our discussion has emphasized the significance of understanding the various work products associated with the standard and how they can be leveraged to achieve a secure system. Furthermore, we have illustrated how the standard’s cybersecurity activities are relevant throughout the system’s lifespan, from planning to end of life.

In summary, the insights provided in this...