The Power of the Minimum Viable Network

Understanding cloud networking is one of the biggest adjustments for organizations starting their cloud journey. As you look at the addressing scheme and the components, it kind of looks like an IP network. And from most perspectives, it is — but in a lot of other areas, it’s not. A software-defined network (SDN) – like those offered in the cloud – is not subject to the same constraints as a physical network, and that can be pretty confusing as you get going.

As opposed to trying to understand how SDN is different from your physical network, let’s focus more on what you need the network to do and more importantly, what should not be allowed. You may be old enough to remember a concept called “default deny,” which meant unless you explicitly allowed a connection to happen, it was blocked by default. Then this web thing happened, and it wasn’t possible to restrict Port 80 or 443 since pretty much every application used those ports. Plus, “default deny” never really made it past the perimeter and our internal networks tended to be flat and open, relying on a DMZ to filter out the nasty traffic from the outside world. As breach after breach has shown, this model is only moderately effective.

But SDN allows us to get much closer to default-deny, via a concept we call the “Minimum Viable Network,” which enables building custom networks with just the pieces needed to get the job done, and nothing more.

A Minimum Viable Network should determine the application architecture and then create ONLY the networking required to support that application, enforcing least privilege routing and security groups, and also utilizing PaaS components like cloud load balancers. This effectively turns the packet-switched network into a circuit-switched network in that application components can ONLY communicate to the other allowed components, and nothing can sniff the traffic in between (except, in some cases, the cloud provider). The network drops all other traffic. This eliminates the need for constructs like the traditional DMZ or network zones since the entire network itself is least privilege and default deny.

Let’s make this a little more tangible by using an example. You can create a traditional 3-tier application stack with a public-facing Application Load Balancer, backed by a web server in a private subnet that ONLY accepts traffic from the load balancer. The web servers can only connect to application servers that accept connections from them. Similarly, the application servers can only send traffic to databases that allow such connections. Each tier is default deny and only allows inbound connections from the load balancers and outbound connections to the databases. In many cases, you can implement this without any Internet connectivity (in private subnets) aside from the public load balancers, which are highly secure PaaS constructs maintained by the cloud provider.

Rather than building the network and putting applications inside, you design the applications and then fit the network to the application’s needs. This dramatically reduces the attack surface of the application stack and reduces your risk accordingly.

We used these principles when we built the securosis.com site, as you can see in the architectural diagram below. If we look at that design with a network security eye we see:

• Access is restricted from the cloud WAF so only clean traffic goes to the VPC.
• The application load balancers (ALBs) are the only resources in public-facing subnets and only allow 80/443 traffic.
• All the instances are in private subnets and only accept traffic from the ALBs.
• The “admin” instance accepts logins but only from a VPN hosted in a different environment.
• Not shown are the subnets for the RDS database, which are also private only, and only accept traffic from the instances. If any direct logins or RDBMS access for data massaging are needed the security group rules are changed for temporary access.
• Connections to S3 are made using a service endpoint, eliminating the need for a NAT Gateway for Internet access.
• SSH is disabled on the non-admin instances. These are autoscaled and immutable and are only modified by changing the base image.
• There are no self-referencing security groups (security groups allowing internal access) to prevent horizontal attacks. Security groups in AWS work on a resource level, not a subnet level, which is very powerful to block East/West attacks.
• This architecture dramatically reduces the overall attack surface. The network only allows the minimum required connectivity, and only contains the minimum required subnets and route tables to allow access. We have essentially fit the network to the application. In fact, the network was only designed after the application stack was architected.
• This is a very simple example of a small site, but the principles can apply to much larger architecture with a greater number of tiers, internal load balancers, API Gateways, and PaaS components.

As you can see, you have tremendous flexibility when using cloud networking constructs. You finally have the ability to build the network the application needs, not adapt the application to the network you have. But with this flexibility comes the ability to configure things incorrectly and open up wide swaths of your infrastructure to the public Internet. So we always recommend you monitor your cloud security posture and enforce best practices with a cloud security operations platform (like the one offered by DisruptOps).