The Missing Piece of the ABAC Puzzle:

A Modeling Scheme for Dynamic Analysis

Marius Schlegel

and Peter Amthor

Technische Universit

at Ilmenau, Germany

Keywords:

Security Engineering, Security Policies, Attribute-based Access Control Models, ABAC, Security Models,

Reachability Property, Dynamic Analysis, Heuristic Safety Analysis, Formal Methods.

Abstract:

Attribute-based access control (ABAC) has made its way into the mainstream of engineering secure IT systems.

At the same time, ABAC models are still lagging behind well-understood, yet more basic access control models

in terms of dynamic analyzability. This has led to a plethora of methods, languages, and tools for designing and

integrating ABAC policies, but only few to formally reason about them in the process. We present DABAC, a

modeling scheme to pick up that missing piece and put it right into its place in the security engineering workﬂow.

Based on an automaton calculus, we demonstrate how DABAC can be leveraged as a holistic formal basis for

engineering ABAC models, analyzing their dynamic properties, and providing a functional speciﬁcation for

their implementation. This sets the stage for comprehensive tool support in building future ABAC systems.

1 INTRODUCTION

Attribute-based access control (ABAC) has established

as the de-facto paradigm for AC models (Jin et al.,

2012; Hu et al., 2014; Ferraiolo et al., 2016; Fern

andez

et al., 2019). ABAC solves a number of issues of popu-

lar models regarding expressiveness, granularity, scal-

ability (cf. role explosion in large-scale RBAC mod-

els), and context-awareness. Authorizations depend

on user, object, and environment attributes involved

in access requests; decisions may change if attribute

values change. This makes ABAC suitable for a broad

range of different application scenarios, such as grid

computing (Lang et al., 2009), IoT (Bhatt and Sandhu,

2020), as well as large and distributed information

systems (Mukherjee et al., 2017).

However, this ﬂexibility also imposes challenges:

Modeling, speciﬁcation, analysis, and implementation

of ABAC policies are not trivial. In order to lower

the hurdles for using ABAC, the AC community con-

tributed many important pieces to this comprehensive

and complex puzzle: Specialized policy engineering

and mining approaches (Narouei et al., 2017; Xu and

Stoller, 2015), the NIST standardization (Hu et al.,

2014), modeling schemes (also called meta-models

in the literature) (Jin et al., 2012; Fern

andez et al.,

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

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

2019; Bertolissi et al., 2020) as well as numerous

application-speciﬁc ABAC models form a compre-

hensive framework for modeling ABAC policies. In

addition, XACML and NGAC provide support for the

speciﬁcation of ABAC policies and security architec-

tures for their enforcement (Ferraiolo et al., 2016).

Since security policies implement an AC system’s

security requirements, their correctness is highly crit-

ical. A modern approach for policy engineering

founded on formal methods is model-based security

policy engineering (MSPE) (Vimercati et al., 2005;

Tripunitara and Li, 2007; Basin et al., 2011). As a

specialization of generic software engineering, MSPE

is divided into three steps: (1.) in model engineer-

ing, a model as a formal policy representation and its

correctness conditions (model properties) are deﬁned;

(2.) during model analysis, formal methods are applied

to verify the former against the latter; (3.) ﬁnally, in

model implementation, the model veriﬁed so far is

translated into actual code for implementation.

Decades of experience and best practices have yielded

modeling schemes: formal toolboxes of predicates,

set-theoretical expressions, automata theory etc., that

support engineers in choosing model formalisms suit-

able for policy speciﬁcation and implementation as

well as the analysis of correctness properties, e. g. for

ABAC (Ahmed and Sandhu, 2017; Jha et al., 2019;

Marin et al., 2019). Probably one of the most funda-

mental and challenging properties are dynamic state

234

Schlegel, M. and Amthor, P.

The Missing Piece of the ABAC Puzzle: A Modeling Scheme for Dynamic Analysis.

DOI: 10.5220/0010556202340246

In Proceedings of the 18th International Conference on Security and Cryptography (SECRYPT 2021), pages 234-246

ISBN: 978-989-758-524-1

reachability properties which can be used to forsee

privilege escalation vulnerabilities of a policy (also

known as safety). Generally, those properties require

dynamic analyses which are pestered by computational

complexity (Tripunitara and Li, 2007). Moreover, such

properties need to be (re-)deﬁned for any application-

speciﬁc model. Since this is a burdensome and error-

prone task, previous research efforts in the AC commu-

nity have focused on more specialized analysis ques-

tions towards the effect of policy administration, rather

than those of more general day-to-day accesses per-

formed by users (Bertolissi et al., 2020).

We aim at contributing to these efforts with a fo-

cus on two sub-problems of the former: experience

teaches us that (1.) dynamic changes in an AC sys-

tem may arise from both administrative operations and

user operations; (2.) generally, interesting dynamic

properties that should be subject to model analysis

queries tend to be undecidable (cf. safety). The main

contribution of this paper is DABAC – a modeling

scheme, that (1.) models protection state dynamics

in an automaton-based formalism, which enables the

analysis of undecidable model properties and unlocks

ABAC models for a broad range of existing model

analysis approaches which have been developed for the

class of automaton-based AC models; (2.) while pre-

serving the expressiveness of state-of-the-art ABAC

models already pursuing a future formal standard.

The paper is organized as follows: After giving an

overview of related work in

2, we present our

DABAC modeling scheme and ready-made patterns

for deﬁning privilege escalation (safety) properties in

3. In

4, we discuss the application of DABAC to an

IoT healthcare scenario following an MSPE workﬂow

consisting of model engineering and analysis.

2 RELATED WORK

This section reviews related work in modeling schemes

for ABAC policies. We will summarize them in con-

text of the goals of DABAC. For a more technical com-

parison with ABAC

and C-ABAC, refer to § 3.2.4.

ABAC

(Jin et al., 2012).

The original motivation

of ABAC

is to demonstrate how a semantically min-

imal ABAC modeling scheme can be used to sub-

sume the traditional AC model paradigms of identity-

based AC, multi-level security, and RBAC. However,

ABAC

was also found useful as an ABAC formalism

for practical model engineering and safety analyses

(cf. (Ahmed and Sandhu, 2017)). Due to the deliberate

restriction of model semantics to the necessary mini-

mum, ABAC

provides many predeﬁned abstractions

for typical policies from the above-mentioned families,

however without aiming at the full range of highly

diverse ABAC applications and their AC policies.

CBAC (Barker, 2009).

Being a widely recognized

calculus to generalize arbitrary AC models, CBAC

takes a different approach than ABAC

. The model-

ing scheme is based on a highly abstract, axiomatic

concept of categorized entities and their relationships,

that can be used to represent attributes and attribution

mechanisms of an ABAC policy. Because of its high

degree of abstraction, CBAC imposes a signiﬁcant se-

mantical gap to both model engineering and model im-

plementation. With a strong focus on the MSPE work-

ﬂow, we choose to represent ABAC policies closer to

their functional semantics instead; however, parts of

our terminology are based on the commonly adopted

terms of CBAC abstractions.

C-ABAC (Fern

andez et al., 2019).

C-ABAC is an

ABAC modeling scheme that results from an appli-

cation of CBAC to ABAC policies. C-ABAC and

DABAC both adopt the idea of environmental informa-

tion as often required by ABAC applications. Even be-

