MODEL-DRIVEN ENGINEERING OF FUNCTIONAL SECURITY

POLICIES

Michel Embe Jiague

1,2

, Marc Frappier

, Fr´ed´eric Gervais

, Pierre Konopacki

1,2

R´egine Laleau

, J´er´emy Milhau

1,2

and Richard St-Denis

GRIL, D´epartement d’informatique, Universit´e de Sherbrooke, Sherbrooke, Qu´ebec, J1K 2R1, Canada

LACL, Universit´e Paris-Est, IUT Fontainebleau, 77300 Fontainebleau, France

Keywords:

Security model, Security policy, Speciﬁcation, Veriﬁcation, Process algebra, Hierarchical state transition dia-

gram, EB

SEC, EB

, MDA, SOA, BPEL.

Abstract:

This paper describes an ongoing project on the speciﬁcation and automatic implementation of functional secu-

rity policies. We advocate a clear separation between functional behavior and functional security requirements.

We propose a formal language to specify functional security policies. We are developing techniques by which

a formal functional security policy can be automatically implemented. Hence, our approach is highly inspired

from model-driven engineering. Furthermore, our formal language will enabled us to use model checking

techniques to verify that a security policy satisﬁes desired properties.

1 INTRODUCTION

Information systems (ISs) are prevalent in today’s

economy. Public companies as well as private cor-

porations have most of their ISs on-line and rely on

data exchange with customers and partners to carry

out their day-to-day business. Due to their nature,

they must be highly accessible over Internet.

Strict security and privacy regulationsare imposed

on ﬁnancial and health sectors. For instance, health

software applications in the USA must comply with

HIPAAA (Health Insurance Portability and Account-

ability Act); those in Canada with PIPEDA (Per-

sonal Information Protection and Electronic Docu-

ments Act). A ﬁnancial software application must sat-

isfy a security policy according to the Sarbane-Oxley

law in the USA.

We distinguish between functionalsecurity, which

deals with security requirements at the business level,

and architectural security, which deals with software

design level issues, like authentication, encryption,

and secure communication protocols. Functional se-

curity essentially determines who can do what, when

and where.

The aforementioned laws and regulations mostly

deal with functional security. Unfortunately, func-

tional security is poorly managed in most organisa-

tions. Requirements are often vaguely described and

handled in various disconnected parts of a software

systems. For instance, basic role-based access con-

trol, RBAC (Ferraiolo et al., 2003) is used to grant

access to a service. But RBAC does not depend on

the state of the service; authorization is granted solely

on the basis of the role of the user and the service

requested. Additional functional security require-

ments are thus handled in the service itself. For in-

stance, business requirements that determine who can

do what and when are mixed with functional require-

ments and implemented together in the service code.

As most organisation and popular agile software pro-

cesses advocate little documentation, the code is the

ultimate description of functional security policies. It

is then highly diﬃ cult to demonstrate that a software

satisﬁes security regulations. It is even more diﬃ-

cult to evolve a security policy to satisfy new require-

ments.

To deal with this issue, we propose a new ap-

proach that is based on the following principles. 1)

Business requirements should be clearly separated in

two parts: i) functional behavior, which states what

the system services should do; ii) functional security,

which states who, when, and where can these services

be used. 2) Functional behavior and functional se-

curity should be separately implemented in distinct

components of the system. 3) The implementation of

functional security policies should be completely au-

374

Embe Jiague M., Frappier M., Gervais F., Konopacki P., Laleau R., Milhau J. and St-Denis R. (2010).

MODEL-DRIVEN ENGINEERING OF FUNCTIONAL SECURITY POLICIES.

In Proceedings of the 12th International Conference on Enterprise Information Systems - Information Systems Analysis and Speciﬁcation, pages

374-379

DOI: 10.5220/0003019403740379

 SciTePress

Application

model

code

CIM

policy

PIM

Security

model

PSM

Security

kernel

Natural

languages

Formal Programming

Transformation

rules

Functional

