Aviatrix Blog 
It’s All About Risk
Earlier this spring I decided to take an in-depth look at the best-practice networking security known as the virtual DMZ, which is essentially a data center era firewall deployed at virtual kit in a hub VPC or VNet, surrounded by various spoke VPCs or VNets. I set out to examine this architecture across four angles – cost, scale, complexity, and agility – to demonstrate how and why the virtual DMZ pattern can suddenly detonate, causing a lot of pain and frustration.
If you’d like to rewind and examine the angle of cost, you can read my first blog post here. In this second article, we’ll learn how the virtual DMZ is a ticking time bomb from the perspective of scale in cloud.
The Firewall Game has Changed
The predictable outcomes of building too many firewalls in cloud are all well known – massive cost, management overhead, and the downward spiral of policy complexity. These scale problems are not that different from the data center. Security teams have become adept at using automation and centralized tool sets to keep these challenges at bay (save the cost piece which people justify due to necessity). Yet the outcome many haven’t considered, until it’s too late, is risk: risk of a breach, risk of data loss, risk of lost revenue, and above all else, risk to the reputation of the business itself.
This seems counter-intuitive. The prevailing wisdom is that that the more firewalls you build, the more security and the less risk you have. Because cloud offers security teams superior automation, traditional firewalls in the cloud should be even more effective than in the data center. Thus, massive investment and energy is pumped straight into stamping out virtual firewalls fast enough to keep pace with innovation. There has got to be some golden ratio here, right?
Unfortunately, this wisdom has turned out to be tragically wrong. In fact, the more firewalls you build in cloud, the more risk you have. How can this be? Because cloud has fundamentally changed the network security game along three central lines:
- The traditional perimeter no longer exists in cloud. It’s endless, dynamic, and undefendable in traditional ways. This is the axis of scale.
- Applications in the cloud are far more dynamic than they are within the data center, and these applications are rapidly shifting to microservices architecture. This is the axis of complexity.
- Cloud infrastructure teams need completely different tools and processes to keep up with cloud-based application requirements. This is the axis of agility.
The remainder of this discussion will focus solely on the first axis, which in many ways precludes the second and third, which I will unpack in the forthcoming articles of this series.
Traditional Perimeters vs. the Endless Perimeter: An Analogy
To those not indoctrinated in data center network security design, the term “perimeter” refers to the bright line that firewalls create between those actors and activities that are trusted, and those that are not. As cybercrime has quickly evolved, the features and capabilities of traditional firewalls have evolved to keep pace, giving birth to a modern security architecture called zero trust security. The basic approach here is to “trust but verify,” meaning the identity of who you are dealing with is not enough. Additional steps are needed to confirm this identity, define what this identity has access to, and then set boundaries for how and how long they should be allowed to access it.
Zero-trust has been a big change, but it has not changed the overall design of perimeter-based security. Firewalls still sit between the edge of the private network and the great unwashed expanse of the internet, and all traffic from the internet (or other untrusted places) is meticulously funneled into the DMZ along one crisp boundary. This works out well because data centers usually only have one logical and physical internet edge – one place where public routes are exchanged, one place where the hand-off between public and private occurs.
It is exactly like a TSA security check point at an airport. No one can get through to the gates without first getting though the checkpoint. Everyone must follow this process, even airport employees. Some people have take off their shoes, and some don’t, but everyone must first prove who they are, prove they need legitimate access, then go through additional security checks to get to their gate. First trust, then verify.
Airports, like data centers, are specifically designed for this process. They are physically built and designed to accommodate checkpoints, queues, and specialized security tech. They have staffed pinch points and man traps (those nifty interlocking sets of one-way doors) to funnel trusted and verified people from the terminal into the gates, and then back out again. They have a well-established perimeter, and every day millions of people can fly securely and safety at the well-accepted cost of some minor (or major?) inconveniences.
The Future is Now
Let’s imagine travel in some distant future ala Star Trek where teleportation has been developed. To get on your starship, you just need a special access code from Star Fleet that you feed into the teleporter at your home or business, then you step in, and in a flash, you are standing in the teleportation deck of the starship. No physical boundaries. No airport terminal. No checkpoints. No line between here and there. All you need is your special code, which is quick and easy to get, then you have immediate, instant access to your destination. This is exactly what Internet access is like in the cloud. As Jack Sparrow would say, “You savvy?”
Next, imagine what it would be like to build a perimeter-based TSA checkpoint system into this super advanced network. You could try and put some kind of checkpoint in every home or business, and on the deck of every starship. Every time a new home, business, or starship is built, you must be sure to put a checkpoint there too. And in our version of the future, homes can be built in minutes, but each checkpoint takes hours or days to build, and costs tens of thousands of digital dollars. No, this process is doomed to fail.
Assuming that the best security tools you have are perimeter based, what do you do? You artificially enforce a perimeter-based infrastructure into a network that has no perimeter. When customers input their special code, they are first teleported into a central processing center that physically queues everybody up into a secure inspection point, does the necessary trust but verify operations, then let’s them step into another teleporter that (hopefully) leads to their starship. It would be an expensive, slow, and frustrating anti-pattern, but it would work.
Or would it? What if you could get a new code, either by accident, mistake, or theft, that lets you teleport directly onto your ship again? What if some businesses were so fed up with the antiquated methods of the central processing center, and the impact it was having on their bottom line, that they petitioned Star Fleet for new instant access codes, and Star Fleet agreed? Again, this is exactly what is happening in cloud. If you haven’t figured it out by now, the access codes are the permissions to put a public IP on an IaaS or PaaS instance, Star Fleet is cloud IT, and the center processing center is, of course, the virtual DMZ.
No matter what you did to make your central processing centers bigger, or more efficient, or more agile, or even more numerous, you would never solve the fundamental problem. In fact, it could make the problem worse: security expenses would skyrocket, but the overall risk either remains constant at best, or quickly grows at worst due to heavy investment in the wrong solution. Remember, the special access codes to the teleporter network can never be removed – they are endemic to the network itself, which cannot function without them.
Regardless of the time, energy and capital invested in virtual DMZs, the cloud network will always grow faster than this artificial perimeter can withstand. Because traditional firewalls were never designed to operate within the endless perimeter of cloud and are certainly not part and parcel of the cloud-native network itself, risk is now a function of overall network growth, not a function of security investment. The virtual DMZ thus becomes a ticking time bomb for scale in cloud – it will never satisfy the risk requirements of cloud, and it’s just a matter of time until a serious security breach or incident happens. All the while, you will be tempted to pour more money and energy into this model, but you will be rewarded with only limited, short term gains.
Teleporter Security for Dummies
I’m sure that as you were following the analogy, many of you quickly cut to the root of the problem: security must be based on the known attributes of the individual traveler and should be enforced as a distributed function of the overall network. Some of you might be thinking, “Just do all the trust and verify stuff before you hand out the special code and let the code determine the action!” Ah, but then the policy follows the code, not the traveler, and the system is defeated again. Here, we must approach security as a dynamic process that grows and changes along with traveler herself, not a static process that is embedded into a hash function, which may or may not wind up with the traveler using it.
What if Star Fleet had a centralized security system that performed the trust and verify operation on a selective set of known traveler attributes, based against the type of code they requested, then dynamically programmed only those teleporters that the traveler would use to take the correct action? All other teleporters across the entire system would not work for that traveler, for that one trip, with that one code.
Photo by Joshua Sortino on Unsplash
The basic model is shockingly simple – build a big brain that is connected to all the teleporters, and let it program them based on every trusted and verified traveler/trip/code combination. The entire network thus becomes the enforcement point, but for this to work, the policy must be centralized, intelligent, and dynamic.
For example, even if the traveler somehow obtained an arbitrary code, the centralized policy system would cross-check with her attributes and then be able to program the correct action into the teleporters – such as block and alert. Finally, any changes to a person’s attributes would be automatically perceived by the central system, then these changes could be instantly pushed to the appropriate teleporters on-the-fly. Wouldn’t that be cool? What if something like that existed for cloud networks today, and worked as a true multicloud solution? Well, I’m here to say that it does, and that it is awesome.
This is the Way
Using the endless perimeter analogy, it’s clear that the only way to secure a distributed, dynamic network is to build security into that network in a distributed, dynamic way. But the system must be more sophisticated than just basic security groups. What is needed is a Distributed Cloud Firewall.
My colleague Chris McHenry recently wrote about the requirements of a distributed cloud firewall, which I highly recommend as a follow up read, but the ultimate end goal is for the Distributed Cloud Firewall to operate as a single intelligent firewall, distributed across one or more clouds. There are only a tiny handful of innovative companies that can deliver on these requirements, and Aviatrix is one of them. Learn more about the Aviatrix Distributed Cloud Firewall: https://aviatrix.com/distributed-cloud-firewall/
You can also get in touch with us today to discuss your firewall needs and potential savings with the Aviatrix Distributed Cloud Firewall.
Let’s Continue the Journey
The final two chapters of this series will expose the virtual DMZ as a ticking time bomb from the angles of complexity and agility – so be sure to keep an eye out for those. In the meantime, I encourage you to check out the following resources if you’d like to learn more about a real-world distributed cloud firewall solution.