A Model-driven Approach for Securing Software Architectures

∗

Mario Arrigoni Neri

, Marco Guarnieri

, Eros Magri

, Simone Mutti

and Stefano Paraboschi

Dip. di Ingegneria Informatica e Metodi Matematici, University of Bergamo, Bergamo, Italy

Institute of Information Security, ETH Zürich, Zürich, Switzerland

Comelit R & D, Comelit Group S.p.A, Rovetta S. Lorenzo, Italy

Keywords:

Access Control, Model-driven Security, Security Policy, Software Architectures.

Abstract:

Current IT systems consist usually of several components and services that communicate and exchange data

over the Internet. They have security requirements that aim at avoiding information disclosure and at showing

compliance with government regulations. In order to effectively handle the security management of complex

IT systems, techniques are needed to help the security administrator in the design and conﬁguration of the

security architecture. We propose a model-driven security approach for the design and generation of concrete

security conﬁgurations for software architectures. In our approach the system architect models the architecture

of the system by means of UML class diagrams, and then the security administrator adds security requirements

to the model by means of Security4UML, a UML proﬁle. From the model enriched with security requirements,

the concrete security conﬁguration is derived in a semi-automated way. We present a tool that supports this

model-driven approach, and a case study that involves a distributed multi-user meeting scheduler application.

1 INTRODUCTION

IT systems are becoming more and more complex as

the range of offered services increases and the capa-

bilities of the systems themselves improve. Current

IT systems consist usually of several components and

services communicating and exchanging data over

complex IT infrastructure through the Internet. These

systems usually have strict and complex security re-

quirements, which are needed in order to adequately

protect sensitive data and to assure the availability of

the systems themselves ((Patterson, 2002; Pertet and

Narasimhan, 2005) analyze the costs of unavailabil-

ity of applications). The management of security re-

quirements is a critical task that has the goal of avoid-

ing possible informationdisclosure and showing com-

pliance with respect to the many regulations promul-

gated by governments.

The security of the global system arises both from

the security of the components and from the correct

conﬁguration of the entire IT infrastructure. Manag-

ing the security of these systems is a tough task, be-

∗

This work was partially supported by the EC within the

7FP, under grant agreement 257129 “PoSecCo” and 256980

“NESSoS”, by the Italian Ministry of Research within the

PRIN projects “PEPPER 2008”, “GATECOM” and “Gen-

Data 2020”.

cause the high number of components, which usually

need an access to the Internet, leads to a large attack

surface, whilst the high level of interconnections be-

tween components increases the damage that an at-

tack to one of the components may cause to the en-

tire system. Recent analysis of information security

breaches has found empirical evidence that highlights

the fact that security management is a difﬁcult and

error prone task, (e.g., (7safe, 2010; Langevin et al.,

2008)) showing that misconﬁgurations of the security

infrastructure are one of the main causes of breaches.

A viable way for handling the complexity of se-

curity management is by using a model-driven ap-

proach. In a way similar to the evolution seen in

the area of software development and database de-

sign, the model-driven engineering of security leads

to the speciﬁcation of security requirements at an ab-

stract level, with the subsequent reﬁnement of the ab-

stract model toward a concrete implementation. It is

then guaranteed that, when the high-level representa-

tion of the security requirements is correct, the secu-

rity conﬁguration of the system satisﬁes the require-

ments. The application of this approach requires the

implementation of a rich collection of tools support-

ing, for each of the many components in the system,

the reﬁnement from the high-level representation of

security requirements to the concrete security con-

595

Arrigoni Neri M., Guarnieri M., Magri E., Mutti S. and Paraboschi S..

A Model-driven Approach for Securing Software Architectures.

DOI: 10.5220/0004611305950602

In Proceedings of the 10th International Conference on Security and Cryptography (SECRYPT-2013), pages 595-602

ISBN: 978-989-8565-73-0

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

ﬁguration. A signiﬁcant investment in research and

development is needed to realize this vision, in or-

der to manage the heterogeneous collection of devices

and security services that information and commu-

nication technology offers to system administrators.

Still, this large investment promises to produce ade-

quate returns, considering the importance that the cor-

rect management of security requirements presents in

modern information systems.

The model-driven approach described above has

several advantages: (1) the concrete conﬁguration can

