Identifying the missing aspects of the ANSI/ISA bestpractices for security policy

ABSTRACTFirewall configuration is a critical activity for the Super-visory Control and Data Acquisition (SCADA) networksthat control power stations, water distribution, factory au-tomation, etc. The American National Standards Insti-tute (ANSI) provides specifications for the best practicesin developing high-level policy [1]. However, firewalls con-tinue to be configured manually, a common but error proneprocess. Automation can make designing firewall configura-tions more reliable and their deployment increasingly cost-effective. ANSI best practices lack specification in all ofthe details needed to allow the firewall to be automaticallyconfigured without supervision. In this paper we discussthe missing aspects from the existing best practice specifi-cations and propose solutions. We then apply our correctedbest practice specifications to real SCADA firewall configu-rations and evaluate the usefulness of the added aspects forthe high-level automated specification of firewalls.

1. INTRODUCTIONNetwork security deals with the protection of data and re-

sources in a communications network, while providing accessto authorised users [7]. It is a crucial element of any modernday business in maintaining productivity, minimising disrup-tions and achieving regulatory compliance. Firewalls are thestandard mechanism for enforcing network security. Theyprotect the Confidentiality (C), Integrity (I) and Availabil-ity (A) of data and resources inside a network.

SCADA networks control the distributed assets of manyindustrial systems. Power generation, water distributionand factory automation are just a few examples that illus-trate the critical nature of these networks.

SCADA networks are not like corporate IT networks, theyhave been designed primarily for reliability and SCADA de-vices often lack built-in security features for protection fromcyber attacks. Consequently, these devices depend on fire-walls to protect them [12]. In these types of networks, thetraditional security priority; CIA, is normally reversed to

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.Copyright 20XX ACM X-XXXXX-XX-X/XX/XX ...$15.00.

AIC, as availability has the highest priority. Disruptions anddowntimes are generally unacceptable in SCADA networks,and rebooting of devices is often impractical. SCADA fire-walls help deliver high-availability of systems and are anintegral part of the safe and reliable operation of SCADAnetworks.

Firewall configuration, in practice, is a complicated andrepetitive manual task. It involves training in proprietaryand device specific configuration languages and long andcomplex device configurations. Lack of automation toolsto assist with such complexity has resulted in unoptimised,error-prone configurations that often deviate from the indus-try recommended network security guidelines [15, 16]. In-correct configuration of SCADA firewalls can lead to secu-rity breaches that could result in significant environmentaldamage, financial loss or in the worst case, loss of humanlives. Examples of past incidents include the hacking of Ma-roochy Shire Council’s sewage system in 2000, which sawtonnes of raw sewage released into public park-lands andriver systems [10] and the sophisticated Stuxnet worm whichattacked and damaged Iran’s nuclear facilities in 2010 [12].

The automation of firewall configuration has been inves-tigated by Bellovin and Bush [3]. They identified require-ments such as security, robustness and a database-drivenapproach as key, but leaves out high-level policies.

The starting point for automation is a high-level secu-rity policy description. High-level policies allow manage-ment level policy makers, who are often unable to specifypolicies in technical detail, to clearly instrument an organ-isation’s network security policies. Policies also need to beseparated from the underlying network topology, to promotereuse across multiple sites. High-level descriptions are of sig-nificant use in achieving this goal [2].

The best practices provided by the ANSI/InternationalSociety for Automation (ISA) introduce useful security con-cepts to mitigate security threats in control systems [1].These concepts enable specification of high-level securitypolicies for SCADA networks and by leveraging them wecan obtain a high-level description suitable for firewall auto-configuration. We analyse real SCADA firewall configura-tions using the ANSI/ISA standard high-level security con-cepts to identify missing aspects required for firewall auto-configuration and propose solutions. We evaluate how wellsuited these concepts are, as they currently exist, to caterfor policy specification requirements found in practice. Keygaps that prevent unambiguous specification of high-levelpolicy, for example in specifying firewall management re-quirements, are identified from our evaluation. By propos-

ing solutions for these gaps, we increase the precision andusefulness of the best practice in the context of automatedspecification of firewalls.

Our contribution is to fill the gaps in the ANSI/ISA stan-dard. We show the missing pieces needed to change the bestpractice from being a collection of good ideas into a tightspecification. Additionally, through real-world case studieswe illustrate that SCADA firewalls, even in simple cases arenot configured appropriately.

2. BACKGROUNDSCADA networks are vital to the operation of a nation’s

critical infrastructure plants. Recently, there has been a sig-nificant increase in the number of plant disruptions and shut-downs due to cyber-security issues in these networks [4].

Poor internal network segmentation in SCADA systemsis a significant contributor to the quick spread of securitythreats and attacks between subnets [1,4,12]. The ANSI/ISAstandards introduce the concepts of zones and conduits asa way of segmenting and isolating the various sub-systemsin a control system [1]. The zone-conduit model is a veryuseful starting point for a high-level description of securitypolicy, and so we shall describe it in detail here.

A zone is a logical or physical grouping of an organisa-tion’s systems with similar security requirements based oncriticality and consequence [1]. By grouping systems in thismanner, a single security policy can be defined for all mem-bers of a zone. For example, 3 security zones can be definedto accommodate low, medium and high-risk systems, witheach device assigned to its respective zone based on their se-curity level needed. A low-risk system can be accommodatedwithin a medium or high security zone without compromis-ing security, but not vice versa.

The uniform security policy of a zone is used to guidethe construction and maintenance of all systems within thezone [1]. Therefore, selected systems within a zone (e.g.,a server) should not have their own separate policies. Al-lowing separate policies would impart an incorrect sense ofsecurity to those systems. These systems are only as secureas the zone itself, in the absence of any firewalls enforcing areal separation.

A conduit provides the communication path between twozones as well as the necessary security functions for them tocommunicate securely [1]. Since availability is paramountin a SCADA network, a conduit should resist Denial of Ser-vice (DoS) attacks and preserve integrity and confidential-ity of network traffic. This is achieved using security miti-gation mechanisms (e.g., firewalls) implemented within theconduit. In Figure 1, two typical zones in SCADA envi-ronments: the SCADA-Zone and the Corporate-Zone areshown connected by a conduit.

SCADAZone

CorporateZoneConduit

Figure 1: Example Zone-Conduit model, adapted from [4].

A conduit cannot be a communications link that sim-ply inter-connects zones without restricting traffic-flow [1].

From a security perspective, this does not provide any mit-igation capabilities to the connecting zones. Such a conduitfails to enforce a clear separation of zones. It is equivalentto the two zones being a single zone and would prove use-less for security policy description purposes. A conduit, inthis view, always offers some security mitigation capability,typically using single or multiple firewall(s).

A zone-conduit security model of a network is key to theaccurate assessment of common threats, vulnerabilities, andrequired security mitigations to protect SCADA resources[1]. It provides a high-level view of an organisation’s secu-rity and traffic control strategy. The model helps identifythe disjoint security zones in the network, enabling the de-tection of serious design flaws such as the allocation of lowand high security devices into a single zone. Such directviolations of the ANSI/ISA best practices would be a clearindication of exploitable vulnerabilities.

