The main purpose of ISO/SAE 21434 standard is to address the cybersecurity perspective in E/E engineering within road vehicles putting the cybersecurity risk management at the center and throughout the whole life cycle of the product.
In fact, this is the paradigm change that comes with this standard. The complete life cycle is susceptible to introduce vulnerabilities into the product. Therefore, cybersecurity measures are defined to implement at each phase.
Another purpose is to create a common understanding and culture of cybersecurity by providing vocabulary, objectives, requirements and guidelines. These enable organisations to define cybersecurity policies and processes, manage cybersecurity risks, foster a cybersecurity culture and implement a cybersecurity management system.
The target of the standard is the family of road vehicles. This is the name of the ISO technical committee TC-22 and it covers motorcycles, cars, articulated goods vehicles, trucks etc. The standard is appliable to all E/E sytems developed or “modified” after the release of the standard. Well, this is a pretty broad scope as a simple SW change can also be considered as a modification.
ISO/SAE 21434 doesn’t prescribe any specific technology or technical solutions. That means, it is the responsibility of the OEMs and suppliers to develop their own solutions to mitigate the cybersecurity risks. The standard doesn’t allocate the functionalities to different items. That means, the standard is written from the perspective of a single item which can be the E/E (Electric and electronic) architecture or the set of cybersecurity cases of the cybersecurity relevant E/E units in the vehicle.
The external systems like EV chargers might have a cybersecurity aspect but they are not in the scope of this standard. However, you may see EV chargers in the market that have ISO certification. This is perfectly ok because ISO/SAE 21434 sets the cybersecurity engineering requirements and all companies are free to obtain a certification for their organisation and products.
A brief description of clauses is presented below. The order of the clauses in the standard don’t necessarily prescribe an execution sequence except from 9 to 13. Each clause has its own applicability. For example, Clause 6 describes the cybersecurity management system (CSMS) and it is defined at organisation level. It is applicable to all projects so it is virtually project independent.
Clause 8 describes the continuous activities in the project, like vulnerability analysis that are performed at different levels. That's why it is applicable to all phases of the project lifecycle.
Clause 15 describes the formal threat analysis and risk assessment methods so this clause is also project independent. However, clause 9 is project dependent because it describes how to create the cybersecurity concept of the project which includes TARA (Threat Analysis and Risk Assessment).
It is important to understand the purpose and the applicability of each clause in the ISO standard. That way, the cybersecurity activities that are required for compliance will be planned accurately and in perfect synchronization with project activities.
Terms and definitions are very important in ISO standards and ISO maintains a terminology database to ensure a common understanding. Therefore, this clause should be consulted to understand the terms before searching in web. For example, if we look up the word vulnerability we will see different definitions from different sources, however, they all mean that it is a weakness that can be exploited.
The flowchart below shows how item, its components and other cybersecurity related terms are related to each other. Many levels are embedded in one image so that we can see their relations between them.
The item sits at the top, the function level. Infotainment, engine, break, ADAS, charging and many other functions can be considered as items that are embodied by an ECU (Electronic Control Unit) in a vehicle. The items are composed of sub-items which are generally software and hardware components. These components sit at architecture level, however, this architecture should not be confounded with vehicle electronic architecture.
The software and hardware modules sit at implementation level. The typical V diagram from ASPICE is placed onto the scheme. The clause 9 which is conception and clause 11 which is validation of the ISO/SAE 21434 standard are applied at item level. Clause 10, which comprises development and testing is applied at architecture and implementation levels. The testing however includes unit, integration and other types of testing depending on the complexity of the architecture.
To enable cybersecurity engineering, the organisation institutes and maintains cybersecurity governance and cybersecurity culture, including cybersecurity awareness management, competence management and continuous improvement. This involves specifying organisational rules and processes that shall be independently audited.
To support cybersecurity engineering, the organisation implements management systems for cybersecurity including managing tools and applying a quality management system.
There is a certain number of activities that needs to be executed in parallel to obtain compliance with ISO/SAE 21434 standard. A cybersecurity organisation must be created first and sufficient resource be allocated for the team to start working. Then, updating the organisation level documents like policies, processes and rules should start in parallel with training of all employees in organisation hierarchy. Updating management systems or creating them from scratch is also necessary.
Once the organisation have the sufficient confidence to have accomplished all tasks and have met all objectives, an independent audit should be performed. It is highly recommended to have an initial gap analysis to be able to interpret the results of the audit accurately. A simple example of the CSMS organisation is given below.
Project dependent cybersecurity management includes the activities such as planning, tailoring, reuse, cybersecurity case, cybersecurity assessment etc. These shall be executed for each project within the organisation, however reuse between similar projects is encouraged to save resources.
Tailoring principles shall be defined and followed to ensure that what is planned at the beginning is correctly reported at the end of the project. Cybersecurity case, cybersecurity assessment and release for post-development are performed at the late phases of development and in post-development.
It is strongly recommended to plan multiple instances of the cybersecurity activities to allow for corrective action and follow-up.
Cybersecurity plan lies at the center of the activities, and it is explained in detail in the standard with several requirements. It is followed by the appropriate person or team in the cybersecurity project organisation until the end of the project and an assessment report is created based on the evidences gathered. The success of the cybersecurity project is dependent of the quality and the follow-up of the cybersecurity plan. It is highly recommended to assign an experienced Cybersecurity Compliance Manager to this task who knows ISO/SAE 21434 standard and UN R155 regulation by heart.
This clause applies if responsibilities for cybersecurity activities for an item or component are distributed. That means, certain cybersecurity activities which are deemed necessary, are performed by collaborative efforts between an OEM and its suppliers or between suppliers. It is remarkable that a dedicated clause is created in the standard. This shows how important it is to document and trace the cybersecurity activities in the whole supply chain.
The distributed activities might be a big headache at to the end of the project if an effective supplier follow-up is not done. The cybersecurity compliance manager should be in close communication with the project manager and hold dedicated meetings with the suppliers if necessary. It is not uncommon that cybersecurity topics are lost in routine project communications.
Below a flowchart is given that shows the OEM and the Tiers. A written agreement, in other words a cybersecurity interface agreement (CIS), must be signed between each stakeholder. In this figure we need 5 interface agreements in total.
Continual cybersecurity activities are performed during all phases of the lifecycle and can be done outside of a specific project. They start with monitoring and end with management of vulnerabilities that are identified. This is performed in a continuous fashion and is not interrupted by the project planning.
Four main activities are defined as seen in the figure below.
This clause covers the cybersecurity conception of the item. Please revisit Clause 4 to see what the item corresponds to.
Cybersecurity conception of a particular project is a highly technical activity which is not described in this standard. A formal process is described on how the conception should take place to guarantee that the cybersecurity concept integrity is preserved from the definition of the item down to the cybersecurity requirements.
This clause also includes the definition of the cybersecurity goals for the item which might be considered as the top-level cybersecurity requirements. Refer to Clause 15, Risk Assessment and Threat Analysis to learn more about on how to formally create goals. In addition to goals, cybersecurity claims are also explained which are the statements about the risks that justify a retention, transfer or monitoring.
Goals are directly linked with high level risks that must be reduced but claims don’t address the implementation of a cybersecurity measure to mitigate the risk.
The work products of this clause are commonly covered in one TARA. However, this is not an obligation of the standard. A format is not mandated. A dedicated tool might be used for the TARA as well as any tabular tool.
The figure below briefly depicts what is mentioned in this clause. On the right you might see the relation between Clause 9 and Clause 15. As previously stated, the formal derivation of the goals is explained in Clause15.
This clause describes the specification of the cybersecurity requirements, architectural design and verification activities at unit and at architecture level. It must be always kept in mind that every project has its own characteristics. There is no solution that fits all. In addition, development of a product might be shared between several stakeholders which again highlights the importance of Clause 7 Distributed Activities.
The main objectives of this clause are obtaining the good set of cybersecurity specifications at first, then developing the HW and SW architecture based on these specifications. Before proceeding to the implementation, we should ensure that the specifications cover the cybersecurity concept which is developed in previous Clause and there are no vulnerabilities at architecture level. Otherwise, it might be too costly to go back and modify the design. Once the architecture is approved, we can go for the implementation and verification.
ISO/SAE 21434 provides considerable flexibility to meet the cybersecurity objectives. The activities and their sequence of execution are described without mandating any specific tooling or method. However, examples are given to guide the readers like the usage of coding rules in SW or verification methods for example.
A simple V diagram is also provided below that shows the main activities only. It doesn’t differentiate between System, HW or SW level development. It reflects the order of the activités as written in the standard.
This clause describes activities for cybersecurity validation and it is performed against the cybersecurity goals and claims that are identified in concept phase in Clause 9. Please also refer to Clause 4 to see the mapping between Clause 9 and 11. Validation is done in the operational environment with the presence of other interacting systems. This can be on the vehicle but also on a test bench with E/E system architecture or an emulator. Validation must cover all goals and claims with the proper testing methods which should be identified in the validation plan.
Validation is not considered as a part of the development phase in ISO/SAE 21343. Therefore, the findings during the validation phase should be addressed carefully. The vulnerabilities which deem as high might be considered as a blocking point for the production. In this case, a deviation might be necessary depending on the project calendar if corrective action cannot be taken before production.
It is very unpleasant to discover vulnerabilities at this last stage before production, therefore the cybersecurity activities in concept and development phases should be executed with extreme care and no details should be missed.
Production covers the manufacturing and assembly of an item or component, including the vehicle level. A plan for production phase cybersecurity activities is created to ensure that cybersecurity requirements for post-development are applied to the item and vulnerabilities cannot be introduced during production. This plan is generally accompanied by checklists that facilitate the controls during production.
Production lines might sometimes be based on a very remote location where no permanent cybersecurity positions exist. This might create certain gaps like production process not being aligned with cybersecurity requirements and employees not being aware of cybersecurity processes. Therefore, it is vital to train all employees of the company to show that cybersecurity applies to all product lifecycle without exception and every employee must have the cybersecurity culture.
A very simple cybersecurity checklist example for production line is provided below to give an idea about the potential cybersecurity requirements for production and how they are verified.
This clause describes cybersecurity incident response and updates applicable to items during the serial life until the end of cybersecurity support. An organization normally has a vulnerability management system that takes actions whenever a new vulnerability arrives.
During the serial life, when analysis of incidents reveals new vulnerabilities, these are taken care of by the vulnerability management system as usual and remediation actions are launched. However, since the item is installed in vehicles that are already in use, the updates require a different process than mentioned in change management.
It is explained in this clause how the incident response in serial life should be handled by the organization and be documented. You might refer to the flowchart on the right to see certain steps. Please keep in mind that work products concerning updates are documented as work products of other clauses.
An organization can end the cybersecurity support for an item according to the initial agreements, but that item can still be in service. However, decommissioning is the end of life of the item. It is scrapped and not used anymore. Therefore, the end of cybersecurity support and decommissioning are handled differently.
An organization must inform its clients and sometimes the end users about the end of cybersecurity support according to a plan because this will mean that the item might have vulnerabilities in future that will not be managed anymore. It is like using an obsolete operating system which is no longer supported by its vendor. It might embody certain cybersecurity risks to continue using it, or some functionalities might get disabled to be able to keep it secure.
Decommissioning of an item might not be under the control of the organization therefore it is left out of the scope of ISO/SAE 21434. However, the cybersecurity assets of the item shall still be protected even when it is scrapped. Imagine a case where a vehicle becomes unusable due to an accident. The electronic units might be removed from the vehicle to be re-selled. In this case, personal information in these ECUs must not be recoverable even if a zeroizing procedure is not followed.
This clause describes a formal methodology to create the threat analysis and risk assessment, so called TARA. It is a project level deliverable and each project must have its own TARA, however similar projects might reuse up to certain extent. As shown in below figure, it should be delivered during the concept phase. If it is delayed and extended into development phase, costly reworks for the unhandled cybersecurity risks might emerge.
The main purpose of the TARA is to determine the extent to which a road user can be impacted by a threat scenario. This requires a formal and disciplined approach that is explained in this clause. Each sub-clause of this clause embodies a TARA activity and a corresponding deliverable which then collectively forms the TARA itself. TARA might be performed with basic office tools, however it is recommended to use a dedicated tool for better visibility, reuse and rework.
There is a comprehensive example of a TARA derivation in the Annex of the ISO/SAE 21434 standard for the interested readers.
Compliance with ISO/SAE 21434 require a rigorous and multidimensional approach that can only be achieved with the help of expert consultation service.
Rappel Cybersecurity provides end-to-end and scalable consultancy services that spans entire product lifecycle. Contact us for your needs regarding cybersecurity compliance at any dimension and phase.
See also our Use Case on ISO/SAE 21434 Compliance to see how ISO/SAE 21434 standard is applied.
Rappel Cybersecurity SAS
9 rue Galilée, 31700 Blagnac - France
info@rappel-cybersecurity.com
