Emergency Systems Modelling using a Security Engineering Process

Jose Fran. Ruiz

, Antonio Ma

, Marcos Arjona

and Janne Paatero

Fraunhofer SIT, Darmstadt, Germany

Computer Science Department, University of Malaga, Malaga, Spain

RUAG Switzerland Ltd., Bern, Switzerland

Keywords:

Security, Conceptual Modeling, Emergency Support Tools, Domain-speciﬁc Tools, Case Studies.

Abstract:

The engineering and development of complex security-sensitive systems is becoming increasingly difﬁcult due

to the need to address aspects like heterogeneity (of application domains, requirements, regulations, solutions,

etc.), dynamism and runtime adaptation necessities, and the high demands for security and privacy of the

users and agencies involved in scenarios where these systems work (natural disasters, accidents, terrorism,

etc.). Moreover, security knowledge is highly domain-dependent and dynamic. These characteristics make the

development of those systems hard because the amount of security knowledge required to dealing with such

a huge variety of situations, which becomes way too large for a human. We propose in this paper a security-

oriented engineering process that is especially useful for these systems. It makes security ﬁt naturally in the

systems by interleaving security into the initial architecture and system description. In particular, the proposed

process provides means to identify and manage security properties in a consistent and intuitive manner. To

illustrate our experience we use a real-world emergency response scenario. More concretely, we focus on the

establishment of a secure ad-hoc wireless mesh communication, which is a key component in the domain of

spontaneous broadband communication among crisis management vehicles.

1 INTRODUCTION

The engineering and development of complex

security-sensitive systems is becoming increasingly

difﬁcult due to the need to address aspects like het-

erogeneity (of application domains, requirements,

threats, regulations, suitable solutions, etc.), dy-

namism and runtime adaptation necessities, and the

high demands for security and privacy of the users

and agencies involved in scenarios where these sys-

tems work (natural disasters, accidents, terrorism,

etc.). Moreover, security knowledge is very domain-

dependent and dynamic. Threats, properties, solu-

tions, etc. that are valid or relevant in a given domain,

are not applicable to other domains and are subject to

constant changes. These characteristics make the de-

velopment of those systems hard because the amount

of security knowledge required for dealing with such

a huge variety of situations, becoming way too com-

plex for a human.

Besides, most of the time, these systems must use

externally developed components that have a complex

set of characteristics according to their security fea-

tures. In particular, security requirements are espe-

cially hard to properly address because of the domain-

speciﬁc knowledge required to understand their secu-

rity concepts.

Modelling is one of the most important activities

in the process of engineering these systems because

it establishes the foundations for the rest of the en-

gineering activities. Unfortunately, current modelling

formalisms do not seamlessly and naturally integrate

security. Ideally, a security modelling activity should

(i) be able to coherently deal with the different ele-

ments and concepts that are related to security (prop-

erties, requirements, threats, attacks, veriﬁcation, as-

surance, etc.) and (ii) be useful as a basis for the se-

lection and integration of appropriate security solu-

tions during the design phase, for the conﬁguration

of the security components during the deployment

phase, for facilitating the testing phase and even for

streamlining system evolution.

This paper describes the experience of using a

novel secure modelling and engineering process de-

veloped in the EU SecFutur project (SecFutur Con-

sortium, 2010). The main objective of SecFutur is

supporting the development of dependable and se-

cure systems composed of embedded components.

117

Ruiz J., Maña A., Arjona M. and Paatero J..

Emergency Systems Modelling using a Security Engineering Process.

DOI: 10.5220/0004480201170124

In Proceedings of the 3rd International Conference on Simulation and Modeling Methodologies, Technologies and Applications (SIMULTECH-2013),

pages 117-124

ISBN: 978-989-8565-69-3

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

To this aim, SecFutur has developed a new security

modelling framework and an associated engineering

process that can ﬂexibly integrate security consider-

ations into the system design and can be easily in-

