Getting started with Security in AWS

all right thanks everybody it's an honor to be your first speaker here at the first ever besides buffalo so i hope i got started before track two to officially be the first speaker uh before i get going i just want to thank everybody in a red shirt today without volunteers things like events like this don't happen um and just furthering on with uh what our fine opening speaker said we really needed the tall the tall person mic so if i wander away from the cone of the microphone please uh please let me know so my name is eclick i'm a principal security engineer with the new relic and i'm going to talk to you today about

getting started with aws security and just before we get going a couple of disclosures because no talk is complete without some i did work for amazon for eight years in their incident response team uh so i was there i currently work for new relic as a principal security engineer as with all tweets and talks these represent my own opinions not those of any employer past or present so what i really want to talk to you today are these two areas which are when you're working with security of aws there's kind of two places that you need to consider there's the control plane and the data plane and we use these terms in incident response to figure out where we actually

need to do some response where where there's potential security issues and so for folks who aren't necessarily um familiar with working in the cloud the data plane is where you're going to feel the most comfortable these are virtual machines that are running within your aws account your standard edr agents will probably be there you can do memory logging or memory forensics you can capture disk images you can do all that fun stuff the control plane is where things get interesting from an aws or really any cloud provider's perspective but this talk is going to focus primarily on aws the control plane is all of your api calls to aws itself it's the security of the aws account itself and it's the

security of anything that is a managed service and so when you're working in aws you're gonna look uh you're gonna become intimately familiar with this shared responsibility model the shared responsibility model is what aws defines of what is their problem and what is your problem a quick way you can think about this in your head is that security of the cloud is aws responsibility and security in the cloud is your responsibility uh aws will keep the data center doors locked they'll make sure that there's fiber you know that the fiber cuts when they happen when they're hunted by their natural predator the backhoe those are fixed we've got some data center people here they'll make sure that the hypervisor

security is is there but above their layer it's your responsibility so when i worked at aws i joked that our in aws security our jurisdiction was the dirt under the data center up through the hypervisor all the computers and humans and software that make up the cloud this shared responsibility model because aws offers so many services it can move a bit right so if a service is more managed it might move slightly higher on aws responsibility and only configuration is your problem if it's lower level and you're running ec2 images then patching an operating system is still your problem uh and so keep this shared responsibility model in mind it doesn't explicitly mention control plane and

data plane but you can think that those map to the the control plane is you interacting with things aws controls on that orange side and the data plane is your systems operating in the blue so i'm going to talk about control planes and data planes but we're going to have some students here so i want to make sure i do a quick mention about uh finding the financial plane which is not a g5 private jet it is the fact that in aws a click can cost you money there is an aws free tier and you can do a lot of experimentation with it there are lots of programs to get educational credits through the aws activate program

but clicks in aws can cost money leaving infrastructure around can cost money and if you create a set of credentials which we're going to talk about later if those are compromised and used by a malicious actor they can generate costs for you that you are on the hook for aws is pretty good at forgiving accidental bills credentials being committed to github accidentally someone else is going to be crypto mining with your resources within minutes contact aws i put a link here these slides are i'll tweet them out after this so people have the link um corey quinn who's a community member who runs an excellent podcast did an episode on bill shock um i really have to reiterate what he

said is that if you end up with a forty thousand dollar aws bill because someone mined some crypto on it the first thing you need to do is breathe get a support case open at aws they will be able they should be able to help you please please do not overreact if you get an accidental giant bill but be aware that when you're running in a cloud you are uh being billed for what you run before we hop into the details i want to just cover some quick three key foundational points so the first thing is there are a bunch of different ways that you can interact with a cloud service provider there's the web console itself which is where a

lot of people are going to get their start there's the cli which is where a lot of command line interfaces which is where a lot of demos will run you through and then there's the full sdk which is when you're ready to go into production that's where you're going to reach out to but in order to use either one of those three things you're going to need a set of aws credentials people will call these an a kid and a secret access key id is where akid comes from secret is the part you want to keep secret think of it as a username and password for two machines to talk to each other publishing an a kid by itself is fine