yond, both modeling schemes aim at generality, which

results in a comparable expressive power with one

exception: other than DABAC, C-ABAC explicitly

excludes dynamic protection state changes from the

modeled semantics. Using the same formal abstrac-

tions as CBAC, the latter serves as a solid foundation

to verify static model properties rather than to enable

dynamic analysis and functional policy speciﬁcation.

Admin-CBAC (Bertolissi et al., 2020).

Admin-

CBAC reuses C-ABAC abstractions to model dynam-

ics, based on the use case of AC system administration.

This enables analyses of reachability properties that

allows to reason about safety (amongst others). How-

ever, as the authors note, Admin-CBAC deliberately

restricts model analysis to decidable instances of these

properties (Bertolissi et al., 2020, Abstract). With the

aim to serve as a basis for both simulative and heuristic

methods that address exactly this gap in model anal-

ysis, DABAC departs the axiomatic approach from

CBAC, C-ABAC, and Admin-CBAC in favor of an

automaton-based modeling scheme. Moreover, instead

of separating administrative from non-administrative

models through different modeling schemes, we opted

for integrating any administrative dynamics with such

from regular user operations. As mentioned, this po-

tentially results in more complex (up to undecidable)

dynamic properties to analyze, but allows for a more

holistic view on the modeled policy on the other hand.

The Missing Piece of the ABAC Puzzle: A Modeling Scheme for Dynamic Analysis

235

We have motivated and discussed this paradigm in pre-

vious work on RBAC (Schlegel and Amthor, 2020).

3 MODELING SCHEME

This section presents DABAC, a formal ABAC mod-

eling scheme suitable for simulative model analysis,

and, based on their results, iterative model reﬁnement

as part of the MSPE workﬂow. We start by analyzing

the requirements (

3.1), then address the individual

abstraction levels deﬁned by the modeling scheme

(

3.2): its primitive models components (

3.2.1), its

deﬁnition of model dynamics (

3.2.2), and its design

space for deﬁning model safety (

3.2.3). Finally, we

discuss the expressive power of DABAC (§ 3.2.4).

3.1 Requirements

ABAC Expressiveness.

From an ABAC applica-

tion’s perspective, we require any modeling scheme to

be both sufﬁciently expressive and usable in a stream-

lined manner to express typical ABAC policies from

real-world scenarios, such as in the application do-

mains of vehicle networks (Gupta et al., 2020), cloud

and edge computing (Bhatt and Sandhu, 2020), or hos-

pital information systems (Ray et al., 2017; Mukher-

jee et al., 2017). More speciﬁcally, this means that

a DABAC model should be capable of expressing an

ABAC feature typical for the above-mentioned, usually

distributed, application scenarios: the need to evalu-

ate both an internal state of the AC system as well as

external information for making an access decision.

Typical examples for this, also called environmental

information in the literature (Barker, 2009; Fern

andez

et al., 2019), are notiﬁcations from third-party systems,

sensor values that depend on physical conditions, or

threat information for risk management. These can

be observed from external sources, and thus need to

be modeled as distinct entities, attributes and attribute

values, respectively. While such information might

be used in access decisions, an AC system has no

inﬂuence on their possible changes.

Model Engineering.

Flexibility of modeling ab-

stractions is a key requirement to support the MSPE

core concept of reiterative model reﬁnement. For mod-

eling ABAC policies, this primarily relates to abstrac-

tions for attribution and attribute evaluation. In this

regard, DABAC should support (1.) indirect attribu-

tion (attributes which are themselves subject to attribu-

tion, i. e. role attributes in parameterized RBAC models

(Stoller et al., 2009)), and (2.) both enumeration-based

and formula-based attribute evaluation (Biswas et al.,

2016). It should be noted that this ﬂexibility is al-

ready required by the MSPE core concept of reitera-

tive model reﬁnement, based on both reﬁned policy

requirements (as part of model engineering) and re-

vised policy rules (as an outcome of model analysis).

Model Analysis.

To reason about dynamic proper-

ties of ABAC policies, we settle for a family of heuris-

tic algorithms that simulate dynamic model behavior,

which allow to study undecidable safety-properties

(Amthor et al., 2014). We therefore require an au-

tomaton calculus, which has been successfully used

for this purpose in previous work (Amthor et al.,

2013; Amthor, 2017; Schlegel and K

uhnhauser, 2020).

Based on this calculus, DABAC should be able to sup-

port custom, policy-speciﬁc safety deﬁnitions by using

the model’s abstractions. Similar to how ABAC gen-

eralizes RBAC, this enables reusing previous work on

safety analysis methods for dynamic RBAC models

(Schlegel and Amthor, 2020).

Model Implementation.

As a last requirement, sec-

ond to their beneﬁts in model analysis, DABAC mod-

els should be re-usable as a formal speciﬁcation for

implementing the actual AC system. This means that,

based on model abstractions, a functional speciﬁca-

tion of interface, internal state and possibly external

state of the AC system should be possible. This lowers

semantical hurdles towards planned semi-automatic

implementation of policy decision making and even

runtime monitoring of policy invariants, both parts of

future work (cf. § 5).

3.2 DABAC

As a modeling scheme rather than a speciﬁc model in

itself, DABAC deﬁnes how a speciﬁc ABAC policy

should be formalized. This happens on three semanti-

cal levels of abstraction:

Primitive Model Components: provide formal arti-

facts to express a policy’s complete authorization

semantics, which are based on families for

•

sets of elementary identiﬁers to express entities

and attribute values;

•

their interrelations, formalized as relations, map-

pings, or boolean expressions, to express attri-

bution as well as authorization rules.

Model Dynamics: rely on the idea of a specialized

automaton model

Γ, Σ, ∆, Perm

consisting of

• the state space Γ: a set of protection states;

•

the input set

: a set of possible inputs that may

trigger state transitions, based on parameterized

operations made available by the AC system;

SECRYPT 2021 - 18th International Conference on Security and Cryptography

236

•

the state transition scheme (STS)

∆ ⊆ Σ ×

P (Perm) × Φ

: state transition pre- and post-

conditions for any input σ ∈ Σ;

•

the permissions set

Perm

: set of identiﬁers for

ﬁne-grained access conditions.

The safety property as a formal deﬁnition of our

analysis question the model should be checked

against according to our requirements.

It should be noted that during practical model engineer-

ing, these levels of abstractions might be addressed

in sequence, but due to their semantical interrelations

(e. g. a safety property depending on both primitive

model components and state deﬁnition), they are inher-

ently subject to iterative model engineering. In favor

of a concise discussion however, we will now address

these three levels in sequence.

3.2.1 Primitive Model Components

To make an authorization decision, any ABAC policy

most generally demands three classes of information:

which entities are involved in an access, which at-

tributes are associated with these entities, and which

access rules should be evaluated to authorize any op-

eration. DABAC covers these information in four

families for each primitive model component. In the

following, we will informally introduce these families,

which are formally deﬁned in Tab. 1.

Entities (EN):

a set of identiﬁers for atomic abstrac-

tions immediately involved in an access, either

actively or passively (such as users, principals, ap-

plications, sessions, devices);

Attribute Values (AV):

a set of identiﬁers that are

