Present the Ability of Risk Approaches to Adapt to Technology Evolution

Integrated Safety and Cybersecurity Risk Analysis of Cooperative Intelligent Transport Systems

Giedre Sabaliauskaite, Jin Cui, Lin Shen Liew, and Fengjun Zhou Centre for Research in Cyber Security (iTrust) Singapore University of Technology and Design

Singapore 487372, Singapore

[email protected], jin [email protected], linshen [email protected], fengjun [email protected]

Abstract—Automated Vehicles (AVs), the self driving vehicles, are expected to outperform human drivers and improve road safety in the near future. However, to achieve these goals, they need to communicate with each other and the other road participants and coordinate their actions. The systems of connected cooperative AVs are called Cooperative Intelligent Transport Systems (C-ITS). Similar to AVs, C-ITS are vulnerable to failures and cyberattacks. In our previous work, we proposed a method US2 for AV risk analysis. This paper extends US2 and presents a method for integrated C-ITS safety and cybersecurity risk analysis. It takes into consideration automotive safety and cybersecurity standards ISO 26262 and SAE J3061, and utilizes the elements of the previously proposed risk analysis methods US2, EVITA, TVRA, and RACE.

Index Terms—automated vehicle, cooperative intelligent trans- port system, safety, security, risk analysis

I. INTRODUCTION

Automated Vehicles (AVs) are the self-driving vehicles.

In AVs, the automated driving system is able to partially

or completely replace a human driver in performing the

driving functions required to operate the vehicle in on-road

traffic. AV technology is promising, as it can help to reduce

commuting time and enable more people to enjoy freedom

of traveling (e.g. elderly and people with disabilities). But,

most importantly, it could help in significantly reducing traffic

injuries and fatalities [1]. However, to achieve these goals, AVs

must be safe and secure. Unfortunately, the first fatal crash of

an AV including pedestrian has been reported in March 2018

[2]. Thus, there is an the urgent need to assure AV safety

and security to prevent such accidents from happening in the

future.

AVs are complex Cyber-Physical Systems (CPSs), which

integrate embedded computing technology into physical phe-

nomena, and therefore they are vulnerable not only to failures,

but also to cyberattacks [3]. Thus, safety and security have to

be considered while developing, testing, and deploying AVs on

public roads [1]. In order to outperform human drivers, AVs

need to communicate with the other traffic participants. The

communications will allow road users and traffic managers to

share and use information to coordinate their actions [4]. The

systems of connected cooperative AVs are called Cooperative

Intelligent Transport Systems (C-ITS) [4] [5]. C-ITS may

include AVs, roadside infrastructure, and other systems.

In Europe, a CAR-2-CAR Communication Consortium

(C2C-CC) has been established with the primary objective of

further increasing road traffic safety and efficiency by means of

C-ITS [6]. C2C-CC has defined a 4-phase roadmap for deploy-

ment of C-ITS: awareness driving phase (vehicles disseminate

only their status information), sensing driving phase (vehicles

exchange their sensor information), cooperative driving phase

(vehicles share their intentions with other traffic participants),

and, finally, synchronized cooperative driving phase (vehicles

exchange and synchronize their driving trajectories to achieve

optimal driving patterns) [5].

C-ITS are vulnerable to failures and attacks just as AVs.

Thus, assuring safety and security of C-ITS is crucial. How

can we assess C-ITS safety and security risks, taking into

consideration the above-mentioned C-ITS deployment phases?

In our previous research, we proposed a method, US2 [7],

for AV safety and security risk analysis at a single vehicle

level. In this paper, we extend the earlier approach to enable

safety and security risk analysis at C-ITS level.

The remainder of the paper is structured as follows. Sec-

tion II includes the preliminaries. Section III describes the

related work in the area of AV safety and security risk analysis.

Section IV explains the proposed approach. Finally, Section V

concludes the paper.

II. PRELIMINARIES

A. Automated Vehicles

Automated road vehicles perform the driving functions

