RELIABLE PROCESS FOR SECURITY POLICY DEPLOYMENT

Stere Preda

†

, Nora Cuppens-Boulahia

†

, Fr

eric Cuppens

†

, Joaquin G. Alfaro

†,‡

and Laurent Toutain

†

GET/ENST Bretagne, 2 rue de la Ch

ataigneraie, 35512 Cesson S

evign

e, France

‡

Universitat Oberta de Catalunya, Rambla Poble Nou 156, 08018 Barcelona, Spain

Keywords:

Network Security, Security Devices, Security Rules, Deployment of Policies, Policy Anomalies.

Abstract:

We focus in this paper on the problem of conﬁguring and managing network security devices, such as Fire-

walls, Virtual Private Network (VPN) tunnels, and Intrusion Detection Systems (IDSs). Our proposal is the

following. First, we formally specify the security requirements of a given system by using an expressive access

control model. As a result, we obtain an abstract security policy, which is free of ambiguities, redundancies

or unnecessary details. Second, we deploy such an abstract policy through a set of automatic compilations

into the security devices of the system. This proposed deployment process not only simpliﬁes the security

administrator’s job, but also guarantees a resulting conﬁguration free of anomalies and/or inconsistencies.

1 INTRODUCTION

Specifying, deploying and managing access control

rules for a network architecture is one of the main

tasks of a security administrator. These rules are usu-

ally implemented by different security devices, such

as ﬁrewalls, virtual private network (VPN) tunnels

and intrusion detection systems (IDSs). The conﬁg-

uration of these devices must be compatible with an

established security policy. In order to ensure this

compatibility in the case of a simple network architec-

ture, the conﬁguration of the security devices may be

obtained directly by translating the security require-

ments into packages of speciﬁc rules for each of these

devices. When the architecture is more complex and

involves several security devices, this procedure may

lead to anomalies in the conﬁguration of these devices

and become an important source of errors exploited

by potential attackers.

These anomalies can be classiﬁed as follows.

Firewall anomalies, also deﬁned in the literature as

intra- and inter-ﬁrewall anomalies (Al-Shaer et al.,

2005), and that refer to those conﬂicts that might exist

within the local set of rules of a given ﬁrewall (intra)

or between the conﬁguration rules of different ﬁre-

walls that match the same trafﬁc (inter); tunneling

anomalies, which refer to those conﬂicts that might

exist when both ﬁrewalls and VPN tunnels match the

same trafﬁc; and intrusion detection system anoma-

lies, which refer to those conﬂicts that might exist

when both ﬁrewalls and IDSs match the same trafﬁc.

There actually exist several proposals that address

the problem of managing security policies free of

anomalies. In (Bartal et al., 1999), for example,

the authors propose a reﬁnement mechanism based

on a high level language and that performs an au-

tomatic ﬁrewall deployment through a reﬁnement.

However, its approach is not fully satisfactory since

it does not apply a complete separation between the

abstract security policy and the security device fea-

tures and technology. The authors in (Cuppens et

al., 2004b) propose a more complete proposal by us-

ing the Organization Based Access Control (OrBAC)

model (Kalam et al., 2003) as a high level policy lan-

guage and an ulterior set of compilations that derive

the OrBAC speciﬁcations into speciﬁc device conﬁg-

urations. Unfortunately, only ﬁrewall management is

addressed in such an approach. Other approaches,

such as (Al-Shaer et al., 2005; Fu et al., 2001; Al-

faro et al., 2006b), on the other hand, present audit

solutions for the analysis of more complex security

setups, where not only ﬁrewalls, but also VPN de-

vices and IDSs, are in charge of the whole network’s

security. However, the main drawback of these audit

approaches relies on their lack of knowledge about a

global security policy, which is very helpful for main-

tenance and troubleshooting tasks.

In this paper, we extend the reﬁnement approach

Preda S., Cuppens-Boulahia N., Cuppens F., G. Alfaro J. and Toutain L. (2007).

RELIABLE PROCESS FOR SECURITY POLICY DEPLOYMENT.

In Proceedings of the Second International Conference on Security and Cryptography, pages 5-15

DOI: 10.5220/0002119200050015

 SciTePress

presented in (Cuppens et al., 2004b), and propose a

more complete reﬁnement process to derive not only

ﬁrewall conﬁgurations, but also VPN/IPSec (Inter-

net Security Protocol Suite) and scenario-based IDSs

conﬁgurations. We propose a 2-steps process to (1)

formally specify the global set of security require-

ments by using an expressive access control model

based on OrBAC; and (2) a set of ulterior compila-

tions to automatically transform such an abstract se-

curity policy into the speciﬁc conﬁguration of each

security device deployed over the system (e.g., ﬁre-

walls, VPN/IPSec tunnels and IDSs). This strategy

not only simpliﬁes the administrator’s job, but also

guarantees that the management of policies at both

high and speciﬁc level is completely free of anoma-

lies, i.e., ambiguities, redundancies or unnecessary

details.

The rest of this paper is structured as follows. Sec-

tion 2 presents some related works. Sections 3 and

4 overview our strategy and introduce the main as-

pects of our expressive access control model. Sec-

tion 5 presents our deployment algorithms. Finally,

Section 6 closes the paper with some conclusions and

work in progress not covered in this paper.

2 RELATED WORK

There exist in the literature several proposals to man-

age and deploy access control policies on security de-

vices free of anomalies. We overview in this section

those works that we consider close to ours.

A ﬁrst approach presented in (Bartal et al., 1999)

proposes a reﬁnement mechanism based on a high

level language that allows administrators to perform

automatic ﬁrewall deployments. It uses the concept

of roles to deﬁne network capabilities, and propose

the use of an inheritance mechanism through a hierar-

chy of entities to automatically generate permissions.

However, this approach is not fully satisfactory since

it does not apply a complete separation between the

abstract security policy and the security device fea-

tures and technology. More speciﬁcally, it does not ﬁx

clear semantics, and its concept of role becomes am-

biguous. A similar reﬁnement approach is also pre-

