lundi 29 mars 2010

Take-Away from Kuppinger Cole's Cloud Computing Security Foundations Virtual Conference (Part 1)

Last week, on March 25-26, 2010 Kuppinger Cole sponsored a virtual conference on the topic of the Security Foundations for Cloud Computing. A much talked-about topic these days as the perceived lack of security in the Cloud is seen by some as a strong adoption inhibitor. For example, Gartner in "Top Five Cloud-Computing Adoption Inhibitors" claims that data security, and regulation non-compliance risks, rank amongst the top-five Cloud Computing inhibitors. Forrester in "How Secure is Your Cloud?" classifies CIOs' fears about Cloud Computing into three categories: Security and Privacy, Compliance and Other Legal and Contractual issues. We will see that to a certain extent these fears, uncertainties and doubts (FUD) around Cloud Computing have been overly emphasized. This Kuppinger Cole event has been organized around six identity and security-related questions that have been the subject of keynotes, panel discussions and analyst viewpoints. What follows are my take-away notes of these viewpoints. Part 1 of this post focuses on the question of the "Cloud Computing security standards. Which one are already there and which one are missing?"[1], Part 2 will focus on Martin Kuppinger's initial keynote around the question of "Cloud Computing, is it really a risk?"

The good news is that the identity security standards we need for the Cloud are already there, and have been around for quite some time. The less good news is that Cloud Computing as a new industry is lagging behind in terms of these standards adoption and use compared to the traditional ITC industry. For example, access control standards are not being implemented by cloud providers as quickly and effectively as we would like. SaaS applications (e.g. as precursors of the Cloud Computing model are the driving forces toward SAML adoption. But in other segments, we see a gap in adoption that arises from the disconnection between XML-based standards and REST-based standards. There is a tendency for the enterprise world to focus on heavyweight, feature-rich, XML-based standards like SPML and SAML, whereas the Cloud world focuses more on lightweight REST-based standards and technologies such as OAuth and OpenID. This is viewed as a big disconnection between these two camps today. On the Web Services security front, WS-* protocols like WS-Trust are very much entrenched in the enterprise (e.g. Service Token Service (STS) in Geneva and OpenSSO/AM), whereas OAuth is more commonly used by SaaS providers. The Cloud Computing industry will have to decide which of these protocol families are going to be used; lightweight REST-based versus more advanced XML-based protocols. Enterprise security specialists are getting involved in this debate. The more advanced standards are seen more appropriate to the enterprise world. As such, we have seen Cloud providers implementing more heavyweight standards like SAML as a direct response to customer requirements. There will be ongoing debates around this question, but at the end of the day, the customer's point of view should win. As a matter of fact, it was suggested that the most effective leverage for standards adoption happens during the RFP contracting process where customers mandate specifically the support of SAML for example. It was noted that another standardization gap relates to the relative inability to get access to application audits and access logs in a coherent and secure way. This gap is rooted at the standardization bodies level defining auditing and access logs standards.

SAML v2 is sufficient and a well-adapted standard for the support of identity federation. SPML, on the other hand (or something very much like SPML), is needed for identity provisioning in the Cloud. The lack of a provisioning standard support in the Cloud is a serious concern that providers must address now to get around the plight of proprietary connectors and custom developments. Also, there are some educational problems around SPML. It is not a well-known standard across the board as its specification does not follow the same "happy path" as the SAML specification.

XACML standard adoption is more of a longer term issue and a more tricky concept for organizations to get their head around. The need for remote authorization in the Cloud will come at some point, but pressure on providers is a little further out. XACML is certainly sufficient for remote authorization in the Cloud and a very rich specification. However, business requirements aren't there yet for organizations to fully understand why they would need to externalize standards like this. There seems to be no generic use cases except perhaps in some vertical markets where specific security requirements call for remote authorization management.

Governance, risk management and compliance (GRC) in the Cloud is yet an even more complicated topic. It was suggested that the first place to go is not related to technology or standards, but to the framework of corporate policies. When trying to nail down cross-domain application relationships in the Cloud, you need a way of communicating requirements and policies at a higher level. At some point, there will be standards able to communicate that kind of information, but today it is hard to think of it as a standard. Risk management auditing is commonly happening more in isolation, in different places with different Cloud vendors implementing it their own way hoping it will become the standard. The best fall-back option may reside in control frameworks already in place in the enterprise such as COBIT or ISO 27000 These norms are most relevant to IT and business service management (ITSM) functions. However, the problem with these frameworks is that they are too broad and non-technical, hence leaving way to interpretations. COBIT provides standardized metrics for self-assessment and self-auditing that could be leveraged in technical standards for the Cloud.

Standards relevancy should be think through according to the three service models found in the Cloud - infrastructure-as-a service (IaaS), platform-as-a-service (PaaS), and software-as-a-service (SaaS) - because these models cast different types of constraints. For example, SaaS and PaaS are black boxes from a security point of view, whereas IaaS is largely yours to apply the same security schemes and controls as you do in on-premises data centers. In any event, auditors are looking for continuity and formalization in the way they apply assessment criteria for SOX or PCI compliance, for instance, regardless whether applications run in the Cloud or on-premises.

Indeed, not all Cloud service models are equal from a security standardization adoption perspective. There are differences between IaaS, PaaS and SaaS with regard to IAM, GRC and ITSM enablement. The key point is that the amount of control you get over your Cloud-based applications goes from one where you have almost complete control with IaaS, to one where you get almost no control - technically speaking - excepted at the data level with SaaS. The question one should ask from a security control changes point-off-view is that SaaS providers should at least provide controls for managing users and their access privileges. Getting control over access logs is a must, but difficult to achieve because of the lack of standards. As you go to the PaaS model, building an application with some level of control at the application logic level is your responsibility, but beyond that level, controls are kind of murky. With IaaS you might want to keep control over privileged users because they are those who get OS access in the VM. The main difference between IaaS and an on-premises infrastructure is that you can't go to the bare-metal. The physical machine is a black box. Anything above that is your responsibility as you can control the entire software stack and, therefore, you should keep the same controls and security processes for applications running in an IaaS and applications running on-premises. However, even though there are differences in the way your applications run in the Cloud, the standards that are used for IAM and GRC should be consistent across the board regardless of the deployment model being used. That is not the case today. For example, getting SAML support in a public SaaS out of your technical control requires the provider to do it for you, whereas in IaaS, buidling SAML in your application is up to you. If you build it, you get it.

The Cloud has already affected the evolution of Web Services and SOA and standards around these technologies. For example, already has more interactions with its Web Services API than it does in terms of browser interactions. Also we can see an increase of inter-cloud interactions with mashups. We have gone from a unidirectional kind of interaction to a bi-directional interaction (i.e. inbound and outbound data transfers). Again, enterprises are focusing on WS* standards whereas the Cloud focuses more on REST-based APIs, for which there wasn't, until the advent of OAuth, a good standard for identify and data security. But there is still a little bit of flux. It is still too early to say which standard to use to secure Cloud-based services because Cloud management APIs haven't stabilized enough yet to positively say which WS* or REST style approaches will prevail. Also, the emergence of the Cloud is the best thing that can happen to SOA because it is bringing under the spot light a compelling service-oriented architectural paradigm.

Cloud computing vendors are adopting IAM security and GRC standards slowly. Too slowly according to the panelists. Customers should mandate for the support of these standards at procurement time as they are the biggest adoption drivers when dealing with SaaS offerings for instance. However, this is not slowing down Cloud Computing yet because INFOSEC people are just starting to think about the security aspects of Cloud Computing and auditors who have to measure the enterprise's ITC against corporate security policies and regulatory compliance are just starting to show interest in the Cloud. These two groups will certainly start to have more influence over these problems to be addressed in a more timely and standardized manner. They will be one of the forcing factors to accelerate the deployment of these standards. At the end of day, Cloud Computing vendors will adopt established security standards only if there is a compelling business incentive for them (i.e. service differentiation, taking into account customer requirements) otherwise they won't. Therefore, the ITC security industry needs to keep pushing for this to happen in any possible way.

[1] Speakers: Matthew Gardiner - Director CA, Patrick Harding - CTO Ping Identity, Martin Kuppinger - Kuppinger Cole

Aucun commentaire: