detecting and resolving firewall policy anomalies

Detecting and ResolvingFirewall Policy Anomalies

Hongxin Hu, Student Member, IEEE,

Gail-Joon Ahn, Senior Member, IEEE, and Ketan Kulkarni

Abstract—The advent of emerging computing technologies such as service-oriented architecture and cloud computing has enabled

us to perform business services more efficiently and effectively. However, we still suffer from unintended security leakages by

unauthorized actions in business services. Firewalls are the most widely deployed security mechanism to ensure the security of private

networks in most businesses and institutions. The effectiveness of security protection provided by a firewall mainly depends on the

quality of policy configured in the firewall. Unfortunately, designing and managing firewall policies are often error prone due to the

complex nature of firewall configurations as well as the lack of systematic analysis mechanisms and tools. In this paper, we represent

an innovative policy anomaly management framework for firewalls, adopting a rule-based segmentation technique to identify policy

anomalies and derive effective anomaly resolutions. In particular, we articulate a grid-based representation technique, providing an

intuitive cognitive sense about policy anomaly. We also discuss a proof-of-concept implementation of a visualization-based firewall

policy analysis tool called Firewall Anomaly Management Environment (FAME). In addition, we demonstrate how efficiently our

approach can discover and resolve anomalies in firewall policies through rigorous experiments.

Index Terms—Firewall, policy anomaly management, access control, visualization tool.

Ç

1 INTRODUCTION

AS one of essential elements in network and informationsystem security, firewalls have been widely deployed

in defending suspicious traffic and unauthorized access toInternet-based enterprises. Sitting on the border between aprivate network and the public Internet, a firewall examinesall incoming and outgoing packets based on security rules.To implement a security policy in a firewall, systemadministrators define a set of filtering rules that are derivedfrom the organizational network security requirements.

Firewall policy management is a challenging task due tothe complexity and interdependency of policy rules. This isfurther exacerbated by the continuous evolution of networkand system environments. For instance, Al-Shaer andHamed [1] reported that their firewall policies containanomalies even though several administrators includingnine experts maintained those policies. In addition, Wool [2]recently inspected firewall policies collected from differentorganizations and indicated that all examined firewallpolicies have security flaws.

The process of configuring a firewall is tedious and errorprone. Therefore, effective mechanisms and tools for policymanagement are crucial to the success of firewalls. Recently,policy anomaly detection has received a great deal of

attention [1], [3], [4], [5]. Corresponding policy analysis tools,such as Firewall Policy Advisor [1] and FIREMAN [5], withthe goal of detecting policy anomalies have been introduced.Firewall Policy Advisor only has the capability of detectingpairwise anomalies in firewall rules. FIREMAN can detectanomalies among multiple rules by analyzing the relation-ships between one rule and the collections of packet spacesderived from all preceding rules. However, FIREMAN alsohas limitations in detecting anomalies [3]. For each firewallrule, FIREMAN only examines all preceding rules butignores all subsequent rules when performing anomalyanalysis. In addition, each analysis result from FIREMANcan only show that there is a misconfiguration between onerule and its preceding rules, but cannot accurately indicate allrules involved in an anomaly.

On the other hand, due to the complex nature of policyanomalies, system administrators are often faced with a morechallenging problem in resolving anomalies, in particular,resolving policy conflicts. An intuitive means for a systemadministrator to resolve policy conflicts is to remove allconflicts by modifying the conflicting rules. However,changing the conflicting rules is significantly difficult, evenimpossible, in practice from many aspects. First, the numberof conflicts in a firewall is potentially large, since a firewallpolicy may consist of thousands of rules, which are oftenlogically entangled with each other. Second, policy conflictsare often very complicated. One rule may conflict withmultiple other rules, and one conflict may be associated withseveral rules. Besides, firewall policies deployed on anetwork are often maintained by more than one adminis-trator, and an enterprise firewall may contain legacy rulesthat are designed by different administrators. Thus, without apriori knowledge on the administrators’ intentions, changingrules will affect the rules’ semantics and may not resolve

318 IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 9, NO. 3, MAY/JUNE 2012

. H. Hu and G.-J. Ahn are with the Security Engineering for FutureComputing (SEFCOM) Laboratory, and the Ira A. Fulton School ofEngineering, Arizona State University, PO Box 878809, Tempe, AZ85287. E-mail: {hxhu, gahn}@asu.edu.

. K. Kulkarni is with the Emerson Network Power and the Ira A. FultonSchool of Engineering, Arizona State University, PO Box 878809 Tempe,AZ 85287. E-mail: [email protected].

Manuscript received 8 Apr. 2011; revised 5 Jan. 2012; accepted 10 Jan. 2012;published online 30 Jan. 2012.Recommended for acceptance by M. Singhal.For information on obtaining reprints of this article, please send e-mail to:[email protected], and reference IEEECS Log Number TDSC-2011-04-0097.Digital Object Identifier no. 10.1109/TDSC.2012.20.

1545-5971/12/$31.00 � 2012 IEEE Published by the IEEE Computer Society

conflicts correctly. Furthermore, in some cases, a systemadministrator may intentionally introduce certain overlaps infirewall rules knowing that only the first rule is important. Inreality, this is a commonly used technique to exclude specificparts from a certain action, and the proper use of thistechnique could result in a fewer number of compact rules [5].In this case, conflicts are not an error, but intended, whichwould not be necessary to be changed.

Since the policy conflicts in firewalls always exist and arehard to be eliminated, a practical resolution method is toidentify which rule involved in a conflict situation shouldtake precedence when multiple conflicting rules (withdifferent actions) can filter a particular network packetsimultaneously. To resolve policy conflicts, a firewalltypically implements a first-match resolution mechanismbased on the order of rules. In this way, each packet processedby the firewall is mapped to the decision of the first rule thatthe packet matches. However, applying the first-matchstrategy to cope with policy conflicts has limitations. Whena conflict occurs in a firewall, the existing first matching rulemay not be a desired rule that should take precedence withrespect to conflict resolution. In particular, the existing firstmatching rule may perform opposite action to the rule whichshould be considered to take precedence. This situation cancause severe network breaches such as permitting harmfulpackets to sneak into a private network, or dropping legaltraffic which in turn could encumber the availability andutility of network services. Obviously, it is necessary to seek away to bridge a gap between conflict detection and conflictresolution with the first-match mechanism in firewalls.

In this paper, we represent a novel anomaly managementframework for firewalls based on a rule-based segmentationtechnique to facilitate not only more accurate anomalydetection but also effective anomaly resolution. Based on thistechnique, a network packet space defined by a firewall policycan be divided into a set of disjoint packet space segments.Each segment associated with a unique set of firewall rulesaccurately indicates an overlap relation (either conflicting orredundant) among those rules. We also introduce a flexibleconflict resolution method to enable a fine-grained conflictresolution with the help of several effective resolutionstrategies with respect to the risk assessment of protectednetworks and the intention of policy definition. Besides, amore effective redundancy elimination mechanism is pro-vided in our framework, and our experimental results showthat our redundancy discovery mechanism can achieveapproximately 70 percent improvement compared to tradi-tional redundancy detection approaches [1], [6]. Moreover,the outputs of prior policy analysis tools [1], [5] are mainly alist of possible anomalies, which does not give systemadministrators a clear view of the origination of policyanomalies. Since information visualization technique [7]enables users to explore, analyze, reason, and explainabstract information by taking advantage of their visualcognition, our policy analysis tool adopts an informationvisualization technique to facilitate policy analysis. A grid-based visualization approach is introduced to representpolicy anomaly diagnosis information in an intuitive way,enabling an efficient anomaly management.1 In addition, we

implement a visualization-based firewall anomaly manage-ment environment (FAME) based on our approach. Toevaluate the practicality of our tool, our extensive experi-ments deal with a set of real-life firewall policies.

This paper is organized as follows: Section 2 overviewsthe anomalies in firewall policies. Section 3 presents ananomaly representation technique based on packet space. InSection 4, we articulate our policy anomaly managementframework. In Section 5, we address the implementationdetails and evaluations of FAME. Section 6 describesseveral important issues followed by the related work inSection 7. Section 8 concludes this paper.

2 OVERVIEW OF ANOMALIES IN FIREWALL POLICIES

A firewall policy consists of a sequence of rules that define theactions performed on packets that satisfy certain conditions.The rules are specified in the form of hcondition; actioni. Acondition in a rule is composed of a set of fields to identify acertain type of packets matched by this rule. Table 1 shows anexample of a firewall policy, which includes five firewallrules r1, r2, r3, r4, and r5. Note that the symbol “�” utilized infirewall rules denotes a domain range. For instance, a single“�” appearing in the IP address field represents an IP addressrange from 0.0.0.0 to 255.255.255.255.

Several related work has categorized different types offirewall policy anomalies [1], [5]. Based on followingclassification, we articulate the typical firewall policyanomalies:

1. Shadowing. A rule can be shadowed by one or a set ofpreceding rules that match all the packets which alsomatch the shadowed rule, while they perform adifferent action. In this case, all the packets that onerule intends to deny (accept) can be accepted(denied) by previous rule(s); thus, the shadowedrule will never be taken effect. In Table 1, r4 isshadowed by r3 because r3 allows every TCP packetcoming from any port of 10.1.1.� to the port 25 of192.168.1.�, which is supposed to be denied by r4.

2. Generalization. A rule is a generalization of one or aset of previous rules if a subset of the packetsmatched by this rule is also matched by thepreceding rule(s) but taking a different action. Forexample, r5 is a generalization of r4 in Table 1. Thesetwo rules indicate that all the packets from 10.1.1.�

are allowed, except TCP packets from 10.1.1.� to theport 25 of 192.168.1.�. Note that, as we discussedearlier, generalization might not be an error.

3. Correlation. One rule is correlated with other rules, if arule intersects with others but defines a different

HU ET AL.: DETECTING AND RESOLVING FIREWALL POLICY ANOMALIES 319

TABLE 1An Example Firewall Policy

1. Our proposed methodology can be also extended to deal with theanomalies in other kinds of policies, such as XACML-based policies [8].

action. In this case, the packets matched by theintersection of those rules may be permitted by onerule, but denied by others. In Table 1, r2 correlateswith r5, and all UDP packets coming from any port of10.1.1.� to the port 53 of 172.32.1.� match theintersection of these rules. Since r2 is a precedingrule of r5, every packet within the intersection of theserules is denied by r2. However, if their positions areswapped, the same packets will be allowed.

4. Redundancy. A rule is redundant if there is anothersame or more general rule available that has the sameeffect. For example, r1 is redundant with respect to r2

in Table 1, since all UDP packets coming from anyport of 10.1.2.� to the port 53 of 172.32.1.� matchedwith r1 can match r2 as well with the same action.

Anomaly detection algorithms and corresponding toolswere introduced by [1], [5] as well. However, existingconflict classification and detection approaches only treat apolicy conflict as an inconsistent relation between one ruleand other rules. Given a more general definition on policyconflict as shown in Definition 1, we believe that identifyingpolicy conflicts should always consider a firewall policy as awhole piece, and precise indication of the conflictingsections caused by a set of overlapping rules is critical foreffectively resolving the conflicts.

Definition 1 (Policy Conflict). A policy conflict pc in a firewallF is associated with a unique set of conflicting firewall rulescr ¼ fr1; . . . ; rng, which can derive a common network packetspace. All packets within this space can match exactly the sameset of firewall rules, where at least two rules have differentactions: Allow and Deny.

Similarly, we give a general definition for rule redun-dancy in firewall policies as follows, which serves as afoundation of our redundancy elimination approach.

Definition 2 (Rule Redundancy). A rule r is redundant in afirewallF iff the network packet space derived from the resultingpolicy F 0 after removing r is equivalent to the network spacedefined by F . That is, F and F 0 satisfy following equations:SAF ¼ SAF 0 andSDF ¼ SDF 0 , whereSA andSD denote allowed anddenied network packet spaces, respectively.

3 ANOMALY REPRESENTATION BASED ON PACKET

SPACE

3.1 Packet Space Segmentation and Classification

As we discussed in Section 2, existing anomaly detectionmethods could not accurately point out the anomalyportions caused by a set of overlapping rules. In order toprecisely identify policy anomalies and enable a moreeffective anomaly resolution, we introduce a rule-basedsegmentation technique, which adopts a binary decisiondiagram (BDD)-based data structure to represent rulesand perform various set operations, to convert a list of rulesinto a set of disjoint network packet spaces. This techniquehas been recently introduced to deal with several researchproblems such as network traffic measurement [9], firewalltesting [10] and optimization [11]. Inspired by thosesuccessful applications, we leverage this technique for the

purpose of firewall policy anomaly analysis. Algorithm 1shows the pseudocode of generating packet space segmentsfor a set of firewall rules R.2 This algorithm works byadding a network packet space s derived from a rule r to apacket space set S. A pair of packet spaces must satisfy oneof the following relations: subset (line 5), superset (line 10),partial match (line 13), or disjoint (line 17). Therefore, one canutilize set operations to separate the overlapped spaces intodisjoint spaces.

A set of segments S : fs1; s2; . . . ; sng from firewall ruleshas the following two properties:

1. All segments are pairwise disjoint: si \ sj ¼ ;;where 1 � i 6¼ j � n; and

2. Any two different network packets p and p0 withinthe same segment (si) are matched by the exact sameset of rules: GetRuleðpÞ ¼ GetRuleðp0Þ; 8p 2 si; p0 2si; p 6¼ p0, where GetRuleðÞ is a function to return allmatched rules of a network packet.

To facilitate the correct interpretation of analysis results,a concise and intuitive representation method is necessary.For the purposes of brevity and understandability, weemploy a two-dimensional geometric representation foreach packet space derived from firewall rules. Note that afirewall rule typically utilizes five fields to define the rulecondition; thus, a complete representation of packet spaceshould be multidimensional. Fig. 1a gives the two-dimen-sional geometric representation of packet spaces derivedfrom the example policy shown in Table 1. We utilizecolored rectangles to denote two kinds of packet spaces:allowed space (white color) and denied space (gray color),respectively. In this example, there are two allowed spacesrepresenting rules r3 and r5, and three denied spacesdepicting rules r1, r2, and r4.

Two spaces overlap when the packets matching twocorresponding rules intersect. For example, r5 overlaps withr2, r3, and r4, respectively. An overlapping relation mayinvolve multiple rules. In order to clearly represent allidentical packet spaces derived from a set of overlapping


2. Similar partitioning functionalities were addressed in [9], [10] as well.

rules, we adopt the rule-based segmentation techniqueaddressed in Algorithm 1 to divide an entire packet spaceinto a set of pairwise disjoint segments. We classify thepolicy segments as follows: nonoverlapping segment andoverlapping segment, which is further divided into conflictingoverlapping segment and nonconflicting overlapping segment.Each nonoverlapping segment associates with one uniquerule and each overlapping segment is related to a set of rules,which may conflict with each other (conflicting overlappingsegment) or have the same action (nonconflicting overlappingsegment). Fig. 1b demonstrates the segments of packetspaces derived from the example policy. Since the size ofsegment representation does not give any specific benefitsin resolving policy anomalies, we further present a uniformrepresentation of space segments in Fig. 1c. We can noticethat seven unique disjoint segments are generated. Threepolicy segments s2, s4, and s7 are nonoverlapping segments.Other policy segments are overlapping segments, includingtwo conflicting overlapping segments s3 and s5, and twononconflicting overlapping segments s1 and s6.

3.2 Grid Representation of Policy Anomaly

