Applying Visualization to the Management of Firewall Rulesets

Applying Visualizationto the Management of Firewall Rulesets Thesis Committee: Prof. Grinstein, Advisor Prof. Levkowitz Prof. Daniels Shaun P. Morrissey 7 October 2009

Outline • Context • Proxies and firewalls? • What is a firewall rule? • Background • Method • Calculation of the acceptance volume • Visual Approaches • Data – Issues & Solutions • Visual Results • Discussion & Directions • What works • What needs to be done

Do we care about firewall rulesets? • (Google, 16 June 2005, ~1745 EDT) • Results 1 - 10 of about 55,600 for "firewall setup". (0.39 seconds) • Results 1 - 10 of about 62,100 for "firewall management". (0.04 seconds) • Results 1 - 10 of about 18,100 for "firewall administration". (0.15 seconds) • (Google, 26 April 2006, ~0935 EDT) • Results 1 - 20 of about 185,000 for "firewall setup". (0.25 seconds) • Results 1 - 20 of about 207,000 for "firewall management". (0.25 seconds) • Results 1 - 20 of about 81,600 for "firewall administration". (0.28 seconds) • (Google, 12 July 2009, ~1457 EDT • Results 1 - 10 of about 1,710,000 for “firewall setup.” (0.37 seconds) • Results 1 - 10 of about 17,800,000 for “firewall management.” (0.22 seconds) • Results 1 - 10 of about 8,230,000 for “firewall administration.” (0.13 seconds).

Do they need help? • Network Managers need methods to quickly and efficiently analyze policy environment and impact of proposed changes on operational environment. • Industry analysts Gartner & IDC – 80% of unplanned outages are a result of changes in IT policies or configurations • Policy artifacts, the rulesets, are large, complex, difficult to comprehend • Errors in interpretation, modification, and development • Demand for capable personnel exceed supply • Diagnostic capabilities desperately needed

What is a firewall? • Implementation tool to achieve security policy goal • Border or Perimeter Device • Generally two or more interfaces • Not limited to a single device • Packet-based decision • Packet decision - pass/deny/drop • Local action - alarm/log/record • Decision basis - Proxy vs firewall distinction • Content awareness - proxy • Packet header plus state • Packet header values (research bound)

Exterior Network (Internet connection) Firewall Interior Network Hosts* Basic Firewall Concept

Exterior Network (Internet connection) X Router X Interior Network Bastion Host Hosts* Basic Firewall Concept Implementation

Exterior Network (Internet connection) (exterior /access) Router Perimeter Network (interior /choke) Bastion Host(s) Router Interior Network Hosts* Screened Subnet (DMZ)

http queries X Exterior Network (Internet connection) (exterior /access) Router X Perimeter Network X (interior /choke) Router Bastion Host(s) http query Interior Network Hosts* Control of HTTP queries

Firewall Rules: Intended Semantics • Source • Host • Group of hosts • Collection of hosts or groups • Destination • Host • Group of hosts • Collection of hosts or groups • Service • HTTP, SSL, SMTP, etc • Action • Accept/Deny

Packet Header Decision Fields

Service • Often listed with the same name as a protocol, • HTTP for web • SSL for secure connections • SSH for secure user connection • Technically defined by protocol and port combinations • HTTP - TCP with destination port 80

What is a firewall rule? • Firewall rules generally abstracted to a 5-tuple filter and an action • The components • Source address (IPv4, IPv6) • Source port (0 - 65535) • Destination address • Destination port • Protocol • Action: Binary, Accept or Deny • Addresses are often combinations of ranges and individuals • Ports are often ranges • Protocol often maps to a single number • Other fields do appear, not considering them at this time. • Packet tests are order-dependent (sequential)

Example: Al-Shaer & Hamed, 2003 <tcp, 140.192.37.20, 4320, 140.192.37.40, 80>

Acceptance Space and Volume Acceptance Space • Set of all possible packet values is a non-negative integer lattice in five dimensions • Lattice is large (2^32 for two of the dimensions) but finite • References to tractability herein are responsiveness concerns, not issues of computability Acceptance Volume • Subset of acceptance space allowed by the ruleset • Product of correct combination of the predicates of the rules • Not equivalent to list of accept rule predicates due to sequential processing and predicate overlap

So what are the problems? • Size complexity • Rulesets grow over time • Interaction Complexity • Field definition overlap • Deliberate use of order-dependence to achieve compactness • A Rule is not the Result! • List of rules • Total effect of file • Organizational issues lead to comprehension concerns • Administrators change • Policy Changes • Documentation lost

Pages 1 and 2, of 114. Placeholder

Challenges • Dataset • Two distinct technical issues • Size complexity • Interaction complexity • Confidentiality issue at every front • Examples provided, permission to use denied • Training community structurally unresponsive • Internal ruleset storage/representation • Direct rule visualization • Interval (non-atomic) data field entries • Closure property violation under logical operations • Decomposition proofs provide some answers • Acceptance set visualization • 5-dimensional space: 5-cubes • Embedded subsets not convex • Extension of solid modeling with logical operations effective • Visualization of moderate dimensional data (<10D)

Research Objective • Create interactive visual representations of firewall rulesets that: • Enhance the speed & correctness of comprehension of ruleset impact or function • Enhance detection of configuration errors • Support modification without the introduction of unacceptable side effects. • Required • Calculate the acceptance volume • Display it • Enable editing in response

Related work? • First, NOTHING directly on point • Point visualizations of 5-tuples • Intrusion Detection • Network traffic • Static and time-dependent, partial and complete • But no range visualizations, not applicable • Data structures for firewall decision-making • Time & space efficient structures • Representations not unique • But none visualized

What’s out there? And the research literature on firewall visualization was simply “None” until 2007.

PolicyVis – Tran et al., 2007

Calculate the Acceptance Volume Basic Guttman Algorithm Implementation Choice: Constructive Solid Geometry • Integer lattice • 5 dimensions – Penteracts • Axis-aligned – intervals only Modifications • Convex solid decomposition • Add provenance • Add created voids

Guttman Algorithm Clear List Index = last Deny or Accept? Deny Accept Union Subtract Index-1 Done Convert order dependent ruleset to static set Original formulation was recursive • Replaced by iteration from end Requires two boolean operations • Union for accept predicates • Set Difference or subtraction for deny-rule predicates

Restricted Constructive Solid Geometry Treat intervals in five dimensions as a solid • Axis-aligned, intervals only • No rotations • Penteracts specified by 10 values, upper and lower limits Existing Constructive Solid Geometry packages • Do not appear to go above 3-D • Carry sophistication to manage arbitrary object orientation • Use logic that eliminates single values in a given dimension • In solids with real dimensions, skin overlaps have no volume, and are eliminated • In our case “degenerate” solids, one value as both upper and lower limit, are real conditions that must be retained. Single values needed for our work (Protocol #) Do it yourself, don’t adapt packages

Boolean operations on solids Work is done on an integer lattice of all non-negative values Critical operations are: • Set Union A∪B • Set Difference A – B = A ∩ ~B Goals include: • Always maintaining convex solid decompositions • ~(~B) = B • Making use of A – B = A – (A ∩ B) to limit need to handle general case of ~B • Maintaining connection to rules that generated volumes • Creating solution approach that works in each dimension so that it can be extended to 5-D with confidence

Penteract Constructive Solid Geometry(3D analogue) Top face of rule A box (red) has been opened to expose A ∩ B

Use Convex Solid Decomposition Rule A: red volumes Rule B: green volumes B ∩ A : blue volume 1-D cuts Simple Data Structure • Only penteracts required Calculation Complexity • 371,293 types of penteract overlap • CSD allows one dimension at a time, five pairs of cuts, 13 cases • Cost: longer list Convex penteract can be visualized easily • Parallel Set Enclosure

371,293 Cases? (13^5) of course! Thirteen(13) cases exist for possible overlaps between the intervals in each of five dimensions • Actually, 25 cases can be enumerated, but 10 are aphysical and two do not overlap In the following discussion, we use T as the target space, and A for the volume being “added”. • T will in fact be only one component of a list of existing blocks • The overall algorithm will need to be executed against each relevant block in the acceptance volume • The overall algorithm will need to account for A intersecting with more than one component of the T’s The following analysis assumes initially that the dimensions are not degenerate. • The resulting algorithmwaschecked to see if it is robust to handling degenerate cases.

Where does 13, 15 or 25 come from? TL TH 1 2 3 4 5 Consider an interval in a dimension of T, defined by upper and lower limits TL and TH. There are five distinct regions where each of the boundaries of A (AL and AH, respectively) can fall • Two exterior regions • One interior region • Coincidence with two boundary values

Analysis of One Dimension 25 possible cases, in general Impose AL ≤ AH, 10 cases removed Require intersection to exist • AH ∈ 1, A is below T, no intersection • AL ∈ 5, A is above T, no intersection 25 – 10 – 2 = 13 • Argument provides enumeration of cases to be handled • 13 cases times five dimensions is plausibly correct • Yields 1,198-line Java method • Alternative is (13^5) = 371,293 cases

Overlap cases for one dimension Impose AL ≤ AH

Resulting Convex Solid Decomposition(3D) Red volumes – rule A Green volumes – rule B Blue volume – rule A and rule B

Thirteen cases, enumeration of actions • Create working copies of T, wT, and A, wA. • Pick a dimension. • Select the case of the thirteen that applies. • Create a copy of wT, wTd, and of wA, wAd, (or two of one of them, etc). • Shift the boundary of wTd so it is the excess beyond the common volume. • Shift the boundary of wT so it is reduced to the common volume. • Shift the boundary of wAd so it is the excess beyond the common volume. • Shift the boundary of wA so it is reduced to the common volume. • Send wTd and wAd to their respective output lists. • Repeat starting at step 2 until all five dimensions are done.

Set operations as disposition rules for convex solid decomposition lists All of the set operations are dispositions for three lists Only one CSD generation method required for intersecting penteract Operations become wrapper around use of that method Class PenteractSliceDice

Created Voids and Provenance • Rule A: red volumes • Rule B: green volumes • B ∩ A : blue volume • 1-D cuts Created Void • Modify Guttman A-B • Normal: discard B ∩ A • Created Void: retain B ∩ A, label with joint provenance • Creates visualizable artifact Add provenance of rules • List of rules for each penteract • Connected to editor

Handle multiple intersections Remaining issue: Added penteract intersects with more than one in target list Add queues for pieces, put penteracts back into queues if further work needed

Visual Approaches Parallel Coordinates • Inselberg lossless multidimensional visualization for points • Use parallel set enclosures for display of penteracts • Ease of representation was one motivation for use of CSD Flow Picture • Loose pipe or pipeline metaphor • Extended polyhedral representation in 3-space • Implemented in Java OpenGL for speed, interaction (Keyes) • Discussion will focus on design, not software implementation • Use visual completion for improved capture-anomaly containment visualization

PC Screen Shot

Flow Picture Mockup

Flow Picture endpoints

Data Sources Requests for operational data sets not favorably received • One permitted use case, port 32760 exclusion Alternative approach - visualize taxonomy of interactions Al-Shaer & Hamed (2003) • Firewall Policy Adviser – defined full range of interactions and created a complete example Yuan, et al. (2006) • FIREMAN (A Toolkit for FIREwall Modeling and Analysis) – defined similar structures with one addition and created examples • Some examples only artifacts of CIDR notation These examples give us a “complete” set of issues to look at.

Example: Al-Shaer & Hamed, 2003 Al-Shaer, E.S. and Hamed, H.H. 2003a. Firewall Policy Advisor for anomaly discovery and rule editing, IFIP/IEEE Eighth International Symposium on Integrated Network Management, 2003, 24-28 March 2003, pp. 17 – 30.

Yuan, et al. (2006) Yuan, L., Chen, H., Mai, J., Chuah, C-N, Su, Z., and Mohapatra, P., 2006. FIREMAN: a toolkit for firewall modeling and analysis, IEEE Symposium on Security and Privacy, 2006, 21-24 May 2006, pp. 213-227.

Anomalies versus Predicate Overlaps Note: in this case, there is the additional requirement that there is no correlation or generalization anomaly involving Ri and any rule between it and Rj

Applying Visualization to the Management of Firewall Rulesets