0% found this document useful (0 votes)

195 views

Tara

This document provides a threat analysis and risk assessment for a vehicle access, locking, and start authorization system. It outlines the following steps: 1. Define the system scope and components through a system diagram and asset list. 2. Identify asset attributes and use cases. 3. Conduct a threat analysis using the STRIDE model and assess risks to assets. 4. Make risk treatment decisions to avoid, mitigate, transfer, or accept risks. 5. Define cybersecurity goals based on the risk treatment. 6. Document any risk avoidance, retention, or transfer claims. The document includes lists of assets and associated data, threat scenarios and potential damage scenarios, risk assessments,

Uploaded by

Anuvind Krishna Tiwari

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as XLSX, PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

195 views

Tara

Uploaded by

Anuvind Krishna Tiwari

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as XLSX, PDF, TXT or read online on Scribd

You are on page 1/ 108

Threat Analysis And Risk Assessment Report

Project: Doc-ID:
Maturity: Released Version: 1.0

Author:
Role Name Date Signature
Cyber Security Manager

Checked by:
Role Name Date Signature
General Manager Pavan Kodali

Purpose:
Threat Analysis & Risk Assessment for Vehicle Access, Locking and Start Authorization
System

Scope (validity area & date, replaced documents):

Validity of this document is only for the defined vehicle use case (based on item definition)
Item Definition (ID)
Provide system diagram about
Step1 the item, which are relevant for
following analysis must be
clarified,including boundaries,
interfaces,data flow.
Asset Attributes Identification
Step (AAI)
2 - Asset List
- Use Case Description
- Attributes Identification

Threat Analysis And Risk Assessment

Step (TARA)
3 - Asset informaiton
- STRIDE Threat Model Scenarios
- Risk Assessment

Risk Treatment Decisions (RTD)

Step4 - Asset List
- Use Case Description
- Avoid
- Mitigation
- Transfer
- Accept

Goal
Cybersecurity Goals (CG)
- Cybersecurity Goals Summary
Step5

Y
(RTD)

Mitigation?

N
Cybersecurity Claims (CC)
- Risk Avoidance Claim
Step - Risk Retention Claim
6 - Risk Transfer Claim
Asset ID Asset
P-001 NFC Interface
P-002 Zone Controller Cabin
P-003 Zone Controller Front Left
P-004 Zone Controller Rear
P-005 Low Voltage Battery Management System
P-006 Airbag Control Unit
P-007 Electronic Stability Program
P-008 Connectivity Box
P-009 Head Unit
P-010 Cloud
P-011 Smart Phone
set Data ID Data
D-001 Door Unlock request from smartphone(NFC enabled) to NFC interface via NFC signal.
D-002 Door Unlock request from NFC interface to ZC_C
Left D-003 Low voltage battery signal from LV_BMS to ZC_R
D-004 Drive direction information (PRND) from gear shifter to ZC_C
Management System D-005 Battery status information from ZC_R to ZC_C.
D-006 Crash status from ACU to ZC_FL.
ogram D-007 Vehicle speed status from ESP to ZC_FL.
D-008 Vehicle speed status and crash status from ZC_FL to ZC_C.
D-009 Lock/unlock request from ZC_C to smart latch.
D-009' Door ajar status from smart latch to ZC_C
D-010 Lock/unlock status from cloud to smart phone app and app update via cloud.
D-011 Lock/unlock status from connectivity box to cloud and firmware update via cloud.
D-012 Lock/unlock status from ZC_C to connectivity box.
D-012' Firmware update from connectivity box to ZC_C and other ECUs via cloud.
D-013 Lock/Unlock request from Head unit to ZC_C.
D-013' Display door related status on head unit.
D-014 Lock/Unlock command from smart phone to Head unit via Bluetooth.
ace via NFC signal.

e via cloud.
pdate via cloud.

a cloud.

th.
Sl. No

P-001

P-002

P-003

P-004

P-005

P-006

P-007

P-007
P-008

P-008

P-009
P-009

P-009

P-010

P-011

D-001

D-002

D-003

D-004

D-005

D-006

D-007

D-008

D-009
D-009

D-009'

D-010

D-011

D-012

D-012'

D-013

firmware can be flashed which
might lead to major safety
Attacker may
issue. 1. Analyze the Ethernet messages via OBD-II
compromise the
Due to the loss of authenticity of Attacker may flash the malicious firmware over the air Financial: Major, as 2. Reverse engineer Ethernet messages and
authenticity of Criminals with motives
Connectivity T- connectivity box, malicious firmware by impersonating legitmate user, thereby driver may system/accident recovery may identify the messages responsible for connectivity Organized Organizational Material
A2 connectivity box by DS-025 Ma Ma Ma Ma Ma OBD II AP-025 6.1 External <6m Proficient Public Easy Standard 8 High 4 of civilian harm conduct Mitigation M10 G.4
Box 025 might be flash into other ECUs through experience unpredictable behaviour from the system take major cost. box. Crime Gain Damage
sending fake request this kind of attack
connectivity box. due to the malicious firmware update. Operational : Major, as driver 3. Transmit the Ethernet messages with Ethernet ID
or by updating
cannot access the vehicle. of connectivity box.
malicious firmware.
Privacy: Major, since private
data is stored in the
connectivity box.

Safety: Negligible, since no

manipulation of critical
functionality.
Attacker may Financial: Major, since
compromise the intellectual property has been 1. Obtain the target ECU (development phase).
A disgruntled employee
confidentiality of lost to the stakeholder, finance 2. Disassemble the Head unit.
Due to the loss of confidentiality of the will have a motive to
T- firmware by analyzing The firmware logic is leaked, resulting in the software is a major concern. 3. Identify the JTAG interface. Disgruntled Reputation
Head Unit C DS-026 firmware, the processing logic of the Ne Ma Ne Ne Ma USB AP-026 15.2 Internal Disgruntlement <1m Proficient Restricted Moderate Standard 11 High 4 damage the reputation Mitigation M18 G.1
026 plaintext firmware files copyright being seen. Operational: Negligible, as the 4. Extract the firmware. Employee Damage
Head unit might be leaked. of his employing
to obtain vehicle's operation remains 5. Analyze the firmware through firmware reverse
company
sensitive/critical unchanged, so there is no engineering tools.
information. operational impact.
Privacy: Negligible, as no
private data stored in the
system.

High
Safety: Moderate because of 1. Download the FOTA package from the FOTA
tampered door ajar status. server.
Financial: Moderate, since the 2. Reverse analyze the FOTA package and forge a
Attacker may An external agent with
system recovery may take malicious FOTA package.
compromise the Due to the loss of integrity of the The firmware has been tampered, resulting in the Cellular motives to damage the
T- major cost. 3. Obtain the target vehicle. Material
Head Unit I integrity of firmware by DS-027 firmware, the function of the head unit manipulation of the functionality of head unit. Mo Mo Mo Ne Mo Connection(3 AP-027 17.1 Cyber Vandal External Dominance <6m Expert Public Moderate Standard 14 Medium 2 assets of a user may Mitigation M20 G.2
027 Operational: Moderate, 4. Attacker might implement man-in-the-middle Damage
tampering the might not work properly. G/4G) carry out this type of
because of partial degradation attacks through fake LTE BTS and push malicious
firmware. attack
of the function. FOTA packages.
Privacy: No private data 5. Wait for the head unit upgrade to restart and to
stored in the system. install the tampered firmware.

Safety: Moderate, as door ajar High

status will not be displayed on
head unit.
Financial: Moderate,since the 1. Analyze the Ethernet messages via OBD-II An external agent with
Exploiting software
Due to a lack of availability, the head system recovery may take 2. Reverse engineer Ethernet messages and motives to damage the
T- vulnerabilities to make This may cause some functions of the vehicle to be Material
Head Unit A1 DS-028 unit might fail to receive the door-ajar Mo Mo Mo Ne Mo moderate cost. OBD II AP-028 identify the messages responsible for Head Unit. 24.1 Cyber Vandal External Dominance <1m Expert Public Easy Specialized 12 High 3 assets of a user may Mitigation M13 G.3
028 ECU unable to provide unavailable. Damage
status and Bluetooth signal, too. Operational: Moderate 3. Transmit large amount of junk data to make it carry out this type of
functions.
because of partial degradation unavailable. attack
of the vehicle.
Privacy: No private data
stored in the system.

Safety: Negligible, no impact

on road user.
Financial: Major, as financial 1. Analyze the Ethernet messages via OBD-II. An external agent with
Attacker may
Due to the loss of authenticity, the fake loss to user. 2. Reverse engineer Ethernet messages and motives to damage the
T- compromise the The vehicle was unlocked illegally, causing it to be Material
Head Unit A2 DS-029 head unit will send control commands Ne Ma Mo Ne Ma Operational: Moderate OBD II AP-029 identify the messages responsible for Head Unit 6.1 Cyber Terrorist External Ideology <6m Proficient Public Easy Standard 8 High 4 assets of a user may Mitigation M10 G.4
029 authenticity of Head stolen. Damage
to ZC_C to access the vehicle. because of partial degradation 3. Transmit the Ethernet messages with Ethernet ID carry out this type of
unit.
of the vehicle. of Head Unit. attack
Privacy: No private data
stored in the system.

Safety: Major, malicious 1. Prepare Universal Serial Radio Peripheral fake

firmware can be flashed, LTE BTS.
Attacker may which lead to safety issue. 2. Use fake LTE BTS to read and analyze data in
A competitor will have a
compromise the Due to the loss of authenticity, the fake Financial: Moderate loss to Cellular car accessories.
T- Organizational Reputation motive to damage the
Cloud A2 authenticity of cloud by DS-030 cloud will send control commands to Malicious firmware can be flashed into other ECUs. Ma Mo Mo Ne Ma stakeholder. Connection(3 AP-030 3. Create fake server. NA Competitor External <1m Proficient Public Easy Standard 5 High High 4 Transfer NA NA
030 Gain Damage reputation of the
replacing it with a fake the target vehicle. Operational : Moderate, as G/4G) 4. Use a fake base station for IP address spoofing
competing company.
one(server). partial degradation of function. to make Connectivity box connect to a fake server.
Privacy: Negligible, as no user 5. Perform drive by download to flash the malicious
details stored. firmware.

Safety: Negligible, as no
impact on road user.
Financial: Major, as vehicle
Due to the loss of authenticity, the 1. Guide users to download and install malicious
Attacker may can be unlocked illegally and A social hacker with
attacker can send control commands applications.
T- compromise the It may cause the vehicle to be unlocked illegally and cause vehicle to be stolen. Online Social Personal Acquisition/ motives to theft may
Smart Phone A2 DS-031 to the vehicle (or to the cloud through Ne Ma Mo Ne Ma Wi-Fi AP-031 2. Obtain user key information through malicious NA External <1m Proficient Public Easy Standard 5 High High 4 Transfer NA NA
031 authenticity of the vehicle to be stolen. Operational : Moderate Hacker Financial Gain Theft carry out this type of
a smartphone app) by impersonating a applications.
smartphone. because of partial degradation attack
legitimate user. 3. Use the key information to forge equipment.
of function.
Privacy: No private data
stored in the system.

Assumption based on Android version 9.0 below.

Safety: Negligible, since no
1. Attacker may bring the NFC reader rigged device
impact on road user.
in to range of 4 to 10 cm of NFC enabled smart
Door Unlock Attack may Financial: NFC interface
phone.
Request from comprimise the Due to the loss of authenticity of the recovery may take moderate A social hacker with
2. Connect the rigged device to the victims NFC
smartphone( T- authenticity of the NFC NFC enabled smartphone, the attacker The user might not access the vehicle through NFC cost. KeyFOB and Online Social Personal Acquisition/ motives to theft may
A2 DS-032 Ne Mo Mo Ne Ne AP-032 enabled smart phone. 16.3 External <1m Proficient Public Easy Standard 5 High High 2 Mitigation M19 G.7
NFC 032 enabled smartphoe or can successfully authenticate the NFC feature. Operational: Moderate Immobilizer Hacker Financial Gain Theft carry out this type of
3. Install the malware on smartphone.
enabled )to any smart device by signal. because of partial degradation attack
4. Malware on the smartphone will impersonate the
NFC interface (Ghost Tap attack) of the vehicle.
legit smartphone application and can be controlled
Privacy: Negligible, No private
by an attacker.
data is stored.

Safety: Negligible, since no

impact on road user.
Financial: NFC interface
CAN Attacker may 1. Gain access to the CAN bus. An external agent with
recovery may take moderate
communicati compromise the Due to loss of integrity of CAN signal, The user might not enable the vehicle through the 2. Observe and capture the CAN messages while a motives to damage the
T- cost. Material
on between I integrity of CAN bus DS-033 the tampered NFC signal will go to NFC feature, which might affect the partial Ne Mo Mo Ne Ne OBD II AP-033 user is operating on NFC or using NFC to unlock / 6.1 Cyber Vandal External Dominance <6m Proficient Public Easy Standard 8 High High 2 assets of a user may Mitigation M10 G.5
033 Operational: Moderate Damage
NFC interface by tampering the CAN ZC_C. functionality of ZC_C. lock vehicle carry out this type of
because of partial degradation
and ZC_C signal. 3. Replay the modified captured CAN messages attack
of the vehicle.
Privacy: Negligible, as no
private data is stored.

Safety: Negligible: no impact

1. Install a malicious application in the Head Unit.
on road user.
2. Attacker now have remote access to the Head
Financial: Moderate,since the
By tampering the Unit. An external agent with
Ethernet system recovery may take
ethernet signal Due to loss of integrity of ethernet 3. Find the MAC address of the Head Unit. motives to damage the
communicati T- moderate cost. Material
I attacker may DS-057 signal, tampered Lock/unlock request Driver might lose partial functionality of ZC_C. Ne Mo Mo Ne Ne USB AP-056 4. Block the communication between the original 6.1 Cyber Vandal External Dominance <6m Proficient Public Easy Standard 8 High 2 assets of a user may Mitigation M10 G.5
on from head 056 Operational: Moderate, Damage
compromise the might send to ZC_C. Head Unit and Zone Controller Cabin. carry out this type of
unit to ZC_C because of partial degradation
integrity of the signal. 5. Masquerade as the Head unit by spoofing its attack
of the vehicle.
MAC address and sending the incorrect message to
Privacy: No private data
the Zone Controller Cabin.
stored in the system.

High

Safety: Negligible, as no
impact on road user.
Financial: Moderate, since the
Flooding of ethernet An external agent with
Ethernet system recovery may take 1. Access the ethernet bus and connect the packet
bus to halt the Due to loss of availability of ethernet Driver may not be able to access the vehicle via motives to damage the
communicati T- moderate cost. analyser device to it. Material
A1 communication DS-057 bus, it halts the communication bluetooth, thereby may feel degraded performance Ne Mo Mo Ne Ne OBD II AP-057 24.1 Cyber Vandal External Dominance <6m Proficient Public Easy Standard 8 High 2 assets of a user may Mitigation M13 G.6
on from head 057 Operational: Moderate, 2. Create the mal crafts packets. Damage
between Head unit between Head unit and ZC_C. from the vehicle. carry out this type of
unit to ZC_C because of partial degradation 3. Flood the bus with mal crafted packets.
and ZC_C. attack
of the vehicle.
Privacy: No private data
stored in the system.

Safety: Moderate, as door ajar

status will got tampered.
(depends upon the scenario).
Ethernet By tampering the Financial: Moderate, since the An external agent with
1. Access the ethernet bus and connect the packet
communicati ethernet signal Due to loss of integrity of ethernet bus, system recovery may take motives to damage the
T- Head unit will receive erroneous signal from ZC_C, analyser device to it. Material
on from I attacker may DS-058 tampered lock/unlock status will pass Mo Mo Mo Ne Mo moderate cost. OBD II AP-058 6.1 Cyber Vandal External Dominance <6m Proficient Public Easy Standard 8 High 3 assets of a user may Mitigation M10 G.5
058 thereby impacting the functionality of Head unit. 2. Create the mal crafts packets. Damage
ZC_C to compromise the on head unit. Operational: Moderate, carry out this type of
3. Tamper the signal with Mal crafted packets.
Head unit. integrity of the signal. because of partial degradation attack
of the vehicle.
Privacy: No private data
stored in the system.

High

Safety: Moderate as door ajar

