Rami McCarthy - AWS Security: Easy Wins and Enterprise Scale

awesome thank you for the introduction and thanks everyone for sticking around as well as the organizers and sponsors for bringing b-sides back to boston i know we've had a ton of great talks today uh so i appreciate everyone who's stuck around uh for the end of the conference this talk is aws security easy wins and enterprise scale and we'll get into what that means in just a second uh so first off this is me i'm a senior security consultant at ncc group i spend my time penetration testing everything from sas applications to financial mobile apps and most relevant to this talk cloud environments i'm aws certified in security and i have my ccsk from the cloud security alliance and i'm

the creator of saad cloud which is an open source tool that uses terraform to allow for configurable insecure aws infrastructure i'm also a contributor to scout suite which is ncc's open source multi-cloud auditing tool um so what am i get at by structuring this talk by uh you know easy wins and enterprise scale well whenever i cfp to a b-side i'm really aware that we can draw a mixed audience and i want to make sure i give a talk that's going to have value to every participant and to that end i'm going to start by working from first principles to quickly cover the key concepts you know backgrounding aws security and then i'll focus on easy wins which i

roughly consider as controls and practices that are broadly applicable i hope this is going to provide kind of a solid grounding in cloud security theory for those who might be newer to the space and give some answers to you know aws security practitioners who are administering smaller environments then i'm going to jump straight to enterprise scale which is discussing the patterns and problems i've seen after working with organizations of all sizes and degrees of cloud maturity for those with less experience i'm looking to give a high-level introduction to concerns that might be on your horizon through this so you know what can you expect as your cloud usage grows and for people who are more experienced

i'm going to be discussing best practices and trade-offs where i expect there will be at least kind of one new takeaway for everyone so before i go any further um i have to define the cloud i want to make sure we're offering off the same baseline so you know probably remedial but in essence the cloud is software and services that are running on the internet instead of locally on your computer that's it that's the whole difference um but this is important right because it really represents a paradigm shift in how we do computing uh organizations that have large and established on-premises computing estates are ever more rapidly adopting the cloud and newer organizations are going fully

cloud native you'll see a lot of startups that are you know fully invested in cloud computing so while a lot of traditional security theory is still applicable um this means there's you know a growing set of novel concerns and controls to be aware of here's some numbers to back me up on you know saying that this is a major change that's ongoing um as you can see a large majority of enterprises are adopting experimenting with or exploring cloud providers uh you know this graph is from the state of the cloud report and shows that over 90 of uh enterprise respondents are currently using experimenting with or plan to use aws um this also breaks down the major

players so as you can see aws azure google cloud and oracle as well as alibaba are really big in this space and having shown that there are all these providers a lot of them being used really broadly why is this talk specifically about aws and that's simply because it has the largest market share and is therefore currently the dominant provider however most problems are cloud agnostic even while some of the solutions may use aws specific services or terminology hopefully you can you know take this and extrapolate if you're a working ad organization that's using azure or gcp or oracle and frankly i work for clients and most of my clients are in aws so it's where i

have the most experience and you know feel the most comfortable talking about these big trends and best practices so this is the shared responsibility model um and every talk about aws security needs to start with a discussion of the shared responsibility model this it comes from aws and it breaks down in detail the differences in responsibility for securing the cloud so as you can see in the diagram aws is responsible for securing the underlying resources and services while customers need to own security for their workloads as well as configuration this means when you operate in aws you don't need to worry about securing data centers uh for services like s3 you don't have to worry about

security of the apis or even availability you know as long as you're operating within the slas on the other hand you're still responsible for authentication and authorization and encryption and this is where things can go really wrong and so that's where the focus of this talk is going to be before discussing specific security wins uh as promised i want to run through a pair of the key security concepts and these should be familiar if you're operating in cloud but there are nuances that become really impactful as we start talking about security wins and scale so the first key concept here is im identity and access management which functionally is aws's directory that controls access to

all of the resources and services via granular permissions and that works through three components so first off is principles principles are the identity to which access is granted um so a user is the canonical idea of a principle uh then there are groups and roles so users can be placed in groups which is a set of principles and then roles can be either assigned or assumed to other principles and we'll talk about what assuming roles means in just a sec so beyond principles we also have policies i am policies are the definitions for access right so they describe uh what access a principal has to a resource um so this might be you know what can a user do in s3 what can a

