Beyond Administration: A Modeling Scheme Supporting the Dynamic
Analysis of Role-based Access Control Policies
Marius Schlegel
a
and Peter Amthor
b
Technische Universit
¨
at Ilmenau, Germany
Keywords:
Security Engineering, Security Policies, Access Control, Role-based Access Control Models, RBAC, Heuristic
Safety Analysis, Formal Methods.
Abstract:
Despite defining a de-facto standard in model-based security engineering, role-based access control models still
suffer from limited analysis capabilities. This is especially true for dynamic security properties in the lineage of
HRU safety. As a consequence, despite of their widespread use for policy specification and implementation, it
is difficult to provide and preserve correctness guarantees for such models. We propose a formal framework,
called DRBAC, to resolve this dilemma: While retaining application-oriented model abstractions, our approach
allows to configure their dynamics in terms of state transitions. This enables a security engineer to tailor both a
model and its analysis method to certain safety-related analysis goals. We demonstrate this claim based on a
practical security policy.
1 INTRODUCTION
To meet mission-critical security requirements, access
control (AC) systems must guarantee to implement
a correct security policy. For decades, such correct-
ness guarantees have been founded on formal meth-
ods (Vimercati et al., 2005; Tripunitara and Li, 2007;
Basin et al., 2011) which rely on three fundamental
artifacts: (1.) a formal security model, e. g. based on
first-order logic or set algebra, (2.) a formal definition
of its correctness condition (security property), and
(3.) a method as automated as possible to validate the
former against the latter. Decades of experience and
best practices have yielded modeling schemes, formal
toolboxes of predicates, set-theoretical expressions,
automata theory etc., that help engineers in choosing
suitable formalisms for a security model.
Role-based access control (RBAC) is a modeling
scheme which has been established as a de-facto stan-
dard for a wealth of application scenarios (Sandhu
et al., 1999; Sandhu et al., 2000). Despite its gener-
alization through attribute-based modeling schemes
(ABAC) (Fern
´
andez et al., 2019; Chakraborty et al.,
2020), it remains one of the most relevant formal tools
because of its simple, clear, yet practical abstractions.
In contrast to the modeling scheme itselft, however,
a
https://orcid.org/0000-0001-6596-2823
b
https://orcid.org/0000-0001-7711-4450
there are no standardized artifacts to answer the other
two questions involved in RBAC policy analysis: how
to formally express relevant security properties, and
how to analyze them based on automatable methods.
This is especially true for the analysis of dynamic
state reachability properties, which can be used to fore-
see privilege escalation vulnerabilities of a policy, but
at the same time is pestered by computational complex-
ity (Tripunitara and Li, 2007). Such formal properties,
which are known as safety properties for historical
reasons, need to be (re-)defined for any application-
specific AC model. We call the resulting security prop-
erty the analysis goal of that specific model. Since the
application-specific definition of an analysis goal is a
burdensome and error-prone task, previous research
efforts in the AC community have focused on more
specialized analysis questions towards the effect of pol-
icy administration, rather than those of more general
day-to-day accesses performed by users (administra-
tive RBAC, ARBAC) (Li and Tripunitara, 2006; Ranise
et al., 2014; Calzavara et al., 2015; Dinh et al., 2017).
This paper addresses this limitation: it proposes
DRBAC, a novel modeling scheme for RBAC poli-
cies, based on a configurable formal framework. This
allows a security engineer to derive an analysis goal
from the resulting RBAC model, which is by design
compatible with a heuristic analysis approach for the
most general (and therefore semi-decidable) class of
safety properties: dynamic privilege proliferation in
Schlegel, M. and Amthor, P.
Beyond Administration: A Modeling Scheme Supporting the Dynamic Analysis of Role-based Access Control Policies.
DOI: 10.5220/0009834304310442
In Proceedings of the 17th International Joint Conference on e-Business and Telecommunications (ICETE 2020) - SECRYPT, pages 431-442
ISBN: 978-989-758-446-6
Copyright
c
 2020 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
431

the lineage of HRU safety (Harrison et al., 1976). With
such a modeling scheme, we may eventually ensure
that precise correctness guarantees can be given and
preserved throughout model-based security policy en-
gineering, which denotes the whole process of speci-
fying, analyzing and implementing a security policy.
DRBAC is based on the observation that interesting
analysis goals relate to (1.) model dynamics not origi-
nating from adminstration and (2.) security properties
intractable or even undecidable. The first observation
can be confirmed in most practical scenarios involving
dynamic user management: While both user creation
and session logins can be modeled in classical RBAC,
they are neither included in administrative model parts
used to represent dynamics in ARBAC , nor, as a conse-
quence, are they subject to related work on analyzing
role-based policies (cf. Sec. 2). The second observa-
tion is based on the mindset that for the most expres-
sive AC models, possibly undecidable safety properties
may offer insights into policy design errors w. r. t. po-
tential privilege escalation. As indicated by previous
work (Amthor et al., 2013; Amthor and Rabe, 2020),
heuristic analysis approaches may provide valuable
hints to find such errors, but require an appropriate
modeling scheme for infinite search spaces.
Paper Organization. After giving an overview of
related work in Sec. 2, we present in Sec. 3 our method-
ical contributions towards model-based security policy
engineering: (1.) a uniform framework to express mod-
eling schemes, applied to the ARBAC97 model family;
(2.) the DRBAC modeling scheme, including an exam-
plary model for a hospital information system policy
which we retain as a running example. Sec. 4 presents
our practical contributions towards model analysis:
we (3.) demonstrate the benefits that result from our
modeling scheme by deriving practically interesting
analysis goals; we (4.) illustrate achievable analysis
results based on our example policy and (5.) discuss a
model-specific DRBAC safety analysis algorithm. We
conclude with Sec. 5.
2 RELATED WORK
This work is based on the foundational RBAC96
model family (Sandhu et al., 1996) and its admin-
istrative extension, ARBAC97 (Sandhu et al., 1999).
Both allow to choose from a set of submodels ( RBAC
1
through RBAC
3
) to express typical features of an
application-specific security policy, such as role hi-
erarchies or separation-of-duty constraints. While dy-
namic analysis are out of scope of classical RBAC96
models, ARBAC97 models protection state changes as
the results of administrative accesses. Again, the mod-
eling scheme provides submodels for different types of
dynamics to meet application-specific analysis goals:
dynamic change of roles and a role hierarchy ( RRA97 ),
user-role-assignments ( URA97 ), and permission-role-
assignments (PRA97).
In (Li and Tripunitara, 2006), a first detailed study
of dynamic analysis goals and their tractability (includ-
ing safety) was performed for the URA97 submodel of
ARBAC97 . The results of this work have been refined
and implemented in the MOHAWK line of analysis
tools (Jayaraman et al., 2013; Shahen et al., 2015),
which allows safety analyses for this model class.
Since then, user-role-reachability via URA97 have
by far received most attention in the model analysis
community: For both ARBAC97 (Stoller et al., 2007;
Jha et al., 2008) and related, more specialized model-
ing schemes (Stoller et al., 2011; Ranise et al., 2014;
Calzavara et al., 2015; Shahen et al., 2015; Dinh et al.,
2017), analysis techniques for decidable instances of
this problem have been presented. This body of work
is considered complementary to ours, since it provides
efficient methods and tools for specialized classes of
policies and their respective analysis goals, while our
motivation is to support a broad range of applications
for role-based models. This also includes a more gen-
eralized notion of safety, which is not restricted to a
specific submodel of ARBAC97 – in fact, we suggest
to treat the notion of administration independent from
model dynamics. This unlocks role-based models to
new dynamic analysis approaches, that may also in-
clude heuristic methods to reason about undecidable
problem instances (which we demonstrate in Sec. 4).
Over the recent years, there has been an increas-
ing attention to ABAC modeling schemes, capable of
generalizing roles as attributes (Fern
´
andez et al., 2019;
Chakraborty et al., 2020). However, since their anal-
ysis goals are mainly static (Fern
´
andez et al., 2019),
formal methods for defining and reasoning about dy-
namic security properties still benefit from a simpli-
fied, yet standardized calculus. To this end, we expect
that our RBAC-related results can be carried over to a
commonly accepted ABAC modeling scheme (such as
proposed in (Jin et al., 2012a; Jin et al., 2012b)).
Our approach builds on previous work to sup-
port holistic model-based security policy engineering
through configurable formal methods. These propose
an automaton-based approach of modeling AC systems
(K
¨
uhnhauser and P
¨
olck, 2011; Amthor et al., 2013),
which consequently allows to tailor each formal arti-
fact used for specifying, analyzing and implementing
a security model to the analysis goal required by its
application domain (Amthor, 2016; Amthor, 2017).
In this paper, we extend this notion of configurable
SECRYPT 2020 - 17th International Conference on Security and Cryptography
432

