A FOUR-CONCERN-ORIENTED SECURE IS DEVELOPMENT

APPROACH

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, 2500 boulevard de l’Universit´e

Sherbrooke J1K 2R1, Qu´ebec, Canada

Universit´e Paris-Est, LACL, IUT S´enart Fontainebleau, D´epartement Informatique

Route Hurtault, 77300 Fontainebleau, France

Keywords:

Information system, Security policy, Access control, Formal method, Model checking, Process algebra, ASTD.

Abstract:

In this paper, we advocate a strong separation of four aspects of information systems: data, dynamic behavior,

security data and access control behavior. We describe how to model each of these aspects using formal

methods. An abstract speciﬁcation of each part of an information system is deﬁned. The presented approach

can be used when building a system from scratch but can also be applied to implement a security controller for

an existing system. In parallel with models, properties of the system are written. These properties are checked

against the system’s models to ensure they hold using model checking techniques.

1 INTRODUCTION

Our aim is the formal speciﬁcation of information

systems (IS). Roughly speaking, an IS helps an or-

ganization to collect and manipulate all its relevant

data. In this context, several characteristics and prop-

erties must be captured by the speciﬁcation: deﬁni-

tion and structuration of data collected and used in the

IS, data integrity constraints, list of actions that can

be invoked by end-users, views that can be displayed

by end-users, action ordering constraints, data access

control, security policies, etc. We strongly believe

that formal methods can improve the quality of IS.

Formal notations being amenable to automated anal-

ysis, they can be used for model-based software de-

velopment, code generation and efﬁcient interpreta-

tion, automated veriﬁcation and testing, thereby re-

ducing development costs, fostering reuse and in-

creasing quality. In order to capture all these aspects,

it seems that several layers of modeling should be

considered. The proposed approach is inspired from

the concept of separation of concerns (Parnas, 1972).

The latter is generally used in the context of program-

ming, like in aspect-oriented software development

(AOSD) (Win et al., 2002). It consists in separating a

program into distinct concerns like security, data log-

ging, optimizations, etc. However, this paradigm can

imply cross-cutting effects. For instance, the imple-

mentation of a concern can be dispatched over several

parts, in that case, the program is no longer modular.

The code of a concern can also be merged with code

that implements other concerns. Such negative effects

are common issues in aspect-oriented programming,

probably because of the low level of abstraction. A

survey of AOSD methods is available in (Schauerhu-

ber et al., 2007). The main contribution of this paper

is to model with formal notations the functional part

and the access control part of an IS, verify proper-

ties on each part independently and on the union of

all parts ensuring quality and reliability, and derive an

implementation of the complete IS using systematic

translations or symbolic execution of models.

1.1 The SELKIS and EB

SEC Projects

The SELKIS project (ANR-08-SEGI-018)

from the

French national research agency aims to deﬁne a de-

velopment strategy for secure health care networks

IS from requirements engineering to implementation.

The results of this project can be applied to any type

of secure IS, but the medical ﬁeld was chosen because

of the complexity and diversity of security require-

ments. EB

SEC is a project of the Canadian research

agency NSERC which aims to secure IS by enforcing

http://lacl.fr/selkis/

464

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

A FOUR-CONCERN-ORIENTED SECURE IS DEVELOPMENT APPROACH.

DOI: 10.5220/0003619604640471

In Proceedings of the International Conference on Security and Cryptography (MPEIS-2011), pages 464-471

ISBN: 978-989-8425-71-3

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

an access control policy modeled using formal nota-

tions without modifying a currently deployed system.

Use cases of the EB

SEC project are about banking IS

that can involve many access control rules. For both

projects, an approach based on formal methods was

chosen in order to build speciﬁcations which can be

rigorously validated by proofs and model checking

over properties of the speciﬁcation. In the approach

of these projects, a separation is made between access

control rules and the functional model at the require-

ment, speciﬁcation and implementation levels. An ac-

cess control ﬁlter is produced. It intercepts actions

before they are executed. If the action and other pa-

rameters match access control rules, the action can be

executed by the IS. In the other case, the execution is

rejected and an error message is returned to the user.

1.2 The Approach

The key idea of our approach is to reuse the AOSD

paradigm, but at a higher level of abstraction, more

precisely at the speciﬁcation level. We aim at dividing

the IS speciﬁcation into four concerns, which are here

