We live in the cloud-native era. That means the firewall strategy that worked for you in the days before containers, microservices and serverless is no longer sufficient for keeping applications and infrastructure secure. Here’s why.
If you’ve been around the world of IT for awhile, you remember a simpler time: a time when Sun Microsystems was still a thing, your servers were reliably updated every Patch Tuesday and Clippy taught you everything you needed to know (or didn’t need to know) about your word processor.
Fast forward to the present, however, and those happy days of yore are long gone. IT professionals now have to contend with a new, more complex generation of technologies, while still managing the old ones to boot. Knowing how to deploy and secure VMware is no longer enough. Today’s DevOps engineers also have to understand the ins and outs of multiple cloud-computing services, Docker, Kubernetes, serverless computing and more in order to do their jobs effectively. These are the technologies that define the cloud-native era in which we now live.
What does all of this mean for your firewall? That may not be the first question you ask yourself as you ponder just how much the IT world has changed over the past couple of decades. But it is a question you need to answer if you want to keep all of your applications and infrastructure secure today.
Let’s explore the role of firewalls in the cloud-native era.
Firewalls Still Exist
To start with the obvious, firewalls still exist, and are still useful tools. The point of this article is not to argue that firewalls are obsolete.
By restricting network access to specific applications or hosts, firewalls provide one useful layer of security. They’re especially handy for helping to secure applications and infrastructure that don’t need to be exposed at all to the public Internet, or integrated with the cloud.
Perimeters Rarely Exist
But the tricky thing about the cloud-native era is that it’s rare to find a resource that can be entirely firewalled off from the rest of the world. As a result, in most cases, it becomes impossible to define a clear perimeter that can be effectively secured by a firewall alone.
Today, even on-premises infrastructure that hosts internal business applications usually has to connect to outside services. Your accounting department’s apps might use S3 for storage even if the applications themselves are hosted on-premises, for example. Or maybe you store all of your data on-premises, but back it up to the cloud. In both of these scenarios, you have no fixed perimeter and you can’t simply set up a firewall to prevent malicious access to your applications and data. (Well, you could, but then the applications and data would become useless because they would stop working properly without being able to access external resources.)
Everything is Dynamic
You may be thinking “But wait! Can’t I use a firewall to restrict all external traffic, except for specific hosts that I whitelist?”
Probably not. The problem with this strategy—which worked quite well in earlier, simpler times—is that today, software environments tend to be highly dynamic. You can’t count on the IP addresses or even hostnames of external resources to remain consistent.
Think about how hard it would be to whitelist IP addresses for employees who want to connect to an internal business application remotely from their homes, for example. You have no good way of knowing what the IP addresses of their home PCs are. Even if you did, those addresses are probably not static, so you’d have to update your whitelist constantly. And even if the addresses were static, the employees might also want to access the applications from their phones, which creates a whole new set of whitelisting challenges.
When you add the network connections that facilitate communications between microservices to the mix, network addresses get even more dynamic. Port numbers and host addresses change constantly. Automated service discovery allows the services to handle this complexity, but it doesn’t allow you to define a perimeter that you can firewall off.
By the way, attempting to limit the dynamism of your infrastructure in order to mitigate the issues just described is a poor approach. Sure, you could forswear microservices and keep your old firewall, but then you won’t reap the many benefits of an agile microservices architecture. Or you could keep all of your workloads in the same public cloud. That would make firewall configuration much simpler, but it would also likely mean that you end up paying more for certain services than you would if you could host them in other clouds. And it would limit your ability to change cloud providers, which would be bad.
If we learned anything in the 1990s, it’s that vendor lock-in is a horrible thing. Self-imposed vendor lock-in due to legacy firewall needs is even worse.
If you can’t count on having a well-defined perimeter or a persistent configuration for your workloads, can you still use a firewall at all?
The answer is yes—provided you have a cloud-aware firewall that can constantly and automatically update its configuration as your applications and hosts move between different clouds, IP addresses, ports, and so on.
These firewalls exist, but they’re not the kind that come built into your operating system or network switches. A new generation of security vendors is designing cloud-aware firewalls that can accommodate containers, microservices, serverless environments and other dynamic, perimeterless technologies.
Securing modern infrastructure and applications also means taking a multi-layered approach. Your cloud-aware firewall is a great tool, but it should not be the only one in your arsenal. You should also be scanning container images and serverless code for malware, checking for runtime vulnerabilities in real time, hardening the network, etc.
This is because, unlike the days when a firewall coupled with an antivirus scanner was enough to keep your hosts secure, today’s threats come in a variety of shapes and sizes. You probably won’t even know which kind of attack intruders will next execute against your infrastructure until it is already underway. A cloud-native firewall can help to keep them out, but depending on the type of attack, it may or may not be effective. You want additional lines of defense.
Related Cloud-Native Security Posts:
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Safer Software with Twistlock and Google’s Binary Authorization for GKERead the Blog
Announcing Our Series C FundingRead the Blog
Real Time View of Your Cloud Native Applications: Radar v3Read the Blog
AWS Fargate Security: Runtime Defense with Twistlock 2.5Read the Blog
Cloud Native Forensics: Security Incident Response in Twistlock 2.5Read the Blog