Imagine walking into your bank’s local branch office, sliding a carton across the counter containing vegetables from your refrigerator drawer, a diamond necklace, and a plunge router, and asking the teller to deposit them. The bank teller then labels each carefully with your name, then lobs them over his shoulder into a huge vat along with other people’s stuff.
Those of you who regularly read my columns, know that I like analogies. Admittedly, some of them may be weak; however, likening sending data to a public cloud is only vaguely similar to depositing money in a bank.
I mention this because I’ve read a few blog posts and articles that make this comparison to argue that cloud security concerns are the paranoia of miserly, cousin-of-a-magpie, data hoarders, and akin to wanting to keep your cash stuffed in the mattress.
Now, I’m far from an expert on the intricate mechanics of banking, but I do know that they deal in financial instruments: they receive deposits, make loans, and provide checking and savings account services. They don’t take and hold groceries for later withdrawal, nor power tools. Of course you can store your diamond necklace in a safe deposit box, but let’s table that for the moment.
The most striking disparity in the comparison between data in the cloud and money in the bank is that the bank knows the value of what you’re depositing. They don’t have to return the exact U.S. dollar bill, Canadian loonie or toonie, Saudi riyal note, or Nigerian kobo coin, that you handed to them; as long as the value of the returned monies works out to what you deposited, plus any interest, minus any withdrawals and penalties, you’re a happy and whole bank customer.
Not so with data in the cloud. One file is not equivalent to another. You may argue that the stream of packets delivered to you when you access your data is not an exact duplicate of what you sent to the cloud (the instrument) as long as the original substance of the data returned is the same—and I agree; however, the distinction isn’t the integrity of the data: it’s the business value it contains.
A cloud provider will treat each of your files the same, as they will all their customers’ data. Your private medical history may be stored shoulder-to-shoulder on a cloud provider’s hard disk with an email from some guy’s grandmother containing her recipe for galumpkis. And the two may be co-hosted on the same physical machine containing the next WikiLeaks server. The value of these files is vastly different to the owners of the data (which may be subjective since those are some damn fine galumpkis!), to Interpol, and to the cloud provider.
Mr. Pink’s dollar, euro, or rupee has the same quantifiable value as yours and the bank uses that value to invest until you withdraw your money. However, public cloud providers are more like a safe deposit box: the value of the object you deposit is not known to the bank. Your stored item may be a handful of precious gems or love letters from an old flame. Or it may be hundreds of dollars in cash—the very thing banks are good at storing outside of the safe deposit box.
The public cloud model doesn’t work the same way as a safe deposit box; it defeats the purpose. Public cloud providers rely on elasticity for economies of scale, which is the very reason most organizations are looking to the cloud: lower cost. Imagine you have three glasses that you only fill half-full of water. It would be cheaper to only buy two glasses and fill one completely or spread the water evenly between the two, each containing three-quarters. If public cloud providers had to dedicate disk resources to store your data separate from other customers, like a safe deposit box, or even dedicate a server, they’re stuck with three half-filled glasses; if they can co-mingle your data with other customers’ on the same disk array and server, they can add or remove glasses as needed and pour the water around to maximize resources and reduce power consumption, maintenance costs, etc.
Another difference is that banks have insurance. In the US the FDIC protects consumer investments up to $250,000. There is no congruent protection for cloud providers, although you may be able to negotiate a data loss amount in your contract with them. The rabbit in the hat here is defining what your data is worth. Unless you’ve conducted a thorough information risk assessment and are able to quantify the value of your data—and specifically data you’re willing to put into a public cloud—you don’t know what your true liability is. At least with a bank, you know you’ve deposited $300,000 and the FDIC will cover $250,000, leaving you with $50K worth of risk.
Additionally, banks normally operate within the jurisdiction of their own country, or at least the country in which a particular branch office operates. With the public cloud you never know where your data may be located geographically, and it may be subject to those countries’ laws, including those concerned with privacy and right to search and seizure.
Other differences between banks and the public cloud include loss of access or unauthorized exposure to your data. What happens if law enforcement gets involved and shuts down the cloud provider, similar to what recently happened with MegaUpload? Or a hacktivist group mounts a DDoS attack against the provider? And while cloud providers are insanely concerned about keeping customer data logically compartmentalized, people make mistakes and software contains bugs. Practically all banks have an online presence and DDoS attacks are a concern, as is unauthorized access; however, with most banks you still have the option of visiting a brick-and-mortar branch and conducting business face-to-face, as inconvenient as that may seem.
One of the reasons organizations move to the cloud is because there’s a perception that cloud providers have more resources to build and maintain stronger security infrastructures, as well as to shift the security responsibility from the organization to the cloud provider. On one hand this sounds an awful lot like the reason we put our money in banks. We withdraw only what we need and accept the risk that we may be mugged walking down the street—or even in the bank parking lot. To mitigate the risk of carrying around cash you may have a safe in your house or maybe store emergency cash in a cookie jar, or even carry a weapon.
This parallel holds true with the cloud: while data is stored in the provider’s infrastructure, it’s used everywhere. When you access the data it’s brought back to the point of use, be it a web browser, database application, or simple file copying. Users may download and save files locally, create reports, or sensitive data may be left hanging around in browser caches. So in effect, you still have to define a security program and build the security infrastructure to support it; data doesn’t exist exclusively in the cloud. But where the parallel starts to diverge is that the majority of bank accounts are held in one person’s name, possibly with a trusted joint account holder; whereas, when considering moving enterprises to the cloud you’ll likely have dozens, if not hundreds or thousands, of employees, who you trust to varying degrees. All the security challenges we face today are true with cloud data: we still have to build a security perimeter and protect the endpoints, monitor the infrastructure and track the data, and engender a culture concerned with security and privacy. So not only can we not sidestep the cost of building a security program, but your data is still only as secure as the weakest link.
Am I saying the cloud is insecure or that it will never have the adoption of the banking industry? Absolutely not; however, we either need to find a more realistic analogy or smother this one in caveats as thick as fried onions and peppers on street meat. The direct and unqualified analogy that putting data into the cloud is like putting money in the bank is hyperbole; the danger in facile comparisons is they can convince decision makers to act without an accurate representation of the risk factors. Accurate analogies are excellent at translating geek-speak to the boardroom; bad ones can be just as sexy and compelling, but put the entire organization at risk.