called models:

1. Functional Models:

(a) The Functional Data Model: this concern deals

with the deﬁnition of entities, associations,

their attributes and the actions related to them.

It also includes the safety properties (invari-

ants) that the data attributes must satisfy.

(b) The Functional Dynamic Model: this part de-

scribes the event ordering constraints and the

dynamic properties. It provides a speciﬁcation

of the IS behavior.

2. Access Control Security Models:

(a) The Security Data Model: this third part also

deals with entities, associations and attributes

and deﬁnes a static access control policy com-

posed of rules which describes who can do what

in the system. Static rules are state invariant,

i.e. they are not based on the state of the sys-

tem.

(b) The Security Dynamic Model also called access

control model: this last concern also deals with

access control policies, but adds the description

of when (in which context) an action can be per-

formed. Such rules can refers to previously ex-

ecuted actions or previous states of the IS. This

kind of policy allows the IS to be more secure,

enabling access only to those that are entitled to

at the right moment in the business process of

the organization.

By using formal notations, veriﬁcation techniques

may be used to check properties on each model and to

verify consistency between the four parts. The chosen

separation of models is justiﬁed as follows. Since we

are dealing with IS, end-usersare naturally focusedon

data. The dynamic model provides more information

than the sole data model. It can be viewed as the con-

troller of the IS. Data and dynamic models constitute

the functional model of the system. Distinguishing

these two parts is somehow analogous to comparing

state-based and event-based models. The two secu-

rity models are justiﬁed by the dependency of most

organizations on the proper functioning of their IS, to

prevent corruption, loss of data or breaches in con-

ﬁdentiality, which may have serious consequences.

Such a separation of concerns also simplify system

evolution. Access control policies often change in-

dependently of the functional model of the system.

Maintenance teams experience a high turnover rate

during the lifetime of an IS. These four models pro-

vide a well-decomposed speciﬁcation which is easier

to grasp and maintain.

Even if other choices could have been made (for

instance, security could be split into several distinct

models, one for each ACIT - Availability, Conﬁden-

tiality, Integrity, Traceability - feature), one of the key

elements in our approach is the incremental building

of IS models. First, the data model only provides data

deﬁnition and structure. Hence, there is no restriction

on the potential behavior of the IS, only excluding

data values violating integrity constraints. Then, the

dynamic behavior restricts the potential IS event or-

derings. Finally, the security dynamic model reduces

the number of possible behaviors by taking the secu-

rity facets into account.

Fig. 1 summarizes our proposal and introduces

properties such as INV, SCE, SCEF and NCE that

will be explained in Section 4. The rest of this pa-

per is structured as follows. Section 2 describes the

software development process of the 4CO approach,

putting a special emphasis on model-driven engineer-

ing, rather than traditional software design and imple-

mentation. Section 3 describes the techniques used

for specifying data, behavior and security policies.

Section 4 describes the techniques used for specify-

ing properties on data, behavior and security policies,

and for verifying them. Finally, Section 5 reviews re-

lated approaches and research projects.

2 IS DEVELOPMENT PROCESS

A four-concern-oriented approach is proposed to for-

mally specify safe and secure IS. This section pro-

A FOUR-CONCERN-ORIENTED SECURE IS DEVELOPMENT APPROACH

465

Figure 1: Our proposal: a four-concern-oriented secure IS development approach.

vides a general overview of the target methodology,

which consists of nine steps. Most of them can al-

ready be supported by existing languages and tools

from the EB

SEC (Embe Jiague et al., 2010) project

that we have developed in our research groups.

The whole speciﬁcation is intended to be built

incrementally, but some exceptions may occur, es-

pecially when maintenance or monitoring issues are

considered. For the moment, we only consider an IS

speciﬁcation from scratch. Specifying concerns for

an existing IS is discussed at the end of this section.

Our approach is composed of the following steps:

1. Specifying the Functional Data Model. The ﬁrst

step consists in deﬁning the main entity types, as-

sociations and attributes. In our approach, this

part is described with class diagrams and attribute

deﬁnitions.

2. Specifying the Functional Dynamic Model. The

next step is the deﬁnition of the IS controller, ex-

pressing ordering constraints on actions. We have

a choice of two complementary, but equivalent

notations. The EB

process algebra allows us to

represent the dynamic behavior using purely alge-

