SAFETY THREAT ANALYSIS FRAMEWORK

copyright@2020 CAV Technologies Co., Ltd. all rights reserved.
THREAT ANALYSIS FRAMEWORK FOR SAFETY ARCHITECTURES IN
SCDL
KENJI TAGUCHI (CAV), RYO KURACHI (NAGOYA UNI), KIYOSHI SASAKI
(MARELLI), NOBUHIKO NAKAMURA (VECTOR), KAZUKI TOMONAGA
(MITUBISHI ELECTRIC), SHUHEI YAMASHITA (DNV)
18 SEP 2020

Background
• Cybersecurity threats have become a reality for safety critical systems
such as automobiles, railways and avionics, witnessing cybersecurity
incidents and POC reports from white hackers.
• Threat analysis for safety critical systems needs to assess an effect
caused by threats against safety.
• How to integrate the system development lifecycle for functional safety
and cybersecurity has not been well established yet.

Main Challenges
• Proposal for Security threat analysis framework at the concept phase in
ISO 26262
‒ This assume that
Identification of essential ingredients on threat analysis and their
adaptation to the security threat analysis framework.
Analysis on security threats against safety concepts (safety goals,
functional safety requirements within abstract safety architecture).
Analysis on effects of security threats against safety
mechanism/architecture.
Protection against safety goal violation
Analysis on protection against security threats by safety
mechanism/architecture.

• Jeep Cherokee was remotely hacked by C. Miller and C. Valasek
‒ Black Hat 2015, Remote Exploitation of an Unaltered Passenger Vehicle, 2015
• Attack vectors
‒ Remote attack
 No direct injection of CAN messages on the CAN Bus.
 Remote access via Infotainment device
‒ Spoof CAN messages
 Enforce an ECU into diagnostic mode and spoof the control messages from it.
• Safety mechanism against security threat!
‒ An ECU can only be put under diagnostic mode at a low speed.
‒ A safety mechanism somehow defends an ECU from this attack vector.
Jeep Cherokee Hack
Tesla Model S Hack
• Hack on Tesla Model S was remotely hacked by Tencent
‒ Black Hat 2016, Free-Fall: Hacking Tesla From Wireless to CAN Bus
• Attack vectors
‒ Remote attack
 via Infotainment system
 Used vulnerabilities commonly found in IT
‒ Spoof CAN messages
 Spoof control messages to ECUs
• Defended by safety mechanism!
‒ Some ECUs do not respond under driving mode

Safety Mechanisms Against Security Threats
Safety mechanism against hazard
hazard
Safety mechanism
Security threat causes hazard
hazardthreat
Jeep/Tesla Hack
hazardthreat
Safety mechanism

Assumed Process
• Several ways to integrate processes for the system development (for system function), safety
development (for safety mechanisms) and security development (for security mechanism).
• The process we assumed in this paper is basically the safety-first process, where safety
architecture has been already modelled in SCDL.
1) Simultaneous development
2) Trade-off development
Trade-off
3) Our process
ISO 26262

SCDL (Safety Concept Description Language)
• ISO 26262 requires the safety concept, which is “specification of the functional safety requirements, with
associated information, their allocation to architectural elements, and their interaction necessary to achieve
the safety goals”.
• The SCDL aims to provide the intuitive semi-formal notation with the rigorous background (meta-model)
for the safety concept which faithfully and precisely follows ISO 26262.
• The language specification has been developed by the SCN-SG (Safety Concept Nation Study Group) formed
by engineers from OEMs, suppliers, tool vendors, etc.
• International standardization of the SCDL is under way at ASAM (Association for Standardization of
Automation and Measuring Systems).
• Some OEMs and suppliers have been using the SCDL for the development of safety concepts in ISO 26262.
‒ SCN-SG members from more than 100 companies and organizations
‒ First version of specification documents 650 downloads for far (2020 Feb)
• Current status
‒ SCDL specification
 English version v. 1.4, 2018
 Japanese version v. 1.5, 2020
• Currently available toos.
‒ Add-in tool on Enterprise Architect (Sparx Systems)
‒ Safilia (Gaio Tech)
‒ Astah System Safety (Change vision)

