Towards A Security Driven Automotive Development Lifecycle

Received: 19 May 2021 Revised: 14 September 2021 Accepted: 13 October 2021
DOI: 10.1002/smr.2407
SPECIAL ISSUE - METHODOLOGY PAPER
Towards a security-driven automotive development lifecycle
Jürgen Dobaj1,2 | Georg Macher1,2 | Damjan Ekert2 | Andreas Riel2,3 |

Richard Messnarz2
1
Institute of Technical Informatics, Graz
University of Technology, Graz, Austria Abstract
2
Development Department, ISCN GesmbH, Cybersecurity has become one of the most crucial challenges in the automotive
Graz, Austria
development lifecycle. The upcoming ISO/SAE 21434 standard provides only a
3
Grenoble INP, G-SCOP, CNRS, Grenoble Alps
University, Grenoble, France generic framework that is insufficient to derive concrete design methods. This article
proposes an actionable cybersecurity development lifecycle model that provides con-
Correspondence
Jürgen Dobaj, Institute of Technical crete action and work product guidance aligned with the ISO/SAE 21434 and Auto-
Informatics, Graz University of Technology, motive SPICE® extension for cybersecurity. The model has been inspired by action
Graz, Austria.
Email: juergen.dobaj@tugraz.at; research in “next” industry practice pilot projects, which ensures that it is actionable.
jdobaj@iscn.com It has been augmented by insights gained from literature research in cybersecurity
Funding information development for embedded systems. The proposed lifecycle model complements the
BLUEPRINT Project DRIVES, Grant/Award ISO/SAE 21434 standard and provides the basis for the company-specific process
Number: 591988-EPP-1-2017-1-CZ-EPPK
A2-SSA-B; H2020 Project TEACHING, Grant/ and practice specifications. It has been validated through the integration of
Award Number: 871385 cybersecurity-related aspects in an electric power steering system. A core character-
istic of the model is the central role of threat modeling, vulnerability analyses, and
cybersecurity requirements derivation on both system and subsystem levels. Without
concrete practice guidelines, the ISO/SAE 21434 is very difficult to understand and
apply at this stage. This contribution aims to fill this gap through a model inspired by
cutting-edge embedded cybersecurity practices interpreted for the current and near-
future automotive electronic architectures.
KEYWORDS
automotive SPICE, cybersecurity, development lifecycle model, ISO/SAE 21434, risk
assessment, threat modeling
1 | I N T RO DU CT I O N
1.1 | Context
As the automotive industry is experiencing a significant technological transformation to satisfy the needs of modern society, safety engineering
has supported the change and has been one of the top industry's priorities over the last decade. As a result, extensive safety engineering methods,
design approaches, and safety processes have been established.
The increasing connectivity and data sharing are driven by new features such as advanced driver assistance systems (ADAS), fleet manage-
ment systems, autonomous driving, and new mobility services. These features require integrated security solutions and architectures to mitigate
This is an open access article under the terms of the Creative Commons Attribution License, which permits use, distribution and reproduction in any medium,
provided the original work is properly cited.
© 2021 The Authors. Journal of Software: Evolution and Process published by John Wiley & Sons Ltd.
J Softw Evol Proc. 2021;e2407. wileyonlinelibrary.com/journal/smr 1 of 22