To enable an effective anomaly resolution, complete andaccurate anomaly diagnosis information should be repre-sented in an intuitive way. When a set of rules interacts, oneoverlapping relation may be associated with several rules.Meanwhile, one rule may overlap with multiple other rulesand can be involved in a couple of overlapping relations(overlapping segments). Different kinds of segments andassociated rules can be viewed in the uniform representationof anomalies (Fig. 1c). However, it is still difficult for anadministrator to figure out how many segments one rule isinvolved in. To address the need of a more precise anomalyrepresentation, we additionally introduce a grid representa-tion that is a matrix-based visualization of policy anomalies,in which space segments are displayed along the horizontal

axis of the matrix, rules are shown along the vertical axis,and the intersection of a segment and a rule is a grid thatdisplays a rule’s subspace covered by the segment.

Fig. 2 shows a grid representation of policy anomalies forour example policy. We can easily determine which rulesare covered by a segment, and which segments areassociated with a rule. For example, as shown in Fig. 2,we can notice that a conflicting segment (CS) s5, whichpoints out a conflict, is related to a rule set consisting ofthree conflicting rules r3, r4, and r5 (highlighted with ahorizontal red rectangle), and a rule r3 is involved in threesegments s5, s6, and s7 (highlighted with a vertical redrectangle). Our grid representation provides a better under-standing of policy anomalies to system administrators withan overall view of related segments and rules.

4 ANOMALY MANAGEMENT FRAMEWORK

Our policy anomaly management framework is composed oftwo core functionalities: conflict detection and resolution, andredundancy discovery and removal, as depicted in Fig. 3. Bothfunctionalities are based on the rule-based segmentationtechnique. For conflict detection and resolution, conflictingsegments are identified in the first step. Each conflictingsegment associates with a policy conflict and a set ofconflicting rules. Also, the correlation relationships amongconflicting segments are identified and conflict correlationgroups (CG) are derived. Policy conflicts belonging todifferent conflict correlation groups can be resolved sepa-rately; thus, the searching space for resolving conflicts isreduced by the correlation process. The second stepgenerates an action constraint for each conflicting segmentby examining the characteristics of each conflicting segment.A strategy-based method is introduced for generating action


Fig. 2. Grid representation of policy anomaly. Fig. 3. Policy anomaly management framework.

Fig. 1. Packet space representation derived from the example policy.

constraints. The third step utilizes a reordering algorithm,which is a combination of a permutation algorithm and agreedy algorithm, to discover a near-optimal conflict resolu-tion solution for policy conflicts. Regarding redundancydiscovery and removal, segment correlation groups are firstidentified. Then, the process of property assignment isperformed to each rule’s subspaces. Consequently, redun-dant rules are identified and eliminated.

4.1 Correlation of Packet Space Segment

Technically, one rule may get involved in multiple policyanomalies. In this case, resolving one anomaly in an isolatedmanner may cause the unexpected impact on otheranomalies. Similarly, we cannot resolve a conflict individu-ally by only reordering conflicting rules associated with oneconflict without considering possible impacts on otherconflicts. On the other hand, it is also inefficient to dealwith all conflicts together by reordering all conflicting rulessimultaneously. Therefore, it is necessary to identify thedependency relationships among packet space segments forefficiently resolving policy anomalies.

Fig. 4 shows an example of segment correlation.3 Supposewe add three new rules r6, r7, and r8 in the example policyshown in Table 1. Several rules in this firewall policy areinvolved in multiple anomalies. For example, r2 is associatedwith three segments s1, s2, and s3. Also, we can identify r3, r5,r6, and r7 are also associated with multiple segments. Assumewe need to resolve the conflict related to a conflicting segments3 by reordering associated conflicting rules, r2 and r5. Theposition change of r2 and r5 would also affect other segments,s1, s2, s4, s5, and s6. Thus, a dependency relationship amongthose segments can be derived. We cluster such segmentswith a dependency relationship as a group called correlationgroup. Consequently, two correlation groups, group1 andgroup2, can be identified in our example as shown in Fig. 4:group1 contains seven segments and a rule set with fiveelements (r1, r2, r3, r4, and r5); and group2 includes threesegments and three associated rules, r6, r7, and r8.

The major benefit of generating correlation groups forthe anomaly analysis is that anomalies can be examinedwithin each group independently, because all correlationgroups are independent of each other. Especially, thesearching space for reordering conflicting rules in conflictresolution can be significantly lessened and the efficiency ofresolving conflicts can be greatly improved.

4.2 Conflict Resolution

Each conflicting segment indicates a policy conflict as wellas a set of conflicting rules involved in the conflict. Onceconflicts are identified, a possible way for a systemadministrator to resolve conflicts is to manually changethe conflicting rules. However, as we addressed in Section 1,resolving all conflicts manually is a tedious task and evenimpractical due to the complicated nature of policyconflicts. Thus, a practical and effective method to resolvea policy conflict is to determine which rule should takeprecedence when a network packet is matched by a set ofrules involved in the conflict. In order to utilize the existingfirst-match conflict resolution mechanism implemented incommon firewalls, the rule expected to take precedenceneeds to be moved to the first-match rule.

Our conflict resolution mechanism introduces that anaction constraint is assigned to each conflicting segment. Anaction constraint for a conflicting segment defines a desiredaction (either Allow or Deny) that the firewall policyshould take when any packet within the conflicting segmentcomes to the firewall. Then, to resolve a conflict, we onlyassure that the action taken for each packet within theconflicting segment can satisfy the corresponding actionconstraint. A key feature of this solution is that we do notneed to move a rule expected to take precedence to the first-match rule at all times. Any rule associated with the conflicton the same action (as a rule with the precedence) can bemoved to the first-match rule, guaranteeing the same effectwith respect to the conflict resolution. Thus, it is doable toobtain an optimal solution for conflict resolution.

4.2.1 Action Constraint Generation

To generate action constraints for conflicting segments, wepropose a strategy-based conflict resolution method, whichgenerates action constraints with the help of effectiveresolution strategies based on the minimal interaction withsystem administrators. Fig. 5 shows the main processes ofthis method, which incorporates both automated and manualstrategy selections.

Once conflicts in a firewall policy are discovered andconflict correlation groups are identified, the risk assessmentfor conflicts is performed. The risk levels (RL) of conflicts are


Fig. 4. Example of segment correlation.

Fig. 5. Strategy-based conflict resolution.

3. Note that for conflict resolution we only need to examine thecorrelation relations among conflicting segments.

in turn utilized for both automated and manual strategyselections. A basic idea of automated strategy selection is thata risk level of a conflicting segment is used to directlydetermine the expected action taken for the network packetsin the conflicting segment. If the risk level is very high, theexpected action should deny packets considering the protec-tion of network perimeters. On the contrary, if the risk level isquite low, the expected action should allow packets to passthrough the firewall so that the availability and usage ofnetwork services cannot be affected. Thus, conflict resolutionstrategies (RS) can be generated automatically for partialconflict segments by comparing the risk levels with twothresholds, upper threshold (UT ) and lower threshold (LT ),which can be set by system administrators in advance basedon the different situations of protected networks. If a risklevel of a conflicting segment is between the upper thresholdand the lower threshold, system administrators need toexamine the characteristics of each conflict, and manuallyselect appropriate strategies for resolving the conflict,considering both network situations (e.g., risk levels ofconflicts) and contexts associated with conflicting rules(e.g., priorities, creation time, authors, and so on). Thus, afine-grained conflict resolution can be carried out withhuman cognition via the interaction facility with systemadministrators. Since some strategies may be nondetermi-nistic and could not generate a concrete action constraintwhen applying to a conflict, system administrators need toadjust the strategy assignments accordingly. As long as allconflicts within a conflict correlation group are associatedwith desired action constraints, these conflicts will beultimately resolved by reordering conflicting rules to satisfycorresponding action constraints.

