EP127 Is IAM Really Fun and How to Stay Ahead of the Curve in Cloud IAM?

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 Product Manager for Threat Detection here at Google Cloud, and Anton Chuvakin, a reformed analyst and senior staff in Google Cloud's Office of the CISO. 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 and argue with your hosts on LinkedIn as well, where coincidentally today's episode first aired as a livestream. If you want to get in on the future livestreams, please do follow the show and get the heads up when we're doing these. You'll find this episode on YouTube. And Anton, what exactly are we talking about today? This is special because it took us Over 120 episodes talking about cloud security to get to maybe the most central thing in cloud security.

Yes. And I think I would say at a whole bunch of episodes, maybe in dozens of episodes, we mentioned the very topic of IAM, identity and access management, as being key for the cloud, being central to the cloud, being error-prone in the cloud. We touched on some aspects, I think, in the TruffleSec episode a little bit, but ultimately, We've been rambling about how I am is important, but we never had an I am episode. And this is actually my fault because I have an I am phobia.

Ah, yes, you do.

Since my Gardner days, I had an I am phobia. So I had to overcome my phobia.

I'm proud of you.

It took a bit of work. Well, 2 years.

Took 2 and a half years of work, listeners. I think one thing that really stood out to me about this episode was that it wasn't new. I've always thought of Cloud IAM as this new emergent challenge for security teams. And what our guest makes very clear today is that it's in fact not. And so perhaps with that teaser of nothing is actually ever new in our industry, let's turn things over to today's guest. Unlike our usual practice, I'm going to let Anton do an introduction today because he ever so sneakily said before we started recording, I have a joke I want to play on our guest.

Actually, I want to apologize Because I used to call Ian's team at Gartner a password change team. Because in my very narrow-minded mind, I associated the entire domain of IAM with password changes. So I think this is my time to come clean and say that I'm sorry.

That's like equating, like, a 3-star chef with the person that made the meal that goes on your flight to, you know, somewhere horrible. That's basically like equating the worst possible experience with the best possible experience. So like, yay, all right.

Yes, correct. And unfortunately, I made a second mistake of repeating this joke roughly 20, 30 times during my tenure at Gartner. And it stopped being funny after the zeroth time. So— Wow.

And yet I still said yes to them.

What were you thinking?

I don't know.

I don't know. And so maybe with that, we should do our introduction. Today we're joined by Ian Glazer, formerly, very recently, SVP of Products at Salesforce, currently, and I think into the future, co-founder of IDPro.

That's right.

So I think the first question honorarily goes to Anton since it's his start of atonement for that horrible set of jokes he made.

I just want to set the record straight and tell us why the entire domain of IAM, identity management, identity and access management, is in fact exciting.

Yeah.

Is it?

So to me it's exciting, and I think it should be exciting to everyone because it is something with which Everyone directly interacts with and does so every day, multiple times a day. And we're all active participants. And to me, that's exciting. It's visceral. Now, that means it's visceral both in the good and the bad way. Like, the good way, hey, I look at my phone, I'm into my app. Awesome. The bad way is the, like, why the heck don't I have access to this damn dashboard? I just got to do the thing and get on with my life, right? So you're going to have to take the good and the bad.

Yeah.

Okay. So, it's a thing that we experience every day. It's a thing that comes with good and bad. How is it exciting in cloud? Because I think, you know, sure, that's exciting for a consumer, but given everything we know about cloud compromises, IAM in the cloud feels like exciting the way that a gunfight feels exciting or exposure to an ionized gas feels exciting. It's like too exciting. It's stripping away my electrons and I would like to keep them. So, how do we have the right approach here?

Partially, I think it's a function of framing, right? And let's take a little bit step back, which is to me— and I'm going to paint both of you in broad brushes. I'm going to do so lightly.

That's fine.

Which is often when I talk to security practitioners, very traditional security practitioners, they understand authentication and that's about it when it comes to identity. Again, I'm painting in a broad brush.

