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.
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.
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:
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.
Receive notifications of new posts by email.