Reasoning About Firewall Policies Through Refinement and Composition

An algebra is proposed for constructing and reasoning about anomaly-free firewall policies. Based on the notion of refinement as safe replacement, the algebra provides operators for sequential composition, union and intersection of policies. The algebra is used to specify and reason about iptables firewall policy configurations. A prototype policy management toolkit has been implemented.


Motivation
Network access control mechanisms, for example, firewalls, Virtual Private Networks (VPN) and Intrusion Prevention Systems (IPS), are configured in accordance with high-level security requirements, and play an important role in provisioning the security for networks and networked systems. While VPNs provide end-to-end security for the packets traversing a network, the use of firewalls as a front-line defence against unwanted network traffic is widespread. Firewalls are used, for example, to mitigate network-based threats for enterprise, research and home networks, and may be deployed throughout a network configuration and at the end-points. For end-users, software-based firewalls come as standard with most of the popular operating systems. In this chapter, we develop a simple running example to illustrate challenges and complexities in managing a firewall policy configuration, and present our approach.

Challenges to Effective Firewall Policy Management
A firewall enforces a policy, and a policy may comprise thousands of low-level and order-dependant firewall rules. As a consequence, policy management is complex and error-prone, and misconfiguration is common. A policy, or distributed policy configuration, may be updated on an ad-hoc basis, possibly by multiple administrators. This can be problematic and may introduce anomalies, whereby the intended semantics of the specified access controls become ambiguous. A misconfiguration may be inconsistent with the high-level security requirements, resulting in accesses that were intended to be denied being permitted, and/or vice-versa.
There are a number of approaches available to an administrator for managing a firewall policy configuration. For example, the goal of [6,30,37,66,159] is to 1. Introduction

Motivation
provide an administrator with the means to detect/resolve anomalies, and work such as [47,52,88,95] allows for querying a policy configuration with regard to the filtering of specific network traffic. High-level specification languages such as [3,13,39,72,84] allow an administrator to abstractly specify what would otherwise be low-level rules. However, in general, the literature for policy management is focused on the conventional five-tuple firewall rule with a binary target action of allow or deny, and few have considered stateful firewall configurations. 1. Introduction

Motivation
Similarly, for the development team, he specifies: Bob needs to combine Pol Admin and Pol Dev into a single firewall policy, and security requirements may change. He requires a consistent means of composing firewall policies, whereby the result is anomaly-free and upholds the enforcements of each policy involved in the composition.

Sequential Composition.
To specify the firewall policy for the company, he tries sequentially composing Pol Admin and Pol Dev as follows. This approach, however, does not does yield the desired result. That is, in the above specification (Pol Admin Pol Dev ), the rule at Index 1 allows some of the IP/port pairs allowed by the rule at Index 2 and vice-versa. Therefore, the policy is anomalous. From this, we have that the naïve sequential composition of rules is not a consistent operation when specifying an anomaly-free policy.

Index Dst IP Dst Port Action
A Flattening Approach. To specify the firewall policy, Bob considers the approach whereby for each IP/port pair allowed by the company's network security policy requirements, there is a rule to allow each IP/port pair. He specifies:

4 4 allow
This policy does provide the desired result, in that it is both anomaly-free and consistent with the two network security policy requirements involved in the composition. We observe however, that this approach is tedious, error-prone and not practical for large numbers of IPs/ports or large numbers of policy rules. 1. Introduction

Motivation
A Different Approach. Bob is required to specify the firewall policy whereby policy rules allow the IP/port-range pairs from either Pol Admin or Pol Dev . To specify the policy for the company, he decides to compose the two requirements into a single requirement as follows.

Index Dst IP Dst Port Action
This approach, however, is inconsistent with the two network security policy requirements outlined by the company. That is, the result of composition is an overly-permissive firewall policy, whereby network traffic is permitted to IP 1 on port 4, and to IP 4 on port 1. Conversely, this approach would result in an overly-restrictive policy if the rules had a target action of deny.
A Better Approach. Bob is required to specify the firewall policy whereby the desired result is the smallest number of anomaly-free rules that allow all the IP/port pairs from either Pol Admin or Pol Dev  In this case, the result is as desired, as it is the smallest number of anomaly-free rules that allow all the IP/port pairs from either Pol Admin or Pol Dev .

Mutual Policy Enforcements.
Bob receives a request to configure the policy that allows the IP/port pairs from both Pol Admin and Pol Dev  In this case, the specification provides the desired result, and defines the smallest number of anomaly-free rules that allow all the IP/port pairs from both Pol Admin and Pol Dev . We observe that the resulting policy upholds the restrictions of both Pol Admin and Pol Dev .
For an administrator, it may be relatively straightforward to understand policy composition where only a small number of rules are involved, however, this 1. Introduction

Research Approach
does not scale. We argue that to reason confidently a policy or distributed policy configuration is anomaly-free and adequately mitigates the identified threats; a common framework is required, whereby knowledge related to detailed access control configurations and standards-based firewall policies can be represented and reasoned about.

Research Approach
The thesis of this dissertation is that a firewall policy should be anomaly-free by construction, and as such, there is a need for a firewall policy language that allows for constructing, comparing, and composing anomaly-free policies.

An Algebra for Firewall Policies
In this dissertation, a formal model for network access control policies is proposed. It is important to have a consistent means of comparing firewall policies, where we can give a precise meaning to the notion of one firewall policy being superior to another firewall policy, with respect to the property of restrictiveness. Therefore, it is necessary to define an ordering over firewall policies. An administrator may need to develop a policy as a collection of independent or related specifications, that will need to be replaced by a policy that adequately captures the requirements of the individual specifications. Therefore, we require a consistent means of composing policy fragments. The proposed model is developed as a lattice structure. The lattice consists of a partially ordered set of all firewall policies, where every pair of policies have a unique lowest upper bound (lub) and a unique greatest lower bound (glb). The glb of two policies defines the most permissive replacement policy that enforces the restrictions of either policy, and the lub of two policies defines the most permissive replacement policy that enforces the restrictions of both policies. Given that firewall policies are used to specify complex access control restrictions, a significant challenge to the approach is determining a suitable lattice. We construct a generic framework for firewall policies that can be used to model policies for different network and host-based access controls. The framework is extensible, and defines an n-tuple model for firewall rule filter condition attributes that extends the conventional five-tuple rule, used for example in [1,5,6,30,35,73,87,159]. The proposed framework defines a firewall policy algebra for constructing and reasoning over anomaly-free policies, and provides sound and consistent lattice operators for policy composition. Based on the notion of refinement as safe replacement [56,57,77], the 1

Research Approach
algebra provides operators for sequential composition, union and intersection of policies. In this dissertation, when one policy is considered a safe (secure) replacement for another, then this means that the former is no less restrictive than the latter. The effectiveness of the algebra is demonstrated by its application to anomaly detection, and standards compliance.
Constructing The Policy Framework. We develop a model to describe what it means to specify, compare and compose anomaly-free policies. The core filter condition attributes for firewall rules in the model define a partial mapping of the iptables filter table. The specification defines formal constructs for filtering at various OSI network layers. To demonstrate the utility of developing an algebra for firewall policies supporting rules with complex range-based constraints, we firstly specify a simple model of firewall rules; FW 0 , whereby policies are defined in terms of constraints on individual IP addresses, ports, protocols and additional filter condition attributes. The proposed algebra FW 0 provides a semantics for firewall policies. While useful for the purposes of reasoning, it is not efficient to naïvely implement the algebra, since a policy is defined in terms of sets of rules constraining individual IP addresses and ports. For example, a policy constraining access from a subnet range 172. 16.*.* involves more than 65K individual packet rules, whatever about the impact of combining these with further constraints on destination IPs and ports. Modelling a firewall rule as a predicate that specifies the set of packets for which the rule evaluates to true requires the conjunction/disjunction of predicates, or the union/intersection of the sets of packets when composing firewall rules. Intersection and union operations on sets of packets may be computationally-expensive due to the possible number of network packets involved. In practice, firewall rules are defined in terms of range-based attributes, and policy rules may match large numbers of packets.
Subsequently, we develop a model FW 1 , that defines a firewall policy in terms of stateful and stateless firewall rules constraining range-based versions of the filter condition attributes used in the simple model. We argue that there is an isomorphic mapping between policies in the FW 0 and FW 1 firewall algebras. A benefit of developing the FW 1 algebra is that we can reason about and compose firewall policies comprising rules constraining range-based attributes, for example ranges of IP addresses and ports, without having to map the rules to individual packets, as this is not practical. We show (in both models), that the set of policies form a lattice under safe replacement, and this enables consistent operators for safe composition to be defined. Policies in each lattice are anomaly- 1. Introduction

Research Approach
free by construction, and the property of anomaly-freedom is upheld as a result of composition under greatest lower bound and lowest upper bound operators. While policies are anomaly-free by construction, we can however define anomalies algebraically; by considering how a policy changes when composed with other policies. The policy ordering relation allows one to reason whether one policy is a safe replacement for another, and as such, we demonstrate its use as a means to test for policy standards compliance. Firewall rules in FW 0 and FW 1 are defined in terms of a binary target action of allow or deny. However, an extension to incorporate an additional firewall rule target action of log is described as part of future work.
Evaluating The Policy Framework. We consider a number of different areas and demonstrate the effectiveness of the approach in practice. A prototype policy management toolkit that implements FW 1 firewall policies for iptables is developed, and experiments are conducted for policy operators. Overall, the results are promising. The cloud computing paradigm has become widely adopted, however, there are security challenges. The OpenStack [63] cloud operating system avails of multiple access control policies of varying types for a firewall deployment, and the environment is highly dynamic due to platform and service migration. A model is developed for OpenStack network and host-based access control policies. Devices such as smartphones operate in mobile network environments and deploying a fixed security configuration for a global set of threats is not practical. Android [141] is used in a variety of domains, from personal devices, to the Internet of Things, to enterprise, medical and military domains. However, configuration of Android security mechanisms, for example, the firewall, and the allocation of system-level permissions to requesting applications, is typically performed by non-technical end-users. The threat-based model developed as part of earlier work [55] is extended to include knowledge about the Android permission model, and a system policy algebra Android Sys is proposed for the Android OS. We show how the compliance-driven threat-based model can be used in conjunction with the Android Sys framework to dynamically manage the anomaly-free security configuration of Android firewall policies and Android permission polices.
Catalogues of Best Practice. Compliance with best practice standards and recommendations allows one to reason confidently that a policy mitigates the identified threats. For example, RFC 5735 [33] recommends countermeasures that mitigate the threat of IP address spoofing from the IANA-assigned 1. Introduction

Contributions
specialized/global-purpose IPv4 address blocks. Best practice standards, including [79,123,125,133,152] for firewall access control have been encoded as part of this work as collections of iptables rules. Excerpts of these catalogues are illustrated in Appendix B, Tables B.1, B.2, B.3, B.4 and B. 5. Compliance policies are defined for use in the FW 1 algebra in Chapter 5 and Chapter 8. In Chapter 8 we also consider policy compliance for permission policies on Android systems. A best practice catalogue extract for permission policies from [112] is illustrated in Appendix B Table B. 6. The knowledge-base of defined compliance policies is used to describe the dynamic synthesis of security configurations for Android.

Contributions
The contributions within this dissertation are summarised as follows.
• The primary contribution of this dissertation is a firewall policy algebra FW 1 , in which anomaly-free firewall policies can be specified and reasoned about. The algebra FW 1 is defined over stateful and stateless firewall policies constructed in terms of constraints on source/destination IP/port ranges, the TCP, UDP and ICMP protocols, and additional filter condition attributes. FW 1 is a generic firewall algebra that can be used to model different firewall systems, and an n-tuple firewall rule filter condition specification is supported by the model.
• A partial mapping of the iptables filter table. This mapping is used to define the filter condition constraints for the firewall policy models.
• A policy model FW OpenStack is defined for OpenStack firewall policies using a derivation of FW 1 . FW OpenStack provides a uniform way to specify and reason about OpenStack host-based and network access controls. In particular, it gives a meaning for OpenStack security group policies and perimeter firewall policies.
• A policy management framework for Android. The framework amalgamates a threat-based model that represents catalogues of best practice standards and a policy algebra Android Sys for the Android OS. The Android Sys algebra incorporates FW 1 , and a simple algebra Android Perm for Android permission policies. The framework defines a model of dynamic security control reconfiguration for Android. 1. Introduction

Layout of Dissertation
Publications. Early versions of the results in this dissertation have been reported in peer-reviewed publications.

Layout of Dissertation
The remainder of this dissertation is structured as follows.
• Chapter 2, Network Access Control and Policy Management. In this chapter, the background research is described, followed by a detailed analysis of related work.
• Chapter 3, Attributes of a Linux-based Firewall . We develop a formal model for various filter condition attributes of the Linux iptables firewall. The attributes are used to construct packet-rules for the FW 0 firewall policy algebra in Chapter 4, and are extended in Chapter 5 to construct range-based rules for the FW 1 algebra.
• Chapter 4, The FW 0 Policy Model. A firewall policy algebra FW 0 is proposed for constructing and reasoning over anomaly-free policies. Firewall 1 An extended version of this paper is currently being prepared for an invited selected publication in the Journal of Computer Security (JCS IOS Press).

Layout of Dissertation
rules in FW 0 are constructed using the filter condition attributes defined in Chapter 3. FW 0 defines a simple model of iptables rules that do not consider range-based filter condition attributes; the purpose of developing FW 0 is to demonstrate the utility of building such an algebra.
• Chapter 5, The FW 1 Policy Model. We develop a firewall policy algebra FW 1 , for constructing and reasoning over anomaly-free policies. The policy algebra FW 1 defines a firewall policy in terms of rules constraining range-based versions of the filter condition attributes defined in Chapter 3.
• Chapter 6, Implementing The FW 1 Policy Algebra. In this chapter, a prototype policy management toolkit that implements the FW 1 Policy I firewall policies defined in Chapter 5 Section 5. 4.1 for iptables is described.
Experiments for policy operators are conducted and the results are reported.
• Chapter 7, A Firewall Policy Algebra For OpenStack. A firewall policy algebra FW OpenStack for OpenStack is proposed. FW OpenStack is a derivation of the FW 1 algebra. We use the algebra FW OpenStack to provide a uniform way to specify and reason about OpenStack host-based and network access controls. A case study OpenStack deployment illustrates practical use of the algebra.
• Chapter 8, A Policy Management Framework For Android. A policy management framework for the Android OS is developed. A case study deployment illustrates practical use of the FW 1 algebra on Android systems. A system policy algebra Android Sys is proposed. Android Sys uses FW 1 , in conjunction with an algebra Android Perm , to manage Android firewall policies and Android permissions. The policy management framework incorporates a threat-based model with Android Sys to enable a model of dynamic security control reconfiguration for Android.
• Chapter 9, Conclusion and Future Research. This chapter concludes the dissertation and considers some future research that may be undertaken.
The Z notation [135] is used to provide a consistent syntax for structuring and presenting the definitions and examples in this dissertation. We use only those parts of Z that can be intuitively understood and Appendix A gives a brief overview of the notation used. Mathematical definitions have been syntax-and type-checked using the f uzz tool [134].

Chapter 2 Network Access Control and Policy Management
This chapter examines the background research for the thesis and related work. In Section 2.1 we consider network and host-based access control through the concepts of the firewall and firewall policy. A classification for firewalls, and the various mitigations they provide in terms of a collection of known network threats is considered. Section 2.2 explores conflict resolution in access control policies. In Section 2.3, current firewall policy management practice is reviewed, and we consider how the work in this dissertation relates to several of the firewall policy management approaches currently available. In Section 2. 4 we consider some of the challenges associated with firewall policy composition.

The Firewall and Firewall Policy
A firewall is an important network security mechanism, used to regulate network access control; it operates as a front-line defence for networks and networked systems. Cheswick et al. [27] give one of the earliest definitions of a firewall as: "a collection of components placed between two networks that collectively have the following properties: 1. All traffic from inside to outside, and vice-versa, must pass through the firewall. 2. Only authorized traffic, as defined by the local security policy, will be allowed to pass. 3. The firewall itself is immune to penetration."

Network Access Control and
Policy Management 2. 1 The Firewall and Firewall Policy In later work, Cheswick et al. describe a firewall as "any software, device, or arrangement or equipment that limits network access" [28].

Security Policy.
A security policy, for example, the Payment Card Industry Data Security Standard (PCI-DSS) [34], is a high-level document that defines a "set of rules and practices that specify or regulate how a system or organization provides security services to protect sensitive and critical system resources" [132]. Table 2. 1 illustrates an overview of the policy requirements from the PCI-DSS.

req-1
Install and maintain a firewall configuration to protect cardholder data. . .
req-1. 1.2 Current network diagram with all connections to cardholder data, including any wireless networks. . .

req-1.2
Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment. . .

req-1.4
Install personal firewall software on any mobile and/or employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), which are used to access the organization's network. To administer network access control, a security policy is refined into a network security policy that "describes an organisation's network security concerns and specifies the way network security should be achieved in that organisation's environment" [105]. Table 2.2 illustrates an example excerpt of a network security policy for a company.

Policy ID Description
nsp-1 Allow administrators to ping the code revision control system in the development subnet for liveness tests.

nsp-2
Allow developers FTP access to the production Web server.

nsp-3
Mitigate the threat of IP spoofing at the network perimeter, in accordance with RFC 5735. All packets traversing the firewall are filtered against policy rules. Both inbound and outbound filtering rules should be specified for resources behind the firewall [152]. Rule target actions are usually allow, whereby the network packet is permitted traversal of the firewall, or deny, whereby the packet is blocked by the firewall. Firewall rules are matched in sequence starting at the first rule, the packet is either allowed or denied when the packet header data is matched against all the filtering fields of a rule within the firewall policy. If there is no rule that matches the packet header information, a default rule is applied. The default rule can be [148]: • Default Deny: deny everything except that which is explicitly permitted.
• Default Allow: permit everything except that which is explicitly denied. The default deny rule is considered best practice [136,152]. It is also considered best practice to log relevant packets for auditing purposes [152], however, a rule with a target action of log does not enforce the final decision to be taken on a matching packet. That is, if the packet is not allowed or denied by a matching rule at a later index, then the default rule is applied.
In this chapter, for ease of exposition, the table format depicted in Table 2 In later chapters, we use different firewall syntaxes, where appropriate, for specifying firewall policies. For example, in Chapter 3, we introduce the iptables [146] command-line syntax, and in Chapter 7 we specify policy rules using the OpenStack [15] firewall syntax.

Firewall Classification
In this section, we examine the various classes of firewall, and consider their effectiveness in terms of mitigating different types of known network threats.

Packet-filter Firewall
A packet-filter is a firewall that enforces a target action on a network packet based only on information found in the packet header. Packet-filters have also been referred to as stateless inspection firewalls [123], as each packet attempting to traverse the firewall is filtered independently of all previously filtered network traffic. Filter condition attributes for policy rules enforced by early packet-filter firewalls are derived from the Network and/or Transport OSI layers [27,105,136]. More recent packet-filter firewalls permit an administrator to also specify policy rules that filter at the OSI Data Link layer, and filter based on the network interface a packet is arriving at/leaving through [40,105,138]. Example 1 A system's attack surface is its number of reachable and exploitable vulnerabilities [75]. An IP-based attack surface is the number of networkaccessible IP addresses reachable through the firewall for exploitation by an attacker. Configuring the firewall to only permit access to the necessary/authorized IPs will reduce the attack surface. The firewall policy example illustrated in Table 2.6 implements the high-level network security policy goal nsp-1 from Table 2 External threats to resources are often more easily perceived than the internal threats [148], and as a consequence, the policy may be overly-permissive to  Table 2.6 permits all outbound traffic. When configuring the rules that define a firewall policy, the specifier should consider the bi-directional nature of the traffic being filtered [24], and where possible, apply a default deny rule to outbound traffic [152]. Therefore, a revised specification for the packet-filter policy that implements nsp-1 is given in Table 2 Enforcing a default deny rule supports the principal of least privilege [120], and when considering outbound traffic, this can help to mitigate/reduce the flow of Malware communication from infected systems. For example, a Remote Access Trojan (RAT) may be running on the code revision control server at gitIP. The default deny rule helps mitigate the RAT from indiscriminately making outbound connections to an external Command and Control (C&C). RATs can also be explicitly blocked by filtering ports known to be used for C&C communication [26]. Best practice [33,115,152] recommends that filtering rules be applied to ingress and egress traffic in order to mitigate the threat of IP spoofing. A packet's source IP address may be spoofed by an attacker in an attempt to get the firewall to process the packet as if it had originated from the system hosting the firewall itself, or from systems protected by the firewall [51]. Spoofing typically forms part of a Denial of Service (DoS) attack [102].

Stateful Firewall
A stateful firewall improves on packet-filter functionality, whereby the decision to allow or deny a packet is also based on previous packets filtered by the firewall [105,123]. Stateful firewalls have also been classified as dynamic packet filters [28]. When a packet is filtered by the stateful firewall, if the packet matches a rule in the firewall policy, then the packet's state information is added to the firewall's state table [152]. A firewall's state table will typically include source and destination IP and port, network protocol, and connection state information such as TCP flags [103]. The connection state information may indicate, for example, Example 2 A port-based attack surface is the number of network ports reachable through the firewall for exploitation by an attacker. Configuring the firewall to only permit access to necessary ports will reduce the attack surface. The initiator of a TCP connection is dynamically allocated a port in the unprivileged port range (1024 . . 2 16 − 1) that only has significance for the lifetime of the connection. A packet-filter firewall must allow traffic on all these ports in order to permit TCP traffic, thereby unnecessarily exposing ports to potential attackers. A stateful firewall dynamically manages the unprivileged ports as part of the TCP connection [136].
State information maintained by the firewall can be used to help mitigate replay attacks [103]. State information for the UDP protocol can be managed in terms of source and destination IPs and ports [152]. Some firewalls, for example, Linux iptables can manage ICMP state information in terms of source and destination IP addresses, where also an ICMP error message may be considered related to an entry in the firewall's state table. Firewalls also provide an effective way to mitigate against invalid TCP packets used in port scanning techniques. For example, the Nmap XMAS TCP port scan where all TCP flags are simultaneously set [91]. A stateful firewall also provides an effective way to mitigate against valid TCP packets that are forged. For example, TCP packets forged to mimic the expected return packets for outbound TCP traffic requests, such as the Nmap ACK port scan [91]. Packet-filters can also enforce rules based on TCP flags, however, a stateful firewall automatically manages TCP flags.
at the OSI Application layer. This process is also referred to as Deep Packet Inspection (DPI) [123]. Filtering packet-payload information allows for decisions to be made on network packets containing certain keywords, for example, the FTP "put" command [111], or on packets containing certain regular expressions. Table 2.9 gives a firewall policy specification for the high-level network security policy goal nsp-2 from Table 2.2, whereby filtering by packetpayload is used to allow all inbound traffic to the production Web server using the FTP Application-layer protocol from the developer IP range.