be generated in a semi-automated way from the mod-

els (in this way the risk of misconﬁgurations is low),

(2) the models can be analyzed for an early identiﬁca-

tion of anomalies and inconsistencies, (3) the models

act as documentation of the security architecture of

the system, (4) the modeling process requires that the

security administrator deﬁnes the security properties

of the system and explicits the assumptions behind the

requirements, (5) it allows the adoption of a defence-

in-depth approach that deploys security countermea-

sures at several layers, (6) changes in the security re-

quirements can be effectively handled by modifying

the initial model and then by generating the new con-

crete conﬁguration.

Integrating this model-driven security approach

with Architecture Description Languages (ADLs) can

lead to great advantages. Software architectures are

produced in the early steps of the development pro-

cess, and thus integrating security properties in archi-

tecture design allows developers to integrate security

early in the development process. In this way, devel-

opers consider security during the whole process and

not only as an afterthought, and they can also analyze

early security conﬁgurations in order to detect ﬂaws.

This fact leads to better security and reduces the costs

of changes in the security conﬁguration.

In this work, we present an approach that can

be used to add security requirements to architectural

models of distributed, data-intensive applications rep-

resented in the C2 architecture style (Taylor et al.,

1996). The paper is organized as follows. In Section

5 a comparison is made with previous related work.

Section 2 presents a brief overview of the C2 archi-

tecture style. Section 3 describes the Model-Driven

Design process in detail. In Section 4 we present our

UML proﬁle, called Security4UML, that can be used

to add security properties to architectural models. In

Section 6 we present a case study describing how our

approach can be used to model security requirements

for a distributed multi-user meeting scheduler appli-

cation. Finally, Section 7 draws a few concluding re-

marks and presents future work.

2 BACKGROUND

The C2 architectural style is a software architectural

style that can be used to model user interface intensive

systems (Taylor et al., 1996). It can thus be used to

model the majority of data intensive applications, e.g.,

e-commerce web applications, by means of the C2

ADL (Medvidovic, 1996). In (Robbins et al., 1998),

Robbins et al. present a way to represent C2 ADL by

means of UML class diagrams. In the remainder of

the paper, we use simply C2 to refer to both the archi-

tecture style and the ADL. C2 architectures are based

on two main concepts: components and connectors.

Componentsare those parts of the architecture that

maintain state and perform operations. They contain

objects with deﬁned interfaces. Each component ex-

changes messages by means of two interfaces, called

“top” and “bottom”. In a UML class diagram, a

component can be modeled by means of a class with

the stereotype ≪ C2Component ≫. In C2, compo-

nents are not allowed to directly exchange messages;

they can exchange messages by means of connec-

tors, which have the responsibility to route, ﬁlter and

broadcast messages. In a UML class diagram, a con-

nector can be modeled by means of a class with the

stereotype ≪ C2Connector ≫. Each interface of a

component may be connected to only one connector,

whereas a connector may be connected with one or

more components.

3 MODEL-DRIVEN DESIGN

PROCESS

The management of security aspects of current IT

systems is a tough task, and misconﬁgurations may

cause security breaches. The increasing complex-

ity of this task may be effectively handled by using

model-driven approaches for the deﬁnition and man-

agement of the security conﬁgurations of the system.

Our model-driven process involves two stakeholders:

(a) the system architect and (b) the security adminis-

trator. The system architect models the architecture of

the system in the C2 architectural style. As shown in

(Robbins et al., 1998), there is a way to represent C2

models by means of UML class diagrams, and thus,

without loss of generality, we assume that the system

architect models the architecture by means of UML

diagrams.

Then, the security administrator receives the ar-

chitectural model of the system and he/she can enrich

it with a representation of the security requirements.

The security administrator can extract information on

the security requirements from two sources: (a) busi-

SECRYPT2013-InternationalConferenceonSecurityandCryptography

596

ness requirements, which express a high-level de-

scription of the expected behaviour of the global sys-

tem (security administrators usually receive business

requirements from the business and they cannot mod-

ify them), (b) the physical conﬁguration of the sys-

tem, i.e., servers, applications etc. (this aspect also

cannot be usually inﬂuenced by the security adminis-

trator, at least in the short term). The security mod-

eling process is divided into three different phases.

In each phase the security administrator adds security

relevant information to the model.

