Towards Language Support for Model-based Security Policy Engineering
Peter Amthor
and Marius Schlegel
Technische Universit
at Ilmenau, Germany
Software Engineering, Security Engineering, Security Policies, Security Models, Specification Languages,
Domain-specific Languages, Automatic Translation.
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 verifiable 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-specific languages and tools. We present
ongoing work on two languages that substantiate this thesis, including their usage in a practical setting, and
discuss the benefits from combining them with appropriate tool support.
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 confidentiality, 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 verified 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 defined by
requirements engineers and application experts, usu-
ally based on semi-formal or natural language (Xiao
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 finally needs
to be translated into a functional software specifica-
tion (OASIS, 2013; Ben Fadhel et al., 2016), and,
finally, 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-specific 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 specification language), a
machine-readable language for model analysis and
automated source code generation (§3).
The fundamental motivation behind a specification 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
2020 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
Security Policy
Formal Model
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 specific MSPE methods. As a first step
towards these goals, REAP is a visual specification
language that defines 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 identified 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 specific range of mathematical
artifacts is used as building blocks of these models, in-
cluding (1.) Basic set theory: sets of unique identifiers,
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 definition.
The semantics of these artifacts dictate the follow-
ing functional language requirements with respect to
expressiveness: (1.) It is possible to define sets of
unique identifiers, which we call atomic sets. Their
elements (e. g. identifiers of human users) do not have
any observable inner structure. (2.) Any language ex-
pression is used to define a relationship between sets.
This may be e. g. a mapping of user- to role-identifiers,
or a relation over roles that indicates a role hierarchy.
(3.) An expression may be used to define 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 specifications 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:
Define sets of atomic identifiers and their
power sets, connect them through mappings or
binary relations.
Express complex definitions of sets derived
from atomic sets, define aliases for sets.
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
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
refinement. 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 defining 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 suffices to distinguish between a first (“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 ( ) identifies a power set used in the
definition of mappings and relations.
Example 1.
Assume a security policy for a hospital
information system (HIS). We first identify necessary
unique identifiers 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:
This enables a policy engineer to leave unspecified, 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
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 fulfill 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 specification 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 definitions of (1.) sets:
U, R, P
; (2.) relations:
R × R
; (3.) mappings:
roles : U P (R)
. This exam-
ple illustrates how the basic language level REAP
can already express a practically significant range of
policies, in particular, RBAC
(Sandhu et al., 1996).
, 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
security policy is a graph composed from valid
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 definitions.
To preserve readability of REAP
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
Note that for both definitions, a policy engineer may
opt to declare a node of independent (administrative)
identifiers, which are described in more details as sub-
set of legal user/role identifiers in the left part of the
If required, operands are ordered by numerical weights.
Towards Language Support for Model-based Security Policy Engineering
(a) REAP
(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 definitions by
, 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
) that result from their subset relationship
. 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 workflow.
Up to this point, REAP enables the defini-
tion and composition of arbitrary sets and their relation-
ships. However, policies may include more abstract re-
quirements that further restrict these definitions, 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).
, 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 specification, 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
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 conflicting 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 specifically 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 specification. This could still be
changed if required in later MSPE steps, such as by an
efficient 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 workflow. This requires the policy engineer to
first make the most fundamental decisions regarding
atomic sets and their simplest possible interrelations,
which are subject to subsequent refinement later on.
This workflow, as well known from the more general
software engineering process, reduces the room for er-
rors and increases communication efficiency by hiding
information irrelevant for experts from differing fields.
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 specific 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
enable automatic translation to formal algebra required
by model analysis methods. While validating the first
goal is subject to our ongoing work, the second one
has already been demonstrated in the examples above.
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 specifications 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 specification as input.
Consequently, model specifications can and should
be based on a uniform textual specification language
usable across the MSPE process steps.
Towards this goal we present DYNAMO – a speci-
fication language for dynamic security models based
on deterministic automatons. DYNAMO is designed to
share goals of all three main steps in MSPE. Hence, a
specification 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 qualified security engineers
which are familiar with mathematical notations of
model abstractions. Consequently, a specification 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 first 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
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 flow 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 configure mod-
eling schemes to application-specific analysis goals.
Hence, we require DYNAMO to being able to specify
security models with configurable dynamics, which we
define based on deterministic automatons (according
to the original idea of (Harrison et al., 1976)).
Definition 1 (Dynamic Security Model).
A dy-
namic security model is a deterministic automaton
defined by a tuple
Γ, Σ, , γ
, E
, where
The state space
is a set of states defined as a
cartesian product of dynamic model components;
The input set
Σ = Σ
× Σ
defines possible inputs
that may trigger state transitions, where
is a
set of command identifiers 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)
× Φ × Φ
defines 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 first-order logic;
The initial state γ
The extension tuple
is a tuple of static model
components which are not part of Γ.
For defining 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
to legally transition from, while
any differences between
and the state
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
refined definition of
to reflect distinct namespaces
of variable identifiers 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 specification
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 specification into two parts, DYNAMO enables
reusability of specifications through inheritance: The
model part describes a certain model class defining
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 finding 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 qualified security engineers, and provide language
elements in a way such that specifications 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 specifications which are as small
and simple as possible. Therefore, DYNAMO sup-
ports a simple flavor of inheritance known from object-
oriented programming languages resulting in hierar-
chic model specifications. From a high-level perspec-
tive, each DYNAMO specification consists of two parts:
and a
. A concrete model
instance is then always derived from an abstract model.
Generallyin DYNAMO, every statement and every
block of statements encapsulated by
trailed by a semicolon. The remainder of this section
details DYNAMOs language features divided into
the two parts of a specification (
3.2.1 and
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 specifications.
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 simplified version
of the HIS security policy introduced in §2.2.
3.2.1 Model Specification
In general, a
specification defines the abstrac-
tions in form of all dynamic and static model compo-
nents (
section) and reusable macros for
pre- and post-clauses as building blocks for STS com-
mands (
Listing 1 shows the structure of a
section defines a model’s com-
ponents which are, later on (in a
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
, or
and a string identifier; parametrized types require ad-
ditional parameters. Listing 2 shows an example for
the DRBAC model.
As required for the specification of pre-clauses,
which are used in a
to specify STS
command pre-conditions, DYNAMO defines the intu-
itive logical operators
not in
, and
, optionally grouped by paren-
( )
. Listing 3 shows two pre-clauses: First,
check acf
specifies an access control function (ACF)
: 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 ss corresponding user u in UA.
SECRYPT 2020 - 17th International Conference on Security and Cryptography
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 specified as blocks of statements.
Each statement modifies a model component by adding
or removing elements. To ease the specification, el-
ements of model components may be also assigned
temporarily to identifiers, 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
ment known from common programming languages.
To further improve the reusability of specifications
and to reduce the specification effort, a model speci-
fication can be inherited (
section): By
, a given
specification is inherited
completely. Parts of a specification 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 Specification
specification defines the automa-
ton components of a dynamic model according to
Def. 1. Listing 6 shows its structure.
For a concrete
, the model com-
ponents derived from an abstract
are divided into dynamic and static components. Con-
sequently, the
statement defines 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 specifications.
state-space : {U , S , UA , user , rol es };
input-vector : {U , S , R };
Listing 7: Example of
The input vector of a dynamic model defines what
parameters can be used for STS commands. Accord-
ingly, the
section specifies a subset of
model components and corresponding power sets (e. g.
user set U or power set of user set 2ˆU).
is a list of com-
mand specifications 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 specified by using single quotes. Listing 8
shows an exemplary specification 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
command specification.
In the
, 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
S = { s1 , s2 };
UA = { [u1 , r1 ], [ u1 , r2] , [u2 , r1 ] };
user = { s1 : u1 , s2 : u2 };
Listing 9: Examples of
component value assigments used in
extension-tuple sections.
del components of types
Complementary to the
, in the
all static model components are listed and initialized.
3.3 Tool Support
With the DYNAMO specification language, we aim
for uniform language support across the MSPE steps
model engineering, model analysis, and model imple-
mentation. In order that a specification in DYNAMO
is effectively usable, tool support in form of compilers
is required, which automate (1.) plausibility and type
checking to detect specification 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 first 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.
This paper discusses language foundations for model-
based engineering of security policies. Considering
the critical and error-prone nature of translating model
specifications between the MSPE steps, we argue that
MSPE requires holistic specification language and tool
support. Towards this goal we present REAP, a visual
specification language for formalizing security poli-
cies in model engineering, and DYNAMO, a textual
specification 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 first 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 flow or non-interference models, and se-
cure runtime environments for rigorously enforcing
compiler-generated executable model representations
within security architecture implementations.
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 Specification 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,
Jin, X., Krishnan, R., and Sandhu, R. (2012). A Unified
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
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). Efficient 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
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