group do in ec2 and this is basically what they look like if you haven't seen one before just you have something in your brain when we're talking about this a policy as you can see will say something like allow ec2 any action uh against any ec2 instance and you would apply this to say a user which gives them broad access to ec2 and then there's credentials right so we have principles and they have to have some way to authenticate and that's via credentials which come in three forms um so first of all there's console access which is your standard username and password to a specific account that everyone's probably most familiar with there's also programmatic access which is via an

access key in secret and you use this with the api or cli or sdk please note don't share your access key in secret like i just did i promise i deleted this key don't go off trying to use it or if you do good luck finally there's assumable roles so like we said roles are principles and one way of managing access is to give a role permissions and then allow users to take on those permissions by assuming a role in this diagram is from aws which basically shows that you have alice who can assume a right role which gives her temporary credentials that you know for a time limited period give least access to um in this case you know access aws

uh specifically an s3 bucket and there are a lot of forms of policies and they re result in like a really complex matrix um that's evaluated for every request uh this is all you know like you can see from this diagram this is kind of the workflow for evaluating a request um it's deny by default uh an explicit deny always overrides an allow rule and that's about all we're gonna need to know for this presentation um if you're interested in learning more this talk from bridget johnson is is really excellent uh become an im policy master in 60 minutes or less we'll tell you everything you need to know far better than i could and

i am is really complex um and automation is key to reasoning at scale so if you actually do have an aws environment you're responsible for securing um i did put together a blog post uh self-promotional here that discusses all the tools you can use to really help analyze and secure your environment great so that's iam and the second uh you know baseline understanding here is of networking um networking functionally very similar to on-premises but the key concepts are um vpcs virtual private clouds are the uh you know the unit you're working against that are a logically isolated virtual network subnets are a range of ip addresses within the vpc similar to on-prem security groups are

one class of firewall rules that apply to individual instances while knuckles are firewall rules that apply to an entire subnet um so i break down the difference between security groups and knuckles very similar to iam not something you need to know all the details of but here's the baseline awesome um so that was a really quick run through key concepts uh hopefully it gives everyone what they need to you know further this discussion um but there's plenty of ways to learn more and i'll point you towards some resources if you want to go over the basics after this talk so how am i defining easywins right um so it's three criteria they need to be

logically straightforward it needs to be something that i can fairly easily describe define and tell you to apply they need to be applicable to all environments 99 of environments um whether you have one account or a hundred whether you have a massive budget or you're paying out of pocket these are things that every environment should be doing to guarantee security or to at least attempt to ensure security and finally they should have turnkey or repeatable implementation so i'm not going to suggest anything here that you have to go back and really architect in a complex manner of course there are caveats here um the first of which is nothing's easy at scale i completely understand yes if

you're managing a thousand environments some of these are not easy wins um and also all of these are easy within the bounds of the pareto principle um which is that eighty percent of the consequences come from twenty percent of the causes um this is like a philosophical principle uh but what i actually hear when you talk about this is that you can get 80 of the results with 20 of the work uh which is really important because as a security professional i'm fundamentally lazy i want to get the most security for the least effort because i have limited time and you should be too so here when we're talking about these easy wins i'm going to tell you what 20 of effort

should get you 80 of the results in aws security so the first easy win is to take full advantage of aws's built-in security services there are over a dozen kind of security services in aws they're 240 services total and we're not going to walk through all of them but we're going to talk about the key ones and then discuss which should almost always be enabled so this isn't the full list but these are the core security services in my opinion i'm going to run through what each of these services is and does because i think it's important to be aware of them even if you're not currently in a place to use them or if i'm not recommending

using them these are what you're going to hear discussed frequently and some of these that i'm not recommending may have additional cost or complexity that i want to avoid recommending blindly as well so first step is aws artifact which is an artifact of compliance reports and what this actually means is they've created a service where you can go and self-service get fed ramp or high trust or sock to or whatever report you need to enable your own compliance which becomes really important because at some point you're going to want to say to customers or to auditors you know we are secure because and this is where you can go to talk about the security on aws's side of the

shared responsibility model then there's aws inspector which is a vulnerability scanner much like uh non-aws services which works against your ec2 instances and it focuses on network reachability and you know patch management vulnerabilities um which can be really valuable obviously to cover and this is aws native then there's guard duty which is an ids for your aws account intrusion detection service basically guard duty does threat detection but more importantly it's backed by aws applying machine learning and using the entire corpus of data they have access to to generate these rules and detections which is something you probably don't have the time bandwidth or access to do unless you're a huge company and this is where you hear about for

