Curing Public Cloud-Phobia

There's an old security maxim: The only secure computer is one completely disconnected from the rest of the world. It's even more secure if it's shut off.

In the real world, all systems must be available to some degree and are therefore vulnerable to attack. Some are especially concerned about systems and data in the public cloud, running on computers owned by someone else, using management systems owned and operated by someone else, with other customers -- maybe even your own competitors -- running on the same computers. Surely these are great risks...aren't they?

Yes, it's true: Attackers can reach your systems in the public cloud; infiltrate them, steal confidential data, even crash them. But, this has nothing to do with them being in a cloud, public or private. When administrators take proper care to secure systems and data, their physical location and software architecture are of no matter. Once you understand the security model, spurious arguments of cloud-phobia fall apart.

Just like any other server infrastructure, systems in the public cloud are connected, perhaps to only other systems you control, perhaps to the Internet more broadly. This is necessary in order that they be useful, but it also allows potential attackers to contact them.

In a large public cloud like Amazon Web Services or Microsoft Azure, software runs in virtual machines (VMs) controlled by a master program called a hypervisor. Each VM looks to the software running on it, like a computer. Whether it's running on an actual computer or a VM is irrelevant to the application.

The hypervisor may, for optimization or legal purposes, place certain virtual machines on certain physical hosts. For instance, government agencies may be obligated to keep citizen data on hardware located specifically in that country or state. And, if a customer has multiple VMs that communicate over the network, it would be optimal for those VMs to be hosted on the same physical server, so that connections are very fast.

But in the bigger scheme of things, you don't know what computer your VMs are running on. As long as the cloud provider supplies the performance, capacity, and bandwidth you're paying for, you have no reason to care what computers they're running on.

So how would the presence of a competitor's systems, or any other systems, on the same physical computer pose a threat? They can't attack your system over the virtual network any more than any other computer in the world. The only potential danger would be for the attacker to break out of one VM into the hypervisor and use that privileged position to steal data from and otherwise abuse other VMs.

Does this actually happen in the real world, though? Cross-hypervisor attacks are possible, but we don't have any credible reports of these exploits appearing outside a research lab.

Public cloud providers have mechanisms to protect VMs from each other: In AWS, for instance, guest Linux OS code runs at a lower privilege level than normal. All network communication goes through a software firewall running at the more privileged hypervisor layer.

Yet the myth that the pubilc cloud exposes your systems to new risks persists. In fact, public clouds provide a more secure infrastructure than you are likely to have on-premises or in a co-location center. A public cloud's business would fail if their infrastructure was not secure. To be clear, the infrastructure refers to the access to physical data centers, access to the underlying networking and computing environment, the reliability of the services, and the continual update process of the services they provide. However, anything you deploy and run on a public cloud environment is your responsibility to secure. Once your systems boot, their security is your responsibility. This is what Amazon Web Services calls the Shared Responsibility Model, although the basic concept is universal.

The cloud relieves you of some security burdens and makes fulfilling many of the others easier. For instance, it will supply you with a strong IAM (Identity and Access Management) system and encryption facilities for your own use. But it does not relieve you of your responsibilities. These responsibilities are ones you would have in any other computing model, including your own data center running all your own software on your own hardware. A classic example is software vulnerabilities. Are you using old versions of applications that have known vulnerabilities in them? It's up to you to update those applications.

Succumbing to cloud-phobia really puts companies at a disadvantage. In the real world, cloud services are hacked, but it's a myth that this happens because they are in the cloud. The truth is that the overwhelming majority of security concerns for cloud customers are identical to those for non-cloud customers: You need to patch your systems promptly, you need to manage identity and access assiduously, you need to encrypt data, and you need to leverage the expertise of dedicated security experts if you don't have that capability in-house.

Read more about protecting your clouds here.

Learn more about comprehensive cloud security from Palo Alto Networks here.