sented in (Hassan and Hudec, 2003). However, and

although the authors claim that their work is based

on the RBAC model (Sandhu et al., 1996), it also

presents a lack of semantics — it seems that they only

keep from the RBAC model the concept of role. In-

deed, the speciﬁcation of network entities, roles, and

permission assignments are not rigorous and does not

seem to ﬁt any reality.

The authors in (Kalam et al., 2005) present an in-

trusion detection approach to enforce a security pol-

icy

. They propose the use of a ”neutral language” to

deﬁne a global policy which is further deployed into

a heterogeneous system. As their work is focused

on a Linux protection language, the rules that can-

not be translated into ﬁle access rules are to be trans-

lated into IDS or ﬁrewall rules. However, although

the distribution of the global policy into the system

is done in a manual fashion on different hosts/nodes,

there is no algorithm explaining the choice of these

hosts/nodes that optimally respond to global security

requirements. Although some veriﬁcation processes

try to guarantee anomaly-free policies, only local con-

ﬁgurations are considered. Some drawbacks when

managing those anomalies are moreover pointed out

in (Blanc et al., 2004) and no solution has been yet

presented. Furthermore, no IPSec devices are taken

into account.

The work presented in (Cuppens et al., 2004b)

successfully applies a set of reﬁnement transforma-

tion to derive from an abstract security policy based

on the OrBAC model (Kalam et al., 2003) into the net-

work’s ﬁrewalls that might be enforced. However, the

network administrator has to assist the deployment of

the access control rules by indicating which ﬁrewall

implements a speciﬁc rule. For instance, concerning

a given rule stating a certain trafﬁc is allowed (e.g.,

the ftp service) between two hosts, the administrator

has to indicate which ﬁrewalls should implement an

accept rule to fulﬁll this requirement. We extend in

this paper this later approach by introducing new se-

curity devices (VPN/IPSec-based tunnels and IDSs),

improving some of the previous limitations, and guar-

anteeing that neither VPN nor IDS anomalies may ap-

ply over resulting setup.

Some other approaches propose to directly an-

alyze existing conﬁgurations in order to warn and

ﬁx inconsistencies. The work presented in (Fu et

al., 2001), for example, concerns the analysis of

VPN overlapping tunnels in order to detect tunneling

anomalies. In their approach, if an access rule con-

cerning a protected trafﬁc between two points is im-

plemented by conﬁguring more than one IPSec over-

lapping tunnels, the risk is that in some network zones

the IP packets circulate without any protection. The

authors in (Fu et al., 2001) present a discovery pro-

cess to detect such situations and propose a high-level

language to deal with VPN policies. However, a sig-

niﬁcant aspect is ignored in their approach: the whole

security policy cannot be seen as two independent as-

pects — VPN tunnels and the ﬁrewall issues. They

should not be separately modeled. Otherwise, there is

a risk of conﬂicts at the end of their process. The use

of a single access model, as our approach does, solves

SECRYPT 2007 - International Conference on Security and Cryptography

this limitation and allows us to deal with security as-

pects as a whole.

In (Hamed and Al-Shaer, 2006), a complete tax-

onomy of conﬂicts in security policies is presented,

and two main categories are proposed: (1) intra-

policy anomalies, which refer to those conﬂicts that

might exist within the local conﬁguration of security

devices; and (2) inter-policy anomalies, which refer to

those conﬂicts that might exist between the conﬁgura-

tion rules of different security devices that match the

same trafﬁc. The authors in (Al-Shaer et al., 2005)

propose, moreover, an audit mechanism in order to

discover and warn about these anomalies. In (Al-

faro et al., 2006a; Alfaro et al., 2006b), some exist-

ing limitations in (Hamed and Al-Shaer, 2006) are

pointed out, and an alternative set of anomalies and

audit algorithms to deal with these anomalies are pro-

posed. However, as noted in (Alfaro et al., 2007), the

main drawback of these solutions relies on the lack

of knowledge about the security policy as a whole —

from a global point of view — which is very useful

for maintenance and troubleshooting tasks. The man-

aging of anomalies during our reﬁnement process, not

only guarantees equivalent results, but also keeps with

such a knowledge.

Support tools can also be used to assist adminis-

trators in their task of conﬁguring security devices.

The Cisco Security Manager (Cisco Systems, Inc.),

for example, is designed to support the security pol-

icy deployment on a heterogeneous network involv-

ing a large diversity of cisco-based devices. How-

ever, we observe the following problems when us-

ing such a tool. First, it does not offer a semantic

model rich enough to express a global security pol-

icy. Although there is the possibility of deﬁning vari-

ables, and thus deﬁning access rules involving such

variables, the administrator tasks are not much sim-

pliﬁed. The administrator always needs a global view

of the topology in order to correctly specify each rule

to network devices; there is no automatic discovery

of security devices that optimally implement an ac-

cess rule involving an IP source and a destination, as

our approach does. Furthermore, the lack of a real

top-down approach as ours (cf. Section 3.1) is par-

tially replaced by other tools — e.g., conﬂict discov-

ery tools that need the administrator’s assistance and

that unfortunately only guarantee conﬂict resolution

for local conﬁgurations.

3 SECURITY POLICY

EXPRESSION

3.1 Downward Approach

Let us start by showing in Figure 1 the strategy of

our approach. The informal security requirements

speciﬁed in current language (informal layer) are ﬁrst

translated into a high level language based on the Or-

BAC model (Kalam et al., 2003). Although this trans-

lation to the OrBAC-based policy expression can not

be wholly automatic, the abstract concepts in the Or-

BAC model (cf. Section 3.2) facilitate this translation

for an administrator. Based upon this abstract secu-

rity policy that is detached from any speciﬁc security

device technology (e.g., NetFilter (Welte et al.)), we

deﬁned a set of deployment algorithms marked in Fig-

ure 1. These compilers are further detailed in Section

5. The ﬁrst compilation is iterated every time a sub-

organization (e.g., a ﬁrewall) is revealed (in Section

3.3 we will explain the element that determines these

iterations). The result is a package of rules written in