modeling schemes to RBAC : Based on the observa-
tion that existing role-based modeling schemes are
selected based on either expressiveness (such as with
the different submodels of ARBAC97 ) or the degree
of dynamics needed for a certain analysis goal, we
propose to unify both goals in one modeling scheme.
3 MODELING SCHEME
In this section we introduce a modeling scheme that re-
flects the semantics of traditional RBAC policies well-
established in both academia and industry. Adding to
this, our scheme aims at satisfying the requirements
of a holistic model-based security policy engineering
process, in particular the need to analyze and verify
application-specific, dynamic security properties.
To this end, we first take a look at this engineering
process in order to highlight the origins of application-
specific formalization requirements. The mindset of
our approach is then to fine-tune all formal artifacts
involved in both model engineering and model analysis
towards these requirements. We call this idea model
configuration.
3.1 Engineering Process
For engineering security-critical systems, both spec-
ification and verification of security policy rules is
based on formal security models. On a fundamental
level, the reasons for this are twofold: First, the unam-
biguous representation of such rules provides a sound
foundation for their correct implementation. Due to
their application-oriented abstractions, administration-
friendliness and resource-efficient enforcement, stan-
dardized RBAC models (Sandhu et al., 1996; Sandhu
et al., 1999; Sandhu et al., 2000; Ferraiolo et al., 2007)
have proven to satisfy this purpose. Second, diverse
modeling schemes enable the analysis of application-
specific security properties on a formal level. In the last
decades, specialized modeling schemes have emerged
for certain analysis goals (Harrison et al., 1976; Vimer-
cati et al., 2005; Barker, 2009; Ranise et al., 2014).
The usage of security models has led to model-
based security policy engineering (MSPE) as a special-
ization of the generic software engineering processes.
It can be divided into three steps (cf. Fig. 1):
1. Model Engineering denotes composing a formal
model from the informal representation of a secu-
rity policy, based on some modeling scheme that
supports the subsequent steps. This model is then
instantiated, e. g. its primitive components are ini-
tialized according to the policy. We hence call
the result of model engineering an instance of the
chosen security model.
2. Model Analysis comprises analyzing the model in-
stance against security properties, which involves
possible re-iteration of model engineering deci-
sions as supported by the modeling scheme. This
leads to possible adjustments in both the previously
derived model and its initialized components. The
finally resulting model instance is meant to comply
to the application-specific analysis goal(s).
3. Model Implementation denotes implementing the
model instance in software.
As becomes apparent, the merits of formal models
are leveraged in different steps, which possibly leads to
a practical dilemma: Modeling schemes developed for
model engineering, such as RBAC , are usually imprac-
tical if not impossible to use when targeting certain
analysis goals, such as privilege escalation. Modeling
schemes developed for such goals, on the other hand,
may fail to represent application-specific policy seman-
tics. This situation leads to models for analysis that
are totally different, from a semantical point of view,
from models used for specification and, finally, for
implementing a security policy. The resulting seman-
tic gap between correctness guarantees gained during
model analysis and the model specification used for
its implementation quite possibly leads to errors that
contradict the raison d’
ˆ
etre of the formal approach.
To resolve this dilemma, more flexible modeling
schemes are needed that adapt to their usage in both
model engineering and model analysis. In previous
work (K
¨
uhnhauser and P
¨
olck, 2011; Amthor et al.,
2014; P
¨
olck, 2014; Amthor, 2016; Amthor, 2017),
we propose an approach that allows a policy engi-
neer to configure modeling schemes to application-
specific analysis goals. From a practical perspective,
typical analysis goals may describe different levels
of dynamics w. r. t. the evolution of a system – usu-
ally represented by a formalization of protection states
and state transition rules. Combining such goals with
RBAC policies leads to a variety of possible RBAC
models ranging from completely dynamic (every part
of the model definition can change during runtime)
to completely static (no changes during runtime al-
lowed). The latter is already covered by RBAC96 ,
while ARBAC97 provides a formalism to express lim-
ited dynamics originating from administration; how-
ever, for all remaining use cases a uniform modeling
scheme is still missing.
In the remainder of this section, we demonstrate
the idea of model configuration based on a real-world
use case. We introduce a configurable RBAC model-
ing scheme, which can be fine-tuned to application-
specific analysis goals regarding dynamic behavior.
Beyond Administration: A Modeling Scheme Supporting the Dynamic Analysis of Role-based Access Control Policies
433

