Security and Communication Networks
Volume 2019 (2019), Article ID 4614721, 35 pages
https://doi.org/10.1155/2019/4614721

Research Article

A Comparative Study of JASO TP15002-Based Security Risk Assessment Methods for Connected Vehicle System Design

Yasuyuki Kawanishi,1,2 Hideaki Nishihara,¹ Daisuke Souma,¹ Hirotaka Yoshida,¹ and Yoichi Hata²

¹SEI-AIST Cyber Security Cooperative Research Laboratory, National Institute of Advanced Industrial Science and Technology (AIST), Osaka, Japan
²Cyber-Security R&D Office, Sumitomo Electric Industries, Ltd., Osaka, Japan

Correspondence should be addressed to Hirotaka Yoshida; hirotaka.yoshida@aist.go.jp

Received 6 July 2018; Revised 12 October 2018; Accepted 11 December 2018; Published 3 February 2019

Guest Editor: Erwin Schoitsch

Copyright © 2019 Yasuyuki Kawanishi et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Abstract.

In recent years, much attention has been paid to autonomous vehicles and security threats on such vehicles have become an important issue. One of these examples is a command injection issue on a gateway ECU, which was reported in 2016. In order to mitigate these threats, the secure design of connected vehicle systems, which is done at the concept phase during development, has become increasingly important in industry. From this perspective, a security guideline such as JASO TP15002 which specifies two concrete methods, CRSS (CVSS Based Risk Scoring System) and RSMA (Risk Scoring Methodology for Automotive System), was made public in 2015. The latest work on the application of TP15002 to the ITU-T X.1373 standard was published in 2017. However, the risk assessment in this publication seems limited. It is not clear from this publication how systematically the risk assessment task in TP15002 can be performed at the implementation level. Another interesting question is how different methods affect the risk scores of connected vehicle systems. In this paper, we focus on the risk assessment phase in JASO TP15002. For a systematic risk assessment, we introduce an idea of asset container and propose to extend CRSS to a novel RSS (Risk Scoring System), RSS-CVSSv3, by appropriately replacing CVSSv2 vulnerability scoring system on which CRSS is based with CVSSv3. To address the above questions, we perform a comparative study on CRSS, RSMA, and RSS-CVSSv3 for multiple use cases such as a CGW (Central Gateway) and a drone, to examine the efficiency and usefulness of our methods. For this comparative purpose, we devise an interesting approach for the refinement of RSMA to the obstacles in comparing CRSS with RSMA.

1. Introduction

1.1. Positioning of This Paper

This paper is an extended version of the paper that appeared in the proceedings of the DECSoS 2017 Workshop [1]. This extended version includes about 200% new material. The main changes and increments are as follows:

(i)Revision of the abstract(ii)Revision of the introduction for better description(iii)Addition of preliminary work regarding general concepts and JASO TP 15002 based(iv)Addition of new problems of difficulty in comparing CRSS and RSMA(v)Addition of new proposals of RSS-CVSSv3 and approach for comparing CRSS and RSMA(vi)Supplementation of all necessary data for case study 1 on connected car system(vii)Addition of a new result on a case study on a UAV (Unmanned Aerial Vehicle) system(viii)Addition of discussions and limitations on our proposals(ix)Supplemental related work.

1.2. The Background and Our Contributions

In recent years, there has been a significant amount of attention devoted to autonomous vehicles. These vehicles have a variety of purposes for which many systems and devices have been developed, ranging from self-driving cars, autonomous robots to aid people in their work in hazardous cities, and UAV which are commonly known as drones.

Recently, it has been known that the security is critical in vehicle systems. Many devices, objects, or entities are highly digitalized and networked in a sense, where vehicle systems can be regarded as Internet-of-Things (IoT) nodes, which allows the users to use various services via Internet. From security point of view, the communication interfaces that allow the vehicles to connect to the Internet can be considered “Entry Points” or “Attack Surfaces” for the attackers to exploit.

Since 2010, researchers have reported attacks on real vehicles, where the attacker can manipulate the control functions in such a way that the car can be controlled in an unintended manner [2, 3]. In 2016, a command injection issue on a gateway ECU, commonly known as the CWE-77 weakness, was reported, for which in CVE 2016-9337 [4] a CVSS Score 6.8, which is computed by means of the formula specified in [5], was assigned.

Regarding the security of the in-vehicle network, in particular, CAN BUS is viewed as a problem [6]. To solve the problem, in [7], the authors studied the new in-vehicle network consisting of several subnetworks, where one subnetwork is connected to another via Central Gateway (CGW).

In addition to the recent hacking of cars, researchers have also found vulnerability in certain types of UAVs (drones), which exploited information security vulnerability in 2015. The attackers took control of driving systems by drones by exploiting sensor systems [8] or interfering with flying functionality by means of attacks via Wi-Fi communications.

For UAVs, although some vulnerabilities were pointed out even before this case [9–11], it is still important to pay attention to these vulnerabilities because UAVs will be incorporated into a larger system, namely, the surrounding environment in the future. For example, the UAV may connect and share its data with other UAVs and the surrounding environmental system [12], or its flight may be controlled in a way that amateurs do not carelessly violate the security and privacy of others [13].

In response to these security concerns, secure design of connected vehicle systems, which is performed at the concept phase during the development, has become increasingly important in industry. From this perspective, a security guideline which incorporates the risk management procedures of information security has been developed [14].

One particularly useful approach is to measure software attack surfaces, which indicate susceptibility to attack. With respect to the security analysis based on attack surface, model-based metrics have recently been developed [15], dealing with the dependability evaluations and the assurance of critical systems.

Regarding IT (Information Technology) security, the concept of risk has been investigated from various perspectives such as risk management [16–18] and risk analysis (cost assessment) [19]. IT security risk assessment is discussed with respect to asset identification, lifecycle clarification, system model definition, and conceptual frameworks for risk assessment [20–23]. There is a document describing the Common Evaluation Methodology (CEM) for Information Technology Security Evaluation, which helps evaluators learn how to apply the CC (Common Criteria) when they perform formal evaluations. ISO/IEC 15408 [24] is based on the security evaluation standard developed by the CC project.

In the automotive industry, several security guidelines and methods have been proposed such as SAE J3061 [25]. JASO TP15002 [26, 27] also deals with high-level methods, as explained in a sequel. In this guideline, unlike in the previous phases, namely, model definition and threat identification, the risk assessment phase has two concrete methods, CRSS (CVSS Based Risk Scoring System) and RSMA (Risk Scoring Methodology for Automotive System). CRSS is a risk evaluation criterion based on CVSS v2 (Common Vulnerability Scoring System), where two metrics Attack Ease and Effect Factor are assigned for each identified threat. RSMA computes the risk score by referencing the Risk Level Decision Table, which consists of Occurrence Possibility and Effect Factor.

To the best of our knowledge, there has been no prior work on these methods in a comparative way, nor on which use case (in one of) these methods work reasonably.

For the last few years, Internet-connected services used in modern vehicles such as cars and drones have received a lot of attention from the public. However, in response to the recent hacking of such services, such as the exploitation of information security vulnerability, the secure design of connected vehicle systems, which is performed at the concept phase during the development, has become increasingly important in industry. From this perspective, a security guideline, JASO TP15002, was made public in 2015. The risk assessment methodology described in TP15002 is applied to the ITU-T X.1373 standard that was published in 2017, dealing with an important security use case, namely, remote software update for vehicles. However, the risk assessment of this work seems limited. The main issues are as follows:

(a)It is not clear how systematically the risk assessment task in TP15002 can be performed at the implementation level.(b)Another interesting question is how different methods affect risk scores of connected vehicle systems. One of the obstacles is the difficulty in comparing CRSS and RSMA.

In this paper, we focus on the risk assessment phase in JASO TP15002. The importance of JASO TP15002 can be explained by the fact that the significant time and effort of a large automotive committee in Japan have been spent as well as their consensus on what has to be taken into account in the product design phase of the automotive development. Another explanation on its importance can be supported by the fact that the methodology of TP15002 is applied to recently developed ITU-T standard X.1373 [28] that addresses one of the most important use cases, over-the-air software updates for the vehicle devices. As a result, TP15002 identified 17 classes of threat on the model of the mobile vehicle gateway.

For a systematic risk assessment, we introduce the idea of an asset container and propose to extend CRSS to a novel Risk Scoring System (RSS)s, RSS-CVSSv3, by appropriately replacing the CVSSv2 (Common Vulnerability Scoring System version 2) vulnerability scoring system on which CRSS is based with CVSSv3. To address the above issues in an objective manner, we perform a comparative study on CRSS, RSMA, and RSS-CVSSv3 for multiple use cases such as a CGW and a drone, to examine the efficiency and usefulness of our methods. For this comparison purpose, we devise an interesting approach of refinement of RSMA to the obstacle in comparing CRSS and RSMA.

As a result, we provide some interesting data which could serve as information for better understanding of original and proposed risk assessment methods. We expect that our research will offer an information basis on which future system designers can choose the most suitable security risk assessments for designs of connected vehicles.

The analysis of our method is efficient enough to minimize reworking the guideline. This saves time by using a format which organizes items which allows an engineer to just write a simple description without any ambiguity.

The Need from Industry. This work is motivated by a need from industry with respect to the implementation of secure system design based on a high-level security guideline, such as JASO TP15002. This need is summarized by conducting a secure system design with appropriate efforts. With a naive implementation of JASO TP15002, the following problems require more effort to keep the quality of the result:

(i)There are nondetailed matters in JASO TP 15002. Thus individual designers have to refine or instantiate these matters in their own ways.(ii)Typically a very large number of threats are identified, which cannot be managed by a designer.(iii)The quality of output, such as granularity, the amount of description, or validity depends on individual designers.

The Industrial Impact. Our work contributes to the secure development of devices such as a CGW, telematics, or end ECUs that play key roles in Over-The-Air (OTA) applications. This is supported by the evidence that JASO TP15002 is used as a risk assessment methodology in the on-going ITU-T development “secure software update capability for intelligent transportation system communication devices” which was discussed in the UNECE World Forum for Harmonization of Vehicle Regulations (WP.29) forum in 2016 [29]. Consequently, we expect that our work will help in reducing efforts for secure system design, with sufficient quality.

Our Contribution. Our first contribution in this paper is for engineering. For system designers who aim to comply with JASO TP15002, we propose the notion of an asset container which leads to a systematic way for secure design, which is consistent over phases 1, 2, and 3, in JASO TP15002. Our approach is to identify gaps between the descriptions in JASO TP15002 and the actual design tasks. Our second contribution in this paper is scientific. We propose a risk assessment method RSS-CVSSv3 based on the well-known vulnerability scoring system CVSS v3 for a reference to future update of JASO TP15002. To pursue our interest in comparing risk assessment methods included in this guideline, we provide an approach to refine RSMA to make the discussion of our risk assessment methods more concrete and more comparative, we focus on particular types of vehicle systems, such as connected cars employing CGW and UAVs.

1.3. Related Work

1.3.1. Vulnerabilities in Cars

Although applying Information Technologies accelerates the evolution of automobiles, it also provides attackers with opportunities to exploit automobiles. As mentioned in [30], implementing intelligent features, especially, like lane keeping assist, may allow critical components, like the steering system, to be controlled from the outside.

In 2010, experimental attacks on actual cars were reported [2, 3]. In those reports, external devices were wired to the in-car network. Attackers could access the network directly; they analyzed traffic and injected fake messages in order to cause irregular behaviors on the car. Furthermore, if the attacker can physically access the car, the attacks are even easier to make. For example, a denial of service attack called the bus-off attack is one of such attacks. Attackers have to use sequences of signals according to the specification, when the car is not physically accessible [31]. Attackers can attack by sequences of signals not according to the specification if they access a car physically [32, 33].

The authors of [2] and [3] discussed remote attacks on actual cars in [34] and [30], respectively. In [30], vulnerabilities in the telematics of a car system and exploits to them were shown in detail. In this case, an attacker could access the telematics easily and send commands to equipment in the car via wireless communication. In 2016, an attack on an actual car was reported by finding a vulnerability assigned CVE 2016-9337 [4] of the Command Injection, for which the CVSS v3.0 Base Score, equal to the RSS-CVSSv3 score, was 6.8. The relevant module was the vehicle’s gateway ECU, which our Case Study 1 dealt with in Section 6. Due to this vulnerability, an attacker installed malicious software by sending messages to the vehicle’s CAN BUS.

With a fake Wi-Fi access point, attackers accessed the target car system, and then they exploited vulnerabilities in the browser [35]. They were then able to control the car even when it was running. The vulnerabilities allowing a remote attack via a cellular network Telematics Control Unit, when present on actual vehicles produced in a certain period, were reported. For one of these vulnerabilities assigned CVE 2018-9318 [36], the CVSS v3.0 Base Score, equal to RSS-CVSSv3 score, is very high, 9.8.

Attacks on specific functionalities of cars using close-range wireless communication have also been revealed. For instance, a car immobilizer is a system that typically requires the presence of a key fob to allow a car to run. An attack where the attacker was able to track car keys by exploiting vulnerabilities in a car immobilizer was reported in [37] in 2012. Cracking car immobilizer systems damages the functionalities and a cracked car system may run without the owner’s key or stop suddenly on a high way [38]. Security concerns in Tire Pressure Monitoring Systems (TPMSs) were reported in [39]. In this case, when messages are communicated, neither authentication nor input validation can take place.

1.3.2. Vulnerabilities in Drones

For many years it has been clear that drones categorized as Unmanned Aerial Vehicles (UAVs) have been used for military purposes of surveillance, but currently drones have become widely known to the public. Companies have given much easier access to drones than before.

In 2017, researchers pointed out that certain drones sold in the market are vulnerable [8].

