Network Access Control Interoperation using

Semantic Web Techniques

William Fitzgerald

1,2

, Simon Foley

and M´ıche´al

O. Foghl´u

Department of Computer Science, University College Cork, Ireland

Telecommunications Software & Systems Group, Waterford Institute of Technology, Ireland

Abstract. Network Access Control requirements are typically implemented in

practice as a series of heterogeneous security-mechanism-centric policies that

span system services and application domains. For example, a Network Access

Control (NAC) policy might be conﬁgured in terms of ﬁrewall, proxy, intrusion

prevention and user-access policies. While deﬁned separately, these policies may

interoperate in the sense that the access requirements of one may conﬂict and/or

be redundant with respect to the access requirements of another policy. Thus,

managing a large number of distinct policies becomes a major challenge in terms

of deploying and maintaining a meaningful and consistent conﬁguration. It is

argued that the Semantic Web—an architecture that supports the formal repre-

sentation, reasoning and sharing of heterogeneous domain knowledge—provides

a natural solution to this challenge. A risk-based approach to conﬁguring inter-

operating policies is described. Each NAC mechanism has an ontology that is

used to represent its conﬁguration. This heterogeneous and interoperating pol-

icy knowledge is uniﬁed with higher-level business (risk) rules, providing a sin-

gle (extensible) ontology that supports reasoning across the different NAC policy

conﬁgurations.

1 Introduction

While application-level services may provide their own access controls, it is standard

practice to deploy additional ‘layers’ of security, such as ﬁrewalls, proxies, and so forth.

In practice, security requirements are implemented as a series of independent security-

mechanism-centric policies that span multiple system services and application domains.

As a consequence, proper application operation is dependent on each security policy.

An overly-restrictive policy conﬁguration may prevent normal interaction of services

with the resulting failure of the application. An overly-permissive policy conﬁguration,

while permitting normal operation of the application, may render the layers of security

ineffective; a service hosted on a subnet is at greater risk of compromise if the ﬁrewall

is conﬁgured with an open-access policy.

In this paper we are interested in Network Access Control (NAC) policies. Con-

ﬁguration of NAC policies can be complex, for example, a ﬁrewall policy may run to

many thousands of rules and are typically maintained on an ad-hoc basis [1,2]. New

Fitzgerald W., Foley S. and Ó . Foghlú M. (2008).

Network Access Control Interoperation using Semantic Web Techniques.

In Proceedings of the 6th International Workshop on Security in Information Systems, pages 26-37

DOI: 10.5220/0001743300260037

 SciTePress

access control rules are often added to access control policies with little regard to how

they interoperate with existing rules and likely resulting in an overly-restrictive and/or

overly-permissive conﬁguration. Similarly, changes to the policy of one NAC mecha-

nism (for example, a ﬁrewall) may indirectly impact the intent of a policy of another

NACmechanism (for example, a proxy). The ideal NAC conﬁguration provides for con-

sistent interoperating NAC policies that support valid service trafﬁc, and, preferably, no

more and no less.

The vision of the Semantic Web is the ability to express World Wide Web informa-

tion in a natural and formal language that can be interpreted by intelligent agents, thus

permitting them on behalf of the human user to locate, share and integrate information

in an automated way. It provides a framework for dynamic, distributed and extensible

structured knowledge (ontology) founded on formal logic [3, 4]. An ontology is an ex-

plicit speciﬁcation of a conceptualization using an agreed vocabulary and provides a

rich set of constructs to build a more meaningful level of knowledge. Ontologies and

their associated reasoners are the building blocks of the Semantic Web initiative.

We argue that the Semantic Web framework provides a natural approach to con-

structing, reasoning about and managing security policies: a security policy can be

regarded as an explicit speciﬁcation of terminological knowledge regarding security

mechanism conﬁguration, that is, an ontology. Separate ontologies can be developed

for different security policies that are naturally composable under the open-world as-

sumption, providing a uniﬁed view of the enterprise-wide policy conﬁguration. It pro-

vides for separation of concerns, whereby security concerns (security policies) and

business concerns (business policies) can be separately developed, with reasoning and

deployment over their composition. It also means that information about new mecha-

nisms/policies and vulnerabilities can be incorporated as new facts within the existing

policy knowledge-base.

