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

CCDS Security Guidelines WG
Automotive On-board Devices SWG

Revision History
VersionDate

Description

Ver.1.0

June 8, 2016

Created a new edition

Ver.1.01

June 15, 2016

Maintained Partial Format■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.

© 2016-2017 Connected Consumer Device Security Council Proprietary

CONTENTS
1

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

Devices .............................................................................................................................. 6
Objectives and Reader of This Document ............................................................... 6
Abbreviations ........................................................................................................... 7

2

A SYSTEM MODEL FOR AUTOMOTIVE ON-BOARD DEVICESGUIDELINES .................................................................................................. 9
Target Model ............................................................................................................ 9
The System Model under Discussion ..................................................................... 11

3

POSSIBLE SECURITY THREATS ............................................................ 14
Carry-in Devices .....................................................................................................14
Attacks Launched from External Networks ............................................................14
Possible Threats and Damage to Automotive On-board Devices ..........................15

4

THE LIFECYCLE PHASES AND SECURITY EFFORTS ........................... 17
Definitions of the Lifecycle Phases ........................................................................17
Security Efforts within the Individual Phases ...........................................................18

5

4.2.1

Policy Phase ........................................................................................................ 19

4.2.2

Planning and Development Phase ....................................................................... 21

4.2.3

Operation Phase .................................................................................................. 24

4.2.4

Disposal Phase .................................................................................................... 25

THREAT ANALYSES ............................................................................... 26
Threat Cases ...........................................................................................................26

1

Risk Characteristics ...............................................................................................27

6

METHODS OF RISK ASSESSMENT ........................................................ 34
Modified ETSI Method .............................................................................................34
CRSS Method (Applied CVSS Method) [6] ..............................................................36
RSMA Method [6] ....................................................................................................38
CCDS Prototype Method .........................................................................................40

7

RESULTS OF RISK ASSESSMENT ......................................................... 43
Modified ETSI Method .............................................................................................43
CRSS Method (Applied CVSS Method) ...................................................................44
RSMA Method ..........................................................................................................46
CCDS Prototype Method .........................................................................................47

8

TREND

ANALYSES OF RISK ASSESSMENT ....................................... 49

Field-specific and Common Threat .........................................................................49
Threat Classification ...............................................................................................50
Connection Interface (Intrusion Route) ..................................................................51
Who : Connected ....................................................................................................52
Whom : Threats Did Harm To ..................................................................................52
Where : Risks Occurred ..........................................................................................53

9
10

CONCLUSION ......................................................................................... 55
ASSOCIATION WITH “IOT SAFETY/SECURITY DEVELOPMENTGUIDELINES” ............................................................................................... 56
2

11

ASSOCIATION WITH “AUTOMOTIVE INFORMATION SECURITY

EFFORTS GUIDELINES” [7] ......................................................................... 59
REFERENCES .............................................................................................. 60
Figure 2-1 Scope of Connectivity .................................................................................... 9
Figure 2-2 Reference Models for Automotive On-board Systems ................................... 10
Figure 2-3 A System Model under Discussion in the Guidelines ..................................... 11
Figure 3-1 Remote Attacks Launched on Cars .............................................................. 14
Figure 4-1 Lifecycle of an Automotive System ............................................................... 17

Table 2-1 Explanations of System Component Elements ............................................... 12
Table 3-1 Possible Threats and Damages ..................................................................... 15
Table 4-1 Definitions of Phases .................................................................................... 18
Table 4-2 List of Security Effort Guidelines Relevant to Individual Phases ..................... 18
Table 4-3 Security Efforts Implemented in the Policy Phase .......................................... 19
Table 4-4 Security Efforts Conducted in the Planning and Development Phase ............. 21
Table 4-5 Security Efforts Conducted in the Operation Phase ....................................... 24
Table 4-6 Security Efforts Conducted in the Disposal Phase ......................................... 25
Table 5-1 Surveyed Literature List ................................................................................ 26
Table 5-2 Risk Characteristics ...................................................................................... 27
Table 5-3 Field-specific and Common Cases ................................................................ 28
Table 5-4 Threat Classifications .................................................................................... 29
Table 5-5 Connection Interface (Intrusion Route) .......................................................... 30
Table 5-6 Who : Connected .......................................................................................... 31
Table 5-7 Whom : Threats Did Harm To ........................................................................ 32
Table 5-8 Where : Risks Occurred ................................................................................ 32
Table 6-1 ETSI Likelihood and Impact Definitions ......................................................... 34
Table 6-2 ETSI Risk Score Calculations ........................................................................ 34
Table 6-3 Motivation and Technical Difficulty Definitions in the Modified ETSI Method ... 35
Table 6-4 Likelihood and Impact Definitions in the Modified ETSI Method ..................... 35
Table 6-5 Risk Score Classifications in the Modified ETSI Method ................................ 36
Table 6-6 Risk Score Definitions in the Modified ETSI Method ...................................... 36
Table 6-7 Base Metrics ................................................................................................. 37
Table 6-8 Risk Score Classifications ............................................................................. 383