publishing a secret is never fine you should see the secret once uh when you create it and put it in a password manager when you're done with it those credentials can be applied to a few different entities within aws there are im users which are long term uh think like a windows user or a linux user there are roles which are a role you can federate into through some other identity like oidc or using octa you can create um you can create federated roles as well as using the root user which we're going to talk to in a bit the catch-all for basically any way that you're going to get some credentials in aws is called an im principle so if you

hear me use that term that just means a user a user in aws a role in aws and the last thing is by default any im principal has no permissions you have a default deny so you have to prove to aws on every api call that your i am principal has permissions to do the thing that you want to do and you do that by attaching a policy so this is a quick example of a policy they are json documents they can get and do get much more complicated than this but there are a few just quick areas that i want to run through you're going to see that this has a version number and that it looks like

it's very long ago in the past and you're going to think i want to change this to today's date leave it the way it is at some point they will change this version number it will be a glorious day today is not that day so everyone's going to have the same date and it's fine the effect is what your what does this what does this clause of this policy allow you to do so like i mentioned before aws has a default deny so you need to allow a specific permission so in this example it's allowing something you can also create a policy that denies specific actions and if folks are familiar with their venn diagrams

your awf your i am principles permissions is that middle section of the venn diagram of all the policies attached to them and aws is looking for a way to deny you uh the ability to do something so if there is any explicit denies on any of the policies attached to your i am principle you're gonna lose and you're going to be denied the next thing is the action this is there are hundreds of aws services they have tens to hundreds of actions themselves i am policies can be incredibly fine-grained which is great because it allows you to explicitly control what folks are allowed to do for folks who have never tried to roll back and implement the principle least

privilege it's tricky to pull off but you can pull it off there's great product in aws called i am access analyzer which will actually look at the history of what an ion principle has done and recommend a policy to you uh and you can chain these permissions together the last one is the resource so similar to to other role-based access controls you can say this principle is allowed to perform this action on this specific resource whether it's an s3 bucket or even a whole service like can launch any ec2 instance there's also the ability to apply permission directly to an object so in this case is an s3 bucket this is basically saying what i am

principles are allowed to interact with this object we're not going to talk a lot about resource policies today but if you're getting into aws this i am security is a group i mean it's a pretty unique place in the cloud but there are a lot of jobs we're going to talk about jobs at the end of this talk so with that kind of just quick background on i am principles and policies that's going to give us some foundation uh to roll through to the next bit of this talk so when you first get an aws account you're gonna have a username and a password uh if you have an amazon.com shopping account you technically already

have an aws account today in that case you can use it if you're thinking of starting a business or a project and you might ever want to share this account with anyone else i highly recommend that you don't use your existing amazon account for your aws the community refers to this as the underwear problem which is the startup founder had been using their amazon.com account to buy underwear for 20 years and now 10 years into the business they're being sold to another company and they have to find some way to remove the founders amazon.com order history it's a pretty tricky one so getting an isolated aws account is a pretty good idea if you're ever thinking

that this might turn into something real and not just a lab environment the root user similar to a linux system is the most powerful user in the aws account it's that initial username and password there are two things that you should ever use the root username a root username and password for one is to put a hardware mfa token on that root user and the second one is to create an iem user with the administrator access policy and then click the log out button if you come into a company and it's your first day and they use aws and you're in charge of securing it the first thing you should ask is do you use the aws root user for

anything and is there an access key in secret for that root user and then someone's going to give you an answer don't believe them go to the im console look at the credential usage report and see if there is an access key in secret for the root user and see when the last time it's been used and if it is being used in any way that is your first security priority for securing an aws account if your root user is gone you cannot feasibly evict someone from the account you're going to be in an active battle with them for the rest of time for control of that account um we're going to talk about aws account

blast radius later but i want to stress that if you ever find yourself using the root user for anything you're probably doing it wrong get that root user put a hardware mfa on it put it in your safety deposit box or wherever you keep your passports or whatever and create an imuser and you can do everything with this administrator policy so we talked about i am policies before aws is a number of what they call managed policies which are recommended job function policies that they wrote for you this is the administrator access policy and it literally says allow any action on any resource so you can do anything with this policy that the root user can do almost