Model
Engineering
Model Analysis
Model
Implementation
Informal
Security Policy
Model
Modeling
Scheme
Model
Instance
Figure 1: Steps in model-based security policy engineering. Formal artifacts are printed italic, dashed arrows denote “used-in”.
As a basis for this, we first introduce an exemplary
security policy.
3.2 Examplary Security Policy
As a running example, the rest of this paper uses a se-
curity policy for a hospital information system (HIS),
simplified for illustration purposes. We will now infor-
mally describe this policy.
There are five different roles to express disjoint
capabilities of doctors, nurses, patients, managers and
receptionists. There are also more specialized roles for
doctors and nurses working in different hospital wards,
including ICU, cardiology and maternity. These roles
extend the permissions assigned to their base roles.
Permissions allow viewing, creating or modifying
electronic patient records (EPRs) and a service roster,
delegating the treatment of a patient to a referred doc-
tor in a different ward and logging in to or out from
the system. Any doctor assigned to some ward may
both view and modify EPRs in that ward, while nurses
assigned to the same ward may only view them. Both
doctors and nurses from any ward may view the ser-
vice roster, which can be both viewed and modified
by a hospital manager. Doctors may consult their col-
leagues on a case by temporarily delegating treatment
capabilities in their own ward to another doctor, who
may in turn delegate the case to a third doctor etc. Re-
ceptionists may create EPRs for new patients. Any
user may log in or out.
The above permissions lead to the following user
operations for the HIS scenario: view EPR, modify
EPR, create EPR, view service roster, login, logout,
delegate treatment. Modifying the service roster is
considered an administrative operation, since it re-
assigns a doctor or nurse to some ward.
1
Ward-specific
roles for doctors or nurses are required for using any
particular permissions for the respective ward. Since
users may change their ward, their respective base
roles are a prerequisite for the adoption of a ward-
specific role.
1
For simplicity, although required from a practical stand-
point, we have refrained from modeling operations to delete
users and revoke roles.
3.3 Role-based Model Components
As a first step to formalize a security policy, any mod-
eling scheme relies on what we call primitive compo-
nents (or just components). They are the basic building
blocks used for two purposes: First, defining elemen-
tary identifies, such as for users, roles or permissions;
second, for defining their interrelations in terms of
policy rules, such as for evaluating access decisions or
restricting possible protection state changes. In case
of role-based policies, RBAC96
2
defines a minimum
of eight primitive components, which can be formally
assigned to exactly one of these purposes.
Definition 1 (Primitive Model Component). A
primitive model component is either (1.) a set ℵ
i
of el-
ementary values or (2.) a relation, mapping or boolean
expression i
j
defined on the basis of ℵ components.
We further call these two “ ℵ components” and “ i
components”, respectively. Typically, ℵ components
are used to specify (possibly infinite) sets of elemen-
tary identifiers, while i components associate them
with each other in a meaningful way (e. g. to specify
authorization rules).
Example 1. Consider our exemplary HIS policy as
introduced in Sec. 3.2. An RBAC model is used to
formalize this policy, which contains the components
listed in Tab. 1 (columns 1–3).
3
We assume the choice
of model components was part of the requirements-
driven design of the informal security policy. Then,
during model engineering, an instance of the model
may be defined as shown in Tab. 1 (column 4).
According to the idea of administration, this model
should be extended by ARBAC components to model
role assignments. We have listed these components in
Tab. 2 (column 1–3). Note that for our policy there
is no need for an administrative role hierarchy ( ARH ).
2
For the rest of this paper we will use the term RBAC to
denote the feature-complete RBAC
3
model from RBAC96 .
In a similar manner, when talking about ARBAC97 , we will
just refer to ARBAC and URA.
3
We use “ ” as a wildcard to support legibility, which
expands to any non-empty element in the respective name
context (only used if unambiguous).
SECRYPT 2020 - 17th International Conference on Security and Cryptography
434

Table 1: RBAC primitive model components and their instantiation for Example 1. Column 1 shows the component class.
(1) (2) Symbol (3) Description (4) HIS Instantiation
ℵ
1
U set of user identifiers { drCox, drKelso, drJD, nurseCarla, nurseLaverne,
mrsFriendly, mrBruise, msPregnant}
ℵ
2
R set of role identifiers { rDoctor, rDoctorICU, rDoctorCard, rDoctorMat,
rNurse, rNurseICU, rNurseCard, rNurseMat, rPatient,
rReceptionist}
ℵ
3
P set of permission identifiers { viewRec, createRec, modRec, viewService,
delegTreat}
ℵ
4
S set of session identifiers
/
0
i
1
UA ⊆ U × R user-role-relation {
h
drJD,rDoctor
i
,
h
drCox,rDoctor
i
,
h
nurseCarla,rNurse
i
,
h
mrsFriendly,rReceptionist
i
,
h
mrBruise,rPatient
i
, ...}
i
2
PA ⊆ P × R permission-role-relation {
h
viewRec,rDoctor
i
,
h
modRec,rDoctor
i
,
h
viewService,rDoctor
i
,
h
delegTreat,rDoctor
i
,
h
createRec,rReceptionist
i
, ...}
i
3
user : S → U session-user-mapping (undefined)
i
4
roles : S → P (R) session-roles-mapping (undefined)
i
5
RH ⊆ R × R role hierarchy (partial order) {
h
rDoctorICU,rDoctor
i
,
h
rDoctorCard,rDoctor
i
, ... ,
h
rNurseICU,rNurse
i
,
h
rNurseCard,rNurse
i
, ...}
i
6
Constraints model constraints
∀u ∈ U : (
h
u,rDoctor
i
∈ UA ⇒
h
u,rDoctor
i
∈ UA)
∧ (
h
u,rNurse
i
∈ UA ⇒
h
u,rNurse
i
∈ UA)
Table 2: ARBAC primitive model components and their instantiation for Example 1. Column 1 shows the component class.
(1) (2) Symbol (3) Description (4) HIS Instantiation
ℵ
5
AR set of administrative role identifiers {rManager}
ℵ
6
AP set of administrative permission identifiers {modService}
i
7
AUA ⊆ U ×AR user-administrator-relation {
h
drKelso,rManager
i
}
i
8
APA ⊆ AP × AR permission-administrator-relation {
h
modService,rManager
i
}
Again, these ARBAC components add to our exem-
plary model instance as shown in Tab. 2 (column 4).
At last, to describe dynamics of the administrative
operation that re-assigns doctors or nurses, we define
the can assign relation in the URA submodel:
can assign = {
h
rManager,rDoctor,{rDoctor }
i
,
h
rManager,rNurse,{rNurse }
i
}.
This allows any user acting as rManager to assign one
of the ward-specific roles ICU, Card, Mat to any
user with the base role rDoctor or rNurse.
This example already exposes one limitation of the
traditional modeling schemes: While RBAC model
components represent our intended policy semantics
quite well, they do not allow reasoning about dynamic
model properties such as the future evolution of role
assignments and role activations. ARBAC , on the
other hand, only allows us to model a small subset
of possible state changes: Using the can assign rela-
tion, we may restrict role re-assignments through a
certain type of pre-condition. However, as we can
see from the example, richer semantics for both pre-
conditions as well as dynamic protection state changes
are required: These include user operations to login
(activate roles), create new users (new patient EPRs)
or delegate permissions to another user. All of these
cannot be modeled without bending the intended se-
mantics of administrative roles and permissions in the
above ARBAC model.
3.4 DRBAC Modeling Scheme
In the following we discuss a more flexible and
analysis-friendly RBAC modeling scheme, which al-
lows reasoning about dynamic model properties. To
this end, we treat the AC system as a deterministic
automaton, based on the original idea of (Harrison
et al., 1976). The idea of our dynamic RBAC modeling
scheme ( DRBAC) is to combine both primitive model
components established for traditional RBAC models
(see Def. 1 and Example 1) with an automaton-based
modeling scheme that generalizes dynamic behavior.
Beyond Administration: A Modeling Scheme Supporting the Dynamic Analysis of Role-based Access Control Policies
435

