Tuesday, December 07, 2010

The Risks of Cloud: Lessons from Wikileaks

Considering cloud computing? As well as any technical factors, make sure a Terms of Service issue doesn't put you out of business.

Article by Simon Phipps

It used to take a bailiff and a man with an axe for the door, but the cloud makes it so much easier. If I told you that your entire business infrastructure could be taken offline by a government employee, or even a commercial provider, without judicial review, useful explanation or workable recourse, perhaps because a politician has philosophical issues with your activities, would that worry you? Yet it seems that the most popular brands on the market for cloud computing and web services place you at that risk if you follow the trend to cloud hosting for business infrastructure.

I commented on Friday about the weakness that responses to Wikileaks have exposed in cloud computing, whatever your view of Wikileaks itself. While there are strong incentives to host critical infrastructure in the cloud or using web services, we saw last week both Amazon Web Services and PayPal - flagship brands in cloud computing and web commercial services respectively - suddenly toss customers off their services without judicial review, useful explanation or workable recourse. I'm sure they breached none of their own (voluminous) agreements. We saw other, less well-known companies (Tableau, EveryDNS) follow suit too, and even a Swiss bank finding a handy loophole. We also saw the US Department of Homeland Security start to seize domain names - this time at least by sending a court order to Verisign, albeit sealed, but without useful explanation or workable recourse. I sense we will see more of this happening.

Cloud Danger

This demonstrates the fundamental flaw in web-mediated services. While the Internet itself may have a high immunity to attacks, a monoculture hosted on it does not. We might be able to survive a technical outage, but a political outage or a full-fledged termination of service are likely to put a company that's relied on the cloud for critical infrastructure out of business. Beware those Terms of Service.

Of course, the terms of service of our suppliers have always included termination clauses. But most of us have lived with them because the risk was manageable. Services consumed in the past contributed to infrastructure we controlled and ran ourselves. A state officer wanting to take the sales system offline would need to penetrate the premises and use force, and would need to get a judge somewhere to agree to it happening. But a sales system hosted in the cloud can be taken offline instantly by someone we will never discover, for reasons we can't determine and with no way for us to get them back online.

Worse, a claim that the terms of service have been breached probably leaves us without an avenue for recourse or compensation, regardless of what the service level agreement says about technical outages. There's likely to be a court battle to get either, and when the priority is to get back online again that's not desirable, even assuming we have access to capable legal representation in the country where our provider is based. Finally, if the service we have been consuming is a closed monoculture, finding an alternative will probably mean refactoring our infrastructure. That's costly, time-consuming and may well prove fatal if revenue has been cut off in the interim.

Maybe that sounds excessively pessimistic to you. But it's worth noting that PayPal didn't take action against Wikileaks; they took it against the Wau Holland Foundation, a charitable foundation who had been supporting Wikileaks as one of several activities driven by their charter. They are now unable to use PayPal to collect donations for anything.

Cloud Procurement Checklist

When procuring cloud computing and web services, we need to ask our suppliers why this won't be a problem with their product. They will naturally claim we have nothing to fear if we have nothing to hide. Taking note of the fact that gives us no assurances whatever, we also need to take steps to protect ourselves against the risk. What will those steps be?

First and foremost, a commitment (backed with substantial penalties) that your supplier will never take your service offline intentionally without a substantiated court order is essential. The phrase "at our absolute discretion" is your red flag. It's your infrastructure and thus it's your discretion that matters. Until there's proof of judicial review, no service should be withdrawn without penalty, and suppliers with a track record of behaving otherwise are suspect.

Secondly, ensure your supplier is not a monoculture. Select suppliers deploying open source software in documented ways, so that you always have the freedom to leave. Avoid solutions where the only company enjoying software freedom is your supplier - that's how open core works. Favour open source software which is open-by-rule rather than controlled by your supplier. Your supplier may be concerned that you are escaping their lock-in and charge you more, but it's worth paying extra to get the additional value software freedom creates.

Finally, consider creating a backup plan for how you would operate the service in the event of your supplier suspending their agreements with you. Consider having a backup provider or even a "private cloud" available and keep copies of your runtime environment in VMs ready for deployment. Of course, this will never work unless the software is open source; software freedom isn't just a philosophy.

Don't Just Blame Cloud

Of course, the problem is really not just about cloud computing and web services. Amazon and PayPal shouldn't be boycotted; they are just reptiles, after all. The problem is that we have a society with the governments that it deserves, ready to encourage summary judgement rather than consider matters deeply. The only protection we can even hope to trust today is to take contractual measures and to be ready to self-host in the age of the digital lynch-mob. Software freedom never mattered more.

0 Comments:

Post a Comment

<< Home