Lost in Translation? Managing Mixed Firewall Estates

Written by

Once upon a time, most organizations used conventional firewalls on their networks, and managing them was relatively simple. The first firewalls used stateless access lists, which required users to explicitly configure rules both for outgoing and returning traffic, were the bedrock of early network security – some stateless access lists are still in use today within routers.

However, the firewall has evolved dramatically since those early days, with each stage of evolution adding more sophisticated security features – thereby making management of firewall estates more complex.

The first evolution was the stateful firewall, which can filter bi-directional traffic streams as a whole, requiring users to write policy only for the outgoing traffic. This was followed by the next-generation firewall (NGFW), which supports more granular filtering and deep packet inspection to identify application-specific traffic, not just network protocols and port numbers.

There were more changes with the adoption of virtualization in data center, leading to the development of virtualized firewalls, adding even more tools to be managed. Now with the move to private and public clouds, yet more security controls are available: commercial cloud firewalls, the cloud providers’ own controls, or host-based firewalls.

As these are increasingly deployed on organizations’ expanding, hybrid networks, they also multiply the complexity of managing the different devices, and handling change processes across these mixed environments.

Translation problems

The current reality is that organizations typically have very mixed environments: a mixture of firewall generations, technologies, and vendors. Managing such a mix is a challenge because each generation of firewalls, and each vendor’s products, use different syntax and semantics for creating security policies.  

For example, let’s look at an enterprise network which uses both traditional firewalls and NGFWs. The organization may have a company-wide policy of blocking access to social media sites, but its marketing department needs to be able to access Facebook. Facebook traffic passes through both types of firewall – which means new security policies need to be written for both.

For the NGFW, this is simple and intuitive. Facebook can be set as a predefined, ‘allowed’ application in the firewall rulesets, while access to other social media sites, and from other departments, is blocked. However, the traditional firewall cannot understand the term ‘Facebook’: it needs to be given the default ‘source’, ‘destination’, ‘service’ and ‘action’ protocols that Facebook uses – http and https.

So actually making the security policy changes on the NGFW and traditional firewall involves very different processes and languages. The engineers configuring the devices must clearly understand the mapping between the applications (as they are defined in the NGFW), and their respective services, protocols and ports (as defined in the traditional firewall), so that the rules and policies can be set properly across both environments.

Any mistake or ‘translation error’ between products when writing those policies or making network changes has the potential to cause unexpected application outages or introduce security holes, either because crucial traffic is inadvertently blocked, or other traffic accidentally allowed. Multiply this across the dozens or even hundreds of firewalls on a typical enterprise network, and it’s a recipe for a hot mess.

Cloud complications

When these processes are extended to cloud deployments, IT teams encounter additional challenges, depending on the cloud security controls being used. One cloud provider may offer the ability to have multiple security groups associated with a particular server; while another may allow only a single security groups – but may also allow security groups associated with all the servers in a VLAN.

At a high level, you may be able to identify a lowest common denominator for basic traffic filtering, but once you want to start doing more elaborate, granular filtering required for enterprise networks, some providers will have certain capabilities and others will not.

Each provider has a different semantic model of what you can filter, and where those controls are applied; these will also differ from the on-premise firewalls that an organization will already have in place.

These different languages mean that taking an organization’s security policy, and applying it across several different types of firewall across a heterogeneous network environment is extremely complicated – meaning that making even outwardly simple changes (such as enabling Facebook or YouTube access for a department in the company) is fraught with risk.

Breaking down language barriers

So how do you remove the risk from making what should be simple, business-led changes to security policies – and reduce the need for IT teams to have to speak multiple firewall languages fluently? What’s needed is a way to translate between the different syntaxes and phrases that each type of security control – whether on premise or in the cloud – used to build its rules and policies, so that IT teams can make their security estate understand the language of their business.

To transcend language barriers and effectively optimize and manage security across a mixed environment from a single console with a single set of commands, you need an automated management solution with four key capabilities:

Visibility and control: You need to be able to visualize all of the firewalls, gateways and security controls on your entire network, in a single pane of glass.

Managing normal changes. You need to be able to configure and manage these security products holistically as part of normal, day-to-day operations. So the solution you choose must be able to translate and interpret the different syntax and logic used by all your various security controls, and automate the implementation of security policy changes consistently. The solution should also document all these changes.

Managing larger changes. Major network architecture changes also place great demands on security policy management. You need to be able to automatically adjust your security policies across the heterogeneous environment when you migrate data centers or applications to the cloud, for example, or when a team moves from one vendor to another.

Demonstrating compliance. Network security is a key area that you need to be able to demonstrate compliance to auditors and regulators. A solution which automatically tracks all processes and changes, proactively assesses risk and provides out of the box audit reports, can help be audit-ready and maintain continuous compliance.

A common tongue

With the right solution, organizations can ensure that their entire estate of firewalls both understands, and responds to a common security requirement, no matter where they are deployed.

This enables policies to be applied consistently, without time-consuming, error-prone manual processes, and ensures network traffic can move securely across both on-premise networks and private or public clouds environments. After all, your business’ security and compliance are two things that you can’t afford to get lost in translation.

What’s hot on Infosecurity Magazine?