Definition 2 (Dynamic AC Model). A dynamic ac-
cess control model is a deterministic automaton de-
fined by a tuple
h
Γ,Σ,∆
i
, where
• the state space Γ is a set of protection states;
• the input set Σ = Σ
C
× Σ
∗
Y
defines possible inputs
that may trigger state transitions, where Σ
C
is a
set of command identifiers used to represent op-
erations a policy may authorize and Σ
Y
is a set of
values that may be used as actual parameters of
commands;
4
• the state transition scheme (STS) ∆ ⊆ Σ
C
× Σ
∗
X
×
Φ × Φ defines state transition pre- and post-
conditions for any input of a command and formal
parameters, where Σ
X
denotes a set of variables to
identify such parameters.
We use Φ to represent the set of boolean expres-
sions in first-order logic (language-agnostic).
For each
h
c,x,φ, φ
0
i
∈ ∆ , a notation borrowed from
the HRU model is used: c(x) ::= PRE : φ ; POST : φ
0
.
We call the boolean term φ the pre-condition (abbre-
viated c.PRE ) and φ
0
the post-condition (abbreviated
c.POST ) of any state transition to be authorized via
command c . On an automaton level, this means that
c.PRE restricts which states γ to legally transition from,
while c.POST defines any differences between γ and
the state γ
0
reachable by any input word
h
c,x
i
. Since
our goal is to reason about possible state transitions,
we require that only such commands are modeled in
∆ that modify their successor state. To distinguish
between the value domains of individual variables
in x , we use a refined definition of Σ
X
to reflect dis-
tinct namespaces of variable identifiers for each model
component. These are denoted by sets X
ℵ
i
so that
S
1≤i≤n
X
ℵ
i
= Σ
X
for a model with n ℵ components.
One may observe that we do not define an output
function for the automaton above. Again, as we are
only interested in the effects of state transitions, not
access decisions, this is not a necessary part of the
modeling scheme. However, for policy-internal autho-
rization rules, we assume a complementary specifica-
tion is used such as a generic access control function
(ACF). For example, for RBAC model components
acf
RBAC
: S × P → {true,false} allows to express if a
permission may be used in a certain session.
Both Def. 1 and 2 describe a configurable modeling
scheme, capable of modeling any type of protection
state change. We again demonstrate its application for
our example scenario.
Example 2. For our exemplary HIS policy, a dy-
namic AC model is defined as follows:
4
We use the Kleene operator to indicate that multiple
parameters may be passed.
Γ = P (U)×P (S)×P (UA)×USER×ROLES , where
γ =

U
γ
,S
γ
,UA
γ
,user
γ
,roles
γ

∈ Γ is a single pro-
tection state,
5
Σ
C
= { createPatient, login, logout, assignDoctor ,
assignNurse, delegateTreatment},
Σ
Y
= U ∪S ∪ R,
Σ
X
= X
U
∪ X
S
∪ X
R
,
∆ is defined by a set of commands as illustrated by
four representative examples in Fig. 2. Their se-
mantics are as follows:
createPatient is intended for creating a new user
eligible for the role rPatient. As per PA , this should be
callable by any user logged in as rReceptionist, which
is the PRE part of the definition. In POST, this user is
created but not already logged in (as this is subject to
the login command). We assume hospital personnel
to be created by similar commands, which assign the
base roles rDoctor or rNurse instead of rPatient.
login is the login command for any specific role.
In this policy, the base roles rDoctor and rNurse
should only serve as assignment prerequisites, i. e. pre-
conditions for modifying UA in terms of the model.
This is why login.PRE checks UA before activating
the intended role for the calling user in a fresh session.
Note that, since our policy explicitly states this, a mere
call of the login operation is unrestricted which is why
we do not need to check acf
RBAC
in PRE.
assignDoctor is one of two commands used to as-
sign (“unlock”) a specific role to a user. That user may
then use login to activate her role. As discussed in
the infomal policy, assign commands may only be
called by users acting in a privileged role (rManager)
allowed to use the modService permission. As an addi-
tional term in PRE, any user assigned a specific doctor-
or nurse-role must be qualified as a doctor or nurse,
respectively – which is modeled by the unassignable,
irrevocable base roles rDoctor and rNurse.
6
delegateTreatment allows any user logged in as a
ward-specific rDoctor to non-permanently delegate
this role to another doctor. Since the latter is only
guaranteed if POST leaves UA untouched, we activate
the delegated role for a specific, running session of the
target user. This specification allows the delegation
to be performed transitively, which is intended by our
HIS application scenario.
5
Note that we define auxiliary base sets for all possible
instances of the mappings user and roles , such as USER =
{user
γ
: S
γ
→ U
γ
|S
γ
⊆ S,U
γ
⊆ U} etc.
6
Technically, this is part of our model constraints which
should be checked as a mandatory pre-condition of every
command. However, since constraints are static in this exam-
ple scenario, we have integrated them in assignDoctor.PRE,
being the only command that may violate them.
SECRYPT 2020 - 17th International Conference on Security and Cryptography
436

I createPatient(s
caller
,u
patient
) ::=
PRE: acf
RBAC
(s
caller
,createRec) ;
POST: U
γ
0
= U
γ
∪ {u
patient
}
∧ UA
γ
0
= UA
γ
∪ {
h
u
patient
,rPatient
i
}
(a)
I login(u
caller
,r
activate
) ::=
PRE:
h
u
caller
,r
activate
i
∈ UA
γ
;
POST: S
γ
0
= S
γ
∪ {s
∗
}
∧ user
γ
0
= user
γ
[s
∗
7→ u
caller
]
∧ roles
γ
0
= roles
γ
[s
∗
7→ {r
activate
}]
(b)
I assignDoctor(s
caller
,u
doctor
,r
ward
) ::=
PRE: acf
RBAC
(s
caller
,modService)
∧
h
u
doctor
,rDoctor
i
∈ UA
γ
∧ r
ward
∈ {rDoctorICU, rDoctorCard,
rDoctorMat} ;
POST: UA
γ
0
= UA
γ
∪ {
h
u
doctor
,r
ward
i
}
(c)
I delegateTreatment(s
caller
,s
deleg
,r
ward
) ::=
PRE: acf
RBAC
(s
caller
,delegTreat)
∧ r
ward
∈ roles
γ
(s
caller
)
∧ u
deleg
= user
γ
(s
deleg
)
∧
h
u
deleg
,rDoctor
i
∈ UA
γ
;
POST: roles
γ
0
= roles
γ
[s
deleg
7→ roles
γ
(s
deleg
)
∪{r
ward
}]
(d)
Figure 2: Exemplary command definitions for the HIS pol-
icy. All non-parameter variables are exists-bound to their
respective ℵ component. We use a superscript asterisk ( ∗ ) to
denote a fresh identifier created by the AC system.
Note that, except for the assign commands, each
of these commands models a non-administrative ac-
cess: creating new patients, logging in (or out) and
delegating permissions are actions that users should
perform as part of their day-to-day workflow rather
than a policy administrator. assign on the other hand
is a typical example for an administrative operation
that needs to be authorized just as a non-administrative
access, which involves PRE checking acf
RBAC
.
When compared to the ARBAC model for this pol-
icy introduced in Example 1, we may also observe that
the administrative operation modeled be the assign
commands precisely matches the pre-conditions ear-
lier defined through the can assign relation. Even
more, it also allows for more fine-grained control over
both PRE and POST, which enables a customized
policy design. This exemplifies how administrative
model components present in ARBAC are supported
by DRBAC without sacrificing expressive power; at
the same time, it eliminates the need to separately de-
fine administration-related model components ℵ
5...6
and i
7...8
.
Usage in Model Engineering. Based on the automa-
ton paradigm from Def. 2, we are able to engineer any
DRBAC model instance similar to RBAC , by fine-
tuning (1.) the expressiveness of the model and (2.) its
degree of dynamics. While the first goal is achieved
by selecting the required primitive model components
from ℵ
1...4
and i
1...6
, the second goal is achieved by
configuring the automaton components Γ , Σ and ∆ . Be-
yond our HIS policy in Example 2, this process can be
generalized for any set of primitive model components.
We therefore conclude this section by demonstrating
how submodels of RBAC96 can be defined in a unified
manner, using DRBAC.
For this, we introduce the notion of potential sets
as an auxiliary formalism.
Definition 3 (Potential Set). The potential set
P
∞
(i) of a primitive model component i is defined
as follows:
1. if i identifies a relation
×
i∈N
A
i
, then P
∞
(i) =
P (
×
i∈N
A
i
);
2. if i identifies a mapping f : A → B , then P
∞
(i) =
{ f : A
0
→ B
0
|A
0
∈ P (A),B
0
∈ P (B)} is a set of all
possible mappings whose domains and codomains
are subsets of A and B, respectively;
3. if i identifies a boolean expression, P
∞
(i) = Φ.
The idea of the potential set is to provide a (pos-
sibly infinite) range of values for the state-specific
instances of dynamic model components. We now ap-
ply this idea to concisely define some configurations
of the classical RBAC model semantics.
Example 3. A completely dynamic DRBAC model
for all RBAC model components is a tuple
h
Γ,Σ,∆
i
where
Γ =
×
4
i=1
P (ℵ
i
) ×
×
6
i=1
P
∞
(i
i
);
Σ = Σ
C
×Σ
∗
Y
, where Σ
C
is a set of application-specific
command identifiers and Σ
Y
=
S
4
i=1
ℵ
i
is a set of
argument values usable for these commands;
∆ ⊆ Σ
C
× Σ
∗
X
× Φ × Φ, where Σ
X
=
S
4
i=1
X
ℵ
i
.
Example 4. A DRBAC model that matches ARBAC
in both expressiveness and degree of dynamics is a
tuple
h
Γ,Σ,∆
i
where
Γ = P (ℵ
2
) ×
×
i
P
∞
(i
i
) for i = 1 ( URA ), or i = 2
(PRA) or i = 5 (RRA);
Σ = Σ
C
× Σ
∗
Y
, where Σ
C
= { can assign, can revoke,
can assignp, can revokep, can assigna,
can revokea, can assigng, can revokeg,
can modify } (administrative commands) and
Σ
Y
= ℵ
2
(role parameter values);
∆ ⊆ Σ
C
× Σ
∗
X
× Φ × Φ , where Σ
X
= X
ℵ
2
(role param-
eter variables).
Note that, according to the motivation of DRBAC ,
Example 4 only considers the dynamic model compo-
nents, while the static components ℵ
{1,3,4}
and i
{3,4,6}
Beyond Administration: A Modeling Scheme Supporting the Dynamic Analysis of Role-based Access Control Policies
437

