As I read different blogs, IT industry analysts and media, I see contradictions galore. Some articles position cloud computing as more secure (like this one) while other journalists highlight new security challenges (here, here, here and here). The concept of the cloud is still emerging and fallacies around cloud computing abound. Below are the five myths that I encounter most frequently while listening to conversations about cloud computing:
1) Virtual private clouds provided by Infrastructure-as-a-Service (IaaS) players are as secure as internal datacenters
“Virtual private clouds” are a new concept from the IaaS community enabling enterprises to connect to cloud resources using Virtual Private Networking (VPNs) using a private IP address range with the IaaS vendor. The challenge here is that you are still using shared hardware and shared switching with Virtual Local Area Networks (VLANs) for separation. Configuration errors happen. A recent study found 31% of data breaches in Australia “involved mistakes by third parties such as cloud computing or SaaS providers”.
2) You don’t need more than one IaaS provider
Putting all of your cloud eggs in one basket can be problematic if that basket gets bumped. While a single IaaS provider is simpler to manage, it still represents a single point of failure. Using a single IaaS player risks an outage if that vendor suffers from a Distributed Denial of Service (DDOS) attack as happened to Bitbucket .
Another example of a SPOF (single point of failure) lies in what happened to Rackspace when a truck accidentally collided with a power transformer and cut off power to the Rackspace datacenter, resulting in an outage. Accidents happen, and minimizing the SPOF risk means multiple IaaS providers.
Redundant processing sites have been one of the hallmarks of disaster recovery and apply to the cloud era. Businesses may not necessarily need a hot failover site but they should plan and test the ability to quickly switch operations to a secondary provider if the need arises. While this risk can be mitigated with the use of things like Amazon’s “availability zones”, the zones do not completely drop the likelihood of SPOF outages to zero (see previous comments on the Bitbucket episode here).
3) The security that I use in my physical datacenter will work in the private cloud
The thinking here is that my old datacenter perimeter worked fine, and that perimeter surrounds my private cloud, so my private cloud is secure. Regrettably, this is seldom true. You face new challenges in a private cloud (or aggressively virtualized datacenter) that did not exist in the traditional, static datacenter of yesteryear. Virtualization and cloud computing have increased the attack surface that bad guys can go after. You have new attack surfaces like shared storage.
You also face new situations like an administrator that can accidentally vMotion a server from a secure tier to the DMZ. VLAN misconfigurations can compromise separation of data. What about traffic between VMs within a vShield zone that goes unexamined? And in a hybrid cloud environment, what happens when you move an application into the cloud without security surrounding your individual virtual machine? Relying on an IaaS provider who has lowest common denominator firewall rules and perhaps no IDS/IPS might make some enterprises uncomfortable.
4) Your cloud service provider takes responsibility for security
While this might be true in a SaaS or PaaS environment where the service provider takes responsibility for security in their terms of service, this is seldom true in the IaaS world. While IaaS vendors do take steps towards security and have polished documents describing their security features, at the end of the day security in the IaaS environment is something that both the enterprise and IaaS provider need to own, and typically the ultimate responsibility for IaaS security falls on the enterprise. The “security” section of the terms of service for your IaaS provider usually highlight this issue ( Amazon EC2 Customer Agreement is a good example).
And while a provider might take responsibility for security, the enterprise is ultimately accountable in the event of a compromise or breach. It is your data.
5) My cloud service provider has a SAS 70 type II audit, so my data is secure with them.
A SAS 70 Type II audit provides a good foundation and a nice checklist to validate a service provider’s controls were working during the period examined, but it does not equate to security. It can engender a false sense of security. Audits look at what has happened in the past, and while past performance is a decent indicator of future performance (at least for data center security) it does not guarantee that practices will continue. Solid and extensive security practices can fall by the wayside or be cut completely as a company experiences large and unexpected personnel churn. Also, a SAS70 will never be able to guard against a disgruntled employee wanting to take out his frustrations on his/her company or its clients.
SAS 70 Type II audits do not examine items outside of the scope of the audit. You can be very rigorous about what you examine in the audit checklist, but your vulnerability might be outside the scope of the audit. And any audit of processes may not touch on the people implementing the processes. What sort of hiring practices does the vendor have? SAS 70 Type II audits don’t require that hiring practices be covered. People are fallible and flawed (not pointing fingers here – we human beings are flawed).
There is no set standard for SAS70 reviews. Such audits are designed collaboratively between the auditor and the auditee and are meant to test the controls of a specific business process. The controls might not be “all encompassing” so objectives outside the designed scope but still important to the business service will not be tested. SAS70s should be reviewed with a critical eye before placing critical business processes with any service provider. And ideally audits should not only focus on data security but expand to other areas like continuity of service, vendor management, backup and recovery, and HR functions.
The cloud, be it private or public, provides fantastic business value in lowering costs and increasing business agility. However, I suggest having a clear-eyed view of some of the security challenges.
I am particularly interested in your 4th point, since my company produces a private cloud generation tool that really does protect the users data (since the data will never reside on a 3rd party server). When data is placed in the cloud it is open to compromise – we see that time and time again. Of course, there is a trade off between the convenience of everywhere-access and security, but I believe that if the data is sensitive then it should not be sent to the public cloud.