Top 5 best practices for firewall administrators

From Michael Hamelin, chief security architect for Tufin Technologies, the Top 5 best practices for firewall administrators….

Document all firewall rule changes.
While this tip sounds like a no-brainier, firewalls do not have a change management process built into them, so documenting changes has never become a best (or even a standard) practice for many organizations. If a firewall administrator makes a change because of an emergency or some other form of business disruption, chances are he is under the gun to make it happen as quickly as possible, and process goes out the window. But what if this change cancels out a prior policy change, resulting in downtime? This is a fairly common occurrence.

Firewall management products provide a central dashboard that provides full visibility into all firewall rule bases, so all members of the team have a common view and can see who made what change, when they made it and from where. This makes troubleshooting and overall policy management much easier and more efficient.

I frequently see firewall changes happening outside of the change process in practice. It irked me, as I am a process purist at heart. However, when I gained total control over the process, I found it just was not efficient to try to subject firewall changes to the normal process, or even the emergency process. Unfortunately, most organizations cannot get funding for firewall management products, thus the reason why documentation is so critical.

Install all access rules with minimal access rights.
Another common security issue is overly permissive rules. A firewall rule is made up of three fields: source (IP address), destination (network/subnet) and service (application or other destination). In order to ensure there are enough open ports for everyone to access the systems they need, common practice has been to assign a wide range of objects in one or more of those fields. When you allow a wide range of IP addresses to access a large group’s networks for the sake of business continuity, these rules become overly permissive, and as a result, insecure. A rule where the service field is ‘ANY’ opens up 65,535 TCP ports. Did the firewall administrator really mean to open up 65,535 attack vectors for hackers?

This (above) is a valid principle everywhere, whether configuring networks, operating systems, databases, or apps.

Verify every firewall change against compliance policies and change requests.
In firewall operations, daily life centers around finding problems, fixing problems and installing new systems. In the cycle of installing new firewall rules to solve problems and enable new products and business units, we often forget that the firewall is also the physical implementation of the corporate security policy. Every rule should be reviewed to understand that it meets the spirit and intent of the security policy and any compliance policies, not just the letter of the law.

So here’s why there needs to be change management around firewall mods!

Remove unused rules from the firewall rule bases when services are decommissioned.
Rule bloat” is a very common occurrence with firewalls because most operations teams have no process for deleting rules. Business units are great at letting you know they need new rules, but they never let the firewall team know they no longer need a service. Getting into the loop on server and network decommissioning as well as application upgrade cycles is a good start for understanding when rules need to come out. Running reports on unused rules is another step. Hackers like the fact that firewall teams never remove rules. In fact, this is how many compromises occur.

Perform a complete firewall review at least twice per year.
If you are a merchant with significant credit card activity, then this one is not just a best practice but a requirement; PCI requirement 1.1.6 calls for reviews at least every six months.

Firewall reviews also are a critical part of the maintenance of your firewall rule base. Your networks and services are not static so your firewall rule base should not be either. As corporate policies evolve and compliance standards change, you need to review how you are enforcing traffic on the firewalls. This is a good place to clean up all those redundant rules that have been replaced by new rules, rules for services no longer used that you were not informed about, and all those temporary exceptions that were added to get projects, acquisitions, mergers and so on finished. The best way to keep bad things from happening is to not create an environment where they can.