Consequently, US-CERT summarized these vulnerabilities and informed the public that certain types of drones allow full file permissions to anonymous users by providing FTP access over its own local access points [40].

The vulnerability note VU#334207[40] and CVE-2017-3209[41] assigned to it can be used to achieve several goals, including that the attackers intentionally cause accidents on a drone. In 2015, in Seattle, an accident of this kind actually occurred [42].

1.3.3. Standardization Activities and Security Guidelines

For the automotive industry, several security guidelines and methods have been proposed. SAE J 3061 [25] is a high-level guideline which includes a definition of the lifecycle process, information for existing tools, and methods.

OCTAVE Allegro [43] is a process-driven threat assessment method. It includes methods for threat identification, risk assessment, and the selection of mitigation approaches. The EVITA method [44] refines abstract attacks into concrete attacks through the construction of Attack Trees and the evaluation of the risks of abstract attacks using those Attack Trees. In the EVITA methodology, risk is evaluated by severity, which includes 4 aspects (safety, finance, privacy, and operation) and attack probability based on the framework of Common Criteria (CC) in which system users can specify their security functional requirements.

The term impact in TP 15002 has the same meaning as in EVITA.

Since 2016, there has been an important standardization joint working project between ISO and SAE, namely, ISO/SAE. This standardization activity on cybersecurity engineering, expected to be published as ISO/SAE 21434, adopts the risk-oriented approach. It attempts to specify Cybersecurity Assurance Level (CAL) [45] which indicates the required level of cybersecurity process rigor, though it is now unclear whether CAL will be normative or informative. In the project, the CAL and the methodology to determine the CAL level will be provided for all the systems and devices throughout the entire automotive supply chain.

1.4. Organization

In Sections 2 and 3, we will introduce preliminary work related to this paper. In Section 4, we will identify the problems in previous work and then we propose our method in Section 5. In Sections 6 and 7, we conduct case studies on the secure designs of publicly available automotive systems. Finally, in Sections 8 and 9, we will discuss our approach and our results and explain the limitations of our work. In Section 10, we present our conclusion.

2. Preliminary 1: Concepts and Framework

2.1. Common Concepts Underlying Safety and Security

We consider that safety is relevant in this paper because the risk score systems we address such as CRSS incorporate criticality of safety as impact factor during their computations. In the automotive industry, it is increasingly important to develop methods for evaluating multiple attributes at the same time and to provide useful information on the entire system. For instance, a methodology for modeling automotive software security, privacy, usability, and reliability has been developed by Ford [46].

The perspectives of CIA (Confidentiality, Integrity, and Availability) of security are increasingly important in safety-critical systems and a security-for-safety paradigm is necessary when hazards originate from threats. A considerable amount of published work exists in this area, for example [47–49].

Automotive systems are typically known as safety-critical systems and the system development process follows the standard ISO 26262 [50], which deals with safety issues. In safety-critical systems, several methodologies of safety analysis and design have been established [51–55], but security was not considered. Various analysis and design methods of security have been proposed in Information Technology [43, 48, 56–62]. Safety-critical systems other than automotive systems have begun to consider the relationship between safety and security. In railway control systems, security affects safety and economy [63]. This relationship between safety and security is called “security informed safety” [64]. Thus, in railway control systems, security is analyzed from two aspects, unsafe train movement and no train movement. In the avionic security standard DO-326A [65], security is analyzed independently. Security-related activities refer to the results of safety related activities but not vice versa. In the FP7 research project SESAMO (SEcurity and SAfety MOdelling), security and safety are analyzed independently [66]. Security and safety requirements derived from analysis converge on a trade-off analysis. Thus, in the SESAMO, security and safety are considered at the same level and affect each other. In industrial control systems, several approaches for combining safety and security including the above concepts are also considered [67, 68].

Referring to well-established work in related disciplines [48], here we give a solid foundation for safety and security engineering by recognizing the similarities and differences in these disciplines. In [48], security and safety are defined as follows:

(i)Safety is the degree to which accidental harm is prevented, reduced, and properly reacted to.(ii)Security is the degree to which malicious harm is prevented, reduced, and properly reacted to.

As SAE J3061 showed some overlaps between safety and security exist. But the differences are not entirely clear. For instance, a malicious attack that compromises the integrity of an ECU could eventually lead to accidental harm caused by an operation parameter change in terms of safety. A more generic quality factor that includes these two quality factors is dependability, which is defined as follows:

(i)Dependability [69] is the degree to which various kinds of users can depend on a work product.

Hazard is a situation that increases the likelihood of one or more related accidents [70]. In ISO 26262, a hazard is defined as a potential source of harm caused by the malfunctioning behavior of the item. Note that this definition is restricted to the scope of this standard. A hazard caused by unintended failure and a threat of attacks by attackers can cause harm to assets. More specifically, hazards and threats are defined as follows:

(i)Hazard is the potential source of harm to an asset due to unintended failure of the system. Note that the harm is typically restricted to humans or the environment.(ii)Threat is the potential source of harm to an asset due to attackers.

The information models of safety and security engineering are significantly similar. For this reason, safety and security requirements can be analyzed regarding a risk-oriented, asset-based approach that considers the accompanied hazards and threats from which these assets have to be protected.

In the above definitions, safety deals with hazards, while security deals with attacks. In order to establish a link between safety and security, the “security-for-safety” paradigm can be introduced in the sense that threats (e.g., intentional hacking attempts) cause hazards that are a potential source of harm.

2.2. The ISO/IEC 15408 Framework in Comparison with ISO 26262

In the automotive industry, there has been an increasing need to develop a framework in which security functions are used in reference to the information system field where ISO/IEC 15408 plays a key role. The purpose of ISO/IEC 15408 is to establish security objectives and evaluation procedure for a Target of Evaluation (TOE), which is a statement that counters identified threats and satisfies assumptions.

In the context of the evaluation of IT products, ISO/IEC 15408 [24] provides a framework and defines security concepts. This standard uses the term TOE where there are modules employing the assets to be protected. In this paper, after defining a TOE, threat identification is conducted and security objectives regarding the major threats are considered.

Referring to [71], we explain the similarities and differences between the ISO/IEC 15408 TOE and an ISO 26262 item definition. Regarding the ISO 26262 item, most required parts of the reference, the overview and description of ISO/IEC 15408 TOE, have been already described. However, ISO/IEC 15408 TOE is extended with an overview of the included security features such as the CIA (Confidentiality, Integrity, and Availability) perspectives and the functionality of the ISO 26262 item. Afterwards, hazard analysis and risk assessment are performed so that potential hazards and their operational situations are identified and an Automotive Safety Integrity Level (ASIL) is determined. Then safety goals are determined for hazardous events (the combination of a hazard and an operational situation [50]).

3. Preliminary 2: Security Evaluation in JASO TP15002

Since 2012, the Society of Automotive Engineers of Japan (JSAE), Inc., has developed a standard procedure for security system design, yielding the guideline JASO TP15002. Its purpose is to describe standard procedures that define the security functions. It considers the prevention of unauthorized operations of the functions that transmit the information to control ECUs (e.g., Body Domain ECUs) from servers and other devices.

In JASO TP15002, the secure system design process consists of five phases: TOE definition, threat analysis, risk assessment, defined security objectives, and security requirement selection. The first three phases are related to security evaluation, while the remaining phrases are about the treatment of major security risks. Hence the tasks and deliverables for the first three phases are reviewed in this subsection.

Another example of security design is that Firesmith [72] defines an asset-based risk-driven procedure for the identification and analysis of security requirements, which consists of 13 general steps.

Also ISO/IEC 27005 [73], based on the international standard ISO 31000 for risk management [74], specifies a security risk management process consisting of 5 iterative activities with 3 activities conducted in activities other than the design phase of the product. Security processes in this literature start with identification of the target or the environment. The processes extract threats and then evaluate and prioritize them. Finally the processes decide treatment of threats as requirements.

3.1. Phase 1: TOE Definition

This phase clarifies the structure of TOE as a model. This model is produced from the assets to be protected and from Data Flow Diagrams (DFD) that specify data flows between the modules in TOE. Thus, the model shows the network structures and entry points in the TOE. Next, properties to protect the CIA perspectives are assigned for each asset in the modules. It is important that the functions of an automotive system operate as correctly as expected, and therefore integrity or availability should be ensured for functions. Similarly, confidentiality or integrity should be ensured for the information exchanged among devices, and for external central servers as well. Information used in the sequel, such as lifecycles and modules of the TOE, is also specified in this phase. Finally, all information related to security evaluation is formalized and shared.

3.2. Phase 2: Threat Analysis

Threats together with the situations they occur in are listed exhaustively in this phase. First, assumptions are stated for feasible analysis. It can be assumed that events or situations that may occur logically but do not actually happen for some reasons are ignored in analysis. Next, adverse actions are investigated exhaustively. The situation of an adverse action is identified with 5W perspectives (“Who,” “When,” “Where,” “Why,” and “What,”). These perspectives take values from information identified in Phase 1 (see Table 1). For example, the factor “When” is valued in the lifecycle phases of the TOE. For each combination of entry points and assets, possible adverse actions should be considered. Moreover, organizational security policy is stated in this phase. Regulations or policies that should be treated with but are not derived from the deliverables of Phase 1 are identified.

Table 1: An Example of a Result at Phases 2 and 3 in JASO TP15002.

#
Where
Who
When
Why
What
AE
EF
Risk Value

1
OBD-II
Outsider
In regular use
Maliciously
cause malfunction
3.9
9.2
6.6

3.3. Phase 3: Risk Assessment

This phase estimates the risk levels for all the threats that have been identified in the previous phase. The result tells us about critical threats we have to treat. Two risk evaluation criteria are mentioned in JASO TP15002, namely, CRSS (CVSS v2 [75] Based Risk Scoring System) and RSMA (Risk Scoring Methodology for Automotive Systems). They are reviewed in the following subsections.

In this risk assessment phase, major threats are analyzed more deeply. Using fault trees, a threat is decomposed into combinations of concrete events or situations step by step. Finally basic events, which are the origins of a threat, are identified. We treat threats of TOE by considering the treatment of basic events (conducted in the next phase).

3.3.1. CVSS Based Risk Scoring System

CRSS is a risk evaluation criterion based on CVSS v2 (Common Vulnerability Scoring System version 2). For each threat identified in Phase 2, two metrics, exploitability and impact, are assigned, and the risk value is computed from them. Exploitability depends on how close an attacker must be to the TOE for the attack, how far the entry point is from the asset logically, and how much an attacker must pass authentication to reach the asset. Impact depends on the severity of the threat. Finally, the risk for a threat is categorized into three levels according to the computed risk value: Level III (Critical), Level II (Warning), and Level I (Caution). An example of a result at Phases 2 and 3 in JASO TP15002 is shown in Table 1.

3.3.2. Risk Scoring Methodology for Automotive Systems

In addition to CRSS, JASE also proposed RSMA (Risk Scoring Methodology for Automotive Systems) in JASO TP15002. RSMA is a method adopting the concept defined by ISO/IEC 27005 [73]. It computes the risk score by referencing the Risk Level Decision Table, which consists of Effect Factor and Occurrence Possibility. More specifically, RSMA has the following procedures:

(1)Based on the attack scenario of the threat, decide on the values of the five metrics in the Likelihood list shown in Table 2 (see Section 6.6), sum up their values, and decide on the Occurrence Possibility level with reference to Table 3.(2)Classify the asset to be attacked into three categories (Damage Category), and decide on the Effect Factor.(3)Decide on RSMA Risk Level referring to Table 4.

Table 2: : Occurrence Possibility for RSMA.

Metric
Rank
Value
Definition

Time required
Practical(P)
0
The time required for the attacker to identify and exploit a vulnerability is practical.

(T)
Unrealistic(U)
19
The time required for the attacker to identify and exploit a vulnerability is unrealistic.

Expert knowledge
Nonprofessional(N)
0
Technical expertise is not needed.

(E)
Professional(P)
3
Technical expertise is needed.

TOE knowledge
Open information(O)
0
TOE knowledge is open information.

(TOE)
Limited(L)
3
TOE knowledge is the information that dealers, developers, and manufacturers can obtain.

Closed(C)
7
TOE knowledge is the information that only a limited number of persons can obtain.

Opportunity
Always(A)
0
The attacker can access TOE unrestricted or the access is not needed.

(O)
Limited(L)
4
The attacker can access TOE but the frequency is limited.

Impossible(I)
19
The attacker cannot access TOE.

Device
Off-the-shelf(OS)
0
Hardware and software used for attacks are the off-the-shelf products.

(D)
Special(S)
4
Hardware and software used for attacks are the special products.

Ordered(O)
8
Hardware and software used for attacks are the specially ordered products.

Table 3: Occurrence Possibility Level Assessment Table for RSMA.

Occurrence Possibility Level
Criteria

Large (L)
0 to 14

Medium (M)
15 to 24

Small (S)
25 or higher

Table 4: Risk Level Assessment Table for RSMA.

Damage
Effect Factor
Definition
Occurrence Possibility

category
(EF)

Small
Medium
Large

Safety
None
No effect on humans
0
0
0

Small
Mild
L
L
M

Medium
Severe
L
M
H

Large
Life-threatening
M
H
H

Personal
None
Not personal information/privacy
0
0
0

information/privacy
Small
A single piece of information cannot identify the individual
L
L
M

Large
Information that can identify the individual
M
M
H

Property/corporate
None
No impact on property/corporate value
0
0
0

value
Small
Impact only internally (impact on business: small)
L
L
M

Medium
Impact on customers (impact on business: medium)
L
M
H

Large
Impact on customers and business (impact on business: large)
M
H
H

3.4. Inputs and Outputs at Each Phase in JASO-Based Risk Assessment

The outputs and inputs at each phase in JASO TP15002 and the inputs that we propose in our risk assessment proposals and their relations are shown in Table 6, in Table 5, and in Figure 1, respectively.