In the ﬁrst phase of the process, the Modeling

Phase, the security administrator models the secu-

rity requirements and adds them to the architectural

model. The security requirements are expressed by

using the Security4UML proﬁle deﬁned in Section 4.

Despite the fact that business requirementsare usually

expressed in natural language, the security adminis-

trator can easily deﬁne a ﬁrst high level model that is

close to the business requirements. Then, he/she re-

ﬁnes the model in several steps, by adding details at

each iteration. During this reﬁnement process the ad-

ministrator can execute automated analysis tools over

the model, in order to detect conﬂicts and anomalies

in the model itself. The results of the analysis can lead

to further modiﬁcations to the model. The resulting

model, called Sec-Model, is a platform independent

model (PIM).

In the second phase of our process, the Enrich-

ment Phase, the security administrator enriches the

Sec-Model with context dependent information, i.e.,

he/she adds information about the concrete conﬁgu-

ration of the system, e.g., information about type and

version of DBMSs or web servers. In this phase the

security administrator can extract the needed informa-

tion from the actual conﬁguration of the system. The

result of this phase is an Enriched Sec-Model (ESec-

Model) which contains the speciﬁcation of the secu-

rity requirements and information about the actual in-

frastructure. The ESec-Model is a platform speciﬁc

model (PSM).

The last phase, called Derivation Phase, con-

sists in the derivation and the deployment, in a semi-

automated way, of the concrete security conﬁguration

of the system. During this phase, the ESec-Model is

given as input to several derivation modules that gen-

erate and deploy the global concrete conﬁguration.

Each module generates and deploys part of the con-

crete conﬁguration, e.g., in the example presented in

Section 6 we have deﬁned a module for PostgreSQL,

which extracts the information needed from the ESec-

Model. The platform dependent model has to con-

tain enough information to allow the generation of the

conﬁguration.

A critical aspect of our process is the need of a

dedicated derivation module for each kind of resource

in the IT system under modeling. However, once the

effort for the development of the adequate modules is

done, the entire security architecture of the applica-

tion can be managed, updated and modiﬁed without

directly operating over the concrete conﬁguration.

4 Security4UML

In order to adequately represent the large number and

variety of entities involvedin actual enterprise scenar-

ios, we need a rich metamodel and a ﬂexible language

for expressing relationships between the entities of

the model. In this section we are going to present

a UML proﬁle, called Security4UML, which can be

used to model security properties. Due to space con-

straints we are going to present only a brief overview

of the proﬁle and in the remainder of the section we

are going to present only the Sec-Model meta-model.

The ESec-Model meta-model, not shown, is an exten-

sion of the Sec-Model meta-model that reﬁnes and en-

riches classes and associations with system dependent

information. System dependent information is stored

in tagged values associated with stereotypes.

Abstract Syntax. The meta-model of the Se-

curity4UML Sec-Model consists of six sub-meta-

models, each one focusing on a particular aspect of

the system.

Figure 1: Principal meta-model.

Principal Meta-model: it can be used to represent

all the individuals and entities that can appear as ben-

eﬁciaries of authorizations or involved in an authen-

tication rule. The meta-model is shown in Figure 1.

It contains the abstract class Principal, which repre-

sents an abstraction of the principals in the system.

We can represent single users by means of the Sin-

gleId class and groups of users using the GroupId

AModel-drivenApproachforSecuringSoftwareArchitectures

597

class. Both classes have a common abstract super-

class called Identity. SingleIds are ﬂexible, they may

represent single users of the system, legal entitites

(i.e., external companies or customers of the system

under modeling) or software components. Over the

identities we can deﬁne a hierarchy, because groups

are organized in a taxonomy via the contains relation-

ship. The class Role can be used to model roles. In

RBAC, each role represents the binding between users

and permissions associated to them. The meta-model

allows the deﬁnition of the role hierarchy by means

of the roleHierarchy relationship. Roles may be used

to represent several concepts. For instance, they may

represent organizational roles (i.e., speciﬁc enterprise

functions), collections of privileges that may be acti-

vated by users or system accounts available on certain

systems.

Privilege Meta-model: this meta-model contains the

Privilege class, which can be used to represent the

right of performing a certain action. When a privi-

lege is associated with a speciﬁc resource, it can be