Table 6-9 Likelihood Parameters .................................................................................. 38
Table 6-10 Likelihood Level Assessment Table ............................................................. 39
Table 6-11 Risk Level Assessment Table ....................................................................... 39
Table 6-12 Scores of Attack Exploitability and Impact Subscores .................................. 40
Table 6-13 Definitions of Attackers` Motivations ............................................................ 42
Table 6-14 Risk Score Classifications ........................................................................... 42
Table 7-1 Examples of Risk Assessments Produced by the Modified ETSI Method ........ 43
Table 7-2 Examples of Risk Assessments Produced by the CRSS Method .................... 44
Table 7-3 Examples of Risk Assessments Produced by the RSMA Method .................... 46
Table 7-4 Examples of Risk Assessments Produced by the CCDS Prototype Method .... 47
Table 8-1 Field-specific and Common Threat Trend Analyses ........................................ 49
Table 8-2 Threat Classification Trend Analyses ............................................................. 50
Table 8-3 Connection Interface (Intrusion Route) Trend Analyses ................................. 51
Table 8-4 Who : Connected .......................................................................................... 52
Table 8-5 Whom : Threats Did Harm To ........................................................................ 53
Table 8-6 Where : Risks Occurred ................................................................................ 53
Table 10-1 A Comparison between IoT Safety/Security Development Guidelines and This
Document 1 .................................................................................................................. 57
Table 10-2 A Comparison between IoT Safety/Security Development Guidelines and This
Document 2 .................................................................................................................. 58
Table 11-1 Table of Comparison between the “Automotive Information Security Efforts
Guidelines” and This Document .................................................................................... 59

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).
With the popularity of IoT, devices in widespread use are supporting a variety of
networking features, increasing security concerns. That said, it is undeniable that security
standards relevant to IoT products and services 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 (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 IPA-WG 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 andreleased as “IoT Safety/Security Development Guidelines - Important Points to beunderstood 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-specific guidelines is developed for locating individual industry specific safety
and security promotion of design or development process.

5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 by a 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.

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:

１) The designers and developers of on-board devices and systems,２) Development supervisors in charge of the implementation of on-board devices andsystems design projects,
３) 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
on-board devices and systems, and the guidelines provided should be supplemented by
the “IoT Safety/Security Development Guidelines [1]”.

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

Table 2-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

IoT

Internet of Things

IPA

Information-technology Promotion Agency, japan

ISOInternational Organization for Standardization

7

SWG

Sub Working Group

WG

Working Group8

2 A System Model for Automotive On-board Devices
Guidelines
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. 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.

Figure 2-1 Scope of Connectivity 1

1

The Connected Consumer Device Security Council "現状のセキュリティ対応記入説明書”(3)9Source: Securit y Trends and Awareness Enhancem ent Measures Sur ve y Report (IPA)

Source: Securit y Trends and Awareness Enhancem ent Measur es Sur ve y Report (IPA)

Source: Action guide to the inform ation security of the car
Source: 2011 Surve y on Inform ation Securit y Trends of car

Source: 2020 Car Society and Security (Inter net IT S Consortium )Source: T hreats to Connected Built-in S ystem s and Counterm easures (IPA)

Source: IPA’s

Second IoT Safety/Securit y Developm ent Guidelines

Review W G

Source: Trends in “Connected Car” Technology and AssociatedStandardizations and security (JARI)

Figure 2-2 Reference Models for Automotive On-board Systems
10

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 haveproperties that put them under threat from attackers. Hence, devices that are either
installed in the automobile or ones carried on-board that are connected through theinterface to outside vehicle, as well as the on-board head unit, have been listed on thebasis 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, thepower 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
11

Table 2-1 Explanations of System Component Elements
Name

Explanation

Automotive on-board device

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

On-board communication

A wireless unit installed to exchange relevant information

devicewith either a roadside system for toll payment, an ITS
service, telematics communication, or vehicle-to-vehiclecommunication.

OBD-II port

On-Board

Diagnostics,

SecondGeneration.

Onboardsystems diagnostics interface.
Gateway

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

ECU

Electronic Control Unit. A unit that electronically controls anumber of 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 roadsidesystem or enable vehicle-to-vehicle communication.

C2C

Car-to-Car Communication.

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

GPS antenna

The antenna used to receive position information from asatellite.

Carried-in on-board device

A device that carries out data communication with anautomotive on-board device via either a wired, wireless or an
attachment connection.

Wi-Fi

Wireless LAN standard certified by the Wi-Fi Alliance.

12

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

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 datawith the on-board computer via wireless communication.

13

3 Possible Security Threats
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 common for external devices to be connected with cars, taking
countermeasures from the development stage for defending threats of any kind is
extremely important.

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

14

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 automotive

Shutting

on-board

external

communication functions.

Fake message transmission by server

User confusion and more.

networks

via

an

the

all

services

down

with

network.
2

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 by operation

receivers.

management authorities.

Messages delivery containing incorrect

Confusion caused by the delivery oflocationsmessages with the incorrect locations.

by

the

third

a

secondparty

GPSgenerators.
6

Spoofingofautomotive

Confusion caused by the delivery of drive

on-board device through the use of theinformation

original automotive on-board device by

information.

users

or

due

to

the

containing

incorrect

Unauthorized

utilization of receivers by third parties.
7

Tracing

personal

locationsthrough

Personal profiling.

receiving messages by the rthird party
receivers or through the user by the
exploitable usage of devices.
8

Intentional shutdown of the ECU control

ECU disabled from working correctly, thus

functions through 3G/LTE by third party

crippling vehicle functions.

during normal operations.
9

Manipulating the vehicle status throughTampering

Bluetooth devices, smartphone etc., byunintended changes to performance.

dealer personnel during maintenance.

15

with

settings

to

make

10

Malfunctioning of the information ECU`s
information

functions

duringnormaloperations intentionally caused by third
parties via an SD card interface.

16

Disabling of information functions.

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.

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

Figure 4-1 Lifecycle of an Automotive System*See: “Automotive Information Security Efforts Guidelines (2013), IPA [7]”17Table 4-1 Definitions of Phases
Phase
Planning

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

Development

Proceeding

with

the

design,efforts

andmanufacture

as

per

the

requirements 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

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
Planning and 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

No.

Item

Effort Guideline

1

Basic policies

Develop basic corporate policies.

2

Framework

Build a corporate framework for taking action.

3

Education

Periodically educate employees.

1

Model
to
assessed2

Threat analysis

Conduct a threat analysis to identify risks.

3

Measuresreview

Review measures.

PolicyFormulation

Planning andDevelopmentbeEstablish the range of threat analysis.

18

Retain evidence.

4

Evidence

5

Parties
concerned
design6

Validation
verification

7

Responses
tounknown threats

Prepare for the occurrence of unknown future

1

User
documentation

Cover

2

Operation-timeusage definition

Define the scope of operation-time usage in strict

3

User alert

4

Update5Parties
concerned
operations

6

Sharing incident
information

1

Obfuscating
analyses2

Initialization

with

and

Beware of assuming the integrity of designers,
developers or subcontractors.
Validate and verify security.

threats of any kind.
allrelevant

aspects

in

the

user

documentation.

terms.
Ensure that users identify operational faults as theyoccur.

Operation
Allow measures to also be taken in the future.

withBeware of placing complete trust in the parties
concerned.
Share incident information in order to use it tomaximum effect.
The design should allow for the Disposal Phase.

Disposal

Allow settings to be initialized according to theirdefaults.

4.2.1 Policy Phase
The following 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

Description

Basic

Establish

basic

policies

corporate policies.

① Gaining cooperation from management isessential because measures are costly.
(Gettingthemanagement

achieved

via raising

on

board

awarenessisof theimportance of the issues with presentations
and publications by public institutions.)② Update basic policies to keep up with19

developments in the threats environment.
③ Establish guidelines to set upper limits onaction taken. (This is necessary to prevent
action from becoming so costly that the
product cannot be launched.)
2① As

Framework
Maintain across-organizational

approaches

areenvisioned according to the corporation, aframework forsupervisory manager should be appointed tocorporate initiatives.

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 regularcustomer support centers.(When a problem is
detected with the operation of a product in themarket, and it is reported to a regularcustomer

supportcenter,itisusually

misclassified as a product fault rather than asecurity issue. It is therefore recommended
that a dedicated incident response center be
set up to respond to security problems.)④ Decide how incident information received isrouted and reported beforehand.
⑤ It

