BSidesATL 2020 - Detect: Conquering the Cloud: Defense-in-Depth Strategies for Amazon Web Services

we want to make sure that we thank all of our sponsors for supporting this year's virtual conference especially in light of the fact that they all chose to stay with us even though we transition from a physical to a virtual event so again diamond level Warner media gold level Kennesaw State University Kohl's college and the KSU Department of Information Systems Bishop Fox coal fire genuine parts company and NCR at the crystal level critical path and synopsis at the Silver level Aaron's binary Defense Black Hills Information Security Cora light and guide point security at the bronze level NCC group a couple of in-kind sponsors yesterday we had great training from EC Council and also today we've got great great relationship

working with a secure code warrior for the virtual CTF that they are running over in that track today we would also like to thank the following individuals and organizations for contributing to our raffle prize effort crosshair information technology Jo gray and information and offensive security and pentester lab and so get used to hearing that you will hear that multiple times throughout the day so at this point in time I would like for everybody to welcome Shane pedan who will be talking running us through his presentation conquering the cloud defense in depth strategies for Amazon Web Services let me stop sharing my screen here and then Shane it will be yours there you go thank you

all right guys I'm Shane Keaton as Andy mentioned also former Kennesaw State Alumni went to school and today I'm going to be talking about a defense in depth for Amazon Web Services I've got a Q&A section at the end of the presentation so I'm going to minimize slack or just try to keep it in the corner of the eye of my otherwise Miya Miya ATD is going to get the best of me I'm going to go crazy so AWS is a really interesting topic so for this talk I'm going to keep it kind of maybe maybe just like kind of semi technical but not hyper-technical I know that there's probably some engineers in the in the session that

probably had mega expertise that vastly outweighs my own so by all means forgive me if I get anything wrong and actually up I'll kick in Who I am so as I mentioned I haven't mentioned yet I am a consultant like a vet our keynote speaker and have actually worked with a bit on past projects with crossed paths it's a small world I'm not an engineer I did do some development back in the day I'm a former IT guy from an earlier career but day-to-day I don't turn the gear so why should you listen to anything that I have to say about AWS I'm usually on the other side on the audit side of the house so usually doing

a security assessment on it's scanning reviewing policies including even the technical policies actually within AWS configurations and then I'm also a pin test peer reviewer I'm pretty pretty bad at pin testing but I do a lot of pure of you and I'm good at picking things out of them asking the hard questions and looking at them from the perspective of my client and also as a business owner and a stakeholder so I read a ton of pin tests in risk 360 my team is pushing to actually have some amazing pen testers so I'm constantly also seeing how AWS is getting gamed and seeing where clients are failing and those patterns that emerge over and over

and I'll share some of those of those as we go through my defensive death strategy because it's really largely driven off of really the state three or four issues that we see again and again at pin cysts and I also helped clients develop controls so where are offset team where I work are always attacking I'm usually on the other side helping companies figure out how to design their environment either to meet certain compliance needs especially HIPAA and PCI you know you have to think a lot about how you design your AWS environment to meet some of these more stringent industry and regulatory standards so we're usually thinking from both a compliance perspective and also purely a harness perspective and

avoiding a lot of the pitfalls that you see happen over and over again and over you know the time I've been looking at AWS environm which spend six years and is really ramped up a lot over the last three years I've been fortunate enough to see everything from the wow that's awesome to the are you kidding these sadly I've seen the whole gamut probably probably 60 to 70 different companies at this point over them the life of my career most of them are high-growth startups if you pull out your phone in scroll third of the appleís I've probably seen the AWS environment behind at least a few of those apps that you have on your phone

so I'm really really lucky um as we go through this talk ba means like I said they're select messages up there we'll see it in the end and I'll give you some context about what we're we're talking about here where we see the biggest issues so the the vast majority of issues that we see in AWS are related to miss configuration and poor commits tremendous right and those in turn lead to insider threat a lot more times than often because AWS is so complex that it's it's easy to hide backdoors in it if you just don't have a well governed environment in a well controlled environment and these these issues spandy span companies and organizations