evaluated in access rules (such as age of a user,

Attribute Association (AA):

a mapping from either

an EN or an AV to either an AV (attribution with

a single value) or its power set (attribution with

multiple values);

Access Rule (AR):

a set containing a logical formula

or an attribute enumeration for each permission in

Perm

, which decides for a vector of AV elements

as arguments if entities attributed with these values

are authorized for that respective permission.

We assume any sets of identiﬁers to be countable but

possibly inﬁnite. For unambiguity, we use the follow-

ing conventions for notation: In a formal context, we

denote the sets representing these families by their

italic symbol. When part of prose, we use upright

abbreviations as follows: “an EN” stands for “a com-

ponent from the entities family”, “element of an EN”

Φ denotes the set of expressions in ﬁrst-order logic.

stands for “an element in a set which is an EN”, and

so on for the other families.

Formally, we treat these families as indexed sets

of primitive model components, each a formal artifact

required by a concrete policy. The choice of DABAC

families explicitly aims at simple, easy to understand

ABAC policy semantics in order to support a reiterative

model engineering process, which equally involves

experts in MSPE as well as in the application domain.

Note that our deﬁnition of AV and AA deliberately

allows for not only direct attribution, but also to use

AV elements as arguments for AA, which satisﬁes

the requirement of iterative model reﬁnement through

indirect attribution. Based on (Amthor, 2019), we

introduce an indirection degree

for each attribute as-

sociation

, which denotes if the respective domain

of these mappings is from

(direct attribution) iff

i = 0

, or from

(indirect attribution) iff

0 < i ≤ i

max

(where

max

denotes the maximum indirection degree

in a model). Whenever used without an index, the

respective set symbol denotes any possible indirection

degree, i. e. AV =

0≤i≤i

max

and similar for AA.

While the above description of AR already al-

lows for arbitrary representations of attribute evalu-

ation – both enumeration-based and formula-based –

the application-speciﬁc requirement of environmental

information leads to another, complementary distinc-

tion of primitive model components.

Another requirement not addressed so far relates

to an explicit distinction between internal and external

domain. For a modeled AC system, the internal do-

main (also called authorization domain) contains any

local information and any authorization rules of the

AC system. The external domain (information domain)

contains observable, external information, which can-

not be controlled by the AC system: it cannot effect,

anticipate, or causally explain any changes in the ex-

ternal domain. Formally, we demand that any primi-

tive model component is exclusively member of either

the internal or the external domain, which results in

a classiﬁcation orthogonal to the semantical families

introduced so far. We thus reﬁne them as follows:

EN:

are internal entities, whose creation, destruction,

and modiﬁcation solely occurs within the domain

of the AC system;

ext

are external entities, which are observable at

the AC system’s interface to another domain (con-

trolling their observability);

AV:

are internal attribute values assigned through

mechanisms implemented in the AC system;

ext

are external attribute values, whose assign-

ments are observable by the AC system;

The Missing Piece of the ABAC Puzzle: A Modeling Scheme for Dynamic Analysis

237

Table 1: Summary of DABAC families. Indices n, m ∈ N are independent for each row.

internal external

EN = {E

, . .. , E

}

, where

1,...,n

are policy-speciﬁc sets of

internal entities

ext

= {E

n+1

, . .. , E

n+m

}

, where

n+1,...,n+m

are

policy-speciﬁc sets of external entities

= {V

, . .. ,V

}

, where

1,...,n

are policy-speciﬁc sets of

internal attribute values of indirection degree 0 ≤ i ≤ i

max

ext

= {V

n+1

, . .. ,V

n+m

}

, where

n+1,...,n+m

are

policy-speciﬁc sets of internal attribute values of

indirection degree 0 ≤ i ≤ i

max

= {att : E → V |E ∈ EN ∧ (∃V

∈ AV

: V = V

∨V =

P (V

))}, where att are internal direct attribute mappings;

= {att : V

i−1

→ V

i−1

∈ AV

i−1

∧(∃V

∈ AV

: V

= V

∨

= P





)}

, where

att

are internal attribute mappings of

indirection degree 0 < i ≤ i

max

ext

are external attribute mappings analogous

to AA

, 0 ≤ i ≤ i

max

AR = {auth

: [v

, . .. , v

] → B, n

∈ N | p ∈ Perm ∧ (∃V

∈

AV ∪ AV

ext

: v

∈ V

∨v

∈ P (V

), 1 ≤ k ≤ n

)}

, where

auth

are authorization functions for each permission

, which map

a vector of (internal or external) AV elements to a boolean

decision value

not applicable

AA, AA

ext

are attribution mappings for internal/exter-

nal attribute associations analogous to AV/AV

ext

;

AR:

describe system functionality rather than infor-

mation. To this end, a distinction based on control-

lability vs. observability is not applicable. Still,

however, since authorization is internal function-

ality of the modeled system, we will technically

treat them as part of the internal domain.

3.2.2 Model Dynamics

Being the key-enabler for safety analysis, the deter-

ministic automaton is formalized in the next step.

State Space.

As the automaton’s state space de-

scribes model components subject to runtime mutabil-

ity, we refrain from deﬁning it on a modeling scheme

level here. Instead, we generalize state-speciﬁc in-

stances of primitive model components from the fami-

lies EN and AA as follows:

Γ =

k∈K

P (E

) ×

l∈L

{att

lγ

: X → V |

att

: X

→ V ∧ X ⊆ X

}

where

∈ EN

and

K ⊆ {1, . . . ,

}

is an index enu-

meration of dynamic internal entities sets;

att

∈ AA

and

L ⊆ {1, . . . ,

}

is an index enumeration of dy-

namic internal attribute mappings. For addressing

model components in a state

γ ∈ Γ

, we will use

as a subscript, i. e.

γ = hE

1γ

, . . . , E

|K|γ

, att

1γ

, . . . , att

|L|γ

Similarly we will use the regular expression

[γ

∗

]

a subscript of dynamics-agnostic model components,

such that

k[γ

∗

]

= E

kγ

in a DABAC model where

k ∈ K

but E

k[γ

∗

]

= E

otherwise.

The rationale for this is twofold. First, for the muta-

ble portion of an ABAC policy, there is no security-

relevant use case for creating or deleting elements of

an AV, since entities are the sole endpoint abstraction

for any access decision. Attribute values, on the other

hand, are relevant for such decision only as far as

they are assigned to entities – which implies that AA

may be mutable in order to model dynamic AC system

reconﬁguration. AR, ﬁnally, must be immutable to pre-

vent a self-modifying policy (in contrast to our goal,

a dynamically modifyable model state). Moreover,

since

auth

∈ AR

are deﬁned based on AV elements

(for both enumerated and formula-based ABAC), the

immutable nature of the latter formally requires the

former to be immutable as well.

Second, according to the deﬁnition of

, model

components from the external domain must never be

part of the automaton’s state space. The reason for

this is a direct consequence from their rationale as a

model abstraction: Since an AC system cannot con-

trol, i. e. create, delete, or modify, such components,

we cannot alter (nor even formalize) their mutability

rules (cf.

∆

) to allow for the correction of policy errors

that dynamic analyses might expose. Nevertheless,

since external components might still impact the au-

thorization of policy-speciﬁc operations (which we

will formalize as logical pre-conditions in

∆

), they

must not be ignored. This results in a deliberate deci-

sion not to model any external state, but instead treat

external model components similar to static, internal

components, just without any guaranteed assumptions

w. r. t. to their dynamics.

Consequently, the dynamic portion of the policy

might be expressed by simply selecting mutable primi-

tive model components from EN and AA.

SECRYPT 2021 - 18th International Conference on Security and Cryptography

238

State Transitions. To formalize (1.) how authoriza-

tion decisions are made and (2.) how mutable model

components change, we discuss next how to deﬁne the

automaton’s interface

and STS

∆

, representing

parameterized input operations, and

∆

, representing

state-change rules, both rely on the deﬁnition of AR,

which also yields the set of possible permissions

Perm

Formally, we deﬁne

Perm

as a set of atomic identi-

ﬁers and Σ as follows:

Σ = {



op, [a

, . . . , a

]



|op ∈ OP ∧

(∃A

∈ EN ∪ EN

ext

∪ AV ∪ AV

ext

∈ A

, 1 ≤ k ≤ n

)}

where

is a set of atomic identiﬁers for operations

made available by the AC system and

]

