 Hey everyone, thanks for coming. Um, okay, so let's just get it, let's get into it. Using Pareto's principle for securing AWS with SCPs. So, let me turn on my remote, that would help. And I'm going to put it over here. All right, cool. So a little about me. Uh, I like AWS. I've been in security for a while, whatever, blah, blah, blah. I took some tests. That's not a big deal. Uh, I'm also really into coffee. Uh, this is my real coffee set at home. Uh, so if you want to talk about single origins and, uh, pour overs and recipes, I could talk ad nauseam about that. Uh, I also run a podcast called Getting Into InfoSec and it's designed to help folks, uh, get into security and by interviewing folks that are out there and see how they got in, because everybody's path into security is different. And then I also wrote a book as well because, well, you know, it's just kind of helping solve the problem as well. So, like, if you sat down with me for like an hour over coffee, what would I tell you? This is what I would tell you. And I like Hawaiian shirts. So on Fridays, on work, you see me, uh, I'll probably be wearing a Hawaiian shirt. So that's a little about me. Cool. So, uh, I have no idea about you guys. Uh, this is the first time that the cloud village existed. So I just want to get to know everyone out there a little bit. How many folks out there manage AWS accounts, uh, 10 or less? 10 or less AWS accounts? Okay. How many manage 25 or more accounts? Alright, alright. And how many manage 75 or more accounts? Alright, very cool, very cool. Okay. And how many of you guys are using AWS organizations and SCPs? Okay, cool, cool. So, um, what's Prado's principle, right? The idea is that with just a little bit of work, you can accomplish a lot of work, okay, or a lot of results. So 20% of effort and you get 80% of the results. Um, and that's where SCPs come in. They're just beautiful. So with only a little bit of, um, code, right, a few lines of configuration, you can really apply a lot of security to a lot of your accounts. Uh, but there's a lot of steps that are required before that. And also we'll talk a little about cloud security issues for those that are, uh, you know, not too familiar about AWS. Again, just trying to level set here. So what are some common issues, right? I am having keys and source code, um, having really egregious permissions on, um, boxes like for say, you know, EC2 star or IM star, uh, storage, leaky buckets, right? We've heard too many stories, logging, right? I mean, really what AWS is, is you're giving the, like, infinite amount of resources globally, right, to an engineer. And this is what you have, but this is what you end up with, right? Uh, it's just, it's, it's, um, you know, AWS has a shared security model. We all know about it, but still it makes it very easy for someone to just trip over themselves. And so, you know, we have leaky buckets. Uh, I think we all know, or we may know about all these leaky buckets that are out there. Uh, someone even created a github page that lists all the S3 bucket leaks out there. Very convenient if you're trying to prove your case or just keep track. And they're just, you know, it goes on and on and on and on. And someone said that there was, like, nine billion data records of S3, uh, from S3 bucket leaks. Same thing, IM is a new perimeter. So, you know, no longer is it network security, it's more IM. Um, everybody might have heard of a capital one breach recently. So, um, you know, a lot of things went wrong there, but you know, we don't want permissions like EC2 star, IM star. I have actually seen this out there. Um, I have seen public machines that are running WAFs with EC2 star on them, and I'm like having heart attack. Um, and you know, in this case, you know, I was at a company once where, uh, someone emailed their IM keys to someone else, and I'm not sure how the keys got compromised, but $40,000 later, uh, a lot of EC2 instances were deployed and, um, it was not, it was not fun. AWS did reverse it, but still we don't want to be in that situation. Yeah. Uh, who here has heard of code spaces? Oh, all right. So, code spaces was like a GitHub-like, uh, company that provided IDC rock solid and secure affordable hosting. So, we all know it's secure because it says it's secure, right? So, um, this was their website on June 14th, 2014. This was their website on June 18th, 2014. Their root keys got compromised, and the attacker basically deleted all their backups, all their instances, everything, and they literally went out of business overnight. Okay? So, this is a target for us, for AWS folks, for Cloud folks. This is our target. We need to know this. Uh, it's a part of our history, and so it's something that, uh, I recommend everyone go ahead and look up. I pulled this from, uh, archive.org, and you can do that scene as well. So, why AWS organizations and SCP? Okay. So, basically with a few lines of configuration or quote unquote code, we can enable a lot of change and a lot of protection in our accounts. Um, but the reason I did this talk is because, so SCP has been around for a little bit, and I'm still not seeing too many organizations taking, taking advantage of it, at least to their full extent. I think people are a little afraid of SCP, um, but it's a really good way to guard your security, um, and, and protect yourself, uh, if you have things even securely configured properly. So, I'll talk a little about multi-account strategy. It's kind of a foundation to this. So, if you are, um, using multiple accounts, you want to take advantage of the multi-account strategy. You want to have a logging account for your, your logs to go to. Okay. Uh, you want to have a security account for your security ops and your tools to run from. Uh, you want to have, you know, networking where you can do your transit gateways and, and things like that. Shared services and, and on and on and on. So, it's really important to do, uh, take advantage of the multi-account strategy. Uh, AWS, you know, first start off, I don't think they realized how, how, how big this would explode. And so, they've, you know, incorporated some multi-account stuff. It's still, um, you know, I would look it up. It's, it's, it's part of the well-architected, well-architected framework. Um, I'm not going to talk anything negative right now. So, um, so once you have this set up, okay, then you can take advantage, full advantage of AWS organizations. So, it kind of works on top of that. Uh, you have your master account. Um, if anyone's familiar with any sort of directory, you have different OUs, and you could have sub-OUs, and you could apply policies at the OU level. So, this is really how, um, security control policies work. Okay. And so, this is kind of a quick outline of what I'm going to talk about. Um, you know, if you're coming in starting with AWS organizations and SCPs from scratch, okay? So, we have the master account. Everything starts with the master account. Um, how many, not to embarrass you, but, uh, how many, how many here have master accounts with resources in them? You don't have to raise your hand. It's okay. So, um, so having a master account with resources is bad. You don't want to do that. Um, why? Because when you're going to apply a policy, you don't want to apply the policy at the master level. You want to apply it at a different OU level. And so, you want a master account that's empty and has no resources. So, that's really your biggest step in all this is getting, uh, creating a master account, moving your consolidated billing to another, uh, to that account. Um, there's a few steps involved. Uh, one, call your rep, um, create the account, create an S3 bucket for that account where your consolidated billing reports can go to, uh, and then create a support account. And if you have, if you're on an enterprise, uh, level support plan, then definitely your rep will take care of most of this for you. Um, in one organization, it took a month for us to get this done. Uh, we had signed a new contract, had to go through legal, blah, blah, blah, blah, blah. I'm like, what is this? Why is this? And they had to sign it with Inc. Not, it wasn't DocuSign. I was like, really? So, um, it was quite interesting. Um, but after you have the new AWS account, then you can create the Oregon, Lincoln, Unlinked accounts and it's pretty straightforward from that. From there. And here you are. So, so now once you have your master account, you create the organization. Okay? Uh, organizations has two modes. Uh, there's billing mode and then the full access, the full features mode, which lets you take advantage of service control policies and, and everything I'm going to talk about today. So if you have an organization already and you have a master account with no resources, then go ahead and make sure your organizations is enabled for full features. It's just, uh, a really quick, uh, CLI command or you can go into console and, and, and do it there as well. You also might need to increase your, um, limits on AWS organizations as well. So, um, I have 10 here because that's what I was doing in my experimental account. Um, but yeah, so you might want to look into that as well. Okay. So, here I, I've created an organization. Um, I'm logged in. I created a couple of different OUs. It's like super easy. And hopefully everyone has a, uh, a dev staging and prod environment. Uh, and hopefully not everyone is doing everything in, in one account or, or prod, right? So, uh, this is the ideal way. Um, so I created a prod staging and dev account. I also created an other account because there's a few accounts that I just didn't know where they should go. So, um, you might have a subsidiary that you're, you know, they want to have their own, uh, deal with AWS and they don't want you messing with that. So, you know, other would might, might be a good place to put it. And you could have SoboUs. Uh, there's no need to create just three top level, um, OUs. You could have, uh, many different SoboUs. It's really up to you how complicated you want it to go. The only one that really would be outside is the, is your root account, your master account, and that would be in the root OU. Pretty straightforward. And then just go ahead and, and enable your service control policies. It's okay. Nothing's gonna happen here. Just go ahead and enable it. Alright. So, applying SCPs. Okay. Be really careful about SCPs. Um, I did say it's okay to enable them. Yes. But when you're going to apply them, take the usual methods about applying it into dev, applying it into pro, uh, staging and then prod. Uh, you, these things are really powerful. Uh, they're instantaneous. And when you apply it at the OU level, it takes effect for all your accounts under your OU. So, you know, take that into consideration. Uh, and please for, for, please don't deploy things on Friday. Just, just don't do it. Okay? Um, okay. So, in AWS organizations, this is not SCP directly, but when you have your master account set up, this is a really nice feature to take advantage of. Just create a cloud trail, if you don't have one already, create a cloud trail in your master account and it will automatically apply to all your, uh, your whole organization. So, you will only see this configuration when you're doing it from your master account. And so, of course, have that bucket in a separate account for logging. Okay. Uh, and the reason it's in a separate account for logging is for integrity purposes, limited access. You don't want everyone to have access to that, to that logging account. And so, go ahead and set this up and you remember the name of your cloud trail. And I'll, I'll tell you why. Um, in the next one here we have an SCP that now prevents anyone from stopping and deleting that trail. Okay. This is all available on, on AWS, uh, on their, uh, examples page where you could also, you know, publish the slides. But here, what I'm referring to is, uh, the specific cloud trail name that you specified. And the reason is, uh, say you have other groups out there that maybe want to have their own cloud trail or want to do whatever. Um, and you can let them, they can create their own cloud trails if they want, they can delete it, they can do whatever, but don't touch this cloud trail. So, uh, with this SCP, it will, will allow you to stop. And you can see here, uh, I'm logged in as, as root, as admin, and I'm trying to disable it. And it says you don't have the necessary permissions. So it works. Yes. That's right. Yeah, I'll be happy to take questions at the end. So, uh, again, so, you know, we're trying, so VPC flow logs, right? You want to protect those, uh, possibly if you really rely on them from a security purpose. Um, so go, you know, this is a, um, a log, uh, sorry, service control policy that will protect them and, and, and prevent someone from deleting them. And you know, you could tune to your liking, right? Do you want to specify a specific, uh, VPC flow log as, you know, you could, you could really play with it as much as you like. Okay. A lot of times, you have resources only in US, West and East, for example, or two or three regions. There's no reason to have all your regions enabled. And so this will kind of limit your attack surface on where regions would be set up. And your attack could come from outside or inside. I mean, a lot of times employees, I don't want to say a lot of times, sometimes an employee could, uh, set up an instance in, I don't know, London or, or Asia, um, with GPU instances and just do some crypto mining. And no one would know about until much later. Um, you know, it really depends how good your monitoring is, how mature your environment is for, uh, for looking at resources outside your environment. So, again, this is not rocket science, uh, but this will limit your, uh, attack surface. So, uh, it's a really good way to just, hey, I don't think we'll ever have a need for US, uh, um, US West one or anything outside of the US, whatever you can use. You know, you can just play with this, uh, to your liking. I did have, oh, so one note is, I put like easy to describe, for example. So, if I want to have a tool or if there's a tool that's gonna do easy to describe, uh, then I could run it and it won't break that tool. So, if you have monitoring tools then you want to add a couple not actions here, uh, so that your tools won't break. Something to take in consideration. And so this is an example of, uh, trying to launch something from a region that is not on that list. Uh, the next thing is limiting the type of instances that are running in your environment. And there's two ways to do it. You could do a deny or you could do a permit list. And I'll show you both. In this case, um, I am denying these particular instance types, right? Um, is there a need for your organization to use a P3 instance, right, with like four GPUs? I don't know. Um, probably not. So, in this case, we're limiting the type of instances, uh, so that either accidentally or maliciously we don't launch instances that are gonna cost us thousands and thousands of dollars. And, and I want to, uh, draw attention to the string-like, uh, condition here. It lets you use, um, it lets you use, uh, wildcard conditions. So it's, it's pretty, pretty versatile. Here's one of allowing it. So, you know, I'm limiting to just general purpose, uh, instances. So here we have a bunch of instances listed. We have A, T, M, and, um, M5 and M4. And so, okay, that's all instances we need, right? It depends on your organization. You could actually, uh, add more to this. You could limit it to particular AMIs if you want. You could limit, you know, you could have, uh, you can make this as restrictive as you want. You can have multiple SCPs. So you have this one for, for instance types, and then another one for AMI. And of course it takes, uh, the IAM precedence where it compiles all the permissions and takes the least, um, or the most restrictive permission out of everything. Here's a good one, uh, limiting root actions, right? You want to deny root actions across your, your accounts. Um, and so this is a really good way to do so. Uh, using the principle ARN and, um, you literally, as root, you can't do anything. I'm logged in as root and I can't even do a describe on instances. I can't launch anything. I can't do a single thing. So it's really, really powerful. Um, this is one of my favorites. So, you know, if you have that founder that still has access to the root account, um, which happens a lot, right? The founder, because the email was created with their credit card and their email address. So, uh, I would, I would recommend, you know, you talk to them first before doing this. That might be a good idea. Um, you do want to keep your job. Here's another one. Uh, you want to enable encryption. So, uh, you don't, you don't want to allow any objects to be put into your S3 buckets, uh, unless they're meeting this criteria. And in this case, the criteria is that it's encrypted with AES 256, for example. Same thing with S3 buc, uh, public access. Uh, here's another one. So, I'm still experimenting with this a little bit, so, um, but it seems to be working. Okay, so troubleshooting. Um, there's a lot of troubleshooting that I went through, um, in this. I definitely recommend you take a deep reading of IM and IM syntax, especially when you're looking at the conditional operators and, and trying to put a list of things. Um, so it's, it's quite tricky, um, especially in this condition map, trying to define it. Uh, but, you know, it's, it's, um, it's all based on IM, so it's, it's pretty straightforward. And, you know, just some little like things. Even I was trying to do a, uh, little Easter egg as far as a version number and, uh, turns out that, you know, AWS doesn't like that. Does anyone know what that date is? Oh, right. Yeah, the date is supposed to be yes, but uh, that date right there, November 5th, 1955. Does anybody know that date? Yes, back to the future. Pretty good. Yeah, I was watching at the time. Actually, I have a few dates throughout their presentation, um, little Easter eggs from different things throughout movie history. So, yeah, and then same thing here. Um, if you want to deny a role, uh, then you could specify the role, but then if you want to, uh, specify an actual IM user, you will need to use the condition string not like. Um, that was quite annoying as well. So, that's something there. Uh, this is a really cool website I found after doing a lot of the stuff anyway. Um, it's Asecure.cloud. Uh, the person that's created this is amazing and, and, uh, they have service control policies, uh, five security groups, a lot of different things that will let you even, uh, put confirmation templates together and just deploy. Uh, of course, you know, deploy cautiously to, uh, dev. But, um, it's a good library of a lot of different service control policies. Uh, the ones I showed you are the ones that, that, that I created and kind of implemented. Um, but that person has a lot of ones like, like, uh, preventing people from deleting KMS keys, for example, right? Uh, that's a really good one. Um, so, I mean, imagine if, if someone deleted your KMS keys, you can no longer, uh, decrypt your information. So, uh, it's quite, quite precarious. And that's about it. This is my contact info. Um, I blog about stuff on AWS, uh, quite sometimes, uh, you know, frequently. And, um, I'd like to open up for questions if there's any questions. Yes. That's right. Yeah. Yeah. Yeah. That's, that's exactly right. You'd have, so you have to take that into consideration, uh, for things. I mean, I think AWS is working solely to limit those root actions. I'm kind of annoyed that there are still things that you need root for, but yeah, that's exactly right. Yes. So the question is, uh, if I get it right. And the previous question was, um, do you have to, when you want to do things that require root action, uh, we're gonna have to remove the service control policy. So that was a previous question. And this question is, what do you do about over permissioning? Oh yeah, there are a few, uh, tools out there that would, that would give you, um, a list of permissions that are recently used by particular users. And AWS has some out of the box section as well. Yes. Yes. That's right. It only applies to CloudTrail. Only CloudTrail. So that, that screen there was a typical CloudTrail creation screen. But you only, you have that extra dialog box for, um, when it's being done from the master account. And so all the settings that you have there are gonna create a CloudTrail in each new account, or each account, uh, and any new accounts. That's right. Well, depending on how you configure it. So if you configure for all regions, then yeah, that'll apply. But it'll apply for the same bucket. And, uh, the great part is for new accounts that are created later, which is a little, like a, a, a, a lifesaver. Yes. That's right. That's right. Yes. Um, one sort of make friends with procurement. Yes. Yes. Procurement is, uh, there are a couple of tools out there actually that I found, uh, that will, um, help you find Shadow IT, uh, accounts out there. So they'll hook up into your Expensify and to your Expensing Tools and look at your credit card, uh, expenses and identify, oh, someone created an AWS account. Oh, look at this. And they'll identify this, uh, Shadow IT stuff for you. So I find that. And it's, it's really interesting because, uh, we ran into issues where eight of us didn't have permission to do things with that account. You probably ran into the same thing. Uh, and so you had to get the account owner to give you permission to handle that account. Yes. In situations where how do you stop them or what mechanisms would you be able to use to stop them from just editing that and through permission when they decide, well, now I want to use this for, uh, functions. So I'm going to go change it back to a wild card and not deny it. Oh yeah. Don't give them that permission. So that, that, that, that is, um, only that you can only do that from the master account. So in any case, you want to limit access to your master account to only limit a few people who could apply those SCPs. So it's an administrative thing. So, you know, a limit, I mean, in general, general rule of thumb is limit master account access to only a few admins. Is that, is that answer your question? The question was, how do you limit access from people changing the flags, uh, on SCPs? And the idea would be to limit access. Uh, yes. Say again. Oh, security hub. Um, I've played with it, um, with guard duty. Yeah, I mean, I've used it, so, um, it won't, it won't monitor everything, but, um, in this, what I'm talking about, I guess is more prevention. So kind of setting up guard rails to prevent, uh, things from happening. So if you're noticing things, you could use SCPs to prevent things, but you want to get at the root cause of what's, what's happening in your environment. Yes. Privileged IAM accounts. Uh, so the question is, do you recommend any tools to, uh, manage privileged IAM accounts, um, in AWS? Uh, there's a couple, I mean, there's a couple tools out of the box, uh, from AWS that will have you run permissions and show you what permissions, uh, IAM users are using, uh, out of the box. And so you can, um, do an audit of that. Um, I recommend, you know, just as a best practice, having different roles. You know, you have a developer, maybe a super developer, uh, your network admin, uh, IAM admin, um, you know, very few super admins, right? Um, and then try to use automation so that things are run and pushed through Terraform and GitHub so that there's an audit log, an audit trail of what's done. And so if you can see things done through a GitHub commit, um, and it's been approved, that PR has been approved, then you have some sort of audit trail and some permissions. And answer your question? Kind of, right? Yes. Uh, that could be a thing. That could be a thing. I haven't used it, but I think that could be a great, uh, that, I mean, the, I think the, the you're unlimited in, in what you could do. Yes. I was just gonna say, can you use SCPs to enforce tagging? I don't know. Do you have specific tags on store? Right. Anything that's great on a better account? I can imagine you can. I, I believe you, right. I have a description tag. Right. Yeah. I, I, so the question is, can you use SCPs to enforce tags? I believe you can. Um, so basically what I would imagine is, uh, you know, when, when, when you have an EC2 run, uh, put a condition to require a tag, for example. Um, but I haven't created one, but yeah, I would imagine so. Yes. Um, so there's a few tools out there. Um, I guess ask me afterwards, I could, I could answer. There's a few out of the box from, uh, CloudTrail, I'm sorry, from AWS, that will let you take a look at permissions. Are you talking about permissions? Permissions question? So I, I, if I understand the question of what tools are there available to take a look at permissions and audit, audit logs or just permissions? So with audit logs, I mean, so CloudTrail, you have now, uh, a lot of the IAM logs are going in CloudTrail. You could use any sort of tool, uh, Elk, Splunk, SumoLogic. Uh, there's a few, there's a bunch out there. Um, yeah, I don't recommend specific vendors, uh, necessarily. So, yeah. There's, okay, just something was wrong. Somebody got something like it automatically goes through like that. Are there teams that exist? There are. So the question is, are there anomaly tools, uh, out there that look for anomalies? Well, there's GuardDuty out of the box, uh, for AWS. I don't work for AWS, by the way. Um, there are other tools that will ingest your logs and look for anomalies. A lot of times you have to write, uh, those out. Uh, but yeah, I mean, Security Hub and GuardDuty and that whole like ecosystem, that's AWS's recommendation. Yes. Uh, yeah, I'm going to be posting these slides. So yeah, these slides will be posted. Yes. I have, um, but I say it with a sigh. So, um, it's, it's, um, I don't know if I want to go on record, but yeah, I've used AWS. I've used AWS config. The question is, I've used AWS config and what are your thoughts on that? Um, I have thoughts on that. Um, I think, you know, it works for, for some organizations. Um, it's something good. I think it's better than nothing. Um, but I think with the convergence of a lot of tools that are coming out there, there's a lot of overlap that I'm seeing. So, and that's the hard thing with AWS is like, you know, you'll find someone that creates a tool either open source or commercial and then AWS comes with something, but then it's kind of half ass, like everything else that comes out of AWS when, you know, when it comes out. Uh, it's kind of like, uh, AWS kind of beta tests things on, on the public. And then, you know, six months later, it's kind of better.