required to operate the vehicle in on-road traffic. These are

the real-time operational and tactical functions, which include

lateral and longitudinal vehicle motion control, monitoring

the driving environment, object and event response execution,

maneuver planning, and enhancing conspicuity via lighting,

signaling, etc. These functions are collectively called the

Dynamic Driving Task (DDT) [8].

AVs perform entire or part of DDT depending of their au-

tomation level. International standard SAE J3016 [8] describes

six driving automation levels. At level 0, the human driver

performs entire DDT. At level 1, an automated system can

assist the human driver to perform either the lateral or the

longitudinal vehicle motion. At level 2, an automated system

performs the lateral and the longitudinal vehicle motion,

while driver monitors the driving environment. At level 3, an

723

2018 Joint 10th International Conference on Soft Computing and Intelligent Systems and 19th International Symposium on Advanced Intelligent Systems

978-1-5386-2633-7/18/$31.00 ©2018 IEEE DOI 10.1109/SCIS-ISIS.2018.00120

Authorized licensed use limited to: Northcentral University. Downloaded on October 19,2021 at 14:00:03 UTC from IEEE Xplore. Restrictions apply.

automated system can perform entire DDT, but the human

driver must be ready to take back control when the automated

system requests. There is no human driver at level 4; an

automated system conducts the entire DDT, but it can operate

only in certain environments and under certain conditions.

Finally, at level 5, an automated system performs entire DDT

in all environments.

Sensor Fusion

Self Localization

Real world projection

Path planning

Mission planning

Path following &

control MAP

Sensing

World Model

Trajectory Execution

Maintenance & Diagnostics Emergency Response

Figure 1. AV functions [9].

The automated system implements DDT using a set of

functions, which can be grouped into three main categories:

perception (perception of the external environment/context

in which vehicle operates), decision & control (decisions

and control of vehicle motion, with respect to the external

environment/context that is perceived), and vehicle platform

manipulation (sensing, control and actuation of the vehicle,

with the intention of achieving desired motion) [9] (see Fig. 1).

In addition, maintenance&diagnostics, which handles software

and hardware error information and report to manufacturer,

and emergency response functions are included in AVs.

V2X Network C-ITS level

AV level

AVAV

RSU

RSU

C-CU On-board computer

Sensors and actuators

ECU ECU

Sensors and actuators

LiDAR

Camera GNSS

Figure 2. AV components and communications.

Fig. 2 shows the main components of an AV at two

levels: AV level and C-ITS level. The AV’s sensors such as

radar, camera and LiDAR (Light Detection and Ranging) are

responsible for sensing vehicle’s dynamics (e.g., location and

speed) as well as its immediate environment (e.g., distances

to neighboring vehicles, road traffic conditions, and traffic

signs). The on-board computer processes this information and

then sends control commands to the Electronic Control Units

(ECUs) which control the corresponding actuators accordingly

to achieve desired movement speed and direction. Global

Navigation Satellite System (GNSS) is often used by AVs to

obtain accurate location information.

The connections between on-board computer, sensors,

ECUs, and actuators form an in-vehicle network (also called

the on-board network). In addition, AVs can communicate with

other AVs as well as the road infrastructure (Road Side Units,

RSUs) by the use of V2X (Vehicle-to-everything) network. A

C-ITS station unit, Cooperative Communication Unit (C-CU),

is added to the AV to enable communication with the V2X

network, as shown in Fig. 2. See next sub-section for more

details.

B. Connected Vehicles and Cooperative ITS (C-ITS)

Cooperation and coordination among AVs and other traffic

participants is becoming increasingly important with the de-

velopment of highly automated vehicles in order to produce

transportation system benefits [4] [5]. The communication

among AVs would enable them to drive closer to each other,

operate with better control and have quicker reaction, and

eventually avoid collisions.

In C-ITS, the service provision is enabled by the use of live

dynamic data from other vehicles and infrastructure, which are

implemented using vehicle-to-vehicle (V2V) and vehicle-to-