The zone-conduit model also reveals unwanted inter-zonecommunication paths. It enables us to understand whetherthe security mitigation devices installed on each path arecapable of offering the level of mitigation required for secureinter-zone communications.

Zone and conduit concepts are intended as a platform forhigh-level security policy description. Before using theseconcepts in policy specification for firewalls, it is best toevaluate their usefulness. Particularly how well they caterfor security architectures used in practice in real networks.

2.1 Related workReal firewall configurations have been studied: a statisti-

cal analysis of corporate-firewall configurations [15] reportedserious errors found in over 80% of the configurations anal-ysed. Corporate-firewall configurations have also been anal-ysed using a firewall modeling and analysis toolkit (FIRE-MAN) [20] and several serious errors were also unveiled.

The problem of firewall configuration is therefore well-known and research has started to address it. Lumeta [14]and Fang [11] are management and analysis tools that inter-act with users on queries about firewall rules. They take aminimum network topology description and firewall configu-rations as input. These inputs are used to build an internalrepresentation of firewall rules which users can query to as-sist debugging and troubleshooting. These tools provide theability to detect firewall misconfigurations but do not ad-dress the manual and device centric configuration approachthat caused these misconfigurations in the first place.

Studies have been carried out on auto-generation and re-laying of organisational policies to distributed firewalls [3,13]. But they lack support for high-level requirements.

The unified modeling of packet filters and routing proto-cols to characterise reachability of a network has been pre-sented by Xie et al. [17]. However, it does not take intoaccount implicit rules which enable services through a fire-wall over and above Access Control Lists (ACLs).

A network control plane enabling direct control of Ether-net and IP based services has been implemented [18]. Directcontrol promotes centralised policy implementation, how-ever it lacks the ability to abstract-away minute policy con-figuration details and specify high-level requirements.

A central Domain Controller with trusted privileges hasbeen proposed [6] to reduce the ability of an end host tolaunch attacks.However, it also lacks the ability to specifyhigh-level policies.

None of the related work refer to the ANSI/ISA zone-conduit security model or attempt to identify a suitablehigh-level security policy description useful for automatingthe specification of firewalls. They also do not look at SCADAnetworks, with unique security requirements compared toCorporate networks. SCADA networks consist of highlyconstrained embedded devices such as Programmable LogicControllers (PLCs) that are incapable of supporting built-in network security features [12]. They have poorly de-signed TCP/IP stacks that easily fail. Installation of se-curity patches and upgrades of devices are also infrequentas rebooting is often impractical in SCADA networks.

A primary objective of our research is to identify missingaspects of the ANSI/ISA zone-conduit model as a high-levelsecurity policy description for SCADA firewalls. We also payattention to the industry best practices surrounding SCADAnetwork security to also understand how well practical fire-wall deployments adhere to these guidelines.

3. METHODOLOGY

Figure 2: Firewall configuration parsing process.

Firewall configurations are long and complex. For exam-ple, the SCADA firewall configurations we discuss consist of1360 lines on average per firewall. We could not use existingtools such as Fang or Lumeta to analyse these as they do notsupport high-level policies based on the zone-conduit model.Hence we built an automated parser to parse configurationsusing zone-conduit concepts.

We describe the Parser in detail here because it explainsthe use of zone-conduit concepts in the analysis of practicalnetworks and allows to identify shortfalls in the model andhelp find solutions. The Parser is depicted in Figure 2. Thedetails are described below:

Firewall Config : The input configuration text-file of a fire-wall containing interface configurations, static routes andACLs. Multiple configuration files can be input for simulta-neous processing.Interface and Route Processing : The processing of fire-wall interface configurations and static routes. This extractsinterface names, subnet IP addresses, security levels, addi-

tional network and gateway IP addresses. Details of thisprocessing are covered in Subsection 3.1.Rule Processing : The processing of ACLs assigned to fire-wall interfaces and any implicit rules. Implicit rules enableservices through the firewall over and above ACLs. Moredetails are discussed in Subsection 3.2.Conduit-Definition : The definition of conduits that inter-connect the security zones in the SCADA network. Detailsare covered in Subsection 3.3.Zone-Conduit Model : The zone and conduit topology out-put of the SCADA network.Interaction Filtering & Synthesis: The filtering of ACLrule interactions and synthesis with implicit rules. Detailsof this stage are covered in Subsection 3.6.Service-flow views: The output traffic-flow views for thefirewall. A service-flow view describes an enabled protocolthrough the firewall by zone.

Our current Parser uses one or more Cisco Adaptive Secu-rity Appliance (ASA) or Private Internet eXchange (PIX) orIOS firewall configurations as input. It begins by process-ing the individual firewall interface configurations. It alsoprocesses any static route configurations to identify the lo-cation of additional networks and gateways. Rule processingpartly involves parsing the ACLs assigned to firewall inter-faces. These indicate the traffic permitted to traverse eachof the firewall interfaces. Additionally, rule processing alsoinvolves parsing implicitly enabled services. The Parser thenperforms conduit definition. This creates the ISA standardzone-conduit model. ACLs and implicit rules are also anal-ysed by the Parser to filter-out any interactions present andsynthesised to generate service-flow views as output.

3.1 Zone constructionThe Parser analyses the interfaces and subnets defined

in the firewall configuration to construct zones. It startsby assuming each interface connects to a disjoint zone, andthen looks for indications that these potential zones shouldmerge. A potential zone merge can be identified via indi-cations of traffic leakage between the zones. These leakagesoccur outside of a firewall but can often be identified throughthe inspection of ACL contents.

Where such a leakage exists, ACLs should control trafficflow equally for those services, on both firewall interfacesconnected to the respective zones. By inspecting the ACLcontents of a firewall, and applying the policy that inter-zonetraffic-flow is allowed via firewall-only paths when redundantpaths are available (i.e., not relayed through a 3rd zone), wecan deduce that the assumed disjoint zones must form a sin-gle zone. The original disjoint zone-firewall model is thenupdated with identified merged zones.

Static routes can help locate additional networks and gate-ways. Static routes contain IP address details of next-hopgateways and networks reachable via them. By identifyingand including these, we can extend our zone-firewall model.

3.2 Implicit rulesIn a Cisco firewall, traffic flows can be enabled explicitly

through ACLs or implicitly via several alternate methods.One available method in ASA and PIX firewalls is to assignsecurity levels to the firewall interfaces [8]. An interface se-curity level is defined as a level of trust bestowed on thenetwork connected to that firewall interface. In the absence

of an ACL assigned to such an interface, certain traffic flowsare permitted by default from an interface with a high secu-rity level to one with a lower security level [8].

Special configuration commands can also be used to en-able services implicitly, for example to enable SSH or HTTPfirewall management traffic into the firewall interfaces [8].Accommodating such management traffic using zones is dis-cussed later in Subsection 3.4.

Implicit rules provide quick and easy alternatives to ACLsin enabling services through the firewall. They may not mapto clear security policies but are convenient. However, auto-configuration relies on clear security policies to permit trafficthrough a firewall. Implicit rules may aim to provide this,but we will see that they actually confuse the situation.

3.3 Zone-Conduit modelAs Section 2 discussed, a zone-conduit model describes the

logical grouping of systems in a network. It gives a high-levelview of an organisation’s network segregation strategy.

The Parser uses the zone-firewall model to generate a cor-responding zone-conduit model. This is done by identifyingthe security conduits based on ANSI/ISA guidelines. A con-duit is defined between zones, based on the available firewall-only paths between them. An example conduit (C1) between2 zones with a single-firewall path is shown in Figure 3.

This case is almost trivial, but the question of how to mapa network to zones and conduits has more complex cases.

(a) Zone-Firewall model for 2 zonesseparated by a firewall.

(b) Zone-Conduit model.

Figure 3: Single-firewall Conduit definition.

(a) Zone-Firewall model for 2 zonesseparated by parallel firewalls.

(b) Zone-Conduit model.

Figure 4: Parallel-firewall Conduit definition.

When two zones are connected by parallel links, the ANSI/ISA standard allows them to be modelled as multiple con-duits. Doing so however, would imply that multiple security

policies could exist between these zones when only one ispossible from the strict interpretation of a zone. Hence, wedefine a single conduit to implement the single policy rela-tionship. An example conduit (C2) is depicted in Figure 4b.

Firewall paths can include firewalls in series (Figure 5a).This back-to-back firewall architecture is one of the indus-try recommended security architectures [5] where defence indepth is achieved by using different vendors’ devices.

(a) Zone-Firewall model for 2 zones separatedby serial firewalls.

(b) Zone-Conduit model.

Figure 5: Serial-firewall Conduit definitions.

This firewall setup can also provide DoS protection byusing one firewall to perform simple processing of a largevolume of packets while the other firewall conducts complexprocessing (e.g., deep packet inspection) on a smaller num-ber of packets [5]. Network engineers may also setup loggingand alerts to originate from the firewalls differently, in such acircumstance. ANSI/ISA guidelines lack clear specificationon how to define zones and conduits to precisely capture thetraffic-flow requirements in this context.

There is a single conduit containing both firewalls, if wedismiss the link between the firewalls. For automation, asingle security conduit hinders precise specification of thedistinct firewalls.

We propose to treat this connecting link as a separatezone, to overcome the specification shortfall. It is referredto as the Abstract-Zone in the absence of any real networkdevices within it (Figure 5b). The approach creates two sep-arate conduits (C1 and C2), each containing one firewall.Auto-configuration can now leverage the distinct conduitsto specify the individual policy requirements. We can alsomodel the security properties of the subnet between the se-rial firewalls as a Demilitarised Zone (DMZ), in case devicessuch as a logger are added. A DMZ is used to expose anorganisation’s external-facing services (e.g., a mail server)to untrusted networks [5]. It adds a layer of security to thecompany’s trusted internal networks by only providing di-rect external access to the hosts in the DMZ.

A conduit may also inter-connect more than two secu-rity zones [1]. ANSI/ISA guidelines lacks clear specifica-tion on appropriate conduit definitions in such circumstance.Consequently, the example zone-firewall model depicted inFigure 6a, could be modelled using a hyper-graph (Fig-ure 6b). In this model, the firewall (FW) is located in-side the hyper-edge conduit C1 which has one-to-many zone-communication paths. This complex conduit can implementmultiple security policies; between Z1 and Z2, Z2 and Z3 andZ3 and Z1. Catering for this complexity requires the conduitto track the participating zones per policy. There is also noclear mapping of the ACL rules enforcing the policy to the

(a) Zone-Firewall model for 3 zones sep-arated by a firewall.

(b) Hyper-graph Zone-Conduit model.

Z2

Z1 Z3

C2

C4

C3

(c) Simple-graph Zone-Conduit model.

Figure 6: Conduit-definition alternatives.

firewall interfaces. Hence, the hyper-graph conduit model isdifficult to use for firewall auto-configuration purposes.

To simplify the complexities of hyper-edge conduits, wepropose to generate a zone-conduit model that consists ofonly one-to-one zone-communication paths (Figure 6c). Eachconduit now implements a single security policy betweentwo zones. The simple design also requires each conduit toonly contain the firewall interfaces attached to its connectingzones (e.g., C2 contains e0/0 and e0/1). A conduit path nowreveals the exact firewall interfaces and their layout with re-spective to the connecting zones, enabling easy placement ofrequired ACL rules. Consequently, the choice of simple-edgeconduits, allows us to enforce a strict 1:1 mapping betweenconduits and policies. This restriction yields a precise high-level specification, useful for firewall auto-configuration.

This logical method of conduit-definition leads to multipleconduits sharing the same firewall in their mitigation offer-ing (e.g., C2, C3, C4 share FW in Figure 6c).

In summary, a single conduit need not always map to a sin-gle firewall. In-fact one-to-many and many-to-one mappingsbetween conduits and firewalls are more useful for high-levelsecurity specification. However, our recommendation forfirewall auto-configuration is that one conduit should alwaysimplement a single relationship between only 2 zones.

3.4 Firewall management access controlIn addition to offering mitigation capabilities to zones,

firewalls play a dual role by providing secure, authorisednetwork management access to themselves. ANSI/ISA pol-icy includes the use of a firewall within a conduit as a miti-gation device, but does not clearly address how to use zoneand conduit concepts to capture firewall management policyrequirements. This is a critical shortfall, because if manage-ment of the firewall is compromised, the entire system iscompromised.

There are several possible ways to address the issue, asillustrated in Figure 7.

(a) Firewall interfaces in zones.

(b) Firewall shared by zones.

(c) Dedicated Firewall-Zone.

Figure 7: Firewall-Zone alternatives for 2 subnets S1 & S2separated by a firewall.

3.4.1 Firewall partially included in zonesWith this approach, each firewall interface belongs to the

zone directly connected to that interface (Figure 7a). It im-plies that all IP traffic to the firewall from hosts and subnetsof zones Z1 and Z2 is allowed.

While simple, this approach has obvious problems. Thedesign prevents restriction of firewall access by traffic type toselected connected-zones. For example, disallowing HTTPaccess to the firewall by zone Z1 would be impossible withthis type of a model.

3.4.2 Firewall shared between zonesThis model assigns a firewall interface to all connected

zones (Figure 7b), also implying removal of any traffic re-striction between hosts and subnets within each zone and thefirewall by default. The outcome is similar to that of 3.4.1,preventing placement of a required policy between a zoneand the firewall.

3.4.3 Firewall in its own zoneHere, we exclude the firewall from belonging to any exist-