This paper describes a risk-based model for NAC policy interoperation. A series

of ontologies are developed using Description Logic that describe network host-based

access-control knowledge at the application-layer and at the systems-layer. Ontologies

are described for the Netﬁlter/iptables ﬁrewall [2],TCP-Wrapper [5] and an application-

level access policy that reﬂects high-level business goals.

The contribution of this paper is a NAC policy model ontology, over which, intra-

policy and inter-policy interoperation can be reasoned about. At the individual policy

level, one can reason about conﬂicts within a policy conﬁguration; for example, ﬁrewall

consistency checking can be performed over the Netﬁlter ontology. One can also reason

across different policies; by combining the ﬁrewall ontology with the application-level

risk access ontology, one can reason about service reachability and access permissive-

ness. The resulting model also demonstrates the practical effectiveness of using Seman-

tic Web techniques in constructing, reasoning about and managing security policies.

The paper is organized as follows. Section 2 introduces Description Logic (DL)

[6]. Section 3 outlines the policy architecture. Individual ontologies for Netﬁlter, TCP-

Wrapper proxy and an application-level access policy are described in Section 4. Sec-

tion 5 deﬁnes a model that is used to represent conﬁguration of a network of systems,

services, proxies, and so forth. This model provides the basis for conﬁguration reason-

ing, which is considered in Section 6.

2 Description Logic & Ontologies

Description Logic (DL) is a family of logic-based formalisms that are well-suited for

the representation of and reasoning about terminological (T-box) and assertional (A-

box) knowledge based on the Open World Assumption (OWA) [6,7]. DL represents a

decidable portion of ﬁrst-order logic and forms part of the W3C recommendation for

the Semantic Web [4,8].

DL uses classes (concepts) to represent sets of individuals (instances) and proper-

ties (roles) to represent binary relations applied to individuals. For example, the DL

assertion:

Server ⊑N ode ⊓

∃hasHost.BusinessService ⊓ ∃hasP rotection.P rotectionService

speciﬁes that a server node (class) hosts business services (class) and has (property)

a protection service (class) protecting them. Note that properties are conventionally

preﬁxed by “has”; for instance, hasHost, is the property over the individuals of the

class Server (domain) that hosts a business service BusinessService (range).

The Semantic Web Rule Language, (SWRL), complements DL providing the ability

to infer additional information in DL ontologies, but at the expense of decidability.

SWRL rules are Horn-clause like rules written in terms of DL concepts, properties and

individuals. A SWRL rule is composed of an antecedent (body) part and a consequent

(head) part, both of which consist of positive conjunctions of atoms [9]. For example,

the requirement: servers hosting ssh based business services protected by a ﬁrewall

require that ﬁrewall to open port 22 is expressed in SWRL as:

Server(?n) ∧ hasHost(?n, s) ∧ hasP ort(?s, ssh) ∧ hasF irewall(?n, ?f )

→ hasP ortOpen(?f, ssh)

3 Security Policy Model

It is considered best practice to secure business critical applications (regardless of their

own ability to secure themselves at a service level) using a layered approach, in par-

ticular, by employing low-level infrastructure access control (ﬁrewalls, intrusion pre-

vention and so forth). Figure 1 provides an abstract policy architecture whereby the

elements represent DL classes that are deﬁned in later sections and arcs represent re-

lationships between the classes. The architecture provides for three security policies:

Netﬁlter, TCP-Wrapper and a business-risk policy. The Netﬁlter and TCP-Wrapper

policies are explicitly enforced by their underlying mechanisms. Section 6 considers

how the overall conﬁguration is reasoned over to determine whether the business-risk

policy is upheld.

A network is a collection of systems Nodes that may host Business Services.

A service Risk policy deﬁnes the risk of allowing particular clients (Client Range)

having access to the service. For example, a particular range of IP addresses may be

considered high-risk to a mail server due to a large volume of spam messages, while

IP addresses with a service agreement are considered low-risk. Each node is deployed

Fig.1. Ontology Policy Architecture.

with zero or more Protection Service(s) that provide access control mechanisms such

as Firewall(s) and Proxy(s). These protection services are conﬁgured in terms of a set

of Protection Rule(s) that deﬁne its Protection Policy. A protection rule, amongst

other components, is deﬁned in terms of a range of IP addresses (Client Range) that

