Our website uses cookies

Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing Infosecurity Magazine, you agree to our use of cookies.

Okay, I understand Learn more

Comment: The Lifecycle of a Firewall Rule

Eliminating unused firewall rules can help improve network performance
Eliminating unused firewall rules can help improve network performance
Journey of a firewall policy rule
Journey of a firewall policy rule

As all firewall managers know, creating firewall policies can be long and tortuous, with not much light at the end of the tunnel. With the right tools and techniques, however, what used to be a pain can now be a pleasure with the added bonus that getting it right can improve your network performance, security and manageability.

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.

The Life and Times of a Firewall Policy Rule

Please see the infographic (right) where I’ve summarized the journey of a firewall policy rule.

These unused or “stale” rules are a hidden menace to your firewall policy rulebase. First of all, they slow down performance – because 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 as the manager also 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?

Eliminating 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, then you can centrally document the rule and expiration date and view them regularly to check that the rules are up to date.

When rules are about to expire, automated tools such as 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. Firewall managers 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 the relevant requestor, project and approvers for expired rules.

With the right tools, rule recertification can be built into the security process. You just need to 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, firewall managers 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 me know.


Reuven Harrison co-founded Tufin Technologies in 2003, serving a vital role as CTO during the company’s fast-paced growth as a worldwide provider of solutions that enable IT administrators to effectively audit, monitor and optimize ever-growing firewall policies. Harrison leads Tufin’s development staff, managing all product architecture while ensuring seamless integration with all leading firewall vendors. He brings more than 20 years of software development experience, holding two key senior developer positions at Check Point Software, as well other key positions at Capsule Technologies and ECS. Harrison received a bachelor’s degree in mathematics and philosophy from Tel Aviv University.