infrastructure (V2I) communications, collectively called V2X.

An on-board communication unit, C-CU, is used by the AV

to enable V2X communication, as shown in Fig. 2.

To the best of authors’ knowledge, there are no interna-

tional standards for designing C-ITS developed yet. Thus,

the standard ISO 21217 (Intelligent transport systems com-

munications access for land mobiles (CALM) architecture),

which has been developed for defining the common ar-

chitectural framework of intelligent transport systems [10],

could be used for this purpose. ITS is a system-of-systems,

which consists of various traffic participants (systems), such

as vehicles, roadside infrastructure, portable devices, control

centers, etc., which are connected via various networking and

access technologies including the Internet, public and private

networks, Bluetooth, Wifi, cellular technologies, etc. Each of

these systems contains a communication unit - ITS station - a

functional entity specified by ITS architecture. In C-ITS, ITS

station corresponds to C-CU.

C-ITS is expected to be launched in Europe in 2019 [4] [5]

and deployment in four phases:

1 Awareness Driving phase (vehicles disseminate their sta-

tus information allowing other vehicle to be aware of the

presence of other vehicles and hazards);

2 Sensing Driving phase (vehicles exchange their sensor

information, such as camera and radar data, which allows

724

Authorized licensed use limited to: Northcentral University. Downloaded on October 19,2021 at 14:00:03 UTC from IEEE Xplore. Restrictions apply.

other vehicles see with the eyes of others and detect

otherwise hidden objects);

3 Cooperative Driving phase (vehicles share their trajecto-

ries or planned maneuvers data with other traffic partic-

ipants, allowing them to accurately predict other traffic

participant behavior and optimize their own decisions);

4 Synchronized Cooperative Driving phase (vehicles ex-

change their coordination data and synchronize their

driving trajectories to achieve optimal driving patterns).

Fig. 3 shows the C-ITS deployment phases with correspond-

ing services and data shared among vehicles, which enables the

implementation of these services. The amount of exchanged

data varies among phases, e.g., in phase 1, AVs exchange only

their status data, while in phase 3 - their status, sensor, and

intention data. The deployment of C-ITS needs to be closely

coordinated with the AV development and deployment, as C-

ITS phases 3 and 4 are feasible only for highly automated

vehicles (automation levels 4 and 5).

C-ITS services

C-ITS deployment phases

AV driving automation level

Phase 1: Awareness driving

Phase 2: Sensing driving

Phase 3: Cooperative driving

Phase 4: Synchronized cooperative driving

Basic warning services: • Intersection warning • Emergency vehicle

warning • Hazard warning • Etc.

Advanced warning services: • Vulnerable road user

warning • Overtaking warning • Etc.

• Roadworks assistance

• Lane-merging assistance

• Platooning • Etc.

• Cooperative merging • Overtaking

assistance • Dynamic platooning • Etc.

Status data Sensor data Status data

Intention data Sensor data Status data

Coordination data Intention data Sensor data Status data

Level 1: Driving assistance Level 5: Full automation

Data shared among AVs

Figure 3. C-ITS deployment phases [5].

The functions of the AVs, participating in C-ITS, have to

be expanded to enable the use of data, received from other ve-

hicles. Fig. 4 show two additional functions, Co-sensor fusion

and Co-localization, added to AV in C-ITS deployment phases

1 and 2. Co-sensor fusion combines the sensor information of

the local sensors, installed in AV, with the sensor information

of other vehicles. Co-localization identifies the location of

other vehicles. In C-ITS deployment phases 3 and 4, additional

functions, such as Mission co-planning and Path co-planning,

will be implemented in AVs to manage data of other AV’s

planned trajectories and maneuvers.

The deployment of C-ITS in Europe will start with phase 1

in 2019 and will continue up to the final phase (EC 2016).

III. RELATED WORK IN THE AREAS OF AV SAFETY AND

CYBERSECURITY RISK ANALYSIS

System safety is the state of a system that does not cause