is

recommended

that

a

qualification

system specifically intended for productsecurity stakeholders be developed in the
future.
3① Ensure periodic retraining of employees toTraining
Periodic
training.

employeemaintain adherence with basic policies.
② It

is

recommended

that

training

ininformation security be conducted in groups
depending on the position of the employees.
(This is because the kind of training required
variesbetweendevelopers,

CSIRT

users,

representatives,
managers

andexecutives.)③ Training

is

also

requiredtomaintain

employee integrity. => See ② under item 5
in

4.2.2.,

aswell

Development Phase”.

20

as“Planningand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.
1

Item

Guideline

Description

Establish the scope① Write up the target system.

beof② Write up possible connection destinations.

assessed

analysis.

Model

to

the

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

2athreat①

ThreatConduct

Try to conduct a threat analysis using at

analysisanalysis to determine

least one method of assessment. However,risks.

the use of multiple methods is preferred, if
possible, in order to compare them. (Asdifferent assessment methods have theirown strengths and weaknesses, threat
analyses that utilize alternative methods
shall be attempted.)② It is desirable to have attackers` motivations
and

case

historyassessment.

(Ifreflected

in

the

risk

any

cases

are

past

presented, exploitability subscores tend to
be

lower

while

attacker`s

motivations

become elevated.)③ Anticipate repeating the threat analyses
after having worked out proposed measuresin order 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

measureshouldbereimplemented to carry out threat analyses.

21

3

Actionreview

Review actions.

① List proposed measures beforehand.
② Start by assuming that something canalways 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
on-board

devices

being

used

as

a

springboard to launch external attacks.)⑤ Verify

theauthenticity

of

the

