Proactive GRC Can Prevent AWS Security Breaches

Governance, risk, and compliance should be at the heart of AWS security procedures Another day, another AWS security breach, and this one is particularly bad because of the extraordinarily sensitive nature of the data that was compromised: Over 9,000 documents containing personal data on job applicants holding U.S. security clearances, some of them Top Secret, were discovered sitting on an insecure AWS S3 bucket, where they may have been for as long as a year. Gizmodo reports: [T]he cache of roughly 9,400 documents reveal extraordinary details about thousands of individuals who were formerly and may be currently employed by the US Department of Defense and within the US intelligence community. Other documents reveal sensitive and personal details about Iraqi and Afghan nationals who have cooperated and worked alongside US military forces in their home countries, according to the security firm who discovered and reviewed the documents. Between 15 and 20 applicants reportedly meet this criteria. The AWS bucket belonged to a company called TalentPen, a third-party vendor hired by private security firm Tiger Swan to process job applications. Sound GRC Can Prevent AWS Security Breaches The TalentPen breach is only the latest in a long line of AWS security incidents, most of them involving third-party business associates of larger firms, such as Verizon and the Republican National Committee. The problem is so pervasive that Amazon itself recently sent out a mass email to customers with unprotected AWS S3 buckets, imploring them to review their security settings, and many companies are now questioning how secure the AWS service really is. However, the problem isn’t with Amazon Web Services. AWS security is quite sound – if it is configured correctly, and if the enterprise using it follows sound GRC practices and applies them to on-premises data, data residing in the cloud, and, in the case of the companies hiring IT service providers, data being handled by those service providers. It’s Your Data, and You’re the One Who Has to Secure It and Maintain Compliance While AWS offers security protections such as encryption of PII both at rest and in transit, and AWS S3 buckets are set to private by default, these protections are only as good as the company that’s utilizing AWS. In the Verizon, C, TalentPen, and other recent breaches, someone went into the system and took specific steps to override the default AWS settings and open the buckets up for public viewing. This raises very serious questions regarding data security and governance within these organizations. Who went into the AWS accounts and made these buckets public? Why did they do this? Why did they have the system privileges to access this data and make this change, and why did the change go unnoticed (in the case of TalentPen, perhaps for as long as a year)? Why was data this sensitive uploaded to the cloud in the first place? Comprehensive, consistent cloud security and AWS security protocols, combined with appropriate user access credentials and continuous system monitoring, would have prevented all of these breaches. Compliance is another issue when using AWS or other cloud services. While AWS contains tools that customers can use to ensure they comply with major IT audit frameworks, such as HIPPA, PCI DSS, NIST, and FISMA, it would be impossible for AWS, or any other provider, to ensure that all of their customers are covering every aspect of the specific compliance requirements that apply to them. Thus, AWS operates on a “shared responsibility” model, where AWS itself is responsible for the security and compliance of their cloud, while their customers are responsible for the security of the data they store within it. In the end, it is your data, and you are the one who is ultimately responsible for it – even if a third-party vendor is the one who mishandles it. Addressing governance, risk, and compliance in the cloud and throughout your cyber ecosystem can be a challenge, but in the end, proactive GRC is much less expensive than cleaning up after a data breach.