1. SECURITY POLICY ANALYZER FINAL MEETING Industrial Project (234313) Fall 2013 Supervisors: Yevgeny Fabrikant Students: Regev Brody, Yuval Adelstein COMPUTER SCIENCE DEPARTMENT Technion - Israel Institute of Technology 1 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. 2

3. 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. 4

5. METHODOLOGY – THE WORLD 5 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 6 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 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. 7

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 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 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) 8

9. DATA STRUCTURE - REPRESENTATION OF A FILTER SET Each packet is a 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. 9

10. DATA STRUCTURE – EXAMPLE 10 Assuming 2 bits each for each member of the tuple. └── root └── 1 └── * └── 0 └── 1 └── 1 (1) Adding rule 1:. The tree will look like this: Adding rule 2:. The tree will look like this: └── root └── 1 ├── 1 │ ├── 0 │ │ └── 1 │ │ └── 1 (1 1 ) │ └── 1 │ └── 1 (2) └── 0 └── 1 └── 1 (1 0 ) Adding rule 3:. The tree will look like this: └── root └── 1 ├── 0 │ ├── 0 │ │ └── 1 │ │ └── 1 (1 0 ) │ └── 1 │ └── 1 (3) └── 1 ├── 0 │ └── 1 │ └── 1 (1 1 ) └── 1 └── 1 (2)

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

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. 12

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

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. 14

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. 15

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.FIREMAN 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.Conflict Classification and Analysis of Distributed Firewall Policies 16

17. QUESTIONS ? 17