- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
30 days of cloud network security
Given all the changes in the way we build and deploy applications—from the cloud, to microservices and containers—it’s helpful to reassess what a firewall is in today’s cloud native age.
The term “firewall” became a part of the IT lexicon in the 1980s when computers were moving out of research and academic facilities and into very early enterprise use—eons ago in computing years. Back then, networks and computing infrastructure were much simpler than they are today, as were the security considerations for networked computers and applications.
Because of these differences, it’s difficult to speak of firewalls now in the same sense in which the term was used in the 1980s (or even the 1990s or 2000s). Given all the changes that have occurred in the way we build and deploy applications—from the advent of the cloud, to the shift toward microservices and the explosive popularity of containers—it’s helpful to reassess what a firewall is in today’s cloud native age.
It’s easy to define what a firewall used to mean. Put simply, a firewall was a hardware device or software application that determined which network traffic to accept and which to reject based on preconfigured rules.
This way of thinking about and building firewalls made sense in a bygone era, when the following conditions were true:
About a decade ago, when most businesses began shifting their workloads toward a cloud-centric infrastructure, those conditions ceased to hold true in several instances.
Networks no longer have fixed perimeters. Instead, the blending of local and cloud-based environments means that the network on which your organization depends likely extends into the public internet and public cloud.
Additionally, identifying malicious traffic is now no longer as simple as registering which IP addresses to block. Bad actors have become more adept at hiding their tracks by taking advantage of VPNs, botnets and other means of obscuring the true origins of network traffic. This makes IP addresses a less useful identifier of malicious traffic.
Looking at protocols and the nature of the traffic itself has become more important than simply tracking traffic origin. This is all the more true because the increasing prevalence of insider attacks means that many breaches now start from within the network, and blocking external traffic is therefore not sufficient for keeping systems secure.
We now live in a world where the most secure approach is to assume that all network traffic is malicious, and we should accept only traffic that we know to be safe. This is why it’s now common to use whitelists, rather than blacklists, as the basis for controlling network traffic.
These network changes mean that today's firewalls – if they want to stand a decent chance of being effective for cloud-native, microservices-based, software-defined infrastructure – are very different from their past counterparts.
It’s now important to think about your firewall not just as a singular tool, but to draw a distinction between layer 3 and layer 7 firewalls. Each layer represents a different firewall tool that mitigates different kinds of risks. It’s not an either/or question; in most cases, you’d use both a layer 3 and a layer 7 firewall at the same time.
Layer 3 firewalls (network firewalls) | Layer 7 firewalls (application firewalls) |
|
|
Yet, the lack of protocol awareness in layer 3 is a significant blind spot the layer 7 firewall addresses. As HTTP has become the universal app protocol, attackers are more likely to probe and exploit weaknesses within the app layer. So if you just have a layer 3 firewall that allows all traffic to port 80, you’re blind to those risks. A layer 7 firewall provides visibility, however, because it is able to look within the app layer and make decisions about whether to allow a request based on what it contains, not just the port it’s trying to reach. This is a more computationally costly operation, but one that provides significantly greater security.
The multi-layered nature of firewalls today also speaks to the ways in which overall firewalling strategies have changed. Given the complex nature of today’s security threats, the numerous ways in which they can manifest themselves, and the difficulty of tracing them to their original sources, it no longer suffices to think of network security as a single-layer task.
Instead, the best model for most scenarios is to use multiple layers of defense in-depth. You need a layer 3 firewall at the edge that only allows inbound traffic on the specific ports your apps use. Those ports should then be routed to a layer 7 firewall for deep inspection at the app protocol level. This model leverages the strengths of each approach, with the layer 3 firewall efficiently dropping all packets but those from allowed sources and destined to allowed ports, thus allowing the layer 7 firewall to focus exclusively on inspecting the content of the requests to those ports.
In its simplest form, the definition of a firewall as it was established in the 1980s holds true today, in the sense that a firewall is a tool that blocks certain kinds of traffic.
However, today’s firewalls look and act very differently than those of the past. Modern, cloud native firewalls are dynamic. They use data and analytics to make informed, real-time decisions about which traffic to allow in. That’s very different from the firewalls of old, which operated according to preset configurations.
In addition, modern firewalls fall into two main categories—layer 3 and layer 7 firewalls. Both have advantages and drawbacks, as explained above, and both are essential tools for a modern security strategy.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Subject | Likes |
---|---|
7 Likes | |
2 Likes | |
2 Likes | |
1 Like | |
1 Like |