but if you lose the credentials for an im user you can evict that user from the account like i mentioned before aws checks every single api call that you make they check the permissions that the iam principal is giving to see if it has the necessary policy so if you lose the credentials for an administrative im user you can delete the policy from that user and even though some will have valid credentials they won't work and so you can actually evict someone with this administrator access policy from your account uh if they have the root credentials you're not evicting them so before we move on you did put your root credentials away right everyone's going to nod at me that we're

going to put our credentials away back tables excellent um so the first things that you're actually going to do once you've put your root credentials away is you're going to want some real contact information on this account uh caveat amazon loves sending marketing material you're going to get a lot of marketing email messages and you're going to want to think of using a throwaway email we all either have used those one-time sites or whoever owns throwaway gmail.com i'm so sorry for you make sure that there is real contact information on your aws account email address phone number which can never change and billing address if for whatever reason you ever end up in a dispute over who owns the aws

account amazon is going to use that information to try and get a hold of you and if you control it it's going to be much easier to get your account back if you've made it up or it's your yahoo account that you don't really remember the password for but you're like oh yeah i think i know what that was uh you're gonna have a hard time regaining custody of that account and aws accounts have a tendency to well this is just a test account for now and then five years later it's the production account for that thing that you didn't think was going to turn into the next acd auto so keep some real contact information on

there the second thing you're going to want to do is enable cloudtrail forever region cloudtrail is your syslog for the control plane of aws so the control plane are your api calls for working with aws and cloudtrail is how you know who done it and when did they do it we're going to talk about cloudtrail later so we want to ask when you're thinking about security in aws especially in a production and setting you're going to want to ask yourself this meta question which is how many aw accounts do i actually need and the answer is if you're running you know in a real environment it's most likely more than one aws is a great document it's very long

it's called the well architected framework it talks about availability security billing controls that you can put in an aws account amazon's recommendation is that you have multiple aws accounts for multiple either projects or teams or organizations and we'll show you the their example hierarchy later the reason why we do this is because it limits the potential blast radius like i mentioned that root user has full control over an aws account if for whatever reason one is created or the credentials are lost or it's compromised and you're running your entire production network inside of one aws account you're going to have a big outage whereas if you are segmenting a specific project into a specific aws account or a

specific team within a specific aws account that team is going to have a big outage but it's it's unlikely and impossible that the blast radius of a compromised set of credentials can hop across the border of an account i say it's unlikely because there could be some sort of federated role access but it's a great way of saying especially if you have a any auditors that you're going to bring in and you're going to want to talk about you know the security controls you have in place having multiple accounts creates this nice blast radius that you can build in there and the links in here are for uh the welcome framework if you see green in

here i'll tweet these out later so there are two aws products that can help you with having multiple accounts uh you know with security you add you get some security benefit but there is some added complexity uh aws control tower is a aws opinionated version of having multiple accounts so you can select from templates from the well architected framework and you can basically launch the way amazon thinks you should uh if you're a new startup and they're like hey we want some you know aws security put in control tower is a nice way to go for a completely green field uh it's unlikely that you're going to be in a scenario where you are able to map

your organization exactly how amazon thinks and so control tower is using aws organizations which is the you have full control which is good but you have full control which is bad account hierarchy service um you will do some googling you'll see a product called aws landing zones this was the first attempt it's sort of an opinionated multi-account thing don't use it it's on the glide slope to being deprecated being not useful so if you're starting something fresh today avoid landing zones you might see it in some google history for aws multi account but if you see landing zone you're you're barking up the wrong tree so this is the uh this is from a bit of

aws documentation this shows a recommended aws account hierarchy for a multi-account setup and so the first thing is the organizational route historically this has been called the master account but it was renamed to the organizational route similar to the root user or the root the root user in aws or the root user in linux this is the the last level the highest permissions everything cascades down from this particular account it's very unlikely that you're going to use this account for anything but there needs to be a source of truth for something you're going to create a management account which is the account that your security team your aws account administrators will use to manage the organizational hierarchy

