Goal and Threat Modelling for Driving Automotive Cybersecurity Risk

Analysis Conforming to ISO/SAE 21434

Christophe Ponsard, Valery Ramon and Jean-Christophe Deprez

CETIC Research Centre, Charleroi, Belgium

Keywords:

Automotive, Safety, Security, Certiﬁcation, Standards, Goal-oriented Analysis.

Abstract:

As cars are increasingly connected and autonomous, they also become more exposed to cyber security threats.

Providing strong protection and reactive response to such threats in a large industry involving many tiers

and complex safety critical systems is challenging and required the development of the new ISO 21434 stan-

dard. Along with ISO 2626 dedicated to safety, it provides solid grounds for safety-security co-engineering.

This paper focuses on how to provide effective and efﬁcient support to the risk assessment phase based on a

model-based approach. A rich goal-oriented meta-model is proposed to capture automotive assets and system

properties, to estimate the impact of damage scenarios, to identify threats and to assess their feasibility. The

approach is implemented as proof-of-concept through the meta-model adaptation of a generic co-engineering

platform and is illustrated on the car light control sub-system.

1 INTRODUCTION

Cars have become totally connected objects and re-

quire communication to support a wide range of sce-

narios from information and entertainment purposes

to new ways of operating the car itself such as driver-

assistance, connected ﬂeet and autonomous driving

modes. This fast pace functional evolution has signif-

icantly increased the attack surface of the connected

car (Shiho Kim, 2020).

Unfortunately, cyber security methods to protect

the car assets did not improve at the same pace and re-

lied, for a time, only on the J3061 set of best practices

with little guidance on how to proceed (SAE, 2016).

To ﬁll this gap, ISO and SAE joined their effort to

produce the ISO/SAE 21434 standard which will su-

persede J3061 by providing more guidance through

actionable steps, a list of requirements for compli-

ance, management processes and a global speciﬁca-

tion (ISO, 2020). This standard is still in draft form

and due to be published in 2021.

The forthcoming ISO 21434 standard also com-

plements the ISO 26262 by covering the cybersecu-

rity perspective while ISO 26262 is addressing the

functional safety perspective (ISO, 2011). The safety

and security domains differ by the considered im-

pacts: safety risks are related to consequences to peo-

ple or environment, while cyber security risks are pri-

mary concerned with ﬁnancial, operational, and pri-

vacy impacts. However, both share a common culture.

From a risk management viewpoint, security risks are

analysed through Threat Analysis and Risk Assess-

ment (TARA) while safety performs Hazard Analysis

and Risk Assessment (HARA). This opens the way

to building a wider safety-security co-engineering ap-

proach, based on the fact safety has been part of the

automotive development culture for decades. Given

this evolution, it is anticipated that automotive suppli-

ers will be asked to demonstrate compliance with ISO

21434 which can also lead to competitive advantage

(Sembera, 2020).

Relying on model-based engineering is a realis-

tic approach as most of the steps in the automo-

tive development process are already model-based

(Leopold, 2019). For example, SysML (OMG, 2005)

and UML (OMG, 1997) are widely used as part of

the architecture process or for model-based software

development and integrated in automotive toolchains

(Hause and Korff, 2007). Supporting model-based

risk assessment is highly beneﬁcial in order to support

the systematic identiﬁcation of assets, vulnerabilities,

threats and countermeasures.

Our paper takes such a model-based approach for

risk assessment. In order to consider both safety and

security dimensions, we rely on a goal-oriented re-

quirements engineering (GORE) framework able to

structure systems properties and related risks (van

Lamsweerde, 2009). Our contributions are to show

Ponsard, C., Ramon, V. and Deprez, J.

Goal and Threat Modelling for Driving Automotive Cybersecurity Risk Analysis Conforming to ISO/SAE 21434.

DOI: 10.5220/0010603008330838

In Proceedings of the 18th International Conference on Security and Cryptography (SECRYPT 2021), pages 833-838

ISBN: 978-989-758-524-1

833

that such an approach supports:

• the identiﬁcation of key assets, safety and security

properties and related risks.

• co-engineering practices through commonly

adopted methods to integrate TARA with HARA.

• a model-based tool chain with analysis, transfor-

mation and document generation.

• a validation on an automotive subsystem for con-

trolling lights. capabilities.

This paper is structured as follows. Section 2 gives

more background on the ISO 26262 and ISO 21434

standards. Section 3 presents our approach based on

the modelling of assets, goals and hazards/threats and

introduces our case study. Section 4 presents our

HARA performed on a tool supported application of

our method to an automotive case. Finally, Section 5

