EP162 IAM in the Cloud: What it Means to Do It 'Right' with Kat Traxler

Security.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Timothy Peacock, the Senior PM for Cloud Detection, Investigation, and Response in Google SecOps, and Anton Chuvakin, a reformed analyst and senior staff in Google Cloud's Office of the CISO. One of these days, listeners, I will standardize what my new job is in the intro. You can find and subscribe to this podcast wherever you get your podcasts, as well as at our website, cloud.google.com/podcasts. If you enjoy our content and want it delivered to you piping hot every Monday, please do hit that subscribe button. You can follow the show, argue with us and the rest of the Cloud Security Podcast listeners on our community page. You can find the link to that in our show notes, and I encourage you to check that out along with our LinkedIn page so you can catch episodes just like this one that appeared first as a livestream. Anton, what did we talk about on our livestream?

So this was a cloud security episode, and I think it's not a surprise because, hey, we have this creatively named Cloud Security Podcast. But it was actually about the very essence, the very juicy part of cloud security, which is of course IAM.

Yes.

And while I already annoyed one guest by pointing out that I thought IAM was about password changes, but this was another very fun deep identity episode with somebody who is really doing it in the field and who really knows the— well, I don't know about everything, but knows a lot of stuff, how to do it securely, how to deal with customer problems. It was super impressive from both depth and practicality point of view.

Yes.

And she gave some really solid advice that you can implement.

Yes. The advice was very doable. And there is a single line in this episode, listeners, that I think distills maybe everything we've learned on this show into a single sentence. And so with that, let's turn things over to today's guest. Today, I'm delighted to introduce Kat Traxler, security researcher, Trust on Cloud. And I think not unfair to call you a well-known quantity on security Twitter. Is that fair?

Oh, I don't know about that. I mean, I might disappoint my security followers because I tweet about plants and birds equally. So, you know, fair warning, if you expect pure security content, you might get some Pictures of my birds.

I love that. With my last name, you're almost required to like birds, and I like birds. So, getting back to cloud and out of things that fly through clouds, one of our favorite things we hear people say in cloud is, you know, you're really only one IAM mistake away from a breach. Do you like that? Do you hate that? I'm gonna cast you into one of the two buckets, like or hate, one IAM mistake from a breach.

Oh, oh, I mean, it's so black and white. I mean, it's a slogan, right? Like, it's some good propaganda. And everybody needs some good propaganda, but the second you start scratching away at that propaganda, you have some problems, right? If you're one IAM mistake away from a breach, that implies you need perfection. You need to be perfect. You're not gonna be perfect. Just FYI, you're not going to be perfect. So—

I wish somebody had told me that when I was about 8 years old.

I'm having a mind-blown moment. We should have thought about this to ruin somebody's lunch who said, Hey, you're one IAM mistake away from a breach. And we should have channeled Kat and said, dude, that's false. Reason. That's really cool. I'm sorry for interrupting. I'm just impressed.

So, say more about what you mean there, Kat. That's interesting. Yeah.

I mean, the slogan rallies people around this really good thing to do good at, your identity and access management architecture, your system, your platform. But If you're one IAM mistake away from a breach, what about your network controls? Like, they have a say in your breach. What about your detective controls? There are more controls than just your identity layer. And if all you're relying on is your identity layer, then I guess maybe that's true. But you really need to take this— this is my favorite line that I've ever been taught— belts and suspenders. I don't know if you've ever—

Uh-huh.

Yeah, yeah, yeah.

So, like, if all you're saying is we need to be perfect at IAM, otherwise we're going to be in the newspaper and we're all going to lose our job, that's a losing proposition. That's a, that's a low morale kind of a statement because your belt is IAM, your suspenders are your network controls, and your other belts are your detective controls. There's more at play than just IAM.

I really like that answer because it leans into the, like, security is a team sport mentality and away from the defenders only have to get unlucky once sort of thinking. I like that. So, how do you help people put together their belt and suspenders? How do you help them coordinate their outfit in cloud? What's the— how do you help people with that? Or in general, what should people think about doing?

Yeah. All right. So, identity, identity, identity. Sure. Identity is everything. But What are you thinking about? Like, are you thinking about, would you be able to tell if you were breached? Would you know? Are you testing to know if your detective controls are correct?

Mm-hmm.

