SECURITY PATTERNS, TOWARDS A FURTHER LEVEL

∗

Beatriz Gallego-Nicasio

ATOS Origin

Antonio Mu

noz, Antonio Ma

na, Daniel Serrano

Grupo GISUM, Universidad de Malaga, Malaga, Spain

Keywords:

Security patterns, Ambient intelligence, Security and dependability services, Security measurements.

Abstract:

Traditionally, security patterns have successfully been used to describe security and dependability (S&D)

solutions, making them available to system engineers not being security experts. Recently, in the SERENITY

research project, the notion of S&D pattern was extended to exact speciﬁcations of re-usable S&D mechanisms

for Ambient Intelligence (AmI) systems. SERENITY is focused in AmI systems, but its results can be applied

to other computer paradigms: grids, distributed computing, etc. SERENITY S&D patterns include information

about both the S&D properties that the solution satisﬁes and the requirements on the context conditions. Along

this paper, we describe how abstract S&D solutions can be implemented by means of functional S&D services.

In order to do that, our approach is based on the use of SERENITY S&D patterns, and their implementations,

called ExecutableComponents. Finally, we propose several examples and we prove their potential application

to AmI scenarios.

1 INTRODUCTION

Traditionally, security engineers’ tasks, in standard

software and service development, have been the def-

inition of security principles and policies, and the

development and validation of solutions for achiev-

ing speciﬁc security properties. Due to the nature of

the systems under development (usually, centralized

or loosely connected systems) there was no need of

a high integration of these tasks in the development

process. Nowadays the provision of security and de-

pendability (S&D) for information systems requires

specialized expertise in the S&D engineering tech-

niques. Indeed, the current S&D engineering tech-

niques are able to warrant high levels of security and

dependability, when they are rigorously and appro-

priately applied. Unfortunately, these techniques are

based on a detailed analysis of every part of the sys-

tem, but not as a standalone. Therefore, they do not

work well when they are applied to highly dynamic

systems, where it is impossible for S&D engineers to

foresee all possible conﬁgurations of the system that

will happen at run-time. In this paper, we present

an overview of how security expertise is captured by

∗

Work partially supported by E.U. through project

Serenity (IST-027587)

means of the Serenity Project S&DPatterns. We also

introduce the structure of these S&DPatterns at the

implementation level: applications use S&DPatterns

at run-time, consequently S&DPatterns are imple-

mented by means of software and hardware compo-

nents, called ExecutableComponents. Secondly, we

introduce the Serenity Run-time Framework, which

is a service providing support to secure applications

at run-time by means of S&DPatterns. And to ﬁnish,

we present how developers proﬁt from all the advan-

tages introduced by Serenity, by introducing the two

Java packages developed to support the development

of both ExecutableComponents and secure applica-

tions. The paper is structured as follows: section 2

compiles relevant related works, section 3 introduces

Serenity artifacts used to capture security knowledge,

section 4 presents the Serenity Run-time Framework

and goes into detail describing the exploitation and

deployment of S&D solutions at run-time. Section 5,

presents the monitoring and reaction mechanisms to

control the execution the S&D solutions. Section 6

shows how these concepts are implemented by means

of ExecutableComponents and presents the support-

ing infrastructure created. An example scenario to

demonstrate all these concepts is described in section

7. Finally, section 8 presents the current state and next

349

Gallego-Nicasio B., Muñoz A., Maña A. and Serrano D. (2009).

SECURITY PATTERNS, TOWARDS A FURTHER LEVEL.

In Proceedings of the International Conference on Security and Cryptography, pages 349-356

DOI: 10.5220/0002230303490356

 SciTePress

steps of the research, together with our conclusions.

2 RELATED WORK

Concerning the problem of providing adaptable secu-

rity services at run-time, we found proposals based

on Component-based Software development (CBSD

for short) (Georgiadis et al., 2002), and others

based on middleware and Frameworks (Schmidt and

Buschmann, 2003). Some approaches based on the

concept of Framework have been proved to be useful

in the development of secure services, as defended

in (Schmidt and Buschmann, 2003). Unfortunately,

current frameworks provide static security properties.

In other words, the security solutions offered can not

be adapted to work when then number of context

changes is high. Thus, they are selected and conﬁg-

ured at application development time. This limitation

