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
e, France
Universitat Oberta de Catalunya, Rambla Poble Nou 156, 08018 Barcelona, Spain
Network Security, Security Devices, Security Rules, Deployment of Policies, Policy Anomalies.
We focus in this paper on the problem of configuring 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 simplifies the security
administrator’s job, but also guarantees a resulting configuration free of anomalies and/or inconsistencies.
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 firewalls, virtual private network (VPN) tunnels
and intrusion detection systems (IDSs). The config-
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 configuration of the security devices may be
obtained directly by translating the security require-
ments into packages of specific 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 configuration of these devices
and become an important source of errors exploited
by potential attackers.
These anomalies can be classified as follows.
Firewall anomalies, also defined in the literature as
intra- and inter-firewall anomalies (Al-Shaer et al.,
2005), and that refer to those conflicts that might exist
within the local set of rules of a given firewall (intra)
or between the configuration rules of different fire-
walls that match the same traffic (inter); tunneling
anomalies, which refer to those conflicts that might
exist when both firewalls and VPN tunnels match the
same traffic; and intrusion detection system anoma-
lies, which refer to those conflicts that might exist
when both firewalls and IDSs match the same traffic.
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 refinement mechanism based
on a high level language and that performs an au-
tomatic firewall deployment through a refinement.
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 specifications into specific device config-
urations. Unfortunately, only firewall 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 firewalls, 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 refinement approach
Preda S., Cuppens-Boulahia N., Cuppens F., G. Alfaro J. and Toutain L. (2007).
In Proceedings of the Second International Conference on Security and Cryptography, pages 5-15
DOI: 10.5220/0002119200050015
presented in (Cuppens et al., 2004b), and propose a
more complete refinement process to derive not only
firewall configurations, but also VPN/IPSec (Inter-
net Security Protocol Suite) and scenario-based IDSs
configurations. 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 specific configuration of each
security device deployed over the system (e.g., fire-
walls, VPN/IPSec tunnels and IDSs). This strategy
not only simplifies the administrator’s job, but also
guarantees that the management of policies at both
high and specific level is completely free of anoma-
lies, i.e., ambiguities, redundancies or unnecessary
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.
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 first approach presented in (Bartal et al., 1999)
proposes a refinement mechanism based on a high
level language that allows administrators to perform
automatic firewall deployments. It uses the concept
of roles to define 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 specifically, it does not fix
clear semantics, and its concept of role becomes am-
biguous. A similar refinement 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 specification of network entities, roles, and
permission assignments are not rigorous and does not
seem to fit any reality.
The authors in (Kalam et al., 2005) present an in-
trusion detection approach to enforce a security pol-
. They propose the use of a ”neutral language” to
define 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 file access rules are to be trans-
lated into IDS or firewall 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 verification processes
try to guarantee anomaly-free policies, only local con-
figurations 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 refinement transforma-
tion to derive from an abstract security policy based
on the OrBAC model (Kalam et al., 2003) into the net-
work’s firewalls that might be enforced. However, the
network administrator has to assist the deployment of
the access control rules by indicating which firewall
implements a specific rule. For instance, concerning
a given rule stating a certain traffic is allowed (e.g.,
the ftp service) between two hosts, the administrator
has to indicate which firewalls should implement an
accept rule to fulfill 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 configurations in order to warn and
fix 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 traffic between two points is im-
plemented by configuring 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-
nificant aspect is ignored in their approach: the whole
security policy cannot be seen as two independent as-
pects VPN tunnels and the firewall issues. They
should not be separately modeled. Otherwise, there is
a risk of conflicts 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 conflicts in security policies is presented,
and two main categories are proposed: (1) intra-
policy anomalies, which refer to those conflicts that
might exist within the local configuration of security
devices; and (2) inter-policy anomalies, which refer to
those conflicts that might exist between the configura-
tion rules of different security devices that match the
same traffic. 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 refinement 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 configuring 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 defining vari-
ables, and thus defining access rules involving such
variables, the administrator tasks are not much sim-
plified. 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., conflict discov-
ery tools that need the administrator’s assistance and
that unfortunately only guarantee conflict resolution
for local configurations.
3.1 Downward Approach
Let us start by showing in Figure 1 the strategy of
our approach. The informal security requirements
specified in current language (informal layer) are first
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 specific security
device technology (e.g., NetFilter (Welte et al.)), we
defined a set of deployment algorithms marked in Fig-
ure 1. These compilers are further detailed in Section
5. The first compilation is iterated every time a sub-
organization (e.g., a firewall) 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-
cific technology. The second compilation takes into
account the specific 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 firewalls.
Figure 1: Downward approach.
3.2 Security Policy Specification
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 first order logic to write access control rules in
the form of permissions (Is permited), prohibitions
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)
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 defining 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 firewall, 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 firewall 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 defined 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) identified by its IP
address or an IP packet with a given data payload.
The context allows the definition of specific security
requirements directly at the OrBAC level. Some of
the permissions occur in a ”protected” context; this
leads to the configuration 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 specific IP payload may also be
specified as a part of the attack signature.
Finally, OrBAC, as also RBAC does (Sandhu et
al., 1996), defines 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 modified 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: 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 finally, 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
defined as excluding the corporate ”Corp”
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 firewall 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:
R DNS srv
R Srv
DNS server
The permissions at the abstract level respect the
data structure shown in Figure 3. This XML schema
is compliant with the OrBAC specification. 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 first 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 specific data pattern as
part of an attack signature.
An important element of the ”permission” is the
”securityRole”. According to the OrBAC terminol-
ogy, ”securityRole” identifies 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 firewall ”FW
Extern”; thus,
the ”securityRole” is the role ”R
FW Extern”. Fur-
thermore, a permission that bounds the role ”R
and the target ”Internet” will be duplicated on both
firewalls ”FW Intern” and ”FW Extern”. In this case,
the ”securityRole” regroups both ”R
FW Intern” and
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 difficult 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:
We consider that the formal policy at the OrBAC
level is correct
: the ”structure” (cf. Figure 3) is
well defined, without ambiguities (e.g., a firewall
is not attributed the role of a server) and the ac-
cess rules (cf. the ”permissions” in Figure 3) are
well specified (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 flow 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
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.1 Modeling the Topology
At the OrBAC level, the security officer identifies 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 firewalls
have the firewall role ”R
FW”) and an entity can have
more than one role (e.g., a firewall can have IPSec
functionalities). The hierarchy of roles is defined
too (e.g., a multi-server that has the DNS
server and
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 subnet excluding the two in-
terfaces of the adjacent firewalls ”FW
Extern” and
Intern” (cf. Figure 2). Multi-level exclusions
may also exist. For example, the ”CorpLessIntra”
is the ”Corporate” entity ( which ex-
cludes the ”Site
ext” entity ( and the
”Intra” entity ( which in turn excludes
the internal interface of the firewall ”FW
”CorpLessIntra” defines briefly all hosts unused by
general corporate employees and managed by ”Ad-
min” zone ( - the network administra-
tion zone).
Regarding complex network architectures, one of
the most difficult tasks for a security officer is to indi-
cate each of the security devices (i.e., ”securityRole”)
which optimally implement the access rules. In our
approach, the security officer does not need to give
such an indication because our algorithms find 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 firewall ”FW
Intern” has
fw & VPN functionalities (firewall and IPSec ca-
- 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 first parsing phase, we obtain
the following two outputs:
(1) A list of security devices,
Ss, defined as follows: Ss =
, f unctionalities
, [
(2) A list of zones, Zones, define as follows: Zones =
}]}, 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
The establishing neighbors algorithm is based on the
longest prefix 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
} = Src Zones;
- dest
} = Dest Zones;
- shortest
path : Zones x Zones Ss, such that
Once identified 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 fire-
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 firewalls found on the path; a prohibi-
tion rule might simply be implemented on the security
device which is the closest to the IP flow source (our
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 filtering rule is not
relevant for our discussion. That is why for didactical
reasons, we considered only permission rules in the
”default” context.
The main part of the security policy deployment is
included in the first 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 =
, functionalities
, [
- the ”hierarchies
treatement” including the role hi-
erarchy treatment and the exclusion entities treat-
- 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 final compilation result is a set of files 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 first compilation, the main algo-
rithms are the ”SecurityRoleDiscovery”, ”exclusion
entities treatment” and ”IDS - Firewall
From the ”multi-target” level, a second compilation is
applied to obtain the packages of concrete rules ac-
cording to the specific syntax of each relevant device.
5.1 The SecurityRoleDiscovery
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”
at the OrBAC level:
A ”permission” rule in a ”default” context is im-
plemented by all security devices with firewall func-
tionalities on the shortest path. For example, given
the topology in Figure 2, both firewalls ”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
Algorithm 1: SecurityRoleDiscovery
foreach permission
call hierarchies treatement;2
} (Src Zones);3
} (Dest Zones);4
foreach zoneS
foreach zoneD
if permission
[context] = default then7
path (zoneS
if S
[functionalities] = f w then9
securityRole S
if permission
[context] = protected then12
Src V P N list find VPN components in
V P N list find VPN components in
if shortest
path (zoneS
by (Src V P N list,Dest V P N list) then16
call configure VPN IPsec tunnel;17
warning (“V P N tunnel impossible”);19
if permission
[context] = vulnerability then21
call IDS-Firewall Redundancy;22
- it identifies 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 finds the right in-
terfaces negotiating the IPSec tunnel (longest prefix
matching scheme);
- new filtering access rules are to be implemented on
the firewalls discovered on the tunnel path (for exam-
ple, to enable the IPSec tunnel negotiation - isakmp
with the above interfaces). This way, we avoid the
conflict firewall IPSec tunnel.
Given the same topology (cf. Figure 2), let us
consider an access rule stating that all TCP traffic
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-
figuration of an IPSec-based tunnel. The IPSec
tunnel will be implemented by ”FW
Intern” and
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 traffic 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 filtering rule permitting the corre-
sponding isakmp traffic is automatically deduced and
finally implemented in all firewalls on the tunnel path
Intern”, ”FW Extern” and also ”FW BD 1”).
If the access rule is in a ”vulnerability” context,
Redundancy is called (cf. Section 5.3).
Instead of deploying an IDS rule, we chose to exploit
an eventual IDS-firewall redundancy. We do not con-
sider any IDS-IPSec tunnel interaction because IDS
generally works on an unencrypted IP traffic.
5.2 The Exclusion Entities Treatment
During the first compilation, we treat the hierar-
chies of roles and activities (network services). Con-
sequently, a permission involving the firewall role
FW” will engage all entities/subjects playing a
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 first 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 first 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 first 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 defined
as follows:
(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
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 flow.
We chose the most down-stream IDS because it
is more efficient against spoofing attacks than the
most up-stream IDS. Moreover, we do not elim-
inate the IDS-firewall 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 firewall. We take advantage of
this redundancy in order to obtain relevant infor-
mation regarding a malfunctioning firewall. The
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 flow
with the ”Intra” source zone and the ”BD” destina-
tion zone will be implemented by IDS
A. An analysis
of the firewall configurations located on the shortest
path connecting the ”Intra” source and the ”BD” des-
tination is launched. We choose to ”analyze” only
the firewalls located up-stream; IDS
A cannot give
any information regarding its malfunctioning down-
stream firewalls.
Let us consider that the up-stream fire-
walls (”FW
BD 1”, ”FW BD 2”, ”FW Extern”,
Intern”) apply a default deny all filtering 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 firewall (e.g., ”FW
may be resumed as follows: (1) pass for F = (S
) (S
) ... (S
), where n = the filtering rules number; (2)
deny for non(F); (3) F and non(F) are included in
the ”3D” space [source, destination, service] where
(source, destination) [ ;]
and service [0 ; 65536].
We refer to the IDS-firewall redundancy only if
the set of parameters forming the firewall and the
IDS rules are the same; thus, the (S,D,P) triplet
is taken into account alongside the IDS ”alert”
rules and the firewall ”deny” rule. For example,
there is an IDS-firewall redundancy if an IDS alerts
for the IP packets including W = (,, all
tcp) (regardless of their payload)
and an up-stream firewall performs deny for the
(,, all
tcp) triplet. Our
Redundancy” algorithm finds the in-
tersection between each triplet W (corresponding to
an alert) and non(F
) for each up-stream firewall FW
Since Wr = W non(Fi) and Wa = W-Wr, then:
- A first IDS rule will be implemented in the imme-
diately down-stream IDS
against the firewall 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
if W
6= then5
alert with Wr in (I DS
) & “malfunction F W
else if IDS
= I DS
W non(F
if W
6= then11
alert with Wr in (I DS
) & “malfunction F W
alert with Wa in (I DS
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
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-
ified 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 specific security device
technology. We deal with a library of transformations.
Each transformation is conditioned by the security de-
vice features.
The intrinsic matching rule (first-matching, or
last-matching) and the rule order are taken into ac-
count when designing a transformation for a firewall.
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 first case, the
negative rule must be placed before (first-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 fire-
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
to obtain the IPSec-based tunnel configurations, 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 specific
5.5 Performance Evaluation
The complete set of algorithms and processes
overviewed in this section have been implemented
and evaluated in a first software prototype. Let us
briefly 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 refinement 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 configured.
For our evaluations, we specified three different
IPv4 simulated networks. The topology for the first
network consisted of four subnetworks, one SNORT-
based IDS and two firewalls the access rules were
deployed on. The topology for the second network
included five subnetworks, one SNORT-based IDS,
three firewalls - two of them having IPSec capabil-
ities. The topology for the third network consisted
of six subnetworks, two SNORT-based IDS, five fire-
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 refinement process. The results of these mea-
surements are plotted in Figure 5(a) and Figure 5(b).
We can first 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 efficient 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 finally 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.
The configuration of security devices is a complex
and cumbersome task. A wrong configuration 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 refinement mechanism to properly configure
and manage the following security devices: firewalls,
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
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 specific se-
curity devices configurations. This strategy not only
simplifies the security administrator’s job, but also
guarantees that the resulting configuration is free of
anomalies and/or inconsistencies. The complete set of
algorithms and processes presented in this paper have
been implemented in a first software prototype, and
the results of a first 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 specifically,
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.
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,
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-
flict Classification 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 firewall 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,
Cisco Systems, Inc. Cisco Security Manager Prod-
uct Information. [Online]. Available from:
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 conflict 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,
Fu, Z., Wu, S. F., Huang, H., Loh, K., Gong, F., Baldine, I.,
Xu, C. IPSec/VPN Security Policy: Correctness, Con-
flict Detection and Resolution. In Policy 2001 Work-
shop, pp. 39–56, 2001.
Hamed, H. H. and Al-Shaer, E. S. Taxonomy of conflicts 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:
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 netfilter project: firewalling, nat and packet
mangling for linux 2.4x and 2.6.x. [Online]. Available