draws some conclusions and identiﬁes further work.

2 BACKGROUND ON

AUTOMOTIVE STANDARDS

This section gives minimal background about the con-

tent of the ISO 26262 standard and the new ISO/SAE

21434 standard.

2.1 ISO 26262 for Automotive Safety

The ISO 26262 “Road vehicles – Functional safety”

is the international standard for functional safety of

electrical and/or electronic systems in production au-

tomobiles (ISO, 2011). It is a risk-oriented standard,

in the spirit of ISO 31000 (ISO, 2018). It is a spe-

cialisation of the IEC 61508, a risks basic functional

safety standard which applies to all industries. The

standard addresses the risk of hazardous operational

situations using qualitatively HARA approaches re-

sulting in the deﬁnition of safety measures to avoid

or mitigate the effect of failures either of systemic or

random nature.

From a process perspective, it follows the automo-

tive W-shaped lifecycle combining two V cycles re-

spectively for hardware and software design. HARA

is performed during the concept phase and results

in the identiﬁcation of potential hazards. The corre-

sponding risks are investigated with a rating function

of the driving situation, the ability to control it and

the severity of the caused harm. It is evaluated using

an automotive safety integrity level (ASIL), which is

assigned to each safety goal ranging from A to D for

the most critical level. For systems with lower risks,

quality management activities are deemed enough

(Schmittner and Ma, 2015).

About cyber security, this standard deﬁnes the

baseline cyber security guidelines for the develop-

ment phase. It does not have speciﬁc requirements

for post-production, decommissioning phases, auto-

motive cyber security, or dealing with speciﬁc cyber

security incidents.

2.2 ISO 21434 for Automotive Cyber

Security

This upcoming standard, due to be released in 2021,

aims at driving an industry-wide consensus related to

key cyber security issues in the automotive domain

(ISO, 2020). It will supersede the J3061 (SAE, 2016)

good practices with more structured recommenda-

tions showing that the industry is fully embracing the

challenges of ensuring automotive cyber security. Its

scope is road vehicles (e.g. car, trucks, busses) and

covers their sub-systems, components, connections,

and software. Its purpose is to ensure that manufactur-

ers and all participants in the supply chain have struc-

tured processes in place that support a “security by

design” process.

For a process perspective, similarly to ISO 26262,

it looks at the entire development process and life cy-

cle of a vehicle. It follows the V-model and consid-

ers a wide range of activities such as TARA in the

design branch, veriﬁcation and validation in the test-

ing branch and security monitoring, incident and re-

sponse management in the operation phase.

The standard is structured in 10 sections and 15

clauses. It starts by deﬁning (1) the scope, (2) the

normative reference, (3) the glossary, (4) general con-

siderations and (5/clauses 5-6-7) the management ap-

proach. Then (6/clause 8) focuses on risk assessment.

It is followed by three sections respectively covering

(7/clause 9) concept phase, (8/clauses 10-11) product

development and (9/clauses 12-13-14) product, oper-

ation and maintenance. The ﬁnal section (10/clause

15) deals with supporting processes.

Concerning the risk assessment, the standard does

not impose any TARA methods but its clause 8 re-

minds about the mandatory steps it should cover, in

the same spirit as the ISO 27005. It is depicted in

Figure 1.

Figure 1: ISO 21434 TARA Process.

SECRYPT 2021 - 18th International Conference on Security and Cryptography

834

Figure 2: Object model of the light subsystem (with legend of notations).

3 GOAL-ORIENTED MODELS

FOR CO-ENGINEERING

This section introduces our methodological frame-

work based on GORE. Different variants of goal mod-

elling were elaborated in the requirements engineer-

ing ﬁeld such as i* (Yu and Mylopoulos, 1997),

KAOS (van Lamsweerde, 2009), GSN (ACWG,

2018). This paper relies on KAOS. The required mod-

elling notations are described in this section and de-

picted in the legend of Figure 2. More details are pro-

vided in the reference book (van Lamsweerde, 2009)

and in a more focused application to co-engineering

(Ponsard et al., 2021). To illustrate the approach, we

use a light control subsystem. This case is actually

used in the standard itself (ISO, 2020). Despite its

limited size, it contains interesting issues to highlight

the beneﬁts of our approach. It is also analysed by

method and tool developers (ASRG, 2020). Our mod-

elling will be divided in three viewpoints: the object

model capturing the domain, the goal model for prop-

erties and the obstacle model for risks.

3.1 Object/Asset Model

The object (or asset) model deﬁnes and interrelates all

the concepts involved in a system. It must be able to

capture all the vocabulary that is required to express