braic expressions (Frappier and St-Denis, 2003).

Algebraic state transition diagram (ASTD) (Frap-

pier et al., 2008) is an hybrid automata-based and

algebra-based formal language with a graphical

notation which allows the speciﬁer to describe

behavior using hierarchical automata that can be

freely combined with process algebra operators.

These formal languages can be used to specify the

functional dynamic model.

3. Verifying Data Integrity Constraints. Once the

functional data model is deﬁned, we use a transla-

tion into Event-B (Abrial, 2010) for checking in-

variant properties like data integrity constraints.

We have developed systematic translation rules

from EB

process expressions to ASTD and from

ASTD to Event-B machines (Milhau et al., 2010).

4. Verifying Dynamic Properties. The aim of this

step is to verify safety properties that involve ac-

tions, such as necessary conditions to enable an

action, and liveness properties, such as sufﬁcient

conditions to enable or reach an event. Model

checking and proving dynamic properties on our

models is presented in (Frappier et al., 2010).

5. Specifying Access Control Data. The ﬁrst two

models constitute the IS functional speciﬁcation.

Next, security policies have to be deﬁned. We

use a class diagram to represent static access con-

trol policies, in a way similar to *-RBAC ap-

proaches (Ferraiolo et al., 2003).

6. Specifying Access Control Security Policies.

More complex access control rules, involving

workﬂows and action ordering, can be expressed

in this model as presented in (Konopacki et al.,

2010).

7. Verifying Security Properties. In this step, ver-

iﬁcation techniques are performed to verify spe-

ciﬁc security properties.

8. Verifying Overall Liveness. Finally, we need to

verify that the functional model coupled with the

security model does not prevent actions from be-

ing executed.

9. Maintaining Models. IS designers may have to

modify the IS models after some time. Our ap-

proach offers a way to update the system without

modifyingevery models, evenif the system is run-

ning.

SECRYPT 2011 - International Conference on Security and Cryptography

466

This process is not linear. Some iterations are

required for obtaining a complete speciﬁcation. For

instance, if the security requirements are too strong,

some users can no longer perform desired actions. In

that case, IS speciﬁers have to take some decisions to

weaken the rules of the security model.

Since our approach is incremental, one can apply

steps 2, 4 – 8 to an existing IS. A prerequisite is a data

model coming from the IS documentation. Then, a

controller can be executed formonitoringthe valid se-

quence of IS actions. This is relevant, for instance, in

a service-oriented approach, where our development

process could be used for service orchestration and

choreography.

3 SPECIFICATION

In this section we introduce a class diagram, the ASTD

notation and a case study that we use to illustrate our

approach. Speciﬁcation refers to points 2, 5 and 6 of

our approach.

3.1 Security Data Model

We need to model access control policies with various

constraints such as permissions, prohibitions, SoD

(Separation of Duty) and obligations. SoD constraints

are dynamic and deﬁned as a workﬂow in the next

section. Sometimes only permissions or prohibitions

are sufﬁcient to model a static access control policy.

A more complete description of permissions, prohi-

bitions, SoD and obligations is given in (Konopacki

et al., 2010).

The class diagram depicted in Fig. 2 is highly in-

spired by the RBAC standard (ANSI, 2004). Enti-

ties User, Role and Action respectively depict users

involved in the IS, the role they play and actions of

the IS. The association Play depicts who is allowed to

play a role in the IS. Relations Permission and Pro-

hibition depict permission and prohibition in the IS.

Actions are granted or prohibited to a role that can

be played by different persons. The semantics of the

class diagram is expressed by a predicate, called the

static predicate sp(σ), which determines if an event

σ satisﬁes the constraints expressed in the class di-

agram. For instance, an RBAC-like static predicate

would state that an event σ =< u, r, a > is valid iff

(u, r) ∈ Play∧(r, a) ∈ Permission∧(r, a) 6∈ Prohibition

3.2 The ASTD Notation

The ASTD notation is a formal and graphical notation

for specifying IS functional dynamic behaviors. The

notation was introduced in (Frappier et al., 2008) as

an extension of Harel’s Statecharts with process alge-

bra operators. Each ASTD type corresponds to either

a process algebra operator or a hierarchical automa-

ton. Automaton states can be elementary or an ASTD

of any type.

ASTD speciﬁcations combine beneﬁts of graphical

