Veriﬁable Policy-deﬁned Networking for Security Management

Dinesha Ranathunga

, Matthew Roughan

, Phil Kernick

, Nick Falkner

, Hung Nguyen

Marian Mihailescu

and Michelle McClintock

ARC Centre of Excellence for Mathematical and Statistical Frontiers,

School of Mathematical Sciences, University of Adelaide, Adelaide, Australia

CQR Consulting, Unley, Australia

School of Computer Science, University of Adelaide, Adelaide, Australia

Teletrafﬁc Research Centre for Mathematical Modelling, University of Adelaide, Adelaide, Australia

Keywords:

Security policy, Zone-Conduit model, SCADA security, Security management.

Abstract:

A common goal in network-management is security. Reliable security requires conﬁdence in the level of pro-

tection provided. But, many obstacles hinder reliable security management; most prominent is the lack of

built-in veriﬁability in existing management paradigms. This shortfall makes it difﬁcult to provide assurance

that the expected security outcome is consistent pre- and post-deployment.

Our research tackles the problem from ﬁrst principles: we identify the veriﬁability requirements of robust

security management, evaluate the limitations of existing paradigms and propose a new paradigm with veriﬁ-

ability built in: Formally-Veriﬁable Policy-Deﬁned Networking (FV-PDN). In particular, we pay attention to

ﬁrewalls which protect network data and resources from unauthorised access. We show how FV-PDN can be

used to conﬁgure ﬁrewalls reliably in mission critical networks to protect them from cyber attacks.

1 INTRODUCTION

“He is making a list, and checking it twice;”

(Coots and Gillespie, 1934)

It is common knowledge that St. Nicholas maintains

a ‘naughty and nice’ list of everyone on the planet.

Santa even checks this list twice to ensure it’s com-

prehensive and accurate. The question is: “Why don’t

administrators check security policies even once?”

We know they don’t check, because every existing

ﬁrewall-study has found serious errors in the majority

of the cases (Wool, 2004; Ranathunga et al., 2015b).

Deploying un-veriﬁed security policies often

leaves networks vulnerable to cyber attack, but, ad-

ministrators have little choice in the case of ﬁrewalls

because they frequently have to conﬁgure complex

policies on many heterogeneous devices manually,

box-by-box. This approach to network management

is tedious, error-prone and expensive.

The concept of programmable networking aims to

overcome these challenges in network management

by allowing creation, deployment and management of

novel services rapidly in a network. The evolution

of programmable networks has been slow (Feamster

et al., 2013) and dependent on timely technological

advances. But, these networks continue to lower the

barrier to deploying new services.

Examples of network-management paradigms in-

clude Bhattacharjee et al., 1997; Magedanz and

Popescu-Zeletin, 1996; Feamster et al., 2013; Verma,

2002. These have focused on innovations in both the

networking hardware and software. One paradigm

that is the outcome of network-software innovation

is Policy-Deﬁned Networking (PDN), also known as

Policy-Based Network Management (Verma, 2002).

In PDN, administrators specify high-level declarative

policies that are reﬁned to device-level conﬁgurations

automatically by the underlying framework.

Network-programming paradigms commonly aim

to facilitate security. But, reliable security-

management has challenges

• a security policy must be formally veriﬁed as

error-free prior to deployment, for instance, we

need to compare policies to best-practice stan-

dards, e.g., ANSI/ISA-62443-1-1;

• a policy must be consistent with the underlying

network and technology; and

• security administrators need assurance that

344

Ranathunga, D., Roughan, M., Kernick, P., Falkner, N., Nguyen, H., Mihailescu, M. and McClintock, M.

Veriﬁable Policy-deﬁned Networking for Security Management.

DOI: 10.5220/0005990303440351

In Proceedings of the 13th International Joint Conference on e-Business and Telecommunications (ICETE 2016) - Volume 4: SECRYPT, pages 344-351

ISBN: 978-989-758-196-0

the expected security outcome pre- and post-

deployment are consistent.

In this paper, we propose Formally-Veriﬁable

Policy-Deﬁned Networking (FV-PDN) to overcome

these challenges. In doing so, we compare existing

network- and security-management paradigms to bet-

ter understand their limitations for security. Our con-

tributions in summary are

• clear expression of need for veriﬁcation.

• framework describing types of veriﬁcation.

• explanation of how they can be achieved.

• discussion of challenges faced.

In particular, we pay attention to ﬁrewalls which

are a standard mechanism for enforcing network se-

curity. Firewalls may only protect systems behind it

from external threats, but they are a necessary evil in

protecting data and resources in a network from unau-

thorised access (Rubin and Geer, 1998).

For instance, ﬁrewalls protect the distributed as-

sets of industrial control systems in Supervisory Con-

trol and Data Acquisition (SCADA) networks from

cyber attacks (Byres et al., 2005). They help prevent

