On January 13, 2020 at an enterprise company headquartered in Mountain View, CA, a Vice President of Product noticed something a bit out of the ordinary in his AWS environment. He followed the breadcrumbs to realize an AWS engineer had sent a gigabyte of data to his personal GitHub account. Five hours might not seem like a long time but to a malicious actor, five hours is more than enough. Luckily, for this Vice President of Product not all actors are malicious, sometimes data leaks or a data breach can occur by mistake.
The data breach was not massive – only about a gigabyte of data was leaked; however, it’s not always the size that matters, it’s the content. This particular data set mostly contained access keys for various cloud services, collections of authentication tokens, and APIs for third party providers. The VP, in this case, was diligent and responded to an alert of suspicious activity timely, allowing the risk to be mitigated and resolved fairly quickly. It was discovered based on his due diligence. He noticed obscure file names “Rootkey” and “Amazon Confidential”. The discovery was not easy to spot and the credit here definitely falls on this VP of Product.
This particular breach would be classified under human error leading to a misconfiguration. Everyone makes mistakes, but it’s important to set up an environment which allows for mitigation of these mistakes as they occur. In this case, this particular human error occurred because an AWS engineer had committed about a gigabyte of data to his personal GitHub repository. This was likely a case of mislabeled and misclassified data. The repository this data was downloaded from was structured as general storage and contained AWS resource templates and log files. Coming from central storage – the data should have been more secured. This also could be a strong case for overpermissioned identities. The AWS engineer should not have been prohibited from downloading the data to his personal repository. The breach could have also been prevented by utilizing S3 buckets. S3 buckets and objects are private; allowing only the resource owner and the AWS account bucket creator to access their bucket and its contents. The resource owner can, however, chose to grant access permissions to other resources and users, making it a safe and secure option for housing data.
The shared responsibility model went a long way in making sure this issue was dealt with effectively and efficiently. Even in a so-called perfect environment, mistakes can occur. The ability of this VP to receive and notice the foul play and act on it in a timely manner was crucial to mitigate the risk. Too often in these situations we see companies battling alert fatigue and do not address high priority issues in a timely fashion. It is always beneficial for an organization to monitor remediation of non-person identities to ensure risk mitigation across the environment.
To learn more about this cloud data breach, read the Security Boulevard article.
Read the latest news and insights
06.17.2020
In the wake of the largest data breach in CIA history,...
07.31.2019
Review a recent cloud data breach as a reminder that...