representation and process algebra: easy to read rep-

resentation of states from automata; control behav-

ior, hierarchical structure and the power of abstrac-

tion of process expressions. An ASTD has a static

topology, i.e. its structure, and a state that evolves

according to actions executed. Contrary to a pro-

cess expression, when an ASTD is executed, only its

state evolves, whereas the execution of an action on

a process expression returns a new process expres-

sion, whose structure is sometimes more complex due

to unwinding of quantiﬁcations, closures and process

calls. Hence, an animation of the speciﬁcationfor val-

idation with end-users is more difﬁcult to understand.

Fig. 3 provides a small example of an ASTD spec-

iﬁcation for a library IS managing members, books

and loans. Each component is described using an au-

tomaton and combined using process algebra opera-

tors from EB

(Frappier and St-Denis, 2003). Each

event can has several parameters. The ﬁrst two pa-

rameters denote security attributes as role and user

from the security data model. Any relevant attribute

could be added to the class diagram and then used in

ASTD events as a security parameter.

ASTD is an executable notation, with reasonable

performance to handle large numbers of entities and

instances, and thus can be used for controlling IS

with low response time constraints. Using iASTD, our

ASTD interpreter, an implementation of the model can

be produced. It can stand as a controller of the sys-

tem. It updates its state to reﬂect the changes induced

by the actions executed.

The ASTD notation can also be used to specify se-

curity dynamic models, by introducing new param-

eters to actions such as user identiﬁer, role, organi-

zation or any additional parameter needed to express

dynamic security rules. Sophisticated access control

rules can be expressed by using process expressions.

In our library IS example, an SoD constraint is added

to request and acquire actions. The separation of duty

comes from the guard uId 6= uId

′

implying that the

user performing the action request must be different

from the user performing the action acquire. For in-

stance, the user must play the role professor to be

granted to make a book request. An obligation con-

straint is also added to acquire and discard. In other

words, the request for a book must be done by a pro-

fessor, and another user must acquire it. Those con-

A FOUR-CONCERN-ORIENTED SECURE IS DEVELOPMENT APPROACH

467

Figure 2: Class diagram used to model access control policies.

straints are expressed in the ASTD speciﬁcation pre-

sented in Fig. 4.

Figure 3: A complete ASTD speciﬁcation for a library IS.

Figure 4: An ASTD speciﬁcation for a security rule of a

library IS.

4 VERIFICATION OF

PROPERTIES

This section describespoints 3, 4, 7 and8 from the ap-

proach where properties are veriﬁed against produced

models.

4.1 Classiﬁcation of Properties

One advantage of using formal methods is the abil-

ity to verify properties over system models, whether

they are functional or security models. Properties are

traditionally partitioned into three categories:

1. Liveness Properties state that something good

eventually happens. They sometimes state that

an action implies a reaction from the system; this

is however rarely used in IS, where actions are

human-driven (one cannot force a user to trig-

ger speciﬁc actions). Deadlock, in the traditional

sense of reachingstates whereno transition is pos-

sible, is rarely an issue.

2. Safety Properties state that something bad does

not happen. IS safety properties usually describe

invariant properties of data, necessary conditions

to enable an action, or what a user is not allowed

to do with the system at a given point.

3. Fairness Properties state that an enabled action

will be executed at some point. Since end-users

determine which actions they want to execute, IS

typically do not have fairness constraints.

In (Konopacki et al., 2010), we have identiﬁed four

sub-categories which frequently occur in IS require-

ments, and for which we want to develop a veriﬁca-

tion strategy.

4.1.1 Liveness

1. SCE: Sufﬁcient State Condition to Enable an

Event. Such properties state that end-users should

be able to execute an action when a condition

holds. “An action is enabled” means that there

is a transition for this action in the current state.

Examples are: i) a book can always be acquired

by the library when it is not currently acquired;

ii) a member can always return a borrowed book.

Thus, the IS must accept acquire(b) when book b

does not exist; the IS must accept return(b) when

b is borrowed.

SECRYPT 2011 - International Conference on Security and Cryptography

468

2. SCEF: Sufﬁcient State Condition to Enable an

Event in the Future. Such properties state that

there is a sequence of actions that leads to the ex-

ecution of the desired action. Examples are: i) ul-

timately, there is always a procedure that enables

