120 likes | 322 Views
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. tufin.com/blog. tufintech. Context: We Make Changes. Firewall Operations Management
E N D
The Joy of Firewall Policy ManagementReuven HarrisonTufin Technologies
whoami Reuven Harrison CTO and Co-Founder of Tufin Technologies My Check Point service: 4 years in R&D reuvenharrison tufin.com/blog tufintech
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
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
Many Ways to Change Access Add a new rule Add a host to a rule Add a host to a group Delete a rule Disable/Enable a rule Remove a host from 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
The Three Steps for Pain-Free Changes The truth, the whole truth Allow full access, as requested Nothing but the truth Don’t allow extra access Keep existing connections So help me god 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…
The Right Tools for the Job Fulfill the entire original request Automatic change verification 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” Don’t violate the compliance policy Enforce compliance policies
When to Test the Change After I make the change, but before I implement it: After Save Policy Before Install Policy Survey: how many people have service windows? Network forensics (postmortem)
Live Demo SecureChange Automatic Verification Access Regression Test SecureTrack Compliance Policies (if time allows)