example um you know evidence of a usage of tor on your network which could be a negative indicator or maybe cryptocurrency mining um so these tend to be um some of these tend to be pretty high fidelity uh because aws has been able to train them against a whole corpus of data and these are things that you probably want to hear about if you're running an environment in the cloud next up is aws security hub which is the single pane for all of your security alerts so all of the tools we're talking about can be fed back into security hub so you can uni use it as a aws native vulnerability management platform this is kind of what it looks like and

actually interesting to add is that a security hub comes with rule sets that you can run uh that will do things like this is the aws foundational security best practice and i limited just to you know the high most interesting vulnerabilities but you can also run um against things like the cis uh best practices awesome so next is aws config which is a configuration monitoring and governance tool that does historical monitoring so it will tell you at a given point in time how your aws environment was configured and you can also set rules that will trigger if something changes so for example you can say trigger this rule if an s3 bucket is ever made public

cloudwatch is for monitoring and observability we're not going to talk about it a lot because it requires a lot of customization but it's important to be aware that you know once you start looking in depth and monitoring observability you're probably talking about cloudwatch and then cloudtrail really important service for security logging monitoring and event history center so cloudtrail is where you'll go to see all of the actions that have been taken on the kind of api level of your aws account primarily and you can also set up other logging that isn't on by default for example s3 data plane actions i believe are configurable and that would be you know you can see exactly who's accessed what

in your s3 buckets um even public ones awesome and aws trusted advisor is an opinionated tool that aws released that gives guidance on their opinion of best practices so this will audit not just security but it'll also talk about for example cost optimization um and it's available for free it'll give you these security checks out of the box so it's an easy win to at least make sure it's on you're checking it and you're flagging alerts if one of these changes because these are all fairly significant risks to your organization and like i said not all of those services make sense for everyone i'd consider guard duty security hub cloudtrail and trusted advisor to be

universally applicable though um guard duty is probably the highest cost of these but you just get um you know such advantage from aws's training of that data set um you are covering your bases for detection for misconfiguration here you have basic logging in place you're getting basic anomaly detection and you have a single pane of glass through security hub although i'd add if you have a different vulnerability management tool if you have a different ids and you're in a hybrid environment uh you know maybe these are caveated but hopefully at that point you know enough about your environment to disagree with me strongly so those are the services you should use now i'm going to talk about

single account best practices and this should happen for every account if you have multiple but it's all limited within a single account and first step is configuration um so security configuration is hard and like i said you're not going to do perfectly as an easy win but what you can do is really easily audit your configuration using scout suite which i've linked which is ncc groups open source tool there are other tools like prowler or cloud mapper that do a really great job as well and just run one of these tools and check all the high risks and that will tell you things like you know are you following basics best practices around setting up mfa in iam or

using proper logging is encryption enabled which is important for compliance although i wouldn't consider it your first concern in the cloud and again this is self promotion i'm a contributor to scout suite but it really is a great open source tool and this is what scout speed looks like so to understand what i mean when i say easywinds you point this at your environment you run it and you get a whole bunch of information on misconfigurations um obviously this is run against a test environment that i want to make sure this lit up like a christmas tree um you know in ec2 this will tell you you have ports open you shouldn't you're failing encryption

maybe there are secrets in instance user data again fixing all of this might be hard but it's easy to know in a single account uh your general threat profile through this kind of auditing also so what else can we talk about when we talk about accounts in aws segmentation again perfect segmentation not an easy win but use an account as a segmentation barrier and you'll get really far for example we'll talk about this more enterprise scale but think about having separate accounts for production and development a dedicated security operations account you don't have to have a complex architecture to gain all the benefits here of account level segmentation just keep it in mind as you're developing and growing in aws

and you'll have a much easier job in the future where you won't hopefully have to re-architect your cloud estate least privilege again getting least privilege perfectly right is just an ongoing battle for anyone um working in security but the easy win is to institutionalize it from the get um a lot of companies and organizations i find when they transition to the cloud development and r d are the first parts of the organization to move to the cloud and how that the result that has is that they tend to have really high levels of access as they're setting it up and maybe that never gets corrected um so making sure you keep in mind from day one least privilege um make