makes the approach not applicable in heterogeneous

and dynamic AmI environments.

Current work on CBSD is mainly focused on the

dynamic analysis of component compatibility. Usu-

ally from a functional point of view, with the target of

adapting components and synthesizing suitable soft-

ware architectures (Becker et al., 2007). A remark-

able research is presented in (Mei and Xu, 2003).

This work is based on the use of Bayesian Belief Net-

works for an adaptive dependability model. Unfortu-

nately, current approaches are not focused on the au-

tomated selection and setup of security solutions an-

swering to different security requirements, which is

one of the strongest points of our approach in Seren-

ity. In (Kung, 2007), A. Kung highlights how the

usage of patterns is widely used today in the speci-

ﬁcation of architectures and the design based on as-

pects. Concretely, these patterns refer to templates

describing a solution to solve a commonly occurring

problem. Work on security architectures for compo-

nent systems has been focused in the security prob-

lems caused by the interaction of general components

while we focus on the interaction of components pro-

viding security and dependability services. A secu-

rity architecture for composing secure systems from

components is presented in (Jaeger et al., 1998). This

architecture is designed to support the dynamic com-

position of systems and applications from individual

components. This approach differs from Serenity due

to it only deals with access control. As this one, most

of the current proposals are based on oversimpliﬁed

views of security, like those based on security levels.

A further discussion is found in (Nobukazu et al.,

2004), where security patterns are applied to construct

secure and efﬁcient intercompany coordination sys-

tems. Authors show an application of their method to

the Environmentally Conscious Product design sup-

port system. As a result, they provide guidelines

to developers for modeling the performance of data

associated with each pattern. Unfortunately, these

guidelines are not expressive enough for the security

patterns developed in the Serenity project and this ap-

proach have no mean for automating neither the dis-

covery, nor selection and nor deployment of the can-

didate patterns.

3 CAPTURING KNOWLEDGE

This section gives an overview of the Serenity Project.

The main objective of Serenity is to provide a frame-

work for the automated treatment of security and de-

pendability issues in AmI scenarios. For this purpose,

the project is two-folded: (i) capturing the speciﬁc ex-

pertise of the security engineers in order to make it

available for automated processing, and (ii) providing

run-time support for the use and the monitorization of

these security and dependability mechanisms. These

two cornerstones have been deployed by means of:

A set of S&D modeling artefacts (S&D artifacts, for

short), used to model security and dependability so-

lutions (S&D solutions) at different levels of abstrac-

tion. S&D solutions are isolated components that pro-

vide security and/or dependability services to appli-

cations. The use of different levels of abstraction re-

sponds to the need of different phases of the software

development process. These artefacts are supported

by an infrastructure created for the development and

the validation of S&D solutions. This infrastructure

includes concepts, processes and tools used by se-

curity experts for the creation of new S&D solutions

ready for automatic processing.

Figure 1: Simpliﬁed model.

A development framework. Under the name of

Serenity Development-time Framework (SDF) there

is an infrastructure that supports the development of

secure applications. These secure applications, called

Serenity-aware applications, are supported by S&D

solutions, consequently, they include references to the

aforementioned S&D artefacts. A run-time frame-

SECRYPT 2009 - International Conference on Security and Cryptography

350

work, called Serenity Run-time Framework (SRF).

The SRF provides support to applications at run-time,

by managing S&D solutions and by monitoring the

systems’ context. The SRF is brieﬂy described in

Section 4. Once infrastructural pieces have been de-

scribed, the rest of this section explains how to use

S&D modelling artefacts to bridge the gap between

abstract S&D solutions and actual implementations

of these S&D solutions. Interested readers could re-

fer to Section 3 in order to ﬁnd information on how

the SRF supports applications at run-time. Back to

the abstractions, ﬁve main artefacts are provided to

achieve a logical way to represent S&D solutions

in the Serenity project: S&DClasses, S&DPatterns,

IntegrationSchemes, S&DImplementations and Exe-

cutableComponents. These artefacts, depicted in ﬁg-

ure 1, represent S&DSolutions using semantic de-

scriptions at different levels of abstraction. The main

reason for using different artefacts, each one address-

ing an abstraction level, is that, by doing this, it is

possible to cover the complete life cycle of secure

applications, especially at development and run-time

