The Life and Times of a Firewall Policy Rule In the infographic below we’ve summarized the (long and sometimes tortuous) life of a firewall policy rule. Firewall rules are born and modified as a result of access requests from users or IT projects. And over time, they become irrelevant – because applications, services and networks change, and users leave.
These unused or “stale” rules are a hidden menace to your firewall policy rule base. First of all, they slow down performance – since the firewall has to scan all of the rules from the top for every traffic request. Second, they are a threat to security – they may leave access open to an unwanted visitor. And finally, they are a blow to manageability. Just like the firewall, you too need to go through the whole list of rules each time you handle a change request. To fully comprehend this, next time you design a policy change, imagine what it would be like for a junior team member to do it instead. How easily would they locate the rule that needed to be changed?
How to Eliminate Unused Rules
The road to eliminating unused rules starts with prevention. First of all, document your rules in the comment field, and indicate the rule owner. Use firewall mechanisms (such as Check Point Time Objects or Cisco Rule Expiration) to set an expiration date. Periodically check for expired rules and recertify them by contacting the owner and determining whether they are still needed.
The next thing you can do is analyze traffic logs (or hit counts on Cisco) to see which rules are, and are not being used. Then you can delete the unused rules. This is pretty tough to do on your own, but if you have a fairly small rule base, you could give it a try.
Using Automated Tools
If you have an automated tool like Tufin SecureTrack, you can document the rule and/or ACL owners (business and technical) and expiration date centrally and view them in every instance of the rule/ACL.
When rules are about to expire, SecureTrack will notify you, or you can generate a report of expired rules. If you are using vendor tools such as Check Point time objects, you can use the Rule Expiration report in SecureTrack to retrieve these notifications – otherwise they are built into the Rule Documentation and Expiration view. You can use the Rule and Object Usage report to automatically analyze traffic logs and identify unused rules. You can also define this as a periodic report and have it sent directly to your inbox.
When servers and services need to be changed or decommissioned, you can easily analyze the policy to find instances of the objects and rules that need to be adjusted.
You can also associate each firewall rule/ACL to the ticket that triggered it by annotating the rule/ACL comment with the ticket ID. This way you can easily find out the relevant requestor, project and approvers for expired rules.
With SecureChange Workflow, rule recertification is built into the process. You define an expiration date for every access request, and receive an automatic notification when it expires.
In Short…
Through a combination of rule documentation, expiration and recertification, combined with regular checks for unused rules, you can identify irrelevant rules as soon as possible, and prevent degradation of performance, security and manageability.
If you have developed other methods for keeping your firewall rulebase/ACL in shape, or have any ideas for the rule lifecycle graphic, let us know.
Reuven Harrison
CTO
Tufin Technologies
Don't miss out on more Tufin blogs
Subscribe to our weekly blog digest