may be permitted access.

4 Security Policy Ontology

In this section, we develop DL ontologies for the model components described in the

previous section. Note that due to space reasons, we provide only fragments of the DL

model. Complete DL deﬁnitions, for example; disjoint axioms, data type properties or

closure axioms are typically not included. The complete DL model has been coded in

the W3C Semantic Web languages (OWL-DL and SWRL) using the Prot´eg´e IDE [10].

4.1 System Ontology

Class N ode represents the set of system nodes. Nodes host business and protection

services and are connected to each other (hasConnectionT o) to form a network.

Node ⊑ ∃ hasConnectionT o.Node ⊓ ∀hasP rotection.P rotectionService ⊓

∀hasHost.BusinessService ⊓ . . .

For example, a N ode instance node2 hosting business service bs1 that is connected

to a gateway node, (node1) and is also protected by various access control service

mechanisms namely a gateway ﬁrewall (fw1), a local ﬁrewall (fw2) and a local proxy

(proxy2) is illustrated in the following expression. Note, atomic individuals are writ-

ten in a typewriter font, while inferred individuals are given in an italic font.

Node(node2) ←hasConnectionT o.(node2, node1) ⊓ hasHost.(node2, bs1)⊓

hasP rotection.(node2, (fw1,fw2,proxy2))

The BusinessService class represents the set of business services deployed to nodes

within the network.

BusinessService ⊑ Service ⊓ ∃hasDeployedT o.Node ⊓ . . .

The class of services, Service is a business service or a protection service.

P rotectionService, BusinessService ⊑ Service

Access control based services (for example, TCP-Wrapper, Netﬁlter) are subclasses of

P rotectionService, where membership of these classes requires protection of at least

one node.

P roxyService, F irewallService ⊑ P rotectionService ⊓ ∃isP rotectionOf.N ode

4.2 Risk Policy Ontology

Security Conﬁdence. Every node has a security conﬁdence; (high, mediumand low),

that indicates the degree to which the services that it hosts are protected.

Node ⊑ ∃

hasAssurance.SecurityConf idence

Thus a N ode individual must also have a hasAssurance relationship to an individ-

ual of SecurityConf idence. This value could be based on an assessment of secu-

rity of the node itself (for example, Unix or Security Enhanced Linux), the subnet

it resides in, and/or the protection services that it hosts. Incorporating the property

hasAssurance.(node2, high) into the same individual node2 described earlier in-

dicates that the high security assurance reﬂects that node2 has multiple and combined

protection by various access control mechanisms namely a gateway ﬁrewall (fw1), a

local ﬁrewall (fw2) and a local proxy (proxy2).

Each business service has a minimum security conﬁdence requirement for any node

on which it is hosted and is deﬁned in the business service deﬁnition as:

BusinessService ⊑ ∃

hasAssurReq.SecurityConfidence

Risk Metric. Each business service has associated risks (hasRisk) of permitting clients

(IP address) access to the service. Ideally the sum of the associated risks should not be

greater than the maximum acceptatble risk threshold (hasRiskT hreshold).

BusinessService ⊑ ∃hasRisk.RiskP olicy ⊓ ∃

hasRiskT hreshold.F loat ⊓ ....

While a service will have clients with which it has service agreements (risk value of

zero), there can be scenarios where it is expedient to tolerate potential service access

from other client/sources hasRisk.RiskP olicy, (notwithstanding the service’s inter-

nal access controls). For example, it might be considered low to moderate-risk for a

mail service to accept packets from addresses that are believed to be spam sources,

while accepting packets from addresses that have been blacklisted as botnet sources is

considered high risk. The service risk threshold reﬂects an business/security trade-off

decision. Section 6.1 considers how a conﬁguration is tested against this measure.

RiskP olicy ⊑∃hasRiskIP StartRange.Integer ⊓ ∃hasRiskIP EndRange.Integer ⊓

∃hasRiskV alue.F loat ⊓ ...

4.3 Netﬁlter Firewall Ontology

Netﬁlter is a framework that enables packet ﬁltering, network address translation (NAT)

and packet mangling. As a ﬁrewall, it is both a stateful and stateless packet ﬁlter that

is characterised by a sequence of ﬁrewall decisions against which all packets traversing

the ﬁrewall are ﬁltered. Each ﬁrewall decision takes the form of a series of conditions