a generic expression (multi-target) and not for a spe-

ciﬁc technology. The second compilation takes into

account the speciﬁc technology and grammar (syntax

& semantics) of the security devices. For example,

different transformations have to be conceived when

dealing with NetFilter, Netasq or Cisco PIX ﬁrewalls.

Figure 1: Downward approach.

3.2 Security Policy Speciﬁcation

OrBAC is the access control model we used to ex-

press the abstract security policy (Kalam et al., 2003).

This model involves two levels of abstraction: (1)

an organizational level (”role”, ”activity”, ”view” and

”context” concepts); and (2) a concrete level (”sub-

ject”, ”action”, ”object”) — that are entirely compati-

ble with our downward approach. The OrBAC model

uses ﬁrst order logic to write access control rules in

RELIABLE PROCESS FOR SECURITY POLICY DEPLOYMENT

the form of permissions (Is permited), prohibitions

(Is

prohibited) and obligations (Is Obliged). For ex-

ample, a permission is derived as follows:

∀ org, ∀ s, ∀ o, ∀ α, ∀ r, ∀ ν, ∀ a, ∀ c

permission(org, r, a, ν, c) ∧

empower(org, s, r) ∧ use(org, o, ν) ∧

consider(org, α, a) ∧ hold(org, s, a, o, c)

→ Is

permitted(s, α, o)

If the organization org grants role r the permis-

sion to perform activity a in view ν in context c and

if the role r is assigned to subject s (empower), the

object o is used in ν (use) and α is considered the ac-

tion implementing activity a (consider), s is granted

permission to perform α on o. Let us note that the

new concepts introduced by OrBAC are the follow-

ing: (1) Activity, regrouping actions having common

properties; (2) View, several objects having the same

properties on which the same rules are applied; and

(3) Context, a concept deﬁning the circumstances in

which some security rules can be applied.

OrBAC is based on the organization concept as-

signed to each network entity that deals with a part

of the security policy. If the (virtual) LAN the se-

curity policy is designed for, constitutes an organiza-

tion then a ﬁrewall, an IDS or an IPSec device be-

come sub-organizations (organization hierarchy) of

this LAN organization. Roles are assigned to sub-

jects, i.e., active entities in the network (e.g., a host, a

server, a ﬁrewall interface). A subject is assigned one

or several roles and will therefore obtain certain per-

missions. The notion of role facilitates the handling

of subjects and permissions. Permissions are obtained

for each of the subjects according to their role. The

activities are an abstraction of the network services.

For example, the action deﬁned as ”ALL

TCP” in-

cludes all tcp network services; ”WEB” refers to https

(port 443) and http (port 80).

A view regroups the objects. As we have seen,

at the concrete level of the OrBAC model, the rules

appear as Is

permitted(s, α, o) meaning that an en-

tity/subject s has the permission to perform the action

α on the object o. Hence, the object is either a net-

work entity (e.g., a web server) identiﬁed by its IP

address or an IP packet with a given data payload.

The context allows the deﬁnition of speciﬁc security

requirements directly at the OrBAC level. Some of

the permissions occur in a ”protected” context; this

leads to the conﬁguration of an IPSec tunnel. On the

other hand, a scenario-based IDS alert is triggered in a

”vulnerability” context associated with an attack with

a known signature; a speciﬁc IP payload may also be

speciﬁed as a part of the attack signature.

Finally, OrBAC, as also RBAC does (Sandhu et

al., 1996), deﬁnes role hierarchies, and also views,

activities and context hierarchies (Cuppens et al.,

2004a). In the specialization/generalization hierarchy,

permissions and prohibitions are inherited downward.

These hierarchies facilitate the administrator’s task by

attributing privileges and also simplify the formaliza-

tion of the security policy.

3.3 OrBAC Security Policy

The authors in (Cuppens et al., 2004b) describe an

XML-based OrBAC security policy implementation.

We chose to keep the same XML environment, but we

slightly modiﬁed and proposed new XML data struc-

tures to handle the IDS and IPSec devices. The net-

work architecture shown in Figure 2 will be used to

explain our methodology. It illustrates a private net-

work (the ”Corp” network: 111.222.0.0/16) including

even geographically different sites.

Accordingly to the OrBAC model, the scheme de-

scribing the high level policy includes an organiza-

tion. It is composed of the following parts: (1) The or-

ganization’s name; (2) An element describing the or-

ganization structure; (3) A set of rules (permissions);

and, if necessary, (4) a reference to a higher level or-

ganization (organization hierarchy).

In the ”structure” element, we distinguish the enti-

ties relevant for the security policy (the subjects) that

compose the network, the roles assigned to these enti-

ties and ﬁnally, the network services. The entities can

be ”host”, ”subnet” or ”address

interval” types. Also,

the entities exclusion is used to simplify the structure

representation. As an example, the Internet entity is

deﬁned as 0.0.0.0/0 excluding the corporate ”Corp”

network 111.222.0.0/16:

entity

entityName

Net

/entityName

subNet

addr

0.0.0.0

/addr

mask

/mask

/subNet

exclusionEntity

entityName

Corp

/entityName

/exclusionEntity

/entity

The roles are assigned to the entities (”entity-

Name”). The specialization/generalization role hi-

erarchy is used to simplify the OrBAC rule expres-

sion. This hierarchy is indicated by an XML child

element of the ”role” element: ”seniorRole”. For

instance, the role ”R

FW” or ”R VPN” is inherited

by all subjects having ﬁrewall functionalities (e.g.,

”FW Extern”, in Figure 2), respectively IPSec func-

tionalities (e.g., ”FW

Intern”). In the following ex-

SECRYPT 2007 - International Conference on Security and Cryptography

Figure 2: Topology example.

ample, the role ”R

DNS srv” (DNS server) is as-

signed to the entity/subject ”DNS

server” that inher-

its the role of a server - ”R

Srv”. Thus, an access rule

implying the role ”R

Srv” will automatically be prop-

agated to DNS server and other servers:

role

roleName

R DNS srv

/roleName

seniorRole

roleName

R Srv

/roleName

