The Breach
The last few months have seen multiple data breaches across organisations in the retail, stock brokerage, restaurant chain, FinTech space etc in India. These breaches have leaked the names, email ids, DOB, PAN Card, Credit Card, Bank Details and other Personally Identifiable Information(PII) of several millions of customers.
This is highly worrying since this data will reside on the dark web for a long time and will be up for sale to anyone who wants to misuse it. You may not see the impact immediately – but these are information that bad actors can use to impersonate you and open fraudulent services, loans, credit cards, etc., in your name.
In the case of the brokerage firm, the breach reason cited is a compromised AWS Access Key (We have not been able to verify this).
What are Access Keys in AWS, and what are the security threats?
Let’s say your Access Key got breached – there are many ways in which this can happen; a typical example is developers checking in code to a public GIT repo (public code repository) and bad actors leveraging that information.
Once your Access Key is in the hands of a bad actor, they can quickly wreak havoc in your cloud infrastructure. Again (and note this point), the extent of damage done depends on the Access Key’s permissions.
Let’s assume the brokerage firm stored all of these files in an S3 Bucket in AWS. S3 Buckets (public cloud storage) in AWS has been a subject of many breaches. Let us also assume the Access Key had administrative access to that AWS Account – this happens in many customer environments we have audited.
The hacker can use those administrative privileges to determine where your crown jewel data (PII data) is stored, exfiltrate it, and also use the administrative permissions to do a complete account takeover.
PII = Personally Identifiable Information
BUT, if the principle of least privilege was applied while associating permissions to the IAM User (to which the access key is associated), and say the IAM User had only permissions to view some S3 Buckets (that had non-PII data), that would have reduced your threat factor significantly. There are a multitude of ways in which you can apply the principle of least privilege – many of them are use case specific.
The point to note is – in almost 90% of cloud accounts we have audited, there were way too many IAM Users who had Administrator privileges that were not needed at all. Identify and curtail these permissions – else you are leaving yourself vulnerable.
Closing thoughts
As more and more organizations leverage the Public Cloud, it becomes highly crucial to educate and inform about the best practices to apply while configuring the cloud and, most importantly, while creating Access Keys and associating permissions to the cloud IAM Users.
ALWAYS follow and apply the principle of least privilege. You may not be able to prevent a breach even if you have all the latest security products, but you can definitely be smart and minimize damage and reduce your threat detection window.
Remember, the cloud by design is secure. Still, cloud customers have to follow the best practices and incorporate good security hygiene – because YOU are responsible for the security of YOUR cloud infrastructure
About C3M
- Complete Visibility
- Misconfiguration Prevention
- Compliance Assurance
- Incident Response
- Least Privilege Enforcement
- Identity and Entitlement Governance
- Quantifying Risk Posture
