Security Guidelines for Product Categories- Automotive On-board Devices Ver. 2.0

CCDS Security Guidelines WG
Automotive On-board Devices SWG

Revision History
VersionDate

Description

Ver.1.006/08/2016

Created a new edition.

Ver.1.01

06/15/2016

Rearranged the format of the table in Chapter 4. Madechanges to Item 3, Table 5-2.

Ver.2.005/29/2017

Revised the document completely to reflect the addition ofChapter 12.

■Trademarks
・All company and product names mentioned in this book are company trademarks ortrademarks registered.
■Further notices
・All information provided in this book is stated at the time of publication and maychange without notice.
・ Any copying or reprinting of the contents of this document without obtaining
permission from CCDS is prohibited.
© 2017 Connected Consumer Device Security Council Proprietary

Contents
1

Introduction ............................................................................................. 5

1.1

The Present Status of, and Security Issues Relating to, Automotive On-board

Devices ..................................................................................................................................6
1.2

Objectives and Reader of This Document .................................................................6

1.3

Abbreviations ..............................................................................................................72

A System Model for Automotive On-board Devices Guidelines ............ 8

2.1

Target Model ...............................................................................................................8

2.2

The System Model under Discussion ...................................................................... 10

3

Possible Security Threats ...................................................................... 12

3.1

Carry-in Devices ....................................................................................................... 12

3.2

Attacks Launched from External Networks ............................................................. 12

3.3

Possible Threats and Damage to Automotive On-board Devices ........................... 13

4

The Lifecycle Phases and Security Efforts ........................................... 15

4.1

Definitions of the Lifecycle Phases ......................................................................... 15

4.2

Security Efforts within the Individual Phases ............................................................ 16

4.2.1

Policy Phase ........................................................................................................ 17

4.2.2

Planning and Development Phase ....................................................................... 19

4.2.3

Operation Phase .................................................................................................. 22

4.2.4

Disposal Phase .................................................................................................... 23

5

Threat Analyses ..................................................................................... 24

5.1

Threat Cases ............................................................................................................. 24

5.2

Risk Characteristics ................................................................................................. 25

6

Methods of Risk Assessment ................................................................ 31

6.1

Modified ETSI Method............................................................................................... 31

1

6.2

CRSS Method (Applied CVSS Method) .................................................................... 33

6.3

RSMA Method ............................................................................................................ 35

6.4

CCDS Prototype Method ........................................................................................... 37

7

Results of Risk Assessment .................................................................. 40

7.1

Modified ETSI Method............................................................................................... 40

7.2

CRSS Method (Applied CVSS Method) .................................................................... 41

7.3

RSMA Method ............................................................................................................ 42

7.4

CCDS Prototype Method ........................................................................................... 44

8

Trend

Analyses Of Risk Assessment .................................................. 46

8.1

Field-specific and Common Threat .......................................................................... 46

8.2

Threat Classification ................................................................................................ 47

8.3

Connection Interface (Intrusion Route) ................................................................... 48

8.4

Who: Connected ....................................................................................................... 49

8.5

Whom: Threats Did Harm To .................................................................................... 50

8.6

Where: Risks Occurred ............................................................................................ 50

9Conclusion ............................................................................................. 51

10

Association with the “IoT Safety/Security Development Guidelines” ..
............................................................................................................. 52

11 Association with the “Automotive Information Security Efforts
Guidelines” .................................................................................................. 55
12

ASSOCIATION WITH "IoT SECURITY GUIDELINES" .......................... 56

References ................................................................................................... 57
Figure 2-1 Scope of Connectivity ..................................................................................... 8
Figure 2-2 Reference Models for Automotive On-board Systems ..................................... 9
Figure 2-3 A System Model under Discussion in the Guidelines ..................................... 102

Figure 3-1 Remote Attacks Launched on Cars ............................................................... 12
Figure 4-1 Lifecycle of an Automotive System ................................................................ 15
Table 2-1 Explanations of System Component Elements ................................................. 11
Table 3-1 Possible Threats and Damages ...................................................................... 13
Table 4-1 Definitions of Phases ...................................................................................... 16
Table 4-2 List of Security Effort Guidelines Relevant to Individual Phases ..................... 16
Table 4-3 Security Efforts Implemented in the Policy Phase ........................................... 17
Table 4-4 Security Efforts Conducted in the Planning and Development Phase .............. 19
Table 4-5 Security Efforts Conducted in the Operation Phase ........................................ 22
Table 4-6 Security Efforts Conducted in the Disposal Phase .......................................... 23
Table 5-1 Surveyed Literature List .................................................................................. 24
Table 5-2 Risk Characteristics ........................................................................................ 25
Table 5-3 Field-specific and Common Cases .................................................................. 26
Table 5-4 Threat Classifications [5] ................................................................................ 27
Table 5-5 Connection Interface (Intrusion Route) ........................................................... 28
Table 5-6 Who: Connected [1] ........................................................................................ 29
Table 5-7 Whom: Threats Did Harm To [1] ...................................................................... 30
Table 5-8 Where: Risks Occurred ................................................................................... 30
Table 6-1 ETSI Likelihood and Impact Definitions ........................................................... 31
Table 6-2 ETSI Risk Score Calculations ......................................................................... 31
Table 6-3 Motivation and Technical Difficulty Definitions in the Modified ETSI Method ... 32
Table 6-4 Likelihood and Impact Definitions in the Modified ETSI Method ...................... 32
Table 6-5 Risk Score Classifications in the Modified ETSI Method ................................. 33
Table 6-6 Risk Score Definitions in the Modified ETSI Method ....................................... 33
Table 6-7 Base Metrics ................................................................................................... 34
Table 6-8 Risk Score Classifications .............................................................................. 35
Table 6-9 Likelihood Parameters .................................................................................... 35
Table 6-10 Likelihood Level Assessment Table ............................................................... 36
Table 6-11 Risk Level Assessment Table ........................................................................ 36
Table 6-12 Scores of Attack Exploitability and Impact Subscores ................................... 37
Table 6-13 Definitions of Attackers’ Motivations .............................................................. 39
Table 6-14 Risk Score Classifications............................................................................. 39
Table 7-1 Examples of Risk Assessments Produced by the Modified ETSI Method ........ 40
Table 7-2 Examples of Risk Assessments Produced by the CRSS Method ..................... 41
Table 7-3 Examples of Risk Assessments Produced by the RSMA Method ..................... 43
Table 7-4 Examples of Risk Assessments Produced by the CCDS Prototype Method .... 44
Table 8-1 Field-specific and Common Threat Trend Analyses......................................... 47
Table 8-2 Threat Classification Trend Analyses .............................................................. 47
Table 8-3 Connection Interface (Intrusion Route) Trend Analyses .................................. 48
Table 8-4 Who: Connecte ............................................................................................... 49
Table 8-5 Whom: Threats Did Harm To ........................................................................... 50
Table 8-6 Where: Risks Occurred ................................................................................... 51
3

Table 10-1 A Comparison between “IoT Safety/Security Development Guidelines” and This
Document 1 .................................................................................................................... 53
Table 10-2 A Comparison between “IoT Safety/Security Development Guidelines” and This
Document 2 .................................................................................................................... 54
Table 11-1 Table of Comparison between the “Automotive Information Security Efforts
Guidelines” and This Document ...................................................................................... 55

4

1 Introduction
To date, every product industry has formulated its own safety standards. Security
standards relating to organizational administration (ISO27001) and product design security
assessment and authentication (ISO15408) have already been formulated, while recent
years have witnessed the formulation of standards targeting control systems for criticalinfrastructure (plants and facilities essential to social infrastructure) (IEC62443).
Along with rapidly increasing the number of IoT devices in our society, these products,
with a variety of networking features, are facing to security theats; however, our security
standards are not yet sufficiently in place.
In the U.S. and European nations, moves are underway to determine security standards
by using industry-specific safety standards. However, while in Japan there are tangible
security concerns that may lead to the establishment of security standards, there are few
areas where practical discussions have yet led to action.
The Connected Consumer Device Security Council (CCDS) was established in responseto this situation. The Council is committed to formulating security standards for common
devices and launching an authentication program to confirm and verify compliance withthese standards in order to reassure users of IoT products.
On August 5, 2015, the Information-technology Promotion Agency, Japan, Japan（IPA）
launched the IoT Safety/Security Development Guidelines Review WG to initiate
discussions on security at the national level. The CCDS has come together with the IPAWG to establish a number of proposals concerning the results of the reviews of guidelines
within the CCDS.
On March 24, 2017, the results of the reviews at the IPA-WG were compiled and released
as “IoT Safety/Security Development Guidelines - Important Points to be understood by
Software Developers toward the Smart-society [1].” While the IPA's development guidelines
focus on the common subjects by comprehensive approach, the CCDS field-specificguidelines is developed for locating individual industry specific safety and security
promotion of design or development process.

51.1 The Present Status of, and Security Issues Relating to, Au
tomotive On-board Devices
Rapidly developing car technologies, such as self-driving and connected cars, havegreatly increased user convenience. Unfortunately, the incidence of cyber-attacks thatthreaten safety and security are also increasing, meaning that cars connected to networks
or devices taken into the car is vulnerable to such attacks. At Black Hat 2015, a U.S.
security-related conference, there was a reported case of a jeep being successfully hacked
into by exploiting the vulnerabilities of the Chrysler connected car system: “Uconnect.”
Clearly, there is a real threat of the steering, brakes or other systems being controlled bya malicious false signal to ECU via on-board LAN or other devices.
The possible damage caused by the hacking of an automobile could endanger human
life. Security is therefore essential, and so supervisors, managers, and developers, are allendeavoring to improve security within their respective fields.
As products previously thought unlikely to be under threat are now being exposed toattacks as they become connected to networks, allowance should be made for security
education for users, as well as the planning and development of security-conscious
products.

1.2

Objectives and Reader of This Document

This document has been written mainly for corporate developers working on thedevelopment of automotive on-board devices and systems. The document summarizes theguidelines relating to the design and development processes that developers should take
into consideration; right through from the design to the release of automotive on-board
devices, to ensure that relevant security countermeasures are performed in the devices.
More specifically, this document is targeted at the following groups:

1) The designers and developers of on-board devices and systems,2) Development supervisors in charge of the implementation of on-board devices andsystems design projects,
3) Supervisors responsible for the budget and the staff allocated to on-board devices
and systems design projects.
Issues that cannot be dealt with by developers alone, but that need overview bymanagement or company-wide support, have been included for reference by company
6executives. This document is designed for use in the review of the development of onboard devices and systems, and the guidelines provided should be supplemented by the“IoT Safety/Security Development Guidelines [1].”1.3

Abbreviations

The full names of the abbreviations used throughout this manual are as follows.

Table 1-1 List of Abbreviations
Abbreviation

Full Name

A2DP

Advanced Audio Distribution Profile

CAN

Controller Area Network

CCDS

Connected Consumer Devices Security council

CSIRT

Computer Security Incident Response Team

CVSS

Common Vulnerability Scoring System

D-Bus

Desktop Bus

DoS

Denial of Service

DSRC

Dedicated Short Range Communications

ECU

Engine Control Unit

ETC

Electronic Toll Collection system

GPS

Global Positioning System

GSM

Global System for Mobile communications

IEC

International Electrotechnical Commission

I/F

Interface

IoT

Internet of Things

IPA

Information-technology Promotion Agency, JapanISOInternational Organization for Standardization

SWG

Sub Working Group

WG

Working Group

7

2 A System Model
Devices Guidelines
2.1

for Automotive

On-board

Target Model
Figure 2-1 should be referred to in the following discussion on the scope of interface

connections within target automotive on-board systems[2]. The scope of discussion
focuses on connections to the head unit. The target model is discussed with references
to currently available literature. In the discussion of SWG, we refer to Figure 2-2 for the
automotive on-board systems [3, 4, 5, 6, 7, 8].

Figure 2-1 Scope of Connectivity[2]8Source: Security Trends and Awareness Enhancement Measures S urv ey Report (IPA)