Index Dir Src IP Src Prt Dest IP Protocol L7 Filter Action
1 ingress devRange ≥ 1024 webIP TCP ftp allow Table 2.9: A policy specification for nsp-2 using Layer 7 filtering The following regular expression [85]: is used by the Netfilter firewall to match packets that are part of FTP traffic.
Application-layer firewalls can filter malicious payloads. For example, Netfilter provides OSI Layer 7 filtering support for executable file types, and some well known worms such as Nimda and Code Red [98]. Application-layer firewalls can also help mitigate the practice of tunnelling, that is, the encapsulation of data from one protocol inside another protocol in order to evade the firewall [27]. For example, using DNS tunnels to bypass captive portals for paid WiFi service [50].

Proxy Firewalls
A proxy is a an intermediary, that operates on behalf of two interacting network principals/systems [103,105]. An application-level gateway is a proxy system with application-layer firewall filtering capabilities, and a circuit-level gateway is a proxy that filters at lower layers of the network stack [28]. The application-level proxy deals specifically with a particular application/service, while an advantage of the circuit-level proxy is that it provides a proxy system for a wider variety of services [24]. A proxy can be used to provide an additional level of security to an organisation's internal systems, whereby external clients may only communicate through the proxy to access an organisation's internal IP addresses not publicly accessible from the Internet [103,152]. Proxies can also make port scan reconnaissance more difficult for an attacker, as the attacker will not receive packets created directly by their target systems [103].

Access Control Policy Conflict Resolution
An access control policy specifies the authorizations to be enforced regarding system or network resources. In general, the authorizations are positive or negative, and traditionally, an access control policy consisted of either positive or negative authorizations under a Closed or Open policy model [121]: • Closed Policy: specified authorizations are positive and signify access be granted, all other accesses are denied.
• Open Policy: specified authorizations are negative and signify access be denied, all other accesses are granted.
The specification of an access control policy that supports both positive and negative authorisations may result in conflicts in policy decisions. That is, for example, when there is both a positive and negative authorisation specified for a given access in a policy. Whether the specified access should be granted or denied must be decidable in order for an access control system to be useful. There are various approaches to policy conflict resolution, however, there is not a one-size-fits-all solution [78,90]. Depending on the type of access restrictions to be enforced, then there are different conflict resolution policies/methodologies that can be applied. For example, the most-specific rule approach [90] means that the authorization that is more-specific takes precedence, allowing for an exception to be made of the less-specific authorization [113]. The denials-take-precedence approach [90] supports the principle of least privilege, and means that negative authorizations take precedence over positive authorizations in policy decisions. The positional approach [131] is where authorizations are specified in an orderdependant list, and the first occurrence of an authorization in a policy is the authorization that gets enforced.
Policy models can incorporate a combination of conflict resolution policies in order to deal with conflicting authorizations in a policy, for example, by firstly applying the most-specific rule approach, followed by denials-take-precedence [121]. The rules in a firewall policy are order-dependant, and therefore when making a policy decision, we evaluate the rules in order and the first matching rule provides the decision. Thus, the sequencing of firewall rules provides a semantics for dealing with conflicts. However, the presence of conflicting rules in a policy results in policy anomalies, whereby a policy is anomalous when a network packet matches with two or more policy rules [5,35]. Even though the sequencing of rules gives a semantics for handling policy conflicts, we argue that a firewall policy should

Firewall Policy Management
Firewall policy management is complex and error-prone [25,156,157]. In specifying a policy or distributed policy configuration, a high-level security policy is translated into low-level rule syntax via a command line interface (CLI) or by using a Graphical User Interface (GUI) management console. A policy may consist of thousands of firewall rules, and as the number of rules increase, so does difficulty of modifying/updating the firewall policy. Typical errors range from invalid syntax and incorrect rule ordering, to a failure to uphold a security policy due to errors resulting from the poor comprehension of a firewall configuration [94,152].
The GUI is the most common technique used to configure a firewall [41,83], however, GUIs often lack configuration granularity and only provide a limited number of filter condition fields, thereby restricting an administrator from, for example, specifying firewall rules that filter TCP Flags or ICMP Codes/Types. An effective firewall policy may be further hampered by the poor understanding and/or management of the overall high-level security requirements. In this section, we consider firewall policy management practice.

Anomaly Management
Recall, a policy is anomalous when a network packet matches with two or more policy rules. Managing anomalies involves determining the relationships between rules in a policy, or between rules across a distributed policy configuration. This structural analysis of policies is used to detect/resolve firewall policy anomalies. Hari et al. [73] report some of the earliest research on conflict detection and resolution in policies for packet-filters. A rule is referred to as a filter, and a filter conflict occurs when "two or more filters overlap, creating an ambiguity in packet classification", whereby the target actions of the two filters are different. The rule relationships are modelled in a directed graph, and the policy is conflictfree if the graph is acyclic. They show that re-ordering conflicting rules does not guarantee anomaly resolution, and a scheme is proposed that results in the addition of resolve rules to the policy. However, the approach requires the manual intervention of an administrator to decide if conflicting rules should be re-ordered, or if a resolve rule is required and the position it should be inserted at in the policy. Al-Shaer et al. [4][5][6]69] provide definitions for firewall policy anomalies. The classifications are redundancy, shadowing, generalization, correlation, irrelevance and spuriousness. In later chapters of this dissertation, we use a subset of these classifications when reasoning about firewall policy anomalies. Al-Shaer et al. use a form of Binary Decision Diagram (BDD) to represent a firewall policy, and define relationships between pairwise rules. The Firewall Policy Advisor [5] tool implements algorithms used to identify firewall rule anomalies using set theory. Anomalies that occur in a single firewall policy are called intra-anomalies, and anomalies that occur in a distributed policy configuration are called interanomalies. Two additional anomaly classifications are considered in [69]. These are the blocking existing service anomaly and the allowing traffic to a non-existing service anomaly. However, these additional anomalies are detected by applying data mining techniques to firewall logs, as opposed to analysing the rules in the policy configuration.

Intra-Redundancy Anomaly.
A policy has intra-redundancy if there are two policy rules with the same target actions filtering some of the same network packets, such that the removal of the redundant rule does not change the filtering semantics of the firewall policy. A redundant rule may be equivalent to, or subsumed by a rule at an earlier index in the policy. For example, in Table 2  Redundant rules may decrease the performance of the firewall due to unnecessary rule lookup overhead.
Intra-Shadowing Anomaly. A policy has intra-shadowing if there are two policy rules with different target actions filtering the same network packets, such that the shadowed rule is never matched, whereby the target action of the rule at the earlier index in the policy is applied to the network packets. A shadowed rule may be equivalent to, or subsumed by a previous rule. For example, in Table 2.12 the rule at Index 2 is a 'subset' of the rule at Index 1, and is therefore shadowed as the rules have contradictory target actions.  In general, an administrator might re-order the rules or remove the shadowed rule to resolve the anomaly.

Intra-Generalization Anomaly.
A policy has intra-generalization if there are two policy rules with different target actions filtering the same network packets, such that the rule at the earlier index in the policy is subsumed by a more general rule at a later index. Al-Shaer et al. consider generalization as an anomaly warning only, as an administrator may specify a rule that makes an exception of a more general rule. For example, in Table 2  We observe that the intra-generalization defines a partial shadowing of the general rule by the exception rule. Note, if an administrator re-ordered the rules in Table 2.12 as an approach to resolving the intra-shadowing anomaly, then an intra-generalization anomaly is the result, as illustrated in Table 2. 13.

Intra-Correlation Anomaly.
A policy has intra-correlation if there are two policy rules with different target actions, such that both rules can filter some network packets filtered by the other. More formally, the rules are correlated, if some of the filter fields in one of the rules are equivalent to, or subsumed by the corresponding fields in the other rule, and the remaining fields in the former rule are supersets of the corresponding fields in the later rule. For example, in Table 2.14 the rules at Index 1 and Index 2 are correlated.  Table 2.14: An intra-correlation policy anomaly example The intra-correlation anomaly is analogous to the packet filter conflict defined by Hari et al. [73], and in [73] it is considered a serious policy error. In contrast, Al-Shaer et al. consider intra-correlation to be an anomaly warning only. Note, Al-Shaer et al. do not consider intra-correlation for firewall rules with the same target action, we observe that this type of anomaly defines a type of redundant filtering in a policy.

Intra-Irrelevance Anomaly.
A policy has intra-irrelevance if there is a policy rule that cannot be matched based on the source and destination IP address of the domains accessible through the firewall. For example, in Table 2  Inter-Spuriousness Anomaly. An inter-spuriousness anomaly exists between an upstream firewall policy and a downstream firewall policy if the upstream policy allows packets that are denied by the downstream policy. A spurious rule in the upstream firewall may be equivalent to, subsumed by or a superset of a rule in the downstream firewall policy. For example, the rule at Index 3 in Table 2.16a of the upstream firewall is allowing FTP traffic to the IP address 172. 16.1.13, while the rule at Index 3 in Table 2.16b of the downstream firewall is denying the same network packets.

Inter-Correlation
Anomaly. An inter-correlation anomaly exists between an upstream and downstream firewall policy if there exists a rule from each policy, such that both rules can filter some network packets filtered by the other, irrespective of the rule target actions. Inter-correlation between upstream and downstream firewalls can also create inter-shadowing and inter-spuriousness anomalies. For example, the rule at Index 4 in Table 2 [35][36][37] and García-Alfaro et al. [67], present MIRAGE (MIs-configuRAtion manaGEr), and provide alternative definitions for intra-and interanomalies. For example, a policy has (intra-)shadowing [35] if there is a policy rule that cannot be matched due to a previous rule or a combination of previous rules filtering the same network packets, regardless of rule target actions. For example, in contrast to the view in [5,6], the rule at Index 2 in Table 2.10 is not intra-redundant to the rule at Index 1, rather it is (intra-)shadowed [35]. A policy has (intra-)redundancy [35] if there is a policy rule that is not shadowed, and removal of this rule does not change the filtering semantics of the firewall policy. In contrast to [5,6], rules with overlapping filter-fields are considered, and given a firewall configuration, MIRAGE will automatically detect and remove intra-redundant and intra-shadowed rules, and generate a semantically-equivalent order-independent set of disjoint rules that are anomaly-free. In contrast to [73], the approach incorporates the automatic re-writing of anomalous rules. The inter-anomalies discovered by MIRAGE in a distributed policy configuration are presented to the security administrator to determine a suitable resolution. Yuan et al. [159] present the FIREMAN (FIREwall Modelling ANalysis) tool. Policy configurations are analysed for inconsistencies that consider intrashadowing, intra-generalisation and inter-shadowing anomalies [5,6]. The definition given for intra-correlation allows for considering overlapping rules. Firewall inefficiency in packet classification and memory consumption is also considered as a result of intra-redundant rules, and 'verbosities', whereby a set of rules may be summarized into a smaller number of rules without changing the filtering semantics of the policy. The authors observe that in a distributed firewall configuration, redundant rules with a target action of allow are required for a packet to be permitted traversal of all firewalls on its path from source to destination. In contrast to the opinion in [6] that inter-redundant rules with a target action of deny can be removed, the view in [159] is that such rules are considered good practice, as they enhance security by providing a defence in depth approach to a distributed policy configuration. Yuan et al. also consider end-to-end security behaviour and Cross-Path inconsistency [159] in a distributed firewall configuration, where there may exist multiple data-paths from one host/network to another host/network, and packets denied on one path may be accepted on another. The authors observe that data-paths are determined by the underlying routing protocol and a given path may not always be available, and as such, the firewall configuration should consider all possible paths.
Chomsiri and Pornavalai [30] propose a method of firewall policy analysis using relational algebra. The definitions provided for intra-redundant and intrashadowed rules are analogous to [35,36], and upon detection, such rules are removed in order to reduce the size of the policy. Similar to the notion of verbosities in [159], Chomsiri and Pornavalai propose combining rules that may be 'summarized' without changing the filtering semantics of the policy. The definition given for intra-generalization is analogous to [5,6], however in contrast to [5,6], rules with overlapping filter-fields are considered through the definition provided for intra-correlation. Intra-correlated and intra-generalized rules are reported to the administrator as a result of policy analysis.
Abedin et al. [1] propose an algorithmic approach to detect and resolve anomalies between pairwise rules in a firewall policy. The definitions provided for intraredundancy and intra-shadowing are analogous to [5,6], and intra-generalization is considered as an anomaly warning only. However, similar to [30,35,36,159], Abedin et al. consider rules with overlapping filter fields, and a definition of intra-correlation is provided, whereby two policy rules are correlated if they are "not disjoint, but neither is the subset of the other" [1]. Fitzgerald et al. [53] propose an ontology engineering approach to model and reason about firewall policy configurations. An iptables policy model ontology is constructed, and policies are reasoned over for intra-redundancy, intra-shadowing, intra-generalisation and intra-correlation anomalies [5,6].
Regardless of the divergence in anomaly classification, the authors of [30,35,53,159] all observe shortcomings in the work of Al-Shaer et al. [5,6]. For example, in [5,6] rule anomaly analysis is performed only on a pairwise basis, and therefore anomalies involving more than two rules are not considered. For example, the rules at Index 1 and Index 2 of Table 2.17 deny SSH traffic from the IPs 192.168. 1.* to the servers at 172. 16. 1.7 and 172. 16.1.8, respectively, however, the rule at Index 3 is intended to permit SSH access to both servers from 192.168. 1.5. Performing pairwise analysis on the rules in Table 2.17 will not detect an anomaly, however, considering the union of the rules at Index 1 and Index 2; we have that all of the packets that match the rule at Index 3 have already been matched [35,36].   [23] propose a tool based on FIREMAN [159] for managing anomalies in stateful firewall policies. The authors argue that verifying a stateful firewall for inconsistencies can be reduced to the problem of verifying a stateless firewall for inconsistencies. Policies are analysed for intra-redundancy, intrashadowing and intra-generalization anomalies that are analogous to the definitions given in [5,6], and intra-correlation anomalies where rule overlap is considered. A limitation of the approach is that their model does not distinguish rules with different state information, that is, for example, there is no differentiation between the establishment and termination phase of a given stateful protocol, and as a consequence, they do not consider more complex anomalies that may occur specifically in the stateful case.

Index Src IP Src Prt Dst IP Dst Prt Protocol Action
Cuppens et al. [38] and García-Alfaro et al. [66] propose an algorithmic approach to detect and resolve anomalies in a stateful firewall policy. A connectionoriented protocol is modelled using general automata, whereby the permitted protocol states and transitions are encoded. Intra-redundant and intra-shadowed  [35,36] are considered for the stateful firewall policy. Further definitions are proposed, whereby an intra-state anomaly occurs in a stateful firewall policy if there are policy rules that partially match (complete) the paths of the protocol automata. For example, if the connection establishment and/or connection termination phase is permitted, and the remaining rules necessary to complete the paths of the protocol automata are either missing or conflict with the earlier rules. The proposed algorithms detect conflicting rules, and a modification is applied "so that the resulting set gets consistent with the action with higher priority (e.g., accepting the termination phase if the establishment was accepted as well)" [66]. In the case of missing rules, then covering-rules are suggested to the administrator as a means of completing the path of the protocol automata. Their work also considers invalid protocol states, and inter-state anomalies that may occur in a firewall policy that filters packets against both stateful and stateless rules. The work in [38,66] also extends the MIRAGE [67] tool. The work of Al-Shaer et al. [5,6] and Cuppens et al. [35,38] is focused on firewall rules with a target action of either allow or deny. However, to permit the logging of relevant packets for auditing purposes [152], then a firewall policy should also allow for specifying rules with a target action of log. In terms of the structural analysis of a policy, a rule with a target action of log may be shadowed by a rule with a target action of allow or deny, however, a rule with a target action of allow or deny cannot be shadowed by a rule with a target action of log. Following the approaches taken by both [5,6] and [35,38], then the rule at Index 2 in Table 2.18 will be falsely detected as intra-shadowed. Fitzgerald et al. [53] consider rules with a target action of log when analysing a policy for anomalies.  In this dissertation, an algebra is proposed for firewall policy configuration management. While policies in the proposed model are anomaly-free by construction, we can however define anomalies using the algebra; by considering how a policy changes when composed with other policies. We use a number of anomaly definitions from [5,6]

Query Systems
Firewall query analysis allows an administrator to pose questions of a policy configuration, such as, for example, "does the policy permit SSH traffic from system x to system y?" or "what network services are available on system x?". Mayer et al. [95], present Fang (Firewall ANalysis enGine). Based on graph algorithms and a rule-base simulator, Fang parses vendor-specific firewall policy and configuration files, and constructs a model of the network topology and a global firewall policy for the network. Fang interacts with the administrator through a query-and-answer session, and queries are constructed as triples, consisting of source IPs, destination IPs and endpoint services/ports. However, the administrator is restricted to querying only the kinds of packets that are permitted. The Lumeta Firewall Analyzer [96,155], built as an improvement on Fang, automates the process of specifying the topology configuration file by taking as input a formatted routing table. The process of constructing the firewall queries is also automated in [96,155].
Eronen and Zitting [47] propose an expert system for query analysis, implemented in constraint programming logic using ECLiPSe [153]. A query is constructed as a six-tuple, consisting of source and destination IP and port, network protocol, and flags. The flags attribute is for TCP connections, however, only the SYN and ACK flags are considered. Their model allows for querying both allow and deny rules. Eronen and Zitting argue that in comparison to Fang [95], the expert system is a more natural solution for query analysis.
Liu et al. [88] present the Structured Firewall Query Language (SFQL), an SQL-like query language. Liu et al. state that constructing an expert system such as [47] "just for analysing a firewall is overwrought and impractical" [88], however, they do not give their reasoning for this assertion. SFQL queries can be constructed over allow and deny rules for an arbitrary number of filter fields. The authors show how SFQL can be mapped to natural language, however, the example queries in [88] only consider network interface, source and destination IP address, destination port and protocol. A study of Fang beta-testers in [96] showed that a significant challenge to effective query analysis is that users often do not know what to query of a policy.
Marmorstein and Kearns [93] present ITVal, a tool that enables query analysis for iptables firewall policies. Firewall  Querying firewall rules with a target action of log is also considered. The authors note that a limitation of their approach is that some queries may generate a large volume of results, and how results are presented may be difficult for an administrator to reason over. In comparison to [88], the query language proposed in [93] is closer to natural language.
While query analysis provides an administrator with a means of asking questions of a firewall policy, what can actually be queried is restricted by the collection of filter condition attributes and target actions expressible in the query language. Effective query analysis may be further hampered by the complexity of the query language, or through an administrators inability to construct useful queries [96]. The FIREMAN [159] toolkit, discussed in Section 2. 3.1, can also be used for query analysis, and provides an administrator with a predefined collection of queries. A consequence of the algebra proposed in this dissertation is that it enables an administrator to perform effective query analysis of a firewall policy configuration. While we do not construct individual high-level queries, we do however demonstrate in later chapters how policies in the algebra may be tested/queried for compliance with best practice standards and recommendations.

High-level Specification Languages
High-level specification languages provides an administrator with the means to reduce the complexity of constructing a firewall policy configuration.
Guttman [72] reported some of the earliest research in this area. The proposed specification language has a Lisp-like syntax, and allows an administrator to specify a global access control policy for the routers of a network. Knowledge about the network topology is incorporated in the approach, and a policy configuration for individual routers is synthesised. Policy rules are conflict-free, however, the proposed approach only considers rules with a target action of allow, and all other traffic is denied by default. As a consequence, this restricts an administrator from explicitly denying network traffic that may, for example, be spoofed, or consist of packets with invalid combinations of TCP flags. Guttman notes a limitation of the approach is that the generated policies only administer network access control for the systems beyond the routers themselves, and as such, policies do not consider access control for services hosted locally by the router.
Bartal et al. [13] and Mayer et al. [96] present the Firmato toolkit. The proposed specification language allows an administrator to specify the network security policy and the topology for the network in terms of an entity-relationship  [72], the modular separation of the network security policy from the network topology provides an administrator with greater flexibility when managing the network configuration. For example, the same high-level network security policy may reused with different network topologies. A limitation of the work is that it only applies to packetfilter policy configurations. Note, the Fang [95] query analysis tool, discussed in Section 2.3.2 is a module of Firmato. The High Level Firewall Language (HLFL) [84] translates high-level firewall rules into usable rulesets for iptables, Cisco ACLs [31], IPFW [11] and others. However, the generated rulesets are order-dependant and may contain anomalies, and the approach does not provide support for incorporating knowledge about a network topology when specifying the high-level rules.
Cuppens et al. [39] present a specification language based on XML syntax. The language is supported by the Organization-Based Access Control (Or-BAC) [2] model, and as such, policies are specified at a high level of abstraction. Similar to [96], the network security policy is decoupled from the network topology. An XSLT translation process is applied to the high-level Or-BAC rules to synthesize a collection of firewall rules for iptables. The MIRAGE [67] tool, discussed in Section 2. 3.1, incorporates the OrBAC model as a means of specifying and deploying anomaly-free network security policies.
In a different vein, Liu and Gouda [87] propose a method of diverse firewall design. The approach is inspired by N-version programming [8], whereby the same network security policy is given to multiple teams who independently specify different versions of the firewall policy. The firewall policies are analysed algorithmically for conflicts, and the different teams compare the results and discuss any conflicts across the specifications. Subsequently, all teams agree on the policy that is to be synthesized. A firewall policy is modelled as a firewall decision diagram (FDD) [71], similar to a BDD. In [71], Gouda and Liu consider the issues of consistency (correct rule ordering), completeness (matching all network traffic), and compactness (no redundant rules) when specifying a firewall policy as an FDD. A disadvantage of the approach is that specifying FDDs is complex. Fitzgerald and Foley [52] propose using ontologies to represent knowledge about firewall policy configurations. Policies are specified using Description Logic and SWRL. Semantic Threat Graphs [60] are used to encode catalogues of best practice firewall rules, and an automated synthesis of standards-compliant rules for a policy configuration is considered. However, the administrator must manu- ally construct the rulesets for the catalogues then populate the Semantic Threat Graphs, and this process is error-prone. The proposed model can also be used for firewall policy query analysis. Adão et al. [3] propose a declarative policy specification language, and present Mignis ("murus ignis" ("a wall of fire" in Latin)), a tool that translates high-level access control specifications into low-level policy configurations for Netfilter. An abstract model of the Netfilter firewall is proposed, and definitions for Network Address Translation and stateful filtering are encoded. The synthesised policies consist of order-independent iptables firewall rules. However, the proposed approach is tightly coupled with Netfilter.
Similar to a shortcoming of query analysis, the policy that can be synthesized using a high-level specification language is limited by the collection of filter condition attributes and rule target actions expressible in the language. Additionally, work in this area in general has been focused on packet-filter firewalls.

