Skip to content

Sorting out "cloud security"

Found this is the Palazzo elevators

Security is sort of a nonstarter. You can build a cloud to be as secure as you want, doesn’t matter what techniques you use. I just pretty much ignore that. Randy Bias

Recently, I’ve been trying to hone in on what people mean when they talk about “cloud security.” More specifically, why the lack of cloud security is causing problems with (mostly public) cloud adoption. As with most questions about security, answers are hard to find. They usually revolve around the dreaded, “well, it all depends”…which just begs the question of what those “depends” are.

I don’t have the answers, and despite having helped start one of the early online banking startups, I’m not a security expert. Nonetheless, here are common sentiments and topics I’ve come up against, along with some more nuanced discussion, many of which overlap if you pay close enough attention:

“I don’t know where my data is”

This has more to do with what jurisdiction your data is in (see the next point) than not knowing where it is. By “definition,” if you can use your data, you know where it is: otherwise you wouldn’t be able to retrieve it to use it. The cloud knows where your data is at any given time precisely – and that’s what the real problem is: a government might use that knowledge to take and then expose your data.

There may be regulation and governance that requires you to account for the physical location of you data at any given time (see below). Of course, this all gets sticky (or maybe not – I don’t know the law when it comes to this stuff) with CDN and other edge caches – and there’s always those damned mobile employees with their smart phones, laptops, and unencrypted tape back-ups left on the back-seat.

Fear of Subpoena

“But there’s another concern,” parried Apik. “Isn’t it true that, as a result of the USA PATRIOT Act, the Canadian government instructed departments not to use computers operating within US borders, because it had concerns about the confidentiality and privacy of Canadian data stored on those computers?” –From Security and Resilience in Governmental Clouds

If you’re in the EU (or any non-US state), you fear the PATROIT act. If you’re a Yankee, you fear the EU and it’s privacy and data laws. In both cases, you fear your data being stored on disk in some jurisdiction that will subpoena your data and then make it part of public record (or otherwise “violate” the secretness of your data). It’s not that some hacker will illegally acquire your data, it’s that a government will do it in a highly legal way, causing all sorts of problems.

One person reminded me of the story of a man who’d murdered his wife and otherwise looked innocent (along the lines of India’s “The Google Murder,” if not that story). With two subpoenas – one to get his list of IP addresses through his provider, and another to Google to find all searches that IP address had done – the government tracked down his extensive research into how to cover up a killing. You can imagine similar cases with corporate crime, esp. if hosted email, document storage, and other collaborative applications and data are involved.

The question here becomes what governments you trust and how much your business depends on not complying with judge’s requests, and the law, really. If you do a lot of shredding in your business, then you should be afraid – you need to make sure your “cloud data” gets shredded before it gets exposed.

I’m not condoning breaking the law, but clearly skating along the edges of illegal, unethical, and “pushing the boundaries” happens as part of many companies daily business. In the tech world, for example, if you don’t have the US Justice Department continually knocking on your door to see if you’re being too monopolistic (that is, grabbing too much of the market) you’re probably not pursing as much money as you could be.

Whether or not you’re breaking the law can be largely irrelevant as what you really fear, what the real risk is: exposing secrets that your partners and customers would find repulsive. Think about Wikileaks for corporations: how would the market react if they really knew what you thought about customers, investors, and all those other “idiots” who won’t just shut-up and pay you already.