status will not be notified.
(depends upon the scenario).
Ethernet Flooding of ethernet Financial: Moderate, since the
1. Access the ethernet bus and connect the packet Criminals with motives
communicati bus to halt the Due to loss of availability of ethernet system recovery may take
T- Driver may not be able to view any door related analyser device to it. Organized Organizational Material to damage the assets
on from A1 communication DS-059 bus, it halts the communication Mo Mo Mo Ne Mo moderate cost. OBD II AP-059 24.1 External <6m Proficient Public Easy Standard 8 High 3 Mitigation M13 G.6
059 status on head unit display. 2. Create the mal crafts packets. Crime Gain Damage of a user may carry out
ZC_C to between ZC_C and between ZC_C and Head unit. Operational: Moderate,
3. Flood the bus with mal crafted packets. this type of attack
Head unit. Head unit because of partial degradation
of the vehicle.
Privacy: No private data
stored in the system.

Safety: Negligible, since no

manipulation of critical
1. Attacker can come in the Bluetooth range.
functionality.
Attacker might 2. Use some malicious device (for e.g. ubertooth
Financial: Major, since A script kiddies with
Smart Phone compromise the Due to loss of confidentiality, the tool) to capture the signal.
T- Attacker can read the sensitive data(bluetooth Intellectual property loss of Personal Acquisition/ motives of theft may
to Head unit C confidentiality of the DS-060 processing logic of the bluetooth signal Ne Ma Ne Ne Ma Bluetooth AP-060 3. Based on the information attacker can analyse 16.3 Script Kiddies External <1w Proficient Public Easy Standard 4 High 4 Mitigation M19 G.8
060 packets). organization. Satisfaction Theft carry out this type of
via bluetooth bluetooth by sniffing might be leaked. the signal.
Operational : Negligible, since attack
the traffic. 4. Reverse engineer the GATT commands using
firmware is not manipulated.
Wireshark.
Privacy: Negligible, since no
private data is stored.

Safety: Negligible,as no
impact on road user.
Financial: Moderate, since the
Attacker might system recovery may take 1. Select the target device. A social hacker with
Smart Phone Due to loss of integrity of bluetooth Beacause of tampered information it might affect the
T- compromise the moderate cost. 2. Sniff the traffic. Online Social Personal Acquisition/ motives of theft may
to Head unit I DS-061 signal, tampered lock/unlock partial functionality of head unit. Driver may not be Ne Mo Mo Ne Ne Bluetooth AP-061 16.1 External <1w Proficient Public Easy Standard 4 High 2 Mitigation M19 G.5
061 integrity of bluetooth Operational: Moderate, 3. Modify and perform replay attack to send the Hacker Financial Gain Theft carry out this type of
via bluetooth information might pass to head unit. able to access the vehicle via bluetooth.
signal by replay attack. because of partial degradation GATT commands. attack
of the vehicle.
Privacy: No private data
stored in the system.

High
Safety: Negligible, as no
impact on road user.
Financial: Moderate, since the
1. Attach BLE Dongle.
Attacker might Due to loss of availability of bluetooth system recovery may take A social hacker with
Smart Phone 2. Scan for targeted vehicle BLE device
T- compromise the signal, it halts the bluetooth Driver may not be able to access the vehicle via moderate cost. Online Social Personal Acquisition/ motives of theft may
to Head unit A1 DS-062 Ne Mo Mo Ne Ne Bluetooth AP-062 3. Run Sweyntooth exploit. 16.3 External <1w Proficient Public Easy Standard 4 High 2 Mitigation M19 G.6
062 availability of bluetooth communication between smartphone bluetooth. Operational: Moderate, Hacker Financial Gain Theft carry out this type of
via bluetooth 4. Vehicle’s BLE device will crash and restart
signal by DoS attack. and head unit. because of partial degradation attack
Which results, head unit ECU will restart.
of the vehicle.
Privacy: No private data
stored in the system.

Safety: Negligible, as no
impact on road user.
Financial: Moderate, since the 1. Use BLE Sniffer to capture the BLE Packets.
Attacker might Attacker can get access to the vehicle by system recovery may take 2. Wait for the victim to connect vehicle Bluetooth A social hacker with
Smart Phone Due to loss of authenticity of bluetooth
T- compromise the impersonating legitmate user, thereby driver may moderate cost. and perform some action. Online Social Personal Acquisition/ motives of theft may
to Head unit A2 DS-63 signal, attacker can get successfully Ne Mo Mo Ne Ne Bluetooth AP-063 4.1 External <1w Proficient Public Easy Standard 4 High 2 Mitigation M10 G.7
063 authenticity of experience unpredictable behaviour from the vehicle Operational: Moderate, 3. Now attacker can capture the GATT Commands. Hacker Financial Gain Theft carry out this type of
via bluetooth authenticate to the bluetooth signal.
bluetooth signal. or attacker can steal the vehicle. because of partial degradation 4. Replay the GATT Command responsible for attack
of the vehicle. authentication.
Privacy: No private data
stored in the system.
Cybersecurity
Cybersecurity Requirement
Claims (If Any)

Encrypt the firmware files. NA

It shall be ensured that production services should

NA
be disabled after the target device production.

It shall be ensured that production services should

NA
be disabled after the target device production.

Access to employees of the company should be

NA
based on least access privilege.

It shall be ensured that logging of user actions

NA
should be done mandatorily.

It shall be ensured that internal malicious activity

NA
should be deducted.

Access to employees of the company should be

NA
based on least access privilege.

It shall be ensured that logging of user actions

NA
should be done mandatorily.

It shall be ensured that internal malicious activity

For OBD port:

It shall be ensured that OBD port access is
protected using UDS 0x27 security access
algorithm.
HMAC-SHA-256 algorithm is used to generate the
key based on the random number provided by
ECU and access to the ECU is granted only after
the successful verification of the key.
NA
For CAN communication:
It shall be ensured that the CAN bus is protected
using the Secure On-board Communication
protocol.
It shall be ensured that AES-128 algorithm is used
to generate the message authentication code.
It shall be ensured that receiver ECU shall accept
the CAN frames only after verification of MAC.
Access to employees of the company should be
NA
based on least access privilege.

A secure mechanism to protect FOTA packages

should be deployed.
It shall be ensured that the firmware is signed with
RSA-4096 along with SHA-384 and firmware
NA
download is only possible inside the ECU after
successful verification of signature.
It shall be ensured that public keys are stored in
HSM/NVM/OTP.

It shall be ensured that internal malicious activity

NA
should be deducted.

For OBD port:

For ethernet communication:

It shall be ensured that the Ethernet bus is
protected using the Secure On-board
Communication protocol.

It shall be ensured that OBD port access is
protected using UDS 0x27 security access
algorithm.
HMAC-SHA-256 algorithm is used to generate the
key based on the random number provided by
ECU and access to the ECU is granted only after
the successful verification of the key.
NA
For CAN communication:
It shall be ensured that the CAN bus is protected
using the Secure On-board Communication
protocol.
It shall be ensured that AES-128 algorithm is used
to generate the message authentication code.
It shall be ensured that receiver ECU shall accept
the CAN frames only after verification of MAC.
For OBD port:
It shall be ensured that OBD port access is
protected using UDS 0x27 security access
algorithm.
HMAC-SHA-256 algorithm is used to generate the
key based on the random number provided by
ECU and access to the ECU is granted only after NA
the successful verification of the key.

For CAN communication:

It shall be ensured that the CAN bus is protected
using the Secure On-board Communication
protocol.

For OBD port:

For CAN communication:

It shall be ensured that the CAN bus is protected
using the Secure On-board Communication
protocol.

It shall be ensured that end-to-end encryption

NA
technique should be implemented.

Secure mechanism to verify the integrity of the

For OBD port:

For ethernet communication:

It shall be ensured that the Ethernet bus is
protected using the Secure On-board
Communication protocol.

Ensures that only the authorized devices can

NA
access the data.

Secured mechanism to verify that the packet or

NA
message was not altered.

It shall be ensure that bluetooth is protected using

NA
TLS (transport layer security) 1.3

Verifies the identity of devices (pairing).

It shall be ensured that secured authentication NA
mechanism should be implemented.
Types of Access Impact Potential
Level Exposures
Physical Access Wireless Access Safety
OBD II Port ✓ ✓
Wi-Fi ✓ ✓
Cellular Connection (3G/4G) ✓ ✓
High
Over-the-Air Update ✓ ✓
Infotainment System ✓ ✓
Smart Phone ✓ ✓
Bluetooth ✓ ✓
Remote Link Type App ✓ ✓
KeyFobs and Immobilizers ✓
Medium
USB/JTAG ✓ ✓
ADAS System ✓ ✓
DSRC-Based Receiver(V2X) ✓ ✓
DAB Radio ✓ ✓
TPMS ✓
GPS ✓
Low
eCall ✓ ✓
EV Charging Port ✓ ✓
CD/DVD Player ✓ ✓

Common Exposure Library

Impact Potential
Data Privacy Car Jacking
✓ ✓
✓
✓

✓
✓ ✓

✓ ✓
✓
✓

✓
✓
Non-Hostile Intent

Threat Agent Attributes

Reckless Untrained
Employee Employee

Internal
Access
External
Acquisition/Theft
Business Advantage
Material Damage
Outcome
Technical Advantage
Reputation Damage
15 Minutes of Fame
Individual
Club
Contest
Resources
Team
Organization
Government
None
Minimal
Skills
Operational
Adept
Overt
Covert
Visibility
Clandestine
"Don't Care"
Code of Conduct
Legal
Limits
Extra Legal - Minor
Extra Legal - Major
Copy
Deny
Injure
Objective Destroy
Damage
Take
All Above/Don't care
Accidental
Coercion
Disgruntlement
Dominance
Ideology
Motivation
Notoriety
Organizational Gain
Personal Financial Gain
Personal Satisfaction
Unpredictable
None
Partial Trust
Trust
Trust
Employee
Administrator
Theft of PII and Business Data
Denial of Service
Method Intentional Manipulation
Unauthorized Physical Access
Unpredictable Action
Privacy Violated
Loss of Financial Assets/Car
Impact
Traffic Accidents
Injured Passengers
Non-Hostile Intent

Online
Outward Information Cyber Data
Hacktivist Competitor Social
Sympathizer Partner Vandal Miner
Hacker
Methods, Objectives & Threat Agent Library
Hostile Intent

Script Government Organized Radical Cyber Cyber

Sensationalist
Kiddies CyberWarrior Crime Activist Terrorist Criminal
ent Library
Internal Disgruntled
Government Spy
Spy Employee
Mitigation Ref.No.
M1 Security Controls are applied to back-end systems to minimise the risk of insider attack
M2 Security Controls are applied to back-end systems to minimise unauthorised access. Example Security C
M3 Security Controls are applied to back-end systems. Where back-end servers are critical to the provision
M4 Security Controls are applied to minimise risks associated with cloud computing. Example Security Cont
M5 Security Controls are applied to back-end systems to prevent data breaches. Example Security Controls
M6 Systems shall implement security by design to minimize risks
M7 Access control techniques and designs shall be applied to protect system data/code
M8 Through system design and access control it should not be possible for unauthorized personnel to acce
M9 Measures to prevent and detect unauthorized access shall be employed
M10 The vehicle shall verify the authenticity and integrity of messages it receives
M11 Security controls shall be implemented for storing cryptographic keys (e.g., use of Hardware Security M
M12 Confidential data transmitted to or from the vehicle shall be protected
M13 Measures to detect and recover from a denial of service attack shall be employed
M14 Measures to protect systems against embedded viruses/malware should be considered
M15 Measures to detect malicious internal messages or activity should be considered
M16 Secure software update procedures shall be employed
M17 Measures shall be implemented for defining and controlling user roles and access privileges, based on t
M18 Organizations shall ensure security procedures are defined and followed including logging of actions an
M19 Security controls shall be applied to systems that have remote access
M20 Software shall be security assessed, authenticated and integrity protected. Security controls shall be ap
M21 Security controls shall be applied to external interfaces
M22 Cybersecurity best practices for software and hardware development shall be followed. Cybersecurity t
M23 Best practices for the protection of data integrity and confidentiality shall be followed for storing perso
Mitigation Methods
sider attack
d access. Example Security Controls can be found in OWASP
are critical to the provision of services there are recovery measures in case of system outage. Example Security Controls can be found in O
ting. Example Security Controls can be found in OWASP and NCSC cloud computing guidance
. Example Security Controls can be found in OWASP

ta/code
uthorized personnel to access personal or system critical data. Example Security Controls can be found in Security Controls can be found in

use of Hardware Security Modules)

loyed
considered
ered

access privileges, based on the principle of least access privilege

luding logging of actions and access related to the management of the security functions

Security controls shall be applied to minimise the risk from third party software that is intended or foreseeable to be hosted on the vehicle

be followed. Cybersecurity testing with adequate coverage

e followed for storing personal data.
rity Controls can be found in OWASP

urity Controls can be found in OWASP

ble to be hosted on the vehicle

Goal Ref.No. Cybersecurity Goals
G.1 Protect the confidentiality of the firmware files.
G.2 Protect the integrity of the firmware files.
G.3 Protect the availability of the firmware files.
G.4 Protect the authenticity of the ECU.
G.5 Protect the integrity of the communication signal.
G.6 Protect the availability of the communication signal.
G.7 Protect the authenticity of the communication signal.
G.8 Protect the confidentiality of the digital key data in bluetooth.
ISO 21434 Road vehicles - Cybersecurity engineering (ISO 2020, Draft International S

Clause ID Description
The organization shall define a cybersecurity policy that includes:
a) acknowledgement of road vehicle cybersecurity risks; and
b) the executive management’s commitment to manage the
Overall Cybersecurity corresponding risks.
Management - [RQ-05-01] NOTE 1: Links to the organization’s objectives and other policies can be
Cybersecurity Governance included in the cybersecurity policy.
NOTE 2: The cybersecurity policy can include a statement regarding
the risk treatment of generic threat scenarios with respect

The organization shall establish and maintain organization-specific rules

and processes to:
a) enable the implementation of the requirements of this document; and
b) support the execution of the corresponding activities.
EXAMPLE 1: Process definition, technical rules, guidelines, methods
and templates.
Overall Cybersecurity NOTE 3: These rules and processes cover concept, development,
Management - [RQ-05-02] production, operation, maintenance, and decommissioning, including
Cybersecurity Governance cybersecurity risk management, information sharing, vulnerability
disclosure, cybersecurity monitoring, incident response, and triggers
(see 3.1.33).
NOTE 4: The rules and processes regarding vulnerability disclosure can
be specified in accordance with ISO 29147[2].

The organization shall assign and communicate the responsibilities to

Overall Cybersecurity achieve and maintain cybersecurity; and assign the corresponding
Management - [RQ-05-03] authority.
Cybersecurity Governance NOTE 6: This relates to the organizational as well as to the project
dependent activities.
The organization shall provide the resources to address cybersecurity.
NOTE 7: Resources include the persons responsible for cybersecurity
Overall Cybersecurity risk management, development, and incident management.
Management - [RQ-05-04] EXAMPLE 2: Appropriate resources might include public affairs or a red
Cybersecurity Governance team.

The organization shall identify disciplines related to, or interacting with,

cybersecurity and establish and maintain communication channels
between those disciplines in order to:
a) determine if and how cybersecurity will be integrated into existing
processes; and
b) coordinate the exchange of relevant information.
NOTE 8: Disciplines include information technology security, functional
Overall Cybersecurity safety, data protection, and privacy.
Management - [RQ-05-05] NOTE 9: Relevant information includes threat scenarios and hazard
Cybersecurity Governance information, cybersecurity goals and safety goals, or where a
cybersecurity requirement might conflict or compete with a safety
requirement.
NOTE 10: Coordination includes the identification of shared
cybersecurity services and the reuse of cybersecurity strategies and
tools between disciplines.
Overall Cybersecurity The organization shall define the risk values (1 to 5) in a risk matrix in
Management - [RQ-05-06] accordance with 8.8.
Cybersecurity Governance NOTE 11: See Annex J for guidance and examples.
The organization shall foster and maintain a cybersecurity culture.
Overall Cybersecurity NOTE 1: Those responsible for cybersecurity engineering lead by
Management - [RQ-05-07] example such that others trust and follow them.
Cybersecurity Culture NOTE 2: See Annex B for examples.
The organization shall ensure the persons within the organization that
are involved in cybersecurity have the competences and awareness to
fulfil their responsibilities.
EXAMPLE: Experience, awareness and training p 257 rograms
consider areas, such as:
- organizational rules and processes regarding cybersecurity, including
Overall Cybersecurity cybersecurity risk management;
Management - [RQ-05-08] - organizational rules and processes regarding disciplines related to
Cybersecurity Culture cybersecurity, such as functional safety and privacy;
- domain knowledge;
- systems engineering;
- cybersecurity-related methods, tools and guidelines; and/or
- known attack methods and cybersecurity controls.

The organization shall institute and maintain a continuous improvement

