Safety, Security and Performance Assessment of Security

Countermeasures with SysML-Sec

Bastien Sultan

, Ludovic Apvrille

and Philippe Jaillon

LTCI, T

ecom Paris, Institut Polytechnique de Paris, Sophia-Antipolis, France

Mines Saint-Etienne, CEA-Tech, Centre CMP, F - 13541 Gardanne, France

Keywords:

Formal Veriﬁcation, Impact Assessment, Countermeasures, Attacks, Safety, Security, Performance.

Abstract:

Deploying security countermeasures on Cyber-Physical Systems (CPS) can induce side-effects that can exceed

their beneﬁts. When CPS are safety-critical systems, performing efﬁciency and impact assessments of security

countermeasures early in the design ﬂow is essential. The paper introduces the W-Sec method, based on

SysML-Sec. The W-Sec method consists in two interwoven formal modeling and veriﬁcation cycles aiming

at providing countermeasures with objective and quantitative efﬁciency and impact assessments in terms of

safety, security and performance. The paper evaluates the W-Sec method with an autonomous rover swarm

case-study, and ﬁnally discusses the method’s strengths and weaknesses highlighted by the case-study results.

1 INTRODUCTION

Cyber-physical systems (CPS) can commonly act

on their environment with actuators. As a result,

a cyber attack on these systems can induce severe

safety consequences on their environment. Thus, for

these systems, bridging safety and security model-

ing and analysis is of prime importance to capture

the inter-relations between safety and security, lead-

ing to better designs and easing maintenance. This

joint safety/security modeling of complex systems

has become a trending research topic over the past few

years. In this context, the CAPE program

(one of the

four scientiﬁc programs of the European Union Hori-

zon 2020 project SPARTA) aims at providing meth-

ods for joint speciﬁcation and assessment of security

and safety properties for complex CPS.

Part of this program, the main contribution of the

paper, is a new method (called “W-efﬁciency and im-

pact assessment method”, W-Sec method for short)

targeting the selection of the right security counter-

measures

for CPS. By relying on the modeling for-

malisms and tools supporting the SysML-Sec frame-

Continuous Assessment in Polymorphous Environ-

ments.

In this paper, a security countermeasure is any modiﬁ-

cation brought to a system in order to mitigate one or several

vulnerabilities. This modiﬁcation can be related to the sys-

tem’s software, hardware, processes, and/or to its physical,

logical and network architecture.

work (Apvrille and Roudier, 2013), our contribution

can now improve the impact assessment method in-

troduced in (Sultan et al., 2018). The W-Sec method

brings two main improvements to this method: (i) re-

ducing models complexity while enhancing the model

precision for hardware and security aspects and (ii)

widening its assessment basis through more ﬁne-

grained security analyses. Formal models of W-Sec

include two abstraction levels: component and over-

all system levels, from which formal veriﬁcation of

safety, security and performance can be performed.

The rest of the paper is organized as follows. Sec-

tion 2 gives an overview of the related works. Then

Sect. 3 introduces the W-Sec method. Section 4

presents the autonomous rover swarm case-study, in-

cluding the attack scenarios and countermeasures, we

used to evaluate the W-Sec method. It also presents

the formal models we have designed: (1) a joint

rover hardware and software model, and (2) a platoon

model allowing to represent rovers’ high-level behav-

ior and interactions within the swarm. Last, Sect. 5

discusses the results of the W-Sec method applied to

the rovers platoon case-study.

2 RELATED WORKS

The interest of assessing efﬁciency and impact of se-

curity countermeasures before their deployment has

been discussed for a long time (Brykczynski and

Sultan, B., Apvrille, L. and Jaillon, P.

Safety, Security and Performance Assessment of Security Countermeasures with SysML-Sec.

DOI: 10.5220/0010832300003119

In Proceedings of the 10th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2022), pages 48-60

ISBN: 978-989-758-550-0; ISSN: 2184-4348

Small, 2003; Nicol, 2005) and several ways to select

countermeasures have been proposed. (Nespoli et al.,

2017) provides a survey on the optimal countermea-

sures selection methods proposed between 2012 and

2016. Regarding the countermeasures’ (negative) im-

pacts, these approaches mainly focus on the monetary

cost of the countermeasures, yet several of them ex-

press the impacts in terms of system downtime or im-

pacts on the provided services, e.g. in terms of conﬁ-

dentiality, integrity, availability and performance. De-

pending on the methods, these impacts can be used

as inputs of the selection method (thus they are not

computed on the basis of the countermeasure descrip-

tion but chosen on the basis of a human analysis),

or computed. However, even if the “collateral dam-

age” (Gonzalez-Granadillo et al., 2015) are assessed

by some of the surveyed approaches, none of them

seem to allow for a precise enough countermeasures

impact assessment with respect to the behavior of the

system, which is critical regarding CPS. For instance,

when assessing a software patch affecting the driving

controller of an autonomous car, it is crucial to quan-

tify how the speed or steering set points can be mod-

iﬁed as well as to evaluate the availability of the con-

troller. Incidentally, to the best of our knowledge, few

research works published after this survey address the

ﬁnding of precise and objective impact assessments

for countermeasures.

Among them, (Sultan et al., 2018) proposes a for-

mal veriﬁcation-based impact assessment method for

security countermeasures, in the context of naval sys-

tems. This method relies on a network of UPPAAL

timed automata (NTA) (Behrmann et al., 2004) used

to model a cyber-physical system. When a vulner-

ability affecting the modeled system is discovered,

NTA is mutated into a set of mutant NTAs repre-

senting (i) the vulnerable system, (ii) the vulnerable

system enhanced with security countermeasures mit-

igating the vulnerability, (iii) the realization of suc-

cessful attacks on the original vulnerable system, and

(iv) the realization of these attacks on the “patched”

systems. Afterwards, the NTA (modeling the CPS)

and the mutant NTAs (modeling the CPS affected by

the cyber events) are model-checked against a set of

properties: the impacts of the cyber events and the ef-

ﬁciency of the countermeasures can then be deduced

by comparing the model-checks results. However, as

the authors explain in (Sultan, 2020), the underlying

modeling framework lacks in expressiveness with re-

spect to data security aspects (e.g., data conﬁdential-

ity is modeled in a simplistic way by a boolean vari-

able depicting an illegitimate access to the the com-

ponent which processes the data). Therefore, the rel-

ative security properties veriﬁcation results may be

not accurate enough. In addition, establishing a ﬁne-

grained modeling with timed automata can be time-

consuming and error-prone, and the resulting models

can be complex to understand as they encompass het-

erogeneous aspects in a single modeling view.

Addressing these ﬂaws requires requires more ap-

propriate modeling formalisms and tools. Provid-

ing a framework for designing safe and secure em-

bedded systems, the SysML-Sec method (Apvrille

and Roudier, 2013) relies on an enhanced SysML-

based modeling formalism that allows for model-