are still part of the policy. For ARBAC , this is worth
mentioning especially for the model constraints ( i
6
),
which must be checked in PRE for all commands (as
discussed in (Sandhu et al., 1996)).
As these examples illustrate, DRBAC offers a wide
range of model configuration options in both expres-
siveness and degree of dynamics while retaining a
structurally similar model engineering process, based
on a fixed set of once formalized primitive model com-
ponents. This model engineering approach should be
embedded in the MSPE process by tailoring these con-
figuration options to a specific analysis goal, which we
will demonstrate in the next section.
4 MODEL ANALYSIS
In the domain of AC models, a core objective is to
study the potential proliferation of privileges. First for-
malized as the safety property (Harrison et al., 1976),
the following type of questions is addressed: Given
a particular model protection state, is it possible that
some subject ever obtains a specific privilege with
respect to some object? Thus, safety analyses ex-
pose model properties that allow for the prediction
of whether the dynamic changes of an AC system may
lead to an unwanted protection state.
In the previous section, we have presented
DRBAC – a modeling scheme for RBAC policies en-
abling configurable protection state dynamics based on
a deterministic automaton. This section aims to carry
that approach further to the MSPE step of model analy-
sis by developing a safety analysis method for DRBAC
models that can be configured to application-specific
safety analysis goals.
First, we explore a family of safety properties for
DRBAC models (Sec. 4.1) which are tailorable to
application-specific analysis goals. Subsequently, we
present an algorithmic framework for DRBAC model
safety analyses (Sec. 4.2).
4.1 DRBAC Safety Properties
When analyzing dynamic model behavior regarding
safety, we are interested in the effects the dynamic
changes will have on future authorizations. Whether a
given access request is allowed or denied in the current
protection state, is answered by a policy’s interface.
Similar to a model formalizing a policy’s authorization
rules, a policy’s interface is formalized by its access
control function (ACF).
In case of the completely static RBAC model, the
ACF can be defined as follows (based on (Ferraiolo
et al., 2007)).
Definition 4 (RBAC Access Control Function).
The ACF of an RBAC model hU, R,P,S, UA,
PA,user,roles,RH,Constraintsi is a mapping
acf
RBAC
: S × P → {true, false} where
acf
RBAC
(s, p) 7→











true, ∃r, r
0
∈ R,s ∈ S :
h
r,r
0
i
∈ RH ∧
r ∈ roles(s) ∧
hp,r
0
i ∈ PA,
false, else.
The semantics of acf
RBAC
is that the request of
a session s for a permission p (e. g. performing an
operation view on an EPR object) is allowed iff a role
r is activated for s , for which p is assigned to r or a
role r
0
subordinated to r .
7
Thus, the ACF acf
RBAC
precisely reflects an RBAC policy’s access decisions.
In DRBAC models, the semantics of acf
RBAC
stays
the same, however, in contrast to traditional RBAC
models, DRBAC model components are not necessar-
ily static anymore and may change with protection
state transitions. Thus, additional assignments in dy-
namic i components queried within the ACF, e. g. PA ,
roles or RH , may also change its behavior directly
leading to additional privileges and, consequently, to
altered access decisions (granted instead of denied).
Changes in any other dynamic i components, e. g. UA
(assigning a role to a user) and user (performing a
login) only make additional privileges indirectly possi-
ble, thus establish a necessary precondition for that.
Subsequently, we call analysis goals regarding
a single i model component simple safety proper-
ties, whereby we differentiate into level-I and level-II
simple safeties, based on the potential to directly or
indirectly contribute to a proliferation of privileges.
Overall, the following simple safety variants are con-
ceivable, named consistently according to the scheme
“
h
i
i
parameter(s)
i
-
h
i
i
name
i
”:
•
h
u
i
-,
h
r
i
- and
h
u,r
i
-UA-safety,
•
h
p
i
-,
h
r
i
- and
h
p,r
i
-PA-safety,
•
h
s
i
-,
h
u
i
- and
h
s,u
i
-user-safety,
•
h
s
i
-,
h
r
i
- and
h
s,r
i
-roles-safety,
•
h
·,r
i
-,
h
r,·
i
- and
h
r,r
0
i
-RH-safety.
8,9
7
Because of the reflexivity property of the partial order
RH (see Sec. 3.3), it is correct to assume a role r
0
that is
checked against PA , even in case there is no other role r
senior to.
8
Since sessions are typically created and assigned some-
time during an AC system’s runtime, note that
h
s
i
-,
h
s,u
i
-,
h
s
i
- and
h
s,r
i
-safety properties only make sense if the model
contains a pre-initialized subset of session elements to which
these session parameters refer to.
9
In order to differenciate between safety regarding the
superordination or subordination of roles in RH , “ · ” denotes
an empty placeholder.
SECRYPT 2020 - 17th International Conference on Security and Cryptography
438