Challenges of Policy Composition
An administrator may develop a firewall policy by specifying independent or related requirements, that need to be replaced by a policy that adequately captures the requirements of the individual specifications. However, while the individual specifications may themselves be consistent with the network security policy, their composition may result in a policy that enables unauthorized traversal of the firewall. Mismanagement of composition in a distributed policy architecture may allow for an attacker to traverse the network configuration in order to reach their intended target by following possibly direct or indirect paths that occur as a result of composition.
Gong and Qian [70] considered the problem of secure interoperation in networks of heterogeneous access control systems. A graph-based model is used to represent a secure access control system, whereby nodes are system entities and arcs specify the direction of positive/negative access. System interoperation is defined by composing graphs, and it is shown that the composition of individually secure systems does not necessarily result in a secure system. That is, an unauthorized user may potentially gain access to a resource by following an indirect path across the individually secure but now interoperating access control systems. Gong and Qian show that in the graph-based approach, the optimal elimination of interoperation vulnerabilities occurring as a result of composition/interoperation is NP-complete. Bistarelli et at. [19] consider the problem in [70], and propose a constraint-based model to represent a secure access control system. System reconfiguration for secure interoperation is expressed as a Constraint Satisfaction Problem [97]. The advantage of the constraint-based approach, is that trade-offs may be made over the set of all interoperation vulnerabilities that occur as a result of composing the individually secure access control systems, in reasonable time [19].
The cascade vulnerability problem [99] is concerned with secure interoperation in networks of multilevel secure systems. The interconnection may be between systems accredited with different levels of risk, and a cascade vulnerability occurs when confidentiality requirements are threatened, whereby an attacker "can take advantage of network connections to compromise information across a range of security levels that is greater than the accreditation range of any of the component systems he must defeat to do so" [99]. This is similar to the problem of security violation due to indirect paths considered in [70]. Bistarelli et at. [20] propose a constraint-based approach to model, detect and eliminate the cascade vulnerability problem in an arbitrary multilevel secure network. Cascading network paths are detected and removed by breaking a minimum number of system links in polynomial time.
Denning [42] reported some of the earliest work on lattice-based models for secure information flow in systems. An information flow policy is concerned with the flow of information between the different security classes in a system, and the information flow policy in [42] consists of the finite set of security classes, a binary ordering between security classes in terms of a "can flow" relation, and a binary class combining (join) operator. Denning demonstrated that under certain axioms, an information flow policy forms a finite lattice structure.
Jacob [77] considered the refinement of systems. It is shown how different refinement relations can be used to capture different kinds of system properties. When one system refines another, it is said to be "no worse with respect to some property of interest" [77], corresponding to one definition of refinement from [7] as "an added development or improvement". However in [77], the notion of refinement does not imply one system is better than another, only no worse.
Foley [56] reinterprets the notion of refinement [77] for refinement of policy. In contrast to [42], an information flow policy is defined as a reflexive relation, whereby details about system entities are encoded along with their security classes. The policy ordering relation captures the property of restrictiveness, and when one policy refines another, the former is said to be "no less restrictive" [56] than the latter. Foley [56] to allow for specifying and reasoning over integrity policies. The proposed approach extends the Clark-Wilson (CW) integrity model [32] to allow for dynamic separation of duty. The policy model forms a lattice under refinement with a lowest upper bound operator for policies. The theory of reflexive relations is extended to include ratings in [58], such that there is a degree of confidence that a given policy is being upheld. The model is used to reason about a problem related to synchronizing devices that is similar to the cascade vulnerability problem. However, Foley envisions that optimally eliminating the cascading paths using the proposed approach is NP-complete, similar to the graph-based approach taken in [70] for the optimal elimination of interoperation vulnerabilities in access control systems. This is in contrast to the later approach in [20] where cascading paths can be eliminated in polynomial time. Zhao and Bellovin [160,161] propose a policy algebra framework for packetfilter firewalls. The framework defines operators for addition, conjunction, subtraction, and summation, over rules and policies. Cost and risk functions associated with policy enforcement are also specified. The proposed approach allows for the detection of conflicts that arise as a result of composition, however, it does not allow for preventing them. Instead, the authors propose a choice of conflict resolution policies be presented to the administrator, who then decides if an access should be granted or denied by considering options such as, for example, the most-specific rule approach [90] implemented as a decorrelation algorithm, or by applying the target action of the first matching rule [131].

Discussion
A firewall is an important network security mechanism, however, the effectiveness of a firewall is hampered by how well its policy is configured. There is a rich literature of work on detecting and resolving anomalies in firewall policy configurations. However, in general, research such as [1,5,6,30,35,73,159] is focused on the conventional five-tuple firewall rule with a binary target action of allow or deny, and with the exception of [23,38,53,66], work in this area has been focused on anomalies in packet-filter policies only. The extent as to what can be synthesized from a high-level specification language suffers from similar shortcomings, and the approaches taken by [13,39,71,72] are only applicable to packet-filter firewalls. Querying a policy configuration is also limited by the fil- ter condition attributes and rule target actions that can be specified in the query language, and with the exception of [52,93], research in this area been focused on packet-filter policies. The query-based approach is further limited by the ability of the administrator to construct useful queries. Firewall policies may need to be reconfigured for highly dynamic environments, and ad-hoc updates are often carried out manually. Policy updates may result in a configuration that is not consistent with a network security policy; the updates may lead to a configuration that is overly-restrictive, thereby denying legitimate access, or the updated configuration may be overly-permissive, resulting in unwanted packets traversing the firewall and potentially resulting in security violations similar to those considered in Section 2. 4. The focus in this dissertation is on firewall policy composition, and we argue that there is a need for a consistent means of composing firewall policies, such that the result is anomalyfree and composition upholds the security requirements of each policy involved. Lattice-based access control models are fundamental components of computer security and provide consistent composition operators for a variety of access control policy models [56,78,121,122]. In this dissertation, we reinterpret the notion of refinement [56,57,77] and develop a lattice-based policy model for firewalls.

Attributes of a Linux-based Firewall
The objective of this chapter is to develop a formal model for various filter condition attributes of the Linux iptables firewall. The attributes will be used to construct packet-rules for the FW 0 firewall policy algebra in Chapter 4, and extended to construct range-based rules for the FW 1 algebra in Chapter 5. The chapter is organised as follows. Section 3.1 provides an overview of Linux Netfilter and iptables. Section 3.2 explores iptables-rule constructs and gives a formal definition for filter condition attributes for use in FW 0 . Filter condition attributes for IPs/ports and the TCP, UDP and ICMP protocols are developed. Additional filtering specifications are also defined.

Linux iptables
Netfilter [68,138] is a framework that enables packet filtering, Network Address Translation (NAT) and packet mangling within the Linux kernel. A front-end command-line utility called iptables is used to construct firewall rules that instruct Netfilter how to interpret packets. As a firewall, iptables has stateless, stateful and Deep Packet Inspection (DPI) filtering capabilities.
An iptables (firewall, NAT or mangle) rule requires the specification of a table, a chain, the accompanying filter conditions on packet fields that must be matched and an associated target action. With iptables, there are four tables: filter, nat, mangle and raw. A table is a set of chains and it defines the global context for common packet handling functionality. For example, the filter table defines the set for firewall rules, while the nat table defines the set of rules concerned with NAT. A chain is a set of rules that define the local context within a table.
Rules within a chain are applied to the context defined both by the chain itself and the particular table. This dissertation focuses on the firewalling aspects of iptables, that is, the filter table. There are three built-in chains defined within the filter table that govern traffic being routed to (INPUT chain), from (OUTPUT chain) and beyond the firewall itself (FORWARD chain). The following example demonstrates the specification of a firewall rule using the iptables command-line syntax.  table is the default table for iptables, therefore it is not necessary to include the (-t filter) option when specifying a firewall rule.

Encoding iptables Filter Condition Attributes
In this section, the core filter condition attributes used to define firewall rules in the FW 0 firewall algebra are formally specified. Attributes are derived from the Data Link, Network, Transport and Application Layers of the OSI model. Additional filter condition attributes are also defined. Attribute definitions are extended in Chapter 5 to specify range-based filter conditions used to define firewall rules in the FW 1 policy algebra.

Data Link Layer Filtering
Packet-type. iptables allows the specification of firewall rules that filter the type of packet at the Data Link layer of the OSI model.

Example 2
The following iptables rule specifies that inbound (INPUT) TCP broadcast packets (-p tcp --pkt-type broadcast) destined for the IP address Let PktTpe be the set of Data Link-layer packet types, whereby:  Let basic type MAC be the set of all MAC addresses. We define: For simplicity, we do not consider how the values of MAC may be constructed, other than to assume that the usual human-readable notation can be used, such as 00:0F:EA:91:04:08 and 00:0F:EA:91:04:09 ∈ MAC .

Network Layer Filtering
IP Addresses. iptables allows the specification of firewall rules that filter the source/destination IP address of a network packet. For simplicity, we consider only the IPv4 address range, as a firewall rule with an IPv6 address filter condition attribute must be specified using ip6tables; the equivalent IPv6 firewall [68].  4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

iptables -
In this dissertation, IP addresses as encoded using natural numbers, as there is a logical mapping from IPs to natural numbers, and a logical mapping from IP ranges and CIDR blocks to intervals of N. This is done for ease of exposition, and to exploit the natural ordering of ≤ over N. Let IP be the set of all IPv4 addresses, given as the set of all natural numbers from 0 . . maxIP, whereby: 1 Packet header illustrations in this dissertation are adaptations of the TikZ source at [140].

Encoding iptables Filter Condition Attributes
The Internet Control Message Protocol, ICMP, is an OSI Network layer protocol. It is used by networked devices to relay error/query messages [108]. iptables allows for filtering by ICMP Type and Code. iptables Let TypesCodes be the set of all valid ICMP Type/Code pairs, as detailed in [110]. Most Type/Code pairs i, j ∈ N are given as (i, j) ∈ TypesCodes, for example, (8,0) is an ICMP Echo Request, however, some ICMP Types i ∈ N; for example, Type 19 (reserved for security), have no ICMP Code, and are given as Note, for ease of exposition we use syntactic sugar in the definition of TypesCodes as a free-type. We define:

Transport Layer Filtering
Network Ports. A network port is a communication end-point used by the Transport layer protocols (for example, TCP/UDP) of the OSI model. A port is always associated with an IP address. The Internet Assigned Numbers Authority (IANA), maintains the official assignments of port numbers for specific uses/services [151]. For example, 22 is used for SSH and 80 is used for HTTP.

Example 6
The following iptables rule specifies that inbound (

Encoding iptables Filter Condition Attributes
Let UDP define the set of packet values for the UDP protocol; whereby 1 signifies that a packet is using UDP or 0 signifies it is not. We define: The Transmission Control Protocol, TCP, is a connection-oriented OSI Transport layer protocol, that provides reliable, ordered, and error-checked packets between communicating network principals [109].  4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31   0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29   iptables allows for TCP firewall rules to be constructed using a pair of TCP flags specifications. The first, specifies the flags that are to be examined in a packet-header, and the second specifies the flags that are to be set in a packetheader, these are the mask and comp values for a TCP packet [68].

Example 8
The following iptables rule specifies that inbound (INPUT) TCP packets (-p tcp) with all flags set (a TCP XMAS port-scan pattern [91]), and all flags to be examined by the firewall (--tcp-flags ALL, ALL), originating from source IP address 0.
The following iptables rules enable the TCP three-way handshake; by permitting HTTP traffic from IP address 0. 0 Let Flags be the set of TCP flags filterable in an iptables rule (as a mask or a comp specification), whereby: and let Flag Spec be the set of all (mask, comp) pairs, we define:

Application Layer Filtering
Layer 7 Protocol Filtering. iptables allows for constructing firewall rules that filter certain protocols at the Application Layer of the OSI model [86].

Example 9
The following iptables rule specifies that inbound (INPUT) SSH packets (-m layer7 --l7proto ssh), originating from the source IP address Let Proto L 7 be the set of all OSI Application-layer protocols recognised by iptables [86]. Note, for ease of exposition we use syntactic sugar in the definition

Encoding iptables Filter Condition Attributes
of Proto L 7 as a free-type. We define: The Layer 7 protocol definitions specify how these protocol names correspond to regular expressions that are matched by Netfilter on the packet Application Layer data. For example, the name smb corresponds to the signature [85]: Packet-owner/creator Filtering. For locally generated packets; iptables allows filtering by various characteristics of the packet creator through the owner module. Filtering is applied to the OUTPUT chain of the filter table [146].
Let UID be the set of 32-Bit UIDs for a Linux system, given as the set of all natural numbers from 0 . . maxUID. We define: Similarly, let GID be the set of 32-Bit GIDs for a Linux system, given as the set of all natural numbers from 0 . . maxGID, whereby:

Additional Filtering Specifications
State. When filtering via a stateful firewall, the firewall's state-table automatically manages TCP flags [152]. The iptables conntrack module defines the state extension [146]. The state extension allows access to the connection tracking state for a packet. The notion of state in iptables is an abstraction, where the literals NEW, ESTABLISHED, RELATED, INVALID and UNTRACKED, signify user-land 'states' that packets within tracked connections can be related to. This is enabled by the conntrack framework within the Linux kernel.

Example 11
The previous four iptables rules from Example 8 that enable the TCP three-way handshake using TCP Flags may be rewritten as follows. Note, these two rules also allow for the TCP connection teardown.

Encoding iptables Filter Condition Attributes
An advantage of specifying state in this way, is that it allows end-users to construct firewall rules that abstract from the low-level operational details of the specified network protocol. The NEW state signifies the packet has started a new connection, or is otherwise associated with a connection that has not seen packets in both directions. An ESTABLISHED state signifies the packet is associated with a connection which has seen packets in both directions. The state RELATED signifies the packet is starting a new connection, but is associated with an existing connection, for example, an FTP data transfer, or an ICMP error. The INVALID state signifies that the packet is associated with no known connection. A state of UNTRACKED signifies that the packet is not tracked [68].
Let State be the set of connection tracking states for a packet/connection. We define: In this dissertation, the proposed model of state is based on the expressiveness of the iptables state module. A limitation of the approach, is that it is not possible to reason about complex stateful anomalies, such as those considered in [66], where a connection-oriented protocol is modelled using general automata with the permitted protocol states and transitions encoded.
Time-based Filtering. iptables allows for a filtering decision to be made if the packet arrival time/date is within a given range. The possible time range expressible in a rule is 1970-01-01T00:00:00 to 2038-01-19T04:17:07 [49], and is specified in ISO 8601 "T" notation [76]. , where T (date) is a function that converts a date specified in "T" notation to a Unix timestamp. We define: maxTime == T (2038-01-19T04:17:07) When reasoning about stateful/time-based policy anomalies in later chapters, we use only the anomaly definitions from [5,6], explored in Chapter 2 Section 2. 3.1, that consider redundancy, shadowing, etc., and do not consider more complex stateful anomalies, such as those considered in [66].
Network Interfaces and Direction-oriented Filtering. iptables allows for a filtering decision to be made with respect to the interface a network packet is arriving at/leaving through. Let basic type IFACE be the set of all interfaces on a machine, where for simplicity, we assume elements of IFACE resemble lo, eth0, wlan0, tun0, etc. We define: Network traffic can be inbound or outbond on an interface. Direction-oriented filtering is defined as Dir, whereby: The following example demonstrates the enforcement of a default deny policy on the INPUT, OUTPUT AND FORWARD chains, respectively.

Example 14
The following iptables rules specify that all network traffic not matched by a rule on the INPUT, OUTPUT AND FORWARD chains of the filter table be denied.

iptables -P INPUT -j DROP
iptables -P OUTPUT -j DROP iptables -P FORWARD -j DROP

Discussion
In this chapter, firewall rule filter condition attributes for IP addresses, ports, and the TCP, UDP and ICMP protocols are defined. The specification includes definitions for TCP flags and ICMP Types/Codes. A notion of state has been encoded also. For the OSI Data Link Layer, attributes for packet-type and MAC address are defined. At the OSI Application Layer, filter condition attributes for Linux UIDs and GIDs, and the various application-layer protocols recognised by iptables are specified. Additional filtering specifications have also been developed. In Chapter 4, we use these filter condition attributes to develop a formal model of filtering constraints for the FW 0 firewall policy algebra. Policies in the FW 0 algebra are defined in terms of constraints on individual IPs, ports, protocols and the additional filter condition attributes defined in this chapter. In Chapter 5, range-based versions of the filter condition attributes defined in this chapter are formally specified for use in the FW 1 firewall policy algebra.

Chapter 4
The FW 0 Policy Model The objective of this chapter is to develop a firewall policy algebra FW 0 , for constructing and reasoning over anomaly-free policies. Firewall rules are constructed using the filter condition attributes defined in Chapter 3. FW 0 defines a simple model of iptables rules that do not consider range-based filter condition attributes; the purpose of developing FW 0 is to demonstrate the utility of building such an algebra. In Chapter 5, the policy algebra FW 1 defines a firewall policy in terms of rules constraining range-based filter conditions. The FW 0 policy algebra in this chapter is an extended version of the algebra in [62]. The chapter is organised as follows. In Section 4.1 the packet-based filter condition attribute datatypes are defined. Section 4.2 defines the FW 0 firewall policy algebra and Section 4.3 demonstrates how the algebra can be used in practice to detect anomalies in firewall policies.

Packet Attribute Datatypes
In this section, filter condition attribute datatypes for the FW 0 policy model are defined. Examples of each attribute instance are given, and these are used to construct network packets at the end of this section for use in the running example given in Section 4.2.

OSI Layer 2.
Let L 2 define the set of all attributes of interest at Layer 2 of the OSI model, given as the set of all tuples over the set of all packet-types (PktTpe) and the set of all MAC address (MAC ). We define: , the set of all Linux UIDs (UID) and the set of all Linux GIDs (GID). We define: The Application Layer attributes l 7A , l 7B , l 7C ∈ L 7 are given as: The Stateful/Protocol Datatype. Let Protocol define the set of all stateful protocols, given as the set of all four-tuples over TCP flags (Flag Spec ), the UDP protocol (UDP), the set of all ICMP Type/Codes (TypesCodes), and the set of all connection tracking states for a packet/connection (State). We define: The attribute instance proto A ∈ Protocol is given as: Additional Filtering Specifications. Let AdditionalFC define the set of all additional filter condition attributes of interest, given as the set of all four-tuples over the set of all Unix timestamps expressible using ISO 8601 "T" notation in an iptables rule (Time), the set of all network interfaces (IFACE), the set of directions for direction-oriented filtering (Dir) and the set of iptables chains (Chain). Network Packets. A network packet header is a eight-tuple (s, sprt, d, dprt, proto, l 2 , l 7 , a), representing network traffic originating from source IP address s, with source port number sprt, destined for destination IP address d, with destination port number dprt, using a stateful protocol proto, with additional Layer 2 attributes l 2 , additional Layer 7 attributes l 7 and additional filtering specifications a. Let Packet define the set of all packet headers: The packets http 1 , ftp 1 , tel 1 ∈ Packet are given as:

The FW 0 Firewall Algebra
In this section, an algebra for constructing and reasoning about anomaly-free firewall policies is defined. We focus on stateful and stateless firewall policies that are defined in terms of constraints on individual IP addresses, ports, TCP, UDP and ICMP protocols, and additional filter condition attributes. A firewall policy defines the packets that may be allowed or denied by a firewall. Let Policy 0 define the set of all firewall policies, whereby: A firewall policy (A, D) ∈ Policy 0 defines that a packet p ∈ A should be allowed by the firewall, while a packet p ∈ D should be denied by the firewall. Given Thus, we have for all P ∈ Policy 0 then P = (allow(P), deny(P)). Proof Given a policy (A, D) ∈ Policy 0 , as A and D are sets of individual packets, then A has no redundancy and D has no redundancy. Therefore, all packets allowed by the policy are distinct, as are all packets that are denied by the policy.
Given that A and D are disjoint, then a policy P has no shadowing.
Given that all packets in P are distinct and P has no shadowing, then P has no generalisations and P has no correlations. Therefore, as P has no redundancy/shadowing/generalisation/correlation, then Policy 0 defines the set of anomaly-free policies.
Note that (A, D) ∈ Policy 0 need not partition Packet: the allow and deny sets define the packets to which the policy explicitly applies and an implicit default decision is applied for those packets in Packet \ (A ∪ D). For the purposes of modeling iptables firewall policies it is sufficient to assume default deny, though we observe that the FW 0 algebra can also be used to reason about default allow firewall policies.

Example 6
Consider the following network security policy that we will refer to throughout this section, where traffic from an administrators subnet is permitted access to a HTTP and a FTP server, and all Telnet traffic to the HTTP server is to be denied. The packets that are used to define this policy include http 1 , ftp 1 , tel 1 ∈ Packet from Example 5. A firewall policy Admin 1 ∈ Policy 0 allows the HTTP and FTP packets while denying the Telnet traffic: Policy Refinement. An ordering can be defined over firewall policies, whereby given P, Q ∈ Policy 0 then P Q means that P is no less restrictive than Q, that is, any packet that is denied by Q is denied by P. Intuitively, policy P is considered to be a safe replacement for policy Q in the sense of [56,57,77], and any firewall that enforces policy Q can be reconfigured to enforce policy P without any loss of security. The safe replacement ordering is defined as follows. : Formally, P Q iff every packet allowed by P is allowed by Q and that any packet explicitly denied by Q is also explicitly denied by P. Note that in this definition we distinguish between packets explicitly denied in the policy versus packets implicitly denied by default. This means that, everything else being equal, a policy that explicitly denies a packet is considered more restrictive than a policy that relies on the implicit default-deny for the same packet; we shall see that this distinction is important when safely extending policies with new rules. Safe replacement is defined as the Cartesian product of subset orderings over allow and deny sets, and it therefore follows that Policy 0 is a partially ordered set under . ⊥ and define the most restrictive and least restrictive policies, that is, for any P ∈ Policy 0 we have ⊥ P . Thus, for example, any firewall enforcing a policy P can be safely reconfigured to enforce the (not very useful) firewall policy ⊥. Proof The powerset ordering of packets is a lattice under subset, the Cartesian product is a lattice under the definitions of glb and lub, therefore, FW 0 is a lattice.

Example 7
Consider, an update to the network security policy Admin 1 , where SSH traffic is to be denied to the HTTP and FTP servers from a malicious IP address. Some packets to be considered as part of this access restriction are mal 1 , mal 2 ∈ Packet, whereby: A firewall policy Admin 2 ∈ Policy 0 extends the previous policy Admin 1 to deny these packets from this malicious host: We observe that Admin 2 safely replaces Admin 1 : Admin 2 Admin 1 , but Admin 1 is not a safe replacement for Admin 2 .
Policy Intersection. Under this ordering, the meet, or intersection P Q, of two firewall policies P and Q is defined as the policy that denies any packet that is explicitly denied by either P or Q, but allows packets that are allowed by both P and Q. Intuitively, this means that if a firewall is required to enforce both policies P and Q then it can be configured to enforce the policy P Q, since P Q is a safe replacement for both P and Q, that is (P Q) P and (P Q) Q. Thus, P Q provides the 'best'/least restrictive safe replacement for both P and Q under .
The policy Admin 3 permits the administrators SSH access to the HTTP and FTP servers, and denies all network traffic from the client destined for a malicious IP, according to packets ssh 1 , ssh 2 and mal 3 ∈ Packet.
Policy Union. The join of two firewall policies P and Q is defined as the policy that allows any packet allowed by either P or Q, but denies packets that are explicitly denied by both P and Q. For example, we have Admin 2 Admin 3 = ({{http 1 , ftp 1 , ssh 1 , ssh 2 }}, ∅). Intuitively, this means that a firewall that is required to enforce either policy P or Q can be safely configured to enforce the policy P Q since provides a lowest upper bound operator, and we have P (P Q) and Q (P Q).

Lattice Properties of the FW 0 Algebra
The ordering relation is a non-strict partial order over Policy 0 ; given the properties of properties of reflexivity, transitivity and antisymmetry [18].
The ordering relation is reflexive, as any policy should be a safe replacement for itself. If for any P ∈ Policy 0 , P P did not hold, then an inconsistency would exist. Transitivity follows from a similar requirement, where for any P, Q, R ∈ Policy 0 , if P safely replaces Q and Q safely replaces R, then P should also safely replace R. Antisymmetry follows from the assumption of irredundant policies, where if P is a safe replacement for Q and Q is a safe replacement for P, then one of them is unnecessary.  (Packet, ∅) We observe that the order in which the operations are performed does not change the outcome of the operation.
We observe that for all P ∈ Policy 0 , P is idempotent with respect to and .
∀ FW 0 ; P : Policy 0 • P P = P ∧ P P = P Identity Laws. We observe that FW 0 is a bounded lattice/algebraic structure, such that (Policy, , ) is a lattice, ⊥ is the identity element for the join operation , and is the identity element for the meet operation .

Constructing Firewall Policies
The lattice of policies FW 0 provides us with an algebra for constructing and interpreting firewall polices. The following constructor functions are used to build primitive policies. Given a set of packets A then (Allow A) is a policy that allows packets in A, and (Deny D) is a policy that explicitly denies packets in D.

Allow,
This provides what we refer to as a weak interpretation of allow and deny: packets that are not explicitly mentioned in parameter S are default-deny and are therefore not specified in the deny set of the policy. The following provides us with a strong interpretation for these constructors: In this case (Allow + A) allows packets specified in A while explicitly denying all other packets, and (Deny + D) denies packets specified in D while allowing all other packets. A firewall policy P ∈ Policy 0 can be decomposed into its corresponding allow and deny policies and re-constructed using the algebra.

Lemma 4.2.3 Given A, D ∈ P Packet, then:
Example 9 An alternative specification for policy Admin 3 is:

Reasoning About Policies in Practice
Sequential Composition. A firewall policy is conventionally constructed as a sequence of rules, whereby for a given network packet, the decision to allow or

Reasoning About Policies in Practice
deny the packet is checked against each policy rule, starting from the first, in sequence, and the first rule that matches gives the result that is returned. The algebra FW 0 can be extended to include a similar form of sequential composition of policies. The policy constructions in Section 4.2.2 can be regarded as representing the individual rules of a conventional firewall policy.
Let (Allow A) o 9 Q denote a sequential composition of an allow rule (Allow A) with policy Q, with the interpretation that a packet that is matched by A is allowed; if it does not match A then policy Q is enforced. The resulting policy either: allows packets in A (and denies all other packets), or allows/denies packets according to policy Q. This is defined as: which is as expected. A similar definition can be provided for the sequential composition (Deny D) o 9 Q, whereby a packet that is matched by D is denied; if it does not match D then policy Q is enforced. This is defined as: While in practice it is usual to write a firewall policy in terms of many constructions of allow and deny rules, in principle, any firewall policy P ∈ Policy 0 can be defined in terms of one allow policy (Allow allow(P)) and one deny policy (Deny deny(P)) and since the allow and deny sets of P are disjoint we have

Reasoning About Policies in Practice
and Admin 3 . We have: A firewall rule specifies a set of packets and an associated target action. Let Rule define the set of all packet-based firewall rules, whereby: We define a rule interpretation function I as: A firewall policy is defined as a sequence of rules r 1 , r 2 , . ., r n , for r i ∈ Rule, and is encoded in the policy algebra as I(r 1 ) o 9 I(r 2 ) o 9 . . o 9 I(r n ).
Policy Negation. The policy negation of P ∈ Policy 0 allows packets explicitly denied by P and explicitly denies packets allowed by P. We define:

Reasoning About Policies in Practice
Example 11 The negation of policy Admin 4 is: From this definition it follows that (not P) is simply (deny (P), allow (P)) and thus not (Deny D) = (Allow D) and not (Allow A) = (Deny A). Note however, that in general policy negation does not define a complement operator in the algebra Policy 0 , that is, it not necessarily the case that (P not P) = and (P not P) = ⊥.

Example 12
Given the firewall policy Admin 4 , then: = and: However, the sub-lattice of policies with allow and deny sets that exactly partition the same set S ⊆ Packet has policy negation as complement (allow (P) ∪ deny (P) = S for all P in the sub-lattice).

Policy Projection.
Useful policies can be constructed through filtering a policy by a given filter condition attribute. The projection operators @ u and @ d filter a policy by a set of IP addresses. Firstly, let S(S ) give the set of all packets that have s ∈ S as source IP, and similarly D(D) gives all packets with a destination IP address d ∈ D.
For a policy P and a set of IP addresses S , P@ u S is the upstream projection of P, and consists of the allow and deny packets from P where each packet has as source IP some member of S . Similarly, P@ d S is the downstream projection of P, it consists of the allow and deny packets from P whereby each packet has as destination IP some member of S .
Example 13 Suppose there is a requirement to specify all the packets allowed/denied to the HTTP server by the policy Admin 4 , then we have: where 10 is the IP address of the HTTP server.

Anomaly Detection
A firewall policy is conventionally constructed as a sequence of order-dependent rules, and when a network packet matches with two or more policy rules, the policy is anomalous [5,6,35]. By definition, the allow and deny sets of some P ∈ Policy 0 are disjoint, therefore P is anomaly-free by construction. We can however define anomalies using the algebra; by considering how a policy changes when composed with other policies.

Redundancy.
A policy P is redundant given policy Q if their composition results in no difference between the resulting policy and Q, in particular, if: 4. The FW 0 Policy Model

Reasoning About Policies in Practice
and, those packets shadowed in Q are a proper subset of Q's denies: not (Allow(allow (P)) Allow(deny (Q))) = Deny(deny (Q)) whereby: Similarly, A generalisation anomaly exists between P and Q if some of the packets denied by P shadow some of the packets allowed by Q, in particular, if: and, those packets shadowed in Q are a proper subset of Q's allows: not (Deny(deny (P)) Deny(allow (Q))) = Allow(allow (Q)) as: not (Deny(deny (P)) Deny(allow (Q))) = (deny (P) ∩ allow (Q), ∅) Inter-policy Anomalies. Anomalies can also occur between the different policies of distributed firewall configurations [6]. In the following, assume that P is a policy on an upstream firewall and Q is a policy on a downstream firewall.
Redundancy. An inter-redundancy anomaly exists between policies P and Q if some part of Q is redundant to some part of P, whereby the target action of the redundant filter conditions is deny. Given the set of packets A denied by P, and the set of packets B denied by Q, then there exists an inter-redundancy between P and Q, if:

Discussion
Shadowing. An inter-shadowing anomaly exists between policies P and Q if some part of Q's allows are shadowed by some part of P's denies. Given a set of packets A denied by P, and the set of packets B allowed by Q, then there is an inter-shadowing anomaly between P and Q, if: Further definitions may also be given for shadowing. For example, we have that some of the packets denied by a policy P shadow some of the packets allowed by a policy Q if: Spuriousness. An inter-spuriousness anomaly exists between policies P and Q if some part of Q's denies are shadowed by some part of P's allows. Given some set of packets A allowed by P, and some set of packets B denied by Q, then there exists an inter-spuriousness anomaly between P and Q, if: A further definition may also be given for spuriousness, whereby some of the packets allowed by a policy P shadow some of the packets denied by a policy Q. We have an inter-spuriousness anomaly from an upstream policy P to a downstream policy Q, if: Allow(allow (P)) Allow(deny (Q)) = (∅, ∅)

Discussion
In this chapter, a policy algebra FW 0 is defined whereby firewall policies can be specified and reasoned about. At the heart of this algebra is the notion of safe replacement, that is, whether it is secure to replace one firewall policy by another. The set of policies form a lattice under safe replacement and this enables consistent operators for safe composition to be defined. Policies in this lattice are anomaly-free by construction, and thus, composition under greatest lower and lowest upper bound operators preserves anomaly-freedom. A policy sequential composition operator is also proposed that can be used to interpret firewall policies defined more conventionally as sequences of firewall rules. The algebra can be used to characterize anomalies, such as redundancy and shadowing, that arise from policy composition.
The proposed algebra FW 0 provides a semantics for firewall policies. While useful for the purposes of reasoning, it is not efficient to naïvely implement the algebra since a policy is defined in terms of rules constraining individual IP addresses and ports. For example, a policy constraining access from a subnet range 192. 168.*.* involves more than 65K individual packet rules, whatever about the impact of combining these with further constraints on destination IPs and ports. In practice, firewall rules are defined in terms of ranges of IP addresses and ports. Extending the policy algebra to include ranges is non-trivial, as is illustrated using the following example.

Example 16
Given a policy defined in terms of (allow and deny) sets of source/destination IP address and port ranges, whereby the policy has no deny constraints (∅) and has one accept rule that permits any packet ) (ranges of source and destination IP addresses and ports). A second policy is similarly defined: In composing these policies under a lowest-upper-bound style operation one cannot simply take a union of the sets of intervals as in some cases they may coalesce and in other cases they may partition into a number of disjoint intervals. The composition of the P 1 and P 2 policies is as follows: The policy algebra FW 1 , presented in Chapter 5, defines a firewall policy in terms of rules constraining ranges of IP addresses and ports.