I see.

That framing is too narrow, right? And so, it leaves out all of the things that the market as identity and access management is, leaves all of that out. What's its relationship to digital experience? How do we actually govern access properly, regardless of whether it's on-prem or in the cloud? Makes no difference in my mind. And often, that painting of, frankly, boringness, which is legit, is the very traditional Workforce-centric, admin-centric user provisioning and access governance is, at this point, it's commoditized, it's a science. It may not mean we do the science well, but it is well understood. And so that can lack excitement in the normal way. Now, it's lack of ability, like necessarily maybe we don't do it great in certain target environments, that adds the excitement in the way you describe, which is like, oh my gosh, sudden decompression of the plane.

Yeah.

And so to me, the framing makes a lot of difference because those— if you focus along certain avenues, you're like, yeah, I get it, sure. But the same thing is true in security. Like, look, I get classic firewalls, woohoo, let's move on to something more interesting, right? So there's no difference. I think in, in some of the framing around the cloud—

I wish we could. Hmm.

The fun comes around authorization and entitlements and privilege.

Wait a second, I want to pause and absorb this. So Authentication and identity may not be dramatically exciting, but authorization is in this case.

When we're going to talk about cloud theft, because obviously we are, I think authorization certainly is, but it leaves out a whole bunch of things like customer identity access management, which is super exciting, but we can get to that hopefully.

I think this is very apt though, because Anton, how many episodes have we had with really deep security experts talking about how it's your authorization system in cloud where you get owned? Think about the whole episode we did with Dylan.

Yes. And I think this whole one breach away from IAM mistake is really, it's not only not true, but it's also, there's a lot of nuance.

But it is also true. I mean, if you have a—

It's not true in a well-architected cloud. You have a PCSA, you have a multifactor stack.

It's just a no true Scotsman.

A little bit. Okay, fine. But I'm squirming a little bit, but well, yes, I'm squirming a lot. But it's true that in a well-architected cloud, you are not one IAM mistake away from a breach. Okay, fine. Let's ask Ian. Ian knows. We don't know, Ian does.

Ian, how many Well-Architected clouds do you see on a weekly basis?

That wasn't the question.

Pass. Next question. So, hold on. I have to say that, you know, when we talk about, in the lead-up to this conversation, just, you know, like, hey, what are we gonna talk about? And thinking about identity in the cloud, I had a realization that to me, this feels very retro. This feels like welcome back to about 2008. And the reason why is it reminds me of the conversations we had about, at the time, governance, risk, and compliance applications, things that would look at complex software packages like SAP, like Oracle E-Business Suite, and look for toxic combinations of access and say, like, hey, look, this activity code means these people can cut checks, create vendors, and actually distribute cash. Oh crap. Now, what is that at the end of the day? It's a complex authorization model inside of a complex application, and the default settings may or may not be in your best interest depending on your perspective. It may be great from a productivity perspective, it may be total crap from a security perspective, if you will.

Oh, that's exactly the same problem as an overprovisioned service account.

Yes, exactly.

But worse, right? So like, you know, to the point of like cloud IAM, it's like, well, you know, whose failing is it that if I create a new default cloud storage, it's public read by default. I feel like that's not an IAM problem. I feel like that's a cloud architecture and defaults problem, right? So I'm painting an extreme example, but you get the point, which is complex systems, no matter the flavor, have complex authorizations associated with it. And there's actually, and this is where I bristle a little bit about cloud identity entitlement management, is The problem space for infrastructure as a service is actually different than the space for platform as a service, which is distinct from the problem space for SaaS.

Yes.

Yes.

That's why we had Obsidian on the show, and that conversation was totally different than what we had with Dylan.

SaaS versus— yes, I mean, pretty much for every security element.

Yeah.

Yeah.

So from a practitioner's perspective, from an identity practitioner's perspective, it's all the same problem. It's authorization and access governance. Where does it get weird? Where does it get scary? Is the, what automated capabilities are there that we can, from central management, discover how bad the morass is and then start kind of making it better?

