Model-guided Security Analysis of Interconnected Embedded Systems

Yasamin Mahmoodi, Sebastian Reiter, Alexander Viehl,

Oliver Bringmann and Wolfgang Rosenstiel

FZI Forschungszentrum Informatik, Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe, Germany

Keywords:

Security Analysis, Virtual Prototyping, UML Proﬁle.

Abstract:

Software-intensive and networked embedded systems implement more and more security critical tasks. The

following paper presents a framework to support security analysis along the design process using virtual pro-

totypes (VPs). VPs describe the interconnection between different system components, include actual applica-

tion codes and even integrate existing physical prototypes. These enable the user to detect structural security

ﬂaws, implementation ﬂaws and even hardware-based security problems. Beneﬁts of using VPs are the early

availability in the design process and the fact that VPs are based on software, therefore established security

analysis methods for software can be applied. This paper provides a methodology and tooling support to apply

VP in the context of security analyses. Especially the integration in a model-driven design (MDD) process is

highlighted. A proposed security UML proﬁle as well as code generation ease the VP-based analysis.

1 INTRODUCTION

Embedded systems are increasingly networked by

information and communication technologies (ICT).

This offers a high beneﬁt in application domains such

as automotive or industrial automation. At the same

time, it creates new challenges, such as the increasing

complexity for security risk assessment. Car2X tech-

nologies are an illustrative example from the automo-

tive domain. They exchange sensor and context data

between vehicles and the trafﬁc infrastructure to in-

crease resource efﬁciency, safety and comfort. How-

ever, in addition to the outstanding advantages, com-

prehensive networking also results in new security

risks. Without sufﬁcient security measures, individ-

ual, manipulated messages are sufﬁcient to affect the

correct behaviour of Car2X-based assistance systems,

such as demonstrated by (Charlie and Chris, 2015). In

an extreme case, critical safety-relevant system com-

ponents are manipulated, resulting in an unacceptable

threat to people or assets. Unauthorized access to

system-internal controls is possible by poorly secured

radio interfaces such as Bluetooth, Wi-Fi, keyless en-

try or tire pressure systems (Checkoway et al., 2011).

"Security by Design" is therefore required, to get the

full beneﬁt of comprehensively networked systems.

This requires a comprehensive consideration of secu-

rity measures along the design process.

We propose an approach to enable security anal-

ysis along the design process of software intensive

and interconnected embedded systems. The approach

provides a comprehensive and executable speciﬁca-

tion of the system architecture as well as mechanisms,

procedures and parameters of security measures in the

form of a virtual prototype (VP). A VP represents the

preliminary stage of a physical prototype in the de-

sign process and denotes the complete or partial pro-

vision of system sub-components as executable mod-

els. Different security analyses such as penetration

testing or structural analyses, including dynamic data

ﬂow analyses, are based on the VP. Virtual Prototyp-

ing is widely used in the ﬁeld of electronic system

design to analyze components and systems for their

functional and non-functional properties (Reiter et al.,

2016). The accompanying use of VPs in the develop-

ment of embedded systems makes the complexity of

the design of secure embedded systems manageable.

A tight integration of the VP in the design ﬂow

and a comprehensive tool support, such as automated

code generation are required to foster the usage of

VPs. In this paper, we highlight a modeling approach

used to guide the security analysis with VPs thus re-

ducing manual overhead. We use the Uniﬁed Mod-

eling Language (UML) (OMG, 2011b) as modeling

language. The goal is to have a well-deﬁned, easy-

to-handle user interface to manage the analysis and

document the system’s security features. In addition,

the model eases manual analyses, such as penetration

testing, by enhancing the documentation and high-

lighting potential design ﬂaws.

602

Mahmoodi, Y., Reiter, S., Viehl, A., Bringmann, O. and Rosenstiel, W.

Model-guided Security Analysis of Interconnected Embedded Systems.

DOI: 10.5220/0006724606020609

In Proceedings of the 6th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2018), pages 602-609

ISBN: 978-989-758-283-7

The paper is structured as follows. First, the envi-

sioned methodology is highlighted in Section 2. Sec-

tion 3 shortly reviews modeling approaches used for

