Research on FOTA Information Security Specifications and Methods for Automobiles

Author: Neo Wong

Introduction

The automotive industry is facing huge challenges in managing increasingly complex systems. The proportion of software implementation is increasing year by year, as is the specialized knowledge and new technologies across domains. With the emergence of multi-core processors, ADAS advanced driving assistance systems, autonomous driving, and Telematics connected cars, the information security performance of cars (remote hacking attacks, privacy information theft) is getting more and more attention from consumers, OEM manufacturers, and regulatory structures. At the same time, the original embedded system characteristics, such as precise timing, priority-based scheduling, and memory consumption, remain core challenges for automotive ECUs. Therefore, it is necessary to support information security and ECU system characteristics through appropriate system methods.

ECUs consist of hardware and software, following the V-model for development, from specification to design, implementation, integration, verification, testing, and production. As more and more OEMs apply modern wireless communications (2G/3G/4G/5G) to cars, providing voice and data transfer services and also providing the possibility of FOTA. Once the vehicle OEM decides to perform the update, FOTA can generally be divided into six steps:

1. Update preparation;
2. If necessary, obtain regulatory approval;
3. Obtain upgrade permission from authorized users;
4. End-to-end firmware transmission from FOTA service to vehicle, and then update to the ECU that needs to be updated;
5. FOTA service receives feedback on the upgrade situation;
6. Perform other relevant management tasks.

Given the process and impact factors of the FOTA business, it is necessary to select appropriate methods to evaluate the information security risks faced by FOTA, define the information security requirements of ECUs involved in OTA on the production line, and design appropriate production processes and methods.

Analysis of Applicability of Automotive Information Security Standards

Automotive Information Security Standards

Automotive information security consists of five aspects: vehicles, terminals, networks, platforms, and services, which are included in the standard system of the connected car and related electronic products and services. Although the industry already has specifications and standards such as IEC-62443 [1], in order to deal with information security challenges, the automotive industry has also utilized some existing experience in this field, such as ISO-26262 [2] formulated based on IEC-61508 by the International Electrotechnical Commission, to form automotive industry information security standards and regulations.

• ISO’s WorkIn 2016, the SC32/WG11 Cybersecurity Information Security Working Group was established under ISO/TC 22 Road vehicles Technical Committee, jointly founded by the United States SAE and ISO (ISO/SAE/JWG Automotive Security) to develop the international standard for automotive information security, code-named ISO-SAE 21434 [3]. This standard mainly aims to ensure the development of the automotive information security engineering from four aspects: risk assessment management, product development, production/operation/maintenance, and process review. The goal is to enable products designed, produced, and tested in accordance with this standard to possess a certain degree of information security protection capability. The first draft of this standard was released in February 2020. From the perspective of the automotive industry, the content it represents mainly emphasizes the need for information security in the development of automobiles and associated products, and the realization of a common understanding of security throughout the entire supply chain.

Originally a specification for functional safety of road vehicles, ISO-26262 standardized safety assessment technologies such as FMEA [4] and FTA [5], and integrated them into the automotive development process. In late 2018, the second edition of ISO-26262 was released, and Attachment E of Part II provided guidance on the interaction between functional safety and cybersecurity:

1. In terms of management, it is recommended to adjust plans and milestones and monitor them in real-time;
2. In the conceptual phase, focus on the interaction and coordination between TARA (Threat Analysis and Risk Assessment) and HARA (Hazard Analysis and Risk Assessment);
3. In the development phase, continue to analyze and identify the potential impact between the two;
4. During the production/usage phase, strategies to resolve information security incidents need to consider the potential impact on functional safety caused by design changes resulting from information security event responses.

ISO/AWI-24089 (Software Update Engineering) aims to provide a standardized architecture for road vehicle OTA updates, including information security components. The working group was launched in March 2019 and is expected to be released in 2024.

In ISO-20078-3 (Extended vehicle (ExVe) web services-Part 3 [6]: Security), it is proposed that in order for vehicle data to be transmitted to a remote and secure server, a unique interface must be provided for the service, in order to meet the goal of minimizing the attack surface.ISO-20828 [7] describes how to use vehicle public keys to issue and manage certificates.