a member to leave library membership(the proce-

dure depends on the loans and reservations of the

member); ii) a member can always ultimately bor-

row a book (the procedure depends on the status

of the book and its reservations). Thus, the action

can become enabled if proper steps are taken.

4.1.2 Safety

1. INV: Invariant State Property. These properties

hold for each state of the system. For example, a

member cannot borrow more books than a certain

limit.

2. NCE: Necessary State Condition to Enable an

Event. These properties state that if the IS can ac-

cept an action, then a condition must hold. Exam-

ples are: i) a book can only be acquired if the buy-

ing request was made by a professor; ii) a book

cannot be reserved by the member who is borrow-

ing it.

4.2 Specifying Properties

4.2.1 SCE and SCEF

CTL is well suited to specify SCE and SCEF proper-

ties, due to its branching naturewhich is useful for ex-

pressing enabledness of actions. Ideally, a CTL-like

(i.e., branching) language should support both states

and actions, as in PROB (Leuschel and Butler, 2003),

since SCE and SCEF properties typically refer to both

states and actions in their natural language formula-

tion. Classical LTL is not suitable, because of its

inability to express enabledness. Particular features

of some model checkers (like the enabled operator in

ProB and location labels in SPIN (Holzmann, 2004))

slightly extend LTL such that some SCE and SCEF

properties can be speciﬁed in LTL. Stable-failure re-

ﬁnement, as in FDR2, can also be used to specify SCE

and SCEF, but not as easily and naturally as in CTL.

Plain ﬁrst-order logic can also be used for SCE and

SCEF when actions are speciﬁed as before-after state

predicates. In (Frappier et al., 2010), we have shown

how ALLOY (Jackson, 2006), FDR2 and PROB can be

used to specify and check SCE and SCEF properties.

4.2.2 NCE and INV

These properties are more widely supported. For ex-

ample CTL, LTL, ﬁrst-order logic and trace reﬁne-

ment can all be used.

4.3 Generic Security Properties

Specifying different kinds of properties on a given

model and checking them on this model ensure a high

level of correctness. Properties expressed by design-

ers are called speciﬁc properties. In addition to these

propertieswe haveidentiﬁed propertiescalled generic

properties. They can be checked on models to ensure

their consistency and liveness. Ten generic properties

have been identiﬁed as for example:

Access Control Policy Typing checks that all events

used in process expressions are also instances of

the class Action, otherwise the static predicate

cannot be veriﬁed. This property can be statically

checked over the access control model.

Role Feasibility checks that all instances of the class

Role can be used by a user to execute at least one

action. This property is generalized to all classes

of the access control data model. They are used to

check that all instances are useful. Furthermore,

we have equivalent properties for associations of

the access control data model. These veriﬁcations

are also used for association permission, to check

that all permissions depicted in the data model are

reachable in the dynamic model.

Prohibition Unfeasibility checks that what is pro-

hibited in the class prohibition cannot be executed

by the access control dynamic model.

Reachability of all Security Events checks that all

instances of class Action in the access control data

model can be executed by the access control dy-

namic model.

Reachability of all IS Events checks that the access

control policy is not too restrictive, i.e.: all events,

that the IS could execute, can be executed at least

once by the access control model.

All these properties can be formalized. For example,

Reachability of all IS events can be expressed using

CTL as follows:

∀e ∈ Σ

|= EF(e)

⇒

∃σ ∈ Σ

SEC

: σ.e = e∧ sp(σ) ∧ M

SEC

|= EF(σ)

In this formula, Σ

(Σ

SEC

, resp.) is the set of events

used in the functional dynamic model M

(security

A FOUR-CONCERN-ORIENTED SECURE IS DEVELOPMENT APPROACH

469

dynamic model M

SEC

, resp.); E and F are symbols

used in CTL to respectively express exists and ﬁnally;

σ is a security event (i.e.: a n-tuple) and σ.e is the

event of σ. There are two problems to make this prop-

erty usable in a modelchecker : i) the quantiﬁcation is

over events, and most model checkers do not support

such quantiﬁcations; thus they must be unfolded, ii)

two distinct models (i.e.: functional and access con-

trol) are used, thus two checks are done in sequence

in the unfolding.

4.4 Verifying Properties

Model checking is an interesting technique to ver-

ify IS speciﬁcations for several reasons: it provides

broader coverage than simulation or testing, it re-