https://doi.org/10.1002/smr.2407
2 of 22 DOBAJ ET AL.
emerging security threats. Cybersecurity is thus becoming a cornerstone for the success of the automotive industry, alongside reliability and
safety. This is mirrored in recent cybersecurity regulations, requiring proof of cybersecurity to introduce vehicle types to the market (i.e., UNECE
Type Approval, particularly UNECE WP.29/R155 and UNECE WP.29/R156).
In that respect, the automotive industry has advanced the development and implementation of secure connected and autonomous vehicles.
Experience from other sectors has been leveraged in preparing for cybersecurity challenges. However, the sector is still facing several specific
challenges. Therefore, there is a considerable drive towards developing industry standards that address cybersecurity engineering to protect mod-
ern connected vehicles and the mobility infrastructure against cyberattacks.
1.2 | Problem statement
Although these standards do not offer details on the development and implementation of cybersecurity, they represent a framework that provides
general guidance. An upcoming security standard was developed with the understanding that for large parts of the cybersecurity process
activities, there is a lack of established state of the art. Therefore, only a framework can be given. This framework needs to be completed in the
future.
Although numerous publications address particular cybersecurity aspects in the automotive development lifecycle, the literature lacks consis-
tent and comprehensive approaches to combining and integrating cybersecurity engineering aspects into a comprehensive automotive reference
development lifecycle/process that extends beyond the concept phase.
1.3 | Objective
The research objective of this work is to propose a development lifecycle model (DLM) that is aligned with the automotive domain standards and
regulations applicable to the secure design of electronically controlled networked vehicle functions. The DLM shall focus on cybersecurity engi-
neering aspects of the various design phases (concept, HW/SW architecture, and HW/SW detailed design) within the automotive development
lifecycle.
1.4 | Methodology
Given the need for a high and immediate practical relevance, our research methodology is characterized by a tight action-research collaboration
with leading industry partners. In the course of this study, our methodology is to transfer tools and methods from traditionally IT-driven domains
by adapting them based on the most recent CPS cybersecurity research results. Our proposal of the threat modeling-driven security DLM is based
on two aspects. First, it is based on practical experience gained during the integration of secure system development practices into existing
workflows of industry partners, and second, on a profound theoretical background derived from the analysis of existing safety and security devel-
opment workflows and methods from a systems engineering perspective. At this stage, we validated the applicability and practical relevance of
our contributions using a widespread electronically controlled electric power steering system as a study example.
1.5 | Conclusion
The upcoming ISO/SAE 21434 standard and the Automotive SPICE for Cybersecurity extension are essential steps towards integrating cyberse-
curity in automotive development processes. However, concrete and practicable guidelines for secure systems development are missing yet. This
article addresses this gap and proposes an iterative threat-model-enabled DLM to systematically derive (detailed) design requirements and deci-
sions from top-level cybersecurity goals (CGs). The practical applicability of the DLM and its alignment to relevant standards and regulations is
demonstrated in the case study of an electric power steering system.
1.6 | Outline
The remainder of this paper is structured as follows. Section 2 gives an introduction to the automotive product and systems engineering lifecycle.
It provides an overview of relevant standards and regulations as well as todays and future vehicle architectures. At the end of Section 2, insights
into the usage of threat modeling for systematic threat analysis and risk assessment (TARA) are given. Section 3 discusses the relevant related
DOBAJ ET AL. 3 of 22
work. Section 4 describes the proposed threat-model-enabled DLM that is subsequently applied within a case study in Sections 5 and 6. Section 7
critically discusses the characteristics of the DLM, and finally, Section 8 concludes this work.
2 | B A CKG R O U N D
Vehicles are moving from isolated and mostly electro-mechanical systems towards connected computers with wheels.1 This trend is driven by the
wish of the automotive industry to offer innovative mobility services and further progress towards partially and fully automated vehicles. It is
expected that these goals are most probably only reachable with cooperative and automated vehicles.2,3 To achieve safe, automated, and inter-
acting vehicles, cybersecurity needs to be further improved.3,4
Recent evaluations and disclosures presented multiple vulnerabilities in almost all connected elements in current vehicles.5–7 With the nearly
112 million vehicles now connected around the world potentially at risk from some form of cyber threat, the global market for automotive cyber-
security is expected to exponentially grow to USD 759 million by 2023.8
Cybersecurity dramatically impacts the safety of automotive systems, their connected control functions, and vehicle fleet management.
Hence, holistic dependable system design is crucial for developing such intelligent connected systems. Both safety and security engineering focus
on system-wide features and must be integrated into the existing automotive process landscape and development lifecycle appropriately.4
2.1 | Automotive product and systems engineering lifecycle
The development lifecycle of electrical/electronic software-based systems in the automotive sector follows strictly defined processes to ensure
that products comply with the applicable standards and that those products also meet the required quality in time. To consistently measure,
compare, and improve the quality of these development processes, the domain-specific Automotive SPICE® (ASPICE) standard9 became de facto
mandatory for suppliers. Since then, sophisticated development processes and best practices have been established and continuously improved.
With the upcoming cybersecurity standards and regulations, these development processes must be adapted to meet the new engineering and
management requirements.
Figure 1 illustrates the automotive development and product lifecycle phases and the influence of the new cybersecurity regulations and
standards on these phases. The top part of Figure 1 shows project milestones typical in an automotive product lifecycle. Bellow that, the names
of the individual lifecycle phases of type approval and the product are shown. At the bottom, the related development activities and engineering
phases are illustrated.
The functional safety engineering activities focus on defects, failures, and errors, which could be foreseen at design time and on mathematical
models that rely on failure probabilities and system models. Therefore, the ISO 2626210 standard defines domain-specific processes and methods
F I G U R E 1 Automotive product and systems engineering lifecycle. (SoP: start of production, SoU: strat of use, EoP: end of production, EoSup:
end of support, EoUse: end of use)
for developing safety-critical embedded systems. The goals are to minimize systematic failures at development and to control random failures dur-
ing operation. Such safety standards rely on quality management at the development stage and systematic hazard identification and management
throughout the concept and development lifecycle phases.
In contrast, the security engineering activities expand beyond the concept and development phases to the decommissioning phase. The rele-
vant security standards (e.g., ISO/SAE 2143411) and regulations (e.g., UNECE WP.2912 R155 and R156) impose this expansion of engineering
activities demanding new activities such as the rigorous integration of security into system development, as well as the patching of security weak-
nesses and continuous system cybersecurity (incident) monitoring in the operations and maintenance phase.
Because the integration of cybersecurity activities affects all lifecycle phases, these activities must be appropriately integrated into the
established process landscape on the original equipment manufacturer (OEM) and supplier levels. To that aim, it is expected that the automotive
(software) development lifecycle will emerge towards a DevOps-oriented development process.13 DevOps is a model with its origin in the IT sec-
tor designed to support rapid response to any kind of software issue through continuous system monitoring and the rapid deployment of software
changes into the operational environment. The industry is already moving towards new development and operational models requiring the devel-
opment and integration of new engineering methods into the established lifecycle.
2.2 | Automotive cybersecurity regulations and standards
The automotive industry has made high investments and efforts in specifying regulations and standards to gear up cybersecurity challenges. The
combined working group of the International Organization for Standardization (ISO) and the Society of Automotive Engineers (SAE), that is, the
ISO/SAE standardization organizations, has established and published a draft international standard, the “ISO/SAE 21434 Road Vehicles - Cyber-
security Engineering” standard.11 This work is based on its predecessor guidelines, the SAE J3061,14 which established a set of high-level guiding
principles for cybersecurity. Due to the joint development of ISO/SAE 21434, this guideline was pulled from the market and will be reworked to
cover additional topics.
Related standards like the IEC 6244315 or the ISO 27000 series16 are not directly aimed at vehicle development. However, they are relevant
for production and back-end system development, becoming ever more critical for cloud-connected service infrastructure in the automotive
domain. In addition, SAE is working on a set of cybersecurity guidance, such as “SAE J3101 – Requirements for HW-protected security of ground
vehicle applications” and “SAE J3138 – Guidance for securing the DLC.”
On the other hand, ISO addresses specific automotive cybersecurity-related topics in standardization activities, like “ISO 20078 – Extended
vehicle web services” and “ISO 20828 – Security certificate management.”
In addition, there are national and international automotive cybersecurity regulations, such as the National Highway Traffic Safety Adminis-
tration (NHTSA) guidelines for cybersecurity best practices for modern vehicles. Security aspects for intelligent transport systems and connectiv-
ity are covered by the activities of the European Telecommunications Standards Institute (ETSI) and the International Telecommunication Union
(ITU), such as “ETSI EN 302 665”17 and “ETSI TS 102 893.”18 These works focus on vehicle-to-everything (V2X) communication, in-vehicle sys-
tems, and their security.
The United Nations Economic Commission for Europe (UNECE) WP29 working party started a task force on cybersecurity and software
updates. The task force provides recommendations for integrating and regulating cybersecurity and software updates for type approval of vehi-
cles.12
Besides the above initiatives, the concern of the International Electrotechnical Commission (IEC) TC65 on the impact of cybersecurity, reli-
ability, and related system properties on functional safety, has led to the creation of three IEC TC65 Ad-Hoc Groups (AHG): (a) IEC TC65 AHG1:
Framework towards coordinating safety, security (in industrial automation); (b) IEC TC65 AHG2: Reliability of Automation Devices and Systems;
and (c) IEC TC65 AHG3: Smart Manufacturing Information Models.
Finally, it should be noted that several OEM standards, such as BMW group standard GS 95014 or VW KGAS standard, state requirements
for cybersecurity (and functional safety) engineering.
2.3 | Vehicular electrical/electronic architectures
Automotive systems engineering and development typically follow a V-lifecycle model with a priori defined processes to meet the stringed quality
requirements imposed by standards and regulations. Such a V-model lifecycle is exemplified at the bottom of Figure 1 and starts with the system-
level analysis in the concept phase. At this stage, the system analysis focuses on vehicle-level functionality and the integration of items into the
vehicle infrastructure.
An item is an electronically controlled networked vehicle function such as steering, braking, and ADAS. Items are typically developed by sup-
pliers, while the OEM is responsible for the final integration of these items into the vehicle infrastructure. The vehicle infrastructure is also den-
oted as electrical/electronic architecture or E/E architecture.
Modern vehicle E/E architectures consist of a heterogeneous network comprised of more than a hundred electronic control units (ECUs) that
implement the electronically controlled networked vehicle functions. As exemplified in Figure 2, today's E/E architectures separate ECUs into sub-
network domains to address the complexity arising due to the distributed development of vehicle functions (i.e., items developed by suppliers)
and to address the demanding requirements on system safety and real-time onboard communication.19,20
However, more demanding vehicle functions such as ADAS and automated driving require cross-domain communication, making the inter-
connection of individual network domains necessary. To that aim, today's E/E architectures rely on a central gateway, as depicted in Figure 2. This
central gateway serves multiple purposes: (a) It provides cross-domain communication; (b) it strictly separates the safety-critical from the non-
safety-critical system functions and components; and (c) it establishes a transparent communication link to external vehicle functions and services,
as well as the onboard instruments, interior, and smart devices via the connectivity gateway. The central gateway and the connectivity gateway
are typically designed as embedded (Unix) server systems offering a broad range of (wireless) communication interfaces and services. By adding
adequate security measures, these gateways significantly contribute to the overall E/E architecture security and provide essential layers of
defense against both local and remote cyberattacks.
However, today's domain-centralized E/E architecture is expected to undergo a transition towards a vehicular centralized E/E architecture.19
This transition is driven by the major trends in the automotive sector, including automated driving, enhanced connectivity, new service models,
electrification, and the need to adequately address the new standards and regulations throughout the entire product lifecycle. In the future, high-
performance vehicle computers become central cornerstones of E/E architectures, on the one hand reducing the overall system complexity and
on the other hand acting as an enabler of new business and service models of the OEMs and suppliers.
Although the described gateway features and vehicular-central computers are among those providing the highest added value for the modern
vehicle consumer market,19 most automotive development still relates to electronically controlled networked vehicle functions. Such functions
include steering, braking, accelerating, and ADAS developed as items and implemented as electronically controlled networked vehicle functions
using ECUs. Hence, the authors decided to validate and demonstrate their contributions' applicability and practical relevance using a widespread
electronically controlled electric power steering system as a study example. In particular, Sections 5 and 6 demonstrate the standard-aligned steps
for developing a secure steering control unit (SCU), as shown on the top-left in Figure 2.
FIGURE 2 Modern vehicle E/E architecture

