Security Risk of Cloud Platforms: All Powerful without Knowing It!

It’s remarkably easy to go out to AWS, Azure, GCP or any of the myriad of cloud providers and spin up a “compute” instance. Commonly, this will be a virtual machine with an OS on it. It might be Ubuntu, CentOS or the latest version of a Windows server. What is often not recognized is that this new instance becomes part of a network topology. This is no different from traditional on-prem environments where you deploy a server and assign it a static IP.

Creator: Unknown Date: November 17, 1930 Archival Citation: Fonds 1266, Item 22555 Credit: City of Toronto Archives www.toronto.ca/archives Copyright is in the public domain and permission for use is not required.

What happens is that your compute instance will immediately be associated with a route table, an ACL of some kind, a subnet and a virtual network. And by default this resource is exposed to the internet. It has to be; otherwise you wouldn’t be able to connect to it via SSH in order to manage it. And by default the realm of source IPs that connect to your instance is 0.0.0.0/0. This is shorthand for “anyone can connect to it”. In a traditional on-prem environment, this doesn’t happen. Serving up a management port to the world is just not done. And if it is done, it is exposed in a DMZ with a firewall in front of it. And also, firewall rules protect the rest of your network from this device: sandwiched by firewall rules.

The folks who spin up these VMs in the cloud aren’t typically network people. Their day-to-day work doesn’t require them to think about enterprise-wide firewall rules unless they work in a highly segmented environment. Many organizations aspire to a high degree of segmentation, but a surprising number don’t achieve it. So isolation doesn’t tend to be of routine concern. Lack of segmentation makes implementation and maintenance easier, but it also makes it easier for bad actors and pen-testers to complete their reconnaissance and move laterally through the network. But I digress.

A large number of developers or system administrators aren’t network people, so they don’t fully comprehend the protections they’ve come to rely on. A misconfiguration in a traditional on-prem environment is a security risk, but it has an added layer of defense: an enterprise firewall, along with a host of other tools that help keep tabs on who is coming and going from their networks. A misconfiguration in the cloud, for a resource that resides on a virtual cloud network, generally means instantaneous exposure. An asset with a publicly exposed IP address starts getting hit within moments of public exposure. Just ask any firewall administrator what they see on a daily basis.

So for folks who aren’t network administrators and who find themselves deploying resources in the cloud, these network configurations are new, to say nothing of network design. “Why do I need to have an internet gateway on a route table?” they might ask. Or, “Why would I want to change this ACL rule to only allow my instance to only be accessed from specific ranges?” Also, do all of your databases need to be exposed publicly? Probably not. But this was never an option in the past. Now, with cloud infrastructure, someone can literally be an all-powerful administrator of everything! And without even knowing it! Herein lies the risk.

All this is to say nothing of the fact that the cloud infrastructure portal being used to do all this work is typically nowhere near as well protected as it should be. In more cases than we wish to admit, the keys to this all-powerful kingdom are one social engineering engagement away from being stolen, but I’ll leave that as a topic for another day.

Picking the right words to describe cloud assets is kind of important

The work of any given IT department is remarkably broad. And within each functional team, vocabularies around technology can be quite unique. This is fine when different groups don’t have to work together much, but when they get together to solve problems, one great challenge has to do with making sure specific IT terms mean the same thing to everyone.

And if that isn’t challenging enough, take traditional IT terms and then figure out how they all translate into the ‘cloud’. I’ll give an example. Take the distinction between IaaS and PaaS. The way this is often described is that with PaaS you don’t have to worry about patching an operating system. With IaaS, this is the customers’ responsibility, not the cloud service provider’s. But the scope of cloud is much bigger than the VM example. And not understanding this can have serious ramifications.

Let’s say you go out into cloud console for your tenant. (This would be the place where you log in to spin up a virtual machine, for example.) Whether you like it or not, the very moment you spin up a VM in the cloud you’ve created the beginnings of a network topology. Not knowing this can cost you dearly later.