Chapter 5
The FW 1 Policy Model The objective of this chapter is to develop a firewall policy algebra FW 1 , for constructing and reasoning over anomaly-free policies. Firewall rules comprise range-based filter condition attributes. The FW 1 policy algebra is an extended version of the algebra in [101]. The chapter is organised as follows. Section 5.1 introduces the notion of adjacency, which is at the heart of reasoning about/composing firewall rules that involve range-based attributes, datatypes for firewall rule attributes and firewall rulesets are also defined. In Section 5.2 the attribute definitions given in Chapter 3 are extended for FW 1 filter conditions. Section 5.3 defines the FW 1 firewall policy algebra, and in Section 5.4 we show how FW 1 can be used to reason about firewall policies in practice.

A Theory of Adjacency
Range-based filter condition attributes (for example, IPs/ports) have logical mappings to intervals of N. For example, the port range that includes all ports from SSH upto and including HTTP can be written as the interval [22 . . 80].
Example 1 Consider, as part of a running example, a system that is capable of enforcing firewall rules whereby the filter condition attribute for the rules is a destination port range only. A rule that allowed all ports from SSH to HTTP would be:

A Theory of Adjacency
where i is the index of the rule in the policy, [22 . . 80] is the required port range, and allow means that network traffic matching this pattern be permitted traversal of the firewall. Suppose we had a second rule, that specifies allow everything from Quote Of The Day (QOTD) up to and including FTP Control, then: specifies that for the rule at index j; the required port range [17 . . 21] is allowed.
Intuitively we can see that the port ranges for the rules at index i and index j are adjacent, and we may want to join rule i and rule j into a single firewall rule that looks like: This notion of adjacency becomes more complex when we consider comparing/composing firewall rules comprising two or more filter condition attributes.

The Adjacency Specification
In this section we define the filter condition attribute relationships of adjacency, disjointness and subsumption. These can be applied to any ordered set, not just number intervals. These relationships are at the heart of adjacency, and ultimately the FW 1 algebra. Let IV[min, max] be the set of all intervals on the natural numbers, from min up to and including max. Intervals are defined by their corresponding sets.
Example 2 For ease of exposition and when no ambiguity arises, we may write an interval as a pair [⊥ . . ], rather than by the set it defines.

A Theory of Adjacency
Port define the set of all possible network port ranges, whereby: Adjacency. The relation ( ) defines adjacency over any ordered set. Adjacency is a general notion that is not limited to N. We generalize adjacency to any attribute of generic type X , whereby for a, b ∈ X , if a X b, then a and b are adjacent in the set X . The property of reflexivity is required as any a ∈ X should be adjacent to itself, that is; if for any a, that a X a did not hold, then an inconsistency would exist. Symmetry follows from a similar requirement, where for a, b ∈ X , if a is adjacent to b in X , then b must also be adjacent to a in X . The following schema defines a generic adjacency relation that can be instantiated for adjacency over different datatypes.
[X ] : Given a set S ∈ P X , then the transitive closure of the adjacency relation for elements in S is defined as follows.
[X ] Interval Adjacency. Two intervals on the set of natural numbers are adjacent if their union defines a single interval. For a given maximum value max ∈ N, we define: Set Adjacency. For a generic type X , and sets S , T ∈ P X , then S and T are adjacent, as S ∪ T ∈ P X . We define: The relation ( | ) is used to define the notion of disjointness over any ordered set. Given a, b ∈ X , then a | X b denotes a and b are disjoint in X . The property of irreflexivity is required, as a cannot be disjoint from itself, that is; if for any a, that ¬ (a | X a) did not hold, then an inconsistency would exist. Symmetry is also required for consistency, as if a and b are disjoint in X , then b and a must be disjoint in X also. The following schema specification defines a generic disjointness relation that can be instantiated for disjointness over different datatypes.
[X ] Interval Disjointness. Two intervals are disjoint if they don't intersect. For a given maximum value max ∈ N, we define: Set Disjointness. Two sets are disjoint if they don't intersect. We define: Reflexivity is required, as any a must cover itself. Transitivity follows from a similar requirement, where for a, b, c ∈ X , if a covers b and b covers c, then a must cover c. Antisymmetry follows from the assumption of irredundant elements, where if a covers b and b covers a then one of them is unnecessary [42]. The properties of reflexivity, transitivity and antisymmetry define X ← as a non-strict partial order over X [18]. The following schema defines a generic subsumption relation that can be instantiated for subsumption over different datatypes.
Some subsumption orderings (for example, subset) may form a lattice with glb ∩ X and lub ∪ X operators for values in X .
Number Subsumption. For a, b ∈ N then b covers a if a equals b. We define: The equality relation is both symmetric and antisymmetric, and defines both an equivalence relation and a non-strict partial order [118]. Thus, a N ← b denotes that b subsumes/covers a.

Set Subsumption.
The definition for set subsumption is as expected, we define: For a generic type X , and S ∈ P X , then the flattening function S gives the cover-set for the elements of S , whereby the cover-set of S has no subsumption. We define: : P X → P X We define a difference operator for S , T ∈ P X , where S \ P X T gives the relative compliment of T in S . That is, everything that is of type X that is covered in S , but not in T . We define this as:

The Adjacency Datatype
For a generic type X , the Adjacency datatype α[X ], is the set of all closed subsets of X partitioned by adjacency.
The ordering relation ≤ is a non-strict partial order over α[X ].
Proof For S , T ∈ α[X ], then S ≤ T means that T covers S , that is, every a ∈ S is covered by some b ∈ T . The ordering relation ≤, is defined as a subsumption ordering/an antisymmetric preorder, where the properties of reflexivity, transitivity and antisymmetry hold for ≤ over α[X ] as ( X ← ) is a non-strict partial order for elements of type X . We have: The elements ⊥, ∈ α[X ] define the least and greatest bounds, respectively, on α[X ], where ⊥ is the unique minimal element that is covered by all elements, and is the unique maximal element that covers all other elements. We have:  Proof This follows from the definition of ≤ as a subsumption ordering/an antisymmetric preorder, the properties of not, the definition of the meet as the cover-set for the generalized union of all Adjacency-sets, where for S , T ∈ α[X ], each element of (S ⊗ T ) is covered by an element in both S and T , and the definition of the join as the generalized intersection of all Adjacency-sets, where each element of (S ⊕ T ) covers an element in either S or T .

The Duplet Datatype
The notion of adjacency becomes more complex when we consider comparing/composing firewall rules comprising two or more filter condition attributes. When joining adjacent firewall rules, in some cases the rules may coalesce and in other cases they may partition into a number of disjoint rules.

Example 10
Recall from Example 1, the firewall system that supports only destination port range filter conditions. Suppose we want to extend the expressiveness of the policy rules for this system to include a definition for destination If we consider the attributes separately, we observe that the IP range in p 1 is adjacent to the IP range in p 2 , and the port ranges in p 1 and p 2 are also adjacent. However, in composing p 1 and p 2 under a lowest-upper-bound style operation one cannot simply take a union of the sets of intervals to be the IP/port range pair: , as this results in an overly permissive policy, given that network traffic is permitted to IP 1 on port 4, and to IP 4 on port 1 as a result of composition. Conversely, this would result in an overly restrictive policy if we were composing deny rules.
If we consider how the join of p 1 and p 2 may be defined, whereby the desired result is the smallest number of non-adjacent rules that cover both p 1 and p 2 , then we can apply an adjacency-precedence to the IP ranges in p 1 and p 2 , and observe that the port ranges in p 1 and p 2 are not disjoint. We refer to this as the 1 st attribute major ordering, and the cover for p 1 and p 2 is given as: In this case, the result is a set of disjoint rules that exactly cover the IP/portrange pair constraints from p 1 and p 2 . The resulting operations are encoded in the matrix in

A Theory of Adjacency
We note, however, that instead, the adjacency-precedence may be applied to the second attribute, where in this case we observe that the port ranges in p 1 and p 2 are adjacent, and the IP ranges in p 1 and p 2 are not disjoint. We refer to this as a 2 nd attribute major ordering, and would therefore expect the set of disjoint rules that exactly cover the IP/port-range pair constraints from p 1 and p 2 to be: The operations for the 2 nd attribute major ordering the are encoded in the matrix in Table 5. 2. For the remainder of this dissertation, we consider firewall rule join in terms of the 1 st attribute major ordering. However, we also consider the join of rules where there is an adjacency in other than the first attribute, we refer to this type of adjacency as forward adjacency.

Duplets.
A duplet is an ordered pair, where the set of all duplets for generic types X , Y , is defined as δ[X , Y ], whereby:

A Theory of Adjacency
Proof Given the definition of δ[X , Y ] as the Cartesian product of X and Y , then if the ordering over X is a lattice and the ordering over Y is a lattice; it follows that δ[X , Y ] forms a lattice under the product order of X and Y .
Forward Adjacency. A pair of duplets are forward adjacent to each other if the attributes in the first coordinate are equal and the attributes in the second coordinate are adjacent. For (a 1 , b 1 ), (a 2 , b 2 ) ∈ δ[X , Y ], we define forward adjacency, whereby: , then these duplets are forward adjacent, as: are adjacent, if the attributes in the first coordinate are adjacent, and the attributes in the second coordinate are not disjoint, or a and b are forward adjacent. For (a 1 , b 1 Example 13 We have p 1 δ[IP Spec ,Prt Spec ] p 2 , since the IP ranges are adjacent and the port ranges are not disjoint. Duplet Disjointness. A pair of duplets are disjoint if the attributes in the first coordinate are disjoint, and/or the attributes in the second coordinate are disjoint. For (a 1 , b 1 ), (a 2 , b 2 ) ∈ δ[X , Y ], we define:

A Theory of Adjacency
Duplet Intersection. The definition for duplet intersection is defined as the intersection of the attributes in each coordinate under their respective orderings. For (a 1 , b 1 ), (a 2 , b 2 ) ∈ δ[X , Y ], we define: Example 15 For p 1 and p 2 , we have: The definition for duplet merge is defined as the union of the attributes in each coordinate under their respective orderings. For (a 1 , b 1 Example 16 For p 1 and p 2 , we have: , if a 1 covers a 2 in X , and b 1 covers b 2 in Y . Thus, we define duplet subsumption as:

Example 17
For p 1 and p 2 , we have: Precedence Subsumption. A precedence subsumption is defined for duplets, whereby we explicitly define subsumption orderings separately in each coordinate.

Reasoning About Firewall Policies Through
Refinement and Composition 5. The FW 1 Policy Model

A Theory of Adjacency
The relation ( → ) defines a general format for precedence subsumption over any ordered set. For a, b ∈ X , if a X → b, then a covers b by precedence in X . The properties of reflexivity, transitivity and antisymmetry define X → as a non-strict partial order over X [18]. The following schema defines a generic precedence subsumption relation that can be instantiated for precedence subsumption over different datatypes.
Thus, we define precedence subsumption as: , then a S is the set of all non-empty intersections of a with each value b ∈ S . We define:

Duplet Adjacency Ordering
In this section, an ordering is defined for Adjacency-sets of duplets.
, where: The implementation definition for duplet difference is given in Chapter 6 Section 6.1.1.

Duplet Adjacency
Ordering. An ordering can be defined over Adjacency-sets of duplets as follows: , such that T ≤ U , then all b ∈ T are covered in U under duplet subsumption. Therefore, all a ∈ S are covered in U under duplet subsumption as duplet subsumption is transitive. Then ≤ is transitive; that is: The elements ⊥, ∈ α[δ[X , Y ]] define the least and greatest bounds, respectively, on α[δ[X , Y ]], where ⊥ is the unique minimal element that is covered by all elements, and is the unique maximal element that covers all other elements. We have: Then we have:

A Theory of Adjacency
Thus, ≤ is a non-strict partial order over α[δ[X , Y ]].
Adjacency Duplet Union. The join of S , T ∈ α[δ[X , Y ]] is defined using subsumption, as the cover-set for the duplet merge of the transitive closure of adjacent duplets, from the generalized intersection of all sets of sets of duplets, whereby each element of the generalized intersection covers an element in either S or T by duplet precedence subsumption. The generalized intersection defines the smallest collection of duplets that cover all of the duplets from both S and T by precedence subsumption. Given that all duplets in this set are now disjoint, the cover-set for the duplet merge of the transitive closure of adjacent duplets merges any forward-adjacent duplets from S and T . If we take some Thus, Adjacency join provides a lowest upper bound operator, we have: An efficient implementation definition for duplet join is given in Chapter 6 Section 6.1.1.

Adjacency Duplet Intersection.
Under this ordering, the meet (S ⊗ T ) of S , T ∈ α[δ[X , Y ]] is defined using subsumption, as the cover-set for the generalized union of all Adjacency-sets, where each element of (S ⊗ T ) is covered by a duplet, or by a collection of duplets in both S and T . The meet is defined as the largest set of adjacency-free duplets that is covered by both S and T . Thus, ⊗ provides the glb operator, then for S , T ∈ α[δ[X , Y ]] we have S ⊗ T is covered by both S and T , that is (S ⊗ T ) ≤ S and (S ⊗ T ) ≤ T .

Adjacency Duplet Negation. Given
where not S is the cover-set for all elements of type X that are not covered by some member of S . We have:

A Theory of Adjacency
Proof This follows from the definition of ≤ as an antisymmetric preorder, the properties of not, and the definitions of ⊕ and ⊗.

Commutative Laws.
We observe that changing the order of the operands/Adjacency-sets does not change the composition result.
Associative Laws. We observe that the order in which the operations are performed does not change the outcome of the operation.
The following identities link ⊕ and ⊗.
, S is idempotent with respect to ⊕ and ⊗.
is a lattice, ⊥ is the identity element for the join operation ⊕, and is the identity element for the meet operation ⊗.

FW 1 Filter Conditions
In this section, the filter condition attribute datatypes for the FW 1 policy model are defined.

OSI Layer 2.
Let L 2 define the set of all additional filter condition attributes at the Data-Link Layer, given as the set of all duplets over the set of all sets of packet-types (P PktTpe) and the set of all sets of MAC addresses (P MAC ).
From Lemma 5. 1.5, we have that L 2 is a lattice.

OSI Layer 7.
Let L 7 define the set of all additional filter condition attributes at the OSI Application Layer, given as the set of all duplets over the set of all sets of Layer 7 protocols (P Proto L 7 ), the set of all closed subsets for the ranges of all Linux UIDs partitioned by adjacency (UID Spec ), and the set of all closed subsets for the ranges of all Linux GIDs (GID Spec ) partitioned by adjacency.
From Lemma 5. 1.5, we have that L 7 is a lattice.
The Stateful/Protocol Datatype. Let Protocol define the set of all stateful protocols, given as the set of all duplets over the TCP protocol (P Flag Spec ), the UDP protocol (UDP), the ICMP protocol (P TypesCodes), and the set of all sets of connection tracking states for a packet/connection (P State). A benefit of the modelling approach to state in this dissertation, is that the powerset ordering defined over the set of iptables state literals enables a consistent means of comparing and composing the stateful aspect of firewall rules in the proposed model. While the approach in [66] provides a more expressive model of stateful rules using general automata, the approach taken to compare and compose stateful firewall rules is more complex than the proposed model in this dissertation. From Lemma 5.1.5, we have that Protocol is a lattice.
Stateful/Protocol Disjointness. A pair of stateful protocols are disjoint if the TCP, UDP and ICMP attributes are disjoint, and/or their state is disjoint. For t 1 , t 2 ∈ P Flag Spec , u 1 , u 2 ∈ UDP, i 1 , i 2 ∈ P TypesCodes and s 1 , s 2 ∈ P State, we define:

The FW 1 Firewall Algebra
In this section, we define an algebra FW 1 , for constructing and reasoning about anomaly-free firewall policies. We focus on stateless and stateful firewall policies that are defined in terms of constraints on source/destination IP/port ranges, the TCP, UDP and ICMP protocols, and additional filter condition attributes. A firewall policy defines the filter conditions that may be allowed or denied by a firewall. Let Policy define the set of all firewall policies, whereby: A firewall policy (A, D) ∈ Policy defines a policy as a disjoint pair of adjacency-free sets of filter conditions under the duplet adjacency ordering, whereby a filter condition f ∈ A should be allowed by the firewall, while a filter condition f ∈ D should be denied. Given (A, D) ∈ Policy, then A and D are disjoint: this avoids any contradiction in deciding whether a filter condition should be allowed or denied. The policy destructor functions allow and deny are analogous to functions first and second for ordered pairs: Thus, we have for all P ∈ Policy then P = (allow(P), deny(P)).

Lemma 5.3.1 Policy defines the set of anomaly-free policies.
Proof Given a policy (A, D) ∈ Policy, as A and D are adjacency-free sets, then A has no redundancy and D has no redundancy, as Adjacency-sets have no subsumption. Therefore, all packets matched in filter conditions allowed by the policy are distinct, as are all packets matched in filter conditions that are denied by the As P has no subsumption and P has no shadowing, then P has no generalised filter conditions and P has no correlated filter conditions. Therefore, as P has no redundancy/shadowing/generalisation/correlation, then Policy defines the set of anomaly-free policies.
Note that (A, D) ∈ Policy need not partition FC : the allow and deny sets define the filter conditions to which the policy explicitly applies, and an implicit default decision is applied for those filter conditions in FC \ α[FC ] (A ⊕ D). For the purposes of modelling iptables firewalls it is sufficient to assume default deny, though we observe that FW 1 can also be used to reason about default allow firewall policies.
Policy Refinement. An ordering can be defined over firewall policies, whereby given P, Q ∈ Policy then P Q means that P is no less restrictive than Q, that is, any filter condition that is denied by Q is denied by P. Intuitively, policy P is considered to be a safe replacement for policy Q, in the sense of [56,57,77] and any firewall that enforces policy Q can be reconfigured to enforce policy P without any loss of security. The set Policy forms a lattice under the safe replacement ordering and is defined as follows. (deny Q ≤ deny P)) ∧ P Q = (allow P ⊗ allow Q, deny P ⊕ deny Q) ∧ P Q = (allow P ⊕ allow Q, deny P ⊗ deny Q) Formally, P Q iff every filter condition allowed by P is allowed by Q and that any filter conditions explicitly denied by Q are also explicitly denied by P. Note that in this definition we distinguish between filter conditions explicitly denied in the policy versus those implicitly denied by default. This means that, everything else being equal, a policy that explicitly denies a filter condition is considered more restrictive than a policy that relies on the implicit default-deny for the same network traffic pattern. Safe replacement is defined as the Cartesian product of Adjacency orderings over allow and deny sets and it therefore follows that (Policy, ) is a poset. ⊥ and define the most restrictive and least restrictive policies, that is, for any P ∈ Policy we have ⊥ P . Thus, for example, any firewall enforcing a policy P can be safely reconfigured to enforce the (not very useful) firewall policy ⊥.

Theorem 5.3.2 The set of all policies Policy forms a lattice under safe replacement, with greatest lower bound ( ) and lowest upper bound ( ) operators in FW 1 .
Proof The ordering of adjacency-free filter condition/duplets is a lattice under subsumption, the Cartesian product is a lattice under the definitions of glb and lub, therefore, FW 1 is a lattice.
Note, the lattice properties of the FW 0 policy algebra, described in Chapter 4 Section 4.2.1, also apply to Policy policies in the FW 1 algebra.

Policy Intersection.
Under this ordering, the meet P Q, of two firewall policies P and Q is defined as the policy that denies any filter condition that is explicitly denied by either P or Q, but allows filter conditions that are allowed by both P and Q. Intuitively, this means that if a firewall is required to enforce both policies P and Q, it can be configured to enforce the policy (P Q) since P Q is a safe replacement for both P and Q, that is; (P Q) P and (P Q) Q. Given the definition of safe replacement as a product of two Adjacency lattices, it follows that the policy meet provides the glb operator. Thus, P Q provides the 'best'/least restrictive safe replacement (under ) for both P and Q.
Policy Union. The join of two firewall policies P and Q is defined as the policy that allows any filter condition allowed by either P or Q, but denies filter conditions that are explicitly denied by both P and Q. Intuitively, this means that a firewall that is required to enforce either policy P or Q can be safely configured to enforce the policy (P Q). Since provides a lub operator we have P (P Q) and Q (P Q).

Constructing Firewall Policies
The lattice of policies FW 1 provides us with an algebra for constructing and interpreting firewall polices. The following constructor functions are used to build primitive policies, and are analogous to the FW 0 constructors defined in Section 4. 2 The following provides us with a strong interpretation for these constructors:

.2. Given
whereby (Allow + A) allows filter conditions specified in A, while explicitly denying all other filter conditions, and (Deny + D) denies filter conditions specified in D while allowing all other filter conditions. A firewall policy P ∈ Policy can be decomposed into its corresponding allow and deny sets, and re-constructed using the algebra; for any (A, D) ∈ Policy, since A and D are disjoint then:

Reasoning About Policies in Practice
Sequential Composition. The algebra FW 1 can be extended to include a form of sequential composition of policies. The definition for FW 1 sequential policy composition is analogous to that given in Chapter 4 Section 4.3 for the FW 0 algebra. The policy constructions in Section 5. 3.1 can be regarded as representing the individual rules of a conventional firewall policy.
Let (Allow A) o 9 Q denote a sequential composition of an allow rule (Allow A) with policy Q with the interpretation that a given network packet matched in A is allowed; if it does not match in A then policy Q is enforced. The resulting policy either: allows filter conditions in A (and denies all other filter conditions), or allows/denies filter conditions in accordance with policy Q. We define: which is as expected. A similar definition can be provided for the sequential composition (Deny D) o 9 Q, whereby a given network packet that is matched in D is denied; if it does not match in D then policy Q is enforced. We define:

Reasoning About Policies in Practice
While in practice its usual to write a firewall policy in terms of many constructions of allow and deny rules, in principle, any firewall policy P ∈ Policy can be defined in terms of one allow policy (Allow allow(P)) and one deny policy (Deny deny(P)) and since the allow and deny sets of P are disjoint we have P o 9 Q = (Deny deny(P)) o 9 (Allow allow(P)) o 9 Q. We define this as: : Policy × Policy → Policy ∀ FW 1 ; P, Q : Policy • P o 9 Q = (Deny + (deny(P))) (Q (Allow + (allow(P)))) Let Rule define the set of all firewall rules, whereby: Rule ::= allow FC | deny FC In Chapter 9 Section 9.2, we consider an additional target action of log for firewall rules. We define a rule interpretation function as: A firewall policy is defined as a sequence of rules r 1 , r 2 , . ., r n , for r i ∈ Rule, and is encoded in the policy algebra as I(r 1 ) o 9 I(r 2 ) o 9 . . o 9 I(r n ).

Policy Negation.
The policy negation of P ∈ Policy allows filter conditions explicitly denied by P and explicitly denies filter conditions allowed by P. We define: not : Policy → Policy ∀ FW 1 ; P : Policy • not P = (Allow + (deny (P))) (Deny (allow (P))) From this definition it follows that (not P) is (deny (P), allow (P)) and thus

Reasoning About Policies in Practice
tion is defined similarly to the policy negation operation in the FW 0 algebra, we observe that in general, policy negation does not define a complement operator in the algebra FW 1 , that is, it not necessarily the case that (P not P) = and (P not P) = ⊥. However, the sub-lattice of policies with allow and deny sets that exactly partition the same set S ≤ FC has policy negation as complement (allow (P) ⊕ deny (P) = S for all P in the sub-lattice).

Standards Compliance
RFC 5735 [33], details fifteen IPv4 address blocks that have been assigned by IANA for specialized/global purposes. The special-use IPv4 addresses are detailed in Table 5. 3.  Some of these address spaces may appear on the Internet, and may be used legitimately outside a single administrative domain, however, while the assigned values of the address blocks do not directly raise security issues; unexpected use may indicate an attack [33]. For example, packets with a source IP address from the private address space 172. 16.0.0/12, arriving on the Wide Area Network interface of a network router, may be considered spoofed, and may be part of a Denial of Service (DoS), or Distributed DoS attack.

RFC 5735 Compliance.
Best practice recommendations are implemented for each of the fifteen specialized IP address block ranges in [33], resulting in one hundred and twenty iptables deny rules. In [55], we defined this deny ruleset

Reasoning About Policies in Practice
for a firewall management tool. We define IP spoof-mitigation policies for each iptables chain separately. For the INPUT chain, a compliance policy RFC5735 I is defined, whereby for each of the IP address block ranges, the following iptables rules are enforced.

iptables -
Similarly, for the OUTPUT chain, an IP spoof-mitigation compliance policy RFC5735 O is defined, whereby for each of the specialized IP address block ranges we have: For the FORWARD chain, then RFC5735 F enforces the following iptables rules for each of the IP address block ranges.

Reasoning About Policies in Practice
RFC5735 I , RFC5735 O and RFC5735 F . Let AdditionalFC I be the set of all duplets for additional filter condition attributes of interest, whereby: A revised definition for the set of all filter conditions FC I is given as:

δ[Protocol, AdditionalFC I ]]]]]
A revised definition for the set of all policies Policy I is given as: The compliance policies RFC5735 I , RFC5735 O , RFC5735 F ∈ Policy I , define the minimum requirements for what it means for some perimeter network firewall policy to mitigate the threat of IP spoofing for all traffic, in accordance with RFC 5735. Thus, we have for all P ∈ Policy I if: then P complies with the best practice recommendations outlined in [33] for IP address spoof-mitigation. In Chapter 6, a prototype policy management toolkit that implements Policy I firewall policies is described.

Anomaly Detection
We have by definition, the adjacency-free allow and deny sets of some P ∈ Policy are disjoint, therefore P is anomaly-free by construction. We can however define anomalies using the algebra; by considering how a policy changes when composed with other policies. The definitions given in this section are analogous to those given in Chapter 4 Section 4.3.1 for the FW 0 algebra.

Redundancy.
A policy P is redundant given policy Q if their composition results in no difference between the resulting policy and Q, in particular, if:

Reasoning About Policies in Practice
P and policy Q, if: Allow(allow (P)) Allow(allow (Q)) = (∅, ∅) as: Allow(allow (P)) Allow(allow (Q)) = (allow (P) ⊗ allow (Q), ∅) A similar interpretation follows for redundant packets with a target action of deny between filter conditions in a policy P and filter conditions in a policy Q.
In particular, we have redundant denies if: Deny(deny (P)) Deny(deny (Q)) = (∅, ∅) as: Deny(deny (P)) Deny(deny (Q)) = (∅, deny (P) ⊗ deny (Q)) Shadowing. Some part of policy Q is shadowed by the entire policy P in the composition P o 9 Q if the filter condition constraints that are specified by P contradict the constraints that are specified by Q, in particular, if: This is a very general definition for shadowing, as discussed in Chapter 4 Section 4. 3.1 when reasoning about shadowing anomalies using the FW 0 algebra. Further definitions may also be given for shadowing. For example, we have that some of the packets denied by filter conditions in a policy P shadow some of the packets allowed by filter conditions in a policy Q if: Deny(deny (P)) Deny(allow (Q)) = (∅, ∅) as: Deny(deny (P)) Deny(allow (Q)) = (∅, deny (P) ⊗ allow (Q)) Similarly, some of the packets allowed by filter conditions in a policy P shadow some of the packets denied by filter conditions in a policy Q if: Allow(allow (P)) Allow(deny (Q)) = (∅, ∅) Allow(allow (P)) Allow(deny (Q)) = (allow (P) ⊗ deny (Q), ∅) Generalisation. A generalisation anomaly exists between P and Q if some of the packets allowed by filter conditions in P shadow some of the packets denied by filter conditions in Q, in particular, if: Allow(allow (P)) Allow(deny (Q)) = (∅, ∅) and, those packets shadowed by filter conditions in Q are subsumed by Q's denies: not (Allow(allow (P)) Allow(deny (Q))) = Deny(deny (Q)) whereby: not (Allow(allow (P)) Allow(deny (Q))) = (∅, allow (P) ⊗ deny (Q)) Similarly, a generalisation anomaly exists between P and Q if some of the packets denied by filter conditions in P shadow some of the packets allowed by filter conditions in Q, in particular, if: Deny(deny (P)) Deny(allow (Q)) = (∅, ∅) and, those packets shadowed by filter conditions in Q are subsumed by Q's allows: not (Deny(deny (P)) Deny(allow (Q))) = Allow(allow (Q)) as: not (Deny(deny (P)) Deny(allow (Q))) = (deny (P) ⊗ allow (Q), ∅) Inter-policy Anomalies. We can also use the FW 1 algebra to reason about anomalies between the different policies of distributed firewall configurations. In the following, assume that P is a policy on an upstream firewall and Q is a policy on a downstream firewall. Further definitions may be given for inter-redundancy. For example, there are redundant packets with a target action of deny in filter conditions between upstream policy P and downstream policy Q, if:

Redundancy. An inter-redundancy anomaly exists between policies
Deny(deny (P)) Deny(deny (Q)) = (∅, ∅) Shadowing. An inter-shadowing anomaly exists between policies P and Q if some part of Q's allows are shadowed by some part of P's denies. Given some set of filter conditions A denied by P, and some set of filter conditions B allowed by Q, then there is an inter-shadowing anomaly between P and Q, if: Further definitions may also be given for inter-shadowing. For example, we have that some of the packets denied by filter conditions in a policy P shadow some of the packets allowed by filter conditions in a policy Q if: Deny(deny (P)) Deny(allow (Q)) = (∅, ∅) Spuriousness. An inter-spuriousness anomaly exists between policies P and Q if some part of Q's denies are shadowed by some part of P's allows. Given some set of filter conditions A allowed by P, and some set of filter conditions B denied by Q, then there exists an inter-spuriousness anomaly between P and Q, if: Spuriousness may also be defined as follows, whereby some of the packets allowed by filter conditions in a policy P shadow some of the packets denied by filter conditions in a policy Q. We have an inter-spuriousness anomaly from an upstream policy P to a downstream policy Q, if: Allow(allow (P)) Allow(deny (Q)) = (∅, ∅)

Discussion
In this chapter, a policy algebra FW 1 is defined in which firewall policies can be specified and reasoned about. At the heart of this algebra is the notion of safe replacement, that is, whether it is secure to replace one firewall policy by another. The set of policies form a lattice under safe replacement and this enables consistent operators for safe composition to be defined. Policies in this lattice are anomaly-free by construction, and thus, composition under glb and lub operators preserves anomaly-freedom. A policy sequential composition operator is also proposed that can be used to interpret firewall policies defined more conventionally as sequences of rules.
The algebra can be used to characterize anomalies, such as redundancy and shadowing, that arise from policy composition. To consider the types of stateful anomalies from [66] in the proposed model FW 1 , then it would be necessary to apply additional constraints when constructing and composing anomaly-free firewall policies. For example, a policy that specifies a firewall rule that enables the establishment of a TCP connection from host X to host Y , should also include rules that allow for the various other permissible transitions of the TCP protocol. A similar approach would be required when considering more complex time-based rule anomalies. Suppose, for example, a policy specifies a rule that allows outbound SSH traffic from host X to host Y between 6 a.m. and 8 p.m. on Tuesdays, but is missing firewall rule/s permitting inbound SSH traffic during the same time period between X and Y . Similar to the notion of more complex stateful anomalies, it would also be necessary to apply additional constraints when constructing and composing anomaly-free firewall policies to consider more complex time-based anomalies. Best practice policy compliance may be defined using . The algebra FW 1 provides a formal interpretation of the network access controls for a partial mapping of the iptables filter table. FW 1 is a generic algebra and can also be used to model other firewall systems.
In [5], a firewall policy is modelled as a single rooted tree, relations between rules are defined on a pairwise basis, and definitions for firewall configuration anomalies are provided. In [6], the work is extended to distributed firewall policies. In [35], a firewall policy is modelled as a linked-list, and in [73] rule relations within a policy are modelled in a directed graph. In [159] Binary Decision Diagrams are used to model firewall rulesets. In [22], a theorem-proving approach is used to reason about firewall policies. We model a firewall policy as an ordered pair of disjoint adjacency-free sets, where the set of policies Policy forms a lattice under , and each P ∈ Policy is anomaly-free by construction.

Discussion
In [5,6,35,73,159] an algorithmic approach is taken to detect/resolve anomalies. We follow an algebraic (as opposed to algorithmic) approach towards modelling anomalies in a single policy, and across a distributed policy configuration through policy composition. In [161], a firewall policy algebra is proposed. However, the authors note that an anomaly-free composition is not guaranteed as a result of using their algebraic operators. Our work differs, in that policy composition under the , and o 9 operators defined in this chapter all result in anomalyfree policies. The proposed algebra FW 1 is used to reason about and compose anomaly-free policies and therefore we do not have to worry about dealing with conflicts that may arise. Anomaly conflicts are dealt with in composition by computing anomaly-free policies, rather than using techniques such as [78] to resolve conflicts in policy decisions.
Yang and Lam [158] propose the Atomic Predicate (AP) Verifier tool. AP Verifier reduces the set of predicates representing network packet filters to a set of atomic predicates, with the aim of speeding up network reachability testing. A predicate is represented as a set of integers that define the atomic predicates. The performance analysis of AP Verifier is compared with other tools, and demonstrates the proposed approach is significantly more time-and space-efficient. Belhaouane et al. [17] propose a formal method to verify when two Access Control Lists are functionally equivalent/isofunctional. In this dissertation, we argue that there is an isomorphic mapping between policies in the FW 0 and FW 1 firewall algebras, that is, every firewall policy P ∈ Policy has a corresponding unique representation P ∈ Policy 0 and vice-versa.
In [62], we developed the algebra FW 0 (extended in Chapter 4), and used it to reason over host-based and network access controls in OpenStack. In [62], we focused on stateless firewall policies that are defined in terms of constraints on individual IPs, ports and protocols. The FW 1 algebra is defined over stateful firewall policies constructed in terms of constraints on source/destination IP/port ranges, the TCP, UDP and ICMP protocols, and additional filter condition attributes. We argue that FW 1 gives a more expressive means for reasoning over OpenStack security group and perimeter firewall configurations. In Chapter 7, the FW 1 algebra is used to construct a policy model for OpenStack host-based and network access controls. This chapter is an extended version of the results reported for the prototype in [101], and is organised as follows. In Section 6.1 the prototype construction is described, we give efficient implementations of firewall rule (duplet) join and firewall rule (duplet) difference, and the experimentation methodology is presented. In Section 6.2, the sequential composition operator for Policy I policies is evaluated. Policy union is evaluated in Section 6.3, as is policy intersection in Section 6. 4. In Section 6.5 we evaluate policy compliance.

Implementing iptables Policies
A prototype policy management toolkit has been implemented in Python for iptables. We reason over an implementation of the Policy I policies described in Chapter 5 Section 5. 4.1, using the o 9 , , and policy operators. The test-bed for the experiments is a 64-Bit Ubuntu 14.04 LTS OS, running on a Dell Latitude E6430, with a quad-core Intel i5-3320M processor and 4GB of RAM. Every experiment was conducted three times; the median result chosen for inclusion. In this section, the construction of the firewall datatypes for the prototype and the methodology for generating the test-data is described.

Firewall Rules.
An iptables rule is modelled as a list of generic filter conditions. The current implementation defines firewall rules with filter condition attributes 6. Implementing The FW 1 Policy Algebra 6.1 Implementing iptables Policies for source/destination IP/port ranges, the ICMP, UDP and TCP protocols, and additional filter condition attributes. The relationships of adjacency, disjointness and subsumption have been encoded, as have composition operators for rule intersection and rule join/combination.

Range-based Attributes.
Filter condition attributes defined as ranges in the FW 1 framework, for example, source/destination IP/port ranges, are implemented as interval sets, using the Pyinter Python package [104]. The package was modified to include definitions for relative compliment operators and adjacency over intervals and interval sets.

ICMP and UDP.
The ICMP protocol is modelled as the set of all valid ICMP Type/Code pairs, given in Chapter 3 Section 3.2. 2. UDP has been defined as a binary attribute. Boolean operators apply for the UDP filter condition attributes.

TCP.
The TCP protocol is encoded as a 2 12 bit array, whereby the position of each bit is mapped to an index value in a table. This table is    Additional Attributes. Attributes for direction-oriented filtering, network interface and iptables chains have been encoded as sets for firewall rules.

Firewall Policies.
A policy is implemented as a disjoint pair of adjacency-free sets of firewall rules. The adjacency-free sets of rules have been modelled following the approach taken to model the interval-sets in the Pyinter package [104].
Transitive Closure of Adjacent Rules. The transitive closure for the adjacency relation over rules in firewall policies has been implemented recursively, following the approach used in the Pyinter package to implement the transitive closure over adjacent intervals [104]. A set of firewall rules is adjacency-free by construction. When a new rule is added to the ruleset, a check is made firstly to determine if there are any rules in the set that are adjacent to the new rule.
If there are none, the new rule is added. Otherwise, the adjacent rules are removed from the ruleset, and rules resulting from the combination of the new rule with the adjacent rules are added to the ruleset, starting again with a check to determine if there are any rules in the set that are adjacent to the new rule.

