Don’t get lost in translation when managing mixed firewall estates

Tuesday, June 27, 2017

Avishai Wool

259aa33b32fc31717e8a18f2dc9edc19

The first commercial firewall, the DEC SEAL, shipped in 1992. 25 years later the firewall is still the core building block of organizations’ security infrastructures. Of course, it has evolved dramatically since those early days, with each stage of evolution adding ever more sophisticated security features.

We’ve evolved from the stateful firewall which filters bi-directional traffic streams as whole, requiring users to write policies only for outgoing traffic, to 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. The adoption of virtualized datacenters lead to the development of virtualized firewalls, adding even more devices that need to be managed. And now, with the move to private and public clouds, there are even more security controls available:  commercial cloud firewalls, the cloud providers’ own controls, and host-based firewalls.

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.

And again, 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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 requirements, 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.

Possibly Related Articles:
64790
Firewalls Enterprise Security Policy
Firewall requirements Network DEC SEAL
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.