ing zone and place it separately in a new security zone on itsown. This may seem more complex but actually representsthe real situation well. This new Firewall-Zone (FWZ) isconnected to the firewall (Figure 7c) via the Management-Data Interface (MDI). The MDI is a logical interface thatprovides traffic packets to the firewall’s control and manage-ment plane (Figure 8) from the data path [9]. The control

and management plane is responsible for processing the fire-wall bound management traffic, while the data path handlesthe traffic forwarded through the firewall.

Figure 8: Logical firewall architecture adapted from [9], de-picting the Firewall-Zone Management-data interface.

The Firewall-Zone enables each zone to communicate whileallowing restrictions to be placed on the firewall to regulateits management traffic. This model now captures the fire-wall’s dual role precisely, and can now impose restrictionssuch as disallowing HTTP access to the firewall by zone Z1(e.g., by placing ACL rules on interface e0/0).

Our solution of introducing a dedicated Firewall-Zone hasa significant impact on simplifying management policy speci-fication and auto-configuration of a firewall. It allows firewall-management and non-management traffic to be consideredequally, but to be specified separately in the auto-configurationprocess. This clean approach facilitates enforcement of fur-ther restrictions on the type of management traffic allowed(e.g., disallow Telnet), promoting compliance with industrialpolicies. Of course additional security mechanisms (e.g.,password access) are required, but these are outside the cur-rent scope of this analysis.

The zone-firewall model, now precisely captures the dis-tinct zones and their interconnections to the firewall. Itincludes implicit zones such as the Firewall-Zone requiredto facilitate firewall management and explicit zones such asthe Corporate-Zone. By compiling a model that consists ofa rich collection of these zones, their contents (i.e., networkdevices) and their respective interconnections to the fire-wall(s), we obtain a high-level view of the security strategyemployed in the SCADA network.

3.5 Carrier network abstractionReal networks commonly utilise a carrier network pro-

vided by a telecommunication service provider to intercon-nect geographically dispersed sites. This is prevalent inSCADA networks which control distributed field-site equip-ment from a centralised control centre, over for example, aleased line Wide Area Network (WAN). The traffic re-layed via the Carrier network is controlled by the securitypolicies between the zones within the two interconnectingsites (Figure 9). Due to the unavailability of every gate-way and network-device configuration for analysis, we needa way to model the interconnectivity provided by a Carriernetwork while abstracting away its underlying implementa-tion details.

Figure 9: Carrier-Zone interconnecting geographically dis-persed sites.

A simple yet effective strategy is to use a single Carrier-Zone in the zone-firewall model as shown in Figure 9, thatencompasses the Carrier network. This zone provides con-nectivity, facilitates security policy specification between thesites and abstracts away unwanted implementation details.

3.6 Service-flow ViewsA service-flow view is a directed-graph of hosts (or their

respective zones) that are allowed to initiate and/or acceptthat service protocol. The Parser generates these for the var-ious traffic classes; IP, TCP, UDP and ICMP protocols, bro-ken down by port, host and zone per traffic class. The out-put views are graphical representations based on GraphMLand can be readily viewed using tools that support the for-mat such as yEd [19].

A key goal in processing the firewall ACLs is to identifythe types of services enabled explicitly between hosts and/orsubnets and between zones. A few obstacles need to be over-come first, to gain this understanding.

Primarily, each rule-set within an ACL can contain poten-tially interacting individual rules referred to as intra-ACLinteractions. These interactions are caused by rule-overlaps,triggered by distinct rules having common packet matchingcriteria described in Subsection 3.1. An example of such ascenario is provided in Listing 1, where rule1 and rule2

both apply to HTTP packets originating at host 10.0.1.18destined to host web_svr.

In Cisco firewalls, the outcome of such a pair of rules de-pends on several factors. These include the order in whichthey are listed, the level of overlap (i.e., partial, full overlapor subset) and their rule actions. Traffic packets to whichboth rules equally apply, will be filtered via rule1 in the list(i.e.,by line 2 in Listing 1). rule2 is completely overshad-owed. Traffic packets outside the rule-overlapping region(e.g., host 10.0.1.20), that still apply to rule1 or rule2 willcontinue to be filtered by their intended rule.

Based on the extent of overlap, interacting rules can beclassified as generalisations, shadowed-rules, partial-overlapsand conflicts. A generalisation refers to the case where asubset of the packets matched to a rule has been excludedby one or more preceding rules with an identical action. Ashadowed-rule is the opposite, all packets applicable to sucha rule have already been matched by a preceding rule with anidentical action. A partial-overlap refers to the case where

1 access− l i s t a c l o v e r l a p i n remark r u l e 12 access− l i s t a c l o v e r l a p i n permit tcp 1 0 . 0 . 1 . 0 2 5 5 . 2 5 5 . 2 5 5 . 0 host web svr eq 803 access− l i s t a c l o v e r l a p i n remark r u l e 24 access− l i s t a c l o v e r l a p i n permit tcp host 1 0 . 0 . 1 . 1 8 host web svr eq 80

Listing 1: Example intra-ACL rule interaction (comments are denoted by remark).

1 access− l i s t ac l−in remark ru l e 12 access− l i s t ac l−in permit tcp host 1 0 . 0 . 1 . 2 5 host web svr eq 803

4 access− l i s t ac l−out remark r u l e 15 access− l i s t ac l−out deny tcp host 1 0 . 0 . 1 . 2 5 host web svr eq 80

Listing 2: Example inter-ACL rule interaction (comments are denoted by remark).

the set of packets matched to a rule partially-intersect withanother preceding rule with a similar action. A conflict oc-curs when the current rule intersects with preceding rulesbut specifies a different action.

We derive the net-effect of the intra-ACL interactions andgenerate an interaction free equivalent version (ACL V1) ofthe ACL. This allows to accurately view the services enabledby each ACL. As a by-product of this processing, the Parsergenerates a list of all intra-ACL interactions found. Theseinconsistencies can assist with security audits.

Secondarily, there can also exist inter-ACL interactionsthat alter a rule’s intended behaviour. Figure 10 and List-ing 2 present an example, where rule1 in acl-in permitsHTTP traffic from host 10.0.1.25 to host web_svr. The sametraffic is denied by rule1 in acl-out. Since acl-out in-evitably applies to any traffic packet traversing from zone1

to zone2, the net-effect of rule1 is the equivalent of a nullrule. Hence, the Parser also needs to analyse potential inter-ACL interactions on ACL V1, to derive a second version(ACL V2) that is interaction free. ACL V2 now reflects thenet-effect of all rule interactions possible for a given network.

Zone1

Zone2acl-in acl-outFW1

Figure 10: Zone-Firewall model for Listing 2.

The Parser also processes implicit rules based on interfacesecurity levels and generates an IP service-flow view depict-ing allowed generic traffic-flows. It processes special Ciscoconfiguration commands that permit firewall managementtraffic above ACLs. The Parser then generates correspond-ing implicit service-flow views for each service enabled.

