nutbear

Good catch on the bucket vs object level permissions with S3 and s3:PutObject.

I'd also be curious for future plans with resource policies as that's another layer of complexity to manage - where the resource policy would manage access to potentially many applications -> 1 resource. Vs 1 application -> many resources which I think is the use case Slauth is solving for initially.

Confused Deputy would be interesting, could be done via Condition Keys such as SourceArn and SourceAccount, but gets complex for cross-account use cases.

Yes. Good points. Agreed with patchwork as sometimes IAM can take a backseat to different priorities such as application development or feature development.

There's a couple different models for IAM ownership. At some places, the application teams own IAM along with the application. Sometimes, it's owned by central teams (such as security).

And agreed, with companies growing and changing, ownership changes as well.

Those factors can all complicated IAM development and policy maintenance as it becomes more difficult to find the right fit for IAM to application. For that, it would require someone who knows exactly what the application needs access to and the IAM actions taken as well as how to configure IAM.

IAM Policies in AWS are inherently difficult - there's a lot of nuance to the policies such as evaluation logic (allow/deny decisions), resource scoping, conditionals, and more. It's often more straightforward to start with a broad IAM policy and then leave it without reducing privilege as to not adversely impact the application. Proper IAM also takes dev cycles, and may not be top priority to get a policy correct. I think it's rare to find a 100% properly scoped IAM policy for an application.

Datadog recently did a State of Cloud Security and one of their findings in https://www.datadoghq.com/state-of-cloud-security/ is that a substantial portion of cloud workloads are excessively privileged (with more data points there).

I wrote a blog detailing what this change means on S3 ACLs and Block Public Access on by default: https://www.cloudquery.io/blog/finding-enabled-s3-acls-and-d...

We wrote a post on this and some of the nuances/discrepancies for these S3 settings: https://www.cloudquery.io/blog/finding-enabled-s3-acls-and-d...

Thanks for sharing your story!

A decent amount of disclosure programs explicitly call out social engineering as unacceptable conduct and submissions.

However, social engineering is a very valid method for attackers and in many cases, offers the path of least resistance.

While I understand why companies don’t want good faith security research to call and try to trick the human factor, this is still a very real attack vector that needs attention and to be fixed as in what you’ve described.