Source: Acti on guide t o t he i nf ormation securit y of the car
Source: 2011 Surv ey on Inf ormati on Security Trends of car

Sourc e: 2020 Car Societ y and S ecurity (Int ernet ITS Consorti um)

Source: Threat s t o Connected Built-in Syst ems and Countermeasures (IPA)

Source: IPA’s Second I oT Saf ety/Security Dev elopment Gui deli nes Rev iew W G

Source: Trends i n “Connect ed Car” Technology and Associat edStandardizations and security (JARI)

Figure 2-2 Reference Models for Automotive On-board Systems [3, 4, 5, 6, 7, 8]
92.2

The System Model under Discussion

A system model is used in the discussion to aid in the task of classifying automotivefunctions and gaining a preliminary insight into the connection interfaces that could be
utilized in attacks. The model is also useful for identifying the locations that have properties
that put them under threat from attackers. Hence, devices that are either installed in theautomobile or ones carried on-board that are connected through the interface to outside
vehicle, as well as the on-board head unit, have been listed on the basis of the earlier
discussion to work out a rough plan for the model.
Based on prior drafts, the SWG reviewed and revised them at following proper points bymembers:・Adding a diagnostic port (OBD-II, On-Board Diagnostics II),
・Adding a smart key connection route,・Adding a connection route to outside servers,
・Describing each gateway as a CAN-gateway (controller area network gateway) which
does not contain security functions,
・Revising to the appropriate categorizations in the car industry that the body system,
the power train chassis system and the safety system,
・Removing electrical charge system out of our scope.
The final model is shown in Figure 2-3.

Figure 2-3 A System Model under Discussion in the Guidelines
10Table 2-1 Explanations of System Component Elements
Name

Explanation

Automotive on-board

A device that communicates with the external world by means of adevicegateway, such as a car navigation system, audio gear or carphone.

On-board

A wireless unit installed to exchange relevant information with

communication

either a roadside system for toll payment, an ITS service, telematics

devicecommunication, or vehicle-to-vehicle communication.

OBD-II port

On-Board Diagnostics, Second Generation. Onboard systems
diagnostics interface.

Gateway

Enables reciprocal communication between two networks thatutilize different means of communication or diverse operation
policies on an automotive on-board system.

ECU

Electronic Control Unit. A unit that electronically controls a numberof car mounted on-board systems.

ETC

Electronic Toll Collection System.

DSRC

Dedicated Short Range Communications. A form of wirelesscommunications technology that enables an ITS (Intelligent
Transport System) service to communicate with a roadside system
or enable vehicle-to-vehicle communication.

C2C

Car-to-Car Communication.

3G/GSMA third generation system for mobile communications / Global
System for Mobile communications.

GPS antenna

The antenna used to receive position information from a satellite.

Carried-in

A device that carries out data communication with an automotive

deviceon-board

on-board device via either a wired, wireless or an attachment
connection.

Wi-Fi

Wireless LAN standard certified by the Wi-Fi Alliance.

BT

Bluetooth. A near-field wireless communication standard designed
for digital devices.

USB

Universal Serial Bus. A serial bus standard for connecting
peripheral devices to information processing equipment, such as acomputer.

SD

An SD card, or a memory card, that is used with mobile devices or
the like.

Smart key

A car key that holds electronic data that is used to verify data withthe on-board computer via wireless communication.

11

3 Possible Security Threats
3.1

Carry-in Devices

Carry-in Devices, such as a smartphone, USB or SD, will have more chance to be
exposed to threats, for example viruses, by connecting outside resources. As it is becoming
increasingly

commonfor

external

devicestobeconnected

with

cars,

takingcountermeasures from the development stage for defending threats of any kind is extremely
important.

3.2

Attacks Launched from External Networks

The use of external communication, such as smart key, GPS, vehicle-to-vehiclecommunications and cloud data, could assume that facing to malicious attacks of the datainterception or the driving operation hack.

A case of remote intrusion into an on-board LAN
A case of hacking into an automotive on-board LAN from a remote location to control

steering or the engine was reported at a meeting of Black Hat 2015. This attack resulted in
the recall of 1.4 million affected cars.

Figure 3-1 Remote Attacks Launched on Cars

12

3.3 Possible Threats and Damage to Automotive On-board Dev
icesThis section describes possible threats and damages to automotive on-board devices.

Table 3-1 Possible Threats and Damages
No.
1

Possible threats

Possible damages

DoS attacks launched on the

Shutting the all services down with

automotive on-board networks via an

communication functions.

external network.
2

Fake message transmission by server

User confusion and more.

spoofing.
3

System freeze of streaming contents

Shutdown of infotainment services.

due to the exploiting browser bugs.
4

5

Messages eavesdrop by the third party

Use of services not intended byreceivers.

operation management authorities.

Messages delivery containing incorrect

Confusion caused by the delivery oflocations by the third party GPS

messages with the incorrect locations.

generators.
6

Spoofing of a second automotive on-

Confusion caused by the delivery ofboard device through the use of thedrive information containing incorrect

original automotive on-board device by

information.

users or due to the unauthorized
utilization of receivers by third parties.
7

Tracing personal locations from

Personal profiling.

received messages through abuse of
on-board devices by users or use ofreceivers by third parties.
8

Intentional shutdown of the ECUECU disabled from working correctly,

control functions through 3G/LTE bythus crippling vehicle functions.

third party during normal operations.
9

Manipulating the vehicle status

Tampering with settings to makethrough Bluetooth devices,

unintended changes to performance.

smartphone etc., by dealer personnel
during maintenance.

13

10

Malfunctioning of the information

Disabling of information functions.

ECU`s information functions during
normal operations intentionally causedby third parties via an SD card
interface.

14

4 The Lifecycle Phases and Security Efforts
The workflow of any system development activity has a lifecycle, which consists of asequence of phases beginning with development, moving through operation, and ending in
disposal. Consideration of security during each of these phases is important. This chapter
provides definitions and approaches of each of these phases.

4.1

Definitions of the Lifecycle Phases

The lifecycle of an automotive system can be divided into four phases: Planning,
Development, Operation and Disposal. For ensuring the product security, we need toconsider the security measures in each of these phases and to perform the plan with ourbest efforts; as a result, these efforts affect and enhance the quality of our product security.

Figure 4-1 Lifecycle of an Automotive System [5]15Table 4-1 Definitions of Phases
Explanation

Phase
Planning

Developing car concepts and the budget required to effort them.
Formulating and defining requirements.

Development

Proceeding with the design, efforts and manufacture as per therequirements and definitions formulated in the Planning Phase.

Operation

Responding to incidents that may occur after the car has been sold by the
dealer to the customer (user). This includes maintaining and servicing thecar, etc.

Disposal

4.2

The owner of the car either sells it as a used car or disposes it.

Security Efforts within the Individual Phases

This document summarizes guidelines for building a framework in the Planning andDevelopment Phase of the lifecycle of an automotive system to defend any threats that
may be experienced in the Operation and Disposal Phases. It describes the efforts madeto ensure security that are performed in the successive phases of the lifecycle, as outlinedin the previous section.
Efforts specific measures is such a costly process that developers often find it difficult toimplement them alone, that is, without support from the management or the entire corporate
organization. Hence, this document includes a Policy Phase, in addition to the Planningand Development, Operation and Disposal Phases, to help the management develop a key
understanding of the whole lifecycle.
A list of the security effort guidelines relevant to each individual phase is provided below.
Table 4-2 List of Security Effort Guidelines Relevant to Individual Phases
Phase
PolicyFormulation

No.

Item

Effort Guideline

1

Basic olicies

Develop basic corporate policies.

2

Framework

Build a corporate framework for taking action.

3

Education

Periodically educate employees.

12Planning andDevelopment

3

Model to beassessedThreat analysis
Measuresreview

Establish the range of threat analysis.
Conduct a threat analysis to identify risks.
Review measures.

4

Evidence

Retain evidence.

5

Parties

Beware of assuming the integrity of designers,

16

concerned with

developers or subcontractors.

design6
7

1

2

Validation andverification
Responses to

Prepare for the occurrence of unknown future

unknown threats

threats of any kind.

User

Cover all relevant aspects in the user

documentation

documentation.

Operation-timeDefine the scope of operation-time usage inusage definition

strict terms.

3

User alert

4

UpdateOperation
Parties
5

concerned with
operations

6
1
Disposal2

Validate and verify security.

Ensure that users identify operational faults asthey occur.
Allow measures to also be taken in the future.
Beware of placing complete trust in the parties
concerned.

Sharing incident

Share incident information in order to use it to

information

maximum effect.

Obfuscating
analyses
Initialization

The design should allow for the Disposal Phase.
Allow settings to be initialized according to theirdefaults.

4.2.1 Policy Phase
The following Table 4-3 is a list of the security efforts that may take place during the
Policy Phases.
Table 4-3 Security Efforts Implemented in the Policy Phase
No.
1

Item

Guideline

Basic

Establish basic

policies

corporate policies.

Description① Gaining cooperation from management isessential because measures are costly.
(Getting the management on board isachieved via raising awareness of theimportance of the issues with presentations
and publications by public institutions.)② Update basic policies to keep up with
developments in the threats environment.
③ Establish guidelines to set upper limits onaction taken. (This is necessary to prevent

17

action from becoming so costly that the
product cannot be launched.)
2

Framework

Maintain a framework① As cross-organizational approaches arefor corporate

envisioned according to the corporation, a

initiatives.

supervisory manager should be appointed
to oversee them.
② Build a framework to ensure that measures
run continually and cyclically.
③ It is recommended that the incident
response center be set up separately from
regular customer support centers.(When aproblem is detected with the operation of a
product in the market, and it is reported toa regular customer support center, it isusually misclassified as a product fault
rather than a security issue. It is therefore
recommended that a dedicated incident
response center be set up to respond tosecurity problems.)③ Decide how incident information received
is routed and reported beforehand.
④ It is recommended that a qualification
system specifically intended for productsecurity stakeholders be developed in the
future.

3

Training

Periodic employee① Ensure periodic retraining of employees totraining.

maintain adherence with basic policies.
② It is recommended that training in
information security be conducted ingroups depending on the position of theemployees.
(This is because the kind of training
required varies between CSIRT
representatives, developers, users,
managers and executives.)③ Training is also required to maintainemployee integrity. => See ② under item
5 in 4.2.2., as well as “Planning andDevelopment Phase.”18

4.2.2 Planning and Development Phase
The following is a list of the security initiatives that shall be conducted in the Planningand Development Phase.
Table 4-4 Security Efforts Conducted in the Planning and Development Phase
No.

Item

Guideline

1

Model to be

Establish the① Write up the target system.

assessed

scope of the② Write up possible connection destinations.

threat analysis.

Description③ Specify connection ports.
④ Write up all hidden interfaces.
⑤ Make an initial listing of all possible threatcandidates.

2

Threat analysis

Conduct a threat① Try to conduct a threat analysis using at least

analysis to

one method of assessment. However, thedetermine risks.

use of multiple methods is preferred, if
possible, in order to compare them. (Asdifferent assessment methods have their own
strengths and weaknesses, threat analyses
that utilize alternative methods shall be
attempted.)① It is desirable to have attackers’ motivations
and case history reflected in the risk
assessment. (If any past cases arepresented, exploitability subscores tend to belower while attackers’ motivations become
elevated.)② Anticipate repeating the threat analyses after
having worked out proposed measures inorder to verify the effects of the measures.
(Doing so will verify the validity and costeffectiveness of the measures.)③ Assess corporate risks that may be posed byincidents.
④ Once a measure is put into action, theamount of properties to be protected will
increase. The measure should be
reimplemented to carry out threat analyses.

3

Action review

Review actions.

① List proposed measures beforehand.

19

② Start by assuming that something can always
be touched or opened.
③ Decide where keys are held and who is
responsible for their management.
④ As a rule, consider the server egress as aroute of intrusion. (There are cases of onboard devices being used as a springboard tolaunch external attacks.)⑤ Verify the authenticity of the devices
connected and application software. (Threat
analyses by the Automotive On-board
Devices SWG report a high-risk score due tospoofing.)⑤ Explore countermeasures to defend risks
posed via an informal interface.
⑥ Consider the cost of development and efforts
of countermeasures on the basis of the
product value and possible risks before
incorporating countermeasures into productdesigns.
⑦ It is necessary for the producer of the final
product to establish policies on the level of
responsibility for security assurance, andletting subcontractors take their respective
shares of security.
⑧ List proposed actions that can be
implemented within the individual layers(physical, network, application).
⑩ If adequate measures cannot be taken due toconstraints on the cost or specifications, also
consider taking measures with the system as
a whole or with upper-level components.

20

4

Evidence

Retain evidence.

① Discussions on documents related to the risk
analysis of threats and measures, along withthe effectiveness of the countermeasurestaken and the reason for them being chosen.
(In the case of any type of event, evidence
should be retained of the scope of selfresponsibility. The purpose of this is toconfirm that the maximum possible effort was
made, and further details could not be
obtained.)

5

Parties

Do not assume① Require submission of written pledges.

concerned withthat designers,② Stress in a training session that breaching

designdevelopers or

security would ruin one`s career. (In addition

subcontractors

to seeking compliance with secrecy

are trustworthy.

obligations, training subcontractors is also
beneficial.)③ Minimize the number of designers who haveaccess to the entire system.
④ Enforce strict key management. (If costs canbe disregarded, use of unique keys will
improve protection.)

