Blog Post

Accidents happen. That’s why the cloud needs a crumple zone

When Henry Ford started churning out Model Ts on his assembly line in 1908, there hadn’t been an automobile fatality in nearly 40 years — not since Mary Ward was run over by a steam-powered car in Ireland in 1869. But with modern production, engineering improvements, better roads and more cars on them, automobile safety became a growing concern.

One of the car’s most recognizable safety features, the seatbelt, became standard equipment by the 1970s, but it wasn’t until 1984 that seatbelt use was made mandatory — over the protestations of the public and industry. Why? After decades of education and awareness, a majority of the public finally came to realize that seatbelts save lives.

Since then, car safety has gone from being an optional afterthought to a required feature, gauged by National Highway Traffic Safety Administration’s 5-Star Star Safety Rating. Today’s cars are replete with innovations engineered to make them safer to drive and to protect passengers when things go awry. Many of these features, like breakaway steering columns and crumple zones, are not as evident as the ubiquitous seatbelt, but are integral to the car’s design because we came to terms with a simple fact: Accidents are inevitable.

Amid the industry’s massive shift to cloud computing and software as a service, the recent [company]Apple[/company] iCloud photo hack may one day be regarded as the tech industry’s wakeup call — the inflection point when security awareness became so acute as to demand that information security and data privacy features be tightly integrated into cloud architecture.

iCloud, after all, should not be read as a portent of “don’t adopt cloud,” but rather, “use cloud wisely.” And wise developers and vendors of cloud services will compete on the basis of safety, touting cloud “crumple zones,” if you will, that  factor in the likelihood of breaches and classify data accordingly.

In cloud architecture, we design for failure. We assume an outage will happen and build an infrastructure that can withstand failure, and even autonomously recover from it. However, we still have not crossed the threshold of designing for breach. In many minds, the notion of a breach is something that can be avoided with proper preventative controls, rather than something that can be accommodated by the architecture. However, we know that breaches are inevitable.

Cloud service providers have standardized on a “shared responsibility model,” which essentially places the onus of infrastructure uptime on the vendor, and breach protection on the customer. Some customers buck the trend and attempt to negotiate better terms with the vendors, but most of us are stuck with the terms of service as they are, indemnifying cloud vendors in the event of  a breach.

So, how can we design crumple zones into our cloud security strategy? First and foremost, we must develop a risk appetite for breach – we need to accept the inevitable. Second, we need to design compensating controls. If we assume a breach will happen, then we must understand its impact to the organization – this means data value classification, which then enables us to determine our appetite for things like data loss, data tampering and even extortion. Then these can be counterweighted with compensating controls such as cyber insurance, cloud access security brokers and additional security headcount.

We don’t need to gaze into a crystal ball to see the consequences of not adopting this model. A few months ago, Code Spaces, a code-hosting and software collaboration platform, was put out of business by an attacker who deleted the company’s data and backups. As more businesses go all-in on cloud, it’s crucial that we add “design for breach” into our “design for failure” methodology. In other words, we need crumple zones in the cloud because accidents are inevitable.

Tal Klein is VP of Strategy at Adallom, a Palo Alto, California–based SaaS security provider.

Photo courtesy of Flickr user choking sun

12 Responses to “Accidents happen. That’s why the cloud needs a crumple zone”

  1. Timothy Borne

    This is why no cloud service API that requires user credentials should be left without a rate limit. Rate limiting restricts the number of requests that can be made with bad credentials or tokens in a particular period of time. Leaving APIs without a rate limit allows hackers to try any number of potential passwords in a short space of time, massively increasing the chances that they’ll hit on the right combination and bypass cloud security measures.

    • API rate limiting, IP restrictions, Two Factor — these are all controls that should be provided by the cloud provider but adoption the customer must be accountable for their use. In the context of your example, there are many services (for example Marketo to Salesforce sync) that would be exceptions to that rule, and only the customer can know for sure – not the vendor. Cloud service security is a collaboration between vendor and customer. It’s not reasonable to expect the vendor to protect your users from malware, or phishing, for example, even those attacks target their service.

    • Tal Klein

      Celebs on iCloud were pwnd by phishing, not a back door. Your NSA fears are privacy, not security concerns. Some cloud services are responding to consumer demand and building NSA crumple zones as well, check out CloudFlare, for example.

      • 1) If it isn’t private, it isn’t secure. 2) The celebs credentials may have been phished, but the software that recovered was intended for law enforcement usage. 3) CloudFlare is offering a Trusted Man in the Middle solution. It’s hardly a new technique and it fails when the Man in the Middle is the NSA with a gag order on CloudFlare.

        My NSA fears are Jennifer Lawrence’s NSA reality. She was completely pwned because of US government policy requiring cloud providers to provide insecure access for law enforcement agencies. Snowden made it clear that the young guys in NSA were sharing these nudes with their coworkers as ‘perks’ of the job. Is that the kind of country you are proud to live in?

        As it stands, no US cloud provider can be trusted. At all.

    • Tal Klein

      Even “internet” is too generic.. It’s important to understand the context of each service you use (IaaS, PaaS, SaaS) and classify its ability to impact your data (whether on it or a service connected to via API).