Table 5: The Inputs at Each Phase Defined in JASO TP15002 and Our Proposed Inputs(,..., ).

Phase #
Label
Input in the corresponding phase

1

System configuration

1

System function

1

Information/data that the system handles

2

System Preliminary condition

2

System outline

2

TOE Model

2

Module Function List

2

Lifecycle List

3

TOE Model

3

Module Function List

3

Attack Ease for CRSS

3

Effect Factor for CRSS

3

Occurrence Possibility for RSMA

3

Effect Factor for RSMA

3

Exploitability for RSS-CVSSv3

3

Impact for RSS-CVSSv3

3

Occurrence Possibility for Q-RSMA

3

Effect Factor for Q-RSMA

Table 6: Output at Each Phase in JASO TP15002.

Phase #
Label
Output in the corresponding phase

1

TOE Model

1

Module Function List

1

Life-cycle List

2

Assumptions List

2

Threat List

2

Organizational security policies List

3

(Prioritized) Threats List

3

FT

Figure 1: Relation of inputs and outputs including both defined by JASO and the ones that we propose.

4. Observations and Problems

4.1. A Concept Model of JASO TP15002

We have reviewed the concepts in JASO TP15002. Figure 2 shows a partial result; concepts in Phases 1, 2, and 3 are identified and related transversely. All concepts are classified into three groups depicted as packages. The first package system-related information represents information about the entire vehicle system. Concepts in this package are the inputs to the TP15002 process. System outline consists of three concepts: system configuration, system functions, and information that the system handles. The second package TOE system represents information actually dealt with in the TP15002 process. Concepts in this package are determined by referring to concepts in system-related information. Component of the TOE system is a part of TOE system, including entry point as a subconcept. Information flow is a part of TOE system as well. Module function is related to asset to be protected and refers to component of the TOE system. The third package threat information represents the result of risk assessment in TP15002. Threat is determined with the help of concepts in TOE system. Attack Ease (AE) and Effect Factor (EF) are calculated by referring to threat, and they determine risk value as a result. Cause is analyzed for threat when required.

Figure 2: Logical relations in JASO design process (Phase 1 to Phase 3).

Our model makes it clear that there is in-dependency of lifecycle from TOE model. In Phase 2, the lifecycle contributes to the perspectives of “Who” and “When” and thus can be dealt with independently.

4.2. Observations and Problems with Previous Work

We made the following observations and identified the following problems with each phase.

4.2.1. Observation in JASO TP15002 Phase 1

Vehicle systems are typically complex. For instance, a whole car employs up to 70 ECUs, which are connected via various protocols such as CAN. It is possible that the in-vehicle devices are developed by different suppliers and vendors. Therefore, the way to form a TOE model depends on them. This means that the TOE could be very different and the model may not be elaborated in a suitable manner. Since a TOE model consists of just functions (and assets in them) and information flows, systems dealing with them in vehicles can be TOEs in general. For instance, it is reasonable that car manufactures consider the whole car as the TOE. However, some suppliers consider only a group of in-vehicle devices responsible for infotainment as the TOE. We observe that, even when there are two TOEs (the whole vehicle and some parts of it) for the same vehicle, it is important to the outcomes of the security design that these two TOEs are consistent with each other and any interactions have to be clear.

4.2.2. Problems in JASO TP15002 Phase 2

Phase 2 of JASO TP15002 suggests that the 5W (“Who,” “When,” “Where,” “Why,” and “What”) perspectives should be considered at the same time for each threat. However, we encounter a problem, namely, the difficulty in exhaustively identifying all the possible threat descriptions from the perspectives of “Where” and “What.”

We point out that this difficulty originates from ambiguity in the definitions of the 5W characteristics. More specifically, there is a problem with the definition of “What,” specifically, what the attacker does. The description for the perspective of “What” could be ambiguous or abstract such as ‘breaking the central gateway;’ hence, the threat identification (Phase 2) might be performed in an ad hoc manner. This could result in producing useless and unnecessary descriptions (data) of threats for Phase 3. On the other hand, important threats might not be identified as a consequence of this ad hoc search and the entire process might end up with a reworking of Phase 2. The 5W method can identify few hundreds or even thousands of threats. Phase 2 might not be performed in a systematic manner; therefore, an exact description of “What” is unclear. Another problem is that it is unclear how logically and closely this phase task is related to tasks in Phase 1 and Phase 3. More specifically, a question arises as to which metric for risk assessment is related to “Where,” “When,”..., or, “What.”

4.2.3. Problems in JASO TP15002 Phase 3

CRSS specified in JASO TP15002 is based on the CVSS v2 vulnerability scoring system that was published in 2007. However, CVSS v3 has also been published. Therefore it is necessary to consider whether CRSS is suitable for current or future vehicle systems. RSMA, another method, may be more suitable than CRSS. One of the obstacles in determining a suitable method is the difficulty in comparing CRSS and RSMA.

4.2.4. Problem in Application of JASO TP15002 to ITU-T X.1373

The latest work on JASO TP15002 can be referred to in the ITU-T X.1373 [28] standard that was published in 2017, dealing with an important security use case, namely, remote software updates for vehicles. The standard defines TOE for VMG (Vehicle Mobile Gateway) which is recognized as a key component of a secure software update.

The problem we identified with this work is that the investigation of the risk assessment seems limited. The TOE contains only one module, VMG, which supports nine functions that include mobile communication function, software get function, remote software update function, GPS reception function, Wi-Fi connection function, USB connection function, CAN communication function, CAN gateway function, and OBD connection function, each of which has one asset or a few assets. The threat analysis result shows the relatively small number of 19 threats. In addition, the risk scores are computed for only 3 threats.

This work is reasonable for the purpose of grasping the idea of how the JASO-defined 3-phase risk methodology works. However, in practice, the system is likely to be more complex. There is an important gap between this work and a thorough study. It is not clear how systematically the risk assessment task in TP15002 can be performed at the implementation level. Another interesting question is how different methods affect the distribution of risk scores for the same connected vehicle system.

4.3. A Taxonomy Observation of the JASO Design Process

Our analysis identified a problem with the JASO design process by investigating the well-known dependability taxonomy dealing with safety and security described in Section 2 based on [48]. As mentioned there, some security threats cause failure in the target system, which is a concern in safety. Indeed, in our case study in Section 6, the threat that control function in Chassis module suffers from a malware is identified. This threat can easily cause an accident in a vehicle.

JASO TP15002 describes the CIA perspectives of security but it does not show a link to safety. In addition, although JASO TP15002 focuses on security, its method allows us to pick up safety-related threats. Hence it is worth distinguishing safety-related threats in threat analysis, and letting safety evaluation refer to the result.

5. Our Proposed Methods

In this section, we propose our methods for solving the problems stated in the previous section. Our methods include an efficient and systematic way of implementing the 3-phase risk assessment methodology specified in the JASO TP15002 guideline.

5.1. Proposed Notion: An Asset Container for a Systematic Approach in Phases 2 and 3

To solve the problem stated in the previous section, we propose a new description for “What” using “At” (attack destination) and “Asset” (the targeted asset) at the threat analysis phase (Phase 2). Our objective is to improve the efficiency of the total work of Phase 2 (threat identification) and Phase 3 (risk evaluation).

Our idea behind this approach is that the Phase-2 work identifies threats in a systematic manner and this work only outputs a list of threats whose description contains information necessary and useful for the risk-score computation in Phase 3.

The perspective of “Where” represents one of the entry points in JASO TP15002, but, in our approach, the perspective of “What” describes what asset of what asset container is attacked. Next, we define the asset container as a module that contains the assets to be targeted as the “At” perspective (see Figure 3).

Figure 3: Our idea of an asset container.

Therefore, it is important to distinguish these two perspectives strictly from the beginning of Phase 2. On the other hand, only two perspectives, “Where” and “What”(= “At” + “Asset”) are necessary to cover all threats, and the remaining three are not necessary up to Phase 3. Though a division of “What” into “At” and “Asset” is added, the number of perspectives for risk analysis drops from five to three, so the workability will be increased.

In our paper, by considering the interdependency we described in the previous section, we propose a 2-step threat identification as follows.

Step 1. Exhaustively identify threats, each of which describes the following three perspectives: “Where,” “At,” and “Asset.”

Step 2. For the identified threats, identify associated threats each of which adds descriptions of the following three perspectives: “Who,” “When,” and “Why.”

Step 1 refers to the TOE model and the module function list, both of which have been produced at Phase 1 in the JASO design process. Step 2 refers to the lifecycle list, which has been produced at Phase 1 in the JASO design process.

After applying the above two steps, our method outputs information shown in Table 7 which includes the data produced by Phases 2 and 3 in JASO TP 15002.

Table 7: An Example of Data Produced by Our Method.

#
Where
Who
When
Why
What (At, Asset)
AE
EF
Risk Value

1
OBD-II
Outsider
In regular use
Maliciously
cause malfunction (CGW, Control function)
3.9
9.2
6.6

Advantage of Our Method. Our method has three advantages over a naive implementation of JASO:

(i) From a working procedural perspective, we make progress in formalizing a security evaluation job. Our method can, especially, separate this job into two tasks, thus enabling an optimization of this job in the sense that our method can refactor in factors necessary for risk assessment. By introducing an asset container which covers “At” and “Asset” in addition to the“What” perspective, all intrusion routes are clearly and systematically identified and all attack targets can be grasped without exception.(ii) From a delivery perspective, our method can improve the quality of the delivery (output) of security because we can remove ambiguity from the threat descriptions. An advantage may exist that encompasses all threats and an accurate computation of risk scores for each can be realized.(iii) From an operational perspective, we propose our method as a practical technique that makes clear what the developer and the factory operator who are not necessarily security specialists should keep in mind.

5.2. Proposed Method: RSS-CVSSv3

We propose a novel risk assessment method, RSS-CVSSv3: The risk scoring system used CVSS version 3 in place of CVSS version 2 of CRSS.

5.2.1. The Idea Inspired by the CRSS Construction

We take a close look at CRSS based on CVSS metrics. We notice that this method makes a clear distinction between what the system designers can take into account during the concept phase and what has to be taken into account after the release of the product to the market. Our view is that this is why CRSS metrics only include six CVSS v2 base metrics (AV, AC, Au, C, I, and A) that are reasonably considered during the concept phase while these metrics exclude CVSS v2 metrics categorized as three temporal or five environmental metrics. We observe that this distinction comes from the important difference between what risk assessment is in the context of security design and what vulnerability analysis is. We note that the former is within the scope of CRSS and the latter is within the scope of CVSS.

As mentioned above, JASO TP15002 adopts CRSS as the quantification method for risk assessment at Phase 3. However, CVSS used for CRSS (version 2)[76] has a new version (version 3)[5]. Many security standards or guidelines have been updated to mitigate security attacks. These standards have only got better and new vulnerabilities are reported on a daily basis. It is natural for us to assume that TP 15002 could be updated to address the latest trends of vulnerability in the future.

5.2.2. RSS-CVSSv3 Score Computation

Against this background we propose a novel risk assessment method, namely, RSS-CVSSv3, based on applying the scoring systems, CVSSv3 (Common Vulnerability Scoring System version 3), which is a new system that scores vulnerability in embedded systems and standardized in ITU-T X.1521(03/2016)[5].

The idea is to include only the basic metrics of CVSSv3 shown in Table 8 because our focus is on security design rather than vulnerability analysis. Compared with CVSSv2, there are some changes of metrics in CVSSv3. To illustrate this, Table 8 also shows some differences of the base metrics between the two standards.

Table 8: CVSSv3 Basic Metrics [5] and Changes from CVSSv2.

Metric
Name
Short Description
Changes from CVSSv2

AV
Attack vector
This metric reflects the context by which vulnerability exploitation is possible.
Same metric

AC
Attack Complexity
This metric describes the conditions beyond the attacker’s control that must exist in order to exploit the vulnerability
Same metric, but rank reduced (3 2).

PR
Privileges Required
This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability.
Expanded from Au (Authentication), and rank reduced (3 2).

UI
User Interaction
This metric captures the requirements for a user, other than the attacker, to participate in a successful compromise of the vulnerable component.
New metric. Whether a user (other than attacker)’s interaction is necessary for successful exploitation.

S
Scope
refers to the collection of privileges defined by a computing authority (e.g., an application, an operating system, or a sandbox environment) when granting access to computing resources (e.g., files, central processing unit (CPU), memory, etc.).
New metric. Whether the vulnerability spreads to other resources beyond the exploited component.

Im-C
Confidentiality Impact
This metric measures the impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability.
Same metric, only renamed from EF-C.

Im-I
Integrity Impact
This metric measures the impact to integrity of a successfully exploited vulnerability
Same metric, only renamed from EF-I.

Im-A
Availability Impact
This metric measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability
Same metric, only renamed from EF-A.

“S”(Scope) is a new metric of CVSSv3, which indicates whether the vulnerability spreads to other resources beyond the exploited component, and from which the formula changes a little. As Scope is unchanged normally, the formula of RSS-CVSSv3 is similar to that of CRSS.

The Formula for RSS-CVSSv3: Based on [5], the score is calculated as follows, depending on parameter .

If the Scope is Unchanged(S=U):

Else if the Scope is Changed(S=C):

5.3. Proposed Approach for Comparing CRSS with RSMA

RSMA is a system that evaluates risk based on an attack scenario and the environment of the attacker, whereas CRSS is a system that evaluates risk based on the asset to be attacked. Therefore, in this paper we attempt to compare their results and to analyze the causes of the difference.

As mentioned previously, JASO TP15002 adopts CRSS as the quantitative risk assessment method at Phase 3, while RSMA is not quantitative. Therefore, we need to customize RSMA in a way that we can calculate figures as the assessed value, compare their results, and analyze the cause of the differences.