process, such as:
a) learning from previous cybersecurity experiences, including
experiences gathered by field monitoring and observation of internal
and external information;
b) learning from information obtained regarding products of similar
application in the field;
Overall Cybersecurity c) deriving improvements to be applied during subsequent
Management - [RQ-05-09] cybersecurity activities;
Cybersecurity Culture d) communicating lessons learned to the appropriate persons; and
e) checking the adequacy of its rules and processes in accordance with
[RQ-05-02].
NOTE 3: Lessons learned applies to activities of all phases (e.g., risk
management, cybersecurity monitoring, and vulnerability management).

Overall Cybersecurity Cybersecurity risk management shall be in accordance with ISO 31000.
Management -
[RQ-05-10]
Cybersecurity Risk
Management
The organization may align its cybersecurity risk management and its
corporate risk management.
NOTE: New and evolving cybersecurity risks after the release for post-
development are managed with cybersecurity monitoring and
Overall Cybersecurity vulnerability management and, if applicable, incident management.
Management -
[PM-01-01] EXAMPLE: During the development phase an assumption is made that
Cybersecurity Risk a specific cryptographic algorithm is secure, but in the field it is
Management discovered via cybersecurity monitoring that the algorithm is no longer
secure. Vulnerability management and incident response are used to
manage this issue.
A cybersecurity audit shall be performed to independently judge
whether the organizational processes achieve the objectives of this
document.
NOTE 1: Such a cybersecurity audit can be included in, or combined
with, an audit according to a quality management system standard.
EXAMPLE: IATF 16949 in conjunction with ISO 9001
Overall Cybersecurity NOTE 2: Independence can be based on, for example, IATF 16949[16]
Management -
[RQ-05-11] in conjunction with ISO 9001[3], or ISO 26262.
Organizational NOTE 3: The person that performs the audit can be internal or external
Cybersecurity Audit to the organization.
NOTE 4: To ensure the organizational processes remain appropriate for
cybersecurity, 291 an audit can be performed periodically.
NOTE 5: Figure 5 illustrates the organizational cybersecurity audit in
relation to other cybersecurity activities. (see [RQ-06-21])

The organization shall define the circumstances under which sharing is

required, permitted, and prohibited, within and outside of the
organization.
NOTE: This can include:
Overall Cybersecurity
a) a list of the types of cybersecurity information that can be shared;
Management - Information [RQ-05-12]
b) approval process for sharing;
Sharing
c) requirements for redacting and sanitizing information;
d) rules for source attribution; and
e) consultation and types of communications permitted.

The organization shall institute and maintain a quality management

system in accordance with international standards, or equivalent, to
support cybersecurity engineering, including:
a) change management;
NOTE 1: The scope of change management in cybersecurity is to
manage changes in items and their components so that the
applicable cybersecurity goals and requirements continue to be fulfilled.
EXAMPLE 1: Review of the changes in production processes against
the production control plan to prevent such changes from introducing
Overall Cybersecurity new vulnerabilities.
Management - Management [RQ-05-13] b) documentation management;
Systems NOTE 2: A work product can be combined or mapped to different
documentation repositories.
c) configuration management; and
d) requirements management.
EXAMPLE 2: IATF 16949[ in conjunction with ISO 9001; ISO 10007,
Automotive SPICE ®1, the ISO/IEC 33000 series of standards,
ISO/IEC/IEEE 15288, ISO/IEC 12207.

The configuration information regarding the cybersecurity of the

Overall Cybersecurity products in the field shall remain available until the end of their support.
Management - Management [RQ-05-14] EXAMPLE 3: Bill of materials, binaries.
Systems

Overall Cybersecurity A cybersecurity management system for the manufacturing processes

Management - Management [RC-05-01] should be established.
Systems 321 EXAMPLE 4: IEC 62443 2-1, ISO/IEC 27001
Tools that can impact the cybersecurity of an item, system, or
component shall be managed.
EXAMPLE 1: Tools used for concept or product development, such as
model based development, static checkers, verification tools.
EXAMPLE 2: Tools used during production such as a flash writer, end
of line tester.
Overall Cybersecurity EXAMPLE 3: Tools used for maintenance, such as an on-board
Management - Tool [RQ-05-15] diagnostic tool or reprogramming tool.
Management NOTE: Such management can be established by:
- correct usage of the tool based on a user manual including errata;
- protection against unintended usage or action;
- access control for the tool users; or
- authentication of the tool.

An appropriate environment to support remediation actions for the

Overall Cybersecurity cybersecurity incident response (see 13.3) should be reproducible until
Management - Tool [RC-05-02] the end of support for the product.
Management EXAMPLE 4: Testing environment for reproducing the vulnerability.
EXAMPLE 5: Forensic methods.
The relevant information security properties of the work products
Overall Cybersecurity required by the cybersecurity plan should be managed by an
Management - Information [RC-05-03] information security management system.
Security Management EXAMPLE: Work products can be stored on a file server that protects
them from unauthorized alteration or deletion.

Overall Cybersecurity Cybersecurity policy, rules and processes, resulting from the
Management - Work [WP-05-01]requirements of 5.4.1, 5.4.3 and 5.4.5.
Products
Overall Cybersecurity Evidence of competence management, awareness management and
Management - Work [WP-05-02]continuous improvement, resulting from the requirements of 5.4.2.
Products
Overall Cybersecurity Organizational cybersecurity audit report, resulting from the
Management - Work [WP-05-03]requirements of 5.4.4.
Products
Overall Cybersecurity Evidence of the organization's management systems, resulting from the
Management - Work [WP-05-04]requirements of 5.4.6.
Products
Overall Cybersecurity Evidence of tool management, resulting from the requirements of 5.4.7.
Management - Work [WP-05-05]
Products
Project dependent [RQ-06-01] The responsibilities regarding the project’s cybersecurity activities shall
cybersecurity be assigned and communicated in accordance with [RQ-05-03].
management - NOTE: Responsibilities for cybersecurity activities can be transferred
Requirements and providing that this is communicated and there is a handover of pertinent
Recommendations - information.
Cybersecurity
Responsibilities and Their
Assignment
Project dependent [RQ-06-02] An analysis shall be performed to determine:
cybersecurity a) whether the item or component is cybersecurity relevant; and
management - NOTE 1: Annex D provides a method and criteria that can be used to
Requirements and assess the cybersecurity relevance.
Recommendations - b) whether the item or component is a new development or a reuse.
Cybersecurity Planning NOTE 2: If the item or component is reused, a reuse analysis in
accordance with 6.4.4 is performed. A reuse can be applied with or
without modification to the item, component or environment.
NOTE 3: If the item or component is determined as not being
cybersecurity relevant, there are no relevant cybersecurity activities
thus cybersecurity planning is not initiated.

Project dependent [RQ-06-03] The responsibilities for maintaining the cybersecurity plan, and for
cybersecurity management - tracking the progress of the cybersecurity activities against the
Requirements and cybersecurity plan shall be assigned in accordance with [RQ-05-03] and
Recommendations - [RQ-05-04].
Cybersecurity Planning
Project dependent [RQ-06-04] The cybersecurity plan shall either be:
cybersecurity management - a) referenced in the project plan for the development; or
Requirements and b) included in the project plan, such that the cybersecurity activities are
Recommendations - distinguishable.
Cybersecurity Planning
Project dependent [RQ-06-05] The cybersecurity plan shall specify the activities that are required to
cybersecurity management - comply with the requirements of this document associated with the
Requirements and concept phase and product development phases (see Clauses 9, 10,
Recommendations - and 11).
Cybersecurity Planning NOTE 5: The cybersecurity plan can be refined in incremental steps
during development and integration.

Project dependent [RQ-06-06] The cybersecurity plan shall include:

cybersecurity management - a) the objective of an activity;
Requirements and b) the dependencies on other activities or information;
Recommendations - c) the person responsible for performing an activity;
Cybersecurity Planning d) the required resources for performing an activity;
e) the starting point, or end point, and the expected duration; and
f) the identification of the work products.
NOTE 6: The extent of the cybersecurity activities defined in the
cybersecurity plan can be updated (e.g., depending on the results of the
risk determination) (see Clause 8).

Project dependent [RQ-06-07] The cybersecurity plan shall be updated when a change or a refinement
cybersecurity management - of the activities to be performed is identified.
Requirements and
Recommendations -
Cybersecurity Planning
Project dependent [RQ-06-08] The work products required by the cybersecurity plan shall be
cybersecurity management - maintained and updated during the development phases so as to
Requirements and provide an adequate representation of the item or component, until and
Recommendations - at the release for post-development.
Cybersecurity Planning
Project dependent [RQ-06-09] When cybersecurity activities are distributed, both the customer and the
cybersecurity management - supplier shall define a cybersecurity plan regarding their respective
Requirements and cybersecurity activities and interfaces in accordance with Clause 15.
Recommendations -
Cybersecurity Planning
Project dependent [RQ-06-10] The cybersecurity plan, as well as the work products resulting from the
cybersecurity management - cybersecurity activities defined in the cybersecurity plan, shall be
Requirements and subject to configuration management, change management,
Recommendations - requirements management, and documentation management, in
Cybersecurity Planning accordance with 5.4.6.
Project dependent [PM-06-01]A cybersecurity activity may be tailored.
cybersecurity
management -
Requirements and
Recommendations -
Tailoring of the
Cybersecurity Activities

Project dependent [RQ-06-11] If a cybersecurity activity is tailored, then a rationale shall be provided
cybersecurity management - that includes why the tailoring is adequate and sufficient to achieve the
Requirements and relevant objectives of this document.
Recommendations - NOTE 1: An activity is tailored if it is omitted or performed in a different
Tailoring of the manner compared to its description in this document.
Cybersecurity Activities NOTE 2: Activities that are not performed because they are performed
by another entity in the supply chain are not considered as tailored, but
as distributed activities (see Clause 15).

Project dependent [RQ-06-12] A reuse analysis of an existing item or component shall be carried out if
cybersecurity it is reused with or without modification; i.e., if:
management - a) it has been developed, but modifications are planned;
Requirements and b) it is reused in another operational environment; and/or
Recommendations - c) it is planned to be reused without modification and the information
Reuse concerning the item or component has changed relevantly, such as a
change in the known attacks and vulnerabilities, or a change of the
assets.
EXAMPLE 1: Modifications to the environment resulting from the
installation of the existing item or component in a new operational
environment, or from the upgrading of other items or components
interacting with it.
NOTE 1: Modifications can include design modifications and/or
implementation modifications:
- Design modifications can result from requirements modification (e.g.,
functional or performance enhancement).
- Implementation modifications can result from corrections of software,
or the use of new production or maintenance tools (e.g., model based
development). These modifications might not affect the specification or
performance of the existing item or component, but only the
implementation features.
NOTE 2: A modification to configuration data or calibration data is
considered as a modification if it impacts the functional behavior or the
assets and cybersecurity properties of the existing item or component.
Project dependent [RQ-06-13] The reuse analysis of an existing item or component shall:
cybersecurity management - a) identify the modifications to the operational context, including the
Requirements and modifications to the item or component as well as modifications of its
Recommendations - Reuse environment;
b) analyze the implication of the modifications regarding cybersecurity,
including the impact on the validity of cybersecurity claims and
previously made assumptions;
c) identify the affected or missing work products and determine the
activities necessary to comply with this document; and
NOTE 3: This includes an analysis of the existing threat analysis and
risk assessment; e.g., considering new assets, threat scenarios or risk
determination compared to when the existing item or component was
developed.
d) specify the cybersecurity activities in the cybersecurity plan, based
on this reuse analysis, in accordance with 6.4.2.
EXAMPLE 2: A modification can have one or more implications on:
- the cybersecurity requirements;
- the design and implementation;
- operational environments and operating modes;
- maintenance;
- cybersecurity controls;
- susceptibility to known attacks and exposure of known vulnerabilities;
or
- the assets.

Project dependent [RQ-06-14] The reuse analysis 494 of an existing component shall:
cybersecurity management - a) evaluate whether, with or without modifications, the reused
Requirements and component is able to comply with the allocated cybersecurity
Recommendations - Reuse requirements that result from the item, or component, in which it is to be
integrated; and
b) evaluate whether the existing documentation is sufficient to support
the integration into an item, or into another component.

Project dependent [RQ-06-15] If cybersecurity activities are tailored in accordance with 6.4.2 because
cybersecurity a component is developed out of context, then:
management - a) assumptions on the new intended use and context, including the
Requirements and external interfaces, shall be documented in the corresponding work
Recommendations - products;
Component Out of Context b) the out of context development shall be based on cybersecurity
requirements that are derived from the assumptions; and
c) for the out of context component integration, the cybersecurity
claims and assumptions of the out of context development shall be
validated.

Project dependent [RQ-06-16] When integrating an off-the-shelf component in accordance with 6.4.6,
cybersecurity the cybersecurity-relevant information shall be gathered and analyzed
management - to determine whether:
Requirements and a) the allocated cybersecurity requirements can be complied with;
Recommendations - Off- b) the off-the-shelf component is suitable for the specific application
the-Shelf Component context of the intended use; and
c) the existing off-the-shelf documentation is sufficient to support the
cybersecurity activities.
NOTE: The integration and test activities are documented in the work
products related to integration and testing.
Project dependent [RQ-06-17] If the existing documentation is insufficient to support the integration of
cybersecurity management - the off-the-shelf component, then the cybersecurity activities to comply
Requirements and with this document shall be identified and performed.
Recommendations - Off-the-
Shelf Component
Project dependent [RQ-06-18] A cybersecurity case shall be created to provide the argument,
cybersecurity supported by work products, for the achieved degree of cybersecurity.
management - NOTE: The argument can be implicit (i.e., if the argument is evident
Requirements and from the compiled set of work products an explicit argument can be
Recommendations - omitted). In this scenario, the cybersecurity case contains the list of
Cybersecurity Case work products required by the cybersecurity plan (see [WP-06-01]).

Project dependent [RQ-06-19] A judgement based on a rationale shall be made to decide whether a
cybersecurity cybersecurity assessment is performed for an item or component.
management - NOTE 1: The judgement of whether to perform a cybersecurity
Requirements and assessment or not can be based on the results of the risk determination
Recommendations - in accordance with Clause 8, supported by a rationale.
Cybersecurity
Assessment

Project dependent [RQ-06-20] The rationale of [RQ-06-19] shall be independently reviewed.

cybersecurity management - NOTE 2: The corresponding independence scheme regarding the
Requirements and review of the rationale can be based on IATF 16949 in conjunction with
Recommendations - ISO 9001, or ISO 26262.
Cybersecurity
Assessment

Project dependent [RQ-06-21] The cybersecurity assessment shall judge whether the available
cybersecurity management - evidence provides confidence that the achieved degree of cybersecurity
Requirements and of the item or component is sufficient.
Recommendations - NOTE 3: The available evidence is provided by the documented results
Cybersecurity of the cybersecurity activities (i.e., the work products) (see Annex A).
Assessment

Project dependent [RQ-06-21] NOTE 4: The cybersecurity assessment can be performed in

cybersecurity management - incremental steps to facilitate an early resolution of identified issues.
Requirements and NOTE 5: The assessment can be repeated or supplemented; e.g., due
Recommendations - to a change, when the previous assessment provided a negative
Cybersecurity recommendation, or when a vulnerability is discovered.
Assessment

Project dependent [RQ-06-22] The cybersecurity assessment report shall be made available prior to
cybersecurity management - the release for post-development.
Requirements and NOTE 6: The scope of the cybersecurity assessment report at the
Recommendations - release for post-development can include the performed cybersecurity
Cybersecurity activities and the cybersecurity requirements for post-development (see
Assessment [WP-10-02]).

Project dependent [RQ-06-23] The person responsible to plan and independently perform the
cybersecurity management - cybersecurity assessment shall be appointed in accordance with [RQ-
Requirements and 05-08] and [RQ-06-01], supported by [RQ-05-03] and [RQ-05-04].
Recommendations - NOTE 7: The independence scheme can be based on IATF 16949[16]
Cybersecurity in conjunction with ISO 9001[3], or ISO 26262[1].
Assessment EXAMPLE: A person of a quality assurance department within the
organization, a person from a different team or department, or a person
from an independent third party.
Project dependent [RQ-06-24] A person who carries out a cybersecurity assessment shall have access
cybersecurity management - to the relevant information, tools and the cooperation of the personnel
Requirements and responsible for performing the cybersecurity activities.
Recommendations -
Cybersecurity
Assessment

Project dependent [PM-06-02] A cybersecurity assessment may be based on a judgement of whether

cybersecurity management - the project 555 related objectives of this document are achieved.
Requirements and
Recommendations -
Cybersecurity
Assessment

Project dependent [RQ-06-25] The scope of a cybersecurity assessment shall include:

cybersecurity management - a) the cybersecurity plan and all work products required by the
Requirements and cybersecurity plan;
Recommendations - NOTE 8: The activities and work products are summarized in Annex A.
Cybersecurity b) the appropriateness and effectiveness of the implemented or
Assessment performed cybersecurity technical or process controls;
NOTE 9: The appropriateness and effectiveness can be judged by
using prior reviews that were performed for verification purposes.
c) the rationales, if provided, that demonstrate the achievement of the
relevant objectives of this document;
NOTE 10: The person(s) responsible for the creation of a work product
can provide a rationale as to why the objectives of this document are
achieved in order to facilitate a cybersecurity assessment, considering
[PM-06-02].
NOTE 11: Compliance with all the corresponding requirements is a
sufficient rationale for having achieved an objective of this document.
d) the rationales for the treatment of the cybersecurity risks, in
accordance with 8.9; and
e) the cybersecurity requirements for post-development (see [WP-10-
02]).

Project dependent [RQ-06-26] A cybersecurity assessment report shall include a recommendation for
cybersecurity management - acceptance, conditional acceptance, or rejection of the achieved degree
Requirements and of cybersecurity of the item or component.
Recommendations - NOTE 12: The assessment report can also include recommendations
Cybersecurity for improvement.
Assessment

Project dependent [PM-06-03] A cybersecurity assessment report may include a recommendation for
cybersecurity management - conditional acceptance.
Requirements and
Recommendations -
Cybersecurity
Assessment

Project dependent [RQ-06-27] If a recommendation for conditional acceptance in accordance with

cybersecurity management - [PM-06-03] is made, then the cybersecurity assessment report shall
Requirements and include the conditions for acceptance.
Recommendations -
Cybersecurity
Assessment
Project dependent [RQ-06-28] The following work products shall be available prior to the release for
cybersecurity post-development:
management - - the cybersecurity case in accordance with 6.4.7;
Requirements and - if applicable, the cybersecurity assessment report in accordance with
Recommendations - 6.4.8; and
Release for Post- - the cybersecurity requirements for post-development (see [WP-10-
Development 02].)

Project dependent [RQ-06-29] The release for post-development of the item or component shall be
cybersecurity management - approved if both of the following conditions are fulfilled:
Requirements and a) sufficient evidence of the achieved degree of cybersecurity is
Recommendations - provided by the cybersecurity case; and if applicable the judgement
Release for Post- included in the cybersecurity assessment report; and
Development b) the cybersecurity requirements for the post-development phase are
identified and reviewed.
NOTE: Changes to the cybersecurity claims (see [WP-09-05]) can
result in repeating the release for post-development.

Project dependent [WP-06-01]Cybersecurity plan, resulting from the requirements of 6.4.1 to 6.4.6.
cybersecurity
management - Work
Products
Project dependent [WP-06-02]Cybersecurity case, resulting from the requirements of 6.4.7.
cybersecurity management -
Work Products
Project dependent [WP-06-03]Cybersecurity assessment report, if applicable, resulting from the
cybersecurity management - requirements of 6.4.8.
Work Products
Project dependent [WP-06-04]Release for post-development report, resulting from the requirements of
cybersecurity management - 6.4.9.
Work Products
Continuous Cybersecurity [RQ-07-01] Internal and external sources shall be monitored for collection of
Activities - Cybersecurity cybersecurity information.
Monitoring EXAMPLE 1: External sources for cybersecurity information can
include:
- researchers;
- commercial or non-commercial sources;
- organization’s supply chain;
- customers of the organization; and/or
- government sources.
EXAMPLE 2: Internal sources for cybersecurity information can include:
- results of vulnerability analyses;
- information received from the field (e.g., vulnerability scanning
reports, repair information, consumer usage information); and/or
- configuration information such as a hardware or software bill of
materials.
Continuous Cybersecurity [RQ-07-02] Triage shall be based on defined triggers and applied to cybersecurity
Activities - Cybersecurity information to determine if cybersecurity information becomes one or
Monitoring more cybersecurity events.
EXAMPLE 3: Criteria for the triage that can be used to define the trigger
thresholds can include:
- whether cybersecurity information comes from a known trusted
source;
- the determined risk of the threat scenarios of the item resulting from
the activity in [RQ-09-05]; and/or
- the type of information obtained (e.g., an active attack or proof of
concept).

Continuous Cybersecurity [WP-07-01]List of sources for cybersecurity monitoring, resulting from [RQ-07-01].
Activities - Cybersecurity
Monitoring - Work
Products
Continuous Cybersecurity [WP-07-02]Results from the triage of cybersecurity information, resulting from [RQ-
Activities - Cybersecurity 07-02].
Monitoring - Work Products

Continuous Cybersecurity [RQ-07-03] A cybersecurity event shall be analyzed to determine if the

Activities - Cybersecurity cybersecurity event affects an item or component based on a
Event Assessment vulnerability analysis in accordance with 7.5.
NOTE 1: If the cybersecurity event assessment determines that the
item or component is unaffected by the cybersecurity event, the
organization can decide to cease further activities.
NOTE 2: A cybersecurity vulnerability identified as a result of [RQ-07-
03] is handled in accordance with 7.6.

Continuous Cybersecurity [PM-07-01] Based on the risk treatment decision from 8.9, the cybersecurity
Activities - Cybersecurity incident response process in accordance with 13.3 may be applied in
Event Assessment post-development phases.
NOTE 3: The organization can define the criteria for invoking incident
response.
EXAMPLE: Risk treatment from 7.6 affects items or components in
post-development phases.
NOTE 4: If the cybersecurity incident response process is applied, then
the cybersecurity event becomes a cybersecurity incident.

Continuous Cybersecurity [WP-07-03]The cybersecurity event assessment, resulting from [RQ-07-03].

Activities - Cybersecurity
Event Assessment - Work
Products
Continuous Cybersecurity [RQ-07-04] Weaknesses and/or cybersecurity events shall be analyzed to identify
Activities - Vulnerability vulnerabilities.
Analysis NOTE 1: Weaknesses can be inherent to the item or component or
caused by human mistakes or errors during concept or development.
EXAMPLE: Weaknesses include:
- missing requirements or specifications;
- architectural or design weaknesses, including incorrect design of
security protocols;
- implementation weaknesses, including hardware and software bugs,
incorrect implementation of security protocols;
- weaknesses in the operational processes and procedures, including
misuse and inadequate user-training; and/or
- use of outdated or deprecated functions, including cryptographic
algorithms.
NOTE 2: Relevance of the weakness for the item can be assessed
through an analysis of the architecture or invocation of attack path
analysis.
NOTE 3: A root cause analysis can be performed to determine the
underlying causes of vulnerability, including possible methods of
exploitation as it relates to the instance of the cybersecurity event.

Continuous Cybersecurity [RC-07-01] Attack paths should be analyzed in accordance with 8.6 to map the
Activities - Vulnerability discovered vulnerabilities to specific attack paths.
Analysis - Requirements
and Recommendations
Continuous Cybersecurity [RC-07-02] Attack feasibility rating in accordance with 0 should be determined for
Activities - Vulnerability the discovered vulnerabilities.
Analysis - Requirements
and Recommendations
Continuous Cybersecurity [WP-07-04]Vulnerability analysis, resulting from [RQ-07-04].
Activities - Vulnerability
Analysis - Work Products

Continuous Cybersecurity [RQ-07-05] Identified vulnerabilities shall be managed based on a rationale such
Activities - Vulnerability that the corresponding risk is treated.
Management - EXAMPLE: Rationales can include arguments such as the following:
Requirements and - verification report that shows the vulnerability is eliminated;
Recommendations - analysis, risk determination and risk treatment of the vulnerability.

Continuous Cybersecurity [RQ-07-06] The risk treatment shall be based on:

Activities - Vulnerability a) the results of a vulnerability analysis in accordance with [WP-07-04];
Management - and
Requirements and b) the results of the risk determination in accordance with 8.8.
Recommendations NOTE 1: An organization can consider several factors in determining
the treatment, such as impact rating (see 8.5) or attack feasibility rating
(see 0).
Continuous Cybersecurity [RQ-07-07] Risk treatment for vulnerabilities shall be performed in accordance 718
Activities - Vulnerability with 8.9, and Clauses 9 and 10.
Management - NOTE 2: Risk acceptance is a possible risk treatment. In this case, the
Requirements and rationale for acceptance is documented.
Recommendations NOTE 3: If the risk treatment results in a change to an item or
component, change management is applied in accordance with [RQ-05-
13].
NOTE 4: Information about identified vulnerabilities can be shared in
accordance with 5.4.5.

Continuous Cybersecurity [RQ-07-08] If cybersecurity information becomes available that invalidates the
Activities - Vulnerability existing rationale, the vulnerability shall no longer be considered as
Management - managed.
Requirements and
Recommendations
Continuous Cybersecurity [WP-07-05]Rationale for the managed vulnerability, resulting from [RQ-07-05].
Activities - Vulnerability
Management - Work
Products

Risk Assessment Methods [RQ-08-01]Damage scenarios shall be identified.

- Asset Identification

Risk Assessment Methods - [RQ-08-02] Assets with cybersecurity properties whose compromise leads to a
Asset Identification damage scenario shall be enumerated.
NOTE: The enumeration of relevant assets can be based on various
methods, including:
- performing an impact rating;
- deriving assets from threat scenarios; and
- using predefined catalogues.
EXAMPLE 1: The asset is personal information (customer personal
preferences) stored in an infotainment system and its cybersecurity
property is confidentiality. The damage scenario is disclosure of the
personal information without the customer’s consent resulting from the
loss of confidentiality.
EXAMPLE 2: The asset is messages received by the braking function
and its cybersecurity property is integrity. The damage scenario is
unintended full braking when the vehicle is travelling at high speed
resulting from the loss of integrity.

Risk Assessment Methods [WP-08-01]Damage scenarios, resulting from [RQ-08-01].

- Asset Identification -
Work Products

Risk Assessment Methods - [WP-08-02]Identified assets and cybersecurity properties, resulting from [RQ-08-
Asset Identification - Work 02].
Products
Risk Assessment Methods [RQ-08-03] Threat scenarios shall be identified.
- Threat Scenario NOTE 1: See Annex G for an illustration with a practical example.
Identification NOTE 2: The method for threat scenario identification can use
brainstorming-based approaches.
EXAMPLE 1:
- misuse-case elicitation;
- taxonomy mnemonic-based approaches (e.g., STRIDE); or
- a combination of the above.
NOTE 3: A threat scenario can include:
- the targeted asset;
- the compromised cybersecurity property; and
- the action to accomplish a damage scenario.
EXAMPLE 2: Spoofing of CAN (controller area network) messages for
the powertrain ECU (electronic control unit) leads to loss of integrity of
the CAN messages (and thereby to loss of integrity of the acceleration
function) potentially causing uncontrollable acceleration of the vehicle
and possible harm.
NOTE 4: Relations and dependencies between assets can be relevant
in the identification of threat scenarios.
NOTE 5: If more information about a threat scenario is available, such
as the threat agent who initiates action, the method, tools, and entry
points, it can be documented to provide further information to the risk
assessment process (e.g., attack path analysis, attack feasibility).
NOTE 6: One damage scenario can correspond to multiple t 828 hreat
scenarios (see Figure 6).

Risk Assessment Methods[WP-08-03] Threat scenarios, resulting from [RQ-08-03].

- Threat Scenario
Identification - Work
Products
Risk Assessment Methods - The following information can be considered:
Impact Rating - Inputs - - item definition (see [WP-09-01]); and
Further Supporting - identified assets and cybersecurity properties (see [WP-08-01]).
Information
Risk Assessment Methods [RQ-08-04] The damage scenarios shall be assessed against potential adverse
- Impact Rating - consequences for stakeholders in the independent impact categories of
Requirements and safety, financial, operational, and privacy (S, F, O, P).
Recommendations
Risk Assessment Methods - [RQ-08-05] If further impact categories are considered beyond S, F, O and P, then
Impact Rating - those categories shall be documented.
Requirements and NOTE 1: S, F, O, P are the core impact categories that are used to rate
Recommendations the impact on road users. This document makes provision for the
extension of the core categories with additional categories that could
help assess the impact on other stakeholders, for example the business
or the performing organization. Example categories are loss of
intellectual property, financial losses to business, loss of brand image or
reputation.
NOTE 2: If distributed development in accordance with Clause 15 is
used, then the rationale and explanation of these parameters can be
forwarded in the supply chain.
Risk Assessment Methods - [RQ-08-06] The impact rating of the damage scenario shall 854 be determined to
Impact Rating - be one of the following:
Requirements and - Severe;
Recommendations - Major;
- Moderate; or
- Negligible.
NOTE 3: Financial, operational and privacy related impacts can be
rated in accordance with tables given in Annex H.

Risk Assessment Methods - [RQ-08-07] Safety related impacts shall be derived from ISO 26262-3:2018, 6.4.3
Impact Rating - Classification of hazardous events.
Requirements and NOTE 4: Table H.1 in Annex H can be used for mapping safety
Recommendations impacts.
Risk Assessment Methods [WP-08-04]Impact rating, including the associated impact categories of the damage
- Impact Rating - Work scenarios, resulting from [RQ-08-04] to [RQ-08-07].
Products
Risk Assessment Methods [RQ-08-08] The threat scenarios shall be analyzed to describe possible attack
- Attack Path Analysis - paths.
Requirements and
Recommendations
Risk Assessment Methods - [RQ-08-09] The attack path analysis approach applied shall be documented.
Attack Path Analysis - NOTE 1: An attack path analysis approach can be based on (see
Requirements and Figure 7):
Recommendations a) Top-down approaches such as attack trees, attack graphs,
taxonomy mnemonic-based approaches (e.g., STRIDE):
i. In top-down (deductive) approach, attack paths are deduced (i.e.,
theorized, inferred, reasoned, conjectured) for the item or component
based on historical knowledge of vulnerabilities in similar systems and
components.
ii. Top-down approach is useful in the concept and development
phases when implementation of the current item or component is not
available, or when effort is directed toward building attack hypotheses
or attack path models.
b) Bottom-up approaches (e.g., the output of vulnerability 888
analysis):
i. In a bottom-up (inductive) approach, attack paths are built for the
item or component from the cybersecurity vulnerabilities identified. Each
action in the attack path is based on an “exploitable weakness.”
ii. The bottom-up approach is most commonly used when an
implementation of the item or component is available, or when
hypotheses or attack model are to be confirmed.
c) A combination of these approaches.

Risk Assessment Methods - [RQ-08-09] NOTE 2: If attack path analysis reveals that a partial attack path does
Attack Path Analysis - not accomplish the threat scenario, this partial attack path can be
Requirements and truncated, and the analysis can be stopped at that point.
Recommendations
Risk Assessment Methods - [RC-08-01] The attack path description should include a reference to the threat
Attack Path Analysis - scenarios that can be realized by the attack path.
Requirements and NOTE 3: If a bottom-up approach is used, the following information can
Recommendations be included:
a) vulnerabilities or weaknesses that could be exploited; and
b) how the vulnerabilities could be leveraged in an attack to realize the
threat scenario.
NOTE 4: In the early stages of product development the attack paths
are often incomplete or imprecise as specific implementation details are
not yet known in sufficient detail to be able to identify specific
vulnerabilities. During the lifecycle, the attack paths could be updated
with additional detail as more information becomes available (e.g., after
a vulnerability analysis).
EXAMPLE:
- Threat Scenario: Spoofing of CAN (Controller Area Network)
messages for the braking ECU (Electronic Control Unit), causing
uncontrollable arbitrary braking of the vehicle leading to loss of
passenger safety causing physical harm to the vehicle user.
- Attack Path: The telematics ECU is compromised via the cellular
interface, then Gateway ECU is compromised via CAN communication,
next the gateway ECU forwards malicious torque request signals,
resulting in spoofing of acceleration torque requests.

Risk Assessment Methods [WP-08-05]Identified attack paths, resulting from [RQ-08-08] and [RC-08-01].
- Attack Path Analysis -
Work Products
Risk Assessment Methods [RQ-08-10] For each attack path the attack feasibility rating shall be determined as
- Attack Feasibility Rating one of the following:
- Requirements and - high;
Recommendations - medium;
- low; or
- very low.
NOTE 1: Annex I provides guidelines on determining attack feasibility
rating. [RC-08-02] The defined rating method should be based on one
of the following assessment approaches:
a) attack potential-based approach;
b) CVSS2 based approach; or
c) attack vector-based approach.
NOTE 2: Selection of the rating approach can depend upon the phase
in the lifecycle and available information.