Risk (security) levels are determined based on thevulnerability assessment of the protected network. We haverecently seen a number of attempts for qualitativelymeasuring risks in a network [12], [13], [14]. In our work,we adopt the Common Vulnerability Scoring System (CVSS)[15] as an underlying security metrics for risk evaluation.Two major factors, exploitability of vulnerability (reflecting thelikelihood of exploitation) and severity of vulnerability(representing the potential damage of exploitation), areutilized to evaluate the risk level of a network system. Besidethose two factors, another important factor in determiningthe criticality of an identified security problem is assetimportance value. Normally, system administrators place ahigher priority on defending critical servers than noncriticalPCs. Similarly, some machines are more valuable thanothers. We use asset importance value to represent a service’sinherent value to network attackers or system administra-tors. Since the CVSS base score can cover both exploitability ofvulnerability and severity of vulnerability factors, we incorpo-rate the CVSS base score and asset importance value to computethe risk value for each vulnerability as follows:

Risk V alue ¼ ðCV SS Base ScoreÞ � ðImportance V alueÞ:ð1Þ

To calculate the risk level of each conflicting segment, weaccumulate all risk values of the vulnerabilities covered bya conflicting segment. In practice, system administratorsmay mainly concern about the security risk (SR) of eachvulnerability in their network. In this case, an average risk

value needs to be calculated as the risk level of a conflictingsegment. In order to accommodate both requirements forrisk evaluation of a conflicting segment, we introduce ageneric equation for the risk level calculation as follows:

RLðcsÞ ¼P

v2V ðcsÞðCV SSðvÞ � IV ðsÞÞ�� jV ðcsÞj ; ð2Þ

where V ðcsÞ is a function to return all vulnerabilities that arecontained in a conflicting segment cs; CV SSðvÞ is a functionto return the CVSS base score of vulnerability v; and IV ðsÞ is afunction to return the importance value (with the range from0.0 to 1.0) of service s. Also, we incorporate a coefficient factor� ( 1

jV ðcsÞj � � � 1) that allows system administrators toexpress their preferences in choosing average or overall riskvalue to measure the risk of each conflicting segment. Thevalue of � can be decreased, in which case an administratorcares more about the overall risk value. Otherwise, she/he canincrease the value of � until it reaches an average risk value.

Some general conflict resolution strategies for accesscontrol have been introduced [16], [17], [18]. We classifyconflict resolution strategies for firewall policies into twocategories: network situation-aware strategy and policy-oriented strategy. Note that other user-defined strategies [19]can be implied in our conflict resolution mechanism as well.

Network situation-aware strategy. A system adminis-trator adopts this strategy to resolve policy conflicts basedon the results of risk assessment of the network covered bycorresponding conflicting segments

. Deny-overrides. This strategy indicates that “deny”rules take precedence over “allow” rules. In general,a system administrator may directly take thisstrategy to harden his network if the risk level of aconflict is very high.

. Allow-overrides. This strategy states that “allow”rulestake precedence over “deny” rules. A systemadministrator may apply this strategy to resolve aconflict, which has a lower risk level.

Policy-oriented strategy. This strategy considers thefactors related to the policy definition, such as when wasthe rule defined? what was the rule defined for? and whodefined the rule?

. Recency-overrides. This strategy indicates that rulestake precedence over rules specified earlier. As thesecurity requirements may change over a period oftime, an administrator may define new rules alongwith his evolving security requirements which maybe in conflict with previous security requirements.Obviously, in this case, newer rules should takeprecedence over older rules.

. Specificity-overrides. This strategy states that a morespecific rule overrides more general rules. In afirewall policy, shadowing and generalization con-flicts can be identified by conflict detection tools. Inour solution, we treat shadowing and generalizationconflicts as the same case, since we resolve themthrough rule reordering.

. High-majority-overrides. This strategy allows (denies,respectively) a packet if the number of rules taking


“allow” (“deny,” respectively) action is greater thanthe number of rules taking “allow” (“deny,” respec-tively) action.

. First-match-overrides. This strategy states that the firstmatched rule takes precedence over others. Thisstrategy can be directly converted to the existingfirewall implementation.

. High-authority-overrides. This strategy states that arule defined by an administrator with a higherauthority level takes precedence.

Since some strategies are nondeterministic and adoptingonly one strategy may not guarantee solving the conflict, itis desirable to combine multiple strategies together to fulfilthe requirements of conflict resolution posed by a policy.Our previous work in [20], [21] proposed a strategy chain toaddress this issue and we incorporate such a strategy chainin our firewall conflict resolution mechanism. Once eachconflicting segment has been assigned to appropriateconflict resolution strategies, action constraints can begenerated based on the assigned strategies. Table 2summarizes the constraint generation from those strategies.

4.2.2 Rule Reordering

The most ideal solution for conflict resolution is that allaction constraints for conflicting segments can be satisfiedby reordering conflicting rules. In other words, if we canfind out conflicting rules in order that satisfies all actionconstraints, this order must be the optimal solution for theconflict resolution. Unfortunately, in practice action con-straints for conflicting segments can only be satisfiedpartially in some cases.

Fig. 6 illustrates a scenario representing that actionconstraints cannot be fully satisfied. In this scenario, fourrules intersect with each other in different conflictingsegments. The existing order of rules cannot satisfy thefourth action constraint. In order to make the fourth actionconstraint satisfied, r4 needs to be moved in front of r1.However, this situation causes the violation against the

third action constraint. We can easily observe that all actionconstraints cannot be satisfied simultaneously by anypermutation of conflicting rules in this scenario.

A naive way to find an optimal solution is to exhaus-tively search all permutations of correlated conflictingrules. We then compute a resolving score for eachpermutation by counting how many action constraints canbe satisfied, and select the permutation with the maximumresolving score as the best solution for a conflict resolution.However, a key limitation of using the permutationalgorithm is its computational complexity which is Oðn!Þ.Even though the search space can be significantly reducedby applying our correlation scheme, the number ofcorrelated conflicting rules may still be large, leading tothe permutation algorithm unapplicable. Since the permu-tation algorithm is time intensive and can be only used toidentify an optimal reordering for a small set of correlatedconflicting rules, an approximation algorithm is moredesirable. Although approximation algorithms can onlyfind a near-optimal solution, they are more efficient infinding a solution comparing to the permutation algorithm.To address this issue, we introduce a greedy algorithm,which can be employed to resolve the conflicts containing alarger number of correlated conflicting rules.

A greedy algorithm makes the locally optimal choice ateach stage with the hope of finding the global optimum. Forall conflicting rules in a correlation group, our greedyconflicting resolution algorithm first calculates a resolvingscore for each conflicting rule individually. Then, the rulewith the greatest resolving score is selected to solve theconflicts: a position range with the best conflict resolution isidentified for the selected rule; and moving the selected ruleto the new position achieves a locally optimal conflictingresolution. Applying the same processes to the remainingrules recursively until all rules in the correlation group areprocessed, the final order of the correlated conflicting rulesis a solution of the conflict resolution. Note that theresolving scores for the remainder of rules should berecalculated, since moving a rule may change the originalconflicting situation of a policy.

In our greedy algorithm, a critical process is to calculatethe resolving score for each conflicting rule within a conflictcorrelation group. This process contains four steps as follows:

1. Generating position indicators for each conflicting seg-ment. A position indicator of a rule for a conflictingsegment indicates a position range in which this rulecan stay so that the action constraint of the conflictingsegment is satisfied. Fig. 7 gives an example, which


TABLE 2Constraint Generation from Conflict Resolution Strategy

Fig. 6. Partial satisfaction of action constraints.

Fig. 7. Example of position indicators for a rule.

demonstrates the generation of position indicators fora rule r8. The rule r8 in this example involves in fourconflicts. In order to fulfill the action constraint of thefirst conflicting segment (cs1), r8 should stay after r2.Thus, a position indicator (pi1) can be generated as:Positionðr8Þ > 2. To satisfy the action constraint ofthe second conflicting segment, r8 needs to be movedin front of r5. Another position indicator (pi2) isgenerated as: Positionðr8Þ � 5.

