Thoughts on the 2016 Uber data breach and the Shared Responsibility Model (SRM) in protecting data stored by cloud providers.
I’ve been asked to comment on articles that suggest that the SRM would have helped prevent the 2016 Uber data breach. While SRM is a great way to delineate roles and responsibilities in cloud storage, I don’t think that it would have made a difference in what happened in the 2016 Uber hack. From the initial data, it appears that the failure was completely within the responsibilities of Uber and not the cloud providers.
What happened in the 2016 Uber hack? The hackers obtained access to a Github repository that contained username and password information for the software developers at Uber. Once they had the developer’s username and password, they had the keys to the kingdom and used those keys to access driver and rider data stored on Uber’s cloud server space at AWS. It’s not clear (right now) how the hackers obtained the Github credentials. Github is a VERY commonly used repository for computer code, that allows many programmers to work on a single large software program (i.e. Uber’s systems) all at the same time – it has lots of features that makes distributed software development efficient and effective. However, sometimes login credentials are shared between programmers (bad idea) and credentials are created for automated processes, but not deleted later (also bad). Regardless, the hackers somehow obtained the Github credentials which gave them access to stored usernames and passwords that could be used to access the rider and driver data in other databases.
Back to the point – why is the Shared Responsibility Model not the culprit here? SRM splits the responsibility for cloud security: essentially, the cloud provider is responsible for protecting the infrastructure and the customer is responsible for protecting the data. As the hacker’s access to the AWS cloud storage was using an authorized username and password (stolen), the failure was in Uber’s access control systems and policies, not something controlled by AWS, the cloud provider. (AWS does use SRM. (FN1)) Moreover (and more important), rights and responsibilities of each party using cloud storage is governed by the user agreement’s Terms of Service – something that is fixed for you and me, but frequently is negotiated for larger users of the service. As stated, the SRM model would have placed the responsibility for user access control on Uber and not the cloud provider – hence, the same result.
When applying the analysis to Github, the answer is less clear because we really don’t know (yet) how the hackers gained access to the programmer’s credentials for the code repository. The odds are high, however, that it was a failure of access control systems, policies or usage on the part of Uber employees – again the responsibility of Uber under the SRM. Regardless, Github’s terms of service expressly disclaim any warranties and state that “we will not be liable for damages or losses arising from your use or inability to use the service or otherwise arising under this agreement.” (FN2)
The point some writers are making is that Github’s security protocols could have been better by using two-factor authentication (2FA) or by separating login accounts and passwords from the software code. The second part would have been Uber’s responsibility under the SRM. No question that 2FA would have helped prevent the attack, however, I’m not sure 2FA has become a minimum “industry standard” in cloud services in 2016 when the hack occurred (Github does provide 2FA today) – although it certainly has been a well-known security control for years prior to 2016. At the end of the day, I’m having a hard time figuring out how the SRM would have prevented the hack, because at first blush, the fault appears to lie solely on Uber’s failure in their access control systems, policies or usage.
What would make a difference? Having a clearly defined SRM so each party knows what their data security roles and responsibilities are with cloud storage? Absolutely. But even more, having clearly defined user access controls and policies that are actually followed as well as procedures to audit compliance by employees of those controls and policies.