ing high-level system architectural and behavioral as-

pects, as well as ﬁne-grained hardware ones. More-

over, SysML-Sec is tailored to produce joint safety,

security and performance analyses (Apvrille and Li,

2019) and is fully supported by the toolkit TTool, that

provides the system designers with a graphical and

easy-to-use modeling and veriﬁcation interface. In

addition, it also provides distinct modeling views that

can help simplifying the system models. For these

reasons, we believe that the SysML-Sec language and

TTool are the best underlying formalism and toolkit

for enhancing the method proposed in (Sultan et al.,

2018). Furthermore, another reason for choosing this

formalism and tools is that our contribution can also

complement the SysML-Sec method. Indeed, the at-

tack model considered by this method is the Dolev-

Yao one (Dolev and Yao, 1983), thus other kinds

of attacks such as “sequence[s] of exploitation of

vulnerabilities of several components” (Apvrille and

Roudier, 2013) are considered out of scope. Thanks to

the introduction of the modular attack scenarios like

in (Sultan et al., 2018), our contribution then widens

the considered attack corpus.

3 W-SEC METHOD

The method introduced in this section (see Fig. 1),

called W-efﬁciency and impact assessment method

(or W-Sec method for short), relies on two interwo-

ven modeling and veriﬁcation cycles aiming at (i) de-

signing relevant models of a complex system and (ii)

providing efﬁciency and impact assessments of coun-

termeasures in terms of safety, security and perfor-

mance. The following paragraphs describe its stages.

3.1 System Modeling

Like in (Sultan et al., 2018), a comprehensive model-

ing of the whole system is ﬁrst built. However, unlike

this approach, our modeling approach does not rely on

a single network of timed automata (NTA). The sin-

gle model approach indeed has two main drawbacks:

Safety, Security and Performance Assessment of Security Countermeasures with SysML-Sec

Components models

(HW/SW par-

titioning)

Attack scenarios

+ Countermea-

sures description

System model

+ all test scenarios

(High-level design)

Components models

+ Attacks

+ Countermeasures

Regression

assessment

(w.r.t. performance)

Security assessment

System model

+ Countermeasures

+ all test scenarios

System model

+ Attacks

+ relevant test sc.

System model

+ Attacks

+ Countermeasures

+ relevant test sc.

System model

+ Attacks

+ Countermeasures

+ relevant test sc.

Regression

assessment

(w.r.t. safety)

Efﬁciency

assessment

(w.r.t. safety)

: Model enrichment

: Simulation (with TTool internal simulator)

: Model-checking (with ProVerif)

: Model-checking (with TTool internal model-checker)

: Feedback to components, system, countermeasures and attacks models

Figure 1: The W-Efﬁciency and Impact Assessment Method.

ﬁrst, it requires the modeling of heterogeneous items

(e.g. software and hardware) and aspects (e.g., data

security and system safety) with the same formalism.

As a result, the modeling effort can be substantial and

the model can lack in precision with respect to one of

the modeled aspects, for instance data security as dis-

cussed in Sect. 2. Second, formal veriﬁcation or sim-

ulation of such a model may be pointlessly complexi-

ﬁed when evaluating safety, security and performance

properties (e.g., the output values of an algorithm can

be needed when analyzing its safety, while they can

be useless when assessing its performance). To tackle

these two issues, we have chosen to rely on two dis-

tinct modeling views provided by TTool and used in

the SysML-Sec method, thus capturing the systems

high-level and low-level aspects with more precision

and facilitating the separation of concerns. One view

targets the hardware/software (HW/SW) partitioning

at a component level. We use it to precisely model

the system’s components (e.g., a PLC, a workstation,

etc.), and we have chosen to carry out the perfor-

mance and security assessments in this view: hard-

ware modeling is obviously needed to assess a sys-

tem’s performance, and veryﬁng the security prop-

erties we want to assess (i.e., integrity, authenticity

and conﬁdentiality of data when transferred between

two components or processed by a component) means

verifying a resistance to attacks, including hardware-

related attacks (e.g. putting a probe on a bus). This

view includes models relying on SysML-Sec block

diagrams, sequence diagrams and activity diagrams.

The other view is dedicated to high-level system de-

sign. We use it to model the system overall behav-

ior and architecture, and to perform the safety assess-

ments at system level. This view relies on SysML-Sec

block diagrams and state machine diagrams.

1. The HW/SW partitioning view is used to

model the system’s components low-level applica-

tion architecture and behavior, as well as their sup-

porting hardware platforms. In this view, each com-

ponent is modeled thanks to three models (Enrici

et al., 2017) depicting its functions

, its hardware

platform, and the communication protocols it uses for

data transfer between its hardware subcomponents

(i.e., DMA transfer protocols). These three models

Note that the functional model focuses both on the ex-

change of information between applicative tasks and on the

computational cost of algorithms (i.e. actual arithmetic op-

erations are not modeled). For instance, if a task receives

a value and then performs a multiplication by 2, the activ-

ity diagram of this task contains a read action in a channel

followed by a one-multiplication complexity operator.

In this paper, a hardware subcomponent refers to the

hardware nodes that are used in SysML-Sec to model hard-

ware architectures (e.g., CPUs, memories, FPGAs).

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

are then linked in a fourth one (the mapping model)

which assigns software tasks to CPUs, communica-

tion protocols between memories, etc. In addition,

in order to assess the external communications secu-

rity, we integrate a simple model of the communica-

tion interfaces with the components modeling (e.g.,

a socket in the functional model and a network in-

terface controller in the hardware model) belonging

to the external components with which the compo-

nent communicates. Thus, the models of this view

are built on the basis of the information that is neces-

sary to precisely depict the software and hardware ar-

chitecture of the modeled components, as well as the

low-level security (i.e., cryptographic algorithms, pri-

vacy of the hardware buses, memories for key storage,

etc.) and performance (e.g., algorithm computational

cost and hardware platform speciﬁcation) aspects. Fi-

nally, this view also features the security and perfor-

mance properties. These properties are established in

parallel with the HW/SW partitioning models design.

Their veriﬁcation enables to assess the low-level se-

curity and performance impacts of countermeasures

and attacks.

2. The High-level system design view is used to

model the system high-level architecture

and behav-

ior, with a focus on the interactions between system

components and on the system’s descriptive variables

(e.g., for a rover, its speed and coordinates) evolution.

Then the relevant arithmetic parts of the components

algorithms can be modeled and even system dynamics

(e.g. simpliﬁed modeling of speed and position) can

be abstracted through integer variables

. Therefore,

the information basis used to build the system model

encompasses the relevant information at system-level

(e.g., regarding system’s functions, dynamics and net-

work topology), and, if needed, at component-level in

order to depict the high-level behavior of the compo-

nents algorithms (i.e., the evolution of their output pa-

rameters depending on their inputs). In other words,

we exclude from these models the the low-level hard-

ware, security and algorithmic complexity aspects. In