is a vector

of operation-speciﬁc argument values from either EN

or AV, both internal or external. This way, the automa-

ton’s interface is policy-agnostic w. r. t. the semantics

of possible access operations.

To ﬁnally address the two modeling tasks

stated above, we express both pre-conditions (and

thus authorization decisions) and post-conditions

(changes of mutable components) through a set of

tuples

∆ ⊆ Σ × P (Perm) × Φ

, where each

hσ =



op, [a

]

k=1



, Perm

, φ

i is written as:

I op(a

, . . . , a

) ::=

VAR: v

= φ

, . . . , v

= φ

PRE:

p∈Perm

auth

([v

]

k=1

)

POST: φ

This notation lists a CNF of AR as the pre-condition

(abbreviated

op.PRE

) and a boolean expression

the post-condition (abbreviated

op.POST

) of any state

transition to be authorized via operation

. On an au-

tomaton level, this means that

op.PRE

restricts which

states

to legally transition from, while

op.POST

de-

ﬁnes any differences between

and the state

reach-

able by any input word

. Finally,

consists of redef-

initions of one or more mutable primitive model com-

ponents, or just of “true” in case of not state-modifying

operations (i. e.

γ = γ

). Note that, while not required

for the same expressive power, the additional section

VAR supports model engineers as well as model read-

ers by explicitly naming (individual or sets of) attribute

values

1,...,m

extracted from

through deﬁnitions

1,...,m

∈ Φ

which are then used in

op.PRE

(such that

indices

are from

{1, . . . , m

}

is not a con-

stant) or in op.POST. See Fig. 2 for some examples.

One may observe that we do not deﬁne an output

function. The reason for this is that any safety property

always aims at changes in potentially reachable pro-

tection states – which only state-modifying operations

might produce. However, for actually implementing a

DABAC model in the last MSPE step, one may easily

derive its access control function (ACF), even with-

out an explicitly formalized output function, based on

AR. For this purpose, we explicitly allow the model

engineer to include not state-modifying operations in

the STS (in contrast to e. g. classical HRU models for

safety analysis (Harrison et al., 1976)).

3.2.3 Model Safety

We conclude the discussion of DABAC formalisms

with the actual goal of dynamic analysis. As already

introduced, the modeling scheme aims at a generaliza-

tion of the reachability property for protection states

that impact the ACF of the model, which might lead

to any form of privilege escalation in a model’s terms.

Similar to how an access matrix containing access

rights formalizes an ACF, we deﬁned AR containing

permission authorization functions to formalize the

same for a DABAC model. To this end we propose a

most general DABAC safety deﬁnition based on the

term of permission leaks.

Deﬁnition 1 (Permission Leak).

For two states

and

of a DABAC model,

leaks a permission

p ∈ Perm

w. r. t.

iff there is either (1.) an

X ∈ EN

and an

att ∈ AA

(direct leakage) or (2.) an

X ∈ AV

and an att ∈ AA

, i > 0 (indirect leakage), such that

∃{x

, . . . , x

} ⊆ X

[γ]

∗

∩ X

[γ

]

∗

auth

([att

[γ]

∗

)]

h=1

) = false

∧ auth

([att

[γ

]

∗

)]

h=1

) = true.

Some observations towards this deﬁnition should be

discussed ﬁrst. (1.) Potentially, both static and dy-

namic model components could be subject of a privi-

lege escalation, since even a static entity set might be

subject to changing attribution. The only exception is

a model in which an attribute mapping in

is static,

which formally requires its domain set

to be static

as well. Consequently, we use the dynamics-agnostic

notation

[γ

∗

]

as introduced before. (2.) Likewise, both

direct and indirect attribute mappings must be taken

into account, since

auth

deﬁnitions are not restricted

to require only direct attribute values. (3.) Since priv-

ilege escalation is only relevant (and ﬁxable) for the

internal domain of our modeled system, safety deﬁ-

nitions only include internal model components for

the violating state

. External components could still

contribute to a path in the model’s state space for

to be reachable, though. (4.) We deliberately ask for

leaks effected by such model component values

that

are already present in

. The reason for this is practi-

cal rather than technical: We agree with (Tripunitara

and Li, 2013) that a meaningful safety analysis result

The Missing Piece of the ABAC Puzzle: A Modeling Scheme for Dynamic Analysis

239

should expose entities or indirect attribute values that

a model analyst can identify in

and therefore relate

to some actual vulnerability in terms of her policy.

Def. 1 leads to our model-independent deﬁnition

of DABAC safety.

Deﬁnition 2 (

-Safety).

For a state

of a DABAC

model and a permission

p ∈ Perm

, is there an input

sequence

, . . . , σ

∈ Σ

∗

that leads from

via

∆

such that γ

leaks p w. r. t. γ?

If no such sequence exists, γ is called

-safe.

In natural prose, we ask “Is it possible that some entity

without a speciﬁc permission gains this permission

in the future?” Note that this subsumes the question

“Is it possible that an operation

, which evaluates

op.PRE = false

for some arguments, evaluates to

op.PRE = true

for the same arguments in the future?”,

which might be asked from a practitioner’s view. For

any concrete DABAC model, the ﬁnal step of model

engineering is to adapt Defs. 1 and 2 to model-speciﬁc

EN and AA, which paves the way for a subsequent,

tool-based analysis.

As with classical safety, both deﬁnitions might be

further reﬁned (cf. (Tripunitara and Li, 2013)). The

idea here is to add, additionally to

, model-speciﬁc

parameters that conﬁne our analysis cases to relevant

model component values (analysis targets)

. These

could be security-critical objects, untrusted users and

the like; again, we support iterative MSPE by allowing

for a step-by-step increase of granularity here – starting

from Def. 2, which only relates to a state

and a

permission p (in the notation “

parameter(s)

-safe”).

Wrapping up, a parameterized analysis query

amends the model-speciﬁc safety deﬁnition as follows.

Deﬁnition 3 (Safety Analysis Query).

A DABAC

safety analysis query is a tuple

hγ

