An infographic about Security and other Cloud Barriers

I know that Cloud Security, as well as other important Cloud barriers, is a subject already treated in this blog several times (e.g. here, here and here) but, in fact, it is a recurring theme in the current Cloud Computing area. So I decided to copy this infographic about the subject.

But, I want to emphasize (since it back my opinion) 2 points:

1. In one hand, some concerns about public cloud security are starting to fade, as it’s showed in this infographic when comparing the results of 2012 survey with the 2011 one. Of course, security concerns still remain high, but they are changing from infrastructure technology based security risks to laws and standard compliance related subjects what shows are higher confidence in the Cloud Service Provider and the solutions they use to offer their service.
2. In the other hand other concerns are growing, as also showed in the picture (compliance, loss of control, complexity, and so on); however, in my opinion two of the more important: lack of standardization (and its several consequences as vendor lock-in, no interoperability, and so on), and weak SLA are missed (according to the data of the survey that this infographic summarizes survey).

Note: About SLA, I should mention specially the one related to service unavailability, since according to International Working Group on Cloud Computing Resiliency, each year a cloud computing is usually down for an average of 7.5 hours. And yes, I know that availability and other SLA measures security properties (see my post titled “Cloud SLAs: a technical point of view“).

 

(Note: the source of this infographic could be found here: http://www.andrewhay.ca/archives/2224).

 

Cloud SLAs: a review of current contracts

Last week I spoke about Cloud SLAs (Service Level Agreements) from a technical point of view, and to back my opinion I cited Gartner’s analyst Lydia Leong’s post that states that Amazon Web Services (which Gartner recently named a market-leader in infrastructure as a service cloud computing, and I think everybody agrees) has the dubious status of “worst SLA of any major cloud provider” and that HP’s newly available public cloud service could be even worse. Let me remind that the main reason (but not the only one) for this statement is the strict requirements of service architecture forced by Amazon and HP. As stated, this isn’t the only reason: besides SLAs are also unnecessarily complex and limited in scope.

Moreover in an amazing post titled “SLA feather allows you to fly in the cloud” another Gartner analyst, Jay Heiserm, uses the Disney’s cartoon Dumbo analogy, and he remind us that AN SLA IS NO MORE THAN AN EXPRESSION OF INTENT; IT IS NOT EVIDENCE OF DELIVERABILITY; in fact, an SLA from a public cloud service promising some sort of recoverability can be a crow feather, clutched in the trunk of the enterprise elephant, providing them the false courage to be willing to fly in the public cloud.
 

Another Jay Heiserm’s post (“Bulletproof Contracts“) summarizes some contractual terms provided by a SaaS prominent vendor and that I copy below (including funny Jay’s comments):

• We believe that we obey the law. If there are any questions pertaining to how your data is handled within our system, it is YOUR problem.
• We won’t give your data to the police. Unless we do give it to the police.
• When this contract is over, you may have the ability to get your data back, but that is YOUR problem, not ours.
• If one of your customers contacts us, we won’t give them anything. Unless we are forced to give them something.
• We will store the data in whatever country we want.
• We might have third parties help us with this, and they of course would be held to the same weak levels of standard as we contractually obligate ourselves to follow.
• You the customer are obligated to obey the law at all times, even if you have no idea what that may entail. (Guess what happens if there is a dispute with us and our lawyers can find some way to demonstrate that you didn’t completely follow the law.)
• We will follow appropriate security measures—as understood by us.
• We will back up your data at least once a week, we will review our procedures periodically, although this seems unnecessary, given that none of these procedures were knowingly designed to fail. If we have the slightest plan for testing our ability to recover, we are not sharing it with you and we hope that you won’t ask that question.
• If any of our support personal ever accesses your data, by definition, it is necessary access.

Finally, copying again but now from NetworkWorld, I analyze the contracts usually signed about SLA cloud, the terms they include, what is its impact, and how often they are present in the current cloud contracts.

All these point are summarized in the next table (please note that I only have copied the NetworkWorld’s data in a table, so for a more accurate a big explanation you should read the NetworldWorld post):

 

Note: Encryption related clauses are not present because in my opinion currently they are either a new service itself, or a differentiating service feature.

Cloud SLAs: a technical point of view

Initially, when I started the first version of these comments, I was decided to speak about Cloud SLAs (Service Level Agreements), because I reminded the contribution of some friends of mine in the last ISACA conference I assisted about its importance (and in spite of that it was lightly treated in the conference discussions because of other subjects capitalize the attention) and ‘cause in my point of view they’re almost nil in the current Cloud contract, as a recent Gartner’s study states. In fact, it is a subject I faced in previous posts: some in English (“Real” Cloud Computing Services vs. “Fake” Cloud Computing Services), and some in Spanish (El Cloud Computing y la ISO-20.000 e ITIL: conteniendo el sobre-aprovisionamiento – Capacity Management).

But, I don’t know how, a few lines after I was speaking about Cloud risks in general, and a few lines further, I was thinking of security concerns, but trying to don’t speak again only about privacy and regulations compliance (as in many discussion everybody only thinks), but also about data lost, data integrity, and so on, remember what CIA means for security: Confidentiality, Integrity and Availability, where everybody adds a second A for authenticity, in both senses, to avoid repudiation and to grant information access only to the correct persons. Then I reminded myself that although without doubts security is the most important Cloud risk, but not the only one and it is even losing relative importance against others; in fact, as the time goes by, new risks are becoming more important for the CSOs (Chief Security Officers) of big companies (75% of them “are confident in security of their data currently stored in the cloud”, according to a recent VmWare report) that are already using Cloud Services: portability, vendor lock-in, standardization, learning curve, and so on (see my Spanish post  ¿”Nubarrones” en la Nube? whose title means something like “Dark clouds over the Cloud?”), and we must not forget SLA incompliance, that was the idea I was trying to write about.
 

And then, when I came back to the initial point, I decided to throw all the written so far in the trash (and the time spent), and to focus only in this subject and trying to not wide (I’ll treat the other subjects in next posts) because otherwise this is going to become confuse and difficult to understand, and to use the information that more clever minds have written. So, here I go:

According to Gartner’s analyst Lydia Leong, Amazon Web Services (which Gartner recently named a market-leader in infrastructure as a service cloud computing, and I think everybody agrees) has the dubious status of “worst SLA of any major cloud provider”.

However, HP’s newly available public cloud service could be even worse. By the way, HP launched the general availability of its HP Compute Cloud on Wednesday, December the 5th  (HP Cloud Compute is a pay-as-you-go Cloud IaaS service that the company first announced earlier this year as a beta program and now is generally available) and it’s based on OpenStack (my favorite open Cloud Platform, I’ll promise to show my reasons about in a future post and compare it against other open platform).
 

Despite of AWS has voluntarily refunded customers impacted by major downtime events even when the SLA did not require it (AWS has experienced three major outages in the past two years), as I underlined it has been voluntary decision, not a consequence of signed SLA. In fact, Ms. Leong recommends investigating cyber risk insurance, which will protect cloud-based assets, because of the SLA requirements basically render the agreements useless. “Customers should expect that the likelihood of a meaningful giveback is basically nil”, she sayd. The main reason for this statement is the strict requirements of service architecture forced by Amazon and HP:

• Both AWS and HP impose strict guidelines in how users must architect their cloud systems for the SLAs to apply in the case of service disruptions, leading to increased costs for users.
• AWS’s, for example, requires customers to have their applications run across at least two availability zones (AZ), which are physically separate data centers that host the company’s cloud services. Both AZs must be unavailable for the SLA to kick in. Of course, that does imply bigger costs.
• HP’s SLA, only applies if customers cannot access any AZs. That means customers have to potentially architect their applications to span three or more AZs, each one imposing additional costs on the business.

However, this isn’t the only reason, others aspects of the SLAs contribute to void its effectiveness as a user’s control and defense: besides SLAs are also unnecessarily complex (“word salads”) and limited in scope. For example, both AWS and HP SLAs cover virtual machine instances, not block storage services, which are popular features used by enterprise customers. AWS’s most recent outage impacted its Elastic Block Storage (EBS) service specifically, which is not covered by the SLA: “If the storage isn’t available, it doesn’t matter if the virtual machine is happily up and running — it can’t do anything useful”.

Next post I’ll come back on this subject and I analyze the contracts usually signed about SLA cloud, the terms they include, what is its impact, and how often they are present in the contracts.