network-security breaches and their resulting physical

and environmental damage, ﬁnancial-loss or worse,

the loss of human lives! Much of our work is moti-

vated by such mission critical security applications.

2 LOWERING THE BARRIER TO

NETWORK INNOVATION - A

BRIEF HISTORY

Deploying ideas for better network management his-

torically required following a path to production

through approvals from industry standardising bodies

such as the ITU, followed by uptake by vendors.

This uptake of research by industry was slow in

the 1970s and 1980s, with ideas pushed to implemen-

tation typically after ten years or more. The lag was

primarily due to vendors initially ﬁnding the majority

of the proposed innovations too hard to implement,

given the high cost of computing (Feamster et al.,

2013). Technological advances eventually reduced

computing cost, but, vendors continued to overlook

these innovations driven by their need to keep net-

works closed and proprietary (Feamster et al., 2013).

As a result, frustrated researchers and organisa-

tions looked to open up network control: an idea that

stemmed from the ability to reprogram a stand-alone

PC (Wetherall, 1999). This initiative brought about

new network programming models that focused on in-

novations in both the network hardware and software,

to facilitate better network management and enable

improved network services.

For instance, Intelligent Networks (late 1980s

to mid 1990s) were introduced to ﬂexibly add

new, sophisticated services to existing ﬁxed-line

and mobile telecommunication networks (Magedanz

and Popescu-Zeletin, 1996). The need for service

providers to incorporate these value-added services

without requesting feature changes from switch ven-

dors demanded innovations in the network software.

These innovations enabled simple security features

to be incorporated into the newly deployed services

(e.g., PIN-based protection in account card calling).

Intelligent Networks reduced the typical innovation

time scale for simple services to about three years.

In the mid 1990s, Active Networks allowed cus-

tom functionality to selected trafﬁc packets travers-

ing a device-node (Bhattacharjee et al., 1997; Ten-

nenhouse et al., 1997; Wetherall, 1999). This cus-

tomisation was performed using special code that ex-

ecuted at the nodes. The approach demanded more

processing in the network, code-execution safety and

code cross-platform portability. Several technological

advances helped meet these demands, particularly, re-

ductions in costs of computing and enhancements in

programming languages. The granular control pro-

vided by Active Networks helped enable ﬂow-level

security in enterprise networks (Casado et al., 2006).

With the rapid growth of the Internet in the early

2000s, ISPs faced signiﬁcant challenges, particu-

larly in Trafﬁc Engineering (TE) (Lakshman et al.,

2004). Operators needed to control the paths of heavy

network-trafﬁc more reliably and predictably. Con-

ventional distributed routing protocols were replaced

with centralised route-control (Caesar et al., 2005;

Lakshman et al., 2004; Verkaik et al., 2007).

Centralising control required a network’s control

plane to be decoupled from the data plane (Caesar

et al., 2005; Feamster et al., 2004). This decoupling

was characterised as Software Deﬁned Networking

(SDN) (Feamster et al., 2013).

The control-plane and data-plane were decoupled

in SDN via an open API between the planes (McKe-

own et al., 2008). This API could be extended to suit

applications beyond route control: e.g., to manage the

security and QoS aspects of network trafﬁc at large

scale data centres (Soul

e et al., 2014).

OpenFlow is an example instantiation of this API

(McKeown et al., 2008; Peterson et al., 2006). Open-

Flow’s ﬂow-level control allows network applications

to deploy granular (i.e., per-host or per-user) access

control policies. Real-world deployment of Open-

Flow is also seamless because its ﬂow-level control

is readily supported by existing network hardware.

Veriﬁable Policy-deﬁned Networking for Security Management

345

Having centralised control of the network is par-

ticularly useful for security applications as it allows,

for instance, policy changes to be rapidly deployed

to the network in response to cyber attacks. Having

network-wide visibility allows accurate predictions of

network behaviour under failure conditions (Vahdat

et al., 2015); a useful feature to ensure the security of

systems during a planned maintenance.

SDN has revolutionised network-management

and offered network operators a real choice in deploy-

ing required features in a timely manner. Software

programmers can now write control software to meet

end goals without using closed, proprietary network

hardware. SDN has proved very cost effective (Vah-

dat et al., 2015; Feamster et al., 2013) and has enabled

ideas to be pushed to implementation within weeks.

Policy languages have also helped improve net-

work and security management (Han, 2012). Busi-

ness and security goals are commonly described us-

ing natural language by non-technical corporate man-

agers and alike. These goals are often ambiguous (Liu

and Gouda, 2008) and require human-translation to a

machine interpretable technical speciﬁcation.

Thus, policy languages were required for var-

ious disciplines; some to suit speciﬁc domains

like network- or security-management and others

for general purpose: e.g., Ponder (Twidle et al.,

2009). Network-management languages (e.g., Mer-

lin, NetKAT) help allocate resources such as band-

