The next step in our journey to understand and select an enterprise firewall has everything to do with management. During procurement it’s very easy to focus on shiny objects and blinking lights. By that we mean getting enamored with speeds, feeds, and features – to the exclusion of what you do with the device once it’s deployed. Without focusing on management during procurement, you may miss a key requirement – or even worse, sign yourself up to a virtual lifetime of inefficiency and wasted time struggling to manage the secure perimeter.

To be clear, most of the base management capabilities of the firewall devices are subpar. In fact, a cottage industry of firewall management tools has emerged to address the gaps in these built-in capabilities. Unfortunately that doesn’t surprise us, because vendors tend to focus on managing their devices, rather than focusing on process of protecting the perimeter. There is a huge difference, and if you have more than 15-20 firewalls to worry about, you need to be very sensitive to how the rule base is built, distributed, and maintained.

What to Manage?

Let’s start by making a list of the things you tend to need to manage. It’s pretty straightforward and includes (but isn’t limited to): ports, protocols, users, applications, network access, network segmentation, and VPN access. You need to understand whether the rules will apply at all times or only at certain times. And whether the rules apply to all users or just certain groups of users. You’ll need to think about what behaviors are acceptable within specific applications as well – especially web-based apps. We talk about building these rule sets in detail in our Network Security Operations Quant research.

Once we have lists of things to be managed, and some general acceptance of what the rules need to be (yes, that involves gaining consensus among business users, tech colleagues, legal, and lots of other folks there to make you miserable), you can configure the rule base and distribute to the boxes. Another key question is where you will manage the policy – or really at how many levels. You’ll likely have some corporate-wide policies driven from HQ which can’t be messed with by local admins. You can also opt for some level of regional administration, so part of the rule base reflects corporate policy but local administrators can add rules to deal with local issues.

Given the sheer number of options available to manage an enterprise firewall environment, don’t forget to consider:

• Role-based access control: Make sure you get different classes of administrators. Some can manage the enterprise policy, others can just manage their local devices. You also need to pay attention to separation of duties, driven by the firewall change management workflow. Keep in mind the need to have some level of privileged user monitoring in place to keep everyone honest (and also to pass those pesky audits) and to provide an audit trail for any changes.
• Multi-domain administration: As the perimeter gets more complicated, we see a lot of focus around technologies to allow somewhat separate rule bases to be implemented on the firewalls. This doesn’t just provision for different administrators needing access to different functions on the devices, but supports different policies running on specific devices. Large enterprises with multiple operating units tend to have this issue, as each operation may have unique requirements which require different policy. Ultimately corporate headquarters bears responsibility for the integrity of the entire perimeter, so you’ll need a management environment that can effectively map to your the way your business operates.
• Virtual firewalls: Since everything eventually gets virtualized, why not the firewall? We aren’t talking about running the firewall in a virtual machine (we discussed that in the technical architecture post), but instead about having multiple virtual firewalls running on the same device. Depending on network segmentation and load balancing requirements, it may make sense to deploy totally separate rule sets within the same device. This is an emerging requirement but worth investigating, because supporting virtual firewalls isn’t easy with traditional hardware architectures. This may not be a firm requirement now, but could crop up in the future.

Checking the Policy

Those with experience managing firewalls know all about the pain of a faulty rule. To avoid that pain and learn from our mistakes, it’s critical to be able to test rules before they go live. That means the management tools must be able to tell you how a new rule or rule change impacts the rest of the rule base. For example, if you insert a rule at one point in the tree, does it obviate rules in other places? First and foremost, you want to ensure that any change doesn’t violate your policies or create a gaping hole in the perimeter. That is job #1.

Also important is rule efficiency. Most organizations have firewall rule bases resembling old closets. Lots of stuff in there, and no one is quite sure why you keep this stuff or which rules still apply. So having the ability to check rule hits (how many times the rule was triggered) helps ensure all your rules remain relevant. It’s helpful to have a utility to help optimize the rule base. Since the rules tend to be checked sequentially for each incoming packet, making sure you’ve got the most frequently used rules early for maximum efficiency, so your expensive devices can work smarter rather than harder and provide some scalability headroom.

But blind devotion to a policy tool is dangerous too. Remember, these tools simulate the policies and impact of new rules and updates. Don’t mistake simulation for reality – we strongly recommend confirming changes with actual tests. Maybe not every change, but periodically pen testing your own perimeter will make sure you didn’t miss anything, and minimize surprises. And we know you don’t like surprises.

Reporting

As interesting as managing the rule base is, at some point you’ll need to prove that you are doing the right thing. That means a set of reports substantiating the controls in place. You’ll want to be able to schedule specific times to get this report, as well as how to receive it (web link, PDF, etc.). You should be able to run reports about attacks, traffic dynamics, user activity, etc. You’ll also need the ability to dig into the event logs to perform forensic analysis, if you don’t send those events to a SIEM or Log Management device. Don’t neglect the report customization capabilities either. You know the auditor or your own internal teams will want a custom report – even if the firewall includes thousands built-in – so an environment for quickly and painlessly building your own ad hoc reports helps.

Finally, you’ll need a set of compliance specific reports – unless you are one of the 10 companies remaining in operation unconcerned with regulatory oversight. Most of the vendors have a series of reports customized to the big regulations (PCI, HIPAA, SoX, NERC CIP, etc.). Again, make sure you can customize these reports, but ultimately the vendor should be doing most of the legwork to map rules to specific regulations.

Other Considerations

• Integration: Since we’re pretty sure you use more than just a firewall, integrating with other IT and security management systems remains a requirement. On the inbound side, you’ll need to pull data from the identity store for user/group data and possibly the CMDB (for asset and application data). From an outbound perspective, sending data to a SIEM/Log Management environment is the most critical need to support centralized activity monitoring, reporting, and forensics – but being able to interface directly with a trouble ticket system to manage requests helps manage the operational workflow.
• Workflow: Speaking of workflow, organizations should have some type of defined authorization process for new rules and changes. Both common sense and compliance guidelines dictate this, and it’s not a particular strength for most device management offerings. This is really where the third-party firewall management tools are gaining traction.
• Heterogeneous Firewalls: This is another area where most device management offerings are weak, for good reason. The vendors don’t want to help you use competitors’ boxes, so they tend to ignore the need to manage a heterogeneous firewall environment. This is another area where third-party management tools are doing well, and as organizations continue acquiring each other, this requirement will remain.
• Outsourcing: Many organizations are also outsourcing either the monitoring or actual management of their firewalls, so the management capability must be able to present some kind of interface for the internal team. That may involve a web portal provided by the service provider or some kind of integration. But given the drive towards managed security services, it makes sense to at least ask the vendors whether and how their management consoles can support a managed environment.

Did we miss anything? Let us know in the comments.

Now that we’ve gone through many of the base capabilities of the enterprise firewall, we’ll tackle what we call advanced features next. These new capabilities reflect emerging user requirements, and are used by the vendors to differentiate their offerings.