ArticlePDF Available

Scalable model-based configuration management of security services in complex enterprise networks


Abstract and Figures

Security administrators face the challenge of designing, deploying and maintaining a variety of configuration files related to security systems, especially in large-scale networks. These files have heterogeneous syntaxes and follow differing semantic concepts. Nevertheless, they are interdependent due to security services having to cooperate and their configuration to be consistent with each other, so that global security policies are completely and correctly enforced. To tackle this problem, our approach supports a comfortable definition of an abstract high-level security policy and provides an automated derivation of the desired configuration files. It is an extension of policy-based management and policy hierarchies, combining model-based management (MBM) with system modularization. MBM employs an object-oriented model of the managed system to obtain the details needed for automated policy refinement. The modularization into abstract subsystems (ASs) segment the system—and the model—into units which more closely encapsulate related system components and provide focused abstract views. As a result, scalability is achieved and even comprehensive IT systems can be modelled in a unified manner. The associated tool MoBaSeC (Model-Based-Service-Configuration) supports interactive graphical modelling, automated model analysis and policy refinement with the derivation of configuration files. We describe the MBM and AS approaches, outline the tool functions and exemplify their applications and results obtained. Copyright © 2010 John Wiley & Sons, Ltd.
Content may be subject to copyright.
Softw. Pract. Exper. 2011; 41:307–338
Published online 19 October 2010 in Wiley Online Library ( DOI: 10.1002/spe.1014
Scalable model-based configuration management of security
services in complex enterprise networks
ao Porto de Albuquerque1, Heiko Krumm2,PauloL
ıcio de Geus3,,and
e Jeruschkat2
1ICMC,University of Sao Paulo,Sao Paulo,SP,Brazil
2Department of Computer Science,Technical University of Dortmund,Dortmund,Germany
3Institute of Computing,University of Campinas,Campinas,SP,Brazil
Security administrators face the challenge of designing, deploying and maintaining a variety of configu-
ration files related to security systems, especially in large-scale networks. These files have heterogeneous
syntaxes and follow differing semantic concepts. Nevertheless, they are interdependent due to security
services having to cooperate and their configuration to be consistent with each other, so that global
security policies are completely and correctly enforced. To tackle this problem, our approach supports
a comfortable definition of an abstract high-level security policy and provides an automated derivation
of the desired configuration files. It is an extension of policy-based management and policy hierarchies,
combining model-based management (MBM) with system modularization. MBM employs an object-
oriented model of the managed system to obtain the details needed for automated policy refinement. The
modularization into abstract subsystems (ASs) segment the system—and the model—into units which
more closely encapsulate related system components and provide focused abstract views. As a result,
scalability is achieved and even comprehensive IT systems can be modelled in a unified manner. The
associated tool MoBaSeC (Model-Based-Service-Configuration) supports interactive graphical modelling,
automated model analysis and policy refinement with the derivation of configuration files. We describe
the MBM and AS approaches, outline the tool functions and exemplify their applications and results
obtained. Copyright q2010 John Wiley & Sons, Ltd.
Received 16 January 2010; Revised 15 August 2010; Accepted 17 August 2010
KEY WORDS: network security policy; policy-based management; automated policy refinement
Current networked IT systems contain a series of heterogeneous security services, such as firewalls
and secure content management systems, intrusion detection systems, identity management, key
management and authentication systems, access control systems, log and audit systems, secure
storage systems, virtual private network and cryptochannel systems. Services of different applica-
tion types have different functionalities and are usually supplied by different vendors. Therefore,
the style, syntax and semantics of their configuration files differ from each other. Each service has
to be configured according to particular settings; moreover, many services depend on each other,
since they usually have to cooperate with each other in a consistent manner in order to enforce
global security objectives. The example scenarios are: the desired access of a given employee to a
Correspondence to: Paulo L´
ıcio de Geus, Institute of Computing, University of Campinas, Av. Albert Einstein,
1251, 13083-852 Campinas, SP, Brazil.
Copyright q2010 John Wiley & Sons, Ltd.
certain resource depending on suitable authentication (access control); packet filtering at a firewall
and VPN connection settings. At least in large organizations, the settings are subject to frequent
changes and tend to overstrain the IT system administrators. Indeed, a survey of three large-scale
Internet sites concluded that 51% of all failures were caused by operator errors—configuration
errors being the largest category of errors [1].
Thus, automation and homogenization are highly interesting challenges. Ideally, there should
be one global abstract, high-level specification describing the objectives in an easy-to-understand,
application-oriented and system-independent way. Furthermore, there should be a tool to process
the high-level specification and to automatically generate the corresponding configuration files.
The approaches of policy-based management [2]and management policy hierarchies [3]yield a
corresponding solution. In accordance with these approaches, the administrator task should be
summarized as obtaining abstract high-level policies, which can then be refined into service-
and system-dependent low-level policies. Finally, configuration files can be derived from those
low-level policies.
Completely automated policy refinement, however, is not possible if high-level policies are
to be kept as the sole input in the process, since system-specific details have to necessarily be
considered during the refinement process. Therefore, our approach of model-based management
(MBM) utilizes a hierarchically structured system model that represents the networked IT systems
on three interrelated levels of abstraction [4–6]. The high-level policies are directly linked with
the highest model layer. The automated policy refinement follows the system layer interrelations,
relying upon the user-defined model in order to obtain the information necessary for generating
the low-level policies. To that effect, MBM comes along with a modelling tool called Model-
Based-Service-Configuration (MoBaSeC). It supports the interactive graphical modelling of object-
oriented system models and policy representations in the form of object instance diagrams, in order
to support the comfortable and easily maintainable definition of system models and high-level
policy descriptions. A library of predefined model element class definitions—the so-called meta-
model—and automated consistency checks facilitate the model construction. Aggregating folder
objects support the handling of large sets of similar model elements, such as user identities and
workstations. The modelling of IT systems that comprise large organizations, nevertheless, results
in broad models which, from the performance point of view, can be handled using MBM but,
from the administrator’s point of view, are—particularly on the lower layers—very complex and
difficult to master.
However, the benefits of policy hierarchies and MBM still stand and are clearly the fundamental
principles towards a scalable solution. To tackle the above problems we therefore came up with a
divide-and-conquer approach to the modelling of network security systems through the so-called
Abstract Subsystems (ASs). The modelling of a given network segment is thereby subdivided into
three steps: (1) the detailed definition of the network mechanisms—in the so-called Expanded
Subsystem (ES); (2) the establishment of an abstract view of those mechanisms by grouping them
into abstract types, i.e. the ASs and (3) the definition of the interaction among ASs in the Diagram
of Abstract Subsystems (DAS). As such, the model designer must deal with the mechanisms’
complexity only on a local basis for each subsystem, i.e. in steps (1) and (2), whereas in step (3) the
system as a whole is considered by means of an understandable and abstract overall representation
of the system’s architecture. The MoBaSeC tool has been correspondingly extended to support
the definition of DAS and ASs. Moreover, it is able to refine policies from the DAS layer into
different ASs. The refinement relations that are applied have been formally verified to ensure that
the system behaviour resulting from the generated configuration upholds the abstract policies.
The DAS approach, its modelling principles and their applications are described in [7].In[8]
the policy support offered by the approach is analysed and a formalism for the model is presented
as a basis for achieving results about the validity of the policy refinement. These results are revised
and further developed in the formal validation approach presented in [9], which consists of the
theoretical foundation of the approach. On the other hand, [10, 11]elaborate on the practical
use of the DAS approach in large-scale environments, presenting also the diagram visualization
and manipulation techniques that were implemented in MoBaSeC to improve the handling of
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
large models. The present article consolidates and extends the previous ones, offering an integral
introduction into the approaches of MBM and ASs and further elaborating on the practical aspect of
the approach. It explains the automated refinement process and presents new experimental results
obtained in a realistic network scenario with a more complex set of security policies.
The remainder of the text is organized as follows. Section 2 presents the real-world problem
security administrators face and Section 3 describes the MBM approach in general, also discussing
previous efforts following this approach, and their scalability problems. Section 4 presents the ASs
approach by describing the modelling framework and giving a simple model example. In Section 5
the tool support offered is presented and we detail the automated policy refinement process.
Section 6.4 outlines a case study that exemplifies how practical the approach is within a typical
complex-networked environment and presents the results achieved, which are discussed in
Section 7. Section 8 reports on the related work and Section 9 draws the conclusions for this article.
Security management in computer networks has become a very complex, critical task and possibly
the main source of concern nowadays. In general terms, network management involves monitoring
the activity of the network, making management decisions and performing control actions to
modify the behaviour of the network [2]. As such, network management is usually concerned with
efficiency aspects, whose bounds lie between maximum efficiency and no connectivity at all: at
worst, this results in a certain period of downtime to the computer infrastructure.
In contrast, security issues can have consequences that range from transient events, such as
DoS attacks([12],see[13]for a survey), to compromising of sensitive information and even
to permanent damage in the computing infrastructure, such as a successful break-in, in which
its internal integrity is compromised. One can distinguish the latter situation from the former
ones, since it involves a state change in the computer system that was not foreseen (information
compromise that is later used as a vehicle for an attacker to compromise the system’s integrity is
ultimately considered a successful break-in).
If an element of the computing infrastructure does get compromised, then an administrator
can no longer count on a reliable engine, i.e. a box that performs actions in a predictable and
expected way. As far as administration is concerned, no other services from that element, possibly
from others that exert some sort of trust relationship with the affected one, may be relied upon,
and as such their services will have to be shut down. At this point, the issue gets into the realm
of security incident response strategies. Administrators tend to establish a subjective distinction
between software and information: corruption of Operating System plus applications (i.e. software)
is dealt with in a different way than is done with data (i.e. information) corruption. The former
may easily be rebuilt from distribution media and/or online repositories, whereas the latter can
only be recovered from a snapshot of the past (how short in the past depends on the quality of the
backup strategy adopted). From an administration point of view, it all comes down to how much
effort and time is going to be required to restore the services that are no longer operational.
With that cost in mind, it is then easy to understand why the configuration of security providing
and supporting systems is the major concern for security management. To guarantee the reliable
operation which administration counts on, effective security management will require that no known
security mechanism configuration error exists. Only in this situation of reliable operation the system
can then be depended on to perform the security services that enforce the abstract information
security goals (such as confidentiality, integrity, availability) intended for the network environment.
Unfortunately for the security administrators, this configuration process is error-prone due to the
complexity, diversity and frequent redesign of such mechanisms. Worse yet, the configuration of
many security mechanisms cannot be proved correct, either due to the mechanisms themselves
not being guaranteed to perform according to specifications or due to testing the resulting system
Denial of Service attacks.
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
Figure 1. Small fraction of an in-production iptables rule set.
being computationally unfeasible. Throughout this work it is assumed that security mechanisms
do perform according to specifications.
A good example is the rule set of a firewall’s filtering function. Figure 1 shows a small fragment
of an in-production iptables rule set at LAS§. This small set of rules already gives some insight into
the practical problems faced by security administrators. There are equivalent filter configurations
that are more compact, however we prefer to spend twice the number of rules to make the rule set
minimally manageable, i.e. still far from desirable. As iptables is configured by shell commands,
this rule set is actually a shell script, which allows parameterization via environment variables of
several items in the rules. This particular example shows also an embedded loop, repeating the
rule structure for more than one case. The outstanding set contains four rules for the SSH service,
but to cover all necessary cases for this network service alone takes 29 rules. The complete rule
set amounts to 233 rules, not counting the possible loops in the script. The security policy at LAS
is not complex at all, since the range of roles and services is very limited. On the other hand, the
filter from our mother organization has several thousand rules (they make use of a similar script
with loops).
Verifying the accuracy of such a rule set cannot be done automatically, since the range of
possible test vectors is not small and, more importantly, involves a wide variety of complex external
systems. To complicate further, some services require replaying sequences of packets and reactions
from systems. Moreover, it is rarely the case where an organization has enough resources to have
a complete stand-by duplicate of the machines involved in the network and security infrastructure,
so that tests could be done without affecting or even disrupting the deployed systems. The usual
practice relies on manual inspection, and that is why some administrators try and structure the rule
set to ease that burden. This has to be managed throughout the continuing evolution and changes of
an organization, as well as security personnel replacements. Other firewall and security functions
present their own complexities, to a lesser or larger extent, requiring dedicated expertise.
§Laboratory of Network Administration and Security at IC-Unicamp.
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
We will now list a few example scenarios where it is hard to keep coherence among security
Insufficient knowledge by the security administrator about a certain packet filter platform
leaves a pathway for unauthorized traffic to access a given internal service. The administrator
was well-versed in the platform used at most packet filtering nodes on the organization’s
network, however some particular piece of network equipments used another filtering platform
whose specification language he/she was not so familiar with.
A subset of rules in a packet filter configuration not only allows a certain service to work
properly, but also allows more traffic to go through. This would probably be due to the said
service being complex in the way the application works and the fact that most packet filters
are static with respect to the parameters in their rules.
The security policy might say that all web accesses initiated by the organization (client
access) need to be logged and scrutinized, so that the administrator opts to implement the
service through a web proxy application. The proxy service is configured and a mechanism
for browsers to discover the proxy service is also set. The proxy was deployed on a bastion
host on the DMZ, however a later auditing reveals that the security administrator did not
write a rule set to prevent traffic from other processes running on the bastion host itself to
access the web.
Accessing ftp services by internal users was required by the policy and the administrator set
up a rule set for the packet filter. The security administrator proceeds with a rule set that
allows passive-mode ftp, since almost all browsers normally access ftp sites in passive mode.
However, a certain legacy application can only do active mode to retrieve data from a remote
location and therefore data cannot be transferred as expected for the correct working of the
given application. After the problem is fixed, it recurs later when another person is on that role
and wants to redesign security mechanisms to address evolving organization needs. Either
that small bit of information about the legacy application never makes it from the previous
person in charge, or although the requirement was properly documented, the current person
in charge misses that information in a heap of so many other sparse requirements. In the end,
the same malfunction is reported again to the security team.
Tracking that sort of problem might be really tough sometimes, and preserving the knowledge for
later employees is usually not simple, let alone organizing it in a way that ensures full compliance
when the need arises. It then becomes clear that guaranteeing security policy enforcement is very
demanding both in time and expertise, and ways of advanced security management are highly
required for current networks. Our initial approach to tackle this problem was to model the systems
involved in a hierarchically structured manner, as is presented in the next section.
MBM is based on the approaches of policy-based management [2]and management policy hier-
archies [3, 14], which aim to derive correct operational low-level policies from high-level abstract
policies by applying stepwise refinement. MBM introduces a hierarchically layered system model
which integrates the policy representations and supports refinement automation by supplying the
necessary details about the structure, functions and properties of the real system.
The model consists of object instances and associations (see Figure 2). It can be depicted as an
object instance diagram, which is structured into three rows and three columns. The rows represent
three abstraction layers:
The Roles and Objects (RO) layer represents the system in an abstract application-oriented
view providing abstract objects, abstract operations and user roles. It is concerned with the
A bastion host is a machine that provides a collection of services and is exposed to direct Internet access, usually
residing on a subnetwork especially designed for that kind of risky operation.
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
Figure 2. Common model structure of previous work on MBM.
kinds of actions and agents that take place in the realm of the network being modelled, more
like a functional view of the system.
The Subjects and Resources (SR) layer represents the system in a service-oriented view. Here,
subjects act on behalf of users and request service operations from services. Services access
abstract resources either directly or by means of other services. As the name implies, this
layer deals with instances of each kind of elements from the RO layer, yet still in an abstract
way. It is more like a production view of the system, one in which the resources available
must be considered in order to implement each function of the layer above.
The Processes and Hosts (PH) layer represents the system in a detailed implementation-
oriented view. As in a real network, the system consists of network links and nodes. Nodes host
application and server processes which communicate via protocol stacks, network addresses
and links. This is where abstract elements from the previous layer must be mapped to real
elements, as far as operating systems are concerned: there are processes (for each application
involved in security), network interfaces, communication sockets that answer for some of the
links between objects in the diagram, and even other host machines, since operating systems
must also be aware of them at the socket level in TCP/IP. Note that, for instance, the subtle
difference between a Web service, a still abstract description of a service to be provided
(described in the SR layer), and a Web server, i.e. a real server process, hosted on a given
machine speaks about the http protocol (in the PH layer).
Now we shall proceed with a more formal explanation of the structure implied by the model.
Each layer hosts a complete self-contained model of the whole system. Neighbouring layers,
however, are linked by refinement associations, e.g. an abstract object IntranetWWW in the RO
layer is linked to an abstract resource WebSite in the SR layer, which in turn is linked to some
html-file objects in the PH layer (Figure 3). Thus, links between neighbouring layers represent
refinement associations of the ‘is implemented by’ type. The columns (back to Figure 2) structure
the model objects according to their purpose:
The left column, System, contains the model objects which represent elements of the production
system, such as information services and application data resources.
Control (middle) contains objects representing components of security and management
On the right, Policy contains objects which specify policy elements.
The highest layer, RO, contains System and Policy objects only, e.g. System may contain an
abstract object IntranetWWW, an abstract operation Access and a role Employee;Policy may contain
an object Permission which is directly linked to IntranetWWW,Access and Employee.IntheSR
layer, the Control column contains services and abstract resources which provide management
and security functions, such as firewall filtering, authentication and authorization, whereas the
objects of the Policy column represent the configuration objectives for these control services. In
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
Figure 3. Simple example model (screendump from the MoBaSeC tool).
the lowest layer, PH, the Control column contains security service implementation components,
such as IPMasqueradingHost,Firewall and LoadBalancer.ThePolicy column objects specify the
configuration of the components (e.g. Access Control Lists) and can be translated into the concrete
configuration files needed by the components.
As an example, Figure 3 depicts a simple model scenario. The RO layer contains four objects
only (the role Employee, the abstract operation Access, the abstract object IntranetWWW and the
permission Employee-Access-IntranetWWW). The SR layer contains user Tom, the subject type
@work, the service WWWservice and the abstract resource WebSite; policy objects are not shown.
The PH layer models the given process, host and network structure (e.g. the application process
Browser on host Workstation1 communicating via the protocol http with the daemon process httpd
on host WebServer1); policy objects are also not displayed. Although Figure 2 suggests a fixed
structure on our modelling, the tool does not keep such a structured view all over the model,
for the sake of clarity in the diagrams. The horizontal structuring is mostly maintained, but the
vertical one is not so possible. In the example of Figure 3, one can identify or associate the Control
elements as the object Access in the RO layer and as WWWService in the SR layer. As for the PH
layer, the Control elements are what is known as processes in an operating system; in this case,
Login,Browser,IPMasqueradingProcess and so on. One notices also that the only visible Policy
element is at the top right in the RO layer.
MBM has already been applied to practical systems. In particular, L¨
uck et al. [4, 5]report on
the derivation of firewall and VPN configurations and L¨
uck [15]describe the detailed modelling
and derivation of configuration parameters for a series of existing security service products. The
models used in these works follow the general model structure described above.
In the RO layer, the static model of the well-known Role-Based Access Control approach
(RBAC) [16]defines Roles,Objects,AccessModes and AccessPermissions. It should be noted that
As can be inferred from the picture, not all the structures present in Figure 2 can be depicted by the graphical
representation that the tool provides.
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
RBAC Permissions are represented by an Object-AccessMode pair, similar to the decomposition of
privileges into operations and objects adopted by [17]. The many-to-many association between roles
and permissions is thus established by means of AccessPermission objects and their associations
with the corresponding Role,Object and AccessMode objects.
In the SR layer, sessions or subjects which activate roles and act on behalf of users are repre-
sented by SubjectType objects. The dynamic activation model of RBAC is contained in a static
approximation where all possible roles of a User-SubjectType pair are permanently activated. Thus,
aSubjectType object is used to represent typical settings in which a user can act in the system,
e.g. ‘@office’ or ‘@home’, representing the subjects that are activated by the user at the office
or at home, respectively. The Policy column contains mainly ServicePermission objects, granting
service access to subjects.
In the PH layer, what is modelled are Hosts, with their respective Network Interfaces and
Links,andProcesses that manipulate SystemObjects and perform communication actions using
Protocols.ThePolicy column contains basically ProtocolPermission and PathDescription objects,
which allow the transition of packets between processes.
Generally, the model and policy design starts with the development of the low-level system
model (System column in the PH layer) and its stepwise abstraction (System and Control columns
in the SR and RO layers). After the system is modelled in the RO layer, the abstract policy can
be designed and represented in the Policy/RO part of the model. In addition to this bottom-up
procedure, a top-down approach can just as well be used, in which the user starts with the modelling
of the RO policies and system objects and then gradually assigns corresponding objects in the
lower levels (SR and PH), eventually yielding a complete system model. In either case, the Policy
fields in the SR and PH layers need not be input by the modeller, since the MoBaSeC modelling
tool is able to automatically derive these two lower level policy sets. Beforehand, MoBaSeC checks
the structural completeness and consistency of the model. The algorithms applied in the checks
and the automated low-level policy derivation ensure that all the high-level policy elements are
completely and correctly enforced at the lowest level (under the assumption that the real control
elements operate correctly).
3.1. Scalability problems
A common problem of the existing applications of MBM occurs when dealing with larger systems,
since the model tends to lose much of its understandability, getting obscure due to the great number
of components (as attested in [18]). Indeed, it can be noted from the previous discussion that
the PH level—which shall depict the entire system, with its processes, hosts, network interfaces,
etc.—has its complexity quickly increased as the size of the modelled system grows.
This fact is also illustrated in Figure 3, which shows the model of a very simple scenario with
only one AccessPermission at the uppermost level: the workers of a company shall be allowed to
access the corporate web server. Despite the simplicity of this RO level, the model unfolds into
a considerable number of objects at the lowest level (bottom of Figure 3), in order to represent
mechanisms, such as IP-masquerading, firewalls and load balancers.
Owing to the simplicity of this example, the resulting model is still reasonable. However, it can
be noted that models of larger real environments tend to become quite confusing. Furthermore, the
refinement algorithms must consider this large number of model elements, for example, in costly
path discovery processes. This results in a restricted support for the realistic, complex network
environments of today’s organizations.
The approach of ASs applies the well-known principle of modularization [19]in order to overcome
the scalability problems of previous MBM work. This is accomplished by substituting a new
abstraction layer for the PH layer: the DAS, which is located immediately below the service-
oriented view of the system (SR layer) and is in fact a major enhancement to the previous PH
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
S & R
R & O
Managed System Policies
Figure 4. Enhanced MBM model overview with the new DAS layer.
layer. The DAS abstraction now allows one to describe the overall structure of the system to be
managed in a modular fashion, i.e. to cast the system into its constituent blocks (ASs) and to
indicate the connections between them. Each AS in DAS is complemented with an extended view
of the system’s actual mechanisms, called ES, which corresponds to the previous PH layer. As
such, each AS abstracts and hides a corresponding PH-subsystem that will be visible only after
an individual expansion of the subsystem (further details in Section 4.2), so as to overcome the
scalability limitations found in the previous model approach.
Figure 4 depicts the three-layered structure of the enhanced model in our technique. The
horizontal dashed lines delimit the abstraction layers of the model: RO, SR and DAS. As for the
vertical subdivision, it differentiates between the model of the actual managed system (system and
control on the left-hand side) and the security policies that regulate this system (on the right-hand
side). The two topmost layers come from previous work on MBM and are extended. The third
model layer (DAS) is new and aims at improving the scalability of the modelling technique.
4.1. The DAS layer
A DAS is a graph comprising ASs as nodes and edges that represent the possibility of bi-directional
communication between two ASs. An AS, in turn, contains an abstract view of a certain system
segment, i.e. a simplified representation of a given group of system components that may rely on
the following types of elements:
Actors: Groups of individuals that have an active behaviour in a system, i.e. they initiate
communication and execute mandatory operations according to obligation policies.
Mediators: Elements that mediate communication, in that they receive requests, inspect traffic,
filter and/or transform the data flow according to the authorization policies and perform mandatory
operations based on obligation policies (e.g. logging).
Targ e t s : passive elements; they contain relevant information, which is accessed by actors.
Connectors represent the interfaces of one AS to another, i.e. they allow information to flow
from and to an AS.
The first three types account for system elements that have a relevant behaviour for a global,
policy-oriented view of the system, whereas the latter accounts for the physical interfaces between
ASs. In this manner, a DAS supports the reasoning about the structure of the system with respect
to the executable security policies, thus making explicit the distribution of the different participants
of these policies over the system. Furthermore, in order to model the security policies themselves,
another object type is also present in a DAS: ATPermissions (ATP). An ATP is associated with
apath pin a DAS that connects an Actor Ato a Target T, possibly containing a number of
Mediators and Connectors along the way. It expresses the permission for pto be used by Ain
order to access T. In this manner, each ATP models an authorization policy. The ATP objects in
the system are not defined by the modeller, but rather derived automatically as explained later.
The reader can see Figure 5 which shows how ATP objects fit into the model.
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
internet websites
Firewall 1 Firewall 2
internal network
web proxy
internal web client
ATPermissio n
Figure 5. DAS example.
4.2. Expanded subsystems
Each AS in a DAS is also associated with a detailed view of the system’s actual mechanisms.
This expanded view is called ES and is related to the PH layer of the previous work on MBM,
with the difference here that they are segmented into subsystems that correspond to the ASs of
the previous section. As such, an ES encompasses objects of the same classes of the PH layer,
e.g. hosts, credentials, processes, protocols, etc. These basic classes are used to define both the
components of the system itself and the security mechanisms employed to control the activity of
the former.
Note that the ES representation has a static character, i.e. it is a picture of the system components
and connections, but does not include a behavioural description of their interactions. Therefore,
in the modelling of processes, an object actually stands for a prototype of processes that might
occur in the real environment. One should thus see a process object not as a picture of a particular
process executing in the real world, but rather as an abstraction that holds the relevant common
properties of all similar processes that can be launched on a certain host.
4.3. Example of DAS and ES
An example of DAS is shown in Figure 5. This diagram corresponds to a simple network environ-
ment with three ASs: ‘internal network’, ‘dmz’ (demilitarized zone) and ‘internet’. In the ‘internal
network’, the object ‘internal web client’ is an Actor representing a group of processes that are
authorized to access the processes mapped by the Target ‘internet websites’ (in the ‘internet’)
through the Mediator ‘web proxy’, and the two firewall objects in the ‘dmz’ subsystem. This
authorization is represented by the policy object ‘ATPermission’, which is associated to the path
marked by grey, thicker and dashed arrows.
Figure 6 shows the expanded view for the AS ‘internal network’ (Figure 5). Each object in the
abstract view of the AS is then related to the elements that model the corresponding real entities
of the system in the ES area; for instance, the Actor ‘internal web client’ is associated with its
respective Process-typed objects. This double representation of an AS provides the designer with
a flexible model of the system that enables him/her to alternate between a more abstract, concise
and understandable description of the system’s structure, and a detailed view of its mechanisms—
depending on his/her attention focus.
In the MBM approach, the MoBaSeC software tool firstly assists the modelling by means of a
diagram editor, and then automatically derives lower level policies based on the defined model
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
internal network
web proxy
Firefox IE
proxy host
ws 1
ws 2
internal web clients
Figure 6. Expanded subsystem (ES) example.
entities. The subsequent sections elaborate on the practical aspect of our approach by presenting
in turn the tool support offered to the modeller, the automated policy refinement and a discussion
on the correctness of this automated process.
5.1. Tool
MoBaSeC’s architecture is generic in such a way that different MBM applications are covered
by the same common tool. The details of a certain application domain are defined by means
of a meta-model, i.e. a set of classes that specify the node classes of each layer, the allowed
connections between classes and the consistency rules to which each model instance must comply.
These rules define the properties whose values must be set (i.e. mandatory properties), the allowed
range for values, the minimum and/or maximum number of connections to objects of a given
class or any other structural consistency restriction concerning the model entities. In addition,
the meta-model encloses the implementation of refinement algorithms that generate lower level
policies for a model instance. Therefore, the same tool can be used to support the management
of an arbitrary application context, as long as there is a meta-model that defines the structure and
refinement procedures for models in that particular context.
MoBaSeC is implemented in Java and basically consists of an object-oriented graph editor (for
a comprehensive explanation of the tool see [15]). Figure 7 shows the appearance of the tool
running on a KDE environment, albeit with the elements reduced to satisfy the size restrictions.
To define a model instance, the user simply selects one of the classes available in the meta-
model and creates a new object of this class in a window that contains a view of the model
instance. Connections between two objects are established by dragging-and-dropping edges to
connect the objects. Property values are set by means of pop-up windows. Furthermore, the tool
checks the consistency rules defined in the meta-model in order to ensure that the model instance
is valid. The verification of basic rules is performed on-the-fly as the user inputs the model objects
and properties—e.g. whether a connection between two objects is allowed. Once the model is
complete, a menu item can be used to trigger a more comprehensive model checking, in which a
number of general consistency rules are applied, and the problems found are listed in a separate
5.2. User interface enhancements
A specific meta-model was developed for this work, consisting of a set of classes and methods
that define (1) the possible model elements and their potential connection to other element types,
(2) consistency checks to be applied to model instances, and (3) the refinement algorithms that
implement the procedure described in Section 5.3 further down. Furthermore, in order to enhance
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
Figure 7. Graphical interface of MoBaSeC’s tool.
the handling of large models, the tool also incorporates the focus and context techniques semantic
zooming and fish-eye views. They will be explained in the subsequent sections.
5.2.1. Focus & context. The term focus & context refers to techniques that allow a user to centre
his view on a part of the model that is displayed in full detail (focus), while at the same time
perceiving the wider model surroundings in a less detailed manner (context). These techniques
bring the advantage of improved space-time efficiency for the user; i.e. the information displayed
per unit screen area is more useful and, consequently, the time required to find an item of interest
is reduced as it is more likely to be already displayed [20].
We employ the focus & context concept within two different methods. First, it is applied to the
structure of compounded elements of the model, i.e. to the model entities that aggregate a group
of simple objects. This application explores the exhibition of these entities in different levels of
detail and is called semantic zooming. Second, we employ a visualization technique that relies on
a specific graphical projection of the model into the two-dimensional Euclidean space, which is
called fish-eye view. Both are detailed in the subsequent sections.
5.2.2. Semantic zooming. Semantic zooming [20, 21]is based on the ability to display model
objects in different abstraction levels, depending on their distance from the focus. Thus, objects
inside the focused region of a diagram are exhibited in their full detailed form, whereas objects
located at the borders are shown in the most simplified way. The regions between these two
extremes are displayed with intermediary levels of detail. This way, the information presented is
selectively reduced by adjusting the level of detail in each region to the user’s interest in that
region, a basic principle for focus & context techniques. However, in the particular case of semantic
zooming, the different levels of detail employed are not related to graphical properties of the
objects, but rather to the kind of information that they represent; i.e. to their semantics.
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
Figure 8. Semantic Zooming applied to an AS.
In our context, there are two classes of compounded objects to which semantic zooming is
applied: typed folders and ASs.Atyped folder is an object that aggregates a group of objects of
the same class (or type), for the sake of conciseness of the representation. Conversely, ASs contain
objects of various classes (see Section 4.1) and may also enclose typed folders. In both cases, the
level of detail shown can be changed by the selective display of internal objects.
Typed folders have two different representations available: a closed (all internal objects are
hidden) and an open folder view. ASs, however, make use of three different levels of abstraction:
(i) a full detailed view that includes all the internal objects, i.e. both the abstract and the expanded
view; (ii) an abstract representation encompassing only the objects pertaining to the abstract
view and (iii) a ‘closed’ view in which no internal objects are displayed. These three different
representations are shown in Figure 8, with decreasing abstraction levels that range from closed
folder view (left) to a complete detailed view (right).
5.2.3. Fish-eye view. The term fish-eye view is used for the type of projection created by a fish-eye
lens used in photography. This type of lens achieves a 180field of view and is uncorrected. It
results in an optical enlargement of objects near the centre in relation to those at the borders. This
feature emulates the human visual perception, which by the effect of the eye movements has a
clear focused area and a gradual loss of visual resolution in the direction of the peripheral regions.
A fish-eye view combines thereby a complete image overview with a gradual degradation of detail
that increases with the distance from the focus—and it is thus well suited to implement the concept
of focus & context. In contrast to semantic zooming, the fish-eye view manipulates the size of the
objects to change the amount of information displayed.
We capitalize on the works of Furnas [22]and by Sarkar and Brown [23]by choosing a variable
radius implementation, since the enlarged focus area is bigger. The variable radius is defined
dynamically as the distance between the focal point and the image borders. Its advantage over the
fixed radius implementation can be seen in Figure 9. We employ a variable radius approach in
which the focus area can also be freely moved by the user throughout the model. As a consequence,
objects within the focused area are displayed in an enlarged scale, whereas the others become
gradually smaller as they approach the model borders. The modeller is still able to perceive the
context in which he/she is working while at the same time being spared of useless details by
optical miniaturization.
The transformation function used [23]is defined based on the distance rbetween the centre of
the view and the coordinates that should be projected:
(v +1)r
In this expression, the distortion parameter v0 controls the relative enlargement of the focused
area in relation to the surroundings. The variable radius rmax is the length of the radius rextended
up to the border of the visible view area.
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
Figure 9. Fish-eye view with fixed (l)and variable (r)radius.
Figure 10. Crossing of edges caused by fish-eye view distortion and its prevention.
As a trade-off between efficiency and quality of the graphical projection, the edges of the models
are drawn as lines (Figure 9, right) and are not continuously transformed into curves (left). While
the use of curved edges in the fish-eye view would improve its graphical quality, calculating the
coordinates of each pixel on the edge—through the transformation function—each time the focus
is moved by the user is too costly. In the context of modelling networks with nodes and edges, it
suffices for edges to be drawn as straight lines. No photo-realistic fish-eye view is needed as they
aim only to represent a connection between two nodes, and in fact the overall visual appearance
resulting from our decision seems much more useful.
However, the intrinsic distortions introduced by fish-eye view, together with the representation
of edges as straight lines, may lead to undesirable edge crossings, as can be seen in Figure 10
between the outstanding nodes. We get around this by having the drawing function insert temporary
intermediate points in the affected edges (dotted edge in the example). Similarly, the graphical
display of AS elements are not distorted but are still drawn as rectangular boxes. In Figure 11,
one should note that the focus is on the leftmost AS, which is displayed on a larger scale; it is
gradually reduced as one moves to the right.
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
Figure 11. Visualization of a DAS in the fish-eye view with the simplification used.
5.3. Automated policy hierarchy building
After a valid model instance is input, the supporting tool automatically builds a policy hierarchy by
deriving lower level policy sets from the policies specified at the most abstract layer. This process
is termed in the literature policy refinement [3, 24]or policy transformation [14]—we adopt in this
work the first one.
In our approach, AccessPermissions represent authorization policies in the uppermost model
level (RO). The AccessPermissions set is supplied by the modeller and acquires in this context
a particular meaning. On one hand it defines the explicit permission for Roles to access Objects
(inthewaydenedbyanAccessMode)—corresponding to positive authorization policies. On
the other hand, we adopt closed policies, i.e. the default decision of the reference monitor is
denial. This implies that all triples of Role,Object and AccessMode not belonging to the set of
AccessPermissions are forbidden. They thus implicitly define the negative authorization policies
which the security mechanisms must as well enforce.
As for explicitly defined obligation policies—i.e. event-triggered condition-action rules that
can be used to define the activities subjects (human or automated manager components) must
perform on objects in the target domain [25]—these are not represented in MBM since the
modelling used in MBM builds upon RBAC (Section 3), which in its basic form does not include
obligation policies (referred to as duties in [16]). However, in the context of security management,
authorization policies alone are not sufficient, since they are not well suited to deal with fine-grained
security properties of authorized communication. Therefore, besides the above policy elements,
our modelling framework also includes an extension to the RBAC model by means of the classes
SecurityGoals,SecurityRequirements and SecurityAssumptions. Objects of these classes are defined
by the modeller and represented by a vector of desired values (natural numbers from 1 to 5) for
the security levels of confidentiality, integrity, availability and traceability.
During the process of policy refinement described in the sequence, the security levels warranted
by mechanisms (SecurityAssumptions) are thus checked against the security requirements
prescribed in the SecurityRequirements. As such, a SecurityRequirement with a high level of
confidentiality could determine, for instance, the decision between using an encrypted tunnel
instead of plain text. Another practical example occurs when a security mechanism that supports
logging has this functionality activated in order to fulfil the high traceability level required by the
prescriptive SecurityRequirement associated to the SecurityGoal of its corresponding AccessPer-
mission. The examples show that, though SecurityRequirements do not directly represent general
obligation policies, the analysis of the security requirements they express can yield configuration
parameters for mechanisms that do correspond to the “need to do” aspects in the system, and
hence to a specific type of obligation policies.
All these different connotations of policies at the highest level must be propagated to the inferior
levels by the policy refinement process. To help the reader understand how the different policy
elements fit together, Figure 12 presents a view of our system with emphasis on the policies
and their relations. One can see rounded-corner boxes, representing the model entities defined
by the modeller, and rectangular ones, representing the objects generated during the automated
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
RO level
SR level
Access Modes
Managed System
Security Goals
Path Security
Figure 12. How different policy elements fit together.
refinement process. Similarly for the connecting lines, the thinner, not-arrowed ones stand for
the assignments given by the modeller, while the thicker, arrowed ones represent associations
established automatically during the refinement process. On the right hand columns of this figure,
one can notice that the policy refinement is subdivided into two parallel tracks, corresponding to the
two policy types supported by the modelling: security goals and requirements,andauthorization
The following sections explain the stepwise refinement process for each model level from the
viewpoint of the modeller (the checking of security requirements are omitted here for the sake
of brevity; for further elaboration on the policy support, and on the refinement algorithms, see
5.3.1. RO/SR refinement. The automated refinement of authorization policies starts from the anal-
ysis of AccessPermissions in the RO level and their related objects, in order to generate a set of
corresponding permissions in the SR level. Thus, each triple of Role,AccessMode and Object,<r,
am,o>, related to an AccessPermission produces a set of 4-tuples, <u,st,sv,r>, each of which
expresses an authorization for a SubjectType st on behalf of a User u to request a Service sv in
order to access a Resource r.
A refinement example is shown in Figure 13. The AccessPermission ‘allow Internet surfing’
is refined into the ServicePermission ‘sp1’ that associates the objects ‘internal user’, ‘@main
office’, ‘WWW proxyservice’ and ‘Internet webpages’. Each of these elements refines an RO-level
object that is related to the permission ‘allow internet surfing’, namely ‘Employee’, ‘surfing’ and
‘Internet WWW’. Note that ‘WWW proxyservice’ cannot access ‘Internet webpages’ directly,
instead depending on the service ‘Internet webservice’.
5.3.2. SR/DAS refinement. Subsequently, ServicePermissions are refined into ATPermission
objects (actor-target permissions, ATP for short, see Section 4.1). As ATPs are paths in the
DAS graph, this refinement phase consists of, for each ServicePermission <u,st,sv,r>,
finding the shortest path between each Actor that is connected to the pair <u,st>, and each
compatible Targ e t that is connected to a Service-Resource pair <svt,r>, which is defined
as follows: if the service sv has direct access to the resource r,thensvt—i.e. the service
related to the Targ e t —and sv will be the same. Otherwise, sv must rely upon a dependency
chain that leads to svt, in order to access r. In this case, to each service that takes part in the
dependency chain, a corresponding mediator must be found along the path between Actor and
Targ e t.
An example for this refinement step is given in Figure 14, which continues the refinement of
the previous section. For the ServicePermission ‘sp1’, the refinement algorithm determines the
ATP ‘atp1’, which is represented in the figure by the grey, dashed arrows, starting from the ATP
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
allow internet surfing
Internet WWWsurfing
internal user
@main office
internet webpages
WWW proxyservice
internet webservice
Figure 13. Example of RO/SR refinement.
internet websites
Firewall 1 Firewall 2
internal network
web proxy
internal web client
internal user
@main office
internet webpages
WWW proxyservice
internet webservice
FWService sp1
Figure 14. Example of SR/DAS refinement.
object and ending at the Actor ‘internal web client’. The Actor is connected to the SR-level objects
‘internal user’and ‘@main office’, which are related to the policy ‘sp1’.
The path traverses the Mediators ‘web proxy’, ‘Firewall 1’ and ‘Firewall 2’ (as well as some
connectors along the way), and ends at the Targ e t ‘internet web sites’ (indicated by the dashed,
arrowed line in grey that goes through those objects), which is in turn connected to the Resource
‘internet webpages’. Note that the Mediator ‘web proxy’ that refines ‘WWW proxy service’ must
be in the path, since there is a dependency chain for this service to reach the Resource ‘internet
web pages’; otherwise, ‘atp1’ could use the shortest path that goes from ‘internal web clients’,
through the connectors, directly to ‘Firewall 1’.
5.3.3. DAS/ES refinement. The following refinement phase comprises the automated generation
of policies that takes into account the equipment and security mechanisms defined in the ESs.
For this purpose, the tool generates, for each ATP, a corresponding AllowedExpandedPath (AEP)
that represents an authorized path in the ES views. Each AEP connects a process (that refines an
Actor) to other processes (that refine the Mediators and the Targ e t ) through their related protocol
stack, interface and network objects. As the path discovery was already accomplished in the
previous refinement step, the DAS/ES refinement algorithm is quite simple. It just expands the
ATPs according to the related objects in the detailed view of the ESs.
The ATP of the example in the previous section and one of its corresponding AEPs are shown
in Figure 15. The path allowed by ‘aep1’ is marked in the figure by dot-and-dash arrows. For the
same ATP, an additional AEP, similar to ‘aep1’, is also generated, beginning in the process related
to ‘workstation2’; it is omitted in the figure for the sake of clarity.
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
interne t
internet websites
web server
iis web files
Firewall 1 Firewall 2
FW host 1 FW host 2
FWProcess 1 FWProcess 2
internal network
web proxyinternal web client
workstation 1
workstation 2
proxy server
Figure 15. Example of DAS/ES refinement. As this illustration comes straight out of a screendump, the
original screen resolution limits and distorts small details, such as the chain of objects that is typically
between a machine process and a network interface, e.g. HTTP, TCP and IP.
5.3.4. Configuration parameter generation. In the last phase of the refinement process, a special
back-end function for each supported mechanism type is executed. It analyses the characteristics
of each AEP that passes through the mechanisms of a type (such as communication protocols,
addresses and ports) to produce corresponding low-level, device-dependent configuration parame-
Clearly, the configuration for a given mechanism must allow only the accesses corre-
sponding to the AEPs that traverse the mechanism. For instance, considering ‘aep1’ (example in
Figure 15), a back-end function for the specific web proxy that is used analyses the path and
converts it into configuration parameters for the proxy mechanism on the host ‘proxy server’, in
order to allow the access. Another specific back-end function will then analyse ‘aep1’ and generate
configuration files for the two firewalls in the subsystem ‘dmz’, i.e. it will produce packet-filter rules
that correspond to the characteristics of the path (addresses involved, protocol, ports, connection
orientation, etc.).
5.4. Refinement correctness
The consistency among abstraction levels, i.e. the refinement correctness of a policy hierarchy is
a crucial issue to ensure that the behaviour of the real system indeed complies with the abstract
policies. Therefore, we developed a formal approach to the validation of the policy hierarchies
generated in this work (this section presents a summary of the results achieved; for an extensive
coverage of the subject see [9, 10]).
Following the literature on multi-layered policy hierarchies [24, 25]and considering the special
meanings conveyed by policies in our approach (see Section 5.3), two correctness criteria were
Completeness, i.e. the desired behaviour specified by the abstract system obligation policies
is completely implemented at the lower levels and
Consistency, i.e. none of the actions enabled at the lowest level is in conflict with the abstract
authorization policies.
As such, completeness warrants compliance with the explicit positive policies, while consistency
makes sure that the implicit negative policies are enforced. Based on these criteria, two types of
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
conditions were defined:
Refinement Conditions regulate the relation between elements of policy sets of two adjacent
abstraction levels and
Structural Consistency Conditions regulate the interrelations of the policy elements of the
same layer.
The conditions were defined for each of the refinement phases described in Section 5.3. Subse-
quently, in order to be able to reason about the possible system behaviour that results from the
application of the generated configuration, model representation axioms were defined that formalize
the implicit assumptions behind the model. These axioms state assumptions concerning both the
mapping of real world entities to the model objects (correct modelling) and the effective applica-
tion of normative aspects in the model to the real system (correct implementation). Relying upon
axioms and conditions, two validation theorems were proved:
VT1: For each high-level policy, the system enables all accesses in the real world that
correspond to the policy.
VT2: To each possible access in the real world there is a corresponding high-level policy.
The two theorems correspond to the elected validation criteria of completeness and consistency,
so that the meaning of the formal proofs is: once a model complies with the conditions defined
and the axioms hold, the refinement process is correct; i.e. the generated system configuration
conforms to the defined abstract policies.
Our approach and associated tool impact security configuration management in several ways,
which leads to the need to perform experiments and analyses to evaluate different aspects of the
system. We identify the following areas where the MBM/DAS/MoBaSeC approach can benefit:
(i) how large models are handled; (ii) how the modeller is faced with the representation of complex
systems; (iii) the automatic generation of configuration files and (iv) how well the tool fares with
regard to scalability. As a reminder, correctness is discussed elsewhere [9, 10]. The subsequent
sections will present and discuss the results covering those areas.
6.1. Handling of large models
We will here compare our approach with the usual technique to deal with large models, which rely
on zooming based on linear enlargement of a fixed-size model cut-out. The screen size imposes
a limitation in the navigation and visualization abilities of graphical tools and so requires from
the user an excessive number of steps to perform usual tasks. The benefits brought forth by the
fish-eye view technique can more easily be seen by considering the execution of a simple design
task on a large model∗∗. First we will consider the steps required with linear enlargement zoom
and then the same procedure for the fish-eye view.
The task consists of connecting an object in the area of the model that is currently located at the
opposite end of the target destination. The standard linear zoom method requires the following steps:
1. Scale down, in order to be able to see the entire model.
2. Estimate the locations of the target and source objects in the out-zoomed view, and the angle
of the edge needed to connect them.
3. Enlarge the area around the source object, in order to be able to select it.
4. Select the source.
5. Drag a new edge from the source into the direction of the previously estimated angle (the
enlarged region of the model moves automatically following the mouse).
∗∗Even the simplest of the network scenarios will easily exceed the graphical ‘real estate’ that current computer
screens offer.
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
Figure 16. Fish-eye view with focus centred at the source node.
6. Try to locate the intended target by panning around the region where the pointer landed.
7. Stop the dragging once the target can be seen on the screen.
8. Drop the edge on the target object to mark it as the endpoint.
With the fish-eye view, on the other hand, the required steps will be
1. Activate the fish-eye view mode.
2. Select the source object, which is displayed inside the enlarged focus area (Figure 16).
3. Drag a new edge from the source into the direction of the target, whose location can be
simultaneously seen in the down-scaled surroundings (the focus follows the mouse during
this process, so that the target can eventually be seen in detail).
4. Drop the edge on the target object (the area around the target is enlarged as shown in
Figure 17).
As can be seen, in this case the fish-eye view technique halves the number of steps needed to
accomplish the task and provides an even greater reduction in the amount of time taken from the
user, since the abrupt scale switching with traditional zooming is bound to disorient the user for
a while. Conversely, the fish-eye view technique presents an intuitive usage, preventing the user
from ever losing sight of the full context of the model.
6.2. Combining semantic zooming and fish-eye view
As both focus & context techniques previously introduced (Sections 5.2.2 and 5.2.3) operate on
orthogonal subjects—namely, fish-eye view on graphics and semantic zooming on structure—it
seems reasonable to combine their use: they do not influence each other and each one has no side
effects that could be detrimental to the use of the other.
We use the scaling factor resulting from the fish-eye transformation function to set a level of
detail attribute on each compound element of the model (ASs and TypedFolders), which is then
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
Figure 17. Fish-eye view with focus centred at the target node.
used to adjust the abstraction level for displaying a given element. As a result, the greater the
difference between the scale of the focused area and the one used to display the element, the
higher the non-linearity in the display of that element. As the distance between the focus and a
certain object increases, that object is gradually represented in a more abstract view—which per se
has a smaller graphical representation—and also graphically shrunk by the fish-eye view function.
Thus, a larger focused area is made possible even with a larger context still visible, leading to an
optimization of the screen space.
The end result can be seen in Figure 18, for the same example used in Figures 16 and 17.
The focus is on the larger AS (bottom right), which is displayed at a scale large enough to allow
comfortable editing of its elements. The second largest AS is contextually close to the one on
focus, and so is ‘benefited’ with a larger size and correspondingly higher level of detail, as opposed
to the other smaller ASs, which are nevertheless still visible. Notice that the small AS on the top
right is topologically closer to the focused AS (bottom right) than the second largest one (top left),
but did not deserve even an equivalent level of detail as it is contextually farther away.
6.3. Examples of generated configuration files
To exemplify the back-end functions that were implemented in the context of this work, two simple
model cases are presented: the OpenBSD pf packet filter, and the VPN daemon isakmpd for the
same operating system.
The back-end function for the generation of packet-filter rules evaluates all AEP paths that
pass through a given firewall process in the model, so as to discover the start and end points for
each connection that will be allowed to cross the firewall. The simplest case here is comprised
by connections that start with a process associated to an Actor, and end up in a process associ-
ated with a Targ e t , i.e. direct connections without proxies, VPN tunnels or active intermediaries.
In this case, the packet filter rules can be composed directly with the IP addresses of the start and
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
Figure 18. Fish-eye view combined with semantic zooming.
ending nodes of the path AEP. These addresses and other information extracted from the nodes of
the AEP (e.g. interfaces, ports, etc.) are then used to produce packet-filter rules for pf.
For more complicated cases in which there are VPN tunnels and proxies, the back-end func-
tion decomposes a path into a number of subpaths (for instance, the subpath between two
VPN gateways), in order to determine the start and end points of the different connections that
need to be established. Special nodes that serve as separation points in these paths are Actor,
Targ e t ,Proxy and VPN processes. After the discovery of these subpaths, the problem is reduced
to the simplest case above and packet-filter rules corresponding to each subpath can then be
As for the back-end function for VPN gateways, its task consists basically of reading the lowest
level policies that require the establishment of VPN tunnels, and of producing the configuration
files for each pair of VPN gateways that must establish such tunnels. In doing so, the function relies
upon some information about the process nodes associated to VPN Gateways, such as certificates
and IP addresses, which are thus used to generate the configuration files for isakmpd.
6.3.1. Packet filter example. We will now consider the simple packet filter model shown in
Figure 19. The RO level allows the employees to surf on the internet, and the security goal and
associated requirements are low, such that they have no influence on the refinement process. Thus,
the actor ‘Client’ is allowed by the ATPermission to access the target ‘Webserver’ via the mediator
‘Firewall’. The AEP (allowed expanded path) is derived from ATPermission, so that the generated
configuration for the packet filter pf on the right-hand column of Figure 19 reflects the information
contained in AEP. In the ‘VARIABLES’ section, the network interface names are associated to
aliases that will later be used in the filter rules of section ‘FILTER’. In there, one rule for each
interface is created, in order to allow the traversing of packets from IP to the
Webserver with address and port number 80. The only difference between the two
rules is the connection direction: $interfaceNo1 (em0) must accept the incoming connections
(pass in), whereas $interfaceNo2 (em1) must allow these connections to pass out. As pf has
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
Web Client Server
em0 em1
internal user @office
allow internet surfing
surfing web SecurityGoal
SecurityRequirementWWWService WebPages ServicePermission
ATPermissio n
Figure 19. Simple packet filter model after refinement and generated configuration file.
stateful capabilities, i.e. it is a dynamic packet filter††, the option keep state makes the packets
in the reverse direction that belong to the same connection to be automatically allowed.
6.3.2. VPN example. As in the previous example, the intent here is to enable employees to access
the company’s internal web server. In this case though, the server is located at another network
that is connected to the workstations’ network through the Internet, as shown in Figure 20 (left).
The security requirements associated to the service and resource of this example require security
levels that are not fulfilled when the communication is performed directly through the Internet
(see Section 5.4), since the security assumption of the AS ‘Internet’ (1,1,1,1) is lower than the
requirements (2,2,2,2). Thus, the tool automatically chooses the path that connects the main office
to the branch office via a VPN tunnel established by the two VPN gateways.
In case the requirements are fulfilled without the VPN tunnel—for example, if the requirements
were set to (1,1,1,1)—the refinement algorithm would choose the shortest path from actor ‘intern
client’ to target ‘webserver’, which bypasses the two VPN gateways. As such, no configuration for
the processes ‘isakmpd 1’ and ‘isakmpd 2’ would be generated. The processes will be configured
only when there is an allowed communication flow that passes through them.
In the example of Figure 20 (left), the path <internClient,VPNGateway1, Cbranch,Cinet,Cmain,
VPNGateway2, Webserver>is able to fulfil the requirements due to the Tunnel <VPNGateway1,
Cbranch,Cinet ,Cmain,VPNGateway2>, which is established by ‘EncryptionService’.
In order to generate the configuration files from the derived AEP, the properties of the involved
objects must be provided in as follows:
For the Certificate, the property distinguished Name must be set to the name of the Certificate
Authority that signs the certificate. In the example:
††Filters that keep track of the history of packets, thus being able to correlate TCP-PDU-packets with a TCP-connection
and reply-datagrams with their corresponding UDP-queries.
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
internet (1,1,1,1)
main office (2,2,2,2)
VPN Gateway 2
certificate 2
isakmpd 2
httpd website
branch office (2,2,2,2)
intern client
VPN Gateway 1
certificate 1
isakmpd 1
@main office internal u ser
allow internet surfing
internet wwwsurfing
SR (2,2,2,2)EncryptionService
SR_max (2,2,2,2)
SA_max (1,1,1,1)
ATPermis sion
Figure 20. Simple VPN model after refinement and generated configuration file.
The IP address used for the communication with the other gateways must be inputted in the
corresponding property of the IPSEC protocol object that is associated to the VPN process.
The value for the process ‘isakmpd 1’ in the example is
The network address and network mask of the network to which the VPN gateway is connected
must be provided through the corresponding properties. In the example, for the process
‘isakmp1’ the values are respectively and
Figure 20 (right) shows the configuration file isakmpd.config generated for the process
‘isakmp1’. Additionally, the tool generates further information that is presented in the hidden
tabs of the generated configuration file: (1) tab Read me contains instructions for activating the
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
home PC external dns client external mail client
external file client
external web client
main office
internal web client
internal file client
internal mail client
internal svn client internal dns client
IS client
branch office
branch vpn
branch www branch mail
branch FW
branch dns
main vpn
public webserver
E-Mail forwarder external DNS
main FW extmain FW int
server network
Repository SQL Server
Mail ServerFile Server
internal DNSserver FW
Information System
anonymous surfer
any mail server public DNS
anonymous mail sender any www server
Figure 21. DAS for the case study environment.
VPN gateway; (2) tab certify contains a script that generates certificates; (3) tab Pol i cy sets the
distinguished name and (4) tab pf.conf disables all the traffic that do not correspond to the allowed
VPN communication to pass through the VPN gateway.
6.4. Case study on scalability
In this section, we outline a case study that considers the network infrastructure of a fictitious,
yet realistic, software development company. In doing so, and comparing with other scenarios, we
show how the system achieves scalability, both in terms of the size of modelled network and the
complexity of the security subsystems involved.
In this scenario a group of developers and some administrative employees are based at the
company’s main office. At a geographically distant branch office, another group of administrative
employees work to take care of activities regarding marketing and client relations. While all
employees are allowed to use the computers in the main and branch offices in order to surf on the
Internet and to access e-mail facilities, only administrative employees may work from home. On the
other hand, the developers have exclusive access to a version control system and to an information
system specially designed for their needs. The company also occasionally hires freelancers to act
as beta-testers for the developed software products. For this purpose, the developers must make
available the versions to be tested in a specific file server, to which the beta-testers should have
The networked IT system consists of the following main segments, which correspond to ASs
and are depicted in Figure 21:
Main Office: The company’s headquarters, where three pools of workstations are available for
common use by developers and administrative employees, plus an Internet terminal available for
all employees.
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
Server Network: The server network is separated from the main office’s network by an internal
firewall. It comprises all servers that are solely intended for internal use, i.e. only by employees at
the main and branch offices, as well as those accessing the internal network through a VPN tunnel
from outside. Its main components are a web proxy (for logging of web activity and performance
optimization), a DNS and a mail server. In contrast with these servers that are available to all
employees, there are also machines with more restricted access: a file server, the information
system server, a database server (necessary for the information system; this shall be accessed for
remote configuration purposes only by developers), and the version control server.
DMZ: The Demilitarized Zone contains servers that should be accessed from outside. A Mail
Forwarding Server is used to forward mail from inside to outside and vice versa. Similarly, an
external DNS server is responsible for answering external queries on the company’s domain names,
as well as for resolving queries forwarded by the internal name server. A web server is employed
to publish the content made available for public access via web. Additionally, a VPN gateway is
also placed at an isolated network to allow employees to access internal network facilities via the
Internet. A quad-homed firewall thus mediates communications of the VPN gateway’s segment,
the DMZ itself, the internal network, and the Internet.
Branch Office: At the branch office, another pool of workstations is available for employees.
The branch office network is protected by a simpler firewall and a VPN gateway that logically
joins both offices.
Home: Administrative employees and beta-testers can access the internal network from home
or elsewhere via the Internet. This access shall be performed using a VPN connection.
Having as input the abstract policy statements and the described network scenario, the configu-
ration development process exemplified here follows a top-down approach [11], evolving through
the following steps:
1. modelling of the abstract policy (RO layer of Figure 4),
2. definition of the system services and their relations to the abstract elements of the preceding
step (SR layer of Figure 4),
3. modelling of the relevant system elements by means of their abstract representations (i.e. the
ASs) as well as their relations to the objects of the service-oriented system’s view (cf. Figure
4. modelling of the ES for each AS in accordance with the real network,
5. automated refinement of the high-level policies at the RO level through the other abstraction
levels, culminating in the generation of the low-level configuration parameters for the security
These steps can be performed according to the spiral development process [26]: a given subset
of the system and policies is first chosen and the steps above are executed considering only that
subset. The development proceeds by iterating the steps in order to consider an increasing part of
the system and policies, so that at the end a complete model is thereby produced. In the context
of this work, the incremental process can be based on the subdivision into ASs, such that the
designer starts with a given subsystem and the local policies to it, i.e. the policies to which the
actor,target and mediators are bound in the considered subsystem. Thereafter, one subsystem is
added in turn, together with the policies related to the set of subsystems considered so far, up to
reaching a complete model.
In the RO layer of the model the Roles ‘developer’, ‘employee’ and ‘beta-tester’ are related to
AccessModes and abstract Objects by means of AccessPermissions. For instance, two permissions
named ‘permit file access’ connect the Roles ‘developer’ and ‘beta-tester’ to the Object ‘files’ and
to the AccessMode ‘access’. They express that developers and beta-testers can access files.
The SR layer represents the services that the system must provide, the resources they need,
the users who may take advantage of them, and the typical subjects that might act on the user’s
behalf. In our example, the users are grouped in ‘developer’, ‘office employee’ and ‘beta-tester’
folders, which are associated with the corresponding roles. Three SubjectTypes, ‘@main office’,
‘@branch office’ and ‘@home’ represent the three sorts of sessions that can be established by an
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
Table I. Comparison of the security configuration complexity of a few network scenarios.
No. of policies No. of network No. of DASs
Scenario at the RO level elements (PH/ES) elements
Previous study, simple network 5 95 19
Previous study, larger network, 5 540 32
similar policy complexity
Current case study, 15 264 49
medium-sized network,
complex policies
employee depending on his physical location. Moreover, for each AccessMode in the RO layer,
the SR layer holds implementing services (e.g. File Service, SQL Service, IS Service, Versioning
Service, WWW Proxy Service) and for each Object it holds implementing Resources (e.g. File
Store, Internal Message Store, Data Base, Repository).
The DAS layer defines the abstract network structure as depicted in Figure 21 by assigning
Actors, Mediators and Targets to the six subsystem areas.
The development of the Extended Subsystems follows the structure of the real network.
For instance, the ES ‘DMZ’ has objects that represent processes running on a web server, a mail
server, a DNS server, a (quad-homed) packet filter firewall and a VPN gateway. Each one of these
processes is connected through the adequate protocol stack—modelled by a series of interconnected
corresponding protocol objects—to their network interfaces.
Finally, the generation of the configuration files is performed by back-end functions which were
implemented for the corresponding mechanisms of the OpenBSD operating system—namely, the
packet filter pf and the VPN daemon isakmpd—covering the basic functions of these mechanisms.
In the case study the tool generated rules for the configuration of six pf packet filters (both for
firewall and VPN gateway processes) and sets of configuration files for each of the isakmpd daemons
used in the VPN gateways (including the IPSEC policy definition and its general configuration).
Another important view of the application of our approach is the complexity involved in the
security configuration process. For that we retrieved data from the examples used in a previous
study [7]and compared to equivalent data from the scenario just described, as can be seen in
Tabl e I .
The figures for the number of network elements give a hint about the work required from a
security administrator, since they reflect the number of different entities to be configured in some
way as regards security. Stated another way, the number of PH/ES elements follows the number of
real network devices. The number of policies, on the other hand, is directly related to the complexity
involved with security configuration. As can be derived from the figures above, our model provides
a significant complexity reduction for the security administration task, since the number of entities
to be dealt with are an order of magnitude more or smaller for these scenarios. For very large
networks, say thousands of network nodes, the advantages can be even more impressive, as the
number of different security scenarios tends to level out.
The approach has shown its practical relevance in a series of real applications and also in the
case study outlined in the previous section where the configuration of packet filters and VPN
gateways of a realistic network environment was developed. Although the simulated company has
a mid-sized network, it has security needs that are representative of the complex environments
of today’s large-scale enterprises, particularly the needs for security policies that structure users
into groups with different privileges—which may also vary depending on their current physical
access points—and the integrated design of the configurations of security services of different
types, which only in close cooperation are able to enforce the abstract global policies.
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
The development of the three-layered model can be performed not only in a top-down fashion
(as applied in the case study) but also in a bottom-up one: sometimes the existence of a network
element might be the evidence of the need for an additional policy not yet modelled. In practice,
however, a mixed procedure is often necessary since the network systems are not capable of
enforcing the given high-level policies. In such cases, the validation conditions described in Section
5.4 are not satisfied, and the tool indicates which policy elements cannot be enforced. Then, one
has to modify the network topology and/or to add further security services and/or to relax the
abstract policies.
The case study clearly shows the advantages of the DAS level based on information hiding and
modularization. Indeed, in Figure 21 each AS hides details about its inner features (i.e. network
topology, hosts, processes, protocols etc.), providing instead a policy-oriented view of them that
allows the administrator to reason about the distribution of policy participants over the system.
Moreover, the structuring of network objects into Actors, Mediators and Targets fulfils a general
user requirement detected by Yurcik et al. [27]while evaluating state-of-the-art security operation
tools: the profiling of distinguishable classes of computers on the network by their activity type.
Furthermore, drawing from this previous study [7]we showed that the size of a DAS grows
much slower than the number of elements in the ES level does, both when there is a simple increase
in the number of ES elements (similar policy complexity) and when there is a significant increase
in the policy complexity (plus a more than moderate increase in ES elements). This makes clear
the scalability gain afforded by DAS in the support of large and complex models.
In summary, our approach allows a significant improvement for the security administration in
large networks by tying systems involved in a particular security service and factoring numerous
instances out of similar functions. Notwithstanding the benefits the approach provides, network
environments of very large corporations with some hundreds of branch offices spread around the
world still impose challenges for the practical use of our approach. One of them involves the
graphical approach used by the tool, since even if a certain service can be adequately modelled,
maybe a 100 object instances of the service or of their agents might still have to be seen individually,
which no amount of zoom would be able to represent as a relevant view in a single screen. The
main limitation, however, concerns the manual development of the detailed IT system model,
which still demands considerable efforts. Future work shall provide for automated modelling of
the objects in the lowest model layer, based on network exploration through management protocols
(such as SNMP) as well as on the analysis of network traffic for automated discovery of typical
network connections. Thus, the modeller would only have to validate this auto-generated model
entities and to group them into subsystems, proceeding with the aforementioned steps. In such
very large environments, it would be also important to generalize the mechanism of hierarchical
decomposition developed in our approach so as to support the nesting of ASs, such that it would
be possible to have more specific subsystems (e.g. standing for different branch offices) inside
other more generic subsystems (e.g. standing for different countries or regions in the globe).
Moreover, a library of model templates shall be developed to support the efficient addition of
template instances into a model, thereby enabling the reuse of architectural patterns among different
Although many of the firewall commercial products include configuration tools, they do not seem
to have integrated security management as a primary concern. Nevertheless, a series of market
product tools in this direction is slowly appearing, for example, Checkpoint’s INSPECT visual
policy editor [28], Cisco’s Manager [29]and the product independent Solsoft NP Tool [30].
As for research work, there are some early approaches which draw on logic-based languages to
specify security policies. Guttman [31]uses prolog to define a security policy for packet filters as
a global policy about which packets can get where. Burns et al. [32]present a tool that, given a
security policy specified in a prolog-based language, automatically checks that the configuration
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
of a network with multiple firewalls adheres to the policy. Uribe and Cheung [33]build upon
previous works and extend them by including specifications and requirements for network intrusion
detection systems (NIDS), so as to allow the joint handling of packet filter rules and NIDSs. These
approaches offer advantages in scalability gains and detailed analysis capabilities, but the syntax
used is far from both the administrator’s view of the system and the business view of the problem,
requiring extra training for the correct policy specification.
The graphical tool Firmato [34]offers a more intuitive approach, since it supports an interactive
policy design by means of diagrams and automatically derives the corresponding configurations
for mechanisms. Al-Shaer and Hamed [35]developed a more comprehensive tool that relies upon
on a tree-based representation of the security policies in order to assist the user in both editing
new rules as well as in finding anomalies and inconsistencies in existing packet filter rules. There
are a number of recent works that are concerned with the problem of translating lower level
packet filter rules into logical rules in order to further analyse them for spotting conflicts and
inconsistencies, such as [36–42]. Although they bring important advances in the analysis of existing
security configuration, these and the other approaches above are mostly concerned with a relatively
low-level view of the management problem. These works proceed bottom-up, starting from the
mechanisms to be configured and achieving representation languages that are too bound up with
the mechanism types initially considered.
On the other hand, there are already some approaches that start from more convenient abstract
models that are able to address the management problem from a business point of view, as shown
below. The Power prototype [43]aims at supporting the building of policy hierarchies by means of
a tool-assisted policy refinement. The tool is then able to refine the high-level policy according to
templates and finally to produce the configuration information for particular devices. The template
specification is done in a prolog-like language, thus suffering from the same problems of the
aforementioned logic-based approaches. Cuppens et al. [44]also present a formal approach, which
is based on the Or-BAC model (an extension of the RBAC model) for specifying network security
policies. The Chameleos-x [45]is a more complete tool that supports the management of security
policies in heterogeneous environments, relying upon Authorization Specification Language (ASL).
This approach supports policy specification, automated translation into configuration files for
different mechanism types and real-time monitoring of policy enforcement. A drawback of the
latter approaches is that they do not offer support for explicit modelling of the network architecture,
making it hard for administrators to get a picture of what is actually allowed in the network by the
model and to reuse policies in different environments. Kropiwiec et al. [46]present a policy-based
framework that is capable of handling mandatory, discretionary and security property policies,
which can then be refined into packet filter rules. Their approach includes both a system model
(called information model) and a policy model that has been formalized using the Z-notation.
However, it is not clear how the system modelling is assisted nor whether the approach is scalable
to complex policies of large organizations.
In a wider context, Trastour et al. [47]propose an interesting approach to refine high-level
change requests into concrete plans for IT operators, so as to deal with the frequent change requests
of current complex IT infrastructures. Carey and Wade [48]present a set of tools for managing
adaptive web services offering support for the specification of supportable high level management
policies and the automated refinement of these high level policies into enforceable (low level)
policies. As for general policy management research, Damianou et al. [49]presented a set of tools
for the specification, deployment and management of policies, which were further developed in the
comprehensive Ponder2 environment [50]. This environment supports the definition of management
and security policies and is based on domains to group managed objects. A further work by
these authors offers an approach to the implementation and conflict analysis of Ponder policies
for the management of Quality of Service in Differentiated Services based on event calculus and
on the DMTF CIM to model network elements [51, 52]. CIM concentrates on the modelling of
management information (e.g. device’s capabilities and state) while our model represents the whole
relevant structure of the managed system together with the management components, producing a
graphical representation understandable to the security administrator.
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
We proposed a design approach for the configuration of network security systems that is especially
concerned with complex environments. The proposed modelling technique achieves scalability by
the segmentation of the system model into ASs, enabling the process of model development and
analysis to be performed in a modular fashion. The tool support offered allows editing of the
model in a comfortable way and provides an automated policy refinement. It derives lower level
policies from the abstract policy set defined by the modeller, eventually yielding the configuration
parameter settings for the security services. The method was applied to the security management
of a complex network environment and the actual benefits the approach yields were demonstrated
with representative network security scenarios.
These results are complemented by a scalable validation approach for the policy refinement
process that was briefly described in Section 5.4 and presented in detail in [8–10]. The validation
includes a formalism of the model, the establishment of consistency conditions and the proof of the
refinement process correctness. Furthermore, the tool prototype also implements focus & context
techniques, substantially improving the navigation and visualization of large models. This topic
was further elaborated in [11], which shows how these techniques were associated to the modelling
framework developed here to improve the navigation and visualization of large system models.
As for future work, the scope of the high-level policies proposed here could be broadened
to include other requirements, such as reliability and performance. This can be accomplished
by adding features of RBAC extensions such as the UCONABC usage control model [53]and
Generalized-RBAC (GRBAC) [54]. An example of this research direction in another context is
given by the SIRENA project [55, 56].
Porto de Albuquerque was supported by a scholarship from CAPES and his stay in Dortmund was
supported by CAPES and DAAD. De Geus was supported by FAPESP during his stay at UCSB. We
thank Richard Kemmerer for his helpful comments and suggestions with an earlier draft of this text. Also,
a thankful acknowledgement is due to the anonymous reviewers for their helpful comments.
1. Oppenheimer D, Ganapathi A, Patterson D. Why do internet services fail, and what can be done about it. Fourth
USENIX Symposium on Internet Technologies and Systems (USITS’03), Seattle, WA, U.S.A., 2003; 1–16.
2. Sloman M. Policy driven management for distributed systems. Journal of Network and Systems Management
1994; 2(4):333–360.
3. Moffett JD, Sloman MS. Policy hierarchies for distributed system management. IEEE JSAC Special Issue on
Network Management 1993; 11(9):1404–1414.
4. L¨
uck I, V¨
ogel S, Krumm H. Model-based configuration of VPNs. Proceeding of the Eighth IEEE/IFIP Network
Operations and Management Symposium NOMS 2002, Stadtler R, Ulema M (eds.) IEEE: Florence, Italy, 2002;
5. L¨
afer C, Krumm H. Model-based tool-assistance for packet-filter design. Proceeding of the IEEE
Workshop Policy 2001:Policies for Distributed Systems and Networks, Sloman M, Lobo ELJ (eds.) (Lecture
Notes in Computer Science, vol. 1995), Springer: Heidelberg, 2001; 120–136.
6. L¨
uck I, Sch¨
onbach M, Mester A, Krumm H. Derivation of backup service management applications from service
and system models. Active Technologies for Network and Service Management,Proceedings of DSOM’99,
Stadler RBS (ed.) (Lecture Notes in Computer Science, vol. 1700). Springer: Heidelberg, 1999; 243–255.
7. de Albuquerque JP, Krumm H, de Geus PL. On scalability and modularisation in the modelling of security
systems. 10th European Symposium on Research in Computer Security—ESORICS 2005,diVimercatiSDC,
Syverson PF, Gollmann D (eds.) (Lecture Notes in Computer Science, vol. 3679). Springer: Berlin, Heidelberg,
Germany, 2005; 287–304.
8. de Albuquerque JP, Krumm H, de Geus PL. Policy modeling and refinement for network security systems. Sixth
IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY 2005). IEEE Computer
Society: Washington, DC, U.S.A., 2005; 24–33. DOI:
9. de Albuquerque JP, Krumm H, de Geus PL. Formal validation of automated policy refinement in the management
of network security systems. International Journal of Information Security 2010; 9(2):99–125.
10. de Albuquerque JP. Model-based configuration management of security systems in complex network environments.
Ph.D Thesis, Institute of Computing, University of Campinas, Campinas, SP, Brazil, 2006.
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
11. de Albuquerque JP, Isenberg H, Krumm H, de Geus PL. Improving the configuration management of large
network security systems. Ambient Networks:16th IFIP/IEEE International Workshop on Distributed Systems:
Operations and Management,DSOM 2005,Sch
alder J, Serrat J (eds.) (Lecture Notes in Computer Science,
vol. 3775). Springer: Berlin, Heidelberg, Germany, 2005; 36–47.
12. Schuba CL, Krsul IV, Kuhn MG, Spafford EH, Sundaram A, Zamboni D. Analysis of a denial of service attack
on TCP. 1997 IEEE Symposium on Security and Privacy. IEEE Computer Society: Los Alamitos, CA, U.S.A.,
1997; 0208.
13. Mirkovic J, Reiher P. A taxonomy of DDoS attack and DDoS defense mechanisms. ACM SIGCOMM Computer
Comunications Review 2004; 34:39–53.
14. Wies R. Policies in network and systems management—Formal definition and architecture. Journal of Network
and Systems Management 1994; 2(1):63–83.
15. L¨
uck I. Model-based security service configuration. Ph.D Thesis, University of Dortmund, Germany 2007 (in
16. Sandhu RS, Coyne EJ, Feinstein HL, Youman CE. Role-based access control models. IEEE Computer 1996;
17. Ferraiolo DF, Barkley JF, Kuhn DR. A role-based access control model and reference implementation within a
corporate intranet. ACM Transactions on Information and System Security 1999; 2(1):34– 64.
18. Geist G. Model-based management of security services: Integrated enforcement of policies in company networks.
Master’s Thesis, University of Dortmund, Germany 2003 (in German).
19. Parnas DL. On the criteria to be used in decomposing systems into modules. Communications of the ACM 1972;
15(12):1053–1058. DOI:
20. Musial B, Jacobs T. Application of focus +context to UML. Australian Symposium on Information Visualisation,
(’03), Conferences in Research and Practice in Information Technology, Pattison T, Thomas B (eds.),
vol. 24. ACS: Adelaide, Australia, 2003; 75–80.
21. K¨
oth O, Minas M. Structure, abstraction, and direct manipulation in diagram editors. Diagrammatic Representation
and Inference,Second International Conference (Diagrams 2002), Hegarty M, Meyer B, Narayanan NH (eds.)
(Lecture Notes in Computer Science, vol. 2317). Springer: Callaway Gardens, GA, U.S.A., 2002.
22. Furnas GW. Generalized fisheye views. Proceedings of ACM CHI’86 Conference on Human Factors in Computing
Systems, Boston, MA, U.S.A., Visualizing Complex Information Spaces, 1986; 16–23.
23. Sarkar M, Brown MH. Graphical fisheye views of graphs. Proceedings of ACM CHI’92 Conference on Human
Factors in Computing Systems, Monterey, CA, U.S.A., Visualizing Objects, Graphs, and Video, 1992; 83–91.
24. Abrams M, Bailey D. Abstraction and refinement of layered security policy. Information Security:An Integrated
Collection of Essays, Abrams M, Jajodia S, Podell H (eds.) IEEE Computer Society Press: Los Alamitos, CA,
U.S.A., 1994; 126–136.
25. Sloman M, Lupu EC. Security and management policy specification. IEEE Network,Special Issue on Policy-Based
Networking 2002; 16(2):10–19.
26. Pressman RS. Software Engineering:A Practitioner’s Approach (5th edn). McGraw-Hill: New York, 2001.
27. Yurcik W, Barlow J, Lakkaraju K, Haberman M. Two visual computer network security monitoring tools
incorporating operator interface requirements. ACM CHI Workshop on Human-Computer Interaction and Security
Systems (HCISEC), Fort Lauderdale, FL, U.S.A., 2003.
28. Check Point Software Technologies Ltd., Redwood City, CA. Check Point Software Revolutionizes Internet Security
Management, January 2000. Checkpoint Press Release. Available at:
vpe012400.html [1 December 2006].
29. Hinrichs S. Policy-based management: Bridging the gap. Proceedings of the 15th Annual Computer Security
Applications Conference, Phoenix, AZ, U.S.A., 1999.
30. Enterprise Management Associates. Solsoft NP: Putting security policies into practice. White Paper 2000. Available
at: profiler.pdf [13 September 2010].
31. Guttman JD. Filtering postures: Local enforcement for global policies. SP ’97:Proceedings of the 1997 IEEE
Symposium on Security and Privacy. IEEE Computer Society: Washington, DC, U.S.A., 1997; 120.
32. Burns J, Cheng A, Gurung P, Rajagopalan S, Rao P, Rosenbluth D, Surendran D, Martin DM Jr. Automatic
management of network security policy. DARPA Information Survivability Conference and Exposition (DISCEX
II’01), Anaheim, CA, U.S.A., vol. 2, 2001.
33. Uribe TE, Cheung S. Automatic analysis of firewall and network intrusion detection system configurations.
Journal of Computer Security 2007; 15(6):691–715.
34. Bartal Y, Mayer AJ, Nissim K, Wool A. Firmato: A novel firewall management toolkit. ACM Transactions on
Computer Systems 2004; 22(4):381–420.
35. Al-Shaer E, Hamed H. Modeling and management of firewall policies. IEEE Transactions on Network and
Service Management 2004; 1(1):2–10.
36. Wool A. Architecting the lumeta firewall analyzer. 10th USENIX Security Symposium. USENIX: Washington
D.C., 2001; 85–97.
37. Yuan L, Mai J, Su Z, Chen H, Chuah CN, Mohapatra P. FIREMAN: A toolkit for FIREwall Modeling
and ANalysis. IEEE Symposium on Security and Privacy 2006; 199–213. DOI:
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
38. Thanasegaran S, Yin Y, Tateiwa Y, Katayama Y, Takahashi N. A topological approach to detect conflicts
in firewall policies. IEEE International Parallel and Distributed Processing Symposium 2009; 1–7. DOI:
39. Horowitz E, Lamb LC. A hierarchical model for firewall policy extraction. International Conference
on Advanced Information Networking and Applications 2009; 691–698. DOI:
40. Capretta V, Stepien B, Felty A, Matwin S. Formal correctness of conflict detection for firewalls. FMSE ’07:
Proceedings of the 2007 ACM Workshop on Formal Methods in Security Engineering.ACM:NewYork,NY,
U.S.A., 2007; 22–30. DOI:
41. Abbes T, Bouhoula A, Rusinowitch M. An inference system for detecting firewall filtering rules anomalies. SAC
’08:Proceedings of the 2008 ACM Symposium on Applied Computing. ACM: New York, NY, U.S.A., 2008;
2122–2128. DOI:
42. Jeffrey A, Samak T. Model checking firewall policy configurations. IEEE International Workshop on Policies
for Distributed Systems and Networks 2009; 60–67. DOI:
43. Mont M, Baldwin A, Goh C. POWER prototype: Towards integrated policy-based management. Proceedings of
the IEEE/IFIP Network Operations and Management Symposium (NOMS2000), Hong J, Weihmayer R (eds.),
Hawaii, U.S.A., 2000; 789–802.
44. Cuppens F, Cuppens-Boulahia N, Sans T, Mi ´
ege A. A formal approach to specify and deploy a network security
policy. Formal Aspects in Security and Trust (FAST 2004), Toulouse, France, 2004.
45. Teo L, Ahn GJ. Towards effective security policy management for heterogeneous network environments.
IEEE International Workshop on Policies for Distributed Systems and Networks 2007; 241–245. DOI:
46. Kropiwiec CD, Jamhour E, Penna MC, Pujolle G. Multi-constraint security policies for delegated firewall
administration. DSOM ’08:Proceedings of the 19th IFIP/IEEE International Workshop on Distributed Systems:
Operations and Management. Springer: Berlin, Heidelberg, 2008; 123–135. DOI:
3-540-87353-2 10.
47. Trastour D, Fink R, Liu F. Changerefinery: Assisted refinement of high-level IT change requests.
IEEE International Workshop on Policies for Distributed Systems and Networks 2009; 68–75. DOI:
48. Carey K, Wade V. Using automated policy refinement to manage adaptive composite services. IEEE Network
Operations and Management Symposium Workshops, Salvador, Brazil, 2008; 239–247.
49. Damianou N, Dulay N, Lupu E, Sloman M, Tonouchi T. Tools for domain-based policy management of distributed
systems. IEEE/IFIP Network Operations and Management Symposium (NOMS2002), Florence, Italy, 2002;
50. Twidle K, Lupu E, Dulay N, Sloman M. Ponder2—A policy environment for autonomous pervasive systems.
IEEE International Workshop on Policies for Distributed Systems and Networks, Palisades, NY, U.S.A., 2008;
51. Lymberopoulos L, Lupu E, Sloman M. Ponder policy implementation and validation in a CIM and differentiated
services framework. IFIP/IEEE Network Operations and Management Symposium (NOMS 2004), Seoul, Korea,
52. Charalambides M, Flegkas P, Pavlou G, Rubio-Loyola J, Bandara AK, Lupu EC, Russo A, Dulay N, Sloman M.
Policy conflict analysis for diffserv quality of service management. IEEE Transactions on Network and Service
Management 2009; 6(1):15–30.
53. Park J, Sandhu R. The UCONABC usage control model. ACM Transactions on Information and System Security
2004; 7(1):128–174. DOI:
54. Covington MJ, Moyer MJ, Ahamad M. Generalized role-based access control for securing future applications.
23rd National Information Systems Security Conference Proceedings, 2000.
55. Illner S, Pohl A, Krumm H. Security service adaptation for embedded service systems in changing environments.
Proceedings of the Second IEEE International Conference on Industrial Informatics (INDIN’04), Berlin, Germany,
2004; 457–462.
56. Illner S, Krumm H, L¨
uck I, Pohl A, Bobek A, Bohn H, Golatowski F. Model-based management of embedded
service systems—An applied approach. Proceedings of the 20th International IEEE Conference on Advanced
Information Networking and Applications (AINA2006), vol. 2. IEEE Computer Society Press: Vienna, 2006;
Copyright q2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:307–338
DOI: 10.1002/spe
Hierarchical management is a typical approach to managing complex information networks (CINs). In hierarchical management, as the only avenue to control information storage, transmission and usage, instruction interaction is often exploited by attackers to threaten CINs security. Now it has become a major challenge to ensure the security of instruction interaction. To address this challenge, in this paper, we propose a security model to manage instruction interaction for the hierarchical management in CINs. First, considering instruction lifecycle, we design five basic instruction operations (i.e., instruction generation, distribution, decomposition, execution, and execution outcome feedback) and formally define their semantics. Then a series of security rules for the basic operations are proposed to monitor and control the instruction interactions. We prove that, through these rules, both controllability and confidentiality can be provided. Finally, case studies demonstrate the feasibility of the proposed model.
The existing methods of policy refinement in computer network defense (CND) can only support the refinement of access control policy, but not the policies of protection, detection, response, and recovery. To solve this problem, we constructed a computer network defense policy refinement model and its formalism specification. An algorithm of defense policy refinement is designed. At last, the effectiveness of our methods was verified through one experiment cases of the composition policies with intrusion detection, vulnerabilities detection, and access control.
Service Providers using Service Oriented Architecture in order to deliver in-house services as well as on-demand and cloud services have to deal with two interdependent challenges: (1) to achieve, maintain and prove compliance with security requirements stemming from internal needs, 3rd party demands and international regulations and (2) to manage requirements, policies and security configuration in a cost-efficient manner. The deficiencies of current processes and tools force these service providers to trade off profitability against security and compliance. This paper summarizes a novel approach of a policy chain, which links high-level, abstract and declarative security policies on one side and low-level, imperative, and technical security configuration settings on the other side. The paper describes an architecture linking several applications and models via state-machines in order to provide a toolset supporting service providers to build such a holistic policy chain at design time, and to maintain and leverage it during system operation.
Full-text available
Introduction From e-commerce to ubiquitous computing, service composition is seen as a key technique in rapidly generating new, tailored functionality from existing service implementations. However, within a specific composite service deployment there may still be the opportunity for further run-time adaptation of the composite service's behaviour based on run-time adaptively built into the software components that implement. This may, for instance, cover non-functional behaviour such as quality of service. In this paper it is assumed that a implementer of service components provide runtime adaptively of service via policy rules that can be triggered by runtime events and which, given certain specified condition are satisfied, will cause specified actions to be taken by the component. Policy rules are declarative and can be loaded into a component at deployment or runtime. However, rules for specific service components will use terminology native to that service and so coordinating the aggregate adaptive behaviour of a composite service though manipulating the heterogeneous policy rules of the components implementing its constituent service is potentially complex. This paper describes an approach to automatically managing constituent service policy-rules of a composite service based. This management allows an administrator or a user to assign a goal, in the form of a high-level policy with event, condition and action, for the composite service and ensures that this goal is propagated to the constituent services by refining this goal into policies which are executed upon the service implementation. The approach taken exposes a service implementation's management controls as a finite state machine (FSM). Background This section described some of the technologies and techniques underlying our approach. Web Services and Composite Services Web services are self-contained, self-describing, modular applications that can be published, located, and invoked across the web. Web services perform functions, which can be anything from simple requests to complicated business processes [20]. Software functionality can be modelled as a well-defined service, which is the means by which their functionality is composed to define more complex services. Such a composition of services provides the well-defined context required for addressing adaptive behaviour, especially of non-functional behaviour such as quality of service, in complex, multi-organizational environments.
Firewalls and network intrusion detection systems (NIDSs) are widely used to secure computer networks. Given a network that deploys multiple firewalls and NIDSs, ensuring that these security components are correctly configured is a challenging problem. Although models have been developed to reason independently about the effectiveness of firewalls and NIDSs, there is no common framework to analyze their interaction. This paper presents an integrated, constraint-based approach for modeling and reasoning about these configurations. Our approach considers the dependencies among the two types of components, and can reason automatically about their combined behavior. We have developed a tool for the specification and verification of networks that include multiple firewalls and NIDSs, based on this approach. This tool can also be used to automatically generate NIDS configurations that are optimal relative to a given cost function.
There are multiple views of corporate (enterprise) computing, each with its own metaphors and terms of reference. The differ-ent views incorporate different levels of abstraction, in which de-tails are suppressed to concentrate attention on the issues important to the particular observer. This essay examines these different metaphors with respect to the enterprise security policy resulting in a layered policy where each main layer relates to one of the system metaphors and the policy described for a lower level of detail is an implementation of the policy at a higher level. The layered view of policy helps system designers, managers, and users understand the rationale for security policy at the lowest levels of abstraction, because the relationship of the low level policy to the enterprise information policy is clear.
In this paper, we introduce the family of UCONABC models for usage control (UCON), which integrate Authorizations (A), oBligations (B), and Conditions (C). We call these core models because they address the essence of UCON, leaving administration, delegation, and other important but second-order issues for later work. The term usage control is a generalization of access control to cover authorizations, obligations, conditions, continuity (ongoing controls), and mutability. Traditionally, access control has dealt only with authorization decisions on users' access to target resources. Obligations are requirements that have to be fulfilled by obligation subjects for allowing access. Conditions are subject and object independent environmental or system requirements that have to be satisfied for access. In today's highly dynamic, distributed environment, obligations and conditions are also crucial decision factors for richer and finer controls on usage of digital resources. Although they have been discussed occasionally in recent literature, most authors have been motivated from specific target problems and thereby limited in their approaches. The UCONABC model integrates these diverse concepts in a unified framework. Traditional authorization decisions are generally made at the time of requests but hardly recognize ongoing controls for relatively long-lived access or for immediate revocation. Moreover, mutability issues that deal with updates on related subject or object attributes as a consequence of access have not been systematically studied.Unlike other studies that have targeted on specific problems or issues, the UCONABC model seeks to enrich and refine the access control discipline in its definition and scope. UCONABC covers traditional access controls such as mandatory, discretionary, and role-based access control. Digital rights management and other modern access controls are also covered. UCONABC lays the foundation for next generation access controls that are required for today's real-world information and systems security. This paper articulates the core of this new area of UCON and develops several detailed models.
Security concerns are becoming increasingly critical in networked systems. Firewalls provide important defense for network security. However, misconfigurations in firewalls are very common and significantly weaken the desired security. This paper introduces FIREMAN, a static analysis toolkit for firewall modeling and analysis. By treating firewall configurations as specialized programs, FIREMAN applies static analysis techniques to check misconfigurations, such as policy violations, inconsistencies, and inefficiencies, in individual firewalls as well as among distributed firewalls. FIREMAN performs symbolic model checking of the firewall configurations for all possible IP packets and along all possible data paths. It is both sound and complete because of the finite state nature of firewall configurations. FIREMAN is implemented by modeling firewall rules using binary decision diagrams (BDDs), which have been used successfully in hardware verification and model checking. We have experimented with FIREMAN and used it to uncover several real misconfigurations in enterprise networks, some of which have been subsequently confirmed and corrected by the administrators of these networks.
Conference Paper
In many contexts, humans often represent their own “neighborhood” in great detail, yet only major landmarks further away. This suggests that such views (“fisheye views”) might be useful for the computer display of large information structures like programs, data bases, online text, etc. This paper explores fisheye views presenting, in turn, naturalistic studies, a general formalism, a specific instantiation, a resulting computer program, example displays and an evaluation