sure to build up permissions not tear them down so don't say okay let's give everyone admin and then start denying certain actions just say what do you need to do your job and give only that and then finally external exposure at the account level getting a full asset inventory is hard but what you should do is be very considerate of your external threat surface there are a lot of attacks that focus on the perimeter in the cloud because without credentials obviously there are a number of things that are exposed by default and so you really need to care about whether you're making things publicly exposed and if so um what threats that can pose so again

just having this in your threat model will get you a lot in cloud security and in aws and then this is again a big bucket but watch out for common compromise footholds um these are some of the most common ways that i see accounts initially breached and if you're just aware of them you can go a really long way towards defending against them um so obviously just to read them off real quick credential exposure um that's where you know someone's leaking their access keys through github or a screenshot in a slideshow managed service exposure uh is s3 buckets and ebs snapshots and you know exposing databases the metadata service you'll heard a lot about that for example

capital one the hack there was an example the med data service uh lets ec2 instances and other things access credentials in aws and they've actually rolled out a new secure metadata service that you should make sure you're migrating to so that someone who gets a server-side request forgery vulnerability into your environment can't escalate and also workstation compromise so the cloud is not divorced from your average security practices and making sure that you're you know executing basic hygiene around employee workstations is really important so here's the quick summary right again easy wins maybe not so easy enable and configure provided security services take advantage of accounts as segmentation boundaries start to practice least privilege and get a handle on iem including with maybe

some of the tooling i've linked to minimize external exposure audit and secure configuration again run scout suite run prowler check the report and make sure there's nothing egregious and watch out for common compromise footholds and hopefully if you do these things it'll buy you like i said 80 of the security in your aws environment and most importantly you may not be at the point of defense in depth just from this but your perimeter should be well enough hardened um to hopefully buy you some time to mature your security practices awesome so this is my reminder to take a sip of water and a breath before we move into the next section um so enterprise scale

as you grow in your usage of aws you're going to find yourself with a lot of new problems um these could come because you're handling much more diverse workloads maybe you have a larger user base you're supporting multiple teams or even just the volume of usage right the difference between managing one account with 10 ec2 instances and 50 accounts using 80 different services can be significant and there's kind of two areas friction can come from once you hit that sort of scale and this can be true in smaller environments but it gets worse as your adoption grows and this is kind of along the two axes of technical and political and this talk is focused on the

technical um but i'm gonna digress for just a quick look at how you can pitch compliance for cloud security within your organization and how i've seen that work really well uh there are a lot of good talks about just the topic of um you know how to pitch cloud security so um this is just a high level preview um first off pave the road right uh if you make it easy for people to use the cloud securely they'll use it securely that's account initialization infrastructure as code creating supported patterns and even hand-holding teams in deployment so long as they follow security compliance billing is also a really strong lever cloud billing can get really complicated

um and if you pitch consolidated billing as a convenience so if you say we'll have the security team handle billing so long as we're able to be the ones to set up your account or so long as you follow our best practices that's great and then once you have consolidated billing you can start looking at reports and expenses to try and find shadow i.t um you know if you have someone paying 50 000 on a credit card for azure and you're an aws shop maybe you want to look into that and that's an example i've seen in real life um also you can remove responsibilities from this team uh so mozilla i linked to an example

from them um but they've set up a secure cloud trail system that all of their teams can use and this is much easier than the team that's implementing owning instant response and log detection and in fact one trick is to actually move the on-call away from the originating team or at least some of that responsibility as an incentive um so this was one of the motivators for talking about scale was actually this twitter thread that uh talks about internal tools every aws shop eventually builds and you can look at some of the answers but it is true that once you hit a certain scale there are some things that you you need to pick a solution for or

create your own and in a lot of instances these are things that are aws services or supported by aws and in others you might need to build your own or look for a vendor or an open source tool so we talked about single account let's talk about multi-account architecture how are you organizing all of your accounts once you have a lot of them this is going to be one of the most important decisions you'll make and it's going to define your constraints going forward so you know depending on your decision you're accepting a set of trade-offs that you're going to be pretty coupled into for the future unless you want to do a really big refactor

