Thread by @kmcquade3

A few thoughts on the $80 million fine from the Capital One Breach - a thread.

Based on public information, we know that this happened, in part, to overly permissive AWS IAM policies that allowed s3:GetObject to * resources.

As @matthewdfuller said - probably one of the most expensive * wildcards in history.

https://twitter.com/matthewdfuller/status/1291513317014605830?s=20

IAM is hard. It's really hard.

Many orgs will put a lot of thought into the privileges behind their user roles, but not nearly enough behind their machine roles - so developers slap an AWS managed policy to their EC2 Instance Profiles so IAM stops breaking shit & call it a day

And honestly, the problem has been so difficult to solve, that I think every AWS customer leveraging Instance Profiles or machine roles is vulnerable to this somewhere. If one app gets compromised and you haven't limited blast radius, you're screwed.

Then, if one app is vulnerable to SSRF or otherwise, the blast radius is large enough so that hackers could compromise customer information, expose resources to the public, escalate privileges, turn your EC2 instances into a Bitcoin mining rig, or just nuke shit & cause downtime

Once your multi-account architecture gets beyond maybe a dozen accounts, this problem balloons beyond the capacity of any one person to fix.

The backlog of insecure IAM policies becomes too much to solve via bugs/tickets, and you start discussing automating the bug opening process and engineering your way out of it. But you do it with zero funding, more pressure from management, and not a lot of IAM experts. Not fun.

If you're in security & you really want to piss off your entire developer population - maybe you get a team of people and turn them into an AWS IAM Policy writing shop. But I can guarantee that if you do that, people will get frustrated and bored that they will leave the company

I've seen it happen, from industry peers and back in consulting. It affects your entire culture, innovation slows, and it's bad for business.

I wrote Policy Sentry to prevent this situation from happening - where writing least privilege IAM policies, particularly for machine roles like EC2 Instance Profiles, becomes so difficult to fix at scale that the problem balloons and people give up.

github.com/salesforce/pol…

I wrote it because customer trust matters. Every company has a responsibility to its customers to lock down their data, whether their cloud provider makes that easy or not.

I wrote it because a single use of s3:GetObject to * resources can result in 100 million customers being affected, and your organization being fined for $80 fucking million - despite having thousands of brilliant engineers, good intentions, and solid security controls.

If you want to lock down your AWS IAM Policies, you have to attack the problem from multiple angles.
- Make Policy writing easy.
- Detect bad ones
- Implement guardrails
- Auto-remediation of excessive privileges
- Solve problems related to people and processes

More details:

(a) Write least privilege IAM policies with Policy Sentry.

Yes, I wrote it so I'm biased. But it's damn good, free and open-source, and doesn't require you to be an IAM expert. Just copy/paste resource ARNs and access levels and call it a fucking day.

github.com/salesforce/pol…

(b) Audit your existing IAM policies for security issues I also wrote Cloudsplaining, which helps you detect which IAM policies allow for PrivEsc, Resource Exposure, Data Exfil, etc. It's not the only approach, but it's damn good & you should try it out

github.com/salesforce/clo…

(c) Turn on Access Analyzer at the AWS Organizations level. Resource-based policies (like S3 Bucket policies, Secrets manager policies, etc.) and allowing access to the internet via * wildcard Principals is an issue too.

(d) Use Parliament by @0xdabbad00 to audit your IAM policies and your resource-based policies. This will help you avoid things like resource policy privilege escalation, credentials exposure, and it's pluggable so you can write your own custom auditors. github.com/duo-labs/parli…

(e) Provide reactive auto-remediation - automatically revoking unused IAM permissions with Repokid. github.com/Netflix/repokid

(f) Express your entire infrastructure as code if you aren't already doing so, and prevent people from going rogue and creating their own policies. I recommend Terraform, unless your name is @__steele, if you just like pain, or if YAML turns you on.

(g) Stop using AWS Managed Policies for machine roles. Just don't. This is why we can't have nice things.

It's fine for user roles, but put some guardrails on it like Permissions boundaries and SCPs.

(h) Use Service Control Policies to implement Guardrails, enforce your security settings, and prevent people from doing dumb shit to get their jobs done.

This is a great starter by @0xdabbad00 at @SummitRoute

summitroute.com/blog/2020/03/2…

(i) From an organizational perspective, treat this shit like you are building out products and features - you can't just address this by opening tickets and assigning cases. You have to build products, automation, and processes to address these things at scale

And lastly - if your organization has an innovative way of approaching this problem - please, share it with the community. The entire community could benefit from your approach and even improve on it.