harm to life, property, or the environment, collectively called

safety losses, while cybersecurity is the state that does not

allow exploitation of vulnerabilities to lead to losses, such as

financial, operational, privacy, or safety losses [11]. Thus, in

addition to safety, cybersecurity aims at protecting finances,

operations, and privacy.

Sensor Fusion

Self Localization Real world

projection Path planning

Mission planning

Path following &

controlMAP

Sensing

World Model

Trajectory Execution

Maintenance & Diagnostics Emergency Response

Co- Localization

Co-Sensor Fusion

Figure 4. AV functions in C-ITS deployment phases 1 and 2.

Ensuring the safety of autonomous vehicles, i.e., reducing

the number of traffic crashes to prevent injuries and save lives,

is a top priority in autonomous vehicle development. Safety

and security are interdependent (e.g., security attacks can cause

safety failures, or security countermeasures may weaken CPS

safety and vice versa), therefore they have to be aligned in the

early system development phases to ensure the required level

of protection [12] [13].

The ISO 26262 standard [14], which defines functional

safety for automotive equipment applicable throughout the

life-cycle of all automotive Electronic and Electrical (E/E)

safety-related, is currently being used for AV safety analysis.

It aims to address possible hazards caused by the malfunc-

tioning behavior E/E systems. The safety process consists of

several phases, such as concept, product development, and

production, operation, service and decommissioning. Hazard

Analysis and Risk Assessment (HARA) is performed during

the concept phase, where hazardous events, safety risks and

goals are identified and analyzed. These goals are further

refined into the safety requirements, and, subsequently, safety

countermeasures are designed and implemented to satisfy the

requirements.

To analyze safety risks and determine their criticality, an

Automotive Safety Integrity Level (ASIL) is assigned to each

identified hazard during HARA phase [14]. The hazards are

quantified according the severity (S), probability of exposure (E), and controllability (C), as shown in Table I. There are three levels of severity: S1 - light or moderate injuries, S2 -

severe injuries, and S3 - life-threatening injuries. Probability

of exposure can be equal to very low (E1), low (E2), medium

(E3), or high (E4). Finally, four levels of controllability are

defined: C0 - controllable in general, C1 - simply controllable,

C2 - normally controllable, and C3 - difficult to control or

uncontrollable.

ASIL A is the lowest safety integrity level, while ASIL D

is the highest. QM (Quality Management) indicates that the

hazard is of low risk and therefore is not required to comply

with the ISO 26262.

Currently available version of ISO 26262, published in

2011, requires the presence of the human driver to respond

to unexpected environments and conditions, and therefore is

not sufficient for highly automated AVs. A new version of ISO

725

Authorized licensed use limited to: Northcentral University. Downloaded on October 19,2021 at 14:00:03 UTC from IEEE Xplore. Restrictions apply.

Table I AUTOMOTIVE SAFETY INTEGRITY LEVEL (ASIL) [14].

Severity S

Exposure E

Controllability C 0 1 2 3

1

E1 QM QM QM QM E2 QM QM QM QM E3 QM QM QM A E4 QM QM A B

2

E1 QM QM QM QM E2 QM QM QM A E3 QM QM A B E4 QM A B C

3

E1 QM QM QM A E2 QM QM A B E3 QM A B C E4 A B C D

26262, which will consider highly automated AVs, should be

published by the end of 2018.

SAE J3061 is a vehicle cybersecurity standard [11], which

was developed using the ISO 26262 standard as a guideline.

Thus, both standards, ISO 26262 and SAE J3061, consist

of similar phases. Security process, defined by SAE J3061,

includes concept, product development, and production & op-

eration phases. Threat Analysis and Risk Assessment (TARA)

is performed during the concept phase, where threats, security

risks, and security goals are defined and analyzed. ISO and

SAE are currently jointly developing vehicle standard ISO

21434 [15], which will replace SAE J3061 in 2019.

SAE J3061 [11] does not provide an unified method for cy-