modeled by means of the ObjectPrivilege class. The

Action class represents the actions that the principals

can execute.

Security Rule Meta-model: it is used to describe se-

curity rules and policies. The main class is Securi-

tyRule which is an abstract class representing security

rules. Each security rule is granted to a certain princi-

pal, as represented by the grantedTo relationship, by

a particular single id, modeled by the grantor rela-

tionship. Our meta-model aims at handling several

aspects of security (i.e., authorization and authentica-

tion) in a common way. For this reason the concrete

subclasses of SecurityRule are: (a) the RoleAuthoriza-

tion class which gives the privilege to enable a certain

role (this fact is represented by the enabledRole re-

lationship), (b) the SystemAuthorization class which

associates the subject to which the authorization is

granted with a privilege, (c) the AuthenticationRule

which models the authentication conﬁguration for a

principal with respect to a certain resource. Security

rules have a sign, and may be marked with a grant

option. This meta-model contains the classes Policy,

PolicySet and Target which can be used to model se-

curity policies in a way similar to what is done in

XACML.

Authentication Meta-model: it can be used to de-

scribe the properties that the authentication service

has to satisfy by means of the AuthcFeature class. The

class AuthcOption can be used to specify the conﬁgu-

ration options of the authentication feature.

Resource Meta-model: this meta-model can be used

to model the entities of the IT system. Given the

fact that our meta-model is quite general and aims at

Table 1: Mapping between UML elements and the ESec-

Model metamodel.

UML type Stereotype Security4UML

Class hhPrincipalii Principal

Class hhRoleii Role

Class hhGroupIdii GroupId

Class hhSingleIdii SingleId

Association hhcontainsii contains

Association hhroleHierarchyii roleHierarchy

representing several aspects of security, we have sev-

eral concrete subclasses of the SecurityObject abstract

class: 1. the Service class can be used to represent ser-

vices in a Service Oriented Architecture environment;

2. the SoftwareModule class describes nodes and soft-

ware modules; 3. the Link class models communica-

tion channels that are concrete, e.g., network links, or

abstract , e.g., software connectors; 4. the Data class

can be used to represent static resources like ﬁles and

directories in a ﬁle system or tables and views in a

database. Protected data may be modeled by means of

the ProtectedData class and its subclasses Encrypted-

Data and SignedData, which contain the details about

the encryption and signature processes. Protected

communication channels, e.g., SSL connections, may

be modeled by the ProtectedLink class (subclass of

the Link class).

Security Domain Meta-model: it contains only the

SecurityDomain class which can be used to repre-

sent security domains and the contained principals, by

means of the principalSecurityDomain relationship,

and resources, using the resourceSecurityDomain re-

lationship. Given the fact that Security4UML aims at

modeling security architectures, which may consist of

several IT systems, the concept of security domain is

important, because it may be used to represent trust

boundaries between systems.

Concrete Syntax. In order to deﬁne the concrete

syntax of our Security4UML modeling language, we

deﬁned a UML proﬁle based on the meta-model pre-

sented above. The mapping between UML types

and stereotypes and the Security4UML meta-model is

straightforward. Due to space constraints we present

only an example. Table 1 shows how the Principal

meta-model can be represented by using UML types

and stereotypes.

Tool Support. A critical aspect in model-driven en-

gineering approaches is the need of adequate tools

that can be used by developers in order to handle,

reﬁne and transform the models. The availability of

such tools is usually one of the main factors that may

inﬂuence the success of the approach itself.

In order to help security administrators in the def-

SECRYPT2013-InternationalConferenceonSecurityandCryptography

598

inition and reﬁnement of our models, we developed

the Security4UML Tool. The tool provides the devel-

oper with three functionalities:

- Reasoning: Security4UML Tool provides several

reasoning services that can be used to detect anoma-

lies and inconsistencies in the model, and to report

them to the user. In this way the user can modify

the model according to the analysis’ results, in order

to remove inconsistencies. These reasoning services

are implemented by using Semantic Web technolo-

gies, i.e., the Sec-Model is represented as an OWL

ontology and the reasoning services are expressed

by means of Semantic Web tools, e.g., OWL-DL,

SWRL and SPARQL. The Minimization service can

be used to detect redundancies in the Sec-Model, i.e.,

the model may contain authorizations which are im-