phases. S&DClasses represent abstractions of a set

of S&DPatterns, characterized for providing the same

S&D Properties and complying with a common inter-

face. This is one of the most interesting artefacts to

be used at development time by system developers.

The main purpose of this artefact is to facilitate the

dynamic substitution of S&D solutions at run-time,

while facilitating the development process. Applica-

tions request S&D Solutions to the SRF to fulﬁll a set

of S&D requirements. Usually, these requirements

are hard coded by means of calls to S&DClasses or

S&DPatterns interfaces. At run-time all S&DPatterns

(and their respective S&DImplementations, described

below) belonging to the same S&DClass, will be

selectable by the SRF automatically. S&DPatterns

are precise descriptions of abstract S&D solutions.

These descriptions contain all the information neces-

sary for the selection, instantiation, adaptation, and

dynamic application of the solution represented by

the S&DPattern. S&DPatterns describe the security

pattern’s functionalities and how to use them in a

structured way. The most interesting elements of

the S&DPattern structure are: (i) The pattern in-

terface, describing the functionalities provided and

how to use them; (ii) references to the S&DClasses

the S&DPattern belongs to; and (iii) the ClassAdap-

tor, describing how to adapt the S&DPattern inter-

face to the S&DClass interface. S&DPatterns repre-

sents monolithic isolated S&D solutions, but a spe-

cial type of S&D artefact called Integration Scheme

(IS) also exists, which consists on an S&D solution

at the same level than S&DPatterns. They represent

S&D solutions that are built by means of combin-

ing other S&DPatterns. At Serenity-aware applica-

tion development time, Integration Schemes are used

similarly as S&DPatterns are. However, they dif-

fer in their development process, presented in (Mana

et al., 2006). All along this paper we use the no-

tion of S&DPatterns to refer to S&DPatterns and In-

tegration Schemes indistinctly. S&DImplementations

are speciﬁcation of the components that realize the

S&D solutions. S&DImplementations are not real

implementations but their representation/description.

An S&DImplementation describes an implementa-

tion of an S&DPattern and, thus, a S&DPattern may

have more than one S&DImplementation. Finally,

ExecutableComponents are real implementations of

the S&DImplementations. These elements are not

used at development time, but they are the real-

ization of the selected S&D solution at run-time.

An ExecutableComponent works as a stand alone

executable S&D solution ready to provide its ser-

vices to applications. They are software, and some-

times hardware, components. As shown in ﬁgure

1, every S&D solution provides at least one security

property. Every S&DPattern (and every Integration

Scheme) refer to an S&D solution. On the contrary,

every S&D solution can be represented by one or

more S&DPattern and/or Integration Scheme. Each

S&DPattern is implemented by means of at least one

S&DImplementation. Finally, there is an Executable-

Component entity for each S&DImplementation. The

entities in the top of the ﬁgure 1 conform a hierar-

chy. While, S&DClasses are the most abstract level

entities to represent S&D solutions, ExecutableCom-

ponents, being software components, are the low-

est abstraction level way to represent an S&D solu-

tion. For the representation of S&D solutions, follow-

ing the Serenity approach, developers need to count

on, at least, one artefact for every level of the hier-

archy. To sum up, S&DClasses, S&DPatterns and

S&DImplementations are development-time oriented

artefacts, while ExecutableComponents are specially

suitable for run-time. Serenity-aware applications in-

clude references to development-time artefacts. De-

pending on the artefact level of abstraction, at run-

time, the SRF has more/less ﬂexibility to select S&D

solutions. In other words, this approach enables the

creation of open architectures where, at run-time, the

SRF completes by applying the ExecutableCompo-

nents that implements the S&D solutions ﬁxed at

development-time. The main purpose of introducing

this approach is to facilitate the dynamic substitution

of S&D solutions at run-time while facilitating the de-

velopment process.

SECURITY PATTERNS, TOWARDS A FURTHER LEVEL

351

4 EXPLOITING S&D SOLUTIONS

Security experts capture their expertise into S&D

Artefacts, but in order to go a step forward, these

artefacts should be exploited by applications at run-

time. In other words, applications with security and

dependability requirements should be able to fulﬁll

them at runtime, by means of deployed S&D So-

lutions, automatically provided and controlled by a

trustworthy third-party. This approach also consid-