2.4 | Threat analysis and risk assessment
TARA identifies potential cybersecurity threats to the system under consideration (SUC) and assesses the risk associated with the identified
threats. With the new regulations and standards, the TARA process becomes an integral part of the cybersecurity development lifecycle in the
automotive domain. The TARA process can be divided into several steps: (a) threat identification, (b) risk analysis, (c) risk assessment, and (d) risk
treatment. Threat modeling is commonly used to support these steps.
2.4.1 | Introduction to threat modeling
The term “threat modeling” refers to the process of developing a representation of adversarial threats inherent to every cyber(-physical) system.
Such threats can target or affect various elements, including devices, applications, networks, (sub-)systems, mission or business functions, and the
cyber(-physical) system-of-systems implementing these functions. Also, entire organizations, regions, or critical infrastructure sectors can be
affected by cyber threats.
In short, cyber threats can emerge on various system levels affecting a variety of system functions and properties. The threat modeling pro-
cess can provide information on cybersecurity aspects in multiple ways to discover potential threats, vulnerabilities, and weaknesses in the SUC21:
• Risk management. Threat modeling is part of various risk management activities, including risk framing, analysis, assessment, and evaluation of
responses to risk. These activities are typically integrated into enterprise and project risk management. Risk management also considers non-
adversarial threats (e.g., hazards to systems from a functional safety point of view); however, the focus is on adversarial threat models in this
work.
• Cyber wargaming. Threat modeling helps to identify and develop threat scenarios and attack paths for cyber wargaming and penetration
testing.
• Technology profiling and foraging. Threat modeling supports the identification of threat scenarios and attack paths to evaluate and compare
the capabilities of technologies, products, and services. This comparison enables the characterization of technologies for proper threat mitiga-
tion, the identification of technology/research gaps, and the scouting of technologies at potential interest (i.e., technology foraging).
• Systems security engineering. Throughout the entire system development lifecycle, threat modeling can be used for requirements engineering,
system analysis, design, implementation, testing, and operations and maintenance. Threat modeling is particularly important for design analysis
and testing, where identified threat scenarios and attack scenarios are used to drive system design and the selection of mitigation measures, as
well as the testing of these measures. To this purpose, the threat modeling process can be tailored towards reflecting specific system aspects,
functions, and layers on various levels of detail. The tailoring of the threat modeling process for automotive system security engineering is a
particular focus of this work and is discusses subsequently.
• Security operations and analysis. Threat modeling can support searching for indicators or evidence of adversary activities to guide continuous
monitoring and security assessment facilitating the fast development and deployment of defense mechanisms into the operational environ-
ment (i.e., DevOps).
Summing up, threat modeling is a generic tool that can be used throughout the entire system/product lifecycle for various cybersecurity-
related activities, including design, development, analysis, operations, and maintenance. However, only specific aspects typically are of interest in
a particular lifecycle phase. Therefore, the threat modeling process must be tailored towards the specific needs of each lifecycle phase. We pro-
pose such tailoring for the automotive development lifecycle in Section 4. Before that, we describe the underlying principles for this tailoring in
the following.
2.4.2 | Approaches to threat modeling
Cybersecurity TARA can be approached from three different perspectives21–23 as depicted on the left-hand side in Figure 3:
• Asset-centric threat modeling first identifies assets of the SUC that could be affected by threats to characterize potential threats to the identi-
fied assets.
• System-centric threat modeling first models the SUC, including structure, data, scope, and the system environment, to determine what threats
are relevant in the modeled context.
FIGURE 3 Threat modeling approaches and their usage for modeling system security aspects
• Threat-centric threat modeling first models threats (e.g., adversary characteristics, behavior, threat events, attack patterns) to apply these
threats to the SUC.
Threat analysis, risk assessment, and vulnerability/weakness identification can be approached by threat modeling from one specific viewpoint
only. However, from a systems engineering perspective (and from the authors' practical experience during the action research), it is recommended
to approach threat modeling from multiple viewpoints in a combined manner to obtain a more holistic understanding of the SUC. The overlapping
areas of the Venn diagram (A, B, C, D) on the right-hand side of Figure 3 highlight the usefulness of such a combined approach, where different
threat model (TM) instances are combined to focus on specific cybersecurity activities and aspects:
A. Model instances of (sub-)systems help identify assets inside the system/project scope. Such assets can be virtual assets (e.g., data, crypto-
graphic key material, firmware, functions, system properties and behavior) and physical assets (e.g., sensors, actuators, devices, bus connec-
tions, networks) at any level of detail. Furthermore, system model instances can be analyzed for design weaknesses and vulnerabilities, which
allow evaluating specific design and technology decisions for their effectiveness and the derivation of tests for validating specific asset secu-
rity properties.
B. TM instances paint a picture of the adversary to expect, which provides guidance in the risk classification process to identify and describe
generic threats and attacks that affect asset properties and may lead to asset damage. Such a generic view is best suited when there is little
knowledge of system specifics, as in early development phases or black box penetration testing. In addition, the adversary picture supports
mitigation scoping in early-stage design phases.
C. Generic TM instances and threat descriptions become concrete and meaningful in the system/project scope if they are applied to the system
model instances. It can be evaluated (also in the context of the adversary characteristics) if a generic threat is plausibly applicable to the system
and shall therefore be mitigated. This viewpoint can support design decisions and the acceptance of certain cybersecurity risks at any level of
detail. In addition, it can be evaluated which (technical and design) mitigation measures in the system address a particular generic threat.
D. The overlapping area at the center combines all the above-described aspects to a set of plausible system-specific threats and attacks to sys-
tem assets of concern. The DLM proposed in Section 4 is targeted towards establishing such specific cybersecurity descriptions and system
understanding to facilitate proper system design and cybersecurity risk treatment at all details.
3 | R E LA T E D W O R K
In our previous work,24 we already reviewed available threat analysis methods and the recommendations of the SAE J3061 guidebook related to
TARA methods. In that work, we also provide an evaluation of available analysis methods and a review of recommended threat analysis methods.
In Macher et al.,25 we investigate systematic approaches to support the identification of trust boundaries and attack vectors for the safety- and
cybersecurity-related aspects of complex automotive systems. In Macher et al. and Riel et al.,4,26 we proposed a structured method to integrate
security and safety engineering in the existing Automotive SPICE context. In Schmittner et al.,13 we give a preliminary view of upcoming cyberse-
curity management aspects and highlight the need for new development lifecycle approaches to integrate cybersecurity activities into develop-
ment and operations properly. In Schmittner et al.,27 we presented a comprehensive overview of automotive cybersecurity standards and their
relations. In Dobaj et al.,28 we present a case study describing the systematic elicitation of traceable cybersecurity requirements.
These existing works provide the basic knowledge bricks and initial concepts to establish the proposed holistic DLM for the threat modeling-
driven security development lifecycle. Further extensions of our existing work are related to the elaborated action-research collaboration resulting
in a generic but industry-relevant use case of an electronically controlled electric power steering system.
Additional relevant related work focuses on specific parts of the DLM solely. As such, consider the previous works21,22,24,29–33 on methods
for systematic cybersecurity risk assessment and their conceptual differences. The other major group of publications focuses on practical
approaches for threat modeling and tool support for the automotive domain. These works include Hao and Han, Karahasanovic et al., and Ma and
Schmittner.34–36 Only a limited number of publications focus on more holistic views of engineering workflows, such as Martin et al., Kondeva
et al., and Amorim et al.37–39 These proposed workflows frequently consider the cooperation and combination of safety and security engineering
approaches.
In other domains, good cybersecurity practices and corresponding systematic ways have been analyzed by researchers. One of the domains
where cybersecurity is most relevant is the Industry 4.0 cyber-physical systems (CPSs) domain. Such CPSs are well suited for a transfer of lessons
learned because (a) these systems are most frequently originally not built with a cybersecurity focus, (b) these systems become more exposed by
higher network connectivity, and (c) attacks can jeopardize the performance and safety measures of such systems. In the work of Corallo,40 meth-
odologies to assess the impacts of cyber-attacks on Industry 4.0 manufacturing systems are discussed, and the work of Zografopoulos et al.41 pre-
sents a framework process for cybersecurity analyses for resilient and secure CPSs.
Thereat modeling approaches, described by Zalewski et al., Khan et al., and Jamil et al.,42–44 are elaborated and frequently discussed issues.
Nevertheless, lessons learned from these domains cannot directly be transferred. Instead, they require adaptation to the specifics of the automo-
tive domain where well-established quality and security-related development approaches, development interfaces, and regulatory constraints sig-
nificantly impact method usage and method adaptation.
Summing up, several works exist showing that cybersecurity threat modeling can be used to address one particular aspect of cybersecurity
TARA. However, the literature lacks consistent and comprehensive approaches to combine and integrate these individual aspects into a consistent
DLM for security-driven automotive CPS development. To address this gap, we propose a DLM for the automotive domain that tailors the threat
modeling process to support the cybersecurity engineering activities throughout the concept and development lifecycle phases for systematic
cybersecurity analysis, risk assessment, and requirements elicitation on all levels of detail.
4 | T H R E A T M O D E L I N G - D RI V E N D L M
This section introduces our proposed threat modeling-driven DLM for secure automotive CPS development. We first describe the DLM depicted
in Figure 4 from a high-level perspective. Second, we explain how threat modeling can be used throughout the development lifecycle to support
cybersecurity analysis and design. Third, we describe the elements and dependences of the DLM presented in detail.
The DLM shown in Figure 4 consists of elements (i.e., the gray and white boxes) and relationships (i.e., the connectors) that describe system
aspects and properties from different viewpoints. The depicted elements are, in essence, work products we propose to create during the develop-
ment lifecycle for systematic system analysis, system design, cybersecurity risk assessment, and requirements elicitation. Besides this, the work
products are intended to credibly demonstrate (e.g., in an assessment) that the relevant quality criteria defined in standards and regulations are
met. To this purpose, the relationships between the elements indicate how work products (i.e., the elements) can be used to build a structured
argument for cybersecurity TARA used in the subsequent requirements elicitation. In addition, the relationships indicate trace links that shall be
established between work products to implement a traceable and evidence-based ASPICE-compliant development process. The gray boxes in
Figure 4 indicate that those elements are covered by Figure 2 “Requirement generation for cybersecurity relevant items or components” of the
ISO/SAE 21434 standard.11 At the same time, the white boxes extend the framework provided by the standard and indicate elements proposed
by this work.
The DLM elements are clustered into two groups. First, into the elements that are of concern in the concept phase. These elements can be
found in the upper part of Figure 4, located inside the light gray area. Second, the elements outside the light gray area are of concern during
FIGURE 4 Development lifecycle model for cybersecurity requirements elicitation
detailed system design and analysis in the development phases. The individual models depict the essential elements of the proposed threat
modeling-driven DLM. These models are used to guide asset identification, risk framing, risk assessment, risk treatment selection (i.e., mitigation
scoping), and weakness analysis throughout the entire lifecycle at all levels of detail. The usage of these models in the automotive development
phases is explained in the following.
4.1 | Concept phase
At this stage, typically, only a little knowledge about system specifics is available. Thus, the focus in system conception is to understand the sys-
tem and the risks inherent to the system. To that aim, we propose to create models describing these high-level properties.
The system and its scope can be described by a high-level block diagram and technology stack representing the item from a functional per-
spective (i.e., similar to the item definition known from functional safety). These models can then be used as input to create cyber TMs reflecting
the high-level cybersecurity aspects of the system. The high-level functional models and the system-level TMs can be combined to identify sys-
tem assets and their associated high-level system-specific threats. With this specific set of assets and threats, plausible threat scenarios can be
identified that may lead to asset damages impacting item/product stakeholders.
Such damage scenarios are used in cybersecurity risk assessment32 as input for evidence-based risk classification. The feasibility of successful
attacks and the impact to stakeholders shall be combined to obtain a single risk value (i.e., the security level [SecL]) that describes the cybersecu-
rity risk inherent to a specific high-level asset/threat pair. Attack paths can be derived from the system and TMs at any level of detail to support
risk classification and the identification of plausible attacks.
The high-level risk mitigation measures or goals (commonly denoted as CGs) can be derived based on the classified asset risks. CGs define
the cybersecurity properties (i.e., integrity, availability, authenticity, and confidentiality) that shall be achieved for a specific asset. In the context
of automotive systems development, such CGs are translated into high-level cybersecurity system requirements.
4.2 | Development phases
The appropriate implementation of the high-level system requirements on the system architecture level (AL) and detailed design level is the focus
of the development phases. Various design decisions must be taken at this stage, and specific technologies and implementation techniques must
be selected. Distinguishing between alternatives requires a detailed understanding of the HW/SW components and their interactions. To that
purpose, the system-level TMs are refined by more detailed ones, that is, the level 1 + TMs, where higher numbers indicate a higher level of detail
in the model.
To reduce the complexity of the more detailed TM instances, we propose creating multiple individual TMs that address only specific product
lifecycle phases and software states. These detailed TMs can then be used to identify and describe data and functions critical to meeting and
implementing the cybersecurity properties assigned to assets (i.e., the CGs or high-level system requirements).
The identified cybersecurity critical data and functional elements can be described on any level of detail for both hardware and software
based on the specific design, technology, and implementation selected. The description of these elements allows to assign and capture the cyber-
security properties provided by specific assets and the overall system. Weaknesses and vulnerabilities in design and implementation can be identi-
fied by comparing the cybersecurity properties provided with those demanded by the CGs. On the one hand, the identified gaps guide proper
technology selection and, on the other hand, in eliciting cybersecurity requirements allocated to specific components.
5 | C O N CE P T P HA S E
In the following, we apply the DLM as proposed above to the SCU introduced in Section 2.3. Figure 5 gives an overview of the lifecycle steps an
SCU supplier can follow to develop a regulatory- and standard-aligned product. Figure 5 also shortly explains the work products the DLM pro-
poses to create during development.
FIGURE 5 Workflow implementing the development lifecycle model (DLM) for systematic cybersecurity development
Product development typically starts with reviewing the customer requirements (1.1) that specify specific functional and non-functional
demands on the product, including demands on cybersecurity. Hence, cybersecurity requirements arise from regulations and standards and cus-
tomer demands, such as the BMW group standard GS 95014 or VW KGAS standard.
These demands are often managed as cybersecurity customer requirements, including non-functional requirements related to specific devel-
opment processes to comply with automotive (cybersecurity) standards. Thus, not only the upcoming ISO/SAE 21434 standard and ASPICE but
in general also the customer requirements state that all parties involved in vehicle development shall conduct a security risk analysis of the system
under development (SUD) to identify potential threats to security-critical functions and components.
The security risk analysis is the primary focus of security-related development in the concept phase, which is split into two steps: (1) threat
analysis and (2) risk assessment, also well known as TARA.24 The TARA is one of the essential sources to establish a common understanding of
security between customer and supplier, considered especially important at the beginning of a project. In the remainder of this section, the con-
cept phase workflow steps depicted in the upper part of Figure 5 are described.
5.1 | Concept definition and threat analysis
Once the customer requirements are reviewed, the definition of the system-level (cybersecurity) concept starts. From a security perspective, the
concept development does not focus on developing certain electronically controlled networked vehicle functions; instead, the focus is on the
secure integration of these functions into the vehicle's E/E architecture. To that aim, a TARA is conducted to identify and estimate cybersecurity
risks inherent to the SUD. The TARA starts with identifying system assets that might be susceptible to cyber threats and therefore need
protection.
According to ISO/SAE 21434, an asset is an element of the SUD whose compromise of cybersecurity properties may damage an item's stake-
holder, that is, a person or organization affected by the damage. The DLM depicted in Figure 4 also includes these relationships between item,
stakeholder, and the damage resulting from threats and attacks.
5.1.1 | Selecting a threat modeling method
Various methods may help to identify the SUD's assets and threats, such as brainstorming variants, literature reviews, and asset databases. How-
ever, these unstructured variants suffer from a variety of problems,45 summarized as follows: By using limitless brainstorming techniques and
poorly defined exit criteria, the results of the threat and asset identification are not repeatable and heavily depend on the aptitudes and knowl-
edge of the participants. Therefore, structured and formal approaches shall be preferred for asset and threat identification.
The DLM proposed in this work is independent of the specific threat modeling approach used. All asset, threat, and system models described
by the DLM can be created using any method or tool appropriate. In this work, the STRIDE threat modeling approach46 is used to create formal
cyber TMs of the SUD at various levels of detail. Microsoft developed STRIDE for the analysis of IT systems. However, STRIDE can also be used
for CPS analysis and development due to its generic and modular nature. STRIDE-specific threat modeling methods and approaches, also in the
context of CPS development, are discussed in previous studies, for example,29,31,43,45 and previous works21,24,34,41,44,46,47 compare aspects and
characteristics of various threat modeling approaches and methods.
In this work, the choice of STRIDE is motivated by the following reasons:
A. it is a systematic model-based approach that can identify and analyze cybersecurity threats for each asset (in an automated fashion),
B. it is comprehensive and analyzes security properties such as authentication, integrity, non-repudiation, confidentiality, availability, and authori-
zation for each asset,
C. it enables the model-based (i.e., also automated) description of potential attack paths,
D. it supports the identification and description of threat scenarios,
E. it allows to clearly understand the impact of single asset vulnerabilities on the entire system or subsystem depending on the details modeled,
F. it uses dataflow diagrams for system modeling and analysis, which nicely complements the signal-flow analysis used for functional safety
analysis,26 and
G. it has a modular and hierarchical nature (i.e., a single threat or component can be described on any particular level of detail).
In addition, we show in Section 5.2 that STRIDE models can be tailored to provide traceable arguments and evidence for risk assessment and
classification, and subsequently, we show in Section 6.1 how STRIDE threat modeling can be used for systematic vulnerability analysis and
requirements elicitation during (detailed) HW/SW design.
Summing up, the STRIDE approach meets the requirements of a structured, formal, and scoped approach to threat and asset identification,
making it a precious tool to support the development of secure electronically controlled networked vehicle functions. Nevertheless, the DLM pro-
posed can be implemented using any method and combination of threat, system, and asset modeling methods.
5.1.2 | Define system-level concept (1.2)
Before one can actually start with threat modeling in the concept phase, various other representations of the system shall be created to establish
a proper and common system understanding and to obtain different viewpoints that support the subsequent threat and asset identification and
the identification and description of potential risks and their consequences in the context of the SUD.
Therefore, system conception should not start with threat modeling. Instead, we recommend first creating multiple types of system-level
models/diagrams describing various (non-security) aspects of the SUD. From a practical point of view, the following models have proven useful:
A. the item block diagram, as exemplified in Figure 6, defines the development scope and describes the CPS aspects of the SUD containing the
sensing, processing, and actuating elements,
B. the technology stack describes all layers of the SUD in a stacked/layered diagram containing the essential HW elements at the bottom and
SW applications and services on top; and
C. the critical function diagram clusters the essential system functions into its different criticality groups, which for a typical automotive product
would be, for example, safety-critical, quality-managed (QM), base software, and complex driver functions.
Because all the other diagrams/models shall be used as input to the threat modeling process, the final step of the concept definition should
be the definition of the system-level TM. The system-level (or level 0) TM should integrate and reflect all essential aspects covered by the previ-
ously created system-level models and diagrams from a cybersecurity perspective. Therefore, a system-level TM shall be derived from the
system-level concept diagrams.
5.1.3 | Identify system-level assets (1.3)
The analysis is focused on functional aspects and assets at this stage instead of more detailed technical or implementation aspects. Therefore, the
system-level TM is derived from the system-level concept models to represent all essential system-level functions, elements, and interfaces from
a security perspective. Therefore, models derived in such a manner contain only system-level assets of concern, as exemplified by the TM of the
SCU in Figure 7.
The TM in Figure 7 intentionally omits technical details. Only system functionality and interfaces of the item are included to ease the asset
identification. System-level assets are (a) all elements (also including data flows) inside the SCU trust boundary and (b) all the information
FIGURE 6 Item block diagram: Road wheel steering control unit (SCU)
FIGURE 7 Level 0 threat model of the steering control unit (SCU) (i.e., system level threat model)
(i.e., data flows) that crosses/intersects the SCU trust boundary. All other TM elements are not considered assets but support the subsequent risk
assessment through easing, e.g., attack path and damage description.
5.1.4 | Identify system-level threats (1.4)
Besides asset identification, TMs also provide systematic and comprehensive support for identifying the cybersecurity threats associated with
each asset. A threat may be a vulnerability in the system, a HW/SW bug, a weakness in the (concept) design, a person in/outside the company, or
anything similar. So basically, a threat can be any element representing a potential weakness or opportunity to attack the system.
As depicted in Figure 4 (1.4), a threat is always associated with an asset, and an asset may be susceptible to multiple threats. The goal of
threat identification is to identify all potential threats to assets. To this purpose, the STRIDE per-element or STRIDE per-interaction algorithm45
can be used for systematic (and automated) threat and asset pair identification.
The resulting sets of asset/threat pairs describe the threats to system assets on a very generic level. The traditional STRIDE approach can
only identify the threats in its acronym but cannot describe specific attack feasibilities and their plausibility. Therefore, the feasibility and plausibil-
ity of threats in the system context and the impact and risk of specific threats must be determined and assessed in the next phase.
Table 1 describes STRIDE threats and gives examples specific to automotive networked embedded systems.
Table 2 in Section 6.3 states security controls that can be implemented on various system levels to mitigate identified threats. In the following
sections, we describe how such controls can be systematically identified using threat modeling. These security controls can then be translated to
requirements and allocated to components of the SUD at any level of detail (see Figure 4 bottom-left label [2.1.6]).
5.2 | Risk assessment and requirements elicitation
The outcome of the previous step (1.4) is a set of asset/threat pairs. Each of these pairs consists of one specific asset and one threat associated
with this asset, although an asset may be associated with multiple threats. As a next step, for each asset/threat pair, the cybersecurity risk shall be
determined. To that aim, for each pair, plausible threat scenarios that lead to potential damage scenarios shall be described. The associated attack
paths, which can be derived from the system-level TM, technically describe how an attacker may compromise system asset cybersecurity proper-
ties. Based on these descriptions, the SecL can be derived. The SecL is a risk value indicating the attack feasibility and the extent to which a spe-
cific damage scenario can impact the item stakeholder(s). A stakeholder, according to ISO/SAE 21434 clause 8.1, is defined as a road user.
However, the standard allows the optional inclusion of additional stakeholders (e.g., supplier and OEM) into the risk assessment. The following
paragraphs describe aspects of risk determination.
TABLE 1 STRIDE threats and security properties affected by these threats
STRIDE threat Security property Threat example

Spoofing Authentication: Imitation of something/someone different An unauthorized ECU is playing the role of a different ECU
sending CAN-messages with a sender-ID of another ECU.
Tampering Integrity: Manipulation of data at rest (e.g., code) or in motion/ Without proper protection, CAN-messages can be intercepted,
transition (e.g., CAN-messages) changed, and resent.
Repudiation Non-Repudiation: Claim to have something (not) done An ECU could claim to have sent a message even this is not true
by, e.g., changing log files.
Information Confidentiality: Disclosure of information An ECU participates in a key-agreement protocol and leaks
Disclosure private key material.
Denial of Availability: Denial or degradation of service/function. An ECU floods the CAN bus with garbage or continuously holds
service the data lines “high”.
Abbreviation: ECU, electronic control unit.
TABLE 2 Examples for security controls on various levels (adapted from3)
Security
property Environmental-level security control Vehicle-level security control Component-level security control
Integrity Integrity management of access rights - Secure communication, TLS, IPsec, etc. - Access control
- Functional separation and trusted - Control flow integrity
execution of the control flow - Trust anchor
Authenticity - Access control to dev. and production - Message authentication codes etc. - Secure boot with a trust anchor, e.g.,
sites public key hash in OTP fuses
- Secure communications
Availability - Intrusion detection mechanisms to - Congestion control on gateways/ - Rate limiting on network interfaces
react to potential attacks routers - Deterministic scheduling
Confidentiality - Access control to documentation - Encryption of data in flight - Encryption of data at rest
- TLS, IPsec, etc. - Secure storage
5.2.1 | Determine SecL (1.6)
The SecL aims to indicate the accumulated risk of an attack's feasibility and the impact of a successful attack. Thus, the SecL is a compound risk
value derived from two individual risk values: the estimated threat level (TL) (1.5), determining the likelihood/feasibility of a successful attack;
and the estimated impact level (IL) (1.5), determining the attack's impact on the stakeholder(s). Typically, predefined rating schemata and risk
matrices are used to determine/assess individual and compound risk values. As shown in the gray area in Figure 4, an appropriate description of
stakeholder(s), assets, threats, threat scenarios, attack paths, and damage scenarios facilitate a consistent and repeatable determination of TLs
and ILs.
The authors recommend using a risk determination model based on attributes described by, for example, HEAVENS48 and by Annex G, H, I,
and J of ISO/SAE 21434. According to Annex G of ISO/SAE 21434, organizations may define and tailor the risk matrices individually for specific
needs and purposes. By sharing (and agreeing on) the determined risk values with the customer, a common understanding of security can and
should be established, which helps to guide the development focus from project start until the final product delivery. A description of the individ-
ual risk assessment steps can be found, for example, in Islam et al. and Khan et al.29,43
5.2.2 | Define CGs (1.7)
Based on the identified risks, for each asset/threat pair, appropriate CGs shall be defined. A CG describes a high-level cybersecurity property to
address a specific damage scenario by mitigating potential attack path(s) associated with the asset/threat pair and the threat scenario.
5.2.3 | Refine system-level concept and define system-level CS requirements (1.8)
Because CGs represent high-level requirements, these CGs shall be appropriately integrated into the development process as traceable system-
level requirements. To that aim, we propose that CGs (and their associated risks) shall be aligned with the customer and subsequently, for
example, treated similarly to customer requirements, as described at the beginning of Section 5. To ensure traceability, the CGs shall be linked to
cybersecurity customer requirements and then linked to and realized by system-level cybersecurity requirements and subrequirements, as shown
in Figure 4 label (1.7). The identified CGs and system-level requirements may lead to a refinement of the system-level concept.
6 | D E V E LO P M E NT P H A S E
The development lifecycle phase consists of two subsequent phases: (a) the SW/HW Architectural Design phase (2.1) and (b) the SW/HW Detailed
Design and Unit Construction phase (2.2), which are depicted on the lower half of Figure 5. The workflow steps are similar for both phases, how-
ever, with the difference that the work products' level of detail increases with the development progress.
What makes the development phases different from the concept phase is that the focus is no longer exclusively on the anticipation of threats
(i.e., causes), risks, and consequences to the stakeholder(s). Instead, the development phases primarily focus on identifying technical and design
weaknesses in the HW/SW architecture and the HW/SW detailed design. These weaknesses are typically denoted as vulnerabilities or weak-
nesses. The following steps explain the systematic identification of such vulnerabilities and weaknesses, denoted as vulnerability/weakness analy-
sis or assessment.
6.1 | Define HW/SW system architecture (2.1.1)
Before weaknesses within the architecture and the design can be identified, it is necessary to create/define the system architecture. Thus, as a
first step, the block diagrams, the technology stack, and the level 0 TMs shall be refined by appropriately integrating the identified system-level
(cybersecurity) requirements into the system (cybersecurity) concept. From this refined concept, the architectural design shall be derived.
6.1.1 | Item lifecycle and SW state analysis
In addition, we recommend considering the influence of the item lifecycle phases and the different HW/SW states on the SUD's (security) archi-
tecture and design, which will also be leveraged in Section 6.1 to obtain more structured and less complex TMs. Typical lifecycle modes of an item
and its SW states are depicted in Figure 8. The influence on architectural design is discussed next.
FIGURE 8 Item lifecycle phases and software state machine

From an overall project perspective, an item goes through three primary lifecycle phases: (a) engineering, where (non-)functional features are
designed, developed, and tested; (b) production, where the supplier prepares the item for shipment to the OEM, and the OEM integrates the item
into the vehicle and finally tailors/configures it for operation; and (c) operation, where the item controls a specific vehicle function or service and
updates are received in the workshop or over the air. The subsequent decommissioning phase is not considered relevant in the context of
this work.
As indicated by the arrow at the top in Figure 8, the item lifecycle phases place different requirements on the item features and functions,
which must be adequately supported by the development processes and the item HW and SW. So, from a lifecycle point of view, the item should
facilitate fast and easy engineering in engineering mode. During the supplier's end-of-line (EoL) process, the item is configured for production; that
is, all security features are activated, and private and public key material is securely stored on the item. Next, the item is shipped to the OEM. In
the OEM's EoL process, the item is integrated into the vehicle E/E architecture. The newest firmware and configuration are downloaded to the
item securely, and after this process, all features for vehicle operation are active.
The SW/HW architecture and design must support these modes so that the item is always properly working even if the set of active features
and interfaces change between the different modes. Hence, good configuration management and proper software support by the item are
required.
The transition between item lifecycle and operating modes is typically implemented through software state machines, as exemplified in the
lower part of Figure 8. The state machine depicts the services and states typical to automotive items. Different features and functions are active
or accessible in each state, and some of the services may also require security credentials for access.
The lifecycle and SW state aspects are essential to creating an adequate HW/SW architecture and design. Furthermore, the lifecycle and SW
state aspects will also be leveraged in the next section to systematically analyze and secure the system design.
6.2 | Threat and vulnerability analysis
This section describes a structured approach to systematically identify threats and vulnerabilities in the SUD's architecture and detailed design.
Similar to the concept phase, STRIDE threat modeling is used for asset and threat identification. However, newly identified asset/threat pairs are
not assessed for their potential risks. Instead, the asset/threat pairs shall be linked to their parent asset(s) or requirement(s) to automatically inher-
iting the SecL and CG already determined by the TARA. Only asset/threat pairs, which cannot be linked to existing parent assets, CGs, or cyberse-
curity requirements, shall be retrospectively integrated and assessed in the system-level TARA.
FIGURE 9 Level 1 threat model: Application startup

6.2.1 | Threat modeling strategies (2.1.2)
TMs created during the development phases can quickly grow into complex models that are hard to understand and no longer adequately analyz-
able by humans. Therefore, this work proposes the following strategies to keep complex TMs simple and to ensure traceability between TMs
without affecting their completeness and without requiring the support of model-based development frameworks:
1. On all levels, it is recommended to only add an element to a TM if the element contributes to identifying threats, weaknesses, or vulnerabilities
that otherwise could/would not be identifiable.
2. On the AL, it is recommended to create an AL TM (also denoted as level 1 TM*) for each identified SW state. The traceability between these
states and the TMs can be achieved using appropriately named TMs and trust boundaries, exemplified in Figure 9 and explained in the follow-
ing: A level 1 TM (a) shall be named similar to the state it is modeling. It shall contain (b) all its entry states and (c) all its exit states encapsulated
within individual trust boundaries named similar to the state. Furthermore, each TM shall include (d) all elements involved in the state transi-
tion and (e) all elements required to represent the functions and services available in the specific state modeled.
3. On the detailed design and unit construction level, the previously described strategies can be similarly applied to describe the substates of spe-
cific elements in more detail. Suppose the interaction with a stateless element should be modeled in more detail. In that case, it is rec-
ommended to create a level 2 (or higher) TM, which is (a) named similar to the element it intends to describe. The TM shall contain (b) all
elements that interact with the stateless element encapsulated within a trust boundary named similar to the parent-level threat model. Finally,
the TM shall contain (c) all elements required to describe the behavior of the stateless element.
6.2.2 | Level 1+ threat modeling (2.1.2)
Figure 9 shows the level 1 TM of the SCU's application startup state, introduced by the software state diagram in Figure 8. If we follow the above
strategies for TM creation, the TM is named, for example, application-startup.tm. The system boot entry state is shown on the left side encapsu-
lated into its appropriately named trust boundary, similar to the exit states on the right-hand side. Because the entry and exit states are modeled
in their separate TMs, the application-startup.tm shall omit the technical details regarding these states. The middle part of Figure 9 models the
state functions and transition between the entry states and the exit states through the processes and storage elements interacting with each
other and the external entities.
In essence, the TM describes that the application startup state follows the system boot state. The safety-critical part of the startup procedure
runs at safety core 1, starting and monitoring functions executed on the application cores. The startup application itself is split into two steps: the
startup procedure validating and initializing the system memory and the startup test checking the functionality of as well as the connectivity to
internal and external system elements required for proper SCU operation. Depending on the result of the startup test, a specific exit state is cho-
sen; for example, if all tests pass, the normal operation state is entered.
6.2.3 | Identify AL assets (2.1.2)
The asset identification in the development phase serves two purposes: (a) The anticipation of risk causes (i.e., threats) and their consequences to
stakeholder(s), which is addressed in the identify AL threats step (2.1.3) that is quite similar to the asset/threat pair identification in the concept
phase; and (b) the identification of vulnerabilities/weaknesses in the SUD's architecture and design addressed in the assign CS properties (2.1.3)
and identify AL design vulnerabilities (2.1.4) steps.
The asset identification in the concept phase intentionally omits technical details by focusing on the item interfaces, the information transmit-
ted through these interfaces, and the primary item functions. However, in the development phase, the technical aspects of the architecture and
the design are of utmost interest. Hence, this workflow step aims to identify functions and data required to realize (i.e., implement) the cybersecu-
rity properties of top-level functions (i.e., system-level requirements).
Therefore, the higher level TMs shall be refined by applying the prior discussed threat modeling strategies to reveal the technical aspects
required for the vulnerability analysis. These technical aspects (i.e., the AL assets) are the (a) cybersecurity-critical functions and (b) cybersecurity-
critical data of the SUD.
A cybersecurity-critical function is any processing element in a TM that implements or influences the cybersecurity property of the system or
asset. Similar to this, cybersecurity-critical data are any storage element (or storage content) in a TM that implements or influences the cybersecu-
rity property of the system or asset by, for example, changing the behavior, function, or content. In addition, any function that is not influenced
by, but processes or alters cybersecurity-critical data, like cryptographic material, shall also be considered a cybersecurity-critical function.
Take, for example, the non-safety-critical startup procedure depicted in Figure 9, which is executed on the application core(s). This procedure
is considered a security-critical function because it validates specific security properties of the code and data flash content before transferring the
application execution to the startup test.
6.2.4 | Identify AL threats (2.1.3)
As described at the beginning of this section, AL asset/threat pairs, that is, the security-critical data and functions and their associated threats,
shall be linked to their parent asset(s) or requirement(s) to automatically inherit the determined SecL and CGs, which were identified in the
workflow steps 1.3–1.8. Only asset/threat pairs, which cannot be linked, shall be integrated into the system-level TARA and assessed as new
asset/threat pairs.
6.2.5 | Assign cybersecurity properties (2.1.3)
This step and the subsequent vulnerability analysis are among the essential steps of the reference workflow presented. In these two steps, the following
two constraints shall be ensured: First, vulnerabilities and weaknesses in the architecture and design shall be identified, and second, it shall be
ensured that the architecture and design adequately address/implement all cybersecurity properties defined by CGs. The systematic determina-
tion of these two constraints and the necessary workflow steps are illustrated in Figures 4 and 5 and marked with the label (2.1.3).
In the current step (2.1.3), the provided cybersecurity properties of the SUD's architecture and design shall be described. To that aim, the
cybersecurity properties provided by each cybersecurity-critical data and function asset shall be determined. In a second step (2.1.4), this descrip-
tion is utilized to identify vulnerabilities/weaknesses by comparing the provided cybersecurity properties with cybersecurity properties demanded
by the CGs. In Scandariato et al.,49 a similar security-pattern-based approach is described, where security patterns and associated security proper-
ties are used to create a secure software system architecture and design.
6.2.6 | Identify AL design vulnerabilities (2.1.4)
By comparing the provided with the required cybersecurity properties (2.1.4), vulnerabilities in the cybersecurity concept, architecture, and detailed
design can be systematically identified. In addition, the comparison reveals if the current SUD architecture and design adequately address the
top-level CGs and requirements, aiming to ensure a traceable and consistent design and review process, as required by ASPICE. In addition, the
vulnerability analysis results can be utilized to guide the further security-related development steps and for systematic cybersecurity requirements
elicitation, as explained in the next section.
6.3 | Mitigation measures and requirements elicitation
CGs define the required cybersecurity properties an asset shall provide to mitigate the risks associated with this asset. These cybersecurity prop-
erties can be used for (a) the systematic identification of non-satisfied CGs and (b) the systematic identification of vulnerabilities in the SUD's
architecture and design. Next, strategies are discussed to address identified vulnerabilities and weaknesses adequately.
6.3.1 | Define AL mitigation measures (2.1.5)
So far, this work has introduced and discussed how cybersecurity properties can be used for systematic and traceable vulnerability identification.
According to Scandariato et al.,49 cybersecurity properties can also be used for the design of secure systems through the systematic selection of
security patterns based on the required cybersecurity properties. Precisely this approach is also proposed in this work to develop a secure system
architecture and design. Table 2 gives examples of security controls (i.e., mitigation measures) that can be used to implement a particular security
property on a particular system level.
6.3.2 | Refine HW/SW architecture and define HW/SW security requirements (2.1.6)
As described in the previous paragraph, security properties can be utilized to derive a secure HW/SW architectural design in a structured and sys-
tematic manner using design patterns. Through applying this approach, the appropriate security patterns and mitigation mechanisms shall be inte-
grated into the HW/SW architectural design and, at the same time, captured as traceable HW/SW security requirements.
6.4 | SW/HW detailed design and unit construction
Sections 6.1 and 6.2 describe the reference development workflow proposed for the SW/HW architectural design phase (2.1), followed by the
SW/HW detailed design and unit construction phase (2.2) as depicted in the lower part of Figure 5. The latter describes the design and construc-
tion of individual units required to implement the higher level component and system functions.
From a security perspective, the security-related definition and design phase ends with the SW/HW architectural design (2.1) for projects
that focus on function-level development only. In such projects, the scope is limited to the development of electronically controlled networked
vehicle functions. These projects do not consider the development of base-software components and services (i.e., operating system functions)
because third-party vendors develop them. Therefore, the security design lifecycle ends in these projects with the proper selection and integra-
tion of security-critical SW/HW components and functions required to implement the cybersecurity properties of identified assets.
The cybersecurity development workflow only continues for those projects with the design and development of specific cybersecurity algo-
rithms and primitives in their scope. For these projects, a similar analysis and design workflow described in the previous section can be applied.
However, each work product's required level of detail and the necessary cybersecurity knowledge is much higher.
7 | DISCUSSION
Analyzing the upcoming release of the ISO/SAE 21434 and the cybersecurity extension to Automotive SPICE with respect to the threat-model-
driven DLM we elaborated above, we can identify the following key characteristics:
• The referred standards currently have an imbalance in focus on the top-level concept phase and the subsequent development steps: Although
they are relatively detailed on the TARA, there is practically no guidance at all on how to derive design objectives and decisions on the system
and subsystem levels from the CGs delivered in the TARA. Our DLM, therefore, has a strong focus on the design-related methodology.
• Our DLM is based on the assumption that firm, well-thought architectural design decisions are crucial to integrating cybersecurity in networked
automotive systems. Architecture can mitigate one or several groups of attacks rather than only individual ones. Therefore, our DLM has been
built around a threat modeling approach that reaches from the top system (context) level down to the most detailed and fine-grained subsystem
model. The multilevel threat modeling approach also integrates into modeling artifacts that are required by Automotive SPICE. In this way,
SPICE's core traceability and consistency requirement can be seamlessly extended to the cybersecurity-related artifacts.
• The functional signal flow principle we consistently apply to asset identification and vulnerability analysis is perfectly consistent with the need
for signal flows in functional safety.26
• Another characteristic of DLM is that it is iterative. TMs on several levels evolve dynamically with the design process and provide the basis for
iterative vulnerability analysis that ultimately lead to the detailed requirements and design decisions needed to improve the system's immunity
from feasible and plausible cybersecurity attacks in the specific system context and level of detail.
• Threat-modeling using a standardized set of modeling elements also allows automation of the vulnerability analyses and requirements deriva-
tion mentioned above. This also provides strong arguments for justifying the cybersecurity cases required for acceptance (and ultimately for
vehicle homologation).
• Our DLM also leverages a pattern-based approach to achieving the cybersecurity objectives on assets derived from the CGs. Intrinsically, pat-
terns provide solid guidelines for developers and testers alike. Patterns also foster automation support through requirements and design tools.
They are also helpful for assessors to know what they can expect and ask for in terms of design requirements and solutions for a given set of
assets and related CGs and properties.
• Multilevel and multistate/session threat modeling facilitates breaking down complexity for more accessible and more focused analyses.
• The DLM is method- and tool-agnostic, which enables its instantiation and integration into any existing process landscape.
Apart from these strengths, our proposed approach also brings along some challenges, shortcomings, and limitations, whose relative weights
will only become visible and measurable once the large-scale experience is collected.
• Additional modeling effort is needed, including the learning of dedicated modeling elements and related tools.
• Analyzing functional flows requires well-specified architectural and detailed designs. They also require an excellent system understanding.
• In its current form, the DLM does not yet clearly indicate where the exact integration points in existing development processes are supposed
to be. It is also not clear at which frequency vulnerability analyses need to be re-iterated and to which extent.
• Currently, the DLM is more detailed on analysis, requirements, and design levels than on verification and validation levels. Although the verifi-
cation part shall be covered by requirements-based testing approaches required by Automotive SPICE, the methodology for the validation part
cannot just be taken over from Automotive SPICE. Penetration testing strategies are expected in this place, and OEM's expectations of the
supplier's scopes do not seem to be clear at this stage. Nevertheless, the DLM has been designed to support approaches leveraging TMs for
penetration and validation testing.
• At this stage, our DLM does not cover mitigation scoping; that is, it does not support developers in evaluating if the mitigation strategies cho-
sen per CGs are indeed appropriate. Mitigation scopes would also provide support in estimating the feasibility and priority of CG achievement
in terms of effort, time, and point of time in the product's lifecycle.
As pointed out earlier, the quantitative validation of the proposed workflow's efficiency across a large number and diversity of automotive
development projects still needs to be done once the industrial context allows for it. However, the close integration of recognized, highly experi-
enced industry experts representing major automotive tier-1 and tier-2 suppliers through the SoQrates initiative† in our work mitigates the risk
of proposing a DLM that will not perform well in practice.
8 | C O N CL U S I O N
At present, the integration of cybersecurity in automotive development processes is only starting, and therefore a commonly agreed state of the
art does not exist yet. The upcoming ISO/SAE 21434 standard and the Automotive SPICE for cybersecurity extension are essential steps in this
direction. However, in order to be able to apply them, engineers need more concrete and practicable design guidelines guiding them through the
cybersecurity development lifecycle and making explicit the work products that they are supposed to come up with in any cybersecurity-relevant
automotive development project. This article attempts to provide a contribution to fulfilling this need on a level that should be sufficiently con-
crete for engineers yet still generic enough for company-specific adaptation and future extensions and refinements.
The model we propose has been derived from practical expert knowledge combined with results from previous research adapted to the par-
ticular domain of networked automotive embedded systems. It is mainly based on an iterative threat-model-enabled workflow for the systematic
derivation of design requirements and decisions from top-level CGs. The latter are determined through threat analyses on the basis of top-level
system, asset, and TMs.
The close, traceable, and consistent integration of these artifacts in those available through Automotive SPICE-aligned development pro-
cesses assures the practicability of our model in existing automotive development project teams.
We use the case study of an electric power steering system to show that our model is actionable and leads to well-aligned technical solutions
with the requirements imposed by the applicable standards. Our future work consists of validating, refining, and improving the model in further
projects and feeding back the results and insights into the different standardization working groups.
ACKNOWLEDGMENTS
Many thanks to the SoQrates working party for review, knowledge sharing and exchange (https://soqrates.eurospi.net). This study was supported
by the H2020 Project TEACHING https://www.teaching-h2020.eu (n. 871385). This project has received funding from the BLUEPRINT Project
DRIVES https://www.project-drives.eu (2018–2021) under grant agreement No 591988-EPP-1-2017-1-CZ-EPPKA2-SSA-B. The publication
reflects only the author's view, and that the funding agency is not responsible for any use that may be made of the information it contains.
DATA AVAI LAB ILITY S TATEMENT

Data is available on request from the authors. The material is the output of the cybersecurity engineer materials (available under DRIVES
LearnCompass https://learn.drives-compass.eu/), the best practice sharing in the SOQRATES working party about cybersecurity processes imple-
mentation. The norm itself, ISO 21434, is available for the public.
ORCID
Jürgen Dobaj https://orcid.org/0000-0001-6460-8080
Georg Macher https://orcid.org/0000-0001-9215-3300
Damjan Ekert https://orcid.org/0000-0001-9301-242X
Andreas Riel https://orcid.org/0000-0001-9859-019X

Richard Messnarz https://orcid.org/0000-0002-0555-3160
ENDNOTES
* The level assigned to a TM indicates the level of detail modeled, that is, the higher the assigned level, the higher the level of detail: Level 0, system level;
Level 1, architecture level; etc.
†
soqrates.eurospi.net
RE FE R ENC E S
1. Ebert C, Jones C. Embedded software: facts, figures, and future. Computer. 2009;42(4):42-52. https://doi.org/10.1109/MC.2009.118
2. European Commission. A European strategy on Cooperative Intelligent Transport Systems, a milestone towards cooperative, connected and auto-
mated mobility, vol. (2016).
3. Aptiv, Audi, and B. M. W. Baidu. Safety first for automated driving. 2019.
4. Macher G, Schmittner C, Dobaj J, Armengaud E, Messnarz R. An integrated view on automotive SPICE, functional safety and cyber-security. In: SAE
Technical Paper Series. SAE Technical Paper Series. Warrendale, PA, United States: SAE International400 Commonwealth Drive; 2020. https://doi.org/
10.4271/2020-01-0145.
5. Strobl S, Hofbauer D, Schmittner C, Maksuti S, Tauber M & Delsing J. Connected cars—threats, vulnerabilities and their impact. In: 2018 IEEE Industrial
Cyber-Physical Systems (ICPS). IEEE; (2018):375-380. https://doi.org/10.1109/ICPHYS.2018.8387687
6. Ring M, Durrwang J, Sommer F, Kriesten R. Survey on vehicular attacks—building a vulnerability database. In: 2015 IEEE International Conference on
Vehicular Electronics and Safety (ICVES). IEEE; 2015:208-212. https://doi.org/10.1109/ICVES.2015.7396919
7. Miller C, Valasek C. Remote exploitation of an unaltered passenger vehicle. 2015.
8. Automotive, I.H.S. Automotive cybersecurity and connected car report. (2016)
9. The SPICE User Group. Automotive SPICE process assessment/reference model V3.0. VDA, vol. (2015)
10. ISO - International Standardization Organisation. ISO 26262 road vehicles—functional safety. ISO - International Standardization Organisation,
vol. (2018)
11. ISO - International Standardization Organisation. ISO/SAE DIS 21434 Road vehicles—cybersecurity engineering. ISO - International Standardization
Organisation, vol. (2020)
12. UNECE WP.29 GRVA. Draft recommendation on cyber security of the task force on cyber security and over-the-air issues of UNECE WP.29 GRVA,
vol. (2018).
13. Schmittner C, Dobaj J, Macher G, Brenner E. A preliminary view on automotive cyber security management systems; 2020:1634-1639. https://doi.
org/10.23919/DATE48585.2020.9116406
14. Vehicle Electrical System Security Committee. SAE J3061 cybersecurity guidebook for cyber-physical automotive systems. SAE, vol. (2016)
15. International Electrotechnical Commission: IEC 62443. Industrial communication networks and system security. IEC, vol. (2009)
16. ISO - International Standardization Organisation. ISO 27000 series, Information technology—security techniques. ISO - International Standardization
Organisation, vol.
17. ETSI: Intelligent Transport Systems (ITS). Communications Architecture V1.1.1. ETSI, vol. (2010)
18. ETSI: Intelligent Transport Systems (ITS). Security: threat, vulnerability and risk analysis (TVRA). ETSI, vol. (2017).
19. Benckendorff T, Lapp A, Oexner T, Thiel T. Comparing current and future E/EArchitecture trends of commercial vehicles and passenger cars. In:
Bargende M, Reuss H-C, Wagner A, Wiedemann J, eds. 19. Internationales Stuttgarter Symposium. Proceedings. Wiesbaden: Springer Fachmedien Wies-
baden; 2019:1190-1200. https://doi.org/10.1007/978-3-658-25939-6_95.
20. Braun L, Gauterin F, Sax E. Experteninterview zur Anforderungsanalyse heutiger und zukünftiger E/E Architekturen im Kraftfahrzeug. Karlsruhe
Institut für Technologie; 2016. https://doi.org/10.5445/IR/1000054216
21. Bodeau D, Fox DB, McCollum CD. Cyber Threat Modeling: Survey, Assessment, and Representative Framework; 2018.
22. Potteiger B, Martins G, Koutsoukos X. Software and attack centric integrated threat modeling for quantitative risk assessment. In: Scherlis WL,
Brumley D, eds. Proceedings of the Symposium and Bootcamp on the Science of Security. New York, NY, USA: ACM. (04192016):99-108. https://doi.
org/10.1145/2898375.2898390
23. NIST. Computer security division (CSD): guide to data-centric system threat modeling. 2016.
24. Macher G, Armengaud E, Brenner E, Kreiner C. A review of threat analysis and risk assessment methods in the automotive context. Int Conf Comput
Safety Reliab Secur. 2016;9922:130-141. https://doi.org/10.1007/978-3-319-45477-1_11
25. Macher G, Sporer H, Brenner E, Kreiner C. An automotive signal-layer security and trust-boundary identification approach. Procedia Comput Sci. 2017;
109:490-497. https://doi.org/10.1016/j.procs.2017.05.317
26. Riel A, Kreiner C, Messnarz R, Much A. An architectural approach to the integration of safety and security requirements in smart products and systems
design. CIRP Annals. 2018;67(1):173-176. https://doi.org/10.1016/j.cirp.2018.04.022
27. Schmittner C, Macher G. Automotive cybersecurity standards—relation and overview. In: Romanovsky A, Troubitsyna E, Gashi I, Schoitsch E, Bitsch F,
eds. Computer Safety, Reliability, and Security. Lecture Notes in Computer Science, Vol. 11699. Cham: Springer International Publishing; 2019:153-165.
https://doi.org/10.1007/978-3-030-26250-1_12
28. Dobaj J, Ekert D, Stolfa J, Stolfa S, Macher G, Messnarz R. Cybersecurity threat analysis, risk assessment and design patterns for automotive
networked embedded systems: a case study. J Univ Comput Sci. 2021;27(8):830-849. https://doi.org/10.3897/jucs.72367
29. Islam MM, Lautenbach A, Sandberg C, Olovsson T. A risk assessment framework for automotive embedded systems. In: Zhou J, Lopez J, eds. Proceed-
ings of the 2nd ACM International Workshop on Cyber-Physical System Security - CPSS '16. New York, New York, USA: ACM Press; 2016:3-14. https://
doi.org/10.1145/2899015.2899018
30. Chockalingam S, Hadžiosmanovic D, Pieters W, Teixeira A, van Gelder P. Integrated safety and security risk assessment methods: a survey of key char-
acteristics and applications. In: Havarneanu G, Setola R, Nassopoulos H, Wolthusen S, eds. Critical Information Infrastructures Security. Lecture Notes in
Computer Science, Vol. 10242. Cham: Springer International Publishing; 2017:50-62. https://doi.org/10.1007/978-3-319-71368-7_5
31. Macher G, Armengaud E, Brenner E, Kreiner C. Threat and Risk Assessment Methodologies in the Automotive Domain. Procedia Comput Sci. 2016;83:
1288-1294. https://doi.org/10.1016/j.procs.2016.04.268
32. Dobaj J, Schmittner C, Krisper M, Macher G. Towards integrated quantitative security and safety risk assessment. In: Romanovsky A, Troubitsyna E,
Gashi I, Schoitsch E, Bitsch F, eds. Computer Safety, Reliability, and Security. Lecture Notes in Computer Science, Vol. 11699. Cham: Springer International
Publishing; 2019:102-116. https://doi.org/10.1007/978-3-030-26250-1_8
33. Hussain S, Kamal A, Ahmad S, Rasool G, Iqbal S. Threat modelling methodologies: a survey. Forensic Sci Int (Lahore),. 2014;26:1607-1609
34. Hao J, Han G. On the modeling of automotive security: a survey of methods and perspectives. Future Internet. 2020;12(11):198. https://doi.org/10.
3390/fi12110198
35. Karahasanovic A, Kleberger P, Almgren M. Adapting threat modeling methods for the automotive industry, vol.
36. Ma Z, Schmittner C. Threat modeling for automotive security analysis. advanced science and technology letters. Sci Eng Res Support Soc. 2016;
333-339. https://doi.org/10.14257/astl.2016.139.68
37. Martin H, Ma Z, Schmittner C, et al. Combined automotive safety and security pattern engineering approach. Reliab Eng Syst Saf. 2020;198:106773.
https://doi.org/10.1016/j.ress.2019.106773
38. Kondeva A, Nigam V, Ruess H, Carlan C. On computer-aided techniques for supporting safety and security co-engineering. In: 2019 IEEE International
Symposium on Software Reliability Enginee\ring Workshops (ISSREW). IEEE; 2019:346-353. https://doi.org/10.1109/ISSREW.2019.00095
39. Amorim T, Martin H, Ma Z, et al. Systematic pattern approach for safety and security co-engineering in the automotive domain. In: Tonetta S,
Schoitsch E, Bitsch F, eds. Computer Safety, Reliability, and Security. Lecture Notes in Computer Science, vol. 10488. Cham: Springer International Pub-
lishing; 2017:329-342. https://doi.org/10.1007/978-3-319-66266-4_2.
40. Corallo A, Lazoi M, Lezzi M. Cybersecurity in the context of industry 4.0: a structured classification of critical assets and business impacts. Comput Ind.
2020;114:103165. https://doi.org/10.1016/j.compind.2019.103165
41. Zografopoulos I, Ospina J, Liu X, Konstantinou C. Cyber-physical energy systems security: threat modeling, risk assessment, resources, metrics, and
case studies. IEEE Access. 2021;9:29775-29818. https://doi.org/10.1109/ACCESS.2021.3058403
42. Zalewski J, Drager S, McKeever W, Kornecki AJ. Threat modeling for security assessment in cyberphysical systems. New York, NY: ACM; 2013.
43. Khan R, McLaughlin K, Laverty D, Sezer S. STRIDE-based threat modeling for cyber-physical systems. Torino, Italy, 26-29 September 2017: Confer-
ence Proceedings IEEE, Piscataway, NJ (2017)
44. Jamil AM, Othmane LB, Valani A. Threat modeling of cyber-physical systems in practice. 2021.
45. Shostack A. Threat Modeling: Designing for Security. Indianapolis, IN: Wiley; 2014.
46. Shostack A. Experiences threat modeling at Microsoft. 2008.
47. Shevchenko N, Chick T, O'Riordan P, Scanlon T, Woody C. Threat modeling: a summary of available methods. 2018.
48. Islam Mafijul. Deliverable d2-secuirty models. HEAVENS Project. 2014.
49. Scandariato R, Yskout K, Heyman T, Joosen W. Architecting software with security patterns. 2008.
How to cite this article: Dobaj J, Macher G, Ekert D, Riel A, Messnarz R. Towards a security-driven automotive development lifecycle.
J Softw Evol Proc. 2021;e2407. doi:10.1002/smr.2407

Towards A Security Driven Automotive Development Lifecycle

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Towards A Security Driven Automotive Development Lifecycle

Uploaded by

Copyright:

Available Formats

Received: 19 May 2021 Revised: 14 September 2021 Accepted: 13 October 2021

SPECIAL ISSUE - METHODOLOGY PAPER

Towards a security-driven automotive development lifecycle

Jürgen Dobaj1,2 | Georg Macher1,2 | Damjan Ekert2 | Andreas Riel2,3 |

J Softw Evol Proc. 2021;e2407. wileyonlinelibrary.com/journal/smr 1 of 22

1.2 | Problem statement

2.1 | Automotive product and systems engineering lifecycle

2.2 | Automotive cybersecurity regulations and standards

2.3 | Vehicular electrical/electronic architectures

FIGURE 2 Modern vehicle E/E architecture

2.4 | Threat analysis and risk assessment

2.4.1 | Introduction to threat modeling

2.4.2 | Approaches to threat modeling

FIGURE 4 Development lifecycle model for cybersecurity requirements elicitation

4.1 | Concept phase

4.2 | Development phases

5.1 | Concept definition and threat analysis

5.1.1 | Selecting a threat modeling method

5.1.2 | Define system-level concept (1.2)

5.1.3 | Identify system-level assets (1.3)

5.1.4 | Identify system-level threats (1.4)

5.2 | Risk assessment and requirements elicitation

TABLE 1 STRIDE threats and security properties affected by these threats

STRIDE threat Security property Threat example

Abbreviation: ECU, electronic control unit.

TABLE 2 Examples for security controls on various levels (adapted from3)

5.2.1 | Determine SecL (1.6)

5.2.2 | Define CGs (1.7)

5.2.3 | Refine system-level concept and define system-level CS requirements (1.8)

6.1 | Define HW/SW system architecture (2.1.1)

6.1.1 | Item lifecycle and SW state analysis

FIGURE 8 Item lifecycle phases and software state machine

6.2 | Threat and vulnerability analysis

FIGURE 9 Level 1 threat model: Application startup

6.2.1 | Threat modeling strategies (2.1.2)

6.2.2 | Level 1+ threat modeling (2.1.2)

6.2.3 | Identify AL assets (2.1.2)

6.2.4 | Identify AL threats (2.1.3)

6.2.5 | Assign cybersecurity properties (2.1.3)

6.2.6 | Identify AL design vulnerabilities (2.1.4)

6.3 | Mitigation measures and requirements elicitation

6.3.1 | Define AL mitigation measures (2.1.5)

6.4 | SW/HW detailed design and unit construction

DATA AVAI LAB ILITY S TATEMENT

Andreas Riel https://orcid.org/0000-0001-9859-019X

You might also like