Towards a security-driven automotive development lifecycle

Cybersecurity has become one of the most crucial challenges in the automotive development lifecycle. The upcoming ISO/SAE 21434 standard provides only a generic framework that is insufficient to derive concrete design methods. This article proposes an actionable cybersecurity development lifecycle model that provides concrete action and work product guidance aligned with the ISO/SAE 21434 and Auto-motive SPICE ® extension for cybersecurity. The model has been inspired by action research in “ next ” industry practice pilot projects, which ensures that it is actionable. It has been augmented by insights gained from literature research in cybersecurity development for embedded systems. The proposed lifecycle model complements the ISO/SAE 21434 standard and provides the basis for the company-specific process and practice specifications. It has been validated through the integration of cybersecurity-related aspects in an electric power steering system. A core characteristic 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.

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 management systems, autonomous driving, and new mobility services. These features require integrated security solutions and architectures to mitigate 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 modern connected vehicles and the mobility infrastructure against cyberattacks.

| 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 consistent and comprehensive approaches to combining and integrating cybersecurity engineering aspects into a comprehensive automotive reference development lifecycle/process that extends beyond the concept phase.

| 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 engineering aspects of the various design phases (concept, HW/SW architecture, and HW/SW detailed design) within the automotive development lifecycle.

| 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 development 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.

| Conclusion
The upcoming ISO/SAE 21434 standard and the Automotive SPICE for Cybersecurity extension are essential steps towards integrating cybersecurity 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 decisions 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.

| 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 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.

| BACKGROUND
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 interacting 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][6][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 cybersecurity 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

| 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) standard 9 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. 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 26262 10 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 during 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 relevant security standards (e.g., ISO/SAE 21434 11 ) and regulations (e.g., UNECE WP.29 12 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 weaknesses 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 sector 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 development and integration of new engineering methods into the established lifecycle.

| 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 -Cybersecurity 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 62443 15 or the ISO 27000 series 16 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 Administration (NHTSA) guidelines for cybersecurity best practices for modern vehicles. Security aspects for intelligent transport systems and connectivity 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 systems, 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 vehicles. 12 Besides the above initiatives, the concern of the International Electrotechnical Commission (IEC) TC65 on the impact of cybersecurity, reliability, and related system properties on functional safety, has led to the creation of three IEC TC65 Ad-Hoc Groups (AHG): (a) IEC TC65 AHG1: 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.

| 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 systemlevel 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 suppliers, while the OEM is responsible for the final integration of these items into the vehicle infrastructure. The vehicle infrastructure is also denoted 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 subnetwork 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 interconnection 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 nonsafety-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, highperformance 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.
F I G U R E 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.

| 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 process can provide information on cybersecurity aspects in multiple ways to discover potential threats, vulnerabilities, and weaknesses in the SUC 21 : • 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 nonadversarial 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 mitigation, 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 environment (i.e., DevOps).
Summing up, threat modeling is a generic tool that can be used throughout the entire system/product lifecycle for various cybersecurityrelated 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 propose such tailoring for the automotive development lifecycle in Section 4. Before that, we describe the underlying principles for this tailoring in the following.

| Approaches to threat modeling
Cybersecurity TARA can be approached from three different perspectives [21][22][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 identified 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.
• 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, cryptographic key material, firmware, functions, system properties and behavior) and physical assets (e.g., sensors, actuators, devices, bus connections, 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 security 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 system 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.

F I G U R E 3
Threat modeling approaches and their usage for modeling system security aspects

| RELATED WORK
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 cybersecurity management aspects and highlight the need for new development lifecycle approaches to integrate cybersecurity activities into development 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 modelingdriven 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 works 21 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 methodologies to assess the impacts of cyber-attacks on Industry 4.0 manufacturing systems are discussed, and the work of Zografopoulos et al. 41 presents 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][43][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 automotive domain where well-established quality and security-related development approaches, development interfaces, and regulatory constraints significantly 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.

| THREAT MODELING-DRIVEN DLM
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 development 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 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 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.

| 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 system 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 perspective (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 system 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 assessment 32 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 cybersecurity 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.

| 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 F I G U R E 4 Development lifecycle model for cybersecurity requirements elicitation 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 cybersecurity properties provided by specific assets and the overall system. Weaknesses and vulnerabilities in design and implementation can be identified 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.

| CONCEPT PHASE
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 proposes to create during development.
F I G U R E 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 customer 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 development 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 concept phase workflow steps depicted in the upper part of Figure 5 are described.

| 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 stakeholder, 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.

| 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. However, 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 knowledge 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 approach 46 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 works 21,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 authorization 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 proposed can be implemented using any method and combination of threat, system, and asset modeling methods.

| 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 previously created system-level models and diagrams from a cybersecurity perspective. Therefore, a system-level TM shall be derived from the system-level concept diagrams.

| 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 F I G U R E 6 Item block diagram: Road wheel steering control unit (SCU) (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.

| 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. 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 algorithm 45 can be used for systematic (and automated) threat and asset pair identification.

As depicted in
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 plausibility of threats in the system context and the impact and risk of specific threats must be determined and assessed in the next phase.  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]).

| 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 properties. 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 specific 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. 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.

| 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 systemlevel requirements. To that aim, we propose that CGs (and their associated risks) shall be aligned with the customer and subsequently, for T A B L E 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/ transition (e.g., CAN-messages) Without proper protection, CAN-messages can be intercepted, 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 Disclosure
Confidentiality: Disclosure of information An ECU participates in a key-agreement protocol and leaks private key material.

Denial of service
Availability: Denial or degradation of service/function. An ECU floods the CAN bus with garbage or continuously holds the data lines "high".
Abbreviation: ECU, electronic control unit. -Encryption of data at rest -Secure storage 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.

| DEVELOPMENT PHASE
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, however, 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 weaknesses. The following steps explain the systematic identification of such vulnerabilities and weaknesses, denoted as vulnerability/weakness analysis 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.

| 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) architecture 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.
F I G U R E 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.

| 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 inheriting the SecL and CG already determined by the TARA. Only asset/threat pairs, which cannot be linked to existing parent assets, CGs, or cybersecurity requirements, shall be retrospectively integrated and assessed in the system-level TARA.
F I G U R E 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 analyzable 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- The asset identification in the concept phase intentionally omits technical details by focusing on the item interfaces, the information transmitted 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 cybersecurity 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) cybersecuritycritical 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 cybersecurity 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.

| 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.

| 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 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 description 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 properties are used to create a secure software system architecture and design.

| 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.

| 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 properties 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.

| 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 systematic manner using design patterns. Through applying this approach, the appropriate security patterns and mitigation mechanisms shall be integrated 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 construction 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 integration 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 algorithms 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.

| DISCUSSION
Analyzing the upcoming release of the ISO/SAE 21434 and the cybersecurity extension to Automotive SPICE with respect to the threat-modeldriven 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 derivation 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, patterns 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 verification 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 chosen 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 experienced 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.

| CONCLUSION
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 concrete 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 particular 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 processes 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 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 AVAILABILITY STATEMENT
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 implementation. The norm itself, ISO 21434, is available for the public.