Public Cloud Is Neither More Nor Less Secure Than Private Cloud
June 27, 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.
The previously listed examples aren’t meant to point fingers. Rather, they’re meant to illustrate where the responsibility lies. To sum up, the service provider is responsible for the security on the services it offers. You are responsible for the proper use of the service and the executable code you put into it. If a service provider includes a firewall service, it’s responsible for it–you’re responsible for the rules. If you add a rule to the firewall that allows any-to-any access and an attacker exploits a vulnerability in a VM you installed, that’s on you, not the service provider.
The amount of responsibility changes as you go down from SaaS to IaaS. The Cloud Security Alliance’s "Security Guidance for Critical Areas of Focus in Cloud Computing v3.0" shares this bit of wisdom, "The key takeaway for security architecture is that the lower down the stack the cloud service provider stops, the more security capabilities and management consumers are responsible for implementing and managing themselves." By the way, the people who wrote that guidance–in fact, the people who volunteer time for the CSA– are security professionals. If you’re thinking about cloud security, start your research there.
You can put secure or insecure services into a public cloud and they will be as secure or insecure as you make them. A cloud provider’s security practices don’t magically mean your applications and VMs have better protection. Anyone who tells you otherwise is trying to sell you something and relying on your fear, uncertainty, and doubt. What you do have to do is assess which risks or protection measures change when you move to a public cloud, and if you can adequately address them.
P.S.: For fun, I gathered up some common FUDful statements with a quick debunking for each. I’m not going to name names. That would be rude.
- Cloud providers have better physical security: You may gain some benefit in physical security and physical access to your applications and data, but that’s only true if the cloud provider’s controls are on par or better than yours.
- Cloud providers’ security is done at scale, and is therefore better: The fact that cloud providers do things at scale is irrelevant. They could execute bad practices like deploying firewalls with default any-to-any allow rules at scale. Is that practice more secure?
- Cloud providers continuously audit and monitor and can detect issues: Yes, they do, but they’re monitoring the service to meet their SLAs. Unless you have contracted specifically for monitoring and IDS/IPS services, then the monitoring is for self-protection only. The cloud provider may notify you of a problem, but if it isn’t spelled out in the contract, the provider isn’t required to.
- Cloud providers have more secure development lifecycles: Again, this applies only to the systems and services offered Ensuring that the service was adequately protected is a reasonable expectation.
- Public clouds are hardened through continual hacking attempts: That may be true of the service, but that doesn’t necessarily leap over the line or responsibility to your programs. This statement is probably more applicable to SaaS. Regardless, this is a dubious claim at best. The service should be resistant to attack anyway.
- The insider threat is the biggest threat, so move your applications away from insiders: If you mistrust your own staff members enough that you think you need to move your applications away from them, you need new employees or a new perspective. Really, you do. Oh, and why would you trust someone you never met?
- Hiding in a cloud: Um, this one doesn’t even make sense.