6

Validation andValidate andverification

verify security.

① Strive to complete testing procedures with aminimum set of fuzzing tools.
② Even though assessments are conducted inhouse, it is desirable that they be subjected
to a minimum of third-party checks.
③ Risk assessment or security verification by
third parties is recommended.

7

Responses to

Be prepared for① Write up all factors for consideration.

unknown

the occurrence of② It is recommended to be constantly preparedthreats

unknown threats

to detect incidents of intrusion or suspiciousof any kind.

behavior.
③ It is recommended to be constantly preparedto take appropriate action upon detection of
any abnormalities, such as the shutting downof any particular function.
④ Retain logs to allow analysis at a later time.

21

4.2.3 Operation Phase
The following is a list of the security efforts that shall be conducted in the Operation
Phase.
Table 4-5 Security Efforts Conducted in the Operation Phase
No.
1

Item

Guideline

User

Include all relevant

documentation

information in the user
documentation.

Description① Specify any disclaimers in the user
documentation.
② Ensure that products, when sold, come with
relevant information about their design
considerations.

2

3

Operation-time

Clearly define theusage

scope of operation-

usage and usage assumptions and impartdefinition

time usage.

them to operators.

User alert

Ensure that users are① Clearly define the scope of operation-time① It is recommended that there be somemeans of alerting users to the connection ofmade aware of

unknown devices or to the detection of any

operational faults assigns of suspicious behavior.

they occur.

② It is recommended that products found tocontain configuration errors are not usedwithout those errors first being corrected.
(Ensure that security has under nocircumstances been disabled due toconfiguration errors committed by users,
dealers or anyone else.)
4

Updates

Allow measures to① Establish a framework for secure firmware

also be taken at a

updating. (Firmware should ideally belater time.

downloaded from a dependable server witha secure boot key.)② Establishing a framework for remote
updating is also recommended.

5

Parties

Never place complete① Ensure that no harm would be caused byconcerned withtrust in the parties

the leakage of maintenance

operations

concerned.

documentation.
② Be prepared for possible threats frommalevolent parties during operations.

6

Sharing of

Share incident① It is essential to set up a system of sharing

incident

information and put it

and utilizing available incident information

information

to effective use.

in-house or among stakeholders.

224.2.4 Disposal Phase
The following is a list of the security efforts that shall be conducted in the Disposal Phase.
Table 4-6 Security Efforts Conducted in the Disposal Phase
No.
1

Item

Guideline

Description

Obfuscating

Designs should allow① It is recommended that boards beanalyses

for the Disposal

designed so they cannot be easily

phase.

reverse-engineered after being disposed.
② Designs should be resistant to reverse
engineering. (One method is to seek
authentication every time a request isconnected.)③ It is also recommended that software be
designed to avoid facilitating reverse
engineering.

2

Initialization

Allow settings to be① Allow settings to be reset to theirinitialized according

defaults.

to their defaults.

23

5 Threat Analyses
5.1

Threat Cases

Literature relating to the cases of automotive threats under preliminary discussion at the
Automotive On-board Devices SWG was utilized in the compilation of threat analyses. At
the Automotive On-board Devices SWG, we researched known incidents about 230 cases,
and then classified by risk characteristics: Target Equipment, Field-specific and Common,
Threat Classification and Connection Interface (Intrusion Route).

And we also evaluatedRisk Scores with two predefined parameters: Attack Exploitability and Degree of Damage
Impact. Table 5-1 lists the literature that has been surveyed by the Automotive On-board
Devices SWG with regard to the incident cases.

Table 5-1 Surveyed Literature List
No.
1

Literature surveyed

URL

Fiscal 2010 Automotive Information

https://www.ipa.go.jp/files/000014119.pdf

Security Trend Survey Report, IPA
2

Fiscal 2011 Automotive Information

https://www.ipa.go.jp/files/000024414.pdf

Security Trend Survey, IPA
3Appendix to the Fiscal 2011https://www.ipa.go.jp/files/000014165.pdf

Automotive Information Security Trend
Survey, IPA
4

Fiscal 2012 Automotive Information

https://www.ipa.go.jp/files/000027274.pdf

Security Trend Survey, IPA
5Security requirements for automotive

https://evita-

on-board networks based on dark-side

project.org/Deliverables/EVITAD2.3.pdf

scenarios, EVITA
6

Automotive Information Security

https://www.bookpark.ne.jp/cm/jsae/particul

Analysis Guide_JASO TP15002,

ars.asp?content_id= JSAE-tp-15002-PDF

Society of Automotive Engineers of
Japan
7

8

Driving Support Communication

http://www.itsforum.gr.jp/Public/J7Database

System Security Guidelines, ITS Forum/p41/ITS_FORUM_RC009V1_0.pdf

Survey Report Concerning Automotive

https://www.ipa.go.jp/files/000014059.pdf

Security Trends at Home and Abroadand Measures to Enhance Security
Awareness, IPA

24

9Automotive and Intelligent Home

https://www.ipa.go.jp/files/000013971.pdf

Appliance Built-in Systems Security
Survey, IPA
10

Future and Issues of Automotive

https://home.jeita.or.jp/page_file/20141009

Networking - Connected Car Security,

110119_FYXUHuv50O.pdf

IPA
11

Automotive Information Security Efforts

https://www.ipa.go.jp/files/000027273.pdf

Guidelines, IPA
12

Present Status of Automotive On-board

https://www.ffri.jp/properties/files/monthly_r

Network Security, FFRI

esearch/MR201310_Current%20state%20of%20automotive%20network%20security_JP
N.pdf

13

Proposals Concerning Tougher

https://www.ipa.go.jp/files/000034668.pdf

Information Security in Built-in
Automotive On-board Systems, IPA

5.2

Risk Characteristics

As part of the compilation of threat analyses using the incident cases that had beencollected at the Automotive On-board Devices SWG, the items of risk characteristics werereviewed. In addition to the four items of classification such as “target equipment”, “fieldspecific and common”, “threat classification” and "connection Interface (intrusion route)”
originally used at the Automotive On-board Devices SWG, three additional items that had
been used at the IPA`s IoT Safety/Security Development Guidelines Review WG forclassifying risk characteristics – Who: Connected, Whom: Threats Did Harm To, Where:
Risks Occurred – have been added. Table 5-2 provides a full list of risk characteristics.
Table 5-2 Risk Characteristics
No.
1

Item
TargetDescription
Equipment exposed to threats.

equipment
2

Field-specificSee Table 5-3 Field-specific and Common.”and common
3

Threat

List cases as per Table 5-4 Threat Classifications.

classification

Classification criteria are as follows.
① Threats resulting from user action.
=> “Configuration error/Virus infection.”② Threats launched by attackers with the express intention of
attacking.

25

=> “Eavesdropping/DoS attack/Fake messaging/Illegal
relaying.”③ The means used by attackers for launching attacks is
unknown or does not apply to the above but the following
damage has been incurred.
=> “Illegal setting/information leakage/log loss.”
If none of above applies to threats, classify as “unauthorized
utilization..”4

Connection

See Table 5-5 Connection Interface (Intrusion route) .

interface(Intrusion route)5

Who: connected

See Table 5-6 Who: Connected.

6

Whom: threats

See Table 5-7 Whom: Threats Did Harm To.

did harm to
7

Where: risks

See Table 5-8 Where: Risks Occurred.

occurred

Field-specific and common cases
Those cases that are dedicated to the automobile field relevant to the present

development activity have been categorized as being field-specific with a view togeneralizing tools. These work not only with automotive on-board devices, but also with
the important life apparatuses to be covered by CCDS in the future. Those cases that relate
to the automotive field, but that could occur with IoT devices as well, are categorized as
being common.
Table 5-3 summarizes criteria for distinguishing between field-specific and common
cases, along with criteria to consult when a threat fits to neither a field-specific nor acommon case.
Table 5-3 Field-specific and Common Cases
Category
Field-specificExplanation
Cases in which any equipment or intrusion route unique to on-board devices
appear to be involved are categorized as being field-specific, e.g., the target
is a CAN or ECU, or a DSRC or OBD is involved in the intrusion route.

CommonCases in which the target is an on-board device, but attacks launched on it
are considered general (such as phishing or a DoS attack), are categorized
as being common.

26



Threat Classifications

Table 5-4 lists typical classifications of the threats that from users’ actions and the threatsthat are caused by attackers’ interferences.
Table 5-4 Threat Classifications [5]ThreatExplanation

Configuration

A threat that is induced by an invalid action or setting made by the user

error

via the automotive user interface.
・For example, personal information is sent to an unintended service
provider by an infotainment function, or transmitted information iseavesdropped as the encryption function for a telematics service has
been turned off.

Virus infection

A threat that is induced by the infection of the automotive on-board
system by a virus or item of malicious software (malware, etc.) via a
device or storage media introduced by the user from the external world.
・For example, a virus penetrating a infotainment device has infected an
automotive on-board device via an on-board LAN.

Unauthorized

A threat that enables unauthorized individuals to take advantage of theutilization

functions of an automotive system by spoofing or exploiting device
vulnerabilities.
・For example, a session of unlocking communication has been spoofed
to unlock a car illegally.

Illegal setting

A threat that enables unauthorized individuals to tamper with the settingsof an automotive system by spoofing or exploiting device vulnerabilities.
・For example, network settings have been tampered with inhibiting
successful communication.

Information

A threat of any information to be protected on an automotive system being

leakagemade available to unauthorized individuals.
・Stored contents or user information of services are illegally stolen due
to intrusion into the equipment or the intercepting of communications.

Eavesdropping A threat of communication between automotive on-board devices or
between a car and a peripheral system being stolen or seized.
・For example, status information (such as the speed of the car andinformation about its position) has been eavesdropped while it is beingtransferred from the car to a surrounding system as a part of thenavigation or the congestion prediction services.

27

DoS attack

A threat that causes a system to close down or impede a service as aresult of invalid or excessive requests for connection.
・For example, excessive communications are directed at a smart key todisable user requests (locking or unlocking).

Fake

A threat that causes an automotive system to perform invalid operations

messagingor produce invalid displays by attackers sending spoofing messages to it.
・For example, a TPMS (Tire Pressure Monitoring System) message has
been faked to turn on a ca warning lamp when an error does not actuallyexist.

Log lossA threat that erases or falsifies an operation log or the like so it cannot beviewed later.
・An example is when an attacker falsifies a log of an attack action
committed by the attacker himself or herself in order to destroy evidenceof that attack.

Illegal relaying

A threat that manipulates a path of communication or takes over normal
communication or uses invalid communication to tamper with it.
・For example, smart key signals are relayed illegally, so that attackers
can unlock the car from a remote location.

Connection Interface (Intrusion route)
Table 5-1 shows the possible route of threat intrusion.
Table 5-5 Connection Interface (Intrusion route)
Connection

Transmissioninterface

distance

3G/GSM(In network
service)

Explanation

Communications method for digital cellular telephones.
A near-range wireless communication standard used byBluetooth0 to 10m

portable information devices for communicating between
devices only several meters apart.

CD

0m

One of the optic disc standards for recording digital
information.
Wireless communication between a roadside system and

DSRC

0 to 30m

the automotive on-board devices installed in a driving car.
Used by ITS.

eCall service(In network

interfaceservice)GPS

European automatic vehicle emergency notification system.

Within the

Global Positioning System. A system that precisely locatesrange ofwhere on the Earth you are now with the aid of artificial

28

reception
OBD

0m

RF

0 to 10mSD0m

satellites.
On-Board Diagnostics implemented by the computer (ECU)
mounted aboard an automobile.
Wireless communication for smart keys or on-board
communication.
A kind of memory card.
Universal Serial Bus, or a serial bus standard for

USB

0m

connecting peripherals to an information device, such as a
car navigation system.

Within theVICSrange ofreception



Wi-Fi

0 to 50m

Sensor0m

Special tools

0m

Vehicle Information and Communication System. A systemthat provides road traffic information, such as congestions
and traffic controls, by either FM multiplex broadcasts orradio beacons.
Technology for connecting network-ready devices
wirelessly.
On-board sensor.
An immobilizer cutter, dedicated maintenance tool or the
like.

Who: Connected
Table 5-6 summarizes information about who is connected according to the method ofsorting risk characteristics discussed at IPA`s IoT Safety/Security Development Guidelines
Review WG.
Table 5-6 Who: Connected [1]ThreatExplanation