ers that application developers do not necessary know

anything about particular security solutions but about

certain generic S&D requirements (such as conﬁden-

tiality or reliability), probably identiﬁed by a func-

tional analyst with a basic security expertise knowl-

edge. Moreover, these applications should rely on the

provided S&D solutions to be able to automatically

be reconﬁgured and adapted in the event of a typical

AmI environment condition change. Serenity Run-

time framework (SRF) provides this support.

4.1 Serenity Run-time Framework

Bellow, Figure 2 presents a simpliﬁed view of the

SRF and the most relevant components that inter-

act with it at runtime, in the process of exploitation

of S&D Solutions. The ﬁgure shows two compo-

nents inside the SRF: the S&DLibrary and the Con-

textManager. The S&DLibrary component is a local

Figure 2: Simpliﬁed architecture.

S&D solution repository that stores the S&DClasses,

S&DPatterns and S&DImplementations, speciﬁc to

the platform and that might, potentially, be used in

the device. The ContextManager component keeps

device’s context related data (SRF conﬁguration, ac-

tive patterns and monitoring information). Context

information is used by the SRF to select the most

appropriate S&D solution for a given scenario under

a set of particular conditions. Outside the SRF, ﬁg-

ure 2 depicts all the components and interfaces that

are involved in the run-time deployment, following

further detailed. A Serenity-aware application is the

application that uses the security services provided

by S&DPatterns, by means of the ExecutableCom-

ponents. The SRF provides a SRFRequest interface,

to be used by applications in order to request S&D

artefacts. Usually, applications request S&DClasses,

S&DPatterns and S&DImplementations, but these re-

quests result in the activation of an ExecutableCom-

ponent implementing the S&D solution requested.

The ExecutableComponents are activated by the

SRF and they implement S&DPatterns functional-

ities. ExecutableComponents provide two inter-

faces: the ECcontrol interface, to be used by the

SRF; and the ECaccessPoint, to be used by appli-

cations. The SRF controls the proper execution of

ExecutableComponents by using the ECcontrol inter-

face. Serenity-aware applications access to the se-

curity services provided by ExecutableComponents

through the ECaccessPoint interface. The ECmoni-

toring interface (provided by the SRF) is used by ECs

to keep the SRF informed about some particular as-

pects of its execution. The SRF uses this information

to control the status of the execution of the EC and its

impact into the environment, with the support of the

Monitoring Services.

This process of control is described ahead in this

document. Finally, Monitoring Services provide an

interface, called monitoring, that allows the SRF

make use of a set of services provided to support the

process of control of the execution of ECs, and to per-

form recovery and reconﬁguration actions. Now we

have a more clear idea of the architecture and compo-

nents involved at run-time, we are going to describe

the functionalities provided by the SRF in more detail.

4.2 Selection of the S&D Solution

In the context of the Serenity project, the SRF is im-

plemented as a service of the operating system that

listens to application S&D requests. By means of

these requests, the applications specify their S&D re-

quirements, and the SRF uses those speciﬁcations to

search the repository of S&D Artefacts, here referred

as S&D Library, and selects the most appropriate

S&DPattern that fulﬁlls the application request. This

selection consists of a pattern-driven algorithm based

on some particular aspects of the S&DPattern spec-

iﬁcation, as well as on the S&D requirements spec-

iﬁed by the application developer. This means that

the SRF looks into the descriptor of each S&DPattern

stored in the repository, and checks if its characteris-

tics, such as security properties or features, match the

application’s particular S&D requirements. In addi-

tion to this, the SRF needs to check if the S&DPattern

is appropriate for the particular context environmental

SECRYPT 2009 - International Conference on Security and Cryptography

352

situation, looking at the context preconditions speci-

ﬁed by the security expert within the S&DPattern de-

scriptor. Once the SRF has selected an S&DPattern,

it is time to start exploiting the S&D Solutions that

represents.

4.3 Activation of S&D Solutions

ExecutableComponents (ECs) are realizations of

S&D Solutions. Each S&D pattern may have several

implementations, described as S&DImplementations,

and, each S&DImplementation has its corresponding

EC. ECs are software components that the SRF is

able to activate and execute, and have some partic-

ular characteristics: (i) provide applications with the

interface deﬁned in the S&DPattern, (ii) implement

