Towards Language Support for Model-based Security Policy Engineering

Peter Amthor

and Marius Schlegel

Technische Universit

at Ilmenau, Germany

Keywords:

Software Engineering, Security Engineering, Security Policies, Security Models, Speciﬁcation Languages,

Domain-speciﬁc Languages, Automatic Translation.

Abstract:

Software engineering for security-critical systems is based on manual translations between languages from

different domains: an informal security policy is translated to a formally veriﬁable model, and further to actual

source code. This is an error-prone task, put at the risk of losing hard-acquired correctness guarantees. To

mitigate this problem, we argue for a methodical support by domain-speciﬁc languages and tools. We present

ongoing work on two languages that substantiate this thesis, including their usage in a practical setting, and

discuss the beneﬁts from combining them with appropriate tool support.

1 INTRODUCTION

Building secure application and systems software im-

poses increasing effort on security engineers, software

developers, and experts for the respective application

domain. As a common prerequisite among all these

stakeholders, security requirements have to be for-

mally guaranteed from early on in order to uphold

security properties regarding protection of informa-

tion conﬁdentiality, system integrity and service avail-

ability over all levels of abstraction throughout the

whole software engineering process. For this purpose,

a specialized model-based security policy engineering

(MSPE) process makes use of formal models (Basin

et al., 2011; Vimercati et al., 2005) to unambiguously

specify, verify, and implement all security-critical func-

tionality, which we call a system’s security policy.

We can distinguish three principal steps in MSPE:

(1.) In Model Engineering, a formal representation of

a security policy is designed in a way that allows to

reason about security properties; (2.) During Model

Analysis, formal methods are applied to verify these

properties and correct any errors found; (3.) Finally, in

Model Implementation, the formal security model cre-

ated and veriﬁed so far is translated in actual code for

implementation. All of these steps require different,

isolated languages to satisfy their individual require-

ments: While initially a security policy is deﬁned by

requirements engineers and application experts, usu-

ally based on semi-formal or natural language (Xiao

https://orcid.org/0000-0001-7711-4450

https://orcid.org/0000-0001-6596-2823

et al., 2012; Mitra et al., 2016), model engineering

requires its translation to mathematical artifacts under-

standable by analysts. Then again, the formal methods

used in model analysis (Crampton and Morisset, 2012;

Stoller et al., 2007) require a machine-readable rep-

resentation of the mathematical model (such as for

semi-automated model checkers), which ﬁnally needs

to be translated into a functional software speciﬁca-

tion (OASIS, 2013; Ben Fadhel et al., 2016), and,

ﬁnally, a programming language. These translations

are required to preserve relevant knowledge from the

previous process step; yet up to date, they are largely

manually work – and thus error-prone.

In this paper, we propose a holistic approach:

the use of interoperating domain-speciﬁc languages

(DSLs), with syntax and semantics tailored to stream-

lining the above translations. Ideally, such DSLs en-

able an automation of these tasks. We substantiate

this position by presenting two DSLs to seamlessly

integrate in MSPE (see Fig. 1): REAP (relationship-

based language for assisted policy design), a visual

language for model engineering (

2), and DYNAMO

(dynamic security model speciﬁcation language), a

machine-readable language for model analysis and

automated source code generation (§3).

2 REAP

The fundamental motivation behind a speciﬁcation lan-

guage for model engineering is to unite the knowledge

and skills of both security engineers and application

Amthor, P. and Schlegel, M.

Towards Language Support for Model-based Security Policy Engineering.

DOI: 10.5220/0009893205130521

In Proceedings of the 17th International Joint Conference on e-Business and Telecommunications (ICETE 2020) - SECRYPT, pages 513-521

ISBN: 978-989-758-446-6

513

Informal

Security Policy

REAP

Speciﬁcation

Formal Model

DYNAMO

Speciﬁcation

C++

Code

Model Engineering Model Analysis Model Implementation

Figure 1: Languages for security policy representation in model-based security policy engineering. Dashed arrows indicate a

manual translation, solid arrows an automatic or semi-automatic conversion.

experts. It should allow both groups to easily interact

in this part of a software engineering process, while

retaining the focus on mathematical formalisms later

required by speciﬁc MSPE methods. As a ﬁrst step

towards these goals, REAP is a visual speciﬁcation

language that deﬁnes the mathematical structure for

a security policy rather than its concrete rules. REAP

is supposed to specify the formal framework for any

security policy rather than its later functionality. This

is because we believe that, once an appropriate model

structure has been found, textual representations offer

