Cloud-computing insurance has long been posed as a solution to the problem of cloud users assuming too much risk of failure in the wake of things such as lengthy outages, data breaches and Lulzsec attacks. But it seems the idea of off-loading some of that risk to a third party — an insurance provider — is finally becoming a reality. Kind of. At the very least, insurance providers are recognizing the importance of insuring both cloud providers and the companies that patronize them — even if their policies still need some fine-tuning.
Getting the lay of the land
That the discussion is at least happening, though, bodes well given the current state of affairs: As it stands right now, customers of cloud providers like Amazon Web Services, Rackspace Cloud, other so-called “credit-card” or “commodity” clouds and most SaaS customers have very little recourse in the case of an outage, breach or other incident. As I explained when examining the state of cloud-computing contracts last summer, most standardized cloud contracts absolve the provider of paying any damages beyond what the service-level agreement (SLA) dictates.
In the event that negotiating is an option — if you’re a big enough customer or if you choose an enterprise cloud provider — the InfoLaw Group offers some good advice for how to approach it. But organizations shouldn’t be fooled into thinking that even a negotiated SLA or an assumption of liability counts as insurance.
This excerpt of the famous cloud-services contract between Google and the city of Los Angeles is particularly illustrative:
It’s notable to attorney types because Los Angeles was actually able to negotiate extra-SLA liability for security breaches (paragraph 14.3), but any other incident resulting in loss of availability or data was remedied by service credits (paragraphs 14.1, 14.2). There is one other key point to note: Alleging and proving both breach of contract and the resulting damages could be a much more cumbersome process than filing an insurance claim.
SLAs are fine — necessary, in fact — but generally they’re not too meaningful. This is because they only give credits based on some percentage of what the customer has paid to the provider, and they only kick in if availability drops below a certain level. A small outage won’t necessarily result in credits. Because they’re based upon system availability, SLAs are particularly ineffective for security breaches that don’t result in downtime. In most cases, security breaches don’t require any compensation from the provider.
Service credits, or any refund-like recompensation, probably aren’t too meaningful, either. Such measures acknowledge a faulty product, but they do nothing to cover the myriad of other costs that a company might incur as a result of an incident — costs that a properly drawn insurance policy would cover. A nonexhaustive list of potential costs includes the notification of customers and other law-abiding behavior regarding breaches: lost revenue during downtime, reputational damage and potential lawsuits from customers whose data was compromised or who couldn’t access a cloud-based service.
For Los Angeles in its Google deal, for example, a week long Gmail outage might warrant a hefty refund or credit, but it won’t even begin to address the chaos resulting from city employees not being able to communicate via email.
Why no negotiations?
There is a pretty straightforward explanation as to why one cloud provider would have generally standard nonnegotiable terms, while others would expect to negotiate with customers: economics and anonymity.
It would be economically imprudent for a commodity cloud provider that offers standard capabilities via a simple web transaction to allow for lost profits, consequential damages and other extra-SLA recourse when the cost of obtaining the service is so low. Even if an organization is spending hundreds of thousands per year on a cloud provider, the cost of an outage or security breach could be far higher for that organization in terms of lost profits and/or damage to reputation. It just doesn’t make much sense for a provider charging 6 cents per hour for a CPU to take on that risk.
Meghan Hannes, the managing director at CloudInsure, a company focused on creating the ideal risk-analysis rating system for cloud computing, looks at the issue from the customer perspective. For customers, she paints the issue as being about the cost of using cloud computing versus the cost of relying on cloud computing. For large enterprises with potentially millions of dollars on the line, or small companies that could base the majority of their IT operations in the cloud, the cost of using the cloud is very appealing. But the potential cost of relying on a provider that won’t truly make them whole (i.e., covering costs beyond that of the cloud service itself) in the case of an incident can be a big detractor, she says.
Anonymity only makes things worse from the provider’s perspective. Assuming a pure credit card transaction, the provider doesn’t necessarily know who’s running what on its cloud. It’s pretty difficult to gauge the true value of a business when any outage or security incident could potentially result in numerous high-value lawsuits.
This was illustrated during the Amazon Web Services outage in April 2011, during which a company emerged on the AWS support forum claiming it was running a heart-monitoring application on AWS, and could no longer read EKG measurements. Imagine the damages that would pile up if AWS’ outage resulted in someone’s death.
From a provider’s perspective, there are likely three options for allocating risk when there’s the potential for customers using the cloud to generate a large amount of revenue or to run critical applications:
- Negotiate risk with everyone who asks, turning the push-button business model on its head and potentially turning away customers that pose too much risk.
- Closely monitor and close customer accounts if they’re using the service in an unsuitable manner (which might be distinguished from using it inappropriately, à la Wikileaks).
- Offer the standard “use-at-your-own-risk” agreement.
Which do you think most providers prefer?
Cloud insurance: where it is now
Cloud insurance, however, is only in its infancy, and policies haven’t necessarily been tuned for the unique realities of doing business in the cloud or for the newfound value in data. As ACORD, an insurance industry trade group, pointed out in January, although cyberliability as a whole is a priority for insurance providers, they’re really just starting to get their head around it, much less the intricacies of the cloud. Many cyberliability policies, for example, still only address infrastructure and security policies that companies manage themselves.
Looking at policies that do purport to address cloud computing, it’s easy to spot some shortcomings. Technology-errors-and-omissions policies generally cover cloud providers quite nicely in the case of any outage or breaches that might result in their facing lawsuits or owing damages. However, the privacy and data-breach policies that often constitute a cloud customer’s policy option tend to address only third-party data and the costs associated with remediating a breach or other incident that exposes or otherwise affects that data.
What they don’t appear to cover is damage to a client’s own data. They certainly don’t cover lost profits or other losses stemming from a service outage. So, if a cloud provider goes down for a week, most insurance policies won’t cover it. Let’s take the example of a medical-records company as the insured user. If a cloud provider suffers a major breach, insurance will pay for the medical-records company to notify any patients whose medical records were being stored in the cloud and to defend any lawsuits from those patients. But if that breach only results in the theft of the medical-records company’s own internal data, which is valuable in its own right, insurance doesn’t kick in for the costs of restoring it.
Another signal that cloud insurance is still young has to do with how it characterizes the relationship between cloud providers and cloud customers. Reading through advisory articles and insurance applications, one might get the impression that cloud computing is very much like traditional IT outsourcing. Outsourcing arrangements are specific to each company and each application. Such arrangements typically involve extensive negotiation around issues, such as the IT system on which an application runs, SLAs and which party assumes the risk in any number of situations involving failure, security breach, etc.
Of course, this is much different than a standard cloud-computing arrangement. Another reason for those unnegotiable terms in many cloud contracts — only hinted at above — is that unlike with traditional outsourcing, the cloud is all about standardization. Cloud-computing resources and SaaS applications are delivered from multi-tenant infrastructures that excel at doing one thing. The reason prices are so low is that providers can achieve economies of scale by purchasing and operating their resources at a large scale because they know they only have to deliver standard services.
Standard services mean cheap resources on demand within seconds or minutes — no engaging with a sales representative, discussing the customer’s needs, negotiating terms and eventually standing up the application. Just as handmade couture garments are more expensive than mass-produced T-shirts pumped out of a sweatshop, so too is traditional outsourcing more expensive than cloud computing — and neither cloud providers nor their customers would have it any other way.
Cloud insurance: where it’s headed
Hannes’ company, CloudInsure, might offer the best example of where cloud-computing insurance is headed. The factors it uses to rate risks and its insurance-provider clients are currently a secret, because the company is still in the developmental phase. Still, the gist of the business is pretty simple to understand: CloudInsure rates cloud providers based on their security policies and infrastructures, cloud customers based on their security policies and the value of the data itself. This results in a unique data risk for each customer.
CloudInsure is an entity of parent company CyberRiskFactors, and uses data from its sister company CyberFactors as the basis for its risk-rating methodology. CloudInsure partners with insurance providers that sell policies based on its ratings.
Hannes thinks this strategy does the trick because it addresses the needs of all the parties involved — customers, cloud providers and insurance providers. Customers have peace of mind knowing they’ll be effectively compensated for lost profits or any costs they incur because of an incident. Cloud providers get coverage, and, as Hannes said, the fact that they’re underwritable proves they’re inherently secure. Insurance providers presumably avoid the legwork of having to develop new risk models that accurately address the realities of cloud computing.
CloudInsure’s list of presently covered cloud platforms suggests that it understands this isn’t typical outsourcing. The company covers Amazon Web Services, EMC, Facebook, Google, Intuit, Microsoft, NetSuite, Oracle, Rackspace, Salesforce.com, SAP and SuccessFactors. Presumably, CloudInsure takes into account such considerations as the best practices for operating a globally distributed, multi-tenant and highly virtualized infrastructure, which is unique among cloud computing compared to other forms of outsourcing.
CloudInsure’s model might get some assistance from the IEEE, which has been beating the drum for cloud insurance, too. In a recent interview, IEEE CIO Alexander Pasik laid out the case nicely: Cloud providers aren’t going to offer compensation for data breaches, for example, without spreading the cost of that self-provided insurance across their customer base in the form of higher prices.
However, he explained, insurance premiums are far less costly than paying out of pocket for security incidents. Since cloud computing is all about economics for providers, the ability to pay lower premiums by implementing better security procedures should actually improve cloud security. The same goes for customers. Choosing a more secure cloud and implementing better security procedures on their end will result in lower premiums and better protection. Although Pasik’s comments focus on security, the same rationale applies to availability. Better procedures by both customers and providers to ensure uptime will result in lower premiums and higher availability levels.
As Pasik notes in the interview, it’s like getting a lower auto-insurance premium because one parks his car in a garage instead of on the street. In fact, the auto-insurance analogy is particularly apt. Consider this oversimplified example:
Provider A implements the best-possible security policies, and runs its service across a globally distributed set of resources designed to failover workloads to another geographic region if something goes wrong. By contrast, Provider B opts for a middle-of-the-road security strategy and runs its entire operation from a single data center. Provider A will get lower premiums should it decide to get insurance to cover itself because its system is safer and more reliable. Likewise, Provider A’s customers will get lower premiums for choosing a safer, more reliable provider. Done right, customer premiums should also be based on how adequately they have designed their applications around security and availability. One issue that surfaced during the Amazon Web Services outage in April was how many users hadn’t prepared to recover from a failure as fully as they could have.
It’s almost exactly like auto insurance. Automobile companies have insurance policies of their own to protect against litigation, almost certainly tied to how likely they are to face a product liability claim, and for how much money. Automobile owners get lower rates for driving safer cars, but also for taking additional steps on their end to help reduce the chance of an accident or other damage. They can park in a garage, install a security system, drive fewer miles or not let their teenagers drive the car.
The CloudInsure model appears to take things a step further because it tries to value the customer’s data itself, but the auto insurance analogy still fits. It’s like trying to insure a Maybach compared with trying to insure a Ford Taurus. Assuming they’re equally safe, the former will cost more to insure because it will cost more to fix if something goes wrong. Financial-trading data and applications, for example, probably demand a higher premium than does a small business’s HR data and applications.
It will be very interesting to watch how CloudInsure, existing insurance providers and even the IEEE advance their efforts on the issue of cloud insurance. Very likely, they’ll have to work together with other stakeholders and technology specialists to get it right. At a high level, it might not appear different than assessing risks for any outsourcing or web-related activity, but its unique business model and infrastructural practices make it a very different beast in some important ways.
In the meantime, while cloud insurance policies are still shaping up and as companies like CloudInsure ready themselves for business, both cloud providers and users should act as if a standard cloud-insurance framework is already in place. The more secure and available things are on both ends, the better the results for everyone are — both now as well as when the time comes to get insured.