Implementing Duplet Join and Difference
In this section, the implementations of duplet/rule join and duplet/rule difference are defined.
Duplet Combination. For f , g ∈ δ[X , Y ], then the combination operation (f δ[X,Y ] g) defines a set of adjacency-free duplets that exactly cover f and g.
[X ] : The operation is described using three recursive functions; center C(f , g), left L(f , g) and right R(f , g), and is defined as the set union of the duplets resulting from C(f , g), L(f , g) and R(f , g). For ease of exposition, a duplet is given as Center. For f , g ∈ δ[X , Y ], then C(f , g) defines the join of the adjacent and common attributes in f and g. For duplets comprising two attributes, we define: Table 6.2 specifies the operations and duplet resulting from C(f , g) for twoattribute duplets. The label D signifies duplet, while A means the attribute. For f and g of length greater than two, we define for each additional attribute: Table 6.3 specifies the operations and duplet resulting from C(f , g) for duplets with three attributes.
, then L(f , g) defines the remaining attribute constraints covered in f , that are not covered in C(f , g). For duplets comprising two attributes, we define:  For f and g of length greater than two, we define for each additional attribute: Table 6.5 specifies the operations and duplets resulting from L(f , g) for duplets comprising three attributes.
, then R(f , g) defines the remaining attribute constraints covered in g, that are not covered in C(f , g). For duplets comprising two attributes, we define: Table 6.6 specifies the operations and duplet resulting from R(f , g) for twoattribute duplets. For f and g of length greater than two, we define for each additional attribute:  Table 6.7 specifies the operations and duplets resulting from R(f , g) for duplets comprising three attributes.
Proof We will show that for f , g ∈ δ[X , Y ], then f δ[X,Y ] g defines the adjacencyfree combination for all n ∈ N, where (n = # f = # g) ≥ 2, using induction on n.
Base Case. For n = 2, then for f δ[X,Y ] g, the resulting operations and duplets for f and g as two attribute duplets are given in Table 6.8:   g) and R(f , g), the resulting operations and duplets for f and g as (k + 1)attribute duplets in (f δ[X,Y ] g) are given in Table 6.10, whereby: return Combine(f, g, len, ruleSet)

Algorithm 1: Duplet combination operation
, we define the implementation definition for sets of adjacency-free duplets as: Proof Given that both definitions define the cover-set for the duplet merge of the transitive closure of forward adjacent duplets from the smallest collection of disjoint adjacency-free duplets that cover all of the duplets from both S and T by precedence subsumption, then Theorem 6. 1