of all sizes in the last two years even all the way up to US Department of Defense there was even a consultant for the Republican National Committee an analytics firm that gave away all of our boat better a few years ago so that's all out there you know Accenture have another large consulting firm they got hit with poorly managed s3 buckets which are basically online storage buckets awhile back and according to Gartner all of this boils them for the most part to poor access management and poor configuration and then somebody taking advantage of that so how is this really different from what has always been happy you know I say security in real life you know are these

really just the same problems I believe existed is this just a another people problem like like another IT problem I'd argue no it's actually bigger than the 19 because the cloud has created a new breed of IT IT professionals that have to have very different skill sets than what we previously saw in last generations IT personnel so in the past you could get away really with having a strong perimeter a strong fire walled-off Network and then from that fire one off network you can sometimes get away with having some really good security appliances and security utilities inside that network that we're very actively working on your behalf and supporting a lot the most common attacks

and kind of feel good with having a really insecure environment that is actually somewhat secure and hard to hard to attack if you're an attacker and when you have these big enterprise-grade defenses in place web infrastructure is a lot different because it's so scalable it's so quick to change and it's all just up there and internet connected by nature of what it is that it's very easy to accidentally open it up to the public world and you also I found in my experience have a lot more people interacting with it a lot more developer teams a lot more engineering teams and whatnot and they're usually doing it programmatically so you don't usually have like a small team of network

engineers that guard these firewalls like you know like it's their crown jewels instead you have a lot of different teams setting up different infrastructure across the array of whatever AWS sets the companies purchased and sometimes things got a sink sometimes teams aren't following the same change procedures you know in teams start to grow organically or that get different cultures some are more locked down than others so we see a lot Harvard actually locked down you margaret's incontrolable and it's it's really just due to how fast things move in the cloud so we're about to start getting into my strategies I've developed these basically as a starting point this is that the in buff will be

on list of things you should do these are basically the foundations to meet both security and compliance requirements as we go through all of these can be much many more layers of deeper than what they are and I've also just tried to cut keep the conversation and options limited to AWS centric solutions there's a lot of third-party solutions that are amazing but we can talk for days that could be that that's a conference in of itself you know it's called blackhat you know I mean basically everyone I'm selling their stuff so as we go through this think about it is this is a base one two to make sure that you just have your basics checked off and then think about

ways that you can build upon it from there so we'll kick into a strategy number one log some there's a certain amount of logging with an AWS that is enabled by default and AWS is logging solutions called cloud trail and basically AWS is driven completely by AP dust so everything is these programmable interfaces and on the backend that works a lot different than what your typical Windows Active Directory environment used to look like and AWS is really good about allowing you to sup all that information up but I've seen some companies that either scale back their logging or maybe they just weren't enabling it enabling cloud routes everywhere that this should be and not getting a holistic picture of everything

that's happening in the organization so the first thing you have to do is enable logging because if you can't recreate history you can't track down things that are happening in the background if you can't invest incidents that have happened in the past I mean you're you have no way of getting to the root cause of what's happening to seeing what's happening or detecting it you're basically flying blind another big things we've seen in pen test is they're pre-built modules pre-built pen test modules that are open source anybody can grab that are made to attack logs and what they will do is not necessarily kill login you're disabled but they'll go in and try to strategically limit logging or Optus

give them or or destroy certain logs that may may be damaging or reveal what they're doing in the environment so my tip number one is you get ax access lock access rights to logs and then also making sure that things like logs around s3 buckets which are your storage and basically simple storage with an AWS make sure that those logs are also protected and encrypted so that you can't see who's accessing what are the clear and that's another great point logs aren't necessarily encrypted by default another mistake and challenge we see customers with is not understanding where that shared responsibility matrix between AWS and the company ends and begins so people might assume oh it's

