fbpx

Status: Working Draft
Published Date: Expected 2020
Region: Global
Document: Link

Background

In September 2016, the ISO and the SAE began a cooperation to develop joint standards related to automotive and ITS, with the first joint publication intended to govern automotive cybersecurity. The current working draft is the result of 2 years of drafting by 82 contributors, including OEMs, Tier Ones, semiconductor vendors, cybersecurity specialist companies, academic institutions, and others. The standard will help define cybersecurity management and risk-oriented approach to robustly define cybersecurity requirements for E/E systems, hardware and software components, and a life cycle management procedure, including cybersecurity monitoring and the handling of vulnerabilities after the vehicle has been deployed.

Summary

The goal of the standard is to manage cybersecurity threats of electrical and electronic systems in road vehicles, similar to how ISO 26262 manages functional safety requirements.

General considerations are tackled in a first instance, which provides an overview of the vehicle ecosystem, threat landscape and vulnerable ecosystem interfaces, and the reasoning behind the need for cybersecurity implementation. The standard is then split into a number of sections, which are reviewed briefly below:

Management of cybersecurity: The objectives and the goals of cybersecurity management are provided in detail in this section. The idea is that cybersecurity becomes a mandatory requirement across the organizations involved in the lifecycle of road vehicles. This includes various steps such as defining objectives and a strategy (through governance), creating rules and processes to implement a cybersecurity strategy (including for the identification of vulnerabilities), assigning responsibilities, providing resources, fostering a cybersecurity culture on a continuous basis, managing competencies and awareness, applying continuous improvement, performing audits, and managing interactions between processes.

The section goes into further detail regarding cybersecurity management specifically during the concept phase and product development, as well as during production, operations, and maintenance. A final subsection focuses on information collection and retention of the processes pertaining to cybersecurity management.

Risk assessment methods: This section provides the steps for performing a comprehensive risk assessment. It beings with identifying the assets and analyzing the associated threats via damage scenarios. The associated impact of road users is determined (impact assessment). The following steps include vulnerability analysis and attack analysis which will form part of the attack feasibility assessment. All these are provided as inputs to the risk calculation (risk assessment), which then feeds into selecting the appropriate treatment category options to address that risk (risk treatment).

Concept phase: The objective of this section is to determine the exposure to cybersecurity risks during the concept phase of a specific vehicle item, that is to identify threats, assumptions and cybersecurity development policies, to evaluate the risk of threats, and to define the process rigor for cybersecurity, to select/deter- mine the risk treatment, and to define the goals which will reduce the threat of risks. This includes tailoring those cybersecurity activities in case that item is later reused.

Product development: This section provides guidance on specifying cybersecurity requirements for system, hardware and software design.
The functionalities, dependencies, constraints, and properties of system components and interfaces have to align to specific cybersecurity requirements. The idea is to verify that the system design and cybersecurity specification comply with the cybersecurity concept.

Additional objectives include analyzing the system design for vulnerabilities, verifying proper implementation in the integrated system, and demonstrating that the system can subsequently fulfill the cybersecurity goals.

The hardware development phase includes planning cybersecurity process tasks, deriving hardware-level cybersecurity requirements, designing in accordance with those requirements and with the system design, identifying vulnerabilities, realizing appropriate controls against those vulnerabilities, and finally confirming those requirements and design are properly implemented.

The software development phase includes similar steps: planning the cybersecurity process tasks, specifying and verifying cybersecurity requirements, developing and specifying software architectural design to realize the cybersecurity specifications, and in accordance with both the architectural design, implementing and demonstrating fulfillment of cybersecurity requirements.

Verification and validation follow the development phases and sets requirements to ensure that the product being developed is per the stated cybersecurity requirements and design specifications, and satisfies set cybersecurity goals. These include planning, reporting and results tracking, as well as handling findings.

A final subsection deals with specifying releases for post-development criteria (production and post-production) once system development is completed and provides evidence of compliance with all the prerequisites for serial production (after successful completion of prior cybersecurity activities).

Production, operations, and maintenance: The objectives in this section are to first ensure the cybersecurity specifications from development are implemented in the produced item and to further implement processes to prevent the introduction of additional cybersecurity processes caused by production.

Next, the section defines cybersecurity monitoring requirements for gathering and reviewing relevant cybersecurity information. This informs the following section on vulnerability handling and incident response, which provides guidance on how to assess relevant cybersecurity events and how to handle incidents.

The final subsection looks at updates and provides information on how to define the basic cybersecurity requirements and attributes of updates, as well as how to securely apply them.

Supporting processes: This last section details operational management systems to support cybersecurity activities, which will define the interactions, dependencies, and responsibilities between customers and suppliers, as well as provide evidence that the tools used during the lifecycle do not adversely affect cybersecurity.

A number of Annexes are included, and notably, Annex E which offers a Cybersecurity Assurance Level (CAL) classification scheme against which organizations can measure and communicate cybersecurity assurance requirements undertaken for an item. Essentially a CAL specifies a set of goal-based assurance requirements on the cybersecurity process, in terms of levels of rigor or effort necessary to provide confidence that the protection of the item’s assets is adequate.

Note

The design of ISO/SAE 21434 is highly similar to ISO 26262, instituting an organizational culture and management for cybersecurity, governing the concept phase, product development and lifecycle maintenance. The CALs are comparable to ASILs in that they aim to fulfill a similar function by allowing the level of cybersecurity process rigor associated with systems to be assigned to supporting hardware and software components, and facilitating clear communication on this cybersecurity process rigor across the supply chain.

The CAL calculated at a system level is then assigned to the component hardware and software elements, ensuring that these elements are designed with appropriate rigor to mitigate the cybersecurity risk. This risk analysis method allows for a single standard to be applied to vehicles containing systems and components of varied criticality—just as in ISO 26262.
The ISO/SAE 21434 standard is intended to focus and harmonize industry efforts and attention toward cybersecurity, and to serve as a state-of-the-art guideline to which regulators and governments can refer.

Many key aspects have yet to be codified and made public, in particular the risk assessment methodology that will underpin the CAL calculation, and the hardware and software measures that will be recommended to enforce the assurance level/rigor derived from the system-level CAL. However, the dynamic scope of the standard will surely mandate the use of IDS and OTA updates to remedy emerging vulnerabilities.

Recent Posts
Contact Us

For a sense of how easy it will be to put ARGUS IPS solutions in your current and future production-line and hearing more about our unique technology, please fill in the form below.

Argus Automotive Cyber Security RegulationsArgus Automotive Cyber Security Regulations