Comment by kkapelon
2 years ago
> 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
2 years ago
> 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
That is the "theoretical" problem
How many times have excess permissions "actually" been the problem... versus something like correct permissions with compromised credentials?
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.
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.
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?
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.
Famous HN (reddit) post: https://news.ycombinator.com/item?id=14476421
"Accidentally destroyed production database on first day of a job"
1 reply →
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