Finally, the Parser synthesises the explicit and implicitservice-flow views to derive a comprehensive collection ofviews for each traffic class. These views accurately describethe overall services enabled through the firewall(s).

4. CASE STUDIESObtaining real firewall configurations from working SCADA

networks is very hard due to the sensitive nature of thedata, and the naturally conservative nature of the owners.We were able to obtain such configurations from 4 SCADAnetworks and a high-level summary of the Systems Under

Consideration (SUCs) is provided in Table 1. We will de-scribe one of these case studies in detail here and refer tothe other’s to illustrate findings.

Due to security concerns and non-disclosure agreementsin place, a modified version of each real SCADA networkanalysed is presented for discussion. Effort has been takento ensure that the core security strategies and underlyingissues uncovered remain intact. However, details such as IPaddresses are anonymised.

4.1 Analysed Configuration DataSUC 1 used two Cisco IOS routers. Their configurations

were extracted in September 2011. Both routers had ACLsconfigured, enabling firewall behaviour. One router (R1)consisted of 1149 Lines of Code (LoC) with 5 ACLs aver-aging 184 conventional rules each. The other router (R2)consisted of 1571 LOC with 5 ACLs averaging 290 ruleseach. Once ACLs are enabled, routers behave as firewalls.

The SUC is shown in Figure 11 which depicts the fire-walls/routers employed (IOS ver 12.2 and 12.3) in a serialconfiguration. There were no network devices connected tothe subnet between the firewalls. R1 connected to the Cor-porate network while R2 connected to the SCADA network.

Figure 11: Dual firewall SCADA network studied.

R1 has 2 physical interfaces operational, pointing to thefollowing subnets:

The Corporate network (Corp): Provides access to busi-ness applications and the Internet.Local Area network (LAN): Responsible for enabling con-nectivity between R1 and R2.

R2 has 2 physical interfaces operational, each pointingto the following subnets:

The SCADA network (SCADA): Responsible for pro-viding networked access to plant equipment.Local Area network (LAN): Responsible for enabling con-nectivity between R1 and R2.

Table 1: High-level summary of analysed SUCs (* backup firewall, ** conventional format, LoC - Lines of Code).

SUC Configurationdate

Firewall type Firewalls Gateways Zones AverageLoC

ACLs Average rulesper ACL∗∗

1 Sep 2011 Cisco IOS 2 1 2 1360 8 2372 Aug 2011 Cisco ASA 1(2)∗ 5 11 432 12 163 Oct 2011 Cisco PIX 2 2 5 125 8 64 Mar 2011 Cisco ASA 1 2 4 819 3 80

1 access− l i s t a c l t ime sync permit 1 7 2 . 2 7 . 0 . 1

access− l i s t acl snmp permit 1 7 2 . 2 7 . 1 . 3

5 access− l i s t a c l v ty1 permit 1 7 2 . 2 7 . 0 . 1 5 logaccess− l i s t a c l v ty1 permit 1 7 2 . 2 7 . 0 . 7 l ogaccess− l i s t a c l v ty1 deny any log

access− l i s t c o r p a c c e s s i n remark enable a c c e s s to SCADA s e r v e r s10 access− l i s t c o r p a c c e s s i n permit tcp host 1 7 2 . 2 7 . 1 . 6 host 1 7 2 . 1 9 . 0 . 1 eq 445

access− l i s t c o r p a c c e s s i n permit tcp host 1 7 2 . 2 7 . 1 . 6 host 1 7 2 . 1 9 . 0 . 1 eq 3389access− l i s t c o r p a c c e s s i n permit tcp host 1 7 2 . 2 7 . 1 . 1 0 4 host 1 7 2 . 1 9 . 0 . 4 eq ftp−dataaccess− l i s t c o r p a c c e s s i n permit tcp host 1 7 2 . 2 7 . 1 . 1 0 4 host 1 7 2 . 1 9 . 0 . 4 eq f tpaccess− l i s t c o r p a c c e s s i n permit tcp host 1 7 2 . 2 7 . 1 . 2 2 0 host 1 7 2 . 1 9 . 0 . 1 eq domain

15 access− l i s t c o r p a c c e s s i n permit tcp host 1 7 2 . 2 7 . 1 . 9 8 eq smtp host 1 7 2 . 1 9 . 0 . 7

Listing 3: Configuration snippet of Firewall R1 (comments are denoted by remark).

Corp could accommodate up-to 2046 hosts and SCADA ac-commodated up to 65534 hosts. There are 51 individuallyaccess controlled servers and hosts through the firewalls,across SCADA and Corp. Corp contains 12 management work-stations, 2 monitoring stations and a DNS server. SCADA

includes 8 SCADA servers, 2 DNS servers and a FTP server.Listing 3 shows a snippet of the representative configura-

tion data found on firewall R1. It reveals that both Ciscostandard and extended ACLs were used with conventionalrules. Of the 5 ACLs defined in R1, all were in use while ofthe 5 ACLs defined in R2, only 3 were in use.Corp has an extended ACL; corp_access_in assigned in-

bound on the corp firewall interface. Partially shown inListing 3, the ACL aims to enable file transfer and sharingbetween corporate users and the servers located in SCADA

using FTP and SMB. It also enables remote managementof SCADA servers from the Corp management workstationsusing RDP. It allows DNS queries between the Corp hostedDNS server and the SCADA servers. The ACL also enablesSMTP responses through to the Email clients in SCADA.

The LAN has two extended ACLs; lan1_access_in andlan2_ access_in assigned inbound on lan1 and lan2 inter-faces respectively. lan1_access_in aims to enable all ICMPmessaging between SCADA and Corp. It enables IP traffic be-tween servers in SCADA and their clients in Corp. The ACLalso allows IP traffic between selected SCADA hosts and theCorp hosted management and monitoring stations. It alsoenables SCADA mail clients to access Email servers locatedoff the Corporate gateway and permits DNS requests fromSCADA hosts to the Corp hosted DNS server.lan2_access_in is similar to corp_access_in and aims to

allow Corp user access to SCADA servers based on FTP andSMB. It too permits remote monitoring and management ofSCADA servers from selected Corp workstations using RDP.The ACL also allows clients in SCADA access to the Email

servers located off the Corporate gateway. It permits DNSrequests from SCADA hosts to the Corp hosted DNS server.

R1 also has 3 standard ACLs defined; acl_time_sync,acl_snmp, acl_vty1. acl_time_sync aims to restrict NTPbased time synchronisations to the known NTP servers lo-cated off the Corporate gateway. acl_snmp aims to restrictSNMP based alert exchanges with known SNMP servers lo-cated in the Corporate network. acl_ vty1 aims to restrictTelnet and SSH based remote access of R1 to selected hostslocated off the Corporate gateway.SCADA has an extended ACL; scada_access_in assigned