representing packet attributes that must be met in order for that decision to be applica-

ble, with a consequent action for the matching packet (accept, drop, log and so forth).

An in-depth description for the Linux Netﬁlter ontology is given in [11].

Netﬁlter requires the speciﬁcation of a table (filter, NAT or mangle), a chain,

the accompanying decision condition details and an associated target outcome. A table

is a set of chains and it deﬁnes the global context, while chains deﬁne the local context

within a table. Our research focuses on the ﬁrewalling aspects of Netﬁlter and hence

our current model only incorporates the filter table attributes. A chain is a set of

ﬁrewall decisions and those decisions in a chain are applied to the context deﬁned both

by the chain itself and the particular table. A Netﬁlter ﬁrewall decision is composed of

exactly one chain, one or more condition ﬁlters and a single permission target. This is

expressed as the DL assertion:

NamedF irewallP olicy ≡ NetfilterF irewall ⊓ ∃

hasChain.Chain ⊓

∃

≥1

hasCondition.F ilter ⊓ ∃

hasT arget.T arget

The Netﬁlter/iptables decision that accepts incoming ssh requests from a trusted client

IP address 4.3.2.1 to a protected server (1.2.3.4) is written as:

iptables -t filter -A INPUT -s 4.3.2.1 -d 1.2.3.4

-p tcp --dport 22 -j ACCEPT

This decision is represented in our ontology by an individual id such that,

NamedF irewallP olicy(id) ←hasChain(id, inputChain)⊓

hasSrcIP (id, ip4.3.2.1)⊓

hasDstIP (id, ip1.2.3.4)⊓

hasP rotocol(id, tcp) ⊓ hasDstP ort(id, portSSH)⊓

hasT arget(id, acceptTarget)

Note that the low-level facts of a ﬁrewall conﬁguration are presented as individuals

rather than classes on the basis that they are atomic and will not be further decomposed.

Using instances (rather than subclasses) allows subsequent reasoning of collections of

ﬁrewall decisions using SWRL, as outlined in [11].

4.4 TCP-Wrapper Proxy Ontology

The Linux/Unix-based TCP-Wrapper service is a host-based transport layer proxy that

provisions network access control to local daemons spawned by the Internet services

daemon (inetd). Under typical circumstances Linux environments use a super server

(inetd) to invoke TCP/IP based network services, for example the ssh service. Instead

of invoking the ssh daemon directly the inetd daemon will invoke the TCP-Wrapper

daemon. The TCP-Wrapper proxy will permit or deny access to the requested service

daemons it protects based on the requesting client (for e.g. an IP address) as ascertained

from the inetd network connection. If a decision has concluded with a permit action

then the TCP-Wrapper proxy shall invoke the appropriate service daemon.

A TCP-Wrapper policy—a set access control rules to protect host-based services—

is speciﬁed in terms of access control ﬁles hosts.allow and hosts.deny. Recent versions

allow the access-controls to be speciﬁed in a single ﬁle. Like ﬁrewall decisions, the

orderingof decisions is vital, thus once a decision has been matched no further decisions

are processed. A TCP-Wrapper decision at its simplest level can be described as having

the following components; one or more service daemons, one or more requesting client

and a exactly one permission target and is represented by the following DL assertion:

NamedT CP DP olicy ≡ T CP W rapperDomain ⊓ ∃

≥1

hasDaemon.DaemonF ilter ⊓

∃

≥1

hasT CP DClient.ClientF ilter ⊓ ∃

hasAction.Action

A TCP-Wrapper decision twd, (an individual of NamedT CP DP olicy) that states a

trusted client IP address is permitted access to the protected ssh daemon is represented

by the following:

NamedT CP DP olicy(twd) ←hasDaemon.(twd, sshD)⊓

hasT CP DClient(twd, ip4.3.2.1) ⊓ hasAction(twd, allow)

The corresponding TCP-Wrapper syntax detailing the access control of the previous

knowledge base individual twd is written as:

sshd: 4.3.2.1 : ALLOW

5 Systems Conﬁguration

This section deﬁnes a model that represents network conﬁguration. Intuitively, a con-

ﬁguration is a collection of nodes, services, proxies, etc. and their relationships, and are

represented as collections of instances from the ontologies.