• SAE’s work

SAE J3061 [8] is the predecessor to ISO-SAE 21434. The standard states that a complete lifecycle process for cybersecurity engineering is required, with its definition borrowing from the process framework described in ISO 26262. However, it does not clearly define the engineering integration model of functional safety and cybersecurity at the interaction level, nor does it directly integrate the two into the process. Due to the development of ISO-SAE 21434, SAE J3061 will be redesigned [9] to cover other topics beyond the scope of ISO-SAE 21434: [1]

• SAE J3061-1 Automotive Cybersecurity Integrity Level: Defines AcSIL (Automotive Cybersecurity Integrity Level) and TARA. By associating AcSIL with ASIL (Automotive Safety Integrity Level), threats that may cause functional safety impact can be addressed.

• SAE J3061-2 Security Testing Method: mainly outlines the software and hardware testing methods currently available for automotive information security.

• SAE J3061-2 Security Testing Tool: mainly outlines the available automotive security testing tools and the testing capabilities of each tool.

SAE J3101 (Requirements for Hardware-Protected Security for Ground Vehicle Applications) proposes hardware protection requirements for ground vehicle information security [10].

SAE J3138 (Guidance for Securing the Data Link Connector (DLC)) is a security communication guide for connecting OBDII devices [11].

In addition, the under-development SAE J1939-91 Part B (Bi-Directional secure Over The Air (OTA) communications via a telematics interface to the vehicle) and J1939-91 Part-C (In-Vehicle Network Security) are both standard specifications related to the cybersecurity of road vehicles.- ITU-T Work

SG17 of ITU-T is mainly responsible for research and standardization of communication security. The standards that have been formally released include X.1373 [12]. This standard aims to apply communication devices in ITS vehicles through the internet and/or ITS dedicated network for vehicle-to-infrastructure (V2I) communication. In addition, ITU-T has some related standards being developed:

1. X.itssec-2 introduces the basic model and use cases of V2X communication system, and gives the security requirements of the system [13].

2. X.itssec-3 aims to identify security issues when an external device (regardless of whether it can be connected to the telecommunications network) connects to the OBDII port similar to SAE J3138, and defines appropriate security requirements to protect this external interface [14].

3. X.itssec-4 aims to provide comprehensive guidance on intrusion detection systems (IDS) in the onboard control network [15]. The proposal will classify and analyze the attack types on the vehicle network and system. The focus of the research is on the vehicle networks, such as Controller Area Network (CAN) or CAN-FD, which are not supported by traditional IDS.

4. X.itssec-5 proposes security requirements for Vehicular Edge Computing (VEC) [16], based on threat analysis and risk assessment.

5. X.eivnsec contains a reference model for automotive Ethernet, as well as a threat analysis and vulnerability assessment for Ethernet-based in-vehicle networks [17]. Security requirements and potential use cases for Ethernet-based in-vehicle networks will be defined.

• UNECE Work

The World Forum for Harmonization of Vehicle Regulations of the United Nations Economic Commission for Europe (UNECE) Sustainable Transport Division has commissioned Working Group WP.29 to develop draft regulations on cybersecurity [15] and over-the-air updates [18]. The working group considers international guidelines on network security and data protection for ITS/AD developed through WP29/2017/46, as well as other relevant standards, practices, instructions and regulations on network security, and existing standards applicable to the automotive industry [19]. The principles for dealing with identified network threats and vulnerabilities are defined, and detailed guidance or measures on how to meet these principles are specified. Finally, the proposed requirements are assessed and met.## Safety standards for communication equipment in ITS (Intelligent Transport System) [18]

To prevent threats such as tampering and malicious intrusion to the communication equipment in vehicles, secure software updates are needed for communication devices according to the basic model of software updates, threat and risk analysis have been carried out, and corresponding security requirements have been specified. An abstract data format has also been designated for updating software modules.

The dark portion in the figure below represents the scope of discussion of [18], while the light portion on the right is the scope of discussion of [19].

