Launch HN: Slauth (YC S22) – auto-generate secure IAM policies for AWS and GCP • Hacker News Board

Re: Launch HN: Slauth (YC S22) – auto-generate secure IAM policies for AWS and GCP

#51

Post by verdverm » Mon, Dec 04, 2023, 3:56 PM UTC

candiddevmike wrote: post #33

DanielSlauth wrote: post #3

Earlier quoted context omitted.

Do you think humans are doing a better job? Research shows that 95% of the permissions granted to users aren't used which creates huge problems and is a reason for spending millions in security tools. Why not use Slauth and other checks such as policy simulators to get tightened policies pre-deployed

AWS and GCP already provide tools to show excess permissions...

The pain there is often a pre-configured role with a slew of permissions was used and you actually need to craft a new role with the right permissions.

I wrote some code once to fetch all those preconfigured role permissions and then present them in a more digestible way

Re: Launch HN: Slauth (YC S22) – auto-generate secure IAM policies for AWS and GCP

#52

Post by lijok » Mon, Dec 04, 2023, 3:58 PM UTC

How are you dealing with invalid policies generated by GPT? For example, in your loom video and the gif on the website, the resource for the s3:PutObject permission is incorrect: it should be "arn:aws:s3:::my_bucket_2/*" not "arn:aws:s3:::my_bucket_2".

Does this support resource policies? If so, how are you ensuring serious security vulnerabilities such as confused deputy are not introduced by this tool?

Re: Launch HN: Slauth (YC S22) – auto-generate secure IAM policies for AWS and GCP

#53

Post by bsamuels » Mon, Dec 04, 2023, 4:00 PM UTC

At my previous job we used GCP and went through so much effort/tooling to try to fix IAM. We definitely would have given this tool a spin. Ignore the HN flashmob.

Another use case you might run in to as you talk with more clients is figuring out what developer IAM roles need to be. This was the far bigger problem for us as we had a ToS that restricted employees from viewing/accessing user data.

Re: Launch HN: Slauth (YC S22) – auto-generate secure IAM policies for AWS and GCP

#54

Post by Eumenes » Mon, Dec 04, 2023, 4:00 PM UTC

The problem with IAM from my experience is it's never truly owned by a single entity. If you have an IT team, its sometimes them. Sometimes its devops, sometimes security. However as a startup grows, the owners change. Policy is rarely developed from the ground up and more patchwork to accomodate teams or timelines

Re: Launch HN: Slauth (YC S22) – auto-generate secure IAM policies for AWS and GCP

#55

Post by tjpnz » Mon, Dec 04, 2023, 4:04 PM UTC

justrealist wrote: post #49

verdverm wrote: post #2

Repost: https://news.ycombinator.com/item?id=34038663 (11 months ago) > We employ Large Language Models (currently OpenAI GPT-4) For IAM, this seems like a disaster waiting to happen. Combining hallucination problems with security settings is not a path I would consider

The space of "real" options in IAM is small enough that hallucination is not a real problem. Anecdotally I've used copilot to help write a lot of IAM polities in Terraform and the accuracy is basically 100% already.

Same could be said for ECS container definitions yet ChatGPT will happily give you a set of parameters which don't exist.

Re: Launch HN: Slauth (YC S22) – auto-generate secure IAM policies for AWS and GCP

#56

Post by slalmeidabbm » Mon, Dec 04, 2023, 4:07 PM UTC

lijok wrote: post #52

How are you dealing with invalid policies generated by GPT? For example, in your loom video and the gif on the website, the resource for the s3:PutObject permission is incorrect: it should be "arn:aws:s3:::my_bucket_2/*" not "arn:aws:s3:::my_bucket_2". Does this support resource policies? If so, how are you ensuring serious security vulnerabilities such as confused deputy are not introduced by this tool?

That's a very good example of the type of hallucinations that can happen, we still need to develop a way to double check that the generated policies are indeed valid and hopefully find a way to simulate them.

As is stands, Slauth doesn't support resource-based policies.

Re: Launch HN: Slauth (YC S22) – auto-generate secure IAM policies for AWS and GCP

#57

Post by debarshri » Mon, Dec 04, 2023, 4:09 PM UTC

verdverm wrote: post #2

Repost: https://news.ycombinator.com/item?id=34038663 (11 months ago) > We employ Large Language Models (currently OpenAI GPT-4) For IAM, this seems like a disaster waiting to happen. Combining hallucination problems with security settings is not a path I would consider

It feels like taking one security problem and creating another problem.

Re: Launch HN: Slauth (YC S22) – auto-generate secure IAM policies for AWS and GCP

#58

Post by callalex » Mon, Dec 04, 2023, 4:14 PM UTC

Can someone explain to me what is so difficult about writing security policies? Are people really deploying services in production without understanding the upstream and downstream dependencies of the service?

Also at cloud-scale 95% accuracy is completely unacceptable.

Re: Launch HN: Slauth (YC S22) – auto-generate secure IAM policies for AWS and GCP

#59

Post by [deleted] » Mon, Dec 04, 2023, 4:19 PM UTC

callalex wrote: post #58

Can someone explain to me what is so difficult about writing security policies? Are people really deploying services in production without understanding the upstream and downstream dependencies of the service? Also at cloud-scale 95% accuracy is completely unacceptable.

[deleted]

Re: Launch HN: Slauth (YC S22) – auto-generate secure IAM policies for AWS and GCP

#60

Post by nutbear » Mon, Dec 04, 2023, 4:20 PM UTC

callalex wrote: post #58

Can someone explain to me what is so difficult about writing security policies? Are people really deploying services in production without understanding the upstream and downstream dependencies of the service? Also at cloud-scale 95% accuracy is completely unacceptable.

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).