Mm-hmm.

And in, let's say, the SaaS case, you're at the whims of the vendor to implement things like SCIM for provisioning, and that your access governance tool knows how to connect to it. But on the other end of the spectrum, the IaaS end of the spectrum, where the blast radius is, well, you know, in the olden days, I screwed up an ACL, crap, this subnet can see that subnet. It's my infra, who cares? But now it's everybody's infra, including the adversary. So those screw-ups have a way different blast radius.

Mm-hmm.

And that's where you have even less when it comes to standards, the implementation thereof, and a way to visualize them. And so it's all of the worst of host-based access control married to the worst sort of combinations of complex systems and authorization. Yippee.

Hmm.

It sounds like you're on the side of cloud has fewer layers than on-prem.

I really don't make a distinction because to me, the practice is the same. I'm gonna govern access. I'm gonna look at what is authorized. I need tools to centrally visualize that, at least discover.

Right.

One of the fundamental problems, no matter if we're talking on-prem or all the way up through IaaS, is you've got a permission, you know, blah blah underscore foo underscore group underscore 2. The hell does that do?

Yeah.

Right? Whether that is a role that is going to grant an ephemeral user in the cloud access to this piece of storage and these ephemeral functions and these other things, or it's a good old Novell file share. I don't care, right? It's the— I wanna show a breadth for all ages of listeners, okay?

Hey, we're gonna get back to dishwasher-sized hard drives in a second here. We better be careful.

So, but here's the thing. That string, what the hell does it mean?

Right.

Right? And if you assume that that meaning is static, you will get bit in the butt because someone's gonna add just like one more little permission in there. It's wafer thin. And then all of a sudden, like, your notional read-only to a file share becomes, oh, actually read all file shares. Son of a gun, right?

Read-only to everybody in the world?

Yeah.

It's read-only, but for everybody, or is it only for every employee?

You got it. So the practice is the same. It's how much tooling do we have to essentially discover, manage, and assign meaning, and then mitigate? And this is following the same arc we saw in the past in the good old on-prem ERP days, which was, You had general purpose tools, like, who can just kind of connect to things, give you a dump of, like, these people have these things, I have no idea what they mean, I don't know if it's important or not. You had specialized tools, the GRC tools, to be like, hey, this is what's going on inside of your PeopleSoft deployment. Today, what do you have? You have the CIEM type tools that are infusing meaning and taxonomy to a specialized authorization system. I know how to do this cloud or that cloud or those combinations. It's the same story, it's the same practices.

That's pretty interesting. But so wait, I want to stop you very briefly and say, so if somebody— and use my 3 AM test. So if somebody wakes you up at 3 AM and says, so in the cloud, are you one IAM mistake away from a breach? And what would be your first instinctive reaction? More yes, more no, or more shut up, it depends? Like, what would you say?

Well, all right. So, Anton, look, we share a heritage as coming from analyst firms, which means by default, the answer is yes. It depends.

It depends. Okay, fine, I figured. Yeah, yeah, yeah.

But you call me at 3 in the morning, you're like, it happened, the thing, the thing happened where we have the breach. You'd be like, my first thing is breathe. My second thing is, in my experience, the first phone call is always to the team that runs login, because no matter what is going wrong, no matter how screwy something is, no matter where the adversary is and the technique is, It's a login problem. You're like, huh?

Okay, it's almost like it's DNS.

There you go. So, the identity team is always gonna get the page. The hardest part I think organizations have is actually walking through the incident and getting to who owns the controls that need to be changed or redeployed. And the complexities of Our applications running in the cloud do not minimize those complexities in any way, shape, or form, and probably distributes ownership more so, even to the point where a lot of these things are automated processes. So now you're looking at, oh, did we patch a config that just rolled into production that made these changes? That's a very different thing than, like, call Tim, he owns the mainframe. That's a really different conversation. So yeah, it depends.