properties (especially about safety and security) that

will be structured in the goal model. It must also iden-

tify all valuable assets that could be threatened from a

cyber security point of view.

This model captures domain concepts using en-

tities, relationships, events or agents/attackers. The

modelling notation used is close to the UML class di-

agram (OMG, 1997).

Figure 2 represents the asset model of our case

study. The system is modelled using different ab-

stractions that can be reused across many subsys-

tems: Electronic Control Unit (ECU), sensors (the

lamp switch in our case), actuators (lamp controller)

and a variety of control devices (head lamps but also

some communication devices). The communication

is managed through an internal CAN bus on which

messages are exchanged. A gateway may also ensure

the bridge across subsystems, for example to connect

communication devices to the CAN bus. Objects can

have speciﬁc attributes reﬂecting important state in-

formation, e.g. the switch and lamp state.

3.2 The Goal Model

Goals capture, at different levels of abstraction, key

properties the considered system should achieve (van

Lamsweerde, 2009). The goal model structures goals

in the form of AND-OR trees which express reﬁne-

ment relationships among goals. High-level goals can

be progressively reﬁned into more concrete and op-

erational ones through relationships linking a parent

goal to several sub-goals, with different fulﬁlment

conditions using either “AND-reﬁnement” (all sub-

goals need to be satisﬁed) or “OR-reﬁnement” (a sin-

gle sub-goal is enough, i.e. possible alternatives). Re-

ﬁnement can be characterised by some tactics which

can help in checking their completeness and consis-

tency, e.g. case-based (making design distinctions) or

milestone-based (i.e. temporal steps). Goals can also

bear speciﬁc attributes characterising speciﬁc nature,

like safety of security which can be made graphically

visible through speciﬁc decorators (SAFE/SEC).

Figure 3 shows the modelling of a safety property:

lamp should be on at night (depicted by blue paral-

lelograms). In our manual design, this relies on the

fact the lamp is turned on if and only if the switch

is activated and the assumption (depicted by a yel-

low parallelogram) the driver will activate and keep

the switch on at night. Given the property (depicted

by the little house) that switch can only be on or off

(no auto-lightning considered), a case-based reﬁne-

ment is used to distinguish two possible state changes

causes by turning the switching ON or OFF. The

AND-reﬁnement is represented by a single yellow cir-

Goal and Threat Modelling for Driving Automotive Cybersecurity Risk Analysis Conforming to ISO/SAE 21434

835

cle connecting reﬁned goals and useful properties that

achieves an higher level goal. The “TurnOn WHEN

SwitchON” goal is further reﬁned using a milestone

decomposition going through the whole communica-

tion chain: detecting the switch change by the ECU

then sending a message on the CAN bus, processing

it by the lamp controller to ﬁnally switch the lamp

on. Different monitoring and controlling agents are

involved in the process and are represented by yellow

hexagons. Goals under the direct control of an agent

are called requirements and have a thicker border.

3.3 The Obstacle Model

An obstacle represents an undesirable property. It is

the dual concept of a goal and can be used to rep-

resent a safety hazard or a security threat. It is de-

picted by red parallelogram in the opposite direction

than a goal. Obstacles can occur from the environ-

ment (i.e. a safety hazard) or be deliberately caused

by an attacker (i.e. a security threat) like an attacker

trying to take control of the light system. An attacker

is depicted by a red agent. Like goals, obstacles can

be reﬁned using AND/OR trees, leading to decom-

position structures quite similar to FTA in safety or

AT in security. Reﬁnement links can also be further

characterised by concrete tactics through more spe-

ciﬁc safety/security gates (not illustrated in this pa-

per). Leaf obstacles are either root causes (in safety)

or vulnerabilities (in security). An obstacle is usually

connected to the goal it is impacting through an ob-

struction relationship. Symmetrically an obstacle can

be mitigated by an additional requirement. Attacker

speciﬁc relationships also explicit the goal under at-

tack or the vulnerability that is exploited.

Figure 4 illustrates obstacles on a partial attack

decomposition unexpectedly turning the lamp on. It

can be achieved by an attacker accessing the bus and

Figure 3: Goal model of the light sub-system.

spooﬁng a CAN message. A possible mitigation is

to implement message integrity checks. Note the top

level safety goal is not broken but a similar attack

turning off the light at night would.

4 MODEL-BASED RISK

ANALYSIS

In order to comply with the ISO 21434 TARA pro-

cess, we will go through clauses 8.3 through 8.5 il-

lustrated in Figure 1 using the goal modelling frame-

work supporting safety and security co-engineering

described in Section 3. The Objectiver platform