A small to medium enterprise network environment typically deploys a gateway

ﬁrewall as the initial step in provisioning access control and a succession of locally

hosted access control mechanisms may follow. Figure 2 illustrates an example of a net-

work access control architecture whereby internal nodes hosting business applications

are protected by low-level infrastructure namely a gateway ﬁrewall and may also be

further protected by a local ﬁrewall and/or local proxy deployed on those same nodes.

SWRL rules and queries can be deﬁned to infer and discover facts about the current sys-

tems policy conﬁgurations within the network. For example, assuming that nodes ?n

and business services ?b have been assigned security conﬁdence levels (by instantiating

the hasAssurance and hasAssurReq properties) we can reason over the knowledge

base to ﬁnd suitable nodes on which to host services, that is a hosts conﬁdence is sufﬁ-

cient for the services it may host.

Node(?n) ∧ BusinessService(?b) ∧ hasAssurance(?n, ?a) ∧ hasAssurReq(?b, ?br) ∧

hasSecureConfidenceV alue(?a, ?nrate) ∧ hasSecureConfidenceV alue(?br, ?brate) ∧

swrlb : lessT hanOrEqual(?brate, ?arate) → hasDeployedT o(?b, ?a)

Fig.2. Example SME Access Control Architecture.

6 Policy Analysis

6.1 Risk Policy

The ideal security policy conﬁguration is one that is aligned with the business service

that is, it permits only valid service trafﬁc, and, no more and no less. The following

example of a risk-based inter-policy query, tests whether the aggregate risk from clients

that are permitted (by the protection services) to reach a service exceeds the risk thresh-

old speciﬁed by the service.

BusinessService(?b) ∧ RiskT hreshold(?r) ∧ hasRiskT hreshold(?b, ?max) ∧

hasRiskIP StartRange(?r, ?iprs) ∧ hasRiskIP EndRange(?r, ?ipre) ∧

hasRiskV alue(?r, ?v) ∧ hasP rotectiveP roxyDecision(?b, ?t) ∧ hasRisk(?b, ?r)∧

hasSrcIP StartRange(?t, ?sip) ∧ hasSrcIP EndRange(?t, ?eip) ∧

ipAddress(?sip, ?x) ∧ ipAddress(?eip, ?y) ∧ swrlb : greaterT hanOrEqual(?iprs, ?x)∧

swrlb : lessT hanOrEqual(?ipre, ?y) → sqwrl : select(?max) ∧ sqwrl : sum(?v)

This compares the rangesof clients made visible by the proxy decisions(hasP rotective

P roxyDecision(?b, ?t)) with the associated risks of each client range. Should the sum

(sqwrl : sum) of individual risks be greater than the maximum acceptable risk thresh-

old then that service is not protected sufﬁciently by its host TCP-Wrapper proxy policy.

6.2 Policy Conﬂict Detection

Al-shaer et. al. [1] classify ﬁrewall conﬂicts into four categories: redundancy, shadow-

ing, correlation and generalisation. Due to page constraints, we focus our attention to

intra-ﬁrewall policy conﬂicts detected using SWRL rules applied across the DL knowl-

edge base. Note for reasons of space, we do not consider all four conﬂict categories in

this paper, however they are modeled withinin our ontology. Table 1 provides a frag-

ment of a Linux Netﬁlter ﬁrewall access control conﬁguration.

Shadowing. In general, ﬁrewall decisions are activated in sequence starting at decision

1. A shadowed decision is one that is never activated due to previous decisions ﬁltering

the same kinds of packets but those decisions having different target actions. Table 1, il-

lustrates that Decision 2 is shadowed by Decision 1. Since Decision 2 is neveractivated,

intended http trafﬁc from a speciﬁc host is not permitted.

Table 1. Firewall Decision Policy Example Extract.

Decision Chain Src IP Src Port Dst IP Dst Port State Action Conﬂict

1 Forward *.*.*.* any 192.168.1.2 80 Drop

2 Forward192.168.1.6 any 192.168.1.2 80 Accept Shadowed by (1)

3 Output 192.168.1.1 any 10.37.2.* 21 Rel Drop

4 Output 192.168.1.1 any 10.37.2.* 22 Est Drop

5 Output 192.168.1.1 any 10.37.2.3 21,22 Rel,Est Accept Shadowed by (3,4)