addition, the safety properties at system-level, estab-

lished in parallel with the system model design, are

captured in this view. Their veriﬁcation enables to

assess the high-level safety impacts of countermea-

sures and attacks. Note that if several test scenarios

are needed to evaluate all these properties, then sev-

eral system models must be built, i.e. one per test

scenario.

Last, note that in the current state of our research,

the semantic links between the HW/SW partitioning

i.e., the relations between the system’s components.

Note however that only simple dynamics can be mod-

eled in this way.

models and the high-level system design models are

not explicit, thus it falls to the user to ensure the con-

sistence of the models of both views while designing

them.

3.2 Integrating Attacks and

Countermeasures through

Enrichment of Models

The second stage of our method consists in integrating

the attacks and countermeasures with the models of

both views (high-level system design view, HW/SW

partitioning view). This integration consists in mod-

eling the attacks and countermeasures in SysML-Sec,

and then, in the current state of our works, to manu-

ally compose these new models with the pre-existing

system and components models. For instance, a coun-

termeasure consisting in encrypting a given commu-

nication channel can be modeled in the HW/SW par-

titioning view with two encrypt and decrypt SysML-

Sec actions: this countermeasure is thus integrated

with the models by adding the encrypt/decrypt ac-

tions before and after the relevant pre-existing send

and receive actions in the pertinent SysML-Sec activ-

ity diagrams. In the same way, attacks can for in-

stance be modeled in the high-level system design

view through a SysML-Sec block (which state ma-

chine diagram models the successive attack stages)

that is then bound to the relevant pre-existing blocks

in the enriched models, and if needed through a mod-

iﬁcation of the state machines of these blocks (in or-

der to model the behaviors that are now possible due

to the attack). Note that due to the absence of in-

teger variables in the HW/SW partitioning view, the

repercussions of attacks on the outputs of the system

algorithms, or on the system dynamics, can only be

modeled in the high-level system design view.

Like the NTA in (Sultan et al., 2018), the high-

level system models are turned into the following

three classes of models (see Fig. 1):

• System models with countermeasures. As we want

to assess the potential regression due to the counter-

measures with respect to each test scenario, we pro-

duce one model per countermeasure and per sce-

nario, i.e., if we have m test scenarios and n coun-

termeasures, m × n models are built.

• System models with attacks. For each attack, we

select the relevant test scenarios

then one model is

produced per selected test scenario.

i.e., the system conﬁgurations on which we want to as-

sess (i) the attack safety impacts and (ii) the related coun-

termeasures efﬁciency.

Safety, Security and Performance Assessment of Security Countermeasures with SysML-Sec

• System models with attacks and countermeasures.

For each countermeasure (as a patch can actu-

ally mitigate several attacks), we build a “patched”

model for every element of the system models with

attacks subset. In other words, if we have p system

models with attacks and n countermeasures, p × n

models are built.

In addition, the models of the HW/SW partition-

ing view are also turned into a set of new models. For

each countermeasure, and for each component tar-

geted by the countermeasure, the component’s func-

tional model is enriched to integrate the countermea-

sure. Then, an attack scenario leading to the counter-

measure triggering is integrated with this new model.

3.3 Performing Safety, Security and

Performance Assessment

The third and last stage of the method consists in per-

forming simulation and formal veriﬁcation of the pre-

viously enriched models.

We carry out security and performance assess-

ments on the models of the components (i.e., of

the HW/SW partitioning view). First, simula-

tions are performed with the TTool HW/SW simu-

lator (Apvrille et al., 2006). These simulations pro-

vide, both for the “nominal” component model and

for the component with countermeasures models, a

set of performance assessments (e.g., the number of

CPU clock cycles for a given algorithm). Thanks to

the comparison of these results the additional com-

plexity of the modeled countermeasures can be eval-

uated, with respect to the hardware platform and in

terms of clock cycles or elapsed time. Second, the se-

curity properties are veriﬁed with ProVerif (Blanchet,

2001) thanks to an integrated HW/SW partitioning

models to ProVerif speciﬁcation translation (Li, 2018;

Lugou et al., 2016), once again both for the “nom-

inal” component model and for the component with

countermeasures models. Note that if the security and

performance assessments show that the component’s

high-level behavior is modiﬁed by the evaluated coun-

termeasure (e.g., if this countermeasure leads to com-

putational overhead that excessively delays the out-

puts of the component’s algorithms), the models of

the high-level system design view may be adjusted in

order to take these modiﬁcations into account as they

can impact the system’s safety. In that case, the safety

assessments (see below) shall be carried out on these

adjusted models.

In addition, the system models (i.e., of the high-

level system design view) are checked with the TTool

internal model-checker (Calvino and Apvrille, 2021)

against the safety properties. As in (Sultan et al.,

2018), these safety veriﬁcation operations aim at:

• evaluating functional regressions induced by coun-

termeasures by comparing the results of the veriﬁ-

cations of the system models with countermeasures

and the “nominal” system models designed at the

ﬁrst step.

• and then, from the comparison of the results of the

model-checking of the system models with attacks

and the system models with attacks and counter-

measures, assessing the countermeasures ability to

mitigate the attacks.

At the end of this stage, we obtain a set of evalu-

ations that enables to determine the subset of the in-

put attacks that can be effective on the system, and

to determine the optimal countermeasure or combina-

tion of countermeasures. If the impact and efﬁciency

assessments show that no countermeasure is satisfac-

tory, the models of both views can incrementally be

modiﬁed and re-assessed until they verify the desired

properties: in this way, the modeled countermeasures

can be improved and then modiﬁed/developed to be

deployed on the system.

3.4 Improvements Brought by the

Method

Table 1: Comparison with SysML-Sec and (Sultan et al.,

2018)

Modeling formalism From SysML-Sec

and (Enrici et al.,

2017)

Two-views modeling From SysML-Sec

Separation in two views of

safety at system-level vs. se-

curity and performance as-

pects

W-Sec method con-

tribution

Use of HW/SW partitioning

view for low-level compo-

nent modeling

W-Sec method con-

tribution

Attacks and countermea-

sures modeling through

model enrichment

From (Sultan et al.,

2018)

Impact assessment approach From (Sultan et al.,

2018)

As explained hereinabove, the W-Sec method uses

elements from SysML-Sec and (Sultan et al., 2018)

(see Table 1). By merging these two approaches, the

method brings several improvements to each of them.

Indeed, with regards to (Sultan et al., 2018):

• The W-Sec method reduces the models complex-

ity because it does not rely on a single NTA but on

several models that can separately be simulated and

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

veriﬁed. These models are based on two distinct

views which only contain the information needed

for their respective purposes (i.e., safety assess-

ment at system-level or security and performance

assessment), and do not aggregate all this informa-

tion in a single view.

• Hardware modeling relies on conﬁgurable tem-

plates already deﬁned in TTool (CPU, memories,

DMA, etc.) so it helps reducing the modeling time