Moreover, simple safeties can be composed, such
that multiple dynamic i components are taken into ac-
count. We refer to these properties as composed safety
properties and name them straight-forward based on
the composed safeties’ names, such that for exam-
ple,
h
u
i
- user -
h
r
i
- roles -safety is composed of
h
u
i
- user -
safety and
h
r
i
-roles-safety properties.
Complementary to this classification, safety proper-
ties can be concretized to application-specific analysis
goals by specifying parameter values (e. g. a user, role,
permission or session) of ℵ components related to the
safety-relevant i components.
In the remaining part of this section, we discuss
a selection of classified safety properties which are
relevant to the modeled HIS security policy from
Sec. 3.2 demonstrating the approach to tailor DRBAC
safety properties for an analysis scenario of a particular
application-specific security policy.
Example 5 (Tailoring DRBAC Safety Analysis
Goals). Given the examplary HIS DRBAC model
from Example 2. We consider the following analysis
question: Since in the HIS security policy it is assumed
that doctors may temporarily delegate treatment capa-
bilities (ward-specific doctor roles such as rDoctorICU,
rDoctorCard, or rDoctorMat), is it ever possible, that
a doctor is being assigned to at least two ward-specific
doctor roles and capable of using those roles actively
in some session, and thereby permanently maintains
their actually separated privileges?
The analysis goal informally described above ac-
tually targets two formal model components defined
as dynamic: The UA relation, in which the permanent
assignment of a ward-specific doctor role establishes
a necessary precondition, and the roles function, in
which the activation directly makes the role’s privi-
leges usable in a particular session. Thus, starting
point for the formal description of the analysis goal is
the level-II simple safety regarding UA called
h
r
i
- UA -
safety, which considers for a given role r whether r is
ever assigned to some user u.
Definition 5 (
h
r
i
-UA-Safety). A DRBAC model
h
Γ,Σ,∆
i
is
h
r
i
- UA -safe w. r. t. a state γ and a role
r ∈ R
[γ]
∗
iff there is no input sequence σ
1
... σ
n
∈ Σ
∗
that, starting with γ leads to γ
0
via ∆ , such that ∃u ∈
U
[γ]
∗
∩U
[γ
0
]
∗
:
h
u,r
i
∈ UA
γ
0
whereas
h
u,r
i
/∈ UA
γ
.
10
The dynamics of roles allow privileges to be pro-
liferated directly (through the activation of roles in
a session). These dynamics motivate a level-I safety
property regarding roles and a role r , to investigate
10
Using the regular expression [γ]
∗
, R
[γ]
∗
and U
[γ]
∗
describe
either static sets R and U or, if they are part of the state space,
dynamically changing sets R
γ
and U
γ
.
whether, based on a particular model state, a role such
as rDoctorICU can be activated in some session. We
define this property as the
h
r
i
-roles-safety as follows.
Definition 6 (
h
r
i
-roles-Safety). A DRBAC model
h
Γ,Σ,∆
i
is
h
r
i
- roles -safe w. r. t. a state γ and a role
r ∈ R
[γ]
∗
iff there is no input sequence σ
1
... σ
n
∈ Σ
∗
that, starting with γ leads to γ
0
via ∆ , such that ∃s
0
∈
S
[γ
0
]
∗
: r ∈ roles
γ
0
(s
0
) whereas @s ∈ S
[γ]
∗
: r ∈ roles
γ
(s).
The definitions so far only considered a single com-
ponent isolated and, thus, are rather limited in terms
of expressiveness. Since we target a single safety def-
inition which takes both model components, UA and
roles , into account, we define the composed safety
property called
h
r
i
-UA-
h
r
i
-roles-safety as follows.
Definition 7 (
h
r
i
-UA-
h
r
i
-roles-Safety). A DRBAC
model
h
Γ,Σ,∆
i
is
h
r
i
- UA -
h
r
i
- roles -safe w. r. t. a state
γ and a role r ∈ R
[γ]
∗
iff there is no input sequence
σ
1
... σ
n
∈ Σ
∗
that, starting at γ , leads to γ
0
via ∆ , such
that ∃u ∈ U
[γ]
∗
∩ U
[γ
0
]
∗
,∃s
0
∈ S
[γ
0
]
∗
,u = user
[γ
0
]
∗
(s
0
) :
h
u,r
i
∈ UA
γ
0
∧ r ∈ roles
γ
0
(s
0
) whereas @s ∈ S
[γ]
∗
,u =
user
[γ]
∗
(s):
h
u,r
i
/∈ UA
γ
∧ r ∈ roles
γ
(s).
Finally, we can now formally concretize our
analysis goal, which was informally established at
the beginning, as
h
r
i
- UA -
h
r
i
- roles -safety with r ∈
{rDoctorICU,rDoctorCard,rDoctorMat}.
4.2 DRBAC Safety Analysis
In the previous section we discussed, given a DRBAC
model and an informal safety analysis question, how
model-specific safety properties can be derived and
formally specified. The purpose of this section is to lay
the algorithmic foundations for an automated analysis
of DRBAC safety properties and then, using the HIS
DRBAC model as an example, to show how analysis
results can be applied by policy engineers to correct
model errors.
Heuristic-driven Safety Analysis. As has been
proven for the seminal HRU model (Harrison et al.,
1976), decidable safety properties require the restric-
tion of a model’s computational power. Since such
restrictions reflect the semantical needs of application-
specific policies which usually differ from each other,
the corresponding analysis algorithms are also specific
to these models. Consequently, new models require
analysis algorithms to be built from scratch.
In contrast, our previous work aims at a common
generalization of safety analysis algorithms for dy-
namic AC models based on deterministic automatons
(K
¨
uhnhauser and P
¨
olck, 2011; Amthor et al., 2013;
Amthor, 2016; Amthor, 2017). Instead of restricting a
Beyond Administration: A Modeling Scheme Supporting the Dynamic Analysis of Role-based Access Control Policies
439