Pricing is a good example. Good profit margins typically require information asymmetry when it comes to pricing: the most profitable buyers are the ones who don’t know what they should be paying and, thus, pay too much. So if some subpoena exposed pricing info (more than likely because of a completely unrelated matter, that asymmetry would be nicely screwed. There’s nothing specifically “cloud” about this example or most others: it just illustrates what companies (should) worry about

If your data gets subpoenaed, it’s out in public. There’s no chance to spend weeks hunting down where those email and document archives are and then conveniently not find them after your data center gets flooded or whatever. Catching Bradley Manning is useless once all those cables are leaked (at least with respect to the past).

Your application is not secure

[T]here are a lot of people who start and go, oh, I am going to make a website, it’s going to swap MySQL up there. I am going to build all this junk, and then at the end, right before I launch, I am going to make it secure.

But the problem with that is, by that time you are screwed, because to do it secure, means that it actually really reflects a lot of your technology choices.

David Barrett,

You’ve been working on an app behind the firewall, and not had to actually make the application secure enough to run on the public Internet. Once you move it to the cloud, there’s little when it comes to firewall to protect you. You have to start thinking about security and writing your application appropriately.

I suspect this is the one of the real problems with “cloud security”: calling in the technical debt you’ve accumulated under the security column over the years. Folks like CohesiveFT would suggest that they have solutions for this – hopefully they and others do.

Regulations and Compliance

For whatever reason, the compliance you need to follow does not allow for cloud architectures and topologies. It could be something as simple as “you must own the hardware.” PCI is an oft cited one, and my discussion with Expensify’s David Barrett provides one discussion of how common cloud offering didn’t seem to cut it. It’s too long to simply quote here but it boils down to:

  1. Requiring two people with separate keys to do major tasks – “Split Knowledge, Dual Control Key that ruins auto-booting of servers
  2. Networked transactions – “if you are moving like a $10,000 expense report, and your server crashes halfway through, like you want to know, like did that money move or not?”
  3. The need for redundant datacenters for your (not a type) redundants datacenters – “you have to have at least three real-time synchronized data centers, to do real financial activity, in a way that’s actually sort of reliable and secure”)
  4. a whole bunch of other considerations

Most of these, you’ll notice, are not really “security” related, but these items come up in “cloud security” conversations because of their relation to PCI.

Larry Carvalho points out another example:

Regulations force telecom providers in several countries to keep all their data on call records in the home country. If a public cloud provider cannot provide that guarantee, it is one thing that will immediately disqualify a public cloud as a solution.

The point isn’t that “The Cloud” can’t comply with these regulations, it’s that you have to make sure they do…if you care about them.

Who’s responsible when things “go wrong”?

When errors and problems occur, folks have told me they’re uncertain if the cloud provider is responsible, if they are, if the network connection is at fault, if the user is: who gets pinned with the blame, and, we’d assume, the responsibility to fix the problem?

This is the one that flumoxes me the most because I tend to feel that when things go wrong, everyone is responsible. (That’s not realistic, of course.) Also, this seems like another way of saying that some cloud’s customer service and “enterprise relationship management” is bad.

“Accountability” feels like what people are trying to hunt down and most people are unsure about what various cloud offerings have to offer. IBM’s Steve Mills recently suggested that, as an example of good, enterprise customer service, IBM knew when to genuflect as needed in front of the customer. Others have snarked that part of the implicit role of big IT vendors is to “fall on their sword for you” when things go pear-shaped. All of that revolved around saving someone’s job, not really solving the problem – but often, keeping that pay-check coming every month is the only SLA that matters in The Enterprise.

Here, a large part seems to rest on trust. Do you, the consumer of cloud services, trust that the provider is not only secure but will “do the right thing” when problem occur? Traditional enterprise vendors have had decades to prove (or not!) that trust and have established relationships with customers to create that trust. New, cloud providers often don’t have that luxury.

There is little risk/benefit analysis available

The best way to secure an application is to delete it and it’s data. Just wipe it off the face of the earth and there’s no way it can be hacked. Of course, that’s not reasonable: security is irrelevant if you have no customers!

At some point, you weigh the risks (including security) of letting the application loose into the wild against the benefits (usually money) it will get you. You do risk/benefit analysis and at some point when the benefits out-weigh the risks enough, you’re “secure enough” to release the application.

Think about e-commerce, online banking, PayPal, online gambling – all of these are (to retro-actively apply the term) cloud-based applications that could go seriously wrong (loose lots of money) if compromised…and yet they can be seriously profitable if they work.

These might take the form of SWOT or other analysis that go over worst and best case scenarios when it comes to security and business benefit. There’s even less “standardized security processes for the cloud” available. Several enterprise architects trying to sort out cloud security have told me that they can’t find a risk/benefit analysis, well, “template” for the cloud space. (See this EU report on cloud security for more discussion on this topic.)

Cloud security is not much different than plain old security

