1

SECURITY POLICY ANALYZER

FINAL MEETING

Industrial Project (234313)Fall 2013

Supervisors: Yevgeny FabrikantStudents: Regev Brody, Yuval Adelstein

COMPUTER SCIENCE DEPARTMENTTechnion - Israel Institute of Technology

22/01/14

2

BACKGROUND AND MOTIVATION

• Definitions• Security Rule (or Rule) – configuration unit of Check Point firewall which specifies which action should be

performed on IP traffic based on IP packet source, destination and port.

• Security Policy (or Policy) – ordered set of security rules.

• fwset – Check Point proprietary format for storing configuration on disk.

• Security Policy can consists of 1000+ rules which have been added to the Policy over a long time, sometimes by different system administrators.

• Changes made to a policy , results in changing it’s effectiveness meaning.

• Security policy may contain redundant rules which can be removed from the policy without changing its overall meaning.

• Reducing the number of rules of a policy will result in a more coherent policy and will increase the efficiency of the firewall.

3

POLICY EXAMPLE

4

GOALS

• Gain the ability to optimize policies.• Remove redundant rules.

• Alert user regarding possible intention conflicts.

• Gain the ability to compare 2 policies by measuring the effective difference between them.

• Given policy A, what changes need to be made to policy B in order to obtain the same effectiveness meaning as A.

5

METHODOLOGY – THE WORLD• The world is the set of all possible packets.

• We can model a firewall policy as an ordered set of packets filters (rules).

• Each filter is designed to catch a subset of the world and perform 1 out of 2 actions on it (Accept/Deny).

• Once a packet is caught in filter i it will not reach any filter j such that j>i.

6

METHODOLOGY - RELATIONS• Filter i is masked by a group of filters, all with

the same action of i – filter i is redundant.

• Filter i is masked by a group of filters, all with the opposite action of i – filter i is shadowed by them.

• Filter j is partly masked by filter i, with the opposite action of j – filter i is generalized by j.

• Filter i is (partly) masked by a group of filters, some of which, with the same action of i and some with the opposite – filter i is correlated with them.

7

OPTIMIZATION ALGORITHM Idea:

• Iteratively add filters to the filters set.

• Remove each filter that if removed, policy overall meaning won’t be changed.

• Raise warnings for possibly intentional conflicts.

Pseudo-Code: FILTERi – the packets caught by rule i.

ACTIONi – action taken on packets caught by FILTERi.

• For each tuple < FILTERi,ACTIONi>

• Add FILTERi to the end of the filters set.

• Check for all possible relations:

• No relation - fully effective filter. Continue.

• Redundant - non-effective filter. remove filter unless all masking filters can be removed instead without changing the effectiveness of the policy.

• Shadowing - non-effective filter. Raise warning. Continue.

• Generalization - raise warning. Continue.

• Correlation - raise warning. If possible, remove filters with the same action.

8

DIFF ALGORITHM Idea:

• Remove from B any filter that does not agree with A’s filter set.

• Add to B all filters from A that do not fully agree with B.

Pseudo-code:

• Optimize(A)

• Optimize(B)

• For each tuple < FILTERi,ACTIONi> in B

• Add FILTERi to the end of the filters set of A.

• Check for all possible relations:

• No relation – do not agree with policy A. remove from A and B. Continue.

• Redundant – fully agree with policy A. Continue.

• Shadowing - fully agree with policy A except on action. Change FILTERi’s action. Continue.

• Else – partly agree with policy A. Remove from A and B. Continue.

• Remove all B’s filters from A’s set.

• For each tuple < FILTERi,ACTIONi> in A

• Add FILTERi to the end of the filters set of B.

• Check for all possible relations:

• Redundant – fully agree with policy B. Remove it from B.

• Else – (partly) don’t agree with policy B. Continue.

• Optimize(B)

B A

A B A B

9

DATA STRUCTURE - REPRESENTATION OF A FILTER SET

• Each packet is a <source,destination,port> tuple, represented by an 80 bits vector.• 32b for source, 32b for destination, 16b for port.

• A filter is a union of packets.

• A policy is represented by a binary tree of filters.• Each tree node represents 1 bit = 0/1/*.

• * node only exists by it self. Each sub tree of a 0/1 node will contain the * sub tree (if such exists).

• Each level of the tree represents the i’th bit of a tuple tree height is 80 (constant).

• Each leaf of the tree represents a route from the root.• This route is an ordered set of bits, representing a packet tuple as introduced before.

• Each leaf holds a list of all filters that contain that packet.

• To understand a relation between a filter to the current set of filters, we check all the leaves that represent packets contained in it and analyze the list of filters listed in them.

10

DATA STRUCTURE – EXAMPLE• Assuming 2 bits each for each member of the tuple.

└── root └── 1 └── * └── 0 └── 1 └── 1 └── 1 <1*,01,11> (1)

• Adding rule 1: <1*,01,11>. The tree will look like this:• Adding rule 2: <11,11,11>. The tree will look like this:└── root └── 1 ├── 1 │ ├── 0 │ │ └── 1 │ │ └── 1 │ │ └── 1 <11,01,11> (11) │ └── 1 │ └── 1 │ └── 1 │ └── 1 <11,11,11> (2) └── 0 └── 0 └── 1 └── 1 └── 1 <10,01,11> (10)

• Adding rule 3: <10,11,11>. The tree will look like this:└── root └── 1 ├── 0 │ ├── 0 │ │ └── 1 │ │ └── 1 │ │ └── 1 <10,01,11> (10) │ └── 1 │ └── 1 │ └── 1 │ └── 1 <10,11,11> (3) └── 1 ├── 0 │ └── 1 │ └── 1 │ └── 1 <11,01,11> (11) └── 1 └── 1 └── 1 └── 1 <11,11,11> (2)

DEVELOPMENTBoth engine & GUI were written in JAVA/SWING.

11

Parser

Rule-Data

PolicySecurity policy analyzer

Policy

Policy

IpSetTree

ParserPolicySecurity policy

analyzer

GUI

Policy

Policy

SWING

FWSet

JAVA

12

ACHIEVEMENTS

Ability to input and parse security policies (fwset format).

GUI environment with Checkpoint Dashboard’s look & feel.

Produce an optimized security policy.

Output the optimized policy in fwset format.

Calculate & graphically visualize the effective difference between two policies.

13

DELIVERABLES

• A program with Graphical User Interface for Security Policy comparison and optimization (Live example)

14

CONCLUSIONS

• Optimizing a firewall policy and calculating the effective difference between 2 policies is feasible.

• Developing a full featured tool for the benefit of Check Point’s customers is not far fetched.

15

FUTURE WORK

• This project is a POC.

• Some elements have been neglected.• multiple sources/destinations/ports in a rule.

• dimensions in a rule – time, track, VPN etc.

• users in the source field of a rule.

• Adding these elements will not affect the correctness of the presented algorithms.

• These can be implemented within the provided framework.

16

REFERENCES

• The optimization algorithm is based on the algorithm introduced at the “FIREMAN” paper by C-N. Chuah, H. Chen and Z. Su from University of California, Davis.

• The implementation was inspired by the “Conflict Classification and Analysis of Distributed Firewall Policies” paper by Ehab Al-Shaer, Hazem Hamed, Raouf Boutaba, and Masum Hasan.

17

QUESTIONS

?