, p, [τ

, . . . , τ

where

∈ Γ

is a model state to analyze,

is the target

permission to analyze, and

[τ

]

k=1

, τ

∈ EN ∪ AV

is a

vector of additional analysis targets.

Composed Safety.

For practical policy analysis, we

expect an even more specialized safety question re-

lating to future conditions for authorizing a complete

operation instead of granting a particular permission.

Again, such questions might be expressed through an-

other reﬁnement step, which results in a composed

safety deﬁnition for a corresponding, specialized anal-

ysis query. Composed safety can be regarded as a

conjoining macro over multiple, operation-speciﬁc in-

stances of

-safety for a speciﬁc policy.

We hence conclude this discussion with a deﬁnition

of such a macro to query composed safety for a fully

parameterized input operation.

Deﬁnition 4 (

-Safety Analysis Query).

-safety analysis query is a tuple

hγ

, op, [x

, . . . ,

, where

∈ Γ

is a model state to analyze,

the target operation to analyze, and

1,...,n

are actual

arguments of op.

Deﬁnition 5 (

-Safety).

Given an

-safety

analysis query

q = hγ

, op, [x

, . . . , x

against a

DABAC model such that

hhop, [a

]

k=1

i, Perm

i ∈ ∆

. Is there an input sequence

, . . . , σ

∈ Σ

∗

that leads from

via

∆

such that both of the

following is true:

• φ

= true

for the input



op, [x

]

k=1



in state

and

• ∃p ∈ Perm

-safety for the query

hγ

, p,

]

k=1

i is false?

If no such sequence exists,

-safety for

is true.

After having deﬁned model components and model

dynamics for an application scenario, we end up with

a model-speciﬁc safety property and analysis query.

These pieces will be put together be an exemplary

MSPE workﬂow illustrated in § 4.

3.2.4 Expressive Power of DABAC

To discuss the expressive power of DABAC, we com-

pare it with two recent ABAC modeling schemes

whose goals overlap with our modeling scheme:

(1.) versatility to express diverse ABAC policies and

(2.) dynamic analysis capabilities. More speciﬁcally,

we have selected ABAC

(Jin et al., 2012) and C-

ABAC (Fern

andez et al., 2019) (see

2). The goal

is to demonstrate that DABAC can be used to formal-

ize instances of both modeling scheme. Due to space

limitations, we will present an informal argumentation

based on the most relevant formalisms; a more com-

prehensive study of both DABAC expressiveness and

expressive power is subject to ongoing work.

ABAC

Other than DABAC, ABAC

does not gen-

eralize ABAC semantics, but instead aims at be-

ing as speciﬁc as possible. This results in model-

independently predeﬁned EN for subjects

, users

and objects

. While ABAC

do not explicitly deﬁne

AV, they are implicitly part of attribution functions,

which again reﬂect the three entity sets. To enable

model-speciﬁc user attributes for example, there is

UA = {ua |ua : U → V

}

, where

is either an AV

or a power set of an AV; subject- and object-attributes

are deﬁned analogously. So instead of deﬁning

based on

, as we did in Tab. 1, ABAC

models

would require the opposite step order (still resulting

in the same semantics). Only direct attribution is sup-

ported. Because of its deliberate choice of semantic

SECRYPT 2021 - 18th International Conference on Security and Cryptography

240

frugality, ABAC

does not make a distinction between

internal and external domains.

While the ACF of ABAC

models can be

ﬂexibly deﬁned in ﬁrst-order logic, the function

Authorization

: S × O → B

deﬁned for this purpose

differs from

auth

functions in DABAC in that it re-

quires to specify how attribute values for the entities

passed as parameters (instead of AV elements) are de-

rived. For DABAC, we deliberately deny this opportu-

nity by the formal deﬁnition of AR in order to prevent

possible conceptional errors introduced by specifying

this part of the policy. The mindset here is that, for

clean ABAC semantics, permissions have to be granted

exclusively based on attribution, but never on iden-

tity – which is possible in ABAC

, again deliberately

to support IBAC policies as well. Having that said,

this difference relates to intended usage rather than

expressive power, since any attribute values passed to

auth

can be derived in the VAR section of STS

deﬁnitions in DABAC.

Although not in automaton notation, ABAC

mod-

els are dynamic. Any model-speciﬁc STS however

is ﬁxed to a set of eight state-modifying operations,

each with their predeﬁned PRE and POST expressions,

which might be rewritten in DABAC notation in a

straight-forward way. This is a main reason for strong

analytical features such as decidable safety (Ahmed

and Sandhu, 2017), but also restricts ABAC

expres-

sive power to dynamics less general than in DABAC.

C-ABAC.

C-ABAC takes a different approach than

ABAC

, which shares more similarities with DABAC

in terms of model engineering. This mainly originates

from the generalized semantics of ABAC abstractions

inspired from CBAC in both cases; it however results

in different formalisms due to our requirements of

automaton-based analysis and functional policy spec-

iﬁcation. Still, because of their generality, basic C-

ABAC semantics can be transformed into DABAC in

a straight-forward way.

From what C-ABAC calls entities, both its fami-

lies

(principals) and

(resources) precisely map

to EN for the internal domain. Since

Env

represents

environment entities (such as networks, channels etc.

(Fern

andez et al., 2019)), this set equals

ext

. An-

other, abstract set of entities is based on CBAC cate-

gories: the set

in C-ABAC is an additional level of

indirection between EN and AV, which can be used to

express attribute classiﬁcation and parameterization.

In DABAC, this exact use case is covered by indirect

attribution, so C is part of AV

here.

Two C-ABAC families

and

are used for

model-speciﬁc deﬁnitions of attributes and AV, respec-

tively: while the former deﬁnes an abstract, model-

speciﬁc set of attribute identiﬁers, the latter represents

appropriate (model-speciﬁc) AV. The actual attribution,

expressed by

att

functions in DABAC, is then formal-

ized through four relations:

PAtA

for

functions

on EN in

RAtA

for

functions on EN in

and

EAtA

for

functions on

ext

, and

CAtA

for

functions. Each of these represents attribution by

association with multiple tuples from At × V .

The most distinct feature of C-ABAC in contrast

to DABAC is how it handles operational semantics:

While the DABAC requirement of functional speciﬁ-

cation and analysis resulted in an automaton model, C-

ABAC follows CBAC in a purely axiomatic approach.

This has two important consequences: (1.) The ACF

of C-ABAC models has a more structured formaliza-

tion that in DABAC. Instead of operation-speciﬁc con-

junctions of

auth

deﬁnitions, which a model engi-

neer might mix and match without further restriction,

C-ABAC deﬁnes a model-independent authorization

axiom. While perfectly rewritable in the PRE sec-

tions of a DABAC STS, this normalization supports

static analyses of C-ABAC models by stronger assump-

tions on authorization conditions. (2.) With respect to

state-modiﬁcation, the POST notation of DABAC goes

beyond C-ABAC since it explicitly speciﬁes model dy-

namics. As already discussed in

2, DABAC does not

separate administrative from non-administrative oper-

ations, for which the authors of C-ABAC presented

Admin-CBAC as a parallel modeling scheme instead.

Finally, it should be highlighted that in terms of ex-

pressiveness rather than expressive power, all three

modeling schemes discussed here are tailored to their

respective use cases – since mere simulation of com-

mon ABAC semantics does not necessarily mean that

model formalisms are suitable for their intended pur-

poses, such as analyzing static or dynamic properties

or enabling tool-supported implementation. With an

MSPE workﬂow and dynamic properties to analyze

as a goal, we have tailored DABAC to support this

speciﬁc use case without sacriﬁcing the opportunity

to switch to another modeling scheme as soon as such

becomes more appropriate for practical reasons.

4 PRACTICAL APPLICATION

The key motivation for DABAC is to support MSPE by

enabling comprehensive analyses of ABAC policies

regarding dynamic model properties. In this section,

we demonstrate the practical application of DABAC

to an exemplary policy based on a scenario in the

health care domain. Balancing security and usability

in this scenario is practically challenging. On the one

hand, conﬁdentiality and integrity of health care data

The Missing Piece of the ABAC Puzzle: A Modeling Scheme for Dynamic Analysis

241

as well as preventing unauthorized access to sensors

and actuators is a critical requirement, on the other

hand, patient-oriented treatment workﬂows must be

possible at any time. In the following, we will guide

through the steps of engineering a DABAC model for

this policy (

4.1) and reﬁning it based on a model

analysis (§ 4.2) in a simpliﬁed MSPE process.

4.1 Model Engineering

The exemplary security policy and its DABAC model

are settled in the context of a smart health care scenario

comprising a hospital information system (HIS) for

medical data management with remote patient monitor-

ing capabilities based on external medical IoT sensors

and actuators, such as can be found in (Ray et al., 2017;

Mukherjee et al., 2017).

Primitive Model Components.

Acting system enti-

ties are users, which are either human users or their

personal (smart) devices. The following entities are

subject to accesses by users:

•

objects, representing data objects, such as patient-

speciﬁc electronic health records (EHRs);

• sensors, representing interfaces to health monitor-

ing sensors connected to patients, such as clinical

thermometers;

•

actuators, representing interfaces to medical actu-

ators connected to patients, such as insulin pumps.

In model terms, user entities (set

) and object entities

(set

) are internal entities. In contrast, both sensor

entities (set

Sen

) and actuator entities (set

Act

) are

logically and physically separate from the AC system,

hence external entities. For illustration purposes,

represents EHRs,

Sen

represents thermometers, and

Act

represents insulin pumps. The individual elements

of these sets are patient-speciﬁc, i. e. for each a one-to-

one mapping to patients is assumed.

The considered policy is modeled based on at-

tributes which reﬂect the hospital’s organizational

structure and workﬂows. Each user is assigned a role,

such as physician, nurse, or patient, that enables ac-

cessing (passive) entities for the accomplishment of

tasks. Orthogonally, each user is assigned to a hospital

ward, such as internal, ICU, or surgery. Consequently,

user entities are attributed by two functions

att

and

att

with role and ward attribute values (from

re-

spectively

). For sake of simplicity, we allow one

role and one ward per user.

Rather than a patient being purely assigned to a

ward for the treatment of a disease and, thus, all users

assigned to that ward having access to her EHR, the

policy is speciﬁed more ﬁne-grained: By introducing

 auth

read

∈ R) ⇔ r

6= rPatient

 auth

shareCases

⊆ I, I

⊆ I) ⇔ I