plied by other authorizations and thus may be re-

moved. The Incompatibilityservice detects authoriza-

tions that are incompatible, e.g., the Sec-Model may

contain conﬂicting authorizations. The SoD service

can be used to detect authorizations breaking Separa-

tion of Duty constraints expressed in the Sec-Model.

A detailed description of these services can be found

in (Arrigoni Neri et al., 2012; Arrigoni Neri et al.,

2013).

- Enrichment: Security4UML Tool helps the devel-

oper in the deﬁnition of the ESec-Model. The plat-

form independent Sec-Model is enriched and trans-

formed in order to obtain the platform speciﬁc model.

Security4UML Tool provides also reasoning capabil-

ities that can be used to check the consistency of an

instance of the ESec-Model.

- Code Generation: Security4UML Tool manages

the process that leads to the concrete implementation

and deployment of the security conﬁguration. The

tool supports the deﬁnition of several code generation

modules that generate the concrete conﬁguration for a

particular element of the infrastructure, e.g., a partic-

ular version of a DBMS. Each module takes as input

the ESec-Model, extracts the needed information and

generates part of the concrete conﬁguration.

We implemented Security4UML Tool on the basis

of the Eclipse framework, because Eclipse is today

one of the de-facto standard in terms of IDEs. Sev-

eral model-driven engineering tools are based upon

Eclipse, e.g., TopCased or IBM Rational Rose. Secu-

rity4UML Tool can be integrated in one of such tools,

and this fact lets us providing developers with reason-

ing, enrichment and code generation capabilities. The

extension point mechanism allows an easy integration

of new reasoning services, enrichment modules and

code generation modules. A detailed description of

part of the tool can be found in (Mutti et al., 2011;

Guarnieri et al., 2012).

5 RELATED WORK

The last decade has seen a growing interest in model-

driven techniques concerning security aspects (Basin

et al., 2011), and several solutions have been proposed

to formalize the development of secure systems.

Basin et al. have proposed SecureUML (Basin

et al., 2006), a UML proﬁle that can be used to model

Role-Based Access Control (Sandhu, 1998) (RBAC)

infrastructures. They have proposed the application

of SecureUML in several contexts: from the deﬁni-

tion of security aware GUIs (Basin et al., 2010) to

process oriented systems (Basin et al., 2003). They

have shown how SecureUML can be used for sup-

porting a model-drivensecurity approach that leads to

the concrete implementation of IT systems. The Se-

cureUML meta-model is primarily focused on access

control systems, and more in detail on RBAC. On the

contrary, our Security4UML proﬁle can model several

aspects of security. It supports the deﬁnition of access

control policies, it can be used to model authentica-

tion properties, it also considers encrypted and signed

resources and protocols such as SSL.

In (Jürjens, 2003), Jürjens proposed, as a security

extension of UML, the UMLSec proﬁle. In (Jürjens,

2005), he shows how UMLSec can be used for se-

curity analysis and formal security requirement ver-

iﬁcation. Although UMLSec supports the annotation

of UML models with security requirements, we need

a more extended meta-model, like Security4UML or

SecureUML, to facilitate a model-driven security ap-

proach.

Some works present approaches for the integra-

tion of security concepts in ADLs. In (Mouratidis

et al., 2005), Mouratidis et al. propose an ADL for

agent systems that is able to express security proper-

ties by means of protection objectives, i.e., desider-

able security properties that an agent might have.

Each agent may own several security mechanisms to

satisfy objectives. The ADL allows the deﬁnition of

security constraints that may restrict goals and capa-

bilities of agents. In (Ren and Taylor, 2005), Ren et

al. extend the existing Architecture Description Lan-

guage xADL with security concepts. They provide a

new SecureConnector which can be used to model ar-

chitectural access control. In (Oladimeji et al., 2007),

Oladimeji et al. present a UML-based ADL that can

express access control properties. On the contrary,

our work can model several aspects of security, not

only access control. Another difference is that we in-

tegrate security requirements in a well-known ADL,

i.e., C2, instead of deﬁning a new one.

Integrating security in software architectures may

be a viable way of handling the increasing complexity

AModel-drivenApproachforSecuringSoftwareArchitectures

599

of IT systems. Although a lot of work has been done

on model-drivensecurity approaches, these works are