the functionality of an S&D Solution, described by

the S&DPattern, and (iii) provide a monitoring inter-

face to enable the SRF to control its execution. There-

fore, to activate the selected S&D Solution that will

provide the application with the S&D properties re-

quested, the SRF creates a new instance of the EC that

runs in the operating system, as an independent soft-

ware piece, within the same S&D realm as the appli-

cation and the SRF are running. To make it accessible

to the application, the SRF uses handler, ECHandler

in the context of Serenity, which is conﬁgured with all

the information the application need to communicate

with the EC. This ECHandler is brought back to the

application as a result of its request. By doing this, the

EC can be accessed by the application directly, and

provide the speciﬁc S&D Solution functionality with-

out any more intervention of the SRF. Up to here, the

initially mentioned approach could be seen, basically,

as repository of S&DPatterns, plus a software compo-

nent that searches and instantiates the corresponding

S&D Solutions. For AmI environments, we must go

further. We must react to continuous changes of the

context conditions and be able to reconﬁgure the run-

ning ECs in order to keep fulﬁlling the security and

dependability requirements of the applications despite

the changes.

5 MONITORIZATION

The Monitoring Services, brieﬂy introduced above,

are actually a framework of components that support

the SRF to monitor, diagnose and detect threats re-

lated with the execution of the ECs.

In ﬁgure 2, there is a component labeled Monitor-

ing Services. Security experts deﬁne a set of moni-

toring rules in the S&DPattern description that need

to be satisﬁed during the whole lifetime of a deployed

S&D Solution. These rules are basically assumptions

about the behaviour of a system, and how runtime

events may affect its state, making sure the security

and dependability properties the S&D Solution is pro-

viding remains no matter the conditions of the context

are,. The SRF, by means of the Monitoring Services,

checks every certain period of time that those rules

keep holding. In the event of a monitoring rule vio-

lation, the SRF makes use of the diagnosis and threat

detection mechanisms of the Monitoring Services to

evaluate if any reaction should be perform. How to re-

act to a monitoring rule violation is deﬁned by the se-

curity experts within the S&DPattern descriptor. For

each monitoring rule there is a reaction behaviour as-

sociated, that basically are intended to take corrective

actions to avoid any potential system failure derived

from the malfunction of the EC, and to adapt the sys-

tem security and dependability mechanisms at run-

time. Some examples of reactions could be to stop

the execution of a particular EC, to restart the EC

with other initial parameters or to stop/start monitor-

ing certain set of rules, amongst others. The Moni-

toring Rules of an S&DPattern rely on the ability of

the ECs to generate traces during its execution. Those

traces are encapsulated in the form of events that are

captured by some components, named Event Cap-

turers in the context of Serenity project, attached to

the ECs. Those events captured feed the Monitoring

Services allowing it to deduce information about the

state of the system being monitored. The SRF polls

the Monitoring Services frequently about the status of

each active Monitoring Rule and if there is a violation

detected, the SRF triggers the corresponding reaction.

6 DEVELOPMENT SUPPORT

Serenity project aims to provide end-users not only

with a set of methodologies and abstractions, but also

with some means to beneﬁt of them and to apply to

within their particular scenarios. To support this, here

we introduce two infrastructures provided by Seren-

ity. One supports the development of the Executable-

Components, and the other supports the development

of Serenity-aware applications. As aforementioned,

ExecutableComponents have a one-to-one correspon-

dence with S&DImplementation abstractions, fully

implementing the security solutions described in

the referenced S&DPatterns. ExecutableComponents

are software/hardware components runnable indepen-

dently in a system. They provide interfaces to be used

by either the Serenity-aware applications or the SRF

itself.

These two infrastructures actually consist on

SECURITY PATTERNS, TOWARDS A FURTHER LEVEL

353

two programming libraries, one for each purpose,

and either EC programmers or Serenity-aware ap-

plication programmers may integrate them by sim-

ply import them within their speciﬁc software dis-

tribution. The upper package represents the li-

brary that developers may use to create Serenity-

aware applications. It includes classes for access-

ing the SRF (SRF AccessPoint) and for managing the

ExecutableComponents (SerenityExecutableCompo-

nent AP.). The other package is the library devel-

oped to assist developers creating ExecutableCom-

