Photo courtesy of @psd. Paul, I owe you one.
There was a time when the “high street” bank was a disconnected silo, an island of tranquillity. Except when it came to a busy afternoon and you wanted to withdraw money. Your money. Because the only place you could withdraw it from was the branch with which you held your account. If you weren’t near it, tough. If it was too busy to serve you, tough.
There was a time when the only way you could draw money from a hole in the wall was to use your bank’s ATM network. It was private. Disconnected from all other bank networks. So if you weren’t near an ATM belonging to the bank you banked with, tough.
There was a time when you could only use the cards you had in the country you lived in. If you had to travel anywhere else, tough. Try cash or travellers’ cheques.
There was a time when there were no guarantees for what happened if someone impersonated you, if your cards were stolen, or, for that matter, your bank had a problem. No guarantee schemes. No nothing.
Thankfully, we’ve moved on from those times. Today we can choose who to bank with, draw money from any branch, any ATM, anywhere, anytime. Securely, efficiently, conveniently. Underpinned by the trust that comes from feeling secure, having guarantees.
And because of all this, we trust our banks with some of our most precious assets. The financial system has had its problems (which system hasn’t?). But people continue to use banks rather than revert to paper money and metal hidden under mattresses.
So it is with the cloud. Your data is a precious asset. Which means that you really have to think about where you keep it, whom you trust to look after it.
The “bank” where you keep your data must use a network that provides you access anywhere in the world; it must support a large variety of “data ATMs”, your mobile devices. It must provide you access swiftly and securely. It must have transparent pricing and charging. If there are legal reasons why someone else seeks to look into your “account” it must tell you about it.
The cloud, like the banking system, like any truly global system, is about openness and standards and transparency and trust and guarantees.
Which is why I’m delighted with what my employer Salesforce is doing, in putting forward a series of “cloud principles”, principles we work by, principles we seek to adhere to. This is something the company has been working on for a while now. Incidentally, where relevant, my posts also appear on cloudblog.salesforce.com.
Here they are, ten guiding principles, in draft form:
- Transparency: Companies that provide enterprise cloud computing platforms should explain their information handling practices and disclose the performance and reliability of their services on their public Web sites.
- Use Limitation: Companies that provide enterprise cloud computing platforms should claim no ownership rights in customer data and should use customer data only as their customers instruct them, or to fulfil their contractual or legal obligations.
- Disclosure: Companies that provide enterprise cloud computing platforms should disclose customer data only if required to do so by the customer or by law, and should provide affected customers prior notice of any legally compelled disclosure to the extent permissible by law.
- Security Management System: Companies that provide enterprise cloud computing platforms should maintain a robust security management system that is based on an internationally accepted security framework (such as ISO 27002) to protect customer data.
- Customer Security Features: Companies that provide enterprise cloud computing platforms should provide their customers with a selection of security features to implement in their usage of the cloud computing services.
- Data Location: Companies that provide enterprise cloud computing platforms should make available to their customers a list of countries in which their customer data related to them is hosted.
- Breach Notification: Companies that provide enterprise cloud computing platforms should notify customers of known security breaches that affect the confidentiality or integrity of their customer data promptly.
- Audit: Companies that provide enterprise cloud computing platforms should use third-party auditors to ensure compliance with their security management system and with these principles.
- Data Portability: Companies that provide enterprise cloud computing platforms should make available to customers their respective customer data in an industry-standard, downloadable format.
- Accountability: Companies that provide enterprise cloud computing platforms should work with their customers to designate appropriate roles for privacy and security accountability.
As I said, these are in draft form right now. Comments welcome. Our intention is to publish them in a more accessible form soon, and to make it possible for you to participate more fully in shaping them and improving them. Watch this space for details.
Hi JP,
As usual u have nailed it on its head. You have indirectly pointed out a few things which are key to getting cloud working as true “cloud” sense. As an end user u could ignore what flavor of cloud the applications are running. Now about a few points which I have had first hand experience as security architect for a platform on the cloud (with my previous employer) which used multiple cloud providers including Salesforce, I really appreciate your comments on transparency, security managment , Audit , Breach notification and Accountability. But I am afraid I havent seen any cloud service providers providing these 6 months back . I beleive one of the things that is missing is the fact that SLA’s dont reflect any of the above attributes and the ability of customer to monitor a large set of these criteria is very limited.
BTW “use limitation” implies tying together data to policies, it is very hard to achieve ;) my two pence.
Two quick points about disclosure:
(1) You might want to make it clear if there is a difference between customer data and a customer’s data. In other words, will you disclose data about a customer (IP addresses, financials, etc.) under circumstances where you wouldn’t give access to the data the customer had chosen to store in your systems.
(2) There is often some discretion in what constitutes a legal requirement. Some UK ISPs have said they would challenge in court any attempt under the Digital Economy Act to compel them to hand over details of their customer’s internet usage. Another UK telco, on the other hand, has a policy of allowing wiretaps on the say-so of a relatively junior police officer when it could insist on a court order. It might help to be clear about the extent to which Salesforce would resist “legally compelled disclosure”.
HTH
@anish @dom thanks. good points, the whole reason for putting this forward in this shape was to figure out how to make the principles better. keep the comments coming.
Hi JP, I found the post very helpful in helping me order my thinking about the cloud – 1) transparency 2) integrity 3) authority 4) security 5) utility 6) availability 7) stability 8) clarity 9) portability & 10) accountability
Excellent framework JP. Two areas of potential clarification occur to me on first reading.
In terms of disclosure, I wonder if there should be an obligation on cloud service providers to inform/educate users in what circumstances they might be required by law to disclose their customers’ data.
In respect of the audit principle, might there be an argument for specifying what sort of penalties might be incurred if the auditors find shortcomings?
JP – taking your example, I would argue that the banking system differs from the cloud in that it doesn’t need to be “always on” – the cash in your wallet works even when the system is not around.
Ditto the Cloud. It needs to have the ability to allow continual operation of systems when they are not connected. Having worked with Clouds (and ASPS, Web Hosting Systems, Grids etc etc) over 15 odd years the 2 things I know for sure are that:
– Getting “5 Nines” reliability is bl**dy hard in real time networked services, and even “5 nines” means dropping the ball a few times a year.
– Murphy’s Law predicts that the f*ck-up will occur at the least good time, in the worst place.
Thus, I would add the Principle of Resilience, (or whatever word works best) that ensures that the system can be run for a period of time for core services while disconnected.
I am not sure whether this is already covered or is it of the same stature. But I feel openness of Access control is something is important. The wording could be something like:
Access control: Companies that provide enterprise cloud computing platforms should allow access to people who may not have credentials issued by the provider.
To be more specific, I am thinking of use of OpenID/OAuth for authenticating “external” users before they are given access to the data they are entitled to. This will facilitate federation between two customers who may use platforms from different companies.
JP – my response is on the blog: http://achur.ch/gzmVNZ … got a bit long :)
Excellent points and well overdue. Too many immature cloud service providers ignore the importance of the 3rd Party Audit assurance to a corporate customer. Just within the last year, one widely used provider answered the question: “What assurance can you give that my data is secure?” by saying “If your data ever got out, we would surely be out of business”. Not the answer I was looking to hear.
Hi JP, 2 short points from my days in Corporate IT Innovation ;-)
1 – Financial transparency and disclosures: I would add this item, as too many times, especially for smallish and growth companies, the main risk is actually non-orderly bankruptcy, or change of ownership impacting the commercial relationship on strategic levels. Even for companies like Salesforce, I believe a greater amount of financial and accounting disclosure would be needed, something that can be done under NDA for large clients only if that’s required.
2 – “Disclosure: […] should provide affected customers prior notice of any legally compelled disclosure to the extent permissible by law.“ Here I would of course love to see that the cloud services provider will pursue all legal means to obtain the right to disclose any law enforcement request, even if not permitted at first; ie, act as Twitter in the recent wikileaks subpoenas, not comply to a sealed request unless all avenues to unseal it have been exhausted.
These are my 2 cents, and thanks for your insightful posts as always ;-)
@John both clarifications make sense, but I don’t know how easy they are to achieve. Let’s see what the rest of the comments say, we can review again
@Alan the resilience principle makes sense as well, though it will have to be bounded and shaped for any one organisation to be able to commit to it.
@swath committing to the use of third party credentials is an interesting one. Why do you feel so strongly about it? Or is the issue to do with “standard” credentials?
@ric wow I need to digest that and reply later, thanks.
@Jim :-) I have seen something similar
@Julian again this makes sense, but the devil is in the details. I am keen to keep the principles as simple as possible
Keep the comments coming
JP, great post and a lot of good points about cloud. I must admit as an RSA / EMC employee, the topic you raise is somewhat close to my heart.
One thing I am always conscious of is that for many existing companies the adoption of cloud services / platform / infrastructure is not an overnight transformation. Getting to the cloud and a place where the principles you listed are all in effect will be a journey. A journey of discovery for most, but also a journey of innovation for many.
I did like your bank analogy, if only cloud service providers (in various guises and contexts) had a “switching” service like many banks do, how simple life could become in adopting cloud.
@JP
Granted, the fin. disclosure may be too much for your set of principles.
BUT the addition to the disclosure point can be worked in without really adding complexity. In my view, it would make it credible. Right now, when reading it, I can’t shake the inference: “to the extent permissible by law” means every sealed requests will be complied with diligently by my provider without me being aware of it.
A proposed phrasing (just so that I can feel I’m not just providing negative comments ;-) ):
Disclosure: Companies that provide enterprise cloud computing platforms should disclose customer data only if required to do so by the customer or by law, and should provide affected customers prior notice of any legally compelled disclosure except if such right has been denied by all legal authorities able to grant it.
Good start to building the set of principles, JP. And pretty much in agreement with what I have been saying (including at the Summer Davos in Tianjin last year). Two points I would like to put forward (but whether they are/should be part of the “principles” is open to discussion): first is the issue of system availability (and related to that availability from geographically dispersed locations in the case of a multi-national using the service) – system availability is a key component to user confidence in the cloud, the second is the notion of inter-cloud computing – can your cloud talk to another cloud service and exchange information, where the second cloud service may be a different vendor but serving the same customer as the first. Once we sort out and standardise the norms for inter-cloud data exchange, I think we are heading for even more interesting times.
JP,
I think regulatory shopping will be at least as important with where we put our data as it has been with where we put our money.
This means that you need to go further with ‘data location’ – the customer doesn’t just want to know where their data might land, you need to empower them to specify where it will be held (assuming that there is some array of choices). This has clear links back to ‘disclosure’, particularly when the conversation turns to ‘permissible by law’ and what that means in practice (e.g. US national security letters [NSLs]) – the customer needs to have choice over which legal framework(s) apply to their data.
I would say that audit could go further too. Don’t just allow 3rd parties in – provide the API so that customers can audit what you’re doing with their data themselves. This is what CloudAudit (http://cloudaudit.org/) is all about, and it would be great to see Salesforce getting involved in that initiative. ‘Trust and verify’ is a common cry of infosec experts – why not make ‘verify’ just another part of the service?
It is not because of standard, but what that standard entails is very amenable to cloud based service: As a customer of a cloud service, I could provide access to you, my cloud provider does not have to have any prior relationship with your id provider to enforce the accessibility rules. Furthermore, your access privilege is determined in a “cloudy” fashion by your status with your Id provider (your employer for example).
The standardized procedure is very amenable to cloud based services. This is the reason for my strong advocacy of OpenID/OAuth.
One aspect to add to the Data Portability principle. I should be able to make a clean exit; as well as gettinga copy of all my instance data I should be able to delete all of it AND if required all of my meta data (name, company, etc)
A more tricky problem involves anonymous activity. Mosts service companies think nothing of amalgamating anonymized data for promotional reasons. For instance, how many companies use their service, and how much data is being transmitted per hour.
For most clients, this is no issue. But some companies will correctly worry that this can be a security peep hole. If I see that your service is suddenly handling more data, I can correlate this with a new customer who I believe might have joined. Then I can make further assumptions about that company. Possibly they are starting a new campaign?
To avoid this, a company must be able to ask for exclusion from promotional statistics. But I can still imagine that a lot of potential clients will be worried about “Enigma” type inferences that can be deduced from noisy service companies.
The analogy to banking is spot-on, but cloud providers might not want to be regulated the way banks are. I wonder if one day we’ll have “deposit insurance” for cloud data and applications?
Also like banks, the cloud-computing industry has a principal/agent problem: that is, my “agent” (the cloud provider) and I suffer very different outcomes if my data is lost or my privacy is violated. The provider merely loses a customer, whereas I have potentially lost everything. This principal/agent dilemma is why we have industries like bond rating agencies, as well as state regulation of banks and insurance companies.
JP,
Love the principles and reflect very well the concerns and requirement we start to have on cloud service providers.
On data location not only the list of countries should be provided but mechanism should be provided to either implicitity of explicitily geo-distribute the data and a clear differentiation should be made between master data and cached data.
right to opt out: data analytics is crucial for cloud services providers but it should be possible as a customer to opt out on any analytics generated either on the data or even on the usage of the data. This should also include what France calls “le droit a l’oubli” which I should be able to select on any data: direct or inferred…
And like other people who gave comments, I am very much in support of openid/oauth support by the cloud service provider.
@richard yes, portability and interoperability will become more and more important. agree with the journey bit, but we need to be careful about the time taken. firms have to keep pace with their competition, if the competition moves faster on to cloud and gets the lower operating costs and faster time to market, you’re dead.
@julien, some of the conversations I’m having suggest something even further, that there is a duty of care on behalf of the customer to resist legal disclosure rather than just roll over; this is above and beyond the “keep the customer informed” aspect
@rajnesh transparent publishing of systems availability is an absolute must. the inter-cloud aspects will happen (as long as we are only talking public cloud, there is no other cloud in practice, just marketing) but it will take time to get the inter-cloud service implications and guarantees right
@chris where, for regulatory purposes or for low latency a specific geography is mandated, location may need to be customer-specified; but it cannot be the norm otherwise we are throwing away the economic value of multitenant. I am foreseeing a different model, where the customer indicates where he does •not• want the data to be held, leaving providers to select beyond the constraint. I will take a look at cloudaudit, thanks
@aswath fair point, I will bring it into our discussions here
@davide the eject button will evolve over time. phase 1: you can take it with you. phase 2: and leave no trace behind. phase 3: parcelled for re-entry anywhere
this false anonymisation issue is known for some time, and is not really a function of cloud. it is a function of anonymisation design weaknesses. in the old days HR departments needed to be careful not to create cost or profit centres with just one or two people, because salaries could be deduced quite easily from the summary data. the answer was to understand the granularity of the data and ensure that the bucket size of anonymised aggregates was suitable.
@tom the principal-agent problem is exacerbated in situations where the only asset is data, so we need to extend the asset base into processes and on to apps and beyond. when principal and agent start sharing up the stack we can reduce the asymmetry. need to think about how best to design this.
@michel thanks, the issues on distribution of data as well as federation of access tools need to be worked on as you say
JP @davide: If clean erase is postponed to Phase 2, then care must be taken that the data architecture doesn’t foreclose that option. For example Facebook has stated that it can not guarantee that a picture is totally removed because they themselves do not know where else that picture is stored.
Great blog post, I like the ATM analogy and I think the 10 principles can help highlight “False Cloud” which I see more and more.
The Data Location principle could be extended to providing a choice of where the customer data is stored which is often an issue or barrier for adoption when customer data has to be stored in a particular geographic location for local regulatory requirements.
Also a principle on collaboration would be interesting as more and more customer move to the cloud the requirement to share selected data with each other in various applications on cloud computing platforms would be needed.
JP,
There should probably be 3 choices for location:
1. My data must be kept here (e.g. Switzerland, for regulatory purposes).
2. My data must not be kept there (e.g. US because I fear NSLs).
3. I don’t care where my data is kept.
Clearly there would be premiums associated with 1&2 that would offset any difficulties with capacity management for multi tenancy (which shouldn’t be THAT hard, but Salesforce is perhaps an extreme case of what can be accomplished in this area).
Just as with banking I’d expect that some locations/regulatory regimes would be more popular than others, which would also ease the multitenant problem.
Do you have any feel for the minimum size of a multitenant infrastructure, and the customer base that would be needed to make it viable?
Obviously the don’t cares provide some flexibility for load balancing, but that may not be all that dynamic (given large data sets relative to small bandwidth). There will also be softer versions of option 1 (e.g. my data must stay in the EU).
Something else to bear in mind here is public sector (Gcloud) initiatives. They pretty much all want to be option 1, but services built for .gov users could be scaled out to suit the needs of commercial users in the same locale.
For anybody else who doesn’t immediately know what an NSL is, here’s what I managed to find: http://en.wikipedia.org/wiki/National_Security_Letter
Is this right, Chris? Or did you mean National Skydiving League?
For some organizations in the FS industry, they will want to know what USA state their data is held in. This is particulalry important if there is even the remotest possibility of litigation, whereby the litigator attempts to go directly to Salesforce to obtain the data.
JP,
Clearly very welcome, and not just as contractual assurances, but in establishing a trust between the cloud services provider and its customers that transcends the specifics of terms and conditions.
Although legal commitments and their minutiae that protect both salesforce and its customers are important, more important will be a recognition by us customers that at the helm of the company, and permeated in its rank and file there is a recognition of those values and principles that guide specific policy. (As a side note, but maybe ever so slightly relevant to this topic of trust and dialogue, the 40 odd comments on confusedofcalcutta and their quality contrasts with the two on cloudblog of the same entry. Maybe its just traffic, or maybe worthwhile to contrast the “here’s a daft – need feedback – genuinely listening” tone of this post with others on cloudblog. I hope I’m not getting you or me into too much trouble :) )
But back to your principles.
One theme that stood out for me across them is the proactive stance that several of them imply. A proactive stance that goes beyond the minimum that is legally mandated. Maybe that translates back into company’s committed full time resources and even right up to a senior executive officer in the firm whose day job is to excel and improve on the implementation of these principles. That’s probably covered in your Accountability principle. And it looks like several comments are requesting a stronger wording of that proactive stance in the principles as you’ve stated them – Chris S. on providings APIs for customers to audit themselves, Julien on stiff resistance to disclosure requests, etc.
Frankly, I think its hard to enhance your proposed set, but the one thing I wanted to put my weight behind was what Rajnesh also picked up on: inter-operability, not just availability of APIs which a cloud provider has to provide anyways to link back with enterprise applications, but as a principle that no barriers will be erected on customers being able to procure, let’s say, cloud infrastructure from Amazon and link it with Sales Cloud. It is after all the strongest point in your bank analogy – the inter-operability of ATMs across banks and countries, but it doesn’t find expression in the principles. Especially in an industry where the major players are renowned for their constant desire to create lock-in, or unfair competitive advantage, this would be a good addition.
A comment on the phasing response (“the eject button will evolve …”), I am assuming you are not proposing that only those things can be included in the principles that are already implemented today – but this is a set of principles that govern direction, maybe mapping to a maturity model against which to report compliance.
Again, very welcome! Thanks.
Fair point. Something we all have to work on. Nobody can guarantee things that are technically impossible. But we can design things in such a way that there are fewer such problems
You’re right, Sandeep. Ecosystems will develop with common principles allowing data sharing between apps from different sources. Already happening
@jonathan one of the earlier comments asked for three choices: (a) must be in jurisdiction x (b) must not be in jurisdiction y and (c) don’t care. there are some european companies who want none of their data in the US. we will see this whole thing evolve; not sure it will go in a good direction. data-driven protectionism is already showing its ugly face.