safety analysis. Section 4 introduces the developed

security proﬁle. In addition, a comparison of the de-

veloped proﬁle with a state of the art UML proﬁle

as well as an exemplary model is presented. Sec-

tion 5 highlights the used VP framework and demon-

strates the security proﬁle integration. The paper is

concluded in Section 6.

2 METHODOLOGY

As motivated in the introduction, the VP is an exe-

cutable simulation model of the physical system. The

technique of virtual prototyping enables the evalua-

tion of hardware/software systems without the need of

physical prototypes. VPs are often used during soft-

ware development, if the target hardware is not avail-

able yet. A VP simulates the required system compo-

nents. Depending on the amount of simulated system

parts and the level of detail, different analysis goals

can be pursued. With a complete system simulation

on a very abstract level, a rough evaluation, such as a

structural analysis that analyses the data ﬂow between

components, is possible. Integrating actual software

implementations within the VP, enables the evalua-

tion of the target software. This step often involves

a reﬁnement of the VP, e.g. to simulate the accessed

registers. Enabling the execution of a rough evalua-

tion in an early design phase with a less detailed sys-

tem model and a continuous gain in accuracy by reﬁn-

ing the system model. The presented approach uses

the event-driven SystemC (IEEE Computer Society,

2011) simulation language. SystemC covers differ-

ent abstraction levels of hardware and software sys-

tems and enables both the modeling of SW applica-

tions as well as digital/analog electronic components.

SystemC provides abstract Transaction Level Models

(TLM) to specify the interaction of system compo-

nents and enables a very early structural analyses of

the complete system.

As SystemC is a C++ class library it is possible

to integrate actual application code that is compati-

ble with C++. This reduces the overhead required

to create the VP and enables the analysis of the ac-

tual implementation. Flaws can be found that would

lead to security vulnerabilities. Figure 1 sketches the

proposed development ﬂow. The overall goal is to

execute security analyses combined with risk assess-

ment. Traditional design ﬂows often use physical pro-

totypes, i.e. when the application code and the sys-

tem hardware are available. Today’s system design

Figure 1: Design support by virtual prototyping.

already beneﬁts from a set of models. This models in-

clude the speciﬁcation of the system architecture with

SysML (OMG, 2012) as well as dedicated software

aspects or use cases with UML. Only few security

analysis approaches are based on these early models.

The Cyber Security Modeling Language (CySeMoL)

(Sommestad et al., 2013) analyzes a range of different

attack types and security measures based on structural

models. The approach is based on probabilities for the

effectiveness of security measures. These probabili-

ties are typically determined with the ﬁnal system or

based on experiences with previous systems. There-

fore, it is not possible to give an analysis that can be

reﬁned along the design process.

Our approach introduces an UML model of the

VP. The idea is to reuse already existing models

from the system design. Compatible models such

as SysML- or UML-based models can be reused by

Model-to-Model (M2M) transformations. We de-

cided to use a separate UML model, because the VP

speciﬁcation may contain additional information that

should not pollute the actual system model. An exam-

ple of such pollutions are functions that model timing

in the VP or functions to read data from the test bench.

Based on this UML-based speciﬁcation we generate

the structural aspects of the VP as well as the simula-

tion runtime conﬁguration. For detailed information

about the provided automation, see Section 5.

Another aspect that is highlighted in Figure 1 is

that the VP can integrate actual application codes.

The VP is a C++ implementation, therefore source

codes are directly integrated and compiled. Binary

codes are integrated with emulators, such as QEMU

or with Instruction Set Simulators (ISS). The use of

existing software reduces the overhead to create the

VP and makes the simulation more accurate.

This paper focuses on the UML-based security

modeling based on UML models of the VP. Before

highlighting our approach, different existing security

modeling approaches are evaluated.

Model-guided Security Analysis of Interconnected Embedded Systems

603

3 EXISTING MODELING

APPROACHES

Several approaches exist for security assessment and

modeling. UMLsec is an extension to the Uni-

ﬁed Modeling Language for integrating security re-

lated information in UML speciﬁcations. The cen-

tral idea of the UMLsec extension is to deﬁne la-

bels for UML model elements (stereotypes), that add

