This post was originally published here by Rich Campagna.
Another day, another massive data breach, this one involving Uber and the theft of data on more than 57 million drivers and customers. Like the recent high profile AWS S3 misconfigurations leading to unwanted exposure of sensitive data, the Uber hack could have been prevented with basic Cloud Access Security Broker (CASB) policies in place. Specifically, identity and access control capabilities.
Identity components in CASBs include not only basic username and password authentication, but can also layer multi-factor authentication (MFA) onto any cloud app (including AWS). In this case, stolen (static) credentials were used to access an Uber AWS account. Forcing MFA either in all cases, or for privileged users that have access to such a massive store of information would have prevented the attack altogether.
Access control, used alone or in conjunction with MFA, could also help. In this case, a policy might have stated that users on unmanaged devices and/or outside of corporate locations have less permissive access to the Uber AWS environment. A very basic policy would be to assign an AWS ARN with limited access from BYOD and off-network. Since the hackers were most definitely not using a managed Uber device, and were likely outside of Uber’s corporate offices, this would be a simple way to limit damage, or prevent it entirely. Does anyone really need access to 57 million records when working from home on BYOD? Access control could also be used in conjunction with MFA – if Uber didn’t want to force everyone to use MFA, they could “step-up” authentication for riskier contexts like unmanaged devices.
Very simple fix for what is turning out to be a very costly PR nightmare for Uber. Hopefully others will take this advice and avoid a similar fate…