Work by ETSI

European Telecommunications Standard Institute (ETSI) has developed a series of information security standards for intelligent connected vehicles and intelligent transportation systems. The standards cover ITS security service architecture [20], ITS communication security architecture and security management [21], trusted and privacy management [22], access control [23], and confidential services [24].

Work by the National Automotive Standardization Technical Committee

China has established the Intelligent Connected Vehicle Sub-Technical Committee (SAC/TC114/SC34) under the National Automotive Standardization Technical Committee to lead the development of national and industry standards for intelligent connected vehicles. The committee has completed the preliminary research work for three basic standards for automotive information security requirements, including general technology requirements for automotive information security, information security requirements for in-vehicle gateway, and information security requirements for in-car infotainment systems. It has also completed the preliminary research work for two urgently needed industry standards, including information security technical requirements for electric vehicle remote management and service systems, and information security technical requirements for electric vehicle charging. The committee has also proposed a sub-system framework for automotive information security standards, comprehensively sorted out the formulation of automotive information security standards from the aspects of evaluation, prevention, and testing, and from the levels of basic, common, system components, and functional management. It has also included interfaces reserved for relevant standards from other information security systems [25].

Figure 2 illustrates the different aspects of automotive information security that the above standard specifications are addressing.

Choosing applicable standardsThe article summarizes the scope, concepts, and methods of ISO-SAE 21434 (and its predecessor, SAE J3061), providing theoretical sources and method guidance for further research on the topic. The reasons are:

1. Typical

ISO-SAE 21434 is a guide specifically for automotive information security, with the following objectives [3]:

• Define information security policies and processes;

• Manage information security risks;

• Cultivate a culture of security.

ISO-SAE 21434 defines a process framework for the information security lifecycle of vehicle systems, providing guidance and information on tools and methods related to information security. It defines in detail the objectives, inputs, outputs, conditions, security risk situations, security assessments, security requirements, and deliverables of various security activities. These tools and methods are adapted to the existing V-model development process in organizations.

In addition, the steps for applying ISO-SAE 21434 include: asset identification -> threat identification -> impact rating -> attack path analysis -> attack probability evaluation -> risk assessment (including risk rating) -> risk analysis and handling decision. This is a typical information security evaluation process in line with the specifications of ISO/IEC 27001.

2. Comprehensive

SAE J3061 is a lifecycle-based specification. ISO-SAE 21434 fills in some gaps in SAE J3061, and in fact replaces it. ISO-SAE 21434 specifies the information security risk management requirements and processing procedures and methods of road vehicles, their parts, and interfaces throughout the entire engineering process (such as conception, design, development), production, operation, maintenance, and retirement. Figure 4 shows the main contents of ISO-SAE 21434 [3]:

In addition to detailed specifications of the definition and requirements of security activities throughout the whole lifecycle, ISO-SAE 21434 and SAE J3061 also provide tools and methods available for the automotive information security field, which can be used in the process of applying the specifications. Table 1 compares the contents of these two standards with other automotive information security standards:

Table 1 Comparison of the contents of ISO-SAE 21434/SAE J3061 with other automotive information security standards

3. Advanced

Despite efforts to extend ISO-26262 to the field of information security, none of the previous automotive standards have fully addressed the issue of automotive cybersecurity. The much-anticipated SAE J3061 was released in 2016 and is considered by industry insiders to have filled an important gap in modern vehicle cybersecurity engineering.

ISO-SAE 21434 has not yet been formally released. This article discusses the last draft released for public comment in February 2020. It appears that the methods, concepts, standards, processes, and content of ISO-SAE 21434 correspond to those of SAE J3061. ISO-SAE 21434 supplements SAE J3061 with information security risk management, information sharing, vulnerability disclosure, information security monitoring, and incident response. This has a guiding role for OEMs, Tier 1 suppliers, car connectivity service providers, regulatory agencies, etc. which are exploring in practice.

ISO-SAE 21434 proposes the concept and requirement of “distributed information security activities” which is unique to the automotive industry.

!Figure 5 ISO-SAE 21434 Distributed Information Security Activities [42]