Basic Symbols of SCDL
• Requirement notation
‒ Functionalities, roles, and behaviors
‒ Weighting (assigned ASIL)
[Requirements]
[Interaction]
Example
• Element notation
‒ Systems, sub-systems, components,
units, modules, etc
‒ Weighting (assigned ASIL)
[Elements]
• Interaction notation
‒ Relationship between requirements
such as information, signals,
messages, etc.
[System boundary interaction]
• System boundary interaction notation
‒ Relationship between requirements
and interactions from/to the outside
of the system/item
Remark: These figures are copyrighted by SCN-SG presentation slides.

Some Auxiliary Notations Unique to SCDL
[Requirement group]
• A collection of requirements within
a certain grouping
[Pairing]
• Linking constraints to paring
between requirements groups
• Coexistence of requirements with
different ASIL (no interference assumed)
• the independence requirement in “Pairing”
with constraints (no interference assumed)
Remark: These figures are copyrighted by SCN-SG presentation slides.

Case Study
• This is a very simplified system of “Parking Assist System” which consists of several elements with
requirements and interactions among them.
‒ Parking Assist System (ITEM-1) = Smartphone (EL-1) + Vehicle (EL-2)
‒ Vehicle (EL-2) = Gateway (EL-3) + Parking Assist ECU (EL-4) + Control System (EL-5) + Locator ECU (EL-6) + Environment
Recognition (EL-7)
Non-functional safety requirement
Main Functionality (Intended Functionality)
Safety Mechanism

Criteria on threat analysis
1. Where does an attack come from? => Attack surface
2. What should be protected from an attack? => Asset
‒ Assets are classified into functional assets and information assets
3. What boundary should be protected from an attack? => Trust boundary
4. How does an attack reach the target? => Attack path/Attack scenario
5. What kind of attacks are possible? => Attack identification
6. How many attacks are necessary? => Multiple attacks
1. Attack surface => Interactions and system boundary interactions
2. Asset => Requirements for functional assets and interactions for information assets
3. Trust boundary => Boundary of an element
4. Attack path => Any path comprising requirements and interactions
5. Attack identification => Typical attack categories such as STRIDE
6. Multiple attacks => Combination of attacks on attack surfaces and/or assets
Interpretation of those modeling elements for threats in SCDL
Remark: No explicit model element for data in SCDL

Security Analysis: Trust Boundary and Attack Surface
• The trust boundary of this system can be regarded as Vehicle itself, e.g., EL-2.
• Any interactions between this boundary and outside can be regarded as an entry point of potential
attacks (Attack surfaces).
‒ Map Data (System boundary interaction)
‒ Positioning Information (System boundary interaction)
‒ Sensor Input (System boundary interaction)
‒ On/NOGO (Interaction)
Attack Surfaces Trust boundary

Security Analysis: Assets
• Assets are classified under functional and information assets.
[Information assets]
[Functional assets]
[Identified attack surfaces]

Identified potential attacks by STRIDE : Attack Surfaces
• STRIDE is a collection of typical threats, i.e., Spoofing, Tampering, Repudiation,
Information disclosure, Denial of Services and Elevation of privilege used in SDL
(Secure Development Lifecycle) by Microsoft.
• STRIDE is applied to identified attack surfaces and assets
Spoofing Positioning Information (e.g., GSP spoofing)
Typical examples:
Tampering Map data (e.g., tampering coordinates)
Information disclosure of GO/NOGO commands (e.g., eavesdropping the command GO/NOGO)
Denial of Service of Sensor Input (e.g., Disturbance against ultrasonic sensor)

Identified potential attacks by STRIDE: Assets
Tampering Command Checking (e.g., change its functionality)
Typical examples:
Denial of Service of Control value generation (e.g., delay the function)
Escalation of privilege against Monitor (e.g., Override the function)

Safety Goal and Safety Goal violation
• Safety Goal
‒ The item does not generate unintended control values (actuation) against user intention.
‒ The safety goal violation could be judged by the outer-most output, in this case Control
values (actuation)
User intention Control values (actuation)

Attack Scenario #1
Attack starting with “Spoofing User operation” could be prevented by “FR-6:
Judgement”.
1: Spoof User operation
2: GO/NOGO is transferred
3: Pre command is transferred
FR-6 judges whether the
parking place is appropriate
using Map Data and
Location Data.