security-relevant information to these model elements

(Jürjens, 2010; Jürjens, 2002) when attached. The

approach is strongly inﬂuenced by networked infor-

mation systems in business infrastructures, such as

distributed information systems (Best et al., 2007) or

electronic payment services. The extension contains

for example stereotypes for «fair exchange», spec-

ifying the requirement of a fair trade exchange, or

«Internet», «LAN» to model links between partici-

pants. Some of the presented stereotypes apply for

networked embedded systems, e.g., «integrity» or

«encrypted». Others are too specialized to cover all

aspects of embedded systems, such as «Internet» or

«LAN». These two stereotypes are too specialized to

cover the different bus systems available in a vehicle.

Others are not required in the context of automotive

systems, such as «fair exchange».

SecureUML on the other hand provides an UML

extension for specifying role-based access control

(RBAC) and other access control policies (Basin

et al., 2006; Lodderstedt et al., 2002). SecureUML

mainly focuses on UML class diagrams and does not

provide stereotypes for other UML diagrams. Based

on its focus on RBAC, the proﬁle does not provide

the required generality for security modeling, e.g., to

specify the attack surface or protection goals. In ad-

dition, only class diagrams are supported, a structural

system speciﬁcation is not considered.

The Cyber Security Modeling Language

(CySeMoL) is another approach with the pur-

pose of modeling attacks and assessing the attack

impact. CySeMoL analyzes a range of attack

types and security measures. CySeMoL’s output

is probabilistic and estimates the probability that

different attacks can be accomplished against assets

in the system architecture (Sommestad et al., 2013).

The listed attacks provide a good overview but the

language do not cover all aspects that are required to

model security concepts on abstract system level.

Another examined approach is Secure Tropos. It

is an extension of Tropos used to model and ana-

lyze security requirements alongside functional re-

quirements. The methodology provides a require-

ment analysis process that supports the designer from

the acquisition of requirements to their veriﬁcation

(Bresciani et al., 2004). The SI* modeling language

evolved from the I* modeling language that employs

the notation of actor, goal, task, resource and social

dependency between actors to represent the functional

design of the system (Massacci et al., 2010). While

the language offers some interesting extensions, it

was not suitable for lightweight annotation, required

for the VP speciﬁcation.

Each of the examined approaches has been de-

ﬁned for certain application areas and has its beneﬁts

and drawbacks. However, in our view, none of them is

adequate to cover all requirements to specify the sys-

tem security concepts in detail, required to conﬁgure a

VP-based security analysis. Therefore, we were con-

vinced to deﬁne our own security modeling approach

presented in this paper.

4 SECURITY UML PROFILE

The model-based virtual prototype speciﬁcation (VP-

Spec) provides models for the required system com-

ponents and their assembly to a simulation instance.

The VPSpec therefor automatically covers the secu-

rity concepts of the system, such as separation, the

inherent weak points of the system architecture or the

protection goals of the system. Additional informa-

tion such as the attack surface or the protection goals

is missing, for an security analysis. Other informa-

tion is inherently speciﬁed in the VPSpec, such as the

communication protocol implemented by a compo-

nent. Therefore, some additional information is added

that is only used for documentation of the analysis.

The center of the VP-based security analysis is the

VPSpec that is extended with this security related in-

formation. It offers the user a single point of informa-

tion and different tasks are automated thus reducing

the manual overhead. Figure 2 depicts the envisioned

structure. In the center is the UML-based VPSpec

that is derived from the actual system model (compare

Figure 1). The model is mainly used to generate and

conﬁgure the VP, both with injectors to simulate the

attack surface and monitors for the protection goals.

In addition, the model is used for static data ﬂow anal-

ysis and for a general documentation of the system’s

Figure 2: Application of the UML security proﬁle.

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

604

security features. Both the VP and the VPSpec are

reﬁned during the design process. UML proﬁles are

used to specialize the UML for the VPSpec.

Information security is deﬁned as protection of

information and information systems against unau-

thorized users to ensure integrity, conﬁdentiality and

availability. Integrity refers to maintenance or assur-

ance of accuracy and trustworthiness of these data

over its life cycle. Conﬁdentiality means that unau-