ponents. In order to create an ExecutableCompo-

nent, programmers must extend the class SerenityEx-

ecutableComponent AP. Following the structure of

the presented infrastructure, a Serenity-aware appli-

cation uses instances of the SerenityExecutableCom-

ponent AP class, to establish communication with the

ExecutableComponents. This class is an interface be-

tween the application and one ExecutableComponent,

providing standard mechanisms no matter how the

implementation of the ExecutableComponent is.

Thus, applications only need to create an instance

of the SerenityExecutableComponent AP class and

then, the application uses the ECHandler information

provided by the SRF to access ExecutableComponent

interface. Figure 3 depicts the S&D artefacts devel-

oped for this scenario.

Figure 3: Hierarchy of S&D Artefacts.

By doing this, applications access the services

that S&DPatterns described. We clarify this pro-

cess a bit more next. At development-time, appli-

cation developers learn the behaviour expected from

the security solution, such as the set of available

calls and the appropriate call sequence to use the

security services, by looking at the description of

the development-time S&D artefacts (S&DClasses,

S&DPatterns, and S&DImplementations). These

artefact descriptors contain this information in the

form of, what we call in Serenity, interface calls,

sequences and constraints. S&DPatterns’ speciﬁca-

tions also contain information about how to adapt the

interface offered by S&DClasses to the one offered

by S&DPatterns, we call this adaptation part Class

Adaptors. ExecutableComponent developers strictly

follow the guidelines described in the correspond-

ing S&DClass and S&DPattern descriptors, so Ex-

ecutableComponents are Serenity compliant and are

expected to respond to those queries as described (part

of the Serenity Project is devoted to guarantee that Ex-

ecutableComponents fulﬁll the speciﬁcations of the

S&DPattern they implement). It is important to take

into account that all Serenity S&D Artefacts are cer-

tiﬁed by its creators, opening a new business model

based on the provision of security solutions by means

of S&DPatterns. Continuing with the process descrip-

tion, the SRF manages all ExecutableComponents in-

stantiated as result of Serenity-aware applications re-

quests. It keeps a record of important information

such as status, location or assigned monitoring ser-

vices. It is important to highlight that the instantiation

of ExecutableComponents generates new context in-

formation for the SRF, and this inﬂuences the results

of the S&D solution selection algorithm. Moreover,

the events generated by ExecutableComponents feed

the Monitoring Service infrastructure and they could

result in the violation of Monitoring Rules. Moni-

toring rules are associated to reactions, and for in-

stance, one common reaction is to de-activate the

S&DPattern whose Monitoring Rule was violated.

7 SECURITY MEASUREMENT

This section introduces an example which highlights

all the concepts presented along this paper. This ex-

ample consists in a prototype implementing a Control

Access System for networks. Brieﬂy, the goal of this

system is allowing or denying access to network re-

sources attending to several parameters what can be

considered security measurements related to sensible

security data like user proﬁle, device identiﬁcation

and location (this last element provides a small com-

ponent of AmI). The prototype has been developed

following the methodology proposed by the Serenity

project, as explained in previous sections. First step

was to extract S&D requirements from the goals, just

like in any other development process. Full list of re-

quirements is out of the scope of this paper, but once

obtained, we design a set of Serenity S&D Artefacts,

modelling S&D Solutions to cover all those require-

ments. For the sake of simplicity, in this paper we

focus on solutions for managing the aforementioned

security measurements.

SECRYPT 2009 - International Conference on Security and Cryptography

354

7.1 S&D Artefacts

The ﬁrst artefact on top is an S&DClass Security Mea-

surement, representing an abstract S&D Solution for

a generic security assessment providing a quantita-

tive value, let’s say a number. Below the S&DClass,

there are four entities: three S&DPatterns and an Inte-

gration Scheme. The S&DPatterns represent particu-

lar implementations of the S&D solution represented

by the Security Measurement S&DClass. The differ-

ence among them is the parameter they are based on,

to perform the security assessment. The UserPro-

ﬁleSM S&DPattern performs a measurement based

on the proﬁle attached to a connected user (please,

assume every user is authenticated when connect-

ing to the network). The ZoneSM and DeviceIdSM

S&DPatterns do the same, taking into account the lo-

cation and the digital identiﬁcation (by cryptographic

means) of the connecting devices, respectively. The