Risk Assessment Methods - [RC-08-03] If an attack potential-based approach is used, it should be determined
Attack Feasibility Rating - based on core factors including elapsed time, specialist expertise,
Requirements and knowledge of the item or component, window of opportunity, and
Recommendations equipment.
NOTE 3: The core attack potential factors can be derived from ISO/IEC
18045[8].
NOTE 4: I.3 provides guidelines on determining attack feasibility based
on attack potential.

Risk Assessment Methods - [RC-08-04] If a CVSS based approach is used, it should be determined based on
Attack Feasibility Rating - the exploit metrics group of the base metrics, including attack vector,
Requirements and attack complexity, privileges required, and user interaction.
Recommendations NOTE 5: I.4 provides guidelines on determining attack feasibility based
on a CVSS based approach.
Risk Assessment Methods - [RC-08-05] If an attack vector based approach is used, it should evaluate the
Attack Feasibility Rating - predominant attack vector (cf. CVSS) of the attack path.
Requirements and NOTE 6: I.5 provides guidelines on determining attack feasibility based
Recommendations 948 on an attack vector based approach.
NOTE 7: Attack feasibility can be estimated qualitatively using an attack
vector based approach during the early stages of product development,
when there is insufficient detailed information to identify specific attack
paths.

Risk Assessment Methods [WP-08-06]Attack feasibility rating, resulting from [RQ-08-10].

- Attack Feasibility Rating
- Work Products

Risk Assessment Methods [RQ-08-11] The risk value of a threat scenario shall be determined from the impact
- Risk Determination - of the associated damage scenario and the attack feasibility of the
Requirements and associated attack paths.
Recommendations NOTE 1: The value 1 is the lowest risk and value 5 is the highest risk,
see Annex J.
NOTE 2: If the threat scenario corresponds to more than one attack
path, the associated attack feasibility levels can be appropriately
aggregated (e.g., the threat scenario is assigned the maximum of the
feasibility levels of the corresponding attack paths).

Risk Assessment Methods [WP-08-07]Risk value, resulting from [RQ-08-11].

- Risk Determination -
Work Products

Risk Assessment Methods [RQ-08-12] A risk treatment option shall be determined, considering impact
- Risk Treatment Decision categories, attack paths and the results from risk determination.
- Requirements and NOTE 1: Options for treating risk can involve:
Recommendations a) avoiding the risk by removing the risk sources, or deciding not to
start or continue with the activity that gives rise to the risk;
b) reducing the risk;
c) sharing or transferring the risk (e.g., through contracts, buying
insurance); and/or
d) accepting or retaining the risk.
NOTE 2: Risk treatment options are not mutually exclusive or
appropriate in all circumstances.

Risk Assessment Methods - [PM-08-01] For threat scenarios of risk value 1, determined from an analysis in
Risk Treatment Decision - accordance with 8.8, compliance with 9.5, and with Clauses 10 and 11
Requirements and of this document may be omitted.
Recommendations NOTE 3: These threat scenarios can have consequences with regards
to cybersecurity and if so, the corresponding risks are treated, albeit
potentially with less rigor than defined in this document.
NOTE 4: The sufficiency of the treatment of such risks can be argued
based on a rationale defined in the cybersecurity case, for example
assurance based on compliance with a quality management standard,
such as IATF 16949 in conjunction with ISO 9001, in combination with
additional measures, such as cybersecurity awareness assurance and
cybersecurity training of quality personnel and the existence of
cybersecurity specific aspects or measures defined in the corporate
quality management system.
NOTE 5: For risk acceptance and risk transfer, the corresponding
rationales are recorded as cybersecurity
Risk Assessment Methods [WP-08-08]Risk treatment decision per threat scenario, resulting from [RQ-08-12].
- Risk Treatment Decision
- Work Products

Concept Phase - Item [RQ-09-01] The following information on the item shall be identified:
Definition - Requirements a) item boundary;
and Recommendations NOTE 1: The item boundary distinguishes the item from its
environment. The description of the item boundary can include
interfaces with other item and components internal and/or external to
the vehicle.
b) function; and
NOTE 2: The description of the item function can include the intended
behavior independent from implementation and architecture. The
function of the item includes the operational vehicle functionality that is
realized by the item, and all other functions that are intended during the
lifecycle phases of the item, such as: product development (testing),
production, operations and maintenance, and decommissioning.
c) preliminary architecture.
NOTE 3: The description of preliminary architecture can include:
- internal components and their connections in the item;
- data flow with other objects outside of the item;
- physical aspects; and
- logical aspects.

Concept Phase - Item RQ-09-02] The relevant information about the operational environment of the item
Definition - Requirements with 1054 regard to cybersecurity shall be described.
and Recommendations NOTE 4: The description of the operational environment of the item can
include the aspects that allow the identification and analysis of relevant
threat scenarios and attack paths.
NOTE 5: The item definition and in particular the item boundary for the
processes as described in this document can differ from the scope and
item boundary of the item definition from another process such as
functional safety in accordance with ISO 26262[1].

Concept Phase - Item [RQ-09-03] Constraints and compliance needs shall be identified.
Definition - Requirements EXAMPLE 1: This can include:
and Recommendations - functional constraints;
- technical constraints; and/or
- standards.
Concept Phase - Item [RQ-09-04] Assumptions about the item and the operational environment of the
Definition - Requirements item shall be identified.
and Recommendations NOTE 6: Some attacks might not be feasible under the assumptions on
the operational environment.
NOTE 7: If the item is being reused after its development was
completed, the assumptions of [RQ-09-04] for the original item are
validated with respect to the operational environment for the re-use (see
6.4.4).
NOTE 8: Development of a component out of context can include a
definition of an assumed (generic) item and description of the functions
of the component within the item.
EXAMPLE 2: Assumptions on physical aspects can include:
- the item will be placed in an anti-tamper enclosure.
EXAMPLE 3: Assumptions on connectivity aspects can include:
- every PKI certificate authority that the item relies on are appropriately
managed.

Concept Phase - Item [WP-09-01]Item definition, resulting from [RQ-09-01] to [RQ-09-04].

Definition - Work Products

Concept Phase - [RQ-09-05] In order to identify cybersecurity goals, an analysis of the item shall be
Cybersecurity Goals - performed that involves:
Requirements and a) asset identification in accordance with 8.3;
Recommendations NOTE 1: The list of assets with cybersecurity properties (as part of the
result of asset identification) can be consolidated for easier reference by
the cybersecurity requirements.
b) threat scenario identification in accordance with 8.4;
c) impact rating in accordance with 8.5;
d) attack path analysis in accordance with 8.6;
NOTE 2: In the concept phase information about potential attacks can
vary in granularity and depth, from an abstract classification in terms of
remote, adjacent, local, and/or physical attacks (i.e., the attack vector
according to CVSS) to a detailed description of distinct attack actions
(e.g., an attack path). This can lead to a corresponding level of
granularity for the subsequent risk determination and for the potential
cybersecurity goals.
NOTE 3: Assumptions considering the attack path analysis enable the
exclusion of attack paths that are infeasible and clarify the rationale for
the determined attack feasibility. If the assumptions are later shown to
be is false, the excluded attack paths are retroactively identified and
analyzed.
NOTE 4: To estimate attack feasibility in the concept phase, the attack
feasibility rating method described in I.5 can be used.
e) attack feasibility rating in accordance with 0; and
f) risk determination in accordance with 8.8.

Concept Phase - [RQ-09-06] For the identified threat scenarios and their associated risks, a risk
Cybersecurity Goals - treatment decision shall be performed in accordance with 8.9.
Requirements and NOTE 5: A risk can be reduced by a cybersecurity requirement
Recommendations allocated to the item or to the operational environment of the item.
NOTE 6: If the risk is addressed by assumptions on the operational
environment, the cybersecurity claim explains why this is adequate.
NOTE 7: Avoiding a risk by removing the risk source means changing
Concept Phase - [RQ-09-07] If the risk treatment decision for a threat scenario involves reducing the
Cybersecurity Goals - risk, then one or more corresponding cybersecurity goals shall be
Requirements and specified.
Recommendations NOTE 8: The statement of the cybersecurity goal can include the
protection of cybersecurity properties of assets whose compromise can
lead to the associated damage scenario.
NOTE 9: If applicable, a CAL can be derived for cybersecurity goals
(see Annex E).
NOTE 10: Cybersecurity goals can be defined for operations and
maintenance, and decommissioning. This includes the cybersecurity
implications of service and repair in the design and development of their
products.
NOTE 11: Cybersecurity goals can be combined.

Concept Phase - [RQ-09-08] Cybersecurity claims shall 1123 be stated for the following cases:
Cybersecurity Goals - a) an assumption on the operational environment leads to a reduction
Requirements and of the risk of a threat scenario so that the risk becomes acceptable; or
Recommendations b) the risk treatment involves sharing or transferring the risk.
NOTE 12: Cybersecurity claims are subject to monitoring.

Concept Phase - [RQ-09-09] The activities to specify cybersecurity goals and cybersecurity claims
Cybersecurity Goals - shall be verified to:
Requirements and a) confirm consistency of the analysis of [RQ-09-05];
Recommendations b) confirm consistency of the risk treatment decisions [RQ-09-06];
c) confirm consistency and completeness of the cybersecurity goals of
[RQ-09-07] with respect to the threat scenarios; and
d) consistency between different cybersecurity goals.

Concept Phase - [WP-09-02]Threat analysis and risk assessment, resulting from [RQ-09-05].
Cybersecurity Goals -
Work Products
Concept Phase - [WP-09-03]Risk treatment decisions, resulting from [RQ-09-06].
Cybersecurity Goals - Work
Products
Concept Phase - [WP-09-04]Cybersecurity goals, resulting from [RQ-09-07].
Cybersecurity Goals - Work
Products
Concept Phase - [WP-09-05]Cybersecurity claims, resulting from [RQ-09-08].
Cybersecurity Goals - Work
Products
Concept Phase - [WP-09-06]Verification report, resulting from [RQ-09-09].
Cybersecurity Goals - Work
Products
Concept Phase - [RQ-09-10] Cybersecurity requirements shall be specified for the cybersecurity
Cybersecurity Concept - goals, including a rationale for the achievement of the cybersecurity
Requirements and goals.
Recommendations NOTE 1: Cybersecurity requirements can specify which threat
scenarios are controlled.
NOTE 2: If available, additional information about potential attack paths
that can lead to a violation of the cybersecurity goals, can be
considered for the derivation of the cybersecurity requirements.
NOTE 3: The type of asset protection can be specified as an
intermediate step, which supports traceability between cybersecurity
goals and cybersecurity requirements and can identify and resolve
potential conflicts.
EXAMPLE 1: Types of asset protection include combinations of:
- prevention, reduction, detection, correction, or monitoring of losses or
compromise; and/or
- restoring or recovery from damage.
NOTE 4: The cybersecurity requirements can depend on or include
update capabilities of the item.

Concept Phase - [RQ-09-11] The cybersecurity requirements shall be allocated to one or more
Cybersecurity Concept - components of the item or to the operational environment.
Requirements and
Recommendations
Concept Phase - [RQ-09-12] The cybersecurity requirements and their allocation shall be verified to
Cybersecurity Concept - confirm:
Requirements and a) consistency with the cybersecurity goals;
Recommendations b) completeness with respect to the cybersecurity goals; and
c) consistency and compatibility with the functionality of the item.
EXAMPLE 2: A potential compatibility issue can be: performance of the
item affected by cybersecurity requirements.
NOTE 5: If applicable, conformance with the cybersecurity goals
includes effectiveness of the mitigation or capabilities for handling of
cyber security events (e.g., over the air update).

Concept Phase - [WP-09-07]Cybersecurity concept, resulting from [RQ-09-10] and [RQ-09-11].

Cybersecurity Concept -
Work Products
Concept Phase - [WP-09-08]Verification report of cybersecurity concept, resulting from [RQ-09-12].
Cybersecurity Concept -
Work Products
Product Development - [RC-10-01] Cybersecurity controls should be selected based on the cybersecurity
Requirements and requirements allocated from higher level and on the architectural design
Recommendations - from higher level.
Refinement of EXAMPLE 1: For system or hardware development: use of a separate
Cybersecurity microcontroller with an embedded hardware trust anchor for secure key
Requirements and store functionalities, and isolation of the trust anchor regarding non-
Architectural Design secure external connections.
EXAMPLE 2: Use of catalogues and standard solutions that are
traceable to national, international or industry standards.
NOTE 1: Cybersecurity controls are effective if their implementation
achieves or supports the fulfilment of the cybersecurity requirements
from higher level allocated to the component under development.
Product Development - [RQ-10-01] Cybersecurity requirements shall be refined based on:
Requirements and a) cybersecurity requirements allocated from higher level;
Recommendations - NOTE 2: This can include cybersecurity requirements allocated to the
Refinement of component under development and cybersecurity requirements
Cybersecurity allocated to its operational environment.
Requirements and b) architectural design from higher level; and
Architectural Design c) cybersecurity controls from [RC-10-01], if applicable.
NOTE 3: This can include the cybersecurity requirements refined
according to the refined 1281 architectural design of [RQ-10-02].
NOTE 4: In order to ensure proper functioning of a cybersecurity
control, additional requirements can be provided with regard to secure
and appropriate use of the cybersecurity controls.
EXAMPLE 3: Anomaly detection with respect to the functioning of the
cybersecurity control.
EXAMPLE 4: A system with secure event logging mechanism imposes
implementation of a secure communication with external systems for
log data collection.
NOTE 5: Technical realizations for cybersecurity requirements from
higher level imposed from external sources can also be included in the
refined cybersecurity requirements.

Product Development - [RQ-10-02] Architectural design shall be refined for the development level based
Requirements and on:
Recommendations - a) the initial architectural design, if applicable;
Refinement of b) the cybersecurity controls from [RC-10-01], if applicable;
Cybersecurity c) the refined cybersecurity requirements;
Requirements and d) the higher level architectural design; and
Architectural Design e) the operational environment.
EXAMPLE 5: Interface specifications between hardware and software.
NOTE 6: The architectural design can include the static design aspects
and the dynamic design aspects.
NOTE 7: Information for correct integration and initialization of
cybersecurity controls can be included in the architectural design.

Product Development - [RC-10-02] The refined architectural design should apply architectural design
Requirements and principles to avoid or minimize the introduction of weaknesses.
Recommendations - NOTE 8: Examples of design principles for architectural design for
Refinement of cybersecurity are given in NIST SP 800-1600, appendix F.1.
Cybersecurity NOTE 9: Design principles can be achieved by applying and enforcing
Requirements and design and modelling guidelines.
Architectural Design

Product Development - [RQ-10-03] The refined cybersecurity requirements shall be allocated to

Requirements and components of the refined architectural design.
Recommendations -
Refinement of
Cybersecurity
Requirements and
Architectural Design
Product Development - [RQ-10-04] Interfaces between components of the refined architectural design
Requirements and related to the fulfillment of the refined cybersecurity requirements shall
Recommendations - be identified and described, and include the following:
Refinement of a) purposes and usage; and
Cybersecurity b) parameters.
Requirements and NOTE 10: Parameters are explicit inputs to and outputs from an
Architectural Design interface that controls the behavior of interfaced component.
EXAMPLE 6: Allowed range of data in the interface.
EXAMPLE 7: The interface between hardware and software is defined
or refined in order to allow for the correct usage of cybersecurity control.
NOTE 11: Interfaces are a potential entry point for cybersecurity
attacks. The interface specification can serve as an input to vulnerability
analysis of [RQ-10-09].

Product Development - [RQ-10-05] During the refinement of cybersecurity requirements, the cybersecurity
Requirements and implications 1318 of post-development phases shall be considered.
Recommendations -
Refinement of
Cybersecurity
Requirements and
Architectural Design

Product Development - [RQ-10-06] If specific procedures are required to ensure cybersecurity in post-
Requirements and development phases, these cybersecurity requirements shall be
Recommendations - specified and allocated to the relevant entities of the operational
Refinement of environment.
Cybersecurity EXAMPLE 8: Table 1 provides example requirements and procedures
Requirements and to ensure cybersecurity in post-development phases including their
Architectural Design allocation.

Product Development - RQ-10-07] The refined cybersecurity requirements shall be verified to ensure:
Requirements and a) completeness, correctness, and adequacy with the cybersecurity
Recommendations - requirements from higher level; and
Refinement of b) consistency with the architectural design from higher level.
Cybersecurity
Requirements and
Architectural Design