thorized users do not have the chance to access the

data, processes or entities. On the other hand, avail-

ability ensures a reliable access to information in

time. We deﬁne our security proﬁle along the trian-

gle of conﬁdentiality, integrity and availability.

Analyzing a system from the security point of

view, weak input points and vulnerable components

of the system should be speciﬁed. Automotive sys-

tems beneﬁt from remote connections for Remote

Key Entry Systems or internet access. Every connec-

tion can bring new opening for attackers and lead to

malicious activities.

Attack Surface

The attack surface is the total vulnerability and shows

weak points of the system, where an unauthorized

user can access, change or insert invalid data. At-

tack surfaces can be categorized as network attack

surfaces, software attack surfaces and physical attack

surfaces. Attack surfaces of the system should be

speciﬁed in the model-based VPSpec.

In our security proﬁle, we deﬁne ﬁve stereo-

types to represent vulnerable points and to deﬁne the

amount of effort, which is needed to break down vul-

nerable objects. The effort is added as an abstract

value that is associated with the stereotype. The

stereotype, «As.DataRead», describes the possibility

of reading the data by an unauthorized user. It also

deﬁnes the level of effort, which is needed to read

the data. «AS.DataModify» is another stereotype,

which states if an attacker can change the data of a

property and how much effort is needed. The stereo-

type «AS.DataDelete» speciﬁes how much effort is

needed for an unauthorized attacker to delete the data

of the stereotyped property. «AS.DataAdd» is another

stereotype which speciﬁes the possibility of adding

data by an unauthorized user and the level of ef-

fort needed. At the end, «AS.ServiceUnavailable»

speciﬁes how much effort an attacker needs to make

an operation unavailable in the system. The pre-

sented stereotypes are used to specify the attack sur-

face within the VPSpec. This information will have

positive effects on the placement of attack points, e.g.,

with injectors, in the VP.

Protection Goal

Embedded systems contain data and components with

different levels of criticality. With the focus on auto-

motive systems, an attacker may hack the head unit

and try to control the volume of the tuner chang-

ing the HVAC temperature or other malicious activ-

ities to disturb passengers. With more effort, the at-

tacker may access the critical data and be able to

send CAN packets to control the brakes, which will

lead to serious consequences. Our extended VP-

Spec enables the speciﬁcation of critical parts of the

system which require protection. The model con-

tains additional information about the severity level

of these protection goals. Five stereotypes in our

meta-model are devoted to these protection goals

to show critical parts of the system. The stereo-

type «PG.DataConfidential» deﬁnes that the asso-

ciated property should be protected against reading

or predicting by an attacker. Using the tag Sever-

ity, it also determines the level of severity if the pro-

tection goal is violated. The second stereotype of

this category, «PG.DataModify» indicates that the

property should be protected against modiﬁcation; it

also deﬁnes the level of severity in case of viola-

tion. «PG.DataDelete» speciﬁes that it should not

be possible for an unauthorized user to delete this in-

formation. Similar to the other stereotypes a level

of severity is added. The stereotype «PG.DataAdd»

indicates with its severity that this property should

be protected against adding new data by an attacker.

The last stereotype «PG.ServiceAvailability» in-

dicates that the stereotyped operation must be avail-

able and should not be stopped. With this informa-

tion, the user can plan suitable attack scenarios. Ad-

ditionally, monitors can be added to evaluate if an in-

jected modiﬁcation leads to a violation of the protec-

tion goal, at least for the protection goals w.r.t. modi-

ﬁcation.

Documentation

To make the documentation-related information visi-

ble to the user, different information is explicitly mod-

eled in the VPSpec. General security information

such as handshaking protocols will be provided with

the stereotype «Doc.SecurityProtocol ». Encryp-

tion protocols are abstract protocols which give in-

formation about the cryptographic methods. A weak

encryption may lead to vulnerabilities and bring new

openings to attackers. Information about applied

cryptographic methods is necessary for security anal-

ysis, which in our model is provided by stereotype

«Doc.EncryptionProtocol». Security communi-

ties regularly publish known vulnerabilities, expo-

sures and related security patches. Appending more

details about the VP components such as the software

