Permissions Boundaries and SCPs: The Cloud IAM Invariants

Rich Mogull (00:00): My name's Rich Mogull after that great intro. Not much else to say. Basically the short version of this is, I've been doing cloud security for quite a while now, so about 15 years. For real, when I started, there was no IAM in cloud, it was just Amazon and it was all root accounts, and it's been pretty wild to be able to grow with it and learn as things go along, which by the way, makes it a lot easier. I feel really bad for those of you that have to jump into cloud right now. And what I want to talk about today is, a bit more of a complicated topic as you'll see once we get into it, but it's one of the most impactful in terms of helping manage IAM around your environments. And as you see when we get into the details, I'm going to talk about general principles and a fair bit of this is going to focus a lot more on AWS and the other providers. (00:52): And as you'll see, it just has to do with how the mechanisms within Amazon work, and I'll do my best to draw some parallels with what Azure and what Google can do. What I want to talk about today is security invariants. An invariant, it's a property that relates to the system to prevent issues from happening at all. So think of invariants as a guardrail, it is. I should be able to make a statement that is enforced and that cannot be circumvented, and that's the objective of establishing security invariants and there's a few different ways to do these. There's actually not a lot, there's not a zillion ways to do invariants in cloud, but there are a few different ones. They all basically are largely relate to IAM. There's one little chunk I'll get into in a bit that doesn't. And as I said, everything is going to be very focused on AWS and then with things that can also apply to Azure and GCP as needed. (01:53): What are some examples of invariants? Things like, only the security team can allow an S3 bucket to be public. Do not allow internet gateways in a production VPC or an alternative to that is no new internet gateways can be created in a production VPC by anyone except the networking team. So, we think of invariants as basically plain language statements that then have to be codified and converted into some kind of an enforcement mechanism. But when you're working with invariants, you don't immediately think of the complexity of IAM policies and Service Control Policies, you want to be thinking in terms of what is the security business outcome statement that I'm trying to achieve? Then, we get into the enforcement mechanisms for the invariants. There's different enforcement mechanisms. So, I'm going to be starting with the generic terms around these. Now, you may know I haven't seen all the other speakers, so I'm not sure how they laid things out, but when I think of IAM policies or when I think of different kinds of policies within cloud, across all of the cloud provider, those policies fall into three buckets. (03:14): They're organization policies, and in Amazon, Service Control Policies in Azure it's going to be Azure policies, Google policies, they all enforce those. Every one of the cloud provider mechanisms has those, or cloud providers has those mechanisms. Organization-based policies which apply that organization at your hierarchy level. Then we had identity-based policies, this is all the IAM. This is where we are setting rules for the users. So, in Amazon everything you do is within IAM with Azure, it's in RBAC, which sometimes they call IAM and it uses an RBAC model and don't get me started on Azure, not my favorite platform to work with. And then the third, which is not on this slide, is resource-based policies. Resource-based policies applied in individual resource. You'll notice I don't have resource-based policies as an invariant, and the reason is that resource-based policies have to be applied at the individual S3 bucket, the individual storage account. (04:11): So it's really hard for me to define a high-level rule that gets applied everywhere, although we do have other mechanisms we can enforce on resources, which is where guardrails come into place. An example is block public access in Amazon, if you're familiar with that. An example is if you're in Azure, you've got those sharing controls that you can apply to OneDrive. So those are a kind of guardrail, and then of course there's all sorts of other kinds of automation including some of the stuff, Sonrai and other competitors in the market have. So those are the ways that we can enforce those invariants. I'm not going to talk about the guardrail stuff today. I can barely get through the 45 minutes I've got to get into the details of the two I am going to cover, which is the organization policies and the identity-based policies, organization-based and identity-based policies. (05:01): So, now I'm switching into AWS terminology almost exclusively for the rest of the session. Please feel free to ask questions at the end if you want to get mappings into the other cloud providers. I did catch the Q&A at the end of the last one and one of the things said was every cloud provider is completely different when you get out into the inside. And that is absolutely true. They all use different identity models. Amazon and Google's are similar-ish compared to Azure, but even then they're just wildly different. So, we have to get into really nuts and bolts. Within AWS we have to start with how do the different kinds of policies and stuff interact with each other? And we have two of the major categories are here. So the Service Control Policy is that organization policy. That's a rule I set that applies to Amazon accounts and Amazon organization unit. (05:57): So it's up at that higher level and I like to describe, well nevermind I'm getting ahead of myself. We also have the permission policy, which is like the IAM policy you apply to a user, giving them their permissions. And then we have this weird thing called a permission boundary that I'm going to spend more time talking about. It's a big part of this talk. When Joseph reached out to bring me in, this was the focus of the talk, my cloud security lab week thing. I had done a lab on permission boundaries he thought was cool and that's why, and you'll actually see what that looks like. I'm going to do some live demo on there. What you can do as a user in a given cloud deployment is the combination of all of those. It is the aggregate permissions, and I like to describe this as it is the logical sum of all permissions that have been given to you with everything being default denied. (06:48): So if you're not given a permission, you're not going to have that permission. So it's a logical sum of all the granted permissions, they're not evaluated in order, they're all evaluated in aggregate. With any deny statement in any of those overriding any allow statement. And we're going to come back to that because it does matter, and again, I'm skipping resource policies and another thing called session policies, just because this is a rabbit hole you can spend a lot of time getting into because of the complexity. So, what are the rules of the road? As I said, default deny. If I create a new IAM policy and I apply it to a user, they can't do anything until I actually put in permissions that say, allow them to do this. They're blocked from everything. It's that logical sum, it's evaluated. There is an evaluation order of the policy types that I'm going to get into, but not the statements within a policy and any deny statement will override any allow statement. (07:48): So, really important to understand that. I will give you an example later of how I messed this up when I was first getting started working with these things. And so what is the order in which policies are evaluated? So this is an Amazon graphic. I didn't make this particular graphic, but this shows how it works. So, the decision at the upper left corner here says if I want to do something, it starts with deny, you can't do anything. Then it evaluates all the applicable policies and is there a deny in any of those policies that denies that action? So let's say the action I'm looking to do is run an instance, something very simple and if anything says deny running an instance, it's immediately denied. Now if I want to then continue so there's no explicit deny in any of the policies, then it starts flowing through in this order. (08:46): First, the Service Control Policies, then the resource-based policies, and then all the way down to get your final decision. And every one of these has to have an allow or not. Any one of these has to have an allow and none of them with a deny. So, you don't tend to have to get into the weeds of this too much with one exception that I'm not going to spend much time about, which is that with a resource-based policy, if there's an allow and there's no explicit deny, it skips all the rest. And that makes sense. If you think give somebody access to an S3 bucket in the resource policy and they're allowed to use S3, then they'll just be able to get in. And again, that's an edge case, it's not an edge case, but it is not totally relevant for what we're talking about today. (09:32): What we're going to focus on is two pieces. We're going to focus on the Service Control Policies and the permissions boundaries because these are where we can really put some of these invariant concepts into action in a way that's more meaningful than just giving you a primer on how IAM policies work. Now, a reason that we're focusing on these two is are very similar in terms of what they can do. Service Control Policies and permission boundaries, they're unique in that they don't grant permissions, they just take permissions away. What do I mean by that? You'll see later when I actually set all of this up and I'm going to pull two examples from one of my Amazon environments. The one I use for the training, the cloud security lab week thing is that if I have an allow statement in the Service Control Policy and then a user is operating in one of those accounts covered by that Service Control Policy, that doesn't allow them to do anything, it's just not blocking them from doing something. (10:37): So, that's why these get weird, kind of complicated and a lot of people struggle to wrap their heads around it, and that's especially true for permission boundaries, which will make a whole bunch of sense once I get into those, sorry, I would drink water, don't have any, got a little coffee there. So it will just make me more excited to talk about permission boundaries. Let's focus on Service Control Policies, and I like to talk about SCPs as the Amazon account security blanket. And the reasoning that I do that is a Service Control Policy is applied at the top level. So there's something known as in a management account and in my little diagram it's up here. And this is an example of what we build in the Lab A Week labs. It's a free thing, so that's why I don't mind talking about it. (11:32): But if I go into the root of my organization and I write a Service Control Policy, I can actually apply that policy to folders of accounts which are known as an organizational unit if you didn't know that or individual Amazon accounts themselves. Now what's great about Service Control Policies is they live outside of the account. So this is something like management security up at the top level can apply and anybody can have full administrative access. You can have root account access in an account and you still can't break out of that Service Control Policy. It's a force field, it's a security blanket, it's a whatever. So, they apply at that org unit level, at the folder level or the account level, they are inherited. So if I apply one at the top of the organization, everybody else inherits it. And that's what this diagram shows. (12:24): I have one here locking out all regions that applies to every one of these organizational units and then every account, it's cascaded, you'll see what that looks like. The only exception of this is the management account, which is the core of your Amazon organization. Service Control Policies can't apply to that. That's a safety mechanism so you don't lock yourself out of your management account. And this is an example of what an SCP looks like. The policy language that Amazon uses is the same for all of these things. Service Control Policies didn't exist in 2012, but that uses the same policy language and it's always written in JSON. And so, in this case I have a statement and you can have multiple statements, this is a single statement and the action is organizations leave organization, the policies are written to specific API calls. So that API call is leave organization and that is denied. (13:18): And so, under no circumstances can anyone leave the organization. Then within this block I have another action, which is, any actions on any resource, deny it if it's from the root account. So this locks out the root account and it's called the root user account. Amazon's really stupid about how they call things root accounts and they used to call the management account the root account and it's very confusing. It's not how we as human beings historically in IT think of root accounts. But the short version is when you establish an AWS account, you start with a root user account. So this Service Control Policy says, hey, don't let anyone leave the org and don't let them get into this super sensitive root account. These are security invariants. Don't let anyone leave the org plain statement. I can apply it with the Service Control Policy to my entire organization and then don't let anybody use the root accounts. (14:13): I can apply that to the entire organization. Now, I actually will set this up usually with an exceptions organizational unit because sometimes you do need to do some of these things, but that's not normal. Now, Service Control Policies also support things known as global condition keys. So, if you notice going back here, this is a very clean statement, leave organization, just deny that one API call. In this case it's deny all API calls only if the user is the root account. And that's basically the translation of that. And there's other ones we can use. So these are those conditions, these are the keys that we can use within our Service Control Policies. We can lock things down to IP addresses and VPCs, we can lock things down based on the organization, but you'll notice these are the only conditions that are supported, you can't come up with any possible attribute in any possible service. (15:18): The ones that are supported for Service Control Policies and globally are just the ones here. So, we'll use these conditions in combination with those kinds of statements I showed previously due to our enforcement. And here's another example of a condition statement. This is a region lockout and you'll notice... And this is where things get weird and complicated, if I look at the statement here and the idea of this, my goal of this policy is, deny everything unless the user is in us-east-1 and us-west-2. That's what this Service Control Policy says. Deny everything except for those two regions. However, you'll notice that I have to have a deny statement with something called a not action and not action means deny everything except these things. And that's part of the again, the complexity of this, when you write IAM policies for all, you get used to reading it, but it is a double negative deny everything except these things. (16:26): So these are all going to be allowed. Now why do all of these have to be allowed? Because Amazon regions, they talk about being isolated and separated. It turns out a whole ton of services just run in us-east-1. And these are all services that if you block these, it's going to break stuff because all of these actually work in us-east-1. So you have to write an exception for those or you're just going to break all these capabilities into your account like key management service and pricing and Route 53, because all of those have hooks into the us-east-1 region that you can't get away from. So, these are all going to be allowed everywhere, but then everything else on every other resource will be denied because we have that top deny statement if StringNotEquals another double negative, the region is not one of these two regions. (17:20): So it's weird. Why do we use all these double negatives in here? Again, think back to the policy evaluation where it's all allow actions, any default deny overrides an allow. And because of that, I write it this way in this weird convoluted language because this means if anybody adds an allow policy, this will still override it. If I said allow everything in only those two regions, somebody could add another allowed policy later for a third region. So this is again, we have to use negatives and denies and double negatives if we want to get our strong policies, our invariants. Okay, what does some of this look like? So, this just going to be a real quick view. Oh, I got to get to my proper browser here. Where's Firefox on my toolbar? Okay, let me go back to there. I have fancy button here and I pressed the wrong button. (18:21): There we go. Okay, so I'm going to go into my org management account and in my case it's this. So I'm logged in with my SSO portal in AWS and this is a real organization again, it's one I use for demonstration training purposes, but this is what a very large AWS organization would start with. And you can see I have a robust organization structure here, nurseries for new accounts and onboarding area. Why have I broken out all those different OUs? Like why do I have a nursery and why is that different than onboarding? Nursery is going to be for creating new accounts, onboarding is going to be for mergers and acquisitions and pulling in accounts from other organizations. These will have different Service Control Policies applied at their levels. So let me go down to one here. The workloads account and then I have my production in non-production. (19:12): So I'll go into non-prod and I can click on here and I can actually see what Service Control Policies I've got. And now the reason I pulled this up is to give you a sense of what this hierarchy looks like. So first I have to have and allow everything. If I don't have that at the root of my organization, no actions are allowed. Think about it because of the default deny would kick into place and the first time I used an SCP I broke my entire organization because I didn't realize you have to have and allow all at the root of your organization at that management account or you're going to block every action in every account. So I always will start with and allow all when I'm dealing with a larger complex org and that's pretty standard. Then that's also attached to the individual accounts themselves. (19:58): Didn't have to do it that way, but I did because these are inherited. And then I have a couple of other ones that are attached at lower levels. So, I have my Region Lockout, which I showed you, which is in the root of the organization. And then I also have my Protect Org And Root, which is attached down at a lower level just to the workload. And this is that one I showed you before block leading the organization and don't allow anyone to use the root account. Two of my security invariants. And so that shows the interaction. I could probably clean that up a little bit, but not really because I've applied this at the root level folder, and then this one is also... Amazon actually will default apply this to all new accounts when you create them and I just haven't pulled it off. But the nice thing is the deny statements in here will override those allow all statements and that's a security invariant, that's why this works. (20:50): All right. Just a really quick showing you what that looks like in a real environment. So let's talk about permission boundaries. Permission boundaries, this is where people tend to get more confused about things because a permission boundary says it's a type of a identity-based policy you attach to the user that says you can do everything except I don't want you to do this one thing or these five things. So, that's why... By the way, it took me forever to find a picture of a dog on one of these zip line camping things that's out there, but that's the idea. You're going to run all the way around in this little area, but you can't break out of that sandbox. A permission boundary, it's a type of guardrail. It will never grant new permissions, but it restricts the total potential permissions of the identity no matter what other policies you assign. (21:46): So, if you read Amazon's documentation, it shows a lot of different ways to use them that are more complicated. In the real world scenarios and most of the organizations that I've done work with, we scope them down and they're mostly just used to allow someone to administer some of IAM you want to delegate a developer or an admin to do IAM within just their account, but you don't want to allow them to abuse that to say make themselves full admin, that's really what it narrows down to. We're going to let you administer some of IAM but not allow you to do a lot of IAM and you can't self-escalate your privileges. That is typically how I focus the discussion around these because there's a lot of other ways you can use them, but honestly, bluntly, most of those use cases are better dealt with just by being better about your permissions policies or Service Control Policies. (22:48): And again, this just reiterates this point, I want to allow you to administer some of IAM, but I don't want to allow you to escalate your privileges and that's because it's really easy to say, hey, I want you to for example, be able to assign users to use this policy in these circumstances or I want to allow you to write a permissions policy for your application. Well then it would be really easy because I could write a permission policy that gives myself full admin rights and then I could assume that policy within my application. It creates a privilege escalation situation. Oh, maybe I can't apply that policy to myself directly, but I could apply it to something that then I could go use. And so, this is where these permission boundaries come into place. And they're a little bit different. There's not, by default, permission boundaries assigned. (23:42): So, if you do not assign one, they're never evaluated. It's like it doesn't exist. You're just using your identity-based policies and it's not like a Service Control Policy where once you start using them, you always have to apply them. With the permission boundary, you just create them on an individual user level and only when you need them. And so if it's not there, it's just not evaluated. It's not like you have to have an allow all policy as I showed you with those SCPs. It is a policy within IAM called a customer managed policy. So it has to be managed policy, you can't use inline policies for these if you're familiar with that. And like everything else, they are default deny. So if you write one that says has any deny statements in it and no allow statements, it's going to not let them do anything because by default everything is denied. (24:30): So you actually have to have allow statements in there or that permission boundary is going to block all actions to whatever users, groups, roles that you've assigned that permission boundary to. They're just like regular permission-based policies that would give you all the permissions, the same IAM language. And there's some limitations in IAM Identity Center that I'm going to get into because that's part of the demo I show. Here's an example. Alice decides to let Bob manage the IAM for parts of his application and specifically Bob can write and assign IAM policies for his instances and his lambda functions. There are some other AWS services in use though that those things should never touch. So it's just, you can't turn off the services that you don't want Bob to use with a Service Control Policy because other parts of the application need them. Remember that SCP, it's very coarse. (25:28): It applies at that account level and you don't always get all the resources and conditions. It can be hard to get all those supported in a Service Control Policy, and you don't want Bob to be able to assign a new policy to himself. And this is kind of what this would look like. So we are denying the actions of attaching a role or detaching a policy to Bob himself. The only resource Bob can attach and detach policies do other things in the account, and I kept this simple for the screen. In real life you'd probably have more granularity in there, but Bob can never attach or detach a role that's associated with himself. So he is locked out from changing his individual user account. By the way, you all know never use IAM users like I'm just doing it for demo purposes. You always want to be using IAM roles and you want to tie in through identity center or an SSO portal. (26:21): Okay, sorry, that's not my talk to give. Hopefully somebody else is making sure you get that lesson. Then, I have to have that allowed statement, all actions, all resources, otherwise Bob can't do anything at all, everything else would be blocked within this environment. This is how I write them. It's very specific around IAM rules and in this case, these are the two things I don't want Bob to do. And they're tied just to Bob himself. They're very specific for him, and by the way, there's some variables and things that you can put in here as well. And then I want to allow him to do everything else. This does not grant any new permissions. This allow statement here doesn't let Bob, for example, leave organization or view billing or whatever else. He still has his permission policies and we'll show you what that looks like in just a moment. (27:11): So, the example I'm going to use is in IAM Identity Center. And this is a setup that I like to use where I have an identity center administrator for managing permissions and I want to let them write and assign policies through the different permission sets within identity Center. Identity Center used to be called AWS SSO. Again, you'll see it here in a moment. The problem is that manager could assign themselves a full administrator policy and take over everything. And so there's a permission boundary that I put in place to prevent that. And what does this look like? So need to exit out of this account. I'm going to go into my IAM administration account. I used a delegate administration for this. Joseph Barringhaus (27:54): He-y Rich, can you use zoom in a little? Rich Mogull (27:56): Yeah. Joseph Barringhaus (27:57): Thank you. Rich Mogull (28:00): Let me make this... Whoops, wrong window. Whoops, wrong window. Again, I want to go to this. Okay, there we go. So make that bigger and I'll make that bigger. And I'm going to go into, in this case, IAM Identity Center itself. You can see if you're not familiar with it, we have different AWS accounts and different permission sets that are associated, which is the permissions. Now I'm logged in as the full admin here and I'm going to go back to, sorry, so let me go to my users. And I have a given user here. So this is my identity center administrator user in different groups with different accounts and permissions associated with them. And if I go into my permission set, I have a permission set which is the set of, it's just a collection of policies. I have a one that user is given, which is the Identity Center administration one. (29:16): And you'll notice I've got two things here. I have the AWS managed policy, I have a customer managed policy, and then I have a permission, the ability to do permission boundaries. And I'm going to go back into IAM itself to show you what that managed permission boundary looks like. Go into my policies, I have my SSO permission policy here and if the Amazon Web Interface catches up, there we go. And I like to show this JSON. I can never read the non-JSON versions. So let me zoom in here. And so what this does in this case is again, it always starts with this allows statement or it'll block everything. (29:59): And what I'm doing here is this permission boundary with an identity center says deny any changes to a specific permission set, this permission set is the one that is associated with administrators. And this will block that SSO, that admin user, from making any changes to the permission set, and again, I know some of this is confusing because it doesn't say administrative actions, but it was one of those ones I showed you a little bit earlier. It does not allow them to make... Or sorry, this is the one associated with that Identity center user doesn't allow them to make any changes to that permission set. (30:42): And then I go ahead and I have that attached to that SSO administrator. And that's a way to kind of restrict the SSO administrator from being able to escalate their own permissions because they can't change their ability and that... I'm not being a little clear here. What they're able to do is manage Identity Center. What they're not able to do is for example, make any other changes within IAM within the entire environment. So it's going to block any of those actions and their ability to change their own permissions. All right, let's go back to the slides here. (31:23): Yes, these things get convoluted and that's part of the problem. And again, this is the, don't allow them to make any changes to that permission set. Now one of the problems is if you're trying to use Identity Center for this, there's two big problems. Identity Center has two services, two pieces of Identity Center. One of those is assigning permission sets to account. That's that little part I showed you. The other is a directory. So keep track of your users and groups and that's if you're not using an external SSO provider and at any store, that thing to manage users or groups doesn't support any resource restrictions. So you cannot, for example, block an IAM administrator from adding themselves to a different group if you will give them the permissions to manage users and groups. Really frustrating, I don't know why Amazon's usually better than that, but that's a hole that they have. (32:18): All right, so put it all together, go to Q&A. Permission boundaries and Service Control Policies limit the maximum amount of things an identity can do. We apply Service Control Policies at your organizational units and your accounts, it's that security blanket. And we provide apply permission boundaries to individual IAM users, groups and roles. These security invariants, these two things never add permissions. They only take permissions away. So, even if you haven't allow all, it doesn't really allow all, it just means don't stop this from happening if the identity policy allows them to do this thing. Service Control Policies are limiting what you can do in Amazon accounts and they're really essential for governance, they're absolutely critical. Trust me, life got a lot better when Amazon created these things compared to what life was like before that. And it really allows you like turn off services, turn off regions, protect the root account, a lot of enterprise-scale management that you need. (33:20): And then permission boundaries, you can do a lot with them. Honestly, I only use them personally if I want allow someone to do some of IAM administration but not escalate their own privileges to full admin. So four year security invariants, your Service Control Policies. Im co-speaking At Amazon re:Invent this year on security invariants. We're just really focusing very, very heavily, most of the talk on those Service Control Policies. I'm not even going to be talking about commission boundaries, I don't think other than mentioning it. Definitely not getting the detail we got in here. Locking out your root accounts, locking out regions, these are all really common things that we use, that we start with, for creating our Service Control Policies. (34:04): And again, I will lock out root accounts, I'll lock out regions. I protect my administrative tools like CloudTrail, not leaving an organization. If you're using something like Sonrai, you use Service Control Policies to make sure no admin in an account can turn it off, turn off that access. So that's protecting your essential roles. That's where I always start. And then I align that with my org hierarchy, and you saw I have kind of a standard org hierarchy I like, which is the example I gave. Then I will only get into permission boundaries if I'm dealing with people who I allow to administer some of IAM but not all of IAM. All right, so I'm going to go ahead and stop sharing here and we'll switch over to Q&A. Joseph Barringhaus (34:46): Hey Rich. All right, so just reminder everyone put questions in the chat, put them in the Q&A section, we've got a few of them ready. And just to remind everyone, yes, the slides will be made available. Yes, the recordings will be made available if somebody asks again, you have to do 10 burpees. Those are the new rules, no one wants burpees. Let's look at this first one from Eniola. Rich, in Azure can this be applied as a resource-based policy? The moment that that came from, it was a question about permissions boundaries. Can you do that in Azure and how do you do that? Rich Mogull (35:23): All right, so first of all, everything with Azure depends on how much money you're paying Microsoft if you get it or not. And let me be clear, I know really in depth for all of this for Amazon, I'm pretty decent on Azure, Google, I'm going to get, I'll still do my best to answer any questions about that. On Azure, Azure has the ability to do certain kinds of deny policies. It is a separate feature and you do need to be at a higher, I think you get it like an E3 license. Obviously you get that with E5 license and then you can do deny policies on there. (35:57): Again, there are back model, there are aspects of it I like, which is basically applying a role at a scope. They do have some specific deny capabilities, which are close to how a service permission boundary would work. Service Control Policies, it's just Azure policy and they are actually more robust than on Amazon policies because you can use detective, you can do reactive, there's some cool stuff that you can do in the Azure policies. They're a bit harder to write, but Azure comes with a massive list of hundreds of Azure policies that you can use out of the box. Joseph Barringhaus (36:37): A-wesome. Someone asked in the Q&A section, when will we have ChatGPT for Cloud IAM? Rich Mogull (36:49): We'll see what happens. Obviously commercial vendors like our host today probably have some pieces of that. This is actually a more interesting question than you realize, because Amazon has had a thing called automated reasoning on their backend. They've been using for a very long time to figure out policy conflicts and stuff, and that is expressed in certain products. So if you go into S3, this is how complicated this stuff is, if you go into Amazon S3 and it'll give you a label of, if it's public, could be public or can't be public, they have to use this big machine learning thing called Zelkova, that's their name for that, that you can request access to. And it's this automated reasoning system for evaluating all the policies and figuring out all the edge cases and everything. So we are using it there. Now for a ChatGPT level, the thing I'm building for re:Invent is just going to try and write some Service Control Policies and test them using... I'm using Bedrock and Anthropic Claude. (37:50): And so far I haven't gotten to the level where I would fully trust it in a production environment because the edge-case aspects of this stuff are there. So I actually use ChatGPT to write, now I actually do use it to help write policies, but I know what I'm doing. The other day I asked it to write one for the cloud security Lab a Week. I needed one quickly. I didn't want to handwrite it. I asked ChatGPT to do it, and I looked at the results and I'm like, no, no, no, no, no, no, you got that wrong. Fix it because you missed these things on it. So someday. Joseph Barringhaus (38:28): Fun fact, if you want to make your policy super over permissive, it will do that very well. Yeah, no, it was that great. Rich Mogull (38:35): So total aside, because I'm nerdy about this use of AI and security stuff. One of the problems is the data sets that the training models they've used include massive amounts of bad examples, Amazon's documentation, a lot of the stuff you see on GitHub and blog posts over permissions because that makes it easier. I view that a lot in my labs. So, these are just feeding in all these over permission. The one I'm building, I actually am giving it a set of SCPs and using research on RAG to actually evaluate off of those instead of AI. Joseph Barringhaus (39:12): Connect with Rich he would love to talk with you about AI. One question here, we touched on this a little bit in Azure, and so it may be the same answer in GCP Rich, and I know you also said disclaimer, don't ask me GCP, I'm going to ask you anyway. What is the equivalent of permission boundaries or conditional access in GCP? That's one of the questions that we got on here. Rich Mogull (39:34): Yeah, I haven't used them in GCP. Joseph Barringhaus (39:39): Find us later. Rich Mogull (39:40): Yeah, find us later. Google has policies for the SCP equivalent. I haven't gotten into the... I don't like that I don't know GCP as well as I do, but let's be blunt, I've been doing this 15 years and I'm only truly an expert on one cloud and I still learn every day. I don't know everything I need to know on Amazon. I barely know enough to get by on Azure and I can't spell GCP. Nobody I know who operates at my level is any different. None of us... If you say somebody who's a multi-cloud expert, that is absolute garbage. Nobody's a true multi-cloud expert because these are all too complicated. Joseph Barringhaus (40:22): Love that. Rich Mogull (40:23): And there's something in the chat room. Joseph Barringhaus (40:24): Someone did share. Yeah, so we've got a GCP expert in the chat I think, or someone that at least uses that component of GCP. I've got one here as well. And Rich, we will end on this and if anything else is in the chat, we'll go from there. But trying to use SCPs and they tend to get in the way exceptions pile up, they get really hard to manage, so I don't use them anymore. Any ideas on how to prevent that from happening? Rich Mogull (40:44): Yeah. Obviously drooling can help you with that. [inaudible 00:40:51], but that's also can be true. Most of the problems that I see with SCP sprawl is you're not using them properly. So the biggest things is, and that's why again, I spent so much time building out the hierarchy that I did and the one that I use in terms of my org units and where I put my accounts and how I apply things. And I understand that hierarchy model, because that really can help prevent a lot of that level of conflict and complexity that you run into. It's usually sprawl and because you throw them on non-strategically, you're like, oh God, I got this one thing over here, I need to put a block on there. (41:42): And then that account moves to a different OU or you applied it at an OU level and you move accounts around and there's nothing wrong with any of that, but it's not having taken that strategic approach to it. So, if I've gone in on my consulting projects to evaluate these, I just rip the hierarchy apart. Honestly, it's kind of think about active Directory. If you screw up your trees and your forest and I don't know your witch's huts or whatever else that AD has in there, your hoaxed because then you're going to get all these conflicts and everything else, and that's the same with dealing with SCPs and with Azure policy. Joseph Barringhaus (42:29): Awesome Rich, as you saw in the chat, everyone is super grateful for you. Thanks so much for the session today. We have a lot more to come. I know Rich is going to stick around here a little bit as well. And if anyone remembers what Rich said about SCPs, they're amazing. But of course you could break everything if you really want to put out services regions, permissions, you do it should definitely go do a lot of what Rich showed you. Those are some of the very basics you should go work on today. (42:50): And if you don't want it and you want the cheat code, well then I've got a couple of things in the chat, we're going to drop one. It's a special offer that we're offering today, but then also some benefits and offers to join Rich's weekly Security Labs. There's a link to that. There'd be a link to a free guide that we give away here as well. And then a link to some powerful permissions that you should know and...