The Joy of Firewall Policy Management Reuven Harrison

The Joy of Firewall Policy Management Reuven Harrison Tufin Technologies

whoami • Reuven Harrison • CTO and Co-Founder of Tufin Technologies • My Check Point service: 4 years in R&D reuvenharrison tufintech tufin. com/blog 2

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 3

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 4

Many Ways to Change Access 5 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. Add a new rule Add a host to a group Delete a rule Disable/Enable a rule Remove a host from a group Add a rule to global policy (P-1) Add a host to a global rule (P-1) Add a host to a global group (P-1) Delete a global rule Delete a host from a global rule (P-1) Delete a host from a global group (P-1) Reorder rules Edit a network range Modify a Group with Exclusion Change a rule target (Install On) Policy Save As Change a time object Change user access ….

The Impact • Fail to fulfill the business need • Break a business-critical service • Ineffective business execution 6

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 • 7 Don’t violate the compliance policy * patent pending

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

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 • 9 Enforce compliance policies

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

Live Demo 1. Secure. Change Automatic Verification 2. Access Regression Test 3. Secure. Track Compliance Policies (if time allows) 11