.2 holds.
Duplet Difference. For f , g ∈ δ[X , Y ], the operation (f \ δ[X,Y ] g) defines a set of adjacency-free duplets that are covered by f but not by g. The operation is described using two recursive functions; center C diff (f , g), and the left L(f , g) function given previously. The function (f \ δ[X,Y ] g) is defined as the set union of the duplets resulting from C diff (f , g) and L(f , g).
Center. For f , g ∈ δ[X , Y ], then for duplets comprising two attributes; C diff (f , g) is defined as follows: a 1 , b 1 , a 2 The operations and duplet resulting from C diff (f , g) for two-attribute duplets are given in Table 6  For f and g of length greater than two, we define for each additional attribute: The operations and duplet resulting from C diff (f , g) for duplets with three attributes are given in Table 6. 12.  Proof We will show that for f , g ∈ δ[X , Y ], then f \ δ[X,Y ] g defines the adjacencyfree duplet difference for all n ∈ N, where (n = # f = # g) ≥ 2, using induction on n.
Base Case. For n = 2, then for f \ δ[X,Y ] g, the resulting operations and duplets for f and g as two-attribute duplets are given in Table 6. 13. f and g as k-attribute duplets are given in Table 6.14. and L(f , g), the resulting operations and duplets for f and g as (k + 1)-attribute duplets in (f \ δ[X,Y ] g) are given in Table 6.15, whereby: return Difference(f, g, len, ruleSet) Algorithm 2: Duplet difference operation

Generating the Datasets
Datasets have been constructed to evaluate the policy operators. The policy composition datasets were constructed in such a way as to test possible best/worstcase scenarios. A dataset has also been constructed to test policy compliance.

Datasets for Sequential Composition Experiments.
Two datasets were generated for experimentation. Each dataset consists of iptables policies of size 2 4 , 2 5 . . 2 11 . This allows us to formulate a doubling hypothesis [128] for each dataset, whereby we determine the effect on the experiment's running time by doubling the number of rules. All dataset rules have a target action of allow.
Non-adjacent Dataset. This dataset contains policies where no rule is adjacent to any other rule (other than itself). The source/destination IP/port ranges for each rule in a policy are incremented, such that each new rule is not adjacent to the previous rule. The first two rules of each policy in this dataset are: The datasets have been constructed in this way, as evaluating randomly generated rules is not an effective testing technique. The adjacent and non-adjacent datasets allow for a boundary value analysis [114] of rule composition.

Example 1
Sequentially composing the first two rules in an adjacent dataset policy results in the following re-computed adjacency-free iptables ruleset. However, sequentially composing the first two rules from a non-adjacent dataset policy results in those two rules for a re-computed adjacency-free iptables ruleset/policy.

Dataset for Policy Union and Intersection Experiments.
Each policy in the previously defined adjacent dataset, is split into two policies to construct the dataset for the lub/glb experiments. The first policy contains the odd (index) rules from the original policy. All rules in an odd-index policy are adjacency-free. The second policy contains the even (index) rules from the original policy. All rules in an even-index policy are adjacency-free. Constructing the dataset from the odd-index and even-index policies allows us to evaluate the cost, in terms of time, of composing policies of different sizes, whereby for the policy union experiments, the maximum number of rules are generated as a result of composition.

Dataset for Policy Compliance Experiments.
A dataset consisting of iptables policies of size 2 5 , 2 6 . . 2 11 is generated to test policy compliance. Each policy in this dataset is RFC 5735 compliant by construction, for TCP traffic arriving on the iptables INPUT chain to/from each of the fifteen special-use IPv4 addresses [33]. Recall, the compliance policy RFC5735 I defined in Chapter 5 Section 5. 4.1 for Policy I policies. The UDP rules from the previously defined non-adjacent dataset have been re-written with a target action of deny, and are used to construct the remaining rules for each policy in the compliance dataset.
The iptables policies in the datasets described in this section are used to evaluate the time complexity of the Python prototype implementation of the FW 1 Policy I policy operators. In this section, when we refer to the cost of the evaluation of a policy in an experiment, we are referring to cost in terms of time.

Evaluating Sequential Policy Composition
In this section, the sequential composition operator for Policy I policies is evaluated. The prototype parses the system's currently enforced iptables ruleset r 1 , r 2 . . r n by chain, using the Python-iptables package [100], and then normalizes each rule to a primitive/singleton policy. The overall policy for the chain is evaluated as I(r 1 ) o 9 I(r 2 ) o 9 . . o 9 I(r n ). Once the sequential composition of the system's currently enforced iptables policy is computed, the prototype generates a semantically-equivalent adjacency-free set of iptables rules and re-writes this new ruleset to the system. Experimentation was conducted over the adjacent and non-adjacent rulesets. Three different approaches have been implemented for evaluating sequential composition. The different approaches and results of the experiments are described in this section.

A Linear Approach.
This approach is the evaluation of policies in a linear sequence, as I(r 1 ) o 9 I(r 2 ) o 9 . . o 9 I(r n ).

Non-adjacent Dataset Experiments.
The first set of experiments were conducted on the non-adjacent datasets. Figure 6.2 details the results.   As the number of rules increase, the cost of computing the sequential composition of non-adjacent rules is relatively cheap, and is proportional to the number of rules. For the largest ruleset 2 11 , the time taken for the evaluation of the sequential composition of the rules is approximately one minute.

Adjacent Dataset Experiments.
The second set of experiments was conducted on the adjacent rulesets. Figure 6.  We observe that as the number of rules increase, the cost of computing the sequential composition of adjacent rules is expensive, but is also proportional to the number of rules used in the experiment. However, the cost is by orders of magnitude more expensive than the cost for evaluating the sequential composition of non-adjacent policies of the same size. For 2 9 rules, the time taken for the evaluation of sequential composition is around three minutes, and the time taken for 2 11 rules is approximately forty six minutes.
A Divide-and-Conquer Approach. This approach has been implemented in order to improve on the results from previous experiments using the linear approach. For this approach, we take a sequence of primitive policies I(r 1 ), I(r 2 ) . . I(r n ) , and perform a binary-chop on the sequence; whereby a binary expression tree is constructed to compute the order of the sequential compositions. Policies are always leaves, and sequential composition operators always have a left and a right sub-tree. Figure 6.4 depicts the expression tree for 2 3 rules/primitive policies. The result of this evaluation is equivalent to the policy resulting from the linear sequential composition of policies, that is, the evaluation of I(r 1 ) o 9 I(r 2 ) o 9 . . o 9 I(r 8 ). If the number of rules/primitive policies is odd, the expression tree is balanced from left to right, as depicted in Figure 6.5.   As the number of rules increase, the cost of computing the sequential composition of non-adjacent rules using the binary-chop is relatively cheap, and is proportional to the number of rules. We observe however, that the cost is slightly more expensive than the cost for evaluating policies of the same size following the linear approach for the non-adjacent dataset. For the largest ruleset 2 11 , the time taken for the evaluation of the sequential composition of 2 11 rules is approximately one minute and twenty seconds.

Evaluating Sequential Policy Composition
Binary-chop Adjacent Dataset Experiments. The second set of experiments was conducted on the adjacent rulesets. Figure 6.7 details the results.  As the number of rules increase, the cost, in terms of time, to compute the sequential composition of adjacent rules using the binary-chop is expensive, but is also proportional to the number of rules. However, we observe that the cost is much more expensive than the cost for evaluating policies of the same size following the linear approach for the adjacent dataset. For 2 9 rules, the time taken for the evaluation of sequential composition is around nine and a half minutes, and the time taken for 2 11 rules is approximately two and a half hours.
A Parallel Divide-and-Conquer Approach. This approach has been implemented in order to improve on the results from previous experiments using the binary-chop approach. For this approach, we again perform a binary-chop on the sequence of rules, however, we incorporate the standard Python multiprocessing package [65]. The left and right sub-expressions are evaluated in parallel, and then sequentially composed, as depicted in Figure 6  As the number of rules increase, the cost of computing the sequential composition of non-adjacent rules using the parallel binary-chop is relatively cheap, and is proportional to the number of rules used in the experiment. We observe that the cost is an improvement to the cost for evaluating policies of the same size following the binary-chop approach without multiprocessing, for the non-adjacent dataset. For the largest ruleset 2 11 , the time taken for the evaluation of the sequential composition of 2 11 rules is approximately one minute.

Parallel Binary-chop Adjacent Dataset Experiments.
The second set of experiments was conducted on the adjacent rulesets. Figure 6.10 gives the results.   We observe that as the number of rules increase, the cost, in terms of time, to compute the sequential composition of adjacent rules using the parallel binary- chop is expensive, and is proportional to the number of rules. We observe that for larger policies, the parallel approach is an improvement to the cost for evaluating policies of the same size following the binary-chop approach without multiprocessing, for the adjacent dataset. The evaluation time for the sequential composition of 2 9 rules is around seven and a half minutes, and the time taken for the largest dataset, 2 11 , is approximately two hours.

Evaluating Policy Union
In this section, the join operation for the FW 1 Policy I policies is evaluated. Experiments are conducted, whereby each policy in the adjacent dataset described in Section 6.1, is split into two policies to construct the dataset for the lub experiments. The first policy contains the odd (index) rules from the original policy, and the second policy contains the even (index) rules from the original policy. For each P, Q ∈ Policy I in this dataset, the time taken for the operation P Q is given by A benefit of conducting the policy join experiments in this way, is that in practice, we may want to update a policy P, comprising a large number of rules, with a smaller policy Q that permits some new accesses. The time taken for composition of policies of equal size is approximately the same as (slightly less than) the time necessary to sequentially compose the rules from both policies. That is; for example, the time taken for the sequential composition of 2 9 rules is around three minutes, as is the join of the two policies of size 2 8 . This is highlighted through the diagonal in the matrix, and is as expected; given that we used all allow rules, and the sequential composition of the rules used in these experiments results in the Reasoning About Firewall Policies Through Refinement and Composition 127 Ultan James Neville 6. Implementing The FW 1 Policy Algebra 6.4 Evaluating Policy Intersection eventual join of the rules. Figure 6.11 gives the 3D plot for the data in Table 6. 16.

Num rules
Num rules Time in seconds

Evaluating Policy Intersection
In this section, the meet operation for the FW 1 Policy I policies is evaluated. Experiments are conducted to test policy glb using the odd-index policies from the policy join experiments. For each P, Q ∈ Policy I in this dataset, the time taken for the operation P Q is given in Table 6. 17.  We observe that as the number of rules increase, the cost in terms of time to compute the intersection of the rulesets is cheap. For the largest ruleset composition of 2 10 and 2 10 rules, the time taken for evaluation was approximately twelve

128
Ultan James Neville 6. Implementing The FW 1 Policy Algebra 6.5 Evaluating Policy Compliance seconds. Figure 6.12 gives the 3D plot for the data in Table 6. 17.

Evaluating Policy Compliance
In this section, we evaluate the ordering relation for Policy I policies. For each P in the compliance dataset described in Section 6.1, the time taken in seconds for the evaluation of P RFC5735 I is given in Figure 6. 13.  We observe that the compliance test has a cheap cost in terms time, and all evaluation times for P RFC5735 I are negligible.

Discussion
In this chapter, a prototype policy management toolkit that implements FW 1 Policy I firewall policies in Python for iptables is described. The results in this chapter are described in terms of the algebra FW 1 , for stateful and stateless firewall policies that are defined in terms of constraints on source/destination IP/port ranges, the TCP, UDP and ICMP protocols, and additional filter condition attributes. Experiments were conducted for o 9 , , and policy operators. Two datasets were generated to evaluate sequential policy composition, one dataset contains policies that are adjacency-free, while the other dataset consists of policies where every new rule in a policy is adjacent to the previous rule. Datasets were constructed in this way to test possible best-and worst-case scenarios for policy composition. Three different approaches have been implemented for evaluation of the sequential composition operator. For the non-adjacent dataset, the cost, of computing the sequential composition of the rules is cheap. In the worst case, evaluation time for 2 11 rules is approximately one minute and twenty seconds using the binary-chop approach, and in the best case, using the linear approach, it is approximately one minute. For the adjacent rulesets, we observe a significant difference in the evaluation times across approaches. In the best case, evaluation time for 2 11 rules is approximately forty six minutes using the linear approach, and in the worst case, evaluation time for 2 11 rules is approximately two and a half hours using the divide-and-conquer/binary-chop approach. We conjecture that this is due to the computation of unnecessary transitive closures over adjacent rules, as a result of how transitive closure has been implemented, and constructing the expression tree to compute the order of the sequential compositions for the binary-chop. For example, in a 2 2 rule policy expression, as depicted in Figure 6.14, rules I(r 1 ) and I(r 2 ) are sequentially composed, the result of this is sequentially composed with the result of (I(r 3 ) o 9 I(r 4 )). The unnecessary closures in this case are computed during the sequential composition of rules I(r 3 ) and I(r 4 ), as I(r 3 ) is adjacent to (I(r 1 ) o 9 I(r 2 )) and the result of the composition of I(r 3 ) and I(r 4 ) will result in a set of rules that are adjacent to (I(r 1 ) o 9 I(r 2 )), rather than just the single rule I(r 3 ). In evaluating and , a dataset was constructed from the rules of the adjacent dataset used in the sequential composition experiments, and a dataset specifying best practice firewall rules was constructed to test policy compliance. Overall, the results are promising and demonstrate that the approach is practical for large policies.

Chapter 7 A Firewall Policy Algebra For OpenStack
This chapter describes a firewall policy algebra FW OpenStack for OpenStack.
FW OpenStack is a derivation of the FW 1 algebra defined in Chapter 5. We use the algebra to provide a uniform way to specify and reason about OpenStack hostbased and network access controls. This chapter builds upon earlier research [62,101] and is organised as follows. Section 7.1 gives an overview of the Open-Stack cloud operating system. OpenStack host-based and network access control is examined in Section 7.2. In Section 7.3, OpenStack perimeter firewalls and security groups are encoded, and a firewall policy algebra FW OpenStack is derived from the FW 1 model. Section 7.4 presents a case study OpenStack deployment that illustrates practical use of the algebra.

OpenStack
OpenStack [63] is an open-source cloud operating system for public and private clouds. It provides Infrastructure-as-a-Service (IaaS) through a collection of interrelated projects/services. These services are used to manage pools of compute, storage, and networking resources throughout a datacenter [63]. For example, the Nova compute service manages the life-cycle of compute instances in an Open-Stack deployment. The Glance image service stores and retrieves virtual machine disk images, and is used by Nova during instance provisioning. The Neutron networking service enables Network-Connectivity-as-a-Service for Nova [64]. In this chapter, we focus on the OpenStack networking service, Neutron.

Motivation
The cloud computing paradigm has become widely adopted, with applications ranging from research to enterprise. However, for end-users, administrators and providers alike, there are security challenges. Managing the host-based and network access controls within and across cloud deployments is complex and errorprone. Cross-tenant accesses are often necessary for service-to-service communication, and the environment is highly dynamic due to platform and service migration. Multiple access control policies of varying types are required for a deployment, and a misconfigured policy may permit accesses that were intended to be denied or vice-versa. We regard the specification of an OpenStack access control policy as a process that evolves. Threats to, and access requirements for, resources within a cloud do not usually remain static, and over time, a policy or distributed policy configuration may be updated on an ad-hoc basis possibly by multiple specifiers/administrators. This can be problematic and may introduce anomalies, whereby the intended semantics of the specified access controls become ambiguous.

OpenStack Firewall Policies
The OpenStack Networking service, Neutron, is a standalone API-centric networking service. In general, the OpenStack networking configuration for a deployment will be segmented into four physical data center networks, as part of three distinct security domains. The Management network is used for intercommunication between OpenStack services, and is considered the Management Security Domain. The API network is used by tenants to access OpenStack APIs, and is considered the Public Security Domain. The External network, also in the Public Security Domain, is used by virtual machines (VMs) for Internet access, while the Guest network, used for VM instance-to-instance communication, is considered the Guest Security Domain. In this chapter, we focus on host-based and network access controls within the Guest Security Domain. These controls consist of perimeter firewall policies and Neutron security groups.

Perimeter Firewall Policies
Firewall-as-a-Service (FWaaS) adds perimeter firewall management to an Open-Stack project by filtering traffic at the Neutron router. It is implemented as a sequence of iptables rules, where a default-deny policy is enforced. One firewall policy is supported per project, whereby the policy is applied to all networking routers within the project [64]. FWaaS is currently considered an experimental feature of OpenStack Networking [15]. A FWaaS rule can be constructed using the OpenStack Neutron command-line client: The source ($s) and destination ($d) IP fields may be given as a single IP address/an IP address block (CIDR), the source ($sprt) and destination ($dprt) ports may be specified as single port values or ranges. The protocol ($p) field may be given as TCP/UDP/ICMP/Any, and the action field ($act) specifying the access decision, may be given as allow/deny.

Security Group Policies
A security group policy is a container for IP filter rules. Traditionally, security group capabilities were managed as part of the OpenStack compute service, Nova, and were instance-based. In Neutron, security groups are virtual interface port based. When utilizing Neutron as part of an OpenStack deployment, best practice [15] stipulates that security group capabilities be disabled in Nova, due to both possible conflicting policies, and also the more powerful capabilities of Neutron security groups. Security group rules allow administrators/tenants the ability to specify the type and direction of traffic that is allowed to pass through a virtual interface port. When a port is created in Neutron it is associated with a security group. If no security group is specified, a 'default' security group is assigned. This default group will drop all ingress traffic except that traffic originating from the default group, and allow all egress [15]. Rules may be added/removed to/from any security group by a tenant/administrator to change the default behaviour. A security group rule can be constructed using the Open- The direction field ($dir) is specified as ingress/egress. The remote source ($rsrc) may be given as an IP address/an IP address block (CIDR) using the remote IP prefix, or as a Neutron security group using the remote group id. Selecting a security group as the remote source will allow access to/from any instance in that security group, depending on the value specified in the direction field. The destination port ($min, $max) may be given as a single port/port range. The protocol field ($p) may be specified as TCP/UDP/ICMP/Any. Additionally, when specifying a rule with an ICMP protocol, given that ICMP does not support ports, the specific ICMP Type/Code may be given in place of the destination port. The SECURITY GROUP attribute specifies the security group that this rule applies to. Note that there are additional parameters that may be provided as command-line arguments, however the above are sufficient for our purposes.

The OpenStack Policy Model
In this section, a derivation of the FW 1 algebra is used to encode the network and host-based access controls available in OpenStack.

FWaaS Filter Conditions.
A FWaaS filter condition is a five-tuple,

Security Group Filter Conditions.
A security group filter condition defines the packets to be accepted relative to the members of the security group. Let FC SG define the set of all security group filter conditions: The filter condition attribute Dir, specifies direction-oriented filtering as ingress or egress. A security group filter condition (sgm, dir, rsrc, dprt, p) ∈ FC SG specifies that for all members sgm of the security group to which the rule belongs, network traffic is permitted in direction dir to/from remote-source rsrc (depending on direction dir), to destination ports dprt, using protocols p.

Filter Condition Mapping.
A security group filter condition f ∈ FC SG can be mapped to the FWaaS filter condition F sg (f ) that it matches, whereby: If the direction attribute is ingress then the filter condition constrains packets coming from the remote source and destined to the members of the security group; if direction attribute is egress then the filter condition constrains packets coming from members of the security group (source) and destined to the remote resource.
The definitions for ordering and composition operations in the FW OpenStack algebra are the same as those defined for the FW 1 policy algebra in Chapter 5, Section 5.3, and therefore, FW OpenStack is a lattice. The lattice of policies Policy FWaaS provides us with an algebra for constructing and interpreting OpenStack firewall polices. Definitions for policy construction, policy negation, policy sequential composition and firewall rule interpretation are assumed for Policy FWaaS policies. These definitions are similar to those defined in Chapter 5 for the FW 1 policy algebra.

Security Group Rules.
A security group rule is simply an allow action on its filter condition: A security group policy is written as a sequence of security group rules r 1 , r 2 , . . . , r n where each r i ∈ FC SG and is encoded in the policy algebra as Note that in this encoding it is assumed that each rule in the original policy has the same membership, that is, group(r i ) = group(r j ) for all rules r i and r j in the policy where group(r) gives the group in the rule/filter condition r.
Policy Projection. The projection operators @ u and @ d filter a policy by a set of IP ranges. Firstly, let S(S ) give the cover-set for all filter conditions that have a source IP in some member s ∈ S , and similarly D(D) gives the cover-set for all filter conditions with a destination IP address in some member d ∈ D. For a policy P and a set of adjacency-free IP ranges S , P@ u S is the upstream projection of P, and consists of the allow and deny filter conditions from P where each filter condition has a source IP in some member of S . Similarly, P@ d S is the downstream projection of P, it consists of the allow and deny filter conditions from P whereby each filter conditions has as a destination IP in some member of S .

Reasoning About OpenStack Firewall Policies
In this section, a case study OpenStack deployment is presented that illustrates the practical use of the algebra FW OpenStack . Consider, a company that has migrated platforms and services to an on-premises OpenStack deployment. The deployment hosts both a development and a production cloud for the Web-service provided by the company and the code revision control systems for the Webservice. These two private clouds are defined as independent OpenStack projects/tenants as depicted in Figure 7.1 1 .

Internet
Company perimeter firewall Intranet 172. 16 All clip art used in this dissertation has been sourced from [106].

Reasoning About OpenStack Firewall Policies
System Administrator Bob manages the network access controls for both the development and production clouds. The architecture for each cloud is depicted in Figure 7

Reasoning About Security Groups
Bob creates a security group policy Git SG within the development cloud to manage the type of traffic permitted to/from the code revision control server. sgm 1 ∈ IP Spec denotes the set of adjacency-free IP ranges for the members of this security group. Bob begins to add rules git 1 , git 2 , for ICMP ping for each member of the dev/tester subnet to allow developers and testers to ping the Git server in the development cloud. Recall that when specifying a security group rule using the OpenStack Neutron CLI, that the ICMP Type/Code is given in place of a port range, when required. The function M(rule) maps a rule written in OpenStack firewall rule syntax to FW 1 algebra syntax.

140
Ultan James Neville Bob finds this tedious and decides to simply add a rule git 3 that allows all inbound ICMP traffic from the dev/tester subnet.
In doing so, however, git 1 and git 2 are now redundant to git 3 , (I s (M(git 1 )) o 9 I s (M(git 2 ))) o 9 I s (M(git 3 )) = I s (M(git 3 )). Rule git 4 is introduced to allow all developers and testers access to the code revision control system (Git) in the development cloud, where: git 4 == neutron security-group-rule-create --direction ingress \ --port-range-min 9418 --port-range-max 9418 \ --remote-ip-prefix 192.168. 1 Cross-tenant access is required for source code replication, therefore Bob must ensure that rsync via SSH is permitted from the Git server in the development cloud to the Git server in the production cloud. To do so, he introduces rule git 5 , where: git 5 == neutron security-group-rule-create --direction egress \ --port-range-min 22 --port-range-max 22 \ --remote-ip-prefix 172. 16.1.7 --protocol tcp Git SG Production Cloud Git Security Group. In the production cloud, Bob creates security group Git2 SG1 to manage the type of traffic permitted to/from the production code revision control server. The literal sgm 4 denotes the set of IP addresses for the members of this security group. Rule git p 1 is introduced to allow all developers and testers access to the code revision control system (Git) in the production cloud, where: The rule git p 2 , intended to ensure rsync via SSH between the code revision control systems in the development and production clouds is permitted, is inter-shadowed by the upstream rule dev 1 of the development cloud perimeter firewall, where: Recall, Pol IN DEV provides a policy about traffic traversing the perimeter firewall for the development cloud to the composite security group. A similar policy can be given for the traffic traversing the perimeter firewall of the production cloud destined to the security group within the production cloud. Further definitions can be given about policies on traffic leaving the respective clouds. These in turn can be composed to give a policy that is effectively about the rsync via SSH for the code revision systems in the development cloud to the production cloud.

OpenStack Firewall Policy Anomalies
In this section, we use the definitions of [5,6] to describe potential intra-and inter-anomalies between rules/policies in Neutron security group and FWaaS policy configurations.
Security Group Intra-anomalies. An intra-redundancy anomaly may occur in a security group, given that we may encounter two or more rules that are equivalent, or one or more rules that are filtering a subset of the network traffic filtered by another rule in the policy. We may also encounter rules that cannot match any traffic based on either the source/destination IP addresses, resulting in an intra-irrelevance anomaly.
Security Group (to Security Group) Inter-anomalies. We observe the possibility of spurious network traffic between different security groups; regarded as an implicit inter-spuriousness anomaly, from an upstream security group P permitting traffic to a downstream security group Q, whereby Q is missing a rule permitting the same traffic (and is therefore implicitly denying it). An implicit inter-shadowing anomaly may occur between security groups; depending on, for example, if upstream security group P was acting as a proxy for traffic for a downstream security group Q, and P is missing a rule (implicitly denying) traffic intended for Q, whereby Q is explicitly permitting the same traffic.

FWaaS Policy Anomalies.
We observe that all the intra-anomalies described in [5] may occur between rules in a single FWaaS policy, and that all the interanomalies given in [6] may occur between rules across distributed FWaaS policies.

Inter-anomalies Between Security Group and FWaaS Policies.
We consider an upstream FWaaS policy P and a downstream security group policy Q.
We observe the possibility of inter-spuriousness; given that P may be configured in such a way to allow unwanted traffic directed towards members of the security group constrained by Q. We note also the possibility of inter-shadowing, whereby P may be explicitly denying traffic that Q has been configured to accept. When considering an upstream security group policy P and a downstream FWaaS policy Q, we note the possibility of inter-spuriousness, and an implicit inter-shadowing anomaly; depending on, again for example, if P was acting as a proxy for traffic for Q, and P is missing a rule (implicitly denying) traffic intended for the downstream FWaaS firewall Q, whereby Q is explicitly permitting the same traffic. We observe the possibility of an inter-correlation anomaly between rules in an upstream FWaaS policy P and a downstream security group Q, or also between an upstream security group policy P and a downstream FWaaS policy Q. This anomaly occurs independent of target action/access decision, where a rule in the upstream policy is filtering some of the packets filtered by a rule in the downstream policy, and the rule under question in the downstream policy is filtering some of the packets filtered by the rule in the upstream policy. The inter-correlation anomaly may cause further anomalies such as inter-spuriousness

Discussion
In this chapter, a policy algebra FW OpenStack is defined in which OpenStack firewall policies can be specified and reasoned about. The set of policies form a lattice under safe replacement and this enables consistent operators for safe composition to be defined. Policies in this lattice are anomaly-free by construction, and thus, composition under glb and lub operators preserves anomaly-freedom. The algebra FW OpenStack is a derivation of the FW 1 policy algebra developed in Chapter 5, and provides a formal interpretation of the host-based and network access controls in OpenStack. In particular, it gives a meaning for OpenStack security group policies and perimeter firewalls. This provides us with a uniform notation to define and reason about different kinds policies in OpenStack. For example, reasoning over combinations of perimeter firewall and security group policies to ensure that modifications are safe (replacements) and checking for heterogeneous inter-policy anomalies.
In [80], cloud calculus is used to capture the topology of cloud computing systems and the global firewall policy for a given configuration. The work in this chapter could extend the work in [80], given that FW OpenStack may be used in conjunction with cloud calculus to guarantee anomaly-free dynamic firewall policy reconfiguration, whereby the ordering relation may be used to provide a viable alternative for the given equivalence relation defined over 'cloud' terms for the formal verification of firewall policy preservation after a live migration.

Chapter 8 A Policy Management Framework For Android
This chapter describes a system policy algebra Android Sys for the Android OS, that uses the FW 1 firewall policy algebra, in conjunction with an algebra for managing Android permissions, to construct a model of security control reconfiguration for Android firewall policies and Android permission polices. This chapter builds upon earlier research [54,55,101], and is organised as follows. Section 8.1 gives an overview of the Android mobile operating system. Android firewall configuration management is considered in Section 8. 2. In Section 8.3, we examine the Android Permission Model, and a simple algebra Android Perm is developed for managing Android permissions. In Section 8.4, a threat-based model that represents catalogues of best practice for Android systems is described. In Section 8.5, a policy algebra Android Sys is defined, whereby Android system policies; comprising firewall and permission policies, can be specified and reasoned about. We also consider a future iteration of the MASON prototype incorporating the proposed framework.

Android
Android [141], is an open-source software framework for mobile devices based on an optimized version of the Linux kernel. It is a privilege-separated mobile operating system. The Android OS has a layered architecture, with user applications (apps) residing at the upper-most layer. The next layer hosts the application framework, containing the Java APIs accessible to app developers. The following layer hosts the native C/C++ libraries of the Android OS; these can be used by any component of the previous two layers. This layer also hosts the Android runtime, which contains an optimized variant of a Java virtual machine (VM), the 148 8

. A Policy Management Framework
For Android 8.1 Android Dalvik VM. The next layer hosts the hardware abstraction layer (HAL) subsystem; this layer provides an interface for vendors to create software hooks between Android and the device hardware [143]. At the lowest layer of the hierarchy is the Linux kernel, the kernel acts as a layer of abstraction between software and hardware, and is responsible for core system services such as process management, and management of the network stack. Android uses Linux iptables as its firewall mechanism.

Motivation
Android runs on a variety of mobile devices, such as smartphones (for example, Google Pixel), tablet PCs (for example, Sony Xperia Z4) and embedded devices (for example, Neo-ITX and Raspberry Pi 3). In this section, we consider the Android software framework from the context of smartphones.
Modern smartphones with their processing power and the wide variety of applications ("apps") are on a par with modern desktop environments [129]. This has resulted in smartphones being used in a variety of domains from a personal device (such as for voice, Web browsing, Email and social media) to enterprise, medical and military domains [154]. The technological advances and the usage of smartphones in a variety of domains is not without its security implications. In addition to traditional mobile phone threats, threats to desktop environments are also applicable to smartphones [29,81,129]. For example, Malware threats such as DroidDream [10], an Android Market Trojan used to maliciously root Android smartphones, and apps that steal user's banking information [82,139,162] are on the increase [129,139].
Smartphones may host a variety of security mechanisms such as anti-virus, app monitoring and firewalls. In practice, security mechanisms are either disabled or configured with an open-access policy [119]. Configuration of smartphone security mechanisms, for example a firewall, is typically performed by non-technical end-users. As a consequence, an effective security configuration may be hampered by a poor understanding and/or management of smartphone application requirements. Misconfiguration, may result in the failure to adequately provide smartphone app services. For example, an overly-restrictive firewall configuration may prevent normal interaction of network-based apps. An overly-permissive firewall configuration, while permitting normal operation of the app, may leave the smartphone vulnerable to attack, for example, across open ports or through malicious payloads.
Smartphones operate in mobile network environments and deploying a fixed What may be considered a threat in one scenario may not be a threat in another. For example, a security configuration that permits a set of apps (such as gaming and social media apps) within a home network environment may not be permitted within an enterprise or teleworking environment. In a teleworking scenario, it is considered best practice to permit the use of "a different brand of Web browser for telework" and prohibit the use of the everyday Web browser [125]. Thus, the deployment of smartphone security configurations must be dynamic in order mitigate the relevant threats within a given scenario. Note, while smartphone apps may provide their own end-to-end security, in accordance with for example [48], it is considered best practice to also restrict access at the smartphone firewall [79,125,133,152].
In this chapter, a threat-based model that represents catalogues of best practice standards for smartphones/Android is described. The firewall catalogues are smartphone/Android-centric and extend the work in [61]. New catalogues of best practice for example NIST 800-114 [125] are developed, as is a prototype firewall app called MASON, to automatically manage firewall configurations on behalf of the end-user [55]. A case study based on firewall access control demonstrates how automated firewall configuration recommendations can be made based on catalogues of countermeasures. These countermeasures are drawn from best-practice standards such as NIST 800-124, a guideline on cell phone and PDA security and NIST 800-41-rev1, a guideline on firewall security configuration. The case study also demonstrates how MASON can be extended with the FW 1 algebra to ensure anomaly-free firewall policy reconfiguration.

Smartphone Firewall Configuration Management
The smartphone firewall is a security mechanism that controls traffic flow to and from network-based applications that are hosted by the smartphone itself and/or are hosted by a network of systems tethered to the smartphone in accordance with a security policy. Management of a smartphone firewall configuration involves either writing low-level command syntax via a CLI or the use of a graphical management console (for example DroidWall [163], WhipserMonitor [92]

Smartphone Firewall Configuration Management
error-prone [25,156,157]. Typical errors range from invalid syntax and incorrect rule ordering, to a failure to uphold a security policy due to lack of GUI-based firewall rule granularity, to errors resulting from the poor comprehension of a firewall configuration [94,152]. An effective smartphone firewall configuration may be further hampered by the poor understanding and/or management of the overall high-level smartphone security requirements.

Threat Mitigation Using A Smartphone Firewall
In this section, we consider known network-based threats that may be mitigated by the smartphone firewall.

Port-based Attack Surface Mitigation.
A smartphone port-based attack surface is the number of network accessible apps, hosted on the smartphone or on its tethered devices, in terms of ports that are available for a potential attacker to exploit. A smartphone may have a number of network accessible apps, for example RDP port 3389, VNC port 5900, SSH port 22, FTP ports 20 and 21.
It is considered best practice to uninstall or disable unnecessary network apps: "Removing or disabling unnecessary services enhances the security" [124]. For example, a smartphone may host server-based apps such as Telnet or FTP intended for occasional use. A smartphone user may not wish to install and uninstall these kinds of apps before or after each use. As a consequence, this increases the smartphone's attack surface. By explicitly configuring the firewall to permit access to intended app ports only, one can significantly reduce the attack surface. Consider the scenario of a remote desktop server app used to manage a smartphones files and photos. Configuring the firewall to permit only RDP traffic destined for port 3389 will reduce the attack surface from a possible 2 16 ports to just one intended port.

IP-based Attack Surface Mitigation. A smartphone IP-based attack surface
is the number of network-accessible apps, hosted on the smartphone or on its tethered devices, in terms of client IP address reachability that are available as a potential attacker threat vector. For example, with respect to smartphone remote management it is recommended to "Restrict which hosts can be used to remotely administer" on the smartphone where the restriction is "by IP address (not hostname)" [124].
Configuration of a smartphone's firewall to comply with best practice recommendations of this kind ensures that the IP-based attack surface is significantly reduced. Note, while a smartphone's remote management server apps, such as a VPN or SSH, may provide their own protection in terms of authentication and authorisation, it is considered best practice to also restrict access at the smartphone firewall as part of a defence in depth strategy [152].

IP-based Spoof Mitigation.
An IP packet's source address may be spoofed (forged) by an attacker in an attempt to trick the smartphone into processing the packet as if it had originated from the smartphone itself or from devices tethered to it. An external attacker may forge IP packets with a set of source IP addresses, for example 192. 168.0.0/16, that are associated with an internal private IP network range [33], but are inbound on the 3g or WiFi external interface.
A smartphone firewall configured in accordance with standards of best practice will mitigate against the threat of IP spoofing. For example, NIST 800-41rev1 recommendation FBPr1-2 in Table B.4 recommends that (spoofed) packets arriving on an external interface claiming to have originated from either of the three RFC 1918 [115] reserved internal IP address ranges should be dropped. This type of attack typically forms part of a Denial of Service (DoS) attack.

Port Scan Mitigation. Port
Scanning is a reconnaissance technique that attackers use to determine the network resources of the smartphone and of its tethered devices. Typical TCP-based port scanning involves exploiting the intended use of the TCP protocol by forging TCP header flags.
Firewalls provide an effective way to mitigate against invalid TCP packets. For example, the XMAS TCP port scan where TCP flags FIN, PSH and URG are simultaneously set [91]. In addition to mitigating invalid TCP packets, a firewall that manages TCP communication state is an effective way to mitigate against valid TCP packets that are forged. For example, TCP packets forged to mimic the expected return packets for outbound TCP traffic requests.

Tunnel Bypass Mitigation.
From the point of view of the firewall, the term tunnelling refers to the practice of encapsulating data from one protocol inside another protocol in order to evade the firewall [27]. For example, a Skype client typically listens on TCP and UDP port 33033 [14]. However, should Skype fail to establish communication over that port, it has the ability to operate on the port required by HTTP (port 80) [14,21,116]. As a consequence, despite denying traffic for TCP and UDP port 33033, Skype packets may still traverse the firewall unhindered by exploiting the intended purpose of HTTP-based firewall rules.

A Policy Management Framework
For Android

Smartphone Firewall Configuration Management
A smartphone firewall that can perform Deep Packet Inspection (DPI) mitigates the threat of tunnelling. The following is one of many possible Skype signatures used in a Skype-to-Skype communication that a firewall may be configured to filter [116]

Malware Traffic Mitigation.
A smartphone firewall can be used to mitigate or reduce the flow of Malware communication even in infected phones. Well known Remote Access Trojans (RATs), such as Android's Geinimi Trojan [137], can be blocked in terms of protocol (TCP) and ports (5432, 4501 and 6543) from indiscriminately making outbound connections to an external C&C. RATs may also communicate with their C&C over HTTP-based ports. For example, DroidDream [89] transmits IMEI, IMSI and device model information to its C&C server using the following URL: http://184. 105

.XXX.XX:8080/GMServer/GMServlet
In this scenario, as with the Tunnel Bypass Mitigation Skype example, a firewall performing DPI with a deny action on outbound HTTP-based packet payloads that contain "GMServer/GMServlet" will prevent an infected smartphone from communicating with DroidDream's C&C. Note, best practice stipulates the avoidance of once-off firefighting rules where possible and to adopt a default deny rule on outbound traffic [152].

Reasoning About Smartphone Firewall Policies
In this section, a case study is presented that illustrates practical use of the FW 1 algebra on Android systems. Consider, some end-user Alice, who over the course of her day encounters various scenarios while using her new smartphone. 7:30 a.m. As part of Alice's morning routine, she likes to check her email, read the news on her favourite Website and watch videos on YouTube. However, a problem on Android systems is that the firewall policy is open-access by default.
The following iptables rules implement a firewall policy Pol Home for Alice, whereby only her three favourite apps are allowed to access the Internet (rules  The policy Pol Home addresses Alice's current requirements and she now has a working firewall implementation. All employees have a VNC server running on their mobile devices to allow for screen sharing with local company systems. Company employees must use a non-standard Web browser for work-related activities, and non-authorised apps are restricted from accessing the company's internal network to help mitigate potential privacy violations.

Internet
The following iptables rules implement a simple BYOD policy Pol Work for Alice; whereby rule r 1 allows inbound network access to the VNC server port on Alice's device from the company's internal network, and rules r 2 . . r 5 permit/deny network access to other applications running on the device. Alice needs to manage her policies. If she simply concatenated Pol Home and Pol Work then she introduces anomalies, in particular, shadowing anomalies; whereby rules r 1 . . r 3 from Pol Home shadow (respectively) rules r 3 . . r 5 in Pol Work . We observe that: From this, we note that a one-size-fits-all approach does not apply to smartphone firewall policies.  The following iptables rules implement a partial compliance policy NIST-800-114, for Alice, whereby the firewall will: "silently ignore unsolicited requests sent to it, which essentially hides the device from malicious parties" [125]. The policy NIST-800-114 denies various TCP flag combinations used in common port scanning techniques [91], while allowing all other network traffic, and is given as: Assume, that the firewall policy currently enforced on Alice's system is Pol Curr , then if Pol Curr NIST-800-114 then Alice's current system policy complies with best practice recommendations outlined in [125] for unsolicited requests sent to the device.  (NIST-800-114 RFC5735 I RFC5735 O RFC5735 F ), then Alice's current system policy complies with best practice recommendations outlined in [125] for unsolicited requests sent to the device and the best practice recommendations outlined in [33] for IP address spoof-mitigation.

MASON
End-user management of security configurations that mitigate smartphone threats is complex and error-prone. As a consequence, misconfiguration of a security configuration may unnecessarily expose a smartphone to known threats.
There are a number of existing techniques for static and dynamic analysis of smartphone applications. The authors in [127] adopt a static analysis approach to detect Android-based Malware. In [43], a tool called PiOS is developed and uses static analysis techniques to detect data flows in Mach-0 binaries. This provides a basis to detect privacy leaks in Apple's iOS applications. TaintDroid [45] is a smartphone application that uses dynamic analysis techniques to detect privacy leaks in Android applications. A machine learning approach is taken in [130] to detect application anomalies. There are a number of Android apps for firewall configuration management, for example DroidWall [163], WhipserMonitor [92] and NoRoot [147]. However, in existing works [92,147,163], Android firewall configuration is performed on an ad-hoc basis. MASON [55], is a prototype automated agent app for Android that manages the firewall configuration on behalf of the non-expert end-user. In contrast to [92,147,163], the automatic generation of smartphone firewall configurations in this research is guided by best practice recommendations. The current version of MASON minimises the potential for firewall configuration conflicts as follows. Generalisation firewall rules that apply to app's as a whole, for example anti-port scanning and anti-bogon firewall rules, are given precedence over the disjoint singleton (specific) firewall rules. For the most part, firewall rules are disjoint singleton rules where rule ordering is irrelevant. That is, for each app requiring network access, there is a corresponding firewall rule that also filters based on that app's UID. The current implementation of MASON assumes that the firewall configuration is conflict free and does not consider firewall policy structural analysis [6,35]. We argue that extending MASON with the FW 1 algebra provides a means of anomaly-free, dynamic firewall policy reconfiguration for Android. An extended version of the prototype may also include a means to manage policies other than those specific to network access control, for example, policies to manage Android permission assignment to system applications using the Android Device Administration API [142].

A Policy Management Framework
For Android 8.3 The Android Permission Model

The Android Permission Model
At the core of the Android security framework is the permission-based model. The model restricts permission assignment to an application in two ways: by user confirmation and through signatures by developer keys [46,141]. An application has no associated permissions by default, and permissions required by the application must be specified by the developer in the application's Manifest file.
Permissions are categorized in terms of four threat-levels [144]: • Normal: permission is granted to any application that requests it.
• Dangerous: permission is not automatically granted to the requesting application and requires user confirmation.
• Signature: permission is granted if the requesting application is signed with the same certificate as the application that declared the permission.
• Signature or System: permission is granted if the requesting application has the same signature as the application that declared the permission, or is granted to apps in the Android system image.
For Android applications signed with the same certificate and specifying the sharedUserId attribute in their respective Manifest files, then these Applications share the set union of their permissions. For platform version Android 5.1 (API level 22) and lower, dangerous permissions must be granted to the application at install-time, or the install will fail. A problem with this, is that it may introduce over-privileged, potentially malicious applications to the system. The user may blindly accept the permission requests, or be unable to deny individual requests considered to be unnecessary for the legitimate operation of the application. Once granted, a permission cannot be revoked. Barrera et al. [12], present an empirical analysis of the Android permission model using 1,100 apps as a case-study. Results show that a small subset of Android permissions are used frequently, while a large subset of permissions were used by very few applications. The authors note potential points of improvement for the Android permission model, such as the lack of expressiveness in the Internet permission. For example, an Android app that holds the Internet permission has unrestricted network access over WiFi and 3g connections. Enck et al. [46], present Kirin, a security service that reads application permission requirements during installation and checks them against a set of security rules. Rules are Reasoning About Firewall Policies Through Refinement and Composition 159 Ultan James Neville

A Policy Management Framework
For Android 8.3 The Android Permission Model used to identify dangerous application permission configurations, such as applications that require Internet access and the ability to process audio and record outgoing calls, as an app with these permissions may potentially record and forward phonecalls to a remote location. If an application fails on any security rule, Kirin blocks the install and the user is alerted. While a light-weight application certification mechanism such as Kirin is desirable, it requires modification of the Android security framework to integrate with the installation process of an Android application. The authors do not consider applications sharing permissions through use of the sharedUserId attribute. For platform version Android 6.0 (API level 23) and higher, a dangerous permission is granted by the user to the application at run-time, and this can be revoked/granted again later. While this run-time permission model is a notable improvement over the install-time model, there are still significant security considerations to be addressed. For example, in [44], attacks against the system are composed from seemingly innocuous applications requesting apparently benign collections of permissions, and many permissions used to construct the attacks are classified under the run-time permission model as normal, for example, the Internet permission and the permission to start at system boot.

Encoding The Permission Model
In this section, we develop a formal model of Android permission management for system applications.

Applications.
We define Android applications by their UID. Thus, we define the set of all Android apps for a system to be UID, given in Chapter 3 Section 3.2. 4.

Permissions.
Android permissions categorized as dangerous [144] may be granted to/revoked from system applications using the Android Device Administration API [142]. Let Permission be the set of Android permissions characterized in [144] as having a threat-level of dangerous. We define: A permissions policy (G, D) ∈ Policy Perm defines that an application/permission pair a → p ∈ G should be granted access to a given resource by the system, while an application/permission pair a → p ∈ D should be denied access to a given resource by the system. Policy accessor functions grant and deny for permissions policies are assumed, and are analogous to functions first and second for ordered pairs. Definitions for permissions policy refinement and composition are analogous to the definitions given for the FW 0 firewall policy model in Chapter 4 Section 4.2. Definitions for policy construction, policy negation and policy sequential composition are also analogous to those given for the FW 0 policy algebra in Chapter 4. Thus, we define the Android permissions policy algebra as: Note, the lattice properties of the FW 0 policy algebra, described in Chapter 4 Section 4.2.1, also apply to Policy Perm policies in the Android Perm algebra.

A Compliance-driven Threat Model
In this section, we extend the threat-based model developed for MASON in [55], and consider the threat of apps with over/under-privileged Android permissions.

Catalogues of Best Practice
A best practice standard is a high-level document that defines a set of recommended best practices (countermeasures) to protect sensitive and critical system resources. The following best practice standards NIST 800-41 [152], NIST 800-41rev1 [123], NIST 800-124 [79], NIST 800-114 [125] and NIST 800-153 [133] for firewall access control have been encoded as part of this work. Excerpts of these catalogues are illustrated in Tables B.1 whilst teleworking [125], respectively. The advantage of developing catalogues from best practice standards is it provides a basis to automatically generate compliant firewall configurations. For example, NIST 800-41rev1 recommendation FBPr1-2 in Table B.4 recommends that (spoofed) packets arriving on an external interface claiming to have originated from either of the three RFC1918 reserved internal IP address ranges should be dropped. Such traffic indicates a Denial of Service attack typically involving the TCP SYN flag. NIST 800-114 recommendation TBP-1 in Table B.5 recommends that in a teleworking scenario, a firewall should be configured with a whitelist of trusted network-based apps.
Catalogues developed as part of this work extends the catalogues in [61] specialised for mobile devices. New best practice catalogues, namely NIST 800-124 [79], NIST 800-114 [125] and NIST 800-153 [133] have also been developed. The catalogue of firewall best practice for smartphones developed as part of this research consists of one hundred and thirty five distinct threat and countermeasure pairs. Future research should extend this catalogue to include knowledge about other best practice standards. Note, the majority of the catalogue countermeasures are templates. For example, the following firewall rules outlined in TBP-1 Table B.5: iptables -A OUTPUT -m owner --uid-owner $appUID \ -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -m owner --uid-owner $appUID \ -m state --state ESTABLISHED,RELATED -j ACCEPT are template countermeasures that have a UID variable $appUID that is modified each time the firewall rules are applied to a locally executing network-based smartphone app. These rules ensure that outbound/inbound local application whitelist traffic is permitted, and as such, avoid the stateful anomalies of [66] that result from the omission of explicit rules in a policy.

Threat Taxonomy
Having analysed the best practice standards outlined in Section 8. 4

Device Security State
The security State of a smartphone represents attributes of a phone in use that may introduce vulnerabilities and/or influence how threats are mitigated. These attributes may correspond to, for example, user-preferences (indicating for instance, security risk appetite), or how the smartphone is currently used (for instance, communicating over a WiFi or 3g Internet connection). While there is potentially a large number of such attributes, for this part of the research we focussed on six, which in-part, based on best practice recommendations, have a direct impact on network access controls on smartphones. We argue that certain attributes, for example, the users' risk appetite, the device battery level, and how the device is currently used (for instance, operating in a teleworking scenario) also, in-part, based on best practice recommendations, have a direct impact on Android permission policy management.

Risk Appetite Attribute.
This user-selected attribute reflects the level of risk that the user is willing to accept [149]. An appetite of hungry means that the user is willing to take risks and is satisfied with minimal countermeasures necessary to mitigate threats. An appetite of averse means that the user wishes for the most extensive countermeasures, for example, defense in depth. We define: RiskAppetite ::= averse | hungry Note, future research may consider additional risk appetite granularity and include minimalist, cautious and open attributes [149].
Teleworking Attribute. This attribute indicates whether the smartphone is used in teleworking, or non-teleworking mode. This is defined as: Telework ::= true | false Battery Level Attribute. The experimental results outlined in [55] found that the number of firewall rules can have an impact on battery consumption. NetConn ::= trusted | untrusted Data Quota Attribute. This user-selected attribute reflects whether the user wishes to apply a maximum data download capacity. If a data quota is to be configured, for example in a scenario where a smartphone is operating in roaming mode, it will be applied to a relevant set of white-listed apps. We define: Quota ::= true | false Security State. The set of all possible states of the smartphone is defined as: The (six-tuple) security State space provides a total of sixty-four states in which a smartphone may operate. However, we argue that certain attribute combinations are not valid and therefore the security state space may be reduced to forty. This is discussed in more detail in [55].

A System Policy Model
In this section, we develop a formal model for Android firewall and permission policy management.

System
Policies. An Android system policy is an FW 1 firewall policy and an Android permission policy. Let Policy Sys define the set of all Android system policies, whereby: Definitions for destructor functions firewall and permission are assumed, and are analogous to functions first and second for ordered pairs. Thus, we have for all P ∈ Policy Sys then P = (firewall (P), permission (P)). Definitions for system policy refinement and composition, including sequential composition, are defined as the Cartesian product of firewall and permission policy refinement and composition, respectively. Thus, we define the Android system policy algebra as: Note, the lattice properties of the FW 0 policy algebra, described in Chapter 4 Section 4.2.1, also apply to Policy Sys policies in the Android Sys algebra.

Security Configuration Synthesis
The current implementation of MASON makes configuration decisions for firewall policies based on six different binary attributes, comprising the security State, defined in Section 8. 4. 3. Suitable firewall configurations are automatically generated for each security state using the information contained in Table B.7 and the threat  catalogues (for example Table B.5). The catalogues of best practice for networkbased threat mitigation using a firewall are encoded as collections of iptables rules. The best-practice rules can be encoded in the FW 1 policy algebra as compliance policies, for example, RFC5735 I , RFC5735 O , RFC5735 F and NIST-800-114, and as policies to manage the user-defined blacklisted and whitelisted networked apps by UID. NIST 800-114 recommendation TBP-3 in Table B.5 recommends that different Web browsers such as Firefox and Google Chrome, should be used in teleworking and non-teleworking scenarios. This is to minimise the Web browser used for general use, which may have become compromised with malicious plugins, from communicating in a teleworking scenario. User-specified application/per- defines the whitelist of the application/permission pairs permitted access to given resources in the system for this state, and deny(permission (Pol Apps )) is the blacklist of application/permission pairs. The permission policy for a given state is Pol Perm ∈ Policy Perm , whereby: Suppose, that in this state, we require that the system configuration complies with the best practice recommendations outlined in NIST 800-114 for threats within the scanning category. Consider, (NIST-800-114, Pol Perm ) ∈ Policy Sys . When constructing the security configuration for this state, that complies with NIST 800-114 for unsolicited requests sent to the device, while also enforcing the networked-app blacklist/whitelist for the state, and the application/permission blacklist/whitelist for the state, then the following policy fragment: (NIST-800-114, Pol Perm ) o 9 Pol Apps defines this part of the system policy.
While various security states may have been related to the same threat categories, the security configuration generated for each state may be different.
whereby the iptables rules that mitigate IP spoofing threats apply to the INPUT and OUTPUT chains. Similarly, we construct the IP spoof mitigation policy for state-25 as follows: The security states state-3 and state-25 are also threatened by scanning. When constructing Pol Curr ∈ Policy Sys , whereby Pol Curr defines the overall security policy for a given state, then if this state is threatened by scanning and IP spoofing threats, and for each other threat category the state is threatened by, then:  That is, only trusted apps defined in accordance with the enterprise-level teleworking security policy may be permitted network access.
The lattice of policies Android Sys provides us with an algebra for constructing and interpreting Android system polices. An anomaly-free security configuration is defined by composing policy fragments derived from the threat catalogues as P, Q ∈ Policy Sys . The current prototype implementation makes configuration decisions for firewall policies based on six different binary attributes, comprising the security state State. In a model of extended security states, the system policy ordering relation may be used as a formal verification of the security policy to be enforced for a state configuration change. Extending the security states by exhaustively enumerating State as a means of manually building a catalogue of countermeasures is not scalable. Looking for optimal policy configurations in extended security states is a topic for future research, and is considered in Chapter 9 Section 9.2.

Discussion
In this chapter, a policy algebra Android Sys is defined, in which Android system policies, comprising firewall and permission policies, can be specified and reasoned about. The Android Sys algebra incorporates the FW 1 firewall policy algebra, defined in Chapter 5 Section 5.3, and the Android permission policy algebra, defined in Section 8.3 of this chapter. The set of Android system policies form a lattice under safe replacement and this enables consistent operators for safe composition to be defined. Policies in this lattice are anomaly-free by construction, and thus, composition under glb and lub operators preserves anomaly-freedom. A policy sequential composition operator is also proposed that can be used to give precedence to the security requirements of one system policy over another in composition.
This chapter also extended the threat-based model defined in [55] for MASON to consider the threat of apps with over/under-privileged Android permissions. Catalogues developed as part of this work extend the catalogues in [61] with an emphasis on mobile devices and provided a basis with which to evaluate the security model. A more fine-grained approach to encoding threats related to apps with over/under-privileged Android permissions is a topic for future research, and is considered in Chapter 9 Section 9.2. Extending the MASON prototype with the proposed model would require mapping the catalogues of best practice policy fragments into the algebra as compliance policies, recall, for example,  114. Given that Android applications are usually written in Java, then the Python FW 1 algebra implementation, presented in Chapter 6, may be incorporated into the MASON prototype using Jython [145]; a Java-based implementation of Python that allows developers to run Python on any Java platform. Alternatively, the existing Python implementation may be incorporated in MASON using Kivy [150]; an open source Python library that runs on Android. The Android Device Administration API may be incorporated into the prototype to enable the end-user to specify blacklist/whitelist permission-policies, these policies can be incorporated into the algebra as sets, thereby enabling MASON to dynamically manage policy reconfiguration. We argue that the MASON prototype, extended with the policy framework described in this chapter, may be used by non-expert end-users to automatically generate and reason over suitable anomaly-free firewall and permission policy configurations on Android systems, that are compliant with best practice recommendations, such as [79,112,123,125,133,152].

Conclusion and Future Research
Firewall policy management is complex and error-prone. Policies may need to be reconfigured for highly dynamic environments, and misconfiguration is common. Typical errors range from invalid syntax and incorrect rule ordering, to a failure to uphold a security policy due to lack of GUI-based firewall rule granularity, to errors resulting from the poor comprehension of a firewall configuration. An effective firewall policy may be further hampered by the poor understanding and/or management of the overall high-level security requirements. Policy management is often reliant on the expert-knowledge of security administrators, and drawing from best practice. A significant challenge is to reason confidently that a policy is anomaly-free, and adequately mitigates the threats outlined in the network security policy. There is a rich literature of work on managing firewall policy configurations. The work in [1,5,6,30,35,66,73,87,159] is focused on detecting and resolving anomalies in firewall policy configurations, while the approaches in [47,52,88,95] enable an administrator to query a policy configuration. Work such as [3,13,39,72,84] permits an administrator to specify at a high-level of abstraction what would otherwise be low-level firewall rules. However, in general, literature is focused on a five-tuple firewall rule with a binary target action of allow or deny, and most consider only packet-filter policy configurations. The thesis of this dissertation is that a firewall policy should be anomaly-free by construction, and as such, there is a need for a firewall policy language that allows for constructing, comparing, and composing anomaly-free policies.

Overview
The objective of this dissertation has been to develop a theory about composing anomaly-free firewall policies, as having a consistent means of anomaly-free 9. Conclusion and Future Research 9.1 Overview firewall policy composition enables a means of anomaly-free, dynamic firewall policy reconfiguration. The thesis of this dissertation was evaluated as follows. A model has been constructed to describe what it means to specify, compare and compose anomaly-free policies. The model is developed as a lattice structure and provides sound and consistent operators for firewall policy composition. The core filter condition constructs developed for firewall rules specify a partial mapping of the iptables filter table. This mapping has been used to define filter condition constraints that extend the conventional five-tuple firewall rule, used for example in [1,5,6,30,35,73,87,159], to include additional filter condition attributes such as, for example, TCP flags, ICMP Codes/Types and time-based filtering. A simple firewall policy algebra FW 0 has been developed for policies that are defined in terms of constraints on individual IP addresses, ports, protocols and additional filter condition attributes. The purpose of developing FW 0 was to demonstrate the utility of specifying an algebra for firewall policies that supports rules with complex range-based constraints.
The firewall policy algebra FW 1 developed in Chapter 5 defines the foundations for the work of this dissertation. Policies in the FW 1 framework are defined over stateful and stateless firewall rules constructed in terms of constraints on source/destination IP/port ranges, the TCP, UDP and ICMP protocols, and additional filter condition attributes. The algebra allows policies to be composed in such a way, that the result upholds the access requirements of each policy involved; and permits one to reason as to whether some policy is a safe (secure) replacement for another policy in the sense of [56,57,77]. The set of policies form a lattice under safe replacement and this enables consistent operators for safe composition to be defined. Policies in this lattice are anomaly-free by construction, and thus, composition under glb and lub operators preserves anomaly-freedom. A policy sequential composition operator is also proposed that can be used to interpret firewall policies defined more conventionally as sequences of rules. The proposed algebra is used to reason about iptables firewall policy configurations.
FW 1 is a generic firewall algebra that can be used to model different firewall systems, and an n-tuple firewall rule filter condition specification is supported by the model. The effectiveness of the algebra is demonstrated by its application to anomaly detection, and standards compliance. Firewall rules in FW 0 /FW 1 policies are defined in terms of a binary target action of allow or deny. We describe an extension of FW 1 to incorporate an additional firewall rule target action of log as part of future research in Section 9.2.

Future Research
We consider a number of possible areas to demonstrate the effectiveness of the approach in practice. A proof of concept prototype policy management toolkit that implements FW 1 firewall policies for iptables is developed. Experiments have been conducted for o 9 , , and policy operators, and the preliminary results are reported in Chapter 6. Overall, the results are promising.
The cloud computing paradigm has become widely adopted, however, managing the host-based and network access controls within and across cloud deployments is complex and error-prone. The environment is highly dynamic due to platform and service migration, and cross-tenant accesses are often required to facilitate service-to-service communication. A policy model FW OpenStack is proposed in Chapter 7 for OpenStack firewall policies using a derivation of FW 1 . OpenStack avails of multiple access control policies of varying types for a firewall deployment, and we use FW OpenStack to provide a uniform way to specify and reason about OpenStack security group policies and perimeter firewall policies. A case study OpenStack deployment illustrates practical use of the algebra.
Deploying a fixed security configuration for a global set of threats is not practical for devices operating in mobile environments. Therefore, security configurations for mobile devices must be dynamic in order mitigate the relevant threats within a given scenario. Mobile devices may host a variety of security mechanisms, however, security configuration is typically performed by non-technical end-users. A policy management framework for Android is proposed in Chapter 8, and a case study deployment illustrates practical use of FW 1 . An algebra Android Sys is proposed that incorporates FW 1 and the Android permission policy algebra Android Perm , for managing the unified reconfiguration of Android firewall and Android permission policies. The compliance-driven threat model developed for the MASON prototype is extended to include knowledge related to Android permissions. The policy framework amalgamates the threat model and Android Sys , and defines a means to dynamically manage the security configuration for firewall policies and dangerous run-time permissions on Android systems. We describe how integrating the policy management framework with the MASON prototype can be used to dynamically synthesise standards-compliant anomaly-free security configurations on behalf of the end-user of Android systems.

Future Research
Extending The Firewall Policy Algebra. There are a number of areas for future work. • A Log Action. In this dissertation, the focus was on firewall rules with a target action of either allow or deny. From a compliance perspective, it is considered best practice to log traffic for auditing purposes [123]. Future work should extend the FW 1 algebra to include a target action of log for firewall rules. An approach may be taken, whereby we extend (A, D) ∈ Policy to (A, D, L) ∈ Policy, where L ∈ α[FC ] and a filter condition f ∈ L should be logged by the firewall. We give the destructor function log for firewall policies; whereby log (A, D, L) = L. For policy composition, then for P, Q ∈ Policy, we have P Q signifies the operation (log P ⊕ log Q) for logged filter conditions. Similarly, for P Q we have the logged filter conditions (log P ⊗ log Q). From this, we have that the ordering for logged filter conditions is defined similarly to the ordering for denied filter conditions. In practice, a logged filter condition may be shadowed by a filter condition with a target action of allow or deny. However, it is not the case that a filter condition with a target action of log can shadow a filter condition with a target action of allow or deny. Therefore, for sequential composition, then we have P o 9 Q defines the logged filter conditions for the resulting policy as: (log P ⊕ (log Q \ α[fc] (allow P ⊕ deny P))).
• A Definition for Network Address Translation (NAT). The NAT routing technology is often combined with firewalling [123]. This dissertation focused on the firewalling aspects of iptables, that is, the filter table. Future work should extend the FW 1 algebra to include a definition for NAT. An approach may be taken, whereby we define the filter condition attribute Table, and mangle, nat, filter, ∈ Table. Additionally, we require prerouting, postrouting ∈ Chain. Given that NAT is the process of transposing one IP address space into another, then rules in the algebra need to include definitions for source and destination NAT address. These address spaces may be modelled as S , T ∈ IP Spec . Similarly, to include attributes for source and destination port translation, a rule would additionally include S , T ∈ Prt Spec . The model of Netfilter in [3] includes a definition for NAT.
Extending The Android Policy Framework. Future work should consider the following areas.
• scenario, for example, when it is located in a certain (untrusted) country or region of the world. Best practice recommendations such as, for example [112,126], provide sources from where new threats and attributes may be identified. For example, in [126], it is recommended that user and application access to hardware such as the USB interface be restricted, to prevent misuse by unauthorized parties, and that all network interfaces not needed by the device, such as Bluetooth and NFC, be disabled, thereby reducing the overall attack surface of the system.
• Optimal Policy Configurations in Extended Security States. The current implementation of MASON makes configuration decisions for firewall policies based on six different binary attributes, comprising the security State. Pruning invalid attribute combinations resulted in forty configuration scenarios for which corresponding policies were manually constructed from the collections of best-practice firewall rules. However, to allow for an arbitrary number of additional security states in future work, then manually constructing a catalogue of best-practice policies is not scalable. For example, supporting three risk-appetite attribute values, or adding an additional binary attribute potentially doubles the size of the matrix of valid security states for MASON. Future research should investigate how policies can be constructed as a set of constraints over State, the associated threats and the collections of best-practice countermeasures; whereby given some s ∈ State, then finding an acceptable security policy P ∈ Policy Sys amounts to a Constraint Satisfaction Problem. Comparable techniques have been successfully used to generate secure configurations [9] given a collection of system constraints. Belhaouane et al. [16] propose a series of quantitative metrics to evaluate the comprehensive complexity of policies. A definition of policy complexity is proposed, along with a set of metrics to evaluate the reasoning effort needed to understand a policy. Future work should investigate a means of policy comparison in the FW 1 algebra that incorporates metrics, as such an approach could be used to allow one to reason consistently about how much more restrictive one policy is when compared to another, thereby enabling trade-offs to be made when considering optimal policy decisions.
• Combinations of Dangerous Permissions. A more fine-grained approach to encoding threats related to apps with over/under-privileged Android permissions should also be considered. For example, in [44], it is shown how attacks incorporating a seemingly benign collection of permissions can pose a significant threat to the security of the system.
Interoperation With Other Domains. The general idea of a policy algebra for network access control can be applied to various domains of interest. For example, future work should investigate the application of the FW 1 algebra to policy composition in Cyber Physical Systems [59] and in SDN hypervisors [117].

A.1 The Z Notation
In this section, we build on the description we gave in [62] for the Z notation. The interested reader is also referred to [135] for comprehensive information on Z. A set may be defined in Z using set specification in comprehension. This is of the form { D | P • E }, where D represents declarations, P is a predicate and E an expression. The components of { D | P • E } are the values taken by expression E when the variables introduced by D take all possible values that make the predicate P true. For example, the set of squares of all even natural numbers is defined as { n : N | (n mod 2) = 0 • n 2 }. When there is only one variable in the declaration and the expression consists of just that variable, then the expression may be dropped if desired. For example, the set of all even numbers may be written as { n : N | (n mod 2) = 0 }. Sets may also be defined in display form such as {1, 2}.
In Z, relations and functions are represented as sets of pairs. A (binary) relation R, declared as having type A ↔ B, is a component of P (A × B). For a ∈ A and b ∈ B, then the pair (a, b) is written as a → b, and a → b ∈ R means that a is related to b under relation R. Functions are treated as special forms of relations. The schema notation is used to structure specifications. A schema such as FW 1 defines a collection of variables (limited to the scope of the schema) and specifies how they are related. The variables can be introduced via schema inclusion, as done, for example, in the definition of sequential composition.

ID
Recommendation Description CPhBP-4 "Network Access -Malware resident on the device is able to use the device for one or more unauthorized network activities, including port scanning or using the device as a proxy for network communications" [79].
Threat Countermeasure No inbound local audit control iptables -A INPUT -j LOG --log-level 7 No inbound forward audit control iptables -A FORWARD -i $iface -j LOG --log-level 7
x.x.255 -j DROP Outbound local directed broadcast iptables -A OUTPUT -d x.
x.x.255 -j DROP Inbound forward directed broadcast iptables -A FORWARD -i $iface -d x.
x.x.255 -j DROP Outbound forward directed broadcast iptables -A FORWARD -o $iface -d x.

ID
Recommendation Description FBPr1-5 To limit Denial of Service "a firewall might redirect the connections made to a particular inside address to a slower route if the rate of connections is above a certain threshold." [123] Threat Countermeasure Inbound forward DoS to tethered device iptables -A FORWARD -i $iface -d $lanIP -m limit --limit $x/s --limit-burst $y -j ACCEPT

ID
Recommendation Description TBP-1 Construct an access control whitelist of locally hosted applications trusted for telework network access: "teleworkers should install and use only trusted software" [125]. Threat Countermeasure Inbound local application whitelist traffic not permit-  [125].

ID
Recommendation Description TBP-4 "Configuring primary applications to filter content and stop other activity that is likely to be malicious" [125] Threat Countermeasure Outbound local unfiltered traffic iptables -A OUTPUT -m -string --algo bm --string '$filterString' -j DROP ID Recommendation Description TBP-5 "Personal firewalls should be configured to log significant events, such as blocked and allowed activity" [125] Threat Countermeasure No inbound local audit control iptables -A INPUT -j LOG --log-level 7 No inbound forward audit control iptables -A FORWARD -i $iface -j LOG --log-level 7