SWRL rules detect conﬂicts within a ﬁrewall conﬁguration. For example, the fol-

lowing ‘partial’ SWRL rule provides a list of tuples x 7→ y, where x is a decision and

y is the decision that shadows x. When executed against the knowledge in Table 1 it

returns tuples 2 7→ 1.

F W 1(?f wrule1) ∧ F W 1(?fwrule2) ∧

decisionOrder(?f wrule1, ?order1) ∧ decisionOrder(?fwrule2, ?order2) ∧

hasSrcIP StartRange(?f wrule1, ?ip1start) ∧ hasSrcIP EndRange(?f wrule1, ?ip1end) ∧

hasSrcIP StartRange(?f wrule2, ?ip2start) ∧ hasSrcIP EndRange(?f wrule2, ?ip2end) ∧

ipAddress(?ip1start, ?ip1s) ∧ ipAddress(?ip1end, ?ip1e) ∧

ipAddress(?ip2start, ?ip2s) ∧ ipAddress(?ip2end, ?ip2e) ∧

hasDstP ortStartRange(?f wrule1, ?dst1ps) ∧ hasDstP ortEndRange(?f wrule1, ?dst1pe) ∧

hasDstP ortStartRange(?f wrule2, ?dst2ps) ∧ hasDstP ortEndRange(?f wrule2, ?dst2pe) ∧

portN umber(?dst1ps, ?dst1ns) ∧ portN umber(?dst1pe, ?dst1ne) ∧

portN umber(?dst2ps, ?dst2ns) ∧ portN umber(?dst2pe, ?dst2ne) ∧

hasT arget(?f wrule1, ?tar1) ∧ hasT arget(?f wrule2, ?tar2) ∧

differentF rom(?fwrule1, ?fwrule2) ∧

swrlb : greaterT hanOrEqual(?order2, ?order1) ∧ swrlb : lessT hanOrEqual(?ip1s, ?ip2s) ∧

swrlb : greaterT hanOrEqual(?ip1e, ?ip2e) ∧ swrlb : lessT hanOrEqual(?dst1ns, ?dst2ns) ∧

swrlb : greaterT hanOrEqual(?dst1ne, ?dst2ne) ∧

. . . → sqwrl : select(?f wrule1, ?fwrule2)

Our DL model not only detects pair-wise conﬂicts between two ﬁrewall decisions (like

the approach taken by [1]) but it can readily detect the conjunctions of partial conﬂicts

in a set-wise fashion that may occur across multiple decisions in regard to a speciﬁed

decision being analysed. For example, Decisions 3-5 of Table 1 captures the ﬁltering of

stateful outward ftp and ssh trafﬁc of the ﬁrewall itself towards the 10.37.2.* subnet

and 10.37.3.3 node respectively whereby connections are Related or Established.

Our model can capture that Decision 5 is ‘partially shadowed’ by the conjunction of a

number of individual proceeding decisions namely 3 & 4 (ports and state).

The same techniques of intra-policy conﬂict detection are applicable to TCP Wrap-

per proxy policies. A risk-based inter-policy analysis was discussed in Section 6.1.

Inter-policyconﬂict detection between ﬁrewall and proxy conﬁgurations to analyze how

one may impact on the other can also be reasoned over within the knowledge base by

the previous conﬂict categorisation methods. While individual conﬁgurations may be

conﬂict free their interoperation may not be, for example; a netﬁlter ﬁrewall decision

may unintentionally ‘shadow’ an intended TCP-Wrapper decsion.

7 Related Research

An ontology-based model that can be used to (binary) test the safety of an individual

ﬁrewall policy with respect to a Semantic Web application policy is described in [11].

This paper builds on the results of [11] by considering how interoperation of multiple

NAC policies (involving multiple ﬁrewalls and proxies) are inﬂuenced by more gen-

eral network service requirements. With this extended model, it is possible to analyze

conﬁgurations for intra- & inter-policy conﬂicts, and to also search for suitable conﬁgu-

rations based on partial conﬁguration knowledge. Furthermore, the risk-metric provides

a quantitative approach to aligning NAC policy to service requirements.

Previous research in relation to applying ontologies to the security domain had pri-

marily focused on security classiﬁcations and tended to go no further than providing