which this is a picture of yes is that corresponding to the aws so this is the root account there is a root user within that account but each one of these boxes is an aws account the question for people who are watching the recording later is does this correspond to the root user uh no it is it is the root account in the hierarchy this is a hierarchy of accounts um and so the management account is how you'll interact with all of the the uh both billing so if you're in a production environment and you're not using your credit card using invoice billing you can have your accountants get consolidated billing through there your security team can have access to

cloud trail records from the whole organizational hierarchy um this is kind of where you're going to be interacting with that organizational account for folks who are familiar with active directory you can see this organizational unit uh survives in the cloud so you can create an organizational unit which is a group of aws accounts so a common one is production and development like all good things you can group your groups so there can be nested ou's within the larger organizational unit and policies which we're going to talk about in a second can be applied to either the ou or the member accounts so the member accounts are those individual pockets of aws that are out there so an example would be i have an

ou for development and i have a member account for the intern projects which we all love a good intern project interns out there you're great but you tend to leave code around and we have to fix it later uh but thank you for making it in the first place but in this case i could give an intern that full administrator access policy star.star they could break everything they could fix everything too but they could break everything but because it's isolated to this specific member account they can't break production which is in the other a different member account and the nice thing about this organizational policy is similar to active directory where group policies can push controls down from the higher

can push controls from the top of the hierarchy down you can apply those same policy statements that we talked about before you can apply those at the organizational route and they will cascade down to all the member accounts and ous within the hierarchy and this gives you the ability to say we as a security team don't use dynamodb we don't do it for whatever reason our auditors say we don't we've decided not to whatever reason we don't at the organizational root level you can put a deny policy on the dynamodb service and even if i'm the account administrator within a member account and i try to spin up dynamodb i should have those permissions right i have

unlimited access to any resource of my account but because my member account is a member of this organizational hierarchy i will be denied right aws is always looking for a way to deny your permissions if there's a d if there is a deny statement on that hierarch or on that union of all of the policies that you have you're going to get denied so account hierarchies are a great way especially if you're running not a lab environment that's really overkill for a lab environment but if you are in charge of security for an aws account in a business or an organization this is a great way to give a lot of flexibility to your member account your account members uh

administrators while still having some security control over uh their various shenanigans so i do work at urelic so i have to include the word observability in my talk i apologies uh we can talk about it more later but it's there um and so observability is uh is logging right so for folks who are in the windows world or the linux world you want to know what those pesky users are up to in your systems in the aws world you want to know what those pesky i am principles are up to and so cloudtrail is the logging system for what happens at the aws control plane level it is a bunch of json files that get stored in

s3 there are there's a free it is free to use cloudtrail but you are charged for the storage of the json objects in s3 so like i mentioned before clicks in aws have a lot of or can cost you money and i did say turn on cloudtrail turning on cloudtrail is great if you're in a lab environment and you're generating you know 100 api calls uh storage in s3 is going to be probably less than a dollar per month but it gives you the ability to know what happened in your aws account which if you ever find yourself in a compromised scenario where a developer put some credentials on github or you have an ec2 instance compromised

and someone's able to jump from the data plane into the control plane you're going to want to know what happened and cloudtrail is the way that you're going to know about it the thing about cloudtrail is that it is just a log it's a json file and just like any logs they're only as good as the things looking at them so they're json files in an s3 bucket you're guaranteed a lot of durability or guaranteed to be able to get them but what are you going to do with them is the question so some people will forward them into splunk um or any sort of other logging aggregator um depending on your environment is how

many cloudtrail logs you're going to have and if you're in charge of budgeting this is sort of where in the cloud world you have to become friends with your accountants because if you have a giant account hierarchy that's generating gigabytes and gigabytes of logs a day or a month and you're only you only have a gigabyte of transfer into splunk every month for your entire company you're going to have browned out and no one's going to be able to use splunk so there are free things like elk uh elasticsearch cabana and logstash that you can use there are a number of cloud service posture monitors cspms which will analyze your logs for you look for detections uh if you're using