In the following formula we adopt RSMA methodology to our risk scoring system. Hereinafter we refer to this method as Q-RSMA (Quantifiable-RSMA). In the original RSMA, the Occurrence Possibility for a threat is decided by evaluating the sum of metrics at the three levels. Here we apply the values of metrics directly. Four levels for Effect Factor (None, Small, Medium, and Large) are converted in numerical forms. In the formula, the Effect Factor values (0.0, 10.0, 20.0, and 30.0) and the constant (34.0, and 100.0) are decided so that the value takes between 0 and 10 and their histogram has one peak.

This method uses the multiplication of Occurrence Possibility and Effect Factor, whereas CRSS uses the addition of Attack Ease and Effect Factor. RSS-CVSSv3 also uses the addition of Exploitability and Impact. Q-RSMA might have different values and prioritized threat lists from CRSS and RSS-CVSSv3. There is a difference in multiplication and addition. The reason why we choose different approach is that we are interested in how different the results of different risk scoring systems are for the same TOE. We expect that our work will be a good reference for the designers to choose more appropriate risk scoring systems for their TOE.

The Formula for Q-RSMA:

In Table 9 there is an Effect Factor list used for Q-RSMA. The RSMA Effect Factor is numerized in Table 9. This table is added for the quantification of the RSMA result.

Table 9: : Effect Factor for Q-RSMA.

Asset Type
Rank
Value
Description

Safety,
Large
30
The assets related to safety or

Property/
Medium
20
the assets related to the added value of the product

corporate value
Small
10

None
0

Personal information/
Large
30
The assets related to the customer’s private information.

Privacy
Small
10

None
0

6. Case Study 1: A CGW-Employed Connected-Car System

Here we present our results on a case study where the target system is a connected-car system employing CGW as a key component. We apply our method to this case study and then we show the prioritized threats. First, we define the following system specifications of our connected car system:

(i)Functional safety of each ECU is maintained by itself.(ii)Safety is maintained, even if any of the communications between the ECUs is made impossible.(iii)The connected-car system is not automated.

6.1. Results of Phase 1: TOE Definition

As an interface to the outside, there is an on-board diagnostics (OBD) connector, a mobile communication module, a global positioning system/global navigation satellite system (GPS) signal reception device, a wireless fidelity (Wi-Fi), a Bluetooth connection, a CAN connection, a universal serial bus (USB) connector, and a secure digital (SD) connector. Based on the vehicle architecture shown in [77], in Figure 4, TOE is defined as the area surrounded by the dotted line and it communicates with the outside of the vehicle via a connection interface.

Figure 4: : TOE Model.

6.1.1. : TOE Model

(See Figure 4).

6.1.2. : Module Function List

Based on the TOE model, its submodules and assets to be protected are shown in Table 10. As for assets in the CRSS method, their importance is determined from the viewpoints of CIA for security, Confidentiality, Integrity, and Availability.

Table 10: : Module Function List.

#
Module name
Function
Assets to be protected
Confidentiality
Integrity
Availability

1
Power-train
Control functions for driving vehicle related to the Engine, Motor, Fuel,
Control function

✓
✓

Battery, Transmission, etc.
Authentication function

✓
✓

Authentication information
✓
✓

Sensor information

✓

2
Chassis
Control functions for operating vehicle related to Brake and Steering.
Control function

✓
✓

3
Body
Control functions for operating vehicle body equipment related to
Control function

✓
✓

Door locks, Air conditioners, Lights, and Blinkers.
Control input data

✓

4
ADAS
Automatic brake, Lane-keeping control, Intervehicle distance
Control function

✓
✓

control, etc. Functions which bring safety and comfort working
Location information

✓

together with other vehicle control functions.

5
CGW
Functions for integration and transformation of the Ethernet and CAN
Authentication function

✓
✓

(Central Gateway)
communication. At the same time, this module acts as fault diagnosis
Authentication information
✓
✓

port, OBD (On-Board Diagnostics)-II.
Vehicle status information

✓

6
ITS
Functions via roadside-to-vehicle or vehicle-to-vehicle communication,
Authentication function

✓
✓

ETC, ITS (Intelligent Transport System), etc.
Authentication information
✓
✓

Control information

✓
✓

7
Telematics
Functions for remote control services. For example, collection service
Authentication function

✓
✓

for location information, remote door-lock service, remote lighting-on
Authentication information
✓
✓

service, etc.
Personal information
✓
✓

Request information to server

✓
✓

Vehicle status information
✓
✓

8
Infotainment
Functions for information and entertainment. For example, car
Authentication function

✓
✓

navigation systems, audio equipment, key-less entry systems, etc.
Authentication information
✓
✓

6.1.3. : Lifecycle List

After writing the details of the TOE model, we write the lifecycle of TOE, and the people involved with this lifecycle. Table 11 shows the lifecycle list.

Table 11: : Lifecycle List.

Phase
Subphase
Overview
Participants

Plan
-
This is the phase in which the planner and the developers of the car’s manufacture plan their product. They formulate their car’s concept, for example, the scope of user, how to use the services of their car, etc. In addition, they summarize and determine the required specifications of the car which include functional and nonfunctional items. As they evaluate the entire costs of the car system throughout its entire lifecycle at this phase, “the security level” of the system will be decided, as well as how much they can assure the security of their product. It is important for the requirement definitions to include the security requirements and not to include the vulnerabilities.
OEM staff

Development
Product design
This is the phase in which the developers of the car’s manufacture and the parts maker design the hardware and the software based on the requirement definitions of the plan phase, in which they plan the implementation of the car.
Supplier staff

Manufacturing
It is necessary at this phase that “the requirement definitions are correctly implemented in the product,” “the vulnerabilities shall not be included in the product,” and “the vulnerabilities, if included must be detected before the shipment of the product”.
OEM staff
Supplier staff

Operation
Shipping
This is the phase in which the user buys the car through the dealer and drives it. For example, in this phase, the status of the car, such as its location, the downloaded software, the operation history of the user, and the driving history of
Carrier staff

Registration
the car, is collected. Also, when the user buys a second-hand car through the second-hand broker, it is necessary for the broker to consider both what should be kept ongoing (e.g., the latest security patch of the firmware) and what must be erased in advance (e.g., the personal information of the previous owner) of the accumulated information.
Dealer staff
Second-hand broker

Regular use, operation
There are many cases in which multiple users who are not the owner of the car use the car in a short term, for example, for car-sharing, car rental, or as a company car. In these cases, it is also necessary to consider the protection of privacy regarding the previous information about the car, its drivers, and types of contract, etc.
Owner/User
Outsider

Maintenance
Furthermore, it is necessary to build a system which allows the users and owners of the car to know its vulnerabilities if some are found after the shipment. This phase also deals with cooperation between the car dealer, the broker, and the maintenance factory.
Administrator of Server
Maintenance staff

Disposal
-
This is the phase in which the owner sells or discards the car to replace it or it breaks down. Two cases exist in which the owner will let go of the car: (1) the owner sells the car to another person through a second-hand broker, or (2) the owner deletes the car’s registration and throws it away. In this phase certain procedures and confidential data (such as in-person inspection, issuing evidence, etc.) must be confirmed by the owner.
Dismantler
Second-hand broker

6.2. Results of Phase 2: Threat Analysis

We present the results on out threat extraction. In this phase, we confirmed the assumptions and conditions of the TOE modeled at Phase 1 and extracted the threats.

6.2.1. : Assumption List

Before performing this evaluation, we assume that no security functions are employed in CGW because our position is that the security functions to be employed will be made clear after the implementation of the final phase of JASO TP15002. Our study makes clear how we can prioritize the CGW-related threats, by considering all of them related to the entire vehicle structure, which we take as the TOE model.

Table 12 shows the preliminary assumptions in advancing risk assessment, which also include assumptions other than CGW.

Table 12: : Assumption List.

Type
Assumption
Overview

Objective
A.No_Objective_to_CGW
It is assumed that there is no advance security objective for CGW, in order to identify all key threats at the initial stage of security design.

Physical
A.Physical_access_by_Outsider
The “Chassis” module, the “Body” module, and the “ADAS” module are connected to other modules only via an in-car bus, so they are not attacked directly through any physical interfaces.

A.Attack_to_Sensor_Receptor
The “ADAS” module also has radar and sensors as its interface. These receptors from which this module gets the location information are treated as physical interfaces without transmission function.

Human Factor
A.Automatic_drive
The transfer of the driver’s authority is not assumed regarding the use of the functions for automatic drive.

Communication
A.GPA
The communication to Satellite is a one-way (Satellite -> Vehicle), the same as the Sensor.

6.2.2. : Threat List

Table 13 is a part of the threat list made by applying the asset container perspectives. We carefully cover all the combinations of the perspectives of “Where,” “At,” and “Asset,” and ‘add’ or ‘remove’ threats according to other perspectives (e.g., “Who” or “What”) and the assumption list.

Table 13: : Threat List.

#
Where
At
Asset
Who
When
Why
What

1
OBD-II
Power-train
Control function
Maintenance staff
In maintenance
Accidentally
cause malfunction

6
CWC (TPMS)
Power-train
Control function
Outsider
In regular use
Maliciously
cause malfunction

10
DSRC (ITS)
Power-train
Control function
Outsider
In regular use
Maliciously
cause malfunction

31
Mobile (Telematics)
Chassis
Control function
Outsider
In regular use
Maliciously
cause malfunction

32
BT/Wi-Fi/IR (Infotainment)
Chassis
Control function
Outsider
In regular use
Maliciously
cause malfunction

34
SD/USB (Infotainment)
Chassis
Control function
Owner/User
In regular use
Accidentally
infect with malware

52
CWC (TPMS)
ADAS
Control function
Outsider
In regular use
Maliciously
cause malfunction

55
DSRC (ITS)
ADAS
Location information
Outsider
In regular use
Maliciously
write wrong data

56
Mobile (Telematics)
ADAS
Control function
Outsider
In regular use
Maliciously
cause malfunction

64
OBD-II
CGW
Control function
Outsider
In regular use
Maliciously
cause malfunction

69
CWC (TPMS)
CGW
Flow/Storage data
Outsider
In regular use
Maliciously
write wrong data

70
DSRC (ITS)
CGW
Control function
Outsider
In regular use
Maliciously
cause malfunction

72
Mobile (Telematics)
CGW
Control function
Outsider
In regular use
Maliciously
cause malfunction

75
BT/Wi-Fi/IR (Infotainment)
CGW
Flow/Storage data
Outsider
In regular use
Maliciously
write wrong data

77
SD/USB (Infotainment)
CGW
Control function
Owner/User
In regular use
Accidentally
infect with malware

In this case study, 145 threats in total have been extracted, including 15 threats related to CGW.

6.3. Results of Phase 3: Risk Assessment in the CRSS Case

In Phase 3, we prioritize these threats by their risk value, which is quantified by the CRSS method.

In advance, we need to set the criteria for each metric used for CRSS, by which each condition gets a numeric value.

6.3.1. and : Attack Ease and Effect Factor for CRSS

Table 14 shows the metrics and the criteria related to Attack Ease (AE). These AE metrics indicate ease of attack from the viewpoint of the attack route. We allocate a combination of the entry point and the module to the rank of a metric.

Table 14: : Attack Ease for CRSS: Value for Rank of Each Metric defined in [76].

Metric
Rank
Criteria
Value

Access Vector
Local (L)
SD/USB, OBD-II, Radar/Sensor
0.395

(AV)
Adjacent (A)
CWC, BT/Wi-Fi/IR, DSRC, GPA
0.646

Network (N)
Mobile Communication
1.000

Access Complexity
High (H)
3 or more
0.350

(AC)
Middle (M)
2
0.610

Low (L)
1
0.710

Authentication
Multiple (M)
2 or more
0.450

(Au)
Single (S)
1
0.560

None (N)
0
0.704

Table 15 shows the metrics and the criteria related to Effect Factor (EF). These EF metrics indicate the importance of the asset from the viewpoint of the security CIA and the seriousness of the attack when it is successful.

Table 15: : Effect Factor for CRSS: Value for Rank of Each Metric defined in [76].

Confidentiality
Integrity
Availability

#
Module name
Asset to be protected
None
Partial
Complete
None
Partial
Complete
None
Partial
Complete

0.000
0.275
0.660
0.000
0.275
0.660
0.000
0.275
0.660

1
Power-train
Control function
✓

✓

✓

Authentication function
✓

✓

✓

Authentication information

✓

✓
✓

Sensor information
✓

✓
✓

2
Chassis
Control function
✓

✓

✓

3
Body
Control function
✓

✓

✓

Control input data
✓

✓
✓

4
ADAS
Control function
✓

✓

✓

Sensor information
✓

✓

✓

5
CGW
Control function
✓

✓

✓

(Central Gateway)
Flow/Storage data
✓

✓
✓

6
ITS
Authentication function
✓

✓

✓

Authentication information

✓

✓
✓

Control information
✓

✓

✓

7
Telematics
Authentication function
✓

✓

✓

Authentication information

✓

✓
✓

Personal information

✓

✓
✓

Request information to server
✓

✓

✓

Vehicle status information

✓

✓

✓

8
Infotainment
Authentication function
✓

✓

✓

Authentication information

✓

✓
✓

6.3.2. : Prioritized Threat List

Our study identified 145 threats in total, with the top 16 shown in Table 17. 9 threats are classified as the ‘Critical’ risk (Level III). 93 threats are classified as the ‘Warning’ risk (Level II). 43 threats are classified as the ‘Caution’ risk (Level I). Table 16 shows the definition of each risk level.

Table 16: Definition of Risk Level for CRSS [26, 27].

Risk Level
Risk Value

Level III (Critical)
7.0-10.0

Level II (Warning)
4.0-6.9

Level I (Caution)
0.8-3.9

Table 17: : Prioritized Threat List.