of your cloud infrastructure um if you're very lucky you're making this decision greenfield you have nothing in the cloud and you get to decide day one how to do it right more likely you're probably wrangling a bunch of disparate environments into a consistent format which is going to be much harder and there are a lot of considerations in multi-account architecture i'm not going to get into them all but you have to think about how you're going to handle billing conway's law states that organization systems will reflect the organizational structure and that often applies in the cloud so for example you'll see an account for each team and also as a security org one of the biggest

decisions you'll make is distributed versus centralized governance um which basically means do you embed security with every team or account uh or do you have it all filter up to security who then manage it centrally and can for example push down controls or policies so what's a multi-account architecture look like for those who haven't thought about this problem before this is kind of the most basic example i stole this graphic from a coinbase blog post i'll link to later um but basically in the simplest case you can have a bastion account that handles your iam and then you have separate accounts for dev and prod so users are always mediated through the bastion account um and before talking about more complex

and sorry for the slight issue with the slide there we need to talk about aws organizations so aws organizations are the prescribed mechanism for multi-account management in aws so this is actually the name of an aws service that is used to manage multiple aws accounts it lets you consolidate them so you can administer them as a single unit this lets you manage accounts centrally and set control centrally so you can set maximum im permissions through something called scps you can have all of cloudtrail log up and so that might look like this right this is aws's visualization of a basic organization as you can see they're grouping accounts into ous which stands for organizational units

and then they're applying policies only to those ou's so as an example you might have a test bed account where you have no sensitive data and you allow a really high level of access or you may have an organizational unit that's for finance that has to have really restrictive controls or you can break down an organizational unit that is compliant with a certain standard as examples and this is you know one example aws gives of what an organization might look like you can have a security and infrastructure inside um with their own organizational units and then individual ones is needed for things like you know special use cases or exceptions or deployments i can't recommend a single structure

here because it's going to depend on what you need to do but making sure you design this at scale is going to be a really big problem you face and something to start thinking about as you grow in your usage of aws and like i said organizations um help you centralize controls and here's a list of some of the services that actually work directly with organizations as of today you'll notice these are all things we've talked about but you can have security hub filter up from all of the member organizations into your parent account you can have guard duty filter all alerts into a security team in the organization these are just examples okay um visibility in security

again these are big problems we're talking about and they're problems that don't just exist in the cloud but there are some specific features of cloud visibility that you need to start thinking about and preparing for and make a decision on once you hit scale and when i'm talking about visibility i'm talking about kind of two layers there's account level inventory and then there's inventory of resources so account level inventory is the simple question of do you know every aws account you have who owns it and what it's for and that may seem like a simple question but anyone in the audience who's managed a large-scale clan environment knows that these will surprise you organizations that have grown naturally

you may have accounts that were set up by individual users that grew to be used much more than expected and aren't centrally managed i'm not saying that's a good pattern but it exists and you just need to be aware of it inventory of resources means being able to answer the question um what account is that ip address in or if you get a bug bounty report about um a web application that has a vulnerability uh what aws account is that application running in and i've worked with as i said a lot of organizations and they've all approached this problem slightly differently so i've abstracted out a few of the common patterns for managing visibility in aws

um and i'm not going to prescribe any of these but these are some of your options and you know maybe you'll recognize what your company or uh project uses one of these or maybe you'll recognize that um one of these seems appealing and use it down the line so first off is the vendor model the cspm cloud security posture management you can pay a company to give you a tool that will help you manage your cloud visibility i have no advice for you here i'm vendor agnostic talk to gartner for that and disclaimer i picked this example of some of the vendors in the space completely at random and i'm very sorry if your favorite

vendor isn't on here if your employer isn't on here if a sponsor isn't on here i'm not recommending any of these tools specifically but one model that companies will use is they'll start adopting the cloud and they'll buy into a vendor um and it's certainly an option there's also the homegrown model or the homegrown model where you can use open source tooling to build out a system for cloud visibility and as a case study chris farris over at warner media now at discovery has done this and blogged extensively about it and i recommend you go seek that out but he created this system called antiope that manages visibility across their hundreds and hundreds of accounts

um and he's been doing this for three or four years at this point and so this is an example of how complex that can get um but basically uh some of the most important things to see here that there's a security audit role in every account uh and that role is assumed to run a bunch of security scans and tools and then the data is brought back to a central location where they can audit it visualize it and for a while i think he was actually just um representing this via excel spreadsheets for executives um which again uh homegrown model for sure a lot of places are running their cloud visibility off excel spreadsheets and well it's not how i personally do it