width (Anderson et al., 2014; Soul

e et al., 2014).

Security-management languages (e.g., XACML, Fir-

mato) assist with access-control and help protect a

user’s privacy (OASIS, 2016; Bartal et al., 2004).

Many SDN languages also exist (e.g., attire,

ﬂowlog, FML, Frenetic, HFT, Maple, Merlin, Net-

core, NetKAT, Pyretic etc.), offering competing

trends. For instance, NetKAT is a functional lan-

guage that supports algebraic models (Anderson et al.,

2014), Pyretic is a procedural language (Reich et al.,

) and Merlin is logic based (Soul

e et al., 2014).

Policy languages can also be device-speciﬁc, i.e.,

low-level (Han, 2012). These languages are not user

friendly: administrator’s cannot specify high-level

goals using them. High-level policy languages try to

overcome the shortfall (Prakash et al., 2015; Bartal

et al., 2004), by capturing policy intent, so, abstract

goals can be speciﬁed. Typical goals include security

objectives (e.g., no single point of failure).

Intent-based network modelling is also supported

by some SDN programming languages (Cohen et al.,

2013; Wijnen, 2015). Intent-based policies are above

network level and are automatically reﬁned to device-

level by the underlying framework.

Policy-language advancements have seen another

network-management paradigm develop: Policy-

Deﬁned Networking (PDN, also known as Policy

Based Network Management) (Verma, 2002). PDN

was developed independently and before the advent

of SDN. In PDN, users specify business-level goals

via high-level policies (Verma, 2002). These policies

are declarative and technology independent. So, users

unfamiliar with the technology details required to de-

ploy a policy, can still manage the network.

PDN has many commercial uses: e.g., QoS man-

agement (Cisco Systems Inc., 1998), Internet services

access-control (Tao, 2005), Web-user privacy man-

agement (Cranor et al., 2002) and so on. Recent work

(Cleder Machado et al., 2015), has shown how PDN

can be adapted for more ﬂexible SDN management.

As PDN and SDN converge to provide an end-to-

end solution for network security management, new

challenges arise. Most notable is that despite the goals

of transparency and predictability adopted in both

communities, the addition of multiple layers makes

policy veriﬁcation more challenging; but also more

vital. We discuss this below.

3 SECURITY-MANAGEMENT

REQUIREMENTS

Security-management has stricter requirements than

general network-management. We investigate these

requirements in detail next.

3.1 Transparency

Network-programming models often include multi-

ple layers of processing (e.g., language compilation,

policy reﬁnement, etc.). These layers decrease trans-

parency. They blur the ability to view the relationship

between a change made and its result.

This black-box like behaviour is analogous to that

of a modern Operating System (OS). For instance,

Microsoft Windows OS depicts storage of ﬁles in a

hierarchical directory structure (Hall, 2003) for easy

understanding. But the layers underneath this repre-

sentation are non-transparent; you need special skills

to learn how ﬁles are stored physically on disk.

Lack of transparency in security-management hin-

ders locating and rectifying an incorrect decision. In

mission critical SCADA networks, this inability can

lead to security malfunction or failure resulting in

catastrophic outcomes. Transparency can be provided

through layer-wise veriﬁcation of the processing. The

more transparent, the more conﬁdence security ad-

ministrators will have of deploying and maintaining

correct security policies in their networks.

SECRYPT 2016 - International Conference on Security and Cryptography

346

3.2 Human-Comprehensible Policy

The ability to author a security policy correctly,

largely depends on (i) how easy it is to express the

intentions of the authors in a policy language; and re-

ciprocally (ii) the ability to clearly understand what

exactly a speciﬁed policy aims to achieve. A security-

policy language therefore, should be easily human

readable and writable to say the least.

But surprisingly, even this fundamental require-

ment is lacking in some popular security-policy lan-

guages. For instance, XACML is an XML based

security-policy language that is accepted as a de

facto standard for access-control management in dis-

tributed systems (OASIS, 2016). The attribute-based

language model offers ﬂexibility, but, the syntax and

semantics of its underlying XML structure makes it

intrinsically difﬁcult for humans to interpret (McK-

endrick, 2006). Thus, a XACML policy author can-

not precisely know, for instance, if a security policy

blocks potentially-unsafe HTTP trafﬁc from entering

a protected SCADA Zone or not. HTTP is known to

carry attacks and worms and could render fatal out-

comes in SCADA networks (Byres et al., 2005).

Even simple XACML access-control policies can

span hundreds of lines of code or more (Han, 2012).

Keeping track of the myriad interactions within a pol-

icy manually is nearly impossible. A useful policy

language should therefore, allow concise description

of policies, in addition to being user friendly.

3.3 Specialisation within Networking

Reliable security management also demands special-

isation in networking. Division of labour is one of

the fundamental hacks of modern culture. Speciali-

