• 06/26/2012
    2:57 PM
  • Rating: 
    0 votes
    Vote up!
    Vote down!

Public Cloud Is Neither More Nor Less Secure Than Private Cloud

Claims that public cloud is more secure than private cloud are pure FUD and ignore the responsibilities that each party plays in information security. What matters is how well your applications and VM are protected. Learn why.

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 life cycles: 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.
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.

Log in or Register to post comments