Attack Scenario #2
Multiple attacks with “Spoofing User operation” and “Tampering Map Data” could be
prevented by “FSR-3: Control Value Generation” with “Environment Recognition Data”.
1-1: Spoof User operation
1-2: GO/NOGO is transferred
1-3: Pre command is transferred
FSR-3 senses the
surrounding environment
from Sensor Input and might
detect some obstacles.
2-1:Tamper Map Data
2-2:Map Data is transferred 2-3: GO/NOGO is transffered

Attack Scenario #3
Multiple attacks with “Spoofing User operation”, “Tampering Map Data” and “Spoof
Sensor Input” could not be prevented by any safety mechanism and causes the safety
goal violation.
1-1: Spoof User operation
1-3: Pre command is transferred
2-1:Tamper Map Data
2-2:Map Data is transferred
3-1:Spoof Sensor Input
3-2: Environment Recognition Data is transferred
The rest of interactions are all transferred.
Unintended control
value/actuation is generated

Related Work
• Only limited to Architecture Description Language (AD) with security extension
related to automotive systems.
• EAST-ADL
‒ Developed under ITEA EAST-EEA
‒ Integration of AUTOSAR
‒ SAM (Security Abstraction Model) for a meta-model for security properties.
‒ No specific threat analysis technique for safety architecture nor any relationship between
safety and security.
• AADL
‒ Developed by SAE and CMU/SEI
‒ Error Mode Annex for error models and Security Annex for security model
‒ Security Annex is based on MILS architecture and applied to avionics
‒ No work on safety and security interactions.
• SysML
‒ cp/TARA is an integrated threat analysis tool
‒ Security extensions of SysML block definition diagrams (assets, attack surfaces, etc) and
requirements diagrams (functional security req. following SAE J3061).
‒ No work on safety and security interactions.

Concluding Remarks and Future Directions
• We proposed the security threat analysis framework for SCDL, which can
help identify potential threats against safety concepts modelled in SCDL.
‒ Effects by security threats against safety architecture/mechanism can be
analyzed.
‒ This framework provides TARA (Threat Analysis and Risk Assessment) at the
concept phase in ISO 26262.
RA part has not been achieved yet.
• Future directions include the followings:
‒ Feedback loop to functional safety activities after threat analysis is carried out
(including feasibility study on cybersecurity concept in SCDL).
‒ Possible yet effective integration of functional safety (ISO 26262) and
security processes (ISO/SAE 21434).
‒ Further adaptation of this framework towards activities to follow (e.g., system
level) in ISO 26262.

Thank you for your attention!
Acknowledgements to all members of SCDL Security SWG, particularly Mr. T.
Muramatsu and F. Kohno for the discussion on the issues addressed in this
paper.

Basic Concept Related to Safety
• Safety related concepts such as hazard, accident, risk, failure have different definitions and
understanding in industries and countries.
• Definitions (from ISO 26262)
‒ Hazard
 potential source of harm caused by malfunctioning behaviour of the item
‒ Safety mechanism
 technical solution implemented by E/E functions or elements, or by other technologies,
to detect faults or control failures in order to achieve or maintain a safe state.
 Remark: Safety mechanism includes simple monitor-arbitration logic to more complex
fault tolerant/redundancy mechanisms
hazard
Safety mechanism
Examples of hazard:
1) Overheat of battery charging device causes its explosion and/or make burns.
2) ECU produces unintended assist torque.
The following simplified figure is used to represent safety mechanism against hazard.

Threat and Hazard: How Do They Interact Each Other?
• There is no clear and definitive definition on how
threat and hazard are related each other.
• Definitions (from J3061)
‒ Threat
 A circumstance or event with the potential to
cause harm, where harm may be with
respect to financial, reputation, privacy,
safety, or operational.
• We take that a hazard may be caused by threat as a
working assumption.
Hazard: Overheat of battery charging device causes its explosion and/or makes burns.
Threat (action): Malware causes malfunction of battery charging device.
Hazard: ECU produces unintended assist torque.
Threat (action): Control message is spoofed.
hazardthreat
That a threat causes a hazard relationship

SAFETY THREAT ANALYSIS FRAMEWORK

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie SAFETY THREAT ANALYSIS FRAMEWORK

Ähnlich wie SAFETY THREAT ANALYSIS FRAMEWORK (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (12)

SAFETY THREAT ANALYSIS FRAMEWORK