inbound on the scada interface. Similar to lan1_ access_in,this ACL aims to enable access between the SCADA hostedservers and their Corp hosted clients. The ACL also enablesIP traffic between selected SCADA hosts and the Corp hostedmonitoring and management stations. It also permits SCADAmail clients access to the Email servers located off the Cor-porate gateway. DNS traffic is also permitted by this ACLbetween SCADA hosts and Corp hosted DNS server.

R2 also has a standard ACL in use; acl_vty2 aims to re-strict Telnet and SSH based remote access of R1, to selectedhosts in SCADA, Corp as well as off the Corporate gateway.

The dual firewall solution studied did not employ NetworkAddress Translation (NAT) or a Virtual Private Network(VPN). NAT was not used because none of the networkedmachines in the SCADA subnet communicated through thefirewalls directly to the Internet. The setup of a VPN tun-nel between the firewalls and a remote host was also notrequired as the firewalls did not provide direct remote ac-cess over the Internet, and both were located at the samephysical site.

EIGRP routing was enabled on both firewalls using anidentical Autonomous System Number (ASN). A defaultroute was also present in each of the configurations, andrevealed a new gateway located off Corp. It also informed

GW1

R1 R2

Corp

SCADA

FWZ2

AZ

UZ

FWZ1

FWZ3

(a) Zone-Firewall model including gateways. (b) Zone-Conduit model of (a).

Figure 12: Security models of the network.

1 access− l i s t c o r p a c c e s s i n permit tcp host 1 7 2 . 2 7 . 0 . 2 host 1 7 2 . 1 9 . 0 . 5 eq 1352 access− l i s t c o r p a c c e s s i n permit ip host 1 7 2 . 2 7 . 0 . 2 host 1 7 2 . 1 9 . 0 . 5

Listing 4: Example intra-ACL rule interaction identified by the Parser.

us that R1 acted as the gateway for R2.The configuration also revealed that a remote Syslog server

located off the Corporate gateway was used to store localfirewall log messages. Both firewalls used the ’ip inspectname’ command to automatically build state-tables and al-low return traffic to bypass the ACLs as necessary.

SNMP messages were also enabled to be sent to a Net-work Monitoring Server (NMS) on authentication, link-upand link-down events.

Both firewalls were also configured as DHCP relay agentsfor local DHCP broadcasts.

The configurations also enabled R1 to be managed fromselected hosts in Corp as well as off Corporate gateway andfrom R2. R2 was allowed to be managed from any Corp

host, R1 and any SCADA host. Additionally R1 restrictedremote logging via the vty lines to selected hosts in Corp

using SSH only. Once remotely logged in, it also disallowedremoting out to other devices. R2 enabled remote loggingvia vty lines using Telnet or SSH.

4.2 Results:The zone-firewall model generated by parsing the config-

uration data for the System Under Consideration (SUC) isshown in Figure 12a. We can directly evaluate this modelagainst the industry recommendations in [4, 11] on suitablesecure segregation architectures for SCADA networks. Themodel falls into the category of paired-firewalls incorporat-ing an empty demilitarised zone (i.e., Abstract-Zone AZ). Italso complies with the requirement that the Internet-Zoneshould not be directly connected to the SCADA-Zone (itis reachable only via the Corporate-Zone’s gateway). Fig-ure 12b shows the corresponding zone-conduit model. It in-cludes the Firewall-Zones (FWZ1, FWZ2) and an Abstract-Zone (AZ). The latter can be leveraged to correctly capturethe individual policy requirements of the serial firewalls.

The Parser identified 167 intra-ACL interactions insidethe 4 extended ACLs applied on the firewall interfaces throughACL rule processing. These consisted of 7 generalisations,146 shadowed-rules, 12 partial-overlaps and 2 conflicts. Thegeneralisations and shadows were mostly caused by the use

of ‘any’ as source and/or destination IP address and by theuse of generic IP based rules. Listing 4 shows an example.

The Parser also identified 765 inter-ACL interactions in-volving the 4 ACLs, as summarised in Table 2. These over-laps contained 762 shadowed-rules and 3 generalisations. Anexample shadowed-rule is given in Listing 5 for the interac-tion between corp_access_in and lan2_access_in. Theseshadows consisted of many identical rules and a few differentrules, indicative of the overlapping yet distinct nature of thepolicies of serial firewalls.

Figure 13: Explicit Service-flow View of SSH traffic.

An example explicit service-flow view of SSH traffic isshown in Figure 13. We can check these service permis-sions against the industry recommendations in [5] for vio-lations. In the case of SSH, which is usually considered asecure protocol, traffic can be allowed both inbound and/oroutbound from the SCADA network [5]. Figure 13 complieswith this requirement. The service-flow view also shows theexplicit intent to allow FWZ2 to be managed via SSH fromthe Abstract-Zone but not FWZ1. This reasserts the dis-tinct policy requirements of the serial firewalls, showcasingthe need for an Abstract-Zone to separate these firewalls toaccommodate such policy specification.

The industry recommendations in [5, 12], call for trafficrestrictions between the Corporate-Zone and the SCADA-Zone. This is readily met by the SUC through the presenceof conduits C4 and C8 separating both zones in Figure 12b.Additionally, it also unveils those zones not allowed to di-rectly communicate, as in this case, the Internet-Zone and

Table 2: Inter-ACL interactions summary.

ACL1 ACL2 Interaction type Interaction count

scada_access_in lan1_access_in shadow 229corp_access_in lan2_access_in shadow 533corp_access_in lan2_access_in generalisation 3

1 access− l i s t c o r p a c c e s s i n permit ip host 1 7 2 . 2 7 . 0 . 9 6 host 1 7 2 . 1 9 . 0 . 1 0 02 access− l i s t l a n 2 a c c e s s i n permit tcp host 1 7 2 . 2 7 . 0 . 9 6 host 1 7 2 . 1 9 . 0 . 1 0 0 eq 445

Listing 5: Example inter-ACL rule interaction identified by the Parser.

the SCADA-Zone. This too is compliant with the industryrecommendations in [5, 12].

An example implicit service-flow view generated in thecase study is given in Figure 14a. It describes the genericIP traffic enabled between the Firewall-Zones and their ad-jacent zones. Since a firewall has its interfaces in each ofits adjacent security zones, all IP based traffic flow is unre-stricted between the Firewall-Zone and these adjacent zones.

Figure 14b describes the service-flow view for implicitlyenabled Telnet traffic for firewall management purposes. Itshows that Firewall R2 is allowed to be managed from boththe Corporate-Zone and SCADA-Zone using Telnet.

4.2.1 Security ViolationsIn analysing this network we found several violations of

the industry standards. These include direct transition ofpotentially unsafe traffic such as DNS, HTTP and FTPbetween the SCADA-Zone and the Corporate-Zone (Fig-ure 15). This exposed the SCADA-Zone to threats andattacks present in the Corporate -Zone. Additionally, allIP-level traffic was enabled explicitly between the SCADA-Zone and the Corporate-Zone, further elevating this risk.TFTP was also enabled from the Firewall-Zone to hosts offthe Corporate gateway. TFTP does not require user loginprior to file transfer and has been recommended by the in-dustry standards to be avoided altogether [5].