AWS it's secure well yes AWS does a good job of securing the underlying infrastructure but that doesn't mean they're encrypting all your stuff by the fall and that doesn't mean that they're limiting access by default so you got to make sure also that you're actually tripped in your lives and then finally you gotta make sure that you're retaining them so you can set life cycle policies and you can store those logs in this three but if you don't set them to meet whatever industry requirements or regulatory requirements you're bold to you might get yourself in trouble it just shouldn't assume that it's happening you shouldn't assume that oh well if I ever have an incident AWS is

taking care of me and I'm just gonna go grab them all a really good example is a HIPAA it has a 7 year retention on anything related to health care processing and transact that are happening so if you're a company that's touching pH I a lot of companies do you know that compliance people know this stuff that maybe the technical people don't and maybe that business requirement never got fed down to them and they're like well Henk we have to start app logs you know cloud trust for seven years and nobody ever told me that the end of the default is nowhere near seven years you know maybe they or maybe we had a policy that was

just given rid of them so that we're just not incurring these extra cost of retaining these logs indefinitely or for an extended period of time you gotta have those conversations and figure that out and then another gotcha I've found that is worth noting is centrally managing those logs as you start scaling up their AWS infrastructure teams will start distributing their infrastructure across what are called availability zones this allows you to basically have one set of AWS infrastructure say on the west coast and another on the East Coast and it helps you achieve certain availability objectives or business continuity objectives there may be some failover objectives if you're not centrally logging and pulling all your logs together you're going to start

having divisions of truth and it's going to get really hard to do effective investigations or tracking or if you're feeding those logs into something like another AWS tool cloud watch which can ingest AWS logs and visualize them before you and do automated learning on them and all that you got to get them all together at the same place so that's another thing I've seen some teams get tripped up on so after you've done with your logs neck good step is to start locking down the console so in AWS use different ways of accessing your environment you can log into the console which is basically go to the website login with your credentials and just start pointing and

clicking this is probably what's comfortable to your more traditional IT employee that's just working in Active Directory I know Active Directory has moved a lot more towards PowerShell and a lot more of that is command driven more and more all the time but traditionally back when I worked at night to you it was all it was all front-end pointing and clicking AWS will give you that same capability to an extent in the console but then outside of that console a lot of other people are interacting with it through software development kits an API access and that's where I see the majority pretty much everybody working in it that's really AWS so that means the console almost becomes a security

liability everybody's going over the command line to get to AWS and this route access in the console kind of gets neglected and forgotten so after you you know get your logging in place you've got a AWS setup my next big one is now locked on that console access and don't let anybody have access to it that doesn't usually that's gonna be limited to like some cyber liability engineering guys and maybe maybe a high-level executive and the company like the CTO somebody like that and then you also gotta put MFA multi-factor authentication on it MFA is actually also a compliance requirement now for a lot of the popular standards that you see out there it actually like

PCI explicitly says hey all admin can't console access you gotta admit so in addition to just being smart it's probably also a compliance requirement for your company if you're dealing with most any kind of sensitive data at all I'd also say after you put MFA make sure that password strong and then go into your user ws I am identity access management console and start really paring down all those permissions to anybody that has that console access and also make sure that you're not letting people that have console access also have programmatic access on the same account it's it's really a big no-no just to allow people to both hit it on the command line and

also be able to interactively log in with the same account I see teams consistently allow this to happen and I think it comes up over and over again that everybody's like no no you need you need to have the segregation of duties just so that we can really lock down and how people are accessing this if one account is compromised and don't automatically get access to the other good tip I have root account nobody should really be interacting programmatically with your environment is fruit you do need to be as an identifiable user in identity access management so delete those API keys just let the root login as root when you need it and that's kind of a break last

