A Review of The ISO SAE CD 21434 Automotive Cybersecurity Standard 1
A Review of The ISO SAE CD 21434 Automotive Cybersecurity Standard 1
A Review of The ISO SAE CD 21434 Automotive Cybersecurity Standard 1
net/publication/343790924
CITATIONS READS
16 36,306
4 authors, including:
Omar Veledar
Beevadoo e.U.
39 PUBLICATIONS 820 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
All content following this page was uploaded by Georg Macher on 07 October 2020.
1 Introduction
Prior to the introduction of connectivity features and automated driving func-
tionalities, safety engineering was at the forefront of the automotive domain’s pri-
orities. Therefore, functional safety engineering methods and processes become
industry standard and critical part of the development. Today, many connected
and automated vehicles are available and connectivity features and informa-
tion sharing is increasingly used for additional vehicle, maintenance and traffic
safety features. This also increased the attractiveness of an attack on vehicles
by hackers with different motivations and thus introduces new risks for vehicle
cybersecurity.
Consequently, new challenges regarding automotive cybersecurity have emerged;
these in turn require additional efforts, engineering approaches and a very spe-
cific skill-set to deal with threats, risk management, secure design, awareness,
and cybersecurity measures over the whole lifecycle of the vehicle. Well aware of
this fact, the automotive industry has therefore taken high efforts in designing
and producing safe and secure connected and automated vehicles. As the domain
geared up for the cybersecurity challenges, they can leverage experiences from
many other domains, but nevertheless, must face several unique challenges.
Automotive industry has recognized these requirements and therefore in-
vested in the development of an industry standard to tackle automotive cyber-
security issues and protect their assets. The joint working group of the stan-
dardization organizations ISO and SAE has recently established a committee
draft of the ”ISO/SAE DIS 21434 Road Vehicles - Cybersecurity Engineering”
standard [11]. From the point of view of the automotive industry, this standard
achieves a common understanding of security by design in product development
and along the entire supply chain.
This document is a review of the available draft. The aim of this work is
to provide a position statement of the available draft, the presented analysis
methods and recommendations given in the standard.
We further provide an overview of recommendations of the ISO/SAE DIS
21434 Road Vehicles - Cybersecurity Engineering standard regarding the map-
ping of cybersecurity processes in context of established processes. The aim of
this work is to provide a basis for industry experts and especially researchers for
an initial review of the standard. Based on this work we intend to trigger discus-
sions on mapping and suggestions of best practices and methods for application
in the context of the standard.
The SAE J3061 [22] guideline is a predecessor of ISO/SAE 21434 and establishes
a set of high-level guiding principles for cybersecurity by:
The sections 1, 2, and 3 define the Scope of the norm and abbreviated terms
and definitions of terms used in the document on the first pages and are not
further detailed in this work, since already introduced in the introduction section
and more details do not provide additional added value.
3.2 ISO/SAE DIS 21434 Sections 4 - General considerations
This section informs of the vehicle ecosystem, organizational cybersecurity man-
agement and the related automotive lifecycle. In this context, automotive cyber-
security is defined, as concerning the protection of all assets in the vehicle against
cybersecurity threats. Automotive cybersecurity thus considers (a) threats to
the vehicle or its components and (b) threats to the ecosystem that compromise
assets outside of the vehicle but utilize vulnerabilities within the vehicle. Addi-
tionally, a general organizational overview of cybersecurity management and the
cybersecurity engineering lifecycle activities is provided.
This section of the norm determines if the system under development is cyber-
security relevant (paragraph 7.1), the item definition in cybersecurity context
(7.2), and the initiation of product development at concept phase (7.3). It also
includes, in alignment with the ISO 26262 approach, the definition of cybersecu-
rity goals (7.4) and a cybersecurity concept (7.5). Here the link to the SAHARA
method [16] shall be mentioned, which was one of the first methods to map the
safety HARA analysis on the cybersecurity challenge.
The determination of the cybersecurity relevance of an item is not specifically
mentioned, but Annex H provides a questionnaire that can be used to assess an
item. The item definition and mining of cybersecurity goals is very much aligned
with the safety-related approach known from ISO 26262 [10]. The cybersecurity
concept consists, again as known from ISO 26262, of the cybersecurity require-
ments that achieve the cybersecurity goals along with their allocation at the
appropriate level of architecture.
Also the cybersecurity concept contains a collection of cybersecurity re-
quirements which achieve the cybersecurity goals in implementation-independent
manner.
This section of the standard describes the remaining product development phases.
System development phase in paragraph 8.1, which can be linked to ISO 26262
part 4, Hardware development phase (paragraph 8.2), which can be linked to
ISO 26262 part 5, and Software development phase (paragraph 8.3), which can
be linked to ISO 26262 part 6. The additional paragraphs 8.4 is dealing with
verification and validation and 8.5 is dealing with post-development release. In
this context the work of Schmittner et al. [19] provides an FMEA application
for security topics, called FMVEA.
Also different risk assessment activity types are mentioned at various stages in
the system development but not detailed; at concept phase an assessment of the
threats for the item and its operational environment and at system development
phase an assessment of system specification vulnerabilities that cause residual
risk and an assessment of system integration vulnerabilities that cause residual
risk are done. Only mentioning, that system development shall be planned to
identify methods and measures for system development and the cybersecurity
activities.
Clause 8.1.4.2.2.3 mentions the following best practices of cybersecurity de-
sign:
Further, all physical and logical interfaces of hardware elements related to cy-
bersecurity, shall be identified by their purpose, usage and parameters. Since
interfaces are a potential entry point for cybersecurity attacks and should serve
as an input to the vulnerability analysis, also mentioned in [17].
For cybersecurity related software development, software cybersecurity re-
quirements have to be derived from the system cybersecurity requirements and
allocated to software modules. Software unit design specifications and their
implementations need to be verified statically and dynamically. Therefore, se-
cure design rules and coding guidelines, domain separation, self-protection, non-
bypass characteristics, and secure initialization definition shall be considered.
Paragraph 8.3.4.6.5 states design principles for software unit design and imple-
mentation at the source code level. Including also the properties of (a) correct
order of execution of subprograms and functions, (b) consistency of the inter-
faces, (c) correctness of data flow and control flow, (d) simplicity, readability and
comprehensibility, and (e) robustness, verifiability and suitability for software
modification. Regarding verification and validation most activities are described
in Annex F.
This section deals with production (paragraph 9.1) to ensure that the cyberse-
curity specifications from development are implemented in the produced item
and that the implement processes prevent the introduction of additional cyber-
security vulnerabilities. The cybersecurity monitoring (9.2), to have processes in
place for gathering relevant cybersecurity information and review of cybersecu-
rity information. Additionally, the handling and incident response (9.3) processes
to present how to handle cybersecurity events and updating of basic cybersecu-
rity requirements and capabilities are mentioned (9.4).
3.8 ISO/SAE DIS 21434 Sections 10 - Supporting processes
The processes described in this section shall support the cybersecurity activi-
ties and define interactions, dependencies and responsibilities between customers
and suppliers. This includes management systems (paragraph 10.2), distributed
cybersecurity activities (10.3) describing the relation between customer and sup-
pliers and tool management (10.4). Although, there are no standard tools for
development processes mentioned, a hint towards safety standards such as ISO
26262, IEC 61508, DO-178B is referred for tool qualification also of cybersecurity
tools.
4 Review
A challenging task of the ISO/SAE 21434 committee was to create a brand
new cybersecurity standard for the specifics of the automotive industry without
building upon a wider variety of previous standards. While SAE J3061 was an
important step forward, it was also recognized that this guidebook could not
fulfil a similar role as was intended by ISO/SAE 21434, alike to ISO 26262, for
the cybersecurity engineering of road-vehicles. The cybersecurity topic in the
automotive context is a very new one and the ambition to provide a framework
that includes requirements for cybersecurity process and a common language for
communicating and managing cybersecurity risk among stakeholders is aiming
high. The fact, that this standard is not prescribing specific technology or solu-
tions related to cybersecurity makes the descriptions of processes and approaches
additionally ambiguous.
Another stated high aim is to provide clear means to react to cybersecu-
rity threats consistently across global industry. That is rather challenging to
achieve.A prominent example, is the CAL, a counterpart to the Automotive
Safety Integrity Level (ASIL) from ISO 26262 during the risk assessment. The
CAL should have be used to define rigorous and applicable methods, but since
no consensus was found yet on how to determine and treat such a parameter,
this part has also been moved to the Annex only. Thus, a risk-oriented approach
for prioritization of actions and methodical elicitation of cybersecurity measures
is encouraged, but no further added value in terms of best practices or agreed
approaches is given.
In conclusion, the performed work is highly credited. The first common stan-
dard is an important and major step in the right direction, but in the context
of a standard not all answers to questions related to methods, guidelines and
best practices can (or are intended) to be provided. Thus, the aim, also of this
work, is to share a bases for discussion and exchange between industry experts
and researchers. Based on this, best practices and state-of-the-art methods for
application in the context of the standard can be mined.
5 Conclusion
The joint working group of the standardization organizations ISO and SAE has
recently established and published a draft of the ”ISO/SAE 21434 Road Vehi-
cles - Cybersecurity Engineering” standard. With this standard, the goal was to
provide a basis for an entire uniform cybersecurity development process in the
automotive industry. The relevant aspects for product definition, design, imple-
mentation and testing with this standard have been described, but no specific
implementation details or best practice approaches given.
Therefore, in this work we highlight the outcomes of this, currently draft stan-
dard and described how security standards, such as ISO/SAE 21434, are not the
silver-bullet answer to applications in practice. Their state is often fragmented,
or described at an abstract level for direct application in working environment
and is not intended to provide answers to questions related to methods, guide-
lines and best practices.
Thus, one aim of this work is to provide a basis for industry experts and
especially researchers for an initial review on the standard. The more important
goal was to trigger discussions on mapping and suggestions of best practices
and methods for application in the context of the standard and the domain.
This work solely provided also some additional related work and was intended
to provide a position statement for discussion, invite experts to get in contact
and set/improve the state-of-the-art.
Acknowledgments
This work is supported by the DRIV ES project. The Development and Research
on Innovative Vocational Educational Skills project (DRIV ES) is co-funded by
the Erasmus+ Programme of the European Union under the agreement 591988-
EPP-1-2017-1-CZ-EPPKA2-SSA-B.
References