Based on current developments, several foreign manufacturers have launched TARA management products based on ISO-SAE 21434. Therefore, it can be foreseen that it will become a future trend in the industry.

Due to the publication of ISO-SAE 21434, SAE J3061 will be redesigned to cover other topics outside the scope of ISO-SAE 21434. The updated version will be numbered as SAE J3061A.

4. Extensive

ISO-SAE 21434 and SAE J3061 define basic guiding principles and processing methods that support cybersecurity for network security, assess potential threats and risks to systems that may be related to information security, and determine whether there are potential information security threats that may result in safety violations.In the field of academic research, policy formulation, and industry engineering, SAE J3061 and ISO-SAE 21434 specifications have been widely referenced, adopted, and applied for their ideas, methods, processes, and information. This indicates that these two specifications are not only applicable to the entire lifecycle of automotive-related products, services, and infrastructure, but also broadly recognized by academia, government regulators, and the automotive industry [26].

China actively participated in the development and formulation of ISO-SAE 21434. From February 18th to 22nd, 2019, the 9th meeting of the Joint Working Group on Automotive Information Security of ISO/TC22/SC32/WG11 (ISO/SAE JWG) was held in Shenzhen to further discuss and resolve disputes and newly received proposals regarding the Committee Draft (CD) stage of ISO-SAE 21434. This meeting was hosted by China Automotive Technology and Research Center Co., Ltd. and co-organized by Huawei Technologies Co., Ltd., with delegations from more than 10 countries including China, Germany, and the United States attending [27].

Based on the analysis of ISO-SAE 21434 and SAE J3061 above, it can be recognized as a reference basis suitable for the topic analysis of this paper for the following reasons:

• The topic belongs to the automotive field, and the specifications are targeted;

• The topic belongs to the production stage of the entire lifecycle of automobiles, and the specifications cover this stage;

• The systems and tools used in the production line involved in the topic need to undergo the entire process of requirement definition, system design and development, testing, production, maintenance, and retirement, and the specifications can guide this process;

• The ECU with secure FOTA involved in the topic itself includes information security components, and the production stage of its information security risk needs to be evaluated using the specifications;

• When initializing ECU data in the production line related to the topic, external systems need to be connected to the network, increasing the attack surface and the probability of being attacked compared to producing ordinary ECUs. The specifications can correctly identify threats, evaluate security risks, and formulate appropriate strategies to overcome them;

• As an ISO specification, ISO-SAE 21434 will be applied by most mainstream OEM and Tier 1 suppliers, and is likely to be incorporated into China’s national standard as a part of its value and significance for the research content of the topic to follow and reference.

Information Security Risk Assessment Methods and TechnologiesAccording to the recommendations of SAE J3061 and ISO-SAE 21434, preliminary analysis should be conducted on potential threats to automotive systems and services, and risk assessment should be carried out on information security and functional safety-related content to determine whether there is a possibility of security vulnerabilities and threats. The method applied in the standard is called Threat Analysis and Risk Assessment (TARA). TARA is defined as a “analysis technique applied in the conceptual stage to help identify potential threats, and evaluate related risks.”

The topic of this paper also involves selecting suitable TARA methods to determine security assets, threats, and risks when initializing data for ECU with security FOTA function.

The following will analyze typical technologies and methods used in the current information security field that can be used in the automotive industry, and then select appropriate technologies and methods according to the topic of this paper.

Information security CIA model

The CIA model is a concept in the field of information security with intuitive and easy-to-apply characteristics [28]:

• C- Confidentiality

Confidentiality involves dynamically generated data or static data. Ensure that any non-target entity cannot read static data and/or messages during transmission.

• Integrity

Integrity involves manipulation or tampering of software and data.

• Availability

When using CIA for risk assessment, expert evaluation is generally used to analyze potential security threats to assets that may be evaluated, and then different weights for CIA are set according to the different focus of evaluation entities (such as companies, governments, etc.) on CIA, and specific scoring criteria are described. The scoring method can be represented by the following formula:

There is also research on calculating the score of CIA through risk factor matrices and neural networks to obtain the risk assessment results.

The main advantages of using CIA directly for TARA are:

• The model is simple and easy to apply;
• The evaluation method is intuitive and easy to obtain evaluation results.

The disadvantages are:

• It depends on the familiarity and understanding of experts with the TOE;
• There is no unified process or method guidance, which may bring inconsistent evaluation results for the same TOE;
• The evaluation parameters are too few, which may result in distorted evaluation results.

STRIDESTRIDE is a threat analysis model developed by Microsoft [29]. It is a structured and qualitative security method used to discover and enumerate threats in software systems. Currently, the applicability of the STRIDE method has been extended to automotive electronic and electrical systems.

S – Spoofing Identity

T – Tampering with Data

R – Repudiation

I – Information Disclosure

D – Denial of Service

E – Elevation of Privilege

By mapping threats to security attributes, STRIDE expands the CIA model. The mapping is static, and once a pair of “threat – asset” is confirmed, it can be used to formulate information security requirements. The mapping between STRIDE threats and security attributes is shown in Table 2.

Table 2 Mapping between STRIDE and CIA

Using the Microsoft Threat Modeling Tool provided by Microsoft for TOE analysis, drawing a Data Flow Diagram (DFD) is very useful for conducting STRIDE threat analysis [30].

Attack Tree Analysis

The concept of Attack Trees was first proposed by the US Department of Defense and is widely used in the defense and aerospace industries to analyze threats to anti-tamper electronic systems (such as avionics equipment on military aircraft) [31]. The ATA analysis method is suitable for feature or system level and is therefore suitable for embedded systems in cars.

ATA is similar to Fault Tree Analysis (FTA) invented by Bell Laboratories to evaluate the combination of multiple threats (attack modes) [4]. Due to the need for sufficient details of TOE, it is not suitable for initial TARA.

ATA is recommended in the SAE J3061 Appendix for evaluating potential threats and risks [8].

EVITAThe full name of EVITA is “E-Safety Vehicle Intrusion Protected Applications,” which is a project funded by the European Commission [32]. The project was launched in 2008, with participants including MIRA, BMW, Bosch, Continental, ESCRYPT, Fujitsu, and Infineon, among others. The goal of the project is to design, validate, and build a prototype of a vehicle network architecture that protects components related to information security from tampering and prevents sensitive data and privacy information from being leaked. To achieve this goal, EVITA draws on the security model and methods provided by ISO/IEC 15408 [33], and combines them with the lifecycle process of ISO-26262, proposing the THROP (THReat and OPerability Analysis) method, which considers the potential threats of specific features from a functional perspective. THROP is derived from the well-known HAZOP (Hazard and OPerability Analysis) method used in functional safety engineering, using ATA to define threats based on the main functions of analyzed features at the functional level. The steps of the THROP method are as follows:

1. Determine the main function of the feature;

2. Apply “guidewords” to identify potential threats, such as “malicious non-intentional,” “malicious error,” “malicious loss,” etc.;

Determine the worst possible situation from the potential malicious behavior.

Table 3 EVITA uses THROP for risk assessment

The risk level is based on the combination of severity, attack probability, and controllable measures. “Severity” evaluates threats from four aspects: operation, safety, privacy, and finance. To rate security threats, a method similar to ASIL is used to map controllability, severity, and attack probability to different risk levels (R0 to R7 and R7+).

The problems of using EVITA methods for TARA in the automotive industry are:

1. The rating method of Severity is inconsistent with that in ISO 26262 standard;

2. The evaluation criteria for security-related threats and non-security-related threats (such as privacy and finance) are different, which may lead to an unbalanced evaluation work and biased evaluation results;

3. The potential attack methods expressed in probabilities are evaluated by adding, minimizing, and maximizing them to obtain the final evaluation result, which is not an accurate calculation method and may introduce distortion.

OCTAVE# OCTAVE

OCTAVE stands for “Operationally Critical Threat, Asset, and Vulnerability Evaluation,” a systematic approach to information security risk assessment proposed by the Software Engineering Institute of Carnegie Mellon University [34]. The OCTAVE assessment consists of three phases and eight processes, as shown in Figure 7.