version enable ﬁnding vulnerable points based on

published vulnerabilities and exposures. The VPSpec

Model-guided Security Analysis of Interconnected Embedded Systems

605

encloses software functionality with an UML class.

Therefore such information would not be visible. We

devoted one stereotype, «Doc.SoftwareVersion»,

e.g., to specify software versions for comparison with

known security issues. Authorization is an access

control method which speciﬁes access rights for re-

sources. Information about authentications gives a

better view about security measure of the system.

Stereotype «Doc.Authorization» indicates that a

client who requests a connection to the stereotyped

operation ﬁrst needs to be authorized. Authentication

is a security mechanism for conﬁrming the identity of

data or users. By adding authentication information in

form of the stereotype «Doc.Authorization», our

model will have a more comprehensive view. Sum-

marising, many information is inherently modeled in

the VP. By selecting a component that implements en-

cryption or decryption, the functionality is automati-

cally regarded in the VP. We added these stereotypes

to make this information more explicit in the UML

model.

Data Flow

Data ﬂow graphs and control ﬂow graphs of the

system make it possible to analyze data spread in

the system and detect the accessibility of critical re-

gions. Our security proﬁle offers one stereotype

named «DP.DataFlowElement» which provides in-

formation about the data ﬂow in the system and could

be used for static analysis. The idea is to use UML

state machines to visualize data dependencies and an-

alyze how the protection goals and the attack surface

are linked. We currently evaluate two approaches to

derive this graph: static code analysis and dynamic

taint propagation based on the VP.

We should sum up that our security proﬁle

speciﬁes conﬁdentiality and integrity aspects re-

lated to the attack surface and the protection

goals. Stereotypes «AS.ServiceUnavailable» and

«PG.ServiceAvailability» on the other hand,

speciﬁes requirements for the availability of the sys-

tem. The proﬁle is deﬁned using stereotypes, tag def-

initions and constraints, which are applied to speciﬁc

model elements, like Classes, Attributes, Operations,

and Activities. Table 1 indicates the stereotypes of the

proposed security proﬁle which we described above.

The stereotypes are associated to the UML-based VP-

Spec instead of the other models. We support dif-

ferent M2M-transformation, based on QVTo (OMG,

2011a), for our approach. This way the stereotypes

are indirectly associated with the other models.

Table 1: Extract of the security proﬁle.

Stereotype Base class Tag

AS.DataRead Property Effort

AS.DataModify Property Effort

AS.DataDelete Property Effort

AS.DataAdd Property Effort

AS.ServiceUnavailable Operation Effort

PG.DataConﬁdential Property Severity

PG.DataModify Property Severity

PG.DataDelete Property Severity

PG.DataAdd Property Severity

PG.ServiceAvailability Operation ResTime

Doc.EncryptionProtocol Class String

Doc.SecurityProtocol Class String

Doc.SoftwareVersion Class String

Doc.Authentication Operation

Doc.Authorization Operation

DP.DataFlowElement State

4.1 Comparison

In the following section, we compare our envisioned

proﬁle with the exiting proﬁle UMLsec. As the fo-

cus on UMLsec lies more on enterprise security it

contains stereotypes that are not applicable to embed-

ded systems. Nethertheless, it offers general security

stereotypes and in this section it should be evaluated

if the envisioned proﬁle covers the essential subset of

UMLsec.

UMLsec offers stereotypes like «fair

exchange» and «provable» originating from

e-commerce scenarios. They specify the requirement

of a fair product exchange, e.g. with the help of a

trusted third party or of provable payments. Con-

sidering the focus of our model to the embedded

systems, we did not devote stereotypes for this aspect.

However, it should be mentioned that the function-

ality of these mechanisms is modeled implicitly by

the VP, e.g., by providing simulation modules that

implement a provable payment.

We broke down the role-based access

to the involved mechanisms by using the

stereotypes «Doc.Authentication» and

«Doc.Authorization» to substitute the UMLsec

stereotype «rbac».

UMLsec uses the stereotypes «Internet», «LAN»

and «wire» to model connections with different at-

tack possibilities. Our proposed proﬁle provides