CombinedSM Integration Scheme combines the three

S&DPatterns and provides a ﬁnal security measure-

ment working as a unique component. The rest of the

ﬁgure 3 presents an S&DImplementation for every

S&DPattern, and an ExecutableComponent for every

S&DImplementation.

7.2 Development Phase

After building the abstract elements in the form of

S&D Artefacts we proceed to develop both the Exe-

cutableComponents and the main access Control Ap-

plication, this time with the help of the SRF’s spe-

cialized APIs (one for Excutable Components and an-

other one for applications), presented in previous sec-

tion. The Control Application was developed as a

Serenity-aware application. It opens a communica-

tion channel with the SRF and requests an S&D so-

lution, represented by the CombinedSM Integration

Scheme. As a result of this request, the SRF instan-

tiates the corresponding ExecutableComponent and

provides the application with the conﬁgured ECHan-

dler. This particular EC works internally as a new

Serenity-aware application which requests the three

S&DPatterns mentioned before, and combine their

results. This way, the core Control Application is

quite simpliﬁed with just one request to perform all

the measurement. In the context of the proposed sce-

nario, the application would expect a solution for a

very simple problem: authorize a resource request. It

is as simple as getting a ok or a ko at certain point

of the execution ﬂow of the application, no matter

how, the great advantage of using Serenity is, in fact,

to make it that easy. The application developer, at

design-time, may assume that a properly conﬁgured

SRF, when requested for a certain S&D solution, will

provide a mechanism to use a running instance of that

S&D solution for its own purposes. Developers do

not need to take into account how the S&D solution

is implemented.

7.3 Monitoring and Reactions

Last but not least, the prototype exploits the Monitor-

ing Services features described in section 5. During

development time, we created for each S&DPattern a

set of monitoring rules, and we also added to each Ex-

ecutableComponent the necessary Event Captors to

feed that rules. For instance, the implementation of

the location solution is based on a client-server model,

and we considered important to monitor the server

availability during the lifetime of the solution. There-

fore, we added a speciﬁc rule within the S&DPattern

descriptor. The rule, roughly, describes the following:

the server must respond always before n seconds. If

the response takes longer than n seconds, or it never

responds then, the rule will be considered violated.

Some Events Captors were developed and attached to

the ExecutableComponents, in order to provide cus-

tom events for our rule. In this case, we have two

types of events: one signaling the ping to the server

and another marking the ping response. With all these

elements on the table, a Monitoring Service will be

able to check the time interval between both events

happens, and to determine whether the rule is violated

or not. Other rules (and its corresponding events)

could be added to control the other ExecutableCom-

ponents as well. Regarding the ability of the SRF to

perform corrective actions on the event of a monitor-

ing rule violation, we use as an example a reaction

mechanism called notify application. This one is used

by the SRF to notify the application a message when-

ever a rule is violated. We need to mark the rule in the

S&DPattern specifying the reaction we would like to

have performed if it is violated, and write down the

custom message we want to notify. In our scenario,

it would be very useful if, in the case the rule is vi-

olated, the SRF sends a particular warning message,

so the application could display it. It is a very simple

reaction but demonstrates the functionality. It would

be possible to design more complex reactions to im-

prove the adaptability of the system. For instance, in

our scenario, imagine the S&D solution has been in-

stantiated with an initial parameter (speciﬁed by the

application) which is actually the server url. Pretend,

the rule that monitors whether the server is alive is

violated. Here, the reaction could be restarting the

solution with a different server url value, such as a

backup server one speciﬁed in the S&DPattern de-

SECURITY PATTERNS, TOWARDS A FURTHER LEVEL

355

scriptor. Then, the application will be able to continue

accessing the services provided by the S&D Solution

with no damage.

8 CONCLUSIONS

This work presents an approach for producing secure

applications by means of a provision of S&D solu-

tions. This approach, called Serenity, is composed

by two frameworks. On the one hand, the Serenity

Development-time Framework (SDF) includes con-

cepts, processes and tools supporting the development

of S&D solutions, and secure applications. These

S&D solutions are implemented by means of four

S&D artefacts: (i) S&DClasses, (ii) S&DPatterns,

(iii) S&DImplementations, and (iv) S&D Executable-

Components. This hierarchy enables the use of