!Figure 7: OCTAVE assessment phases and processes [98]

The focus of OCTAVE is to bring together stakeholders of information security and gradually identify security threats and risks through a series of workshops. However, this method is more suitable for enterprise information security risk assessment and may not be as applicable to embedded automotive systems.

HEAVENS

HEAVENS Security Model is a method, process, and tool support for the analysis and risk assessment of information security threats to the vehicle’s electrical/electronic (E/E) systems [35]. The HEAVENS Security Model proposes a systematic approach to derive information security requirements for automotive E/E systems, taking into account the most advanced threat analysis and risk assessment methods through three steps:

• Threat Analysis

The HEAVENS Security Model uses STRIDE to conduct threat analysis.

• Risk Assessment

After analyzing the Threat-Asset Pairs (TA Pairs) based on the STRIDE method, a security level is assigned to each TA Pair. The risk assessment includes three steps:

• Determine the Threat Level (TL): Estimate the level of threat according to the “likelihood” of the threat.

• Determine the Impact Level (IL): Refers to the severity of “impact” that occurs after a security problem.

• Determine the Security Level (SL): Corresponds to the final risk assessment level, jointly determined by TL and IL.

Table 4 Evaluating SL using TL and IL

• Security RequirementsTranslate Chinese Markdown to English Markdown, preserving HTML tags within Markdown, output only result:

The final step is to derive the security requirements based on Asset, Threat, security attributes, and SL. When an Asset has a security level of “QM”, it may or may not require additional information security requirements, which needs to be evaluated by business experts. If it is not “QM”, information security requirements should be formulated for the other two cases.

!Figure 8 HEAVENS Security Model Evaluation Process [98]

When an asset may face multiple threats, its security level may have multiple levels based on the threat levels associated with all threats. One way to determine the security level of the entire asset is to consider the highest security level among all threat levels associated with the asset. Another way is to consider the highest threat level and impact level to define the security level of the asset.

HEAVENS benefits from the steps and methods of STRIDE, making it possible to discover potential threats in a structured and systematic way. However, a lot of work is required to analyze and determine the IL and TL factors of individual threats to determine the SL.

SAHARA

The name SAHARA comes from the combination of STRIDE and HARA in ISO 26262 [36], which quantitatively evaluates the development of safety systems at the system level. SAHARA combines HARA [2] and STRIDE methods [29] to track the impact of information security issues on system functional safety. It uses the ASIL method to quantitatively analyze the results of STRIDE analysis based on resources (R), knowledge required to implement the threat (K), and the criticality of the threat (T) to determine the security level (SecL):

Examples of R, K, and T in SAHARA are shown below:

Table 5 Examples of R, K, and T Parameters in SAHARA

The quantitative calculation method of SAHARA is not complicated and does not require too much analysis work and details of the analyzed system. This allows SAHARA to determine the resource limits assigned to a specific threat and quantify the impact of the threat on functional safety goals.

TVRATVRA, the abbreviation for “Threat, Vulnerabilities, and implementation Risks Analysis,” is a process-driven threat assessment/risk evaluation method [37]. TVRA was developed in 2009, updated by the European Telecommunications Standards Institute (ETSI) in 2010, and currently standardized in ETSI TS 102 165-1 V4.2.3.

TVRA requires 10 steps to systematically identify the unwanted events to prevent in a system. TVRA identifies assets in the system and their related weaknesses and threats, and determines the system’s risks by modeling the likelihood and impact of attacks on the system’s vulnerabilities.

TVRA is specifically designed for data networks and telecommunications networks, making it challenging to apply to the security system analysis of vehicles.

FMVEA

FMVEA, the abbreviation for “Failure Mode, Vulnerabilities and Effects Analysis,” is a method based on FMEA described in IEC 60812 [4]. Schmittner et al. [38][39] proposed this failure mode and effect model for causal analysis of security safeguards. This work categorizes threats by quantifying threat agents (i.e., attackers), threat mode (using STRIDE model), threat effects, and attack probability. A common limitation of this analysis is that it only analyzes a single cause of one effect and overlooks multi-stage attacks. Therefore, FTA and ATA are considered to support FMVEA.

