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.
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:
- Requiring two people with separate keys to do major tasks – “Split Knowledge, Dual Control Key that ruins auto-booting of servers
- 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?”
- 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”)
- 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”?