#
Where
Who
When
Why
What
(At,
Asset)
AV
AC
Au
AE
EF-C
EF-I
EF-A
EF
Risk Value

117
Mobile (Telematics)
Outsider
In regular use
Maliciously
steal information
Telematics
Authentication information
N
L
S
8.0
C
C
N
9.2
8.47

118
Mobile (Telematics)
Outsider
In regular use
Maliciously
steal information
Telematics
Personal information
N
L
S
8.0
C
C
N
9.2
8.47

72
Mobile (Telematics)
Outsider
In regular use
Maliciously
cause malfunction
CGW
Control function
N
M
S
6.8
N
C
C
9.2
7.95

6
CWC (TPMS)
Outsider
regular use
Maliciously
cause malfunction
Power-train
Control function
A
L
S
5.1
N
C
C
9.2
7.15

7
CWC (TPMS)
Outsider
regular use
Maliciously
interfere with access
Power-train
Authentication function
A
L
S
5.1
N
C
C
9.2
7.15

8
CWC (TPMS)
Outsider
regular use
Maliciously
steal information
Power-train
Authentication information
A
L
S
5.1
C
C
N
9.2
7.15

87
DSRC (ITS)
Outsider
In regular use
Maliciously
steal information
ITS
Authentication information
A
L
S
5.1
C
C
N
9.2
7.15

141
BT/Wi-Fi/IR (Infotainment)
Outsider
In regular use
Maliciously
interfere with access to
Infotainment
Authentication function
A
L
S
5.1
N
C
C
9.2
7.15

142
BT/Wi-Fi/IR (Infotainment)
Outsider
In regular use
Maliciously
steal information
Infotainment
Authentication information
A
L
C
5.1
C
C
N
9.2
7.15

68
CWC (TPMS)
Outsider
in regular use
Maliciously
cause malfunction
CGW
Control function
A
M
S
4.4
N
C
C
9.2
6.81

70
DSRC (ITS)
Outsider
In regular use
Maliciously
cause malfunction
CGW
Control function
A
M
S
4.4
N
C
C
9.2
6.81

74
BT/Wi-Fi/IR (Infotainment)
Outsider
In regular use
Maliciously
cause malfunction
CGW
Control function
A
M
S
4.4
N
C
C
9.2
6.81

63
Radar/Sensor
Outsider
In regular use
Maliciously
cause malfunction
ADAS
Control function
L
L
N
3.9
N
C
C
9.2
6.59

64
OBD-II
Outsider
In regular use
Maliciously
cause malfunction
CGW
Control function
L
L
N
3.9
N
C
C
9.2
6.59

65
OBD-II
Owner/User
In regular use
Maliciously
cause malfunction
CGW
Control function
L
L
N
3.9
N
C
C
9.2
6.59

66
OBD-II
Maintenance staff
In maintenance
Accidentally
cause malfunction
CGW
Control function
L
L
N
3.9
N
C
C
9.2
6.59

This result shows that the more highly evaluated significant asset in the vicinity of the entry point which can be accessed from a remote place is more likely to be attacked.

With respect to CGW, our study makes the following points clear:

(i)Regarding the attack path, the entry point via the telematics leads to a Level III threat. This was not expected before our study. Intuitively, the OBD interface might lead to this kind of threat. However, this is not the case. Some connected cars have already had updated software (and firmware) OTA by using telematics, and the number of cars updated over the air will certainly increase in the future. Attackers will be using the OTA update mechanism to reprogram ECUs to take control of the vehicle. To prevent this attack, authenticity and integrity need to be updated and implemented in CGW. Threats from telematics and attacks to CGW control functions impact safety mechanisms.(ii)From our risk analysis result with respect to CGW, there is no significant bias among the 15 related threats with respect to the interface. This implies that uniform security countermeasures are necessary, in contrast to focusing on protecting attacks via one or a few interfaces (see Table 18).

Table 18: : Risk Analysis with respect to CGW.

#
Where
Who
When
Why
What ( At, Asset )
AE
EF
Risk Value

64
OBD-II
Outsider
In regular use
Maliciously
cause malfunction ( CGW, Control function)
3.9
9.2
6.6

65
OBD-II
Owner/User
In regular use
Maliciously
cause malfunction ( CGW, Control function)
3.9
9.2
6.6

66
OBD-II
Maintenance staff
In maintenance
Accidentally
cause malfunction ( CGW, Control function)
3.9
9.2
6.6

67
OBD-II
Maintenance staff
In maintenance
Accidentally
write wrong data ( CGW, Flow/Storage data)
3.9
6.9
4.9

68
CWC (TPMS)
Outsider
In regular use
Maliciously
cause malfunction ( CGW, Control function)
4.4
9.2
6.8

69
CWC (TPMS)
Outsider
In regular use
Maliciously
write wrong data ( CGW, Flow/Storage data)
4.4
6.9
5.2

70
DSRC (ITS)
Outsider
In regular use
Maliciously
cause malfunction ( CGW, Control function)
4.4
9.2
6.8

71
DSRC (ITS)
Outsider
In regular use
Maliciously
write wrong data ( CGW, Flow/Storage data)
4.4
6.9
5.2

72
Mobile (Telematics)
Outsider
In regular use
Maliciously
cause malfunction ( CGW, Control function)
6.8
9.2
7.9

73
Mobile (Telematics)
Outsider
In regular use
Maliciously
write wrong data ( CGW, Flow/Storage data)
6.8
6.9
6.3

74
BT/Wi-Fi/IR (Infotainment)
Outsider
In regular use
Maliciously
cause malfunction ( CGW, Control function)
4.4
9.2
6.8

75
BT/Wi-Fi/IR (Infotainment)
Outsider
In regular use
Maliciously
write wrong data ( CGW, Flow/Storage data)
4.4
6.9
5.2

76
SD/USB (Infotainment)
Outsider
In regular use
Maliciously
cause malfunction ( CGW, Control function)
2.7
9.2
6.0

77
SD/USB (Infotainment)
Owner/User
In regular use
Accidentally
infect with malware ( CGW, Control function)
2.7
9.2
6.0

78
SD/USB (Infotainment)
Outsider
In regular use
Maliciously
write wrong data ( CGW, Flow/Storage data)
2.7
6.9
4.4

6.4. Results of Phase 3 in the RSS-CVSSv3 Case

As mentioned in Section 5.2.2, we prioritized the threats using the RSS-CVSSv3 method in this case study (see Table 20).

6.4.1. : Exploitability for RSS-CVSSv3

In Table 19, Exploitability list is used for RSS-CVSSv3. Table 19 shows the metrics and the criteria related to exploitability. These exploitability metrics indicate ease of attack from the viewpoint of the attack route similar to the AE metrics in the CRSS method. We allocate a combination of the entry point and the module to the rank of metric.

Table 19: : Exploitability for RSS-CVSSv3: Value for Rank of Each Metric is defined in[5].

Metric
Rank
Criteria
Value

Access Vector
Network (N)
Mobile Communication, GPA
0.85

(AV)
Adjacent (A)
BT/Wi-Fi/IR, DSRC
0.62

Local (L)
OBD-II, Radar/Sensor
0.55

Physical (P)
SD/USB
0.20

Access Complexity
Low (L)
1
0.77

(AC)
High (H)
2 or more
0.44

Privilege Required
None (N)
0
0.85

(PR)
Low (L)
1
0.62 (if Scope=U)

0.68 (if Scope=C)

High (H)
2 or more
0.27 (if Scope=U)

0.50 (if Scope=C)

User Interaction
None (N)

0.85

(UI)
Required (R)

0.62

Table 20: : Prioritized Threat List in the RSS-CVSSv3 Case.

#
Where
Who
When
Why
What
(At,
Asset)
AV
AC
PR
UI
EX
Im-C
Im-I
Im-A
ISC
SC
Risk Value

117
Mobile (Telematics)
Outsider
In regular use
Maliciously
steal information
Telematics
Authentication information
N
L
L
N
2.8
H
H
N
5.2
U
8.01

118
Mobile (Telematics)
Outsider
In regular use
Maliciously
steal information
Telematics
Personal information
N
L
L
N
2.8
H
H
N
5.2
U
8.01

63
Radar/Sensor
Outsider
In regular use
Maliciously
cause malfunction
ADAS
Control function
L
L
N
N
2.5
N
H
H
5.2
U
7.69

64
OBD-II
Outsider
In regular use
Maliciously
cause malfunction
CGW
Control function
L
L
N
N
2.5
N
H
H
5.2
U
7.69

65
OBD-II
Owner/User
In regular use
Maliciously
cause malfunction
CGW
Control function
L
L
N
N
2.5
N
H
H
5.2
U
7.69

66
OBD-II
Maintenance staff
In maintenance
Accidentally
cause malfunction
CGW
Control function
L
L
N
N
2.5
N
H
H
5.2
U
7.69

6
CWC (TPMS)
Outsider
regular use
Maliciously
cause malfunction
Power-train
Control function
A
L
L
N
2.1
N
H
H
5.2
U
7.25

7
CWC (TPMS)
Outsider
regular use
Maliciously
interfere with access
Power-train
Authentication function
A
L
L
N
2.1
N
H
H
5.2
U
7.25

8
CWC (TPMS)
Outsider
regular use
Maliciously
steal information
Power-train
Authentication information
A
L
L
N
2.1
H
H
N
5.2
U
7.25

87
DSRC (ITS)
Outsider
In regular use
Maliciously
steal information
ITS
Authentication information
A
L
L
N
2.1
H
H
N
5.2
U
7.25

141
BT/Wi-Fi/IR (Infotainment)
Outsider
In regular use
Maliciously
interfere with access to
Infotainment
Authentication function
A
L
L
N
2.1
N
H
H
5.2
U
7.25

142
BT/Wi-Fi/IR (Infotainment)
Outsider
In regular use
Maliciously
steal information
Infotainment
Authentication information
A
L
L
N
2.1
H
H
N
5.2
U
7.25

72
Mobile (Telematics)
Outsider
In regular use
Maliciously
cause malfunction
CGW
Control function
N
H
L
N
1.6
N
H
H
5.2
U
6.80

14
Mobile (Telematics)
Outsider
In regular use
Maliciously
cause malfunction
Power-train
Control function
N
H
L
N
1.6
N
H
H
5.2
U
6.80

15
Mobile (Telematics)
Outsider
In regular use
Maliciously
interfere with access to
Power-train
Authentication function
N
H
L
N
1.6
N
H
H
5.2
U
6.80

16
Mobile (Telematics)
Outsider
In regular use
Maliciously
steal information
Power-train
Authentication information
N
H
L
N
1.6
H
H
N
5.2
U
6.80

31
Mobile (Telematics)
Outsider
In regular use
Maliciously
cause malfunction
Chassis
Control function
N
H
L
N
1.6
N
H
H
5.2
U
6.80

56
Mobile (Telematics)
Outsider
In regular use
Maliciously
cause malfunction
ADAS
Control function
N
H
L
N
1.6
N
H
H
5.2
U
6.80

90
Mobile (Telematics)
Outsider
In regular use
Maliciously
steal information
ITS
Authentication information
N
H
L
N
1.6
H
H
N
5.2
U
6.80

139
Mobile (Telematics)
Outsider
In regular use
Maliciously
interfere with access to
Infotainment
Authentication function
N
H
L
N
1.6
N
H
H
5.2
U
6.80

140
Mobile (Telematics)
Outsider
In regular use
Maliciously
steal information
Infotainment
Authentication information
N
H
L
N
1.6
H
H
N
5.2
U
6.80

6.4.2. : Impact for RSS-CVSSv3

: Impact for RSS-CVSSv3 is similar to the EF metrics of as shown in Appendix.

6.4.3. : Prioritized Threat List in the RSS-CVSSv3 Case

Table 20 is the prioritized thread list.

6.5. Results on Comparison of Proposed RSS-CVSSv3 with JASO CRSS

Because CVSSv3 is the evolved system of CVSSv2, the result of RSS-CVSSv3 is similar to that of CRSS. But there are some changes. For example, the number of ranks for the Attack Vector becomes four and the value of the rank “Local(L)” increases (0.395 to 0.55) in RSS-CVSSv3. As a result, the risk assessment result from OBD-II has shifted to the higher level (see Table 21).

Table 21: Comparison of Results: CRSS vs RSS-CVSSv3.

CRSS
RSS-CVSSv3

#
Where
At
Risk Value
Rank
Risk Value
Rank

64
OBD-II
CGW
6.59
13
7.69
2

65
OBD-II
CGW
6.59
13
7.69
2

66
OBD-II
CGW
6.59
13
7.69
2

This is the result obtained by classifying OBD-II as a higher-level network by dividing it from other physical access points such as USB, because exploiting OBD-II can affect a wider range. Since research about attacks via OBD-II has increased in recent years, we think this difference is timely. Furthermore, because the threats that ranked higher are related to CGW, the countermeasures against the CGW are also urgent ( Table 20).

6.6. Results of Phase 3 in the Q-RSMA Case

As mentioned in Section 5.3, we prioritized the threats using the Q-RSMA method in this case study.

Q-RSMA uses the same Occurrence Possibility list used for RSMA; =

Table 22 is the prioritized thread list. From the perspectives of “Who,” “When,” and “Why,” assigned values are always the same. The “Who” is ‘Outsider,’ the “When” is ‘In regular use,’ and “Why” is ‘Maliciously,’ respectively, in all the 14 high risk threats. Hence, these corresponding three columns are omitted from this table.

Table 22: : Prioritized Threat List in the Q-RSMA Case.

#
Where
What
(At,
Asset)
Type
Effect Factor
T
E
TOE
O
D
Risk Value

117
Mobile (Telematics)
steal information
Telematics
Authentication information
Privacy
L
P
N
L
A
OS
9.30