sation allows people to work more efﬁciently, and ef-

fectively. For example, in building construction, ar-

chitects do not learn how to lay bricks. They might

learn some structural engineering, but it isn’t neces-

sary. Other specialists can perform that task.

Why then is network engineering still a mono-

lithic area of expertise? We have network archi-

tects and/or IT specialists, but in reality, they are just

better paid network engineers. For instance, con-

sider how network infrastructure manufacturers (e.g.,

Cisco) structure their certiﬁcation programs. It is as-

sumed, that a network architect will know as much,

or more about devices than the person programming

the devices. Decoupling policy from implementation

also creates opportunities for specialisation.

Network-specialisation also allows to verify work

more easily. For one, network architects could easily

check that their designed security policies meet high-

level goals, in the absence of implementation-centric

details. For another, network-engineers only need to

verify that their policy implementations match the ar-

chitects’ designs and not high-level business goals.

3.4 Veriﬁability

The above requirements indicate how veriﬁability is

an important property in security-management. We

cannot assume any software component functions

correctly, from the network-devices up to and includ-

ing the security-management platform. We need to

provably check that the policies are speciﬁed and im-

plemented correctly at every level possible. We dis-

cuss these dimensions of veriﬁability in detail next.

4 WHAT SHOULD WE VERIFY?

Policies play a key role in security management and

it would be sensible therefore, to begin to understand

what aspects of a policy needs to be veriﬁed for reli-

able security-management.

4.1 Verify Policy is Correct

Inconsistencies such as conﬂicts and redundancies

can often occur in a policy (Prakash et al., 2015; Soul

et al., 2014). Conﬂicts indicate an ill-deﬁned pol-

icy and redundancies imply an inefﬁcient one. These

inconsistencies can stem from ambiguities in the

high-level policy goals and their error-prone (manual)

translation to technical speciﬁcation. For instance, it’s

easy for a policy author to accidentally leave in two

conﬂicting access-control rules inside a complex se-

curity policy containing thousands of rules.

The problem is exacerbated by the need for policy

administration by users from multiple sub-domains

(e.g., SCADA engineers, Corporate admins), partic-

ularly in large distributed environments. Commer-

cial network-management tools often cannot com-

pose distributed policies automatically (Prakash et al.,

2015). So, users must manually check with policy

sub-domains for conﬂicts to maintain consistency.

Inconsistencies introduced by policy composition

can also produce unintended consequences (Wool,

2004). So, correct policy deployment demands the

ability to check for policy inconsistencies accurately.

Policy-consistency checking partly veriﬁes syn-

tactic correctness. A syntactically correct policy

must also be semantically correct for it to be well

designed. For instance, it may be necessary to

check a security policy’s semantics against industry-

recommended practices: e.g., ANSI/ISA- 62443-1-1,

Veriﬁable Policy-deﬁned Networking for Security Management

347

for compliance. Doing so, is critical in SCADA net-

works where more restrictive practices are required to

prevent serious injury of people, or even death!

Best-practice compliance checks are also only

meaningful if we compare policy intent not imple-

mentation. How can one compare a SCADA security

policy with a generic ISA-recommended policy if ei-

ther is inter-twined with implementation details?

But, not all policies capture intent. Such policies

need to be checked against organisational intent, sup-

plementary to standards. Deriving organisational in-

tent is a non-trivial manual task that requires a risk

assessment to identify the threats, vulnerabilities, im-

pacts (Stoneburner et al., 2002) and appropriate risk

mitigation strategies. Once the intended policy is de-

rived, a deployed policy can be validated against it.

Existing security-management tools can compre-

hensively check policy syntactic correctness, but not

semantic correctness. And there have been major

incidents: e.g., the hacking of a German steel mill

(BBC, 2014), as a result.

Policy languages that do not capture high-level in-

tent (e.g., Cisco CLI) are often tightly coupled with

the underlying network (Cisco Systems Inc., 2010).

Using these low-level languages is similar to pro-

gramming with Assembler in the 1970s, where users

need to specify, for instance, hardware addresses in

order to communicate with devices. Naturally, errors

are common in Assembler programs (Endres, 1975).

High-level policy languages attempt to overcome

these shortfalls and are analogous to present-day pro-

gramming languages used by software developers.

These programming languages support features such

as modularisation and other constructs that automate

common tasks. They also hand off many subtasks

to the operating system or their interpreter (for in-

stance memory management) and avoid wasted pro-

gramming time in repetitive and error-prone tasks.

To allow cross-policy comparisons, security pol-

icy languages should allow policies to be speciﬁed

abstractly, ﬂexibly enough and in detail. In every

sense of the word these policies must be high-level:

i.e., they must be decoupled from the network and its

implementation, separating the what from the how.

4.2 Verify Policy is Compatible with

Network and Technology

A policy may not always be compatible with the target

deployment network. For instance, the target topol-

