Security policy analyzer

1. 22/01/14 COMPUTER SCIENCE DEPARTMENT Technion - Israel Institute of Technology Industrial Project (234313) Fall 2013 Security policy analyzer Final meeting Supervisors:YevgenyFabrikant Students: Regev Brody, Yuval Adelstein

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 iis masked by a group of filters, all with the same action of i – filter i is redundant. • Filter iis 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 iis generalized by j. • Filter iis (partly) masked by a group of filters, some of which, with the same action of iand 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)

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 • Adding rule 1: <1*,01,11>. The tree will look like this: • Adding rule 2: <11,11,11>. The tree will look like this: • 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) └── 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) └── root └── 1 └── * └── 0 └── 1 └── 1 └── 1 <1*,01,11> (1) • Assuming 2 bits each for each member of the tuple.

11. Development Both engine & GUI were written in JAVA/SWING.

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, HazemHamed, RaoufBoutaba, and MasumHasan.

17. Questions ?