ArticlePDF Available

Formal validation of automated policy refinement in the management of network security systems

Authors:

Abstract and Figures

Policy hierarchies and automated policy refinement are powerful approaches to simplify administration of security services in complex network environments. A crucial issue for the practical use of these approaches is to ensure the validity of the policy hierarchy, i.e. since the policy sets for the lower levels are automatically derived from the abstract policies (defined by the modeller), we must be sure that the derived policies uphold the high-level ones. This paper builds upon previous work on Model-based Management, particularly on the Diagram of Abstract Subsystems approach, and goes further to propose a formal validation approach for the policy hierarchies yielded by the automated policy refinement process. We establish general validation conditions for a multi-layered policy model, i.e. necessary and sufficient conditions that a policy hierarchy must satisfy so that the lower-level policy sets are valid refinements of the higher-level policies according to the criteria of consistency and completeness. Relying upon the validation conditions and upon axioms about the model representativeness, two theorems are proved to ensure compliance between the resulting system behaviour and the abstract policies that are modelled.
Content may be subject to copyright.
Int. J. Inf. Secur.
DOI 10.1007/s10207-010-0101-6
REGULAR CONTRIBUTION
Formal validation of automated policy refinement
in the management of network security systems
João Porto de Albuquerque ·Heiko Krumm ·
Paulo Lício de Geus
© Springer-Verlag 2010
Abstract Policy hierarchies and automated policy refine-
ment are powerful approaches to simplify administration
of security services in complex network environments.
A crucial issue for the practical use of these approaches is to
ensure the validity of the policy hierarchy, i.e. since the pol-
icy sets for the lower levels are automatically derived from
the abstract policies (defined by the modeller), we must be
sure that the derived policies uphold the high-level ones. This
paper builds upon previous work on Model-based Manage-
ment, particularly on the Diagram of Abstract Subsystems
approach, and goes further to propose a formal validation
approach for the policy hierarchies yielded by the automated
policy refinement process. We establish general validation
conditions for a multi-layered policy model, i.e. necessary
and sufficient conditions that a policy hierarchy must satisfy
so that the lower-level policy sets are valid refinements of
the higher-level policies according to the criteria of consis-
tency and completeness. Relying upon the validation condi-
tions and upon axioms about the model representativeness,
two theorems are proved to ensure compliance between the
resulting system behaviour and the abstract policies that are
modelled.
J. P. de Albuquerque (B
)
School of Arts, Sciences and Humanities, University of Sao Paulo,
Rua Arlindo Béttio, 1000, Ermelino Matarazzo, São Paulo,
SP 03828-000, Brazil
e-mail: joao.porto@usp.br
H. Krumm
Department of Computer Science, Technical University
of Dortmund, 44221 Dortmund, Germany
e-mail: Heiko.Krumm@udo.edu
P. L. de Geus
Institute of Computing, University of Campinas,
Campinas, SP 13083-852, Brazil
e-mail: paulo@ic.unicamp.br
Keywords Policy refinement ·Model-based
management ·Formal validation ·Security policies ·
Policy based management ·Network security
1 Introduction
Current enterprises heavily rely upon network infra-struc-
tures that are connected to the internet in order to effectively
perform their business. In these environments, a great vari-
ety of security technologies and mechanisms are employed to
offer protection against network-based attacks. Whilst signif-
icant progress has been made on improving network security
technology in recent years, research still remains to be done
to offer a proper abstraction, integration, and tool support for
the management of the configuration of security services. In
practice, a security administrator must nowadays deal with
a great number of complex and heterogeneous configura-
tion syntaxes, most of which are unintuitive and in some
cases even misleading. This error-prone process is a threat to
the security of those environments, since a single maladjust-
ment between two mechanisms can leave the whole system
vulnerable to attacks.
1.1 Previous work
Within this context, policy-based network management
offers a promising approach, since it describes the behaviour
of different mechanisms by means of abstract and uniform
policies [23]. Model-based Management (MBM) [16,17]is
a policy-based approach that employs an object-oriented lay-
ered model. It aims to provide a smooth transition from an
abstract view of the system to be managed and the policies
that apply to it down to reaching a detailed system represen-
tation at the most inferior layer. The modeller thus defines the
123
J. P. de Albuquerque et al.
system in each abstraction level, but the policies are specified
only at the most abstract layer. After the model is complete,
an automated policy refinement process takes place that gen-
erates policy sets for the lower levels, ultimately achieving
the derivation of configuration parameters for all the secu-
rity mechanisms of the system. In a further development,
the scalability of the approach was improved by means of an
additional layer, the Diagram of Abstract Subsystems (DAS),
in order to cope with large-scale, complex network environ-
ments [79].
1.2 Current work
A subject that was not sufficiently explored up until then is
the correctness of the automated policy refinement in MBM,
which was briefly introduced in Porto de Albuquerque et al.
[9]. Indeed, since the policy sets for the lower levels are auto-
matically derived from the abstract policies (defined by the
modeller), we must be sure that the derived policies uphold
the high-level ones, i.e. we must assure that the refinement
algorithms always produce a correct refinement from the pol-
icies and system objects given by the modeller. Only in this
case the configuration generated from the lower levels can
be expected to be in conformance with the abstract policies
that were specified. The present work is thus dedicated to
examine this issue.
This paper addresses this problem by proposing valida-
tion criteria for the automated policy refinement in MBM.
We present here a general result that establishes conditions
for the application of a policy refinement algorithm to always
comply with the general validation critera for policy hierar-
chies of consistency and completeness. Additionally, in order
to reason about the effect of the application of the automati-
cally generated configuration to the real environment, a series
of axioms are defined to capture the assumptions that are
implicit in the modelling. We thus prove that the defined con-
ditions are sufficient and necessary to guarantee the validity
of the refinement.
The rest of the paper is organised as follows: The first two
sections summarise previous works, where Sect. 2presents
the main elements of the modelling technique that was
employed, and Sect. 3analyses the policy support offered
in the MBM approach and explains the policy refinement
process. Then, Sect. 4presents the validation approach pro-
posed in this paper, including an overview of the valida-
tion approach as a whole in Sect. 4.1, in order to guide
the reader throughout the section. In Sect. 5, the practical
results achieved are presented and a simple use example
of the approach is given. Section 6discusses the validation
results, making considerations about the validation sound-
ness. Lastly, Sect. 7discusses related work and Sect. 8sum-
marises the contributions of this paper and points out to future
work.
2 Modelling framework
The modelling framework of our approach is structured in
three layers, as depicted in Fig. 1. Each of the layers is a
refinement of the superior one in the sense of a “policy hier-
archy” [18,26], i.e. as we go down from one layer to another,
the higher-level system’s view contained in the upper level
is complemented by the lower-level system representation,
which is more detailed and closer to the real system.
Thus, the horizontal dashed lines of Fig. 1delimit the
abstraction levels of the model: Roles & Objects (RO), Sub-
jects & Resources (SR), and Diagram of Abstract Subsys-
tems (DAS). As for the vertical subdivision, it differentiates
between the model of the actual managed system (on the left-
hand side) and the security policies that regulate this system
(on the right-hand side).
The two topmost levels are gathered from previous work
on MBM [16,17] and extended. The RO level is based on
concepts from Role-Based Access Control (RBAC) [11,21],
and the second level (SR in Fig. 1) offers a system view
defined on the basis of the services that will be provided.
They are both briefly described in Sect. 2.1.
The third model layer (DAS) is where the main contri-
bution of this work is applied. It aims at offering a modular
description of the system’s overall structure, thereby improv-
ing the scalability of the modelling technique.
2.1 RO and SR layers
The topmost level of our model describes the system relying
on the concept of roles, i.e. system permissions are estab-
lished based on functional roles in the enterprise, and then
appropriately assigned to users [11].Themainclassesinthis
level thus represent Roles in which people who are work-
ing in the modelled environment act; Objects that should
be subjected to access control; and AccessModes, i.e. ways
to access objects. The class AccessPermission expresses an
authorisation policy, allowing the performer of a Role to
access a particular Object in the way defined by Access-
Mode. Figure 2shows the graphical representation for each
of these classes as well as for the remaining classes used in
DAS
S & R
R & O
Managed System Policies
Fig. 1 Meta-model overview
123
Formal validation of automated policy refinement
Fig. 2 Classes of the model
our modelling framework, which are described in the next
sections.
The classes in the RO level correspond to and convey
the same semantics of the equally named entities in the
RBAC terminology (see [21]). It should be noted that we
represent RBAC Permissions by a pair of an Object and an
AccessMode (similarly to the decomposition of privileges
into operations and objects adopted by Ferraiolo et al. [12]).
The many-to-many association between roles and permis-
sions is thus established by means of an AccessPermission
and its associations with the corresponding objects (Role,
Object, and AccessMode).
The second level (SR in Fig. 1) offers a system view
defined on the basis of the services that will be provided.
Objects of these classes represent the following: (a) people
working in the modelled environment (Users); (b) subjects
acting on the user’s behalf (SubjectTypes); (c) services in the
network that are used to access resources (Services); (d) the
dependency of a service on other services (ServiceDepen-
dency); and also (e) Resources in the network.
Therefore, as regards the modelling of users, for each Role
in the RO level related objects of the classes User and Sub-
jectType are defined in the SR level. These two classes add
information about each user that is authorised to act in a cer-
tain role and the possible subjects that may take place on the
system. Both terms users and subjects refer to the equally
named concepts of the RBAC terminology, and thus serve to
complete the RO level model in the sense of the reference
model RBAC0[21]. The subjects (also named sessions in
the RBAC literature) refer to a mapping of one user to pos-
sibly many roles that are activated simultaneously [21]. As
for the “type” suffix, it is appended in MBM to indicate that
the objects do not represent all the possible subjects during
the execution of the system as in RBAC; rather they stand for
the basic types of these subjects that may occur at run-time
(seealso[15]).
2.1.1 Formalisation
In the formalism used in this work, each class in the meta-
model is represented by a set, whilst each object of that class
is then an element of the corresponding set. The possible
connections between two or more classes in the meta-model
are then represented by a relation on those sets that for-
malise the classes. Each particular instance in such relation
thus represents one or more edges in the model. In addi-
tion to these formal entities that are directly derived from
the model, some auxiliary sets and functions are also defined
in order to ease the notation of the expressions along the
paper.
Following these principles, the following definitions for-
malise the meta-model entities that are relevant for the policy
refinement validation presented later on.
Definition 2.1 The SR level has the following components:
U,St,Sv, R, disjoint sets respectively encompassing
objects of the User, SubjectType, Services, and Resources
classes;
SvDep Sv×Sv×R, a partially ordered relationship
to express that a service depends on another to access a
resource.
123
J. P. de Albuquerque et al.
2.2 The DAS level
The main objective of the Diagram of Abstract Subsystems
(DAS) is to describe the overall structure of the system in
a modular fashion, i.e. to cast the system into its building
blocks and to indicate their interconnections. As such, this
diagram is conceived to provide security administrators and
designers with an intelligible view of the system’s architec-
ture, by means of which the system configuration can be
effectively managed.
A DAS is, formally speaking, a graph comprised of
Abstract Subsystems (ASs) as nodes, and edges that represent
the possibility of bi-directional communication between two
ASs. An AS, in turn, contains an abstract view of a certain
system segment, i.e. a simplified representation of a given
group of system components that may rely on the following
types of elements:
Actors: groups of individuals which have an active behav-
iour in a system, i.e. they initiate communication and
execute mandatory operations according to obligation
policies (see Sect. 3.1).
Mediators: elements that intermediate communication, in
that they receive requests, inspect traffic, filter and/or
transform the data flow according to the authorisation
policies; they can also perform mandatory operations
based on obligation policies, such as registering infor-
mation about data flows.
Targets: passive elements; they contain relevant informa-
tion, which is accessed by actors.
Connectors: represent the interfaces of one AS with
another; i.e. they allow information to flow from, and
to, an AS.
Each element of the types Actors,Mediators or Targets
represents a group of system elements that have a relevant
behaviour for a global, policy-oriented view of the system.
As for the Connectors, they are related to the physical inter-
faces of an AS (for a detailed elaboration on the modelling
of abstract subsystems we refer to the study by Porto de
Albuquerque et al. [8]). The DAS is formally defined as fol-
lows.
Definition 2.2 The DAS level comprises the following ele-
ments:
A,M,T,C,Su, sets respectively enclosing Actors,
Mediators,Targets ,Connectors, and Subsystems;
DAS =(V,E), where V=(AMTC), and E
is a set of undirected edges that connect the nodes in V
(definition for the DAS graph itself);
sub :VSu, a function that gives the subsystem to
which a certain element of Vis assigned in the model.
Definition 2.3 The associations between elements of SR and
DAS are formalised as follows:
RA A×U×St, representing abstraction refinements
from a pair of User and SubjectType objects to an Actor;
RM M×Sv, refinements from Services to Mediators;
RT T×Sv×R, refinements from Service and
Resource pairs to Tar g e ts.
2.3 Security goals, requirements, and assumptions
In order to provide the model with more fine-grained infor-
mation about accesses that the system must allow, the mod-
elling encloses an the goals are defined at the RO level
by SecurityGoal objects. They extend the RBAC model
by abstractly representing the security properties that are
required to access an object or to perform a given access
mode. The modeller thus defines a SecurityGoal by attach-
ing it a label (e.g. “Top Confidential” or “Mission Critical,
24 ×7 availability needed”), and connecting Objects and
AccessModes to the goal. In this manner, security goals
complement the authorisation policies expressed by Acces-
sPermissions—which represent what must be allowed—with
qualitative information about how accesses must be per-
formed (following thus the definition of policy goals by West-
erinen et al. [25]).
At the SR level, each SecurityGoal is assigned to a Securi-
tyRequirement. This work follows the standardised definition
according to which a requirement is a description of a system
service or constraint needed to achieve a goal [14]. Thus, a
SecurityRequirement details the security properties that must
be fulfiled to achieve the corresponding SecurityGoal. These
properties are expressed by a vector of security levels (natu-
ral numbers ranging from 1 to 4) with respect to four catego-
ries: confidentiality,integrity,availability, and accountabil-
ity. Each 4-tuple of security level values constitutes a security
class—for instance, (1,1,1,1)is the lowest possible class.
Hence, a SecurityRequirement specifies how a SecurityGoal
should be accomplished by the system in terms of the lowest
security class that must be enforced for the related objects
and access modes.
An additional type of object is included in the model
in order to express the security properties that an entity is
assumed to assure:theSecurityAssumptions. Similarly to
the SecurityRequirements,SecurityAssumptions are also rep-
resented by a security class. At the SR level, SecurityAs-
sumptions are associated to each Service in order to represent
the security class that the service provides; i.e. to represent
the security levels one can assume in a communication that
involves that service. Analogously, at the DAS level a mod-
eller may assign a SecurityAssumption both to subsystems—
representing the security class that the elements inside an AS
are assumed to share—and individually to Actors,Targets ,
123
Formal validation of automated policy refinement
and Mediators—when a particular object is assumed to have
different security properties than those of the other elements
in the subsystem.
Definition 2.4 The security requirements and assumptions
are formally defined as follows:
SL := {1,2,3,4}, the set of security levels;
SC SL4, the set of security classes (4-tuples of secu-
rity levels);
sa :SvSuVSC, a function that returns the secu-
rity assumptions of services, subsystems, and elements
in DAS.
Definition 2.5 Suppose sc1and sc2are security classes in
SC, such that sc1=(l1,l2,l3,l4)and sc2=(m1,m2,m3,
m4). Thus the following operations are defined (the security
classes in SC together with the partial order form a lattice):
sc1sc2is the partial order in SC that comes from
the product order of the ordinary integer ordering, i.e.
limifor i=1,2,3,4;
sc1sc2=(n1,n2,n3,n4)means that if limithen
ni=li, otherwise ni=mifor i=1,2,3,4;
sc1sc2=(n1,n2,n3,n4), means that if limithen
ni=li, otherwise ni=mifor i=1,2,3,4.
2.4 Expanded subsystems
Additionally, each AS in a DAS is also associated with
a detailed view of the system’s actual mechanisms. This
expanded view is called Expanded Subsystem (ES) and
encompasses classes of objects that represent the following:
computers of the system (or hosts); credentials of the users,
like login names or certificates; processes that take part in the
communication corresponding to the policies; system objects
that are manipulated by processes, e.g. data files; and net-
work connection entities, such as protocols, interfaces, and
network segments. These classes are used to define both the
components of the system itself and the security mechanisms
employed to control the activity of the former.
We formalise the model elements of this layer and their
associations with the DAS level in the following definitions.
Definition 2.6 The ES level has the following elements:
Uc,Pc,H,So,Nc, sets correspondingly enclosing
objects of types: UserCredentials, Processes, Hosts,
SystemObjects, and NetworkConnections (this encloses
protocols, network interfaces, network segments, etc.);
ES := (W,F), where W=(UcPc HSo Nc),
and Fis a set of the directed edges that connect nodes
in W.
Definition 2.7 The associations between elements of the
ESs and DAS are defined by the following relations:
RUc Uc×A×U, refinements from Actors and Users
to credentials;
RPc Pc ×AMT, refinements from Actors,
Mediators or Targets to processes;
RSo So ×T, refinements from Targe t s to system
objects;
NcC Nc×C, connections between network connec-
tion objects and Connectors;
RES W×V, general refinements from components
of DAS to ES nodes;
sub :WSu, overriding of function sub to map the
association of ES nodes to subsystems.
Notice that the ES representation has a static character, i.e.
it is a picture of the system components and connections, but
it does not include a behavioural description of their inter-
actions. Therefore, the modelling of processes is somewhat
particular. A process object in the ES level actually stands for
aprototype of processes that might occur in the real environ-
ment. One should thus see a process object not as a picture of
a particular process executing in the real world, but rather as
an abstraction that holds the relevant common properties of
all similar processes that can be launched on a certain host.
2.5 Simple model example
A model example is shown in Fig. 3, in which a DAS (at the
bottom) is represented together with the RO and SR levels.
This model represents a typical network environment, for
which three AccessPermissions are defined at the uppermost
level (RO), in order to regulate the access rights of the users
in the internal network with respect to e-mail transactions, as
well as to allow the users to receive e-mails from the Internet.
At the bottom of this figure, the DAS for this environment
illustrates the concepts previously explained in this section.
Figure 4shows the Expanded Subsystem for the AS “inter-
nal network” as an example. Comparing the simplified view
(in the DAS of Fig. 3) and the detailed one (Fig. 4), it can be
observed that modelling through abstract subsystems offers
concrete advantages in the conciseness and understandabil-
ity of the model, as well as providing an intelligible view of
the system architecture.
3 Policy support and automated refinement
In MBM, after the input of a valid model instance, the sup-
porting tool automatically builds a policy hierarchy by deriv-
ing lower-level policy sets from the policies specified at the
most abstract layer. This process is termed in the literature
123
J. P. de Albuquerque et al.
DMZ Internet
DAS
SR level
RO leve
l
internal network
Fig. 3 Three-layered Model
AS
AS Expanded
Fig. 4 “internal network” abstract and expanded subsystem (Fig. 3)
either policy refinement [1,18]orpolicy transformation [25,
26]. In this work, we adopt the first notation.
The fully automated derivation of low-level, executable
policies from a set of abstract specifications is, in the gen-
eral case, not practical [24,26]. Nevertheless, as in MBM
the system model is structured into different abstraction lev-
els, the analysis of the system’s objects, relationships and
policies at a certain abstraction level enables the generation
of lower level policies, based also on the system’s model at
the lower level and on the relations between entities of the
two layers. As such, the model entities of a certain level and
their relationships supply the contextual information needed
to automatically interpret and refine the policies of the same
level.
Before presenting the refinement process in MBM, the
next section analyses the policy support provided by the mod-
elling and its semantics in comparison with a classification
framework [24].
3.1 Policy support and semantics
According to Sloman and Lupu [24], there are two basic types
of policies: authorisation and obligation policies. Authori-
sation policies are used to define access rights for a subject
(management agent, user, or role) and can be either positive
(defining the actions subjects are permitted to perform on
target objects) or negative (specifying the actions subjects
are forbidden to perform on target objects). As such, au-
thorisation policies are used to define access control rules
implemented by several types of mechanisms in a network
security system, such as packet filters, Kerberos, and VPNs.
Obligation policies are, in turn, event-triggered condition-
action rules that can be used to define the activities subjects
(human or automated manager components) must perform on
objects in the target domain, i.e. the duties of these subjects.
In the network security context, obligation policies can be
used to specify the behaviour of mechanisms such as logging
agents, intrusion detection systems (IDSs), and watchdogs.
123
Formal validation of automated policy refinement
RO level
transfer
Security
SR level
Services
Actors
Mediators
refinement
refinement
Assumptions
Targets
AS
DAS
Security
Policies
Assumptions
Security
Security
Assumptions
Path Security
Objects
Access Modes
Managed System
Security Goals
Access
Permission
Permission
Service
Requirements
Requirements ATPermission
Fig. 5 Policies and security requirements in the system
An overview of the hierarchical structure of the policies
supported in our modelling is presented in Fig. 5. This fig-
ure emphasises the policies, so several other element types
are omitted. While boxes with rounded corners represent the
model entities defined by the modeller (described in the pre-
vious sections), the objects generated during the automated
refinement process are depicted as normal rectangular boxes.
As for the connecting lines, the thicker, arrowed ones repre-
sent associations automatically established during the refine-
ment process, while the thinner lines with no arrows stand for
the assignments given by the modeller. In the right hand col-
umns of this figure, one can notice that the policy refinement
is subdivided in two parallel tracks, corresponding to the two
policy types supported by the modelling: security goals and
requirements, and authorisation policies.
In the uppermost model level (RO), authorisation poli-
cies are represented by means of AccessPermission objects
(Sect. 2.1). The set of AccessPermissions is given by the
modeller and acquires in this context a particular meaning.
On the one hand it defines the explicit permission for Roles
to access Objects (in the way defined by an AccessMode)—
corresponding to positive authorisation policies. On the other
hand, MBM adopts closed policies [22], i.e. the default deci-
sion of the reference monitor is denial. This implies that all
triples of Role,Object, and AccessMode not belonging to the
set of AccessPermissions are forbidden. They thus implicitly
define the negative authorisation policies which the security
mechanisms must as well enforce. Moreover, as a particu-
larity of the MBM approach that differentiates it from tra-
ditional access control models, the high-level policies and
system model additionally represent features that the sys-
tem to be managed must implement. As a consequence, the
positive and negative authorisation policies for users—i.e.
the user privileges, or actions that users may or may not
do—are also to be interpreted as obligation policies for the
system—i.e. the system duties or actions that the system
must support (allow) or not (forbid). All of these different
connotations of policies at the highest level must be prop-
agated to the inferior levels by the policy refinement pro-
cess.
As for explicitly defined obligation policies, these are
not represented in MBM since the modelling used in MBM
builds upon RBAC (Sect. 2.1), which in its basic form does
not enclose obligation policies (referred to as duties in [21]).
However, besides the above policy elements, our modelling
framework also includes an extension to the RBAC model
by means of the SecurityGoals,SecurityRequirements, and
SecurityAssumptions classes (Sect. 2.3). During the process
of policy refinement described in the sequence, the security
levels warranted by mechanisms (SecurityAssumptions)are
thus checked against the security requirements prescribed
in the SecurityRequirements. As such, a SecurityRequire-
ment with a high level of confidentiality could determine,
for instance, the decision to use either an encrypted tunnel or
a plain text channel. Another practical example occurs when
a security mechanism that supports logging has this func-
tionality activated in order to fulfil the high traceability level
required by the SecurityRequirement prescriptive associated
to the SecurityGoal of its corresponding AccessPermission.
The examples show that, although SecurityRequirements do
not directly represent obligation policies, the analysis of the
security requirements they express can yield configuration
parameters for mechanisms that do correspond to the “need
to do” aspects in the system, and hence to obligation poli-
cies.
3.2 Automated refinement and configuration generation
The automated refinement of authorisation policies starts
from the analysis of the AccessPermissions in the RO level
and their related objects in order to generate a set of cor-
responding permissions in the SR level. Thus, each triple of
Role,AccessMode, and Object (r,am,o)related to an Acces-
sPermission produces a set of 4-tuples (u,st,sv, r), each of
which expresses an authorisation for a SubjectType on behalf
of a User to use a Service in order to access a Resource.
These tuples are represented by ServicePermission objects
(see Fig. 5) and are defined as follows.
Definition 3.1 The set of authorisation policies for the SR
level is defined as:
SP U×St ×Sv×R;
sr :SP SC, a function that gives the security class
required by a ServicePermission (see Sect. 2.3).
Along with the SP set of positive authorisation policies,
we also define an auxiliary set of negative authorisation pol-
icies, SP, which is the complement set of SP.TheSP set is
not explicitly defined, but implictly derived here due to the
123
J. P. de Albuquerque et al.
semantic of closed policies employed in MBM as mentioned
previously, in order to facilitate the notation in the validation
framework below.
Definition 3.2 The set of negative authorisation policies for
the SR level is defined as
SP ={xU×St ×Sv×R|x/SP}
Subsequently, the ServicePermissions are refined into AT-
Permission objects (actor-target permissions, ATP for short),
which represent authorisation policies in a DAS (Sect. 2.2).
Since ATPs are paths in the DAS graph, this refinement phase
consists of, for each ServicePermission (u,st,sv, r), finding
the shortest path between each Actor that is connected to the
pair (u,st), and each compatible Tar g e t that is connected
to a pair like (svt,res). In fact, the path discovery must also
consider some other constraints such as service dependencies
and the compliance of security requirements—these are not
explained here though, as they are discussed in detail later
on in Sect. 4.
In order to formalise ATPermissions, we begin with an
auxiliary definition as follows.
Definition 3.3 Alocal DAS path is a path in the DASgraph
that is completely contained into a single subsystem, i.e. it
spans one subsystem. The set of local DAS paths is defined
as
LP ={v1,...,v
n|v1,...,v
n(AMT)
sub[v1]= ··· = sub[vn]
vj,vj+1Efor j=1,2,...,n1
The Pset encloses all DAS paths, i.e. each element of Pis
either a local DAS path (in LP) or it spans x>1 subsystems
and has the recursive form p1,c1,c2,p2, where:
(i) p1LP is a local DAS path, such that
p1=v1,...,v
k;
(ii) p2Pis a DAS path that spans x 1 subsystems,
such that p2=vk+1,...,v
m;
(iii) c1and c2are connectors such that (vk,c1),(c1,c2)and
(c2,v
k+1)are edges of DAS(i.e. they are elements of
E).
Now, the ATP set contains the authorisation policies at the
DAS level. Each element of ATP is a DAS path between an
Actor a and a Ta rg et t , i.e. it has the form v1,...,v
nP,
where v1=aand vn=t.
The set RATP AT P ×SP formalises the refinement
relations from service permissions to ATPs, i.e. it maps the
association of policies of the SR level (SP) with the corre-
sponding policies derived for the DAS level (ATP).
The following refinement phase comprises the automated
generation of policies that consider the equipment and secu-
rity mechanisms defined in the ESs. For this purpose, the tool
generates for each ATP a corresponding Allowed Expanded
Path (AEP) that represents an authorised path in the expanded
subsystem views. Each AEP connects a process (that refines
an Actor) to other processes (that refine the Mediators and
the Target) through their related protocol stack, interface,
and network objects. Since the path discovery was already
accomplished in the previous refinement step, the refinement
algorithm DAS/ES is quite simple. It just expands the ATPs
according to the related objects in the detailed view of the
ESs.
Definition 3.4 Alocal ES path is a path in the ESgraph that
is completely contained into a single subsystem, i.e. it spans
one subsystem. The set of local ES paths is defined as
LEP ={v1,...,v
m|v1,...,v
mW
(vi,v
i+1)Ffor 1 i<m}
The EP set contains all expanded paths in a model, i.e.
paths formed by the concatenation of local ES paths through
pairs of connectors. Each element of EP is thus either a local
ES path (i.e. an element of LEP) or a path that spans x>
1 subsystems and has the recursive form ep1,c1,c2,ep2,
where:
(i) ep1LEP is a local ES path, such that ep1=
v1,...,v
k;
(ii) ep2EP is an expanded path that spans x 1 sub-
systems, such that ep2=vk+1,...,v
m;
(iii) c1and c2are connectors such that (c1,c2)E(i.e.
there is an edge in DAS that connects c1and c2,see
Definition 2.2), (vk,c1)NcC, and (vk+1,c2)
NcC.
The AEP set of Allowed Expanded Paths (Sect. 3.2)is
the subset of EP whose elements represent policies in the
ES level, i.e. the elements of AE P are the expanded paths
that the system must allow.
The set RAEP AEP ×AT P formalises the refine-
ments from ATPs to AEPs, i.e. it represents the association
of policies of the DAS level (ATP) with the corresponding
policies derived for the ES level (AEP).
In the last phase of the refinement process, a spe-
cial back-end function for each supported mechanism type
is executed. It analyses the characteristics of each AEP
that passes through the mechanisms of a type (such as
communication protocols, addresses, and ports) to pro-
duce corresponding low-level, device-dependent configura-
tion parameters. Clearly, the configuration for a given mecha-
nism must allow only the accesses corresponding to the AEPs
that traverse the mechanism.
123
Formal validation of automated policy refinement
4 Validation approach
The consistency amongst abstraction levels of a policy hier-
archy is a crucial issue. If the policy sets at the different
levels are in perfect harmony, only then one can trust the
system behaviour resulting from the application of the low-
est-level policies to be in conformance with the specified
abstract goals. Specifically, an automated policy refinement
process as the one described in the previous section is only
of practical use if we can be certain that the generated lower-
level policies adhere to the abstract policies defined by the
modeller.
Following the observations of Abrams and Bailey [1] and
Sloman and Lupu [24], it is important to ensure the following
properties:
Completeness: the desired behaviour specified in an
abstract manner (i.e. the abstract positive policies) is
completely implemented at the lower levels;
Consistency: all the actions enabled at the lower level do not
contradict the high-level undesired behaviour specifica-
tion, i.e. the possible system behaviour is constrained
by the abstract negative policies.
The reader should note that completeness concerns positive
policies, whilst consistency deals with negative policies. As
such, these two properties are complementary and thereby
provide the necessary and sufficient criteria to ensure the
propagation of the meanings conveyed by both policies and
system model in the MBM approach (see Sect. 3.1). Thus,
this work assumes that the fulfilment of these two crite-
ria attests the correctness or validity of the policy refine-
ment.
Therefore, the main goal of the present work is to establish
validation criteria for the automated refinement described in
Sect. 3.2. As such, we do not aim at validating a particu-
lar refinement algorithm, but rather to come up with a gen-
eral result that establishes necessary and sufficient conditions
so that the application of the policy refinement to a model
instance always complies with the aforementioned general
validation criteria. Since the refinement correctness between
the RO and the SR levels was already extensively studied by
Lück [15], the topmost abstraction level (RO) is left out of
the analysis here. This validation is thus based on an analysis
of the policy refinement that starts from the SR level. On the
one hand, the analysis considers a complete model after the
policy refinement, i.e. a model yielded after the execution of
a given refinement algorithm. This complete model is thus
composed of both a group of system objects and a policy set
for each of the SR, DAS, and ES levels. On the other hand,
another important issue to be analysed is the effect on the
real world that the implementation of the lowest level policy
set has.
The validation approach of this work consists of establish-
ing a series of consistency conditions that the model must ful-
fil in order to be valid. These consistency conditions concern
both policies and system objects, and are expressed in terms
of relations amongst the various model objects and classes.
Subsequently, two theorems are presented to prove that the
defined conditions are sufficient and necessary to guaran-
tee the validity of the refinement process. These theorems
establish a connection between the input for the refinement
process and its output. In this respect, the input consists of
the system view and the policies at the most abstract level
considered (SR), whilst the ultimate output is the possible
system behaviour that results from using the produced con-
figuration parameters.
4.1 Validation overview
In the following sections we first establish the consistency
conditions for a valid refinement from the SR to the DAS level
in Sect. 4.2. These conditions are subdivided into two groups:
refinement consistency conditions and structural consistency
conditions. The first subgroup is presented in Sect. 4.2.1 and
contains conditions that validate the DAS policy set (ATP)
in comparison to the two types of policies at the SR level:
service permissions (SP) and security requirements (SR).
The structural conditions (Sect. 4.2.2), in turn, establish the
compatibility of the DAS structure (i.e. the managed system
representation) with the ATP policy set.
Subsequently, Sect. 4.3 analyses the relation between the
DAS and the Expanded Subsystems level (ES). Three sub-
groups of conditions are defined here: refinement consistency
conditions, local structural consistency conditions, and com-
position consistency conditions. The conditions of the first
group are presented in Sect. 4.3.1 and validate the ES policy
set (AEP) in comparison to ATP. As at the previous level,
the second subgroup (Sect. 4.4) also comprises structural
conditions, but this has an important difference: due to the
segmented structure of the ES level, these conditions have a
local scope. They aim at checking whether the abstract view
of each subsystem (AS) corresponds to the subsystem ele-
ments in the expanded view (ES), and are thus restricted to
consider the elements within the boundaries of each subsys-
tem in turn. Section 4.4.1 presents the composition consis-
tency conditions, which validate the interconnection between
ESs.
Furthermore, we prove in general, by means of the the-
orems and lemma in Appendix A, that the local conditions
can be generalised relying on the assertion of the composi-
tion conditions. These theorems and the lemma do not have
to be checked for each model instance as the other condition
sets do.
In order to prove that the conditions are able to validate
a model, we examine thereafter the application to a real
123
J. P. de Albuquerque et al.
SP
b
a
SP
c
SR level Real World
EAc
Fig. 6 Relation between the SR level and the real-world
environment of the configuration generated using the policy
refinement process. Section 4.5 presents assumptions about
the model capability of representing the real world environ-
ment, the so called model representativeness axioms. Thus,
two theorems are proved to follow from these axioms and
from the consistency conditions:
VT1: For each policy in the SR level, the system enables all
accesses in the real world that correspond to the policy;
VT2: To each possible access in the real world there is a
corresponding policy at the SR level.
These two theorems establish a relation between the input
for the refinement process (the policies of the SR level) and
its ultimate output (the possible accesses in the real world
that result from the implementation of the configuration gen-
erated in the refinement).1This relation is represented by the
Venn diagram of Fig. 6. The input is depicted on the left-hand
side by the SP set of service permissions (i.e. the positive
authorisation policies), and its complement set, SP, with the
negative authorisation policies. On the right-hand side, the
output is represented by the set of enabled accesses (EAc),
i.e. all potential accesses in the real world that are enabled
by the whole security system. The arrows connect each of
these accesses with its corresponding abstract representation
in the sets SP and SP. In fact, security requirements are
also part of the input, but they can be seen in this scheme
as a restriction on the relation of the abstract representation,
such that an access in the real world is only represented by
an element of the SR level if the security assumptions of
the former comply with the security requirements of the lat-
ter.
In Fig. 6, valid elements of each set are represented by
black or grey circles (for the input and output, respectively),
whilst white circles stand for invalid elements, i.e. elements
1Notice that, though the output of the refinement algorithms is the
generated configuration parameters, we are considering here the whole
refinement process and its ultimate output, i.e. the accesses enabled/dis-
abled in the real system using the generated configuration parameters.
The link between yielded configuration and system behaviour is estab-
lished by means of the axioms in Sect. 4.5.
that will not be present if the refinement is valid. Indeed,
VT1 assures that each element of SP will have all of its
corresponding accesses in the real world enabled (i.e. they
will pertain to EAc). Therefore, an SP element such as a,
which does not have a related element in EAc, will not exist
if VT1 holds (considering that all SP elements have at least
one corresponding access in the real world; see Axiom 2in
Sect. 4.5). Conversely, the existence of elements such as b
and cin EAcwould violate VT2. The belement represents
a possible real-world access that has an abstract representa-
tion in the SR level which does not pertain to the SP policy
set—thus contradicting VT2. As for c, it stands for an access
that does not have an abstract representation at all, and that
is just as well forbidden by VT2.
4.2 SR/DAS congruence
4.2.1 Refinement consistency conditions
The refinement validation from the SR to the DAS level must
assert the consistency between the two levels in respect to
both authorisation policies and security requirements. For
this purpose, the first group of conditions below concerns
the RATP refinement relation (Definition 2.3) between the
set of authorisation policies in SR (SP) and the analogous
set in DAS (ATP). To improve legibility, we will henceforth
interchangeably use the terms service permission,SR per-
mission, and the symbol sp to refer to elements in SP, i.e. to
policies in the SR level. Analogously, the terms DAS permis-
sion and ATPermission, and the symbol at p shall all indicate
an element of the ATP DAS policy set.
Before presenting the first condition, the predicate atcomp
is in sequence introduced in order to capture the compatibility
between actors and targets of the model. A compatible actor-
target pair will have corresponding processes associated to
protocol stacks that contain the same protocol types and dif-
fer only in the connection direction (outgoing for actors and
incoming for targets). Thus, they will effectively be a poten-
tial communication pair.
Definition 4.1 The predicate atcomp :A×T→{0,1}
denotes whether an actor-target pair is compatible, i.e.
whether the actor and the target are effectively able to com-
municate.
In order to facilitate the notation of service dependencies,
the condition relies also on the following auxiliary predicate.
Definition 4.2 The predicate dep :Sv×Sv×R→{0,1},
indicates if a service depends on another to access a resource.
123
Formal validation of automated policy refinement
It is recursively defined as follows:
dep[sv1,sv2,r]=
1ifsv1=sv2(sv1,sv2,r)SvDep
(sv3Sv:
(sv1,sv3,r)SvDep
dep[sv3,sv2,r])
0 otherwise
The first refinement consistency condition below aims to
establish that for each SR permission the model contains a
corresponding DAS permission, so that all the authorisation
policies in the SR level are structurally feasible in the DAS
level. Consequently, all accesses in DAS which are related
to service permissions will be completely enabled by corre-
sponding elements of the ATP policy set.
Condition 4.2.1 Let sp =(u,st,sv1,r)be a service per-
mission in SP. For each actor, aAthat refines the user-
subject type pair (u,st), and each target tTthat refines
aservice-resource pair like (sv1,r), given that aand tare
compatible, the set ATP must contain a DAS permission atp
that connects ato tand is related to sp through RATP:
sp SP,aA,tT,sv2Sv:sp =(u,st,sv1,r)
(a,u,st)RA
(t,sv2,r)RT atcomp[a,t]∧dep[sv1,sv2,r]⇒
atp AT P,atp =a,...,t:(sp,atp)RATP
Notice that sv1and sv2may be different in case of a ser-
vice dependency, i.e. if sv1must rely upon other services to
get access to the rresource. If the sv1service has direct access
to r, then sv1and sv2will be the same (see Definition 4.2).
The second condition below conversely asserts that to each
DAS permission in the ATP set, a corresponding SR permis-
sion must exist in the model. This is important so that the
enabled actions in DAS can be traced back to the abstract
policies that authorise them. Additionally, the condition also
prevents a given DAS permission to authorise actions forbid-
den by a negative policy in the SR level, since each atp is
required to be mapped to an authorising service permission.
Condition 4.2.2 Let atp =a,...,tbe an ATPermission
in ATP. Suppose there is a user uU, a subject type st St,
two services sv1,sv2Sv, and a resource rR, such that
arefines (u,st), and trefines (sv1,r). Thus, the SP set
must contain a service permission sp =(u,st,sv2,r)that is
related to atp through RATP and the sv1service must have
access to rby a dependency chain that passes through sv2
(sv1and sv2may also be the same, see Defiition 4.2):
atp AT P,uU,st St,sv1,sv2Sv, rR:
atp =a,...,t(a,u,st)RA(t,sv2,r)RT
dep[sv1,sv2,r]⇒
sp SP,sp =(u,st,sv2,r):(sp,atp)RATP
Subsequently, the third condition below shall validate the
correspondence of pairs (atp,sp)contained in the RATP
relation. This correspondence is established by checking not
only the structural connections between the system objects
related to atp and sp, but also by ensuring the satisfaction of
service dependencies and the fulfilment of security require-
ments.
The fulfilment of security requirements demands closer
examination. The first point to be considered is that secu-
rity assumptions of services that are related to the DAS ele-
ments along a given path are assumed to be active throughout
the whole path. As such, the security assumptions associ-
ated to services are used to model situations in which a cer-
tain service, with particularly desirable security properties,
is employed to improve the security level of the whole com-
munication path. For instance, a packet filter with logging
enabled may improve the traceability of all communication
flows that pass through it (in fact, encryption services that
are related to Virtual Private Network mechanisms are not
active on the whole path, but rather in the subpath between
two VPN gateways. However, since the formalism here pro-
posed can be simply adapted to reflect this fact, it is assumed,
for the sake of conciseness, that all service assumptions act
throughout the whole path).
The security class that results from the combination of the
security assumptions of all the services related to elements
along an ATPermission is called overall security assumption
and is denoted by the function osa.
Definition 4.3 Let atp =v1,...,v
nbe an element of ATP
and SvaSvthe set of services associated to the elements
of atp, such that Sva={sv|(v j,sv) RM (v j,sv,r)
RT for some 1 jn}. The function osa :AT P SC
is thus defined as
osa[atp]=
svSva
sa[sv]
The combination of the security classes is performed in
this definition by a generalisation of the binary operator
declared in Definition 2.5. It independently selects the greater
security level for each dimension of the security classes, i.e.
for each category of security requirements considered (see
also Sect. 2.3). Thus, the resulting security class reflects the
joint work of all the services involved.
We turn our attention now to the security class assured
by a given individual DAS element in the context of an AT-
Permission. There are three security assumptions that must
be considered: a) the overall security assumption of the AT-
Permission; b) the security assumption associated to the
subsystem to which the element pertains (i.e. the security
properties expected from the environment wherein the indi-
vidual is located); and c) the security class assigned to the
node itself (represented by its corresponding assumption).
These three sources of information about security properties
123
J. P. de Albuquerque et al.
correspond to different protection layers that build upon each
other. Although separately modelled, they are all active at the
same time in a given component of the real system. There-
fore, the security class effectively active in a certain DAS
object is the result of the combination of the security classes
from (a), (b), and (c)—just like a chord is the sonorous effect
of several simultaneously produced tones.
The security class that a DAS node can assure in the con-
text of an ATPermission is thus henceforth called effective
security assumption and is denoted by the function esa.
Definition 4.4 Let vbe a DAS node, such that atp AT P
contains v. The function esa :V×AT P SC is thus
defined as
esa[v, atp]=sa[v]sa [sub[v]]osa[atp]
To finish the consideration of security assumptions on this
track, let us analyse now the security properties that a path as
a whole can be expected to assure. At this plane, we follow
the principle according to which a security chain is only as
strong as its weakest link. However, since security assump-
tions enclose four categories of requirements, the assump-
tion of a whole path cannot be picked from a single object.
Rather, the weakest security level for each category must
be independently determined amongst the effective security
assumptions of each element along the path. As such, the
security assumption of the path reflects common properties
shared by all of its participating elements.
The security class that can be assured in the context of an
ATPermission is thus denoted by the function psa.
Definition 4.5 The path security assumption of an ATPer-
mission represents the security class that all elements along
the path can provide. It is given by the function psa :
AT P SC.Letatp =v1,...,v
nbe an element of
ATP; thus:
psa[atp]=
1jn
esa[vj,atp]
This definition relies upon a generalisation of the binary
operator declared in Definition 2.5. It selects the lowest
values independently for each dimension of the security clas-
ses—thus yielding the desired result for the whole path.
Figure 7illustrates the previous concepts with a path
example and its associated security assumptions. The ppath
comprises four nodes (v1v4) which are distributed over
three different subsystems (sub1,sub2and sub3). The grey
tones reflect the security assumption of each element, such
that the darker the background colour of a given object, the
higher (stronger) the security level that it can provide. Notice
that the security classes consist of a vector of four levels, but
in this example only one level is considered for the sake
of clarity. For instance, the v1node is assumed to ensure
esa[v3,p]=2
osa[p] = 2
esa[v4,p]=3esa[v1,p]=4
psa[p]=2
esa[v2,p]=2
sa[v3]=1
sa[sub2]=1
sa[v2]=2
sa[sub1]=2
v4v3v2v1
sa[v1]=4
sa[sub3]=3
sa[v4]=2
Fig. 7 Example of active security assumptions in a path
level 4 (sa[v1] = 4) even though the subsystem to which it
belongs has an assumption of level 2 only (sa[sub1] = 2).
The effective security level that v1is assumed to provide
in the path is then a combination of the previous two levels
with the overall path assumption of p—which is of level 2,
i.e. osa[p]=2—, resulting in an effective security assumption
of level 4 (esa[v1,p] = 4). On the other hand, nodes v2and
v3are the weakest in the path since their effective security
assumption amount only to level 2. Consequently, the path
security assumption of pis also of level 2, i.e. psa[p] = 2.
Finally, relying upon the aforementioned considerations,
we can define the third refinement consistency condition as
follows:
Condition 4.2.3 Let sp =(u,st,sv, r)be a service per-
mission in SP and atp AT P an ATPermission, such that
sp =(u,st,sv, r),atp =v1,...,v
n,, and the two are
related by RATP, i.e. (atp,sp)RATP. Hence the fol-
lowing propositions must hold:
(i) the actor aAmust refine the user-subject type pair
(u,st);
(ii) the target tTmust refine a service-resource pair
like (svt,r);
(iii) actor aand target tmust be compatible (Defini-
tion 4.1);
(iv) the path security assumption of atp must fulfil the
security requirements of sp;
(v) for each service svdon which svdepends to provide
resource r, either svdis the svtservice related to the
target or a mediator that refines svdmust be found
along atp.
Formally stated:
atp AT P,sp SP :
atp =v1,...,v
n,sp =(u,st,sv, r)
(sp,atp)RAT P
(v1,u,st)RA(vn,svt,r)RT atcomp[a,t]
sr[sp]≤ psa[atp]∧∀svd:dep[sv, svd,r]⇒
123
Formal validation of automated policy refinement
tam
ru st svdsv
svdep
sp
atp
Fig. 8 Example of correspondence between a service permission and
an ATPermission
svd=svt∨∃vj:(v j,svd)RM for 1 <j<n
A generic example of an spservice permission and its cor-
responding atp is shown in Fig. 8. Each of the required items
in Condition 4.2.3 can be seen to be satisfied by atp except
for the security class compliance, which is not depicted by
objects, but is represented in their properties.
4.2.2 Structural consistency conditions
The following conditions impose structural restrictions for
the connections amongst DAS elements and SR elements,
and also in relation to the ATP policy set of the DAS level.
Condition 4.2.4 Let aAbe an actor in the model. Thus,
there must exist a user uUand a subject type st St,
such that ais associated to the pair (u,st):
aA⇒∃uU,st St :(a,u,st)RA
Condition 4.2.5 Let tTbe a target in the model. Thus,
there must exist a service svSvand a resource rR,
such that tis associated to the pair (sv,r):
tT⇒∃svSv,rR:(t,sv,r)RT
Condition 4.2.6 (DAS Edge Minimality)Letv1,v
2Vbe
two nodes in DAS, such that there is an edge connecting
them. Thus, there must be some permission atp AT P that
contains the edge (v1,v
2):
v1,v
2V:(v1,v
2)E⇒∃atp AT P :v1,v
2atp
Condition 4.2.7 Let v1,v
2be two vertices in DAS which are
not connectors, and c1,c2Cbe two connectors. Suppose
there is a DAS path that connects v1to v2passing through c1
and c2. Thus, there must exist a permission atp AT P that
includes the path v1,c1,c2,v
2:
v1,v
2(VC), c1,c2C:v1,c1,c2,v
2P
⇒∃atp AT P :v1,c1,c2,v
2atp
4.3 DAS/ES congruence
4.3.1 Refinement consistency conditions
Definition 4.6 Consider a DAS path ap Pin an expanded
path ep EP (see Definitions 3.3 and 3.4). Let ap =
v1,...,v
n, and let e1,...,embe the ordered sequence of
processes and connectors of ep, i.e. the sequence of elements
in ep in the order they occur, such that eiPc C,for
1<i<m. The predicate expand :P×EP →{0,1}is
true if an expanded path is a valid expansion of a DAS path,
and is defined as follows:
expand[ap,ep]⇔m=n((ei,v
i)RPc ei=vi)
for 1 im
Condition 4.3.1 Let atp =a,...,tbe an element of ATP.
Suppose there are two processes pca,pctPc, such that
pcarefines the aactor and pctrefines the ttarget. Thus, an
allowed expanded path aep =pca,...,pctmust exist in
AEP, such that aep is a refinement and a valid expansion of
atp:
atp AT P,pc1,pc2Pc :atp =a,...,t
(pca,a), ( pct,t)RPc
⇒∃aep AEP,aep =pca,..., pct:
(aep,atp)RAEP expand[aep,atp]
Condition 4.3.2 Let aep be an allowed expanded path in
AEP.Thus,anatp must exist in ATP such that aep refines
and is a valid expansion of atp:
aep AEP ⇒∃!at p AT P :
(aep,atp)RAEP expand[aep,atp]
4.4 Local structural consistency conditions
The following auxiliary predicates are defined to improve
legibility of the conditions presented later in this section.
Definition 4.7 An expanded path in the model (Defini-
tion 3.4)issaidcompatible if it represents a valid path, i.e. if
it connects processes through valid protocol stacks and con-
nectors. The predicate compatible :EP →{0,1}indicates
if an expanded path is compatible.
This predicate is not formally defined, since it depends
on model details that are not formalised, such as which pro-
tocol stacks are compatible, and which process types may
be traversed (i.e. which ones can act as gateways). All those
details are irrelevant for the purposes of this validation and
are thus abstractly treated by means of the above predi-
cate.
123
J. P. de Albuquerque et al.
Definition 4.8 A local ES path (Definition 3.4)issaid
locally connected if it connects two processes and is compat-
ible. This fact is denoted by the predicate lconn :LEP
{0,1}, formally defined as
lconn[ep]⇔ pc1,pcnPc
v2,...,v
n1(WPc)compatible[ep]
which leads us to introduce a first set of conditions to deal
with the DAS/ES refinement relations:
Condition 4.4.1 Let vbe an actor or target in DAS. Thus, a
process pc Pc must exist that refines v:
vAT⇒∃pc Pc :(pc,v) RPc
Condition 4.4.2 Let mbe a mediator in M. Thus, a unique
process pc Pc must exist that refines v:
mM⇒∃!pc Pc :(pc,m)RPc
Condition 4.4.3 Let pc be a process in Pc. Thus, an element
in DAS must exist that is refined by pc:
pc Pc ⇒∃!vAMT:(pc,v)RPc
Condition 4.4.4 Let uc be a user credential in Uc,abe an
actor in Aand ubeauserinU, such that uc refines (a,u).
Thus, a subject type st St must exist, such that arefines
(u,st):
uc Uc,aA,uU:(uc,a,u)RUc
⇒∃st St :(a,u,st)RA
The following conditions are then related to the correspon-
dence between DAS edges and local ES paths.
Condition 4.4.5 Let v1,v
2Vbe elements of DAS, and
let pc1,pc2be processes in the corresponding ES, such that
there is a DAS edge (v1,v
2)E,pc1refines v1and pc2
refines v2. Thus, a local ES path must exist that connects pc1
to pc2and is locally connected (Definition 4.8):
v1,v
2V,pc1,pc2Pc :
(v1,v
2)E(pc1,v
1), ( pc2,v
2)RPc
⇒∃ep =pc1,...,pc2:lconn[ep]
Condition 4.4.6 Let pc1,pc2Pc be two processes
that are connected by a locally connected ES path ep
(Definition 4.8). Thus, two DAS nodes v1,v
2Vmust
exist such that pc1refines v1,pc2refines v2, and there is a
DAS edge (v1,v
2)E:
ep=pc1,..., pc2:lconn[ep]
⇒∃ v1,v
2V:(pc1,v
1), ( pc2,v
2)RPc(v1,v
2)E
4.4.1 Composition consistency conditions
The following auxiliary predicate is used in the conditions
presented later in this section.
Definition 4.9 An expanded path (Definition 3.4) is consid-
ered connector connected if it is compatible and connects
a process of a subsystem to another process in an adjacent
subsystem (through a pair of connectors) without traversing
other processes along the way. Formally stated:
cconn[ep]⇔ep =w1,...,w
k,c1,c2,w
k+1,...,w
n:
w1Pc wnPc w2,...,w
n1(WPc C)
compatible[ep]∧c1,c2C
w1,...,w
k,wk+1,...,w
nLEP
vk,c1,c2,v
k+1EP
Conditions analogous to the previous section’s are thus
defined to deal with the correspondence between DAS edges
and connector-connected paths.
Condition 4.4.7 Let v1,v
2Vbe two DAS elements that
pertain to adjacent subsystems, such that they are linked
by a pair of connectors, i.e. the DAS contains the path
v1,c1,c2,v
2. Suppose that pc1,pc2Pc are processes
such that pc1refines v1and pc2refines v2. Thus, a connec-
tor-connected path must exist that goes from pc1to pc2:
v1,v
2V,c1,c2C,pc1,pc2Pc :
v1,c1,c2,v
2P(pc1,v
1), ( pc2,v
2)RPc
⇒∃ep =pc1,..., pcn:cconn[ep]
Condition 4.4.8 Let pc1and pc2be two processes that
are connected by a connector-connected path ep. Thus, two
DAS nodes v1,v
2Vmust exist such that pc1refines
v1,pc2refines v2, and the model contains the DAS path
v1,c1,c2,v
2:
ep =pc1,..., pc2:cconn[ep]
⇒∃v1,v
2V,c1,c2C:
(pc1,v
1),(pc2,v
2)RPcv1,c1,c2,v
2P
4.5 Model representativeness axioms
In this section, we consider the relationship between a model
instance and the environment in the real world that the model
aims to represent. The intent is to identify the underlying
assumptions one must postulate about the model represen-
tativeness, i.e. the expected capability of the model to accu-
rately reflect the real environment it depicts. Stated another
way, our concern here is to determine key aspects in the real
world that must be correctly captured by the model, so that
the policy refinement process produces a trustworthy result.
123
Formal validation of automated policy refinement
To accomplish this goal, the first step is the formalisation
of the relevant entities of the real world that are not pres-
ent in the model. Subsequently, axioms define the required
relations between the formalised real entities and modelled
objects.
4.5.1 Accesses and their abstract representations
As explained in Sect. 4, the main interest of this validation
relies upon examining the ultimate output of the policy refine-
ment process, i.e. the accesses that might take place in the
real-world environment. To this concern, the relevant sets are
formalised by the following definition.
Definition 4.10 The real environment comprises the follow-
ing sets:
Ac, the set of all potential accesses in the real-world
environment that must be considered;
EAc Ac, the subset that contains those accesses that
are enabled by the security system.
The expression potential access in the real world that must
be considered means a potential communication flow in the
real-world environment that starts from an initiator process
and is directed to another (responding) process—it is hence-
forth simply called access in the real environment,forthe
sake of conciseness. An access enabled by the security sys-
tem, in turn, indicates a communication flow which is allowed
to pass through all security mechanisms along the network
path between the initiator and responding processes.
The explanation above already anticipates the relation
between an access in the real world and the lowest model level
(ES). Indeed, if an access in the real environment stands for
a communication flow between processes, these processes
should be represented in some expanded subsystem of the
corresponding model instance. Moreover, within the scope
of a given access, the initiator process is actually acting on
behalf of a user, which is identified in the real environment
by means of a user credential. The responding process of the
same access, on the other hand, is performing some operation
on a particular system object. As such, user credentials and
system objects are also connection points between accesses
in the real environment and the model instance. These con-
siderations are formalised by our first axiom as follows.
Axiom 1 Each access in the real environment is associated
toa4-tuple(uc,pci,pcr,so), where uc Uc is the user
credential associated to the initiator process pciPc, and
pcrPc is the responding process that in turn handles the
system object so So. Thus, the Ac set can be represented
as a relation on the respective ES-level sets:
Ac Uc×Pc ×Pc ×So
It is worth remembering here that a process in the ES
level represents a prototype for actual processes that might be
started in the real environment (Sect. 2.4). As such, the rela-
tion established by Axiom 1between processes and accesses
in the real environment imposes that the latter will also stand
for the prototype of actual accesses, or as stated previously,
for potential accesses in the system that share some common
properties. These common properties are thus each of the
4-tuple dimensions mentioned in Axiom 1.
An observation is due here, since the axiom states that
all potential accesses are a subset of the set of 4-tuples link-
ing user credentials, processes and system objects. From an
administrator’s point of view, this is at first glance hard to
accept, for mapping all possible accesses on a given net-
work scenario is a daunting task due to the large number
of alternatives, be them simple or more complex ones, and
that knowledge would not be available to the administrator.
It must be clear, then, that the set of 4-tuples to be consid-
ered will normally turn out to be quite smaller than initially
thought and the statement will make sense. The reason is that
the administrator, when modelling the system, does not have
to cover all possible accesses the network technology allows,
but rather only the accesses the security policy to be imple-
mented should allow. Security is achieved because forbidden
accesses (the complement of the set of policy-allowed acces-
ses) are automatically blocked due to the adoption of closed
policies (see fourth paragraph of Sect. 3.1).
Hence, the axiom establishes that each access to be con-
sidered can be described in terms of system objects in this
way: the pciprocess, on behalf of the uc user credential,
communicates with the pcrprocess that manipulates the so
system object. But we can just as well describe the access by
means of the corresponding abstract entities like this: the u
user logged in the system as the st subject type is using the sv
service in order to access the rresource. And these two quite
different expressions refer to one and the same phenomenon
in the real world—an access—though each one of them at a
different abstraction level. Thus, we must establish a means
of formalising this correspondence, by connecting accesses
in the real environment to abstract entities of the model. This
job is accomplished by Definition 4.11 as follows.
Definition 4.11 The correspondence between an access in
the real environment and the SR level is denoted by the func-
tion abstract-rep :Ac U×St ×Sv×R. The 4-tuple
(u,st,sv, r)returned by the function is the abstract repre-
sentation of a given access in the set Ac.2
The reader may be asking him/herself at this point: why
is the access mapped to a representation at the SR level?
Why not any other model level? This choice is not arbitrary;
2Functions in this section are assumed to exist in the environment and
stand out with a different typeface.
123
J. P. de Albuquerque et al.
instead, it is due to the fact that the SR level is the top-
most level considered in the validation (see the beginning
of Sect. 4). As such, the SR representation offers the refer-
ence for the expected system behaviour in the context of the
present validation.
The use of a function to map this relation is also by no
means accidental. The assumption behind it is that for each
access in the real environment there is one unique abstract
representation at the SR level. Conversely, each 4-tuple
(u,st,sv, r)can be the abstract representation of one or more
real accesses. Indeed, for each of such 4-tuples, there will
usually be several corresponding potential accesses in the
real environment, for an abstract entity represents, in gen-
eral, a group of similar lower-level objects.
An additional point that is worth mentioning here is that
the service dependencies of the SR level (see Sect. 4.2.1)are
by purpose left out of the analysis in this section and in the
validation theorems of Sect. 6.
This is done in order to simplify the assumptions and
proofs, such that one can more clearly perceive their intent
and meaning. Nevertheless, these results and assumptions
could simply be changed to cover dependencies by the addi-
tion of extra conditions to the statements. Therefore, leaving
dependencies out does not consist on a limitation for the val-
idation presented here.
From this background, we can reinterpret the SP set of
policies in the SR level. Since its elements are 4-tuples in
the form (u,st,sv, r)that represent positive authorisation
policies, the set can be seen to enclose the abstract repre-
sentations of those accesses that must be enabled in the real
environment. As such, each element of SP must have a cor-
responding potential access (otherwise the policy could not
be enforced), i.e. each service permission must be an abstract
representation of some element of Ac. This fact is formalised
by the following axiom.
Axiom 2 Each element of SP is the abstract representation
of at least one access in the real environment in the set Ac.
In a formal notation:
sp SP ⇒∃ac Ac :sp =abstract-rep[ac]
In addition to that, we must now analyse the model struc-
ture that reflects the relation of abstract representation defined
above. In order to yield valid results, the model structure must
correctly represent the correspondence between each access
in the real environment and its abstract representation at the
SR level. For each 4-tuple (uc,pci,pcr,so)that stands for
an access in the real environment, the model structure must
thus connect the objects in each dimension of that tuple with
the objects of the corresponding abstract representation in the
SR level, i.e. with the objects of the corresponding 4-tuple
(u,st,sv, r). The connection is established through actor
and targets as illustrated in Fig. 9. Hence, an aactor is con-
nected to both the user credential and initiator process pair
ust sv r
at
uc pci pcr so
SR
ES/
DAS
Real System
Fig. 9 Correspondence between accesses in the real environment and
the SR level
(uc,pci), and to the user and subject type pair (u,st)—thus
establishing the correspondence between them. Analogously,
attarget is connected both to the responding process and sys-
tem object pair ( pcr,so) and to the service and resource pair
(sv,r).
Therefore, a well-defined model instance must contain in
its structure one such connection between each access and
the corresponding abstract representation. This fact is forma-
lised by the following axiom.
Axiom 3 The model structure correctly represents the cor-
respondence between accesses in the real environment and
their abstract representations. Let (uc,pci,pcr,so)Ac
be an access in the real environment, such that the 4-tuple
(u,st,sv, r)is its abstract representation at the SR level.
The model structure must thus contain:
(i) an actor that is connected to both the user credential
and initiator process pair (uc,pci), and to the user and
subject type pair (u,st);
(ii) a target that is connected both to the responding pro-
cess and system object pair ( pcr,so) and to the service
and resource pair (sv,r);
(iii) actor aand target tmust be compatible (see Defini-
tion 4.1);
(iv) a host that is connected both to the pcrresponding
process and to the so system object.
Formally stated:
(u,st,sv, r)=abstract-rep [(uc,pci,pcr,so)]
⇔∃aA,tT:(a,u,st)RA(t,sv, r)RT
atcomp[a,t]
(uc,a,u)RUc (pci,a), ( pcr,t)RPc
(so,t)RSosamehost[pcr,so]
In order to simplify the notation, the axiom relies upon
the predicate samehost defined as follows:
123
Formal validation of automated policy refinement
Definition 4.12 The predicate samehost :Pc ×So
{0,1}denotes if a process and a system object are connected
to the same host. It is defined as:
samehost[pc,so]⇔∃hH:(h,pc), (h,so)W
4.5.2 Authentication and enabled accesses
We must now examine the circumstances in which an access
is enabled by the system in the real environment. For this
purpose, let us first define some predicates in order to reflect
the relevant facts in the real environment.
Definition 4.13 The following predicates map the system
behaviour in the real environment:
can-use :Uc ×Pc →{0,1}denotes whether a user
credential can be used to launch a given process in the
real environment, a condition defined as:
can-use[uc,pc]=
1iftheuc credential can be used
to access process pc
0 otherwise
can-handle :Pc ×So →{0,1}denotes whether a
process is able to handle a system object in the real envi-
ronment, defined as:
can-handle[pc,so]=
1ifthepc process can handle
the so system object
0 otherwise
Concerning the possibility of a user credential starting a
process in the real environment, the assumption is that the
actors in the model represent all such possibilities, i.e. a given
credential is able to start a certain process in the real envi-
ronment if, and only if, both are connected to the same actor
in the model, formalised in the next axiom.
Axiom 4 A credential uc Uc is able to start the process
pc Pc in the real environment if, and only if, there is
an actor aAin the model such that uc and pc are both
connected to a:
can-use[uc,pc]
⇔∃aA,uU:(uc,a,u)RUc (pc,a)RPc
Notice that the above axiom requires the system to be able
to correctly identify and authenticate the user credential, and
that the privileges for starting processes be enforced in con-
formance with the modelled actors. As in most access control
models (as pointed out by Sandhu [20]), this work assumes
that identification and authentication of users take place in
a secure and correct manner, and the main concern is with
what happens afterwards.
Analogously, a process is assumed to be able to access a
system object if, and only if, both are connected to the same
host and to the same target in the model. Here, the criterion of
the same host has to be introduced to avoid pairs of process
and system object, though connected to the same target, being
placed on different machines, an assumption formalised as
follows:
Axiom 5 A process pc Pc can manipulate a certain sys-
tem object so So in the real environment if, and only if,
both pc and so reside in the same host and are connected to
the same target tTin the model:
can-handle[pc,so]⇔samehost[pc,so]
∧∃ tT:(pc,t)RPc(so,t)RSo
We can now proceed to analyse accesses that are enabled
by the system in the real environment. In this respect, the
system is assumed to correctly enforce the system view
defined at the lowest model level (ES), i.e. the mechanisms of
the real-world environment are expected to only permit the
passing through of those communication flows that corre-
spond to allowed expanded paths in the model. This assump-
tion requires the correct implementation of the configuration
according to the lowest-level policies in the model, as in the
next axiom:
Axiom 6 (Correct Implementation) Suppose the real-world
system enables an access eac EAc, such that eac =
(uc,pc1,pcn,so).Let pc1,..., pcnbe the sequence of
processes along the communication path between the ini-
tiator process pc1and the responding process pcn.Thefol-
lowing propositions must hold:
(i) the uc credential can be used to access the pc1pro-
cess;
(ii) process pcncan handle the so system object;
(iii) there is an allowed expanded path aep AEP in the
model, such that aep =pc1,..., pcn, i.e. aep con-
tains exactly the same process sequence pc1,...,pcn
of eac.
Formally stated:
eac EAc :eac =(uc,pc1,pcn,so)
can-use[uc,pc1]∧can-handle[pcn,so]∧
aep AEP :
aep =pc1,..., pcn
To complete the analysis of an access in the real envi-
ronment, one must also consider the security class within
which the access takes place. This security class depends
on the security assumptions of all the processes along the
communication flow between the initiator process and the
123
J. P. de Albuquerque et al.
responding process. First, we must then define a function to
map these security assumptions:
Definition 4.14 The function pc-esa :Pc ×Eac SC
gives the effective security assumption of a process in the
context of an enabled access in the real environment.
Subsequently, since Axiom 6implies that for each enabled
access (say eac) there is a corresponding allowed expanded
path in the model (say aep), each process along the commu-
nication path of eac is assumed to enforce the same security
class as that assured by the corresponding process object in
the context of aep, i.e. the effective security assumption of
Definition 8.2 in Sect. A.3. This assumption follows from a
correct attribution of security classes to objects in the model.
The model must be consistent with respect to the classifica-
tion of model objects, so that the effective security assump-
tion of processes correspond to the security properties of the
entities in the real environment, according to the following
axiom:
Axiom 7 Let eac EAc be an enabled access in the
real environment, such that eac =(uc,pc1,pcn,so)and
pc1,..., pcnis the sequence of processes along the com-
munication path between the initiator process pc1and the
responding process pcn. Assume aep AEP to be an
allowed expanded path in the model that corresponds to eac;
i.e. both eac and aep have exactly the same process sequence
pc1,..., pcn(Axiom 6guarantees the existence of such a
path). Therefore, each process in the sequence is assumed
to enforce the same security class in the real environment
as that of the effective security assumption assured by the
corresponding process object in the context of aep (see Def-
inition 8.2 in Sect. A.3). Formally stated:
eac EAc,aep AE P :
eac =(uc,pc1,pcn,so), aep =pc1,..., pcn
pc-esa[pcj,eac]=esa[pcj,aep]for 1 jn
Finally, we must consider the security class one can expect
of an access as a whole. Analogously to the psa and psa
functions (Definitions 4.5 and 8.3), the security assumption
of the access must reflect the security class that all the ele-
ments along the path are able to enforce. This is denoted by
the following function.
Definition 4.15 The function acc-psa :Eac SC gives
the path security assumption of an enabled access in the real
environment, i.e. the security class that all elements within
the scope of an allowed communication flow in the real envi-
ronment can provide. Let eac be an element of EAc, such that
eac =(uc,pc1,pcn,so)and pc1,..., pcnis the sequence
of processes in the communication flow of eac, thus:
acc-psa[eac]=
1jn
pc-esa[pcj,eac]
5 Practical application and use example
The approach has shown its practical relevance in a series
of case studies [7,8,10]. A supporting tool was imple-
mented and has been employed for the integrated config-
uration management of packet filters and VPN gateways
of realistic network environments, with different number
of network elements and growing security policy complex-
ity. Back-end functions were implemented for the genera-
tion of configuration files of the corresponding mechanisms
of the OpenBSD operating system (pf and isakmpd), suc-
cessfully covering the basic functionalities of these mecha-
nisms.
A comprehensive covering of these application cases lies
outside the scope of the present paper as it is done else-
where [7,8,10]. To give a flavour of the results achieved,
though, Fig. 10 shows a simple model example produced
with the associated software tool that illustrates the practical
use of our approach in a common situation. The high-level
policies modelled allow the employees of a branch office to
access the company’s web server located at the main office’s
network, which is accessible via the Internet. However, the
security requirements associated to the service and resources
of this example require security levels that are not fulfiled
when the communication is performed directly through the
Internet, since the security assumption of the AS “Internet”
(1,1,1,1) is lower than required one (2,2,2,2). Thus, the tool
automatically finds out and selects the path that connects
the main office with the branch office via a VPN tunnel
established by the two VPN gateways. In Fig. 10 the policy
objects (Sect. 3.2)ServicePermission,ATPermission, and the
allowed expanded path ADP are automatically generated by
the tool.
In the example of Fig. 10, the DAS path of ATPermis-
sion—which goes from intern Client to Webserver passing
through VPN Gateway 1, three conectors, and VPN Gate-
way 2—is able to fulfil the requirements due to the tunnel
established by EncryptionService between VPN Gateway 1
and VPN Gateway 2. Clearly, should the requirements be ful-
filed without the VPN tunnel—for example, if the require-
ments were set to (1,1,1,1)—the refinement algorithm would
again choose the shortest path available, this time effectively
bypassing the two VPN gateways and not generating any
configuration for processes “isakmpd 1” and “isakmpd 2”.
In order to generate the configuration files from the derived
lower-level path (ADP), the properties of the involved objects
must be provided as follows.
–FortheCertificate, the property distinguished Name
must be set with the name of the Certificate Authority
that signs the certificate.
–TheIP address used for the communication with the
other gateways must be inputted in the corresponding
123
Formal validation of automated policy refinement
internet (1,1,1,1)
main office (2,2,2,2)
VPN 2
VPN Gateway 2
certificate 2
isakmpd 2
webserver
htt pd website
server
192.168.1.2 10.2.0.200
em0
80
branch office (2,2,2,2)
PC VPN 1
intern client
VPN Gateway 1
UserCredential
certificate 1
isakmpd 1
opera
192.168.1.110.1.0.100
pcn0
@main office i nternal user
employee
webpagesWWWService
allow internet surfing
internet wwwsurfing
SecurityGoal
SR (2,2,2,2)EncryptionService
ServicePermission
SR_max (2,2,2,2)
SA_max (1,1,1,1)
ATPermission
ADP
Fig. 10 Simple VPN model after the automated refinement
property of the IPSec protocol object that is associated
to the VPN process.
–Thenetwork address and network mask of the network to
which the VPN gateway is connected must be provided
in the corresponding object properties.
As such, the implemented tool generates configuration
files for the two VPN gateways based on the analysis of the
model and on the provided information. Additionally, the tool
also enforces the validation conditions defined in Sect. 4.
From the standpoint of the practical application, these
conditions can be sorted into three groups. The first con-
dition group is checked on the fly as the modeller defines the
objects and associations in the diagram. Each condition in
this group reflects a simple relation between objects in the
model and it is checked either: (a) whenever an object is cre-
ated; (b) whenever a new association between two objects is
defined—i.e. a new edge is drawn in the diagram; (c) when-
ever the modeller launches the menu option “Check Model”
in the tool. This first group consists of the pre-conditions for
the algorithm of the respective refinement step (SR/DAS or
DAS/ES). The second condition group comprises conditions
that must be present in the model after the execution of the
refinement algorithm at a given step. Therefore, they are the
post-conditions for the respective refinement algorithm and
are thus achieved by the algorithm. The third condition group
is in turn composed of additional conditions that must be ver-
ified after the refinement algorithm is performed (for details
in the implementation of the conditions into the software tool
refer Porto de Albuquerque [6]).
The enforcement of these conditions as a whole is thus
capable of validating the multi-layered structural architecture
of the system vis-à-vis the security policies prescribed. As a
matter of fact, experience has shown that in practice the given
network systems are often not able to enforce the claimed
high-level policies unless additional protection mechanisms
are introduced. In such cases, some of the validation condi-
tions defined here cannot be satisfied, and the tool indicates
the model elements which violate the policies. This way the
modeller receives valuable information to design the neces-
sary extensions to the system in order to make it congruous
to the policies.
We can illustrate this still with the example of Fig. 10:
if there were no VPN gateways in any of the networks, the
tool would inform the user that no path could be found to
satisfy the security requirements. The user would thus find
out that there is a need to add a security mechanism that pro-
vides encryption services, thereby supporting the security
level required for implementing the high-level security poli-
cies.
123
J. P. de Albuquerque et al.
6 Discussion of the validation results and soundness
Based on the axioms of Sect. 4.5, the validation theorems
proposed in Sect. 4.1 are now formalised.
Validation Theorem 1 (VT1) For each policy in the SR
level, the system enables all accesses in the real environment
that correspond to the policy:
spSP,ac Ac :sp =
abstract-rep
[ac]⇒acEAc
Validation Theorem 2 (VT2) For each enabled access in
the real environment, there is a corresponding policy at the
SR level:
ac EAc
sp SP :sp =
abstract-rep
[ac]∧sr[sp]
acc-psa
[ac]
The two theorems can be shown to follow from the condi-
tions and axioms previously defined—which is accomplished
in Appendix B. By analysing the two validation theorems,
one can conclude that they ensure the compliance of the pol-
icy sets with the validation criteria defined in the beginning of
Sect. 4. Indeed, VT1 implies that the real system enables all
accesses in the real world that correspond to the SR level pol-
icies specified, such that the completeness criterion is thereby
satisfied. As for the satisfaction of consistency,VT2 asserts
that for each possible access in the real world, a correspond-
ing policy exists at the SR level in the model. These criteria
are cited in the literature as the most important ones to assure
the refinement correctness in a multi-layered policy hierar-
chy (refer for instance, Abrams and Bailey [1] and Sloman
and Lupu [24]). Indeed, in the particular context of this work,
the criteria ensure that the special meaning conveyed by pol-
icies and system model—i.e. at the same time representing
the positive and negative prescriptions for system duties and
for user privileges (see Sect. 3.1)—be propagated and main-
tained from one abstraction level to its immediate inferior
neighbour.
Therefore, the formal proofs mean that: provided that a
model (including system and policy representation after a
process refinement) fulfils the defined condition sets, and
that this model accurately represents a real-world environ-
ment (i.e. the axioms hold), one can conclude that the gener-
ated output—i.e. the possible system behaviour that results
from using the generated configuration—is exactly in confor-
mance with the input—i.e. the system view and the policies
at the most abstract level considered (SR). As such, the whole
system can be seen to act as a reference monitor in the access
control terminology [22], which allows only those accesses
enabled by the access control policies.
The computational effort required by the verification of
the defined conditions has been analysed in [6]. To that
respect, the DAS level can afford to split up the system anal-
ysis, i.e. it allows the validation to be performed in a mod-
ular fashion, which is more appropriate when dealing with
large models. Indeed, the DAS/ES structural conditions have
a local scope and thus limit to consideration only the ele-
ments inside the boundaries of one subsystem at a time, so
that the analysis process can be performed independently
on each subsystem. The system-wide validity of those local
conditions is proved by means of generalisation theorems
and a lemma, which do not have to be checked for each par-
ticular model instance. Therefore, the more complex a sys-
tem is, the more beneficial will be the introduction of DAS
in the validation cost, since the complexity of all subsys-
tems but one is hidden during the execution of each local
test.
It should be noted that the accesses in the real world are
not represented in the model, since the modelling technique
used in this work is based on a static picture of the system. As
such, policy semantics and system behaviour are not explic-
itly/formally modelled (as in the work of Burns et al. [3], ana-
lysed in Sect. 7), but rather implicitly assumed. The model
representativeness axioms of Sect. 4.5 thus serve to make
explicit the assumptions that are implicit in the modelling,
thereby allowing us to draw conclusions about the system
functioning behind the model. In this manner, the axioms
reflect assumptions concerning both the correct modelling
of the real-world entities, and the correct implementation of
the normative model elements.
Security goals and requirements, in turn, should be actu-
ally seen as a prescription of modes in which accesses may
take place. They complement the access control policy by
adding contextual information, thus having a subordinate
character. This means that, in isolation, they do not have a
meaning of their own, rather they only acquire significance
together with an access permission by modifying (restrict-
ing) the modelled authorisation. They act just like adverbs
in the natural language, which are used to imprint a different
connotation to verbs and adjectives. Consequently, the secu-
rity requirements and assumptions in this work are not to be
directly compared with clearances and labels of traditional
mandatory policies in lattice-based access control models
[20], as the latter have a much stronger, independent charac-
ter (although there is of course some resemblance between
the two concepts).
Furthermore, the requirement support is left flexible
enough, so that it is possible to address the needs of different
scenarios, depending on how fine-grained and comprehen-
sively one would like to verify the requirement assurance by
the system. For instance, a modeller may expand the catego-
ries above to encompass all functional classes prescribed by
the Common Criteria [4], by adjusting the vector dimension
and the level range in order to map families and components
in each of those classes. For the purpose of the present work
123
Formal validation of automated policy refinement
though, the simplified approach that was adopted is suffi-
cient.
7 Related work
Guttman [13] presents an approach that defines a security
policy for packet filters in a logic-based language, as a
global policy about which packets can get where. It has the
advantage of offering an additional method for solving the
localisation problem—i.e. to determine the filtering deci-
sions of individual routers—and an automated verification
method for the localisation problem. Burns et al. [3] present
a tool that, given a security policy specified in prolog-based
language, automatically checks that the configuration of a
network with multiple firewalls adheres to the policy. The
network topology, mechanism configuration, and behaviour
are also represented by logic assertions, so that a policy
engine is able to verify the compliance of the network
state against the specified policy. These two logic-based
approaches have the advantage of offering scalability gains
and more comprehensive analysis capabilities, allowing the
formal evaluation of system security properties. However,
the syntax used is both far from the expert system view and
from a business view of the problem, requiring extra training
for the correct policy specification.
The graphical tool Firmato [2] offers a more intuitive
approach, since it supports the interactive policy design by
means of diagrams, and automatically derives the corre-
sponding configurations for mechanisms. However, this and
the other approaches aforementioned are mostly concerned
with a low-level view of the management problem. These
works proceed bottom-up, starting from the mechanisms to
be configured and achieving representation languages that
are too bound up with the mechanism types initially consid-
ered. On the other hand, there are already some approaches
that turn the problem onto the right direction by starting from
convenient abstract models that are able to address the man-
agement problem from a business point of view.
The Power prototype [19] aims at supporting the build-
ing of policy hierarchies by means of a tool-assisted pol-
icy refinement. The tool is then able to refine the high-level
policy according to pre-defined templates and finally pro-
ducing the configuration information for particular devices.
Cuppens et al. [5] present a more formal approach for spec-
ifying network security policies, which is based on the
Or-BAC model, an extension of the Role-Based Access Con-
trol Model (RBAC). This work has the advantage of using the
formal syntax of access control models to represent policies,
yielding a higher-level view of the network policy. However,
both approaches lack analysis capabilities, so the problem
of correctness in the policy refinement is left open, i.e. the
question whether the generated lower-level policies uphold
the abstract policy remains not answered.
8 Conclusion
This paper introduces a formal approach to the validation of
policy hierarchies for the model-based management (MBM)
of the configuration of network security systems. This vali-
dation builds upon a formalism for the modelling framework
that appeared in previous works [7,8