quires less human interaction than theorem proving,

and it has the ability to easily deal with both safety

and liveness properties.

The separation of concerns illustrated in Fig. 1 al-

lows for a modular veriﬁcation of properties. Invari-

ant properties can be checked separately in the func-

tional model and the security model, since one model

cannot modify the state of the other. NCE can also be

checked locally in each model: the functional model

and the security model are composed in parallel and

must synchronize on common actions; thus the traces

of the parallel composition of these two models are

included in the traces of each component, when re-

stricted to their respective alphabets. SCE and SCEF

can be checked locally, but the parallelcomposition of

the two modelsmay furtherrestrict the enabledness of

actions, thus violating these properties. The speciﬁer

must identify which properties should still hold in the

parallel combination and re-check them. Some of the

generic properties guaranty liveness of the combina-

tion and must be checked over the parallel composi-

tion of the functional model and the security model.

5 RELATED WORK

Few methods have been developed to formally spec-

ify and verify secure information systems. If we con-

sider only the functional aspect, we have pointed out

in (Fraikin et al., 2005) that it is interesting to com-

bine state-based and event-based modelsto express all

kinds of properties of IS. State-based methods have

been extensively used because they are suitable to de-

scribe states of IS, with invariant predicates to rep-

resent static integrity constraints, two important as-

pects of IS. Dynamic properties are more tricky to

specify. Even if complex ordering of operations can

be expressed by using additional variables and pre-

conditions, this kind of properties are more naturally

and clearly expressed by event-based methods. In our

work, we combine the B method and EB

. Other com-

binations can be considered. In (Evans et al., 2008),

we propose to combine B and CSP, mainly because of

existing tools.

With regard to the security aspect, there ex-

ist many formalisms to specify security proper-

ties (Konopacki et al., 2010). However most of them

consider basic access controls. Few research projects

deal with separation of duty. Thework in (Basin et al.,

2010) uses CSP with an RBAC model. Because CSP

does not support natively state variables, it is not well

adapted for IS. Moreover, the access control model is

RBAC and cannot be extended or tailored to speciﬁc

IS as we propose in our work.

Finally, when combining functional and secu-

rity aspects, comparable research projects are (Basin

et al., 2009) and (Kallel et al., 2009). The ﬁrst one

is based on SecureUML (Basin et al., 2006) and ex-

presses security properties with OCL. OCL being a

state-based method, dynamic properties, such as con-

straints on workﬂows, may require to encode work-

ﬂow manually and describe the evolution of the state

for each action executed. Moreover, veriﬁcation tools

associated with OCL are less powerful than PROB,

ALLOY and FDR2. The second one is based on

RBAC, Z, temporal logic (LTL) and aspect-oriented

languages for implementation purposes. Regarding

RBAC, the same limit as mentioned above can be

stated. In addition, LTL is not sufﬁcient to express

important security properties, as described in Sec-

tion 4 where we point out that at least CTL has to

be used.

6 CONCLUSIONS

We presented our approach of secure IS design, in

which a strong separation of four essential parts of

a system is performed at the speciﬁcation level. Each

of these parts is described by a model expressed with

a formal notation. When writing a model, proper-

ties that must be checked are also expressed. Our

approach alternates between model speciﬁcation and

model checking in order to ensure consistency and

cohesion between all aspects of the system. Model-

speciﬁc and overall veriﬁcations are performed. The

relative independency between models also helps IS

designers to update the system after it is deployed. As

validation of our approach, we have developed inter-

preters, systematic translation procedures and imple-

mentations based on models described in this paper.

Presently we can interpret access control policy spec-

SECRYPT 2011 - International Conference on Security and Cryptography

470

iﬁcations in order to provide a ﬁlter that will grant or

deny the executionof actions. In (Milhau et al., 2010)

we present systematic translation rules from the ASTD

notation to Event-B (Abrial, 2010). We are currently

working on a translation of such Event-B access con-

trol policy speciﬁcations into Business Process Ex-

ecution Language (BPEL) that can be enforced in a

service oriented architecture (SOA) system (Embe Ji-

ague et al., 2011). As future work we plan to provide

tools in order to model and verify ASTD speciﬁcations

and implement thealgorithms of (Milhauet al., 2010).

ACKNOWLEDGEMENTS

This research is funded by ANR (France) as part

