The U.S. Dept. of Commerce’s definition of cloud computing lists the following key component first above all others: on-demand self-service. The federal government regulates cloud service providers (CSPs) based on this recommendation from the National Institute of Standards and Technology: Customers should be able to acquire cloud services through an automated system, as if through a vending machine, “without requiring human interaction with each service’s provider.”
Which makes this a story about how the most obvious interpretation of the law (or at least what lawmakers have recommended thus far) collides head-on with the law itself. There are a lot of legal documents that pertain to you or your business that you may have never read. The most common, and perhaps most comical, is the End-User License Agreement (EULA) that accompanies software — even the kind you download. People find EULAs funny because they pretend to become enforceable the moment you do something specific, such as touch it, lay eyes upon it, or breathe in its general vicinity. And because customers usually consider EULAs senseless or even unenforceable, they tend to ignore similar-seeming documents they may encounter at other times in the course of business or everyday life.
One example is the service-level agreement (SLA) that accompanies cloud services. You or someone in your company probably checked a box at some time that says yes, you read it, even if you didn’t. If you did glance it over, then you probably noticed its most typically prominent feature: the CSP’s promise of minimum service availability, or uptime — often a percentage like 99.999%, with even more 9’s tacked onto the end just to stay competitive.
A 2011 survey conducted by the UK-based Cloud Industry Forum (CIF) of 650 cloud customer businesses of all sizes, and from both the private and public sectors, uncovered some facts that, like Lady Gaga’s next outfit, may not be news to anyone but still looks shocking enough on paper: Among those businesses that responded, only 52% claimed they actively negotiated the legal terms of their contract, including the SLA component, with their CSP. What compounds the weight of this fact is that only 218 of businesses surveyed actually responded to this question, suggesting the actual total percentage is far higher.
Of those 218 businesses, 45% told the CIF that their CSP of choice did not give them the opportunity to negotiate. Before you go thinking that’s a shame on the part of CSPs, recall the Commerce Dept.’s own definition of cloud service: something you obtain without negotiation.
Some EULAs may be suitable for lining your bird cage, but an SLA is always vital. What it specifies, or at least should, is something that goes to the core of your business: Who is liable in case of a security breach? It’s no longer a simple question to answer, and before long, it won’t even be this simple to ask.
“I think the industry is in transformation,” states Pat O’Day, Chief Technology Officer of Indianapolis-based CSP BlueLock. O’Day is directly involved in the process of crafting basic SLAs, and helping to negotiate their terms with specific customers. “My hope and belief would be that the intent is that the data is secure, at least as much as it can be. We also have to be realistic about the level of responsibility that all parties share in that data.”
The principal presumption that many cloud customers appear to be making is that liability is transferred to the CSP automatically along with their content.
“You cannot assume that the cloud, by definition, is more secure than doing it yourself,” says Ian Moyse, EMEA channel director for Webroot, a UK-based cloud-based security provider. “It absolutely can be, and it can do it more effectively, but you have to do due diligence as a customer. You have to ask questions to potential cloud vendors, [such as], which cloud provider delivers the [appropriate] level of functional security and efficacy? There isn’t a one-size-fits-all answer, unfortunately.”
The Cloud Security Alliance, a worldwide group of CSPs, has gone so far as to publicly suggest that customers be enabled and even encouraged to negotiate their service contracts before entering into a business relationship with a CSP. One CSA recommendation is for customers to ask for right-to-audit clauses in their service contracts. Such clauses enable customers themselves, at their discretion, to monitor the systems (or have them be monitored) to ensure their compliance with the regulations of the countries and states where they do business.
“Right from the start, any organization that is investigating cloud offerings as a solution, regardless of what that solution may be (SaaS, IaaS, PaaS) needs to not just make a business investigation into cost savings or benefits, but to have IT and business and legal [departments] involved,” Rich Santalesa, senior counsel with the New York based law firm Information Law Group tells us. “Otherwise, if you try to tack on security solutions later, or try to tack on legal liability and indemnification issues later, it becomes harder and a lot of time and effort gets wasted.”
That recommendation — not just to read, but negotiate your agreement before you sign off on it — may seem like one of those everyday reminders you might file in the back of your mind along with carrying a clean handkerchief and eating one serving of fruit every day. Believe it or not, this is the problem, in more ways than one. You see, the moment human beings are involved in the negotiation process, it’s no longer self-service, is it? It ceases to fall under what the U.S. Government currently considers the cloud. That’s extremely important, because it’s the U.S. Government that is presently considering a flurry of new legislation and regulations governing precisely the matter addressed by the SLA: Who’s liable in case of a security breach?
Which Law Will You Choose?
In a set of suggested best practices for the industry to follow, The Cloud Industry Forum’s poll suggested several categories of subject areas that every modern service-level agreement should contain. Some categories should be somewhat familiar to anyone who’s negotiated a service contract with a wireless phone service. For instance:
- How soon can either party terminate service, and under what terms? Usually a CSP reserves the option to terminate a customer under reasonable circumstances; but since these are the customer’s vital business assets we’re talking about, the CSP can’t just flip the switch. What’s a reasonable notification period should one party need to part ways with the other?
- What provisions can a CSP make when its customer wishes to transfer its assets to another provider? Is your cloud transferrable from one atmosphere to another? Some providers utilize standard formats, such as those devised by VMware, for cloud-based infrastructures and other assets to be portable between systems.
- A CSP should retain the customer’s data even while its service is suspended or in the process of being terminated. That means the customer should have access to the data in some form or fashion, even while matters such as unpaid bills are being haggled.
- A well-crafted SLA, says the CIF, should make service availability guarantees in terms of reasonable downtime. In other words, how many hours in a given period, such as a month, should a customer reasonably expect service to be inaccessible to users? Such a phraseology would be more meaningful, the Forum implies, than the “99.99999...% uptime” guarantees that tend to be concocted more by marketers than engineers.
Besides these, however, there are a handful of other terms of service that you might never have thought were negotiable.
Choice of law. Few other industries in the world would give their customers freedom of choice with regard to which country enforces the law where arbitration may take place. But cloud computing is unique in that it is a wholly global technology: Data and even desktops are moved around the world in real-time as conditions warrant. The country where your company is headquartered, and the one(s) where your data is hosted, may simultaneously claim sovereignty over that data — the right to regulate how it’s used and whether law enforcement has access to it.
“With the global data flows, we have these issues cropping up at my firm on a weekly basis,” says Santalesa. “We have client X who’s sending data from the E.U. into the U.S. via safe harbor [provisions], but then there might be some other data coming in from Mexico or Latin America. Whose laws do we need to recognize? If we’re storing data in the cloud, how do we make sure that they don’t get to the cloud data center in country Y?”
Various countries claim that your data is subject to their laws when it is stored on servers hosted in those countries. But some countries also claim that your data is subject to their laws as well — or even their laws instead — when the CSP with which you’re doing business is headquartered there.
For the time being, this has led to a veiled, though perforated, barricade between the U.S. and the European Union. In July 2011, U.S.-based CSP Microsoft, the host of Windows Azure, announced to its customers that their data may be subject to inspection by U.S. law enforcement officials under the terms of the Patriot Act, even when that data is housed outside the U.S. “In a limited number of circumstances,” reads the company’s Trust Center for Online Services, “Microsoft may need to disclose data without your prior consent, including as needed to satisfy legal requirements, or to protect the rights or property of Microsoft or others (including the enforcement of agreements or policies governing the use of the service).”
The U.S.’ consideration of data centers operated by U.S.-based providers open to U.S. inspection is among the growing list of grievances for the European Union. (Another is a failure to allow E.U. citizens to sue U.S. companies in U.S. courts for violations of E.U. data protection laws.) As things stand today, the European Data Protection Directive prohibits E.U. companies from transferring their data, or allowing it to be transferred, into the jurisdiction of a country it believes may encroach upon the rights of its citizens and companies based there. The U.S. is one of those prohibited countries, by virtue of its exclusion from an official E.U. whitelist.
So (surprise!) a great deal of what’s going on in the cloud today is technically illegal. And if the E.U. had its way, you could be served.
Control of the data. Perhaps the only way you can get a handle on whose laws apply to your data and assets, and when, is by designating up front where you allow your data to reside. It’s a demand that more and more customers are making, as they become more aware of this international situation that isn’t as cloudy as it is murky.
“A lot of the questions we get on data security — certainly in the E.U., and most obviously in the U.K. — tend to be, ‘Where is my data going to be stored?’” relates Webroot’s Ian Moyse. “And if you ask them what’s behind the question, the answer is, ‘I want my data to be in this jurisdiction.’ We’ve had customers who have even specified, ‘We want to know the data will be in the E.U. and not in the U.S., because of things like the Patriot Act, where people can get access to it.’ We’ve even had Canadian customers request to root their traffic through non-U.S.-based data centers around the globe — again, the Patriot Act gets mentioned. Rightly or wrongly, as per people’s understanding.”
The major problem here is that the Patriot Act itself was written and passed in a different era, when Internet service essentially meant sending e-mails and using the Web. By volume, that’s not what it is any more — not by a long shot. Whether the Patriot Act even applies in cloud circumstances has yet to be determined by law, but until it is, it’s up to judges to apply a law from the dialup era as best they can to the cloud era.
“BlueLock has customers around the world in 11 different time zones, the majority of whom today — even if they’re headquartered overseas — are trying to serve a North American audience,” states BlueLock CTO Pat O’Day. “So putting their data in the U.S. works for them, and we don’t have the regulatory issues of those other markets, even though those other companies may be headquartered there. But we have gotten numerous requests to try and help tackle that problem in reverse. We have North American companies, particularly SaaS providers, and they see great opportunity in overseas markets to sell their SaaS application, and they don’t know how to control the regulatory issues and infrastructure requirements that are over there.”
In July 2010, Mexico passed a data protection directive intended to apply to CSPs as well as other ISPs. The directive gives Mexican law enforcement agencies the right to access customers’ data and assets under court warrant. But unlike the U.S., the service provider is obligated to inform the customer. And the customer has the right to object to the process and potentially forestall it, because of how the new law specifically identifies the customer as the owner of the data. Under the Mexican interpretation — which appears to have been inspired by the European interpretation — the data is protected by the laws where the customer resides, not where the data resides.
Navigating the various countries and the relative heights of their respective political grandstands requires a lawyer, which at this time and place in history, Rich Santalesa is quite happy that he is. “It is a very complex issue, and I think it really hurts smaller and medium-sized businesses who are trying to do any international work,” he tells us, “whereas larger companies already have a lot of legal teams in place to handle this.” Smaller companies, he adds, are fast becoming his firm’s clients.
Geography is not the only element in determining who controls your data in the cloud and when. Service category plays a role as well, and can easily become more confusing than you may have ever imagined. Consider, for example, a client of an application service (SaaS) such as Salesforce.com. That client’s vital sales and customer data are being trusted to a major corporation, whose reputation depends on maintaining that data’s integrity. If security were to be breached, most likely Salesforce.com would be responsible, and probably held liable.
On the other end of the scale, an infrastructure service provider (IaaS) such as BlueLock may offer clients resources for hosting virtual desktops in its cloud, enabling them to access full, running instances of their business desktops from thin clients and even tablet devices. In such situations, the Cloud Security Alliance has carefully concluded, security breaches on account of the client’s own shoddy desktop security may very well be the client’s responsibility.
But a fast-growing segment of the cloud market consists of SaaS providers competing with Salesforce.com and other applications, which are themselves IaaS customers. They’re leasing BlueLock’s cloud, and others, to provide SaaS services. “So what’s happening is, companies that want to outsource their infrastructure as a service but that still are responsible for their application,” says O’Day, “are struggling to create an application-level SLA.”
What they end up negotiating is what O’Day describes as an aggregate SLA: “a combination of SLAs from themselves, from BlueLock, and from other providers. It’s not the SLA for just the two companies, but also for the network plus the storage plus the compute, and all these things add up together.”
And this sometimes ends up causing a bigger mess. Like an evil algebra problem, adding together the ownership entities on one side of the equation means multiplying their respective service availability factors on the other side. When you multiply a number less than one by another number less than one, the result is always a somewhat lesser value.
“Five 99-percents do not add up to one 99-percent,” admits O’Day. “It’s more like 94 or 93. So there’s a lot of eye-opening discussion; and at the end of the day, what I’m really trying to do is guarantee delivery of the service. When the service has so many components inside of it, and there’s more than one company involved in delivering it, that’s a challenge.”
Liability. Usually, among the least negotiable aspects of a service-level agreement concern those terms that indemnify the CSP (hold it harmless and faultless) against certain damaging or illegal acts, such as copyright violation on the part of the customer. You’ll find caps on damages attributable to the customer, and terms that restrict compensation to service credits instead of dollars.
“Most cloud providers are going to seek very aggressively to keep [liability caps] to a minimum,” says attorney Santalesa. “I have worked with some negotiations where a fixed dollar amount has been specified, where each side at least has a sense of what they’re on the hook for, and what may happen in any sort of a significant data breach scenario. But in any type of data loss item like that, if you’re the licensee or the owner and you’re using the cloud provider to store it, there’s no way that you’re going to be able to shift all of the responsibility and costs onto them.”
That’s also the case when certain data is more valuable than others. When you’re shipping a package, you’re often given the option of paying a surcharge for insurance, if you claim the package has a higher value. The way cloud services work today, a CSP charges a fixed amount (usually per gigabyte) for the storage of customer data. As BlueLock’s Pat O’Day explains, if a CSP charged a customer 30¢ per gigabyte to store certain data that’s worth $1 per gigabyte to the customer, the charge for storing a gigabyte that’s worth $4,000 to that same customer will still be 30¢.
“There’s no way in the provider’s financial model for [the CSP] to take on liability reflected in the difference in the value of the actual data that it’s storing,” O’Day says. “So that burden has to reside on the part of the owner of the data, because they’re the only one who can possibly appreciate how valuable the data is that it has.”
The need for enterprises to control their risk, with respect to the cloud as well as every other part of their businesses, is just now triggering the emergence of the insurance industry into the SLA process. And believe it or not, it’s insurance that could end up the hero in all of this, tying up all the loose ends and straightening out all the deficiencies with cloud SLAs, including conflicting international laws.
“Obviously insurance companies are in the business of gauging risks,” remarks Santalesa, “and then offering products that will enable them to make money while protecting their clients and customers as well.” As underwriters begin redesigning their policies for the cloud era, he believes, they will accomplish the same thing they did for the real estate industry: the introduction of standardized templates for the agreements on which they’re willing to sign off. In other words, insurance companies could create the new standard for cloud SLAs.
“Insurance industries love templates, they love to be able to have standardized forms and conditions and primers that they present,” he continues. “I think at some point, we may see some sort of model form like that, that are adopted by the insurance industry in response to many of the governmental pressures, which is the reason those forms are adopted by the real estate industry. But right now, their efforts are really on trying to come up with a set of ways of gauging risk.”
Oftentimes the first step for insurers to gauging risk in any industry they enter, is to evaluate the damages won in lawsuits. As data loss events become more common, damage awards should normalize. But where that normal level eventually resides may depend on how judges and juries perceive the cloud as the perpetrator of data loss incidents.
A July 2011 report from security analyst firm Imperva estimates that the average website comes under attack 27 times per hour. It’s reports like these that can be cited by expert witnesses and entered into evidence. If every website comes under attack once every two minutes, it could be argued in court, why wasn’t the defendant cloud provider prepared for the attack that disgorged its customers’ data? Could CSPs face the prospect of liability for gross negligence every time an incident occurs — and could that prospect keep the insurance industry out of this market?
“In a commercial contracting situation, generally agreements are going to attempt to limit liability and damages to specific events and amounts,” responds attorney Santalesa. “While in many states, attempts to limit such damages for gross negligence or willful conduct are considered unconscionable in consumer situations (particularly if property or personal injury is involved), commercial situations are different.
“So a party likely trying to use such a report,” he continues, “would use it as evidence that the defendant’s specific conduct – depending on the facts and circumstances – didn’t rise to the level required to satisfy the party’s duty to the plaintiff. The established elements of negligence are duty, breach, cause in fact, and proximate cause and damages. All must be present. For negligence to rise to ‘gross negligence’ the breach must be with an element of reckless disregard for the results that occurred.”
So the risk of colossal gross negligence awards for now appears small. Once both CSPs and their insurers better understand risk (and the risks involved with it) Santalesa believes, they’ll be in a better position to explain those risks to customers at the beginning of the service selection process. This could be the game changer for cloud customers. Says Webroot’s Ian Moyse, “There needs to be 1) an education of the end user so that they know what to ask and that they understand why; and 2) from the vendor perspective, an openness that lets it ask the customer questions, in a meaningful format that the customer can understand.”
But the reason “cyber-policies” are relatively inexpensive now is because the system of gauging risks in the cloud, believes Santalesa, is in the embryonic state of development. “They don’t feel they can put an adequate price on it, because they don’t have their arms wrapped around the scope of the various risks yet.”
Once that system has been worked out — which Santalesa feels is inevitable — CSPs will be able to offer new service tiers that make it easier for the customer to name its terms and choose more well-defined options. BlueLock’s O’Day foresees a time in the very near future when a federation of cloud providers, all of whom agree upon standards such as those from VMware, coalesce to facilitate the hosting of each other’s data and assets. They could all offer simple, though multiple, options. Among those options would be the CIF’s star prize: choice of law.
“The idea is, basically, you buy the services through the provider in your market,” explains O’Day, “but because we’re all vCloud-based and we all subscribe to the [Open Virtualization Format] standard, you can run the workload in [Europe/Middle East/Africa] even though it’s managed by BlueLock, and the vCloud provider in EMEA is already complying, ideally, with the particular requirements of the European Union.” Prices to park data could be computed on a flexible, per-gigabyte basis according to such factors as the legal requirements of the territory where it’s parked. “And that pricing would incorporate that cost for the local provider to deal with all the localized regulations that might exist in that particular area,” he adds.
As you might expect, however, the costs of cloud computing would rise. But some of these costs could be offset, Santalesa theorizes, by the expansion of the U.S. federal government into the cloud market as a consumer. As the most likely early adopter of standardized, modernized service agreements, he believes, the government’s policy could become the model for the service levels that customers will most often prefer — and by expressing that preference, smaller private customers could save on legal costs. Or to put it like the patron of a café, “I’ll have what they’re having.”
All of a sudden, the Commerce Dept.’s definition of cloud services may have been ahead of its time after all.