the stereotypes «AS.DataRead», «AS.DataModify»,

«AS.DataDelete» and «AS.DataAdd» to character-

ize the attack surface of different connections. Fur-

thermore, encrypted connections which are mod-

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

606

eled with the stereotype «encrypted» in UMLsec

will be speciﬁed in our proﬁle by the combina-

tion of «AS.DataRead» and «Doc.Encryption».

The stereotypes «smart card», «POS device» and

«issue node» in UMLsec are nodes with varying

protection mechanism. Our stereotypes to specify the

attack surface are used to specify the characteristics

of the different devices.

The assumption of secrecy and integrity as well

as high sensitivity is indicated with the stereo-

types «secrecy», «integrity» and «high» in

UMLsec. In our model, stereotypes for protec-

tion goals can model the secrecy, integrity and level

of sensitivity. The concepts of the stereotypes

«critical», «secure links», «data security»,

« no down-flow » and «no up-flow» are modeled

with the help of the protection goal stereotypes.

The stereotype «Doc.Authorization» speciﬁes

a property which is protected by an authorization

mechanism. This mechanism ensures that the ob-

ject can be accessed only through authorized par-

ties. This is a proper stereotype to model guarded ob-

jects which can be accessed only through their guard.

In UMLsec, this concept is model with the stereo-

types «guarded» and «guarded access». «secure

dependencies» is a stereotype of UMLsec which en-

sures secure dependencies. Secure dependencies are

covered with the stereotypes «Doc.Authorization»

and «Doc.Authentication».

In our opinion, all relevant aspect of UMLsec

can be modeled with our stereotypes on a more ﬁne

grained level, what is necessary for considering em-

bedded security.

4.2 Example

Hacking modern automotive embedded systems often

requires three steps. First, the attacker needs to gain

remote access to the internal network of the vehicle.

This step is usually accomplished by sending wire-

less signals and compromising the control unit in the

front line. This step leads the attacker to the next step,

which is injecting messages to the car network and di-

rectly or indirectly controlling desired electronic con-

trol units (ECUs). Here it should be considered that

in many designs, it is not possible to send a message

to the safety critical ECUs directly. Therefore, the

attacker has to bypass gateway ECUs to forward the

compromised message to the critical ECUs. The last

step will be forcing the target ECU to compromise

safety features. The whole attack needs information

on messages and structure of the automotive network.

Our security proﬁle covers all steps of the attack

by its stereotypes. The stereotype regarding the attack

Figure 3: VPSpec of the simulation component.

surface will mark penetration possibilities. All the

attack points of the various steps should be marked.

That means, not only the ﬁrst attack surface only,

but also it is assumed that an ECU is compromised,

an extended attack surface is possible. This allows

to evaluate isolated attack steps with the VP. The

next information that is speciﬁed in the model are

the protected safety critical ECUs or gateway ECUs.

This is done with the protection goal stereotypes.

Finally, documentation-related stereotypes offer

information about the applied security mechanisms

or software versions to estimate vulnerabilities and

guide the manual penetration tests.

Here we focus on an attack scenario based on the

aqLink protocol within the Gateway which controls

both voice and data cellular communication. First,

an attacker employs some ﬂaws in the authentication

procedure. In a second attack, the attacker uploads

an exploit to the telematics system. The attacker

hacks the head unit and then sends compromised

messages to the safety critical ECUs by spooﬁng

messages. Before the critical ECU can be reached,

the ﬁltering mechanism of the gateway has to be

deactivated. Figure 3 models components involved

in the attack to compromise the gateway. It shows

three components that represent the functionality of

the different ECUs. The fourth component is the

ﬁeld bus used for communication. In the system

structure two instances of the CAN bus are present;

one with sensitive information (Body-CAN) and one

with non-critical signals (Comfort-CAN). The used

structure is shown in Figure 5. The chosen abstrac-

tion level is TLM, because the model is mainly used

for a structural data ﬂow analysis. Some information

stored in the head unit is assumed readable by an

attacker. In this scenario, it is assumed an attacker

Model-guided Security Analysis of Interconnected Embedded Systems

607

Figure 4: Speciﬁcation and analysis ﬂow.

has already compromised the head unit. This infor-