I don't want that job.

You don't want that job, that's right. Okay, that actually is very, very helpful. I appreciate it. And I think the audience would find value in this particular advice, actually. I like that.

So, Ian, I want to take a step back and ask, just real casual, what advice would you give to somebody who's recently found themselves in a position of authority or responsibility for a cloud IAM environment? Somebody wakes up at 3 in the morning and realizes, oh shit, I'm responsible for cloud IAM. What do you tell them?

Yeah. So, the first thing I would say is join IDPro. It's the professional association of identity management.

Oh yeah, what's IDPro?

Yeah, so IDPro is the professional association for identity management and identity practitioners, and it's something that I and some friends started. It's coming up on our 7th birthday this June, but it predates that. Many years before that, I've been incubating the idea of, hey, look, our peers in security, our peers in privacy, they have professional associations where they can learn from one another, they can grow together, and, and this is really important, they can get access to vendor-neutral training material. They can learn the practice and then they can go use that practice in a specific setting. Identity didn't have that. And for a $25 billion market, that's— that was crazy to me 10 years ago. I'm like, we got to fix this. So I kept asking people, is this a problem? They're like, yes. I'm like, should someone do something about that? They're all like, yeah, Ian, you should do something about that. I'm like, oh, should have seen that coming. So at any rate, IDPro, idpro.org, professional association. It's a community at the very least The power there is, it's an ultimate phone a friend, right? It's a safe space where people can be like, hey, what's the best practice around vetting that someone calls the internal help desk to do a password reset is actually an employee?

Hmm.

What do we do about that, right? That's an example of a question that just went by in Slack a couple of minutes ago. Like, it's that thing. The other thing, if you don't wanna do that, that's cool. Go to bok.idpro.org, which is our body of knowledge. And we have been curating over years articles on practice, not vendor-specific practice, mind you, but what is the best practices for these kinds of activities and what do you need to know and what's the overviews of this too? Because just like security, just like privacy, identity has a very rich, some would say arcane, set of practices that you got to understand and you just want to learn. Most people don't start as identity practitioners, right? Oftentimes they're like, "I was working the help desk, and then that meant I also did password resets." And so every two weeks, password resets. I knew it. I'd be like, "You're horrible people. I can't remember my password." And this poor person is like, "Sure. At this point, I am a horrible person. Fine, sir. Here's your password.

It's fuzzy bunny one." Hey, that's my password too.

It's weird.

Yeah.

Yeah.

And I knew it again. I knew it take two.

People start at the help desk, or they start with user account administration, like, I am just gonna pull the levers to create accounts. And, or they come from other parts of security domain, or other, just totally general operations. And so, learning the practices is really important to me. At IDPro, we run a skills survey every year. This year, the results are in. I write the report with a colleague of mine, Andrew Hindle, who is the content chair for Identiverse. And we ask a question, which is, how long does it take you To feel proficient, not be proficient, but feel proficient as a practitioner. This year, it looks like the numbers are coming in somewhere between like 3 to 6 to 8 years is the bulk of respondents say they feel proficient. Now, I will point out that 25-ish percent of our respondents say, I still don't feel proficient. Now consider that nearly, I think, a third of respondents have been in the industry over 10 years. And to me, this is great because this reflects a growing market and a changing market. Like, yeah, there are parts of identity that are less interesting for sure. I know how to do those. But what's this verified credential thing over here? Like, what's this verification and proofing stuff over here? Like, I don't know, right? So, you know, and then we see this in the security market, we see this in privacy as well. Like, things adapt and change. Like, the new frontier is gonna be like, What does security mean in a post-LLM world? Right? This is the question du jour of everybody, I guess. And we'll see that played out everywhere else.

I think that's the wrong question, but yes, go on.

You know what I mean.

It's a very popular wrong question.

It's a very popular wrong question.

It's a very popular wrong question.