not integrated in the current software architecture de-

sign process. On the other hand, some approaches

propose ways of integrating security requirements in

ADLs. Given the fact that these approaches tackle

security at a very abstract level, they are not able to

effectively support a model-driven security approach.

In this work, we want to propose a model-driven se-

curity approach that can be used to integrate the C2

ADL with security requirements.

6 CASE STUDY

The management of security requirements is a criti-

cal task specially in modern application. In order to

aid the Security Administrator in this task, we imple-

mented a prototype that permits to start from business

security requirements, transforms them into a more

concrete representation (i.e., policies), ties them to

a representation of the elements in the software ar-

chitecture, and produces a concrete conﬁguration for

each element involved in the policies. In order to

point out the beneﬁt of the tool we have deﬁned the

following case study. Figure 2 shows the software ar-

chitecture of a distributed multi-user meeting sched-

uler. Usually, the architecture model is provided by

the System Architect. Figure 3 shows the architecture

modeled by means of UML.

Figure 2: C2 Architecture. Figure 3: UML Architecture.

As described in Section 3 the architecture pre-

sented in Figure 2 can be easily translated into the

corresponding UML class diagram with the use of the

≪ C2Component ≫ and ≪ C2Connector ≫ stereo-

types. With this translation the Security Administrator

has all the information needed to add the security re-

quirements. According to the ISAE 3402 standard, a

business requirement that the application has to fulﬁll

is the following: Standards and policies exist to au-

thenticate all administrative users. This top level re-

quirement exempliﬁes requirements related to authen-

tication (and authorization) of administrative users.

For example, this requirement can be reﬁned into the

following set of authorizations and authentications:

• access to Admin GUI requires authentication,

• the data exchanged through Admin GUI must be

protected,

• the data exchanged between the web server and

the Database must be protected,

• only the Administrative roles can create a new

meeting,

• persistent data must be encrypted.

The requirements presented above lead also to the

deﬁnition of a set of negative authorizations and au-

thentications in order to make explicit the assump-

tions behind the requirement.

• the role User cannot create a new meeting,

• the Admin GUI is not accessible from the Internet,

• the role User must not access the Admin GUI,

• the data exchanged between the web server and

the Database must be protected.

With the use of Security4UML the Security Ad-

ministrator is able to represent the above policies in

a more concrete way. Figure 4 shows the ESec-

Model representing the following authorizations: (a)

only the Administrative roles can create a new meet-

ing (authz-1), (b) the role User cannot create a new

meeting (authz-2) and (c) the role User must not ac-

cess the Admin GUI (authz-3). These authorizations

are not tied to the speciﬁc system, hence in order to

add the security requirements to the software architec-

ture, the Security Administrator has to reﬁne the Sec-

Model into the ESec-Model as described in Section 3.

For instance, the Security Administrator may enrich

the top-level action Create with information about the

concrete action. If we assume that the new meeting

corresponds to a new row in the Meeting_Table, then

the corresponding concrete action will be an Insert

into the database. Furthermore, in this phase, the Se-

curity Administrator can introduce additional proper-

ties in order to tie the authorizations and/or authenti-

cations with the technologies related to the architec-

ture. For instance he/she can specify which crypto-

graphic technique (e.g., 3DES, AES) is used for the

encryption of the Meeting_Table.

The result of the Enrichment process above is a

SECRYPT2013-InternationalConferenceonSecurityandCryptography

600

Figure 4: Security requirements.

set of policies related to the actual infrastructure and

ready to be translated into the concrete conﬁgura-

tion in order to fulﬁll the security requirements. Af-

ter the Enrichment phase the Security Administrator

can perform the Derivation phase in order to pro-

duce a set of scripts and conﬁguration ﬁles in order

to enforce the authorizations and authentications de-

ﬁned by means of Security4UML. The requirements

only the Administrative roles can create a new meet-

ing (authz-1), and the role User cannot create a new

meeting (authz-2) are implemented by the following

SQL scripts:

CREATE ROLE Admin LOGIN

CREATE ROLE User LOGIN

GRANT INSERT ON Meeting_Table TO Admin

REVOKE INSERT ON Meeting_Table TO User

7 CONCLUSIONS AND FUTURE

WORK

The increasing complexity of current IT systems re-

quires techniques that can be used to help security ad-

