Sorting out "cloud security"

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, Expensify.com

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

• I really enjoyed the 146 page(!) paper put out by the EU, Security and Resilience in Governmental Clouds. It not only goes over “the same old” security practices (like risk/benefit analysis, separation and control of roles, etc.), but has a nice, non-US-centric discussion of Fear of Subpoena.
• Harold Moss, CTO of Cloud Security Strategy at IBM Security Solutions, is one of the first “enterprise guys” I’ve talked with who actually spoke some sense here. He went beyond the usual, non-specific FUD, and actually has a nice talk that’s trying to make enterprise more comfortable (!!) with security in the cloud. He’s co-author of a paper an IBM paper on cloud security, which I haven’t read in detail, that tries to outline how to think about security in the cloud.
• The “cloud security” session at the IBM Impact Unconference was excellent in that a mix of vendors and practitioners were trying to sort out just what cloud security meant.