So, I mean, when I think about how to help somebody, I think about, what's your, like, holistic plan for protecting your assets? Have you identified your assets? Do you even know what they are? Do you know what the important ones are? Once you know what the important ones are, then you can protect them. Okay, IAM network. Once you've been able to identify them and protect them, okay, can you detect something that's gone bad? Again, it's holistic, it's a team sport. One of those can fall down, and the other ones can prop you up and prevent you from being in the newspaper.

I like that.

So, it's basically going back to, well, I think asset management and asset discovery obviously comes up because ultimately IAM won't save you. if you are not covering the assets you don't know and all that stuff, like the usual step zero, right?

And it's such a fallacy too, because I've worked in security engineering, I've worked on that protective control side. And you can get in this mindset of, like, we just have to be perfect. We just have to get all the roles scoped down to have the least privilege possible. And this can be this, like, we're chasing this ultimate least privileged, shining moment on a hill, you know, and we just get into this mindset of like, we're gonna lease privilege till we can't lease privilege anymore. And it's like, I'm glad that's somebody's job. And I'm sad that somebody's obsessed with that. But also, if that fails, when that fails, there's more to the story.

That actually makes sense. And I think to me that it almost like sells the detection to people who are convinced that they can lease privilege to the max, and then be done somehow. Yeah.

Yeah. And it's contextual too, like, like least privileged, least privileged, least privileged. But like, would you know an overprivileged role by looking at it?

Would you know one out of 40,000, which is overprivileged? Not only would you know if you have unlimited time and one role in front of you, maybe the answer is yes. But if you have no time and millions of roles, well, thousands of roles, then probably likely the answer is no.

And if you have thousands of overprivileged roles, how do you know which one is most important to fix next?

That's a good put-down to people who are overly obsessed about least privilege. I love it. I mean, that's the second line I love. So it's not about lines, but like, this is good. Okay. So let me switch to— I kind of realized I wrote the question. Actually, I woke up with that question today. I'm realizing now that my second question is kind of the same as the first question. But the backstory goes like this. I've been given some advice on cloud to, say, security operations people, SOCs, who are kind of obsessed about detection. And I would tell them that if you are entering cloud from the pre-cloud days, you have to get IAM right. And you have to kind of know IAM, you have to do it well. But I never really in my head got a clear picture about, like, well, what do you mean right? Like, is it perfect or is it, like, right enough? So, if somebody says in the cloud, you should pay more attention to IAM or you must do IAM right, what's the first thing that comes to mind? I know it's not least privilege. I get that part. But what is it?

I find it so funny that I'm like playing this devil's advocate role, like seemingly against IAM, but I feel that when people say they need to get it right, and I'm using like my fingers to do air quotes for people who aren't watching, I'm doing the right, like define to me what right is because it's contextual. I'm gonna also challenge you. I'm like, if I showed you a role of somebody, I don't know if you could tell me if that is truly overprivileged, because that privilege is going to be dependent. They could be a privileged user, and we don't know until we've identified— I'm going to, like, NIST Cybersecurity Framework shit— have we identified who needs access to what, when they need access to it, from where do they need access to it? Doing it right is a much more complicated question, and it also involves, like, how do you know What really is privilege? That's like a very amorphous question. Years ago, when I was like diving into this about like, I'm gonna define privilege in Google Cloud, a very senior architect was like, good luck with that. Because it is so amorphous about what is privilege.

Mm-hmm.

It's contextual. It depends on who's doing what to what asset. So, you need, Doing IAM right, you need to do all those NIST framework identify pieces first.

Hmm.

That's profound and sort of like obvious in a profoundly non-obvious way.

Yeah, it's super simple. It's, it's, it's so simple, it's kind of dumb.

So, what you said there though makes me wonder, you, you said it was amorphous on GCP. Does that mean it's less amorphous on other clouds? We've got the next question is literally, how have you seen the CSPs take different approaches to IAM? But that's actually what I want to know about now. So, so that question, please.

Yeah, I mean, I think the question about privilege is very amorphous, like, across the board because of, like, the contextual piece. But between the different CSPs, they take this very different approach to architecture, which is, I think, what you're getting at, is like, how is resource management? How does a bill become a law? How does Bob get access to a bucket?

Yeah.

How does that happen? Between AWS and GCP, incredibly different. I mean, it couldn't be more different.

So, give our listeners who maybe aren't familiar with the 2 things just the quick version of how a bill becomes law on each one. And maybe without, you know, a jaunty dance about Capitol Hill. Okay.

