The Joy of Firewall Policy Management

Reuven HarrisonTufin Technologies

2

whoami

• Reuven Harrison

• CTO and Co-Founder of Tufin Technologies

• My Check Point service: 4 years in R&D

reuvenharrison

tufin.com/blog

tufintech

3

Context: We Make Changes

• Firewall Operations Management• Changes/day?

• Why we change the policy• Usually: application connectivity• Rarely: security related

• Risk: Collateral Damage• Unintentionally impact business• Open up security holes

4

Problem: Things Change, Things Break

• Simple syntax errors:• Opened 22 (ssh) instead of 21 (ftp). Oops!

• Rule Shadowing• Add a connection to a shadowed rule• Add a connection to a partially shadowed rule• Oops, it doesn’t work – redo it

• Indirect changes (network group)• Oops, it appears in multiple rules• Argh, it appears in multiple policies• OMG: P-1 global rule/object – multiple customers

5

Many Ways to Change Access

1. Add a new rule2. Add a host to a rule3. Add a host to a group4. Delete a rule5. Disable/Enable a rule6. Remove a host from a rule7. Remove a host from a group8. Add a rule to global policy (P-1)9. Add a host to a global rule (P-1)10. Add a host to a global group (P-1)11. Delete a global rule12. Delete a host from a global rule (P-1)13. Delete a host from a global group (P-1)14. Reorder rules15. Edit a network range16. Modify a Group with Exclusion17. Change a rule target (Install On)18. Policy Save As19. Change a time object20. Change user access21. ….

6

The Impact

• Fail to fulfill the business need

• Break a business-critical service

• Ineffective business execution

7

The Three Steps for Pain-Free Changes

1. The truth, the whole truth• Allow full access, as requested

2. Nothing but the truth• Don’t allow extra access• Keep existing connections

3. So help me god• Don’t violate the compliance policy

* patent pending

8

The Holy Grail

• Simulate traffic through the new policy• It is not enough to test a rule out of the policy context

• It’s impossible!• Scanners – too much time to scan 2^32 IPs• Not proactive

• But it would be perfect if we could…

9

The Right Tools for the Job

1. Fulfill the entire original request• Automatic change verification

2. Don’t open/close anything else closed/opened• “regression testing focuses on retesting old/existing

functions and making sure it didn’t get affected by the newly introduced code/functions”

3. Don’t violate the compliance policy• Enforce compliance policies

10

When to Test the Change

• After I make the change, but before I implement it:

1. After Save Policy

2. Before Install Policy• Survey: how many people have service windows?

3. Network forensics (postmortem)

11

Live Demo

1. SecureChange Automatic Verification

2. Access Regression Test

3. SecureTrack Compliance Policies (if time allows)