situation you should be logging in as the root account anyway and don't let root do anything but actually hit that admin account and I've seen some companies go as far as printing up those word accounts the credentials and putting them in a fire safe and then also putting them in like a cryptographic key management system like a hardware security module something like that and then just not letting anybody who's root ever nobody actually knows the password unless they need to go get it for some reason and then also going back to strategy number one make sure that crown cloud trail logging is it able especially on anything in the root account is doing and I've seen some

teams set up hi automatically flag high risk alerts if root does anything if root touches anything at all that's an incident and that's an instant security incident in their mind and it gets elevated to the top of the queue and it seemed as almost like a breach because nobody should have room so strategy number three this is a tough one develop an I am management strategy this is this has always been hard everywhere even back in the days of Active Directory I guess Active Directory is still a thing I just see less of it personally but even in Active Directory it's really hard to manage access because in large organizations it gets unload ly fast an

identity access management I feel it's also a little bit tougher to my manager because everything is so programmatically driven like when you went to when you want to issue new permissions usually those are taking form is a Java JavaScript object notation like your programmatically setting up permissions and spinning it to AWS and your provisioning permissions that way and it gets really hard sometimes for somebody that doesn't have console access and they're just working programmatically to really tell what their giving permission what and what the consequences it also gets hard because within ia I in there there are hundreds of pre-built permissions that you can choose from and they all do very different things so coming up with a good come up with a

good eye and strategy first starts with policies and that's really uncool to a lot of security people but it they require stepping back as a management team and saying who needs permission to do what what is our environment comprised of and what groups do do we need to to use to get this done so once you get those basic policies then you got to start mapping different roles or users to user groups and the goal should be to really make that is least privileged as possible that can get hard sometimes it can get hard for a number of reasons sometimes it's just hard to tell what groups have the ability to do what and then number four

you couldn't take a lease privilege approach and start using AWS security token services so think of it this way you can create your baseline of AWS roles what they need to have permission to I think you could create a situation where users actually have to use a sink called AWS STS security token service to dynamically be given access and assume those roles of them the access automatically the automatically expires after a short time so let me go over to the next slide real quick so best-in-class companies I've seen spend a lot of time on AWS I am they use it as a foundation of their their program their information security program usually I am serves as a launching point

into other solutions some of the best solutions I seen is people will have either Active Directory or to sweep in them integrate that with the octo r1 login these are single sign-on products and though they'll basically let optimum login stand as an authentication engine between more of an enterprise solution that you're a charm Enterprise IT teams would interact with and you'll manage user identities based on you know if they actually work here at a minimum you know whether they actually have a legitimate account between their G suite or their gmail address their enterprise address or the Microsoft account that'll integrate with octo or one login and then those will integrate with AWS and you can actually tie users together

between what they should have permission with in AWS time that I am back to your you're basically orgy suite an ad user access management permissions then often when logging give you the ability to a layer multi-factor authentication on top of it so you can actually layer on that extra layer of security and then you could even go a step further I seen some teams also use AWS security token services which are those temporary credentials that are dynamically generated and in short the way it works is that user will use their Active Directory or DC credentials to more or less authenticate AWS they'll be pre assigned roles with an AI am that the team has the management team has already

developed and created a baseline for an AWS and then those users will make a request or AWS I am will make a request for a temporary security tool and it will give you that token you'll assume that role and be given permission for a short period of time you do whatever administrative features you need to do in the environment and then the permissions expire this alleviates one of the big problems we see in pin tests where users also will be given I am permissions that have a security key attached to it and that key allows them to programmatically access the environment usually over SSH which is a remote access protocol so using the security token services it gives you

automatic Hakeem rotation and it keeps people from having that persistent access and then the integration with the enterprise security side of the house gives you the extra benefit of the time back here I am users whether they should be legitimately given access back to the HR function of the business which is usually working with enterprise security to make to provision those email accounts more or less at the time that the employee is hired so hi I am huge deal we could do a whole talk on that and I actually if you guys have any permit questions on that in particular dump those in slack because I have a lot of thoughts and I am and what I've seen

seems to good and bad on that one so we touched on this a little bit sorry but after I am the next big one is dealing with those access keys so when users interact with AWS they're usually doing so over command line like I'd mentioned and the way that you authenticate is over an access key well one problem that we seem with a lot of teams is they're given an access to eat and they never wrote them and they never expire this is for a number of reasons and it's usually not because of laziness it's actually usually because it's really hard to manage access key rotation in AWS depending on how you're architecting your solution

so for example when you're interacting with AWS is ec2 instances which is basically their basic virtual machine unit that you can stand up infrastructure in AWS a lot of times it's not easy to communicate those key rotations to the ec2 instances it can also be a challenge in databases as well so every time you read say the key everywhere that the the other half of that key the public part of that key is shared you would have to rotate it there as well because it would be a king to me saying say you show up to a cool night club in the club has a password to get in well you change your password and you

never told the other guy on the other side of the door that the password changed how do you communicate that what's an effective way to do that especially in a very complex network of infrastructure so in pin Tessa this becomes a problem because usually developers and engineers will have those keys sitting on the laptop or maybe they were accidentally committed to your source code somewhere or they're late online or they're stolen one way or the other and bad guys get a hold of these and they exploit them and if they're never rotating you're expiring you got persistently you know usable passwords essentially floating out in the internet that anybody from anywhere might be able to get into the environment if you don't

have other safeguards in place so AWS offers a few solutions for this and one of them are lambda features so lambda lambda is another talk but in short it's it's a serverless infrastructure that you can just throw functions at an AWS manages all the infrastructure processing behind it so AWS has has templates that will help you with managing queue rotation especially for databases so I'd encourage you to google that if you guys are dealing with this in your company and then the sts that I mentioned in the last slide that's another very way to get automated rotation keys so again I always come back to that if you guys can use those those rotating temporary STS

tokens definitely go for it another got you here that I already mentioned make sure that you have policies and procedures against putting your access keys and the config files of applications with a webcam fix source code all of that because it just leads to a whole world of pain and we see a ton of time to get in pen tests another strategy different access piece for different applications but again this creates more burden and complexity in the environment but it's it is a strategy of students into mistake in web applications so layered defense model for web apps one thing that I've learned about all the organizations that I've worked with is organizations never build the same app twice or they never

built it the same way as as one of their peers in the organization but a lot that we're using using very similar components on the back end that being your s3 buckets dlb web app firewall availability zones etc so as you're thinking about how you're stacking together the AWS elements of usability wrap you got to start thinking about how you how you are building security into the design so first things first you gotta identify and define all the business needs this this kind of exists outside of security you've got to think what does this have actually have to do and then as you're designing that you've got to tie that back to security departments and then those security

requirements ultimately become technical requirements so once we have those technical requirements start thinking about okay what ports do we actually need to have available to us what kind of communication does the app actually need to have available to it to to basically create this this at least privileged situation where apps are only allowed to talk to each other based on the need-to-know basis so in AWS you have the concept of virtual private clouds and then also security groups we're showing a private cloud on us create virtualized private networks within AWS and then within those you can actually have subnets and it starts to look a little bit more conceptually like your traditional IT environment where

you might have like a demon tiller DMZ and then a production network you can have different groups of applications and actually walk off and the VPC is allow you to have very explicit ingress and egress rules so when you're going through that security design phase you need to stay well who really needs to communicate with this act you might say well this is a web app and all we really need to come into this VPC is port 443 important 84 internet traffic and then you might say well we need to be able to access some energy servers maybe we want to jump through a VPN tunnel so we need to open up whatever important we need to use for

VP in here and that's another round in and then you can effectively kill everything else then be a very wise decision to make a design decision to make you can implement that with the B PC and say nothing can come in or come out but then once you're inside that V PC you can go further with the security groups which are almost like localized firewalls on every ec2 instance start thinking about how should those ec2 instances be able to talk to each other so should that's web evidence be able to talk to say this database server sure what poor okay this you know whatever port based on the data base you're using explicitly define that and block