I'll try not to do this in song and dance, right? In AWS, you can have— there's an extremely complex evaluation scenario where you can consider resource-based permissions, identity-based permissions, both. So, that's like, I'm assigning Bob permissions, or I'm assigning permissions on the bucket, like, who can access the bucket.

Mm-hmm.

Those are 2, like, super different constructs that are at war against each other, are fighting each other in AWS constantly. There's more to the story around why the evaluation's so complex, because you can get into conditions, you can get into session-based policies, you can get into lots of things. But at GCP, we only have resource-based policies to contend with. You don't have this war between resource-based and identity-based policies.

Which is better?

Well, I mean, I have my opinions.

I'm not— No, no, no. It's a genuine question, by the way. It's not— we are not trying to like, let's steer cats to saying Google is amazing. No, no, no, no. We are— I'd be legit curious.

I'm not trying to shill GCP. I'm really curious.

Legit. I mean, complexity is the enemy of security. Google Cloud had it right from the beginning. They have it right because of the simplicity. They have it right because of some opinions in their architecture that piss people off sometimes. But I would say, you know, there are fewer knives in the drawer of Google Cloud, which sometimes people want to carve a fancy steak, you know, but I'm saying, no, too many knives, you're— there's too much complexity involved with the AWS drawer of knives.

So, I'll agree hard with the predicate of Simplicity is the ally of security, complexity is the enemy. I'll pass on agreeing about GCP versus AWS in the concrete, but I agree with where you started from, for sure.

Yeah. My opinion is strictly around identity architecture, right? We could argue who's got the better compute or pricing model. I have no opinions on that. I have not dived deep on it, but strictly identity architecture, strictly the model by which how a bill becomes a law, Google Cloud has a very opinionated approach. They have a very strong resource-based hierarchy that people can leverage to their advantage. Google Cloud has a lot of hodgepodgey approach, I would say, things sort of wedged in there that add complexity to the evaluation of the ultimate decision of thumbs up, you can access it, thumbs down, you can't.

Yeah.

That complexity is dense in AWS. As a result of kind of shoehorning in different capabilities over time.

But does it, as a strange side thought from this, does it actually mean that there would be a specific type of a mistake or a pitfall that affects the migrants from A to B or from B to A, either from us to Amazon or from Amazon to us? There would be specific, there would be certain mistakes would be more likely in IAM land, right? Is that too weird to ask or not?

No, that's not too weird at all. I mean, I think, like, Google Cloud suffers from, like, the number 2 cloud syndrome, where most people learn cloud on AWS.

Yes.

Most people learn it the hard, complex way, in my opinion. And so, when they move over to Google Cloud, they're not familiar with the power of the resource hierarchy and the power of inherited permissions. So, that's a very unique... problem in Google Cloud, that unique error that people make, is not recognizing that inheritance model for permissions, which totally does not exist in AWS, which I believe is the preferred way to do permissions, but AWS just doesn't have that construct.

So, that's actually fascinating. It's almost like a topic for a mystery movie or something. Like, one model is kind of, quote unquote, better, But most people learn the other, and they come into the better model while learning the worse model, and then they try to turn the better model to the worse. Okay, maybe not a mystery. Okay, maybe I'm pushing it too far.

Anton, you watch some weird movies, man.

Okay, there's that.

Let's collab on this murder mystery because I've been thinking of it as well. Like, you know, all of a sudden, there's this meeting, and people are like, oh, well, we wanna do this one access pattern to match AWS, but you know, no, it's gonna open up new knives. And I know I can, I can actually see a drama happening with this.

Yeah.

And it's, I think that the term footgun officially shows up in some of our documentation internally. So I guess I can say footgun. So it's almost maybe not even who has more guns, that gets too militaristic quickly, but who has more footguns, who has more things that actually specifically shoot your foot. I think that sounds like the metric to use.

Absolutely.

And listeners, if you're not familiar with the phrase footgun, it means to shoot yourself in the foot or to cause self- harm trying to do something useful that ultimately doesn't do something useful.

Correct. Yes, that's exactly it. And I think that it's also kind of like a gun optimized for shooting your own foot as opposed to for actual whatever purposes. So, okay, take this metaphor out. Sorry.

I think the reason why I use knives and drawers is because you think like, oh, a knife you can use to butter your bread. You could— like, they're useful. Clearly there's a use case. But you could also injure yourself.

Right.