abstract taxonomy’s [12,13]. However, our research provides, in conjunction with pro-

viding an explicit speciﬁcation and basic DL reasoning from a taxonomy perspective,

inferences at a lower level of granularity. Thus, low-level facts of a NAC conﬁguration

are presented as individuals rather than classes on the basis that they are atomic and

will not be further decomposed. Using instances (rather than subclasses) allows sub-

sequent reasoning of collections of NAC conﬁguration policies using SWRL to extend

the expressive capabilities of DL. Policy speciﬁc languages such as KAoS utilize the

Semantic Web approach [14]. However, these languages tend to have a number of short

comings, for example, KAoS’s dependence on Deontic Logic unlike SWRL [15]. SWRL

provides a more generic form of expression with its horn-like rules that can represent

varying degrees of policy conﬁguration (enforcement, conﬂict analysis), business rules,

risk metrics and so forth.

Due to the complexity of NAC policy conﬁgurations, being able to perform con-

ﬁguration analysis can greatly improve network conﬁguration management issues. For

example, a number of approaches have been proposed for the formal analysis of ﬁre-

walls [16–20]. For example, model-checking techniques [16,19] are used to test that

a conﬁguration of ﬁrewalls uphold a global routing policy that restricts certain data to

certain sub-nets. In [18] constraint programming is used as an approach to ﬁnding suit-

able ﬁrewall rules from higher level policy constraints. The focus in these approaches

is more on analyzing that ﬁrewall rules uphold particular ‘correctness’ properties, or on

synthesising ﬁrewall rules from speciﬁed ‘correctness’ properties. While this notion of

‘correctness’ does, in effect, provide semantics for ﬁrewall conﬁguration under a lim-

ited number of a priori properties, it is not intended to provide a framework for general

knowledge representation about ﬁrewalls. The DL & SWRL approach, while not as ex-

pressive as the logics that underlay [16–20], is intended to allow the knowledge base to

be extended and managed in general.

The policy conﬂict detection aspects of this paper focus on the issues of ﬁrewall con-

ﬂicts classiﬁed by [1] as an example. Al-Shaer’s research provides a ﬁltering decision

tree approach to discover and generate an effective and anomaly-free ﬁrewall policy de-

cisions [1,21]. However, we argue that the practicalities of the Semantic Web approach

outlined in this paper greatly extends the research of [1] and other such related research.

Utilising this approach provisions the expressive semantics to interpret not just ﬁrewall

conﬁgurations but those of NAC’s in general in a much more diverse and expressive

way. The provision of reasoning, in particular within the context of OWA, provides our

model with ﬂexibility and extendability of incorporating new knowledge.

8 Discussion & Conclusions

This paper outlined an approach to using a DL constrained ontology to construct, rea-

son about and manage NAC policy conﬁgurations. We demonstrated how NAC policies

(for example; Netﬁlter, TCP-Wrapper and business-level risk policies) could be repre-

sented using Semantic Web techniques. The effectiveness of an access control policy

may be limited or compromised by poor conﬁguration and management of policy de-

cisions. The paper describes how reasoning facilitated access control (inter-policy &

intra-policy) interoperability and measured the level of risk between protection policies

and higher-level business goals. Further investigation is required, for example, extend-

ing the risk metric model, scalability issues and how this work might be used in practice.

Typical errors in a security policy conﬁguration range from invalid syntax and in-

appropriate decision ordering to errors resulting from comprehending the conﬁguration

given its scale and complexity. This paper illustrated how Semantic Web techniques

could be employed to resolve policy conﬂicts (Section 6.2).

Future research will investigate developing a prototype autonomic architecture that

is based on this ontology and reasoning framework. Existing Semantic Web techniques

can be used to provide an agent-based approach to deploying and maintaining security

policy conﬁgurations in a automated/autonomic manner. Semantic NAC agents are re-

sponsible for managing the conﬁguration of access controls (ﬁrewalls, proxies, IDS’s

and so forth). These semantic agents negotiate NAC settings that are constrained by

the current knowledge base, which is in turn controlled by the NAC agents and other

application agents, managing for example, the business rules. The knowledge base is

controlled by adding or deleting facts based on new knowledge and inferences by the

agents. For example, a business agent informs a ﬁrewall agent of a new service offering

whereby the ﬁrewall agent must reconﬁgure (new facts) to enable access.

