Firewalls are simple things. They stand in front of other things to keep stuff from passing through. The origin of the term is about the walls built in buildings to prevent the spread of fires. But the modern application of the term is all about the technology discussion around them.
Firewalls are probably the most recognizable aspect of perimeter security. They are the bastion that prevents bad actors from invading. They prevent software from scanning your network and doing recon on everything. They hold the line against the darkness. But they are also very static in nature. The very first firewalls needed specific network configurations in order to operate correctly. Traffic needed to pass through the device in order to be inspected and secured. And if there was an entry or exit point on your network that wasn’t secured by the firewall and someone found out about it, all bets were off at that point.
As networking and security became more focused on the software side of things, firewalls naturally moved with it. Now, instead of having to put up a firewall at the network perimeter, either on the WAN edge or the datacenter edge, you could install a firewall per host. Maybe it was something as simple as the Windows firewall protecting your entire server. Or it could be the VMware host-based firewall protecting each individual VM on your machine. It worked well for a long time.
But the world of today isn’t the world that VMware was created in. The idea of a “host” has quickly become as antiquated as a mainframe. We live in a serverless world full of cloud-native applications running in containers and processes that can run on multiple machines. The idea of a single server or a single operating system running every aspect of an application is falling out of vogue. Instead, the idea that applications are nebulous constructs consuming available resources from wherever they can find them is the new norm.
How can you protect an application with no host? How can you secure access to a process that lives for mere seconds or minutes? If you can’t even measure the location of an application, how can you build a firewall around it?
VMware Service-Defined Firewall
During Security Field Day 3, the delegates and I got a great look at the new VMware Service-Defined Firewall from Dhruv Jain. Here’s a link to the video that we recorded:
The Service-Defined Firewall shows that VMware is rethinking the role of a firewall for the modern serverless datacenter, much as they did for the shift from physical to virtual machines. Just because the host has disappeared, doesn’t mean there isn’t traffic flowing back and forth across your applications. East-to-West traffic is quickly growing to eclipse North-to-South traffic. It makes sense when you think about it logically. Applications are crunching data amongst themselves and spending less time sending data back and forth to the users.
VMware designed the Service-Defined Firewall to be both distributed and elastic. That’s a huge change from the way we used to design static hardware firewalls. The old mentality used to be “buy the biggest one they have, buy a second identical one, and hope it’s enough”. Most of the time, it wasn’t. Once you hit the throughput limitations of the single firewall, you had to get creative, and you figure out how to use both of them at once. And should one of them fail and require all of the traffic running across that unit have to be sent to the other box, you’re going to have a meltdown.
The Service-Defined Firewall is Layer 7 aware. That means it’s not looking at IP addresses or port numbers to make decisions. It is aware of the applications that it’s protecting. It also means that the firewall can track important aspects of application communication. If the app needs to talk to another server, the firewall can see that and allow it. If the app suddenly starts talking to something that is outside the scope of normal, the firewall can lock that communication down. It can also disallow communications from untrusted or unauthorized sources. This is a huge component of Zero Trust Networking, which helps security teams ensure that users, hosts, and applications are only talking to the servers that they need to talk to and nothing is being broadcasted that shouldn’t be.
Don’t think that the uses for a service-oriented firewall are restricted to just the infrastructure teams. Developers will love the fact that they no longer have to futz with temperamental devices blocking the communications. As long as it’s properly defined in their programs and services, the Service-Defined Firewall will recognize it and automatically allow or deny it. This simple security keeps your development teams safe and allows them to have frictionless coding.
Bringing It All Together
The world isn’t the same as it was when I started in IT. Applications don’t install from CDs and run on my machine alone. They’re in the cloud and distributed to handle any load that might come up. And that means they’re more difficult to secure and protect. The methods we use to do that have to change along with the times. VMware has transformed firewalls before and it looks like they’re ready to do it again with the Service-Defined Firewall.
If you’d like more information on VMware’s Service-Defined Firewall along with their other security solutions, make sure you visit http://VMware.com