Cloud infrastructure is not just VM’s. There’s a whole world of storage, networking and compute services, too, which we often overlook as being IaaS. Why does this matter? Because knowing and understanding this is also the beginning of securing it. Consider where each of these pieces live in a traditional on-prem model, and what controls are in place to protect the confidentiality, integrity and accessibility of these assets. That same diligence has to be transferred to the cloud. For example, protecting your firewall configurations is not unlike protecting your security group configs on a subnet or VM instance.

Also, how do you track changes to these assets? Whatever diligence you apply in traditional IT models, this same diligence is required in the cloud. This includes reviewing and validating configurations on these virtual assets. Think about what would happen if any one of these virtual assets, like a subnet or a whole virtual network were to be deleted. Where would you be and what controls do you have in place to keep this from happening? And in the unfortunate case that it does happen, how would you know how it happened and who did it?

Because it is so much easier to set up infrastructure in the cloud, it is also that much easier to abuse said infrastructure either intentionally or unintentionally. Getting everyone on the same page around the vocabulary for cloud infrastructure is the beginning of fully understanding how to secure this environment. Let’s decide on our critical cloud vocabulary and make sure we all share the same deep understanding of the words we use to describe this environment.

Study both AWS and Azure for High-level Cloud Understanding

Recently, I’ve found it’s not enough to simply say, “I’m an AWS person” or “I’m an Azure person” when it comes to learning and understanding the cloud. The greatest benefits in learning surface from seeking a high-level understanding of cloud platforms, in general.

These two leading cloud providers, AWS and Azure, are distinct enough from each other, but fundamentally there are features that neither of them can avoid if they are going maintain market share, or simply be able to provide viable solutions to their customers.

When folks spin up a VM instance at AWS or in the Azure portal, they are likely to overlook a few critical things. 1) These environments are networks unto themselves, 2) Where you might’ve been operating a private cloud in the past, which is essentially a traditional data center, you’re now using a public cloud, and 3) Where you might envision you’re life getting simpler with cloud, it’s actually getting more complicated.

When folks spin up a VM instance at AWS or in the Azure portal, they are likely to overlook a few critical things. 1) These environments are networks unto themselves, 2) Where you might’ve been operating a private cloud in the past, which is essentially a traditional data center, you’re now using a public cloud, and 3) Where you might envision you’re life getting simpler with cloud, it’s actually getting more complicated.

With point #1, AWS and Azure both provide ways for their customers to create networks. There may be slight differences in how these networks are set up, but the concepts are the same. Azure calls theirs virtual networks and AWS describes them as virtual private cloud or VPC instances. (Oracle calls theirs virtual cloud network or VCNs.)

Call it what you want, it is a network. And if you don’t know that, you’re likely in for a world of hurt later when you need to scale or secure your cloud environment. And if you can’t do the same thing in AWS as you do Azure on this front, then you don’t really understand the fundamentals. And if you try another cloud platform and find you simply can’t fine tune networks the way you like, then you’ll know why AWS and Azure are leaving them behind.

With point #2, you are now participating in the use of a public data center. This means it is exceedingly easy to expose your services in ways you maybe didn’t intend. Take a careful look at how AWS and Azure overlap or don’t overlap in their approach to exposing services. If you only ever had you head in AWS you might assume that certain settings are always set to be public and the same might be true of Azure.

They’re both evolving from month to month on their approach to how they handle default public exposure, so I won’t go into too much detail. But if you work with them simultaneously when you’re learning, you’ll make fewer assumptions and as more critical questions than you would otherwise.

With point #3, generally speaking, your life as an IT professional who uses the cloud to build IT infrastructure, services and to take advantage of pre-built applications, is about to get a bit more complicated. Why? Because now in addition to all the systems you need to support locally, which help you move data in an out of the cloud, you need to manage the cloud as well. And if you’re using a service that “manages itself” you need to manage perpetual change just to keep up with it.

Understanding integration in both AWS and Azure will help you make fewer assumptions about the way things should be and, again, think critically about the fact that much of the design is actually up to you. You can’t afford to turn of your critical thinking skills. Having the courage to ask tough questions is even more important than it has been in the past. So if someone asks you, should I learn AWS or Azure, or (name your favorite alternative), the answer should be “yes”. There is no “or” if you’re going to be the master of your own cloud destiny. 🙂