Illogical Cloud Positivism
Last we learned, Peter Coffee was Director of Platform Research for salesforce.com. He also blogs on their corporate weblog, CloudBlog, a blog that promises “Insights on the Future of Cloud Computing”.
He has a post up from last week that called “Private Clouds, Flat Earths, and Unicorns” within which he tries to “bust some myths” about Cloud Security. Now most of the time, corporate blogs are almost always light on content, but at least most of the time they are banal, emasculated vagaries that can neither be too stupid nor particularly insightful. Well, not this one.
This blog post is so dangerously filled with complete and utter cowpie that I could not but respond here – it is fundamentally contrary to the concerns James Arlen and I wrote for the IRM chapter of the CSA document.
It is a completely Cloud-tarded article.
WHAT? A SAAS PROVIDER RAILING AGAINST PRIVATE CLOUDS?!?! I CAN’T BELIEVE IT!!!
First, Peter makes the assertion that when IT managers are surveyed and state a strong preference for “private clouds” and that this is a desire, not their choice, and subsequently ridicules IT managers for having that desire. His claim is that:
“To have physical possession of the data, you also have to own and maintain the data storage hardware and software.”
This is a dangerous assertion for a cloud provider to make. The semantic game he’s playing here is around the word “possession”. I’ll agree that it is impossible to have physical possession without ownership of the infrastructure. Fine. But this is NOT what security and responsibility (both ethical and legal responsibility) in cloud computing is about. Cloud Risk Management is not about possession, it is about custodianship. If I put credit card numbers in your (his) cloud, I am still, in the eyes of class action lawsuits at least, it’s custodian. Looking at all forms of loss associated with a data breach, there is no pure, 100% transfer of risk. And *this* is the problem IT managers face.
COFFEE’S NAIVE IMPACT MODELING
A desire for security (more below) operations stems solely from the fact that risk is not completely transferred. What do I mean? If my bank puts my banking data in Salesforce.com and there’s a breach, yes – I’m going to be mad at Salesforce. But I’m going to pull my money (and it’s earning potential) out of my bank because some Cloudtard over there decided that this was a good idea.
In other words (use ISO 27005, FAIR, VERIS, whatever) Primary Loss Factors are only half the impact model. And maybe the Cloud Provider owns some of that loss, maybe they don’t. Secondary Factors are still borne solely by those that use the cloud provider.
BEING GOOD AT OPSEC IS A CRITICAL COMPONENT IN RISK MANAGEMENT
“If you have operational control of the infrastructure you have to employ and supervise a “team of experts” who spend most of their time waiting to respond to critical but rare events.”
One has to but wonder how often Peter talks to his own OpSec guys. I imagine (sincerely hope) that the CIRT team at Salesforce absolutely cringed when they read this. Indeed, my sympathies go out to you, Your Supreme Galactic Director Of Platform just called you a mostly useless operating expense, and you may have a little internal selling to do.
That aside, anyone who has heard me speak for the last year knows the stress I put on understanding your OpSec capabilities as a component of managing risk. I won’t rehash those presentations (they’re online – use The Google) but both understanding the Cloud Providers capabilities and your ability to interact with them – that is the crux of managing risk in the cloud.
ILLOGICAL CLOUD POSITIVISM
“Security in cloud services can be constructed, maintained and operated at levels that are far beyond what’s cost-effective for almost any individual company or organization.”
The irony of this quote, of course, is that his linked supporting evidence is SalesForce’s statement of ISO 27001 compliance. ’nuff said.
But in regards to the actual argument, the answer is: “maybe”. If InfoSec is the study of the collision of multiple complex systems, and the cloud provider has a much more complex system to manage than you do on your own, the answer must be “maybe”. To support such a statement we must identify models that are informative about cost to secure per $. I haven’t seen much research around this, and certainly Coffee doesn’t link to any.
COMPLIANCE ISN’T A “ROLES” AUDIT
“The discipline and clarity of service invocations in true cloud environments can greatly aid the control of access, and the auditability of actions, that are dauntingly expensive and complex to achieve in traditional IT settings.”
I honestly have no idea what this means. I take it that he’s saying that proof of access control and audit evidence is easier to gain just by casually tossing an email in the direction of your SaaS buddy. But in terms of regulatory compliance (PCI DSS, HIPAA, OTHER ALPHABET SOUP) my experience is vastly different.
HEY, TECHNOLOGY IS TECHNOLOGY, RIGHT?
“Customization and integration of cloud services are neither intrinsically better nor inherently worse than the capabilities of an on-premise stack.”
This, of course, viewed in the context of the top two points Coffee makes, for the purposes of risk management, are statements with contradictory implications. Let me some up what Peter says to me when I read this article:
“The cloud is easy to use. The cloud is easier to secure. The cloud is friendly to auditors.” and “The cloud is neither better nor worse than securing data on site.”
I’M STILL OK WITH THE CLOUD
With my years of SMB F.I. audit/PenTest experience, I don’t disagree that cloud computing may make sense from a risk management standpoint. I’ve been appalled at times about the one guy in the middle of nowhere Midwest whose in charge of $200 million in credit union/pension fund assets. The other thing to remember is that in fact, in many ways these SMB FI folks have been offloading financial machinations to partners for years – they are already “cloud users” by some informal lose definition. But it’s an awfully cavalier attitude Mr. Coffee takes here with us making these assertions, esp. with no real supporting evidence. Welcome to the NewSchool, Peter Coffee. In God We Trust, everyone else brings data.
If my meaning was not clear, mea culpa. It’s my job to say what I mean to convey in a way that’s not easily misunderstood.
I have no confusion myself, and don’t mean to create it, concerning the distinction between physical possession and constructive custody of data. Salesforce.com completely understands that our tens of thousands of customer organizations retain responsibility for the data they place in our care.
My assertion is simply that it’s more cost-effective for a cloud service provider to handle the mechanics of data protection, while making full disclosure as required/desired by service consumers as to how that responsibility is being fulfilled.
As to the cost-effectiveness of keeping one’s own security team at hand, my point is that the cost of that team is being spread across a far greater number of customer organizations when that team is protecting a large-scale cloud. It’s probably also true that the team at Visa, or eBay, or Amazon.com, or salesforce.com is kept busier than the team at YourCompanyNameHere — but I don’t measure the value of a team by the number of attacks that they block, rather by the value of the services they protect against the cost of that protection. I believe this math favors security in the cloud.
I welcome vigorous discussion of these and any related points. Thanks for the chance to comment.
Peter,
Thanks for being a sport.
It may be more cost effective to outsource InfoSec to your cloud provider, I agree. But cost-effectiveness comes at a price, a price paid in the adoption of the cloud provider’s risk tolerance rather than your own. This can be a positive gain in risk reduction, a zero some gain (unlikely) or a negative one. The requirement a CISO needs is to make sure it is not a negative one (actually, the requirement the CISO needs is to make sure a negative move is in line with the data owner’s desires).
Proof of that risk tolerance alignment is in information exchange – this is what I meant when I said last year that for the CISO, the move to cloud computing is the act of gracefully giving up control. Control is ceded, but in its place must be timely, accurate information. This is something most cloud providers don’t understand, and to be frank with you, pointing to ISO 27001 certification is *exactly* the kind of stupidity that, as a CISO, I would basically expect to hear from someone who does not have a salient view of my difficult position.
Cloud service providers risk the utter destruction of all brand equity in the event of any significant breach of security. Any service provider that seeks to engage the enterprise market should therefore have even less tolerance of risk than the vast majority of enterprise CIOs are forced by limited resources to accept (even if that acceptance is only tacit).
Further, it’s in the nature of service invocation and response that every interaction is visible and formally specified: far more so than in most legacy IT environments, where any number of shortcuts and low-level hacks may have accumulated over time.
Therefore, even if one stipulates that a shift to cloud services will reduce one’s control, I assert that this shift can also elevate both performance and visibility of both security and operational assurance. As a private pilot, I know I’m giving up control when I fly by commercial air — but I also acknowledge that the people up front with the stripes on their sleeves are investing far more in training and the maintenance of their proficiency than I would ever be able to do.
Peter,
Can you give me a list of brands that have been destroyed by significant security breaches, and define your bar for “significant?”
In other words, I think your claim “Cloud service providers risk the utter destruction of all brand equity in the event of any significant breach of security” is not backed by any facts, is disjoint from experience, and you reduce your credibility by repeating it.
For you to say that my claim is “disjoint from experience” would require, it seems to me, that you cite an enterprise-oriented cloud computing service provider that *has* experienced a major security breach but has *not* suffered serious brand damage as a result. Are you able to do that?
The fact that a major cloud security breach has not yet happened is a demonstration, I would argue, that major cloud service providers are taking great pains to prevent it — unless you widen the umbrella to include, for example, credit card payment processing as a cloud service, in which case the incident of CardSystems Solutions (http://en.wikipedia.org/wiki/CardSystems_Solutions) would seem to illustrate my point.
PS to my previous: to add to the list, Heartland Payment Systems also suffered a major security breach, in 2008: the company has only just struggled back to profitability in the most recent quarter after undergoing a wrenching series of disruptions in its key card provider relationships.
ok, great, let’s talk Heartland. First, as I understand it, most of their customers didn’t leave. They did have to spend a metric boatload of money to appease other people’s brands (Visa, MC, Amex). However, I suspect that had a lot more to do with optics and “an example for the others” than any actual damage. No one’s said to me “gosh, I don’t use my credit card online after Heartland.”
I can cite thousands of major breaches which have not lead to brands being destroyed. See the datalossdb.org The vast majority have lead to little to no brand damage.
So: lots of breaches. Almost no brand destruction.
I think its on you to explain why cloud changes that.
But to date we’ve only seen one service provider out of many actually suffer that level of reputation damage. so while the risk is there, it’s not significant (probably). Furthermore, while I’m sure slaesforce takes security quite seriously, whose to say all the vendors in your technology stack do? the entanglement of multiple risk tolerances expressed as an outcome of quality creates a large, difficult to manage complex system. one constantly in collision with an intelligent, adaptive threat landscape.
stupid iPad auto-complete
@Peter –
Not to speak for Adam, but the reason we’re asking for examples is because we (this *is* the newschool blog) cannot find much evidence at all (the one you mentioned is the one I alluded to) of catastrophic impact due to security breaches. Cloud provider management may or may not be aware of these breaches and their impacts -but if they were, there would be no way to interpret one significant instance out of thousands as a significant risk. And not to be snarky (goodness knows you’ve been gracious enough), but your attitude towards CIRT teams in your original post (as CTO and all) is, well, fairly indicative.
Not that I can blame you. If I were your position, I’d probably be similarly “Security? I’m too busy scaling to be Rugged.”
Thanks Alex! That’s a great point.
Peter, I’m the co-author of a book, “The New School of Information Security.” (After which this blog is named) We call for a much more data driven approach to infosec, and the “colossal brand damage” idea is a pet peeve of mine.
Absence of evidence is not evidence of absence. It will never be my hope to see a statistically significant number of cloud security incidents. I will strive to keep these in the domain of small-sample phenomena — and to make what will probably be my final comment on this thread, I assure you that we work very hard on ruggedness, because we’re certain (with or without data) that we can’t afford not to do so.
@Peter
“Absence of evidence is not evidence of absence”
No, but only a fool ignores his prior distributions (See IJ Good on frequentists). In this case, over thousands of incidents – we have a frequency of one. This is not uninformative by any stretch of the imagination.
I walk away for a couple days and you guys get into a flamewar about my favorite topic this side of vi vs. emacs. :^)
Obviously, SF’s customers’ tolerances for risk, and the extents to which dataloss would provably harm them, are distributed somehow (I suspect those distributions are unimodal, but that’s another topic).
Any customers who care less about their data than SF does about it will be fine with SF (as long as they’re available and cheap). So, the decision for SF is how to set their own “willingness to lose data” so as to capture the profit-maximizing number of customers, given that data loss decreases with security investment, and that customer count decreases with increased cost.
I see this as strictly analogous to a hosting company deciding to offer two nines or six according to how it sees the market, and what its own cost structure is. I hope none of this is controversial.
Perhaps SF’s cost structure is such that they can profitably provide for all but the most paranoid of customers. Rather than portray this as the result of cool calculation of the profit-maximizing amount of security, they talk about how any “significant” data (read: customer) loss is unacceptable. The reason it is unacceptable is because (once existing customers revise their priors and estimate how secure SF really is) it represents a failure to capture available profit.
This flamewar is about the extent to which that revision of priors plays out. WEIS is (or was, anyway) rife with papers about such things.
Sick and tired of getting low amounts of useless traffic for your site? Well i wish to tell you about a brand new underground tactic which makes myself $900 daily on 100% AUTOPILOT. I could be here all day and going into detail but why dont you just check their site out? There is really a great video that explains everything. So if your serious about making hassle-free hard cash this is the website for you. Auto Traffic Avalanche