But the point is that I believe if you think, I got this nailed, I'm totally good, personally, I'm like, ooh, Well, that's yikes. Like, that's not a growth mindset. That means you're not pushing, like, where you could, you know, seeing what's around the bend a little bit. And so, to me, it's really exciting that people are like, I don't know, I don't feel proficient because there are so many new things, which is cool.

Which basically led me to another epiphany, funny enough, because I was giving some presentation related to SOC and stuff, and I mentioned that in the cloud, a really good piece of advice, even if you're a SOC manager, is to learn IAM. And then I was like, yeah, yeah, yeah, learn IAM. But later on, somebody said, Anton, you're kind of right, but you're really wrong because ultimately, you need to say, keep learning IAM. Learn IAM is decent advice, but the real advice is keep learning IAM. If you look at something like GCP Identity Docs in 2019, 2021, 2023, there's a lot of learning in the difference. It's not just like learn IAM and you're done. So, to me, this was kind of a big epiphany. So, I guess you already provided advice on how to keep learning IAM as opposed to just learn it once?

I think the recognition that a lot of the classic sort of IAM things, which is authentication, administration, authorization, the 3 A's, those are practices that even amongst themselves are still advancing. And so, we see, you know, what used to be, hey, it's role-based access control. No, no, no, it's gonna be attribute-based access control. No, it's policy-based access control. You know, who knows where it goes from here, but even within that discipline, you still see change. But knowing the basics, at the end of the day, I'm gonna govern who has access to what, under what conditions, or what thing is gonna have access to what, under what conditions, and then starting to manifest that in new ways. To me, that's how you keep fresh.

Perfect.

This is very useful, and I think that actually helps me also to kind of figure out So, one of the things I often say to users is, you know, what you know about IAM systems in AWS don't translate one-to-one with GCP. First, is that a fair thing to say? And then 2, what's your advice to teams that have to know more than one IAM system?

Yeah, so the practices are the same. The words are going to be different. And the tooling from each vendor, no matter what the vendor is, is going to be slightly different in terms of that the observability side of things, which I think is really, really critical. And then the one thing that is common, from my experience in the multi-cloud world, or just single cloud, is there aren't really standards for entitlement discovery. And that makes it really hard to, in a standardized way, basically point it at your GCP instance and your AWS instance and be like, all right, Give me all my IAM groups and the resources associated and all that stuff. Like, there isn't a standard for that. There hasn't been a standard for that going back to the on-prem days. So it's not a uniquely cloud problem.

That's what you mean by entitlement discovery?

Yep.

Understanding what's out there.

Yep. It's just like, what is the state of play?

Yes.

And then the next level is, under what conditions do people get these things, right?

That's a mess on-premise though. That's an ungodly mess on-premise.

Oh, hell yeah.

Yeah.

Oh, well, just because something's a mess on-prem doesn't mean we should try to solve it in the cloud any In fact, it means we should try to solve it more hard here.

I would definitely agree. It doesn't mean we are, but the state of play is this. Unlike user account management, which has had multiple attempts at standards, some of which I will take responsibility for, some of which I actually helped, where there is a standard right now, SCIM, SCIM V2 seems to work pretty well across SaaS vendors, even on-prem packages. There's gateways for that. Great. The discovery part of the entitlements that you could assign, that you can handle in SCIM, but it really doesn't translate to more general, say, IaaS or PaaS environments. And the thing that makes it harder to be in the cloud is understanding the rule by which, hey, I'm gonna assert this user exists, I'm gonna bind it to some set of entitlements, all of this is dynamic and on the fly. It's gonna run a little bit of compute and interact with a little bit of cold storage. Tracing that chain and documenting that chain, I feel like that's harder because of just where the maturity is of some of these cloud platforms, and thus why you see things like CIEM start to become a thing, right? Specialized tools for specialized cases. Now, they're big fricking cases, but it's still specialized tools. And then you start to see people that are trying to do the other thing, which is overlay policy across the multi-cloud environment.