(Respect-IT, 2005) is used as tool to build the model

and perform the risk assessment but also as prototyp-

ing platform thanks to its plugin mechanism.

4.1 Asset Identiﬁcation (8.3)

The asset identiﬁcation step was already covered in

Section 3.1 when presenting the object/asset model.

Assets are identiﬁed by analysing the system goals.

For example, the goal ”Lamp is On IFF Switch is On”

enables to identify the Lamp and Switch. The goal re-

ﬁnement process conducts to the identiﬁcation of the

whole command transmission chain. Assets can also

structured using more generic concepts forming the

building blocks of a car (e.g. sensor, ECU, actuator)

as shown in Figure 2. Those can then be instantiated

in various subsystems.

Note the asset model can be further enriched

with architectural information useful for the attack

path analysis and later with components dealing with

counter-measures (not detailed in this paper).

4.2 Damage Scenario

Damage scenarios can be elicited by trying to system-

atically break goals by introducing obstacles. It can

be done on the different security dimensions of :

• Conﬁdentiality. In this case, it is not relevant as

everyone can see when lamps are turned on.

• Integrity results in obstacles related to unexpect-

edly turning lights on or off.

• Availability results in obstacles related to impos-

sibility of turning lights on or off.

4.3 Threat Scenario Identiﬁcation (8.4)

and Attack Path Analysis (8.6)

This step is performed through attack trees which in

SECRYPT 2021 - 18th International Conference on Security and Cryptography

836

Figure 4: Obstacle (partial attack) on the light sub-system.

reﬁnement of damage scenarios in a top-down ap-

proach or based on known vulnerabilities in a bottom-

up approach. The later requires a richer architectural

model which motivates to elaborate the object model

as described in Figure 2. The full reﬁnement of threats

will naturally explore and discover different attack

paths. In our case, the asset model analysis reveals

a possible attack path using the media communica-

tion, either through the BT or cellular interface. From

there, it can launch speciﬁc attack actions impacting

either integrity or availability. The analysis can be

performed on each of those security dimensions sep-

arately to be more modular. Figure 5 shows our anal-

ysis for integrity were both channels can be used to

take control of the gateway and then some spoofed

messages can be sent on the bus to make the lamp ac-

tuator believe the switch state has changed. This is

depicted by a OR-reﬁnement to compromise the nav-

igation system, although the risk might be different

for each path.

Figure 5: Analysis of the integrity attack paths.

4.4 Impact Rating (8.5)

The impacts have to be rated on four dimensions:

Safety, Financial, Operational and Privacy (SFOP)

(Sembera, 2020). In our case, there is no privacy im-

pact given the lights are publicly observable. Oper-

ation impact is major as it changes the expected be-

haviour of the car. There is also no direct ﬁnancial

impact although the image damage might have an im-

portant indirect impact of this kind. About the safety

impact, it can be rated in more details by reasoning

on the safety impact of each threat w.r.t. the modelled

safety goal stating lamps should be on at night:

• R1 - Unexpectedly turning lamps on: has no im-

pact on the driver but may surprise another driver.

• R2 - Unexpectedly turning lamps off : can have a

major impact if it happens at night.

• R3 - Impossibility to turn lamps off : has negligible

impact although it can drain the battery.

• R4 - Impossibility to turn lamps on: has moderate

impact because it requires to switch to a degraded

mode, i.e. stop driving, at nightfall.

4.5 Attack Feasibility Rating (8.6)

To rate the feasibility of an attack, the process is ﬁrst

to evaluate each path. Attack factors can be used to

rate each path against Time, Expertise, Knowledge,

Opportunity and Equipment factors. To support this,

we extended our tooling with the ability to capture

those attributes using a meta-model extension. The

various attack paths can be identiﬁed by looking at

the different paths leading to leaf nodes in the attack

tree. This can be implemented by a model query and

results in the table show in Figure 6. The resulting

table can be directly edited in our tooling.

The second step is to combine the factors de-

pending on the way the paths are combined: AND-

reﬁnement will require to consider the minimal feasi-

bility level while the OR-reﬁnement needs to consider

the maximal level. Note that other methods might be

considered to deal with a richer set of reﬁnement gates

but are not elaborated here.

Figure 6: Feasibility analysis of the attack paths.

Based on this analysis, both the spooﬁng attack on

integrity can be assessed to a medium level while the

impact of the DOS attack on availability is low.

Goal and Threat Modelling for Driving Automotive Cybersecurity Risk Analysis Conforming to ISO/SAE 21434

837

4.6 Risk Determination (8.9)

Based on the combination of the rating of impact and