ogy may be different from that perceived by the pol-

icy creator, a common occurrence when high-level

policies are built on abstract views of the underly-

ing network. A security-policy creator for instance,

may use the Zone-Conduit abstraction (ANSI/ISA-

62443-1-1, 2007) and consider two zones to be dis-

tinct in the policy speciﬁcation, but in the absence of

one or more ﬁrewalls enforcing a real separation be-

tween the zones, only a single zone may actually ex-

ist. Another example is when network operators cre-

ate out-of-policy connects, e.g., to support wireless,

but again, effectively fuses two zones.

A policy may also not be supported by the under-

lying network’s technology. For instance, a security

policy may intend to ﬁlter application-layer trafﬁc.

But, if Deep Packet Inspection (DPI) capable ﬁrewalls

are unavailable in the target network, the policy can-

not be correctly implemented (Byres et al., 2005).

Thus, a policy must be checkable against both the

underlying network and its technology for compati-

bility, prior to deployment. A user could then swiftly

rectify an incompatible policy or update the target net-

work or technology, in preparation for deployment.

4.3 Verify Expected Security Outcome

Pre-deployment

Policy-creator oversights can also cause a policy to be

ﬂawed (Wool, 2004). Flawed policies can result in se-

curity holes or non-functional networks. A common

instance is failure to enable required routing proto-

cols. Debugging such problems can be confusing and

slow and we would prefer to avoid network disrup-

tions in the interim. Checking a policy for oversights

prior to deployment also needs to be made compul-

sory and automated.

4.4 Verify Expected Security Outcome

Post-deployment

Pre-deployment veriﬁcation doesn’t necessarily guar-

antee expected policy outcome in the real network.

For instance, unintended security policy behaviour

can still occur due to ﬁrewall software bugs (Stouffer

et al., 2008). So, in security management it is equally

necessary to be able to verify that the real network

operates as intended, post-deployment.

A policy may also function correctly in the real

network at ﬁrst, but produce unexpected behaviour

later. For instance, following the upgrade and/or

patching of network ﬁrewalls (Stouffer et al., 2008).

Thus, pragmatic security-management also demands

on the ability to continuously monitor the security

mechanisms of a network post-deployment.

We have described so far, veriﬁability require-

ments of security management. Next, we show how

these requirements can be implemented concretely in

our proposed network-programming paradigm.

SECRYPT 2016 - International Conference on Security and Cryptography

348

5 FORMALLY-VERIFIABLE PDN

Both SDN and PDN support high-level policies de-

coupled from network implementation. Both build on

centralised network control: a feature that helps de-

liver new functionality more rapidly and drive opera-

tional expenditure savings (Feamster et al., 2013). A

key difference is that SDN requires the use of a stan-

dard network API (e.g., OpenFlow) to manage het-

erogenous network devices, while PDN does not.

This requirement in SDN can be too restrictive for

traditional networks: e.g., deploying OpenFlow ca-

pable devices is a distant reality in mission critical

SCADA networks where TCP is a recent innovation!

High availability requirements in these control net-

works (Byres et al., 2005) mean the legacy network

equipment employed within them is unlikely to be

upgraded except during a major overhaul of a plant,

which might happen once in a decade (if that often).

PDN doesn’t require an open network API (e.g.,

OpenFlow), thus, heterogeneous devices in traditional

networks can be managed through support for pro-

prietary conﬁguration languages (e.g., by use of tem-

plates) (Verma, 2002). Administrators don’t require

learning these arcane languages; the PDN engine au-

tomatically invokes them when reﬁning policies.

With this added ﬂexibility, PDN can deliver the

beneﬁts of SDN, while overcoming SDN shortfalls

(e.g., lack of scalability). But, like SDN, traditional

PDN lacks built-in veriﬁability capabilities in §4.

Precisely checking a policy is correct is a non-

trivial task. But, progress can be made towards the

goal using formal policy language semantics. SDN

programming languages: e.g., NetKAT, Pyretic (An-

derson et al., 2014; Reich et al., ) and PDN pol-

icy languages: e.g., Rei, ASL (Kagal, 2002; Jajo-

dia and Samarati, 1997), often include semantics to

facilitate this checking. Additionally in FV-PDN,

formalisms would be included to allow automated-

reasoning about policies: e.g., to precisely compare a

security policy with a best-practice policy for compli-

ance. Such a reasoning framework would involve de-

riving canonical representations of the security poli-

cies (Ranathunga et al., 2016) and developing alge-

bras for accurate policy comparisons.

A correct high-level policy should in theory re-

ﬁne down to correct network- and device-level pol-

icy. But, we simply cannot ‘trust’ FV-PDN to always

correctly reﬁne high-level policy. So, we must addi-

tionally validate that the reﬁned policies are likewise

correct. Alloy (Jackson, 2011) is an example formal

veriﬁcation tool that can be employed to perform this