you know the snowflake seam or any other sort of seam you can pull these logs in they are json files in an s3 bucket i am not an sre or a devops person but once you have json files in an s3 bucket you can go to all sorts of places but your logs are only as good as what you do with them i'm going to mention the first party guard duty service like i mentioned there are a number of options out there obviously guard duty is a first party aws service so it's going to be the most tightly integrated with amazon itself which is good and bad if you're only in an aws shop that's great

but if you're in a environment where you've got an e5 light a microsoft e5 license for your microsoft teams deployment you might randomly have a team running in azure somewhere and you might have acquired a company that runs in gcp and then you've got your production amazon stack in that case guard duty is only going to be looking at the amazon logs because it's an amazon first party product there is a small first there is a small monthly fee for using guard duty and you are charged for its access to your logs so within aws there's data transfer pricing and so the larger number of logs you have the larger your deployment the more expensive your guard duty bill is going

to be if you're purely an aws shop guard duty is a great way to get started on what the heck is happening with my account hierarchy and it also will send you some alerts so guard duty generates finding types and there are four here uh im identity access management s3 ec2 and they recently launched some kubernetes things which is more on the data plane side um because it's a first party product amazon is aware of the threats that are out there versus what actors are trying to do with aws accounts and i want to save a bunch of time for questions but we can talk about specific guard duty findings later they will alert you but again if you

haven't updated your contact information they're not going to find you and so if you do have a seam or if you have a shared mailbox that your security team monitors you can you can keep an eye on for alert from guard duty but you still need to do this roll some incident response once one shows up so i've been talking for 30 minutes and where has it gotten to us because the smart people in this audience are going to say we haven't actually done any work in aws yet we've just been doing a bunch of setup work uh and that's true we haven't actually done anything in aws and sometimes being a security engineer is building that foundation to enable

your developers and your internal customers to actually roll with things so working through this part of setting up an aws account for production we've talked about the control plan in the data plane we've pretty much exclusively talked about the control plane we have not talked about hardening instances as through bucket security we've just talked about the account itself so remember the shared responsibility model running in the cloud does not secure the stuff running in the cloud security in the cloud is your responsibility also don't forget the financial plane if you get a large if you're a student or just getting started with an aws and you have a large bill take a moment to breathe don't do

anything crazy listen to the podcast episode that i linked to at the beginning of this talk get in contact with amazon they should be able to help you out but don't forget these financial plane the financial plan i tried to mention it where services cost money uh throughout and uh keep that in mind um you've all kept your root username and password put away right thank you okay good we're not gonna use the root user if there's one thing you can take away from this talk if you are a security person in an organization and they use aws and you are not sure of the answer of is the mfa for a root user in a safe

that i know about don't go in tomorrow because it's a weekend and you'll miss the rest of the conference day but monday morning look at the im credential usage report see if anyone is using the root user and if they are declare a proactive incident you're going to be much happier doing that now than once it's out the door we've talked about account hierarchy again there's a lot of complexity there that you is not worth it in a lab environment but if you are in charge of a production setup it's going to be super helpful right you're going to be able instead of having to go through some complicated it procurement and make sure that the im rules aren't too broad

and adding a lot of friction you can just say here you go new software development team here's an aws account that you have full control over asterix it's got a bunch of security controls on it don't worry about those but it really unlocks your internal customers to use the flexibility of an aws account to get going we've talked about observability with cloudtrail new relic i did use word observability twice no let it be known for the record um cloudtrail is how you're gonna know what people are doing in your amazon account uh and if you ever have to roll incident response it's gonna be your social login we've talked a little bit about detection with guard duty um

if there aren't a ton of questions i'll go into some details on those um but i want to make sure that we have time for questions because this was sort of a quick higher level talk my contact information is on here i'll be around for the rest of the day uh z1g1 is me on twitter my sister's name is zoe glick and so we shared the z2g2 at aol.com account and she had friends to email and i would read her email so i was given my own account which is z1g1 which is where that name come from and your handle sticks with you from aol to the present day i also if you're here and you're not a member of the infosec

