• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Cutting To The Chase: Cloud From A Customers Perspective
 

Cutting To The Chase: Cloud From A Customers Perspective

on

  • 973 views

Discussion of legal issues in cloud computing from the customer's perspective

Discussion of legal issues in cloud computing from the customer's perspective

Statistics

Views

Total Views
973
Views on SlideShare
821
Embed Views
152

Actions

Likes
1
Downloads
0
Comments
0

4 Embeds 152

http://cloud-security.i-base.co 136
http://www.linkedin.com 10
http://www.visualcv.com 4
https://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Just a little bit about me, my practice, and my firm. My background is heavy technology with 2 degrees in engineering and stints at Andersen Consulting (now Accenture) and IBM. I am a certified information privacy professional and focus my practice on commercial transactions involving technology and intellectual property. Basically if you want to sell or acquire technology to further your business objectives, I am the person to help you get that done. My firm is a general practice firm with offices on both costs and internationally. We’re a pretty large firm with well over 500 lawyers and professional.
  • This slide supports what I was just discussing. There is quite a bit of interplay between the providers of the cloud services. Vendors provide all three types of services. Notice that infrastructure supports platform and platform supports software. Developers may be consumers of infrastructure and platform, so they can provide software. Now this isn’t the only way that they relationships work, as clearly and end user could use the infrastructure as its backup storage solution and not have any relationship at all to platform or software at all. That being said, as a consumer plugs in at higher and higher levels, its reasonable to assume that the provider of the service has utilized supportive cloud services.
  • Of the five characteristics presented here, note that cloud differs in some way from both outsourcing and ASP. Many have asked ‘well, isn’t cloud just outsourcing or the same thing as application service providers services.’ The answer is both yes and no. Cloud computing is a form of outsourcing, but many of the features of traditional outsourcing are different than cloud computing. And, as we mentioned earlier, application service provider services are the predecessors to software as a service. But again, there are some differences. Let’s take a look at the matrix here. Of the five characteristics presented here, note that cloud differs in some way from both outsourcing and ASP. A couple of quick definitions – outsourcing in this context is where a company takes a technology or business process and let’s a third party essentially step into the company’s shoes and deliver the services as if it were the company. Usually the company provides the software and/or hardware for the outsourcer to use and the environment is closed for each customer. Application service providers offer services that are accessed via the internet, but the hardware is housed in a set of known data centers. The environment is closed in that the ASP is running its software on its hardware. There is no sharing of technology resources. With those definitions under our belt, lets go to location of service or data. The notion of location irrelevance is a key feature of cloud computing. When one contracts for cloud services, the user has absolutely no idea where the data is, how its being processed, where its being processed. This is different from both outsourcing and ASP, where generally as a matter of contract the user knows exactly where processing occurs and where data resides. Second, the owner of the technology – with both cloud and asp, the provider owns the technology. As we just discussed with outsourcing, the company outsourcing the services owns the technology. Third, the nature of the contract – in most public cloud contracting the contract is an online agreement commonly known in legal circles as a click wrap agreement. That term is a permutation of the shrink-wrap agreement that is found in most commercially available software. The agreement is underneath the shrink-wrapped plastic. This gives the user no opportunity to review the terms of the agreement before purchasing the software and eliminates the negotiability of the terms. Similarly in the click wrap context, the user has the ability to review the terms, but has no ability to negotiate them. This is completely different than what has been traditionally seen in the outsourcing and ASP context, where the contract has been potentially highly negotiated. This lack of negotiability ties into the next item, contract risk. Not surprisingly, since the cloud provider does not give the user the right to negotiate the terms, they create a contractual relationship where all the risk sits with the user of the services. This is different with outsourcing, where the provider carries significant contract risk, and ASPs where the risk is typically shared. Finally, cloud systems are quickly scalable by design, but outsourcing – also by design – are not. That’s because the hardware and software is limited by the acquisitions of the company contracting with the outsourcer. The scale is limited by the available excess capacity. The ASP may have some ability to scale, but that scalability is based on customer-base growth, not on having on-demand capacity.
  • Most public cloud services are contracted for using the click wrap model as we previously discussed. This chart shows what the user loses through this contracting mechanism. The click wrap is not negotiable, provides no or very little protection for the user in the event the provider does something wrong. As a result, the risk of problems is born by the user. If the contemplated cloud services warrant an RFP being issued by the potential user, then a standard contract may result. This will most likely result in much more favorable contract terms for the user.
  • Though there’s nothing new about a privacy policy, as it’s been around as long as the internet has been a commercial enterprise. However, the privacy policy has morphed into a document that essentially said ‘we don’t keep your information private’ to one that does a reasonably good job of indicating how your personal, company, and aggregated information will be treated. This document takes on enhanced importance in the cloud context since a cloud user’s data can reside in multiple disparate locations (including international locations). Let’s take a quick look at Google’s approach to online contracting through it’s terms of use and privacy policy. I choose Google because of the sheer breadth of its cloud and ASP offerings. Google obviously has its search engine, but that’s merely a scratch on the surface. Here are a sampling of Google’s products: Gmail, Google App Engine, Google Apps, Google Earth, Chrome, Reader, Talk, Picasa, Toolbar, Calendar, Maps, YouTube, DoubleClick, and Gadgets. If it’s online, Google wants a share of it. Well, Google has to take a comprehensive view to accessing its services, and so it has one standard privacy policy and a standard set of terms of use, and has specific terms and conditions for each of its offerings that supplement the base terms and privacy policy. What’s the skinny with Goggle. Well, as you see here, a user grants Google a right to the content that its created and stored or processed in its servers. Google is contractually permitted to modify your content. If the service is broken, that’s just too bad. It is ‘as is’ and ‘as available’. Further, and not surprisingly given what I’ve shared with you about risk allocation in click wrap agreements, it has no risk for a user’s damages, even if it does something wrong like failing to store the data, corrupting it, or deleting it. These are a couple of examples, but these terms apply to all of Google services unless the service specific addendum overrides these – and in most cases they do not. But even though the terms are consistent across all of their services, the effects to the user of those service differs. My last bullet highlights that point. If Google loses my email, that’s one thing. But if I am developing software using Google Apps Engine, that’s really something different for me as a user. Loss of my code, my development environment have a potentially huge detrimental effect.
  • The United States, as you know, does not have a comprehensive data privacy regime. It’s laws are sectoral on the federal level. Also, the states have gotten into the mix with their data breach legislation. What this slide illustrates is that depending on the nature of the business information being placed in the cloud, there may be any number of laws that apply to it. The following slides discusses data breach and a bit on each of these laws. Also, what’s not here is the new Massachusetts law that requires personal information of Massachusetts residents to be encrypted on servers.
  • Let’s switch to some commercial considerations. We will take these items in turn. Ultimately its all about assessing and minimizing risk regarding the processing and data placed in the cloud. Each of these points all deal with risk mitigation in one form or another.
  • What are the big risk areas? Data integrity, service level agreements, and disaster recovery. Data integrity deals with the data remaining in the form that it was provided with no alterations of any kind other than the intended alterations caused by processing. If data is corrupt bad information results. In this case paying attention to the contractual language regarding data integrity, if any, will give you some sense of what the provider is willing to agree to. This, of course, may be very different (and far less than) what they try to do. But you can only recover under a contract if the language giving you a recovery is actually in the contract. The SLAs are another place to look to drive down risk. If the provider gives a robust SLA regarding uptime and other key metrics and provides some sort of remedy if the SLA is not met, then the user should have comfort that the provider is at least attempting to do the right thing to make sure its systems stay up and the data remains available. In an environment where the user doesn’t control its data, since the user has placed the data in someone else’s hands, knowing that the environment will have highly availability is key. A low or no SLA is a yellow flag. Whether it’s a deal breaker depends on the nature of the information potentially being placed in the cloud. For the most part, a user has to rely on the cloud provider with respect to data integrity and SLAs. However, both the user and the provider have a role in disaster recovery. While it is important to try to glean what a provider’s DR strategy is, this information may not be accessible. I would suggest that this burden should rest more with the user. Ultimately the user has the responsibility to a customer, whether that customer be internal or external. So, the user should have a workable disaster recovery strategy in case a cloud provider has a catastrophic event or has a data outage. Let’s look at Gmail. In 2009 Google has had roughly 6 email outages of various durations, various severity, and effecting different numbers of people. For those that use Gmail as their primary email provider they have had a bit of a rocky road this year. Ultimately, we have to figure out how much to trust these providers and how much to use our own DR strategies that are independent of the cloud provider.
  • Viability of the cloud provider. It definitely matters. Why does it matter? Because the user makes an investment in a cloud provider when it selects it. Limited interoperability between providers makes migration between providers difficult. Also, there is a bit of ambiguity surrounding what might happen to a user’s data in the event that the provider files bankruptcy, or is merged with or is acquired by another company. Let’s talk about these in turn.
  • The first scenario, the provider files bankruptcy. In this scenario the data is treated like any other asset and is subject to the same disposition as a desk or a computer. It’s not treated like intellectual property – which has its own set of rules. If the data is personally identifiable information then the privacy policy of the provider will give some sense of what will happen to the data and there might even be a role for a consumer privacy ombudsman who will determine whether the data can be sold off as an asset of the bankrupt company. The concern for the cloud user is this – potential loss of control over who has custody of its data and whether there are potential custodians of the data that would be uncomfortable for the user, like a competitor, for example. Potential workarounds if the bankruptcy temporarily froze the user’s account with the provider, etc.
  • A potential merger or acquisition is potentially less troublesome than a potential bankruptcy. Why, well at least in the near term business will continue as usual. The user will get little if any notice at all regarding the transaction. So the user will wake up one day and learn that company X is now company Y. There may be some rights of termination in the contracts if the user is displeased with the new company, but the user would need to have access to the contract terms to determine that. Almost assuredly, the data will go with the transaction. So the same issues regarding discomfort with the new potential owner would apply. One risk – that the new owner will change the services over time in a way that no longer satisfies the user’s objectives. The option in such a scenario is really just one – terminate the relationship.

