Uber is not alone in its reliance on Amazon Web Services, but it may be a bellwether, since the digital solution du jour may have led directly to the catastrophic data breach the embattled taxi-killer deigned to disclose.
It is crucial to focus on the root cause of the Uber hack so we can avoid similar attacks in 2018. The vulnerability is common, and it will cause other service-based companies to walk the plank of public outrage if it is not properly understood and contained.
Uber has acknowledged that unauthorized parties got deep into its AWS platform to steal private data belonging to 50 million riders and 7 million drivers. The hackers did this by obtaining, then using, the AWS logon credentials of one of Uber's software developers. Apparently, this coder left his or her AWS credentials somewhere where hackers could get to them on GitHub.
Nitty gritty details notwithstanding, something like this had to have happened: The Uber developer in question uploaded some code to GitHub while working on an AWS task. ("Git" is a system for controlling the latest version of software programs; GitHub is an online repository where developers upload the latest versions of code for peer reviews.)
No security sins were committed up to this point.
Here's what happened from 30,000 feet.
Connecting riders and drivers is a neat digital trick. To do it, Uber collects and stores oceans of data on AWS and then feeds this information to other services supplied by Google, Facebook, Twitter, iPhone and Android. This massively complex orchestration requires continual software maintenance and development.
Uber is a perfect example of a 21st century, cloud-enabled commercial entity. Amazon, meanwhile, has made AWS the cornerstone for many Internet-centric businesses. Netflix, Spotify, Instagram and tens of thousands of other popular consumer services are powered by AWS.
As consumers, we are content to remain blind to the complexity underlying these familiar services that make life easier, more enjoyable and less occupied by trivial chores like renting movies, buying CDs--all the stuff you can no longer do anyway because the post-AWS world has it all figured out. We look at our screens, watching the driver we just hailed wend closer and closer.
To make that happen seamlessly, continual software development is required. That means humans need to be involved (at least for the time being). And what we know about humans is that they mess up.
What has become clear is that Uber's programmer did not understand, or perhaps did not care about, the risk of including AWS logon credentials in GitHub uploads. What's most troublesome is that this shortsightedness is a common practice -- one that is being repeated countless times every day, Jeremiah Grossman, Chief of Security Strategy at SentinelOne, told me.
"The average piece of software today has to take data from multiple locations and bring it to one spot," Grossman explains. "When you're developing software, your code might have to authenticate to Amazon, or to Facebook, or to many other systems. So developers are including those authentication keys in their source code because the software needs to leverage those credentials.''
This bad coding practice is an unintended consequence of something called DevOps - the push to combine software development (Dev) and software operations (Ops.) DevOps encourages both to happen simultaneously, instead of sequentially; the idea is to speed up deployment of new programs.
"One of the consequences of DevOps, and the increased need to automate everything, is that your automation scripts and your automation tools need to have access to everything very fast," explains Liz Rice, technology evangelist at Aqua Security. "So it has become very, very easy for people to put account credentials into those scripts, and it is that kind of mistake that ends up with people losing control of those credentials."
Grossman puts this new type of oversight into perspective: "It's a huge mistake and it's also a very unforgiving mistake. It's like leaving your key under the doormat where anybody can easily find it and use it."
Given the notoriety and lucrative payoff of the Uber hack, it is reasonable to expect cybercriminals to accelerate efforts to discover and take advantage of AWS credentials left exposed on GitHub in 2018.
Amazon has addressed this in its shared responsibility policy for AWS users. The upshot? It's up to AWS users to jealously guard access to their AWS accounts.
To its credit, Amazon doesn't leave users out on a limb; it supplies the technical means for AWS users to exercise fine-grained control over access privileges, Rice says.
At the end of the day it comes down to individual developers pausing while rushing to push the latest, coolest program into live deployment - and actually taking extra security steps to restrict AWS account access.
"It's exactly the same as you, as an individual, having the responsibility to look after your own passwords and PIN numbers for you bank accounts," Rice says. "If you leave your passwords and PIN numbers out on a piece of paper on your desk, you bear some of the responsibility if someone were then to take your money."
Clearly, Amazon can't be held responsible if a harried software developer leaves his or her AWS credentials lying around. Yet, the temptation to take security shortcuts looms large. What's more, this same human-centric vulnerability exists not just for AWS, but also for Microsoft Azure and Google Cloud, as well as popular business tools like Office365, Salesforce.com and Concur, says Tim Erlin, vice president of product management and strategy at Tripwire.
"The Uber breach should drive organizations to evaluate the various points of access throughout their software development lifecycle, and their supply chain in general," Erlin says.
Companies whose operations pivot off of AWS and similar services need to address this critical, human-powered vulnerability in 2018. If they don't, we already know the outcome.