/seniorRole

entityName

DNS server

/entityName

/role

The permissions at the abstract level respect the

data structure shown in Figure 3. This XML schema

is compliant with the OrBAC speciﬁcation. The role

”roleName” performs the activity ”serviceName” on

the object ”target” with the role ”target/roleName”.

The ”context” element is optional. If the security

policy does not specify any particular conditions in

which this permission is attributed to the role ”role-

Name”, the context is ”default”. Otherwise, the secu-

rity policy may announce a ”protected” context or a

”vulnerability” one. In the ﬁrst case, an IPSec-based

tunnel must be created according to the ”child ele-

ments” of the ”protected” context: the type of the

encryption algorithm (e.g., AES), the entities which

have to negotiate the tunnel, a time interval during

which the IPSec tunnel is enabled, etc. The sec-

ond case will correspond to an IDS alert; a possible

(XML) attribute of the ”vulnerability” context ele-

ment may be the CVE vulnerability code if known

(MITRE Corp.). Moreover, a ”content” child element

of the ”context” will contain a speciﬁc data pattern as

part of an attack signature.

An important element of the ”permission” is the

”securityRole”. According to the OrBAC terminol-

ogy, ”securityRole” identiﬁes a sub organization. A

”securityRole” is also responsible for the activation

of certain contexts, thus the activation of an access

rule. It designates the role attributed to the security

device(s) which implement(s) the corresponding ac-

cess rules. For example, a rule stating that the access

from the ”Internet” to the DNS server is allowed will

be implemented by the ﬁrewall ”FW

Extern”; thus,

the ”securityRole” is the role ”R

FW Extern”. Fur-

thermore, a permission that bounds the role ”R

Intra”

and the target ”Internet” will be duplicated on both

ﬁrewalls ”FW Intern” and ”FW Extern”. In this case,

the ”securityRole” regroups both ”R

FW Intern” and

”R

FW Extern”.

In the case of less complex network architectures,

the ”securityRole” is given by the network adminis-

trator. Concerning more complex architectures (and

a great number of access rules), this security role as-

signment is difﬁcult to elaborate and can lead to er-

rors. That is why we propose some algorithms to au-

tomatically designate the right ”securityRole” under

the following two hypothesis:

(1)

We consider that the formal policy at the OrBAC

level is correct

: the ”structure” (cf. Figure 3) is

well deﬁned, without ambiguities (e.g., a ﬁrewall

is not attributed the role of a server) and the ac-

cess rules (cf. the ”permissions” in Figure 3) are

well speciﬁed (e.g., there is no OrBAC rule shad-

owed by any other). However, we admit that cer-

tain rules cannot be implemented because the ad-

equate security device (with the appropriate func-

tionalities) is missing. Our algorithms can detect

this kind of mismatch when deploying the policy.

(2) Inside the (virtual) network the security policy is

designed for, the IP packets ﬂow according to the

shortest path principle (as a routing protocol guar-

antees). The shortest path principle is used to

identify the device(s) on which a given security

We prove in (Cuppens et al., 2006) that such an as-

sumption is feasible

RELIABLE PROCESS FOR SECURITY POLICY DEPLOYMENT

Figure 3: OrBAC organization structure.

rule must be deployed. However, notice that the

shortest path is not always unique. For instance,

in Figure 2, there are two possible shortest paths

from site

ext to Srv BD. In this case, our algo-

rithms attempt to deploy the security rule on each

candidate shortest path.

To achieve this, the OrBAC structure shown in

Figure 3 is parsed and relevant information about the

network topology is collected. Practically we will ob-

tain a graph and the shortest path principle will be

applied to it. We describe the methodology in the fol-

lowing section.

4 MODELING THE TARGET

ARCHITECTURE

4.1 Modeling the Topology

At the OrBAC level, the security ofﬁcer identiﬁes the

relevant active entities (i.e., subjects) and roles as-

signed to these entities with respect to the network

topology and the security requirements. A role can

be assigned to more than one entity (e.g., all ﬁrewalls

have the ﬁrewall role ”R

FW”) and an entity can have

more than one role (e.g., a ﬁrewall can have IPSec

functionalities). The hierarchy of roles is deﬁned

too (e.g., a multi-server that has the DNS

server and

Web

server roles inherits inevitably the server role - a

less specialized role). An entity can be either a host,

a subnet or an address interval type.

As mentioned in Section 3.3, the entity exclusion

is used to achieve a better structuring and manage-

ment of the entities. The DMZ zone is considered to

be the 111.222.1.0/24 subnet excluding the two in-

terfaces of the adjacent ﬁrewalls ”FW

Extern” and

”FW

Intern” (cf. Figure 2). Multi-level exclusions

may also exist. For example, the ”CorpLessIntra”

is the ”Corporate” entity (111.222.0.0/16) which ex-

cludes the ”Site

ext” entity (111.222.5.0/16) and the

”Intra” entity (111.222.2.0/24) which in turn excludes

the internal interface of the ﬁrewall ”FW

Intern”.

”CorpLessIntra” deﬁnes brieﬂy all hosts unused by

general corporate employees and managed by ”Ad-

min” zone (111.222.3.0/24 - the network administra-

tion zone).

Regarding complex network architectures, one of

the most difﬁcult tasks for a security ofﬁcer is to indi-

cate each of the security devices (i.e., ”securityRole”)

which optimally implement the access rules. In our

approach, the security ofﬁcer does not need to give

such an indication because our algorithms ﬁnd the

right set of ”securityRole” for each ”permission” if

”securityRole” exists. For this purpose, the OrBAC

”structure” is initially parsed and we construct a graph

where every node is a zone

. In order to do so, the fol-

lowing information is automatically extracted during

the initial phase of our process:

- The functionalities of each security devices. For

example, in Figure 2, the ﬁrewall ”FW

Intern” has

fw & VPN functionalities (ﬁrewall and IPSec ca-

pabilities).

- The set of neighbors of each zone (based on their

IP addresses and masks

). For example, after

parsing the ”structure” corresponding to Figure 3,

the neighbors of the zone ”FW