Cutting To The Chase: Cloud From A Customers Perspective Cutting To The Chase: Cloud From A Customers Perspective Presentation Transcript

  • Janine Anthony Bowen, Esq., CIPP 404-527-4671 March 25, 2010 © 2010 J. A. Bowen. All Rights Reserved. Cutting to the Chase: Cloud Computing from the Customer’s Perspective
  • Your Presenter
    • Janine Anthony Bowen, Esq.
      • Janine’s practice focuses on strategic commercial transactions involving technology and intellectual property. Such transactions include licensing and acquisition of technology, including cloud computing services; issues surrounding the protection and exploitation of Internet-based assets; privacy and information security; and technology export compliance. 
    • McKenna Long & Aldridge LLP
      • 500+ Attorneys and Public Policy advisors
      • A national, general practice firm focused on transactional, litigation, and government/regulatory matters
      • 9 US-based offices, 1 international office (Brussels, Belgium)
  • Agenda
    • I. What is it?
    • II. Distinguishing Cloud from Outsourcing and ASPs
    • III. The Various Cloud Contracting Models
    • IV. Data Privacy and Security Considerations
    • V. Commercial and Business Considerations
    • VI. Negotiation Strategy
    • VII. Take Away Messages
  • Cloud Computing Plain English Definition
    • From the Customer ’ s Perspective
      • Data processing and storage, application development, and software hosting over the Internet instead of on a personal computer or over a business ’ network
      • Available on an ‘ on demand ’ basis
      • Location of information stored ‘ in the Cloud ’ is potentially unknown at any given point in time
      • Relatively inexpensive
  • How’s it Different?
    • Geography – Data in the cloud can be anywhere; multiple copies can be in multiple locations
    • The potential for brokering capacity exists, this is ‘surge computing’
    • In current state of play cloud providers assume virtually no liability – all risk resides with the user
    • Difficult for a user to know where liability rests, even if it were properly assigned
    • The nature of the potential legal issue depends on where a user plugs into the cloud
    • Virtually complete loss of control by data owner (who holds it and where is it?)
    • Relatively inexpensive OPEX instead of CAPEX
  • Service Model Relationships Gerard Briscoe, London School of Economics and Political Science, Alexandros Marinos, Faculty of Engineering & Physical Sciences, University of Surrey, “Digital Ecosystems in the Clouds: Towards Community Cloud Computing” March 2009
  • Understanding the Differences: Cloud vs. Outsourcing vs. ASP Cloud Computing Outsourcing ASP Location of Service/Data unknown known known Owner of Technology provider Probably the user provider Contract non-negotiable highly negotiated negotiated Contract Risk company provider shared Scalability Yes No Maybe
  • Cloud Contracting Models: Online Contract vs. Standard Contract Online Contract Standard Contract Negotiable No. Yes, generally. Limits Placed on Provider ’ s Liability Yes. Very little or no liability to provider. Yes. Risk shared by provider and user. Risk in the Event of Problems Born by user. Born by party responsible.
  • Cloud Contracting Models: Terms of Use & Privacy Policy
    • The Privacy Policy and Terms of Use specify the privacy protections in place as well as the terms under which the services are offered
    • Mini Case Study – Google’s Terms and Privacy Policy
      • User grants content license – Google can modify the content to deliver the service
      • User’s use of services is ‘as is’ and ‘as available’
      • No liability for user’s damages, including for deletion, corruption, or failure to store a user’s data
      • Effect on a Gmail user is one consideration, but what about a Google Apps (PaaS) user?
  • The Law is the Law is the Law: Privacy from the Customer’s Perspective
      • Data Breach/State Laws
      • HIPAA/HITECH Act
      • USA PATRIOT Act
      • European Union Data Privacy Directive
  • Data Security: A Key Consideration
    • Confidentiality
      • Limits on who can get what kind of information
    • Possession/Control
      • Loss of control of the information, regardless of whether there is a breach of confidentiality
    • Integrity
      • Information is correct or consistent with its intended state
    • Authenticity
      • Correct labeling or attribution of information
    • Availability
      • Timely access to information
    • Utility
      • Usefulness of information (e.g. loss of encryption key for encrypted data eliminates its utility or usefulness)
      • *Parkerian Hexad proposed by Donn B. Parker (can be found on Wikipedia)
  • Commercial & Business Considerations
    • Methods to Minimize Risk
    • Viability of the Cloud Provider
    • Other Factors to Consider When Selecting a Vendor
      •  
  • Commercial & Business Considerations: Minimizing Risk
    • Contractual Methods to Minimize Risk
      • Data Integrity – ensuring that data at rest is not subject to corruption
        • Look for contractual obligations or representations regarding data integrity
        • Perhaps have SOW-level detail
      • Service Level Agreements (SLAs) – the cloud provider’s contractually agreed to level of performance
        • What is the SLA and what happens if it is not met? Look for teeth here.
      • Disaster Recovery requirements
        • Learn more about the cloud provider’s DR strategy?
        • If your information is lost due to a catastrophe at the cloud provider, can you recover?
  • Commercial & Business Considerations: Viability of the Cloud Provider
    • Viability matters. Why? A cloud user makes an investment when choosing cloud provider. For example a user:
      • Integrates cloud services into existing business processes
      • Migrates data from its environment to a cloud environment
    • Lack of standardization makes moving to a new cloud provider difficult
    • What happens to a cloud user’s data in the event of:
      • Bankruptcy
      • M&A
  • Viability of the Cloud Provider: Bankruptcy
    • Cloud Provider files for Bankruptcy
      • Data is treated as a non-intellectual asset and is subject to different rules
      • Privacy Policy will provide first indication of what a Provider will do with the data
      • Depending on the nature of the data and it’s sensitivity, a “ consumer privacy ombudsman ” may determine what happens with personally identifiable information
      • Contract terms can override the general rule
  • Viability of the Cloud Provider: M&A
    • Cloud provider merges with or is acquired by another company
      • Cloud user will likely get no notice (unless size of transaction is news worthy or contract requires it)
      • Privacy policy will indicate disposition of personal information
      • Online agreement or terms of use may specify termination options available to user
  • Negotiation Strategy
    • Start with a considered list of what’s important AND what’s not
      • If you can recover money will that make you whole?
    • Recognize the business model of the cloud provider
      • Set reasonable expectations about the provider’s flexibility and reasonable expectations about your own
      • Assess whether the provider is really a cloud provider
    • Understand there is a trade off between dollars spent and contract protections desired
  • Negotiation Strategy
    • Limitation of Liability
      • Data Breach/Privacy
      • Compliance with laws
    • SLAs
      • What’s commercial in a non-cloud environment
      • Determine whether you need contractual terms or business-level comfort
    • Whose Problem is it?
      • Determine what is your responsibility and what’s the provider’s
  • The Take-Aways
    • Be thoughtful about which parts of your business are cloud-worthy. All business processes are not suitable.
    • Have a plan to deal with mistakes that will happen in the cloud (business, technology, legal). What level of risk can you tolerate?
    • Work with your key internal and external advisors to think through your cloud strategy. A cross-functional strategy is in order.
  • Q&A Contact Me
    • Janine Anthony Bowen, Esq.
    • [email_address]
    • http://www.visualcv.com/jdabowen
    • 404-527-4671
    • Twitter - @cloudlawyer
    © 2010 J. A. Bowen. All Rights Reserved.