Manufacturer or

A connection envisioned by the manufacturer at the time ofassociated company

design.

Service provider

A connection not envisioned by the manufacturer at the time ofdesign.

User (intentional)

An intentional connection made by the user.

User (wrong

An incorrect connection made by the user.

connection)
Attacker

A connection made by exploiting vulnerabilities.

Accidental

An accidental connection that happens to be established when anumber of connections are in place.

.”
29



Whom: Threats Did Harm To
Table 5-7 summarizes information about whom did threats harm according to the methodof sorting risk characteristics discussed at IPA`s IoT Safety/Security Development
Guidelines Review WG.
Table 5-7 Whom: Threats Did Harm To [1]ThreatExplanation

IoT functions

IoT applications, communication functions, security(communication, linkage,functions, etc.

concentration and more)
Inherent functions (e.g.,

An inherent function of a device or system, or a function

server, GW, thing)intended for safety assurance.

Information

Personal information, payment information, sensor data,
etc.

Bodies and properties

Users` bodies, properties and more.

OthersCommodities kept in a vending machine, cash in an ATM,
their bodies components, etc.



Where: Risks Occurred
Table 5-8 shows where risk sources are located, according to the method of sorting risk

characteristics under discussion by “IoT Safety/Security Development Guidelines [1]”Review WG.
Table 5-8 Where: Risks OccurredThreatExplanation

Ordinary-use interface

A user operation panel, service wired/wires interface, USB
terminal or the like.

Maintenance interface

A management operation panel, remote management
communications Interface, software update USB terminalor the like.

Informal interface

An unused port left open, USB terminal used only during
manufacture or the like.

Internally contained risk

Examples include a defect or bug that could be a sourceof a failure, a vulnerability that could be exploited, afunction that could do harm when it fails or isunauthorized utilization, etc.

Physical contact

Direct contact with the body.

30

6 Methods of Risk Assessment
Prior to the risk assessment of threat cases, the available methods of on-board disk
assessment for automotive on-board devices were explored on the basis of automotive
reference literature.

6.1

Modified ETSI Method

According to the ETSI (European Telecommunications Standard Institute), threats areclassified by likelihood and impact, and are assessed on a scale of three ranks for each ofthese two characteristics. Each of these ranks is assigned a score, and the resultant twoscores are multiplied together to arrive at a risk score [9]. Table 6-1 lists ETSI definitionsof likelihood and impact, while Table 6-2 lists definitions of risk score classifications.
Table 6-1 ETSI Likelihood and Impact Definitions
Item

Likelihood

Score

Rank

Definition

3

Likely2

PossibleNot fully prepared against threats, with attackers
being highly motivated.
Attackers do not require advanced skills or much
effort to launch attacks, only justifiable motivations.
Attacks are difficult to launch even with the latest

1

Unlikelyknowledge, meaning that attackers’ motivation is
low.

Impact3

High impact

Business is seriously damaged.

2

Medium impact

There is a significant impact.

1

Low impact

The chances of damage occurring are low.

Table 6-2 ETSI Risk Score Calculations
Item

Score

Rank

Definition(product)
6,9

CriticalSerious risks could occur that require action of thehighest priority.

Risk score

4

Major

1,2,3

Minor

Major risks could occur, even though they do have a
critical impact.
Minor risks may occur, but won`t necessitate action.

Since the wisdom of allowing for exploitability (the presence or absence of precedents)
and attackers’ motivations, as well as likelihood and impact scores, in the risk assessment
31

process was suggested at the Automotive On-board Devices SWG, available literature
concerning the methodology of risk assessment relevant to automotive on-board devices
was examined. As a result of this examination, the modified assessment method publicizedby the European Telecommunications Standard Institute (ETSI) was chosen as a reference[10] [11].
This assessment method analyzes the likelihood in terms of motivation and technicaldifficulty for assessment purposes. Table 6-3 shows definitions of motivation and technicaldifficulty. The modified method also works out likelihood ranks in terms of motivation andtechnical difficulty. Likelihood and impact definitions are given together in Table 6-4.

Table 6-3 Motivation and Technical Difficulty Definitions in the Modified ETSI
MethodItem

Rank

DefinitionHigh

Highly profitable

(in

terms

of

gain)

for

attackingindividuals or organizations.
Motivation

Moderate

Serviceconfusion(e.g.

offenderismotivatedbypleasure).
Low

Not very profitable.

None

Attacks technically and economically easy to launch(antecedents available).

Technical
difficulty

Solvable

Attacks theoretically possible.

StrongAttacks

extremely

difficulttolaunchtheoretically,

technically or economically.

Table 6-4 Likelihood and Impact Definitions in the Modified ETSI Method
Item

Likelihood

Impact

Rank

Value

Definition

Likely3

All elements exist.

Possible2

Some elements exist.

Unlikely

1

Essential elements are missing.

High

3

Users and services are seriously affected.

Medium2

Services shut down for a short period of time.

Low

1

Users and services are affected.

As with ETSI, risk scores are classified on the basis of the multiplication of likelihood andimpact. Table 6-5 shows definitions of risk score classifications.
32

Table 6-5 Risk Score Classifications in the Modified ETSI Method
Score

Item

Rank

Definition

9,6

CriticalAction mandatory.

4

Major

Caution required.

3,2,1

Minor

Immediate action not required.

(product)

Risk score

Table 6-6 shows the classifications of risk scores, in a matrix form, based on therelationships between the scores of motivation, technical difficulty and likelihood, as wellas the impact scores.
Use of the modified ETSI method is expected to allow risk assessment with attackers’
motivations being taken into consideration.

Table 6-6 Risk Score Definitions in the Modified ETSI Method
Motivation

Technical
DifficultyHigh (3)Medium (2)Low (1)

None

High

Solvable

Moderate

Likely (3)Critical (9,6)

None
Solvable

Low

Any

Any

Strong6.2

ImpactLikelihood

Possible (2)Major (4)

Unlikely (1)Minor (3,2,1)

CRSS Method (Applied CVSS Method)

The CVSS-based Risk Scoring System (CRSS) is a scheme of risk scoring that builds on
the Common Vulnerability Scoring System (CVSS), which is a scheme of risk scoring withproven success in the assessment of vulnerabilities in information devices and systems.
While CVSS has been formulated by Forum of Incident Response and Security Teams(FIRST) and is in widespread use as a scheme of assessing information systemvulnerabilities, it does not consider impacts severe enough to affect human bodies, suchas those of threats to an automotive on-board system. CRSS, on the other hand, addresses
the task of risk scoring for automotive on-board systems by classifying those impact
parameters that are partial, and therefore minor, as well as those that are full-scale, and33

therefore severe.
Among the three assessment criteria considered, CVSS uses base scores for risk
assessment. Table 6-7 shows the parameters of base metrics used by CRSS. By using
these parameters of base metrics, the impact and exploitability subscores are determinedby solving the equations given below and then risk scores are classified by the resultant
base scores. Table 6-8 shows definitions of the risk score classifications.

・Impact subscore = 10.41×(1-(1-C)×(1-I)×(1-A))
・Exploitability subscore = 20×AV×AC×Au・f (Impact subscore) = 0 (impact subscore 0), 1.176 (impact subscore other than 0)

Base score = ((0.6 × impact subscore) + (0.4 × exploitability subscore)-1.5) × f(impact subscore)

Table 6-7 Base Metrics
Parameter

AV: Access Vector

OutlineCategory
Local

0.395

Adjacent

0.646

Network

1.0

High

0.35

Medium

0.61

Low

0.71

Assesses the need to seek

Multiple

0.45

authentication from the target

Single0.56

system to exploit its vulnerabilities.

No need

0.704

Assesses the possibility of any

None

0.0

confidential information stored in the

Minor

0.275

Severe0.660

Assesses the possibility of any

None

0.0

information stored in the target

Minor

0.275

Severe0.660

Assesses the possibility of any

None

0.0

functionalities of the target system

Minor

0.275

Assesses from where a vulnerable
system can be attacked.

Assesses the complexity of the
AC: Access Complexity

conditions prerequisite to attacking avulnerable system.

Au: Authentication

C: Conf ident iality Im pacttarget system leaking when its
vulnerabilities are exploited.

I: Integrity Impact

system being falsified when its
vulnerabilities are exploited.

A: Availability Impact

Score

34

being delayed or shut down when its

Severe0.660

vulnerabilities are exploited.

Table 6-8 Risk Score Classifications
Threat level

Risk score(base score)Level

7.0 to 10.0

(serious)
Level

II

4.0 to 6.9III

0.0 to 3.9(warning)
Level(caution)

6.3

RSMA Method

RSMA (Risk Scoring Methodology for Automotive system) is the method whereby risk
scores are evaluated from a table of risk level assessments by impact subscore andlikelihood. Impact subscores are grouped into one of three damage classifications – safety,
personal information/privacy and property/corporate value. Further, the likelihood isassessed at one of three levels, high, medium and low, pursuant to a likelihood assessment
table on the basis of the five parameters – duration, specialized knowledge, TOE
knowledge, opportunity and devices. These are summarized in Table 6-9 and Table 6-10.
Risk scores are evaluated in a matrix of impact subscores and likelihoods. The evaluationtable is given in Table 6-11.

Table 6-9 Likelihood Parameters
Parameter

Duration

Explanation

Criteria

Time needed to identify

Realistic.

0

and then exploit

Non-realistic.

19

vulnerabilities.
Specialized

Technical specialized

Amateurs.

0knowledgeknowledge required.

Professionals.

3

Publicized information.

0

Information available to dealers,

3

TOE
knowledge

Knowledge limited toattacked objects(TOE).

developers and manufacturers.
Information available only to limited sets35

7

of users.
Access not required.
Time and frequency ofOpportunity

access to attacked
objects (TOE).

0

Access required/unlimited access.
Access required/limited frequencies.

4

Access required/Inaccessible.

19

Commercial products (commercial

0

hardware, software and other products).
Devices

Hardware and software

Special devices (such as dealer-owned

used to launch attacks.

products).
Custom devices (such as products

48

dedicated to development work).

Table 6-10 Likelihood Level Assessment Table
Likelihood level

Value

High

0 to 14

Medium15 to 24Low

25 or more

Table 6-11 Risk Level Assessment Table
DamageImpactclassification

subscore

SafetyPersonal

Description

Likelihood
Low Medium HighNone

No human impact.

0

0

0

Low

Minor.

L

L

M

MediumSerious.

L

M

H

High

Life threatening.

M

H

H

None

No personal information/privacy.

0

0

0

Low

Information that does not lead to

L

L

M

M

M

H

0

0

0

L

L

M

L

M

H

individual identification alone.

information/privacy
High

Information that helps identify
individuals.

None

No impact on properties/corporate
values.

Property/corporate

Low

value

Limited to impact in-house only
(low business impact).

Medium

Impacting customers (medium
business impact).

36

High

Impacting both customers and

M

H

H

business (high business impact).

6.4

CCDS Prototype Method

The Automotive On-board Devices SWG uses a method whereby risk scores are ranked
on the basis of attack exploitability and user impact subscores. This method uses
exploitability and impact subscores as basic axes with a view to expediting assessment
and development in the initial stages with reference to the information found in the“Common Vulnerability Scoring System CVSS Overview.”
Exploitability subscores are broken down into four ranks, S, A, B and C, S being thelowest level of exploitability and C being the highest. Rank C is assigned 10 points. The
higher a threat level is, the higher its assigned score. A large score difference of 5 points
is allowed between a threat having no security in place and one having at least one security
feature in place, with 2 points allowed between all other threats. Consequently, the four
ranks are assigned 10, 5, 3 and 1 points, respectively.
Impact subscores are broken down into four levels – minor, medium, serious anddestructive. The destructive level is assigned 10 points and other levels are evaluatedaccordingly. Attack exploitability and impact subscore definitions and scores are listed inTable 6-12 below.

Table 6-12 Scores of Attack Exploitability and Impact Subscores
Item

Item definition

Rank

Rank definition

Value

Multiple conditions(authentication, special privilegesSand so forth) are required, andAre there any

only local connections (attacks)

conditions

are possible.

necessary to

A single condition

Exploitability

launch attacks(authentication, special privilege

subscore(such asAor the like) is required, and only

authentication orconnections (attacks) are

specialpossible.

privileges)?

1

3

One or more conditions(authentication, special privilege

B

and so forth) are required, or only
local connections (attacks) are37

5

possible.
No need for conditions forlaunching attacks, andCconnectable (attacks possible)

10

from a wireless network.
Attacks launched will leave no
impact on users or only produce
Minora minor display error.
Furthermore, there is no leak of

1

information that will help identify
individuals.
Attacks launched will put users at
What are theimpact subscores

Mediuma disadvantage or allow anindividual to be identified from

Impactand ranges ofleaked information.

subscore

attacks andAttacks launched will not only put

secondaryusers at a disadvantage, but also

damage?

Seriousproduce secondary damage or
allow multiple individuals to be3

5

identified from leaked
information.
Attacks launched will produce
Destructive

damage with either fatal
consequence or secondary

10

damage.

The Automotive On-board Devices SWG decided to take attackers’ motivations into
account when conducting risk assessments, because higher attackers’ motivations tended
to give higher threat risk levels. Attackers` motivations were assessed at one of three levels,
low, medium, and high, on the basis of the CCDS method. The medium level was set togive a 1.25 times higher risk score, and the high level, a 1.5 times higher risk score. Risk
scores are calculated by the following equation.