Ooh, that's tricky also, right?

That's an understatement.

Understatement of the year, perhaps.

Yeah, no joke. It's like, yes, yeah, that is a hard thing. Wait, I think there's a school of thought that says, if you're having a hard time in this specific instance you're working in to implement policy, Classic computer science joke, nothing that can't be solved without a layer of abstraction. Like, okay, so then let's go up a layer, overlay a piece of policy that is neutral, and then we'll have translation capabilities, whether those are classic connectors or it's dynamic, or it's essentially just we're transpositioning one policy language for another. That's kind of immaterial, but let's bring it up a level, document at that level, enforce at that level and audit at that level, and then you can still prove this down into each implementation. That's the theory, but it means you're now managing another layer of abstraction with another point of failure potentially, and, you know, down the garden path we go.

Yes, sounds all too familiar. So, we're coming up on time. I think Anton has maybe one more question to ask, and then we'll ask our traditional closing questions.

So, I really need to ask you about your favorite list of cloud IAM mistakes. Because people ask me about SIEM mistakes. People, I mean, it's just useful frame of mind, but given the time, just give me like 3. Don't give me 33.

I'm gonna, right, I'm gonna give you 2. So one is, and this is independent of cloud or not cloud, is thinking when you're managing users for your workforce, you've gotta automate everything, automate connectors to every platform. I'm gonna create everything through automatic processes. Do not do that. Work on the birthrights. What do you need when you're hired? What are very basic broad stroke sort of job responsibilities mapped to coarse-grained access? And then everything else should be either request-based or automated based on context, i.e., what do my peers have? What does my cohort have for access? And work from there with a review process. And on customer identity side, which we haven't touched on, and that's a whole nother topic, which is This is where you're engaging with your customers. It could be citizens, they could be consumers. You've gotta have literally buy-in from everybody. Chief digital officer, chief marketing officer, product officer. These are people that classic IT workers don't necessarily have a reason to rub elbows with, but we're touching the customer's experience from the very beginning. How do I get through the front door? To how do I get the awesome that my organization, be it public sector or private sector, how you get it, which means your stakeholder group looks really, really different. And if you don't have them there, you're going to fail fast, but not in a good way.

Okay, Ian, I regret to do this because I've enjoyed this tremendously and I think we could do this for another half hour. What's one tip for people when it comes to their identity security story? And what have you been reading lately that you'd like to recommend to our audience? And it can be anything. We've had, well, Really anything, except Anton's blog.

Oh, are you gonna make a pitch for your own stuff, man?

No, no, no, no. I usually load up those links in there anyway, so people— that's why Tim prods me, because I would be like—

So, the tip is, leaving aside the cheeky, like, don't treat identity as a subset of security. Like, it's just easy. Like, don't do that. But more importantly, learn the practice ahead of the product. Learn the basic practices. What is provisioning? What is authentication? What is authorization? Before you learn it in a specific instantiation, i.e., I've learned GCP, I've learned AWS, I've learned SAP. When I started, I did the other way around. I learned a product, and then I learned the practice over years to do that. Like, don't do that. Learn the practice, then learn the product. What have I been reading? So, on my desk is Dominique Crenn's Rebel Chef, which I have not started but wanted to because I just wanna hear about a total badass chef and learn about their experiences. I am delving into reading things that my peers like Eric Leach and others have been writing lately, and Eric Norlin, just some interesting stuff that people are musing about. What's it mean to be a product executive or investor in this kind of time of hype of AI? And it's keeping me busy. And of course, the Body of Knowledge from ID Pro. If you haven't read that, you should do that.

Awesome. Well, Ian, thank you so much for joining us today. Sure. Livestream listeners, thank you for joining us on LinkedIn. We will release this as an episode on the regular podcast, as well as on our YouTube channel.

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 at Anton underscore Chuvakin and underscore Tim Pico. 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.

Security running.