bersecurity risk analysis, however includes several examples,

such as EVITA [16] and HEAVENS methods. In addition,

the European Telecommunications Standard Institute (ETSI)

proposed the TVRA (Threat, Vulnerability, and Risk Analysis)

method [17]. Furthermore, in our previous work we proposed

the US2 method [7] for unified safety and security risk

analysis.

There are no standards, which define AV system-of-systems

safety and security, available yet. Thus, we can adapt 26262

and SAE J3061 for analyzing C-ITS safety and security risks.

In [18], Boudguiga et al. proposed a RACE (Risk Analysis for

Cooperative Engines) methods for C-ITS cybersecurity risk

analysis, based on EVITA and TVRA methods.

In this paper, we extend the US2 [7] method and propose an

approach for C-ITS cybersecurity and safety analysis, based

on the ISO 26262 and SAE J3061 standards, which uses

the elements of previously proposed methods US2, EVITA,

TVRA, and RACE.

IV. AN APPROACH FOR AV SAFETY AND CYBERSECURITY

RISK ANALYSIS IN C-ITS

In order to estimate risks, two main factors have to be de-

fined: likelihoods (or probabilities) and impacts (or severities).

During vehicle hazard risk analysis, likelihood is addressed

by the probability of exposure, while impact - by the severity

and controllability [14] (see Section III), while cybersecurity

threats are evaluated with respect to the severity of the possible

outcome of an attack and the likelihood that a potential attack

can be successfully carried out (attack potential) [11].

We assume that the AV safety and security risk analysis

has been completed at a single AV level before performing

the analysis of C-ITS risks.

As we can see from Fig. 2, the main C-ITS components are:

communication units C-CUs, installed inside AVs, roadside

infrastructure, and V2X communication network. C-ITS safety

analysis includes the risk analysis of hazards caused by the

accidental failures of these components and, consequently,

the failures of the C-ITS functions (co-sensor fusion and

co-localization functions, as shown in Fig. 4), while the

cybersecurity risk analysis focuses on cyberattacks on V2X

and C-CU and their affect on C-ITS functions.

C-ITS safety risk analysis is performed using the HARA

process, defined by the ISO26262 standard [14] (see Sec-

tion III). The following sub-sections describe the C-ITS cy-

bersecurity risk analysis and its integration with the safety risk

analysis.

A. C-ITS cybersecurity risk analysis

1) Attack potential: In EVITA [16], the authors define attack potential using the following five parameters: elapsed

time, expertise, knowledge of system, window of opportunity

and equipment. However, Macher et al. [19] point out that such

attack potential classification is too complex and requires a lot

of effort. Out of these five parameters, knowledge of system

and required equipment are the key parameters, which affect

the success of an attack. Thus, we have previously included

only these two parameters in US2 method [7] for defining

the attack potential P . The same two parameters are used for defining C-ITS attack potential as described below.

Three levels of attackers’ knowledge, K, are identified: 0 - attackers do not require prior knowledge of the C-ITS; 1 -

attackers need some basic knowledge or some basic under-

standing of the C-ITS; level 2 - attackers need comprehensive

domain knowledge.

The equipment required to perform a successful attack, R, can also be assigned to three levels: 0 - no special equipment

is needed; 1 - standard equipment is needed, which can be

easily obtained; 2 - specialized, not easy to obtain equipment

is required.

Using the knowledge K and required equipment R, we can define the attack potential P , as shown in Table II. First, we define two extreme situations: if exerting a threat does not

require any tool (R = 0) and any knowledge (K = 0), this threat is of the high attack potential (P = 3); in contrast, if exerting a threat requires advanced tool (R = 2) and specific training or knowledge (K = 2), such threat is of very low attack potential (P = 0). In situations when for achieving a threat an attacker needs either specific knowledge (K = 2) or specific tool (R = 2), the attack potential is considered as low (P = 1). If the requirement of knowledge and equipment is medium (K = 1 or R = 1), the attack potential is also medium (P = 2). All the combinations of (K, R) and associated attack potential are listed in Table II.