2. Generating position ranges. Based on the positionindicators generated for a rule, we sort the rangebounds in an ascending order, and then employ aplane sweeping technique [22] to obtain the disjointposition ranges (pr) for the rule. Using the sameexample in Fig. 7, two position indicators pi1 and pi2can identify three ranges for the selected rule:pr1 : ½1; 2�, pr2 : ½2; 5�, and pr3 : ½5; 8�.

3. Calculating a resolving score for each position range.The resolving score of a position range representsthe impact of resolving conflicts when moving theselected rule to this position range. Moving theselected rule to a position range satisfies someaction constraints, but may also violate some otheraction constraints. Thus, the resolving score for aposition range with respect to the selected rule canbe calculated by subtracting the number of violatedaction constraints from the number of satisfiedaction constraints. For example, if we move r8 to therange pr1. The resolving score in this case is equal to0, since the action constraint of cs1 will be satisfiedbut the action constraint of cs2 will be violated insuch a particular situation.

4. Choosing the maximum range score as the resolving scoreof selected rule. Since one rule may have multipleassociated position ranges. In order to achieve theeffectiveness of conflict resolution, it is necessary tomove the rule to a position in the range with themaximum resolving score. Thus, we use the max-imum resolving score of a position range torepresent the resolving score of selected rule.

In order to achieve the objective of resolving conflictseffectively and efficiently, our conflict resolution mechanismadopts a combination algorithm4 incorporating featuresfrom both permutation and greedy algorithms. A thresholdN for selecting a suitable rule reordering algorithm toresolve a conflict can be predefined in the combinationalgorithm. When the number of conflicting rules is less thanN , the permutation algorithm is utilized for resolvingconflicts. Otherwise, the greedy algorithm is applied toresolve conflicts.

4.3 Redundancy Elimination

In this step, every rule subspace covered by a policy

segment is assigned with a property. Four property values,

removable (R), strong irremovable (SI), weak irremovable (WI),

and correlated (C), are defined to reflect different character-

istics of each rule subspace. Removable property is used to

indicate that a rule subspace is removable. In other words,

removing such a rule subspace does not make any impact

on the original packet space of an associated policy. Strongirremovable property means that a rule subspace cannot beremoved because the action of corresponding policysegment can be decided only by this rule. Weak irremovableproperty is assigned to a rule subspace when any subspacebelonging to the same rule has strong irremovable property.That means a rule subspace becomes irremovable due to thereason that other portions of this rule cannot be removed.Correlated property is assigned to multiple rule subspacescovered by a policy segment, if the action of this policysegment can be determined by any of these rules. We nextintroduce three processes to perform the property assign-ments to all of rule subspaces within the segments of afirewall policy, considering different categories of policysegments discussed in Section 3.1

1. Property assignment for the rule subspace covered by anonoverlapping segment. A nonoverlapping segmentcontains only one rule subspace. Thus, this rulesubspace is assigned with strong irremovable prop-erty. Other rule subspaces associated with the samerule are assigned with weak irremovable property,except for the rule subspaces that already havestrong irremovable property.

2. Property assignment for rule subspaces covered by aconflicting segment. The first rule subspace coveredby the conflicting segment is assigned with strongirremovable property. Other rule subspaces in thesame segment are assigned with removable property.Meanwhile, other rule subspaces associated withthe first rule are assigned with weak irremovableproperty except for the rule subspaces with strongirremovable property.

3. Property assignment for rule subspaces covered by anonconflicting overlapping segment. If any rule sub-space has been assigned with weak irremovableproperty, other rule subspaces without any irremo-vable property are assigned with removable property.Otherwise, all subspaces within the segment areassigned with correlated property.

Fig. 8 illustrates the result of applying our propertyassignment approach, which performs three property assign-ment processes in sequence, to a firewall policy with eightrules. We can easily identify that three rules, r3, r5, and r8, areremovable rules, where the removable property is assigned to


Fig. 8. Example of property assignment.

4. The pseudocode of conflict resolution algorithm is omitted in thispaper due to the space limitation.

all subspaces. In addition, by examining the correlated rulesr2, r4, and r7, which contain some subspaces with correlatedproperty, r2 and r7 can be identified as redundant rules andremoved from the policy. However, if we leverage traditionalredundancy detection method [1], [6], which is limited todetect pairwise redundancies, to this example, only tworedundant rules r2 and r7 can be discovered.

5 IMPLEMENTATION AND EVALUATION

Our framework is realized as a proof-of-concept prototypecalled Firewall Anomaly Management Environment. Fig. 9shows a high-level architecture of FAME with two levels.The upper level is the visualization layer, which visualizesthe results of policy anomaly analysis to system admin-istrators. Two visualization interfaces, policy conflict viewerand policy redundancy viewer, are designed to managepolicy conflicts and redundancies, respectively. The lowerlevel of the architecture provides underlying functional-ities addressed in our policy anomaly managementframework and relevant resources including rule informa-tion, strategy repository, network asset information, andvulnerability information.

5.1 Implementation of Anomaly ManagementFramework in FAME