Product Development - [RQ-10-08] The refined architectural design shall be verified to ensure:
Requirements and a) compliance with the refined cybersecurity requirements;
Recommendations - b) compliance with the architectural design from higher level; and
Refinement of c) for software development: compatibility with the target environment.
Cybersecurity NOTE 12: The target environment includes architectural constraints.
Requirements and EXAMPLE 9: Verification methods can include:
Architectural Design - review;
- analysis;
- simulation; and
- prototyping.
NOTE 13: If CAL is used, then Annex E (Table E.3) provides methods
of verification and criteria for applicability.
Product Development - [RQ-10-09] Vulnerability analysis in accordance with 7.5 shall be performed to
Requirements and identify vulnerabilities associated with the refined architectural design
Recommendations - and refined cybersecurity requirements, including the interactions
Refinement of between components that could impair the fulfilment of the refined
Cybersecurity cybersecurity requirements.
Requirements and
Architectural Design

Product Development - [RQ-10-10] Identified vulnerabilities shall be managed according to 7.6.

Requirements and NOTE 14: Vulnerabilities can be handled with additional cybersecurity
Recommendations - requirements and components in the architectural design.
Refinement of EXAMPLE 10: Treatment of vulnerabilities 1346 in development can
Cybersecurity include:
Requirements and - isolation of functions;
Architectural Design - use of encryption;
- secure storage; and/or
- anonymization of personal information.

Product Development - [RQ-10-11]The vulnerability analysis of [RQ-10-09] shall be verified.

Requirements and
Recommendations -
Refinement of
Cybersecurity
Requirements and
Architectural Design

Product Development - [RQ-10-12] Verification activities shall be performed to confirm that the
Requirements and implementation of the design and the integration of the components are
Recommendations - compliant with:
Integration and a) the refined cybersecurity requirements (result of [RC-10-01] to [RQ-
Verification 10-01]); and
b) the refined architectural design (result of [RQ-10-02] to [RQ-10-04]).
NOTE 1: This can include the vehicle integration and verification at
system level.
NOTE 2: The results of the hardware and software verification activities
can be considered at system level.
NOTE 3: Verification activities can include regression testing for
updates and changes and re-testing for patching of a discovered
vulnerability.
NOTE 4: Verification methods as part of standard engineering per a
quality management system can be used as a baseline. Additional
verification types or activities specific for cybersecurity can be used.
EXAMPLE 1: Methods for verification can include:
- requirements-based test;
- interface test;
- resource usage evaluation;
- verification of the control flow and data flow; and
- static analysis; for software: static code analysis.
NOTE 5: If CAL is used, then Annex E (Table E.4) provides methods of
verification and criteria for applicability.
Product Development - [RQ-10-13] The integration and verification specification for the verification activities
Requirements and of [RQ-10-12] shall be defined considering:
Recommendations - a) the refined architectural design;
Integration and NOTE 6: This includes assumptions on reused components.
Verification EXAMPLE 2: The hardware-software interface can require specific
consideration.
b) the refined cybersecurity requirements;
c) the vulnerability analysis of [RQ-10-09] and the results of
vulnerability management of [RQ-10-10];
d) configurations and/or calibration processes intended for production,
if applicable;
e) dependencies 1379 that are relevant for integration; and
f) sufficient resources to support the functionality specified in refined
cybersecurity requirements.
NOTE 7: The verification specification initiated during system
development can be further refined during hardware and software
development.

Product Development - [RQ-10-14] If testing is used for the verification activities of [RQ-10-12], test cases
Requirements and shall be specified that include pass/fail criteria.
Recommendations - EXAMPLE 3: Methods of test case specification can include:
Integration and - analysis of requirements;
Verification - generation and analysis of equivalence classes;
- boundary values analysis; and/or
- error guessing based on knowledge or experience.
NOTE 8: If CAL is used, then Annex E (Table E.5) provides methods of
test case specification and criteria for applicability.
Product Development - [RQ-10-15] Test coverage by test cases shall be determined for the completeness
Requirements and of testing activities using a defined test coverage metric relevant for
Recommendations - cybersecurity.
Integration and NOTE 9: Test coverage can be determined by the use of appropriate
Verification software tools.
NOTE 10: A target value below full test coverage can be sufficient if a
rationale is provided.
NOTE 11: Test coverage is only useful for determining whether all
requirements were transcribed into implementation and realization; e.g.,
software code in the case of software development, and whether the
implementation matches the requirements.
NOTE 12: Some weaknesses go beyond the fact that all possible
control flows are evaluated. For example, improper sequence of
operations, insufficient authentication. As a consequence, a review of
the coverage of common weaknesses by the tests can complement this
activity.
NOTE 13: Analysis of test coverage can reveal shortcomings in
requirements-based test cases, inadequacies in requirements, dead
code, deactivated code or unintended functionality.
EXAMPLE 4: Structural coverage metrics at the software unit level can
include:
- statement coverage; and/or
- branch coverage.
NOTE 14: For software development, if instrumented code is used to
determine the degree of structural coverage, it can be necessary to
provide evidence that the instrumentation has no effect on the test
results. This can be done by repeating representative test cases with
non-instrumented code.
EXAMPLE 5: Structural coverage at the software architectural level can
include:
- function coverage; and/or
- call coverage.
NOTE 15: If CAL is used, then Annex E (Table E.6 and Table E.7)
provide methods and criteria for applicability.

Product Development - [RQ-10-16] A verification that components do not contain any unspecified 1415
Requirements and functionality shall be performed.
Recommendations - NOTE 16: Unspecified functionality is not explicitly described in the
Integration and architecture design specification but is implemented for any reason.
Verification EXAMPLE 6: For software development, code used for debugging or
instrumentation.
NOTE 17: If the unspecified function is deactivated, this can be an
acceptable control.
NOTE 18: If the unspecified function is encapsulated in a separate zone
outside of the trust boundary, this can be an acceptable control.
Product Development - [RQ-10-17] If testing is used for the verification activities of [RQ-10-12], the test
Requirements and environment shall be suitable for achieving the test objectives.
Recommendations - EXAMPLE 7: Test environments can include:
Integration and - hardware-in-the-loop;
Verification - electronic control unit network environments; and/or
- vehicles.
NOTE 19: In software development, the target environment can be
considered. Depending on the scope of the tests and the hierarchical
level of integration, the appropriate test environments for the execution
of the software components can be used. Such test environments can
be the target processor for final integration, a processor emulator or a
development system for the previous integration steps.
NOTE 20: In software development, if the integration testing is not
carried out in the target environment, the differences between the test
environment and the target environment can be analyzed in order to
specify additional tests in the target environment during the subsequent
test phases.
NOTE 21: In software development, differences between the test
environment and the target environment can arise in the source or
object code, for example, due to different bit widths of data words and
address words of the processors.

Product Development - [RC-10-03] Component testing should be performed to search for unidentified
Requirements and vulnerabilities.
Recommendations - EXAMPLE 8: Test methods to search for vulnerabilities can include:
Integration and - penetration testing;
Verification - vulnerability scanning; and/or
- fuzz testing.
NOTE 22: If CAL is used, then Annex E (Table E.8) provides test
methods and criteria for applicability.
NOTE 23: In software development, different weaknesses can exist in
the test environment and the target environment, and their triggering
into vulnerabilities depends on the functionality or code that executes
on them. Thus, the studied differences between the test environment
and the target environment encompass also existing weaknesses and
how they can or cannot be triggered by the functionality or code that
executes on them.

Product Development - [RQ-10-18] If testing of [RC-10-03] identifies weaknesses and/or vulnerabilities

Requirements and from, these shall be managed according to 7.6.
Recommendations - EXAMPLE 9: An additional cybersecurity control is implemented to
Integration and achieve a cybersecurity requirement, or a cybersecurity requirement is
Verification reworked and subsequently complied with.
Product Development - [RQ-10-19] When selecting a design, modelling or programming language the
Requirements and following shall be considered:
Recommendations - a) an unambiguous and comprehensible definition in both syntax and
Specific Requirements for semantics;
Software Development b) support for achievement of modularity, abstraction and
encapsulation;
c) support for the use of structured constructs; and
d) support for the use of secure design and coding techniques.
EXAMPLE 1: Community or provider support for the language itself.
Product Development - [RQ-10-20] Criteria for suitable modelling, design or programming languages for
Requirements and cybersecurity (see [RQ-10-19]) that are not sufficiently addressed by
Recommendations - the language itself shall be covered by coding guidelines, or by the
Specific Requirements for development environment.
Software Development EXAMPLE 2: Use of MISRA C:2012 3rd edition, 1st Revision or CERT
C for secure coding in the “C” programming language.
EXAMPLE 3: Criteria for suitable design, modelling and programming
languages for cybersecurity can include:
- use of language subsets;
- enforcement of strong typing; and/or
- use of defensive implementation techniques.
EXAMPLE 4: User input (e.g., input field, data import, APIs) is validated
and sanitized.
NOTE 1: If CAL is used, then Annex E (Table E.9) provides topics and
criteria for applicability.

Product Development - [RC-10-04] Design principles for software unit design and implementation at the
Requirements and source code level should be applied to achieve the following
Recommendations - characteristics:
Specific Requirements for a) correct order of execution of subprograms and functions within the
Software Development software units, based on the software architectural design;
b) consistency of the interfaces between the software units;
c) correctness of data flow and control flow between and within the
software units;
d) low complexity;
e) readability and comprehensibility;
f) robustness;
EXAMPLE 5: Methods to prevent use of tainted data.
g) suitability for software modification (unless ease of software
modification runs contrary to the cybersecurity requirements); and
h) verifiability.
NOTE 2: These characteristics can be achieved by applying and
enforcing coding guidelines.
NOTE 3: Coding guidelines can cover aspects such as safety and
overall code quality as well as the required cybersecurity properties.

Product Development - [RQ-10-21] The software unit design and the implemented software unit shall be
Requirements and 1488 verified to provide evidence for compliance with the coding
Recommendations - guidelines of [RQ-10-20], if applicable.
Specific Requirements for
Software Development

Product Development - [WP-10-01]Refined cybersecurity specification, resulting from [RC-10-01] to [RQ-

Work Products 10-04].
Product Development - [WP-10-02]Cybersecurity requirements for post-development, resulting from 0 and
Work Products [RQ-10-06].
Product Development - [WP-10-03]Verification report for the refined cybersecurity specification, resulting
Work Products from [RQ-10-07] and [RQ-10-08].
Product Development - [WP-10-04]Vulnerability analysis report, resulting from [RQ-10-09] to [RQ-10-11].
Work Products
Product Development - [WP-10-05]Integration and verification specification, resulting from [RQ-10-13].
Work Products
Product Development - [WP-10-06]Integration and verification reports, resulting from the requirements of
Work Products [RQ-10-12] and [RQ-10-14] to [RQ-
1497 10-18].
NOTE: This work product includes results from 0 in software
development.
Product Development - [WP-10-07]Documentation of the modelling, design or programming languages and
Work Products coding guidelines, if applicable, resulting from [RQ-10-19] to [RQ-10-
20].
Product Development - [WP-10-08]Software unit design and software unit implementation, if applicable,
Work Products resulting from [RC-10-04].
Cybersecurity Validation - [RQ-11-01] Validation activities shall be performed to confirm:
Requirements and a) the adequacy of the cybersecurity goals;
Recommendations b) the completeness, consistency, correctness and adequacy of:
i. the item and
ii. the cybersecurity requirements on the operational environment to
achieve the cybersecurity goals of the item; and
c) if applicable, the validity of the cybersecurity claims.

Cybersecurity Validation - [RQ-11-02] A validation specification for the validation activities of [RQ-11-01] shall
Requirements and be defined considering the configurations intended for production.
Recommendations
Cybersecurity Validation - [RC-11-01] Penetration testing should be performed to validate the cybersecurity
Requirements and goals as part of the validation activities of [RQ-11-01].
Recommendations NOTE: The extent of penetration testing can be defined based on risk
considerations.
Cybersecurity Validation - [RQ-11-03] Vulnerabilities revealed during the validation activities of [RQ-11-01]
Requirements and shall be managed in accordance with 7.6.
Recommendations
Cybersecurity Validation - [PM-11-01] If the residual risk is unacceptable, activities from 10 or, 9.4 and 9.5
Requirements and may be re-performed.
Recommendations
Cybersecurity Validation - [RQ-11-04] The validation of the item shall confirm that all the risks identified during
Requirements and the concept and product development phases are accepted or have
Recommendations been treated such that they are accepted, based on a rationale.
Cybersecurity Validation - [WP-11-01]Validation specification, resulting from [RQ-11-02].
Work Products
Cybersecurity Validation - [WP-11-02]Validation report, resulting from [RQ-11-01] and [RC-11-01] to [RQ-11-
Work Products 04].
Production - Requirements [RQ-12-01] A production control plan shall be created that applies the cybersecurity
and Recommendations requirements for post-development and includes:
a) the cybersecurity requirements for post-development allocated to
production;
b) an outline of the necessary installation procedures to achieve a);
NOTE 1: To manufacture an item or component and install the
hardware and software, the production process can use privileged
access. Such access can be used to introduce vulnerabilities in the item
or component if used in an unauthorized manner after production.
EXAMPLE 1: Removal of production access once the item or
component is produced.
c) description of protection measures for components to prevent
unauthorized alteration; and
NOTE 2: The protection measures can cover physical access and
logical access.
EXAMPLE 2: Physical measure that prevents physical access to
production servers holding software.
EXAMPLE 3: Logical measure that applies cryptographic techniques
and/or access controls.
EXAMPLE 4: Protected components can include:
- microcontrollers and processors;
- control units;
- systems;
- low-level programs;
- bootloaders;
- application software; and/or
- cryptographic material.
d) methods to confirm that the cybersecurity requirements for post-
development are met in the item or component.
NOTE 3: Methods can include verification, validation, inspection or
configuration and calibration checks.
NOTE 4: Methods can be conducted at the component level to give
assurance, and to reduce testing at the integrated item level.
NOTE 5: The production control plan can be included as part of an
overall production plan.

Production - Work [WP-12-01]Production control plan, resulting from [RQ-12-01].

Products
Operations and [RQ-13-01] For a cybersecurity incident, a cybersecurity incident response plan
Maintenance - shall be created that includes:
Cybersecurity Incident a) remediation actions for the cybersecurity incident;
Response - Requirements NOTE 1: Remediation actions are determined under vulnerability
and Recommendations management in 7.6.
b) a communication plan;
NOTE 2: The creation of a communication plan can involve internal
interested parties, including communications teams (e.g., marketing or
public relations), product and development teams, legal, customer
relations, quality management and purchasing.
NOTE 3: A communication plan can include identification of internal and
external communication partners (e.g., development, researchers, the
public, authorities) and communication packages for various audiences.
c) assigned responsibilities 1626 for the remedial actions;
NOTE 4: Those responsible can have:
- expertise in affected items or components, including legacy items
and components;
- organizational knowledge (e.g., business process, communications,
purchasing, legal); and/or
- decision authority.
d) a method for determining progress; and
EXAMPLE 1: Procedures to determine the progress criteria during the
remediation actions can include:
- percentage of affected items or components that are covered within
a defined timeframe; and/or
- percentage of items or components affected by remediation actions.
e) criteria for closure and actions upon closure.

Operations and [RQ-13-02]The status of cybersecurity incident remediation shall be tracked.

Maintenance - Cybersecurity
Incident Response -
Requirements and
Recommendations
Operations and [RQ-13-03] Relevant information for a cybersecurity incident shall be associated
Maintenance - Cybersecurity with the cybersecurity incident.
Incident Response - EXAMPLE 2: Relevant information can come from various sources and
Requirements and can include:
Recommendations - assets affected (e.g., part number, system description, number of
assets affected);
- related incidents and vulnerabilities;
- forensic data such as logging data; crash sensor data; and/or
- end-user complaints.

Operations and [WP-13-01]Cybersecurity incident response plan, resulting from [RQ-13-01].

Maintenance -
Cybersecurity Incident
Response - Work Products

Operations and [WP-13-02]Cybersecurity incident response information, resulting from [RQ-13-03].

Maintenance - Cybersecurity
Incident Response - Work
Products
Operations and [RQ-13-04] Updates and related capabilities shall be developed in accordance with
Maintenance -Updates - Clauses 9 and 10.
Requirements and NOTE 1: Capabilities can include the update capability within the
Recommendations vehicle.
NOTE 2: Cybersecurity of updates and capabilities can be achieved by
considering cybersecurity properties (confidentiality, integrity and
availability) and risk-based approaches.

Operations and [RQ-13-05] Cybersecurity implications of recovery options for updates shall be
Maintenance -Updates - considered in accordance with 0.
Requirements and NOTE 3: Recovery options can negatively affect the cybersecurity of
Recommendations the item or component.
EXAMPLE 1: Recovery options can include:
- rollback of the update to restore the item or component to its
previous state; and/or
- replacement/repair of the item or component.