Totally.

I agree. So maybe it's a foot knife. I think I like that a lot.

Foot knife.

So, so fine, ignore me. In any case, back to the serious question. Yes, thank you. So people still make those, you know, abysmal mistakes, not just like regular IAM mistakes because of challenges. I'm trying to figure out, like, do you have a take on why do people still screw up IAM? in the cloud specifically so badly after essentially years of trying? Cloud has been around for what, decades at this point? Well, not quite 2, but more than 1. And people still make abysmal mistakes, specifically with access and privilege. Do you have any philosophical or maybe practical take on that? Why do people do it?

I am full of philosophy, Anton. Like, I sit alone at night not sleeping, and I'm just thinking like, why the heck? Yeah, like, I've never known anybody to get a, like, perfection trophy in security. Like, you never know, like, here's, you know, your 1,000th day without a mistake, because that's not what security is about. Security operational in industry, in the trenches, security is not about perfection. It's about enabling the business. And the business is going to do what the business does. Acquisitions, M&A, enabling some crazy features in order to drive revenue and value for the customer. And security is there to try to mitigate that as much as possible. In hindsight, that might look like some crazy— I'll use air quotes— crazy stuff. But really, all we're trying to do is trying to enable, in the most secure way, some wild stuff the business needs to do.

Hmm.

And I'm not here to judge whether or not the business needs to acquire a company still running XP. Okay, they've decided to. What we need to do to mitigate that is what we need to do. Is that going to ruin my perfection score? Probably. Hmm.

I really like this answer because it reminds me of something that I think Rick was saying about the importance of separation between security and business decision-making, and how security really does exist to help the business do what it needs to do in a way that's secure. I think that's a great answer.

I love it as well. I mean, I think that that's also, it does shine a light on the mystery because there is still a mystery of like people making it, going bad specifically in this area versus say NetSec. Like we are not having a podcast on like, why are people screwing up network security so badly? They do, by the way, but it's just not a thing to discuss it. Or I don't know, something else, endpoint security. But for IAM, it's sort of a thing to discuss IAM mistakes.

Is that because we've just gotten used to people screwing up network and endpoint security and we've accepted that they're hard and IAM is new and we think, Oh, this new thing, it should be easy, and eventually we'll figure out, no, it's hard just like everything else?

No.

Layers.

Layers.

Layers.

Yeah. Okay. So, maybe we can pick on kind of a related topic, which is resource hierarchy and resource management.

You're talking my core there, right? Like, that's what Google Cloud's got that AWS doesn't. And certainly Azure also has that as well, but I try not to think about Azure.

That's fair.

Yeah. malicious reasons. I just feel that I only have a limited amount of RAM in my brain. And if I were to add Azure things, I'd have to move out GCP or AWS things. And so, I just try not to add any Azure facts. But I am aware that they also have resource management and hierarchy, and they have these 2 really important properties of a resource hierarchy. which is the ownership of resources, right? Like, your project is owned by your folder, your folder is owned by your organization. All these resources have parents, one direct parent, and then multiple children. So, you can use that property as a guiding principle when creating a hierarchy. And then, the second property is policy inheritance, either your deny policies around your organizational constraints, right?

Hmm.

What do you want to prevent Or specifically have an allow list around? What do you want to constrain? And then your policies around permissions. What do you want to grant access to at the project level or at like a specific compute or at the folder level? So all of these permissions are going to flow down, never up, down. And you can use this power, then have that in mind as you're creating this hierarchy.

That seems so logical and sensible when you lay it out like that. How could anybody get that wrong?

Well, we are back to I am is the easiest thing ever. Everybody should get it right since 1994, maybe. I need to have a '90s joke.

So, yeah, I mean, you're— a lot of the times you're just asked to do it before you know. That's the thing. You're asked to scaffold it out before you really know what's going to go on. The good thing is, is that these things are flexible. They're not set in stone. You need to revisit them constantly as you add new lines of business, as you find scale, as there's some organic growth in a corner and you're like, this is not looking right. So, yeah, you're not going to get it right the first time. You're going to have something kind of basic scaffolded out, and it's going to be this constant revisiting of like, do we have the right structure to support what we need to do?

That makes sense.