FMVEA is based on FMEA and is not suitable for TARA work in the early development stage (Concept Phase).

Conclusion

This article introduced the information security regulations and standards that are currently widely used in the automotive industry and analyzed the applicability of SAE J3061 proposed by SAE and ISO-SAE jointly proposed ISO-SAE 21434, determining that the methods and steps defined by these two regulations can be used to analyze the TOE involved in FOTA.

This article also conducted a comprehensive analysis of relevant risk assessment methods and technologies for contemporary information security and summarized the characteristics of various methods and technologies. Based on the analysis of the advantages and disadvantages of various methods and technologies in section 3, they can be summarized in the following table:

Table 6 Comparison of Automotive Information Security Evaluation Methods

According to the analysis results in the table above, it is not enough to use a single technology to conduct information security analysis of the car system. It is necessary to combine their respective advantages.

Based on the follow-up research content of the project, it is necessary to identify the information security risks in the ECU data initialization process with FOTA function during the production stage, define corresponding information security requirements, and design production line methods, processes and steps according to the requirements. ISO-SAE 21434 specification clearly requires that the implementation of ECU production-related tools and environments should be considered throughout the entire life cycle. Therefore, information security evaluations should also be implemented during the production stage of the ECU.

Due to its suitability for whole life cycle analysis and the ease of combining with STRIDE and ATA, the HEAVENS security model is suitable for follow-up analysis work. In the future, the HEAVENS security model will be improved to adapt to the information security requirements in the production stage and combined with STRIDE and ATA to conduct information security analysis of ECU production line development in the conceptual stage and system design stage.

References:

[1] Ouyang Jinsong, Ding Lu. Overview of IEC 62443 industrial network and system information security standards. Information Technology and Standardization, 2012, 3:24-27.

[2] ISO Std. ISO:26262: Road Vehicles-Functional safety. International Standard ISO 26262 (2018).

[3] ISO Std. ISO:21434: Road Vehicles-Cybersecurity engineering. International Standard ISO 21434 (Under development).

[4] IEC 60812, Analysis techniques for system reliability – Procedure for failure mode and effects analysis (FMEA), 2006.

[5] IEC 61025, Fault tree analysis (FTA)[M]. 2006.

[6] ISO-20078-3 Extended vehicle (ExVe) web services-Part 3 Security, International Standard ISO 20078-3 (2019)- [7] ISO 20828: Road vehicles — Security certificate management. International Standard ISO 20828 (2006).

• [8] SAE International: SAE J3061-Cybersecurity Guidebook for Cyber-Physical Automotive Systems. SAE-Society of Automotive Engineers (2016).

• [9] SAE International: SAE J3061A-Cybersecurity Guidebook for Cyber-Physical Automotive Systems. SAE-Society of Automotive Engineers (Under development).

• [10] SAE International: SAE J3101 Requirements for Hardware-Protected Security for Ground Vehicle Applications (2020)

• [11] SAE International: SAE J3138 Guidance for Securing the Data Link Connector (DLC) (2018).

• [12] ITU-T: X.1373 (2017.03), Secure software update capability for intelligent transportation system communication devices，Accessed on Jan 8, 2020, [Online]

• [13] ITU-T: Security guidelines for V2X communication systems, Accessed on Jan 8, 2020, [Online]- [14] ITU-T: Security requirements for vehicle accessible external devices, Accessed on Jan 8, 2020, [Online]: itu.int/itu-t/workprog/

• [15] ITU-T: Methodologies for intrusion detection system on in-vehicle systems, Accessed on Jan 8, 2020, [Online]: itu.int/itu-t/workprog/

• [16] ITU-T: Security guidelines for vehicular edge computing, Accessed on Jan 8, 2020, [Online]: https://www.itu.int/ITU-T/workprog/wp_item.aspx?isn=14396]