726

Authorized licensed use limited to: Northcentral University. Downloaded on October 19,2021 at 14:00:03 UTC from IEEE Xplore. Restrictions apply.

Table II ATTACK POTENTIAL P .

Potential P Description (K,R) combinations 0 Very low (2,2) 1 Low (2,0)(0,2)(1,2)(2,1) 2 Medium (1,1)(0,1)(1,0) 3 High (0,0)

2) Attack severity: Cyberattacks can lead to four different types of losses, i.e. safety, privacy, financial, and operational

(as defined by the SAE J3061 standard [11]), which have to

be considered while assessing the cybersecurity risks. EVITA

[11] [16] has defined attack severity SA as a vector of four components: SS (safety), SP (privacy), SF (financial), and SO (operational). The SS evaluates the attack damage to driver or passengers. SP is related to personal data exposure and vehicle tracking. SF defines economical losses for users and vehicle manufacturers. Finally, SO describes the impact of the attack on vehicle performance.

The attack severity types, proposed by EVITA [16], can

be applied for evaluating C-ITS attack severity as well, as

shown in RACE method [18]. Thus, we will use the same

attack severity types in our approach. The severity levels for

each severity type are shown in Tables III and IV, where four

levels of severity, 0-3, are defined.

If an attack causes several types of losses with different

level of severity, the highest level is assigned to an attack and

its severity SA is determined. E.g., if SS=2 and SP=3, then SA=3.

Table III ATTACK SEVERITY WITH RESPECT TO SAFETY AND PRIVACY (FROM

RACE METHOD [18]).

Severity SA Safety SS Privacy SP 0 No injuries No unauthorized ac-

cess to data 1 Light injuries Access to anonymous

data 2 Severe injuries, with survival Identification of vehi-

cle or driver 3 Life threatening, possible death Driver or vehicle

tracking

Table IV ATTACK SEVERITY WITH RESPECT TO FINANCIAL AND OPERATIONAL

LOSSES (FROM RACE METHOD [18]).

Severity SA Financial SF (in $) Operational SO 0 0 < loss < 100 No impact on performance 1 100 < loss < 1000 Impact not detected by

driver/system 2 1000 < loss < 10000 Driver/system aware of per-

formance degradation 3 loss > 10000 Significant impact on perfor-

mance

Several authors argue that to compute the final attack sever-

ity value, S, we need to consider the attack intensity I, as in

TVRA and RACE methods method [17] [18]. Attack intensity

is important in C-ITS risk analysis, since the attack severity

value is different depending not only on attack instances but

also the number of targeted vehicles [18]. Thus, we include

the intensity value in computing the total attack severity S. The intensity ranges from 0 to 2, where 0 corresponds to a

single attack instance, 1 - moderate number of attack instances

on one vehicle or one attack on moderate number of vehicles,

and 2 - heavy number of attack instances on many vehicles.

The total attack severity, S, is computed as S = SA + I with a truncation to 3 if S >3 (same as in RACE method [18]).

3) AV automation level: Driving automation levels of AV is another important factor, which has to be considered during

risk analysis. As the automation level increases, the amount

of driving tasks, controlled by the system, increases, while

the role of the human driver reduces (see Section II-A for

more details). Thus, the risk analysis has to be performed for

all automation levels of and AV, at which it is expected to

operate.

The driving automation level L has not been considered neither in EVITA, nor in RACE methods. However, we took

it into account in US2 method [7], where we grouped the

automation levels into three groups: low (levels 1 and 2),

medium (level 3), and high (levels 4 and 5). The same groups

are used in this approach.

4) Cybersecurity risk values: Using the attacks’ total sever- ity S, potential P , and vehicle automation level L values, we can define the Cyber Security Risk Level (CSRL), as

shown in Table V. CSRL values 0-3 indicate that the risk is minor, therefore there is no primary need for security

