Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IAM is hard – Thoughts on $80M fine from the Capital One Breach

twitter.com

Post reply on HN
Print view View original

61–70 of 125 posts

Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach

#61

Post by nine_k »

The original thread is good, because it states the problem and links to a number of tools which mitigate the problem in various ways.

I'd say that IAM is a too low-level interface (or language). It makes it hard for engineers to think at the convenient enough level of abstraction correctly. (Imagine writing e.g. a C++ compiler in 6502 assembly.)

An obvious solution would be to introduce a tool / language which allows to operate at the level engineers are used to think at, validate the structure, and analyze the potential breach impact for every resulting piece. (Sort of like, again, a compiler. Or at least something like Terraform as a first step.)

A few steps in that direction are already done with the tools mentioned in the original thread. But I suspect that a lot can still be done in this area, bringing fame and potentially money to those who would come up with a tool which becomes widespread. (I mean, it could be a wide project / startup idea for those who understand both IAM and formal methods well.)

Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach

#63

Post by mxz3000 »

nine_k wrote: post #61

The original thread is good, because it states the problem and links to a number of tools which mitigate the problem in various ways. I'd say that IAM is a too low-level interface (or language). It makes it hard for engineers to think at the convenient enough level of abstraction correctly. (Imagine writing e.g. a C++ compiler in 6502 assembly.) An obvious solution would be to introduce a tool / language which allows…

This is exactly the sort of problem solved by cdk: https://docs.aws.amazon.com/cdk/latest/guide/home.html with cdk you generally don't have to mess with IAM constructs, and can just use the provided APIs to setup necessary permissions (and those permissions are always as narrow as possible by default)

Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach

#64

Post by ethbro »

xyzzy_plugh wrote: post #46
mesofile wrote: post #8

My general experience with crafting IAM policies is very reminiscent of SELinux, in that it's very difficult to work agnostically while adhering to a principle of least privilege. Especially given that this kind of task is often done by admin/ops people, one typically can't know in advance everything that the app might need to be able to access in order to work correctly. The process of discovering this is: try runni…

For AWS integration with my commercial tool, I am considering having it inspect it's own permissions and loudly tell you it's misconfigured if you give it permissions to do anything more than what it minimally needs. I wish more tools did this.

I feel like this is the real base problem here.

There's an incredibly broad set of permissions (at the cloud or OS level). Any app / tool may be written to use any subset of those. And what it uses is rarely documented (because developers don't see IAM security as a primary feature, outside of apps intended for use in regulated environments).

Without automation, this thus requires continual reverse engineering, which is never a healthy, sane long-term solution.

This should be fixed on the product / app side, where folks are much better placed to dump "I need this, and only this" in machine-readable form.

Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach

#65

Post by mlthoughts2018 »

chousuke wrote: post #29
mesofile wrote: post #8

My general experience with crafting IAM policies is very reminiscent of SELinux, in that it's very difficult to work agnostically while adhering to a principle of least privilege. Especially given that this kind of task is often done by admin/ops people, one typically can't know in advance everything that the app might need to be able to access in order to work correctly. The process of discovering this is: try runni…

As one of those "admin/ops" people with experience of fixing terribly set up systems, a common issue is that users just can't tell the difference between systems that work insecurely and systems that work securely, but they will immediately notice if a system does not work because the security policy is too strict. You get the best security when everyone is involved in the security design from the "ground up", but qu…

I always find the lack of communication goes the other direction. Security and compliance teams just enforce an IAM policy without talking to application or product teams. It gets rolled out and lots of things break, even things that have legitimate needs to work the way they do and have considered security best practices heavily already, and then security and compliance just throws their hands up and says too bad, refactor it from first principles regardless of the level of effort, staffing requirements, competing priorities, etc.

Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach

#66

Post by shadowgovt »

In my experience, the hardest thing about this whole space is the number of developers who don't understand what the problem is until it is costing them $80 million dollars.

Limiting blast radius, for example. Why does your threat model include the possibility of one of your applications being compromised and using its credentials to do desired things to other applications? That implies your programs are buggy. And clearly, your programs aren't buggy; you're using best practices. How could they be?

Even in professional development in big name companies, this is a surprisingly pervasive default attitude. Appropriate level of paranoia is something that I think has to be taught.

Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach

#67

Post by freeone3000 »

john-shaffer wrote: post #13

Those problems seem to come from the separation of the IAM admin from the developer. I'm coding a server now. My IAM roles are defined in a template, and I just add new permissions to the template as I need them. My code has the bare minimum permissions that it needs, and it doesn't seem at all onerous for the benefit it provides. So I think the problem is less "IAM is hard", and more "coordination is hard". The one…

We've managed to mitigate this by doing cloudformation launches manually with the developer's own credentials, and have each resource take on the IAM role it needs. (Since you need sts:AssumeRole for CFN creation anyway, it's not really useful to limit the cloudformation role, it's going to be essentially admin in any event.)

Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach

#69

Post by techntoke »

The sooner that these cloud companies work to create a common open API the more secure and better off we'll all be. The idea of spending so much time being specialized for a particular cloud provider is stupid, when you've built your tech career not knowing actual technology but just a proprietary overlay that doesn't even resemble anything useful outside of the organization.

Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach

#70

Post by jedberg »

FYI for anyone in the same situation, Netflix built some open source packages to solve this:

https://netflixtechblog.com/introducing-aardvark-and-repokid...

The idea is that the default policy on new things is deny all, and then it monitors cloudtrail for privilege failures and reconfigures IAM to allow the smallest possible privilege to get rid of that deny message.

Post reply on HN