devicesconnected and application software. (Threat
analysesbytheAutomotive

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 andefforts 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.
⑨ Listproposedactions

that

can

be

implemented within the individual layers(physical, network, application).
⑩ If adequate measures cannot be taken due
to constraints on the cost or specifications,also consider taking measures with thesystem as a whole or with upper-levelcomponents.

22

4

Evidence① Discussions on documents related to the risk

Retain evidence.

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
shouldberetained

of

the

scope

of

self-responsibility. 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 that

① Require submission of written pledges.

concerned

designers,② Stress in a training session that breachingwithdevelopersorsecurity would ruin one`s career. (In addition

designsubcontractors

are

to

trustworthy.

seekingcompliancewithsecrecyobligations, 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

Validate and verify

andsecurity.

①

Strive to complete testing procedures witha minimum set of fuzzing tools.

verification② Even though assessments are conductedin-house,itisdesirablethat

subjected

toaminimum

of

they

be

third-party

checks.
③ Risk assessment or security verification by
third parties is recommended.
7

Responses

Be prepared for the① Write up all factors for consideration.

tooccurrenceof② It is recommended to be constantly prepared

unknown

unknown threats of

to detect incidents of intrusion or suspicious

threats

any kind.

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

23

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

Description① Specify any disclaimers in the user

User
documentation

Includeall

information

relevantintheuser documentation.

documentation.
② Ensure that products, when sold, comewithrelevant information

about theirdesign considerations.
① Clearly

2
Operation-time
usage
definition

Clearly define thescopeofoperation-time usage.

defineoperation-timeassumptions

the

scope

usage
and

and

impart

of
usage

them

to

operators.
① It is recommended that there be some3means of alerting users to the connectionof unknown devices or to the detection of
any signs of suspicious behavior.
Ensure that users are
made
aware
of
operational faults asthey occur.

User alert② It is recommended that products found tocontain configuration errors are not usedwithout those errors first being corrected.
(Ensurethat

security

circumstances

been

has

under

disabled

due

no
to

configuration errors committed by users,
dealers or anyone else.)
4① Establish

UpdatesAllowmeasurestoalso be taken at alater time.

aframework

firmwareupdating.

ideallybeforsecure(Firmware

shoulddownloaded

from

a

dependable server with a secure bootkey.)
② Establishing a framework for remote
updating is also recommended.

5① Ensure that no harm would be caused byParties

Never place complete

concerned

trust in the parties

the

with

concerned.

documentation.

operations

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

6

SharingofShareincident

24① It is essential to set up a system ofincident

information and put it

sharing and utilizing available incident

information

to effective use.

information

in-house

or

among

stakeholders.

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① It is recommended that boards be designed

Obfuscating
analyses

Description

Designs should allow
for

the

so they cannot be easily

Disposal

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

reverseengineering.
2

Initialization

Allow settings to be① Allow settings to be reset to their defaults.

initialized according totheir defaults.

25

5 Threat Analyses
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, about 230 cases of known incidents had beenclassified by risk characteristics, such as “Target Equipment”. “Field-specific andCommon”. “Threat Classification” and “Connection Interface (Intrusion Route) ”, to assess
risk scores on the basis of predefined assessment items of exploitability, damage andimpact subscores. 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
Fiscal2010

Automotive

URL

Information

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

Security Trend Survey Report, IPA
2

Fiscal2011

Automotive

Information

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

Appendix to the Fiscal 2011 Automotive

http: //www.ipa.go.jp/files/000014165.pdf

Security Trend Survey, IPA
3Information Security Trend Survey, IPA
4

Fiscal2012

Automotive

Information

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

Security Trend Survey, IPA
5

6

Security requirements for automotive

http:on-board networks based on dark-side//evita-project.org/Deliverables/EVITAD2.3.

scenarios, EVITA

pdf

Automotive
Analysis

Information

Security

Guide_JASO

TP15002,

Society of Automotive Engineers of

http://www.bookpark.ne.jp/cm/jsae/particulars.a
sp?content_id= JSAE-tp-15002-PDF

Japan
7

Driving Support Communication System

http:Security Guidelines, ITS Forum//www.itsforum.gr.jp/Public/J7Database/p41/ITS_FORUM_RC009V1_0.pdf

8Survey Report Concerning Automotive
Security Trends at Home and Abroadand Measures to Enhance Security
Awareness, IPA

26

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

9Automotive

andIntelligent

Home

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

Appliance Built-in Systems Security
Survey, IPA
10

Future11

andIssuesofAutomotive

http:Networking - Connected Car Security,//home.jeita.or.jp/page_file/2014100911011

IPA

9_FYXUHuv50O.pdf

Automotive Information Security Efforts

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

Guidelines, IPA
12

Present Status of Automotive On-board

http:Network Security, FFRI//www.ffri.jp/properties/files/monthly_resear
ch/MR201310_Current%20state%20of%20a
utomotive%20network%20security_JPN.pdf

13

Proposals

Concerning

Information

Security

Tougher
inhttps: //www.ipa.go.jp/files/000034668.pdf

Built-in

Automotive On-board Systems, IPA

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”,“field-specific and common”, “threat classification” and connection Interface (intrusionroute)” 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
for classifying 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.

27

=> “Configuration error/Virus infection”.
② Threats launched by attackers with the express intention of
attacking.
=> “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

Explanation

Field-specificCases in which any equipment or intrusion routes 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.

28

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.

Threat Classifications
Table 5-4 lists the cases of classifications of threats caused by user action and threatscaused by attackers` intervention.

Table 5-4 Threat Classifications
ThreatQ

Configuration

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

error

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 orstorage 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 settings ofan 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 tointrusion 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 and29

information 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.
DoS attack

A threat that causes a system to close down or impede a service as a resultof 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 or

messagingproduce 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 canunlock the car from a remote location.

*See: “Automotive Information Security Efforts Guidelines (2013), IPA [7]”Connection Interface (Intrusion routes)
Table 5-1 shows the possible routes of threat intrusion.

Table 5-5 Connection Interface (Intrusion Route)
Connection

Transmission

Interface

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

DSRC

0 to 30m

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

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

receptionsatellites.

OBD

0m

RF

0 to 10m

SD

0m

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 connecting

USB

0m

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

31

User (intentional)

An intentional connection made by the user.

User (wrong connection) An incorrect connection made by the user.
Attacker

A connection made by exploiting vulnerabilities.

Accidental

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

*See: “IoT Safety/Security Development Guidelines [1]”.

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
ThreatExplanation

IoT functions

IoT applications, communication functions, security functions,(communication, linkage,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, theirbodies components, etc.

*See: “IoT Safety/Security Development Guidelines [1]”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

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

32

MaintenanceA

management

operation

panel,

remotemanagement

Interfacecommunications Interface, software update USB terminal or the like.

Informal Interface

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

Internallycontainedrisk

Examples include a defect or bug that could be a source of a failure,a vulnerability that could be exploited, a function that could do harmwhen it fails or is Unauthorized utilizationd etc.

Physical contact

Direct contact with the body.

*See: “IoT Safety/Security Development Guidelines [1]”.

33

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.

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 [3]. Table 6-1 lists ETSI definitions oflikelihood and impact, while Table 6-2 lists definitions of risk score classifications.

Table 6-1 ETSI Likelihood and Impact Definitions
Item

Likelihood

Score

Rank

3

Likely2

Possible

Definition
Not 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

(prod
uct)
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.

34

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
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[4], [5].
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 Method
Item

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 and35

impact. Table 6-5 shows definitions of risk score classifications.

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

Score

Rank

Definition

(prod
uct)

Risk score

9,6

CriticalAction mandatory.

4

Major

Caution required.

3,2,1

Minor

Immediate action not required.

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
Technical
Motivation

ImpactLikelihood

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

None
High
Solvable

Likely (3)Critical (9,6)

NoneModerate
Solvable
Low

Any

Any

StrongPossible (2)Major (4)

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

CRSS Method (Applied CVSS Method) [6]
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,36

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,and 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

Category

Score

Local

0.395

Adjacent

0.646

Network

1.0

High

0.35

Medium

0.61

Low

0.71

seek

Multiple

0.45

authentication from the target system toSingle0.56

exploit its vulnerabilities.

No need

0.704

any

None

0.0

C:

confidential information stored in the

Minor

0.275

Confidentiality Impact

targetSevere0.660

AV: Access Vector

OutlineAssesseswhereavulnerable

system can be attacked.

Assesses
AC: Access Complexity

from

the

complexity

of

the

conditions prerequisite to attacking avulnerable system.
Assesses

Au: Authentication

Assessesthethesystemneedpossibility
leaking

to

of
when

its

of

any

None

0.0

information stored in the target system

Minor

0.275

Severe0.660

vulnerabilities are exploited.
Assesses
I: Integrity Impact

thepossibility

being falsified when its vulnerabilities
are exploited.

37

Assesses
A: Availability Impact

any

None

0.0

functionalities of the target system being

Minor

0.275

Severe0.660

delayedtheorpossibility

shut

down

of
when

its

vulnerabilities are exploited.

Table 6-8 Risk Score Classifications
Threat level

Risk score(base score)

Level (serious)

7.0 to 10.0

Level II

4.0 to 6.9(warning)
Level III

0.0 to 3.9(caution)

RSMA Method [6]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
evaluation table is given in Table 6-11.

Table 6-9 Likelihood Parameters
Parameter

Duration

Explanation

Criteria

Time needed to identify

Realistic.

0

and

Non-realistic.

19

Amateurs.

0

Professionals.

3

Publicized information.

0

then

exploitvulnerabilities.
Specialized

Technical

specialized

knowledgeknowledge required.

TOE

Knowledgeknowledge

attacked objects (TOE).

limitedtoInformation

availabletodevelopers and manufacturers.

38

dealers,3

Information available only to limited sets of7

users.
Access not required.
Time and frequency ofOpportunity

accessto0
Access required/unlimited access.

attacked

objects (TOE).

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).
Customdevices(suchasproducts

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

Likelihood
Description
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

SafetyPersonal

individual identification alone.

information/privacy
High

Information that helps identify
individuals.

None

No impact on properties/corporate
values.

Property/corporate
value

Low

Limited to impact in-house only (lowbusiness impact).

Medium

Impacting customers (medium

39business impact).
High

Impacting both customers and

M

H

H

business (high business impact).

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 isallowed 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
MultipleValue

conditions(authentication, special privilegesSand so forth) are required, and1

only local connections (attacks)
Are there any

are possible.

conditions necessary
A single condition (authentication,

Exploitability to launch attacks
subscore(such asspecial privilege or the like) isArequired, and only connections

authentication or3(attacks) are possible.

special privileges)?

One

or

more

conditions(authentication, special privilege

B

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

5

possible.
No
C

need

for

conditions

forlaunchingattacks,

andconnectable(attacks

possible)10

from a wireless network.
Attacks launched will leave no
impact on users or only produce a
Minor

minor display error. Furthermore,1

there is no leak of information thatwill help identify individuals.
Attacks launched will put users at
MediumWhat are the impact
Impactdisadvantage

or

allow

an

individual to be identified from3

leaked information.

sub subscores and ranges

score

a

of attacks andAttacks launched will not only put

secondary damage?

users at a disadvantage, but also
Seriousproducesecondary damage

or5

allow multiple individuals to be
identified from leaked information.

Destructive

Attacks

launched

will

damagewitheitherconsequenceor

producefatal

secondary10

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 threelevels, low, medium, and high, on the basis of the CCDS method. The medium level was
set to give 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.

41

Table 6-13 Definitions of Attackers` Motivations
Item

Rank

Definition

Value

Low

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 12^

12 or more but less than 17

Essential

17 or more

42

1.5

7 Results of Risk Assessment
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
damagesTargetdevices

Modified ETSI method
Con
Who
Field-s
Wher
Who
m
:
necti
pecifice:
TechThreat: Threatoron Conne s Did Risks Motiv nical Likeli Impa Risk
classification
OccurrcommoInterf cted Harm ed ation diffic hood ct score
ulty
To
n

ace

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

4

5

6

7

DoS
AttackOrdin
IoT ary-u
3G/ Attac
Mode Solva
functi se
GSM kerrate bleons Interf
ace

User
Ordin
Automotive(wron IoT ary-u
Commo
Fake
3G/
Mode Solva
on-boardgfuncti senmessaging ﾞ GSM
rate bleconne ons Interf
devices
ction)
ace
Ordin
Freezing of systems
Shutdown ofAutomotive
User IoT ary-u
due to streaming
Commo
Fake
3G/
Mode Solva
infotainment
on-board(intent functi secontent exploitingnmessaging ﾞ GSM
rate ble
services
devices
ional) ons Interf
browser bugs
aceEavesdropping of Use of services
Ordincommunication
not intended by Automotive
ary-uCommo Eavesdroppin
Attac Infor
Solva
messages by taking the operation
on-board
Wi-Fi
se Highng
ker matioble
advantage of third management
devicesInterfnparties` receivers authorities
ace
Delivery ofConfusion
messagescaused by theOrdincontaining incorrect
Inher
delivery ofAutomotive
ary-u
locations through
Commo
IllegalAttac ent
Mode Solva
messagesGPSseon-board
the Unauthorizednrelaying
ker functi
rate ble
containing
Interfdevicesutilization of GPS
ons
incorrect
ace
generators by third
locationsparties
Spoofing of asecond automotive
on-board device
Confusion
through the use of
caused by theOrdin
the original
delivery of drive Automotive
User
ary-u
Infor
automotive
Commo Unauthorized 3G/
Mode Solva
information
on-board(intentseon-board device bynutilization GSM
matio
rate ble
containing
devices
ional)
Interfusers or thenincorrect
ace
Unauthorized
information
utilization ofreceivers by third
parties
Tracing to personal
locations from
Ordin
received messages
Automotive
ary-u
through the use of Personal
Field-s Information
Attac Infor
Solva
on-board
Wi-Fi
se Highreceivers by third profiling
pecificble
Leakageker matio
devicesInterfparties or thenace
Unauthorized
utilization of an

Transmission of
2 fake messages byserver spoofing

3

Shutdown of allservices that
AutomotiveCommo
on-board
requirencommunication
devicesfunctionsUser confusion
and more

43

2

3

6

2

2

4

2

2

4

3

1

3

2

2

4

2

2

4

3

1

3

automotive
on-board device byusers
Intentional
shutdown of the
ECU disabledOrdin
control ECU`sfrom working
Inher
ary-u
control functions
correctly,
Field-s Unauthorized 3G/ Attac ent
Mode Solva
ECU
se
8 from 3G/LTE lines crippling thepecific
utilization GSM ker functi
rate bleInterfby third parties
vehicleons
aceduring normal
functionsoperations
Dealers’ personnel
Tampering withfalsify vehicle
Ordin
settings toServi
status information
Automotive
Infor ary-u
make
Field-sBluet ce
Mode Solva
on-board
Illegal setting
matio se9 from Bluetooth
unintended
pecificrate bleooth provi
devices, such as adevicesn Interfchanges todersmartphone, duringace
performance
maintenance.
Malfunctioning of
the information in
the ECU`s
information
Information
Ordin
Inher
functionsfunctionsary-u
Field-s Unauthorized
Attac entMode
prevented from
ECU
se
SD
None
10 intentionallypecific
utilization
ker functi
rate
induced by third
working
Interfons
parties from an SD correctlyacecard interface
during normal
operations

2

3

6

2

2

4

3

1

3

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

CRSS Method (Applied CVSS Method)
The CRSS method changes the impact subscore parameter categories from “partial” to“total” and from “total” to “severe”. which better reflects risk assessment solutions forautomotive 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 producedby other method. Consequently, there are fewer serious risk score levels (red).
Furthermore, when assessed 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

No

Possible threats

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

FieldCRSS (CVSS-based)
Who
Threa Conn
Wher AV
speci
AC
Au
C
I
A
m
:
Explo
t
ectio Who :e : Acces Acces
Confid Integri Availa Impa
Possible
Targetfic
Threatitabiliclassi n Conne s Did Risks
s
s
Authe
entialit tybilityct
Risk
devicesandtydamages
ficati Interf cted Harm Occurr Vector Compl nticati subsc y Impact Impact subsc score
comm
ed
ore
exity
on
Impact
To
on
ace
ore
on
Shutdown of
Ordin
DoS
all
services Automotive
IoT ary-u
Com
3G/ Attac
Netw
Singl
functi sethat require on-board
Low
7.95 None Minor Minor 4.94 5.46
mon Attac GSM ker
orke
ons Interf
communicati
deviceskace
on functions

44

network

Transmission of
2 fake messages byserver spoofing

User
confusionand moreFreezing of systems
Shutdown of
due to streaming
3 content exploiting infotainment
servicesbrowser bugs

User
Ordin
Fake
Automotive(wron IoT ary-u
Com mess 3G/
Netw
Singl
on-boardgfuncti se
Low
7.95 None Minor Minor 4.94 5.46
mon agin GSM
orkedevicesconne ons Interfgﾞ
ction)
ace
Ordin
Fake
Automotive
User IoT ary-u
Com mess 3G/
Netw
Singl
on-board(intent functi se
Low
7.95 None Minor Minor 4.94 5.46
mon agin GSM
orkedevices
ional) ons InterfgﾞaceUse ofEavesdropping of
Ordin
services notcommunication
Automotive
Eave
ary-u
intended by
Com
Attac Infor
Adjac Medi Multi
3.55 Minor None None 2.86
4 messages by taking the operation on-board mon sdrop Wi-Fi ker matio se
ent
um
ple
advantage of third
devicespingInterfmanagementnparties` receivers
aceauthorities
Delivery ofConfusion
messagescaused by
Ordin
containing incorrect
IllegaInher
the delivery Automotive
ary-u
locations throughComl
Attac ent
Netw
of messages
on-boardGPSse
Low None 10.00 None Minor Minor 4.94
5 the Unauthorized
mon relayi
ker functi
ork
containing
devicesInterfutilization of GPS
ng
ons
incorrect
ace
generators by third
locationsparties
Spoofing of asecond automotive
on-board device
Confusion
through the use of caused by
Unau
Ordin
the original
the delivery
Automotive
User
thorizary-u
automotive
Com
3G/
Netw
Singl
of driveInfor
on-board(intent
Low
7.95 None Minor Minor 4.94
edse
6 on-board device by information
mon
GSM
matio
ork
e
devices
ional)
utilizInterfusers or thecontaining
n
ation
ace
Unauthorizedincorrect
utilization of
information
receivers by third
parties
Tracing to personal
locations fromreceived messages,
through the use of
Infor
Ordin
receivers by third
Automotive Field- matio
ary-uPersonal
Attac Infor
Adjac Medi Multiseon-board speci n Wi-Fi
3.55 Minor Minor None 4.84
7 parties or the
profilingker matio
ent
um
ple
Unauthorized
fic LeakInterfdevicesnutilization of anage
ace
automotive
on-board device byusers
Intentional
shutdown of the
ECU disabled
Unau
Ordin
control ECU`sfrom working
Inher
Field- thoriz
ary-u
control functions
3G/ Attac ent
Netw Medi Singl
Sever Sever
correctly,seECU
speci ed6.83 None
9.21
8 from 3G/LTE lines crippling the
GSM ker functi
ork
um
e
e
e
fic utiliz
Interfby third parties
vehicle
ons
ation
ace
during normal
functionsoperations
Dealers’ personnel
Tamperingfalsify vehicle
Ordinwith settings
IllegaServi
status information
Automotive Fieldary-u
to makelBluet ce Infor
Adjac
Singl
on-board speci
se
Low
5.14 Minor Minor None 4.94
9 from Bluetooth
unintended
settin ooth provi matioentedevices, such as adevicesfic
Interfchanges togdernsmartphone, duringace
performance
maintenance.
Malfunctioning of
the information in
the ECU`s
information
Information
Unau
Ordin
Inher
functionsfunctionsField- thoriz
ary-u
Attac ent
prevented
ECU
speci edSD
se Local Low None 3.95 None Minor None 2.86
10 intentionallyker functi
induced by thirdfrom working
fic utiliz
Interfons
parties from an SD correctly
ation
ace
card interface
during normal
operations

Level

1.92

6.42

5.46

3.39

7.95

4.14

2.11

(Serious)

Level II (Warning)
Level

45

(Caution)

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.

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

No

Possible threats

RSMA Method
Who
Targe Field- Threa Conn
Wher
Who
m
:
ectio
Dama
t
specif
t
Impac
Speci
: Threat e :TOEPossible damages devic ic and classi n Conne s Did Risks get
Durati alized
Oppor Devic Likelih Risk
classiknowl
Occurr
subsc
on
knowl
tunity es
ood scorees comm ficatio Interf cted Harmficatio
edge
ed
ore
edge
To
on
n
n

ace

1

2

3

4

5

6

Auto
Accessmotiv
DoS
attacks
Ordin ProperCom
ShutdownofallLimite notlaunched
on
an
e
DoS
IoT ary-u ty and
Profe
merci
services that requireCom
3G/ Attac
Mediu Realid sets require
automotive on-board
on-bofuncti se corpor
ssion
al
High
communication
GSM ker
m
stic
of
d and
mon
ard
ons Interf ate
networkvia
anattackals
produfunctionsusers unlimit
external network
devic
cts
ace valueedeAuto
Accessmotiv
Ordin Proper
Fake
User
Limite not Custo
Transmission of fakee
IoT ary-u ty andProfe
User confusion and
Com mess 3G/ (wrong
Mediu Realid sets require m Mediu
messages by server
ssion
on-bo
functi se corpormore
mon aging GSM connec
m
stic
of
d and produ
m
spoofingard
ons Interf atealsﾞ
users unlimit cts
tion)
devic
ace valueedeAuto
AccessOrdin Proper
motiv
Freezing of systems
Fake
Limite not Custo
Shutdownof eUser IoT ary-u ty andProfedue to streaming
Com mess 3G/
Mediu Realid sets require m Mediu
infotainment
on-bo(intenti functi se corporssion
content
exploiting
mon aging GSM
m
stic
of
d and produ
mals
services
ardonal) ons Interf ate
browser bugs
ﾞusers unlimit cts
devic
ace value
ed
e
Deale
Auto
Personrs,
Eavesdroppingof Use of services not motiv
Ordin aldevel Limite Custo
communication
intended
by
the e
Eaves
ary-u inform
Profe
Com
Attac Infor
Reali
opers
d
m Mediu
messages by taking operation
on-bo
ation Low
ssion
dropp Wi-Fisemonker matio
stic,access produmadvantage of third management
ardingInterf andalsnmanuf count cts
devic
parties` receivers
authorities
ace privac
actur
e
y
ers
DeliveryofAutomessages containing
motiv
Ordin Proper
PublicCom
incorrect
locations Confusion caused by
Inher
LimiteIllegalary-u ty andProfe ized
merciethroughthe thedeliveryofCom
Attac ent
Mediu Realidon-borelayi GPS
se corpor
ssion inforalHigh
Unauthorized
messages containing
monker functimsticaccessard
ngInterf ate
als matio
produ
utilization of GPS incorrect locations
ons
count
ace value
n
cts
devic
generators by thirdeparties
Spoofing of a second
automotive on-board
Autodevice through theConfusion caused by motiv
Unaut
Ordin Properuse of the original
Limite Limite Custo
the delivery of drive ehorizeUser
ary-u ty and
Profe
Infor
automotive on-board
Com
3G/
Mediu Realid sets d
m Mediu
information
on-bod(intenti
se corpor
ssion
device by users or
mon
GSM
matio
m
stic
of access produ mcontaining incorrect ard
utilizaonal)
Interf atealsthe
Unauthorizednusers count cts
information
devic
tion
ace valueutilizationofereceivers by third
parties

46

H

M

M

L

H

M

Tracing to personal
locationsfromreceived messages,
through the use ofreceivers by third
Personal profiling
7 parties
ortheUnauthorized
utilizationofanautomotive on-board
device by users

Auto
Personmotiv
Infor
Ordin alLimite Limite Custoe Field- matio
ary-u inform
Profe
Attac InforRealid sets d
m Mediu
on-bo specif n
Wi-Fi
seation Lowssion
ker matio
sticof access produ m
ardInterf andals
ic leakan
users count cts
devic
ge
ace privac
e
y

Deale
Intentional shutdown
rs, Access
Unaut
Ordin
of the control ECU`s ECU prevented fromInher
devel not Speci
Field- horize
Profe
ary-u
controlfunctions working
correctly,
3G/ Attac ent
Safet
Reali
opers require al
High
ssion
High
se
8 from 3G/LTE lines by crippling the vehicle ECU specif d
GSM ker functiystic,d and devic
ic utiliza
Interfals
third parties during functions
ons
manuf unlimit es
tion
ace
normal operations
actur eders
Deale
Dealers’
personnel
Auto
rs,
motiv
falsify vehicle status
Ordin Proper
LimiteTampering
with
Servi
devel
Speci
informationfrome Field- IllegalProfedary-u ty andInforsettings
tomakeBluet ce
Reali
opers
al
devices,
on-bo specif settin
ssion
acces
High
se corpor Low
9 Bluetooth
unintended changes
stic
,
devic
ooth provid matio
ard
ic
g
such
as
a
Interf ate
alss
to performance
er
n
manuf
es
smartphone, during
devic
count
ace value
actur
maintenance.
eers
Malfunctioning of theDeale
information in the
rs,
ECU`s
information
Unaut
Ordin Proper
Inher
devel
Speci
ary-u ty andfunctions
Information functions
Field- horize
Profe
Inacc
Attac ent
Reali
opers
al
intentionallyinducedprevented
from
ECU
d
SD
se
corporLow
ssion
essiblLow
specif
10
ker functi
stic
,
devic
by third parties from working correctlyInterf atealse
ic utiliza
ons
manuf
es
an SD card interface
tion
ace value
actur
duringnormalers
operations

L

H

M

L

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

No

Possible threats

CCDS Prototype Method
Conn
Whom
FieldTarget
Threat
:
Where
ectio
specifiWho :Exploi
AttackedeviceClassiThreats : Risks
ImpactRisk
c andn Connec Did Occurre tability subsc rs`
sficatioted
subsc
motivat score
comm
Harm
d
ore
Interf
n
ore
ion
To
on

Possible damages

ace

Autom
otive
Ordinar
DoS attacks launched on an
DoS
IoT
3G/ Attack
Shutdown of all services thaton-bo Commy-use
functio
1 automotive on-board network via require communication functions
ard
on
er
InterfaGSM
an external network
attackns
deviceces

47CSeriou Mediu Essent
smial

Automotive
User
OrdinarFake
IoT
on-bo Commy-use
Transmission of fake messages by
3G/ (wrong
2
User confusion and moremessafunctioserver spoofingard
GSM connec
Interfaonging ﾞ
ns
device
tion)
ce
s
Autom
otive
OrdinarFreezing of systems due to
Fake
User
IoT
Shutdown of infotainment
on-bo Comm
3G/
y-use
messa
(intenti functio
3 streaming content exploiting
services
ard
on
GSM
Interfabrowser bugs
ging ﾞ
ns
onal)
deviceces
Autom
Ordinarotive
Eavesdropping of communication Use of services not intended by
Eaves
Attacky-use
on-bo Comm
Wi-Fi
messagesbytakingadvantageoftheoperation
management
droppiInform4
onerInterfaard
third parties` receivers
authorities
ng
ation
ce
devices
Autom
Delivery of messages containing
otive
Inhere Ordinar
Confusion caused by the delivery
Illegalincorrect locations through the
on-bo Commy-use
Attack nt
ofmessages
containing
incorrect
relayinGPS
5 Unauthorized utilization of GPS
ardon
er functio Interfa
locationsggenerators by third parties
devicenscesSpoofing of a second automotive
Autom
Unaut
on-board device through the use
otive
OrdinarConfusion caused by the delivery
horizeUserof the original automotive
3G/
on-bo Commy-usedInformof
driveinformation
containing(intenti
6 on-board device by users or the
on
GSM
ard
Interfautilizat
incorrect informationonal) ation
Unauthorized utilization ofdevicece
ion
receivers by third partiess
Autom
Tracing to personal locations fromreceived messages, through theotiveInformOrdinarFielduse of receivers by third parties or
on-bo
ation
y-use
Attackspecifi
Wi-Fi
Inform7 the Unauthorized utilization of an Personal profiling
ard
Leaka
Interfaercation
automotive on-board device bydevice
ge
ce
users
s
Unaut
Intentional shutdown of the control
Inhere Ordinar
ECU prevented from working
Field- horize
ECU`s control functions from
3G/ Attack nt
y-use
correctly, crippling the vehicle
ECU specifi
d8 3G/LTE lines by third parties
GSM
er functio Interfa
functionscutilizat
during normal operations.
ns
ce
ion
Autom
Dealers’ personnel falsify vehicle
otiveServicOrdinarTampering with settings to makeFieldIllegal Blueto
status information from Bluetooth
on-bo
e
y-use
specifi
Inform
9 devices, such as a smartphone, unintended changes toardsetting oth provid
Interfac
ation
performance
during maintenance.
deviceerces
Malfunctioning of the information
Unaut
Inhere Ordinar
Field- horizein the ECU`s information functions
Information functions prevented
Attack nt
y-use
ECU specifidSD
10 intentionally induced by thirdfrom working correctly
er functio Interfacparties from an SD card interface
utilizatnsceduring normal operations.
ion

C

Mediu Mediu
m
m

High

C

Mediu Mediu
m
m

High

B

Minor

Mediu
m

Low

B

Mediu Mediu
Middlemm

B

Mediu Mediu
Middle
m
m

B

Minor

Mediu
m

Low

B

Destructive

大Essential

CMediu Mediumm

B

Mediu Mediu
Middlemm

Essential

High
Middle
Low

48

High

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 the six risk characteristics by category item were counted, and the ratio of
the number of “Essential” and “High” occurrences by category was calculated as an M&H
ratio, along with the risk score average. Risk trends by category item were then analyzed
on the basis of these values.

Field-specific and Common Threat
Table 8-1 summarizes the field-specific and common threat trend analyses conducted. No
significant difference in the M&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.

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

Category

Field-specificEssenti
al

80

Total
High

MiddleLow

occurr
ences

44

38

49

12

174

Risk

Essent

score

M&H

ial

averag

ratio

ratio

71.3%

46.0%

e
17.0

Common

14

26

13

4

57

14.5

70.2%

24.6%

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 ahigh M&H ratio. As outlined in Table 5-4, Unauthorized utilization is defined as
unauthorized individuals taking advantage of the functions of an automotive system byspoofing or exploiting device vulnerabilities. Fake messaging is a threat posed by anattacker 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 need to take countermeasures against spoofing in the operation phase of an
automotive system should 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

Essenti
al

Total
High

MiddleLow

occurr
ences

Risk
score

M&H

averagratio

eConfiguration errors

2

0

2

0

4

14.8

50.0%

Virus infection

14

7

8

0

29

17.3

72.4%

Unauthorized utilization

33

18

10

2

63

18.1

81.0%

Illegal setting

3

8

2

2

15

14.4

73.3%

Information leakage

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%

Fake messaging

17

16

3

0

36

19.7

91.7%

Log loss

0

0

0

1

1

7.5

0.0%

50

Illegal relaying

1

5

5

0

11

12.5

54.5%

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
M&H ratio than other routes. 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 riskscoring.
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 M&H ratios than otherintrusion routes. 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

EssentialHigh

Middle

Low

Total

Risk

occurr

score

ences

average

M&H
ratio

3G/GSM

17

15

12

3

47

16.4

68.1%

Bluetooth

7

3

2

0

12

18.4

83.3%

CD

1

2

0

0

3

20.8

DSRC

0

3

0

0

3

15.4

E-call service interface

1

2

0

0

3

16.3

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%

51

100.0
%
100.0
%
100.0
%

USB

2

3

4

0

9

14.3

VICS

0

3

0

0

3

15.4

Wi-Fi

12

11

12

2

37

15.5

Sensor

2

0

0

0

2

18.8

Special equipment

6

5

4

5

20

12.9

55.6%
100.0
%
62.2%
100.0
%
55.0%

Who : Connected
Table 8-4 summarizes who-connected trend analyses. Service providers had asomewhat higher M&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 notenvisioned by manufacturers at the time of design, hence no risks were expected.

Table 8-4 Who : Connected

Category

Manufacturers and related

Essenti
al

Total
High

MiddleLow

occurr
ences

Risk
score

M&H

averag

ratio

e

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%

User (wrong connection)

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

-

-

firms

Whom : Threats Did Harm To
Table 8-5 shows whom-did-threats-harm trend analyses. The IoT functions delivered an
M&H ratio somewhat higher than others, but these attacks are mostly those launched from52

wireless 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 Unauthorized 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-5 Whom : Threats Did Harm To

Category

Essenti
al

Risk

Total
High

MiddleLow

occurr
ences

score

M&H

averagratio

e

IoT functions(communication, linkage,

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%

concentration and more)
Inherent functions (e.g.,server, GW, thing)

Where : Risks Occurred
Table 8-6 summarizes Where-risks-occurred trend analyses. There is not a significant
difference between ordinary-use Interface and maintenance Interface in their M&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, professionals could navigate through such Interface to launch attacks.

Table 8-6 Where : Risks Occurred
Category

Essen
tial

High

Middle

53

Low

Risk

M&H

occurr score

ratio

Total

Essen

ences averag

tial

e

ratio

Ordinary-use Interface

58

55

36

7

156

16.7

72.4%

37.2%

Maintenance Interface

29

8

11

4

52

16.6

71.2%

55.8%

Informal Interface

5

7

3

4

19

13.0

63.2%

26.3%

Internally contained risk

0

0

0

0

0

-

-

-

Physical contact

1

0

1

1

3

13.8

33.3%

33.3%

54

9 Conclusion
While this document is designed to present security guidelines related to automotive
on-board devices, the discussions of possible threats, security procedures to beperformedin 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
security-conscious design and development activity in response to these and otherevolving 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
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 anautomotive 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.

55

10 Association With “IoT Safety/Security
Development Guidelines”“IoT

Safety/Security

Development

Guidelines”

wasreleased

Information-technology Promotion Agency, japan (IPA) in March 2016.

by

the

These Guidelines

have been formulated to encourage the manufacturers of IoT devices and systems to carryout 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
formulation of this document and the IoT Safety/Security Development Guidelines havebeen achieved through mutual sharing of the status of discussions. The IoT
Safety/Security Development Guidelines may be thought of as a collection of industry-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 summarized inTable 10-1 and Table 10-2 for use in cross-referencing.

56

Table 10-1 A Comparison between IoT Safety/Security Development Guidelines andThis 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

Understanding

connections

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

Guideline 5 Assuming the risks caused by

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.

57

Table 10-2 A Comparison between IoT Safety/Security Development Guidelines andThis 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

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.

4.2.2

Lists issues 1 to 4 relating to responses to unknown threats under Item 7.

4.2.2

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.

58

11 Association With “Automotive Information Security
Efforts Guidelines” [7]In

formulating

these

Guidelines,

the“Automotive

Information

Security

Efforts

Guidelines”. published by the Information-technology Promotion Agency, japan (IPA) in
March 2013, was consulted. A comparison between the “Automotive Information Security
Efforts Guidelines” and this document is summarized in Table 11-1 for cross-referencing
with the comparison 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.

59

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

References[1] H. Takada, A. Goto and et al., “IoT Safety/Security Development Guidelines,”

Information-technology Promotion Agency, Japan (IPA), First Edition, 2016,
http://www.ipa.go.jp/files/000053920.pdf.
[2] 高田 広章, 後藤 厚宏ら, “つながる世界の開発指針,” 独立行政法人情報処理推進機構(IPA) 技術本部 ソフトウェア高信頼化センター(SEC), 第 1 版, 2016,
http://www.ipa.go.jp/files/000054906.pdf.
[3] ETSI, “Telecommunications and Internet Protocol Harmonization Over Networks(TIPHON) Release 4; Protocol Framework Definition; Methods and Protocols for
Security; Part 1: Threat Analysis,” Europian Telecommunications Standards Institute,
ETSI TS 102 165-1 v4.1.1 (2003-02), Technical pecification, 2003,
http://www.etsi.org/deliver/etsi_ts/102100_102199/10216501/04.01.01_60/ts_1021650
1v040101p.pdf.
[4] C. Laurendeau and M. Barbeau, “Threats to Security in DSRC/WAVE,” ADHOC-NOW

2006 Proceedings, Lecture Notes in Computer Science Vol. 4104, pp. 266―279, 2006,
http://people.scs.carleton.ca/~claurend/Pubs/adhocnow2006.pdf.
[5] 萓島 信ら, “運転支援通信システムに関するセキュリティガイドライン,” ITS 情報通信

システム推進会議, ITS FORUM RC-009 1.0 版, 2011,
http://www.itsforum.gr.jp/Public/J7Database/p41/ITS_FORUM_RC009V1_0.pdf.
[6] JASO, “自動車－情報セキュリティ分析ガイド,” 公益社団法人自動車技術会 規格会議

審議, JASO TP15002, 2015.
[7] IPA, “自動車の情報セキュリティへの取組みガイド,” 独立行政法人情報処理推進機構(IPA), 第 1 版, 2013, https://www.ipa.go.jp/files/000027273.pdf.

60