On July 17 Virginia-based bank Capital One received an email tip that their data had been leaked on code-hosting site Github. An initial investigation found that the data originated from a Capital One server hosted in the cloud that was accessed via a misconfigured firewall.
Capital One contacted the FBI who found online social media postings of the hack by former Seattle software engineer Patricia Thompson who was then arrested and charged on July 29th for computer intrusion and theft of the Capital One data.
Thompson “made statements on social media for evidencing the fact that she has information of Capital One, and that she recognizes that she has acted illegally,” according to the criminal complaint. In one post, “erratic,” Thompson’s hacker name, states “I’ve basically strapped myself with a bomb vest …dropping Capital ones docs and admitting it”.
The data theft compromised “approximately 100 million individuals in the United States and approximately 6 million in Canada. Importantly, no credit card account numbers or log-in credentials were compromised and over 99 percent of Social Security numbers were not compromised. The largest category of information accessed was information on consumers and small businesses as of the time they applied for one of our credit card products from 2005 through early 2019,” said Capital One.
Capital One also says that safeguarding applicant and customer information is essential to their role as a financial institution while investing heavily in cybersecurity and incorporating the learnings from this incident to further strengthen their cyber defenses, according to a statement posted on the Capital One web site.
The data breach is unique in that it was not done by a nation-state. The FBI does not name the cloud provider that was compromised at Capital One, how Thompson knew which server to attack or where she worked, or if she was employed at all. This incident contributes to the trend that has compromised security at dozens of enterprises from Marriott to Quora. When will these enterprises realize that when it comes to protection from security breaches it is time to assume the worst?
Amazon Web Services’ Shared Security Model
The Capital One breach highlights the need to ensure that enterprises who host their data in the cloud, whether it is AWS Public Cloud or the GovCloud, intimately know how to correctly configure their cloud resources and protect their data assets by knowing which employees or contractors can access cloud resources. Cloud security is the responsibility of both the cloud consumer and provider.
Amazon, for instance, uses the AWS Shared Security Model that provides security for AWS infrastructure, including protecting computing, storage, networking and database services. This means that Amazon is responsible for the security of the software, hardware, and the physical facilities that host AWS services. This has been especially important for AWS when adhering to legal security standards while working with NASA, Department of Homeland Security, and financial service leaders.
However, AWS is only responsible for securing the underlying infrastructure that supports the cloud. Despite this additional security measure, customers are still responsible for resources they put in the cloud or connect to the cloud as well as the individuals that manage and access cloud resources.
Although Capital One immediately fixed the configuration vulnerability that Thompson exploited, the hack exposes the need for companies to develop security strategies that address not only cloud security from an infrastructure standpoint but also the need to carefully manage everything from firewall configurations to identity and access management.
AWS Firewall Manager and Identity and Access Management
From a security configuration standpoint AWS offers security services such as AWS Firewall Manager and Identity and Access Management. AWS Firewall Manager has been praised as it makes it easier to centrally configure and manage AWS firewall rules across accounts and applications. Firewall Manager also makes it easy to bring new applications and resources into compliance with common security rules.
With AWS Identity and Access Management (IAM) enterprises can securely manage access to AWS services and resources by creating and managing AWS users and groups, and permissions to allow or deny access to AWS resources.
The cornerstone of AWS identity and access management are IAM roles and IAM users that grant access permissions to specific cloud resources.
According to Amazon, an IAM role is an identity that you can create to grant users and IT administrators specific permissions to cloud resources. An IAM role is like an IAM user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. When you assume a role, it provides you with temporary security credentials for your role sessions.
You can use roles to delegate access to users, applications, or services that don't normally have access to your AWS resources. For example, you might want to grant users in your AWS account access to resources they don't usually have, or grant users in one AWS account access to resources in another account.
At Stratus10 we always use AWS security best practices when designing our client's infrastructure, please contact us for questions about your AWS Shared Security Model strategy.
Get in touch with a cloud expert today to discuss how Stratus10 can help!
Call us at 619.780.6100
Send us an email at Sales@Stratus10.com
Send us a message by filling out our Contact Form
Read our Customer Case Studies