a more suitable language to express policy rules.

In the remainder of this section we discuss the re-

quirements of REAP, which determine both its syntax

and semantics (

2.1); the language design decisions

following from these requirements (including a run-

ning example) (

2.2); and the merits of using the lan-

guage in the overall MSPE process (§2.3).

2.1 Language Requirements

To devise language requirements, we identiﬁed recur-

ring patterns in the established formalizations of com-

mon security policy classes. In model terms, most

of them fall in the domain of access control (AC)

(Basin et al., 2011; Vimercati et al., 2005), including

identity-based (Harrison et al., 1976; Sandhu, 1992),

role-based (Sandhu et al., 1996; Ferraiolo et al., 2007),

or attribute-based (Jin et al., 2012; Servos and Os-

born, 2017) models. A speciﬁc range of mathematical

artifacts is used as building blocks of these models, in-

cluding (1.) Basic set theory: sets of unique identiﬁers,

their relationships such as subset, power set, difference,

union, intersection, cartesian product; (2.) Discrete

functions (mappings) based on these sets; (3.) Seman-

tic meta-information about the above artifacts, which

is not captured by their structural deﬁnition.

The semantics of these artifacts dictate the follow-

ing functional language requirements with respect to

expressiveness: (1.) It is possible to deﬁne sets of

unique identiﬁers, which we call atomic sets. Their

elements (e. g. identiﬁers of human users) do not have

any observable inner structure. (2.) Any language ex-

pression is used to deﬁne a relationship between sets.

This may be e. g. a mapping of user- to role-identiﬁers,

or a relation over roles that indicates a role hierarchy.

(3.) An expression may be used to deﬁne a new set,

called a derived set since its elements reference ele-

ments of other sets (e. g. a cartesian product).

In addition to these requirements, the intended us-

age in MSPE demands the following non-functional

properties: REAP speciﬁcations should (1.) allow for

as much precision as needed through alternative syn-

tax for complex expressions, (2.) be as intuitive and

readable as possible, (3.) allow to ignore unneeded

information about the underlying formalisms to min-

imize visual complexity, (4.) enable tool-support for

modeling decision support and model translation to

formal artifacts usable in subsequent MSPE steps.

To satisfy these functional and non-functional re-

quirements, REAP supports an iterative approach to

model engineering: it offers three levels of expressive-

ness, which may be combined as needed. Here is an

overview of language features in these levels:

REAP

Deﬁne sets of atomic identiﬁers and their

power sets, connect them through mappings or

binary relations.

REAP

Express complex deﬁnitions of sets derived

from atomic sets, deﬁne aliases for sets.

REAP

Annotate all visual elements with meta-

information, such as logical constraints.

2.2, we will discuss syntax and semantics of these

language levels by example.

2.2 Language Design

The basic idea of REAP is to visualize formal model

components as a graph, consisting of connected sub-

graphs for individual expressions. As already intro-

duced, we distinguish between three levels of expres-

siveness that support an increasing amount of model

complexity. Since this also means that more expres-

sive policies lead to more complex graphs, our require-

ment to minimize visual complexity results in policy

graphs that are still valid in any of the more expres-

sive language levels. Thus, language design supports a

top-down model engineering approach, where expres-

sions for increasingly complex policy semantics may

be added to an existing graph on demand.

SECRYPT 2020 - 17th International Conference on Security and Cryptography

514

REAP

A security policy in REAP

is a connected,

directed graph whose nodes represent sets. These may

be either atomic sets, drawn as a circle ( ), or re-

lationships. Relationships may be used to represent

either mappings, drawn as a block arrow ( ), or

relations, drawn as a hexagon ( ). Generally, all

nodes in REAP contain up to two labels: a name of

the respective model component and a specialization

label that adds more information for policy design and

reﬁnement. In REAP

, only name labels are used.

Edges connect relationship nodes with atomic set

nodes to indicate the operands of a relationship, such

as the domain and co-domain of a mapping (expressed

by ) or the deﬁning sets of a relation

(expressed by ). A REAP

policy is

thus a bipartite graph.

While the presence of an edge is part of the seman-

tics of its adjacent relationship node, its orientation

indicates its operand ordering. Based on the observa-

tion that most relations used in security models are

binary, it sufﬁces to distinguish between a ﬁrst (“in-

put”) operand, given by an incoming edge, and a sec-

ond (“output”) operand, given by an outgoing edge.

This also applies for the domain (input) and co-domain

(output) of a mapping in a similar way. If required, the

power set edge ( ) identiﬁes a power set used in the