countermeasures. CSRL values 4-5 represent major risks, for which countermeasures should be applied. Finally, CSRL values 6-7 indicate critical risks, which should be minimized

with highest priority.

In EVITA and RACE methods, controllability factor C is added for risk evaluation of attacks that cause safety losses

(SS >0). However, controllability is part of safety risk analysis and determination of ASIL level, as described in Section III.

Thus, instead of including controllability into the cybersecu-

rity risk analysis, we integrate cybersecurity and safety risk

analysis processes. In this way, the controllability of attacks

that cause safety losses is assessed using the ISO 26262. See

Section IV-B for more details.

Table V CYBER SECURITY RISK LEVEL (CSRL).

Total Severity S

Automation Level L

Potential P 0 1 2 3

1 Low (1-2) 1 1 2 3

Medium (3) 1 2 3 4 High (4-5) 2 3 4 5

2 Low (1-2) 2 2 3 4

Medium (3) 2 3 4 5 High (4-5) 3 4 5 6

3 Low (1-2) 3 3 4 5

Medium (3) 3 4 5 6 High (4-5) 4 5 6 7

727

Authorized licensed use limited to: Northcentral University. Downloaded on October 19,2021 at 14:00:03 UTC from IEEE Xplore. Restrictions apply.

B. Integration of C-ITS security and safety risk analysis

SAE J3061 standard [11] emphasizes that although automo-

tive safety and cybersecurity analysis processes can be per-

formed separately, they need to communicate with each other

in order to maintain consistency and completeness between

them. It can be done via communication links between various

phases of safety and cybersecurity processes. One of such links

has to be established between safety and cybersecurity risk

analysis phases, since cybersecurity vulnerabilities may lead

to violation of safety goals. However, SAE J3061 [11] does

not provide details on how to establish these links.

Hazard identification

C-ITS safety risk analysis (ISO 26262)

C-ITS cybersecurity risk analysis (proposed)

Hazard risk analysis

Hazard ASIL levels

Safety requirements

Threat risk analysis

Attack CSRL levels

Security requirements

Safety losses

Privacy losses

Financial losses

Operational losses

Threat identification

Integrated requirement analysis

Figure 5. Integration of C-ITS safety and cybersecurity risk analysis.

We integrate C-ITS safety and cybersecurity risk analysis

processes as shown in Fig. 5. Both processes are performed

in parallel, and there are two communication links between

them:

• The first communication link is from cybersecurity threat risk analysis step to safety hazard identification

step. This link is needed for the situations when an attack

can cause safety losses SS, as described in Section IV-A. In such cases, the information about possible safety losses

due to an attack is transferred to the safety analysis

process, where hazards related to the attack are identified,

analyzed, and their ASIL level is determined;

• The second communication link is between safety and security requirements, which are defined based on ASIL

and CSRL levels. At the end of safety and cybersecurity

risk analysis phases, the safety and security analysts have

to work together and review all the requirements to ensure

their completeness and consistency.

The integrated C-ITS safety and security analysis process

enables comprehensive analysis of C-ITS risks.

V. CONCLUSIONS

This paper presents a method for integrated C-ITS safety

and cybersecurity risk analysis. It takes into consideration

automotive safety and cybersecurity standards ISO 26262

and SAE J3061, and utilizes the elements of the previously

proposed methods US2, EVITA, TVRA, and RACE. The

proposed method could be used for risk analysis of C-ITS,

which includes AVs with different driving automation levels,

as well as at the different C-ITS deployment phases. Further

work will include practical implementation of the proposed

approach.

REFERENCES

[1] Automated Driving Systems 2.0. A Vision for Safety. National Highway Traffic Safety Administration, NHTSA, U.S. Department of Transporta- tion, Sep. 2017.

[2] “Self-driving Uber kills Arizona woman in first fa- tal crash involving pedestrian. The Guardian.” 2018, URL: https://www.theguardian.com/technology/2018/mar/19/ uber-self-driving-car-kills-woman-arizona-tempe [accessed: 2018- 03-27].

