Do We Still Need Firewalls?

In short, yes - now more than ever. There has never been a greater or more deliberate threat to information and communication systems

New technologies developed and adopted as a means for defence by vulnerable organisations have been repurposed for nefarious activities by malicious actors.

More widespread public adoption of technology has increased attack surfaces and consequently the requirement for an efficient security solution. The question isn't "whether to Firewall our environments", but rather how, says Brookcourt Solutions, as it explains below.

The term 'Firewall' has come to mean different things to different people. The traditional view of a perimeter guard is now outdated, but, rather than deem the role obsolete, the technology industry has retained it as a verb, to 'Firewall' one's environment.

A Firewall (in its simplest form) was originally an appliance sitting on a perimeter like a gateway, determining what to let into the network. This worked well for simple and flat environments. An organisation may have had a network, accessed only by its own assets (either the people or other internal systems). Traffic would flow freely inside with inspection taking place on ingress or egress.

Many of these Firewalls were 'Stateless', meaning that they used packet filtering rules to determine permissible traffic. If match conditions were met, the stateless firewall would allow the packet to enter the network; otherwise, the packet will be blocked and access denied.

But then it all got a little bit more complicated…

The Present Day Network security systems today must exist in several different states. As networks have grown more complex, so, too, has the job of the Firewall. With modern business practices, personnel and organisations need to access a network from various means and locations, even perhaps the mythical 'cloud'. Users may need to collaborate with entities outside of their network, but still receive the same level of protection. Market leaders like Cisco, Fortinet, Sophos etc refer to this as the evolution from perimeter to many micro-perimeters.

Firewalls must meet strict requirements:

IDENTIFY - Identify applications, not ports. Classify traffic as soon as it hits the firewall to determine the application identity, irrespective of protocol, encryption or evasive tactic. Then use that identity as a basis for all security policies.
CONNECT - Tie application usage to user identity, not IP address, regardless of location or device. Employ user and group information from enterprise directories and other user stores to deploy consistent enablement policies for all your users, regardless of location or device.
PROTECT - Protect against all threats - both known and unknown. Prevent known vulnerability, exploits, malware, spyware, malicious URLs while analysing traffic for, and automatically delivering, protection against highly targeted and previously unknown malware.
MANAGE - Simplify policy management. Safely enable applications and reduce administrative efforts with easy-to-use graphical tools, a unified policy editor, templates and device groups.

To achieve these requirements, there has been a move away from 'Stateless' towards 'stateful'. Now the data itself is interrogated to determine whether it may be trusted and allowed to access the network. This might involve trying to identify a 'signature' previously associated with malicious activity or similarities to previous transmissions. Naturally, Stateful sounds like an upgrade to Stateless, but with greater capability comes an increased demand in performance and possible latency issues, depending on the situation.

Cloud Access Security Broker or Secure Access Service Edge
Of course, reliance on Cloud environments continues to grow and with it the need to protect them. For this, we commonly see two solutions: Cloud Access Security Broker (CASB) or Secure Access Service Edge (SASE). CASB is a program sitting between a user and the entity it wishes to access in the Cloud. The CASB enforces policies set by an organisation for access and usage, and is particularly effective at securing Software as a Service (SaaS) platforms and integrating them into an existing infrastructure. SASE (pronounced 'Sassy') developed this further, merging a Software Defined (SD) WAN with network security, and arguably more effectively addresses an organisation's various risks and needs. Among the various positives for SASE are its use of the SD WAN, more often a more cost-effective approach and easier to deploy in complex environments.

Choosing the appropriate approach is not simple, and depends on the needs and future intent of an organisation. Some organisations still rely on legacy MPLS connections, and introducing a SASE solution would present issues and inefficiencies. Alternatively, if the organisation is looking to integrate a solution with SD WAN or Zero Trust, CASB is unlikely to be appropriate and would be difficult to implement. This would be the case even with an API version, in which the 'broker' is embedded into the API of the SaaS and so monitors all actions regardless. In both cases, success will derive from:

  • Choosing the right solution for your organisational needs
  • Fine-tuning during integration (especially with SASE)
  • Investment in upskilling your security and IT staff.
Zero Trust
One route of development of the Firewall is 'Zero Trust' or micro segmentation. The idea is that every entity must authenticate each time it wishes to access an item in the network, even if already operating inside the network. Enforcing segmentation with least-privileged access reduces the scope of lateral movement and mitigates the risk of data breaches. This may be strengthened by software-defined perimeters, where the Firewall becomes the filter in a zero-trust model. This approach requires entity-specific configuration, which is a complicated undertaking for any organisation.

The three Zero Trust approaches are:

  1. Agent based - Using a software that may use a solution's in-built capabilities
  2. Network based - Using SD WANs and physical infrastructure, like switches, to enforce policies
  3. Native Cloud - Offered by all the main providers, embedding their service into a cloud platform and using some of the host's capabilities.
Most leading security solution providers can offer services to meet all these needs, including Next Generation Firewalls (NGFWs), Virtual Firewalls for deployment into Cloud environments, and supporting management and threat integration consoles/portals.

The Future of Firewalls
We are living in a unique time with regards to technology as the pace of development has only accelerated and keeping up can be a challenge. Next Generation Firewalls used to be a very attractive option when applications lived in our data centres.

However, with most organisations now relying solely on internet communications, sending traffic to the data centre for inspection affects the performance and user experience, and many are turning to 'FireWall as a Service' (FWaaS) solutions to enable flexibility and scalability. Whilst industry leaders are using quantum computing and artificial intelligence, some organisations are still operating simple networks with a Stateless Firewalls. Most organisations are migrating some or all of their environments to Cloud services.

‘To firewall’ or ‘firewalling’
The most effective solution at present appears to be pushing the Firewall activity to the endpoints, if practical. This is where we see the introduction of 'To Firewall', or 'Firewalling', the practice of achieving the function of a firewall across your complex network. We believe there are significant benefits to choosing a supplier to execute this activity.

Taking a holistic approach enables the systems to work together. However, this assumes that organisations have single suppliers for their security solution or suppliers that can operate efficiently together. Organisations will need to decide whether to use a single preferred provider, which increases concentration risk; or select 'best of breed' solutions from various providers and bear the higher costs of integration.