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.