[3] J. Petit and S. E. Shladover, “Potential cyberattacks on automated vehicles,” IEEE Transactions on Intelligent Transportation Systems, vol. 16, no. 2, pp. 546–556, 2015.

[4] COM/2016/0766 final: Communication from the Commision to the European Parliament, the Council, the European Economic and Social Committee and the Committee of the Regions. A European strategy on Cooperative Intelligent Transport Systems, a milestone towards cooper- ative, connected and automated mobility. Taxonomy and Definitions for Terms Related to On-Road Motor Vehicle Automated Driving Systems. The European Commission, Nov. 2016.

[5] K. Sjoberg, P. Andres, T. Buburuzan, and A. Brakemeier, “Cooperative intelligent transport systems in europe: Current deployment status and outlook,” IEEE Vehicular Technology Magazine, vol. 12, no. 2, pp. 89– 97, June 2017.

[6] “European vehicle manufacturers work towards bringing Vehicle-to-X Communication onto European roads. Car2Car Communication Consor- tium Press Release 30 Oct 2015. ,” 2015, URL: https://www.car-2-car. org/index.php?id=214 [accessed: 2018-03-27].

[7] J. Cui and G. Sabaliauskaite, “Us2: An unified safety and security analysis method for autonomous vehicles,” in Future of Information and Communication Conferences (FICC), Singapore, 2018, pp. 315 – 321.

[8] SAE J3016: Taxonomy and Definitions for Terms Related to On-Road Motor Vehicle Automated Driving Systems. SAE International, Sep. 2016.

[9] S. Behere and M. Törngren, “A functional reference architecture for autonomous driving,” Inf. Softw. Technol., vol. 73, no. C, pp. 136–150, May 2016. [Online]. Available: http://dx.doi.org/10.1016/j.infsof.2015. 12.008

[10] ISO 21217:2014, Intelligent transport systems – Communications access for land mobiles (CALM) – Architecture. International Organization of Standardization, ISO, 2014.

[11] SAE J3061: Cybersecurity Guidebook for Cyber-Physical Vehicle Sys- tems. SAE International, Jan. 2016.

[12] J. Cui and G. Sabaliauskaite, “On the alignment of safety and security for autonomous vehicle,” in IARIA Cyber, Barcelona, Spain, 2017.

[13] L. Piètre-Cambacédès and M. Bouissou, “Cross-fertilization between safety and security engineering,” Reliability Engineering & System Safety, vol. 110, pp. 110 – 126, 2013.

[14] ISO26262-3:2011, Road Vehicles – Functional Safety – Part3: Concept Phase. International Organization of Standardization, ISO, 2011.

[15] ISO/SAE AWI 21434, Road Vehicles – Cybersecurity engineering. In- ternational Organization of Standardization, ISO, Under development.

[16] EVITA - E-safety vehicle intrusion protected applications, “Evita project,” (accessed: 2017-10-12). [Online]. Available: https://www. evita-project.org/deliverables.html

[17] ETSI - TR 102 893: Intelligent Transport Systems (ITS); Security; Threat, Vulnerability and Risk Analysis(TVRA). Taxonomy and Definitions for Terms Related to On-Road Motor Vehicle Automated Driving Systems. European Telecommunications Standards Institute, Mar. 2017.

[18] A. Boudguiga, A. Boulanger, P. Chiron, W. Klaudel, H. Labiod, and J. C. Seguy, “Race: Risk analysis for cooperative engines,” in 2015 7th International Conference on New Technologies, Mobility and Security (NTMS), July 2015, pp. 1–5.

[19] G. Macher, E. Armengaud, E. Brenner, and C. Kreiner, A Review of Threat Analysis and Risk Assessment Methods in the Automotive Context. Trondheim, Norway: Springer International Publishing, Sep 2016.

728

Authorized licensed use limited to: Northcentral University. Downloaded on October 19,2021 at 14:00:03 UTC from IEEE Xplore. Restrictions apply.