Intern” are the ”In-

tra”, ”DMZ” and ”Admin” zones.

As a result of this ﬁrst parsing phase, we obtain

the following two outputs:

(1) A list of security devices,

Ss, deﬁned as follows: Ss =

∪

{device

, f unctionalities

, [∪

{neighbors

}]}.

(2) A list of zones, Zones, deﬁne as follows: Zones =

∪

{zone

[neighbors

}]}, and where neighbors

is the neighbor k zones of the ith zone.

A zone is either a subnet with no security device inter-

facing any other subnet or the set of interfaces of a security

device

The establishing neighbors algorithm is based on the

longest preﬁx matching scheme.

SECRYPT 2007 - International Conference on Security and Cryptography

4.2 Modeling Paths

Let us consider a rule at the OrBAC level; it implies a

role (”roleName”) and an object (”target/roleName”)

that corresponds to respectively a source ”Src” and

a destination ”Dest” entities. This information is

mandatory at the OrBAC level (cf. Figure 3). As al-

ready mentioned, we developed an algorithm that out-

puts the optimal set of ”securityRole” based on the

following three assumptions:

- source

zone: ∪

{zone

} = Src∩ Zones;

- dest

zone: ∪

{zone

} = Dest ∩ Zones;

- shortest

path : Zones x Zones → Ss, such that

shortest

path(zone

,zone

)←∪

{

device

}

Once identiﬁed the source and the destination

zones for an access rule, the shortest paths between a

source zone and a destination zone are computed and

the security devices on this path are revealed. Some of

these security devices will be designated as ”security-

Role”. Moreover, the security devices on the shortest

path must have the functionalities:

- if the access rule is in a ”default” context then ﬁre-

wall functionalities are necessary;

- if the access rule is in a ”protected” context then

IPSec functionalities are required;

- if the access rule is in a ”vulnerability” context,

then IDS functionalities are required.

In a ”default” context, a permission rule will be imple-

mented on all ﬁrewalls found on the path; a prohibi-

tion rule might simply be implemented on the security

device which is the closest to the IP ﬂow source (our

shortest

path algorithm was designed so as to choose

the most up-stream — the closest to the source — or

the most down-stream — the closest to the destination

— security device). The fact that an access rule is ei-

ther a permission or a prohibition ﬁltering rule is not

relevant for our discussion. That is why for didactical

reasons, we considered only permission rules in the

”default” context.

5 DEPLOYMENT ALGORITHMS

The main part of the security policy deployment is

included in the ﬁrst compilation phase (cf. Figure 1)

as a set of four processes:

- The ”structure

parsing” with the main results, i.e.,

the list of security devices Ss

and Zones;

We recall, from Section 4.1, that Ss is

the list of security devices, such that Ss =

∪

{device

, functionalities

, [∪

{neighbors

}]}.

- the ”hierarchies

treatement” including the role hi-

erarchy treatment and the exclusion entities treat-

ment;

- the ”securityRole” phase including the shortest

path computation;

- ”multi-target” extracts all relevant information

about the set of access rules the ”securityRole”

must implement, in a generic format.

The compilation process is schematized in Fig-

ure 4. The input is the OrBAC security policy; the

intermediary results are represented by dotted lines.

The ﬁnal compilation result is a set of ﬁles consisting

of the part of the security policy assigned to each ”se-

curityRole” (the ”multi-target” level). ”call” stands

for function callings; ”input” means that the interme-

diary results serve as input for other processes.

Figure 4: First compilation phases.

Concerning the ﬁrst compilation, the main algo-

rithms are the ”SecurityRoleDiscovery”, ”exclusion

entities treatment” and ”IDS - Firewall

Redundancy”.

From the ”multi-target” level, a second compilation is

applied to obtain the packages of concrete rules ac-

cording to the speciﬁc syntax of each relevant device.

5.1 The SecurityRoleDiscovery

Algorithm

The ”securityRole discovery” takes into account,

as an input, the ”structure” (cf. Figure 3) pars-

ing results: Ss and Zones. It also uses the short-

est path function. Let us assume the ”permissions”

= ∪

{

permission

}

at the OrBAC level:

A ”permission” rule in a ”default” context is im-

plemented by all security devices with ﬁrewall func-

tionalities on the shortest path. For example, given

the topology in Figure 2, both ﬁrewalls ”FW

site Ext”

and ”FW

Extern” implement an access rule stating

that ”ftp” is allowed from the ”site

ext” zone to the

”DMZ” zone.

In the ”protected” context, we formulated an ex-

tension to the shortest path function - passing

by():

RELIABLE PROCESS FOR SECURITY POLICY DEPLOYMENT

Algorithm 1: SecurityRoleDiscovery

foreach permission

do1

call hierarchies treatement;2

∪

{zoneS

} ← (Src ∩ Zones);3

∪

{zoneD

} ← (Dest ∩ Zones);4

foreach zoneS

do5

foreach zoneD

do6

if permission

[context] = default then7

list

← shortest

path (zoneS

,zoneD

);8

if S

list

[functionalities] = f w then9

securityRole ← S

list

;10

break;11

if permission

[context] = protected then12

Src V P N list ← find VPN components in ∪