corporated into existing engineering processes. The

security solutions are provided in terms of SecFutur

Patterns (SFP) and Security Building Blocks (SBBs)

(Grawrock, 2009) (Pearson, 2002), which integrate

existing hardware and software security mechanisms

in order to provide complex security properties. The

architecture of the SecFutur Modelling Framework

(Jose Fran. Ruiz and Ma

na, 2011) is based on the

UML metamodeling capabilities and is composed of

three different layers that cover different objectives.

To illustrate our experience we use a real-world

emergency response scenario. More concretely, we

focus on the establishment of a secure ad-hoc wire-

less mesh communication, which is a key component

in the domain of spontaneous broadband communi-

cation among crisis management vehicles. The com-

munication between the vehicles occurs on a tactical

level, without any ﬁxed or deployable communica-

tion infrastructure available. Depending on the type

of emergency or crisis, the ﬁxed and deployed infras-

tructure may be totally destroyed or partially avail-

able. In the latter case, the tactical communication is

augmented with backhaul links to headquarters.

The rest of the paper is structured as follows: in

Section 2, we describe the state of the art of the cur-

rent modelling and engineering processes. Section 3

presents the proposed security engineering process.

Section 4 describes the real-world scenario we use as

an example. Section 5 contains the modelling of the

scenario and Section 6 discusses the beneﬁts and con-

clusions of the engineering process.

2 RELATED WORK

Currently, although some companies use security en-

gineering processes in the development of their sys-

tems, usually, these practices for modelling systems

with security properties consist of a traditional sys-

tem modelling, subsequent implementation and test-

ing, combined with ad-hoc methods (”gut feeling”) to

deﬁne security issues and, in the best cases, some iso-

lated systematic threat modelling. Most of the times

those issues are only considered after the architectural

and functional design of the system.

The Uniﬁed Modeling Language (UML) has be-

come the de-facto standard notation for system devel-

opment. This language is well supported by platforms

and tools and suited for deﬁning designs at high ab-

straction levels. It offers an excellent opportunity to

close the gap between software and security engineer-

ing and to support the development of security-critical

systems in an industrial setting. Although originally

not based on UML, the work proposed in (Peter Her-

rmann, 2006) includes an extension intended to sup-

port the development of an abstract UML-based busi-

ness process speciﬁcation.

UMLsec (J

urjens, 2001) is proposed as an ex-

tension of UML for modelling security properties

of computer systems. Unfortunately, UMLsec only

addresses a few speciﬁc security requirements and

doesn’t allow to create complex or composed ones

that can be necessary for a speciﬁc scenario.

Model Driven Security (Basin et al., 2003) is a

specialization of the MDA approach that proposes

a modular approach combining languages for mod-

elling system design with languages for modelling se-

curity. One of these languages for modelling security,

called SecureUML (T. Tryfonas, 2001), is only used

to describe role-based access control policies.

Another recent approach proposes to integrate se-

curity and systems engineering using elements of

UML within the Tropos methodology (Castro et al.,

2001) and (Mouratidis et al., 2003). This approach is

a requirement-driven process, therefore it collects all

the requirements and the system is modeled as a com-

position of subsystems interconnected through data.

The complexity of obtaining how the actors interact

and the sequence of their actions hinders a friendly

approach to this engineering process. Also, the engi-

neer needs to have speciﬁc knowledge of the scenario

and the necessary security properties to fulﬁll them.

Another interesting approach to the introduction

of security, focused on the concept of risk, in the de-

velopment cycle is presented in (Dimitrakos et al.,

2002). This process begins with a rigorous analysis

of the context, collecting different aspects and con-

cerns such as the speciﬁc requirements. The risks

are identiﬁed and analyzed, in order to be included in

later stages of the process, but this approach merges

entities with different natures and behaviors such as

threats, vulnerabilities or incidents, treating them in

the same way and ignoring their own characteristics.

Finally, on the conceptual level, the Systems Se-