if it's working for your organization go for it and then the third one is the service desk model um so this is an organization that has you know maybe open source tooling maybe vendor tooling maybe manual reporting all filtering up into salesforce or jira or another service desk tool and everything's managed through that lens you know i've worked with a lot of clients where all of their vulnerability management is done through jira so that's one other model that's a possibility so we've talked about visibility now we have to talk about governance if you know what accounts you have and what resources are running in them now do you know how they're configured how they're being used and

what can you do to govern that what can you do to ensure that even if someone has full access to an environment as an employee they can't accidentally make an s3 public bucket public and there are a lot of ways to handle governance there's aws config rules which we touched on briefly earlier there are third-party tools that will do this um you can use infrastructure as code you can only give access to your environment to uh your ci cd pipeline um and deploy that way you can you have a lot of options here but again at scale this becomes a big problem you need to think about what are you doing to ensure consistency and security throughout your

environment another big problem here that we actually talked about is an easy win but surprise also a problem of scale least privilege getting least privilege right at scale is a really hard problem that you're gonna have to or want to address you're gonna wanna automate as much as you can creation of least privileged policies analysis of existing policies users roles to make sure that they're minimal and correct and ideally you're going to automate remediation so that if you find an overprivileged user or role in your environment not only are you logging monitoring and alerting but you're actually remediating that without any need for security interaction and we're not going to cover what that whole pipeline would look like

because there's just not enough time but i'm going to talk through kind of some of the steps here so access advisor is a built-in aws tool that will analyze unused policies so you can actually go into your environment today look at access advisor and figure out what policies aren't being used and then remove them from users or roles there's also access analyzer which very confusing that there's advisor and analyzer to me personally but you can use access analyzer to check cross account access so this will show you what other accounts have access to resources in your environment which um you know there may be some that are valid there may be some that are invalid but

normally this is a pretty big concern and something you want keep a tight grip on in terms of open source tools and i apologize i'm not sure if gifs have been working this whole time hopefully this one is um policy sentry is a tool from salesforce uh canard mcquaid over there made it and this is a tool that automates making lease privileges policies because um you know if you're familiar you'd know or if maybe you saw being the talk i am is really complicated that's hard to do correctly and so this tool make sure you're only creating policies that grant access to specific resources in a minimal way so if you can evangelize this throughout your

organization and adopt it it means everything you're deploying in theory should be minimal and then final example of a tool repo kit from netflix is a really cool tool that'll actually minimize permissions automatically um this flow chart chart from them kind of shows the process but basically it will collect some data of usage in your environment and then automatically remove those permissions if they're not being used so once you have this set up it will actually start cleaning up your environment by default in theory and it does have fallbacks if it breaks anything if it notice permissions are denied once it removes them in a short period of time it will actually re-grant those permissions

as that's commonly a concern great one more problem here secrets management this is a problem for developers this is from on-prem and it's a problem in the cloud too um how do you manage secrets securely so that you're not leaving them in codes you're not leaving them in configuration and there are options here there are vendors like hashportvault and there's also aws secrets manager um you want to store secrets you want to set fine-grained access policies you want to access them just at runtime or maybe build time and you want to allow for really easy rotation and using secrets manager it looks like this right this is the goal to get to is that your code can call secrets manager to

temporarily return credentials and establish a connection and then those can be rotated on the back end really easily so that you can follow best practices around rotation one of the last few problems we're going to talk about here is getting full coverage on logging monitoring and alerting there are a lot of great talks about this so i'm just brushing the surface here of all the problems you'll see aggregation ingestion analysis and observability for things like serverless are all really hard problems they're only just finally being um addressed really comprehensively in the cloud in my opinion um i stole this slide from uh that london summit uh 2017 full credit um basically there are a lot of sources that you

should be feeding into cloud watch you need to have cloud trail going consider vpc flow logs um you should have resource-based logging so s3 cloudfront all have their own log sources you should be centralizing this whether in the cloud or if you have a sim you're already using um and then you should be notifying and alerting based on it and ideally you'll eventually automate this all and part of logging monitoring and alerting right why do we log monitor an alert well we're preparing for the worst we're preparing for instant response as security professionals and it's important to prepare because once an incident has happened unfortunately you don't have the ability to go back and retroactively implement some of this