of the SELKIS project (ANR-08-SEGI-018) and by

NSERC (Canada).

REFERENCES

Abrial, J.-R. (2010). Modeling in Event-B. Cambridge Uni-

versity Press.

ANSI (2004). American national standard for information

technology – role based access control. ANSI INCITS

359–2004.

Basin, D., Burri, S. J., and Karjoth, G. (2010). Dynamic

enforcement of abstract separation of duty constraints.

In Computer Security – ESORICS 2009, LNCS. vol.

5789, pp. 250–267, Springer, Berlin Heidelberg.

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

driven security: From UML models to access control

infrastructures. ACM TOSEM, 15(1):39–91.

Basin, D. A., Clavel, M., Doser, J., and Egea, M. (2009).

Automated analysis of security-design models. Infor-

mation & Software Technology, 51(5):815–831.

Embe Jiague, M., Frappier, M., Gervais, F., Konopacki,

P., Milhau, J., Laleau, R., and St-Denis, R. (2010).

Model-driven engineering of functional security poli-

cies. In INSTICC Press, volume Information Systems

Analysis and Speciﬁcation, pages 374–379, Funchal,

Madeira.

Embe Jiague, M., Frappier, M., Gervais, F., Laleau, R., and

St-Denis, R. (2011). From ASTD access control poli-

cies to WS-BPEL processes deployed in a SOA envi-

ronment. In Chiu, D. K. W. and al., editors, WISS 2010

Workshops, LNCS. vol. 6724, pp. 126–141, Springer,

Berlin Heidelberg.

Evans, N., Treharne, H., Laleau, R., and Frappier, M.

(2008). Applying CSP - B to information systems.

Software and System Modeling, 7(1):85–102.

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

Role-Based Access Control. Artech House, Inc., Nor-

wood, MA, USA.

Fraikin, B., Frappier, M., and Laleau, R. (2005). State-

based versus event-based speciﬁcations for informa-

tion system speciﬁcation: a comparison of B and EB

Software and Systems Modeling, 4(3):236–257.

Frappier, M., Fraikin, B., Chossart, R., Chane-Yack-Fa, R.,

and Ouenzar, M. (2010). Comparison of model check-

ing tools for information systems. In Dong, J. and

Zhu, H., editors, Formal Methods and Software En-

gineering, LNCS. vol. 6447, pp. 581–596, Springer,

Berlin Heidelberg.

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.

Holzmann, G. J. (2004). The Spin Model Checker: Primer

and Reference Manual. Addison-Wesley.

Jackson, D. (2006). Software Abstractions. MIT Press.

Kallel, S., Charﬁ, A., Mezini, M., Jmaiel, M., and Klose, K.

(2009). From formal access control policies to run-

time enforcement aspects. In Massacci, F., Zannone,

N., and Redwine, S. T., editors, Engineering Secure

Software and Systems, LNCS. vol. 5429, pp. 16–31,

Springer, Berlin.

Konopacki, P., Frappier, M., and Laleau, R. (2010).

Expressing access control policies with an event-

based approach. Technical Report TR-LACL-2010-6,

LACL, Universit´e Paris Est.

Leuschel, M. and Butler, M. (2003). ProB: A model checker

for B. In Araki, K., Gnesi, S., and Mandrioli, D., ed-

itors, FME 2003: Formal Methods, LNCS. vol. 2805,

pp. 855–874, Springer, Berlin Heidelberg.

Milhau, J., Frappier, M., Gervais, F., and Laleau, R. (2010).

Systematic translation rules from ASTD to Event-B.

In M´ery, D. and Merz, S., editors, Integrated Formal

Methods, LNCS. vol. 6396, pp. 245–259, Springer,

Berlin H.

Parnas, D. (1972). On the criteria to be used in decomposing

systems into modules. Communications of the ACM,

15(12).

Schauerhuber, A., Schwinger, W., Kapsammer, E., Rets-

chitzegger, W., Wimmer, M., and Kappel, G. (2007).

A survey on aspect-oriented modeling approaches.

Technical report, Vienna University of Technology.

Win, B. D., Vanhaute, B., and Decker, B. D. (2002). How

aspect-oriented programming can help to build secure

software. Informatica (Slovenia), 26(2).

A FOUR-CONCERN-ORIENTED SECURE IS DEVELOPMENT APPROACH

471