Additionally, EIGRP configuration was not carried out asper Cisco guidelines. Instead of enabling EIGRP hello mul-ticasts between neighbours, broad ACL rules were created toallow IP-level multicasts between neighbours. To accommo-date unicast EIGRP acknowledgments (responses), similarIP-level broad rules were also created.

The configurations also enabled local broadcasts to be for-warded between the firewalls using the ‘ip-forward-protocol’configuration command. However, broadcasts on UDP port80 were enabled which is not used by a common service.

4.2.2 Configuration inefficienciesOur Parser detected that every extended ACL in use con-

tained entries with incorrect source and destination IP ad-dresses. In some cases the order of the addresses were wrongwhile in others they were simply invalid. There were 70 dis-tinct occurrences of this type. The Parser also found ACLentries that attempted to explicitly block directed broad-casts from propagating between the firewalls, which wereredundant as routers by default blocked these out.

We further uncovered that ACLs were copied between thefirewalls but were left-in unused, wasting hundreds of linesin the configuration files. Additional copies were also madeof these ACLs, renamed and briefly modified to cater for the

distinct policy requirements of the serial firewalls. This ap-proach to firewall configuration, is in-efficient and accentu-ates the overlapping nature of the security policies enforcedby a serial firewall configuration.

5. CASE STUDY VARIATIONSSUC 2 and SUC 4 consisted of Cisco ASA firewalls. ASA

allows, varying security levels to be assigned to each firewallinterface (from 0 to 100), based on the security policies of thenetwork connected to that interface. The firewall configura-tions in these case studies also used object-groups to classifydevices, protocols and ports into groups. These groups werethen applied to ACLs in a single rule.

Object-groups can be very useful in practice since the sizeof a conventional ACL can be large. For example, the ACLsstudied in SUC 1 contained on average 237 conventionalrules each, as opposed to 6 in SUC 3. With frequently chang-ing rules, managing lengthy conventional ACLs is a difficulttask. Using object-group based ACLs makes ACLs smaller,more readable and easier to configure and manage. Thisand security-level are nascent attempts to provide higher-level security policy description, but as we outline here, theydon’t map clearly to the zone-conduit model.

SUC 2 enforced NAT on all traffic traversing from high-security (i.e., inside) interfaces to low-security (i.e., outside)interfaces by default. This meant that unless the trafficmatched a specified NAT rule, it was blocked by the fire-wall. To omit certain traffic having to undergo NAT trans-lation, exemptions were used. These NAT exemptions wereprovided via ACLs. Traffic that matched the ACL rules didnot have their inside addresses translated when traversingoutbound. A NAT-exemption allows both translated andremote hosts to initiate connections.

The firewall in SUC 2 also had an active/standby fail-overconfiguration enabled through a dedicated Ethernet link.This allows an identical standby firewall to take over thefunctionality of the primary unit on failure [8]. The pri-mary firewall automatically replicates its configuration tothe standby unit once special configuration commands areissued [8]. So the standby unit always has an identical mir-roring of the primary unit’s configuration. The standby unitis also accessed only via the primary unit, so both are man-aged as one using a single Firewall-Zone.

Each SUC studied included static routes, additionally SUC3 also utilised OSPF.

SUC 2 also had basic threat detection enabled on the fire-wall. This captured ACL statistics, recording packet denialrates and connection limit exceeds.

None of the other case studies (SUC 2,3 or 4) includedAbstract-Zones in their zone-conduit model. This is because

(a) Generic IP traffic.

SCADA

AZ

FWZ2

CorpFWZ1

FWZ3

(b) Telnet.

Figure 14: Implicit Service-flow Views.

(a) DNS. (b) HTTP. (c) FTP.

Figure 15: Explicit Service-flow Views of DNS, HTTP and FTP traffic.

their SUCs did not include any serial firewalls. Only SUC3 included a Carrier-Zone in its zone-conduit model. Thiszone interconnected two geographically dispersed networks.

Intra-ACL interactions were present in all SUCs analysedexcept for SUC 3. These interactions were predominantlyshadowed-rules and generalisations.

Inter-ACL interactions were also present in all SUCs. Thesewere mostly shadowed-rules caused by identical rules in dis-tinct ACLs, collectively enabling traffic flow between zones.

In all the SUCs studied, traffic restrictions were enforcedbetween the Corporate-Zone and the SCADA-Zone throughthe presence of one or more conduits in the zone-conduitmodel. Additionally there was no direct connection betweenthe SCADA-Zone and the Internet-Zone (often only reach-able via the Corporate-Zone’s gateway). These strategiesclearly met the industry recommendations in [5, 12].

In all cases we found potentially unsafe traffic such asHTTP, Telnet and SMTP explicitly disallowed inbound tothe SCADA-Zone. But in most cases, such traffic was thenimplicitly allowed to reach the same zone, breaching indus-try recommendations. In SUC 2,3 and 4 these implicit flowsstemmed from the security-levels assigned on the interfaces.

In most cases we also found explicitly allowed NTP, DNSand FTP traffic transiting directly between SCADA andCorporate Zones. This setup can easily expose the SCADA-Zone to threat or attacks present in the Corporate-Zone.

Implicit rules were used across all case studied for specify-ing firewall management traffic. SUC 3 and 4 utilised HTTPwhile SUC 2 utilised Telnet.

6. DISCUSSIONOur case studies allowed us to identify the requirements

for auto-configuration of firewalls. Most prominent is a goodset of high-level abstractions.

Implicit rules are nascent attempts to provide high-levelabstractions, but are too restrictive that you cannot writeflexible rules. For example, Cisco security levels allow quickand easy access between internal and external firewall in-terfaces, but lack the flexibility to specify detailed traffic re-strictions. Hence the large ACLs supplementing these levels.

Likewise, ANSI/ISA zone-conduit abstraction was too flex-ible, allowing alternate ways of defining zones and conduitsto cater for business models. The abstraction is good whenused by humans, but for automation we need precision.

A good abstraction is a tussle between the above two ap-proaches. It should provide clear mapping between policiesand networks, with some restrictions but also the requiredamount of flexibility.

For instance, the standards allow 1:n or n:1 mapping be-tween conduits, firewalls and policy. We argue that main-taining a 1:1 mapping between policies and conduits leadsto a simple, understandable and useful abstraction for high-level policy specification. Otherwise the ambiguity mightlead to specification of policies that breach the restrictionsimplied by a zone, i.e., a single policy within a zone.

For another instance, when firewalls are placed in series,the best practice is vague about how zones and conduitsshould be defined. We argue that there needs to be anAbstract-Zone to capture the distinct policies that could bereasonably applied to the two firewalls.

ANSI/ISA best practices also lacked specification on howto precisely capture firewall management traffic. Adding aFirewall-Zone addressed the problem.