• [17] ITU: Security guidelines for the Ethernet-based in-vehicle networks, Accessed on Jan 8, 2020, [Online]: itu.int/itu-t/workprog/

• [18] Secretary of TF-CS/OTA UNECE WP29: Draft Recommendation on Cyber Security of the Task Force on Cyber Security and Over-the-air issues of UNECE WP.29 IWG ITS/AD , 2018. Accessed on Jan 9, 2020, [Online]: wiki.unece.org/pages/vi- [19] Secretary of TF-CS/OTA UNECE WP29. Draft Recommendation on Software Updates of the Task Force on Cyber Security and Over-the-air issues – draft version, 2019. Accessed on Jan 9, 2020, [Online]: unece.org/fileadmin/DAM.

• [20] ETSI. ETSI TS 102 731 V1.1.1 (2010-09) Intelligent Transport Systems (ITS); Security; Security Services and Architecture.

• [21] ETSI. ETSI TS 102 940 V1.2.1 (2016-11) Intelligent Transport Systems (ITS); Security; ITS communications security architecture and security management.

• [22] ETSI. ETSI TS 102 941 V1.1.1 (2012-06) Intelligent Transport Systems (ITS); Security; Trust and Privacy Management.

• [23] ETSI. ETSI TS 102 942 V1.1.1 (2012-06) Intelligent Transport Systems (ITS); Security; Access Control.

• [24] ETSI. ETSI TS 102 943 V1.1.1 (2012-06) Intelligent Transport Systems (ITS); Security; Confidentiality services

• [25] National Information Security Standardization Technical Committee Information Security Assessment Standards Working Group. White Paper on Standardization of Automotive Electronic Network Security (2018 version), 2018. Accessed on Nov 23, 2019, [Online]: cesi.ac.cn/images/edito.- [26] John T. Krzeszewski, ISO 21434 current status – Presentation at the 3rd Vector Automotive Cybersecurity Symposium. Accessed: Feb.15.2020, [Online]: youtube.com/watch?

• [27] Zhang Xing. The 9th Meeting of the ISO/SAE Joint Working Group on Automotive Information Security Held in Shenzhen [J]. China Auto, 2019, 000 (003):P.28-29.

• [28] Wikipedia. Accessed on Nov 14, 2019. [Online]: en.wikipedia.org/wiki/I

• [29] Microsoft Corporation. The STRIDE Threat Model, 2005.

• [30] Microsoft Corporation. Accessed: Jan.08.2020, [Online]: microsoft.com/en-us/sec

• [31] U.S. Department of Defense. “Defense Acquisition Guidebook”, Section 8.5.3.3

• [32] Henniger O, Ruddle A, Seudié H, et al. Securing vehicular on-board IT systems: The EVITA project [C]//VDI/VW Automotive Security Conference. 2009.

• [33] ISO/IEC Std., “ISO/IEC 15408: Information technology—Security techniques—Evaluation criteria for IT security”. ISO/IEC, 2005.

• [34] Alberts, Christopher. “Introduction to the OCTAVE® Approach”. Software Engineering Institute, Carnegie Mellon: Pittsburgh. 2003.- [35] M. Islam et al., Deliverable D2 Security models. HEAVENS Project, Deliverable D2, Release 1. Dec. 2014.

• [36] G. Macher, H. Sporer, R. Berlach, E. Armengaud, and C. Kreiner. SAHARA: A security-aware hazard and risk analysis method. In Design, Automation Test in Europe Conference Exhibition (DATE), 2015.

• [37] ETSI. ETSI TS 102 165 V4.2.3 (2011-03) Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Methods and protocols.

• [38] Schmittner C , Gruber T , Puschner P , et al. Security Application of Failure Mode and Effect Analysis (FMEA)
  [C]// International Conference on Computer Safety, Reliability, and Security. Springer, Cham, 2014.

• [39] C. Schmittner, Z. Ma, and P. Smith, “FMVEA for safety and security analysis of intelligent and cooperative vehicles”. Computer Safety, Reliability, and Security. 2014.

This article is a translation by ChatGPT of a Chinese report from 42HOW. If you have any questions about it, please email bd@42how.com.