Day 1 - 03 - Applying Pareto’s Principle to Securing AWS with SCPS - Ayman Elsawah

Hey everybody, how's it going? Okay, I'm going to stand right here because the projector is kind of bright. So, my talk today is using Pareto's principles to secure AWS accounts using service control policies. So, a little about me. I love AWS. I've embraced it for at least probably five, six years now. 0:41 I knew that it was going to be the thing, so I kind of just jumped all in it. And I run a consultancy that helps CTOs or security-minded CTOs get their security up to speed. I also am really into coffee. So this is my coffee set at home. It drives my wife crazy, but I can talk about single origin coffee and brewing methods all day long. So a little OPSEC leakage there. 1:11 If you want to get to me, you can tell me about coffee. I also have a podcast called Getting Into Infosec and what I do there is I interview folks on how they got into the field so that others looking to get into the field can also be encouraged and learn from their experience and kind of save some time. And I also wrote a book so if you were to sit down with me with coffee and I would tell you, you know, how to get in from zero, this would be everything I would say correctly. 1:44 And I'm also really into Hawaiian shirts. So if you see me on a Friday, I like wearing Hawaiian shirts. I think it's really important to keep it lively. And I'm really excited about Picard coming up. So I might throw some Star Trek references here and there. Okay, so a little bit of a survey. How many folks here have AWS accounts, like 10 or less accounts, or run or manage 10 or less? Okay, and then how about 25 accounts? 2:17 Okay, great. And then 75 or more accounts? Okay. So this talk is really geared to take advantage of AWS organizations, and when you have a lot of accounts, you want to take advantage of AWS organizations that run SAPs at the organization level. So a little primer, what's Pareto's principle? The idea is that you want to make 20% effort to have 80% results. 2:48 80-20 rule. If you ever heard the 80-20 rule, it's actually called Pareto's Principle. So, let me, so, a show of hands, who here has an 80-60 rule? Okay, okay, great. Great, okay, cool. So, common cloud security issues. Many, you know, I wasn't sure of the audience, so I'm just gonna go over this. Some of you might know this or not, but let's go over it. So IAM, for example, so many times there's keys in source code, so that's a common issue. 3:24 All you need is a key, permissions are tied to these keys and so a lot of times developers are lazy or don't know and may put keys in source code. Also adding a lot of permissions Yes, you might be using role-based access, which is great, but then the role itself might have EC2 star, IAM star, and I have actually seen this out there, so that's kind of problematic. Storage, a lot of leaky buckets, we've heard about S3 buckets, I'll talk about that a little bit later. 3:57 And logging, so lack of logging. And the thing is with the cloud, the cloud is, everybody This is what everybody thinks of the cloud. I'm gonna be able to do this. You're essentially giving Talk on information security covering CISO, vCISO, red team, threat modeling, Enterprise Security Weekly, Security Cafe, Getting Into Infosec, Ayman Elsawah, Adrian Sanabria Talk on information security covering CISO, vCISO, red team, threat modeling, Enterprise Security Weekly, Security Cafe, Getting Into Infosec, Ayman Elsawah, Adrian Sanabria Talk on information security covering CISO, vCISO, red team, threat modeling, Enterprise Security Weekly, Security Cafe, Getting Into Infosec, Ayman Elsawah, Adrian Sanabria 4:41 So, leaky S3 buckets. Well, somebody actually created a GitHub page of all the S3 bucket leaks that have been out there, right? You know, even GoDaddy, a salesperson, leaked a lot of information. FedEx, a lot of companies. So, I don't need to go into it, but like, you know, if you look at it, this is as of last year, 9 billion pieces of data. So, we don't need a reminder on... Why S3 buckets like that? 5:12 I mean, sorry, I'm leaking S3 buckets. So let's talk about IAM. IAM is the new perimeter, right? I think we can all agree in the cloud space, IAM used to be the network, but IAM is really the new perimeter. So with a security access key and a secret key like this, and any permissions tied to it, you can do whatever you want. So we want to stay away from this. Now, who here knows about Codespaces? Who's here? 5:42 Okay. So Codespaces was a company that offered rock-solid, secure, and affordable GitHub hosting. Okay? So if they say it's rock-solid and secure, then it must be, right? So this was their website as of, some of you will say, like, this was their website when they were in production. This was the website a couple days later. So that was the website of June 14th. This was the 17th. 6:13 What happened was someone had the root keys of the company leaked online and this attacker went and literally just terminated all their instances and their backups and everything. So they're just gone. And so literally the company went out of business overnight. And so this was what their webpage looked like on the 17th, or a couple days later. And in summary, this is what they said. So everything was deleted. So this is why IAM is really important. 6:45 Okay, so why AWS organizations and SCP? Well, so a little background. This talk is really to raise awareness. It's not like super, it's not rocket science, right? But there's a lot of folks that are not taking advantage of this. And so it's really to kind of increase awareness. Because, you know, again, it's where you can just, Deploy a few lines and kind of get everything set up and with only a few lines of code you can really secure a lot of AWS accounts so that's the idea and you want to have it as a guardrail we're not going to go through all the security best practices you're not going to be super secure from just this but it really helps make your job a lot easier 7:32 So, here's a little overview. Say you have multiple accounts, and you have them organized according to a database-as-well-architected framework. Okay, so you have a security account, a log archive, a networking account, shared services, and then developers may have their own accounts or not, and then, you know, your production and your pre-prod and your staging, things like that. So, and God forbid, maybe you still have a data center, I don't know. So... 8:02 This is a lot to manage. Okay, and so what Iterus SEPs does is it applies at the org level. So ideally you would have this set up in different organizations such as this. Okay, so you've taken your accounts and now you've applied some sort of logical separation to your accounts to like say, okay, it's dev, test, prod. And you're creating OUs and you can have sub OUs. And you can apply these SCPs at any level of OU, okay? You can just apply it at the top level OU or sub level OUs, anywhere you'd like. 8:39 And moving your accounts is like super easy. I'll walk through it in a second. And so here's really like a playbook of what you'd want to do if you don't have AWS organizations and SCP set up. You'd want to create a master account with no resources, create the organization, enable all the features, create OUs, and then move those accounts and you're literally just dragging and dropping. And then enable policies. I'll go through all this in the next few slides, but this is really like everything, my whole talk in one slide. 9:13 Then, you know, set up logging, because it's a best practice, so centralize your logs. And then start applying SEPs that we're going to go through. Okay, really important, do not apply resources or do not apply SEPs onto your master account. Okay, the whole reason you have to migrate is usually you start off with your master account and your master account has resources. And so you have to go through this whole headache because it's just a rule. 9:45 Okay, so if you apply SEPs to your master account, you can lock yourself out. It's just, you get this kind of feedback loop. So your master account, you want it to be no resources, And just really pristine from there. So it's really bad. Okay, so migrating your master account. Well, depending on the size of your organization, call your rep and let them know because it's going to affect your billing. You might have reserved instances or like enterprise billing discount. So it's going to be a medium to big deal, right? 10:18 You might have to sign a new contract and they still do it over paper. It's kind of weird. So hopefully it's changed in the past few months. So it's simple yet complicated. You know, you're also going to lose your billing history on your account. So if you're using the GUI for that, let your folks know. So try to stay away from budget season, you know, doing this during budget season. I'm working with a company right now and they're like, yeah, we can't do this right now because everybody's still using Cost Explorer. 10:49 I'm like, okay, fine. Can you let me do this, please? So... Yeah, so you at least sign a new agreement and then you'll create a new org and unlink and link your accounts. And then check your bill because you might get a blip. You might see like a $100,000 increase and then a $100,000 credit the next month, so it'd be kind of funny. Okay, so then now we just want to organize our organization. How does your organization work? Do you have, you know, everything separated in prod and staging and, you know, nice and clean and logically? 11:23 So this might take baby steps. In one place, they had a lot of acquisitions. And these acquisitions, they didn't want to mess with them. So I just created another OU. And I just threw them there, and I didn't do anything with that because I don't want to rock the boat. You know, in security, you have to choose your balance, right? Oh, also, you want to do a request to limit increase. So by default, it's only 10. I'm sorry, it's like five. I can't remember what it was. 11:53 But you want to ask for more accounts appropriate to your organization. So this is how it looks like. So now you've set up your organization. You've set up prod, staging, dev, and other. And you just literally can drag and drop. And then you have your group account. You can have multiple use. So the whole use, I think, can apply to three or five levels deep documentation online. And then just enable it. Yes, there's nothing wrong with doing it. Just click enable. You're not doing anything yet. 12:24 You don't have any SAPs, so it's OK. All right, now we're ready to apply SEPs. I'm glad someone's getting the car jokes. Okay, something to know, you know, SEPs take effect immediately. So please test appropriately. Don't do this on a Friday afternoon, okay? It's not a good idea. So test, test, test, test on your own test account. Make sure it works. 12:54 Really, I mean, you know, the first time I did this, I was, like, super scared. I'm still, like, even when Okay, so before we get into ICPs, one other thing that you can take advantage of now with your nice, new, well-organized account, organization, is CloudTrail. You can create this CloudTrail at the master account. This is one resource I would say you can do. And you would see this dialog right here. So you can apply this trail to your whole organization. 13:25 So any new account that comes up will automatically have this trail there. And you'll see why I do this later. It's just easier to manage from SAP perspective. Unfortunately, we don't have the ability to do this at the OU level. I would like that to happen. Put in a request for main OS, but who knows? That's never going to see the light of day. Yeah. So now that we have this CloudTrail account or CloudTrail set up in this particular bucket set up, now we can put an SEP to block this CloudTrail from being deleted all over. 14:01 And so basically you would apply this SEP. So this is an SEP that you would apply at any, like so at the prod and the dev levels. And that's it. Have these, you know, it's like, what is this, like six lines? And this would prevent someone from deleting your cloud trails. So this is super important to have. 14:31 Now also protecting your root account so you don't want, oh sorry. Oh so here's an example of me trying to delete the cloud shell and I'm doing this as root. So I'm logged in as root in one of the accounts and it won't let me do it. So these SCPs are really, really powerful. And I'm open to taking questions. This is not gonna be like a whole 45 minute talk so I'm open to questions throughout. So feel free and I'll leave a lot of time at the end for questions. So, VPC flow logs. 15:02 So, also, again, protecting your logs. You want to have VPC flow logs set up. Here's an example SAP to protect those log groups. You can tune it to your liking, of course. I don't know which water is mine. That's yours. This one? Thanks. So... Okay, limiting your regions. I like this one a lot. So, you know, your production probably only runs in US East, maybe US West one, but it doesn't run in Asia Pacific, it doesn't run in EU, it doesn't run in Ohio. 15:47 So, you know, if an attacker were to get into an account, the first thing I would do is Create a resource or create EC2 instances somewhere that you don't check, right? So we want to stop that. It also helps from a billing perspective. So you know where all your resources are, and so if a developer or someone wants to set up a coin mining, That's what they would do, right? 16:18 So again, understanding where your resources are and just kind of walking that down. Now this might break some of your monitoring because what I'm doing here is denying EC2 describe all over, except for these regions. So if you're relying on this API, then it might break some of your tools. And you can see here, this is me trying to launch something in a region outside of US East 1 and 2, or West 2, and it's not working at all. 16:56 Okay, now this is another one, denying instance types. So, again, it comes to billing, so you don't want everyone launching, you know, a four GPU instance and racking up, you know, lots of dollars and trying to answer questions on that. This is a way to kind of limit instance types that you could run. So you can take it two ways. You can take it to deny instance types. So say you might not know exactly what everyone wants to allow. 17:26 You can take the deny approach. Or you can take the allow approach. I'm only going to allow A's and T3's and M5's and M4's. Now, another way you can save money is by allowing only like the latest generation instances. So, a T3 is cheaper than a T2. So, even from that perspective, you can save money. So, you know, you kind of want to show security in a good light. Hey, we're saving money. So... I have customers that ask for this based on mobile. 17:58 Say again? Based on mobile. Can we customize it based on the role? I don't think so. We could put a condition. Yeah, maybe there might be a condition actually that you can apply if IAM role is this. Yeah. Yeah, so, in about, in May or March, SCP, or eight of us, added IAM-like permissions to SCPs, which really increased the scope of what we can do with SCPs. 18:34 So, yeah, roles are always there, as long as it's within a condition statement. Again, limiting root actions, so we don't want actions to be done as root. We want to stay away from that. Best practice for root account is to apply MFA and then lock it away and make sure that very few people have access to it. But of course, apply it carefully and make sure that you're testing properly. 19:07 And here is a screen of myself trying to go in and look at the EC2 dashboard. I can't do anything. This is with SCP in place. Here's another one for requiring S2 encryption. So you want to encrypt your stuff to make sure you're in compliance and best practices. So here's another one. And then preventing S3 public access, right? So when, you know, not allowing someone to create a bucket with public access. 19:43 Now, troubleshooting. So, again, SEPs are using IAM-like syntax, so... You know, there's a lot of, you know, it can be tricky, especially the condition block. I, you know, I spent a lot of time trying to get some of these conditions right, and I found, like, some really tiny, obscure, like, documentation after, you know, going for a while. You know, I recommend, you know, just, you know, whenever you get frustrated, just walk, take a walk and come back to it, you know, let that subconscious do the processing. 20:16 But this is an example of, you know, trying to do the condition block. So if you look here, This was where that was helpful. Also, knowing some of the little nuances of AWS. I tried to change the date here to that because I was just trying to be a little goofy. Does anybody know this date? November 5th, 1955. 20:49 It was a date in Back to the Future, you know, that he went back to. But, you know, AWS was not happy with that date. Okay, fine. And then also limiting principles. So, you know, the principle syntax in SAP is a little different than I would have liked. So, this was something that I also, a little tip there. 21:22 Okay, and I also found a really valuable site that has a whole slew of SAPs more than this. I talked to the developer and he does not want to Share his name. But it's a really useful website, asecure.cloud, and there's tons of CloudFormation templates and things there that I found super useful. So that's about it. 21:53 And thanks. Just want to open it to questions. Thank you.