The service-flow views generated, also play an importantrole in auto-configuration. They help verify that the net-traffic flows enabled through firewalls match those specifiedvia high-level policy. Any discrepancy would indicate flawsin the auto-configuration process.

The average firewall configuration length in our case stud-ies, was 684 lines. It is trivial to accidentally leave-in lapsedACL rules inside a lengthy configuration, when the compo-sition of network devices changes with time. These rulescan lead to potentially dangerous outcomes and keep fire-wall configurations from being concise and up-to-date. Anauto-configuration process should therefore, allow detectionand removal of obsolete rules.

ACLs and implicit rules can have complexed interactions.For example, a rule within an ACL can overlap and conflictwith other preceding rules in the same ACL, potentially al-tering or even reversing its intended effect. With lengthy

ACLs, managing interaction free rule-sets manually is a nearimpossible task but is addressable through automation.

Implicit rules can override ACLs, rendering the effort ten-dered to the careful design and deployment of ACLs ob-solete. For example, consider using security levels throughfirewall interfaces. It continues providing network access im-plicitly, in the absence of ACLs and can easily be overlooked.

We assert that the use of implicit rules should be avoidedwhere possible, and replaced with explicit ACL based accesscontrol instead. This will be the difference in being able toautomatically generate clear, simple and effective firewallconfigurations from confusing, complex and ineffective ones.

Our case studies did not comprise large, complex net-works. This simplicity implies that the task of configuringthe network firewalls should be relatively easy. Additionally,due to the critical nature of the industrial control equipmentprotected by these firewalls, one expects them to be correctlyconfigured. As we found, this is far from reality. Even inthe simplest of cases, SCADA firewalls are still badly config-ured!. Needless to say, what chances do we have of correctlyconfiguring firewalls in a large, complex network?

We have taken a significant step towards making fire-wall auto-configuration a reality. By refining the ANSI/ISAzone-conduit abstraction we make it precise and complete.Firewall configuration is complex and difficult as re-assertedby our case studies. The refined zone-conduit model, pro-vides a precise, simple yet rich high-level abstraction forfirewall policy description, that is suitable for automation.

7. CONCLUSIONS AND FUTURE WORKA SCADA firewall configuration consists of diverse config-

uration components that have complex interactions, makingit intrinsically difficult to manage manually. ANSI/ISA bestpractices provide a zone-conduit model for firewall policyspecification. However, it lacks key aspects for automationof firewall configuration.

To address the missing aspects, we proposed to use ded-icated Firewall-Zones to precisely capture firewall manage-ment traffic requirements, use Abstract Zones to capturedistinct policy requirements of serial firewalls and maintaina 1:1 mapping between policy and conduits. Through singleand multi-firewall case studies, we verified the use of theseproposed solutions for high-level policy description.

Several additional requirements of auto-configuration werealso identified through this research. Namely, eliminatingACL interactions, avoiding implicit rules, removal of lapsedrules and platform or device specific compilation of high-level policy. We hope to consolidate these requirements fur-ther to formulate a feasible firewall auto-configuration de-sign. Our end goal is to realise the design into a softwareprototype and analyse and test to unveil findings.

8. REFERENCES[1] ANSI/ISA-62443-1-1. Security for industrial

automation and control systems part 1-1:Terminology, concepts, and models, 2007.

[2] Y. Bartal, A. Mayer, K. Nissim, and A. Wool.Firmato: A novel firewall management toolkit. ACMTransactions on Computer Systems (TOCS),22(4):381–420, 2004.

[3] S. Bellovin and R. Bush. Configuration managementand security. IEEE Journal on Selected Areas inCommunications, 27(3):268–274, 2009.

[4] E. Byres. Using ANSI/ISA-99 standards to improvecontrol system security. White paper, Tofino Security,May 2012.

[5] E. Byres, J. Karsch, and J. Carter. NISCC goodpractice guide on firewall deployment for SCADA andprocess control networks. National InfrastructureSecurity Co-Ordination Centre, 2005.

[6] M. Casado, T. Garfinkel, A. Akella, M. J. Freedman,D. Boneh, N. McKeown, and S. Shenker. SANE: Aprotection architecture for enterprise networks. InUsenix Security, 2006.

[7] W. R. Cheswick, S. M. Bellovin, and A. D. Rubin.Firewalls and Internet security: repelling the wilyhacker. Addison-Wesley Longman Publishing Co.,Inc., 2003.

[8] Cisco Systems. Cisco ASA 5500 Series ConfigurationGuide using the CLI. Cisco Systems, Inc., 170 WestTasman Drive, San Jose, CA 95134-1706, USA, 2010.

[9] Cisco Systems. Cisco ASA 5585-X adaptive securityappliance architecture. White paper, Cisco Systems,May 2014.

[10] R. Jamieson, L. Land, S. Smith, G. Stephens, andD. Winchester. Critical infrastructure informationsecurity: Impacts of identity and related crimes. InPACIS, page 78, 2009.

[11] A. Mayer, A. Wool, and E. Ziskind. Fang: A firewallanalysis engine. In Security and Privacy, 2000. S&P2000. Proceedings. 2000 IEEE Symposium on, pages177–187. IEEE, 2000.

[12] K. Stouffer, J. Falco, and K. Scarfone. Guide toIndustrial Control Systems (ICS) security. NISTSpecial Publication, 800(82):16–16, 2008.

[13] T. Tuglular, F. Cetin, O. Yarimtepe, and G. Gercek.Firewall configuration management using XACMLpolicies. In 13th International TelecommunicationsNetwork Strategy and Planning Symposium, Sep, 2008.

[14] A. Wool. Architecting the lumeta firewall analyzer. InUSENIX Security Symposium, pages 85–97, 2001.

[15] A. Wool. A quantitative study of firewall configurationerrors. Computer, IEEE, 37(6):62–67, 2004.

[16] A. Wool. Trends in firewall configuration errors:Measuring the holes in Swiss cheese. InternetComputing, IEEE, 14(4):58–65, 2010.

[17] G. G. Xie, J. Zhan, D. A. Maltz, H. Zhang,A. Greenberg, G. Hjalmtysson, and J. Rexford. Onstatic reachability analysis of IP networks. InINFOCOM 2005. 24th Annual Joint Conference of theIEEE Computer and Communications Societies.Proceedings IEEE, volume 3, pages 2170–2183. IEEE,2005.

[18] H. Yan, D. A. Maltz, T. E. Ng, H. Gogineni,H. Zhang, and Z. Cai. Tesseract: A 4d network controlplane. NSDI, 7:27–27, 2007.

[19] yEd. yEd graph editor manual,http://yed.yworks.com/support/manual/index.html.

[20] L. Yuan, H. Chen, J. Mai, C.-N. Chuah, Z. Su, andP. Mohapatra. FIREMAN: A toolkit for firewallmodeling and analysis. In IEEE Symposium onSecurity and Privacy, pages 15–213. IEEE, 2006.