Firewalls

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.

1989 Firewall is Born				The story begins in 1989 with the birth of packet filtering firewalls which were used to achieve simple control over access. Following this came proxy firewalls which acted as application layer proxies for communication between internal and external networks.
1994 The Firewall Changes for Good				In 1994, an Israeli based security company released the world’s very first stateful inspection based firewall.
1995 Mainstream Growth				Stateful inspection firewalls became much more mainstream. Additional support for more advanced features (ex. VPN) and functions (ex. Access control methods) were added.
2004 UTM				In 2004, the unified threat management- (UTM) theory was introduced. This combined traditional firewalls, intrusion detection, anti-virus, email filtering, and other functions into a firewall
2008 NGFW Introduction				The first Next-Generation Firewall was released from a California based company. NGFW focused on performance degradation when enabling multiple functions and also allowed for better management of users, applications, and content. In 2009, Gartner defined “NGFW” as criteria firewalls should possess.
2019 The Service-defined Firewall Changes Landscape Forever				The Service-defined Firewall is the industry’s first purpose-built internal firewall. It delivers intrinsic stateful layer 7 firewall protection to prevent lateral movement and other attack vectors specific to the internal network of on-prem, hybrid, and multi-cloud environments.

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…

Cloud Access Security Broker (CASB) or Secure Access Service Edge (SASE)

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 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 perimeter, 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.