Public Cloud Is Neither More Nor Less Secure Than Private Cloud

Posted by Mike Fratto
June 26, 2012

There's a meme in the water that public cloud is more secure than private cloud. That's just plain wrong. Also wrong: the idea that the private cloud more secure than public cloud. There's nothing inherently more or less secure about either cloud model, and you can put VMs or applications securely in either (or both). Don't get excited by these FUD-filled claims.

Let me be clear: When people talk about something being more or less secure than another, what they mean is that one thing is better protected than another--that the better-protected thing is harder to break into. What they don't often talk about is risk. Risk is the likelihood that some loss will occur. There is always risk. Always. With public cloud, you face different risks than if you use a private cloud. I will not be focusing on risk--rather, I will focus on protection and debunking the pernicious myth that public cloud is more secure than private cloud.

Here's the common reasoning for why public cloud is more secure than private cloud (see if you can catch the flaw): Public cloud providers have a vested interest in providing a secure, multitenant service offering, and they can do so at scale. They have the resources to acquire well-trained experts to secure and manage their services. Security is part of the cloud provider's core competence. Your organization does not have the same skills and security is not likely a core competence.

The flaw is the reasoning doesn't take into account the boundaries of responsibility between you, the customer, and the cloud provider. I wrote about the responsibility in Network Computing's November 2010 digital issue (free, registration required), but this meme continues to crop up like toadstools.

Cloud providers focus on ensuring the following:

Multitentant isolation;

A secure and reliable underlying infrastructure, as well as services;

A secure management framework that also exposes the features and functions that customer require; and

Monitoring to detect and respond to security and service issues.

The protection measures are fundamental to cloud offerings.

The cloud provider should use a number of technologies and processes to implement both electronic and physical security, but there's a bright line between where its responsibility ends and yours begins. Using key cards, physical cages, security guards and tight physical controls, as well as monitoring who has physical access to the cloud infrastructure, are best practices. Electronic separation and isolation technologies like firewalls, IDS/IPS, VPNs, encryption and a number of other software security products are also good practice, but there's no magical transference of security benefit from provider to customer.

Where that bright line of responsibility falls depends largely on the type of service you use:

• IaaS offers you a virtualized environment that you put your VMs into. The provider is responsible for protection mechanisms applied to the underlying environment and the management services that are offered. You and you alone are responsible for securing the VM and applications that you place in the IaaS. The cloud provider isn't. If you place a vulnerable VM into an IaaS, it doesn't become magically secure.
• PaaS offers a development environment that includes the IaaS components plus the language, libraries, API, interfaces and other services such as a service bus, database and storage. The PaaS provider is responsible for that entire environment. You're responsible for the security of the code you place in it, as well as any services that you access outside of the PaaS. If you put the code into a PaaS that's vulnerable in and of itself, that's your responsibility. If your code uses a library, function or service that PaaS offers, then it's the service provider's responsibility.
• SaaS offers you a complete application. In this case, the provider is responsible for the security of the entire operation and you're responsible for the configuration options that you make. For example, a SaaS may offer HTTP or HTTPS access. If you enable HTTP access and someone uses it and his credentials are stolen by an attacker who sniffs it off HTTP, well, that's your fault for enabling, or not disabling, HTTP.

Next: Who's Responsible for Cloud Security?

Related Reading

---