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

101–110 of 125 posts

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

#101

Post by coredog64 »

lovehashbrowns wrote: post #16
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…

I agree that "coordination is hard" is the root issue here. For things I develop, it's easier for me to specifically say what permissions the IAM roles need, and I can get them down to least privilege. Then sometimes I need to onboard an application written in a language I don't know, and it's a beast of an application. I ask the developer what permissions it needs, and they say "I don't know" but give me a full admi…

Time will tell if this works out for me, but lately I’ve been explaining the risk to the developers’ manager, that I wouldn’t do this, but if they assume the risk that I’ll do what they ask. I figure eventually we’ll get compromised and/or some misbehaving app will take down production and then people will pay attention.

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

#102

Post by peterwwillis »

Make IAM part of the design of the application. If you need to use AWS API calls, then you need your app's design architecture docs (you have those right?) to list the IAM permissions needed to do each thing, and stuff that info into ADRs, and link to some IaC that you used to stand up your dev/test environment. All of this creates 1) formal IaC used to apply the permissions, 2) formal documentation of what functions need what permissions. As a final step during development, write tests that verify the IAM permissions are as expected.

You will of course need some way to scale this later, but as long as an artifact of your build pipeline is auto-generated IAM policy jsons, an org-wide security team can analyze them with automated tools and remediate as needed.

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

#103

Post by coredog64 »

k__ wrote: post #68

FaaS helps here. It's easier to reason about the access one function does than all the infra a monolith needs to access.

You’d think that, but Friday I just helped a dev team deploy a Lambda function that had full capability to update any Lambda in the account. The devs didn’t know anything about how the app worked, since it was a drive-by from the architect. He, in turn, just grabbed an AWS blog post, confirmed that it worked in his personal account, and called it a day.

Also, since the devs don’t know IAM, every resource request is a wild card. A function compromise would allow deployment of a new function that could extract every SSM secret, Cognito identity, and S3 object.

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

#104

Post by Spivak »

mlthoughts2018 wrote: post #65
chousuke wrote: post #29

Earlier quoted context omitted.

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, r…

I have never seen a compliance team make the choice to just break production unless they (and by proxy you) are in hot water with auditors.

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

#105

Post by Aeolun »

brendoelfrendo wrote: post #88
gray_-_wolf wrote: post #78

Earlier quoted context omitted.

In our company we went the other road. We have the developers write the policies (since I mean, they know what their app needs) and test it in dev environments. After that, ops guys step in during code review to check for too broad allow in the policies. So far it seems to work in acceptable manner.

This sounds like a good process, but it depends a lot on the relationship between dev and ops... I've seen too many dev shops push against changes requested by ops or security because their main pressure is to ship features fast. And then it turns into a management fight and whoever has the more influential management gets the final say while the other side is forced to grumble.

We have machines to tell people their policy (in dev) is insecure and will be deleted in 30 minutes.

Not really easy to argue with the machine.

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

#106

Post by ldoughty »

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…

Some steps I take to mitigate:

1) put ec2 servers I can't properly IAM lock down in dedicated accounts separated from all other things

2) don't let users create the things.. let users take actions that result in what they want by a programmed set of commands that is peer reviewed (e.g. spin up an EC2 instance with specified config/user data by an MFA'ed credential.)

3) user accounts are created manually (we have A LOT, like every damn security talk I've ever been to, says to watch cloud trail and enforce bad action by writing reactive scripts. We enforce before the action is taken, essentially. This works for better for EC2, which, in my opinion, is HORRENDOUS for least privilege.

Serverless items, while sometimes requiring more permissions than I'd like or expect, is far _less_ common to throw a requirement for "Create" on resource '*'..

Lastly, I give developers a playground to learn in that is entirely disconnected from user data. It has some mocked false user data and structures, and it's own isolated domain so the infrastructure can be explored

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

#107

Post by staticassertion »

zymhan wrote: post #99
staticassertion wrote: post #82

Earlier quoted context omitted.

Sure, CF is garbage, I won't try to argue otherwise. There's this though: https://www.hashicorp.com/blog/cdk-for-terraform-enabling-py...

Wonder what Pulumi will do to stay relevant now.

Pulumi probably has a better story around multicloud, but yes, it does seem like it's going to be difficult to differentiate.

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

#108

Post by unixhero »

dopylitty wrote: post #56
ENOTTY wrote: post #18

AWS Zelkova is in theory supposed to find these sorts of issues. I haven't used it, so I'm curious what others think about it.

I went to a talk about it at Re:Invent and it does seem to solve the issue in theory but the service based on it (Access Analyzer) seems to only apply to very limited use cases.

Is Re:Invent worth the trip? For me the cost would be formidable.

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

#109

Post by thayne »

gray_-_wolf wrote: post #78
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…

In our company we went the other road. We have the developers write the policies (since I mean, they know what their app needs) and test it in dev environments. After that, ops guys step in during code review to check for too broad allow in the policies. So far it seems to work in acceptable manner.

In my company, developers write policies, but they have to be approved by someone with ops expertise (usually me). And the policies are often either too broad, or not sufficiently tested, and missing permissions for things it needed. Sometimes the same policy has both problems. I don't blame the developers. You can hardly expect every developer to become an expert on AWS's IAM system. Especially given how inconsistent it can be.

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

#110

Post by thayne »

It doesn't help that AWS IAM is often confusing and inconsistent. And some permissions that should have resource-level granularity and/or support conditions, don't. To be fair, this does seem to be improving somewhat, but even some newer permissions aren't able to be controlled in as granular a way as I would like.
Post reply on HN