behavior

languageslanguage

Security

Validation

Properties

and

verification

Figure 1: The proposed MDE approach.

tomatic, to ensure reliability, maintainability and cor-

rectness with respect to regulations.

To implement this approach, we use the princi-

ples of model-driven engineering (MDE), which rec-

ommends to elaborate abstract models independently

of any implementation techniques. It includes three

steps as shown in Figure 1. The ﬁrst step focuses

on the creation of a computation independent model

(CIM) of the IS by considering various kinds of re-

quirements (including security) formulated in a nat-

ural language. The second step consists in the de-

velopment of a platform independent model (PIM)

that allows the IS to be deﬁned at an abstract level

using appropriate domain-speciﬁc languages, prefer-

ably formal languages. The third step reﬁnes the lat-

ter in a concrete model according to a service ori-

ented architecture (SOA) environment, which results

in a platform speciﬁc model (PSM) that takes into ac-

count implementation issues. Generally, the security

requirements of an IS are collected at the CIM level

by means of a security policy, that consists of high-

level security rules, speciﬁed more precisely at the

PIM level and enforced at the PSM level by a security

kernel. Figure 1 emphasizes the separation of security

aspects and functional aspects in all the three steps

of the MDA approach. First, the functional security

policy is stated separately from functional behavior

requirements. Second, the PIM consists of two ab-

stract models derived from business rules and the se-

curity policy, respectively. Third, the security kernel,

responsible for the enactment of the security policy,

is independent of the application code, enabling mod-

iﬁcations of security rules without having to change

the application code. The proposed approach also in-

cludes activities for the validation or veriﬁcation of

the three main models (CIM, PIM and PSM). For in-

stance, the security model can be checked with re-

spect to some properties in order to guarantee that it

does not restrict unduly the behavior of the IS.

There are several ongoing projects and initia-

tives related to security of Web-based systems.

ORKA (ORKA, 2009) explores ways to bridge the

gap between organizational control and access rights

management. It includes the development and im-

plementation of integrated security concepts founded

on role-based security policies while considering or-

ganizational control principles. The NGN-44 (ICTI,

2010) project is an initiative inside the Carnegie

Mellon|Portugal Program. It consists in the devel-

opment of new notions of semantically rich interface

languages, and an associated programming language

as well as logic-based veriﬁcation techniques with the

aim of enforcing security, integrity, and correctness

requirements on distributed extensible Web-based ap-

plications. Finally, Meinel proposes a security model

that enables the description of security policies as a

set of abstract security intentions, which can be trans-

lated automatically into concrete security policies. An

identity model, which makes possible the propagation

of identity information to all services, and methods to

describe trust between two unrelated parties in order

to carry out sensitive transactions are also under in-

vestigation (Meinel, 2009). Since all these projects

are in their infancy, it is diﬃcult to appraise their real

impact and compare the eﬃciency of the proposed

tools.

The solutions introduced in this paper are in the

spirit of recommendations of a re-engineering project

initiated by one of our partners in Canada in the

banking industry This ﬁrm is currently examining

the functional security aspects of its ISs, particularly

those interacting with brokers, customers and exter-

nal ﬁnancial systems to manage investment portfolio

and trade ﬁnancial products like stocks and options.

These solutions will also be validated in a companion

French project, called SELKIS, which targets medical

ISs (SELKIS, 2009).

This paper focuses on the formalization of func-

tional security rules by using the EB

SEC method and

automatic translation of EB

SEC speciﬁcations into

algebraic state transition diagram (ASTDs) in order

to implement security policies eﬃciently and verify

their consistency. Two techniques are investigated for

the implementation of security policies. ASTDs are

either reﬁned into BPEL models executed by a BPEL

engine or simulated by an interpreter with persistent

objects, the BPEL engine and the interpreter being in-

tegrated into Web services of an SOA environment.

MODEL-DRIVEN ENGINEERING OF FUNCTIONAL SECURITY POLICIES

375

2 SPECIFICATION OF THE