curity Engineering Capability Maturity Model (SSE-

CMM) (SSE-CMM, ) highlights the relationship be-

tween security engineering and systems engineering,

regarding the former as an integral part of the latter

and not an end by itself. On the other hand it does not

provide any concrete realization of the proposed inte-

grated treatment of security and systems engineering.

This overview shows that, based on the variety

of different approaches, and although several speciﬁc

properties can be considered more or less rigorously

SIMULTECH2013-3rdInternationalConferenceonSimulationandModelingMethodologies,Technologiesand

Applications

118

in the development process, there is still a large gap

between the integration of security and systems engi-

neering. The goal of the SecFutur process is precisely

to ﬁll that identiﬁed breach by providing an security

engineering process with tool support, allowing rigor-

ous treatment of security and reliability requirements

and making the experience and knowledge of security

experts available for system engineering.

3 SECURITY ENGINEERING

PROCESS AND ARTEFACTS

The main objective of the SecFutur Security Engi-

neering Process is to help developers and engineers in

the treatment of security aspects and the use of secu-

rity elements in order to enhance system models with

security. This is done by applying security properties

in order to fulﬁll the security requirements of the sys-

tem, which are obtained by means of a security anal-

ysis of the targeted scenario. Our proposed security

engineering process integrates security solutions into

a modelling framework which can be easily integrated

with other processes.

3.1 Artefacts

The architecture of the artefacts of the security engi-

neering process is composed of three different layers

that aim at different objectives. Each layer is based

on the previous one and deﬁnes a more speciﬁc model

of security aspects. Figure 1 shows the dependencies

between the different layers. Due to the limitation of

the paper we only present the description and func-

tionality of each layer. The three layers of the SecFu-

tur framework are based on the UML Standard Meta-

model. However, it is important to clarify that we use

the term domain to refer to speciﬁc application do-

mains (e.g. wireless sensor networks, smart metering

systems, etc.), while in the ﬁeld of modelling it is nor-

mally associated with the notion of Domain Speciﬁc

Figure 1: Layers in the SecFutur Engineering Process.

Language (DSL), and focused on code generation.

The ﬁrst (most abstract) SecFutur layer is called

Core Security Metamodel (CSM) and is materialized

as a metamodel that contains elements (in the form

of UML meta-classes) and relations to represent rel-

evant security concepts, such as properties, require-

ments, threats, attacks, assumptions, actors, tests,

etc. This layer deals only with concepts (e.g. ”at-

tack”) and not with instances of these concepts (e.g.

”distributed denial of service”). Thus, this layer is

domain-independent and we could say that it deﬁnes

the common language (vocabulary, rules, etc.) to ex-

press security-related information. Figure 2 shows an

example of a CSM.

The CSM presented in Figure 2 shows only the

classes and relations between the elements. Due to

size limitations we do not show the attributes of each

element but these metaclasses contains relevant ﬁelds

for the language usability, such as attributes to iden-

tify the author, version, description or to include ref-

erences to external components. The elements of the

CSM focus on different targets. In order to facilitate

the understanding of the CSM we have divided it into

six different expertise subsets. Each one focuses on a

security concept. The different subsets are:

• Properties Model (SF PM): focuses on the deﬁni-

tion of security properties and its characteristics

• Requirements Model (SF RM): describes the re-

lations between security properties, requirements

and solutions

• Threat Model (SF TM): deﬁnes and describes se-

curity threats, attacks and attackers

• Domain Model (SF DM): represents the do-

main to which the DSM is applicable, includ-

ing the domain-related elements of the real world

(database, communication networks, etc.) and the

list of known actors or roles of the domain

• Assurance Model (SF AM): represents the assur-

ance and certiﬁcation mechanisms used in the do-

main

• V&V Model (SF VVM): this part of the meta-

model is used to represent validation and veriﬁ-

cation approaches such as testing strategies, etc.

Despite the conceptual division in subsets aiming