FAME was implemented in Java. Based on our policyanomaly management framework, it consists of six compo-nents: segmentation module, correlation module, riskassessment module, action constraint generation module,rule reordering module, and property assignment module.The segmentation module takes firewall policies as an inputand identifies the packet space segments by partitioning thepacket space into disjoint subspaces. FAME utilizesOrdered Binary Decision Diagrams5 to represent firewallrules and perform various set operations, such as unions([), intersections (\), and set differences (n), required by thesegmentation algorithm. A BDD library called JavaBDD[24], which is based on BuDDy package [25], is employedby FAME. Once the segmentation of packet space is

identified, FAME further identifies different kinds ofsegments and corresponding correlation groups. In riskassessment module, Nessus [26] is utilized as a vulnerability

scanner to identify the vulnerabilities within a conflictingsegment. Network address space of each conflictingsegment is fed into Nessus to get the vulnerabilityinformation of a given address space. Nessus producesthe vulnerability information in a “nbe” format. The riskassessment module utilizes tissynbe script [27] to parse theNessus results and store the vulnerability information to avulnerability database. A risk calculator retrieves vulnerabilityinformation, such as CVSS base score and asset importancevalue, to calculate the risk level of each conflicting segment.

5.2 Implementation of Visualization Interfaces inFAME

FAME provides two policy viewers to visualize the outputsof policy conflict analysis and policy redundancy analysis.Each viewer offers two kinds of visualization interfaces: oneinterface shows an entire snapshot of all anomalies; anotherinterface shows a partial snapshot only containing anoma-lies within one correlation group.

Fig. 10 depicts interfaces of FAME conflict viewer. Thegrid representation shows accurately how a set of rulesinteracts with each other. FAME conflict viewer has theability to show an overview of the entire conflicts as well asportions of the policy conflicts, that need to be examined indepth for conflict resolution, based on correlation groups.As illustrated in Fig. 10a, all conflicting segments andconflict correlation groups are displayed along the hor-izontal axis at the top of the interface. All conflicting rulesare shown along the vertical axis at the left of the interface.Each grid cell represents a rule’s subspace. In our interface,the icons for conflicting segments indicate four differentstates with respect to conflicting resolution. One iconrepresents a conflicting segment with the state of strategyunassigned. Two other icons indicate conflicting segmentswith the state of strategy assigned with “Allow” actionconstraint and strategy assigned with “Deny” actionconstraint, respectively. The fourth icon indicates a con-flicting segment with the state of conflict unresolved. Inaddition, this interface allows an administrator to set therisk level thresholds for automatically assigning strategies.

Clicking on a group name box of the interface in Fig. 10a,another window as shown in Fig. 10b is displayed with thetargeted conflicts that an administrator needs to examineand resolve. In this interface, the number of visible entitiesis reduced to only display conflicting segments in onecorrelation group and a list of conflicting rules associatedwith this group. This significantly eliminates administra-tors’ workloads in resolving conflicts by highlightingconflicts within a group. For resolution strategy selection,the administrator needs to further examine rule informationfor selecting suitable strategies for each conflicting segment.When the administrator clicks the icon of a conflictingsegment, the detailed information related to the conflict isdisplayed in a window as shown in Fig. 10c.6


Fig. 9. Architecture of FAME.

5. BDD has been demonstrated as an efficient data structure to deal witha variety of network configuration analysis [5], [23].

6. FAME redundancy viewer was also developed in a similar fashion.We elide the discussion of redundancy viewer in this paper.

5.3 Evaluation of FAME

For FAME evaluation, we utilized a number of firewallpolicies and associated information required by our toolfrom different resources. Most of them are from campusnetworks and some are from major ISPs. Our experimentswere performed on Intel Core 2 Duo CPU 3.00 GHz with3.25 GB RAM running on Linux kernel 2.6.16.

5.3.1 Evaluation of Conflicting Segment Generation and

Correlation

Table 3 shows the evaluation results generated by thesegmentation and correlation engine of FAME. The numberof conflicting segments, the number of conflict correlationgroups, the number of large conflict correlation groups (therule number is greater than six) and the number ofconflicting rules in the largest correlation group are givenin this table, which also contains the execution timerequired by the segmentation module of FAME foridentifying conflicting segments (i.e., detecting conflicts),as well as the one required by the correlation module ofFAME for identifying correlation groups among conflictingsegments. Note that all measurements were based on thesystem time stamps in our experiments.

In Table 3, the number of large conflict correlationgroups and the number of conflicting rules in the largestcorrelation group give us the evidences that manual conflictresolution for a large size of firewall policies is almostimpossible. Also, we can observe that the segmentation andcorrelation processes are efficient enough to handle a largersize of firewall policies, such as policy G and policy H inthe table.

5.3.2 Evaluation of Conflicting Rule Reordering

Algorithm

We have addressed that permutation and greedy algorithmscan be used for reordering conflicting rules, and our conflictresolution mechanism utilizes a combination algorithmincorporating the features of both permutation and greedyalgorithms to achieve a more effective and efficient conflictresolution. In order to evaluate our proposed method, wemeasured the effectiveness and efficiency of three algo-rithms implemented in the rule reordering module of FAMEusing two metrics, resolved conflicts (RC) and resolving time.

Table 4 summarizes our evaluation results. It shows thatthe permutation algorithm can always achieve an optimalconflict resolution for all policies except policy H. We wereunable to resolve the conflicts in policy H using thepermutation algorithm, because there exist a larger size ofconflicting rules in some correlation groups. From Table 3,we can notice that the number of the largest group memberof policy H is eighteen. Also, it shows that the resolving timerequired by the permutation algorithm increases exponen-tially as the number of conflicting segments increases.Hence, the permutation algorithm is infeasible to thepolicies with a large size of conflicting rules, although itcan achieve an optimal solution.

Regarding the greedy algorithm, Table 4 shows that itcan only achieve a near-optimal conflict resolution for allfirewall policies. However, as the size of conflicting rulesincreases, the time taken by the greedy algorithm increasesalmost linearly as opposed to an exponential increase incase of using the permutation algorithm.


Fig. 10. Interface of FAME conflict viewer.

TABLE 3Segmentation and Correlation Evaluation

TABLE 4Rule Reordering Algorithm Evaluation

For the combination algorithm with the default threshold(N ¼ 6), the results in Table 4 show that the number ofresolved conflicts by the combination algorithm is greaterthan the greedy algorithm and almost equal to the optimalsolution achieved by the permutation algorithm. Thecomputation time is acceptable for all policies as well.Therefore, it represents higher efficiency and effectivenessin conflict resolution.

5.3.3 Evaluation of the Effectiveness of Conflict

Resolution Approach

Three metrics, resolution rate, risk reduction, and availabilityimprovement, were adopted to evaluate the quality ofconflict-resolved policies generated by our conflict resolu-tion approach. We adopted average risk value (from 0.0 to10.0) as the risk level of each conflict segment, and fixedupper and lower thresholds as 8.0 and 2.0, respectively, inour experiments.

First, we evaluated the conflict resolution rate of ourstrategy-based approach, which is reflected by the numberof resolved conflicts (i.e., satisfied action constraints). Wecompared the results of applying our strategy-basedapproach with the results of directly applying the existingfirst-match mechanism for conflict resolution. As shown inFig. 11a, we could observe that directly applying theexisting first-match mechanism can only solve an average63 percent of conflicts. However, when applying ourstrategy-based approach, an average 92 percent of conflictscould be resolved in our experiments. Moreover, for somesmall-scale policies, we noticed that FAME was capable ofresolving all policy conflicts.

In general, when conflicts in a policy are resolved, therisk value of the resolved policy should be reduced and theavailability of protected network should be improvedcomparing with the situation prior to conflict resolution.To evaluate the risk reduction and availability improvementof our conflict resolution approach, we compared theresults of conflict-resolved policies with the original policiesas well as the best case and worst case with respect to theconflict resolution. The best case of a conflict resolution isachieved when all action constraints assigned to theconflicting segments can be satisfied. The worst caseconsidering the security risk is that all packets covered byconflicting segments are allowed to pass through a firewall.And the worst case considering the availability is that allpackets covered by conflicting segments assigned with“allow” action constraints are denied.

We evaluated each policy described in Table 3 based on therisk values caused by corresponding conflicts, consideringfour situations: worst case, best case, original policy, and resolvedpolicy. The security risk value of a policy (p) can be calculatedby aggregating the risk levels of conflicting segments that take“allow” action to any matched packets as follows:

SRðpÞ ¼X

csi2CSðpÞ:isAllowedðÞRLðcsiÞ: ð3Þ

Note that CS(p) returns all conflicting segments of apolicy (p) and the function isAllowed() is used to identify allconflicting segments taking “allow” actions. From Fig. 11b,we noticed that the security risk values of the conflict-resolved policies are always reduced, compared to thesecurity risk value of the original policies. Our experimentsshowed that FAME could achieve an average 45 percent ofrisk reduction. We could also notice that the security riskvalues of the conflict-resolved policies are very close to thesecurity risk values of the best case. It further indicates thatFAME can achieve a higher rate of conflict resolution.

To measure the impact of conflict resolution on networkavailability, we were able to calculate an availability loss (AL)value for each policy. Computing the availability loss valuefor a policy only need to consider the conflicting segments ofthe policy whose action constraints are “allow,” but carryingout “deny” action to all matched network packets. Supposethese conflicting segments can be returned by a functionisForceDenied() and we utilize the equation ð10�RLðcsÞÞ toderive the availability value of a conflicting segment cs. Theavailability loss value of a policy is calculated as follows:

ALðpÞ ¼X

csi2CSðpÞ:isForceDeniedðÞð10�RLðcsiÞÞ: ð4Þ

Evaluation results depicted in Fig. 11c clearly show thatthe availability loss value for each conflict-resolved policy islower than that of corresponding original policy, whichsupports our hypothesis that resolving policy conflicts canalways improve the availability of protected network.

5.3.4 Evaluation of the Effectiveness of Redundancy

Removal Approach

We also evaluated our redundancy analysis approach basedon those experimental firewall policies. We conducted theevaluation of effectiveness by comparing our redundancyanalysis approach with traditional redundancy analysis


Fig. 11. Evaluation of conflict resolution.

approach [1], [6], which can only identify redundancyrelations between two rules. Fig. 12 depicts the results ofour comparison experiments. From Fig. 12, we observed thatFAME could identify an average of 6.5 percent redundantrules from the whole rules. However, traditional redundancyanalysis approach could only detect an average 3.8 percent oftotal rules as redundant rules. Therefore, the enhancementfor redundancy elimination was clearly observed by ourredundancy analysis approach compared to traditionalredundancy analysis approach in our experiments.

6 DISCUSSIONS

The main limitation of CVSS is that it treats vulnerabilitiesindividually without considering attack interdependencieson target networks. Therefore, it may be insufficient toevaluate overall security of a network configuration run-ning multiple services by counting the number of vulner-abilities or adding up the CVSS scores. Attack graphs can beused to model causal relationships among vulnerabilitiesand capture security interactions within an enterprisenetwork [28], [29]. There have been some attempts atcalculating quantitative metrics by attack graphs [14]. It is apromising direction to combining CVSS metrics with attackgraphs to achieve a more fine-grained risk assessment for theprotected network when performing conflict resolutions infirewall policies.

Our experimental results show that around 92 percent ofconflicts can be resolved by using our FAME tool. Theremay still exist requirements for a complete conflict resolution,especially for some firewalls in protecting crucial networks.We believe our FAME tool can help achieve this challenginggoal. First, FAME provides a grid-based visualizationtechnique to accurately represent conflict diagnostic in-formation and the detailed information for unresolvedconflicts, that are very useful, even for manual conflictresolution. Second, FAME resolves conflicts in each conflictcorrelation group independently. That means a systemadministrator can focus on analyzing and resolving con-flicts belonging to a conflict correlation group individually.

We may have another way to adjust the thresholds forconflict resolution with respect to the network situationchange based on the risk analysis of entire network protectedby the firewall. When the network situation deteriorates,such as discovering some severe vulnerabilities within theprotected network or services, the system administrator may

adjust the thresholds to a lower value to enable the firewall tofortify the security of the network perimeter. Otherwise, if thenetwork situation ameliorates, such as fixing significant bugsor vulnerabilities of the protected network or services, thethresholds can be tuned to a higher value to improve theavailability and utility of the network services. Moreover, it ispossible to carry out this process in an automated fashion byteaming up with other network security measures such asintrusion detection systems. Thus, such a conflict resolutionmechanism can be also considered as an important steptoward adaptive security management in which networks canbe evaluated and legitimately hardened by continuouslymonitoring dynamic changes in the network and servicevulnerabilities.

7 RELATED WORK

There exist a number of algorithms and tools designed toassist system administrators in managing and analyzingfirewall policies. Lumeta [30] and Fang [31] allow userqueries for the purpose of analysis and management offirewall policies. Essentially, they introduced lightweightfirewall testing tools but could not provide a comprehensiveexamination of policy misconfigurations. Gouda et al. [32]devised a firewall decision diagram (FDD) to supportconsistent, complete, and compact firewall policy generation.Bellovin et al. [33] introduced a distributed firewall modelthat supports centralized policy specification. Several otherapproaches presenting policy analysis tools with the goal ofdetecting policy anomalies are closely related to our work.Al-Shaer and Hamed [1] designed a tool called FirewallPolicy Advisor to detect pairwise anomalies in firewall rules.Yuan et al. [5] presented FIREMAN, a toolkit to check formisconfigurations in firewall policies through static analysis.As we discussed previously, our tool, FAME, overcomes thelimitations of those tools by conducting a complete anomalydetection and providing more accurate anomaly diagnosisinformation. In particular, the key distinction of FAME is itscapability to perform an effective conflict resolution, whichhas been ruled out in other firwall policy analysis tools.

Hari et al. [34] provided an algorithm for detecting andresolving conflicts in a general packet filter. However, theycan only detect a specific correlation conflict, and resolvethe conflict by adding a resolving filter, which is notsuitable for resolving conflicts identified recently in firewallpolicies. Fu et al. [35] examined conflict detection andresolution issues in IPSec policies, which is not directlyapplicable in firewall policy analysis. Also, there exist otherrelated work to deal with a set of conflict resolutionstrategies for access control including Fundulaki and Marx[16], Jajodia et al. [17] and Li et al. [19]. These conflictresolution mechanisms can be accommodated in our fine-grained conflict resolution framework.

There are several interfaces that have been developed toassist users in creating and manipulating security policies.Expandable Grid is a tool for viewing and authoring accesscontrol policies [36]. The representation in Expandable Gridsis a matrix with subjects shown along the rows, resourcesshown along the columns, and effective accesses for thecombinations of subjects and resources in the matrix cells.The SPARCLE Policy Workbench allows policy authors to


Fig. 12. Evaluation of redundancy removal.

construct policies in a natural language interface, which arein turn translated into machine-readable policies [37]. Eventhough these tools are useful for authoring access controlpolicies, they cannot effectively represent the results ofpolicy analysis for firewalls.

8 CONCLUDING REMARKS

In this paper, we have proposed a novel anomaly manage-ment framework that facilitates systematic detection andresolution of firewall policy anomalies. A rule-basedsegmentation mechanism and a grid-based representationtechnique were introduced to achieve the goal of effectiveand efficient anomaly analysis. In addition, we havedescribed a proof-of-concept implementation of our anom-aly management environment called FAME and demon-strated that our proposed anomaly analysis methodology ispractical and helpful for system administrators to enable anassurable network management.

Our future work includes usability studies to evaluatefunctionalities and system requirements of our policyvisualization approach with subject matter experts. Also,we would like to extend our anomaly analysis approach tohandle distributed firewalls. Moreover, we would explorehow our anomaly management framework and visualiza-tion approach can be applied to other types of accesscontrol policies.

ACKNOWLEDGMENTS

This work was partially supported by the grants from theUS National Science Foundation (NSF-IIS-0900970 andNSF-CNS-0831360) and US Department of Energy (DOE)(DE-SC0004308). All correspondence should be addressedto: Dr. Gail-Joon Ahn, ASU, PO Box 878809, Tempe,Arizona 85287.

REFERENCES

[1] E. Al-Shaer and H. Hamed, “Discovery of Policy Anomalies inDistributed Firewalls,” IEEE INFOCOM ’04, vol. 4, pp. 2605-2616,2004.

[2] A. Wool, “Trends in Firewall Configuration Errors: Measuring theHoles in Swiss Cheese,” IEEE Internet Computing, vol. 14, no. 4,pp. 58-65, July/Aug. 2010.

[3] J. Alfaro, N. Boulahia-Cuppens, and F. Cuppens, “CompleteAnalysis of Configuration Rules to Guarantee Reliable NetworkSecurity Policies,” Int’l J. Information Security, vol. 7, no. 2, pp. 103-122, 2008.

[4] F. Baboescu and G. Varghese, “Fast and Scalable ConflictDetection for Packet Classifiers,” Computer Networks, vol. 42,no. 6, pp. 717-735, 2003.

[5] L. Yuan, H. Chen, J. Mai, C. Chuah, Z. Su, P. Mohapatra, and C.Davis, “Fireman: A Toolkit for Firewall Modeling and Analysis,”Proc. IEEE Symp. Security and Privacy, p. 15, 2006.

[6] E. Lupu and M. Sloman, “Conflicts in Policy-Based DistributedSystems Management,” IEEE Trans. Software Eng., vol. 25, no. 6,pp. 852-869, Nov./Dec. 1999.

[7] I. Herman, G. Melancon, and M. Marshall, “Graph Visualizationand Navigation in Information Visualization: A Survey,” IEEETrans. Visualization and Computer Graphics, vol. 6, no. 1, pp. 24-43,Jan.-Mar. 2000.

[8] H. Hu, G. Ahn, and K. Kulkarni, “Anomaly Discovery andResolution in Web Access Control Policies,” Proc. 16th ACM Symp.Access Control Models and Technologies, pp. 165-174, 2011.

[9] L. Yuan, C. Chuah, and P. Mohapatra, “ProgME: TowardsProgrammable Network Measurement,” ACM SIGCOMM Com-puter Comm. Rev., vol. 37, no. 4, p. 108, 2007.

[10] A. El-Atawy, K. Ibrahim, H. Hamed, and E. Al-Shaer, “PolicySegmentation for Intelligent Firewall Testing,” Proc. First WorkshopSecure Network Protocols (NPSec ’05), 2005.

[11] G. Misherghi, L. Yuan, Z. Su, C.-N. Chuah, and H. Chen, “AGeneral Framework for Benchmarking Firewall OptimizationTechniques,” IEEE Trans. Network and Service Management, vol. 5,no. 4, pp. 227-238, Dec. 2008.

[12] M. Frigault, L. Wang, A. Singhal, and S. Jajodia, “MeasuringNetwork Security Using Dynamic Bayesian Network,” Proc.Fourth ACM Workshop Quality of Protection, 2008.

[13] M. Sahinoglu, “Security Meter: A Practical Decision-Tree Model toQuantify Risk,” IEEE Security and Privacy, vol. 3, no. 3, pp. 18-24,May 2005.

[14] R. Sawilla and X. Ou, “Identifying Critical Attack Assets inDependency Attack Graphs,” Proc. 13th European Symp. Research inComputer Security (ESORICS), 2008.

[15] P. Mell, K. Scarfone, and S. Romanosky, “A Complete Guide to theCommon Vulnerability Scoring System Version 2.0,” Published byFIRST—Forum of Incident Response and Security Teams, June 2007.

[16] I. Fundulaki and M. Marx, “Specifying Access Control Policies forXML Documents with Xpath,” Proc. Ninth ACM Symp. AccessControl Models and Technologies, pp. 61-69, 2004.

[17] S. Jajodia, P. Samarati, and V.S. Subrahmanian, “A LogicalLanguage for Expressing Authorizations,” Proc. IEEE Symp.Security and Privacy, pp. 31-42, May 1997.

[18] T. Moses, “Extensible Access Control Markup Language(XACML), Version 2.0, Oasis Standard,” Internet, http://docs.oasis-open.org/xacml/2.0/accesscontrol-xacml-2.0-core-spec-os.pdf, 2005.

[19] N. Li, Q. Wang, W. Qardaji, E. Bertino, P. Rao, J. Lobo, and D. Lin,“Access Control Policy Combining: Theory Meets Practice,” Proc.14th ACM Symp. Access Control Models and Technologies, pp. 135-144, 2009.

[20] J. Jin, G. Ahn, H. Hu, M. Covington, and X. Zhang, “Patient-Centric Authorization Framework for Sharing Electronic HealthRecords,” Proc. 14th ACM Symp. Access Control Models andTechnologies, pp. 125-134, 2009.

[21] J. Jin, G. Ahn, H. Hu, M. Covington, and X. Zhang, “Patient-Centric Authorization Framework for Electronic HealthcareServices,” Computers and Security, vol. 30, no. 2, pp. 116-127, 2011.

[22] J. Bentley and T. Ottmann, “Algorithms for Reporting andCounting Geometric Intersections,” IEEE Trans. Computers,vol. 28, no. 9, 1979.

[23] E. Al-Shaer, W. Marrero, A. El-Atawy, and K. ElBadawi,“Network Configuration in a Box: Towards End-to-End Verifica-tion of Network Reachability and Security,” Proc. Int’l Conf.Network Protocols (ICNP ’09), pp. 123-132, 2009.

[24] “Java BDD,” http://javabdd.sourceforge.net, 2012.[25] “Buddy Version 2.4,” http://sourceforge.net/projects/buddy,

2012.[26] “TENABLE Network Security,” http://www.nessus.org/nessus,

2012.[27] “Tissynbe.py,” http://www.tssci-security.com/projects/

tissynbe_py, 2012.[28] K. Ingols, R. Lippmann, and K. Piwowarski, “Practical Attack

Graph Generation for Network Defense,” Proc. 22nd Ann.Computer Security Applications Conf. (ACSAC), 2006.

[29] X. Ou, W. Boyer, and M. McQueen, “A Scalable Approach toAttack Graph Generation,” Proc. 13th ACM Conf. Computer andComm. Security, pp. 336-345, 2006.

[30] A. Wool, “Architecting the Lumeta Firewall Analyzer,” Proc. 10thConf. USENIX Security Symp., vol. 10, p. 7, 2001.

[31] A. Mayer, A. Wool, and E. Ziskind, “Fang: A Firewall AnalysisEngine,” Proc. IEEE Symp. Security and Privacy, pp. 177-189, 2000.

[32] M. Gouda and X. Liu, “Firewall Design: Consistency, Complete-ness, and Compactness,” Proc. 24th Int’l Conf. Distributed Comput-ing Systems (ICDCS ’04), p. 327, 2004.

[33] S. Ioannidis, A. Keromytis, S. Bellovin, and J. Smith, “Implement-ing a Distributed Firewall,” Proc. Seventh ACM Conf. Computer andComm. Security, p. 199, 2000.

[34] A. Hari, S. Suri, and G. Parulkar, “Detecting and Resolving PacketFilter Conflicts,” Proc. IEEE INFOCOM, pp. 1203-1212, 2000.

[35] Z. Fu, S. Wu, H. Huang, K. Loh, F. Gong, I. Baldine, and C. Xu,“IPSec/VPN Security Policy: Correctness, Conflict Detection andResolution,” Proc. Int’l Workshop Policies for Distributed Systems andNetworks (POLICY ’01), pp. 39-56, 2001.


[36] R. Reeder, L. Bauer, L. Cranor, M. Reiter, K. Bacon, K. How, andH. Strong, “Expandable Grids for Visualizing and AuthoringComputer Security Policies,” Proc. 26th Ann. SIGCHI Conf. HumanFactors in Computing Systems, pp. 1473-1482, 2008.

[37] C. Brodie, C. Karat, and J. Karat, “An Empirical Study of NaturalLanguage Parsing of Privacy Policy Rules Using the SPARCLEPolicy Workbench,” Proc. Second Symp. Usable Privacy and Security,pp. 8-19, 2006.

Hongxin Hu is currently working toward thePhD degree from the School of Computing,Informatics, and Decision Systems Engineering,Ira A. Fulton School of Engineering, ArizonaState University, Tempe. He is also a member ofthe Security Engineering for Future ComputingLaboratory, Arizona State University. His currentresearch interests include access control mod-els and mechanisms, security and privacy insocial networks, and security in distributed and

cloud computing, network and system security and secure softwareengineering. He is a student member of the IEEE.

Gail-Joon Ahn received the PhD degree ininformation technology from George MasonUniversity, Fairfax, Virginia, in 2000. He is anassociate professor in the School of Computing,Informatics, and Decision Systems Engineering,Ira A. Fulton Schools of Engineering and thedirector of Security Engineering for FutureComputing Laboratory, Arizona State University.His research interests include information andsystems security, vulnerability and risk manage-

ment, access control, and security architecture for distributed systems,which has been supported by the US National Science Foundation(NSF), National Security Agency, US Department of Defense, USDepartment of Energy (DOE), Bank of America, Hewlett Packard,Microsoft, and Robert Wood Johnson Foundation. He is the recipient ofthe US Department of Energy CAREER Award and the Educator of theYear Award from the Federal Information Systems Security EducatorsAssociation. He was an associate professor at the College of Computingand Informatics, and the founding director of the Center for DigitalIdentity and Cyber Defense Research and Laboratory of InformationIntegration, Security, and Privacy, University of North Carolina,Charlotte. He is a senior member of the IEEE.

Ketan Kulkarni received the master’s degree incomputer science from Arizona State University.He was also a member of the Security Engineer-ing for Future Computing Laboratory, ArizonaState University. He is currently working as asoftware engineer at Emerson Network Power.

. For more information on this or any other computing topic,please visit our Digital Library at www.computer.org/publications/dlib.


detecting and resolving firewall policy anomalies

Documents

security policy

firewall policy management

firewall policy advisor

firewall rules

thequality of policy

inspected firewall policies

policy anomaly detection

security rules