SECURITY MODEL WITH THE

SEC METHOD

An EB

SEC speciﬁcation includes a data model and a

process expression for the deﬁnition of functional se-

curity rules at two granularity levels: atomic services

(actions or transactions) and business processes (col-

lections of related, structured atomic services). Per-

missions related to the execution of actions are de-

scribed in the former. Security rules of the latter are

deﬁned by a process expression in the EB

SEC lan-

guage, which is inspired from process algebras. The

process expression can refer to the data model to spec-

ify state-oriented constraints. The EB

SEC method is

an extension of EB

(Frappier and St-Denis, 2003),

a method speciﬁcally devised to derive the input-

output behavior of an IS (i.e., the IS model in Fig-

ure 1). There is another granularity level suitable

for the static permissions for users to access data at-

tributes. The EB

SEC method is not really concerned

with this lowest granularity level. Nevertheless, it is

taken into account during the reﬁnement of the PIM

into the PSM.

Person

User

name

pId

name

1..n

Unit

uId

1..n

Role

rId

1..n

Action

aId

name

1..n

Play

Permission

Figure 2: Class diagram of the security model.

The example data model represented by the class

diagram of Figure 2 includes four main entity types

and two associations. The entity types Unit, Person,

Role and Action correspond respectively to the

units of an organization (e.g., hospital wards or bank

branches), the users or customers of the IS, the roles

assigned to persons (e.g., patient, nurse, doctor) and

the visible operations of the IS, more precisely the

atomic operations that come from the IS’s class di-

agram of an EB

model (e.g., Register, Open File).

The association Play allows to deﬁne the role of a

person in a unit. Finally, the association Permission

provides a means to deﬁne functional security rules at

the granularity levels of atomic services.

The data model allows one to borrow concepts

from role-based access control models, such as

RBAC (Ferraiolo et al., 2003) and OrBAC (Kalam

et al., 2003). In return, one is not limited to the

framework of these models, and can include any

entity deemed relevant for the security problem at

hand. The concept of role is important to grant ac-

cess rights to users according to their roles. Each

user in a given role can then access the only part of

the system (atomic services and data attributes) cir-

cumscribed by his access rights or privileges. These

technologies have been extended to take into account

temporal constraints on user-role assignments (X-

GTRBAC (Joshi et al., 2005)) and Web services as

protected resources (WS-RBAC (Bhatti et al., 2007)).

They are, however, not adapted to long running pro-

cesses, as those encountered in an SOA environment,

and lack the expressive power to refer to past actions

(which are elements of traces in process algebra no-

tations). Nonetheless, the EB

SEC language solves

this problem. Indeed, ordering constraints on actions

can be easily formulated while considering the asso-

ciations Permission and Play. For example, the

following security requirement include ordering con-

straints of actions:

A professor must approve a book prior to its

acquisition and prior to its discard.

||| bId : BOOKID | pId : PERSONID

ApproveAcquire(bId; pId, professor, _ )

Discard(bId; _, librarian, _ )

ApproveDiscard(bId; pId, professor, _ )

Acquire(bId; _, librarian, _ )

Figure 3: Speciﬁcation of the security rule using the ASTD

notation.

These constraints on the acquisition and discard of

books is formalized as follows in EB

SEC:

Approval Rule() =

9bId : BOOKID : | pId : PERSONID :

hpId, professor, , ApproveAcquire(bId)i

h , librarian, , Acquire(bId)i 

hpId, professor, , ApproveDiscard(bId)i

h , librarian, , Discard(bId)i

ICEIS 2010 - 12th International Conference on Enterprise Information Systems

376

ESB

Service A

Service B

Consumer Service registry

1 2

PDP

Secondary

poll service

ASTD

Security kernel

Transformation

BPEL+

WS−BPEL

engine

Authentification

Figure 4: SOA environment for the enforcement of security policies using BPEL.

In this process expression, each action is embedded

in a quadruple, which also includes the identiﬁca-