at facilitating the understanding of such a complex

metamodel, the CSM is a single metamodel and can-

not be splited.

The speciﬁcation of the security knowledge for

a speciﬁc domain is done in the second layer of

the framework by creating a Domain Security Meta-

model (DSM). DSMs allow experts to capture secu-

rity knowledge (properties, solutions, threats, etc.) for

EmergencySystemsModellingusingaSecurityEngineeringProcess

119

Figure 2: Extract of the CSM.

a speciﬁc domain. Some examples of domains are

Trusted Meters, Secure Cash Systems, etc. and every

one has a unique set of characteristics, constraints, se-

curity properties, etc. One domain and its correspond-

ing DSM is distinguished from another one by means

of the deﬁnition of the domain instance, its attributes,

objective and identiﬁer.

SecFutur promotes separation of duties, allowing

experts to deﬁne models in their domain of expertise

(e.g. a standardization body) or domain of authority

(e.g. the security ofﬁcer of a company). An addi-

tional advantage of this approach is that applications

are decoupled from the speciﬁc security aspects of the

context, which are captured in the DSM. This ensures

that application designs remain valid for all those con-

texts. There can be as many DSMs as application do-

mains, and these can be combined in a modular way.

Finally, the System Model (SM) describes the

UML model of the targeted system. The SM has the

information of the targeted scenario and the security

properties that make it secure (according to the secu-

rity requirements obtained in the security analysis of

the system done by the System Engineer). Besides,

the security properties have information such as the

attacks that could compromise that property, the tests

that could be done to check the resilience of the sys-

tem, the assumptions of the solution, etc.

3.2 Security Modelling Activities

The SecFutur Security Engineering Process for the

creation of complex systems is done by means of the

System Engineers. They access DSM repositories in

order to obtain the data and objects for their mod-

elling scenarios. In particular, they select DSMs for

their domains, import them into their model and then

use the elements of the DSM to express the security

aspects of their systems.

A System Engineer can use one or more DSMs for

her modelling. It depends on the number of domains

the scenario has. She uses many security properties

of the DSM (or DSMs) in order to fulﬁll the secu-

rity requirements of the system. Once she uses one

she needs to deﬁne the requirement class of the se-

curity property, as it will help later in the implemen-

tation phase. A description of the creation and use of

the other artefacts of the Security Engineering Process

can be found in (Jose Fran. Ruiz and Ma

na, 2011).

3.3 Tool Support

The SecFutur Process Tool (SPT) is a plugin for Mag-

icDraw (NoMagic, 1995), designed to help and sup-

port security engineers in using the SecFutur Secu-

rity Engineering Process. The tool provides speciﬁc

functionalities for the different actors and activities

described above. Figure 3 depicts the Imported Prop-

erties browser showing the properties contained in a

DSM (in this case ”MANET (Mobile Ad-hoc NET-

work) for Emergency Systems”). In this Figure, the

properties are classiﬁed according to the type of ele-

ment they can be applied to. For instance, the prop-

erty ”Storage Integrity” can be applied to Classes and

Attributes. The Figure shows other info such as the

CSM used to create the DSM (SecFutur CSM v2.6),

the name and version of the DSM, the info of a se-

lected security property (Secure Conﬁdentiality), etc.

SIMULTECH2013-3rdInternationalConferenceonSimulationandModelingMethodologies,Technologiesand

Applications

120

Figure 3: SPT Property Browser.

4 SCENARIO DESCRIPTION

The mobile command post (MCP) use case is illus-

trated in Figure 4. Typically, in this scenario, vari-

ous agencies such as ﬁre ﬁghters, police and rescue

teams, work in a joint mission. Such missions can

be known in advance and thus pre-planned (e.g. in

the case of major events, like concerts or large sports

events) or they can be spontaneous (e.g. in case of en-

vironmental catastrophes or serious accidents). The

action forces of the agencies build a MCP network

