Evolving Attacker Perspectives for Secure Embedded System Design
Letitia W. Li
1,2
, Florian Lugou
1
and Ludovic Apvrille
1
1
LTCI, T
´
el
´
ecom ParisTech, Universit
´
e Paris-Saclay, 75013, Paris, France
2
Institut VEDECOM, 77 rue des Chantiers, Versailles, France
Keywords:
Model-Driven Engineering, Security, Formal Verification.
Abstract:
In our increasingly connected world, security is a growing concern for embedded systems. A systematic design
and verification methodology could help detect vulnerabilities before mass production. While Attack Trees
help a designer consider the attacks a system will face during a preliminary analysis phase, they can be further
integrated into the design phases. We demonstrate that explicitly modeling attacker actions within a system
model helps us to evaluate its impact and possible countermeasures. This paper describes how we evolved the
SysML-Sec Methodology with “Attacker Scenarios” for the improved design of secure embedded systems.
1 INTRODUCTION
The advent of connected and soon autonomous vehi-
cles is projected to ease traffic congestion, improve
safety, and free us from tedious daily commutes.
However, even with the limited connectivity of today,
connected cars have already been compromised in
various hacks (Miller and Valasek, 2015; Constantin,
2016).
The methodology of our lab, SysML-Sec
(Apvrille and Roudier, 2015), describes a design
process for safe and secure embedded systems. How-
ever, during our study of the security of connected
vehicles, we found that we lacked the ability to
precisely model certain published attacks, and thus to
consequently evaluate countermeasures against them.
While attack steps can be modeled in Attack Trees,
the description of each attack is usually limited to a
few words, thus limiting their usage to documentation
and not to formal evaluation.
Therefore, this paper introduces a new concept
called Attacker Scenarios”, which precisely model
attacker actions within a system design, therefore us-
ing the same operators as for system design. Thus,
attacker scenarios are intended to interact with (and
possibly control) system models with communica-
tions via signals. The paper explains the modeling
capacities of attack scenarios e.g., how to model
message injection in communication channels as
well as how they integrate into our methodology. In
section 2, we discuss the high-level approach of us-
ing attack scenarios in system design, which we elab-
orate in section 3 to be specific for embedded sys-
tems. We then present the main phases of our method-
ology in greater detail, and how attacker scenarios
can be efficiently used within these phases: Require-
ments/Analysis in section 4, HW/SW Partitioning in
section 5, and Software Design in section 6. Next, we
present the related work in Section 7. Finally, Section
8 concludes the paper.
2 INTEGRATING ATTACKER
MODELS WITH SYSTEM
DESIGN
1. The process starts with considering the needs and
threats of the system, which are expressed respec-
tively in Requirements and Attack Tree Mod-
els. Attack Trees may impact the Security Re-
quirements for instance, to handle a threat, a
new requirement is added , so these may be de-
signed together. Each Attack Tree is a diagram
gradually refining the different steps necessary to
realize a single root attack. Regardless of which
individual attack steps are possible for the attacker
to perform, our ultimate concern is to ensure the
root attacks cannot be performed.
2. Next, the System is Designed. The functional-
ity of system components is modeled, along with
attacker scenarios which describe the attacker’s
interactions with the system. Attacker Scenar-
ios can be either pre-built attacker models (Dolev-
Li, L., Lugou, F. and Apvrille, L.
Evolving Attacker Perspectives for Secure Embedded System Design.
DOI: 10.5220/0006535802870294
In Proceedings of the 6th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2018), pages 287-294
ISBN: 978-989-758-283-7
Copyright © 2018 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
287
Requirements
Analysis
Hardware/
Software
Partitioning
Attack Tree
Application
Architecture
Mapping
Verification
Safety Security Performance
Software/
System
Design
Software Design
Verification
Safety
Security
+ Architectural
Countermeasures
+ Attacker Model
(Dolev-Yao)
+ Application
Countermeasures
+ Attacker Scenario
+ Attacker Scenario
Attack Trace
Attack Trace
Legend
Modeling
Security
Verification
User-defined
Automatic
Reconsideration
+ Security
Properties
Figure 1: Design Methodology.
Yao) or a custom-generated attack behavior.
3. Based on the Requirements of Step 1, Security
Properties are modeled with regards to the sys-
tem design. Security properties describe if a sys-
tem or data should be secure against a specific
type of attack. For example, if a security require-
ment states that all communications shall be con-
fidential (unrecoverable by the attacker), then one
security property of confidentiality is added for
each communication exchange.
4. Formal Verification: The security properties de-
scribed in Step 3 are verified on the system model
(step 2) with a security prover. The results of ver-
ification are either:
(a) All Security Properties are Satisfied, and no
root attacks can be performed. The system, if im-
plemented as specified, should be secure against
these conceived attacks in this form and fulfill the
requirements. (If new attacks arise afterwards or
the system model needs to be modified, then the
process must be repeated.)
(b) At Least One Security Property is Proven
False. If the prover can output an execution trace
demonstrating the property violation, then the At-
tack Trees of Step 1 can be enhanced with this
information. Then, to secure the system, either
we must reconsider (i) the Requirements of Step 1
(if the security requirements are too strict and un-
realistic), (ii) reconsider the security mechanisms
used to secure the model, or (iii) reconsider the
attacker model (An attacker is generally assumed
not to be willing to spend a cost more than the
value of the information recovered/system dam-
aged, and we can reconsider it if we have assumed
he/she has more resources than realistic.) After
modifications, we re-iterate through the process
until our system is verified secure.
Using this framework for integrating attacker be-
havior into system models, we next present our de-
tailed SysML-based methodology specialized for em-
bedded systems.
3 MODELING ATTACK
FRAMEWORKS FOR
EMBEDDED SYSTEMS
Embedded systems have faced a growing number
of attacks in recent years (Newman, 2016; Larson,
2017). Combining the ideas in the previous sec-
tion with the 3 phases of embedded system design
in SysML-sec (Analysis, Hardware Software Parti-
tioning, and System/Software Design), we present the
new methodology shown in Figure 1. As indicated,
we differentiate between the original modeling sub-
phases for embedded systems (in green), the security-
relevant sub-phases (in yellow), and the verification
steps (in blue). The solid black arrows show steps the
designer must take in developing models manually,
the blue arrows show automated steps such as model
translation, and purple arrows show steps for recon-
sidering the model.
First, the Analysis phase considers the general
needs of the system. We rely on Requirements Di-
agrams, which describe the functional and security
needs of the system. Also, we design Attack Tree
Diagrams, which are based on SysML Parametric Di-
agrams, (Kordy et al., 2013), one for each main attack
against the system.
Next, in the Hardware/Software Partitioning
Phase, we design the functionality and candidate ar-
chitectures of a system in a highly abstracted way.
This phase follows the Y-Chart approach, modeling
MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development
288
application and architecture separately, and then map-
ping tasks to architecture (Kienhuis et al., 2002). The
Mapping model can then be evaluated in terms of
Safety, Security, and Performance. Security verifica-
tion of the mapping is performed based on Security
Requirements and the Attacker Model. These results
can lead us to reconsider any of the existing models.
For security results, an attack trace is automatically
generated for each falsified security property. Based
on this attack trace, we can add Attacker Scenarios
to the application model, modeling possible attacks.
By examining the interaction of the attacker and sys-
tem, we can update our Attack Trees, and also accord-
ingly protect our system with Application-based and
Architecture-based security countermeasures.
Once a mapping is satisfactory, we proceed to the
Software Design Phase a skeleton of this model
can be automatically obtained from partitioning mod-
els where software models are much more detailed
that the high-level partitioning models. For instance,
partitioning models abstract algorithms as complexity
operations, while software models give the details of
these computations. Security verification on the soft-
ware algorithms including security protocols may find
that certain security requirements are not met. The at-
tack traces can again be used to generate new attacker
scenarios, which may require changes to the Attacker
Scenarios modeled in HW/SW Partitioning or Attack
Trees. The HW/SW Partitioning models may also be
revised. For example, if a security issue may not be
easily corrected with the selected hardware architec-
ture, we must return to the previous stage to recon-
sider those models.
System and Attacker Models are continually re-
fined over iterations until our system is secure against
all predicted attacks.
4 ANALYSIS: SECURITY
REQUIREMENTS AND ATTACK
TREES
<<block>>
Vehicle
<<root attack>>
attackAutomaticBraking
<<attack>>
preventDataTransmission
<<attack>>
delayDataTransmission
<<attack>>
ddosController
<<attack>>
disableSensors
<<attack>>
manipulateLIDAR
<<attack>>
manipulateSensors
<<AND>>
<<attack>>
preventDataComputation
<<OR>>
<<OR>>
<<OR>>
<<attack>>
preventObstacleDetection
<<attack>>
preventBrakingFunction
<<attack>>
delayBrakingFunction
<<attack>>
manipulateCamera
<<attack>>
corruptControllerCode
<<attack>>
jamInCarCommunications
Figure 2: Attack Tree for Attacking Automatic Braking
Function on Connected Car.
The Analysis phase involves describing the require-
ments and use cases of the system, and simultane-
ously considers the possible attacks that the system
may face (Roudier et al., 2013). This analysis is ex-
pected to prepare the future system to be adapted to
counter the listed attacks. Analysis also prepares the
verification phase since properties to be evaluated are
derived from requirements, and root attacks represent
attacks that shall not be reachable.
Throughout this paper, we demonstrate our
methodology on the design of a connected car
equipped with sensors, V2X, etc. Based on data from
the sensors, the system may need to send an emer-
gency brake command to the ECUs. V2X data may be
used to determine heavy traffic along the road, and the
system should send its own V2X messages in the case
of unexpected reduced speed. Even without a con-
crete model of the system, we can choose security re-
quirements like “An attacker should not be able to af-
fect vehicle function”, refined to An attacker should
not be able to prevent emergency braking”.
Next, we model the possible attacks violating this
requirement, as shown in Figure 2. The root attack,
‘attack Automatic Braking’, is the ultimate goal of the
attack, and to perform this attack, an attacker needs
to perform a combination of the refined attack steps.
Each attack step can be marked as possible or not,
and analyzer determines if the root attack is logically
possible. For example, if none of the 3 ways to at-
tack automatic braking ‘Prevent Brake Function Acti-
vation’, ‘Prevent Braking Function’, and ‘delay Brak-
ing Function’ are possible, then the root attack cannot
be carried out.
Depending on the system design, attack steps may
be added or removed, and the analyzer should be run
again to determine if each root attack is possible.
5 HW/SW PARTITIONING
The HW/SW Partitioning Phase involves the design
of the high-level functions and architecture of the
system. Based on the models and evaluation in this
phase, we can refine our developed attack trees or dis-
cover new possible attacks, as explained below.
5.1 Modeling
A partitioning consists of three main types of models:
the application model, architectural model, and map-
ping model. First, we describe the base models in this
phase, and then discuss how to consider the attacker
capabilities.
The Application Model is a set of communicating
tasks built upon SysML block diagrams. The behav-
Evolving Attacker Perspectives for Secure Embedded System Design
289
Sensor_LIDAR
Sensor_Camera
SensorControl
Lidardata
envData
Sensor_Env
ECUGateway
V2XGateway
Central
V2Xdata
cameraData
broadcastData
cmdData
sensorData
sensorControl
<<BUS-RR>>
Bus0
CPU0
Sensor_Env
<<CPURR>>
CPU2
<<CPURR>>
Sensor_Camera
<<CPURR>>
SensorControl
CPU1
<<CPURR>>
Sensor_LIDAR
CPU3
CPU_ECU
<<CPURR>>
ECUGateway
CPU4
<<CPURR>>
V2XGateway
<<BUS-RR>>
Bus1
CPU_Central
<<CPURR>>
Central
<<BRIDGE>>
Bridge0
Figure 3: Application and Mappings Models for Connected
Vehicle Example.
ior of tasks is described abstractly with activity dia-
grams. The Architecture Model displays the under-
lying architecture as a network of abstract execution
nodes, communication nodes, and storage nodes. The
Mapping Model then partitions the application into
software and hardware, and specifies the location of
their implementation on the architectural model. A
task mapped onto a processor will be implemented in
software, and a task mapped onto a hardware acceler-
ator will be implemented in hardware.
The application and architecture model for our
connected car is shown in Figure 3. The systems con-
tains a Central controller communicating with V2X,
and Sensor Control unit which manages the different
sensors. Different environmental conditions affect the
functionality of the system: during rain, braking dis-
tance changes, and the reliability of different sensors
is also affected. The architecture/mapping consists of
two central bus systems and one processor per task.
5.2 Security Countermeasures
In our previous work (Li et al., 2017), we demon-
strated how security can be considered in the HW/SW
Partitioning phase. As the V2X Gateway offers an ex-
terior connection to the outside world, we investigate
the consequences if it is compromised and allows an
attacker access to the internal vehicular communica-
tions (Henniger et al., ). In our example, we assume
the attacker has access to all communications along
the two main buses (i.e., Bus0 and Bus1).
Even before performing formal verification, we
can add preliminary security countermeasures to our
mapping model to protect important communications.
As all inter-task data is being sent on buses accessible
to the attacker, we must secure the communications
with Application Countermeasures, which include en-
crypting data to prevent it from being comprehensible
to an attacker, or concatenating data with a calculated
Message Authentication Code (MAC) to ensure the
message cannot be modified.
Architectural Countermeasures such as Hardware
Security Modules and Firewalls can also be added.
Since security operations can be computationally-
intensive and require the secure storage of crypto-
graphic elements (e.g., keys), there exist specialized
co-processors Hardware Security Modules which can
perform cryptographic operations faster than a normal
processor and can store cryptokeys.
Firewalls filter communications and can block an
attacker without having to attempt to decrypt/analyze
the contents of his/her communications. Filtering
communications could prevent an attacker from in-
jecting code to a certain extent, if we limit the size of
allowed messages.
In our first secured model, we only add application
countermeasures, in the form of MACs to data that we
do not want the attacker to forge, most importantly
commands to the ECU. In our next step, we evalu-
ate if these countermeasures are sufficient and prevent
the ‘Attack Braking Function’ attack described in the
Analysis Phase.
5.3 Evaluation of Security
Data sent across channels can be evaluated in terms
of confidentiality and authenticity. We perform secu-
rity verification with ProVerif, a verification tool op-
erating on a pi-calculus specifications of communi-
cating processes (Blanchet, 2001). ProVerif assumes
a Dolev-Yao attacker, who can read and write on any
public channel, create new messages, and apply cryp-
tographic primitives. We also transform the security
requirements described in the Analysis phase into for-
mal security queries, which we send to ProVerif. The
verifier can check if queried data can be recovered by
the attacker (which violates confidentiality), injected
by the attacker (which violates weak authenticity), or
replayed by the attacker (which violates strong au-
thenticity).
As shown in the methodology, verification re-
sults for properties proven false are shown as ‘Attack
traces’ showing the attacker actions performed. Com-
mand data sent from the central controller to ECUs
was concatenated with their MAC, to ensure that the
attacker cannot modify the command.
This attack could be prevented if the original mes-
sage was concatenated with a sequence number or
timestamp. We could also reconsider the architecture,
such that the attacker would have no access to the bus
between Central and ECU Gateway.
MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development
290
<<BUS-RR>>
Bus1
4%
54%
<<CPURR>>
CPU4
60%
Central
<<CPURR>>
CPUECU
ECUGateway
<<CPURR>>
CPUECU
ECUGateway
21%
<<CPURR>>
CPU4
Central
66%
<<BUS-RR>>
Bus1
1%
Attacker Scenario
interval
Loop
cmdData(1)
[bus access?]
[else]
analyzeCmd
cmdData(1)
forgeCmd
injectCode(V2X)
Loop
chl
cmdData(1)
Without Attacker
With Attacker
Performance
Results
<<CPURR>>
CPUV2X
V2X
40%
20%
<<CPURR>>
CPUV2X
V2X
Read Public
Channel
Write Public
Channel
Code Injection
Figure 4: Attacker Scenario and impact on performance.
5.4 Attacker Scenarios
To better evaluate the attacker impact on a system, we
model Attacker Scenarios in the form of an additional
task on the component diagram. They describe their
abstract behavior in terms of their injected data.
An attacker scenario consists of one or many at-
tacker tasks, representing separate functions working
together to carry out an attack on a system. An at-
tacker task’s behavior includes all possible actions
of a normal application task (read/write data on a
channel, control operations, execution of calculations,
etc). In addition, where regular tasks can only read
and write on channels directly associated with them-
selves, the attacker tasks may read and write on any
public channel. A public channel is defined to be any
channel mapped to a path including at least one bus
accessible to the attacker. Furthermore, attacker tasks
possess an additional capability: ‘Code Injection’,
which replaces an application task’s behavior with an
attacker-determined one, modeling an attacker’s ca-
pability to change a task’s execution flow which may
include code modification.
We can also examine the impact on the system
when sending forged messages, whether sent by the
attacker directly or by a task whose code has been
modified. We previously noted that replay attacks
could be prevented by adding a sequence number to
messages before calculating the MAC. However, the
ECU Gateway must still process those messages even
if it will detect that they are forged. We can evaluate
the attacker impact on the system using simulation.
If we assume a rate at which the attacker can inject,
then we can evaluate using a simulation the impact of
performance. If we notice that the bus or processors
are processing mostly only the attacker messages or
show dramatically increased load, these performance
metrics can be used to conclude about the Availability
of a system.
The top of Figure 4 shows an attacker scenario
where the attacker has two options depending if it
has read/write access to the bus directly. The three
Attacker Behavior Elements are marked with the At-
tacker mask symbol, and labeled with their action.
With access to the bus, the attacker attempts to read
the public channel of current ECU commands and
then inject a fake one (by writing to the public chan-
nel ECUcmd) that differs significantly (for example,
injecting a command to turn sharply while driving
straight on a freeway). Otherwise, the attacker will
perform code injection and change the functionality
of the V2X Gateway to constantly inject messages to
prevent legitimate commands from being processed.
We analyze the performance results in the second
case, as shown in the bottom of Figure 4. The load
of each architectural component is calculated as ac-
tive cycles divided by total execution cycles. In this
case, we notice a significant increase in computations
performed on the ECU, and an increase in Bus load.
This new modeling capability allows us to analyze the
property ‘Availability’.
These Attacker Scenarios can be refined in the fol-
lowing Software/System Design Phase, after which
we reconsider the attack trees to consider these new
attacks.
6 SOFTWARE DESIGN
The Software Design phase models the software part
of the system in greater detail. The general frame-
works of the Software models are generated automat-
ically from HW/SW Partitioning models, leaving the
user to refine abstract elements, e.g. the implementa-
tions of algorithms.
The security of channels is determined by the ar-
chitecture in the previous stage. Indeed, while the ar-
chitecture diagrams are not part of this phase, they are
initially used to choose whether the connections be-
tween blocks of the Software Design models are ac-
cessible to the attacker or not.
6.1 Attacker Model
Attacker Scenarios in Software/System Design can
be used to analyze the data communications in more
detail. For example, we can analyze the communi-
cations between the sensors. In the previous phase,
we assumed that the attacker could access the bus on
which the different sensors communicate. Therefore,
Evolving Attacker Perspectives for Secure Embedded System Design
291
[else]
[|(lidardist-cameradist)/
lidardist|>threshold]
[mode==1]
setMode
modeNormal
modeRain
[mode==2]
error
valid
calculate Distances based
on Sensor Data
calculate nal distance
based on combination of
camera and lidar distances
...
calculate nal distance
based on only camera
distance
...
...
<<block>>
Sensor_Environment
~ out envData(int data)
<<block>>
SensorControl
~ in camData(int data)
~ in envData(int data)
<<block>>
Sensor_Camera
~ out camData(int data)
<<block>>
Sensor_LIDAR
~ out lidarData(int data)
<<block>>
Attacker
~ out camData(int data)
~ out lidarData(int data)
~ out envData(int data)
Figure 5: Sensor Software Design Models with Attacker.
we model the communications between the compo-
nents in this phase as occurring on a public channel
accessible to the attacker, as shown in the top of Fig-
ure 5, where public channels are marked with the eye
in a triangle. In our system, the Sensor Control block
implements a plausibility and coherence check on the
data received by the sensors as shown in Figure 5. The
attacker cannot inject arbitrary data that would greatly
differ from the other data present in the system, for
then the system will detect an anomaly. If the calcu-
lated distance to the nearest obstacle differs by over
X%, then the system could assume a malfunction or
attack was taking place and warn the user. In case of
rain, however, LIDAR data is not used and no coher-
ence check takes place.
However, if it were possible for the attacker to im-
itate both the LIDAR and the camera, then the system
would accept the forged data. If it should be possi-
ble to attack the environmental sensor (which may be
user set or acquiring meteorological data by internet),
then the attacker would only need to attack one of the
other two sensors.
6.2 Reconsideration of Attack Trees
In the last two sections, we examined different possi-
ble attacks on the system, including Denial of Service
attacks on the ECU Gateway, forging sensor data, etc.
We notice that the preliminary Attack Tree in Fig-
ure 2 was incomplete, as it did not cover all these at-
tack scenarios. For example, the attack ‘Manipulate
Sensors’ could also involve manipulating the Envi-
ronment sensor. Also, we can elaborate on some of
the listed attack steps, such as ‘prevent Braking Func-
tion’ that would involve the attack sub-steps ‘attack
V2X Gateway’ to gain control, and then ‘replay ECU
commands’. The preliminary Attack Tree of Figure 2
must be enhanced to add the new attacks which may
be possible in our system, as shown in Figure 6.
When we add countermeasures, certain attack
steps become impossible. For example, we could add
a firewall to ensure in-car communications cannot be
jammed. Furthermore, we could add timestamps to
ECU commands before calculating a MAC to prevent
replay attacks as we described in section 5.4.
As the root attack is still logically possible, more
countermeasures must be added to protect our sys-
tem. Subsequent iterations through the design pro-
cess could involve ensuring the sensor data could not
be forged, or considering if keys should be periodi-
cally distributed. Then, the security verification could
evaluate if there exist vulnerabilities in the implemen-
tation of those security protocols, which may suggest
future attacker scenarios, and consequently, modifi-
cations to the displayed Attack Tree or new Attack
Trees.
7 RELATED WORK
Regarding security in embedded systems, multiple
works develop toolkits for the design process only
(Balarin et al., 2003; Rosales et al., 2014; Kangas
et al., 2006), and many study the verification of se-
curity, but few study both in one framework. Of the
works which investigate both, (Hansson et al., 2010)
relies on Architecture Analysis and Design Language
(AADL) models to consider architectural mapping
during security verification. The authors note that a
system must be secure on multiple levels: software
applications must exchange data in a secure manner,
and also execute on a secure memory space and com-
municate over a secure channel. Our work, however,
investigates protections against an external attacker
instead of access control.
Another approach performs Design Space Explo-
ration on a vehicular network protecting against re-
play and masquerade attacks (Lin et al., 2015). The
project evaluates possible security mechanisms, their
effects on message sizes, and candidate architectures
during the mapping phase. While their work tar-
gets automotive systems and network communica-
tions, our analysis may be applied more broadly for
any embedded system. Also, we focus on the integrity
and confidentiality of data itself instead of on specific
attacks.
7.1 Security Modeling and Verification
Attack Defense Trees (Kordy et al., 2013) analyze the
possible attacks against a system, in conjunction with
the defenses that the system may implement. The sup-
porting toolkit ADTool analyzes attack scenarios to
MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development
292
<<block>>
Vehicle
<<root attack>>
attackAutomaticBraking
<<attack>>
preventDataTransmission
<<attack>>
delayDataTransmission
<<attack>>
jamInCarCommunications
<<attack>>
ddosController
<<attack>>
disableSensors
<<attack>>
manipulateSensors
<<AND>>
<<attack>>
preventDataComputation
<<OR>>
<<OR>>
<<OR>>
<<attack>>
preventObstacleDetection
<<attack>>
preventBrakingFunction
<<attack>>
delayBrakingFunction
<<attack>>
manipulateCamera
<<attack>>
corruptControllerCode
<<attack>>
manipulateCamera
<<attack>>
manipulateEnvSensor
<<AND>>
<<OR>>
<<Sequence>>
1
2
<<attack>>
attackV2XGateway
<<attack>>
ddosECUGateway
<<OR>>
<<attack>>
manipulateLIDAR
<<attack>>
replayECUcommand
<<countermeasure>>
AddFirewall
<<countermeasure>>
checkMAC+Timestamp
Figure 6: Modified Attack Tree after System Design and Evaluation.
determine the cost, probability, time, etc, required for
a successful attack.
The Knowledge Acquisition in Automated Spec-
ifications approach Security Extension aims to iden-
tify security requirements for software systems (van
Lamsweerde, 2004). The methodology uses a goal-
oriented framework and builds a model of the sys-
tem, and then an anti-model which describes possi-
ble attacks on the system. Both models are incre-
mentally developed: threat trees are derived from the
anti-model and the system model adds security coun-
termeasures to protect against the attacks described in
the anti-model.
The Combined Harm Assessment of Safety and
Security for Information Systems (CHASSIS) method
considers safety and security together in a common
model (Raspotnig et al., 2013). Safety and security
hazards in the form of misuse cases are developed,
and then trade-off analysis to unify all requirements
and identify when safety and security conflict. While
these techniques targeting the requirements and anal-
ysis phase offer a detailed approach to considering
threats against safety and security, they are not yet
automated.
Unlike these works, our work allows formal veri-
fication of attack trees to check the possibility of exe-
cuting a root attack, and then continues on to design-
ing the system itself in the subsequent stages.
(Vasilevskaya and Nadjm-Tehrani, 2015) pro-
posed modeling security in embedded systems with
attack graphs to determine the probability that data
assets could be compromised. While their approach
is also UML-based, they focus on estimating proba-
bilities of success for attacks, while ours focuses on
verifying adequate placement of encryption.
UMLSec (J
¨
urjens, 2002) is a UML profile for ex-
pressing security concepts, such as encryption mech-
anisms and attack scenarios. It provides a modeling
framework to define security properties of software
components and of their composition within a UML
framework. It also features a rather complete frame-
work addressing various stages of model-driven se-
cure software engineering from the specification of
security requirements to tests, including logic-based
formal verification regarding the composition of soft-
ware components. However, UMLSec does not take
into account the HW/SW Partitioning phase neces-
sary for the design of IoTs.
The authors of (Dawkins and Hale, 2004) lever-
aged Attack Trees to analyze network security. Both
system vulnerabilities and attacker capabilities are
modeled and analyzed to determine the possible at-
tacks a system may face. (Hong and Kim, 2016)
also used a hierarchical attack representation model
(HARM) to assess different moving target defenses,
modeling both system vulnerabilities and attack
graphs and trees. (Ge et al., 2017) described a simi-
lar framework modeling attacks and defenses in IoTs.
While similar to our work as they described the sys-
tem vulnerabilities along with the attacker actions,
our toolkit models system behavior including counter-
measures instead of only vulnerabilities, and is sup-
ported by formal verification.
8 CONCLUSION
Our Model-Driven methodology combines Attack
Trees with Embedded System Design, developing an
iterative design process evolving system models and
attacker models collaboratively. As demonstrated us-
ing a connected car case study, Attack Trees devel-
oped in the preliminary first steps of modeling have
an incomplete vision of the system, and need to be
further refined as the system is developed. Security
Evaluations reveal additional attacks, or provide im-
plementation details for existing predicted attacks. As
long as there exist executable root attacks, the system
must be further protected with additional countermea-
sures.
Future work will seek to better automate the gen-
eration of Attacker Scenarios. Attack traces could be
automatically translated into the attacker’s functional
model. We could reconstruct functional attack scenar-
ios based on attack traces and automatically integrate
them to the attack trees so that the designer is able to
improve system design or rework the attacker model
depending on the effect of the scenario on the system.
Evolving Attacker Perspectives for Secure Embedded System Design
293
We also plan to provide a toolbox of Attacker
Models, to provide the designer with some templates
or example attack scenarios, such as DDoS attacks,
replay attacks, brute-forcing of keys, etc., that he/she
can then further enhance. While our current security
prover ProVerif has limited support for mathematical
operations, we plan to integrate safety and security
verification to allow formal evaluation of plausibil-
ity and coherence checks that we currently perform
with simulation. We may find a different security
prover, or integrate security reasoning into our reach-
ability graphs. Furthermore, we’d like to better con-
nect analysis and implementation, such as connect-
ing Requirements Diagrams with implemented coun-
termeasures, etc. Our ultimate goal will be a com-
prehensive methodology for systematic modeling and
verification of security.
REFERENCES
Apvrille, L. and Roudier, Y. (2015). SysML-Sec: A Model
Driven Approach for Designing Safe and Secure Sys-
tems. In 3rd International Conference on Model-
Driven Engineering and Software Development, Spe-
cial session on Security and Privacy in Model Based
Engineering, France. SCITEPRESS Digital Library.
Balarin, F., Watanabe, Y., Hsieh, H., Lavagno, L.,
Passerone, C., and Sangiovanni-Vincentelli, A.
(2003). Metropolis: An Integrated Electronic System
Design Environment. Computer, 36(4):45–52.
Blanchet, B. (2001). An efficient cryptographic protocol
verifier based on prolog rules. In Proceedings of the
14th IEEE Workshop on Computer Security Founda-
tions, CSFW ’01, pages 82–, Washington, DC, USA.
IEEE Computer Society.
Constantin, L. (2016). Researchers hack Tesla Model S
with remote attack. http://www.pcworld.com/article/
3121999/security/researchers-demonstrate-remote-
attack-against-tesla-model-s.html.
Dawkins, J. and Hale, J. (2004). A systematic approach
to multi-stage network attack analysis. In Informa-
tion Assurance Workshop, 2004. Proceedings. Second
IEEE International, pages 48–56. IEEE.
Ge, M., Hong, J. B., Guttmann, W., and Kim, D. S. (2017).
A framework for automating security analysis of the
internet of things. Journal of Network and Computer
Applications, 83:12–27.
Hansson, J., Wrage, L., Feiler, P. H., Morley, J., Lewis, B.,
and Hugues, J. (2010). Architectural Modeling to Ver-
ify Security and Nonfunctional Behavior. IEEE Secu-
rity Privacy, 8(1):43–49.
Henniger, O., Apvrille, L., Fuchs, A., Roudier, Y., Ruddle,
A., and Weyl, B. Security Requirements for Automo-
tive On-Board Networks. In ITST 2009, Lille, France.
Hong, J. B. and Kim, D. S. (2016). Assessing the effective-
ness of moving target defenses using security models.
IEEE Transactions on Dependable and Secure Com-
puting, 13(2):163–177.
J
¨
urjens, J. (2002). UMLsec: Extending UML for Secure
Systems Development. In Proceedings of the 5th In-
ternational Conference on The Unified Modeling Lan-
guage, UML ’02, pages 412–425, London, UK, UK.
Springer-Verlag.
Kangas, T., Kukkala, P., Orsila, H., Salminen, E.,
H
¨
annik
¨
ainen, M., H
¨
am
¨
al
¨
ainen, T. D., Riihim
¨
aki, J.,
and Kuusilinna, K. (2006). UML-based Multipro-
cessor SoC Design Framework. ACM Trans. Embed.
Comput. Syst., 5(2):281–320.
Kienhuis, B., Deprettere, E., van der Wolf, P., and Vissers,
K. (2002). A Methodology to Design Programmable
Embedded Systems: The Y-Chart Approach. In Em-
bedded Processor Design Challenges, pages 18–37.
Springer.
Kordy, B., Kordy, P., Mauw, S., and Schweitzer, P. (2013).
Adtool: Security analysis with attackdefense trees. In
Joshi, K., Siegle, M., Stoelinga, M., and DArgenio, P.,
editors, Quantitative Evaluation of Systems, volume
8054 of Lecture Notes in Computer Science, pages
173–176. Springer Berlin Heidelberg.
Larson, S. (2017). FDA confirms that St.
Jude’s cardiac devices can be hacked.
http://money.cnn.com/2017/01/09/technology/fda-st-
jude-cardiac-hack/.
Li, L. W., Lugou, F., and Apvrille, L. (2017). Security-
Aware Modeling and Analysis for HW/SW Parti-
tioning. In Confer
´
ence on Model-Driven Engineer-
ing and Software Development (Modelsward’2017),
Porto, Portugal.
Lin, C.-W., Zheng, B., Zhu, Q., and Sangiovanni-
Vincentelli, A. (2015). Security-Aware Design
Methodology and Optimization for Automotive Sys-
tems. ACM Transactions on Design Automation of
Electronic Systems (TODAES), 21(1):18.
Miller, C. and Valasek, C. (2015). Remote exploitation of
an unaltered passenger vehicle. Black Hat USA.
Newman, L. (2016). The Botnet That
Broke the Internet Isn’t Going Away.
https://www.wired.com/2016/12/botnet-broke-
internet-isnt-going-away/.
Raspotnig, C., Katta, V., Karpati, P., and Opdahl, A. L.
(2013). Enhancing CHASSIS: A Method for Com-
bining Safety and Security. In Availability, Reliability
and Security (ARES), 2013 Eighth International Con-
ference on, pages 766–773.
Rosales, R., Glass, M., Teich, J., Wang, B., Xu, Y., and
Hasholzner, R. (2014). MAESTRO— Holistic Actor-
Oriented Modeling of Nonfunctional Properties and
Firmware Behavior for MPSoCs. ACM Trans. Des.
Autom. Electron. Syst., 19(3):23:1–23:26.
Roudier, Y., Idrees, M. S., and Apvrille, L. (2013). To-
wards the Model-Driven Engineering of Security Re-
quirements for Embedded Systems. In proceedings of
MoDRE’13, Rio de Janeiro, Brazil.
van Lamsweerde, A. (2004). Elaborating Security Require-
ments by Construction of Intentional Anti-Models. In
Proc. of the 26th International Conference on Soft-
ware Engineering , ICSE ’04, pages 148–157.
Vasilevskaya, M. and Nadjm-Tehrani, S. (2015). Quanti-
fying Risks to Data Assets Using Formal Metrics in
Embedded System Design, pages 347–361. Springer
International Publishing, Cham.
MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development
294