ministrators and system architects in the design, im-

plementation and deployment of secure software ar-

chitectures. A viable way for handling this increas-

ing complexity is by using model-driven security ap-

proaches, which can guide the user from the formal

deﬁnition of security requirements to the concrete im-

plementation of the security conﬁguration.

In this paper we presented a model-driven secu-

rity approach that can be used to introduce security

requirements in software architectures, and to imple-

ment and deploy the security conﬁguration in a semi-

automated way. We have shown how a well-known

ADL (C2) may be integrated with a representation of

security requirements. We presented an overview of

our Security4UML meta-model, and we have shown

how this meta-model can be mapped on a UML pro-

ﬁle. We also presented a case study in which we have

modeled a distributed multi-user meeting scheduler

application.

Our approach is currently based on UML class

diagrams. This is not a restriction, because there

are ways to represent Architectural Design Languages

with UML models (Robbins et al., 1998). We plan in

the future to integrate our model-driven approach in

ADLs that are not UML-based.

REFERENCES

7safe (2010). UK security breach investigations report.

Technical report, University of Bedfordshire.

Arrigoni Neri, M., Guarnieri, M., Magri, E., and Mutti, S.

(2013). On the Notion of Redundancy in Access Con-

trol Policies. In Proc. of SACMAT.

Arrigoni Neri, M., Guarnieri, M., Magri, E., Mutti, S., and

Paraboschi, S. (2012). Conﬂict Detection in Security

Policies using Semantic Web Technology. In Proc. of

IEEE ESTEL - Security Track.

Basin, D., Clavel, M., and Egea, M. (2011). A decade of

model-driven security. In Proc. of SACMAT.

Basin, D., Clavel, M., Egea, M., and Schläpfer, M. (2010).

Automatic generation of smart, security-aware GUI

models. In Proc. of ESSOS.

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

driven security for process-oriented systems. In Proc.

of SACMAT.

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

driven security: From UML models to access con-

trol infrastructures. ACM Trans. Soft. Eng. Methodol.,

15(1).

Guarnieri, M., Magri, E., and Mutti, S. (2012). Automated

management and analysis of security policies using

eclipse. In Proc. of the Eclipse-IT 2012.

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

Springer Berlin / Heidelberg.

Jürjens, J. (2005). Sound methods and effective tools for

model-based security engineering with UML. In Proc.

of ICSE.

Langevin, J., McCaul, M., Charney, S., and Raduege, H.

(2008). Securing cyberspace for the 44th presidency.

Technical report, DTIC Document.

Medvidovic, N. (1996). Formal modeling of software ar-

chitectures at multiple levels of abstraction. In Proc.

of the California Software Symposium.

Mouratidis, H., Kolp, M., Faulkner, S., and Giorgini, P.

(2005). A secure architectural description language

for agent systems. In Proc. of AAMAS. ACM.

AModel-drivenApproachforSecuringSoftwareArchitectures

601

Mutti, S., Neri, M. A., and Paraboschi, S. (2011). Aneclipse

plug-in for specifying security policies in modern in-

formation systems. In Proc. of the Eclipse-IT 2011.

Oladimeji, E., Supakkul, S., and Chung, L. (2007). A

Model-driven Approach to Architecting Secure Soft-

ware. In Proc. of SEKE.

Patterson, D. A. (2002). A simple way to estimate the cost

of downtime. In Proceedings of LISA, Usenix.

Pertet, S. and Narasimhan, P. (2005). Causes of failures in

web applications. CMU Technical Report.

Ren, J. and Taylor, R. N. (2005). A Secure Software Ar-

chitecture Description Language. In Proc. of SSATTM

Workshop.

Robbins, J., Medvidovic, N., Redmiles, D., and Rosenblum,

D. (1998). Integrating architecture description lan-

guages with a standard design method. In Proc. of

ICSE.

Sandhu, R. (1998). Role-based access control. Advances in

computers, 46.

Taylor, R., Medvidovic, N., Anderson, K., Whitehead, E.J.,

J., Robbins, J., Nies, K., Oreizy, P., and Dubrow, D.

(1996). A component- and message-based architec-

tural style for GUI software. IEEE Trans. on Soft.

Eng., 22(6).

SECRYPT2013-InternationalConferenceonSecurityandCryptography

602