(referred to as Mesh in the ﬁgure) on demand on site.

The MCP network is based on ad-hoc mesh net-

work technology. This type of network operates au-

tonomously in a self-conﬁguring manner, thus de-

creasing the deployment burden by reducing the en-

tire networking conﬁguration effort. The intercon-

nection between vehicles and action forces is typi-

cally based on wireless communication technology.

In addition to the communication services in the oper-

ational area, an interconnection to external networks,

backbones and terrestrial infrastructure is typically re-

quired in order to reach various information systems

available in headquarters as shown in Figure 4.

In the MCP network scenario we adopt the ar-

chitectural approach of an infrastructure mesh. The

network is based on a series of trusted mesh network

nodes (TMN) with the functionality of a mesh router

and used to build a mesh backbone. TMNs are de-

ployed in vehicles and are responsible for building

the mesh infrastructure, providing network connec-

Figure 4: Mobile Command Post Scenario Overview.

tivity, packet routing and forwarding to other mesh

routers. Action forces use client devices (e.g. phone,

PDA, computer) with different applications installed

in them. These client devices are connected to TMNs

through wireless or wired links.

Our use case focuses on the dependability of the

network infrastructure itself, excluding the applica-

tion, clients and user domain based security issues.

The rationale behind this decision is the following:

in an ad-hoc mesh network, new security challenges

emerge. Since nodes build the network spontaneously

and they can join and leave the network at any time,

nodes have to be able to recognize trusted communi-

cation partners, to detect malicious or compromised

nodes and to exclude such nodes from the network.

Therefore, authentication and authorization of nodes

are key security functions to ensure authorized ac-

cess to the network and to information sources on

nodes. Additionally, secure storage of information on

nodes and secure key distribution and storage for se-

curity protocols are key features. Because of wireless

communication links, integrity and conﬁdentiality of

transferred data is especially important.

The security requirements of the use case are

listed below.

• Authentication and trust establishment between

TMNs: before connecting to each other the TMNs

authenticate mutually using cryptographic means

and prove their trust states.

• Authenticity of mesh network topology: only au-

thenticated and trusted TMNs can be part of the

trusted mesh network.

• Conﬁdentiality of mesh network topology: the

mesh network topology information must remain

conﬁdential to trusted TMNs.

• Authenticity of payload trafﬁc: payload trafﬁc (all

trafﬁc except the mesh routing protocol trafﬁc)

sent between TMNs must be authentic.

• Conﬁdentiality of payload trafﬁc: the payload

trafﬁc sent between TMNs remains conﬁdential

for trusted TMNs.

EmergencySystemsModellingusingaSecurityEngineeringProcess

121

• Protection of log data: the integrity of the infor-

mation about events and system logs stored in

TMNs must be protected.

5 MODELLING OF THE

SCENARIO

This section presents the modelling of the use case

using the Security Engineering Process. We focus on

the parts of the process that are directly related to the

modelling of the system. First we start with the de-

scription of the key characteristics of the emergency

system scenario, next we describe the results of the

analysis of the security requirements of the system.

We also summarize the creation of the DSM used in

this scenario and the development of the SM with the

security aspects included.

Following on from this, we present some (of

many) of the technical key characteristics, assump-

tions and constraints of the TMN devices:

• TMNs are installed in vehicles, therefore power

consumption (e.g. battery life) is not a primary

design criterion. Physical access to the installed

devices is secured.

• Communication between the vehicles is primarily

wireless and must be secured.

• We assume that the mission planning and conﬁgu-

ration phase is carried out by trustworthy person-

nel in a physically secure environment.

• The devices are assumed to be free of malicious

behaviour when correct states are deﬁned in the

mission planning and conﬁguration phase.

The Security Requirements and Functionality

Analysis describes the analysis and description of the

emergency use case. The analysis is focused on the

modelling activity, so all the descriptions are high-

level abstractions of the system functionality.

In order to present a better analysis of the system