everything else so it requires a lot of really good planning upfront and a lot of really stringent configuration management but this is really the best way to go to get that layered defense so every every step of the way you're adding layers of rules and layers of design that minimize communications and minimize the ability of attackers and malware really navigate and move within the environment one good thing that sometimes teams forget especially me when I'm doing audits carried verbs for staple where new PCs are stateless so what that means is the AWS security groups that you see on the ec2 instance they allow everything they allow nothing to come in by default but they allow

everything to go out by default so teams may have to say okay we explicitly want to allow Internet traffic he said this ec2 instance but by default if you had a she's pista malicious software misconfigured application whatever on that instance they can dial out to anything at once so once you get into that you see two instance theoretically an attacker can move anywhere out of it unless you explicitly configure that ec2 instance to not allow anything out as well except those very necessary ports the VP seeds or that virtualized Network I was talking about they have access control lists those are stateless so anything allowed to come in is not automatically automatically allowed to come so it's the it's the opposite

situation just because you allowed something in say again that legitimate in web traffic if you don't create a rule that it can head back out if you had a legitimate user hitting a web app and you didn't figure out a rule that say can communicate back out it's it's going to be a broken app until you fix that so that's something that create headaches that I've seen teams that are less familiar with AWS get frustrated and just open the floodgates that's a huge mistake you really need to be thoughtful about what you're allowing in and out of both your VP season and your security groups another big one to think about is AWS meta meta data services and

ec2 so an ec2 there's a service that allows you to see basically all the a lot of the configs on the machine and this is this is vital to allow you to effectively manage ec2 instances the problem is that if a team happens to have sensitive information like security access Keys stored on those instances attackers are regularly getting an instance an ec2 instance or though use something like a server side request forgery attacks which basically trick the web service on the ec2 instance and they're thinking that the traffic is originating from inside that instance to cough up all the secrets this is a really really big deal this is probably the second most common thing that we see

companies fell out and pin tests so this is another reason to restrict that traffic let's say that you have a web app with an SS RFP vulnerability on it an attacker is able to cop that backup at least if you have the right role port roles in place you might be able to forbid them from actually retrieving that retrieving that information or give it and using it to to siphon it out to another area of the infrastructure another thing to think about as well just think gotcha that I knew were miss if I didn't mention is you got to think about CSL termination though ah that's definitely an engineering issue that I see happen from

time to time that is really outside the scope of this talk but I just want to bring it up just in case it about he's feverish like taking notes to take back to their teams and make sure you go go that and this is just a simple example of how you can stack all of these AWS elements to get defensive depth I had a good buddy that is a real AWS engineer and when he saw this he beat it up he's like oh you definitely would architect it that way except this is graphic come from AWS set them so that just goes to show no two people have the same take on AWS but what you see here is these are

AWS services that's kids but AWS has a service like the web app are all the route 53 which is their DNS server the storage CloudFront which is a CDN or content delivery network etc and you stack them together and along the way you can create different rules or or features that will further refine what is allowed to pass through these gates if you will and it allows you different ways of interacting and every time that you add a different future you got more security problems to solve in this example you see that s3 bucket up top you might have aesthetic what they post up there and then cloud front might be grabbing that and you basically create a

really quick quick website that you just cough up let's do the end-user megafest and then within that maybe you have iframes and those iframes are time back to something very technical on the backend or some kind of API calls in the back ends well developers might assume oh we have this s3 bucket everybody needs I have access to these oh these web apps here are these static web sites will then be wrong CloudFront means access to those static web sites so these let's just said one example I've seen happen before you really got to think every step of the way what really needs access to another gotcha too is don't assume that these services are configured or right out of the box