The end result of all my scouting around for what “cloud security” means leads me to one conclusion: it mostly means the same thing as plain, old security. That is, the same general practices and thinking that lead to secure applications can guide you to get security in the cloud (these are just a few):

  1. Your applications are going to be insecure if you don’t spend a lot of time securing them.
  2. You want your providers to follow secure practices and keep their systems patched and up-to-date.
  3. There’s always going to be some paper-work (some helpful, some not) that you have to comply to.
  4. Much of your security work will be counter-measures and hunting down bad agents. Technology is often used more as a tool than then as “the solution.” See these examples from Jeff Jonas for some fascinating Las Vegas “hacks.”
  5. You need to balance all of this effort, and possible disasters that can occur, against the possible up-side of the application you’re sticking on the cloud.

What people fear is The Fear of the New – The Unknown. They think something about cloud computing is wildly different – more than likely, it’s about exposing your technical debt in security, your current weaknesses, not introducing new problems.

Background and more

Categories: Cloud, Enterprise Software, Systems Management.

Tags: , , , , , ,

Comment Feed

8 Responses

  1. Michael – great write-up!
    I think the subpoenas issue is a bit different to what you describe.

    Firstly, the Patriot Act / Canada question is mostly a canard. The Patriot Act applies just as much for Canada-stored data as it does for data stored in the U.S. Unless you – and your cloud provider – can completely avoid U.S. jurisdiction, which is hard-to-impossible in Canada, your data can be subpoenaed from a Canadian data center by the U.S. government. There are some subtleties even beyond this – including questions of government as opposed to private/comercial data – but in general being outside-the-U.S., but in a developed country allied with the U.S., doesn't help (much).

    Secondly, the real difference between cloud and non-cloud data storage and subpoenas is that cloud storage enable "blind" subpoenas – your data can be subpoenaed from your cloud provider without you knowing. This can happen somewhat even with on-premise data centers, in that subpoenas can be applied to your Internet service provider for data-in-motion "wire taps"; but additionally an in-cloud provider can be obligated to deliver stored data – "data at rest" – without you knowing, preventing you preparing a defense, launching an internal investigation, or taking whatever other action you might take in response to receiving the subpoena yourself.

    The only "solution" to the blind subpoena problem would seem to be for you to encrypt your cloud data and hold the key yourself; the government would then have to subpoena you for the key, or apply very large-scale compute capacity to break your encryption, which is rarely practical except for major crime / major threat investigations.

    However, for many SaaS services customer-holds-the-key models are impossible today. It's almost like a whole new piece of SaaS infrastructure would need to be invented (an idea for ?).

    Customer-holds-the-key would also protect against abuse by service-provider staff, of course, in addition to protecting against blind-subpoenas.

    dgreatwoodApril 20, 2011 @ 12:54 pm
  2. Great article. At LASCON 2010 I did a presentation on "Why The Cloud Is More Secure Than Your Existing Systems." In many cases, fears about security in the cloud are driven more by an illusion of control and inflated assumptions about the level of security one's data is currently enjoying.

    Encrypting data at rest is good (mitigates some insider concerns and some sweeping-discovery concerns), but funnily enough we were just discussing customer-holds-the-key schemes over here today and the problem with it is that often it sharply inhibits your ability as a provider to provide functionality. If I have a service and you are storing your data on it and you encrypt it, I can't search index it, perform offline analysis on it, do differential transfers with it, check it for compatibility with upgrades, or do most of the interesting things that makes my service not just a glorified DropBox. MessageOne, for example, offered customer-holds-the-key encryption and then decided it sucked so much that they stopped selling it and tried to get people to migrate off. It is optimal from a security point of view (till the customer loses their key and gets pissed) but has a number of extremely undesirable side effects.

    ernestmApril 20, 2011 @ 3:56 pm
  3. Good point – the recent dust-up over DropBox's privacy changes are tangentially related as well.

Continuing the Discussion

  1. […] I had a wonderful time, talking with several people and groups about cloud stuff. Some of of my cloud security post comes from discussions there, and I wrote-up an off the cuff explanation of 3 tips for applying […]

  2. […] decisions – is how much that “genuflecting in front of your customers,” as IBM’s Steve Mills recently put it, costs in the end. A hell of lot more than […]

  3. […] biggest argument of all is over public vs. private. The idea that you need private has all but won, with “security” and special snow-flake concerns weighing too heavily on decision maker’s […]