deﬁnition of mappings and relations.

Example 1.

Assume a security policy for a hospital

information system (HIS). We ﬁrst identify necessary

unique identiﬁers and their respective base sets: roles

(

) identify organizational functions, users (

) iden-

tify humans, and permissions (

) identify technical

capabilities. The mindset, according the general idea

of role-based access control (Sandhu et al., 1996), is

that both users and permissions are associated with

roles, which may be granted or revoked to control ac-

cess. Both associations my be represented by relations:

and

This enables a policy engineer to leave unspeciﬁed, at

least for the moment, how many roles are assigned to

a user (and likewise, how many permissions to a role).

Another relation is used to relate general (e. g. doctor)

to derived roles (e. g. surgeon) in a role hierarchy

To enable separation-of-duty semantics, we add

the concept of dynamically assigned roles: A mapping

roles

describes subsets of roles available to a user active at

a given time. At this point, it becomes obvious that at

the same time a user, such as a doctor, may fulﬁll func-

tions of more than a singular role – such as e. g. as a

physician and a medical director at the same time. Con-

sequently, we need the power set edge ( ) that ex-

plicitly indicates multiplicity of co-domain-elements,

which should be sets of elements from R.

Since a REAP speciﬁcation needs to be connected,

we can assemble the graph in Fig. 2a from these sub-

graphs. With tool support, this graph can be eas-

ily translated to mathematical deﬁnitions of (1.) sets:

U, R, P

; (2.) relations:

UA ⊆ U ×R

PA ⊆ P×R

RH ⊆

R × R

; (3.) mappings:

roles : U → P (R)

. This exam-

ple illustrates how the basic language level REAP

can already express a practically signiﬁcant range of

policies, in particular, RBAC

(Sandhu et al., 1996).

REAP

In REAP

, we allow for more complex for-

mal structures: derived sets created by set composition

operators, identity relationships to create aliases for

sets, and cascading of set composition operators. A

REAP

security policy is a graph composed from valid

REAP

subgraphs and the following expressions.

Derived sets are denoted by a set composition node,

which contains a set algebra operator symbol as its spe-

cialization label, such as cartesian product (

), partial

or total inclusion (

⊂, ⊆

), union, intersection and dif-

ference (

∪, ∩, \

), or power set (

). Set composition

nodes are draw as a diamond ( ) and connected in the

same mindset of input and output as with mappings

and binary relations. However, since operators such

∪

are not restricted to single input and output

nodes, we need to generalize edge orientation seman-

tics: Any incoming edge of a set composition node

connects operands, while an outgoing edge references

the resulting set.

This way operators may be cascaded

to allow subgraphs for complex set deﬁnitions.

To preserve readability of REAP

speciﬁcations,

we also allow for an easy way to hide this complexity

whenever undesired: for this purpose, we introduce

identity relationships. These are denoted by an edge

type that indicates equality of both adjacent nodes

(which are also called aliases). To distinguish them

from regular input-output-edges, we draw them dashed

and, due their symmetric semantics, undirected ( ).

Example 2.

We continue the HIS policy introduced

in Example 1. To add semantics for role administra-

tion, a policy engineer may intend a special subset

of roles (

) only eligible for a special subset of

(administrator-)users (

). This results in

⊂

and

⊂

Note that for both deﬁnitions, a policy engineer may

opt to declare a node of independent (administrative)

identiﬁers, which are described in more details as sub-

set of legal user/role identiﬁers in the left part of the

If required, operands are ordered by numerical weights.

Towards Language Support for Model-based Security Policy Engineering

515

roles

(a) REAP

roles

⊂

SoD

(b) REAP

Figure 2: Exemplary REAP graphs for the hospital information system scenario.

graph, e. g. to enable its reuse as a single atomic set

in another, related policy. Alternatively, she may also

skip the explicit denomination for the sake of brevity.

Both ways are semantically identical.

Finally, again in the mindset of extending parts of

the policy by just extending the previous graph, we

may go into more detail about what exactly a permis-

sion in set

is. In case we conceive a permission as a

set of pairs of objects (

) and operation (

) (Fer-

raiolo et al., 2007), this may be achieved by cascading

a cartesian product and a power set:

While the cartesian product may remain anonymous,

we identify the power set resulting from this subgraph

with our permissions set P.

Compared to Example 1, this extends our resulting

set deﬁnitions by

AU ⊂ U

AR ⊂ R

, whereas

P = P (O × OP)

is now a derived set (cf. Fig. 2b).

Note that for conciseness, we have decided not to show