the laughs is a great example Amazon's web firewall has tons of pre-configured rule sets but you got to customize it to whatever you're using in your environment and you got a tailor and build it to suit your needs because out of the box sure it'll block a lot of junk but it's probably not doing everything you need so that's where that shared responsibility you know where it ends and where it begins is really important to be aware of and then you'll notice how they're using an elastic load balancer in this illustration to split the infrastructure across availability zones that's that could solve a bunch of other problems it's in itself as well and give you more availability give you

more security in different ways create other security problems I guess my point is a nothing is simple and everything needs to be really thought through I think there are how it ties together and security requirements and no two teams do it the same way twice so making sure s3 that it is locked down this is probably the number one issue that we see in pin test and if you look at in the industry of the big hacks s3 buckets are a big problem by default s3 is locked down you got to open up access to it before it allows you to see anything but for whatever reasons is you start putting things in s3 teams you know wires get crossed across

teams and permissions get harder to manage you and you've really just got to pay attention to how you're granting access another problem is s3 allows for multiple ways to manage access to it so you can do it via I am you can do it yeah access control it and then there's a third way that escapes me at the moment you need to basically come come to a resolution of how you're going to manage I am as a team and make sure that you're not unintentionally exposing this is where pin testing is mega helpful because those fan testers that's the first thing one of the first things are going to look at they're going to start

scanning your s3 buckets looking within things that are unintentionally exposed to the public Internet another thing to be aware of when public access is needed I hit it on this on the left side you got to think about the origin access identity especially if you're tying it to a cloud front make sure that you just really tying down those s3 permissions like I could beat this one into the ground this is another one that could almost have a whole talk to itself another good toy see teams using is AWS Maisie Maisie will scan your buckets and look for a lot of security concerns especially if you don't want things like PCI data or credit card data store

security numbers their unique identifiers that might be considered very sensitive PII or pH I I've seen a lot of teams start pointing Edom AWS may see it s3 in scanning them as another safeguard just to make sure people aren't committing system data into clear over there to s3 and finally don't assume it's first encrypted either it's not encrypted by default don't assume communications in an animus through encrypted by default I mentioned earlier logs are not encrypted by default either finally AWS has a ton of security tools more all the time it's hard to keep up with the moment these are the ones that I've seen heavily used today there's also a lot of great third-party solutions but don't

over rely on them and as I've mentioned over and over again don't assume that they're configured right out of the gate so these all serve very different needs I think a WS guard duty is just a must-have unless you've got a third party solution that you just think it's bigger and better guard duty is so easy to turn on and it gives you a ton of value Amazon laughs as well is very important especially since if you're dealing with certain compliance standards it's a requirement so it's an easy way to get compliant quick but again don't assume that it's configured right out of the gate you may just stand it up and get compliant but that doesn't mean you're

secure AWS inspector is also another great one to stand up and it does configuration and vulnerability scans one big problem I've seen this companies move to containerized environments is that those hosts that are running the containers get locked into certain versions of Ubuntu or whatever they're using as their their cluster hosts and they never update inspector will do a good job of finding those out-of-date Asians or urgings I have ulnar abilities and lining up the security to to let them know that you need to patch and that that's a big deal that's one of the primary another primary way that we see in pin tests these teams getting home is out of patch systems AWS shield is also a no-brainer

it's basically you click on button and you get aw show that's D do a DDoS or distributed denial service service that you can turn on I believe that one is also required for some compliance requirements so another way to get compliant as well and then detective AWS detective I'm not having an opportunity to use this yet but I'm really interested to see how well it does it pulling together all of these different sources of data and allowing me to gain intelligence so be on the lookout for that it was new just come out like an q4 of last year and this was very topical if you want to go deeper you can just google AWS well architected framework

it's going to get in a lot to that ia and stuff I talked about in the V PC and s3 stuff I talked about it's also going to talk about how you set up multiple accounts and how you can tie together your accounts to get better segregation of duties like getting true segregation between your dev staging and production environments how you can pull policies together across all these different environments it's if you're a geek you'll love it if you're not a geek it'll be dry but really informative and it's free on the Kindle app so you can get it on your phone right now for free if you want to check it out and I've got