tion number of a person (pId), a role (professor,

librarian), and a unit. The symbol “ ”, used as

a wildcard, means that the corresponding ﬁeld is not

constrained by any value. The actions Acquire and

Discard can only be executed by librarians (not nec-

essarily the same), and actions ApproveAcquire and

ApproveDiscard by a professor for a given book.

The sequential composition operator “” is used to

specify the execution order of actions for a given

book. The quantiﬁed interleaving (“9”) takes into ac-

count all entities of type Book while the quantiﬁed

choice (“|”) indicates the entity of type Person in-

volved for every book.

The valid system input trace, which records the

actions in their execution order, must match the traces

deﬁned by the security rules. The following process

expression puts the security rules together:

main() = rule

() k rule

() k · · · k rule

(),

where the operator “k” is the parallel composition

(i.e., CSP’s synchronization on shared actions).

3 TRANSLATION OF EB

SEC

SPECIFICATIONS INTO ASTDS

SEC and EB

are trace-based formal languages.

To make easier the veriﬁcation of properties with

model-checking techniques and interpretation of

functional security policies at the PSM level, the

state-based formalism of ASTDs (Frappier et al.,

2008) has been adopted. This choice has no impact

on the formalization of security policies. In fact an

SEC speciﬁcation can be easily translated into an

ASTD because there is a one-to-one correspondence

between syntactical elements of EB

SEC and those

of the ASTDs notation. Figure 3 shows the ASTD

for the Approval Rule introduced in the previous sec-

tion. This representation, closely related to process

algebras and statecharts, acts as a pivot language.

A translator and a prototypingversion of an ASTD

interpreter have been written in the OCaml program-

ming language. The current state of the interpreted

ASTD is stored in a relational database in order to

ensure that the IS can recover after a crash. This in-

terpreter beneﬁts from EB3PAI (Fraikin and Frappier,

2002; Fraikin and Frappier, 2009), an interpreter of

processes. Another version of the ASTD inter-

preter written in Java is under development with the

sole intention to integrate it more easily into an SOA

service. OCaml and Java versions should be com-

pared with respect to eﬃciency and access time cri-

teria. Such a comparison may lead to better optimiza-

tions of the underlying algorithms and data structures.

4 IMPLEMENTATION OF THE

SECURITY MODEL WITH

BPEL

In the context of an IS along with security mecha-

nisms, the security kernel is responsible for the en-

forcement of the security policy. Its primary com-

ponents is a WS-BPEL engine and a policy decision

point (PDP). The former is a back end server for the

latter as illustrated in Figure 4. The WS-BPEL engine

runs security processes or security workﬂows when

using BPEL as a speciﬁcation language for security

policies. The numbers in Figure 4 indicate the order

of messages when a consumer requests the service A,

which in turn requests the service B.

A security process cannot be arbitrarily deﬁned.

It must comply with a BPEL model based on the se-

mantics of ASTDs as well as with the BPEL stan-

dard and the interaction schema between security pro-

cesses and the PDP (as illustrated in Figure 5). It

MODEL-DRIVEN ENGINEERING OF FUNCTIONAL SECURITY POLICIES

377

if parameters OK

Yes/No

Yes

Process flow

operationSecurity message

operationSecurity response

Figure 5: Communication protocol between a PDP and a

security process.

should also be possible to deploy each security rule

as a service in order to promote its reuse.

Since a security process must be executed by

a WS-BPEL engine, an ASTD speciﬁcation must

be transformed into one or more security processes.

Such a transformation is founded on a behavioral and

semantic equivalence rather than a simple syntactical

mapping, even though a ﬁrst evaluation has revealed

similarities between some ASTD operators (e.g., se-

quential composition, (quantiﬁed) choice, (quanti-

ﬁed) interleaving, synchronization) and BPEL con-

structs (e.g., sequence, pick, flow) or combinations

of tags (e.g., sequence with correlationSet on

var for a quantiﬁed choice). The resulting BPEL pro-