logging monitoring and alerting and so you need to make sure to do it up front so that your bases are covered if the worst case scenario happens and this is a diagram a mind map for ir and aws that's been floating around twitter um that gives an idea of some of the things you'll want to look for and set detections for um you know as the topmost example there uh if someone's accessing credentials you want to make sure you have an alert for uh behavior there that could be concerning so again i'm not prescribing how to fix your logging monitoring alerting problem but what i am saying is that at scale this is going to be something you have

to solve for awesome and i think this is the last thing i'm going to talk about here um one of the big differences i've seen at enterprise scale that isn't happening in a lot of small organizations is resource tagging um so tagging right is uh you can associate tags with aws resources each one is user defined with a key and a value and tags can be used for managing organizing searching filtering resources right um their metadata uh so you can use tags for a lot of things um here's the example from the aws documentation of tag categories right um so looking just at security tags one really important thing is to have a good uh data classification framework

what is our most sensitive data and where does it live and one way to do that really comprehensively is to have a tagging policy um and have a confidentiality tag that for every resource describes what category of data is allowed and if you do this you can actually start to analyze where data is flowing from high security areas to low security areas same thing from this example compliance you can define which resources are currently or maybe need to be compliant with certain compliance schemes and what's important for tagging uh is consistency you need to have tags um with the consistent formats that are easily indexed and searched and they need to be applied across the board

and less can be more if you're um over tagging you're going to have the same issues as you would have with alert fatigue tag-based access control is really interesting right you could define a tag that specifies what team should have access and used attribute-based access control to facilitate that access it's not production ready i would say in aws but something to keep an eye on as attribute-based access control is definitely a really hot topic in cloud security also automation um so can you automate tagging and what can you automate based on tagging so this might be via terraform for example if you're using infrastructure as code if you're defining all of your infrastructure as terraform templates

it's also possible to then include automatically the tagging you need in those templates and have it be applied broadly you can also do this in ci cd so while you're building infrastructure um you can set tagging and tagging really important tool uh to pitch it right we talked about politics earlier cost exploration so if you tag based on ownership you know maybe your multi-account structure means that multiple billing areas are co-mingled in a single account you can use tags to explore kind of where charges should be placed inside your enterprise so enterprise scale right plan for the politics really hard problem to solve think about your multi-account architectures maybe using aws organizations think about which of those visibility patterns

you might currently fall into whether you've intentionally adopted one uh or maybe you know one's developed organically what governance you have in place for this is one thing i've frequently seen as organizations don't have governance it's all policy and procedure based but there's no enforcement on a technical level what are you doing to ensure least privilege is enforced everywhere and is established from the get logging monitoring and alerting what's your coverage look like where are there gaps where can you fill it out how are you prepared unfortunately for instant response because incidents happen and you can just be prepared for them as best you can and if you're not using tagging definitely signing to start

familiarizing yourself with if you're someone in a small environment tagging can still be really valuable but i think as you see enterprise scale environments you'll become more familiar and see it much more frequently and then i'm going to talk about right what are the resources you can use uh to learn more this talk was at a very high level i didn't go into the weeds on a lot of these things that top blog post i wrote it's a security ramp-up guide that links to some of my favorite resources so that i use as a compiled example to throw people towards if they have questions about how do i learn aws security these other three links are some of the

best cloud security resources i've seen the top one so you inherited an aws account really talks you through how to get your account under control which if you're taking over a new account is really important the security maturity roadmap is from scott piper of summit route he's a consultant the maturity roadmap is excellent check it out and finally disrupt ops has kind of an example of the top 10 kill chains um which ties into my earlier example the most common ways your account gets compromised and then of course um these are the references for my talk uh please check out the original sources on all of these things there's a lot of really cool research and speaking being

done um and you know thank you all for listening if there are questions i think i'm running up against time so i'm happy to discuss them in discord or come harass me over on twitter or linkedin or something um but otherwise thanks thanks for uh for a great talk ronnie that was really good awesome yeah well thanks to everyone um i think am i okay to get kicked out of here now or is there anything else we should touch on nope i think you are good i didn't even see any questions come in through the track too so so maybe there will be something that comes in um sometimes they trickle in at the end

of the talk but yeah i'll go ahead and i'll go ahead and give you a soft boot out and then again thank you very much for your time and it was great to have you of course thank you have a good one