mation is marked as «AS.DataRead». On the other

hand, an internal ECU that is connected to the sec-

ond bus contains information that should not be read

by an attacker. Therefore, this information is stereo-

typed as «PG.DataConfidentiality». The goal of

this abstract VP is to detect security ﬂaws within the

gateway, such as an unauthorized ﬂash mechanism to

change the routing table. In the original scenario,

it was possible to conﬁgure the gateway over CAN.

The conﬁguration included the writing of a ﬁlter that

should prevent sensitive information to be forwarded

on the public CAN. The data ﬂow analysis showed

that both the ﬁlter condition and the forwarded data

where dependent on the same input data, in this case

the CAN message payload. This dependency showed

that if the input data is compromised the ﬁlter is jim-

mied. This very basic example showed how an ex-

ecutable speciﬁcation could be used to analyze the

data propagation paths between the attack surface and

the protection goals to ﬁnd potential weak spots. The

analysis is not yet fully automated. It gives only hints

to the user to take into account, such as this concen-

tration point at the ﬁlter. By adding e.g., an authen-

tication mechanism for overwriting the ﬁlter, the data

ﬂow analysis would show the same result. But the au-

thentication would prevent the attacker from changing

the routing table. Therefore, our approach highlights

a false positive, under the assumption the authentica-

tion is not corruptible.

5 VIRTUAL PROTOTYPE

FRAMEWORK

The presented approach uses a subset of the UML to

specify the VP and its security analysis related infor-

mation. In this section, the link between the modeling

and the VP should be described. An overview is given

in Figure 4.

As already highlighted, the UML-based VPSpec

is basis for the security analysis. The simulation

library is generated from this speciﬁcation. The

library contains all system components required for

one simulation run. This library is compiled and for

each simulation run a conﬁguration ﬁle is given that

determines the simulation instance. This conﬁgu-

ration ﬁle is again generated from the UML-based

VPSpec. The different security analyses, such as the

dynamic data ﬂow analysis or the manual penetration

testing are based on the executable simulation.

Before going into detail on how the VP is linked

to the VPSpec, let highlight the general procedure

of our VP approach. The VP consists of the design

under test (DUT) and its test bench. The DUT

models software, hardware and analog system parts.

It consists of a modular, parameterizable system

simulation. One simulation instance is assembled of

parameterizable simulation entities (SEs). To facil-

itate the analysis of different DUT characteristics,

the framework uses a dynamic conﬁguration that

is supplied during runtime. This covers the DUT

architecture as well as the SEs parameterization. This

provides a high re-usability of existing simulation

models.

The components of the VP are speciﬁed using

UML class diagrams. Each simulation component

can be speciﬁed using an UML class, attributes

and operations. Dedicated stereotypes, to specify

SystemC related declarations such as SystemC

threads (sc_thread) are added with additional pro-

ﬁles, beside the already highlighted security proﬁle.

Based on the VPSpec automatically the structural

aspects of the C++ code are generated. This covers

all class deﬁnitions, member variables and member

methods as well as SystemC macro deﬁnitions such

as SC_HAS_PROCESS. The member methods are

only generated as empty stubs which have to be

implemented by the user. The code generation is

realized, by different Java Emitter Templates (JET).

One key element of our VP-based approach is

that the VP is assembled and conﬁgured by a ﬁle dur-

ing execution. All VP components provide a fabric

method to dynamically instantiate and conﬁgure them

as well as some methods to interconnect the created

instances. This way it is not necessary to program a

top module that assembles and conﬁgures all compo-

nents. The conﬁguration ﬁle is an IP-XACT design

speciﬁcation (SPIRIT Consortium, 2009) that lists

all the components to instantiate, how to parametrize

them and how to interconnect them. Basis for the

generation of the conﬁguration ﬁle is an UML com-

posite structure diagram.The diagram instantiates the

already deﬁned classes, assigns parameters and inter-

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

608

Figure 5: UML model to specify the simulation structure.

connects them. Figure 5 highlights such a speciﬁca-

tion. It instantiates the classes from Figure 3 and in-

terconnects them. With such a speciﬁcation, the con-