In: ∆ . . . state transition scheme
γ
0
. . . state to be analyzed
target . . . unsafety target
Out: stateSeq . . . states sequence leaking target
1 γ ← γ
0
; stateSeq ← γ;
2 CDG ← CDGAssembly(∆, γ, target);
3 repeat
4 inputSeq ← generateInput(CDG, γ);
5 while σ ← inputSeq.next do
6 γ
0
← transition(γ, σ,∆);
7 stateSeq ← stateSeq ◦γ
0
;
8 γ ← γ
0
;
9 until isUnsafe(γ
0
,γ
0
,target);
10 return seq;
Algorithm 1: DEPSEARCH.
model’s expressive power to achieve safety decidablity,
our approach accepts the impossibility of confirming
model to be safe. We choose to trade accuracy for
tractability: by performing a heuristic-driven simula-
tion of a dynamic AC model, unsafe model states may
be found (given such exist), while the termination of
the algorithm cannot be guaranteed.
Heuristic safety analysis algorithms exploit the
semi-decidablity of the problem: Given two model pro-
tection states with one state being some follow-up state
of the other, it is efficiently decidable whether in the
follow-up state a proliferation can be observed. Thus,
starting with some state γ , heuristic search algorithms
guide a model through its state space by generating
input sequences, feeding them into the automaton and
checking for each reached state γ
0
whether it renders
state γ unsafe. A successful heuristic must therefore
maximize the propability of an input to contribute to a
path from γ to γ
target
.
Our most promising heuristic for the safety anal-
ysis of dynamic automaton-based AC models is
DEPSEARCH (dependency search) (Amthor et al.,
2013). Based on the insight that in the most diffi-
cult case, privilege proliferation in a dynamic model
occur only after specific state transition sequences
where each command executed depends exactly on the
execution of its predecessor, DEPSEARCH explicitly
searches for such dependencies and executes corre-
sponding input sequences. Given the termination of
the analysis algorithm and that unsafe states are found,
the analysis results provide valuable hints on model
correctness and policy engineers are pointed to input
sequences that lead to such states.
In the following, we adapt the approach of heuris-
tic safety analysis for DRBAC models and discuss a
DRBAC-tailored descendant of DEPSEARCH.
The DEPSEARCH Algorithm for DRBAC. We de-
veloped the DEPSEARCH heuristic based on the ob-
servation of sequences of interdependent commands
leading to proliferations of privileges. Hence, we de-
rived the idea of a two-phases algorithm: First, a static
analysis of inter-command dependencies is performed;
a subsequent, dynamic analysis consists of state space
exploration by simulating the automaton’s behavior.
We will discuss these phases on an informal basis, for
an in-depth discussion and evaluation of DEPSEARCH
for the HRU model see (Amthor et al., 2013; Amthor
et al., 2014). The generic base algorithm is presented
in Alg. 1.
During the first phase (cf. Alg. 1, line 2 ), a static
analysis of the model’s state transition scheme ∆ is
performed. It yields a graph-based description of inter-
command dependencies, constituted by adding (as a
part of POST) and requiring (as a part of PRE) the
same element (e. g.
h
u
doctor
,rDoctorCard
i
in UA ) in
two different commands. As a result of the static
analysis, these dependencies are modeled by a com-
mand dependency graph (CDG)
h
V,E
i
where nodes
v ∈ V represent commands, and an edge
h
c
1
,c
2
i
de-
notes that a post-condition of c
1
matches at least one
pre-condition of c
2
.
The CDG can be assembled in a way that all paths
from vertices without incoming edges to vertices with-
out outgoing edges indicate input sequences for reach-
ing γ
target
from γ . To achieve this, two virtual com-
mands c
γ
and c
target
are generated: c
γ
is the source of
all paths in the CDG, since it represents the state γ to
analyze in terms of a command specification added to
∆ . It is generated by encoding the dynamic i com-
ponents in POST(c
γ
) . In a similar manner, c
target
is
the sink of all paths in the CDG, which represents all
possible states γ
target
by checking the presence of the
target elements in the safety-relevant i component
according to the safety definition in PRE(c
target
).
In the second, dynamic analysis phase (cf. Alg. 1,
lines 3 – 9 ), the CDG is used to guide dynamic state tran-
sitions by generating input sequences to the automaton.
The commands involved in each sequence are chosen
according to different paths from c
γ
and c
target
, which
in turn determine the direction of state space explo-
ration. Paths in the CDG are generated based on a
simple ant algorithm: with each edge traversed to gen-
erate an input sequence, the algorithm increases an
edge weight “scent” which has repellent effect for the
next iteration of the CDG traversal, thus effectively
leading to a full path coverage and potentially maximal
chances for actually generating a proliferation.
DEPSEARCH successively generates input se-
quences by traversing the CDG on every possible path
and in turn parameterizing the emerging sequence of
SECRYPT 2020 - 17th International Conference on Security and Cryptography
440

In: γ =

U
γ
,S
γ
,UA
γ
,user
γ
,roles
γ

. . . state to
be analyzed
γ
0
=

U
γ
0
,S
γ
0
,UA
γ
0
,user
γ
0
,roles
γ
0

. . .
state to check for unsafety
target =

r
target

. . . target role
Out: true iff γ is
h
r
i
-UA-
h
r
i
-roles-unsafe
w. r. t. r, false else
1 sExists ← false;
2 for u ∈ U
γ
∩U
γ
0
do
3 for s
0
∈ {st
0
∈ S
γ
0
|u = user
γ
0
(st
0
)} do
4 if

u,r
target

∈ UA
γ
0
∧
r
target
∈ roles
γ
0
(s
0
) then
5 for s ∈ {st ∈ S
γ
|u = user
γ
(st)} do
6 if r
target
∈ roles
γ
(s) then
7 sExists ← true;
8 if

u,r
target

/∈ UA
γ
∧
sExists = false then
9 return true;
10 return false;
Algorithm 2: isUnsafe.
commands with values from Σ
Y
. Each effected state
transition is simulated by the algorithm, and once a
CDG path is completed, the validity of the unsafety-
criteria is checked.
The corresponding algorithm used is directly tai-
lored to the unsafety-criterion for the particular analy-
sis. As an example, Alg. 2 represents the
h
r
i
- UA -
h
r
i
-
roles-unsafety which is defined as follows.
Definition 8 (
h
r
i
-UA-
h
r
i
-roles-Unsafety). A
DRBAC model
h
Γ,Σ,∆
i
is
h
r
i
- UA -
h
r
i
- roles -unsafe
w. r. t. a state γ and a role r ∈ R
[γ]
∗
iff there is an input
sequence σ
1
... σ
n
∈ Σ
∗
that, starting at γ , leads to γ
0
via ∆ , such that ∃u ∈ U
[γ]
∗
∩ U
[γ
0
]
∗
,∃s
0
∈ S
[γ
0
]
∗
,u =
user
[γ
0
]
∗
(s
0
) :
h
u,r
i
∈ UA
γ
0
∧ r ∈ roles
γ
0
(s
0
) whereas
@s ∈ S
[γ]
∗
,u = user
[γ]
∗
(s):
h
u,r
i
/∈ UA
γ
∧ r ∈ roles
γ
(s).
Interpretation of Analysis Results. We now ap-
ply the DEPSEARCH heuristic for the analysis of
the HIS DRBAC model (see Example 2) with re-
gards to
h
r
i
- UA -
h
r
i
- roles -safety checking for the cor-
responding unsafety-criterion. In order to keep the
algorithm comprehensible and to avoid the problem
of dynamic dependencies of command parameters
(Amthor and Rabe, 2020), wherever a parameter is
passed as a parameter is passed to a dynamic, safety-
relevant model component (e. g. r
ward
in the com-
mand assignDoctor), the respective command defini-
tion is treated like a macro. This requires that the
command be expanded in terms of acceptable val-
ues. For example, the command assignDoctor expands
for r
ward
∈ {rDoctorICU,rDoctorCard,rDoctorMat}
to assignDoctorICU, assignDoctorCard, assignDoc-
torMat).
Then, the execution of DEPSEARCH results in
the following sequence of inputs and state transitions,
which leads to a violation of the examined safety.
1. (γ
0
→ γ
1
) loginManager(drKelso)
2. (γ
1
→ γ
2
) assignDoctorICU(s ∈ S
γ
: drKelso =
user
γ
(s), drJD)
3. (γ
2
→ γ
3
) assignDoctorCard(s ∈ S
γ
: drKelso =
user
γ
(s), drJD)
4. (γ
3
→ γ
4
) loginDoctorICU(drJD)
5. (γ
4
→ γ
5
) loginDoctorCard(drCox)
6. (γ
5
→ γ
6
) delegateTreatmentDoctorCard(s ∈ S
γ
:
drCox = user
γ
(s), s ∈ S
γ
: drJD =
user
γ
(s), rDoctorCard)
According to the MSPE process, the error be sub-
ject to correction of the model by a qualified policy
engineer. To ensure that, at any given point in time,
only a single ward-specific doctor role is permanently
associated with each doctor user, the PRE part of the
assignDoctor command would have to check whether
a user associated with a ward-specific doctor role al-
ready has such a role. This can be achieved by adding
a condition of the following kind:
∀r ∈ {rDoctorICU, rDoctorCard,rDoctorMat} :

