Now that you have a solid, repeatable, and automated firewall change management process, it’s time to delve into the next major aspect of managing your firewalls: optimizing rules. Back in our introduction we talked about how firewall rule sets tend to resemble a closet over time. You have a ton of crap in there, most of which you don’t use, and whatever you do use is typically hard to get to. So you need to occasionally clean up and reorganize – getting rid of stuff you don’t need, making sure the stuff that’s still in there should be, and arranging things so you can easily access the stuff you use the most. But let’s drop the closet analogy to talk firewall specifics. You need to optimize rules for a variety of reasons:

1. Eliminate duplicate rules: When you have a lot of hands in the rule base, rules can get duplicated. Especially when the management process doesn’t require a search to make sure an overlapping rule doesn’t already exist.
2. Address conflicting rules: At times you may add a rule (such as ALLOW PORT 22) to address a short-term issue, even though you might have other rules to lock down the port or application. Depending on where the rule resides in the tree, the rules may conflict, either adding attack surface or breaking functionality.
3. Get rid of old and unused rules: If you don’t go back into the rule set every so often to ensure your rules are relevant, you are bound to have rules that are no longer necessary, such as access to that old legacy mainframe application that was decommissioned 4 years ago. It is also useful to go back and confirm with each rule’s business owner that their application still needs that access, and they accept responsibility for it.
4. Simplify the rule base: The more rules, the more complicated the rule base, and the more likely something will go wrong. By analyzing and optimizing rules on a periodic basis, you can find and remove unneeded complexity.
5. Improving performance: If you have frequently used rules at the bottom of the tree, the firewall needs to go through every preceding rule to reach them. That can bog down performance, so you want the most frequently hit rules as early as possible. Without conflicting with other rules, of course.
6. Controlling network risk: Networks are very dynamic, so you need to ensure that every network or device configuration change doesn’t add attack surface, requiring a firewall rule change.

For all these reasons, going through the rule base on a regular basis is key to keeping firewalls running optimally. Every rule should be required to support the business, and optimally configured.

Key Firewall Management Rule Optimization Features

The specific features you should get in your firewall management product or service apply directly to the requirements above.

1. Centralized management: A huge benefit of more actively managing firewalls is the ability to enforce a set of consistent policies across all firewalls, regardless of vendor. So you need a scalable tool that supports all your devices. You should have a single authoritative source for firewall policies.
2. Rule change recommendations: If a firewall rule set gets complicated enough it’s hard for any human – even your best security admin – to keep everything straight. So a tool should be able to mine the existing rule set (thousands of rules) to find and get rid of duplicate, hidden, unused, and expired rules. Tools should assess the risk of the rules, and flag rules which allow too much access (you know: ANY ANY).
3. Optimize rule order: A key aspect of improving firewall performance is making sure the most-hit rules are closer to the top of the tree. The tool should track which rules are hit most often through firewall log analysis, and suggest an ordering to optimize performance without increasing exposure.
4. Simulating rule changes: Clever ideas can turn out badly if a change conflicts with other rules or opens up (or closes) the wrong ports/protocols/applications/users/groups, etc. The tool should simulate rule changes and a prediction of whether the change is likely to present problems.
5. Monitoring network topology and device configuration: Every network and device configuration change can expose additional attack surface, so the tool needs to analyze every proposed change in context of the existing rule set. This involves polling managed devices for their configurations on a periodic basis, as well as monitoring routing tables.
6. Compliance checking: Related to monitoring topology and configurations, changes can also cause compliance violations. SO you need the firewall management tool to flag rule changes that might violate any relevant compliance mandates.
7. Recertify rules: The firewall management tool should offer a mechanism to go back to business owners to ensure rules are still relevant and that they accept responsibility for their rules. You should be able to set an expiration date on a rule, and then require an owner to confirm each rule is still necessary. Getting rid of old rules is one of the most effective ways to optimize a rule set.

Asking for Forgiveness

Speaking of firewall rule recertification, you certainly can go through the process of chasing down all the business owners of rules, if you know who they are, and getting them to confirm each rule is still needed. That’s a lot of work. You could choose a less participatory approach as well: make changes and then ask forgiveness if you break something. There are a couple options with this approach:

1. Turn off unused rules: Use the firewall management tool’s ability to flag unused rules and just turn them off. If someone complains you know the rule is still required and you can assume they would be willing to recertify the rule. If not you can get rid of it.
2. Blow out the rule base: You can also burn the rule base to the ground and wait for complaints to start about applications that broke as a result. This is only sane in dire circumstance, where no one will take responsibility for rules or people are totally unresponsive to your attempts to clean things up. But it’s certainly an option.

NGFW Support

With the move to next-generation firewalls (NGFW), you need to start managing policies which are not simply based on port/protocol/source/destination combinations. You have to address applications, identities, and content. Even better, you can get very granular in what is allowed for specific applications, so you will be able to set specific policies for key application features such as Facebook chat and Twitter Direct Messages.

Your firewall management tool needs to not only support and optimize these advanced rules, but also to facilitate the migration to application-aware rules. By analyzing firewall logs, the tool should be able to suggest a set of NGFW policies to reflect your organization’s usage patterns for websites and other applications. Many NGFW vendors have their own tools to facilitate this migration, but none are heterogeneous, and they tend to ignore optimization once the rules are migrated.

The addition of threat prevention (IPS) and malware detection to the NGFW also adds complexity to your rule base. Over time you should expect your firewall management tool to be able to configure, optimize, and tune attack policies – and to define specific actions based on malware determinations. These are not your grandpappy’s firewall – they require a much more sophisticated operational environment to keep the rules under control.

Firewall Migration

Another value-add aspect of a firewall management tool is heterogenous firewall support. Firewall vendors treat their devices like the Hotel California. Once you import rules they never want you to leave. Firewall vendors have little incentive to offer easy migration to competing devices.

But that may not fit the way you want to run your environment. Now that many organizations are re-architecting the perimeter, there may be devices available to move to smaller offices. Or you might make an acquisition, and have a bunch of old (but still useful) gear waiting to be deployed. In this case you want your firewall management tool to enable quick and easy redeployment of firewalls, regardless of vendor.

This involves analyzing existing policies on each device to be replaced, optimization for the new device (especially if it is a NGFW), and recommending specific policies for implementation. You do the same process on every redeployed firewall, taking the opportunity to analyze and optimize policies based on topology and application requirements.

One of the areas we glossed over as we discussed optimizing rules is effectively managing the risk of changing network topologies, firewall configuration, and rule changes. Our next post will dig into the increasingly important discipline of risk management within the context of firewall management.