about 10 minutes left so I'm going to open up slack and take a look let me know if anybody has any questions here and feel free to to help me out of India if you saw anything come up in a mist

no I am I'm good with everything I mean there's always a lot of content right you're the expert that's why we brought you in I'm just a lowly host today yeah we yeah so we've had some good questions running in a slack Channel I don't know I know you've been focused on giving your talk I don't know if you want to take a few minutes and address some of the comments that were dropped in the channel maybe yeah I'm king through I saw ouch one or no it was an Ultron ethic Oh InfoSec asked about a casb solutions of cloud access security broker you know I'm actually I'm actually don't know that I'm in a

I don't know that I'm qualified to answer that when if I'm being honest with you guys I mean if you google you can look at the Gardiner Magic Quadrant but most of the teams that I see are using something like octa and one login to integrate with Active Directory or G suite and just tie that indirectly to their there I am that's what the really good companies that are more mature doing and I don't know if they're using any other any other solutions beyond that we had another question devops for second demos so this is something I missed it was in my notes but I miss bringing up one of the challenges with moving to

the cloud is we have a lot of IT guys that are having to move to the cloud and maybe there's a gap in skill set because the cloud is really geared towards developers more and it's really been taken over by this philosophy called DevOps which blends together development and operations for better or for worse for better because it allows you a lot more agility but worse because you lose a lot of the segregation that traditional IT had so a developer in an IT were siloed to a point where one could not adversely affect the other and you can allow IT to really just focus on doing what at your best well now you've had teams pulling in a direction where

there's a lot of shared responsibility DEP SEC Ops is meant to address some of those challenges and find ways to integrate security into the DevOps lifecycle and a lot of that would be things I mentioned in this presentation really insisting on as you go through the whole process of delivering an application and then managing its lifecycle finding places to plug security into it along the way so there's a pretty good question as well do you see any anything prior mike siestas virtual Mike C just said virtual patching is definitely worth the effort yes you are absolutely right Paul mentioned Amazon laughs block a lot of activity by default yeah one companies get a false sense of security

because you hire a pen tester they hit your wife and the wife does a great job at killing pen testers because that's what it's made to do because the pen testers are you something like burp suite just to like pummel the laughs and laughs just like no way bro we saw this coming a mile away well a laugh doesn't stop very very clever guys that actually know how to programmatically attack Web Apps as a not hit a buzzer or not hit some automated tool that just sprays it but guys that are like surgeons and find this used so you got to actually go on the left and figure out exactly it's at least privilege problem all over again

you gotta figure out what is the expected behavior of this web app what functions and calls should be happening and tune your wife to allow those and block everything else that really takes a specialized security expert to do it it takes a it takes almost a developer that has decided they really love security across to it so tuning a wife is actually really hard job it's like tuning a sim same kind of situation or SM being a security logical utility sorry I don't want us to everybody knows what these acronyms mean you guys said any other sir we need to cut it off in yeah we're right we're right up against it here we've got maybe time for one

more brief question so that we can keep running on schedule you got one so yeah honestly this is the first time we've done this today and you are the first speaker in the track how did it how did it work for you I thought that I wasn't gonna be nervous because I do this for clients all the time and then I got on here and I just totally choked on my tongue [Laughter] like what am i nervous I'm sitting in my office by myself in shorts I mean yeah not for nothing but you know we at our high count here the last time I'm keeping a periodical eye on the number of participants and we're at 131 last

time the high number awesome there you go yeah that's the high-water mark for everybody to be so I know Wes Lambert is cued up and on the panel and ready to go next so that's that's your that's your a high mark you got to beat that man yeah oh oh I dumped my slides into the appropriate chance laughs excellent thank you guys okay all right Shane thank you so much for everything