[lijok]

> Research shows that 95% of the permissions granted to users aren't used

These would be the "s3:*" and "Resources: *" scoped permissions I assume? I can't imagine users are explicitly typing out permissions, 95% of which are not relevant for the task.

> which creates huge problems

Such as? What is the material impact of a workflow or a user having too many permissions?

> and is a reason for spending millions in security tools

Are you claiming that overscoped IAM permissions alone are responsible for 1M+ security tooling bills in companies? Would you be willing to share information on which tools these are?

[kkapelon]

> Such as? What is the material impact of a workflow or a user having too many permissions?

Security obviously https://en.wikipedia.org/wiki/Principle_of_least_privilege

[verdverm]

That is the "theoretical" problem

How many times have excess permissions "actually" been the problem... versus something like correct permissions with compromised credentials?

[blincoln]

It's hard to know with any kind of accuracy how often it comes up in real breaches, but we exploit it all the time to great effect in pen testing.

A few examples I've seen repeatedly:

* An AWS-hosted container/artifact/CI/CD application has an SSRF vulnerability that can be used to retrieve IAM instance credentials. Because micromanaging permissions is hard, and the application needs to access so much content in S3, spin up/down instances, etc. it has ec2:* and s3:. Unless the organization has created a separate AWS account for this platform specifically, it's probably game over at that point.

An internet-facing MDM solution has a code execution vulnerability. Because the vendor didn't want to document all of the individual permissions it needs, the installation instructions specify that it should run as an account with Domain Admin permissions in AD. That is definitely game over for most organizations, because even systems that don't authenticate against AD are almost always accessed from systems that do.

Micromanaging permissions is hard in a big organization. I saw it done well, years ago, in Active Directory, but it took several FTEs who were personally interested in the topic to set up and manage, and that was a traditional big business IT environment. In a startup-style free-for-all, good luck. I don't have an opinion either way on Slauth specifically, but something that generates IAM policies procedurally seems like a step in the right direction.

[kkapelon]

I am not a security expert by any means, but there are several stories of excess permissions that resulted in the security breaches. The last one I actually remember was here in HN, and I think it was about a bug bounty for Facebook where a QA system could affect production. The bug bounty person "broke" production by "breaking" in the QA system.

By the way, I have no affiliation with slauth.io (just found them today as well). I just think that https://en.wikipedia.org/wiki/Principle_of_least_privilege is something good to follow in critical systems.

[lijok]

If you're trying to sell a tool, you don't justify its cost by saying it addresses "huge problems" such as "security". Lets talk material impact; how will this tool pay for itself?

[kkapelon]

Sorry, I am not trying to sell anything. I am not OP or parent poster.

If you want to hear about stories of privilege escalation there should be easy to find. I also have some on my own which I might describe in another post but essentially it was the classic - CI/CD pipeline that "thinks" it has access only to QA does a "destroy all servers" in both QA and Production because it also had access to production without knowing anything about it.

[verdverm]

Famous HN (reddit) post: https://news.ycombinator.com/item?id=14476421

"Accidentally destroyed production database on first day of a job"

[kkapelon]

I also like the "integration tests reaching production" as well https://news.ycombinator.com/item?id=27546017

[verdverm]

I think it's supposed to be like insurance. The cost of bad things happening inspires you to pay for things that give you peace of mind. I don't trust LLMs to give me peace of mind for security tasks, if anything, the opposite

[rtkwe]

It's the constant tug of war between the idealized security status where users have just enough access to do their jobs and the fact that it's hard to know the precise access you need until you get the task at which point the idealized process of review to grant access takes too long and really drags down your development pace.

At my job for example we don't have a separate support team for the ETL work we do so I have a lot of access I don't use unless things are breaking and then I can't wait for the access approval process to get added to database XXX or bucket YYY to diagnose what data has broken our processes.