Privacy Weather: Cloudy with Complications
While in San Francisco for the ABA annual meeting earlier this month, I had lunch with John Tomaszewski, the General Counsel of TRUSTe. At the end of a very good conversation on privacy, security and identity, I couldn’t help but think that Cloud computing, as it actually is supposed to work, raises a lot of questions as to how custodians of personal information will be able to meet their legal obligations under existing data protection/privacy laws.
As my last blog post indicated, NIST defines Cloud computing to have five characteristics: On-demand self-service; Broad network access; Resource pooling; Rapid elasticity and Measured Service. The one that troubles me the most is “resource pooling”, which, for ease of reference, involves “different physical and virtual resources dynamically assigned and reassigned according to consumer demand”.
Keep in mind the “Cloud computing pyramid” has software at the top, platform immediately below, followed by software infrastructure and then, below that, hardware infrastructure. Each of these layers would be provided as a service to the custodian. A nice description of the layers can be found in this Silicon Whisperer post. In a true Cloud scenario, with resource pooling and rapid elasticity, the Cloud-based IT computing resources could very easily not be under the control of the same entity on a per use basis.
What do I mean by that? Imagine a series of separate but connected cubes with different colours on each side, making a stack. A colour represents an owner of the IT resource being used. Imagine tens, hundreds, thousands of different colours. Now imagine spinning the stack of cubes. When they stop, the odds are very good that the colour of the sides facing the user will all be different. Now consider that each spin is a transaction by a custodian of personal data that represents the use of an application and involves personal information. Each transaction has different service providers assist in the processing of the information. And these service providers can change with every transaction.
How could this be? You now have to keep in mind that Cloud computing, in a true Cloud, means reducing IT to a utility business model. That involves different players providing resources when required. That doesn’t mean one provider simply calling up more internal resources to service the custodian’s business requirements or, perhaps, using one or two key sub-contractors. (That’s not Cloud computing; that’s outsourcing to a managed host – and there is a significant difference between the two). The result is a contractor using sub-contractors as required. As you deal with different applications, through one or more portals, the database, network and actual processing would likely involve different subcontractors. Why would a Cloud service provider have an enormous amount of internal capacity that it may not use? If it needs capacity it would draw it from a sub-contractor on a “pay-per-use” basis. In a true Cloud environment, the same logic that drives custodians to externalize their IT inevitably will drive Cloud providers to do the same.
The privacy implications of this are significant. Since a custodian has “accountability” obligations under data protection laws (in Canada and elsewhere where such laws are based on fair information principles), one usually sees an obligation in master service agreements that have contractors impose privacy and security obligations on sub-contractors. Lawyers will say make sure agreements are in place for all parties involved in the processing. Seems simply a paper exercise but in auditing or enforcing those obligations (whether or not there is a data breach) you now have the potential for a dazzling array of different data elements, sub-contractors, and jurisdictions. How do you really ensure accountability and safeguards in such an environment?
How can any government sensitive to the location of citizen data use a true Cloud-based service provider? How can custodians even use the Cloud if data from Europeans is being processed? Some providers such as Amazon can now limit the processing of data to specific regions but will that be the norm?
Even if you could manage this by contract, how do you explain this to the individuals whose personal information is being processed in any meaningful way? Is putting in a privacy statement “your personal information may be processed outside of your country of residency” enough? If you can’t have an informed consent, can you really say you have consent? In this context, the concepts of “onward transfer” and “consent” seem to invoke the need for a “re-think” of what privacy requirements we really want to impose.
It is very early days for “Cloud computing” and a lot of it today is simply outsourcing to a one or more service providers who have dressed the service offering up in the Cloud “hype” that is out there. One can’t help but wonder if this is the real direction of information technology or just another fad – one Cloud concept or another has been around for since the turn of the century. (Sun coined the phrase “the network is the computer” a decade ago.) So whether the world ever moves to true Cloud computing is certainly open to debate (and custodians may never want to give up total management of IT resources).
I don’t wish to come across as unduly negative about Cloud computing. The question for me is not the technology but whether our laws concerning data protection – even written broadly as principles – are sufficient to address utility-based processing of personal information.
The Office of the Privacy Commissioner of Canada, Jennifer Stoddard, held a public consultation in Calgary in June to raise awareness about privacy/Cloud computing issues and has posted links to written submissions here. It will be interesting to see the results of those consultations but if anything causes us to re-examine what privacy laws should look like in the 21st century, the impetus may very well be the operational implications of Cloud computing.
Let’s say I am offering an on-line service and make use of cloud services for computing and storage resources in delivering this service. In order to meet my obligations to my clients, I am going to choose my service providers carefully and have service level agreements in place with these providers. If the location of my customer’s data is of importance to them (e.g. must remain in the same country) then I am going to contract with service providers who can address this requirement.
Amazon’s S3 storage service, for example, lets customers specify the region in which data is stored. They still operate multiple facilities in the region for redundancy and still allow me to scale my storage requirements on an as-required basis (storage on demand). I have no control over which storage device is used or even whether different storage devices are used at different times. I do have control, however, over the region in which data is stored.
I am not a lawyer (nor do I play one on TV) but it is not clear to me whether legislative changes are needed to deal with cloud computing. Careful attention will need to be paid to the terms of the service level agreements and the “resource pooling” characteristic of cloud computing will need to be carefully considered.
Michael Martineau
eHealthMusings.ca
Alas the shorthand “cloud computing” strikes again. The cloud computing shorthand actually refers to a very wide variety of services provided in a number of different ways. We can only discuss the challenges and considerations for businesses by getting very specific about what services are being leveraged in what way for what data.
I often describe the challenge using the meteorological clouds which we are more familiar with. If I were to say to you, “Don’t go outside if there are clouds”, you would clearly think I was nuts. The clouds could be cirrus clouds (high and wispy), stratus clouds (low blanket like grey clouds), nimbus clouds (rain clouds), cumulonimbus (thunderstorm clouds) or even funnel clouds (tornados). For the everyday person, some clouds don’t require any additional actions be taken, some require modest safeguards e.g. umbrella and others more significant safeguards (take cover!). For pilots there are other considerations such as alternative airports, instrument flight rules etc. For truck drivers there are considerations like fog lights, wipers. For meteorologists etc.
As we help businesses embark on service transformation through the use of cloud computing technologies, let’s get more specific so that we can define the right risks and the right safeguards for their specific services.
John, I couldn’t agree with you more! Cloud computing is a rather general term that is misused and dare I say abused by many because it is trendy. In my view, cloud computing is about replacing local resources (software, storage, etc) with services accessed over the Internet (e.g Software as a Service, Amazon S3 storage, etc).
Michael raises some very good points regarding the need to consider how the data that may no longer resides on computers under the users control is handled. What happens if the company from whom you are buying a service goes out of business? Can the data be viewed by others without your knowledge or consent?
I believe that companies offering cloud computing services will need to address privacy issues because their customers will demand it. I contend that is exactly the reason why Amazon allows clients to specify the “region” in which data will be stored.
Mike
John and Michael’s comments note that people really don’t understand what the “cloud” means. A very valid point. The post isn’t so much about what the cloud is (or is not). When you have a distributed model of computing with the different levels (SaaS, PaaS, IaaS); the different ownership of those resources and the potential for a large number of different owners given outsourcing then that the contract model we’ve come to rely upon may not really work. So “contractual assurances” for accountability may be meaningless in practice. At that point our privacy laws and how custodians remain accountable needs to be reconsidered.
I ran into a similar problem years ago. In the early 1990’s I was on the board of directors for CA*net, Canada’s first Internet backbone. We had designed a redundant ring network across Canada and had carefully chosen alternate suppliers for specific legs of the network so that if one leg was disrupted the network could route around the problem.
Unfortunately, unknown to us, one of the suppliers with whom we were dealing subcontracted to another supplier with whom we are dealing in Atlantic Canada. One day, a backhoe sliced through a fibre optic cable in New Brunswick and all of Atlantic Canada was off the Internet. Why? Because the two network links that we had carefully ensured were from different suppliers were actually both in the same fibre optic bundle! Supplier B had actually purchased services from Supplier A and was simply reselling them to us. Purchasing services from two different suppliers did not end up providing the redundancy that we thought that it would!
Mike