we divided it into different sub-scenarios. Due to the

limitation in size of the paper we present only the se-

curity requirements analysis of the Mission Planning

and Conﬁguration phase of the TMNs. This scenario

deals with the preparation of different missions by

creating different models of typical mission conﬁg-

urations that are later activated when necessary. It is

composed of three different use cases: deﬁne and gen-

erate mission-speciﬁc conﬁguration, activate or re-

move functionality and update software packages.

After analyzing these use cases, we describe and

model their functionality and security requirements

using diagrams. The security deﬁnitions are:

• Deﬁne and generate mission-speciﬁc conﬁgura-

tion security properties: secure authentication,

generate conﬁgurations (uses conﬁdentiality and

integrity) and acknowledgments (secure commu-

nication property).

• Activate or remove functional security properties:

authentication, secure install or remove software

components and acknowledgments.

• Update software packages: authentication, secure

install and secure remove.

Regarding the modelling part, this scenario has

only one domain (from the security point of view):

MANET for Emergency Systems. Consequently, we

must import into our model the corresponding DSM.

Normally, this DSM should be available when the sys-

tem modelling starts, acting as a security library ready

to be imported. In the speciﬁc case of our experience,

we developed such DSM, as the modelling approach

is still under development in the project. The design

of DSMs is done by the Security Domain Experts,

therefore, we consulted security experts at RUAG .

The creation of DSMs gathers and represents the se-

curity knowledge of the domain, which is not related

to a particular application. Therefore, the DSM con-

tains a large number of elements.

To illustrate this modelling activity, we use the

features of the SPT from the approach of a Security

Domain Expert. We focus on one speciﬁc security

property (Storage Integrity) and show the part of the

model that is directly linked to this property. In order

to create the DSM we start with an empty model con-

taining the CSM . Once the CSM language is loaded,

we start adding instances of the CSM metaclasses for

the elements. We present only some of them in this

paper. We create an instance for the domain called

”MANET for emergency scenarios”. We add an in-

stance for the Property ”Storage Integrity”, we deﬁne

the Element Type ”Class” where it can be applied us-

ing an standard ”Association” and we add a security

threat called ”Data Alteration”. We continue adding

other related elements such as attacks, attacker types,

solutions (in the form of SBBs), etc. For each ele-

ment we also complete additional internal informa-

tion to further describe it. Completely ﬁll the DSM

is beyond the scope of this paper, but to help readers

understand the result, Figure 5 shows a partial view

focused on the Storage Integrity property.

The development of the System Model is essen-

tially a normal UML modelling. We (in this case with

the role of System Engineer) start by importing the

appropriate DSM from a repository of DSMs, as if

they were security libraries, and then we model the

system including classes, methods, relations, etc.

SIMULTECH2013-3rdInternationalConferenceonSimulationandModelingMethodologies,Technologiesand

Applications

122

Figure 5: Partial view of the MANET for emergency scenarios DSM.

As we add classes to represent elements of our

system, we link the ones with security requirements

(obtained after doing the security analysis of the sys-

tem) to the corresponding security properties of the

DSM in order to fulﬁll the security requirements. This

is done by using the SPT. If we select an element and

right-click on it, it will show the possible properties

that can be attached to it( this is deﬁned in the DSM).

When the system engineer selects one of the proper-

ties the tool automatically creates and imports all the

related elements of the security property such as so-

lutions (SBBs), threats, assumptions, etc. to the ele-

ment of the system model, as we can see in Figure 6.

The tool also allows users to select the visibility of the

different elements that are automatically added to the

model, in order to avoid overcomplicating view. For

instance, we can choose to see only the requirements.

In a later stage, when all the security requirements of

the scenario are fulﬁlled, the tool will allow us to re-

place security properties by speciﬁc solutions (SBBs),

thus evolving the security elements from the require-

ments phase to the design phase.

6 CONCLUSIONS

The main goal of the security engineering process is

a clear separation between the expertise domains. Se-

curity engineering is not only the task of the highly

experienced security expert. Using this approach, also

system engineers are in a position to make sound se-

curity engineering decisions. In general terms, the

integration of security engineering into the regular

UML-based system engineering has at least two ben-

eﬁts. First and foremost, as security engineering is

naturally integrated from the beginning into the mod-

elling process, it helps to avoid design decisions that

are contrary to the security requirements (a frequent

problem when security is only considered in the ﬁnal

stages of development). Second, the SecFutur arte-

facts provide a common language for the roles in-

volved in the engineering of the system, facilitating

their communication.

The SecFutur process is especially designed to ﬁt

into modern iterative (or even agile) development pro-

cess as it is based on a model-driven philosophy. The

approach is based on the following principles:

• Modelling and implementation should be consid-

ered, communicated and managed to be iterative.

The model should be allowed to change between

iterations, as design is emergent.

• Modelling and implementation can be done even

in parallel. Often an implementation (even par-

tial) helps to identify which design makes sense.

This emphasizes that design is emergent, and usu-

ally the form (design) follows the function (imple-

EmergencySystemsModellingusingaSecurityEngineeringProcess

123

Figure 6: Security Property Imported into a System Model.

mentation).

• The savings originate from reuse. The SecFutur

engineering process supports reuse in the form of

the DSMs and, in particular, the SBBs.

Summarizing our conclusions, we have presented and

applied the novel security engineering approach to a

real engineering use case, the emergency systems sce-

nario. The experience suggests (from real experiences

in the SecFutur project) that the novel approach is

combinable with the already existing engineering for-

malisms and iterative and agile development methods.

ACKNOWLEDGEMENTS

This work is partially supported by the E.U. through

FP7 project SECFUTUR (IST-256668) and FP7

project CUMULUS (IST-318580).

REFERENCES

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

driven security for process-oriented systems. In SAC-

MAT ’03: Proceedings of the eighth ACM symposium

on Access control models and technologies. ACM

Press.

Castro, J., Kolp, M., and Mylopoulos, J. (2001). A

requirements-driven development methodology. In

Proc. of the 13th Int. Conf. On Advanced Information

Systems Engineering (CAiSE).

Dimitrakos, T., Ritchie, B., Raptis, D., and Stølen, K.

(2002). Model based security risk analysis for web

applications: the coras approach. In Proceedings of

the 2002 international conference on EuroWeb.

Grawrock, D. (2009). Dynamics of a Trusted Platform: A

Building Block Approach. Intel Press (2009).

Jose Fran. Ruiz, R. H. and Ma

na, A. (2011). A security-

focused engineering process for systems of embedded

components. SD4RCES 2011.

urjens, J. (2001). Towards development of secure systems

using umlsec.

Mouratidis, H., Giorgini, P., and Manson, G. (2003). Inte-

grating security and systems engineering: Towards the

modelling of secure information systems. In Proceed-

ings of the 15th Conference On Advanced Information

Systems Engineering (CAiSE). Springer-Verlag.

NoMagic (1995). Magicdraw uml tool.

Pearson, S. (2002). Trusted computing platforms, the next

security solution. Technical report, Trusted Systems

Lab, HP Laboratories.

Peter Herrmann, G. H. (2006). Security-oriented reﬁne-

ment of business processes. springer-verlag. Elec-

tronic Commerce Research Journal, 6.

SecFutur Consortium (2010). Design of secure and energy-

efﬁcient embedded systems for future internet appli-

cations (secfutur), ist-25668. fp7.

SSE-CMM. The systems security engineering capability

maturity model (sse-cmm).

T. Tryfonas, E. Kiountouzis, A. P. (2001). Embedding se-

curity practices in contemporary information systems

development approaches. Information Management &

Computer Security, (4).

SIMULTECH2013-3rdInternationalConferenceonSimulationandModelingMethodologies,Technologiesand

Applications

124