and effort, while giving more precision to the mod-

els with respect to the NTA approach.

• Low-level security aspects can be captured in a

more ﬁne-grained way. In addition, this low-level

security modeling is facilitated thanks to TTool

predeﬁned security-related patterns (e.g., crypto-

graphic algorithm models or hardware ﬁrewall

blocks).

• Thanks to the simulation and veriﬁcation tools pro-

vided by TTool, our approach assesses the impact

of countermeasures and attacks, with respect to a

widened property basis. Indeed, we can now eval-

uate ﬁne and low-level security properties (e.g., re-

lated to the integrity of a data transfer, or the conﬁ-

dentiality of a component data).

Furthermore, the W-Sec method completes the

SysML-Sec method thanks to the integration of mod-

ular attack scenarios like in (Sultan et al., 2018).

When designing a countermeasure, the W-Sec method

can therefore be used before the SysML-Sec design

stage.

4 THE AUTONOMOUS ROVER

PLATOON CASE-STUDY

4.1 Description of the Case-Study

4.1.1 The Platoon and its Rovers

The case-study relies on the SPARTA/CAPE Con-

nected and Cooperative Cars system (Dupont et al.,

2020). In concrete terms, we consider a platoon com-

posed of three vehicles (one leader and two follow-

ers) driving in cooperative adaptative cruise-control

(CACC) mode. The three vehicles we model are au-

tonomous rovers designed by Fortiss in cooperation

with Tecnalia (Dupont et al., 2020; Martinez et al.,

2021; L

ucio et al., 2018). The hardware architecture

of these rovers relies on two Raspberry Pi 3B+ (one

for the driving algorithms and the other one for pro-

cessing images produced by the camera), three kinds

of sensors (a camera, a LIDAR and ultrasonic dis-

tance sensors), a DC motor and a steering servo mo-

tor. In a CACC mode, a rover can act as a leader. In

that case, the rover regulates its speed and trajectory

using information received by its sensors. If a rover

is a follower, then it has to adapt its speed according

to the speed value received from the leader and gap

information received from its sensors, and its trajec-

tory according to the sensed information. It shall also

brake whenever it receives an emergency brake (EB)

message from the leader. Note that in our model we

assume that a follower only relies on the speed value

received from the leader to adapt its speed.

In order to assess the impact of attacks and coun-

termeasures on safety, we have selected three sce-

narios derived from the Basic Scenario described

in (Martinez et al., 2021) (“the platoon [...] navigates

on a straight road” and “the goal of [an attacker] is to

cause a crash between two legitimate vehicles”). We

also assume that communications between vehicles

are not signed nor timestamped, and that the leader

only sends speed update or emergency brake (EB)

messages to the followers. Our three platooning sce-

narios and can be summarized as follows (see Fig. 2):

(a) a simple scenario where the three rovers run in

a straight lane. The leader (Rover

) continuously

sends its speed value to the followers (Rover

and

Rover

) so that they can adapt their speed on the

basis on the received value. In this scenario, the

leader can keep a constant speed (scenario (a

)),

decelerate (scenario (a

)) or accelerate (scenario

)).

(b) a scenario where a vehicle crosses the platoon lane

in front of the leader. In the ﬁrst steps of the sce-

nario, the leader sends its speed value to the fol-

lowers like in scenario (a). Then, when the vehicle

crosses the lane, the leader detects it, brakes and

sends EB messages to the followers. Last, when

the vehicle has ﬁnished to cross the lane, the leader

restarts and sends its speed value to the followers.

) leaves the pla-

toon. It joins the leaving rovers lane and sends a

leaving message to the followers. The immediate

following vehicle (Rover

) becomes the new leader

and continuously sends its speed value to its fol-