ﬁguration ﬁle is generated and the simulation is ex-

ecuted. The example shows the structural speciﬁca-

tion of the previous example with a head unit an inter-

nal CAN (Body-CAN) and a public CAN (Comfort-

CAN). Both are interconnected via a gateway that is

the target of the analysed attack.

6 CONCLUSION

In this paper, we outlined our ambition towards the

modeling of security concepts in the context of VP-

based security analyses. Modeling is applied for the

speciﬁcation of the attack surface, protection goals

and further documentation. With this comprehensive

information base, different security analysis based on

VPs are executed, such as a dynamic data propagation

analysis or virtual penetration testing. Currently the

available analyses are largely manual tasks e.g., the

interpretation of the data propagation analysis to see

if the attack surface is linked to the protection goals,

without security measures. In the future, we will try

to automate the tasks and reduce the manual overhead

for the user. The presented modeling approach al-

ready provides various steps of automation, but these

mainly support the user to generate the VP and plan

the attack scenarios.

ACKNOWLEDGEMENTS

The work was partially funded by the Baden-

Württemberg Stiftung gGmbH.

REFERENCES

Basin, D., Doser, J., and Lodderstedt, T. (2006). Model

driven security: From uml models to access control

infrastructures. ACM Trans. Softw. Eng. Methodol.

Best, B., Jurjens, J., and Nuseibeh, B. (2007). Model-based

security engineering of distributed information sys-

tems using umlsec. In 29th International Conference

on Software Engineering.

Bresciani, P., Perini, A., Giorgini, P., Giunchiglia, F., and

Mylopoulos, J. (2004). Tropos: An agent-oriented

software development methodology. Autonomous

Agents and Multi-Agent Systems, 8(3):203–236.

Charlie, M. and Chris, V. (2015). Remote exploitation of an

unaltered passenger vehicle. Black Hat USA, 2015.

Checkoway, S., McCoy, D., Kantor, B., Anderson, D.,

Shacham, H., Savage, S., Koscher, K., Czeskis, A.,

Roesner, F., and Kohno, T. (2011). Comprehensive

experimental analyses of automotive attack surfaces.

In Proceedings of the 20th USENIX Conference on

Security, SEC’11, pages 6–6, Berkeley, CA, USA.

USENIX Association.

IEEE Computer Society (2011). IEEE 1666-2011 Stan-

dard SystemC Language Reference Manual. IEEE Std

1666-2011.

Jürjens, J. (2002). Umlsec: Extending uml for secure

systems development. In Proceedings of the 5th

International Conference on The Uniﬁed Modeling

Language, UML ’02, pages 412–425, London, UK.

Springer-Verlag.

Jürjens, J. (2010). Secure Systems Development with UML.

Springer-Verlag, Berlin, Heidelberg.

Lodderstedt, T., Basin, D., and Doser, J. (2002). Se-

cureUML: A UML-Based Modeling Language for

Model-Driven Security, pages 426–441. Springer

Berlin Heidelberg, Berlin, Heidelberg.

Massacci, F., Mylopoulos, J., and Zannone, N. (2010). Se-

curity Requirements Engineering: The SI* Modeling

Language and the Secure Tropos Methodology, pages

147–174. Springer, Berlin, Heidelberg.

OMG (2011a). Meta Object Facility (MOF) 2.0

Query/View/Transformation Speciﬁcation.

OMG (2011b). Uniﬁed Modeling Language.

OMG (2012). OMG Systems Modeling Language (OMG

SysML).

Reiter, S., Viehl, A., Bringmann, O., and Rosenstiel, W.

(2016). Fault injection ecosystem for assisted safety

validation of automotive systems. In 2016 IEEE Int.

High Level Design Validation and Test Workshop.

Sommestad, T., Ekstedt, M., and Holm, H. (2013). The cy-

ber security modeling language: A tool for assessing

the vulnerability of enterprise system architectures.

IEEE Systems Journal, 7(3):363–373.

SPIRIT Consortium (2009). IEEE Standard for IP-XACT,

Standard Structure for Packaging, Integrating, and

Reusing IP within Tool Flows.

Model-guided Security Analysis of Interconnected Embedded Systems

609