Risk score= (Exploitability subscore + Impact subscore) × Attackers` motivation

Table 6-13 summarizes attackers’ motivations, with definitions of the risk scores listed inTable 6-14.

38

Table 6-13 Definitions of Attackers’ Motivations
Item

Rank

Definition

Low

Value

Threats occur accidentally, with attackers having no1

particular intention at all.
Attackers`

Mediummotivation

Attackers seek experimentation, amusement,

1.25

exhibitionism or other objectives.
Attackers have stronger incentives, such as gainingHigh

monetary profits or impacting security.

Table 6-14 Risk Score Classifications
Risk score

Criterion

Low

Less than 8

Middle8 or more but less than 12High
Essential

12 or more but less than17
17 or more

39

1.5

7 Results of Risk Assessment
7.1

Modified ETSI Method

As the modified ETSI method calculates risk scores on the basis of the product ofmultiplication of likelihood and impact, the risk scores are discrete. Furthermore, since only
a score of 4 will produce a “major” result, the modified ETSI method is more liable toproduce results in the “critical” (red) and “minor” (yellow) bands than the other methods.
Table 7-1 summarizes some examples of risk assessments produced by the modified ETSI
method.

Table 7-1 Examples of Risk Assessments Produced by the Modified ETSI Method

No

Possible threats

Possible damages

Targetdevices

Field-

Threatspecific orclassi-commonfycation

Modified ETSI method
Whom:
Where:
Who: Threat
Techn
Risks
Connec s Did
tion
Occurr Motiv ical Likeli Impact Risk
ted
Harmation difficu hoodscore
ed
InterfaceTo
lty
Connec-

1

DoS attacks
Shutdown of alllaunched on anservices that
automotive on-board require
network via an
communication
external network
functions

Automotive
on-board
devicesCommonDoS
Attack3G/
GSM

2Transmission of
fake messages byserver spoofing

Automotive
on-board
devicesCommonFakemessaging

3G/
GSM

Automotive
on-board
devicesCommonFakemessaging
ﾞ

3G/
GSM

Automotive
on-board
devicesCommonEavesdrop
ping

Wi-Fi

Automotive
on-board
devicesCommonIllegalrelaying

Automotive
on-board
devicesCommonAutomotive
on-board
devices

ECU

3

4

5

6

7

8

User confusion
and moreFreezing of systems
Shutdown of
due to streaming
infotainment
content exploiting
servicesbrowser bugs
Eavesdropping of
Use of services
communication
not intended bymessages by taking the operation
advantage of third management
parties` receivers
authorities
Delivery of
messages
Confusion caused
containing incorrect by the delivery oflocations throughmessages
unauthorized
containing
utilization of GPS
incorrect
generators by third locations
parties
Spoofing of asecond automotive
on-board device
Confusion caused
through the use ofby the delivery of
the original
drive information
automotive on-board
containing
device by users orincorrect
the unauthorized
information
utilization ofreceivers by third
parties
Tracing personal
locations fromreceived messages
through abuse of
Personal profilingon-board devices byusers or use ofreceivers by third
parties
Intentional
ECU disabled
shutdown of thefrom working
control ECU`scorrectly,
control functions
crippling theOrdinar
IoT
Attackey-use Moder Solva
functiorInterfac ate
ble
ns
e

2

3

6

2

2

4

2

2

4

OrdinarAttacke Inform y-use
Solva
High
r
ation Interfac
ble
e

3

1

3

GPS

Inhere Ordinar
Attackenty-use Moder Solvarfunctio Interfac ate
ble
ns
e

2

2

4

Unauthorizedutilization

3G/
GSM

Ordinar
User
Inform y-use Moder Solva(intenti
ation Interfac ate
ble
onal)
e

2

2

4

FieldspecificInformation
leakage

Wi-Fi

OrdinarAttacke Inform y-use
Solva
High
r
ation Interfac
ble
e

3

1

3

FieldspecificUnauthorizedutilization

3G/
GSM

Inhere Ordinar
Attackenty-use Moder Solvarfunctio Interfac ate
ble
ns
e

2

3

6

40

User
OrdinarIoT(wrongy-use Moder Solva
functioconnecInterfac ate
ble
ns
tion)
e
OrdinarUser
IoT
y-use Moder Solva(intenti functio
Interfac ate
ble
onal)
ns
e

from 3G/LTE lines vehicle functions
by third parties
during normal
operations
Dealers’ personnel
falsify vehicle status Tampering withinformation fromsettings to make
9 Bluetooth devices, unintended
such as achanges tosmartphone, during performance
maintenanceMalfunctioning of
the information in
the ECU`s
information
Information
functionsfunctions
10 intentionally induced prevented fromby third parties from working correctlyan SD card interface
during normal
operations

Automotive
on-board
devices

FieldspecificIllegalsetting

ECU

FieldspecificUnauthorizedutilization

OrdinarService
Inform y-use Moder Solva
Bluetooth provide
ation Interfac ate
ble
r
e

2

2

4

Inhere Ordinar
Attackenty-use ModerNonerfunctio Interfac ate
ns
e

3

1

3

SD

Critical (6,9)
Major (4)Minor (3, 2, 1)

7.2

CRSS Method (Applied CVSS Method)

The CRSS method changes the impact subscore parameter categories from “partial” to“total” and from “total” to “severe” to better reflect risk assessment solutions for automotive
on-board systems than the original CVSS method. For this reason, the impacts on
information processing and vehicle control are categorized as being “minor” and “severe”
respectively, so that impact subscores tend to appear lower than those produced by othermethod. Consequently, there are fewer serious risk score levels (red). Furthermore, whenassessed by the CRS method, the same threat case could characteristically deliver
different risk scores depending on the attack route taken (3G/GSM, Wi-Fi and so forth).
Table 7-2 summarizes examples of risk assessments produced by the CRSS method.

Table 7-2 Examples of Risk Assessments Produced by the CRSS Method
FieldNo

Possible threats

Possible

Targetspecificdamages

devicesandcommon1

2

3

4

Threatclassif
ication

Conne
ction
Interface

Whom:
Who: Threat s Where
Connec
ted

Did
Harm
To

CRSS (CVSS-based)

ExploitC
I
A
ImpactOccurre Access Access Aut hent ability Conf ide Integrit Av ailabi subsc or Risk
Vect or Compl e ication subscor ntiality
y
lity
score
d
e
xity
e
Impact Impact Impact: Ri sks

AV

AC

Au

DoS attacks
Shutdown of all
Ordinalaunched on anservices that
Automotive
DoS
IoT
3G/ Attack
ry-use Net
automotive on-board require
on-board Common
functio
Low Single
GSM
erInterfa work
network via an
communication
devices
Attackns
ce
external network
functions
User
OrdinaTransmission of fake
Automotive
Fake
IoT
User confusion
3G/ (wrong
ry-use Netwo
messages by server
on-board Common messa
functio
Low Single
and more
GSM conne
Interfa rk
spoofing
devicesging ﾞ
ns
ction)
ceFreezing of systems
OrdinaShutdown ofAutomotive
Fake
User
IoT
due to streaming
3G/
ry-use Netwo
infotainment
on-board Common messa(intent functio
Low Single
content exploiting
GSM
Interfa rk
services
devicesging ﾞ
ional)
ns
browser bugs
ceEavesdropping of
Use of services
Ordinacommunication
not intended by Automotive
Eaves
Attackry-use Adjace Mediu Multipl
messages by taking the operation
on-board Common droppi Wi-Fi
Informer
Interfa nt
me
advantage of third
management
devicesng
ation
ce
parties` receivers
authorities

41

7.95

None Minor Minor

4.94

5.46

7.95

None Minor Minor

4.94

5.46

7.95

None Minor Minor

4.94

5.46

3.55

Minor None None

2.86

1.92

5

6

7

8

9

10