Acknowledgements

This research has been funded by SFI Autonomic Management of Communications

Networks and Services PI Cluster Award: 04/IN3/I404C.

References

1. Al-Shaer, E., Hamed, H., Boutaba, R., Hasan, M.: Conﬂict Classiﬁcation and Analysis of

Distributed Firewall Policies. In IEEE Journal on Selected Areas in Communications, Vol-

ume 1-1 (2005)

2. Gheorghe, L.: Designing and Implementing Linux Firewalls with QoS using netﬁlter,

iproute2, NAT and l7-ﬁlter. PACKT Publishing (2006)

3. Alesso, H.P., Smith, C.F.: Thinking on the Web: Berners-Lee, Gdel and Turing. Wiley-

Interscience (2006)

4. Smith, M.K., Welty, C., McGuinness, D.L.: OWL Web Ontology Language Guide. (W3C

Recommendation, Technical Report)

5. Venema, W.: TCP Wrapper: Network monitoring, access control, and booby traps. Third

UNIX Security Symposium (Baltimore, September’92) (1992)

6. Baader, F., Calvanese, D., McGuinness, D., Nardi, D., Patel-Schneider, P.: The Description

Logic Handbook: Theory, Implementation and Applications. Cambridge University Press

(2003)

7. Haarslev, V., Mller, R.: Description Logic Systems with Concrete Domains: Applications

for the Semantic Web. In: Proceedings of the International Workshop on Knowledge Repre-

sentation meets Databases, (KRDB), Hamburg, Germany. (2003)

8. Taniar, D., Rahayu, J.W.: Web Semantics Ontology. Idea Publishing (2006)

9. O’Connor, M.J., Knublauch, H., Tu, S.W., Grossof, B., Dean, M., Grosso, W.E., Musen.,

M.A.: Supporting Rule System Interoperability on the Semantic Web with SWRL. (Fourth

International Semantic Web Conference (ISWC2005)

10. Standford: Protege IDE. (http://protege.stanford.edu/)

11. Foley, S.N., Fitzgerald, W.M.: Semantic Web and Firewall Alignment. First International

Workshop on Secure Semantic Web (SSW’08), Cancun, Mexico (2008)

12. Anya Kim, J.L., Kang, M.: Security Ontology for Annotating Resources. 4th Interna-

tional Conference on Ontologies, Databases, and Applications of Semantics, (ODBASE),

Agia Napa, Cyprus. (2005)

13. Herzog, A., Shahmehri, N., Duma, C.: An Ontology of Information Security. International

Journal of Information Security and Privacy (2007)

14. Uszok, A., Bradshaw, J., Jeffers, R., Johnson, M., Tate, A., Dalton, J., Aitken, S.: KAoS

Policy Management for Semantic Web Services. In IEEE Intelligent Systems, Vol. 19, No.

4, (2004)

15. Prez, G.M., Clemente, F.J.G., Blaya, J.A.B., Skarmeta, A.F.G.: Representing Security Poli-

cies in Web Information Systems. Policy Management for the Web (PM4W) Workshop in

the 14th International World Wide Web (WWW) Conference (2005)

16. Guttman, J.D.: Filtering Postures: Local Enforcement for Global Security Policies. IEEE

Symposium on Security and Privacy, Oakland (1997)

17. Mayer, A., Wool, A., Zishind, E.: Fang: A Firewall Analysis Engine. 2000 IEEE Symposium

on Security and Privacy, p. 0177 (2000)

18. Eronen, P., Zitting, J.: An Expert System for Analyzing Firewall Rules. (In: In Proceedings

of the 6th Nordic Workshop on Secure IT Systems (NordSec 2001), pages 100-107)

19. Hazelhurst, S.: A Proposal for Dynamic Access Lists for TCP/IP Packet Filtering. South

African Computer Journal, Vol. 33 (2004)

20. Marmorstein, R., Kearns, P.: A Tool for Automated iptables Firewall Analysis. (USENIX

Annual Technical Conference, FREENIX Track)

21. Golnabi, K., Min, R., Khan, L., Al-Shaer, E.: Analysis of Firewall Policy Rule Using Data

Mining Techniques. In the 10th IEEE/IFIP Network Operations and Management Sympo-

sium, (NOMS) (2006)