validation. But as a pre-requisite, the reﬁned policies

need to be converted to an Alloy compatible format.

A high-level policy can be checked against the un-

derlying network for compatibility by validating the

abstract network model perceived by the policy cre-

ator with that of the physical network. For instance,

with Zone-Conduit policies, FV-PDN could derive

and compare the Zone-Conduit model of the actual

network against that the policy is built on, for a match.

It is also possible to check that a policy can be sup-

ported by a network’s technology capabilities, dur-

ing policy reﬁnement (Verma, 2002). So, FV-PDN

could for instance, validate an application-layer ﬁlter-

ing policy against the DPI ﬁrewalls available in the

network, when reﬁning the policy to network-level. If

the available DPI ﬁrewalls cannot implement the pol-

icy correctly, an error is raised.

FV-PDN would also have pre-deployment veriﬁ-

cation built-in. A simple, cost effective way to do

this is by using an emulated network together with

automated pathological trafﬁc tests. Emulation tools

have been used in SDN to test prototype applications

(Gupta et al., 2013) and in PDN to test policies (Va-

cante and Houck, 2003). But, these tools are stan-

dalone, so, prototypes and policies need to be hand

deployed and tested using pathological-trafﬁc. The

manual tedium leads users to bypass this step.

In FV-PDN, we would make this step compulsory

and automated. For instance, FV-PDN could use the

Netkit open source software package (Knight et al.,

2013) that provides an emulation platform for tradi-

tional networks with virtual devices and interconnec-

tions via User Mode Linux. Pathological trafﬁc tests

can be automatically conducted, for instance, using

test scripts generated in Expect– a UNIX scripting

and testing utility (Libes, 1995). These automated

tests can check for ﬁrewall-policy oversights and ver-

ify that a policy only allows the expected trafﬁc ser-

vices through a ﬁrewall (i.e., positive vetting) and

blocks all other services (i.e., negative vetting).

A simple way to automate post-deployment veri-

ﬁcation is by extending the test scripts from the em-

ulated network to the real network. Post-deployment

network behaviour can also be monitored using the

various network-device reports available (i.e., logs,

alerts, traps etc.) (Ranathunga et al., 2015a). For in-

stance, a network’s security mechanisms can be mon-

itored using the diverse ﬁrewall reports generated. A

ﬁrewall-reporting framework proposed (Ranathunga

et al., 2015a) shows that reporting policy must be cou-

pled with security policy, to be useful. Otherwise, one

could deploy policies that are not veriﬁed. FV-PDN

would enforce this coupling automatically.

Next, we consider the challenges that need to be

overcome to achieve the veriﬁability requirements in

§4.

Veriﬁable Policy-deﬁned Networking for Security Management

349

6 FV-PDN CHALLENGES

Achieving veriﬁability in FV-PDN has challenges

What policies do we need to specify, at what level

of detail? We need to understand the types of se-

curity policies that must be supported and the level

of policy-detail needed, to develop methods to check

policy correctness. A comprehensive study of the var-

ious security use cases (e.g., trafﬁc ﬁltering, access-

control etc.) would help identify the different pol-

icy types. Analysis of policy granularity with re-

spect to dimensions such as network, service, time

etc. (Ranathunga et al., 2015a), can help understand

the level of policy speciﬁcation detail required.

What policy abstractions should we choose to as-

sist veriﬁability? The choice of security abstraction

can also assist or hinder veriﬁability. For example,

ﬁrewall policies can be described using the Zone-

Conduit abstraction (ANSI/ISA-62443-1-1, 2007) or

the Role Based Access Control abstraction (Bartal

et al., 2004). The ﬁrst helps to check these policies are

best-practice compliant (Ranathunga et al., 2015b),

whereas the latter can make the task difﬁcult.

How should we manage conﬂicts? Verifying a policy

is correct also depends on managing conﬂicts reliably

and efﬁciently. The type of policy conﬂicts that arise

are context dependent. For instance, a policy built on

an Attribute Based Access-Control abstraction, will

produce two primary conﬂicts: (1) conﬂict between

permission and prohibition; and (2) conﬂict between

obligation and dispensation (OASIS, 2016).

The nature of the conﬂicts determine the man-

agement scheme(s) required (Di Vimercati et al.,

2007b; Di Vimercati et al., 2007a; Strassner and

Schleimer, 1998). For instance, the above conﬂicts

can be managed by assigning explicit priorities to

policies or by overriding positive policies with neg-

ative ones. But, assigning priorities is infeasible for

large distributed environments where distinct policy-

domain users could specify policies. Thus, conﬂict-

management is a balancing act: abstractions must be

chosen to reduce the possible conﬂict types to a man-

ageable few; and conﬂict-management schemes must

be developed being mindful of their limitations.

7 CONCLUSIONS

The inability to verify security policies comprehen-

sively makes it difﬁcult to provide assurance that the