716 discord uh it's a great place it's where we do our monthly monthly sync ups so you don't get to hang out with us just once a year uh you can hang out once a month and sometimes we have tacos in the park uh even though i'll miss that one i'm sorry um there's also the western new york startup community slack if you're a student and thinking you know i don't want to be an employee i want to be my own boss god bless you but um there there are great resources in the western new york community uh 43 north is a great one there startup incubator is um giving away not giving away they are

investing a million dollars for a five percent equity stake in a bunch of companies starting up soon and there are a ton of people in this slack who are helping students and first-time entrepreneurs get started with founding a business and rolling with it so not just security in there but accounting lawyers finance vc all those sorts of things there's also the buffalo dev slack if you're more on the technology side and you just want to ask some python questions feel free to hit me up afterwards on these i can shoot you an invite there's not a great way to just put a join this slack link in some slides and the last thing i want to say is

i'm going to be around the rest of the day i got my start in the infosec industry a long time ago now because somebody replied to a reddit dm i was in the r net set quarterly hiring thread i was working i.t at a school district wanted to get into security didn't quite know how to do it and i sent a dm to somebody on reddit and that person was a manager for the sock at dell in rhode island and that got me my first job in the security industry and so i want to make sure that i'm passing that down to the next generation so if you've got questions about how do i break into the security

industry or how do i transfer or whatever please feel free to hit me up uh the mask is on but that doesn't mean don't come and say hi uh i'd be remiss to say new relic is hiring we've got a number of security rules i can talk about those as well and i want to open it up for questions and i'm totally going to remember to repeat the question over the microphone i'm going to remember i swear uh yes in the gray shirt duty did that actually also analyze um firewall

yeah so the question was can uh amazon guard duty look at web application firewalls uh logs uh and does it trigger on malicious ips uh it's a it's a it's a two-part answer so on the malicious ips part so there are some there are tens of finding types i pulled four three or four from each category so the i am finding types and the ec2 finding types will alert on uh malicious ips either connecting to a known commanding control channel in the case of ec2 or on the im side if it sees again because it's an amazon first party product their thread intel groups are looking for actors doing shenanigans in aws and they have their own list to say

hey this is going there from a web application firewall perspective not so much um it really is if it's interacting with it a log that is a cloud trail record it's probably a guard duty finding forward or a way to alert on it but if it's an application that you're running the the kubernetes new finding type sort of throws a little bit of a monkey wrench in that but guard duty is primarily for amazon logs uh and those types of alerts uh yes does it detect brute forcing attacks the question was does it detect brute forcing attempts so there are outbound brute forcing meaning your ec2 instance is doing something odd uh but there but because it's not

looking it doesn't have logs for each individual node um there's no like someone's trying to brute force ssh into this system i believe there's an im finding for uh in crete like a spike in i in api call usage and that could be an indicator of compromise right that someone has you know it but uh has gotten control of the account but it's probably there's no i don't believe there's a detection for like password stuffing of an aws account itself uh yes so what tends to be the most popular motivations for the bad actors so is it installing bitcoin miners is it to try to use that as a jump off to get access to on-prem resources or is it just extra

trade data for s3 yeah so the question was what's the most popular thing for for an attacker uh okay so i want to pull up this community resources slide um the motivation is as wide as attackers are numerous so you can if you put a set don't do this but if you put a set of aws credentials into a repo on github somebody's going to be trying to mine cryptocurrency within minutes uh mining cryptocurrency dot dot mining cryptocurrency and amazon is not profitable if you're paying for it if you're using someone else's computers it's possible to be profitable uh and so that's where some of that bill shock comes from right there are 20 plus aws

regions each one of those can run hundreds of gpu powered instances you can rack up a 60 000 bill in minutes and if you're not paying for those instances you can maybe mine some fake internet money and x fill it out if you do some google searching amazon actually has what they call the quarantine user policy which is if amazon detects your credentials on github they will actually apply an im policy to the credentials for quarantine user to prevent the launch of um to prevent the launch of crypto mining there are this is not an official award but there is the s3 bucket negligence award which the community uh grants to people that leave a bunch of data and s3 there are