cess needs to be eﬃcient, particularly when dealing

with quantiﬁed operators, like quantiﬁed interleaving

over large sets of data. In addition, the data model is

translated into an XSD and permissions related to the

execution of actions are accessed via services.

There have been many attempts to transform spec-

iﬁcation written in process algebra like languages.

Amstel and al. (Amstel et al., 2008) developeda trans-

formation from the process algebra ACP (Algebra of

Communicating Processes) into UML state machines

while preserving the semantics as much as possible.

The execution context of ACP speciﬁcations is, how-

ever, the usual one, in the sense that events are re-

ceived from the environment and then accepted or dis-

carded by the interpreter based on the current state

of the process. If the event is accepted, the pro-

cess evolves into another state where it waits for spe-

ciﬁc events to happen. Chirichiello and Sala¨un de-

signed Web services using a process algebra and en-

coded them into WS-BPEL processes (Chirichiello

and Sala¨un, 2007). In the case of the combination

ASTD/BPEL, the execution schema is quite diﬀerent

and must be considered when dealing with transfor-

mation. An ASTD speciﬁcation does not model the

IS itself but rather a policy, which is enforced during

the execution of the IS.

Using the communication protocol depicted in

Figure 5, the following XML code shows a part of

the BPEL security process obtained from the ASTD

of Figure 3:

<receive name="recAppAcqSec"

createInstance="yes"

operation="appAcqSec"

variable="inAppAcq">

</receive>

’professor’ = $inAppAcq.credential/ns0:role/ns0:roleName

</from>

<to variable="outAppAcq"

part="canExecute"/>

</copy>

</assign>

<reply name="repappAcqSec"

operation="appAcqSec"

variable="outAppAcq">

</reply>

</sequence>

<condition>$outAppAcq.canExecute</condition>

</repeatUntil>

[...]

</sequence>

5 VERIFICATION OF THE PIM

A number of typical properties that a security policy

should satisfy have been identiﬁed. For instance, if

a user u can play a given role r in an organisation

o according to association Play in the security class

diagram, then process expression main (or the ASTD)

should allow him to execute at least an action under

this role. This is a reachability property which can be

expressed in temporal logic (CTL) as follows:

∀t ∈ Play : ∃σ, a :

σ = ht.u, t.r, t.o, ai ∧ sp(σ)∧ main |= EF(σ))

Another typical class of properties is permission fea-

sibility: at least one person can execute a given action

allowed for a role in an organisation.

∀t ∈ Permission : ∃σ, u :

σ = hu, t.r, t.o, t.ai ∧ sp(σ)∧ main |= EF(σ)

We are currently experimenting the veriﬁcation of

these properties using model checking techniques.

ICEIS 2010 - 12th International Conference on Enterprise Information Systems

378

6 CONCLUSIONS

We have presented an MDE solution to functional se-

curity management in service-oriented IS. Security

policies can be comprehensively described in a sin-

gle speciﬁcation language called EB

SEC, which in-

tegrates traditional RBAC-like access control poli-

cies, using its security data model, and stateful con-

trol rules using a process algebra or ASTDs. EB

SEC

can be automatically implemented using symbolic

computation, thereby streamlining policy evolution.

SEC is amenable to automated analysis using

model-checking techniques. We are currently experi-

menting several model checkers to determine the most

appropriate one. We are also investigating the trans-

lation of EB

SEC policies into BPEL policies, to pro-

vide a more standard implementation.

SEC subsumes RBAC organizational control

principles like separation of duties, delegation of

rights and hierarchical structuring of concepts. These

can all be express as elements of a security class

diagram and their semantics deﬁned using a ﬁrst-

order predicate. EB

SEC goes beyond access con-

trol rules typically expressed in RBAC-like policies

and XACML, by taking into account stateful rules,

i.e. rules that can deal with the history of service re-

quests to determine the authorization of the next re-

quests. These stateful rules are abstractly described

using a process algebra or ASTDs. In an RBAC or