118
Mobile (Telematics)
steal information
Telematics
Personal information
Privacy
L
P
N
L
A
OS
9.30

63
Radar/Sensor
cause malfunction
ADAS
Control function
Property/Value
L
P
N
L
L
OS
8.10

90
Mobile (Telematics)
steal information
ITS
Authentication information
Privacy
L
P
N
C
A
OS
8.10

140
Mobile (Telematics)
steal information
Infotainment
Authentication information
Privacy
L
P
N
C
A
OS
8.10

145
SD/USB (Infotainment)
steal information
Infotainment
Authentication information
Privacy
L
P
N
L
L
OS
8.10

6
CWC(TPMS)
cause malfunction
Power-train
Control function
Safety
L
P
P
L
L
OS
7.20

14
Mobile (Telematics)
cause malfunction
Power-train
Control function
Safety
L
P
P
C
A
OS
7.20

31
Mobile (Telematics)
cause malfunction
Chassis
Control function
Safety
L
P
P
C
A
OS
7.20

56
Mobile (Telematics)
cause malfunction
ADAS
Control function
Property/Value
L
P
P
C
A
OS
7.20

58
BT/Wi-Fi/IR (Infotainment)
cause malfunction
ADAS
Control function
Property/Value
L
P
P
L
L
OS
7.20

72
Mobile (Telematics)
cause malfunction
CGW
Control function
Property/Value
L
P
P
C
A
OS
7.20

73
Mobile (Telematics)
write wrong data
CGW
Flow/Storage data
Property/Value
L
P
P
C
A
OS
7.20

91
Mobile (Telematics)
write wrong data
ITS
Control information
Property/Value
L
P
P
C
A
OS
7.20

Although the top two show the same results as in Table 17, 8 threats are newly replaced. With their tendency to change priority, “Opportunity (O)” and “Device (D)” metrics seem to emphasize the risk value at Q-RSMA. These threats are emphasized because there is enough opportunity to attack and the attack is easy to carry out by remodeling commercial devices.

In addition, depending on the features of Q-RSMA, this method uses multiplication of “Occurrence Possibility and Effect Factor,” and the magnitude of the Effect Factor tends to influence the result significantly. For example, #141 is the fourth highest value tied in Table 17 but is the 141st in the Q-RSMA result (Value=2.30), because the asset “The Authentication Function of Infotainment” is not considered important (property/corporate value = Small) and is one-third the value compared with High (Table 23).

Table 23: Risk Value Comparison at Threat #141.

CRSS
Q-RSMA

#
AV
AC
Au
EF-C
EF-I
EF-A
Value
Type
Effect Factor
T
E
TOE
O
D
Value

141
A
L
S
C
C
N
7.15
Property/Value
S
P
N
C
L
OS
2.30

As mentioned in Table 23, the differences are seen as the method evaluated from the attack scenario or as a quantification method by multiplication compared with CRSS.

6.7. Safety-Related Threats Included the Result of Phase 3 in Each Case

It is interesting that the threats as an output of Phase 3 include some safety-related threats.

Both the threat on the Power-Train ECU (access) and the threat on the Chassis ECU (brake and steering) can be viewed as safety-related threats. In this case study, Threat #6, #14, and #31 are the safety-related threats.

For comparison purposes, we now examine three safety-related threats shown in Table 24, for which the risk values and the prioritized rank are associated. Although there are some differences in risk value between CRSS and RSS-CVSSv3, they are simply rank fluctuations because the classification change of Access Complexity (AC) has been made to CVSSv2 on which CRSS is based. Consequently, we consider that there is no fundamental difference in risk assessment between CRSS and RSS-CVSSv3 regarding these three safety-related threats.

Table 24: Safety-related Threats in Case Study 1.

What
CRSS
RSS-CVSSv3
Q-RSMA

#
Where
At
Asset
Risk Value
Rank
Risk Value
Rank
Risk Value
Rank

6
CWC (TPMS)
Power-train
Control function
7.15
4
7.25
7
7.20
7

14
Mobile (Telematics)
Power-train
Control function
6.58
17
6.80
13
7.20
7

31
Mobile (Telematics)
Chassis
Control function
6.58
17
6.80
13
7.20
7

For each of the three methods that we used in this study, the Impact metrics reflect how important the asset is and the Exploitability metrics reflect the ease and the technical means including the route in which the attack can be mounted from a remote place at any time (by the devices easy to purchase in the Q-RSMA case). Hence, their scores belong to a higher rank in the prioritized threat list in each case. As described above, our proposed methods identified the safety-related threats in this case study.

7. Case Study 2

In this section, we describe the components of the intradrone network formed by the interconnection of the multiple modules in the drone.

There are two reasons why we add this case study:

(i)To verify whether our proposed method can be applied to other systems, that is, not only limited to the automobile industry. Precisely, we are going to confirm whether the anticipated threats are reasonably quantified by our proposed method.(ii)To visualize the threats influenced by new features, which are likely to be applied to automated driving technology. The drone has an autonomous control function in addition to a remote operation function, and we attempt to investigate what threats will be regarded as more important in the future, such as attacks on logs of the sensor information and position information in this case study.

7.1. Results of Phases 1 and 2

7.1.1. : TOE Model

There is prior research on attacks on drones where a threat model is typically established before the actual attacks are described. In [8], the threat model considers an attacker that is within Wi-Fi range of the drone but otherwise has no other direct physical access to the device. In their drone model, drones have Wi-Fi access points for their devices to be connected. According to the authors, it is very common in IoT systems that embedded devices with a Wi-Fi access point are used to communicate with an application in a smart phone.

The sensor regarding altitude, called an optical flow sensor, is used for the drone to attempt to keep the altitude constant. In [78], the authors demonstrate the effectiveness of their optical flow sensor input spoofing attack against certain drones.

On the other hand, in our TOE model, in addition to a wireless communication interface, there are more than one entry point. We also refer to recent research on drones [79, 80].

In Figure 5, TOE is defined as the area surrounded by the dotted line, which realizes communication control as a connection interface to the outside of the drone.

Figure 5: : TOE Model for Our Drone System.

7.1.2. : Module Function List

The Module Function List in TOE is shown and the main security perspectives are Confidentiality (C), Integrity (I), and/or Availability (A) in order to provide security requirements as the goal of security design.

In a drone, sensors such as cameras, altitude sensors, geomagnetic sensors, and navigational systems are typically present. Drones use several kinds of sensors to fly safely. Many of them have Global Navigational Satellite Systems (GNSS) such as GPS receivers. A downward-facing optical flow camera is used to stabilize the drone.

The drone needs to use its sensors to react to its environment in a timely manner. Therefore, for instance, the cameras record video image and send this data to the drone’s navigation system to interpret the video image and trigger commands for navigation.

The battery is critical to flying safely. Lithium Polymer (Li-Po) batteries are known as good technology in terms of energy density, power density, and lifetime use.

7.1.3. : Lifecycle List

Table 26 shows the lifecycle list related to our drone system. This is similar to the case of the connected-car system except that the user performs the maintenance.

7.1.4. : Assumption List

Table 27 shows a description of assumptions. Compared to Case Study 1 (connected-car), the drone is conscious of autonomous movements, and attacks on sensors and the integrity of information necessary for flight are emphasized.

7.2. Results of Phase 3 in the CRSS Case

By applying TP 15002 (CRSS) and our method, our study identified 138 threats on our drone systems. In concrete, we applied our “Asset Container” method to the drone TOE as follows:

(i)Figure 5 showed that the TOE had 7 “Where”(entry points).(ii)Table 25 showed that it had 26 combinations of “At” and “Asset.”(iii)Therefore, it was confirmed that the TOE could be subject to at least kinds of attacks.(iv) kinds of attacks were excluded because the attack from 4 entry points could only attack to each first module (see A.Attack_to_Sensor in Table 27).(v)52 kinds of attacks were added by applying STRIDE method which added the variants of “Who,” “Why,” and “What.”(vi)Finally threats were listed.

Table 25: : Module Function List for Our Drone System.

#
Module name
Function
Assets to be protected
C
I
A

1
CPU
Control function module for flight:
Firmware
✓
✓

(Flight Controller)
(1) Control motors using the Control command from the
Configuration information

✓

Receiver and the Configuration information,
Control function

✓
✓

(2) Keep altitude from the information of the Altitude Sensor,
Control command
✓
✓

(3) Keep direction from the information of the Geomagnetic Sensor,
Data handling function

✓
✓

(4) Send the video image of the Camera to the Storage and the
Status information

✓

Receiver,
Location information
✓
✓

(5) Edit the Status information from the data of the Sensors, the
Position information
✓
✓

GPS, and the Battery, and send it to the Receiver,
Battery information

✓

(6) Flies back automatically if communication is interrupted.
Video image
✓
✓

2
Receiver
Communication functions to access with the Smart Phone:
Authentication function

✓
✓

(Network Interface)
(i) Receive the Control Command,
Authentication information
✓
✓

(ii) Send the Status information and the Video image,
Communication function

✓
✓

(iii) Use wireless communication with authentication
Control command
✓
✓

Status information

✓

Video image
✓
✓

3
GPS
Receive the signal from GPS, and calculate the Location
Receive function

✓
✓

information
Location information
✓
✓

4
Camera
Record the Video image
Recording function

✓
✓

Video image
✓
✓

5
Position Sensor
Calculate the Altitude, Attitude, and Direction of the Drone,
Sensor function

✓
✓

(Altitude, Attitude, Direction)

Position information
✓
✓

6
Storage
Store the Video image to the SD-card
Storage function

✓
✓

Video image
✓
✓

7
Li-Po Battery
Supply the power to the Drone and charge the power from the
Charging function

✓
✓

external connector
Battery information

✓

Table 26: : Life Cycle List for Our Drone System.

Phase
Subphase
Overview
Participants

Plan
-
This is the phase in which the planner and the developers of the manufacturer plan their product. They formulate their product’s concept, for example, the scope of user, how to use the services of their product in the field. They also summarize and determine the required specifications of the product which includes functional and nonfunctional items. They evaluate the entire cost of the product throughout its entire life cycle at this phase, and decide on both the safety level and “the security level” of the product in addition to the safety of the product. It is important for the requirement definitions to include the security requirements and not to include the vulnerabilities.
Supplier staff

Development
Product design
This is the phase in which the developers of the drone’s manufacture and the parts maker design the hardware and the software based on the requirement definitions of the plan phase, where they implement and manufacture the
Supplier staff

Manufacturing
product. It is necessary at this phase that “the requirement definitions are correctly implemented in the product,” “the vulnerabilities shall not be included in the product,” and “the vulnerabilities, if included must be detected before the shipment of the product.”
Supplier staff

Operation
Shipping
This is the phase in which the user buys the drone through the agency of the manufacture (or rents the drone through a
Carrier staff

Registration
rental lease company), and flies it. For example, the user operates the drone, collects various information such as video images, Also when a user buys the second-hand drone through a second-hand broker, it is necessary for the broker to consider both what should be kept ongoing (e.g., the latest security patch of the firmware) and what must be erased in advance (e.g., the personal information of the previous owner) of the accumulated
Agency staff
Second-hand broker
Rental lease company’s staff

Regular use, operation
information. In the case of a rental lease, it is also necessary for the user to check if all recorded video images and private information are erased. And it is also necessary for the agency staff to let the user know of the vulnerabilities
User
Outsider

Maintenance
if some are found after the shipment.
Agency staff User

Disposal
-
This is the phase in which the user sells or discards the product to replace it or if it breaks down. There are two cases to let go the product, one is the case that the owner sells the product to other user through the second-hand broker, the other is the case that the user makes it scrapped. Anyway, it is necessary some procedures (in-person inspection, issuing evidence, etc.) that the user can confirm that all confidential data, for example, the private information and the authentication information, are erased.
User
Dismantler
Second-hand broker

Table 27: : Assumption List for Our Drone System.

Type
Assumption
Overview

System
A.Semi_Self_Control
The TOE has an attitude and altitude control, so the integrity of all information is necessary to assist the user.

Module
A.CPU_Not_Disclosed_Firmware
The firmware is not disclosed and difficult to retrieve for analysis.

A.CPU_Not_Disclosed_Configuration
The configuration information is not disclosed and difficult to retrieve for analysis.

A.Attack_to_Sensor
The attacks to the sensor modules (Camera, Position Sensor, GPS, and Battery) from their entry points (Optical wave, Electromagnetic wave, GPA, and Physical) only influence themselves (single-stage attack only).

Table 28 shows a part of the prioritized threat list for our drone system () where there are 15 threats with risk value, ranging from 7.51 to 9.43, categorized as level III, the most important class of threats. From the perspectives of “Who” and “Why,” the assigned values are always the same. The “Who” is ‘Outsider,’ and the “Why” is ‘Maliciously,’ respectively, in all the 15 high risk threats. Hence these corresponding two columns are omitted from this table.

Table 28: : Prioritized Threat List for Our Drone System.

#
When
Where
What
(At,
Asset)
AV
AC
Au
AE
EF-C
EF-I
EF-A
EF
Risk Value

1
Operation
GPA
Malfunction
GPS
Receive function
N
L
N
10.0
N
C
C
9.2
9.43

2
Operation
GPA
Tampering
GPS
Location information
N
L
N
10.0
C
C
N
9.2
9.43

26
Operation
Wireless
Malfunction
Receiver
Authentication function
N
L
S
8.0
N
C
C
9.2
8.47

27
Operation
Wireless
Leakage
Receiver
Authentication information
N
L
S
8.0
C
C
N
9.2
8.47

28
Operation
Wireless
Malfunction
Receiver
Communication function
N
L
S
8.0
N
C
C
9.2
8.47

10
Operation
Wireless
Tampering
CPU
Firmware
N
M
S
6.8
C
C
N
9.2
7.95