lower (Rover

4.1.2 Attack Scenarios and Countermeasures

In addition to these platooning scenarios, we have

implemented four of the attack scenarios described

in (Martinez et al., 2021). We consider a Dolev-

Yao (Dolev and Yao, 1983) adversary model: an at-

tacker can thus eavesdrop, modify, block or inject

Safety, Security and Performance Assessment of Security Countermeasures with SysML-Sec

Rover

(ﬂwr)

Rover

(ﬂwr)

Rover

(ldr)

Platoon lane

(a) Simple scenario

Rover

(ﬂwr)

Rover

(ﬂwr)

Rover

(ldr)

Platoon lane

(b) Crossing vehicle scenario

Rover

(ﬂwr)

Rover

(ldr)

Rover

(leaving)

Platoon lane

Leaving

rovers lane

Figure 2: CACC Platoon Scenarios.

messages. Attacks are:

• Attack 1: the attacker modiﬁes the speed update

messages sent by the leader to the followers by

adding a large deviation to the legitimate value.

• Attack 2: the attacker modiﬁes the speed update

messages sent by the leader to the followers by

adding a small deviation to the legitimate value.

• Attack 3: the attacker injects false EB messages

bound for the ﬁrst follower. In our implementation,

the attacker performs this attack by changing the

speed update messages sent to the ﬁrst follower into

EB messages.

• Attack 4: the attacker blocks the EB messages sent

by the leader to the followers. In our implementa-

tion, this attack is performed by changing the EB

messages into speed update messages.

We also have implemented several countermea-

sures in order to mitigate these attacks. They can be

classiﬁed into two groups:

• Plausibility Checks

Speed Plausibility Check: this countermeasure

has been introduced in (Martinez et al., 2021) and

consists in checking if the speed update value re-

ceived by the followers “deviates from a given per-

centage w.r.t. the average of the last n speed values

received by the vehicle” (Martinez et al., 2021). If

it is the case, the message is discarded and the rover

relies on the last legitimate received speed value to

elaborate its actuators commands.

Emergency Brake Plausibility Check: (Martinez

et al., 2021) mentions a sensor-based plausibility

check. We have chosen to implement such a coun-

termeasure, working as follows: (1) when the ﬁrst

EB message is received, the follower checks if the

three next gap measurements decrease. If it is not

the case, the EB message is discarded. If it is the

case, the EB message is considered as legitimate,

the rover brakes and the current gap measurement

is recorded. (2) When the next EB message is re-

ceived, it is considered as legitimate if the current

gap measurement is less than or equal to the previ-

ously recorded gap measurement

. If it is not the

case, the recorded gap measurement will be set to

0 and the successive gap checks will be performed

as for the ﬁrst iteration.

Emergency Brake Plausibility Check with Gap

Check: as the previous countermeasure can re-

sult in platoon crashes under certain conditions (see

Sect. 5), we have designed an alternative version

enhanced with an additional safety check. Before

each speed order is sent to the actuators, this safety

check veriﬁes if the gap measured ahead of the

rover is greater than a given threshold. If it is not

the case, an emergency brake is performed.

• Cryptographic Countermeasures: these counter-

This check is performed in order to avoid a crash be-

tween the leader and the ﬁrst follower if the leader sends

two successive legitimate EB messages (e.g., if a slow ve-

hicle crosses the road ahead of the leader).

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

measures have been proposed by (Li, 2018), in a

context of autonomous connected vehicles security.

MAC: for each message sent by the leader, a mes-

sage authentication code (MAC) is added in order

to allow the followers to check the messages au-

thenticity and integrity.

Symmetric Encryption with Nonce Exchange:

for each message sent by the leader to a given

follower, a nonce is exchanged and then the mes-

sage is encrypted with a symmetric encryption al-

gorithm (AES) and the nonce is concatenated. This

countermeasure ensures conﬁdentiality of the mes-

sages, provides anti-replay protection and allows

the followers to check their authenticity and in-

tegrity.

If the integrity/authenticity check fails, the rover re-

lies on the last legitimate received message to elab-

orate its actuators commands.

4.2 Modeling the Platoon

Platoon net-

work model

Rover

soft-

ware model

...

Rover

soft-

ware model

Rover

dy-

namics model

...

Rover

dy-

namics model

Environment

model

Attackers models

Countermeasures

models

Figure 3: Structure of the platoon model (High-level system

design proﬁle).

In this case-study, we consider that the system is the

platoon, and its components are the rovers. Thus, the

platoon model we have built (in the high-level sys-

tem design view) relies on four kinds of SysML-Sec

blocks (see Fig. 3):

• The Rover Software Models. These blocks depict

the high-level logic behavior of the rovers: their

state-machines model the network communications

and the driving algorithms. But since they are high-

level models, the algorithms are not represented in

a ﬁne-grained way: e.g., we do not model the PID

control loops and we consider that, for a given con-

trolled parameter (e.g., speed), the command val-

ues are directly equal to the ﬁnal set point val-

Proportional, Integral, Derivative control, elaborating

a command relying on the current, past and foreseen error

values.

idle

PlausibilityCheckIn(messageType, messageContent)

sendingCheckedMessage

PlausibilityCheckOut(messageType, messageContent)

[10*messageContent < 13*averageSpeed]

leaderSpeed1 = leaderSpeed2

leaderSpeed2 = leaderSpeed3

leaderSpeed3 = messageContent

[else]

messageContent = leaderSpeed3

averageSpeed = (leaderSpeed1 + leaderSpeed2 + leaderSpeed3)/3

checkingSpeedValue

Figure 4: State machine of a block modeling the Speed

Plausibility Check.

ues and the actuators directly reach these command

values.

• The Rover Dynamics Models, used to abstract the

evolution of the rover’s coordinates and gap value

(ahead of the robot). For each rover, the software

model block and the dynamics model block ex-

change signals through their SysML ports, in order

to simulate the rover’s sensors acquisition cycle.

• The Platoon Network Model. This block mod-

els the communications between the leader and its

followers. To this end, the rover software model

blocks exchange signals with the network block

through their bound SysML ports: in our model,

a communication between two robots Rover

and

Rover

will be modeled by two successive signals

exchanges Rover

software model → platoon net-

work model → Rover

software model.

• The Environment Model, intended to link the

rover dynamics model blocks through bound

SysML ports. Thanks to this block, the rover dy-

namics models exchange their coordinate values in

order to update their gap value.

Note that in order to make the platoon model eas-

ily scalable, we have deﬁned two libraries (i.e., block

patterns that can be instantiated through “regular”

blocks) depicting the rover-related models. Actually,

the rover software model and rover dynamics model

blocks are instances of these two libraries.

In addition, the attacks have been modeled by

enriching the platoon network model block, and the

countermeasures have been depicted through enrich-

ments of the rover software model library (see Fig. 3),

or by adding countermeasure blocks bound to the

Safety, Security and Performance Assessment of Security Countermeasures with SysML-Sec

rover software model instances (see Fig. 4). Given

our test scenarios, attacks and countermeasures, we

have built 50 distinct platoon models.

4.3 Modeling the Rover

In this case-study, we consider that a rover is a compo-

nent. As seen in Sect. 3, a SysML-Sec HW/SW parti-

tioning model consists in four distinct “sub-models”.

Therefore, we have designed the following models in

order to depict our rover:

• The Rover Functional Model. We have mod-

eled the driving algorithms, including message ex-

changes and interpretation, data fusion from the

sensors, PID controllers for speed and heading and

emergency brake controller. The functional model

also includes an abstraction of the sensors’ behav-

ior (i.e., continuous data sending) as well as an ab-

straction of the actuators behavior (i.e., continuous

data reception).

• The Rover Platform Model. Our hardware model

mainly focuses on the Raspberry Pi dedicated to ex-

ecute the driving algorithms

. We have modeled

the Raspberry SoC (with a 4-core CPU, a GPU,

a DMA controller, a bus and a memory block) as

well as the sensors and actuators (with CPU, bus

and memory blocks). The I/O devices (sensors and

actuators) are linked to the SoC through a main bus

and bridges.

• The Communication Model. We assume that the

Raspberry Pi SoC and the I/O devices communi-

cate through DMA transfer protocols.

• The Mapping Model, bridging the three previous

ones.

In addition, we have modeled the attack scenar-

ios and countermeasures by adding tasks to the rover

functional model and by modifying the pre-existing

tasks. Note that the countermeasures algorithms have

been modeled according to the worst-case perfor-

mance, i.e. if, for a given algorithm, the number of

executed instructions depend on the value of a given

input variable, we always consider that this variable

is set to a value leading to the highest number of ex-

ecuted instructions. Given our test scenarios, attacks

and countermeasures, we have built 6 distinct rover

models.

Table 2: Veriﬁcation results for security properties.

Contermeasure

Property Weak

auth.

Strong

auth.

No countermeasure 7 7

MAC 3 7

Symm. Encr. + Nonce 3 3

Speed Plausibility Check 7 7

Emergency Brake PC 7 7

EB PC with Gap Check 7 7

5 RESULTS AND DISCUSSION

This section discusses the application of the third

stage of our method, i.e. assessing the impacts and ef-

ﬁciency of countermeasures thanks to the simulation

and veriﬁcation of these models. We have veriﬁed and

simulated the behavior of our rovers on 21 consecu-

tive operating cycles

. This number of operating cy-

cles has been chosen to suit the hardware limitations

of the computer we used to verify the models: as the

models of the high-level system design view rely on

unbounded integer variables (coordinates and gaps),

the veriﬁcation computational cost increases with the

number of rovers operating cycles. Apart from lim-

iting the number of operating cycles, other strategies

could have been used to handle the combinatory ex-

plosion, such as bounding the evolution of variables.

However, the 21 operating cycles were enough to sim-

ulate all platooning scenarios, to identify one rover

collision for each attack, and to observe impacts of the

selected countermeasures, thus providing the safety,

security and performance results to evaluate our ap-

proach.

5.1 Performance Assessment

Performance assessment aims at comparing the over-

head cost, in terms of operating cycles duration, of the

countermeasures. In order to carry out performance

measurements, two breakpoints have been added in

the rover functional model of the HW/SW partition-

ing view. The ﬁrst one is placed on the “read in chan-

nel” action modeling a leader message reception, and

the second one on the “read in channel” action mod-

eling the reception of a power command by the actua-

tors. Thus, if the ﬁrst breakpoint is reached after n ns

and the second breakpoint is reached after m ns, then

it takes m −n ns for the rover to perform an operating

Since the countermeasures will be mapped to this Ras-

bperry Pi, its SoC constitutes our target of evaluation.

An operating cycle is the sequence of actions starting

at the reception of sensed data and/or a leader message and

ending at the next command execution by the actuators.

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

cycle. We have then measured this difference for each

of the 21 operating cycles and for each rover conﬁgu-

ration (i.e. the “unpatched” and the 5 “patched” con-

ﬁgurations).

To have a fair comparison, we have also enforced

the following for the patched rover model:

• to integrate to each rover model an attack scenario

systematically leading to the use the countermea-

sure

• to model the countermeasures so that they always

lead to the driving actions (i.e., always elaborate

speed and trajectory commands).

Table 3: Average elapsed time between the two consecutive

breakpoints (ns).

Without any countermeasure 274

With MAC 1,019

With Symm. Encryption + Nonce 646

With Speed Plausibility Check 357

With Emergency Brake PC 344

With EB PC with Gap Check 391

Table 3 gives, for each rover conﬁguration (i.e.,

with or without countermeasures), the average du-

ration of the operating cycles, and thus the induced

overhead. These durations are consistent with our

expectations: the cryptographic countermeasures in-

duce more operations, thus they imply has a higher

computation cost than the plausibility checks. Yet,

these overhead costs are all acceptable since acqui-

sition cycles of the rover’s sensors are far greater

than these values (the minimal acquisition cycle be-

ing 3,704 μs (Dupont et al., 2020; Garmin, 2016)).

Therefore, with respect to performance aspects, all

the countermeasures are compatible with the perfor-

mance requirements of the rovers.

5.2 Security Assessment

Given the chosen attack scenarios (i.e., modiﬁcations

of the messages exchanged between the leader and

the followers), we have decided to evaluate the secu-

rity of the followers’ incoming communications. To

this end, we have integrated a simple software task

simulating the leader’s network behavior, and a sim-

ple leader hardware model on which this task is ex-

ecuted, with the models of the HW/SW partitioning

view. This hardware model is linked to the rover’s one

through a public bus: this bus depicts the unprotected

platoon network. The software task is linked to the

rover’s tasks through two communication channels.

We have assessed the two following properties related

to the downlink channel: Weak authenticity (i.e. in-

Table 4: Safety properties veriﬁcation results.

Scenario

Attack

No att. Att. 1 Att. 2 Att. 3 Att. 4

Scenario (a

) —

Scenario (a

) — —

Scenario (b) — —

Scenario (c) — — — —

(a) Without countermeasure

Scenario

Attack

No att. Att. 1 Att. 2 Att. 3 Att. 4

Scenario (a

) —

Scenario (a

) — —

Scenario (b) — —

Scenario (c) — — — —

(b) With Speed Plausibility Check

Scenario

Attack

No att. Att. 1 Att. 2 Att. 3 Att. 4

Scenario (a

) —

Scenario (a

) — —

Scenario (b) — —

Scenario (c) — — — —

Scenario

Attack

No att. Att. 1 Att. 2 Att. 3 Att. 4

Scenario (a

) —

Scenario (a

) — —

Scenario (b) — —

Scenario (c) — — — —

(d) With Emergency Brake PC + Gap Check

Scenario

Attack

No att. Att. 1 Att. 2 Att. 3 Att. 4

Scenario (a

) —

Scenario (a

) — —

Scenario (b) — —

Scenario (c) — — — —

(e) With MAC or with Symm. Encr. + Nonce Exchange

tegrity), and Strong authenticity (i.e. data integrity

and data origin authenticity). Indeed, these two prop-

erties indicate, respectively, if an attacker could fal-

sify a message, and if an attacker could falsify and/or

replay a message, without the follower being able to

detect any of these attacks.

The veriﬁcation results are given in Table 2. They

conﬁrm that the implementation of the MAC counter-

measure provides the rover’s incoming network com-

munications with weak authenticity, while the imple-

mentation of the Symmetric Encryption with Nonce

Exchange ensures a strong authenticity. Therefore,

with respect to the security requirements, the latter

should be selected.

5.3 Safety Assessment

We have chosen to focus our safety assessment on the

two most critical safety properties of the platoon: (i)

the gap between Rover

and Rover

is always strictly

positive and (ii) the gap between Rover

and Rover

is always strictly positive (i.e., no crash can occur be-

tween Rover

and Rover

, and between Rover

and

Rover

). The veriﬁcation of these properties enables

to evaluate if the attacks (which aim is to cause a pla-

toon crash) are successful on the rovers, if the coun-

termeasures can actually mitigate them, and if they

could lead to the worst regression (i.e., a crash under

Safety, Security and Performance Assessment of Security Countermeasures with SysML-Sec

nominal driving conditions)

. Table 4 summarizes

the veriﬁcation results for each rover conﬁguration.

Each cell depicts the results for a given hplatooning

scenario, attack scenarioi pair, and is divided into two

subcells: the ﬁrst subcell represents the property 1

veriﬁcation, and the second the property 2 veriﬁca-

tion. If the subcell is green, then the property is veri-

ﬁed; if the subcell is red, the property is not veriﬁed.

For instance, Table 4 (a) indicates that when attack 3

occurs in platoon scenario (b), there is no crash be-

tween Rover

and Rover

, but a crash occurs between

Rover

and Rover

. According to these results:

None of the countermeasures leads to a safety

regression under normal conditions (see the “No at-

tack” column of each table).

Speed plausibility check only mitigates attack 1

in scenario (a

). That seems consistent since this

countermeasure makes the followers rely on the last

legitimate leader message: as in scenario (a

), the

leader decelerates while the attack is carried out, the

followers rely on a speed value higher than the actual

leader speed.

EB Plausibility Check only mitigates attack 3 in

scenario (a

), but not in scenario (b). These veriﬁca-

tion results led us to design the next countermeasure.

EB Plausibility Check with gap check mitigates

all the attacks. These results are obvious since the

countermeasure makes the followers brake when their

measured gap value is smaller than a given threshold.

The two cryptographic countermeasures miti-

gate attacks 1, 2 and 3 in scenario (a

) but do not mit-

igate them, nor attack 4, in the other tested scenarios.

That seems logical since they make the followers rely

on the last legitimate leader message if they detect a

received message alteration. Indeed, in hscenario (b),

attack 4i Rover

and Rover

detect that the incoming

speed message has been modiﬁed. But since they rely

on the last legitimate message that has been a speed

update message, they continue to run while Rover

is braking when the intruder crosses the lane. Then

in hscenario (b), attack 3i Rover

detects that the in-

coming EB message has been modiﬁed. But after the

intruder has crossed the lane, the last legitimate mes-

sage received by Rover

is an EB message. So it con-

tinues to brake and that leads to a collision with its

follower Rover

. Finally, in hscenario (a

), attacks 1

and 2i the followers rely on a last legitimate speed

value higher than the actual leader speed as for Speed

Plausibility Check. Note that for hscenario (a

), at-

tack 2i, property 2 is not veriﬁed while it is veri-

ﬁed for the “unpatched” rover (see Table 4 (a)). This

seems to indicate a safety regression but it is actually

Note that these two properties are insufﬁcient for pre-

senting cases where a countermeasure deteriorates safety.

due to the 21 operating cycles limitation: a simula-

tion on 42 operating cycles also leads to a crash be-

tween Rover

and Rover

in the “no countermeasure”

conﬁguration. Thus, for hscenario (a

), attack 2i the

cryptographic countermeasures only make this crash

occur sooner. This can easily be explained since in

the “unpatched” conﬁguration, Rover

will adapt its

speed on the basis of the received speed value which

is the leader speed slightly increased by the attacker.

For instance, if the leader runs at 10 mph then decel-

erates down to 5 mph, Rover

and Rover

will run at

12 mph and then decelerate down to 7 mph. But with

cryptographic countermeasures enabled, Rover

and

Rover

will elaborate their driving commands on the

basis of the last legitimate received speed value, i.e.

10 mph: in the end, they will run faster than in the

“unpatched” conﬁguration so the collision between

the leader and Rover

, and then Rover

and Rover

will occur sooner. The fact that the 21 operating cy-

cles were not enough to observe this crash constitutes

a weakness of our choice to rely on unbounded inte-

ger variables for modeling the rovers’ dynamics.

5.4 Discussion

This platoon case-study is interesting to evaluate the

W-Sec method, e.g. to analyze the relations between

safety, security and performance requirements and

mechanisms. Indeed, thanks to safety veriﬁcation, we

were able to show that all the attack scenarios were

successful on the platoon and that the designed coun-

termeasures were not as efﬁcient as expected: for in-

stance, the Speed Plausibility Check was designed to

mitigate attack 1 but we showed that under certain

conditions (i.e., if the leader decelerates while the at-

tack is carried out), it can lead to a platoon crash. In

addition, the method helped us in improving the EB

Plausibility Check: safety assessment results showed

that the improved EB Plausibility Check was more ef-

ﬁcient, and performance assessment results showed

that its overhead cost was still acceptable. This shows

the importance of the joint safety-performance analy-

sis, thus of the interleaving of the two modeling and

veriﬁcation cycles. Broadly speaking, these two ex-

amples show the interest of the W-Sec method for

designing security countermeasures or merely assess-

ing the impact of existing ones. Also, the case-study

highlighted the interest of the W-Sec method regard-

ing the performance assessment: thanks to the mea-

surements, we were indeed able to establish that the

rover model enhanced with countermeasures still re-

spects performance properties. Finally, the case-study

fully illustrates the relevance of joint safety-security

analysis: the assessment of cryptographic counter-

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

measures showed that even if the attacked commu-

nication channel is provided with integrity, authentic-

ity and anti-replay protection, the attacks could still

lead to a crash depending on the platooning scenario

and on the countermeasures implementation. Here,

the main implementation problem lies in the fact that

the rover systematically relies on the last legitimate

received message when it detects that the current mes-

sage has been altered.

But this case-study also identiﬁed several remain-

ing weaknesses of the method. Firstly, depending on

the modeling choices for the models of the high-level

system design view, we can face a combinatorial ex-

plosion when verifying safety properties. In our case-

study, this was due to the unbounded integer variables

used to model the rovers’ coordinates and gap values.

To tackle this issue, we have decided to limit the num-

ber of operating cycles. However, this leads to incom-

plete safety veriﬁcations with respect to the whole at-

tack sequence: for instance, as explained in the pre-

vious subsection, depending on the hplatooning sce-

nario, attack scenarioi pair, a crash between Rover

and Rover

can occur after 21 operating cycles. The

simulation then helped to analyse and complete the

veriﬁcation results. Yet, this shows that it is impor-

tant to analyze the scope of the veriﬁcation results.

Secondly, if our safety property basis was relevant

for assessing the impacts of the attacks and then the

efﬁciency of the countermeasures, it was insufﬁcient

to obtain a comprehensive countermeasures safety re-

gression assessment. In general, further safety prop-

erties are needed to perform a complete regression

assessment. For instance, it should have been inter-

esting to systematically check reachability and live-

ness properties for all states of the SysML-Sec state-

machines, and to compare, for each countermeasure,

the results of this veriﬁcation performed on the “un-

patched” and on the “patched” model.

Thirdly, as the model enrichment (i.e., their com-

position with attack scenarios and countermeasures

models in the second stage of the method) is not au-

tomated, human intervention is needed to carry them

out. Depending on the initial system and components

models, attack scenarios and countermeasures, that

could be time-consuming —especially as we produce

up to three enriched system models per test scenario

as explained in Sect. 3: for instance, we produced

47 enriched models for this case-study. However,

the transformations were simple (add a block, change

variables updates or guards in the state-machines,

etc.) and as TTool provides the user with conve-

nient functions (e.g., models or objects cloning), we

were able to perform the needed models’ enrichment

quickly. Still, the reduction in the number of needed

enriched models shall be studied in future works: for

instance, we could design a single test scenario en-

compassing all the atomic test cases and so assess all

the countermeasures at once.

Fourthly, if we can assess the safety and perfor-

mance impacts of a wide variety of attacks, the se-

curity formal veriﬁcation only evaluates the impact

of a Dolev-Yao attacker. For instance, verifying the

conﬁdentiality of data processed by a component is

done by verifying the conﬁdentiality of data transfers

within this component (i.e., between its hardware sub-

components). That is enough to model eavesdropping

attacks targeting the component’s buses. Yet, we still

cannot evaluate the security impacts of more complex

attack scenarios, e.g. side-channel attacks.

Finally, regarding the safety assessments, the W-

Sec method focuses on safety veriﬁcation at system-

level, in the high-level system design view. There-

fore, the hardware platform is not taken into account

for safety veriﬁcation. Yet, the hardware architecture

of a system’s component may obviously impact its

safety. We can imagine a countermeasure that pre-

vents a component from reaching a given state due

to performance issues. In that case, the performance

assessment will detect the computational overhead in-

duced by the countermeasure. However, a safety as-

sessment at component-level should be led in order to

make sure that the state is not reachable. Then, if this

safety issue impacts the outputs of the component’s

algorithms, the countermeasure model in the high-

level system design view shall be enriched to take

it into account. Since the SysML-Sec approach in-

cludes post-mapping safety veriﬁcation (Apvrille and

Li, 2019), future works may focus on the joint appli-

cation of SysML-Sec and W-Sec methods to address

this limitation.

6 CONCLUSIONS

The W-Sec method, introduced in this paper, allows

CPS designers and maintenance engineers to assess

the efﬁciency and impacts of security countermea-

sures. It relies on two distinct modeling views help-

ing in reducing the models complexity, and on for-

mal methods for providing objective and quantita-

tive assessments regarding three aspects: safety, secu-

rity and performance. By combining their strengths,

the W-Sec method enhances the method presented

in (Sultan et al., 2018) and complements the SysML-

Sec method. Its relevance has been illustrated by an

autonomous rover platoon case-study.

Yet further works are needed to address its limi-

tations. As mentioned in Sect. 5, we intend to study

Safety, Security and Performance Assessment of Security Countermeasures with SysML-Sec

the reduction in the number of needed enriched mod-

els while still correctly assessing safety, security and

performance impacts. We will also investigate the au-

tomation of the enrichment stage. Furthermore, we

will work on the identiﬁcation of the links between

the two modeling views. Regarding the assessment

stage, the security assessment of more complex attack

scenarios, the automated generation of properties and

the design of metrics allowing to easily compare the

veriﬁcation and simulation results are three improve-

ment perspectives we intend to explore. Finally, we

intend to evaluate the method on other case-studies

that can help in comparing the assessment results with

the impacts observed on real systems.

ACKNOWLEDGEMENTS

This work has been funded by the EU H2020 project

SPARTA. We gratefully thank Fortiss and Yuri Gil

Dantas for their kind help and support.

REFERENCES

Apvrille, L. and Li, L. W. (2019). Harmonizing safety, secu-

rity and performance requirements in embedded sys-

tems. In 2019 Design, Automation & Test in Europe

Conference & Exhibition (DATE), pages 1631–1636.

IEEE.

Apvrille, L., Muhammad, W., Ameur-Boulifa, R., Coud-

ert, S., and Pacalet, R. (2006). A uml-based environ-

ment for system design space exploration. In 2006

13th IEEE International Conference on Electronics,

Circuits and Systems, pages 1272–1275. IEEE.

Apvrille, L. and Roudier, Y. (2013). SysML-Sec: A SysML

Environment for the Design and Development of Se-

cure Embedded Systems. In APCOSEC 2013, Yoko-

hama, Japan.

Behrmann, G., David, A., and Larsen, K. G. (2004). A

tutorial on uppaal. Formal methods for the design of

real-time systems, pages 200–236.

Blanchet, B. (2001). An Efﬁcient Cryptographic Proto-

col Veriﬁer Based on Prolog Rules. In 14th IEEE

Computer Security Foundations Workshop (CSFW-

14), pages 82–96, Cape Breton, Nova Scotia, Canada.

IEEE Computer Society.

Brykczynski, B. and Small, R. A. (2003). Reducing

internet-based intrusions: Effective security patch

management. IEEE software, 20(1):50–57.

Calvino, A. T. and Apvrille, L. (2021). Direct model-

checking of sysml models.

Dolev, D. and Yao, A. (1983). On the security of public key

protocols. IEEE Transactions on Information Theory,

29(2):198–208.

Dupont, S., Maroneze, A., Massonnet, P., Nigam, V., Plate,

H., Sykosch, A., Cakmak, E., Thanasis, S., Jim

enez,

V., Amparan, E., Martinez, C., L

opez, A., Garc

ıa-

Alfaro, J., Segovia, M., Rubio-Hernan, J., Blanc, G.,

Debar, H., Carbone, R., Ranise, S., Verderame, L.,

Spaziani-Brunella, M., Yautsiukhin, A., Morgagni,

A., Klein, J., Bissyande, T., and Samhi, J. (2020). As-

sessment speciﬁcations and roadmap. Technical re-

port.

Enrici, A., Apvrille, L., and Pacalet, R. (2017). A model-

driven engineering methodology to design parallel and

distributed embedded systems. ACM Transactions on

Design Automation of Electronic Systems (TODAES),

22(2):1–25.

Garmin (2016). Lidar lite v3 operation manual and techni-

cal speciﬁcations. Technical report.

Gonzalez-Granadillo, G., Garcia-Alfaro, J., Alvarez, E., El-

Barbori, M., and Debar, H. (2015). Selecting opti-

mal countermeasures for attacks against critical sys-

tems using the attack volume model and the rori index.

Computers & Electrical Engineering, 47:13–34.

Li, L. (2018). Safe and secure model-driven design for em-

bedded systems. PhD thesis, Universit

e Paris-Saclay.

ucio, L., Kanav, S., Bayha, A., and Eder, J. (2018). Con-

trolling a virtual rover using AutoFOCUS3. In Pro-

ceedings of the MDETools Workshop co-located with

MODELS 2018, volume 2245 of CEUR Workshop

Proceedings, pages 356–365.

Lugou, F., Li, L. W., Apvrille, L., and Ameur-Boulifa,

R. (2016). Sysml models and model transformation

for security. In 2016 4th International Conference

on Model-Driven Engineering and Software Develop-

ment (MODELSWARD), pages 331–338. IEEE.

Martinez, C., Maroneze, A., Massonnet, P., Dupont, S.,

Grandclaudon, J., Nigam, V., Dantas, Y.-G., Plate,

H., Sykosch, A., Ohm, M., Cakmak, E., Athanasios,

S., Jim

enez, V., Amparan, E., L

opez, A., Apvrille,

L., Blanc, G., Debar, H., Bisegna, A., Carbone, R.,

Verderame, L., Ranise, S., Bernardinetti, G., Palam

I., Pellegrini, A., Restuccia, G., Sirbu, G., Yaut-

siukhin, M. S.-B. A., Poretti, C., Klein, J., and Samhi,

J. (2021). Demonstrators speciﬁcations. Technical re-

port.

Nespoli, P., Papamartzivanos, D., M

armol, F. G., and Kam-

bourakis, G. (2017). Optimal countermeasures selec-

tion against cyber attacks: A comprehensive survey on

reaction frameworks. IEEE Communications Surveys

& Tutorials, 20(2):1361–1396.

Nicol, D. (2005). Modeling and simulation in security eval-

uation. IEEE Security & Privacy, 3(5):71–74.

Sultan, B. (2020). Ma

ıtrise des correctifs de s

ecurit

e pour

les syst

emes navals. PhD thesis, Ecole nationale

sup

erieure Mines-T

ecom Atlantique Bretagne Pays

de la Loire.

Sultan, B., Dagnat, F., and Fontaine, C. (2018). A method-

ology to assess vulnerabilities and countermeasures

impact on the missions of a naval system. In Com-

puter Security, pages 63–76, Cham. Springer Interna-

tional Publishing.

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development