∩ I

 auth

assign

∈ R) ⇔ r

= rManager ∨ r

= rPhysician

 auth

isAssignee

∈ R, r

∈ R) ⇔

((r

= rManager ∧ r

= rPhysician) ∨ r

= rNurse)

 auth

delegate

∈ R) ⇔ r

= rPhysician

 auth

isDelegate

∈ R) ⇔ r

= rPhysician

Figure 1: Exemplary deﬁnitions of authorization functions

for permissions in the DABAC HIS model.

treatment cases, only exactly those physicians and

nurses assigned to care in a case will have access to

an EHR. Additionally, assigned treatment personnel

may belong to different wards. In our model, this is

realized by the attribute value set

containing medical

case identiﬁers (represented by indexing) as well as the

attributions

att

and

att

, which attribute (1.) users

related to that case (assigned physicians or nurses,

patients treated) and (2.) EHR objects that represent

the information about that case.

The external entities, thermometer sensors and in-

sulin pump actuators, are attributed as follows: each

temperature sensor is attributed with a temperature

value from the set

Temp

att

and each insulin

pump actuator is attributed with a dose value from the

set Dose by att

Following the components from EN, AV, and AA

families, we now conclude by deﬁning the AR fami-

lies. Generally,

contains a set of attribute-checking

permissions (modeled as authorization functions). As

an example, we have presented a selection of deﬁni-

tions in Fig. 1, which, subsequently, are also used in

the STS operations. Their semantics are as follows:

auth

read

The permission read is granted any role other

than rPatient.

auth

shareCases

The permission shareCases is granted

iff given case attribute value sets

and

have a

non-empty intersection.

auth

assign

The permission assign is granted for the

roles rManager or rPhysician.

auth

isAssignee

The permission isAssignee is granted

iff either a physician or a nurse is assignee, where

only managers can assign cases to physicians.

auth

delegate

The permission delegate is granted for the

delegator role rPhysician.

auth

isDelegate

The permission isDelegate is granted

for the delegate role rPhysician.

Note that

auth

delegate

and

auth

isDelegate

have different

semantics here, their identical deﬁnition is merely due

to the simpliﬁcations of the example scenario.

SECRYPT 2021 - 18th International Conference on Security and Cryptography

242

Table 2: Overview of DABAC HIS primitive model components and their instantiation (functions written in relational style).

Symbol Description HIS Instantiation

U set of user identiﬁers {

drCox, drKelso, drJD, nurseCarla, nurseLaverne,

mrsFriendly, mrBruise, msPregnant, ... }

O set of (data) object identiﬁers {ehrMrsFriendly, ehrMrBruise, ehrMsPregnant, ... }

ext

Sen set of sensor identiﬁers {sThermometerMsPregnant, ...}

Act set of actuator identiﬁers {actPumpMrsFriendly, ... }

R set of role attribute values {

rPhysician, rPatient, rNurse, rParamedic, rMan-

ager, rClerk}

W set of ward attribute values {

wInternal, wICU, wSurgery, wCardiology,

wMaternity}

I set of numerical case identiﬁers I ⊆ N

ext

Temp set of temperature attribute values Temp ⊆ N

Dose set of drug dose attribute values Dose ⊆ R

att

: U → R user-role-attribution {

nurseCarla, rNurse

drCox, rPhysician

drKelso,rPhysician

, ...}

att

: U → W user-ward-attribution {

nurseCarla, wInternal

drCox, wInternal

drKelso,wMaternity

, ...}

att

: U → P (I) user-cases-attribution {

drKelso,{42}

, ...}

att

: O → P (I) EHR-cases-attribution {

ehrMsPregnant, {42}

, ...}

ext

att

: Sen → Temp sensor-temperature-attribution not applicable

att

: Act → Dose actuator-dose-attribution not applicable

AR AR

set of permission authorization

functions

{auth

read

, auth

shareCases

, auth

assign

, auth

isAssignee

auth

delegate

, auth

isDelegate

, ...}

All described primitive components and their instanti-

ations (cf. automaton’s initial state) for our model are

summarized in Tab. 2.

Model Dynamics.

In DABAC, model dynamics are

deﬁned based on a specialized deterministic automa-

ton. The model dynamics are deﬁned as described in

§ 3.2.2 and tailored model-speciﬁcally as follows:

• Γ = P (U)×P (O) ×{att

: U

→ R |U

⊆ U}×

{att

: U

→ W |U

⊆ U} × {att

: U

→

P (I) |U

⊆ U} × {att

: O

→ P (I) |O

⊆ O}