Operations and [RQ-13-06] A procedure shall be created to communicate to customers when an

Maintenance -Updates - organization decides to end cybersecurity support for an item or
Requirements and component.
Recommendations NOTE 4: These communications can be handled under contract
requirements.
EXAMPLE 2: Timeframes for communication, method of
communication.

Operations and [WP-13-03]Procedures to communicate end of cybersecurity support, resulting

Maintenance -Updates - from [RQ-13-06].
Work Products
Decommissioning - [RQ-14-01] The cybersecurity implications of decommissioning shall be considered
Requirements and in accordance with Clauses 9 and 10.
Recommendations
Distributed Cybersecurity [RQ-15-01] For distributed activities, the capability of the considered supplier, to
Activities - Requirements develop and, if applicable, perform post-development activities
and Recommendations - according to this document shall be evaluated.
Demonstration and NOTE 1: This evaluation supports supplier selection and can be based
Evaluation of Supplier on the supplier’s capability to comply with this document, or on an
Capability evaluation of the previous implementation of another national or
international cybersecurity standard.

Distributed Cybersecurity [RC-15-01] To support the customer’s evaluation of supplier capability, the supplier
Activities - Requirements 1726 should provide a cybersecurity record of capability.
and Recommendations - NOTE 2: The supplier’s record of capability can include:
Demonstration and a) evidence of the organization’s capability concerning cybersecurity
Evaluation of Supplier (e.g., cybersecurity best practices from the development, post-
Capability development, governance, quality, and information security);
b) evidence of continuous cybersecurity activities in accordance with
Clause 7;
c) summary of previous cybersecurity assessments;
d) organizational audit results, if available;
e) evidence of an information security management system; and
f) evidence of the organization's management systems in accordance
with 5.4.6.
NOTE 3: An organization can outsource parts of running a
management system.
Distributed Cybersecurity [RQ-5-02] When cybersecurity activities are distributed, a request for quotation
Activities - Requirements from the customer to the candidate supplier shall include:
and Recommendations - a) a formal request to comply with this document;
Request for Quotation b) the expectation of cybersecurity responsibilities taken by the supplier
in accordance with 15.4.3; and
c) the cybersecurity goals or the set of relevant cybersecurity
requirements, including their attributes, depending on what the supplier
is quoting for.
EXAMPLE: Technical specification for integrating message
authentication.

Distributed Cybersecurity [RQ-15-03] The customer and the supplier shall specify the distributed
Activities - Requirements cybersecurity activities in a cybersecurity interface agreement including:
and Recommendations - a) the appointment of the customer’s and the supplier’s points of
Alignment of contact regarding cybersecurity;
Responsibilities b) if applicable, a joint tailoring of the cybersecurity activities in
accordance with 6.4.2;
c) the identification of the cybersecurity activities that are to be
performed by the customer and by the supplier, respectively;
EXAMPLE 1: Cybersecurity validation at the vehicle level performed by
the customer.
EXAMPLE 2: The distribution of cybersecurity activities regarding post-
development.
NOTE 1: The supplier, the customer or a third party can perform the
cybersecurity assessment concerning the components or work products
developed by the supplier.
NOTE 2: A RASIC table can be used, see Annex C.
d) the information and the work products to be shared, including
distribution, reviews and 1758 feedback mechanisms in the case of a
cybersecurity issue;
EXAMPLE 3: The shared information can include:
- information sharing strategy (see 5.4.5);
- information exchange procedures for cybersecurity vulnerability and
findings regarding cybersecurity risks;
- interface-related processes, methods and tools to ensure
compatibility between the customer and the supplier, such as proper
handling of data and securing the communication networks used to
pass that data;
- the definition of roles, the way of communicating and documenting
changes, and potentially a re-iteration of the risk determination;
- alignment on a tool for requirements management;
- process of reporting known vulnerabilities in a customer released
product; and/or
- results of cybersecurity assessments.
e) the target milestones regarding the cybersecurity activities of the
customer and the supplier; and
f) the definition of the end of cybersecurity support for the items or
components.
Distributed Cybersecurity [RC-15-02] The cybersecurity interface agreement should be concluded between
Activities - Requirements the customer and the supplier by the start of the distributed activities.
and Recommendations - EXAMPLE 4: Cybersecurity interface agreement for development,
Alignment of cybersecurity interface agreement for production.
Responsibilities
Distributed Cybersecurity [RQ-15-04] If a vulnerability report in accordance with 7.5 requires actions, the
Activities - Requirements customer and the supplier shall agree the actions required and who
and Recommendations - performs them.
Alignment of
Responsibilities
Distributed Cybersecurity [RQ-15-05] When there is a risk of not conforming to the agreed cybersecurity
Activities - Requirements planning, or a risk concerning cybersecurity, the other party shall be
and Recommendations - informed and both parties shall agree on a resolution.
Alignment of
Responsibilities
Distributed Cybersecurity [RQ-15-06] A party shall notify the other if there are conflicts concerning
Activities - Requirements cybersecurity requirements between cybersecurity and related
and Recommendations - disciplines (see [RQ-05-05]) such that appropriate action and decision
Alignment of can take place.
Responsibilities
Distributed Cybersecurity [RQ-15-07] If the customer’s cybersecurity requirements are unclear or not feasible,
Activities - Requirements the supplier shall consult the customer to come to a mutual
and Recommendations - understanding.
Alignment of
Responsibilities
Distributed Cybersecurity [RC-15-03] The definition of responsibilities should be specified in a matrix of
Activities - Requirements responsibility assignment.
and Recommendations - EXAMPLE 5: Template in Annex C.
Alignment of
Responsibilities
Distributed Cybersecurity [WP-15-01]Cybersecurity interface agreement, resulting from the requirements of
Activities - Work Products 15.4.3.
aft International Standard)
Section Category Requirement
For the assessment the Approval Authority or its
Technical Service shall verify that the vehicle
manufacturer has a Cyber Security Management
7.2.1 CSMS System in place and shall verify its compliance
with this Regulation

The vehicle manufacturer shall demonstrate to an

Approval Authority or Technical Service that their
Cyber Security Management System applies to
7.2.2.1 CSMS the following phases: Development phase;
Production phase; Post-production phase.

The vehicle manufacturer shall demonstrate that

the processes used within their Cyber Security
Management System ensure security is
adequately considered, including risks and
mitigations listed in Annex 5. This shall include:
7.2.2.2 - (a) CSMS (a) The processes used within the
manufacturer’s organization to manage cyber
security;

The processes used for the identification of risks

to vehicle types. Within these processes, the
7.2.2.2 - (b) CSMS threats in Annex 5, Part A, and other relevant
threats shall be considered

The processes used for the assessment,

7.2.2.2 - (c) CSMS categorization and treatment of the risks
identified
The processes in place to verify that the risks
7.2.2.2 - (d) CSMS identified are appropriately managed;

The processes used for testing the cyber security

7.2.2.2 - (e) CSMS of a vehicle type

The processes used for ensuring that the risk

7.2.2.2 - (f) CSMS assessment is kept current;

The processes used to monitor for, detect and

respond to cyber-attacks, cyber threats and
vulnerabilities on vehicle types and the processes
used to assess whether the cyber security
7.2.2.2 - (5) CSMS measures implemented are still effective in the
light of new cyber threats and vulnerabilities that
have been identified.

The processes used to provide relevant data to

7.2.2.2 - (g) CSMS support analysis of attempted or successful
cyber-attacks.
The vehicle manufacturer shall demonstrate that
the processes used within their Cyber Security
Management System will ensure that, based on
categorization referred to in paragraph 7.2.2.2 (c)
7.2.2.3 CSMS and 7.2.2.2 (g), cyber threats and vulnerabilities
which require a response from the vehicle
manufacturer shall be mitigated within a
reasonable timeframe.
The vehicle manufacturer shall demonstrate that
the processes used within their Cyber Security
Management System will ensure that the
7.2.2.4- (a) CSMS monitoring referred to in paragraph 7.2.2.2 (g)
shall be continual. This shall:
(a) Include vehicles after first registration in the
monitoring

Include the capability to analyse and detect cyber

threats, vulnerabilities and cyber-attacks from
vehicle data and vehicle logs. This capability shall
7.2.2.4- (b) CSMS respect paragraph 1.3. and the privacy rights of
car owners or drivers, particularly with respect to
consent.

The vehicle manufacturer shall be required to

demonstrate how their Cyber Security
Management System will manage dependencies
7.2.2.5 CSMS that may exist with contracted suppliers, service
providers or manufacturer’s sub-organizations in
regards of the requirements of paragraph 7.2.2.2.

The manufacturer shall have a valid Certificate of

Compliance for the Cyber Security Management
System relevant to the vehicle type being
approved
However, for type approvals prior to 1 July 2024,
if the vehicle manufacturer can demonstrate that
7.3.1 Vehicle Types the vehicle type could not be developed in
compliance with the CSMS, then the vehicle
manufacturer shall demonstrate that cyber
security was adequately considered during the
development phase of the vehicle type
concerned.

The vehicle manufacturer shall demonstrate that

the processes used within their Cyber Security
Management System will ensure that, based on
categorization referred to in paragraph 7.2.2.2 (c)
7.3.2 Vehicle Types and 7.2.2.2 (g), cyber threats and vulnerabilities
which require a response from the vehicle
manufacturer shall be mitigated within a
reasonable timeframe
The vehicle manufacturer shall identify the critical
elements of the vehicle type and perform an
exhaustive risk assessment for the vehicle type
and shall treat/manage the identified risks
appropriately. The risk assessment shall consider
the individual elements of the vehicle type and
7.3.3 Vehicle Types their interactions. The risk assessment shall
further consider interactions with any external
systems. While assessing the risks, the vehicle
manufacturer shall consider the risks related to all
the threats referred to in Annex 5, Part A, as well
as any other relevant risk.

The vehicle manufacturer shall protect the vehicle

type against risks identified in the vehicle
manufacturer’s risk assessment. Proportionate
mitigations shall be implemented to protect the
vehicle type. The mitigations implemented shall
include all mitigations referred to in Annex 5, Part
B and C which are relevant for the risks identified.
However, if a mitigation referred to in Annex 5,
Part B or C, is not relevant or not sufficient for the
risk identified, the vehicle manufacturer shall
ensure that another appropriate mitigation is
7.3.4 Vehicle Types implemented.
In particular, for type approvals prior to 1 July
2024, the vehicle manufacturer shall ensure that
another appropriate mitigation is implemented if a
mitigation measure referred to in Annex 5, Part B
or C is technically not feasible. The respective
assessment of the technical feasibility shall be
provided by the manufacturer to the approval
authority.

The vehicle manufacturer shall put in place

appropriate and proportionate measures to
secure dedicated environments on the vehicle
7.3.5 Vehicle Types type (if provided) for the storage and execution of
aftermarket software, services, applications or
data.

The vehicle manufacturer shall perform, prior to

type approval, appropriate and sufficient testing
7.3.6 Vehicle Types to verify the effectiveness of the security
measures implemented.
The vehicle manufacturer shall implement
measures for the vehicle type to:
7.3.7- (a) Vehicle Types (a) Detect and prevent cyber-attacks against
vehicles of the vehicle type
Support the monitoring capability of the vehicle
manufacturer with regards to detecting threats,
7.3.7- (b) Vehicle Types vulnerabilities and cyber-attacks relevant to the
vehicle type;
Provide data forensic capability to enable
7.3.7- (c) Vehicle Types analysis of attempted or successful cyber-
attacks.
Cryptographic modules used for the purpose of
this Regulation shall be in line with consensus
7.3.8 Vehicle Types standards. If the cryptographic modules used are
not in line with consensus standards, then the
vehicle manufacturer shall justify their use
The vehicle manufacturer shall report at least
once a year, or more frequently if relevant, to the
Approval Authority or the Technical Service the
outcome of their monitoring activities, as defined
in paragraph 7.2.2.2.(g)), this shall include
relevant information on new cyber-attacks. The
Reporting vehicle manufacturer shall also report and
7.4.1
provisions confirm to the Approval Authority or the Technical
Service that the cyber security mitigations
implemented for their vehicle types are still
effective and any additional actions taken.

The Approval Authority or the Technical Service

shall verify the provided information and, if
necessary, require the vehicle manufacturer to
Reporting remedy any detected ineffectiveness.
7.4.2
provisions If the reporting or response is not sufficient the
Approval Authority may decide to withdraw the
CSMS in compliance with paragraph 6.8.
High-level Vulnerability / threat

Back-end servers used as a means to attack a

vehicle or extract data

Services from back-end server being disrupted,

affecting the operation of a vehicle

Threats regarding back-end

servers related to vehicles in
the field

Vehicle related data held on back-end servers

being lost or compromised ("data breach")
Spoofing of messages or data received by the
vehicle

Communication channels used to conduct

unauthorized manipulation, deletion or other
amendments to vehicle code/data
Communication channels permit
untrusted/unreliable messages to be accepted
or are vulnerable to session hijacking/replay
attacks

Threats to vehicle regarding

their communication
channels

Information can be readily disclosed. For

example, through eavesdropping on
communications or through allowing
unauthorized access to sensitive files or folders

Denial of service attacks via channels to disrupt

vehicle functions

An unprivileged access to vehicle systems

Viruses embedded in communication media are
able to infect vehicle systems

Messages received by the vehicle (for example

X2V or diagnostic messages), or transmitted
within it, contain malicious content

Misuse or compromise of update procedures

Threats to vehicles regarding

their update procedures
It is possible to deny legitimate updates

Threats to vehicles regarding

Legitimate actors are able to take actions that
unintended human actions
would unwittingly facilitate a cyber-attack
facilitating a cyber-attack

Manipulation of the connectivity of vehicle

functions enables a cyber-attack, this can
include telematics; system that permit remote
operations; and systems using short-range
wireless communications

Threads to vehicles
regarding their external
connectivity and
connections
Hosted 3rd party software, e.g., entertainment
applications used as a means to attack vehicle
systems
Devices connected to external interfaces, e.g.
USB ports or OBD port used as a means to
attack vehicle systems

Extraction of vehicle data/code

Manipulation of vehicle data/code

Threads to vehicle
data/code

Erasure of data/code

Introduction of malware

Introduction of new software or overwrite

existing software
Disruption of systems or operations

Manipulation of vehicle parameters

Cryptographic technologies can be

compromised or are insufficiently applied
compromised or are insufficiently applied

Parts or supplies could be compromised to

permit vehicles to be attacked

Software or hardware development permits

vulnerabilities

Potential vulnerabilities that

could be expolited if not
sufficiently protected or
hardened

Network design introduces vulnerabilities

Unintended transfer of data can occur

Physical manipulation of system can enable an

attack
Ref No.

1.1

1.2

1.3

2.1

3.1

3.2

3.3

3.4
3.5

4.1

4.2

5.1

5.2

5.3

5.4

5.5
6.1

6.2

6.3

7.1

7.2

8.1

8.2

9.1
10.1

11.1
11.3

11.4

12.1

12.2

12.3

12.4
13.1

15.1

15.2

16.1

16.2

16.3

17.1
18.1

18.2

18.3

19.1

19.2

19.3

20.1

20.2
20.3

20.4

20.5

21.1

21.2

22.1

23.1
24.1

25.1

25.2

26.1

26.2
26.3

27.1

28.1

28.2

29.1

29.2
30.1

31.1
Description

Abuse of privileges by staff (insider attack)

Unauthorized internal access to the server (enabled, e.g., by backdoors, unpatched system software
vulnerabilities, SQL attacks or other means)