11
Purchase
Wireless
Leakage
CPU
Firmware
N
M
S
6.8
C
C
N
9.2
7.95

13
Operation
Wireless
Malfunction
CPU
Control function
N
M
S
6.8
N
C
C
9.2
7.95

15
Operation
Wireless
Malfunction
CPU
Data handling function
N
M
S
6.8
N
C
C
9.2
7.95

18
Operation
Wireless
Tampering
CPU
Location information
N
M
S
6.8
C
C
N
9.2
7.95

19
Operation
Wireless
Leakage
CPU
Location information
N
M
S
6.8
C
C
N
9.2
7.95

5
Operation
Electromagnetic wave/
Supersonic wave
Malfunction
Position Sensor
Sensor function
A
L
N
6.5
N
C
C
9.2
7.77

29
Operation
Wireless
Tampering
Receiver
Control command
N
L
S
8.0
P
C
N
7.8
7.51

32
Operation
Wireless
Tampering
Receiver
Video image
N
L
S
8.0
C
P
N
7.8
7.51

33
Operation
Wireless
Leakage
Receiver
Video image
N
L
S
8.0
C
P
N
7.8
7.51

In these threats, the entry points for the attackers that come to TOE are mainly GPA and wireless communication, the remote network. Threat #26 corresponds to a lock-out attack [8] where the attacker prevents the legitimate owner of the device from connecting to it.

The threat to the electromagnetic wave and supersonic wave is ranked in, too. This fact indicates the importance of sensors. Also, the attacks targeting information necessary for autonomous flight are also ranked in the top rank. These are the features of our drone system.

7.3. On the Relevance of This Study to Real-World Drone Security

We believe that this study is of practical relevance to real-world Drone Security, so that Threat #27 and Threat #33 in Table 28 are related to the vulnerabilities in commercial drones [8].

In 2016, attacks via optical flow were reported in [78], where the authors demonstrate the effectiveness of this sensor input by mounting spoofing attacks on certain drones. From this point of view, additional relevance can be illustrated by our risk assessment comparison on Threat #6 that exploited sensor input shown in Table 29. It is interesting to us that, for this threat, our proposed RSS-CVSSv3 suggests a higher risk level, namely, three, than the other two methods.

Table 29: Risk Score Comparison for Threat #6 Exploiting the Sensor Input.

#
Who
When
Why
Where
What

CRSS
RSS-CVSSv3
Q-RSMA

(
At
Asset
)
Score, Level
Score, Level
Score, Level

6
Outsider
Operation
Maliciously
Electromagnetic wave/ Supersonic wave
Tampering

Position Sensor
Position information

6.81 Level II
7.05 Level III
6.00 Level II

8. Discussion

8.1. Number of Metrics Necessary for Risk Assessment Methods to Work Properly

It is worth discussing how many metrics a risk assessment method needs for the risk scores to be moderately distributed. Our intuition is that the number of these metrics may be about 5 or 6 based on what our case studies suggest. It seems to us that, if these metrics are classified in an appropriate manner, the resulting risk assessment method including the risk ranking would work properly.

8.2. Evaluation of Assets in the Asset Container Method

However, it does not appear that the risk scores are effectively distributed, in spite of the number of metrics. This ineffectiveness can be illustrated by our case-study example showing that there are six threats whose scores are the same, that is, 7.15 in CRSS, there are nine threats whose scores are the same, 6.80 in RSS-CVSSv3, and there are eight threats whose scores are the same 7.30 in Q-RSMA. One reason why several different threats tend to group in the same risk value could be due to the rough way of classifying the impact related to the asset.

Also, in Q-RSMA, where there are only four values of Effect Factor, the classification of CRSS and RSS-CVSSv3 are also rough, which can be explained because the Impact values are only a few at best, even though the asset values can be selected out of three values for each of the three metrics (Confidentiality, Integrity, and Availability).

It is possible that the other metrics concerning the attack route and method make a difference in the risk score, which does not mean that we can neglect to strictly evaluate the value of each asset.

Our proposed method of an “Asset Container” allows the system developer implementing JASO TP15002 to identify the threats in a systematic manner, without considering how the attack is mounted and what the attack means is. Although it is difficult to cover all attack variations, that is, to imagine the attacker’s potential, we can grasp all the assets and the routes to them. We think that a combination method is preferable, as it ensures comprehensiveness of threats with the “Asset Container” method, prioritizes them in risk assessment, and then attempts to cover means of them by the STRIDE method and so on. Therefore, it is important for us to classify and prioritize the assets at first. For the sake of the developers, different assets corresponding to similar values in the risk assessment phase should be avoided.

8.3. Evaluation of Routes in the Asset Container Method

We have confirmed that the other metrics concerning the attack routes, that is, the metrics of Attack Ease in CRSS and Exploitability in RSS-CVSSv3, were effective in identifying the important threats. Specifically, by comparing Tables 17 and 20, we notice that the rank of threats via OBD-II [31], which have received much attention in recent years, has become higher in RSS-CVSSv3 because the degree of attention to the metric has been changed.

8.4. On the Use of Different Methods for Threat Identification

In this paper, we mainly assume the same method threat identification by means of 5W is used for the existing methods in TP15002 and the proposed methods for risk assessment. It appears to us that the 5W method is suitable for these risk assessment methods in terms of risk score computation. On the other hand, it would be interesting whether we could find desired tradeoffs between time spent in the security design task and the granularity of the result. This could give the designers a variety of choices. We speculate that there are certain designers who would need a rough result with limited time.

9. Limitations

The scope of this research is limited in the sense that we only discuss the results up to Phase 3 in JASO TP15002. Our main focus is on the trend of how the risk values are taken and distributed through the comparison result of risk assessment methods. We are currently considering whether an efficient definition of the security objectives can be realized by efficiently distributing risk values at Phase 4: define security objectives or phase 5: security requirement selection in JASO TP15002. Our discussions in this paper regarding by which operation the risk score is derived from the multiple metrics, addition or multiplication, are limited. The only point we make clear is that the same technical paper TP15002 specifies the different approaches, namely, CRSS and RSMA. CRSS uses addition while RSMA uses multiplication.

10. Conclusion

We have investigated a promising security JASO TP15002 guideline. We have identified the difficulties in carrying out the actual design tasks based on JASO TP15002 and we have proposed a systematic way for implementing the 3-phase risk assessment methodology in the guideline.

For the systematic risk assessment, we introduced the idea of an asset container and proposed extending CRSS to a novel Risk Scoring System (RSS)s, RSS-CVSSv3, by appropriately replacing the CVSSv2 vulnerability scoring system on which CRSS is based with CVSSv3. We performed a comparative study on CRSS, RSMA, and RSS-CVSSv3 for multiple use cases such as a CGW and a drone to examine the efficiency and usefulness of our methods. For this comparison purpose, we devised an interesting approach of refinement of RSMA to the obstacles in comparing CRSS and RSMA. As a result, we have provided some interesting data so that the system developers can have a better understanding on original and proposed risk assessment methods in a comparative manner. We expect that our research will offer an information basis on which the system designers and developers can choose suitable security risk assessments for the future system designers of connected vehicles.

Appendix

A. Inputs for Case Study 1

A.1. : Impact for RSS-CVSSv3

Table 30 shows the metrics and the criteria related to impact of asset if it will be attacked. This impact metric indicates importance of asset from the viewpoint of the security CIA and the seriousness when the attack succeeds, the same as the Effect Factor (EF) at CRSS method.

Table 30: : Impact for RSS-CVSSv3.

Confidentiality
(Im-C)
        Integrity (Im-I)
    Availability (Im-A)

#
Module name
Asset to be protected
None
Low
High
None
Low
High
None
Low
High

0.00
0.22
0.56
0.00
0.22
0.56
0.00
0.22
0.56

1
Power-train
Control function
✓

✓

✓

Authentication function
✓

✓

✓

Authentication information

✓

✓
✓

Sensor information
✓

✓
✓

2
Chassis
Control function
✓

✓

✓

3
Body
Control function
✓

✓

✓

Control input data
✓

✓
✓

4
ADAS
Control function
✓

✓

✓

Sensor information
✓

✓

✓

5
CGW
Control function
✓

✓

✓

(Central Gateway)
Flow/Storage data
✓

✓
✓

6
ITS
Authentication function
✓

✓

✓

Authentication information

✓

✓
✓

Control information
✓

✓

✓

7
Telematics
Authentication function
✓

✓

✓

Authentication information

✓

✓
✓

Personal information

✓

✓
✓

Request information to server
✓

✓

✓

Vehicle status information

✓

✓

✓

8
Infotainment
Authentication function
✓

✓

✓

Authentication information

✓

✓
✓

B. Inputs for Case Study 2

B.1. : Attack Ease

See Table 31.

Table 31: : Attack Ease for Our Drone System.

Metric
Classification
Rank
Criteria
Value

Access Vector (AV):
Distance from threat
Local (L)
Serial, USB, Physical connector
0.395

Adjacent (A)
Optical wave, Electromagnetic wave, Supersonic wave
0.646

Network (N)
Wi-Fi, GPA
1.000

Access Complexity (AC):
Number of penetrations
High (H)
3 or more
0.350

Medium (M)
2
0.610

Low (L)
1
0.710

Authentication (Au):
Number of authentication
Multiple (M)
2 or more
0.450

Single (S)
1
0.560

None (N)
0
0.704

B.2. : Effect Factor for CRSS

See Table 32.

Table 32: : Effect Factor for Our Drone System.

#
Module name
Assets to be protected
        Confidentiality
        Integrity
        Availability

None
Partial
Complete
None
Partial
Complete
None
Partial
Complete

0.000
0.275
0.660
0.000
0.275
0.660
0.000
0.275
0.660

1
CPU (Flight Controller)
Firmware

✓

✓
✓

Configuration information
✓

✓
✓

Control function
✓

✓

✓

Control command

✓

✓
✓

Data handling function
✓

✓

✓

Status information
✓

✓
✓

Location information

✓

✓
✓

Position information

✓

✓
✓

Battery information
✓

✓
✓

Video image

✓

✓

✓

2
Receiver (Network Interface)
Authentication function
✓

✓

✓

Authentication information

✓

✓
✓

Communication function
✓

✓

✓

Control command

✓

✓
✓

Status information
✓

✓
✓

Video image

✓

✓

✓

3
GPS
Receive function
✓

✓

✓

Location information

✓

✓
✓

4
Camera
Recording function
✓

✓

✓

Video image

✓

✓

✓

5
Position Sensor (Altitude, Attitude, Direction)
Sensor function
✓

✓

✓

Position information

✓

✓
✓

6
Storage
Storage function
✓

✓

✓

Video image

✓

✓

✓

7
Li-Po Battery
Charging function
✓

✓

✓

Battery information
✓

✓
✓

Abbreviated Terms

ADAS: | Advanced Driver-Assistance Systems
AE: | Attack Ease
ASIL: | Automotive Safety Integrity Level
AT: | Attack Tree
BT: | Bluetooth (Communication)
CAL: | Cybersecurity Assurance Level
CAN: | Controller Area Network
CEM: | Common Evaluation Methodology for Information Technology Security Evaluation
CC: | Common Criteria
CERT: | Computer Emergency Response Team
CGW: | Central Gateway
CIA: | Confidentiality, Integrity, and Availability
CRSS: | CVSS Based Risk Scoring System
CVSS: | Common Vulnerability Scoring System
CWC: | Close-Range Wireless Communication
DFD: | Data Flow Diagram
DSRC: | Dedicated Short Range Communications
ECU: | Electronic Control Unit
EF: | Effect Factor
FT: | Fault Tree
FTP: | File Transfer Protocol
GPA: | GPS Antenna
GPS: | Global Positioning System
JSAE: | Society of Automotive Engineers of Japan, Inc.
JASO: | Japanese Automotive Standards Organization
IR: | Infrared (Communication)
ITS: | Intelligent Transport Systems
OBD-II: | On-Board Diagnosis second generation
OTA: | Over-The-Air
Q-RSMA: | Quantifiable-RSMA
RSMA: | Risk Scoring Methodology for Automotive system
RSS: | Risk Scoring System
STRIDE: | Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege
TOE: | Target of Evaluation
TPMS: | Tire Pressure Monitoring System
UAV: | Unmanned Aerial Vehicle
VMG: | Vehicle Mobile Gateway.

Data Availability

The data used to support the findings of this study are included within the article.

Disclosure

This paper is an extended version of [1], which appeared in the proceedings of the DECSoS 2017 Workshop.

Conflicts of Interest

The authors declare that they have no conflicts of interest.

Acknowledgments