the implicit relationships between

and

(via

and

roles

) that result from their subset relationship

with

and

. Again, drawing these additional edges

it left to the discretion of the policy engineer. This is

also an example for how potential incompleteness or

inconsistencies may be reported to the engineer in a

tool-assisted graph drawing workﬂow.

REAP

Up to this point, REAP enables the deﬁni-

tion and composition of arbitrary sets and their relation-

ships. However, policies may include more abstract re-

quirements that further restrict these deﬁnitions, which

we call constraints. Constraints can be visualized by

node annotation, which can also be used for arbitrary

meta-information about any part of the model (e. g. for

distinguishing mutable from static sets).

In REAP

, we introduce annotation nodes for sets

of boolean expressions. Such nodes are visually de-

noted by a capsule ( ) and labeled as usual: by a

A third way, that still names a derived set without an

explicit alias by using the name label, is depicted in Fig. 2b.

name and a specialization, where the latter contains

an explicit expression if visually capable. Otherwise,

the constraint set name serves as a reference to an ex-

ternal textual speciﬁcation, just as with name labels.

They are connected to annotated nodes through visu-

ally distinguished scope edges ( ). A possible use

case is shown in Fig. 2b: Constraints to enforce static

separation of duties restrict

, where

SoD

is a refer-

ence to a set of boolean expressions such as “

∀u ∈ U :

{

u, MedMgmt

u, NursMgmt

} 6⊆ UA

” which pre-

vents any user from accessing both medical manage-

ment and nursing services management resources (and

possibly other pairs of conﬂicting roles).

Note that the model resulting from the above ex-

amples closely resembles the basic modeling schemes

for (administrative) RBAC (Ferraiolo et al., 2007),

however speciﬁcally tailored to our HIS scenario: for

example, since the policy does not mention a session

concept nor a separation of administrative from non-

administrative roles (Stoller et al., 2007), both are not

included in our model speciﬁcation. This could still be

changed if required in later MSPE steps, such as by an

efﬁcient model analysis method, using the set-based

language elements presented here.

2.3 Usage in Model Engineering

By design, REAP suggests an iterative model engineer-

ing workﬂow. This requires the policy engineer to

ﬁrst make the most fundamental decisions regarding

atomic sets and their simplest possible interrelations,

which are subject to subsequent reﬁnement later on.

This workﬂow, as well known from the more general

software engineering process, reduces the room for er-

rors and increases communication efﬁciency by hiding

information irrelevant for experts from differing ﬁelds.

Finally, it should be highlighted that according to

our general claim, language support for MSPE must

always enable tool-support. For REAP, this comprises

two speciﬁc tasks: (1.) to support the design part of

model engineering through a graphical editor, featur-

ing plausibility checks and decision support (possibly

based on a model engineering expert system); (2.) to

SECRYPT 2020 - 17th International Conference on Security and Cryptography

516

enable automatic translation to formal algebra required

by model analysis methods. While validating the ﬁrst

goal is subject to our ongoing work, the second one

has already been demonstrated in the examples above.

3 DYNAMO

Given the critical importance of security policy correct-

ness, our overall goal is to make the entire MSPE pro-

cess more streamlined and, thus, to avoid error-prone

translations of model speciﬁcations in transitions be-

tween MSPE steps. We argue that this is achievable

by comprehensive and uniform language support.

Having engineered a formal model for a security

policy in the model engineering step, both subsequent

steps, model analysis and model implementation, re-

quire a machine-readable model speciﬁcation as input.

Consequently, model speciﬁcations can and should

be based on a uniform textual speciﬁcation language

usable across the MSPE process steps.

Towards this goal we present DYNAMO – a speci-

ﬁcation language for dynamic security models based

on deterministic automatons. DYNAMO is designed to

share goals of all three main steps in MSPE. Hence, a

speciﬁcation in DYNAMO is (1.) close to formal model

abstractions (model engineering step); (2.) semanti-

cally expressive to be able to specify policy dynamics,

which enables analyses of dynamic model properties

(e. g. model safety), and machine-interpretable by anal-

ysis tools (model analysis step); (3.) translatable into

source code which can be integrated into security archi-

tecture implementations (model implementation step).

In the following we detail these goals to describe

language requirements (

3.1), derive design decisions

regarding language paradigms (

3.2), and discuss how

tool support embeds DYNAMO into MSPE (§3.3).

3.1 Language Requirements

In general, MSPE involves qualiﬁed security engineers

which are familiar with mathematical notations of

model abstractions. Consequently, a speciﬁcation lan-

guage facilitating cross-step support in MSPE should

generally support these notations. Access control (AC)

policies are one of the most prominent policy classes

in practice. As a ﬁrst step, DYNAMO focuses on lan-

guage support for dynamic AC models demonstrating

the approach to streamline MSPE.

As yielded by the requirements analysis on neces-

sary formal building blocks for expressing AC models

(cf.

2.1), basically three abstract data types (ADTs)

are required: set, relation, and mapping, each repre-

senting its mathematical counterpart. Since we strive

for supporting a broad range of dynamic security mod-

els, the extension regarding further common mathe-

matical model abstractions, such as matrices

(e. g.

often used in AC models such as (Harrison et al.,

1976), (Sandhu, 1992), and (Zhang et al., 2005)) or lat-

tices (e. g. often found in information ﬂow models (cf.

(Vimercati et al., 2005)) should be easily realizable.

The model analysis step may not only aim at ana-

lyzing static model properties (e. g. model consistency)

but also dynamic model properties (e. g. model safety)

regarding the temporal changes an AC system may un-

dergo. In previous work (Amthor et al., 2014; Amthor,

2016; Schlegel and Amthor, 2020), we propose an ap-

proach that allows security engineers to conﬁgure mod-

eling schemes to application-speciﬁc analysis goals.

Hence, we require DYNAMO to being able to specify

security models with conﬁgurable dynamics, which we

deﬁne based on deterministic automatons (according

to the original idea of (Harrison et al., 1976)).

Deﬁnition 1 (Dynamic Security Model).

A dy-

namic security model is a deterministic automaton

deﬁned by a tuple

Γ, Σ, ∆, γ

, E

, where

•

The state space

is a set of states deﬁned as a

cartesian product of dynamic model components;

•

The input set

Σ = Σ

× Σ

∗

deﬁnes possible inputs

that may trigger state transitions, where

is a

set of command identiﬁers used to represent op-

erations a policy may authorize and

is a set of

values usable as actual parameters of commands;

•

The state transition scheme (STS)

∆ ⊆ Σ

∗

× Φ × Φ

deﬁnes state transition pre- and post-

conditions for any input of a command and formal

parameters, where

denotes a set of variables to

identify such parameters, and

represents a set of

boolean expressions in ﬁrst-order logic;

• The initial state γ

;

•

The extension tuple

is a tuple of static model

components which are not part of Γ.

For deﬁning each

c, x, φ, φ

∈ ∆

, the notation

c(x) ::= PRE : φ; POST : φ

is used. We call the term

the pre-condition and

the post-condition of any

state transition to be authorized via command

. On

an automaton level, this means that

restricts which

states

to legally transition from, while

deﬁnes

any differences between

and the state

reachable

by any input word

c, x

. To distinguish between the

value domains of individual variables in

, we use a

Note that for access control matrices (ACMs) mathemat-

ically formalized by mappings, a convenience matrix ADT

would just ease access to ACM columns and rows.

We use the Kleene operator to indicate that multiple

parameters may be passed.

Towards Language Support for Model-based Security Policy Engineering

517

reﬁned deﬁnition of

to reﬂect distinct namespaces

of variable identiﬁers for each model component.

In the model analysis step, our goal is to reason

about possible state transitions. Hence, we require that

only such commands are modeled in

∆

that modify

their successor state. Additionally, the model imple-

mentation step requires a complete model speciﬁcation

also incorporating policy authorization rules which not

necessarily modify a current protection state. We as-

sume such rules to be modeled as STS commands with

an empty post-condition.

A core motivation for DYNAMO is to prevent

and respectively reduce potential errors in transitions

between MSPE steps. Hence, we require our lan-

guage to encompass two well-known concepts of es-

tablished programming languages. First, by dividing a

model speciﬁcation into two parts, DYNAMO enables

reusability of speciﬁcations through inheritance: The

model part describes a certain model class deﬁning

policy abstractions through model components as well

as macros for pre- and post-condition of STS com-

mands; the model instance part describes a concrete

initialization of a dynamic model’s automaton by using

parts of a derived model. Second, by encompassing a

strong typing of model components, which is enforced

and checked by DYNAMO compilers, security engi-

neers are supported in ﬁnding invalid assignments or

relations between common model component types.

Model engineering is an iterative approach, model

analysis results often have to be incorporated manually.

Therefore, DYNAMO must be ergonomic, especially

for qualiﬁed security engineers, and provide language

elements in a way such that speciﬁcations are as sim-

ple, concise, and unambiguous as possible.

3.2 Language Design

The size and complexity of real-world security poli-

cies require model speciﬁcations which are as small

and simple as possible. Therefore, DYNAMO sup-

ports a simple ﬂavor of inheritance known from object-

oriented programming languages resulting in hierar-

chic model speciﬁcations. From a high-level perspec-

tive, each DYNAMO speciﬁcation consists of two parts:

model

and a

model-instance

. A concrete model

instance is then always derived from an abstract model.

Generallyin DYNAMO, every statement and every

block of statements encapsulated by

begin

and

end

trailed by a semicolon. The remainder of this section

details DYNAMO’s language features divided into

the two parts of a speciﬁcation (

3.2.1 and

3.2.2)

and extracts of the EBNF notations, which are

demonstrated stepwise based on a dynamic RBAC

(DRBAC) model (according to Def. 1 and

model_sp e c =

" be gin " " model " stri ng ":"

" be gin " " inheritance " ":"

inherita n c e _ s e c t io n

" end " " inheritanc e " "; "

" be gin " " components " ":"

components _ s e c t i o n

" end " " compone n t s " ";"

" be gin " " pre-clauses " ":"

pre_clau s e s _ s e c t io n

" end " " pre-clause s " ";"

" be gin " " post-clauses " ":"

post_cl a u s e s _ s ec tion

" end " " post-clauses " ";"

" end " " model " ";" ;

Listing 1: EBNF for model speciﬁcations.

set U , R , P , S ;

relat ion UA(U , R) , PA (P , R ) ;

mapp ing user ( S : U) , roles ( S : 2ˆ R );

Listing 2: Example of a components section.

(Schlegel and Amthor, 2020)) for a simpliﬁed version

of the HIS security policy introduced in §2.2.

3.2.1 Model Speciﬁcation

In general, a

model

speciﬁcation deﬁnes the abstrac-

tions in form of all dynamic and static model compo-

nents (

components

section) and reusable macros for

pre- and post-clauses as building blocks for STS com-

mands (

pre-clauses

and

post-clauses

sections).

Listing 1 shows the structure of a

model

speciﬁcation.

The

components

section deﬁnes a model’s com-

ponents which are, later on (in a

model-instance

divided into dynamic components, belonging to the

state space

, and static components, belonging to the

extension tuple

. Each model component has a type

declared by the ADTs

set

relation

, or

mapping

and a string identiﬁer; parametrized types require ad-

ditional parameters. Listing 2 shows an example for

the DRBAC model.

As required for the speciﬁcation of pre-clauses,

which are used in a

model-instance

to specify STS

command pre-conditions, DYNAMO deﬁnes the intu-

itive logical operators

not in

not

forall

exists

and

, and

, optionally grouped by paren-

theses

( )

. Listing 3 shows two pre-clauses: First,

check acf

speciﬁes an access control function (ACF)

acf

RBAC

: S × P → {true, false}

which allows to ex-

press whether a permission

p ∈ P

may be used in a

certain session

s ∈ S

. Second,

can activate role

checks whether a role

r ∈ R

may be activated in a cer-

tain session

s ∈ S

by requiring that

is associated with

the s’s corresponding user u in UA.

SECRYPT 2020 - 17th International Conference on Security and Cryptography

518

check_ a c f ( S s , P p ):

exi sts r in roles ( s ) : [p, r ] in PA ;

can_activate _ r o l e ( S s , R r):

exi sts u in U: (

u == user ( s ) and [ u , r] in UA ) ;

Listing 3: Example of a pre-clauses section.

begin a c t i v a t e _ r o l e ( S s , R r ):

rs = roles (s ) ;

rs = rs + { r };

roles = role s + { (s : rs) };

end ;

Listing 4: Example of a post-clauses section.

begin i n h er i te d_ m od el _ 1 :

all ;

end ;

begin i n h er i te d_ m od el _ 2 :

componen t s : {U, R as R_NEW };

pre-conditions : { }; /* inherit none. */

post-conditions : all ;

end ;

Listing 5: Example of an inheritance section.

Post-clauses are speciﬁed as blocks of statements.

Each statement modiﬁes a model component by adding

or removing elements. To ease the speciﬁcation, el-

ements of model components may be also assigned

temporarily to identiﬁers, which are local within a

clause’s scope. Listing 4 exemplarily demonstrates

this for the post-clause

activate role

. Futhermore,

it is possible to iteratively execute statements for each

element a component contains by using a

for

state-

ment known from common programming languages.

To further improve the reusability of speciﬁcations

and to reduce the speciﬁcation effort, a model speci-

ﬁcation can be inherited (

inheritance

section): By

using

all

, a given

model

speciﬁcation is inherited

completely. Parts of a speciﬁcation can be inherited

list-based under indication of the corresponding sec-

tion. It is also possible to rename inherited components

using the keyword as. Listing 5 shows two examples.

3.2.2 Model Instance Speciﬁcation

model-instance

speciﬁcation deﬁnes the automa-

ton components of a dynamic model according to

Def. 1. Listing 6 shows its structure.

For a concrete

model-instance

, the model com-

ponents derived from an abstract

model

speciﬁcation

are divided into dynamic and static components. Con-

sequently, the

state-space

statement deﬁnes a set of

all dynamic model components (see Listing 7).

model_in s t a n c e _ s pe c =

" be gin " " model-instance " s tring ":"

str ing ":"

" state-space " ":"

"{" s tate_space "}" ";"

" input-vector " ":"

"{" i n p ut_vector "}" ";"

" be gin " " st a t e - t ransition-sch e m e " ":"

stat e _ t r ansition_ s c h eme_secti o n

" end " " state- t r a n sition-scheme " ";"

" be gin " " initial-state " ":"

inital_ s t a t e _ s ec tion

" end " " initial-state " ";"

" be gin " " extension-tup l e " ":"

extens i o n _ t uple_section

" end " " extension-tuple " ";"

" end " " model-instance " ";" ;

Listing 6: EBNF for model-instance speciﬁcations.

state-space : {U , S , UA , user , rol es };

input-vector : {U , S , R };

Listing 7: Example of

state-space

and

input-vector

statements.

The input vector of a dynamic model deﬁnes what

parameters can be used for STS commands. Accord-

ingly, the

input-vector

section speciﬁes a subset of

model components and corresponding power sets (e. g.

user set U or power set of user set 2ˆU).

The

state-transition-scheme

is a list of com-

mand speciﬁcations where each one either has a pre-

condition part (

pre: ...;

) consisting of logically con-

nected clauses and derived clause macros, a post-

condition part (

begin post: ... end post;

) con-

sisting of one or more clauses and clause macros,

or both parts. Constants in pre- and post-conditions

can be speciﬁed by using single quotes. Listing 8

shows an exemplary speciﬁcation of a command

delegate treatment doc card.

deleg a t e _ treatment_ d o c _ card (

S s_caller , S s_del e g ) :

pre : check_a c f ( s_caller ,

' p_ d eleg_trea t m ent ') and

is_activated ( s_caller ,

' r_doc _card ') and

can_activate _ r o l e ( s_deleg ,

' r_doc _card ') ;

begin post : a c t i v a t e _ r o l e ( s_deleg ,

' r_doc _card ') ;

end post ;

Listing 8: Example of a

state-transition-scheme

command speciﬁcation.

In the

initial-state

, all dynamic model com-

ponents are assigned their initial values. Listing 9

exemplarily shows assignments of initial values to mo-

Towards Language Support for Model-based Security Policy Engineering

519

S = { s1 , s2 };

UA = { [u1 , r1 ], [ u1 , r2] , [u2 , r1 ] };

user = { s1 : u1 , s2 : u2 };

Listing 9: Examples of

set

relation

and

mapping

component value assigments used in

initial-state

and

extension-tuple sections.

del components of types

set

relation

and

mapping

Complementary to the

state-space

and

initial-state

, in the

extension-tuple

section,

all static model components are listed and initialized.

3.3 Tool Support

With the DYNAMO speciﬁcation language, we aim

for uniform language support across the MSPE steps

model engineering, model analysis, and model imple-

mentation. In order that a speciﬁcation in DYNAMO

is effectively usable, tool support in form of compilers

is required, which automate (1.) plausibility and type

checking to detect speciﬁcation errors, (2.) generation

of a intermediate language representation for existing

model analysis tools, and (3.) source code generation

for machine-executable model implementations.

As a ﬁrst proof-of-concept, we implemented two

compilers. First, a DYNAMO-to-XML compiler is

able to generate an intermediate XML-based model

representation which is compatible with our dynamic

model analysis tool (Amthor et al., 2014). Second,

a DYNAMO-to-C++ compiler enables an automated

generation of an algorithmic model representations

in C++ and all functionality necessary for its runtime

based on a layered approach.

4 CONCLUSIONS

This paper discusses language foundations for model-

based engineering of security policies. Considering

the critical and error-prone nature of translating model

speciﬁcations between the MSPE steps, we argue that

MSPE requires holistic speciﬁcation language and tool

support. Towards this goal we present REAP, a visual

speciﬁcation language for formalizing security poli-

cies in model engineering, and DYNAMO, a textual

speciﬁcation language enabling model engineering,

model analysis and model implementation of dynamic

security models. We already tested both languages by

proof-of-concept tools.

We consider the work in this paper a ﬁrst step:

Ongoing work focuses on evaluating the methodol-

ogy within a use case study comprising a real-world

security policy, enabling support for further classes

of security models in REAP and DYNAMO such as

information ﬂow or non-interference models, and se-

cure runtime environments for rigorously enforcing

compiler-generated executable model representations

within security architecture implementations.

REFERENCES

Amthor, P. (2016). The Entity Labeling Pattern for Modeling

Operating Systems Access Control. In E-Business and

Telecomm.: 12th Int. Joint Conf., ICETE 2015, Revised

Selected Papers, pages 270–292.

Amthor, P., K

uhnhauser, W. E., and P

olck, A. (2014).

WorSE: A Workbench for Model-based Security Engi-

neering. Comp. & Secur., 42(0):40–55.

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

Model-Driven Security. In Proc. 16th ACM Symp. on

Access Control Models and Technol., pages 1–10.

Ben Fadhel, A., Bianculli, D., and Briand, L. (2016).

GemRBAC-DSL: A High-level Speciﬁcation Lan-

guage for Role-based Access Control Policies. In Proc.

21st ACM Symp. on Access Control Models and Tech-

nol., pages 179–190.

Crampton, J. and Morisset, C. (2012). PTaCL: A Language

for Attribute-Based Access Control in Open Systems.

In Principles of Secur. and Trust: POST 2012, vol.

7215 of LNCS, pages 390–409.

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

Role-Based Access Control. Artech House. Sec. Ed.,

ISBN 978-1-59693-113-8.

Harrison, M. A., Ruzzo, W. L., and Ullman, J. D. (1976).

Protection in Operating Systems. Comm. of the ACM,

19(8):461–471.

Jin, X., Krishnan, R., and Sandhu, R. (2012). A Uniﬁed

Attribute-Based Access Control Model Covering DAC,

MAC and RBAC. In Data and App. Secur. and Priv.

XXVI, vol. 7371 of LNCS, pages 41–55.

Mitra, B., Sural, S., Vaidya, J., and Atluri, V. (2016). A

Survey of Role Mining. ACM Comput. Surv., 48(4).

OASIS (2013). eXtensible Access Control Markup Lan-

guage (XACML) Version 3.0. OASIS Standard.

Sandhu, R. S. (1992). The Typed Access Matrix Model.

In Proc. 1992 IEEE Symp. on Secur. and Priv., pages

122–136.

Sandhu, R. S., Coyne, E. J., Feinstein, H. L., and Youman,

C. E. (1996). Role-Based Access Control Models.

IEEE Comp., 29(2):38–47.

Schlegel, M. and Amthor, P. (2020). Beyond Administration:

A Modeling Scheme Supporting the Dynamic Analysis

of Role-based Access Control Policies. In Proc. 17th

Int. Conf. on Secur. and Cryptogr., to appear.

Servos, D. and Osborn, S. L. (2017). Current Research

and Open Problems in Attribute-Based Access Control.

ACM Comput. Surv., 49(4):65:1–65:45.

Stoller, S. D., Yang, P., Ramakrishnan, C. R., and Gofman,

M. I. (2007). Efﬁcient Policy Analysis for Administra-

tive Role Based Access Control. In Proc. 14th ACM

Conf. on Comp. and Comm. Secur., pages 445–455.

SECRYPT 2020 - 17th International Conference on Security and Cryptography

520

Vimercati, S. D. C. d., Samarati, P., and Jajodia, S. (2005).

Policies, Models, and Languages for Access Control.

In Proc. 4th Int. Workshop on Databases in Networked

Inf. Syst., vol. 3433/2005 of LNCS, pages 225–237.

Xiao, X., Paradkar, A., Thummalapenta, S., and Xie, T.

(2012). Automated Extraction of Security Policies

from Natural-language Software Documents. In Proc.

20th Int. ACM Symp. on the Found. of Softw. Eng.,

pages 12:1–12:11.

Zhang, X., Li, Y., and Nalla, D. (2005). An Attribute-based

Access Matrix Model. In Proc. 2005 ACM Symp. on

Applied Comp., pages 359–363.

Towards Language Support for Model-based Security Policy Engineering

521