XACML approach, stateful business rules are sepa-

rately described in a conventional programming lan-

guage, hence are hard to modify and analyse. Ap-

proaches based on workﬂows can also be expressed in

SEC. Our process algebra and ASTDs oﬀer more

powerful modeling mechanisms than BPEL, which

streamlines the speciﬁcation of workﬂow constraints.

For instance, synchronisation, quantiﬁcation, and ac-

cess to state variables in guards can be used to model

complex ordering constraints. Timing constraints can

also be represented through the use of action time-

stamps, guards and time attributes in the security class

diagram.

REFERENCES

Amstel, M. F. V., van den Brand, M. G. J., Proti, Z., and

Verhoeﬀ, T. (2008). Transforming process algebra

models into UML state machines: Bridging a seman-

tic gap? In Theory and Practice of Model Transfor-

mations, volume 5063 of Lecture Notes in Computer

Science, pages 61–75. Springer Berlin / Heidelberg.

Bhatti, R., Sanz, D., Bertino, E., and Ghafoor, A. (2007).

A policy-based authorization framework for web ser-

vices: Integrating xgtrbac and ws-policy. In Web Ser-

vices, 2007. ICWS 2007. IEEE International Confer-

ence on, pages 447 –454.

Chirichiello, A. and Sala¨un, G. (2007). Encoding process

algebraic descriptions of web services into bpel. Web

Intelli. and Agent Sys., 5(4):419–434.

Ferraiolo, D., Kuhn, D., and Chandramouli, R. (2003).

Role-based access control. Artech House Publishers.

Fraikin, B. and Frappier, M. (2002). EB3PAI: an Interpreter

for the EB

Speciﬁcation Language. In Haneberg, D.,

Schellhorn, G., and Reif, W., editors, 5th Workshop on

Tools for System Design and Veriﬁcation (FM-TOOLS

2002), proceedings, Reisensburg Castle, G¨unzburg,

Germany.

Fraikin, B. and Frappier, M. (2009). Eﬃcient symbolic

computation of process expressions. Science of Com-

puter Programming, 74(9):723 – 753. Special Issue

on the Fifth International Workshop on Foundations of

Coordination Languages and Software Architectures

(FOCLASA’06).

Frappier, M., Gervais, F., Laleau, R., Fraikin, B., and St-

Denis, R. (2008). Extending statecharts with process

algebra operators. Innovations in Systems and Soft-

ware Engineering, 4(3):285–292.

Frappier, M. and St-Denis, R. (2003). EB

: an entity-based

black-box speciﬁcation method for information sys-

tems. Software and Systems Modeling, 2(2):134–149.

ICTI (2010). Carnegie mellon | portugal program.

interfaces - certiﬁed interfaces for integrity and

security in extensible web-based applications.

http://www.cmuportugal.org/tiercontent.aspx?id=

1564&ekmensel=568fab5c 68 0 1564 6.

Joshi, J., Bertino, E., Latif, U., and Ghafoor, A. (2005). A

generalized temporal role-based access control model.

Knowledge and Data Engineering, IEEE Transactions

on, 17(1):4 – 23.

Kalam, A. A. E., Benferhat, S., Mi`ege, A., Baida, R. E.,

Cuppens, F., Saurel, C., Balbiani, P., Deswarte, Y., and

Trouessin, G. (2003). Organization based access con-

trol. Policies for Distributed Systems and Networks,

IEEE International Workshop on, 0:120.

Meinel, C. (2009). Soa — security. hasso-plattner-institut

f¨ur softwaresystemtechnik. http://www.hpi.uni-

potsdam.de/meinel/research/security engineering/

soasecurity1.html.

ORKA (2009). The orka consortium. germany. http://

www.organisatorische-kontrolle.de/index-en.htm.

SELKIS (2009). Project anr-08-segi-018. france. http://

lacl.fr/selkis/.

MODEL-DRIVEN ENGINEERING OF FUNCTIONAL SECURITY POLICIES

379