We would like to thank the anonymous reviewers for their valuable comments and Edit Science, Inc. (http://www.editscience.com/) for English language editing.

References

Y. Kawanishi, H. Nishihara, D. Souma, and H. Yoshida, “Detailed analysis of security evaluation of automotive systems based on JASO TP15002,” in Proceedings of the SAFECOMP Workshops, pp. 211–224, 2017.

K. Koscher, A. Czeskis, F. Roesner et al., “Experimental security analysis of a modern automobile,” in Proceedings of the 31st IEEE Symposium on Security and Privacy, pp. 447–462, May 2010.

C. Miller and C. Valasek, Adventures in Automotive Networks and Control Units, vol. 21, DEFCON, 2013.

NIST, “National vulnerability database,” Tech. Rep. CVE-2016-9337, 2016, https://nvd.nist.gov/vuln/detail/CVE-2016-9337.

ITU, ITU-T X.1521: Cybersecurity information exchange, Vulnerability/state exchange, Common vulnerability scoring system, 2016.

X. Li, Y. Yu, G. Sun, and K. Chen, “Connected Vehicles' Security from the Perspective of the In-Vehicle Network,” IEEE Network, vol. 32, no. 3, pp. 58–63, 2018.

J. Liu, S. Zhang, W. Sun, and Y. Shi, “In-vehicle network attacks and countermeasures: Challenges and future directions,” IEEE Network, vol. 31, no. 5, pp. 50–58, 2017.

J. Valente and A. A. Cárdenas, “Understanding security threats in consumer drones through the lens of the discovery quadcopter family,” in Proceedings of the 2017 Workshop on Internet of Things Security and Privacy (IoT S&P), P. Liu, Y. Zhang, T. Benson, and S. Sundaresan, Eds., pp. 31–36, 2017.

J. A. Yochim, The Vulnerabilities of Unmanned Aircraft System Common Data Links to Electronic Attack, U.S. Army Command and General Staff College, Fort Leavenworth, Kan, USA, 2010.

A. Kim, B. Wampler, J. Goppert, I. Hwang, and H. Aldridge, “Cyber attack vulnerabilities analysis for unmanned aerial vehicles,” in Proceedings of the Infotech@Aerospace Conferences, pp. 1–30, 2012.

K. Hartmann and S. Christoph, “The Vulnerability of UAVs to Cyber Attacks - An Approach to the Risk Assessment,” in Proceedings of the 5th International Conference in Cyber Conflict (CyCon), pp. 1–23, 2013.

C. Lin, D. He, N. Kumar, K.-K. R. Choo, A. Vinel, and X. Huang, “Security and Privacy for the Internet of Drones: Challenges and Solutions,” IEEE Communications Magazine, vol. 56, no. 1, pp. 64–69, 2018.

I. Güvenç, F. Koohifar, S. Singh, M. L. Sichitiu, and D. Matolak, “Detection, Tracking, and Interdiction for Amateur Drones,” IEEE Communications Magazine, vol. 56, no. 4, pp. 75–81, 2018.

S. Fenz and A. Ekelhart, “Verification, validation, and evaluation in information security risk management,” IEEE Security & Privacy, vol. 9, no. 2, pp. 58–65, 2011.

G. Hatzivasilis, I. Papaefstathiou, and C. Manifavas, “Software security, privacy, and dependability: Metrics and measurement,” IEEE Software, vol. 33, no. 4, pp. 46–54, 2016.

M. S. Saleh and A. Alfantookh, “A new comprehensive framework for enterprise information security risk management,” Applied Computing and Informatics, vol. 9, no. 2, pp. 107–118, 2011.

K. Bandyopadhyay, P. P. Mykytyn, and K. Mykytyn, “A framework for integrated risk management in information technology,” Management Decision, vol. 37, no. 5, pp. 437–445, 1999.

R. K. Rainer Jr., C. A. Snyder, H. H. Carr, and R. E. X. K. Rainer, “Risk analysis for information technology,” Journal of Management Information Systems, vol. 8, no. 1, pp. 129–147, 1991.

N. Kolokotronis, C. Margaritis, P. Papadopulou, P. Kanellis, and D. Martakos, “An integrated approach for securing electronic transactions over the Web,” Benchmarking, vol. 9, no. 2, pp. 166–181, 2002.

P. Shedden, R. Scheepers, W. Smith, and A. Ahmad, “Incorporating a knowledge perspective into security risk assessments,” Journal of Information and Knowledge Management Systems, vol. 41, no. 2, pp. 152–166, 2011.

R. Bernard, “Information Lifecycle Security Risk Assessment: A tool for closing security gaps,” Computers & Security, vol. 26, no. 1, pp. 26–30, 2007.

R. A. Botha and J. H. P. Eloff, “Access control in document-centric workflow systems - An agent-based approach,” Computers & Security, vol. 20, no. 6, pp. 525–532, 2001.

P. Shamala, R. Ahmad, and M. Yusoff, “A conceptual framework of info structure for information security risk assessment (ISRA),” Journal of Information Security and Applications, vol. 18, no. 1, pp. 45–52, 2013.

ISO/IEC, ISO/IEC 15408: Information technology – Security techniques – Evaluation criteria for IT security, 2009.

SAE, SAE J3061, Cybersecurity Guidebook for Cyber-Physical Vehicle Systems, 2016.

JASO, TP15002: Guideline for Automotive Information Security Analysis, 2015.

JASO, TP15002: Guideline concerning Automotive Information Security , 2015 (Japanese).

ITU, ITU-T X.1373: Secure Software Update Capability for Intelligent Transportation System Communication Devices, 2012.

World Forum for Harmonization of Vehicle Regulations (WP.29), UN Task Force on Cyber security, and OTA issues (CS/OTA), Draft Recommendation on ‘Secure software update capability for intelligent transportation system communication devices,’, CS/OTA, 2016, https://www2.unece.org/wiki/pages/viewpage.action?pageId=40829523.

C. Miller and C. Valasek, Remote Exploitation of an Unaltered Passenger Vehicle, Black Hat, 2015.

K.-T. Cho and K. G. Shin, “Error handling of in-vehicle networks makes them vulnerable,” in Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security (CCS’16), pp. 1044–1055, October 2016.

R. Kameoka, T. Kubota, M. Shiozaki, M. Shirahata, R. Kurachi, and T. Fujino, “Bus-Off Attack against CAN ECU using Stuff Error injection from Raspberry Pi,” in Proceedings of the Symposium on Cryptography and Information Security (SCIS), Niigata, Japan, 2017 (Japanese).

A. Palanca, E. Evenchick, F. Maggi, and S. Zanero, “A stealth, selective, link-layer denial-of-service attack against automotive networks,” in Proceedings of the International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment, Springer, Cham, Switzerland, 2017.

S. Checkoway, D. McCoy, B. Kantor et al., “Comprehensive experimental analyses of automotive attack surfaces,” in Proceedings of the 20th USENIX conference on Security, 2011.

Q. Luo and J. Liu, “Wireless telematics systems in emerging intelligent and connected vehicles: Threats and solutions,” IEEE Wireless Communications Magazine, pp. 1–7, 2018.

NIST, “National Vulnerability Database,” Tech. Rep. CVE-2018-9318, 2018, https://nvd.nist.gov/vuln/detail/CVE-2018-9318.

S. Tillich and M. Wójcik, “Security analysis of an open car immobilizer protocol stack,” in Proceedings of the Trusted Systems, 4th International Conference, INTRUST 2012, C. J. Mitchell and A. Tomlinson, Eds., vol. 7711 of Lecture Notes in Computer Science, pp. 83–94, Springer, London, UK, 2012.

R. Verdult and F. D. Garcia, “Cryptanalysis of the Megamos Crypto Automotive Immobilizer,” USENIX, vol. 40, no. 6, pp. 17–22, 2015.

I. Rouf, R. Miller, H. Mustafa et al., “Security and privacy vulnerabilities of in-car wireless networks: a tire pressure monitoring system case study,” in Proceedings of the 19th USENIX Conference on Security, p. 21, 2010.

Vulnerability Notes Database, “Vulnerability Note VU#334207 - DBPOWER U818A WIFI quadcopter drone allows full filesystem permissions to anonymous FTP,” 2017, https://www.kb.cert.org/vuls/id/334207.

Common Weakness Enumeration, “CWE-276 - incorrect default permissions,” 2017, https://cwe.mitre.org/data/definitions/276.html.

City of Seattle, “City Attorney's Office prevails in drone case,” 2017, https://news.seattle.gov/2017/01/13/city-attorneys-office-prevails.

R. A. Caralli, J. F. Stevens, L. R. Young, and W. R. Wilson, “Introducing OCTAVE allegro: improving the information security risk assessment process,” Tech. Rep. CMU/SEI-2007-TR-012, 2007.

A. R. Ruddle, D. Ward, B. Weyl et al., “Security requirements for automotive on-board networks based on dark-side scenarios,” E-Safety Vehicle Intrusion Protected Applications (EVITA), 2009.

A. Barber, “Status of work in process on ISO/SAE 21434 automotive cybersecurity standard,” 2018, https://www.sans.org/summit-archives/file/summit-archive-1525889601.pdf.

K. V. Prasad, T. J. Giuli, and D. Watson, “The Case for Modeling Security, Privacy, Usability and Reliability (SPUR) in Automotive Software,” Model-Driven Development of Reliable Automotive Services LNCS 4922, 2008.

B. Dobbing and S. Lautieri, “SafSec Methodology: Standard,” Praxis High Integrity Systems, no. 3.1, S.P1199.50.2, 2006.

D. G. Firesmith, “Common concepts underlying safety, security, and survivability engineering,” Tech. Rep. CMU/SEI-2003-TN-033, Software Engineering Institute, 2003.

G. Macher, E. Armengaud, E. Brenner, and C. Kreiner, “Threat and Risk Assessment Methodologies in the Automotive Domain,” in Proceedings of the 7th International Conference on Ambient Systems, Networks and Technologies (ANT 2016) / The 6th International Conference on Sustainable Energy Information Technology (SEIT-2016) / Affiliated Workshops, vol. 83 of Procedia Computer Science, pp. 1288–1294, Elsevier, 2016.

ISO, ISO 26262: Road Vehicles – Functional Safety, 2011.

IEC, IEC 61025 Fault Tree Analysis (FTA), 2006.

IEC, IEC 60812 Analysis Techniques for System Reliability-Procedure for Failure Mode and Effects Analysis (FMEA), 2006.

IEC, IEC 61882 Hazard And Operability Studies (HAZOP Studies)-Application Guide, 2001.

C. A. Ericsson, Hazard Analysis Techniques for System Safety, John Wiley & Sons, 2015.

N. G. Leveson, Engineering A Safer World: Systems Thinking Applied to Safety, MIT Press, 2011.

“Introduction to Microsoft Security Development Lifecycle (SDL) Threat Modeling,” https://www.microsoft.com/en-us/sdl/default.aspx.

B. Schneier, “Attack Trees: modeling security threats,” Dr. Dobb’s Journal, vol. 24, no. 12, pp. 21–29, 1999.

B. Kordy, S. Mauw, S. Radomirovic, and P. Schweitzer, “Foundation of Attack-Defense Trees,” in Proceedings of the International Workshop on Formal Aspects in Security and Trust, Springer, 2010.

A. Roy, D. S. Kim, and K. S. Trivedi, “Attack countermeasure trees (ACT): Towards unifying the constructs of attack and defense trees,” Security and Communication Networks, vol. 5, no. 8, pp. 929–943, 2012.

G. Sindre and A. L. Opdahl, “Eliciting security requirements with misuse cases,” Requirements Engineering, vol. 10, no. 1, pp. 34–44, 2005.

J. P. McDermott and C. Fox, “Using abuse case models for security requirements analysis,” in Proceedings of the 15th Annual Computer Security Applications Conference, IEEE Computer Society, pp. 55–64, Phoenix, Ariz, USA, 1999.

T. Okubo, K. Taguchi, H. Kaiya, and N. Yoshioka, “MASG: Advanced misuse case analysis model with assets and security goals,” Journal of Information Processing, vol. 22, no. 3, pp. 536–546, 2014.

UK Department for Transport, Rail Cyber Security Guidance to Industry, 2016.

K. Netkachova and R. E. Bloomfield, “Security-Informed Safety,” The Computer Journal, vol. 49, no. 6, pp. 98–102, 2016.

RTCA, DO-326A Airworthiness Security Process Specification, 2014.

SESAMO, “Security and Safety Modelling,” 2015, http://sesamo-project.eu.

S. Kriaa, L. Pietre-Cambacedes, M. Bouissou, and Y. Halgand, “A survey of approaches combining safety and security for industrial control systems,” Reliability Engineering & System Safety, vol. 139, pp. 156–178, 2015.

S. Kriaa, Joint Safety and Security Modeling for Risk Assessment in Cyber Physical Systems [Diss.], Université Paris-Saclay, 2016.

A. Avizienis, J.-C. Laprie, B. Randell, and C. Landwehr, “Basic concepts and taxonomy of dependable and secure computing,” IEEE Transactions on Dependable and Secure Computing, vol. 1, no. 1, pp. 11–33, 2004.

N. G. Leveson, Safeware: System Safety and Computers, Addison-Wesley, 1995.

C. Schmittner and Z. Ma, “Towards a Framework for Alignment Between Automotive Safety and Security Standards,” in Proceedings of the SAFECOMP, LNCS 9338, pp. 133–143, 2015.

D. Firesmith, “Specifying reusable security requirements,” The Journal of Object Technology, vol. 3, no. 1, pp. 61–75, 2004.

ISO/IEC, ISO/IEC 27005: 2011 Information Technology – Security Techniques – Information Security Risk Management, 2011.

ISO, ISO 31000: Risk Management – Principles And Guidelines, 2009.

ITU, ITU-T X.1524: Cybersecurity Information Exchange –Vulnerability/State Exchange, Common Weakness Enumeration, 2012.

ITU, ITU-T X.1521: Cybersecurity Information Exchange, Vulnerability/State Exchange, Common Vulnerability Scoring System, 2011.

Y. Miyashita, H. Yasukawa, I. Kurosaki, T. Matsuo, S. Horihata, and N. Kobayashi, “On-vehicle compact and lightweight multi-channel central gateway unit,” SEI Technical Review, no. 83, pp. 5–9, 2016.

D. Davidson, W. Hao, R. Jellinek, T. Ristenpart, and V. Singh, “Thomas Ristenpart, and Vikas Singh, Controlling uavs with sensor input spoofing attacks,” in Proceedings of the 10th USENIX Workshop on Offensive Technologies, (WOOT 16), N. Silvanovich and P. Traynor, Eds., pp. 221–231, 2016.

M. Lichtman, J. D. Poston, S. Amuru et al., “A Communications Jamming Taxonomy,” IEEE Security & Privacy, vol. 14, no. 1, pp. 47–54, 2016.

D. He, S. Chan, and M. Guizani, “Communication Security of Unmanned Aerial Vehicles,” IEEE Wireless Communications Magazine, vol. 24, no. 4, pp. 134–139, 2017.