{zoneS

[neighbors

];13

Dest

V P N list ← find VPN components in ∪

{zoneD

[neighbors

];14

if shortest

path (zoneS

,zoneD

)15

passing

by (Src V P N list,Dest V P N list) then16

call configure VPN IPsec tunnel;17

else18

warning (“V P N tunnel impossible”);19

break20

if permission

[context] = vulnerability then21

call IDS-Firewall Redundancy;22

- it identiﬁes the security devices - neighbors of the

source and the destination zones having IPSec func-

tionalities and it is supposed to compute a path be-

tween two of them;

- if a path exists, the algorithm ﬁnds the right in-

terfaces negotiating the IPSec tunnel (longest preﬁx

matching scheme);

- new ﬁltering access rules are to be implemented on

the ﬁrewalls discovered on the tunnel path (for exam-

ple, to enable the IPSec tunnel negotiation - isakmp

with the above interfaces). This way, we avoid the

conﬂict ﬁrewall ↔ IPSec tunnel.

Given the same topology (cf. Figure 2), let us

consider an access rule stating that all TCP trafﬁc

from the zone ”Intra” to the ”site

BD” zone must

be secured: Is

permited(R Intra, ALL TCP, target-

site BD, context-protected). With the previous al-

gorithm, the ”protected” context leads to the con-

ﬁguration of an IPSec-based tunnel. The IPSec

tunnel will be implemented by ”FW

Intern” and

”FW

BD 1” security devices because: (1) a path ex-

ists from the ”Intra” zone to the ”site

BD” zone and

(2) the path crosses these two security devices with

IPSec functionalities in the immediate neighborhood

of respectively the source IP trafﬁc zone (”Intra”) and

the destination (”site

BD”) zone. The interfaces in

charge of the IPSec tunnel negotiation (isakmp) are

the ”FW Intern” interface adjacent to the DMZ zone

and respectively the ”FW

BD 1” interface adjacent to

the Internet zone. A ﬁltering rule permitting the corre-

sponding isakmp trafﬁc is automatically deduced and

ﬁnally implemented in all ﬁrewalls on the tunnel path

(”FW

Intern”, ”FW Extern” and also ”FW BD 1”).

If the access rule is in a ”vulnerability” context,

IDS-Firewall

Redundancy is called (cf. Section 5.3).

Instead of deploying an IDS rule, we chose to exploit

an eventual IDS-ﬁrewall redundancy. We do not con-

sider any IDS-IPSec tunnel interaction because IDS

generally works on an unencrypted IP trafﬁc.

5.2 The Exclusion Entities Treatment

Algorithm

During the ﬁrst compilation, we treat the hierar-

chies of roles and activities (network services). Con-

sequently, a permission involving the ﬁrewall role

”R

FW” will engage all entities/subjects playing a

”R

FW” role. These entities may contain other en-

tities which are excluded. Deploying an access rule

implying subjects/entities which exclude other enti-

ties is solved as follows:

- a permission at the OrBAC level involving entity

E1, E1 excluding E2 will be translated in a generic

rule which will include E1, E1 excluding E2;

- a permission involving E1, E1 excluding E2, E2

excluding E3 will be translated in two generic

rules: the ﬁrst will involve E1, E1 excluding E2

and the second will involve E3;

- a permission involving E1, E1 excluding E2, E2

excluding E3, E3 excluding E4, will be translated

in two generic rules: the ﬁrst will include E1, E1

excluding E2 and the second will include E3, E3

excluding E4;

- a permission involving E1, E1 excluding E2 and

E3, E3 excluding E4 and E5, E5 excluding E6 will

be translated in three generic rules: the ﬁrst will

include E1, E1 excluding E2 and E3, the second

will include E4 and the third will include E5, E5

excluding E6.

This reasoning derives from a simple mathemati-

cal logic; for the last example, the entity E1 is deﬁned

as follows:

E1∧

(E2∨ E3) ∧ E4∨ (E5∧ E6) =

= (E1∧

E2∨ E3) ∨ E4∨ (E5∧ E6)

where ”∨” stands for the addition of a new

generic permission at the multi target level (cf. Fig-

ure 4); and ”∧” denotes an exclusion.

5.3 The IDS-Firewall Redundancy

Algorithm

An access rule in the ”vulnerability” context is de-

ployed on a single IDS device on the shortest path

binding the source and the destination of an IP ﬂow.

We chose the most down-stream IDS because it

is more efﬁcient against spooﬁng attacks than the

most up-stream IDS. Moreover, we do not elim-

inate the IDS-ﬁrewall redundancy: IDS alert sets

SECRYPT 2007 - International Conference on Security and Cryptography

off for IP packets that should have been blocked

by an up-stream ﬁrewall. We take advantage of

this redundancy in order to obtain relevant infor-

mation regarding a malfunctioning ﬁrewall. The

”IDS-Firewall

Redundancy” algorithm is based on

the shortest path principle with some extensions. To

illustrate our approach, let us consider the topology

shown in Figure 2.

A rule in the ”vulnerability” context for an IP ﬂow

with the ”Intra” source zone and the ”BD” destina-

tion zone will be implemented by IDS

A. An analysis

of the ﬁrewall conﬁgurations located on the shortest

path connecting the ”Intra” source and the ”BD” des-

tination is launched. We choose to ”analyze” only

the ﬁrewalls located up-stream; IDS

A cannot give

any information regarding its malfunctioning down-

stream ﬁrewalls.

Let us consider that the up-stream ﬁre-

walls (”FW

BD 1”, ”FW BD 2”, ”FW Extern”,

”FW

Intern”) apply a default deny all ﬁltering policy.

In this case, with our security policy deployment,

they implement only permission rules (accept or

pass). Each rule generally involves an IP source and

destination address and a network service (ports).

Let (S,D,P) be the triplet including this information.

The entire policy of a ﬁrewall (e.g., ”FW

Intern”)

may be resumed as follows: (1) pass” for F = (S

∧ D

∧ P

) ∨ (S

∧ D

∧ P

) ∨ ... ∨ (S

∧ D

∧ P

), where n = the ﬁltering rules number; (2)

”deny” for non(F); (3) F and non(F) are included in

the ”3D” space [source, destination, service] where

(source, destination) ∈ [0.0.0.0 ; 255.255.255.255]

and service ∈ [0 ; 65536].

We refer to the IDS-ﬁrewall redundancy only if

the set of parameters forming the ﬁrewall and the

IDS rules are the same; thus, the (S,D,P) triplet

is taken into account alongside the IDS ”alert”

rules and the ﬁrewall ”deny” rule. For example,

there is an IDS-ﬁrewall redundancy if an IDS alerts

for the IP packets including W = (111.222.2.0/24,

111.222.4.10, all

tcp) (regardless of their payload)

and an up-stream ﬁrewall performs deny for the

(111.222.2.32/27, 111.222.4.10, all

tcp) triplet. Our

”IDS-Firewall

Redundancy” algorithm ﬁnds the in-

tersection between each triplet W (corresponding to

an alert) and non(F

) for each up-stream ﬁrewall FW

Since Wr = W ∩ non(Fi) and Wa = W-Wr, then:

- A ﬁrst IDS rule will be implemented in the imme-

diately down-stream IDS

against the ﬁrewall FW

the previous intersection was computed for. The

IDS alert message will not only be the message

corresponding to the attack but will also include

”beware, malfunctioning FW

”. For example, in

Algorithm 2: IDS Firewall Redundancy

// Let IDS

be the most down-stream IDS of the

// sortest

path(source, destination).

// Let F W

be the last firewall of the

// sortest

path(source, destination) placed just before IDS

foreach F W

∈ shortest path (source,destination) do1

if exists (IDS

∈ shortest path (source,destination) then2

← W ∩ non(F

);3

← W − W

if W

6= ∅ then5

alert with Wr in (I DS

) & “malfunction F W

”;6

W ← W

else if IDS

= I DS

then8

← W ∩ non(F

);9

← W − W

;10

if W

6= ∅ then11

alert with Wr in (I DS

) & “malfunction F W

”;12

alert with Wa in (I DS

);13

break;14

the case of IDS A↔”FW Intern” redundancy, in-

volving Wr = W ∩ non(F), an IDS rule involving

Wr will be implemented in IDS B and thus the

”FW

Intern” malfunction can be detected.

- The last IDS rule will be implemented in the most

down-stream IDS and include Wa. For the previ-

ous example, an IDS rule with Wa and the unmod-

iﬁed message corresponding to the initial vulner-

ability will be implemented in IDS

5.4 Final Phase

The second compilation phase (cf. Figure 1) trans-

lates the generic rules to a speciﬁc security device

technology. We deal with a library of transformations.

Each transformation is conditioned by the security de-

vice features.

The intrinsic matching rule (ﬁrst-matching, or

last-matching) and the rule order are taken into ac-

count when designing a transformation for a ﬁrewall.

Let us consider that an entity excludes another en-

tity in one generic permission; we have the choice

to design either a transformation that outputs two

rules (one of them being the negative rule and corre-

sponding to the excluded entity) or a transformation in

which the excluded entity is actually left out (the re-

sult is a single pass/accept rule). In the ﬁrst case, the

negative rule must be placed before (ﬁrst-matching)

or after (last-matching) the positive rule.

NetFilter offers a mean to skip the rule order im-

portance. The authors in (Cuppens et al., 2004b) use

the jump and new chain functionalities each time ex-

clusion entities are involved. However, not all ﬁre-

walls we dealt with had these functionalities. The or-

der of rules will not be important if we succeed in

writing pass rules and only the last rule is deny all.

We designed such a transformation in XSLT language

for Netasq F200 IPS. On the other hand, and in order

RELIABLE PROCESS FOR SECURITY POLICY DEPLOYMENT

to obtain the IPSec-based tunnel conﬁgurations, an-

other transformation is required. Therefore, we con-

ceived one for the Netasq F200 family which also in-

cludes the IPSec functionalities. As scenario-based

IDS, we worked with SNORT-based IDS, for which

we considered only the alert IDS rules and a speciﬁc

transformation.

5.5 Performance Evaluation

The complete set of algorithms and processes

overviewed in this section have been implemented

and evaluated in a ﬁrst software prototype. Let us

brieﬂy present in this section some of the results we

obtained. The implementation has been done by us-

ing PHP, a general-purpose scripting language that is

especially suited for web services development. In

this way, the complete reﬁnement process can be lo-

cally or remotely executed by using a HTTP server

(e.g., Apache server over UNIX or Windows setups)

and a web browser. On the other hand, the evaluation

was carried out on an Intel-Pentium M 1.4 GHz pro-

cessor with 512 MB RAM, running Ubuntu 6.0.6 with

GNU/Linux 2.6.15 (32 bits), and using Apache/2.0.55

with PHP/5.1.2 interpreter conﬁgured.

For our evaluations, we speciﬁed three different

IPv4 simulated networks. The topology for the ﬁrst

network consisted of four subnetworks, one SNORT-

based IDS and two ﬁrewalls the access rules were

deployed on. The topology for the second network

included ﬁve subnetworks, one SNORT-based IDS,

three ﬁrewalls - two of them having IPSec capabil-

ities. The topology for the third network consisted

of six subnetworks, two SNORT-based IDS, ﬁve ﬁre-

walls - three of them with IPSec capabilities. For each

topology we considered several security policies with

an incremental number of OrBAC rules.

During the evaluation, we measured the memory

space and the processing time needed to perform the

whole reﬁnement process. The results of these mea-

surements are plotted in Figure 5(a) and Figure 5(b).

We can ﬁrst notice in Figure 5(a) that an important

part of memory consumption is due to the structure

parsing phase (cf. Section 4.1) and then the memory

increases linearly with the OrBAC rules number. On

the other hand, we notice in Figure 5(b) that the pro-

cessing time is not due to the parsing structure phase

but to the OrBAC rules number and complexity.

However, although both memory space and pro-

cessing time results are pointing out to strong require-

ments, we consider they are reasonable since: (1) the

implementation of our approach has been done by us-

ing a high level scripting language, and we expect that

the use of a more efﬁcient language will clearly im-

prove these results; (2) our approach relies on an off-

line process which does not affect the performance of

the security policy enforcement.

We want ﬁnally to note that the implementation of

our proposal in a software prototype demonstrates the

practicability of our work; and the obtained results

allow us to be very optimistic about its use in more

complex security policy scenarios.

6 CONCLUSIONS

The conﬁguration of security devices is a complex

and cumbersome task. A wrong conﬁguration of

those devices may lead to weak security polices – eas-

ily to be bypassed by unauthorized parties. In order to

help security administrators, we have presented in this

paper a reﬁnement mechanism to properly conﬁgure

and manage the following security devices: ﬁrewalls,

VPN/IPSec-based tunnels, and scenario-based Intru-

sion Detection Systems (IDSs).

Our proposal allows the administrator to formally

specify security requirements by using an expressive

200

250

300

350

400

450

500

10 20 30 40 50 60 70 80 90 100

Memory space (kb)

Number of rules

First topology

Second topology

Third topology

(a) Memory space evaluation.

10 20 30 40 50 60 70 80 90 100

Average process time (secs)

Number of rules

First topology

Second topology

Third topology

(b) Processing time evaluation.

Figure 5: Memory and processing time evaluations.

SECRYPT 2007 - International Conference on Security and Cryptography

access control model based on OrBAC (Kalam et al.,

2003). As a result, an abstract security policy, which

is free of ambiguities, redundancies or unnecessary

details, is automatically transformed into speciﬁc se-

curity devices conﬁgurations. This strategy not only

simpliﬁes the security administrator’s job, but also

guarantees that the resulting conﬁguration is free of

anomalies and/or inconsistencies. The complete set of

algorithms and processes presented in this paper have

been implemented in a ﬁrst software prototype, and

the results of a ﬁrst evaluation have been overviewed.

Such implementation demonstrates the practicability

of our work and its performance results allow us to be

very optimistic about its use in more complex security

policy scenarios.

As work in progress, we are actually studying how

to extend our approach in the case where the security

architecture includes IPv6 devices. More speciﬁcally,

the construction of new VPN tunnels (e.g., IPv6-over-

IPv4) for IPv6 networks must be revised, and more

investigation has to be done in order to extend the

approach presented in this paper. In parallel to this

work, we are also extending our approach to make

cooperate routing and tunneling policies.

REFERENCES

Abou el Kalam, A., Baida, R. E., Balbiani, P., Benferhat,

S., Cuppens, F., Deswarte, Y., Mi

ege, A., Saurel, C.,

and Trouessin, G. Organization Based Access Con-

trol. In IEEE 4th Intl. Workshop on Policies for Dis-

tributed Systems and Networks, pp. 120–131, Lake

Come, Italy, 2003.

Abou el Kalam, A., Briffaut, J., Toinard, C., and Blanc, M.

Intrusion detection and security policy framework for

distributed environments. In Collaborative Technolo-

gies and Systems, pp.100-106, Missouri, USA, 2005.

Alfaro, J. G., Cuppens, F., and Cuppens-Boulahia, N.

Towards Filtering and Alerting Rule Rewriting on

Single-Component Policies. In Intl. Conference on

Computer Safety, Reliability, and Security, pp. 182–

194, Poland, 2006.

Alfaro, J. G., Cuppens, F., and Cuppens-Boulahia, N. Anal-

ysis of Policy Anomalies on Distributed Network Se-

curity Setups. In 11th European Symposium On Re-

search In Computer Security, pp. 496–511, Germany,

2006.

Alfaro, J. G., Cuppens, F., and Cuppens-Boulahia, N. Ag-

gregating and Deploying Network Access Control

Policies. In 1rst Symposium on Frontiers in Avail-

ability, Reliability and Security (FARES), 2nd Interna-

tional Conference on Availability, Reliability and Se-

curity (ARES2007), Vienna, Austria, 2007.

Al-Shaer, E. S., Hamed, H. H., and Masum, H. Con-

ﬂict Classiﬁcation and Analysis of Distributed Fire-

wall Policies. In IEEE Journal on Selected Areas in

Communications, 23(10):2069–2084, 2005.

Bartal, Y., Mayer, A., Nissim, K., and Wool, A. Firmato:

A novel ﬁrewall management toolkit. In IEEE Sym-

posium on Security and Privacy, pp. 17–31, Oakland,

California, 1999.

Blanc, M., Clemente, P., Courtieu, P., Franche, S., Oudot,

L., Toinard, C. and Vessiller, L. Hardening large-

scale networks security through a meta-policy frame-

work. In Third Workshop on the Internet, Telecommu-

nications and Signal Processing, Adelaide, Australia,

2004.

Cisco Systems, Inc. Cisco Security Manager Prod-

uct Information. [Online]. Available from:

http://cisco.com/go/csmanager

Cuppens, F., Cuppens-Boulahia, N., and Miege, A. Inher-

itance hierarchies in the OrBAC Model and applica-

tion in a network environment. In 2nd Foundations of

Computer Security Workshop (FCS’04), Turku, Fin-

lande, 2004.

Cuppens, F., Cuppens-Boulahia, N., and Ben Ghorbel,

M. High-level conﬂict management strategies in ad-

vanced access control models. In Workshop on Infor-

mation and Computer Security (ICS 2006), Timisoara,

Roumania, 2006.

Cuppens, F., Cuppens-Boulahia, N., Sans, T. and Miege, A.

A formal approach to specify and deploy a network

security policy. In 2nd Workshop on Formal Aspects

in Security and Trust, pp. 203–218, Toulouse, France,

2004.

Fu, Z., Wu, S. F., Huang, H., Loh, K., Gong, F., Baldine, I.,

Xu, C. IPSec/VPN Security Policy: Correctness, Con-

ﬂict Detection and Resolution. In Policy 2001 Work-

shop, pp. 39–56, 2001.

Hamed, H. H. and Al-Shaer, E. S. Taxonomy of conﬂicts in

network security policies. In IEEE Communications,

44(3):134-141, 2006.

Hassan, A. and Hudec, L. Role Based Network Security

Model: A Forward Step towards Firewall Manage-

ment. In Workshop On Security of Information Tech-

nologies, Algiers, 2003.

MITRE Corp. Common Vulnerabilities and Exposures.

[Online]. Available from:

http://cve.mitre.org/

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

E. Role-Based Access Control Models. IEEE Com-

puter, 29(2):38–47, 1996.

Welte, H., Kadlecsik, J., Josefsson, M., McHardy, P., and

et al. The netﬁlter project: ﬁrewalling, nat and packet

mangling for linux 2.4x and 2.6.x. [Online]. Available

from:

http://www.netfilter.org/

RELIABLE PROCESS FOR SECURITY POLICY DEPLOYMENT