industrial espionage uh you know data harvesting firms that love a good you know s3 bucket full of you know applications for credit cards um there are ways i mentioned it briefly that you can jump from the data plane and the control plane into on-prem resources so aws has a number of ways of extending your data center into aws and vice versa and so if you had a compromised set of aws credentials a hypothetical example you could take a snapshot of a database that contains usernames and passwords exfiltrate that snapshot to an account you control run offline cracking and then you come back into the account you've got common usernames and passwords in that environment so just

like a data center or you know they're ransomware operators there are industrial espionage people um whenever you're building a security you want to try to get rid of that you know the lowest hanging branch first that is the crypto people the i want to send spam email people um you know you can knock those out with some you know the stuff that's in the aws well architecture framework um if you find yourself uh the target of a nation state actor uh an intro talk out of b-sides is not gonna uh you probably need some specialized help but there are a lot of actors out there i pulled up this community so this is a community resource slide this is not a

limited this is not the limit of the community resources this is just what fit on a slide there are some incredible researchers out there wiz.io orca security the folks at rhino labs the talos group they're doing research about what threat actors are doing in the community talos did great work on team tnt which was a threat actor who was compromising ec2 instances to harvest aws credentials to mine bitcoins so if you want to read all about team tnt it's out there there's a great newsletter called last week in aws which covers both the business and security side of aws uh tldr security is a great newsletter they have a cloud section but it's not exclusively cloud

and seriously risky business is a newsletter that comes out once a week from the risky business podcast folks and they cover trends in the industry cloud is just another it's you know it's another computer in somebody else's data center and you're going to have attackers going after it any other questions uh we'll go there and then at the back uh in the black hat um

so the question was where do i recommend putting the credentials uh in a pam solution what's the password rotation policy um if it's a green field there will be no credentials um so an i am principle can be an imuser which is a long term like this is the zach user in aws which is a way a lot of people get started um if you if you have your preference you want to move towards federating into an im role so you can have a role of database administrators or a role of ec2 users and you can integrate that role with whether it's your office 365 directory octa your on-premises active directory however your users are already logging

in you can set up a single sign-on where they don't need a separate set of aws credentials if you do have to have credentials running around you can implement both a rotation requirement and a complexity requirement inside of amazon um i don't believe there's a way to check like the have i been pwn list for common or reused credentials um so as with all security things if you can avoid credentials at all if you can't password manager is a great way to do it um i could give given a whole another talk on getting your family on a password manager uh it's not the best one out there my family is on lastpass i i know that they got bought by log me

and then spun out and raised a bunch of vc money and i just closed my eyes because the family is using it we're not moving uh one follow-up and then we'll go to yeah i i love bit warden i'm not retraining everyone in my family i i i i admit that there's better technology out there but it is just once you get your your parents your sister the ability to share disney plus passwords is amazing with lastpass highly recommended uh for the white shirt in the back

uh so i think i heard the question of what about security hub yeah so security hub is an amazon product that will help you aggregate findings from a number of security places so if you do have other cloud service posture managers you want to pull them all together there are some recommended um similar to the well architecture framework you can pull in i haven't used security hub in production so i'm not sure of its particular quirks but it is a way to aggregate um aggregate a bunch of different alerting sources together and again if you're in that greenfield setup and you're native in aws it's probably a good way to go in but i haven't played with it personally myself

uh we got five minutes left so we'll do one or two more questions and then uh next speaker will come and set up uh yes in the back

so the question was have i found any anomalies of uh when using cloudtrail um yeah i mean your users are gonna use her um i mean for lack of a better term there are people doing things that you couldn't even imagine with computers and and that's the power of that organizational hierarchy is you give them full control over the member account but you can still say things like um you know you cannot have a public s3 bucket and you can apply that control to root hierarchy even if someone's going to try and do it because they think they're administrator in their account your controls are going to prevent them from doing it so it's probably not the most the greatest

term but in the industry you'll hear people say like there are a lot of foot guns in that product that's sort of short hands are saying there are a lot of ways to shoot yourself in the foot using it and an aws account organization hierarchy is a good way to to hide some of those foot guns from your users cool it was a pleasure hanging out with everyone today thank you for your time i'll be around the rest of today and have a great rest of the b-sides everyone

[Applause]