where

γ =



, O

, att



∈

Γ is a single protection state;

• OP = {

readEHR, appendToEHR, createEHR, de-

leteEHR, fetchTemp, pushDose, addUser, remove-

User, assignCase, delegateCase, revokeCase};

• ∆

is deﬁned by a set of operations according to the

identiﬁers from

. Generally, users may read

or write objects, read but not write sensors, and

write but not read actuators.

Fig. 2 illustrates three

In practice, there might be devices such as ICU bedside

monitors which both allow to monitor (“fetch”) real-time

patient data, as well as to store (“push”) history records

from newly arrived patients. These could be modeled by a

common identiﬁer, both in

Sen

and in

Act

. However, for the

sake of simplicity, we assume

Sen ∩ Act =

in this example.

I readEHR(u ∈ U

, o ∈ O

) ::=

VAR: r

= att

(u), I

= att

(u), I

= att

(o)

= att

(u),

∈U

\{u}, att

)=w

att

)

PRE: auth

read

) ∧ auth

shareCases

, I

) ∧

auth

shareCases

, I

)

POST: true

I assignCase(u ∈ U

, u

∈ U

, i ∈ I) ::=

VAR: r

= att

(u), r

= att

), I

= att

(u)

PRE: auth

assign

) ∧ auth

isAssignee

, r

) ∧

auth

shareCases

, {i})

POST: att

) ← att

) ∪ {i}

I delegateCase(u ∈ U

, u

∈ U

, i ∈ I) ::=

VAR: r

= att

(u), r

= att

), I

= att

(u)

PRE: auth

delegate

) ∧ auth

isDelegate

) ∧

auth

shareCases

, {i})

POST: att

) ← att

) ∪ {i}

Figure 2: Exemplary deﬁnitions of STS operations for the

DABAC HIS model.

representative examples readEHR, assignCase, and

delegateCase. Their semantics are as follows:

readEHR

represents an operation to read an EHR. A

user

u ∈ U

is allowed to read

o ∈ O

iff (1.)

attributed a role

∈ R

other than rPatient, i. e. no

patient may read

(

auth

read

), (2.)

shares cases

With respect to the scenario’s background, one might

The Missing Piece of the ABAC Puzzle: A Modeling Scheme for Dynamic Analysis

243

Table 3: Overview of additions to DABAC HIS primitive model components and their instantiation.

Symbol Description HIS Instantiation

, AV

T set of team attribute values T ⊆ N

att

: {u ∈ U |att

(u) ∈ {rPhysician,

rNurse, rParamedic,rManager}} → T

user-team-attribution {

drKelso,4242

drCox, 4242

nurseCarla, 4242

, ...}

att

: T → P (I) team-case-attribution {

4242, {42}

, ...}

with

(

auth

shareCases

), and (3.) there is at least one

user, who shares cases with

and who is from

the reader’s own ward (last statement in VAR and

auth

shareCases

). Given all permission checks evalu-

ate to true, POST does not have any effect on the

model state and, thus, evaluates to true.

assignCase

represents the assignment of treatment ca-

pabilities. A user

u ∈ U

is allowed to assign a case

i ∈ I

to user

∈ U

iff (1.)

is attributed with role

rPhysician or rManager, i. e. the assigner is either a

physician or manager (

auth

assign

), (2.) the assignee

is attributed with rNurse or, if

is a manager,

rPhysician (

auth

isAssignee

), and (3.)

is attributed

with case

(

auth

shareCases

). Given all permissions

are successfully evaluated to true, POST renders a

new state by additionally attributing u

delegateCase

covers medical referrals and treatment

delegations in the sense of “a physician assigns

another physician responsibility for some case”.

Thus, a user

u ∈ U

is allowed to delegate a case

i ∈ I

to user

∈ U

iff (1.)

is attributed with role

rPhysician (

auth

delegate

), (2.) the delegate

is at-