Delivery ofConfusion
messages containing
caused by theincorrect locations
Inhere Ordina
delivery ofAutomotive
Illegalthrough
Attacknt
ry-use Netwo
messageson-board Common relayin GPS
Low None 10.00
unauthorized
er functio Interfa rk
containing
devicesgutilization of GPS
nsce
incorrect
generators by third
locationsparties
Spoofing of asecond automotive
Confusion
on-board device
caused by thethrough the use of
Unautdelivery of
Ordinathe original
Automotive
horize
User
drive
3G/
ry-use Netwo
automotive on-board
on-board Commond(intent Inform
Low Single 7.95
information
GSM
Interfa rk
device by users ordevicesutilizat
ional) ation
containingcethe unauthorizedion
incorrect
utilization of
information
receivers by third
parties
Tracing personal
locations fromreceived messages
InformOrdinaAutomotive
through abuse of on- Personal
Fieldation
Attackry-use Adjace Mediu Multipl
on-board
Wi-Fi
Inform
3.55
board devices by
profiling
specific Leaka
er
Interfa nt
me
devices
ation
users or use ofgecereceivers by third
parties.
Intentional shutdown
ECU disabledof the control ECU`s
Unautfrom working
Inhere Ordina
control functions
horizecorrectly,
Field3G/ Attacknt
ry-use Netwo Mediu
from 3G/LTE lines
ECU
dSingle 6.83
crippling thespecificGSM
er functio Interfa rk
mby third parties
utilizatvehiclensceduring normalionfunctionsoperations
Dealers’ personnel
Tampering withfalsify vehicle statussettings toServicOrdinainformation from
Automotive
makeField- Illegal Bluetoery-use Adjace
Bluetooth devices,
on-board
InformLow Single 5.14
unintended
specific setting oth provid
Interfa nt
such as adevicesation
changes toerce
smartphone, duringperformance
maintenance.
Malfunctioning of theinformation in the
ECU`s information
Information
Unaut
Inhere Ordina
functionsfunctionshorizeFieldAttacknt
ry-useintentionally induced prevented fromECUdSD
Local Low None 3.95
specific
er functio Interfa
by third parties from working
utilizatnscean SD card interface correctlyionduring normal
operations

None Minor Minor

4.94

6.42

None Minor Minor

4.94

5.46

Minor Minor None

4.84

3.39

Sever Sever
e
e

9.21

7.95

Minor Minor None

4.94

4.14

None Minor None

2.86

2.11

None

Level Ⅲ
(Serious)
Level II (Warning)
Level Ⅰ
(Caution)

7.3

RSMA Method

While impact subscores are categorized based on damage classifications forassessment, the impact subscore level is directly reflected in the risk score as an axis ofassessment, as defined in the risk level assessment table. The likelihood level is anotheraxis of assessment in the risk level assessment table, and is determined by the sum totalof the scores of the five parameters: duration, specialized knowledge, TOE knowledge,
opportunity and devices. The RSMA method involves more assessment parameters thanother methods, so that the number of impact subscore parameters and likelihood subscoreparameters to be assessed are out of balance. Table 7-3 summarizes examples of risk
assessments produced by the RSMA method.
42

Table 7-3 Examples of Risk Assessments Produced by the RSMA Method
Field-

No

Possible threats

Possible

Targetspecif ic

damages

devicesandcommon

1

2

3

4

5

6

7

8

9

10

ConnecThreatclassif icationtion

W hom:
W ho:

ThreatConnec s Did

Interf a
ce

ted

Harm
To

RSMA Method
W here:SpecialRi sks Damag Impact
TOEe
Durati o ized
Oppor Devic Likeli Risk
Occurrsubscoknowl eclassifinknowl
etunity es
hood score
ed
re
dge
cation
dge

Acces
Prope
DoS attacks
Shutdown of
Ordin
s not
rty
LimiteCommlaunched on an
all services
Automotive
IoT
aryProfe
requirDoS 3G/ Attack
and Mediu Realis
d setsercialautomotive on-board that require
on-board Common
functi use
ssion
edHigh H
attack GSM
ercorpor m
tic
of
produ
network via an
communicatio
deviceons Interf
als
and
ate
users
cts
external network
n functions
ace
unlimi
value
ted
Acces
Prope
User
Ordin
s not
Fake
rty
LimiteCusto
Transmission of
User
Automotive(wron IoT
aryProfe
requirmess 3G/
and Mediu Realis
d setsm
Mediu
fake messages byconfusion and on-board Commongfuncti use
ssion
ed
M
aging GSM
corpor m
ticof
produ mserver spoofing
more
deviceconne ons Interf
als
and
ﾞ
ate
users
cts
ction)
ace
unlimi
value
ted
Acces
Prope
Ordin
s not
Freezing of systems
Fakerty
LimiteCusto
Shutdown ofAutomotive
User IoT
aryProfe
requirdue to streaming
mess 3G/
and Mediu Realis
d setsm
Mediu
infotainment
on-board Common(intent functi use
ssion
ed
M
content exploiting
aging GSM
corpor m
ticof
produ mservices
deviceional) ons Interfalsandbrowser bugs
ﾞ
ate
users
cts
ace
unlimivalue
ted
Use ofEavesdropping ofservices notcommunication
intended bymessages by taking
the operation
advantage of third
management
parties` receivers
authorities

Perso
Deale
Ordin nal
rs, Limite
Custo
Automotive
Eaves
ary- inform
Profe devel dAttack Inform
Realism
Mediu
on-board Common droppi Wi-Fi
use ation Low
ssion opers, acces
L
er
ation
tic
produ mdeviceng
Interf andals manuf s
cts
ace privac
acture countyrsDelivery ofConfusion
messagesPrope
caused by the
Ordin
Limitecontaining incorrect
Inhererty
PublicCommdelivery ofAutomotive
IllegalaryProfedlocations throughAttack nt
and Mediu Realis
ized
ercialmessageson-board Common relayi GPS
use
ssion
acces
High H
unauthorizederfuncticorpor m
tic
informprodu
containing
deviceng
Interfalssutilization of GPS
ons
ate
ation
cts
incorrect
ace
countgenerators by thirdvalue
locationsparties
Spoofing of asecond automotive
Confusion
on-board device
caused by thePropethrough the use of
Unaut
Ordin
Limitedelivery ofrtyLimiteCusto
the original
Automotive
horizeUser
aryProfe
d
drive
3G/
Informand Mediu Realis
d setsm
Mediu
automotive on-board
on-board Commond(intent
use
ssion
acces
M
information
GSM
ation
corpor m
ticof
produ mdevice by users ordeviceutiliza
ional)
Interfalsscontaining
ate
users
cts
the unauthorized
tion
ace
count
incorrect
value
utilization of
information
receivers by third
parties
Tracing personal
locations fromreceived messages
through abuse of
Personal
on-board devices by profilingusers or use ofreceivers by third
parties.

Perso
Ordin nal
LimiteInformLimiteCusto
Automotive
ary- informProfedField- ation
Attack Inform
Realisd setsm
Mediu
on-board
Wi-Fi
use ation Low
ssion
acces
L
specific leaka
er
ation
tic
of
produ mdeviceInterf and
als
s
ge
users
cts
ace privac
countyIntentional shutdown ECUof the control ECU`s prevented
control functions
from working
from 3G/LTE lines
correctly,
by third parties
crippling theduring normal
vehicleoperations
functions
Dealers’ personnel
Tamperingfalsify vehicle status
with settings
information fromto makeBluetooth devices,
unintended
such as achanges tosmartphone, duringperformance
maintenance.
Malfunctioning of
the information inInformation
the ECU`sfunctionsinformation
prevented
functionsfrom working
intentionally induced correctlyby third parties from

Deale Acces
Unaut
Ordin
rs, s notInhereSpecihorizearyProfe devel requir
Field3G/ Attack nt
Realisal
ECUduse Safety Highssion opers, edHighspecificGSM
erfunctitic
devic
utiliza
Interfals manuf and
ons
es
tion
ace
acture unlimi
rs ted
Deale
Prope
Ordin
rs, Limite
Servicrty
Speci
Automotive
IllegalaryProfe devel d
FieldBluetoeInformandRealisal
on-board
settinuse
Lowssion opers, accesHigh
specific
oth provid ation
corportic
devic
deviceg
Interfals manuf s
er
ate
es
ace
acture count
value
rs
Deale
Prope
Unaut
Ordin
rs,
InherertySpecihorizearyProfe devel Inacc
FieldAttack nt
andRealis
al
ECU
d
SD
use
Low
ssion opers, essibl
Low
specificerfuncticorportic
devic
utiliza
Interfals manuf e
ons
ate
es
tion
ace
acture
value
rs

43

H

M

L

an SD card interface
during normal
operations

7.4

CCDS Prototype Method

The modified CCS method offers a simpler solution to calculating risk assessment thanthe other methods because it uses only the exploitability subscore and impact subscore as
the basic items of assessment. Moreover, it has four risk score ranks defined to reducesignificant variations in scoring and the tendency of risk scores to favor the center. An effort
to reflect attackers’ motivations in the risk scores has also been incorporated. This method
was so radical that concerns were raised over the validity of its risk assessments. But
following risk assessments conducted with the other three methods using the same set of
threat cases, it was found to demonstrate similar trends despite slight method-specificdifferences. Table 7-4 summarizes examples of risk assessments produced by the CCDS
Prototype Method.

Table 7-4 Examples of Risk Assessments Produced by the CCDS Prototype Method
CCDS Prototype Method
Whom :
Where:
Who: Threats
Exploita
Attacketion
specific
Risks
ImpactConnec Did
bilityrs`
Risk
Classifi
OccurresubscorandInterfactedHarm
subscormotivati scorecationdecommonToeone
Field-

No

Possible threats

1

DoS attacks launched on an
automotive on-board network
via an external network

2

Transmission of fakeUser confusion and moremessages by server spoofing

3

4

5

6

7

8

9

Possible damages

Shutdown of all services that
require communication
functionsTargetdevices

ConnecThreatAutomotive
on-board
devicesCommonDoS
attack3G/
GSM

Automotive
on-board
devices

Fake
Common messag
ing ﾞ

3G/
GSM

Freezing of systems due toAutomotive
Shutdown of infotainment
streaming content exploiting
on-board
servicesbrowser bugs
devices
Eavesdropping of
Use of services not intended by Automotive
communication messages by
the operation management
on-board
taking advantage of third
authorities
devicesparties` receivers
Delivery of messages
containing incorrect locations Confusion caused by the
Automotive
through unauthorized
delivery of messages containing on-board
utilization of GPS generators incorrect locations
devicesby third parties
Spoofing of a second
automotive on-board device
through the use of the original Confusion caused by the
Automotive
automotive on-board device by delivery of drive information
on-board
users or the unauthorized
containing incorrect infor mation devices
utilization of receivers by third
parties
Tracing personal locations
from received messages
Automotive
through abuse of on-board
Personal profilingon-board
devices by users or use ofdevicesreceivers by third parties
Intentional shutdown of thecontrol ECU`s control
ECU prevented fro m working
functions from 3G/LTE lines
correctly, crippling the vehicle ECU
by third parties during normal functions
operations
Dealers’ personnel falsify
Tampering with settings to
Automotive
vehicle status information
make unintended changes toon-board
from Bluetooth devices, such
performancedevices
as a smartphone, during

Fake
Common messag
ing ﾞ

3G/
GSM

CommonEavesdropping

Wi-Fi

Attacke InformartionCommonIllegalrelaying

Common

Unauthorizedutilizati
on

44

IoT
Ordinary
Attackefunction -usersInterface
User
IoT
Ordinary(wrongfunction -useconnectsInterface
ion)
User
IoT
Ordinary(intenti function -useonal)sInterfaceC

Serious Medium

EssentialCMedium Medium

High

C

Medium Medium

High

Ordinary-useInterfaceB

Minor Medium

Low

GPS

InherenOrdinary
Attacket-userfunctionInterfaces

BMedium Medium Middle

3G/
GSM

User
Ordinary
Informa(intenti
-use
tion
onal)
InterfaceB

Medium Medium Middle

FieldspecificInformaOrdinary
Attacke Informa
tion
Wi-Fi
-use
r
tion
leakage
InterfaceB

Minor Medium

FieldspecificUnauthorizedutilization

InherenOrdinary
Attacket-userfunctionInterfaces

B

Destruc
tive

Fieldspecific

Service
Ordinary
Illegal Bluetoo
Informaprovide-use
settingthtionrInterfaceC

Medium Medium

3G/
GSM

High

Low

