The 5 cloud risks you have to stop ignoring

Whether or not you liked former U.S. Secretary of Defense Donald Rumsfeld, you had to chuckle over his famous “unknown unknowns” quote:

There are known knowns; there are things we know we know. We also know there are known unknowns; that is to say, we know there are some things we do not know. But there are also unknown unknowns — the ones we don’t know we don’t know.

[ From Amazon to Windows Azure, see how the elite 8 public clouds compare in InfoWorld Test Center’s review. | Also check out our “Cloud Security Deep Dive.” | Keep up with key security issues with InfoWorld’s Security Central newsletter. ]

Although Rumsfeld was ridiculed for that statement, it was a case of a politician accidentally telling the truth, and I think anyone in computer security quickly understood what he was talking about. We are constantly faced with all three types of risks: known knowns, known unknowns, and unknown unknowns.

One of the biggest impediments to public cloud computing adoption is the calculation of additional risk from all the unknowns, known and otherwise. I’ve spent the last few years contemplating these issues as both a public cloud provider and user. Here’s a list of five risks any business faces as a customer of a public cloud service.

Cloud risk No. 1: Shared access

One of the key tenets of public cloud computing is multitenancy, meaning that multiple, usually unrelated customers share the same computing resources: CPU, storage, memory, namespace, and physical building.

Multitenancy is a huge known unknown for most of us. It’s not just the risk of our private data accidentally leaking to other tenants, but the additional risks of sharing resources. Multitenancy exploits are very worrisome because one flaw could allow another tenant or attacker to see all other data or to assume the identity of other clients.

Several new classes of vulnerabilities derive from the shared nature of the cloud. Researchers have been able to recover other tenants’ data from what was supposed to be new storage space. Other researchers have been able to peek into other tenants’ memory and IP address space. A few have been able to take over another tenant’s computing resources in totality by simply predicting what IP or MAC addresses were assigned.

Multitenancy security issues are just now becoming important to most of us, and the vulnerabilities within are starting to be explored. The best precursor example is a single website placed on a Web server with hundreds or even thousands of other, unrelated websites. If history is any guide — it usually is — multitenancy will be a big problem over the long haul.

Cloud risk No. 2: Virtual exploits

Every large cloud provider is a huge user of virtualization. However, it holds every risk posed by physical machines, plus its own unique threats, including exploits that target the virtual server hosts and the guests. You have four main types of virtual exploit risks: server host only, guest to guest, host to guest, and guest to host. All of them are largely unknown and uncalculated in most people’s risk models.

When I talk to senior management about virtual risk issues, their eyes glaze over. Many have said to me that the risks are overblown or exploits are unheard of. I usually tell them to check out their own virtualization software vendor’s patch list. It isn’t pretty.

To up the ante, the cloud customer typically has no idea what virtualization products or management tools the vendor is running. To shed some light on this risk, ask your vendor the following questions: What virtualization software do you run? What version is it on now? Who patches the virtualization host and how often? Who can log into each virtualization host and guest?

Cloud risk No. 3: Authentication, authorization, and access control

Obviously, your cloud vendor’s choice of authentication, authorization, and access control mechanisms is crucial, but a lot depends on process as well. How often do they look for and remove stale accounts? How many privileged accounts can access their systems — and your data? What type of authentication is required by privileged users? Does your company share a common namespace with the vendor and/or indirectly with other tenants? Shared namespaces and authentication to create single-sign-on (SSO) experiences are great for productivity, but substantially increase risk.

Data protection is another huge concern. If data encryption is used and enforced, are private keys shared among tenants? Who and how many people on the cloud vendor’s team can see your data? Where is your data physically stored? How is it handled when no longer needed? I’m not sure how many cloud vendors would be willing to share detailed answers to these questions, but you have to at least ask if you want to find out what is known and unknown.

Cloud risk No. 4: Availability

When you’re a customer of a public cloud provider, redundancy and fault tolerance are not under your control. Heck, usually what’s provided and how it’s done are not disclosed. It’s completely opaque. Every cloud service claims to have fantastic fault tolerance and availability, yet month after month we see the biggest and the best go down for hours or even days with service interruptions.

Of even bigger concern are the few instances in which customers have lost data, either due to an issue with the cloud provider or with malicious attackers. The cloud vendor usually states that they do awesome, triple-protected data backups. But even in cases where vendors said that data backups were guaranteed, they’ve lost data — permanently. If possible, your company should always back up the data it’s sharing with the cloud or at least insist on legalese that has the right amount of damages built in if that data is lost forever.

Cloud risk No. 5: Ownership

This risk comes as a surprise to many cloud customers, but often the customer is not the only owner of the data. Many public cloud providers, including the largest and best known, have clauses in their contracts that explicitly states that the data stored is the provider’s — not the customer’s.

Cloud vendors like owning the data because it gives them more legal protection if something goes wrong. Plus, they can search and mine customer data to create additional revenue opportunities for themselves. I’ve even read of a few cases where a cloud vendor went out of business, then sold their customers’ private data as part of their assets to the next buyer. It’s shocking. Make sure you have this known unknown on lockdown: Who owns your data and what can the cloud provider do with it?

Cloud visibility Even when the cloud computing risks are known, they’re difficult to calculate with real accuracy. We simply do not have enough history and evidence to determine the likelihood of security or availability failures, especially for a particular vendor, or whether such risks will lead to substantial customer damage. The best you can do is pull a Rumsfeld and least let your management in on the known unknowns.

But first, endeavor to minimize the unknown unknowns. You want as much transparency as possible; if nothing else, at least get a copy of the last successful, relevant audit report. Ask your vendor about previous instances of tenant data compromises and losses, as well as the policy on reporting them to you. Nail down as best you can the limits of the cloud vendor’s responsibility. Only by asking the hard questions can you begin to understand the total risks of public cloud computing.

Although it may sound as if I’m down on public cloud computing, I’m actually a huge fan of it. I believe that most public cloud vendors do a far better job securing data than their customers do. But you need to know where your cloud vendor stands and the measures it takes to mitigate risk as compared to what your company alone could provide.

This story, “The 5 cloud risks you have to stop ignoring,” was originally published at InfoWorld.com. Keep up on the latest developments in network security and read more of Roger Grimes’ Security Adviser blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.