feasibility, it is possible to locate each risk in a qual-

itative risk matrix by using feasibility as column and

impact as line, as shown in Table 1. This can be di-

rectly computed by the tool from information present

in the model and then exported to a text processor ta-

ble or spreadsheet (Ponsard et al., 2015).

Table 1: Safety Risk matrix for the light sub-system.

Very Low Low Medium High

Severe

Major R2

Moderate R4

Negligible R3 R1

4.7 Risk Treatment Decision

Finally, actions must be taken to reduce the risks be-

low an acceptable level. It can rely on tactics to ac-

cept, avoid, mitigate or transfer them. This step is not

elaborated here due to space limitations.

5 CONCLUSION & NEXT STEPS

In this paper, we showed how to conduct a cyber secu-

rity risk analysis in the automotive domain conform-

ing to the new ISO 21343 standard. The proposed ap-

proach is model-based and also integrates with safety

analysis in line with ISO 26262, opening the way to

safety and security co-engineering. It was demon-

strated on a generic goal-oriented toolset and illus-

trated on an automotive sub-system. Although lim-

ited in size, our case study could show the beneﬁts of

the approach related to the elicitation of threats, anal-

ysis of attack paths and assessment of risks. It also

has good automation, scalability and reuse possibili-

ties across sub-systems.

Based on this proof-of-concept, our next steps are

to elaborate the risk treatment phase and to consider

a larger case in the context of a on-going autonomous

driving project. We also plan to improve our tool sup-

port and move to a domain speciﬁc system engineer-

ing tool, more adequate for integration and adoption

in an automotive toolchain.

ACKNOWLEDGEMENTS

This work is partly funded by the CYRUS project of

the Walloon Region (nr 8227).

REFERENCES

ACWG (2018). Goal Structuring Notation Community

Standard, Version 2. The Assurance Case Working

Group https://scsc.uk/r141B:1?t=1.

ASRG (2020). ISO21434 by Example. Automotive

Security Research Group, https://www.youtube.com/

watch?v=3LsNx-ljIK8.

Hause, M. and Korff, A. (2007). An overview of sysml for

automotive systems engineers. ATZelektronik world-

wide, 2.

ISO (2011). ISO 26262-1:2011 Road vehicles — Func-

tional safety. https://www.iso.org/standard/43464.

html.

ISO (2018). Iso 31000, risk management - guidelines,

provides principles, framework. https://www.iso.org/

iso-31000-risk-management.html.

ISO (2020). ISO/SAE FDIS 21434 Road vehicles — Cy-

bersecurity engineering (draft). https://www.iso.org/

standard/70918.html.

Leopold, D. (2019). Relevance of iso 21434

for the automotive development process.

Itemis Blog https://blogs.itemis.com/en/

relevance-of-iso-21434-for-the-automotive

-development-process.

OMG (1997). Uniﬁed modeling language. http://www.omg.

org/spec/UML.

OMG (2005). System modeling language. http://www.omg.

org/spec/SysML.

Ponsard, C., Darimont, R., and Michot, A. (2015). Combin-

ing models, diagrams and tables for efﬁcient require-

ments engineering : Lessons learned from the indus-

try. In Actes du XXXIII

eme Congr

es INFORSID, Biar-

ritz, France, May 26-29, 2015, pages 235–250.

Ponsard, C., Grandclaudon, J., and Massonet, P. (2021).

A goal-driven approach for the joint deployment of

safety and security standards for operators of essential

services. Journal of Software: Evolution and Process.

Respect-IT (2005). The Objectiver Goal-Oriented Require-

ments Engineering Tool. http://www.objectiver.com.

SAE (2016). Cybersecurity Guidebook for Cyber-Physical

Vehicle Systems - J3061 201601. https://www.sae.

org/standards/content/j3061 201601.

Schmittner, C. and Ma, Z. (2015). Towards a framework

for alignment between automotive safety and security

standards. In Computer Safety, Reliability, and Secu-

rity, pages 133–143. Springer.

Sembera, V. (2020). Iso/sae 21434 - setting the standard for

connected cars’ cybersecurity. Trend Micro Research.

Shiho Kim, R. S. (2020). Automotive Cyber Security: Intro-

duction, Challenges, and Standardization. Springer.

van Lamsweerde, A. (2009). Requirements Engineering -

From System Goals to UML Models to Software Spec-

iﬁcations. Wiley.

Yu, E. and Mylopoulos, J. (1997). Enterprise modelling for

business redesign: The i* framework. SIGGROUP

Bull., 18(1):59–63.

SECRYPT 2021 - 18th International Conference on Security and Cryptography

838