security and dependability (S&D) patterns imple-

mentations to develop secure applications. These

S&DPatterns are not a simple set of best practices

or recommendations, like those proposed in the lit-

erature as security patterns, but precise, well-deﬁned

and automated-processing-enabled implementations

of security mechanisms. The extensive use of seman-

tic descriptions, enable the use of automated reason-

ing mechanisms capable of solving problems such as

pattern composition and adaptation. Thus, we have

presented an infrastructure for supporting both the de-

velopment of ExecutableComponents and Serenity-

aware applications. On the other hand, the Serenity

Run-time Framework (SRF) completes the open soft-

ware architectures designed using the SDF, by sup-

porting applications when they requires the use of se-

curity solutions at run-time. It is important to high-

light that the SRF includes monitoring mechanisms

that guarantee that selected S&D solutions are run-

ning properly. In this paper we have presented both

the SDF main concepts and the SRF architecture. Fur-

thermore, we have provided the description of full

developed demo scenario. To deploy this scenario

a set of S&D artefacts has been developed. These

artefacts are used to provide several secure measure-

ment and authentication security patterns, all of them

represented at different abstractions levels, ranging

from the most abstract representation of the solution

(S&DClass), to the real implementation of the pattern

(ExecutableComponent). Among the more relevant

features of this approach is the selection of patterns at

runtime, as well as the conﬁguration of them. Indeed,

this allows context awareness while running obtain-

ing exceptional results. Currently, we count on a fully

operational prototype of the SRF and on XML based

languages for the creation of all S&D artefacts. Be-

sides, we have developed two APIs, one for the imple-

mentation of ExecutableComponents, and the other

one oriented to the implementation of serenity sup-

ported applications (Serenity-aware applications). Fi-

nally, we count on an on-line repository and a useful

tool to search for S&D artefacts. These elements have

been the basis to develop a ﬁrst set of S&D solutions.

Next steps are (i) to improve the capacities of the SRF

prototype with more reaction capabilities, (ii) to cre-

ate a plugging for include design concepts in a Java

IDE, and (iii) to provide a new version of the APIs for

taking the new advantages that will be introduced in

the next SRF prototype.

REFERENCES

Becker, S., Canal, C., Diakov, N., Murillo, J., Poizat, P.,

and Tivoli, M. (2007). Coordination and adaptation

techniques: Bridging the gap between design and im-

plementation. In Springer, L., editor, Report on the

ECOOP Workshop on Coordination and Adaptation

Techniques for Software Entities (WCAT’06).

Georgiadis, I., Magee, J., and Kramer, J. (2002). Self-

organising software architectures for distributed sys-

tems. In WOSS ’02: Proc. workshop on Self-healing

systems, pages 33–38, New York, NY, USA. ACM.

Jaeger, T., Liedtke, J., Pantellenko, V., Park, Y., and Islam,

N. (1998). Security architecture for component-based

operating system. In ACM, editor, In ACM Special

Interest Group in Operating Systems (SIGOPS) Euro-

pean Workshop., page 118.

Kung, A. (2007). Architecture and design patterns for am-

bient intelligence: an industry perspective. In Proc.

of AmID 2007, volume ISBN: 978-2-287-78543-6,

pages 55–67, Sophia-antipolis (France). Springer-

Verlag.

Mana, A., S

anchez, F., Serrano, D., and Munoz, A. (2006).

Building secure ambient intelligence scenarios. In

18th conf. on Software Engineering and Knowledge

Engineering (SEKE’06).

Mei, L. and Xu, Y. (2003). An adaptive dependability model

of component-based software. In ACM, editor, ACM

SIGSOFT Software Engineering Notes, volume 28.

Nobukazu, Y., Shinichi, H., and Anthony, F. (2004). Se-

curity patterns: A method for constructing secure and

efﬁcient inter-company coordination systems. In In-

ternational, E. I., editor, Enterprise Distributed Object

Computing Conference, pages 84–97. IEEE Computer

Society Press.

Schmidt, D. C. and Buschmann, F. (2003). Patterns, frame-

works, and middleware: their synergistic relation-

ships. In ICSE ’03., pages 694–704, Washington, DC,

USA. IEEE Computer Society.

SECRYPT 2009 - International Conference on Security and Cryptography

356