tributed with role rPhysician as well (

auth

isDelegate

and (3.)

is attributed with case

(

auth

shareCases

Given all checks evaluate to true, POST renders a

subsequent state by attributing u

with i.

4.2 Model Analysis

Once a model has been designed, the model engineer is

interested in whether it meets the required correctness

guarantees. Such questions are asked and answered in

the model analysis step.

Analysis.

We exemplarily consider the following

practical analysis question in the given scenario: Is

nurseCarla ever able to read ehrMsPregnant? This

precisely reﬂects a query regarding the

-safety

(Def. 5), where

equals readEHR. Based on the

argue that a patient should be allowed to read her own EHR

at any time. This could be easily achieved by just remov-

ing the

auth

read

authorization clause in PRE. Note that this

relaxation cannot be made for appendToEHR.

given initial state

, this query would be expressed by

, readEHR, [nurseCarla, ehrMsPregnant]

In general, safety properties are undecidable. Nev-

ertheless to be able to perform safety analyses, a pos-

sibility is to restrict a model w. r. t. its dynamics and,

thus, its expressive power (cf. ABAC

and Admin-

CBAC). Since our goal is to maintain a model’s expres-

sive power, we instead exploit the semi-decidability

of safety: Given a model state

and another state

reachable from

, it is efﬁciently decidable whether in

the considered safety property is violated.

In order to ﬁnd such states efﬁciently – espe-

cially in practical complex and extensive model in-

stances – heuristic approaches have been developed.

Sophisticated heuristics, such as DepSearch (Amthor

et al., 2013) and WSDepSearch (Schlegel and K

uhn-

hauser, 2020), are based on the dependency search

approach exploiting inter-dependencies of STS opera-

tions, where the necessary pre-condition of an opera-

tion are established by the post-condition of another

operation. Thus, in order to show the unsafety of a

given model state, a privilege escalation is explicitly

induced by executing a sequence of STS operations

and a clever choice of operation parameters.

By leveraging a heuristic algorithm as outlined, a

possible sequence of operations and inputs leading to

a safety-violating state can be also identiﬁed in the

given model instance and rendered as follows:

1. delegateCase(drKelso, drCox, 42);

2. assignCase(drCox, nurseCarla, 42);

3. readEHR(nurseCarla, ehrMsPregnant).

Interpretation.

To enable nurseCarla to execute

readEHR on ehrMsPregnant, the following pre-clauses

must be met: (1.) she must be authorized to read – this

is true since she is a nurse, not a patient; (2.) she must

be assigned to at least one case that ehrMsPregnant

is also assigned to; (3.) at least one user of the same

ward must be assigned that case.

The latter two pre-clauses must have been explic-

itly established beforehand due to the assignments

in the initial state (cf. Tab. 1). Being assigned to

case 42 by drCox via assignCase satisﬁes the second

pre-clauses for nurseCarla. For assignCase to be exe-

SECRYPT 2021 - 18th International Conference on Security and Cryptography

244

cutable (1.) drCox as assigner must be either physician

or manager – this is true; (2.) drCox as assigner and

physician must be attributed with this case; (3.) nurse-

Carla must be a nurse – this is also true.

Both, the second pre-clauses of assignCase and

third pre-clauses of readEHR, become satisﬁable by

the delegation of case 42 to drCox by drKelso via

delegateCase: (1.) drKelso as delegator and drCox as

delegate are both physicians; (2.) drKelso is assigned

to this case. have se Consequently, a potential privi-

lege escalation is possible on a ward-by-ward base, i. e.

if at least one member (any one) of ward

is capable

of accessing cases originally treated in ward

, this

also holds for any other member of

. If, then again,

a different member of

is capable of accessing cases

from ward z, this may spread transitively.

Consequences.

The model originally formalizes a

policy which is based on the organizational structure

of a hospital. Now, the analysis results produced a

more substantial understanding of possible privilege

escalation vulnerabilities that are anchored in this de-

sign. To address these design ﬂaws, a reiteration step

in the model engineering phase of MSPE is necessary

to improve the model design.

One possible approach to ﬁx the above-discussed

privilege escalation phenomenon is summarized in

Tab. 3. In order to cover the semantics of ward-

crossing treatment workﬂows, the attribute team, the

user-team-attribution

att

, and the indirect team-case-

attribution

att

are introduced. A team consists of

users, possibly from different wards, such that any

team could commonly treat cases independent from

their “original” wards.

5 CONCLUSIONS

This paper presents DABAC, a modeling scheme for

ABAC policies that enables automaton-based analysis

and speciﬁcation of ABAC policies. By classifying

formal abstractions in the semantical levels of primi-

tive model components, model dynamics, and safety

properties, we support a mix-and-match approach that

streamlines the integration of DABAC models in the

MSPE workﬂow. Based on a common ABAC use-

case, we have highlighted how this approach could

pave the way to a more standardized, tool-supported

engineering of ABAC systems.

This is also reﬂected in our ongoing work: sup-

porting DABAC-based MSPE by tools in two areas

of application. These are (1.) semi-automated model

implementation, based on our previous work on model

speciﬁcation languages (Amthor and Schlegel, 2020);

(2.) real-time monitoring of model invariants which

cannot be proven during model analysis, such as is

the case with a heuristically analyzed but formally

undecidable safety deﬁnition. For a real-world appli-

cation integration, our future work aims at leveraging

DABAC to implement correct and reliable risk-based

ABAC policies based on real-time threat information

from external sources.

REFERENCES

Ahmed, T. and Sandhu, R. (2017). Safety of ABAC

Decidable. In NSS ’17, pages 257–272.

Amthor, P. (2017). Efﬁcient Heuristic Safety Analysis of

Core-based Security Policies. In SECRYPT ’17, pages

384–392.

Amthor, P. (2019). Aspect-oriented Security Engineering.

ISBN 978-3-7369-9980-0.

Amthor, P., K

uhnhauser, W. E., and P

olck, A. (2013). Heuris-

tic Safety Analysis of Access Control Models. In SAC-

MAT ’13, 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 Schlegel, M. (2020). Towards Language

Support for Model-based Security Policy Engineering.

In SECRYPT ’20, pages 513–521.

Barker, S. (2009). The Next 700 Access Control Models

or a Unifying Meta-Model? In SACMAT ’09, pages

187–196.

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

Model-Driven Security. In SACMAT ’11, pages 1–10.

Bertolissi, C., Fern

andez, M., and Thuraisingham, B. (2020).

Admin-CBAC: An Administration Model for Category-

Based Access Control. In CODASPY ’20, pages 73–84.

Bhatt, S. and Sandhu, R. (2020). ABAC-CC: Attribute-

Based Access Control and Communication Control for

Internet of Things. In SACMAT ’20, pages 203–212.

Biswas, P., Sandhu, R., and Krishnan, R. (2016). Label-

Based Access Control: An ABAC Model with Enu-

merated Authorization Policy. In ABAC ’16, pages

1–12.

Fern

andez, M., Mackie, I., and Thuraisingham, B. (2019).

Speciﬁcation and Analysis of ABAC Policies via the

Category-Based Metamodel. In CODASPY ’19, pages

173–184.

Ferraiolo, D., Chandramouli, R., Kuhn, R., and Hu, V.

(2016). Extensible Access Control Markup Lan-

guage (XACML) and Next Generation Access Control

(NGAC). In ABAC ’16, pages 13–24.

Gupta, M., M. Awaysheh, F., Benson, J., Alazab, M., Patwa,

F., and Sandhu, R. (2020). An Attribute-Based Access

Control for Cloud-Enabled Industrial Smart Vehicles.

TII, 17(6):4288–4297.

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

Protection in Operating Systems. Comm. of the ACM,

19(8):461–471.

The Missing Piece of the ABAC Puzzle: A Modeling Scheme for Dynamic Analysis

245

Hu, V. C., Ferraiolo, D., Kuhn, R., Schnitzer, A., Sandlin,

K., and Scarfon, K. (2014). Guide to Attribute Based

Access Control (ABAC) Deﬁnition and Considerations.

NIST Special Publication 800-162.

Jha, S., Sural, S., Atluri, V., and Vaidya, J. (2019). Security

Analysis of ABAC under an Administrative Model.

IET Inf. Secur., 13(2):96–103.

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

Attribute-Based Access Control Model Covering DAC,

MAC and RBAC. In DBSec ’12, volume 7371, pages

41–55.

Lang, B., Foster, I. T., Siebenlist, F., Ananthakrishnan, R.,

and Freeman, T. (2009). A Flexible Attribute Based

Access Control Method for Grid Computing. J. Grid

Comput., 7(2):169–180.

Marin, M., Kutsia, T., and Dundua, B. (2019). A Rule-based

Approach to the Decidability of Safety of ABAC

. In

SACMAT ’19, pages 173–178.

Mukherjee, S., Ray, I., Ray, I., Shirazi, H., Ong, T., and

Kahn, M. G. (2017). Attribute Based Access Control

for Healthcare Resources. In ABAC ’17, pages 29–40.

Narouei, M., Khanpour, H., Takabi, H., Parde, N., and

Nielsen, R. (2017). Towards a Top-down Policy Engi-

neering Framework for Attribute-based Access Control.

In SACMAT ’17, pages 103–114.

Ray, I., Alangot, B., Nair, S., and Achuthan, K. (2017). Us-

ing Attribute-Based Access Control for Remote Health-

care Monitoring. In SDS ’17, pages 137–142.

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

A Modeling Scheme Supporting the Dynamic Analysis

of Role-based Access Control Policies. In SECRYPT

’20, pages 431–442.

Schlegel, M. and K

uhnhauser, W. (2020). Exploiting Hot

Spots in Heuristic Safety Analysis of Dynamic Access

Control Models. In SECRYPT ’20, pages 522–532.

Stoller, S. D., Yang, P., Gofman, M., and Ramakrishnan,

C. R. (2009). Symbolic Reachability Analysis for

Parameterized Administrative Role Based Access Con-

trol. In SACMAT ’09, pages 165–174.

Tripunitara, M. V. and Li, N. (2007). A Theory for Compar-

ing the Expressive Power of Access Control Models. J.

Comput. Secur., 15(2):231–272.

Tripunitara, M. V. and Li, N. (2013). The Foundational

Work of Harrison-Ruzzo-Ullman Revisited. TDSC,

10(1):28–39.

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

Policies, Models, and Languages for Access Control.

In DNIS ’05, volume 3433/2005 of LNCS, pages 225–

237.

Xu, Z. and Stoller, S. D. (2015). Mining Attribute-Based

Access Control Policies. TDSC, 12(5):533–545.

SECRYPT 2021 - 18th International Conference on Security and Cryptography

246