expected security outcome is consistent pre- and post-

deployment. We propose Formally-Veriﬁable Policy-

Deﬁned Networking (FV-PDN) as a new management

paradigm to allow users to comprehensively check

a policy is correct, consistent and compatible with

the underlying network and its technology. We illus-

trate FV-PDNs use in reliable security management

by considering the administration of ﬁrewall policies

in mission critical SCADA networks.

ACKNOWLEDGEMENTS

This project was supported by an Australian Post-

graduate Award, Australian Research Council Link-

age Grants LP100200493, LP140100489 and CQR

Consulting.

REFERENCES

Anderson, C. J., Foster, N., Guha, A., Jeannin, J.-B., Kozen,

D., Schlesinger, C., and Walker, D. (2014). NetKAT:

Semantic foundations for networks. ACM SIGPLAN

Notices, 49(1):113–126.

ANSI/ISA-62443-1-1 (2007). Security for industrial au-

tomation and control systems part 1-1: Terminology,

concepts, and models.

Bartal, Y., Mayer, A., Nissim, K., and Wool, A. (2004).

Firmato: A novel ﬁrewall management toolkit. ACM

TOCS, 22(4):381–420.

BBC (2014). Hack attack causes ‘massive damage’

at steel works, http://www.bbc.com/news/technology-

30575104.

Bhattacharjee, S., Calvert, K. L., and Zegura, E. W. (1997).

An architecture for Active Networking. In High Per-

formance Networking VII, pages 265–279. Springer.

Byres, E., Karsch, J., and Carter, J. (2005). Good practice

guide on ﬁrewall deployment for SCADA and process

control networks. NISCC.

Caesar, M., Caldwell, D., Feamster, N., Rexford, J., Shaikh,

A., and van der Merwe, J. (2005). Design and imple-

mentation of a routing control platform. In USENIX

NSDI, pages 15–28.

Casado, M., Garﬁnkel, T., Akella, A., Freedman, M. J.,

Boneh, D., McKeown, N., and Shenker, S. (2006).

SANE: A protection architecture for enterprise net-

works. In Usenix Security, pages 137–151.

Cisco Systems Inc. (1998). Delivering end-to-end security

in policy based systems. Technical Report.

Cisco Systems Inc. (2010). Cisco ASA 5500 Series Conﬁg-

uration Guide using the CLI.

Cleder Machado, C., Araujo Wickboldt, J., Zam-

benedetti Granville, L., and Schaeffer-Filho, A.

(2015). Policy authoring for software-deﬁned net-

working management. In IEEE IM, pages 216–224.

Cohen, R., Barabash, K., Rochwerger, B., Schour, L.,

Crisan, D., Birke, R., Minkenberg, C., Gusat, M., Re-

cio, R., and Jain, V. (2013). An intent-based approach

for network virtualization. In IEEE IM, pages 42–50.

SECRYPT 2016 - International Conference on Security and Cryptography

350

Coots, J. F. and Gillespie, H. (1934). Santa Claus is Comin’

to Town. Leo Feist Pub 6752-4, NY.

Cranor, L., Langheinrich, M., Marchiori, M., Presler-

Marshall, M., and Reagle, J. (2002). The platform

for privacy preferences (P3P1. 0) speciﬁcation. W3C.

Di Vimercati, S., Foresti, S., Jajodia, S., and Samarati, P.

(2007a). Access control policies and languages in

open environments. In Secure Data Management in

Decentralized Systems, pages 21–58. Springer.

Di Vimercati, S., Foresti, S., Samarati, P., and Jajodia,

S. (2007b). Access control policies and languages.

IJCSE, 3(2):94–102.

Endres, A. (1975). An analysis of errors and their causes

in system programs. In ACM SIGPLAN Notices, vol-

ume 10, pages 327–336.

Feamster, N., Balakrishnan, H., Rexford, J., Shaikh, A., and

Van Der Merwe, J. (2004). The case for separating

routing from routers. In ACM FDNA, pages 5–12.

Feamster, N., Rexford, J., and Zegura, E. (2013). The road

to SDN. Queue.

Gupta, M., Sommers, J., and Barford, P. (2013). Fast,

accurate simulation for SDN prototyping. In ACM

HotSDN, pages 31–36.

Hall, M. (2003). Understanding the ﬁle

system architecture in Windows CE

.NET, https://msdn.microsoft.com/en-

au/library/aa459155.aspx.

Han, W. (2012). A survey on policy languages in network

and security management. pages 477–489. Elsevier.

Jackson, D. (2011). Software Abstractions: Logic, Lan-

guage, and Analysis. The MIT Press.

Jajodia, S. and Samarati, P. (1997). A logical language for

expressing authorizations. In IEEE S&P, pages 31-42.

Kagal, L. (2002). Rei: a policy language for the Me-Centric

project. HP Labs.