Unauthorized physical access to the server (conducted by, e.g., USB sticks or other media connecting
to the server

Attack on back-end server stops it functioning, for example it prevents it from interacting with vehicles
and providing services they rely on

Abuse of privileges by staff (insider attack)

Loss of information in the cloud/KMS/HSM. Sensitive data may be lost due to attacks or accidents
when data is stored by third-party cloud/KMS/HSM service providers.

Unauthorized internet access to the server (enabled, e.g., by backdoors, unpatched system software
vulnerabilities, SQL attacks or other means)

Unauthorized physical access to the server (conducted by, e.g., USB sticks or other media connecting
to the server
Information breach by unintended sharing of data (e.g., admin errors)

Spoofing of messages by impersonation (e.g., 802.11p V2X during platooning, GNSS messages)

Sybil attack (in order to spoof other vehicles as if there are many vehicles on the road)

Communication channels permit code injection, for example tampered software binary might be
injected into the communication stream

Communication channels permit manipulate of vehicle's held data/code

Communication channels permit overwrite of vehicle's held data/code

Communication channels permit erasure of vehicle's held data/code

Communication channels permit introduction of data/code to the vehicle (write data code)
Accepting information from an unreliable or untrusted source

Man-in-middle attack / session hijacking

Replay attack, for example an attack against a communication gateway allows the attacker to
downgrade software of an ECU or firmware of the gateway

Interception of information / interfering radiations / monitoring communications

Gaining unauthorized access to files or data (e.g., configs, memory map)

Sending a large number of garbage data to vehicle information system, so that it is unable to provide
service in the normal manner

Black hole attack, in order to disrupt communication between vehicles the attacker is ably to block
messages between the vehicles

An unprivileged user is able to gain privileged access, for example root access, access to ACL
Virus embedded in communication media infects vehicle systems

Malicious internal (e.g., CAN) messages

Malicious diagnostic messages

Malicious proprietary messages (e.g., those normally sent from OEM or component/system/function
supplier)

Compromise of over-the-air software update procedures. This includes fabrication the system update
program or firmware

Compromise of local/physical software update procedures. This includes fabrication the system
update program or firmware

The software is manipulated before the update process (and is therefore corrupted), although the
update process is firmware

Compromise of cryptographic keys of the software provider to allow invalid update

Denial of Service attack against update server or network to prevent rollout of critical software
updates and/or unlock of customer specific features

Innocent victim (e.g., owner, operator or maintenance engineer) being tricked into taking an action to
unintentionally load malware or enable an attack

Defined security procedures are not followed

Manipulation of functions designed to remotely operate systems, such as remote key, immobilizer,
and charging pile

Manipulation of vehicle telematics (e.g., manipulate temperature measurement of sensitive goods,

remotely unlock cargo doors)

Interference with short range wireless systems or sensors

Corrupted applications, or those with poor software security, used as a method to attack vehicle
systems
External interfaces such as USB or other ports used as a point to attack, for example trough code
injection

Media infected with a virus connected to a vehicle system

Diagnostic access (e.g., dongles in OBD port) used to facilitate vehicle parameters (directly or
indirectly)

Extraction of copyright or proprietary software from vehicle systems (product piracy)

Unauthorized access to the owner's privacy information such as personal identity, payment account
information, address book information, location information, vehicle's electronic ID, etc.

Extraction of cryptographic keys

Illegal/unauthorized changes to vehicle's electronic ID

Identity fraud. For example, if a user wants to display another identity when communications with toll
systems, manufacturer backend
Action to circumvent monitoring systems (e.g., hacking/tampering/blocking of messages such as ODR
Tracker data, or number of runs)

Data manipulation to falsify vehicle's driving data (e.g., mileage, driving speed, driving directions, etc.)

Unauthorized changes to system diagnostic data

Unauthorized deletion/manipulation of system event logs

Unauthorized deletion/manipulation of public keys

Introduce malicious software or malicious software activity

Fabrication of software of the vehicle control system or information system

Denial of service, for example this may be triggered on the internal network by flooding a CAN bus, or a
high rate of messaging

Unauthorized access of falsify the configuration parameters of vehicle's key functions, such as brake
data, airbag deployed threshold, etc.

Unauthorized access of falsify the charging parameters, such as charging voltage, charging power,
battery temperature, etc.

Combination of short encryption keys and long period of validity enables attacker to break encryption

Insufficient use of cryptographic algorithms to protect sensitive systems

Using already or soon to be deprecated cryptographic algorithms

Hardware or software, engineered to enable an attacker or fails to meet design criteria to stop an
attack

Software bug. The presence or software bugs can be a basis for potential exploitable vulnerabilities.
This is particularly true if software has not been tested to verify that known bad code/bugs is not
present and reduce the risk of unknown bad code/bug being present

Using remainders from development (e.g., debug ports, JTAG ports, microprocessors, development
certificates, developer passwords, …) can permit access to ECUs or permit attackers to gain higher
privileges

Superfluous internet ports left open, providing access to network systems

Circumvent network separation to gain control. Specific example is the use of unprotected gateways,
or access points (e.g., truck-trailer gateways), to circumvent protection and gain access to other
network segments to perform malicious acts, such as sending arbitrary CAN bus messages
Information breach. Personal data may be leaked when the car changes user (e.g., is sold or used as
hire vehicle with new hirers)

Manipulation of electronic hardware, e.g., unauthorized electronic hardware added to a vehicle to

enable "man-in-middle" attack

Replacement of authorized electronic hardware (e.g., sensors) with unauthorized electronic hardware

Manipulation of the information collected by a sensor (for example, using a magnet to tamper with
the Hall effect sensor connected to the gearbox)
Value
Impact Category Safety Financial Operational Privacy
Ne 0 0 0 0
Mo 10 10 1 1
Ma 100 100 10 10
Se 1000 1000 100 100

Impact Level Sum of Values

Ne 0 - 19 Negligible
Mo 20 - 99 Moderate
Ma 100 - 999 Major
Se >= 1000 Severe

Attack feasibility factors

Knowledge about
Time Consuming Value Expertise Value
Item
<1w 0 Layman 0 Public
<1m 1 Proficient 3 Restricted
<6m 4 Expert 6 Sensitive
<= 3 y 10 Multiple Experts 8 Critical
>3y 19

Attack Feasibility Map

Attack Feasibility Value
High 0 - 13
Medium 14 - 19
Low 20 - 24
VeryLow => 25

Risk Value Attack Feasibility Level

Impact Level VeryLow Low Medium High
Se 2 3 4 5
Ma 2 3 3 4
Mo 2 2 2 3
Ne 1 1 1 2

Risk Treatment
Strategy
Avoid
Mitigation
Transfer
Accept

To obtain the "Total", "AF Level" & "Risk Value" in "Attack Feasibility Assessment", drag from bottom ri
Negligible
Moderate
Major
Severe

tack feasibility factors

Window of
Value Value Equipment Value
opportunity
0 Unlimited 0 Standard 0
3 Easy 1 Specialized 4
7 Moderate 4 Bespoke 7
11 Difficult 10 Multiple Bespoke 9

Severe
Major
Moderate
Negligible

nt", drag from bottom right corner of the preceding box on top
Layman

Automotive Threat Analysis and Risk Assessment in Practice
0% (1)
Automotive Threat Analysis and Risk Assessment in Practice
27 pages
ISO#SAE 21434 2021 (E) - Character PDF Document
No ratings yet
ISO#SAE 21434 2021 (E) - Character PDF Document
7 pages
Iso 13400-1-2011
No ratings yet
Iso 13400-1-2011
22 pages
SEooc Solution
No ratings yet
SEooc Solution
9 pages
ISO SAE 21434 Automotive Cybersecurity Standard
No ratings yet
ISO SAE 21434 Automotive Cybersecurity Standard
25 pages
BSC CS Shell Programming
No ratings yet
BSC CS Shell Programming
33 pages
ISO/SAE 21434: Setting The Standard For Connected Cars' Cybersecurity
No ratings yet
ISO/SAE 21434: Setting The Standard For Connected Cars' Cybersecurity
47 pages
2-10 Automotive-Spice Version 3 Pocketguide
No ratings yet
2-10 Automotive-Spice Version 3 Pocketguide
110 pages
Threat Analysis and Risk Assessment for Connected
No ratings yet
Threat Analysis and Risk Assessment for Connected
19 pages
Approaches For Vehicle Cyber Security PDF
No ratings yet
Approaches For Vehicle Cyber Security PDF
2 pages
2021 en WP Automotive Cybersecurity Web1
100% (1)
2021 en WP Automotive Cybersecurity Web1
23 pages
GP - Cybersecurity in Automotive - WP v1-2022-11-29 PublicRls SIGNED
No ratings yet
GP - Cybersecurity in Automotive - WP v1-2022-11-29 PublicRls SIGNED
16 pages
Automotive Cyber Security: Andi Otea May 2018
No ratings yet
Automotive Cyber Security: Andi Otea May 2018
18 pages
US DOT - Cybersecurity Best Practices For The Safety of Modern Vehicles
No ratings yet
US DOT - Cybersecurity Best Practices For The Safety of Modern Vehicles
24 pages
NXP Automotive Cyber Security
No ratings yet
NXP Automotive Cyber Security
49 pages
Automotive Cybersecurity
No ratings yet
Automotive Cybersecurity
6 pages
(Automotive Cybersecurity Best Practices) Auto-IsAC - Awareness and Training (2019, Auto-IsAC) - Libgen - Li
No ratings yet
(Automotive Cybersecurity Best Practices) Auto-IsAC - Awareness and Training (2019, Auto-IsAC) - Libgen - Li
22 pages
Cybersecurity in Automotive
No ratings yet
Cybersecurity in Automotive
3 pages
Diagnostics of Software Defined Vehicles
No ratings yet
Diagnostics of Software Defined Vehicles
4 pages
Rimac Automobili Cybersecurity Eng
No ratings yet
Rimac Automobili Cybersecurity Eng
1 page
Subrahmanya HN: Software Project Manager - Senior Safe Scrum Master & Agile Coach
No ratings yet
Subrahmanya HN: Software Project Manager - Senior Safe Scrum Master & Agile Coach
4 pages
1 - ISO 21434 준수 확인을 위한 사이버 보안 프로세스 심사의 이해와 대응 방안
No ratings yet
1 - ISO 21434 준수 확인을 위한 사이버 보안 프로세스 심사의 이해와 대응 방안
20 pages
Software-Defined Vehicles - November 2024
No ratings yet
Software-Defined Vehicles - November 2024
22 pages
PDF 08 DEKRA - How To Integarte Cybersecurity and Functional Safety Into Your Process Ver 5
No ratings yet
PDF 08 DEKRA - How To Integarte Cybersecurity and Functional Safety Into Your Process Ver 5
33 pages
Renesas ADAS Products
No ratings yet
Renesas ADAS Products
14 pages
Car Play
No ratings yet
Car Play
12 pages
Security in VANET
No ratings yet
Security in VANET
22 pages
Automotive Attacks and Countermeasures On LIN Network Bus
No ratings yet
Automotive Attacks and Countermeasures On LIN Network Bus
10 pages
1.vehicle Overview
100% (1)
1.vehicle Overview
34 pages
Etas Sec SDV Whitepaper 20230525
No ratings yet
Etas Sec SDV Whitepaper 20230525
13 pages
Challenges in Certification of Autonomous Driving Systems
No ratings yet
Challenges in Certification of Autonomous Driving Systems
8 pages
CSMS Solutions Brief v4
No ratings yet
CSMS Solutions Brief v4
2 pages
A Smart Way To Drive Ecu Consolidation
No ratings yet
A Smart Way To Drive Ecu Consolidation
4 pages
Aspice & Iso26262
No ratings yet
Aspice & Iso26262
3 pages
Fault Attack
No ratings yet
Fault Attack
100 pages
IJTG
No ratings yet
IJTG
13 pages
Company Profile Template
No ratings yet
Company Profile Template
4 pages
ECU Penetration Testing
100% (1)
ECU Penetration Testing
35 pages
The Car Is Connected Now! But Are We Safe?
No ratings yet
The Car Is Connected Now! But Are We Safe?
39 pages
NM 252
No ratings yet
NM 252
137 pages
Automotive Security Challenges Standards and Solutions
No ratings yet
Automotive Security Challenges Standards and Solutions
22 pages
Service Oriented Architecture For Software Driven Vehicles
No ratings yet
Service Oriented Architecture For Software Driven Vehicles
13 pages
Thesis Kaiser 2015 PDF
No ratings yet
Thesis Kaiser 2015 PDF
163 pages
Connected Automated Driving - Standards Collection
No ratings yet
Connected Automated Driving - Standards Collection
43 pages
What Are The Cybersecurity Challenges For Connected and Autonomous Vehicles
No ratings yet
What Are The Cybersecurity Challenges For Connected and Autonomous Vehicles
7 pages
Automotive Systems - Day 1
No ratings yet
Automotive Systems - Day 1
109 pages
Final
No ratings yet
Final
20 pages
KPIT Presentation
No ratings yet
KPIT Presentation
18 pages
(Standard) J3061 Automotive Secuirty Requirement
100% (1)
(Standard) J3061 Automotive Secuirty Requirement
15 pages
SecOC Presentation
100% (1)
SecOC Presentation
32 pages
Shantesh resume automotive
No ratings yet
Shantesh resume automotive
2 pages
What Is SOTIF
No ratings yet
What Is SOTIF
6 pages
TP SDV in Action From Tech To New Experiences
No ratings yet
TP SDV in Action From Tech To New Experiences
36 pages
Tuv India Training Academy Online Training Programs: Click Here For Android For Ios
No ratings yet
Tuv India Training Academy Online Training Programs: Click Here For Android For Ios
12 pages
Imap Sector Report Telematics Augist 2017
No ratings yet
Imap Sector Report Telematics Augist 2017
30 pages
NHTSA Releases AEB System Requirements To Be Implemented by 2029
No ratings yet
NHTSA Releases AEB System Requirements To Be Implemented by 2029
317 pages
Risk Risk Advisory Automotive Software Quality EN S
No ratings yet
Risk Risk Advisory Automotive Software Quality EN S
14 pages
Mastering Rtos: Hands On Freertos and Stm32Fx With Debugging
No ratings yet
Mastering Rtos: Hands On Freertos and Stm32Fx With Debugging
348 pages
YD18050 Automotive Lighting November 2018 Sample
No ratings yet
YD18050 Automotive Lighting November 2018 Sample
41 pages
Incident response team Third Edition
From Everand
Incident response team Third Edition
Gerardus Blokdyk
No ratings yet
Autonomous Vehicles
No ratings yet
Autonomous Vehicles
12 pages
CV-3001 Series: User's Manual
No ratings yet
CV-3001 Series: User's Manual
630 pages
Skill: Numerical Ability::Worksheet Number:62
0% (1)
Skill: Numerical Ability::Worksheet Number:62
2 pages
Computer Aided Design
No ratings yet
Computer Aided Design
14 pages
GWG Packaging Specifications v3
No ratings yet
GWG Packaging Specifications v3
9 pages
Lab 3
No ratings yet
Lab 3
7 pages
Harsh Resume
No ratings yet
Harsh Resume
3 pages
Practical No 24 2308
No ratings yet
Practical No 24 2308
4 pages
How To Rank - Bank FREE APPs - Mobile Games
No ratings yet
How To Rank - Bank FREE APPs - Mobile Games
38 pages
24a - w09 - MCQ - Final
No ratings yet
24a - w09 - MCQ - Final
10 pages
ISP BestPractices LSMV Auto-Labeling-3.0
No ratings yet
ISP BestPractices LSMV Auto-Labeling-3.0
26 pages
An Introduction To G Code
100% (1)
An Introduction To G Code
50 pages
117 Polynomial Problems From Amsp Toc
No ratings yet
117 Polynomial Problems From Amsp Toc
3 pages
Data Structure and Algorithm Chapter Three: Linear Array
No ratings yet
Data Structure and Algorithm Chapter Three: Linear Array
25 pages
Self Source SWP User Guide
No ratings yet
Self Source SWP User Guide
11 pages
W3schools: Bootstrap Get Started
No ratings yet
W3schools: Bootstrap Get Started
5 pages
Standard Battery Pack Li-Ion 14.40V / 6.80ah / 97.92Wh: Technical Data Sheet
No ratings yet
Standard Battery Pack Li-Ion 14.40V / 6.80ah / 97.92Wh: Technical Data Sheet
4 pages
Second Midterm For ECE374: 04/16/12 Solution!! Instructions
No ratings yet
Second Midterm For ECE374: 04/16/12 Solution!! Instructions
10 pages
Client Master List: National Securities Depository Limited
No ratings yet
Client Master List: National Securities Depository Limited
2 pages
Leb400a-90000617 B Userguide
No ratings yet
Leb400a-90000617 B Userguide
92 pages
NI DC-DC-Converter AppNote
No ratings yet
NI DC-DC-Converter AppNote
15 pages
12 Maths
No ratings yet
12 Maths
4 pages
UNIT 4 OCI
No ratings yet
UNIT 4 OCI
51 pages
Test Itt300 Okt 2023 - Q
No ratings yet
Test Itt300 Okt 2023 - Q
6 pages
Xpeditor UserGuide PDF
No ratings yet
Xpeditor UserGuide PDF
286 pages
Google Aiml
No ratings yet
Google Aiml
50 pages
Parent Portal Guide
No ratings yet
Parent Portal Guide
23 pages
Machine Learning Technique Based Wrist Radial Pulse Diagnosis
No ratings yet
Machine Learning Technique Based Wrist Radial Pulse Diagnosis
37 pages
Web Development Internship Project Report Sample
0% (1)
Web Development Internship Project Report Sample
6 pages
100 - Telegram Bots (@socialcrrowd)
No ratings yet
100 - Telegram Bots (@socialcrrowd)
3 pages