So let me ask you, let me go to an area which is kind of scary and possibly fun. And, you know, it's the area of sins. So sometimes when we observe what users do, we kind of realize that what they do is kind of constrained, defined, predetermined, or maybe even predestined by what the creators of the systems, well, have created. Are the identity sins of cloud IAM users truly the sins of whoever built the system, whether it's, well, us at GCP or our partners, so to say, at AWS or others? How does it continue to manifest today? This is interesting, hopefully, not just to you, but to everybody.

I also find it really interesting, like, the historical, not only the historical nature, but, like, How is their identity architecture then informed with how we use the system? In AWS, they have the highest-level container that they have is the account. That was a design decision, who knows at what point, but this is what you got to work with.

Mm-hmm.

So, everything is based around just assigning identity-based permissions to users or roles at the account. It goes back to what I imagine, you know, Amazon as a little bookseller was. You know, I imagine that they were a little bookseller, and they had this account, and they had users who had permissions to access things in that account. And now, how many years later, we still just have the account as the highest-level resource container. We do have this thing called organizations, but that's really just like a specially designated account. So, it doesn't have the power of a hierarchy. So, anybody who tells you they have a hierarchy, just, you know, lies, lies, lies, lies. Lies.

Lies, lies, lies, lies.

Are they confused? Maybe they think they have a hierarchy and they're not lying, they're just wrong.

Correct. Correct. Yeah. Yeah. They don't know a real hierarchy in Google Cloud. Where you have these multiple tiers where you don't assign permissions to Bob, you assign permissions at the levels, at the resource level. Which, as people migrate from AWS to Google Cloud, can get people confused. Yeah.

You know what's funny about this? This feels like the one case where I've seen the opposite of Conway's Law. Google is a very non-hierarchical organization. And I've never worked at AWS, but I have the impression that there are A little bit more hierarchical than we are. So, it's kind of funny that you would have these orgs not do the Conway's Law thing of reflecting their structure in their products.

It is interesting, isn't it? It's just like a very flat identity architecture for AWS, but in Google Cloud, you can take advantage of the properties of that hierarchy.

Which in theory should reduce the number of scripts you make if you can do, you know, the structure correctly, right?

Yeah.

Yeah.

Yeah.

Okay. So, I hate to do this because Anton and I both love IAM as a topic, and you clearly do, and I think we could do this all day. I have to ask our traditional closing questions. One, do you have a tip to help people improve their IM outcomes? And 2, do you have recommended reading?

And before we close, I want to stick my nose in there for a second. We are skipping one question because of time, but this is kind of my favorite question. So in that answer to that question, you have a really good tip. So can you perhaps reuse this tip for the closing question?

Yeah, I was going to.

I'm sorry, I'm being like—

Anton, this is beyond leading the witness.

I know, I know. I'm sorry. It's kind of hard. It's not our fault that we cut this back.

I got you, Anton. Like, this is— I wasn't gonna let our audience go away without knowing. If you only have to do one thing in Google Cloud, okay, this is like literally everything around IAM, just assign that role at the lowest resource level possible. You could spend all day long fretting around between 2 roles. Oh, between this managed role and this managed role, which is more or less privileged? You know, save, take time back. Take that time back in your life and just assign it, scope it down, assign it to the lowest resource level possible, and call it a day. That's the best thing you can do for yourself.

I love that. Maybe that'll be the title of the episode, Assign Roles at the Lowest Level Possible.

Yeah, perfect. Add it to the metadata.

Yeah. And then, recommended reading.

So, I love recommending a book that was recommended to me by a cool guy named Welcome, Dr. Starr. Complexity: A Guided Tour. It's a philosophical book diving into complexity throughout nature. And when you read that kind of with an eye and ear towards complexity in systems and IT systems, you're like, oh, wow, there's some similarities between, like, how ant colonies organize themselves and how, like, a complex cloud environment has organized themselves. Complexity: A Guided Tour.

I love it. That's great. Kat, thank you so much for joining us today. I suspect we'll have you back on the show to talk about this at greater length because this was delightful. Thank you.

This is too amazing. That's too amazing to not repeat.

You folks are awesome. Thank you for having me. Aw.

And now we are at time. Thank you very much for listening and, of course, for subscribing. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever else you get your podcasts. Also, you can find us at our website, cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes. You can follow us on Twitter, twitter.com/cloudsecpodcast. Your hosts are also on Twitter, @Anton_Chuvakin and _TimPico. Tweet at us, email us, argue with us, and if you like or hate what we hear, we can invite you to the next episode. See you on the next Cloud Security Podcast episode.

Bye.