Knight, S., Nguyen, H., Maennel, O., Phillips, I., Falkner,

N., Bush, R., and Roughan, M. (2013). An auto-

mated system for emulated network experimentation.

In ACM CoNEXT, pages 235–246.

Lakshman, T., Nandagopal, T., Ramjee, R., and Woo, T.

(2004). The softrouter architecture. ACM HotNets.

Libes, D. (1995). Exploring Expect: A Tcl-based toolkit for

automating interactive programs. O’Reilly.

Liu, A. X. and Gouda, M. G. (2008). Diverse ﬁrewall de-

sign. IEEE TPDS, pages 1237–1251.

Magedanz, T. and Popescu-Zeletin, R. (1996). Intelligent

Networks: Basic Technology, Standards and Evolu-

tion. Thompson Computer Press.

McKendrick, J. (2006). Another view:XML not meant to

be human readable, http://tinyurl.com/hytddnt.

McKeown, N., Anderson, T., Balakrishnan, H., Parulkar,

G., Peterson, L., Rexford, J., Shenker, S., and Turner,

J. (2008). OpenFlow: enabling innovation in campus

networks. ACM SIGCOMM CCR, 38(2):69–74.

OASIS (2016). OASIS Extensible Access Control Markup

Language (XACML) version 3.0.

Peterson, L., Anderson, T., Blumenthal, D., et al. (2006).

GENI: Global Environment for Network Innovations,

http://www.geni.net.

Prakash, C., Lee, J., Turner, Y., Kang, J.-M., Akella, A.,

Clark, C., Ma, Y., and Sharma, P. (2015). PGA: Using

graphs to express and automatically reconcile network

policies. In ACM SIGCOMM, pages 29-42.

Ranathunga, D., Roughan, M., Kernick, P., and Falkner, N.

(2015a). Towards standardising ﬁrewall reporting. In

WOS-CPS. Springer LNCS.

Ranathunga, D., Roughan, M., Kernick, P., and Falkner, N.

(2016). Malachite: Firewall policy comparison. In

IEEE ISCC.

Ranathunga, D., Roughan, M., Kernick, P., Falkner, N., and

Nguyen, H. (2015b). Identifying the missing aspects

of the ANSI/ISA best practices for security policy. In

ACM CPSS, pages 37–48.

Reich, J., Monsanto, C., Foster, N., Rexford, J., and Walker,

D. Modular SDN programming with Pyretic. Techni-

cal Report of USENIX, pages 40–47.

Rubin, A. D. and Geer, D. E. (1998). A survey of Web

security. IEEE Computer, pages 34–41.

Soul

e, R., Basu, S., Marandi, P. J., Pedone, F., Kleinberg,

R., Sirer, E. G., and Foster, N. (2014). Merlin: A

language for provisioning network resources. In ACM

CoNEXT, pages 213–226.

Stoneburner, G., Goguen, A. Y., and Feringa, A. (2002).

Risk management guide for information technology

systems. NIST Special Publication, 800(30).

Stouffer, K., Falco, J., and Scarfone, K. (2008). Guide to In-

dustrial Control Systems (ICS) security. NIST Special

Publication, 800(82).

Strassner, J. and Schleimer, S. (1998). Policy framework

deﬁnition language. Internet Draft, IETF.

Tao, H. (2005). A XACML-based access control model for

Web service. In IEEE WiCOM, pages 1140–1144.

Tennenhouse, D. L., Smith, J. M., Wetherall, D. J., and Min-

den, G. J. (1997). A survey of active network research.

IEEE Communications Magazine, (1):80–86.

Twidle, K., Dulay, N., Lupu, E., and Sloman, M. (2009).

Ponder2: A policy system for autonomous pervasive

environments. In ICAS, pages 330–335.

Vacante, R. C. and Houck, P. T. (2003). Testing of policy

prior to deployment in a policy-based network man-

agement system. US Patent 6,651,191.

Vahdat, A., Clark, D., and Rexford, J. (2015). A purpose-

built global network: Google’s move to SDN. Queue.

Verkaik, P., Pei, D., Scholl, T., Shaikh, A., Snoeren, A. C.,

and Van Der Merwe, J. E. (2007). Wresting control

from BGP: Scalable ﬁne-grained route control. In

USENIX ATC, pages 295–308.

Verma, D. C. (2002). Simplifying network administra-

tion using policy-based management. IEEE Network,

16(2):20–26.

Wetherall, D. (1999). ANTS: network services without the

red tape. IEEE Computer, pages 42-48.

Wijnen, B. (2015). Intent Based Network Modeling (IB-

NEMO), http://tinyurl.com/h95ecﬂ.

Wool, A. (2004). A quantitative study of ﬁrewall conﬁgu-

ration errors. IEEE Computer, 37(6):62–67.

Veriﬁable Policy-deﬁned Networking for Security Management

351