EssentialHighmaintenanceMalfunctioning of theinformation in the ECU`s
information functions
10 intentionally induced by third
parties from an SD card
interface during normal
operations

Information functions prevented
ECU
from working correctlyFieldspecificUnauthorizedutilizationSD

InherenOrdinary
Attacket-userfunctionInterfaces

BMedium Medium Middle

Essential
High
MiddleLow

45

8 Trend Analyses Of Risk Assessment
Using the results of the risk assessments of the listed threat cases, trend analyses byitem were conducted with regard to the six risk characteristics: field-specific and common
threats, threat classification, connection Interface (intrusion route), who: connected, whom:threats did harm to and where: risks occurred.
Since risk analyses of the around 230 known incidents listed had already been completed,
the risk assessment trend analyses were carried out using results of risk assessment with
the CCDS Prototype Method. “Essential”, “High”, “Medium” and “Low” occurrences of thesix risk characteristics by category item were counted, and the ratio of the number of“Essential” and “High” occurrences by category was calculated as an E&H ratio, along withthe risk score average. Risk trends by category item were then analyzed on the basis ofthese values.

8.1

Field-specific and Common Threat

Table 8-1 summarizes the field-specific and common threat trend analyses conducted. No
significant difference in the E&H ratio is seen between field-specific and common threats,
but in terms of the “Essential” ratio, the field-specific threat cases score 46.0% whencompared with 24.6% for common threats. Field-specific threat cases that specialize in theautomotive field, including impacts on vehicle control, have a much higher “Essential” ratio
than common threat cases concerned with information processing, which could also occur
with other IoT devices. Field-specific threat cases are thus found to present more severe
impacts than common threat cases.
Formulating field-common security guidelines or developing a field-common security
verification infrastructure is clearly important, but responding to threats that could deliver
tougher impacts should call for the formulation of field-specific guidelines or thedevelopment of field-common verification infrastructures.

46

Table 8-1 Field-specific and Common Threat Trend Analyses
Category

Essential

High

Middle Low

Total
occurrences

Risk
score
average

E&H

Essential

ratio

ratio

Field-specific

80

44

38

12

174

17.0

71.3%

46.0%

Common

14

26

13

4

57

14.5

70.2%

24.6%

8.2

Threat Classification

Table 8-2 summarizes threat classification trend analyses. Among the 10 items in thethreat classifications, unauthorized utilization and fake messaging are found to have a highE&H ratio. As outlined in Table 5-4, unauthorized utilization is defined as unauthorizedindividuals taking advantage of the functions of an automotive system by spoofing or
exploiting device vulnerabilities. Fake messaging is a threat posed by an attacker sending
a spoofing message to an automotive system causing it to malfunction or display incorrect
information. Considering the fact that both kinds of attacks are based on spoofing, the needto take countermeasures against spoofing in the operation phase of an automotive systemshould be factored into the guidelines for consideration.
Furthermore, configuration errors have a low M&YH ratio but users sometimes keep theirautomotive systems running without security being enabled because of configuration errors,
which might pose a major threat to security.

Table 8-2 Threat Classification Trend Analyses
Category
Configuration
errorsVirus infection
Unauthorized
utilization
Illegal setting

Total

Risk score

occurrences

average

0

4

14.8

50.0%

8

0

29

17.3

72.4%

18

10

2

63

18.1

81.0%

8

2

2

15

14.4

73.3%

Essential

High

Middle Low

2

0

2

14

7

33
3

47

E&H ratio

Information

0

1

1

6

8

7.2

12.5%

Eavesdropping

3

3

2

2

10

13.2

60.0%

DoS attack

21

12

18

3

54

15.1

61.1%

17

16

3

0

36

19.7

91.7%

Log loss

0

0

0

1

1

7.5

0.0%

Illegal relaying

1

5

5

0

11

12.5

54.5%

leakageFakemessaging

8.3

Connection Interface (Intrusion Route)

Table 8-3 summarizes connection Interface (intrusion route) trend analyses. OBD isgenerally considered to be an intrusion route vulnerable to attacks, but registered lower
E&H ratio than other route. This is probably because the risk assessment in the CCDS
Prototype Method, used for the trend analyses, assessed exploitability subscores on thebasis of the CVSS method. It therefore tended to give a higher exploitability subscores tolocal attacks than attacks originating from wireless networks, resulting in lower risk scoring.
3G/GSM and Wi-Fi, both of which were open to remote manipulation, had been predicted
to result in high risk scores generally, but turned out to deliver lower E&H ratios than otherintrusion route. This is probably because many threat cases relating to information
processing were involved, with impact subscores moving from medium to minor, giving rise
to lower risk scoring.

Table 8-3 Connection Interface (Intrusion Route) Trend Analyses
Category

Total

Risk score

occurrences

average

3

47

16.4

68.1%

2

0

12

18.4

83%

2

0

0

3

20.8

100%

0

3

0

0

3

15.4

100%

1

2

0

0

3

16.3

100%

Essential

High

MiddleLow

3G/GSM

17

15

12

Bluetooth

7

3

CD

1

DSRC
E-call service
interface48

E&H ratio

GPS

4

4

1

0

9

17.4

88.9%

OBD

25

8

11

4

48

16.4

68.8%

RF

13

11

2

2

28

18.3

85.7%

SD

2

0

3

0

5

16.0

40.0%

USB

2

3

4

0

9

14.3

55.6%

VICS

0

3

0

0

3

15.4

100%

Wi-Fi

12

11

12

2

37

15.5

62.2%

Sensor

2

0

0

0

2

18.8

100%

6

5

4

5

20

12.9

55.0%

Specialequipment

8.4

Who: Connected

Table 8-4 summarizes who-connected trend analyses. Service providers had a somewhat
higher E&H score than the others. This may be attributable to the fact that no threat use
cases were essentially considered for service providers, i.e. a connection not envisioned
by manufacturers at the time of design, hence no risks were expected.
Table 8-5 Who: Connecte
Category
Manufacturers andEssential High Middle Low

Total

Risk score

E&H

occurrences

average

ratio

0

0

0

0

0

-

-

Service provider

0

5

0

1

6

11.5

83.3%

User (intentional)

0

10

12

0

22

12.5

45.5%

2

2

2

0

6

15.3

66.7%

Attacker

92

53

37

15

197

17.0

73.6%

Accidental

0

0

0

0

0

-

-

related firms

User (wrong
connection)

49

8.5

Whom: Threats Did Harm To

Table 8-6 shows whom-did-threats-harm trend analyses. The IoT functions delivered an
E&H ratio somewhat higher than others, but these attacks are mostly those launched fromwireless networks and tend to deliver a lower exploitability subscore, resulting in higher
risk scores. Attackers might launch attacks on an automotive system from a wirelesssystem to uauthorized utilization or take over its IoT functions via remote control. Thisposes a greater threat by exploiting the IoT functions as a starting point, rather than simply
harming certain kinds of information, such as personal and payment information. In thepresent context of a growing number of automotive systems linking and syncing with other
IoT devices, responses to such threats should be mandatory.

Table 8-6 Whom: Threats Did Harm To
Category

Essential High Middle Low

Total
occurrences

Risk
score
average

E&H
ratio

IoT functions(communication,

5

23

2

2

32

15.4

87.5%

74

25

31

4

134

17.8

73.9%

Information

14

19

19

10

65

13.7

55.4%

Bodies and properties

0

0

0

0

0

-

-

Others

1

3

0

0

1

19.5

100.0%

linkage, concentrationand more)
Inherent functions(e.g., server, GW,
thing)

8.6

Where: Risks Occurred

Table 8-7 summarizes Where-risks-occurred trend analyses. There is not a significant
difference between ordinary-use Interface and maintenance Interface in their E&H ratio,
but in terms of the “Essential” ratio, the uppermost risk level, ordinary-use Interface andmaintenance Interface are 37.2% and 55.8% respectively. If it is assumed that themaintenance Interface or informal Interface, as used by managers in running or updating
software, will not be used for launching attacks because they are hidden and not publicized,50

professionals could navigate through such Interface to launch attacks.
Table 8-7 Where: Risks Occurred
Category

Ordinary-use
Interface
MaintenanceInterface
InformalInterface
Internallycontained risk
Physicalcontact

Essential High Middle Low

Total
occurrences

Risk
score
average

E&H

Essential

ratio

ratio

58

55

36

7

156

16.7

72.4%

37.2%

29

8

11

4

52

16.6

71.2%

55.8%

5

7

3

4

19

13.0

63.2%

26.3%

0

0

0

0

0

-

-

-

1

0

1

1

3

13.8

33.3%

33.3%

9 Conclusion
While this document is designed to present security guidelines related to automotive onboard devices, the discussions of possible threats, security procedures to be performed in
the lifecycle of a product, and other topics presented could also apply to other fields.
Stringent use of these guidelines is recommended to allow for the efforts of security
countermeasures in the processes of the development of a range of products.
As the growing popularity of the Internet of Things (IoT) means that previously
standalone domestic appliances continue to provide a variety of connections to increase
their functionality, the frequency of attacks that target these devices are only expected toincrease. The number of cases of attacks launched on automotive on-board systems has
noticeably been growing in recent years, and often makes headlines in the media, which is
motivating interest in car security. The following measures are required to pursue securityconscious design and development activity in response to these and other evolving cases
and threats:①

Update threat cases and have such updates reflected in the review of threat

analyses and countermeasures.
②

Conduct a threat analysis by assuming a system responsive to cases of evolving
use to explore requirement specifications and countermeasures.

It has also been found from the threat case risk assessments and trend analyses by risk
51

characteristics that attackers are able to breach systems through a carried-in device or via
an external interface to attempt takeover by spoofing or launching more risky threats. In
parallel with the formulation of field-specific security guidelines, the CCDS is working todevelop security validation and verification tools compatible with IoT devices as part of its
security verification infrastructure formation initiative. Two kinds of validation andverification tools have also been developed in the automotive on-board devices field. The
reader is strongly advised to utilize tests starting with possible interface with an automotive
on-board devices the most likely trapdoor.
Finally, thanks are due to the members of the Automotive On-board Devices SWG for
their extensive support in compiling this document.

10 Association with the “IoT Safety/Security
Development Guidelines”“IoT Safety/Security Development Guidelines” was released by the Informationtechnology Promotion Agency, Japan (IPA) in March 2016 [1].

These Guidelines havebeen formulated to encourage the manufacturers of IoT devices and systems to carry out
certain basic tasks to ensure compliance with security-conscious development practicesuch as security guidelines, as well as existing safety standards.
Four committee members joined from the CCDS to work on the compilation. The “IoT
Safety/Security Development Guidelines” and the formulation of this document have beenachieved through mutual sharing of the status of discussions. The “IoT Safety/Security
Development

Guidelines”

may

be

thoughtofasacollectionofindustry-wide

interdisciplinary guidelines, when compared with this document that covers compatible
guidelines focusing on the specific field of automotive on-board systems. A comparison
between “IoT Safety/Security Development Guidelines” and this document is summarizedin Table 10-1 and Table 10-2 for use in cross-referencing.

52

Table 10-1 A Comparison between “IoT Safety/Security Development Guidelines”
and This Document 1
IoT Safety/Security Development Guidelines
Major item

Guidelines
Guideline 1 Formulating the basic policies
for Safety/Security

Makingcorporate
Policyefforts for the

Guideline 2 Reviewing systems and humanresources for Safety/Security

Safety/Securityof the Smartsociety

Corresponding part of this book
Chapter

4.2.1

4.2.1

4.2.1
Guideline 3 Preparing for internal frauds
and mistakes

4.2.2
4.2.3
8.2
5.2

Guideline 4 Identifying the objects to beprotected

Overview

No.

7.1～7.4
8.5
2.2

Describe the eﬀorts contents ① ~ ③ to the basic policy of the company in Section 1.Lists issues 1 to 3
relating to the efforts to be made by a corporation to approach its basic policies under Item 1.
Lists issues 1 to 5 relating to the corporate framework required under Item 2.
Lists issues 1 to 3 relating to the scheme of human resources development activity required under Item 3.
Lists issue 3 relating to education aimed at preventing internal fraudulence under Item 3.
Lists issues 1 to 4 relating to the actions to be taken to prevent fraudulence by stakeholders under Item 5.
Lists cautions to prevent setup errors and the outflow of documentation in (2) under Item 3 and in (1)under Item 5.
Inserts an alert to prevent setup errors in the implementation of trend analyses of threat classifications.
Defines what needs to be observed on the “Whom threats did harm to” principle in accordance with the
IPA’s scheme of classifying risk characteristics in the implementation of threat analyses.
Implement risk assessments of the threat cases after defining what needs to be observed.
Summarizes the results of trend analyses carried out with regard to the risk characteristics of whom threats
have done harm to.
Presents the system model under discussion in Figure 2.3, defining the points of connectivity with an onboard system.
Lists issues 1 to 5 for presuming the risks of connectivity under Item 1.

4.2.2

Item 3.

Guideline 5 Assuming the risks caused by
Understanding

connections

Analysis the risks of theSingles out (3) key management and (6) informal interface as topics of discussion in an action review under

Defines who connected and where risks occurred as a result of connections on the “Who connected” and5.2

Smart-society“Where risks occurred” principle in accordance with the IPA’s scheme of classifying risk characteristics in theimplementation of threat analyses.

7.1～7.4
8.4、8.6

5.2
Guideline 6 Assuming the risks spreadthrough connections

7.1～7.4
8.2

Guideline 7 Understanding physicalsecurity risks

Implement a risk assessment of threat cases after identifying who connected and where risk occurred.
Present the results trend analyses carried out with regard to the risk characteristics of who connected andwhere risks occurred.
Presents risk classifications as part of the risk characteristics of a threat analysis, including “virus infection,”“abuse” and “DoS attacks,” which are possible risks that may result from connections.
Implement a risk assessment of the threat cases after defining threat classifications.
Summarizes the results of trend analyses carried out with regard to the risk characteristics of threatclassifications.

3.2

Figure 3-1 illustrates the case of a remote attack launched on a car.

4.2.4

Items 1 and 2 describe efforts to be made in the scrapping phase.

8.5、8.6

Present alerts to attacks launched in a remote operation or over a maintenance or informal interface.

53

Table 10-2 A Comparison between “IoT Safety/Security Development Guidelines”
and This Document 2
IoT Safety/Security Development Guidelines
Major item

Guidelines
Guideline 8 Designing to enable both

Corresponding part of this book
Chapter

5.2
7.1～7.4
8.2
8.6
Guideline 9 Designing so as not to cause
Considering the trouble in other connected entities
designs to
Design protect theobjects to beprotected

4.2.2
4.2.2

Guideline 10 Ensuring consistency between
the designs of safety and security

Overview

No.
4.2.2

Covered in (9) and (10) in the action review under Item 3.
Describes risks raised via an external interface, intrinsic risks and risks raised upon physical contact in thecontext of “Where threats occurred.”
Implement a risk assessment of threat cases after identifying where risks occurred.
Describes the need to take countermeasures against the risks of spoofing, in a trend analysis of threatclassifications.
Presents alerts to attacks launched over a maintenance or informal interface, in a trend analysis of where
threats occurred.
Lists issues 1 to 4 relating to responses to unknown threats under Item 7.
Covers issues relevant to the threat analysis under Item 2 and the evidence under Item 4.
Presents case studies conducted using four methods with regard to how to carry out threat analyses andChapters 5 risk assessments, to recommend the implementation of analyses using multiple assessment methods in (1)to 7

under Item 2, 2.2.2 and to aid in the reassessment of threats after the implementation of measures in (3)under Item 2.

Guideline 11 Designing to ensure
Safety/Security even when it is connected

4.2.2

with the unspecified partner.
4.2.2
Guideline 12 Verifying/validating thedesigns of safety and security

Covered in (5) in the action review under Item 3 only to mention the action validation, without going as far
as to mention how to make connections depending on whom to connect with and where.
Lists issues 1 to 3 relating to the assessment and verification process under Item 6.
Assess risks by defining what needs to be protected, how to make connections, where risks occurred and so

Chapters 5 on, in addition to who connected, whom risks did harm to and where risks occurred, in accordance with the
to 7

IPA’s scheme of classifying risk characteristics in the implementation of threat analyses, and suggest theneed to explore measures according to the risk degree.

Considering the Guideline 13 Implementing the functions to
Maintenance

designs to

identify and record own status

ensureGuideline 14 Implementing the functions toprotection even maintain Safety/Security even after theafter market

4.2.2

Describes an issue relating to logs in (4) under Item 7.

4.2.3

Describes issues 1 and 2 as updates under Item 4.

passage of time
Guideline 15 Identifying IoT risks andproviding information after market release

4.2.3
Chapter 9

Describes what is shared as incident information under Item 6.
Suggests the need to update threat cases and carry on threat analyses to respond to new use cases, as
future tasks.

Operatio Protecting with Guideline 16 Informing relevant businessnrelevant parties operators of the procedures to be followed

4.2.3

Presents a definition of usage during operations under Item 2.2.

after market release
Guideline 17 Making the risks caused byconnections known

to general users

4.2.3

Describes issues 1 and 2 relating to what needs to be observed by users as user instructions under Item 1.
Describes issues 1 to 2 to alert users under Item 3.

54

11 Association with the “Automotive Information
Security Efforts Guidelines”
In formulating these Guidelines, the “Automotive Information Security Efforts Guidelines.”
published by the Information-technology Promotion Agency, Japan (IPA) in March 2013,
was consulted [5]. A comparison between the “Automotive Information Security Efforts
Guidelines” and this document is summarized in Table 11-1 for cross-referencing with thecomparison between the “IoT Safety/Security Development Guidelines” and the document
listed in the previous chapter.

Table 11-1 Table of Comparison between the “Automotive Information Security
Efforts Guidelines” and This Document
Action Guide to Information Security of Automobiles
Chapter

Title

Chapter

1.1.
1Introduction

Automotive
2

3

security in theautomotive
systemDetails of the4efforts tosecurity

security

Model of automobile systems

2.2.

Threat on the security assumed

3.1.
3.2.

1.1

Presents the present status and issues of security of
automotive on-board modules.

2.1.

2.4.
Efforts to

Current status and Issues of car

The aim of this book

2.3.

SummaryNo.

1.2.

Systems andSecurity

Title

No.

Corresponding part of this book
Chapter

1 and 1.2

in a car system
Security measures against

2.1 and
1.2

Mapping functions, threats andcountermeasures technology
Life cycle of the automotive－
4,1

systemSecurity efforts level and policyof each phase"Introduction," and its audiences in Section 1.2.
Defines the target model in Section 2.1 and the systemmodel under discussion in Section 2.2.
Describes possible threats to security.

－

threats

Defines the objective of this document in Chapter 1,－

A detailed description of the measures is beyond thescope of this document.
A detailed description of the measures is beyond thescope of this document.
Cites and defines the life style of an automotive system.
A description of phase-specific efforts to be made isbeyond the scope of this document.
Describes efforts to be made in the policy formulation

4.1.

Efforts in the management

4.2.1

4.2.

Efforts in the planning phase

4.2.2

4.3.

Efforts in the development phase

4.2.2

4.4.

Efforts in the operational phase

4.2.3

Describes efforts to be made in the operation phase.

4.5.

Efforts in the disposal phase

4.2.4

Describes efforts to be made in the scrapping phase.

55

phase.
Describes efforts to be made in the planning anddevelopment phase.
Describes efforts to be made in the planning anddevelopment phase.

12 Association with the "IoT Security Guidelines”
The Ministry of Economy, Trade and Industry and the Ministry of Internal Affairs andCommunications formed the “IoT Acceleration Consortium IoT Security Working Group” toexplore approaches necessary to create IoT-base innovative business models and forge asociety in which people can live a safe and secure life. The Group formulated the “IoT
Security Guidelines Ver.1.0,” which was released in July 2016 [13]. Because the “IoT
Security Guidelines Ver.1.0” is an evolution of the "IoT Safety/Security Development
Guidelines[1]” mentioned earlier, correspondences between the “IoT Security Guidelines
Ver.1.0” and this document are summarized in Table 11-1 for cross-referencing with thecorrespondences between the “IoT Safety/Security Development Guidelines[1]” and the
document listed in Chapter 10.

56

References[1]

IPA, "つながる世界の開発指針," 2016.
(IPA, "IoT Safety/Security Development Guidelines," first edition 2016, second edition2017.)
http://www.ipa.go.jp/sec/reports/20160324.html[2]

CCDS, "第 2 回セキュリティガイドライン WG 資料," 2015
(CCDS, "Second Security Guidelines Working Group Document," 2015.)[3]

IPA, "国 内 外 の 自 動 車 の 情 報 セ キ ュ リ テ ィ 動 向 と 意 識 向 上 策 に 関 す る 調 査 報 告 書 ,"2010.
(IPA, "Survey Report on Automotive Information Security Trends in and outside Japanand Measures to Enhance Awareness," 2010.)
https://www.ipa.go.jp/files/000014059.pdf[4]IPA, "2011 年度 自動車の情報セキュリティ動向に関する調査," 2012.
(IPA, "Fiscal Survey on 2011 Automotive Information Security Trends," 2012.)
https://www.ipa.go.jp/files/000014164.pdf[5]IPA, "自動車の情報セキュリティへの取り組みガイド," 2013.
(IPA, "Automotive Information Security Approach Guides," 2013.)
https://www.ipa.go.jp/files/000027273.pdf[6]

IPA, "繋がる組込みシステムの脅威とその対策," 2014.
(IPA, "Threats of Connected Built-in Systems and Countermeasures," 2014.)
http://www.chubu.meti.go.jp/b34jyoho/shiryo/2014072425securitykoshukai/2014072
425ipa.pdf[7]

インターネット ITS 協議会, "2020 年の自動車社会とセキュリティ," 2014.
(Internet ITS Consortium, "Automotive Society and Security in Year 2020," 2014.)
https://www.ipa.go.jp/files/000037537.pdf[8]IPA, "第 2 回つながる世界の開発指針検討 WG 資料 3," 2015.
(IPA, "Second Connected World Development Guidelines Review WG Document 3,"
2015.)
http://www.ipa.go.jp/files/000047927.pdf[9]

ETSI, "Telecommunications and Internet Protocol Harmonization Over Networks(TIPHON) Release 4; Protocol Framework Definition; Methods and Protocols for
Security; Part 1: Threat Analysis. Technical Specification ETSI TS 102 165-1 V4.1.1,"
2003.
http://www.etsi.org/deliver/etsi_ts/102100_102199/10216501/04.01.01_60/ts_10216
57501v040101p.pdf[10] C. Laurendeau and M. Barbeau, "Threats to Security in DSRC/WAVE," ADHOC-NOW
2006, LNCS 4104,
http://people.scs.carleton.ca/~claurend/Pubs/adhocnow2006.pdf[11] ITS 情報通信システム推進会議, "運転支援通信システムに関するセキュリティガイ
ドライン. ITS FORUM RC-009 1.0 版," 2011.
(ITS

Info-communications

Forum,"Security

Guidelines

for

Driving

SupportCommunications Systems. ITS FORUM RC-009 Ver. 1.0," 2011.)
http://www.itsforum.gr.jp/Public/J7Database/p41/ITS_FORUM_RC009V1_0.pdf[12] 公益社団法人自動車技術会, "JASO テクニカルペーパ

自動車－情報セキュリテ ィ

分析ガイド, JASO TP15002," 2015.
(Society of Automotive Engineers of Japan, Inc., "JASO Technical Paper: AutomotiveInformation Security Guide, JASO TP15002," 2015)[13] IoT 推進コンソーシアム, "IoT セキュリティガイドライン ver 1.0," 2016.
(IoT Acceleration Consortium, "IoT Security Guidelines Ver. 1.0," 2016.)
http://www.soumu.go.jp/main_content/000428393.pdf

58