u
doctor
,r /∈ UA
γ

.
Alternatively, in the POST part of the assignDoctor
command, the already associated ward-specific doc-
tor role could be de-associated, and, if activated in
any of that user’s sessions, the “former” ward doctor
role must be deactivated and the “new” ward doctor
role be activated. Since this kind of proliferation can
also occur in the command assignNurse, an analogous
correction is necessary.
5 CONCLUSIONS
This paper presents DRBAC , a modeling scheme for
RBAC policies supporting their safety analysis by
protection state dynamics tailorable to a plethora of
application-specific safety analysis goals. We demon-
strate the potential of our approach based on an exem-
plary healthcare information system security policy.
By supporting both policy specification and analy-
sis, we consider our approach as a step towards stream-
lining the process of model-based security policy engi-
neering. Future work will apply this approach to the
Beyond Administration: A Modeling Scheme Supporting the Dynamic Analysis of Role-based Access Control Policies
441

more generalized class of ABAC policies. To extend
our approach even further to the step of model im-
plementation, ongoing work focuses on the compiler-
automated translation of model specifications into
source code, and secure runtime environments for rig-
orously enforcing embedded policies within operating
system and application security architecture implemen-
tations.
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. (2017). Efficient Heuristic Safety Analysis of
Core-based Security Policies. In Proc. 14th Int. Conf.
on Secur. and Cryptogr., pages 384–392.
Amthor, P., K
¨
uhnhauser, W. E., and P
¨
olck, A. (2013). Heuris-
tic Safety Analysis of Access Control Models. In Proc.
18th ACM Symp. on Access Control Models and Tech-
nol., pages 137–148.
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.
Amthor, P. and Rabe, M. (2020). Command Dependencies
in Heuristic Safety Analysis of Access Control Models.
In Found. and Practice of Secur., vol. 12056 of LNCS,
pages 207–224.
Barker, S. (2009). The Next 700 Access Control Models or
a Unifying Meta-Model? In Proc. 14th ACM Symp. on
Access Control Models and Technol., pages 187–196.
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.
Calzavara, S., Rabitti, A., and Bugliesi, M. (2015). Compo-
sitional Typed Analysis of ARBAC Policies. In Proc.
IEEE 28th Comp. Secur. Found. Symp., pages 33–45.
Chakraborty, S., Sandhu, R., and Krishnan, R. (2020). On
the Feasibility of RBAC to ABAC Policy Mining: A
Formal Analysis. In Proc. 8th Int. Conf. on Sec. Knowl.
Managem. in Artific. Intell. Era, pages 147–163.
Dinh, K. K. Q., Tran, T. D., and Truong, A. (2017). Security
Analysis of Administrative Role-Based Access Control
Policies with Contextual Information. In Proc. 4th Int.
Conf. on Future Data and Secur. Eng., vol. 10646 of
LNCS, pages 243–261.
Fern
´
andez, M., Mackie, I., and Thuraisingham, B. (2019).
Specification and Analysis of ABAC Policies via the
Category-Based Metamodel. In Proc. 9th ACM Conf.
on Data and App. Secur. and Priv., pages 173–184.
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.
Jayaraman, K., Tripunitara, M., Ganesh, V., Rinard, M., and
Chapin, S. (2013). MOHAWK: Abstraction-Refinement
and Bound-Estimation for Verifying Access Control
Policies. ACM Trans. on Inform. and Syst. Secur.,
15(4):18:1–18:28.
Jha, S., Li, N., Tripunitara, M., Wang, Q., and Winsborough,
W. (2008). Towards Formal Verification of Role-Based
Access Control Policies. IEEE Trans. on Depend. Se-
cure Comp., 5:242–255.
Jin, X., Krishnan, R., and Sandhu, R. (2012a). A Unified
Attribute-Based Access Control Model Covering DAC,
MAC and RBAC. In Proc. 26th Ann. IFIP WG 11.3
Conf. on Data and App. Secur. and Priv., vol. 7371 of
LNCS, pages 41–55.
Jin, X., Sandhu, R., and Krishnan, R. (2012b). RABAC:
Role-Centric Attribute-Based Access Control In Proc.
6th Int. Conf. on Math. Methods, Models and Arch. for
Comp. Netw. Secur., vol. 7531 of LNCS, pages 84–96.
K
¨
uhnhauser, W. E. and P
¨
olck, A. (2011). Towards Access
Control Model Engineering. In Proc. 7th Int. Conf. on
Inform. Syst. Secur., pages 379–382.
Li, N. and Tripunitara, M. V. (2006). Security Analysis in
Role-Based Access Control. ACM Trans. on Inform.
and Syst. Secur., 9(4):391–420.
P
¨
olck, A. (2014). Small TCBs of Policy-controlled Operating
Systems. Universit
¨
atsverlag Ilmenau.
Ranise, S., Truong, A., and Armando, A. (2014). Scal-
able and Precise Automated Analysis of Administrative
Temporal Role-Based Access Control. In Proc. 19th
ACM Symp. on Access Control Models and Technol.,
pages 103–114.
Sandhu, R., Bhamidipati, V., and Munawer, Q. (1999). The
ARBAC97 Model for Role-based Administration of
Roles. ACM Trans. on Inf. Syst. Secur., 2(1):105–135.
Sandhu, R., Ferraiolo, D., and Kuhn, R. (2000). The NIST
Model for Role-Based Access Control: Towards a Uni-
fied Standard. In Proc. 5th ACM Workshop on Role-
Based Access Control, pages 47–63.
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.
Shahen, J., Niu, J., and Tripunitara, M. (2015). Mohawk+T:
Efficient Analysis of Administrative Temporal Role-
Based Access Control (ATRBAC) Policies. In Proc.
20th ACM Symp. on Access Control Models and Tech-
nol., pages 15–26.
Stoller, S. D., Yang, P., Gofman, M., and Ramakrishnan,
C. R. (2011). Symbolic Reachability Analysis for
Parameterized Administrative Role Based Access Con-
trol. Comp. & Secur., 30(2-3):148–164.
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. Comp. & Comm. Secur., pages 445–455.
Tripunitara, M. V. and Li, N. (2007). A Theory for Compar-
ing the Expressive Power of Access Control Models.
Jour. of Comp. Secur., 15(2):231–272.
Vimercati, S. D. C. d., Samarati, P., and Jajodia, S. (2005).
Policies, Models, and Languages for Access Control.
In Proc. 4th Int. Conf. on Databases in Networked
Inform. Syst., vol. 3433/2005 of LNCS, pages 225–237.
SECRYPT 2020 - 17th International Conference on Security and Cryptography
442