Guardrails in the Cloud

security architect and enthusiast with a strong background and skills in multiple areas of security including application security cloud security and telecom security rohini is an experienced ethical hacker and has conducted secure development training classes for clients worldwide rohini is the current chair co-chair of the south florida owasp chapter and she is also an aws certified solutions architect associate so without further ado i'm going to hand it over to you rory thank you thank you very much let me share my s presentation can everyone see my presentation okay excellent thank you very much all right welcome everybody and uh thank you for being here on a saturday uh we really appreciate you taking the time uh to attend all these talks

and hopefully you'll get something out of them talking about guardrails in the cloud um and uh going over the tables of content um i'll be starting off with the current landscape and the and the disruption that's happening right now i'll cover the first guardrail with organizations and scps the second guard rail to reduce blast radius the third guardrail how to implement least privilege the fourth card rail which is automation and then the fifth card rail which is thread detection and then i'll basically go over everything and then we'll put it all together so without any further ado let's talk about the current landscape as it exists right now so 2020 was a really interesting year and

uh twilio and and as as mentioned i'm a member of the security architecture team at twilio twig i did a survey last year and what we found out was that companies had pulled in their digital strategy by six years which is pretty phenomenal so and we saw that last year where you know you had brick and mortar shops that had to go online your customer contact centers had to go online uh we had e-education virtual virtual education we were seeing our doctors online so there's a lot of disruption happening right now and and you know what does that mean for sort of our overwhelmed security teams our security teams were already you know were sort of kind of underwater

and now it's it's even more so so if you had if if you really did not have a cloud presence and suddenly say you're going to go on to like the aws cloud or or azure or the google cloud we have a whole new landscape to uh to protect and secure there's compliance requirements you know especially with sort of your uh your e-doctor you know your online doctor there's hipaa requirements um and and you know there was a lot of like i mentioned there was a lot of innovation last year and and uh and and and disruption that's happened so so so there's you know so so there's a lot of a lot of things going on and really

what's happening is if you do not have guardrails if you don't have a cloud strategy a security strategy you're gonna be overwhelmed and and if if you we're already overwhelmed we're even more so right now so let me i'm basically going to talk about the aws um you know the amazon cloud uh and but but really all these principles apply to any cloud if you're really any cloud that you go to the the same guardrails would apply so in amazon when you get an account the first thing what you do is on aws you can you start up an account you log in hopefully you set up a multi-factor authentication um maybe you spin up an instance or two

you know you open a bucket uh and then you do various services you could set up subnets you know you have a virtual private cloud your vpc which is your isolated uh section of the cloud uh you could create like a public private segment you start to set up route tables um you know you have things like security groups um you may set up like an rds a relational data store or like a nosql database such as dynamodb and so on so you know there's like aws is a complicated um you know environment so it's it's kind of useful to have an analogy so the way there's no really great analogies uh unfortunately with uh with with the cloud environment the

best one that i've i've seen is basically a real estate like say your developer say if you're a developer and you have real estate a real estate developer and say you're developing like a residential area you're setting up a commercial like a strip mall of some sort so the way to think about is is your accounts are like your parcel of land so you bought up different parcels of land and you're going to do construction on them so you you know you can you can set up like say like a uh and a city you have postal codes which are your subnets uh you have route table which are your roads um buildings which could be say you know

you when you spin up machines those are your instances uh you have security groups which could be uh say security guards outside the buildings that may or may not allow you know people to go into buildings and then you have policies things like you know what what can be done so if you don't have guardrails if you don't have a clear strategy on how we're going to secure this complex environment chances are it's not going to end well for us uh you know there's going to be there's been a lot of breaches in the cloud i mean you know we see you know in security we live in a very interesting environment there's zero days

uh dropping all the time you know there's calm breaches happening um you know we face anything from say very you know script kitties to like nation state attackers um so you know we live in a very uh in a constantly evolving environment so we have to have a plan on how we're going to deal with this so what are guardrails so guardrails are a way to set security boundaries right so so basically you're like yeah this is you know this is what you can and cannot do these are the your bro these are not sort of granular very fine grain boundaries these are broad brown boundaries this is and this is a way for securities the

cloud security team so let the engineering teams know that this is what you can and cannot do you know as a as a secure as a member of the security architecture team or just you know of the security team our job is to set these guard rails and give our engineering teams a runway so they can run fast so they can innovate we just want to make sure that they innovate securely you know we want to give them a very broad runway but we want it to be secure so guard rails are a really good way to do that to set these boundaries they're also a way to alert teams about security mistakes and you can do that a

lot with automation it's also a way to train teams about cloud security what's a good you know what what are the uh mistakes that can be made and what are the consequences and it's also away from being a blocker to enabler if you have going back to my real estate development analogy if you have a building how you know you've got construction happening people are putting up buildings and if they have to come to you forever hey can do you know can we set up this building can we connect this building to this other building do i need a security guard here how long do i do is it just a night guard is that it

like you know you're always you're you're a blocker yeah and and and there's no way we're going to scale that that big so we have to go from being a blocker to an enabler and and the way to do it is with setting these security boundaries so some high level things about architecting guardrails your godress should generally cover common use cases um you know so what whatever your use cases are and there are some that apply to everyone which i'll cover so make sure that these guardrails cover common use cases so you know you've taken care of say most of your most of the questions that come up regarding security in the cloud make sure you give

flexibility and optionality you know we've always heard that security says no so you know we're gonna either try and go around them or we're gonna go to them in the end or you know things like that so you want to be flexible and up and give options just just you know if something can't be done my advice is you know give give another option that that could work for the teams guardrails really won't be you know if if your guard rails are not well understood then you know then basically they're not going to be very uh effective so you make sure your guardrails are well understood and and uh teams understand them and then the final thing is they have to

be enforceable if you have uh if you have guardrails that you know and your car is going over like the side of a cliff and the guardrail really doesn't protect you then you know what would use were the god well so make sure they're enforceable so those are sort of the best sort of best practices um sort of things to think about uh when you are building guardrails okay so let's walk let's talk about the first guardrail so the first guardrail is uh is is specific to aws which is setting up organizations and scps basically centralized control if you don't have centralized control if you don't know all your accounts if you don't know all your resources you can't

protect you cannot protect what you don't know so you have you have to have a way to centralize this control and the way to do it in aws is through organizations and the use of service control policies which i'll talk a little bit more about in a few slides here so organizations give us a way of managing multiple accounts from a central account using a hierarchical structure and and this is kind of what it looks like you've got a root management account uh which and and it it sends invitations to all member accounts also basically what you would you should what the first card rail is find all your accounts and get them and and uh

and and have every account be a part of this or set up an organization set up a management account which is separate um and then set up a a decent hierarchical structure composed of organizational units and member accounts so for example a very simple organizational unit that you can do is um you know you can have a dev stage and a production and organizational unit because chances are you're going to have different policies that apply to different ous in a development environment for example teams are going to be engineering teams are going to be experimenting say they're going to be you know trying out new services uh and and playing around with so you may want to give a little bit more

control there you know so you you want them more flexibility there now your production account say you have a production or you you that's has to be locked down right because any any any breach there any any uh lack of uh you know any lack of security controls there it could be catastrophic for uh for your organization so the first thing to do is set up an organization have a management account and set up a good and find all your accounts and set up a a good hierarchical structure that's your first step is specific to aws organizations give you a number of other benefits they do things like centralized billing allow you to as i've been talking about centrally

manage all your accounts you can also push service control policies which is very powerful and i'll be talking about it in the next slide you can configure services centrally such as audit logging with cloudtrail and then you can also show that ensure that all accounts have audit logging enabled and they cannot be modified and then you can share things like root table route 53 rules across all accounts so they give you a lot of sort of benefits and and i hope you can see how how powerful this is uh before i go into service control policies one of the big things that you need to do with manage with that management account that's a very powerful account

right like that's that's a super account um you want to lock it down um and because it can it has special privileges you can create accounts you can invite accounts um if an if a attacker gets access to that account well you know they can account you know they can they they can get elevated privileges and things like that so you really don't want that to happen also the principle of least privilege and and separation of concerns which are you know general sort of security best practices only use it for in administration don't run anything else in it like at the ec2 instance or or anything else in this account so you know so so that as a

and only limit access this should only be given to the minimum number of user access to the minimum number of users possible so that's a management account uh best practice now let's talk about service control policies these are very powerful and it always surprises me when when you know organizations are not using these just because you know because of how powerful they are so what are service control policies so saps or service control policies set the maximum level of set of permissions that are allowed for all accounts in an organization this is your your your guard rail number one right like it's basically anything that uh if that's not in an scp cannot will not happen in your

organization say you've said it so for example um you don't want to run um say fargate or or you know some there are some services you don't want to run uh machine learning uh you know something else um you can use scps to set this maximum set of permissions um so there are some useful policies that i would recommend things like you know you deny root user they don't allow any of your instances to have root users because as mentioned a lot of bad things happen that so that that that root user has uh elevated privileges uh you don't want to have local users on instances that run production workloads right you want to use things like

federated authentication and i'll i'll touch on that a little bit uh down the road you also want to only allow specific services you don't uh for example and the reason for that may be uh that your team that the cloud security team is not familiar has not like looked at that service doesn't really know this the best practice you know best practices around that service so you you want to only allow specific services and the way to do this is you can actually go and use organizations to see that what is what are the teams using right now so you can actually use do that or you can talk to teams and so on and and get the

list of specific services now if uh teams want to use a service that's not allowed they can they can contact uh the cloud security team or the security team whoever's running are responsible for the security of the cloud you know of services running in the cloud um and they can actually have a dialogue and their team might do a poc and and you know and and and come up with some guidance around how to secure that new service and add that to the scp you also want to deny me you might want to uh deny ability to create access keys i think in the keynote uh you know speech that was just given that's a real issue right like

we've seen a lot of breaches happen because people have checked uh access keys into uh into code repositories and uh mostly by mistake we also you know there's a very famous case of where a company got wiped out basically they had to shut down because somebody got access to their uh to their keys and act just started deleting stuff and then basically had and and that company went out of business so there's been some extreme cases of of of really bad things happening when people lose access keys you may all you also might also since organization is is uh setting up organizations and scps is a foundational uh guardrail you want to deny uh accounts

ability to leave an org there's no reason that any uh account that's owned by your organization should be should not be part of that or right so you you can set the you can deny the ability to leave in order you might also do specific things like um deniability say you have a backup or you say you've set up a backup or you are you you have a backup account where all your where you do all your uh backups and so on you want the ability to delete to uh deny the ability to delete s3 buckets you do not want your s3 buckets deleted so uh you know because that those are your backups so just uh this example i just

gave up this company that that lost that um managed to lose their access keys and went out of business uh was you know that that prevents that scenario at least with backups and then you may also do things like use approve regions and you may need to do that for compliance uh reasons that only specific regions uh that people that your team members or engineering teams cannot spin up accounts and services in um you know in in an unapproved region so so service control policies are very powerful and and should absolutely be used as guardrail number one um some some issues that i should mention about scps it's it the currently there is no good way to

audit an scp so you know you can you for example you you can uh set up an scp or service control policy but you may not you don't really know it could actually break something so one of the best uh practices is to set up like i said set up that hierarchical structure in a coherent fashion and you want to set the sap at the lowest or you and then test it make sure it doesn't break anything and then you can move it up um i also talked about finding unused services and organizations can be used to do that and then you also want to make sure you understand what scps are saps don't give you permissions

right like so you so it's uh they only set the maximum boundary for permissions you still have to get permissions they just set up the guardrail the maximum boundary uh and they only apply to accounts within an organization so like i mentioned all accounts should be within a in in your organization's uh structure they will not because saps don't apply to any accounts outside your organization so for example if you have a trust relationship with an account outside this organization it's not going to apply there all right so we've done guardrail number one and uh you know if so you've set like this guardrail you've set the maxim you've created a hierarchy you found all your accounts um and

you've set up this this uh coherent hierarchical structure and you've said scps you've set the maximum permissions for all accounts in your organization the second guardrail is to go multi-account you don't want to put all your eggs in a basket right for example going back to my um to my analogy of like if you're if we're developing real estate if we only have a parcel of land say in tampa or uh where i'm at i'm in south florida uh you know and a hurricane hits us we're out of business so you kind of want to you know you you may want a parcel of land somewhere else um you know and or we get uh breached we

get attacked and reached because we haven't said guardrails well the blast radius is limited only to that account so you so as a best practice you want to be multi-account um also it makes total and there another reason is it ties in with the first card drill the guard first card rail doesn't work if you only have one one account so you you want to have multiple accounts it's a great way of organization uh organizing your related workloads and policies uh for exa you know like i mentioned if you have a compliance uh account uh you can you can actually make sure and you can enforce uh you know those policies uh using scps a backup account for example that i

talked that i touched upon that you can't delete any uh any objects in any s3 buckets your keys you want you know enhance alerting their production also you want enhanced alerting and in your development you may want to give them the ability to create new services because teams maybe for example uh you know maybe experimenting with new services seeing if they work the other reason to go multi-count is it's easier tracking and alarming uh i've already touched upon the fact that you minimize your blast radius because you've set up you know relevant security boundaries and say you get breached um you can destroy that account start over and the other thing that that you know

that you may come up again if you really start using uh aws in a big way is that aw has some hard limits on primitives like s3 buckets vpcs the number of vpc parent connections you can set and security groups and so on and this is something that you know when you're starting out is not a big deal when you start using aws in a big you know in a big way this you could you will certainly come up against that so when you have multiple accounts um you know you don't have these limits because you've got other accounts uh you know you've distributed sort of these quotas on across multiple accounts um you can look up the aws documentation on

quotas and and you'll get all that information there okay so now we've set up a guardrail number one and two we've set up organizations we've gone multi-account we've uh distributed our risk we've minimized blast radius and we've set up a read with some really great god uh guardrails with uh uh surv with scp service control policies so we're already in much better shape than we were before so i am at least privileged and this is an area where a lot of uh security issues occur you know i so identity and access management right like uh who you are and what you know and what what you're entitled to do is a global service um you know you have

things like users groups and roles users and roles are identities groups contain multiple users you you can authenticate as a group but you can attach policies to them and roles are sort of uh can be adopted assume you can do an assumed role to assume permissions you get a temporary set of permissions to access various resources if you've got the right policies so i'll talk a little bit about a policy this was a sort of a sample policy that's created that basically puts gives an access to all speakers uh the ability to put their presentation in a b-sides bucket right like you we've got like our so policies are a json representation of who can do

what to which resource so the who is the principal in this case it's anybody with a speaker role so for example i would be able to put this presentation in in a b sides bucket um what they can do would be the action which is i can do a put object and which resource is the resource which is the which is the b-sides bucket so these are our json policies they're very powerful but they're also of a source of privilege escalation attacks and and so one of the third guard trail is to implement least privilege so a lot of issues can happen when you do things like you uh you know especially with the wild

card with the uh if you have a wild card so if anybody so if instead of in the principle instead of uh having just the speaker anybody with a speaker or if i just had a star that means anybody can put anything in a bucket in this bucket well there's been cases of that being attacked so for example i could distribute malware i could i'll i find this policy and upload malware and i could say say hey you know send a survey to like say all the b-sides uh you know to people i know uh attended this uh talk or this uh this conference and say hey uh please go and download uh this uh from

the here's the talk uh please download this and they could actually effectively be downloading malware because i because i have this problem because i put a wildcard uh as a re as uh as a principal so there's many things there's a number of things to be worried about when you have teams creating uh uh you know implementing policies you want to look for things like wild card any action against any resource allow for any principles things like destructive delete object you know things like destructive privileges and then things that attach role policy to a user group a role and so because what that means is if i have if that's in my policy then i

can give myself that an administrator role and and basically do privilege escalation so policies are very i hope you can see how hard it is to audit these you know these are not easy to audit and they've they've been um they've been a source of of a number of issues and breaches um uh within the cloud environment it's uh and so the word research uh so the suggestion is that if you're going use a tool like uh there's a couple of open source tools out there the one and first one is by salesforce called policy sentry what it does is it creates new policies with least privilege uh it leverages aws documentation on actions resources and

conditions and you can set up automation so when uh when your teams are creating policies that they use this tool so you're automatically creating uh new policies with least prefetch which is a good thing to do now say you have a lot of policies already out there you know you're uh you want to scan for privilege flaws and the one one of the tools is by rhino security labs called aws escalade that'll look for things like um attaching policies uh like attached role policies and and flag those so that's our second guard role that uh guardrail is basically make sure you're implementing least privilege you've actually checked your other policies and make sure that there is no privilege

escalation vulnerabilities in any of these policies and new policies are being created with these privilege um this like i said this is a very important one this is also a source of lot of friction with the with cloud security teams um you know when uh when when engineering teams are setting up new workloads in in aws um you know typically what has sometimes are actually sometimes what happens is just to get things working they give they give very broad privileges you know they're not really looking at security they're just trying to get the functionality working so you really want to set this guardrail in place that everything happens with least privilege and you don't and and these are very

difficult to audit manually so you really don't want to do that so so that's your third guardrail least privilege with with i am now let's talk about the fourth guardrail um you know asset management's hard anywhere you go and i've yet to see any anybody do it well you know that that because that's hard to do um and the way to do it in ws is through tagging so we're tagging in aws is uh that you have the ability to assign metadata to a lot of your resources not all but but most of you like things like ec2 and they're basically a key value pair and you can use tagging for a number of things it's not just for security you

can use it for governance so for example you've got uh an account that's uh that's you know uh that's handling say credit card numbers right like soca might fall and scope for pci you can actually put that tag and say yeah this is a compliance and a and the compliance that if this uh this uh instance falls under scope is pci you can do finance uh you know that's a big one and uh you know a lot of you know you you can do deny you know you've got denial of uh denial of service but you've also got denial of wallet attacks in aws because you get built for absolutely everything you run there so you have to make sure

that you know you're watching your your cost there as well um another big advantage of tagging is that it enables automation um and it actually can be used in i am policy conditions which is which is very very powerful um some useful tags with the uh with tagging is you know obviously want the owner you know who owns this uh this account who owns this resource who owns this ec2 instance who's the owner of this bucket uh you know things like that so you want the uh so so that's a really good tag to have the cost centers is is a is a pretty ubiquitous tag that's something again for financial reasons you might want in

there the risk classification is is something i mentioned but uh you know uh but say like an instance is actually processing credit card numbers you'd want to put so you might want to put the pci tag on it a description of what that you know what that uh resource is doing the date created that's a good one because you may wanna uh you know to bring down your cost you may want to let instances say in a development environment only run for a certain amount of time so that that's a that's a very good tag to have an environment tags a good one that says yep uh you know this is running in a development

environment this is running in a production environment and then department and so on so there's a you know this you can do a number of tags um these are this is a good sort of uh place to start with tags uh in your environment and then you can always add more tags that are relevant uh to your organization so tags are a great way to do apac which is a attribute based access control so you can use tags and policies to grant access only when say for example when a certain tag has a matching uh value you know in this case that the uh that i can only start and stop instances if if i'm on that project

and i'm in that department you know nobody else can do that so this can all be done automatically uh using conditions and policies uh so that's so so tags are a very powerful way to do a back and then what should be automated so any place where you do not have uh service control policies or other policies enforcing your security uh guardrails you can use automation so i mentioned uh you know if you have tested uh if you have instances and test accounts or resources and test accounts running for say whatever number of days hours or days you can delete those right like they will they can only run for those you can use uh automation to detect and

remediate open security group for example if you have a security group that really shouldn't be open but it's got zero zero zero zero slash zero or it's open it's open uh open up to insecure protocols like ftp or so on um you can use tagging or you can use automation to detect and remediate those um you can find things like unused rules and services again you know good thing reduction of attack surface right like always a good thing for us to do uh also bringing down your bill and which which in aws or in other clouds is is a is a big issue you can also use automation to update your asset management say you have an

asset management system you can use automation to update that um your cmdb with let's say your cloud asset so really you know the sky's the limit uh you know if you have a plan and you have a yeah you have specific uh security controls you want to enforce that that you can use to you can use automation for that so so that's really great uh you know there's a couple of things you can use uh uh this uh this blog that aws publish and parliament which uh which is an open source tool that's that's basically scraping a lot of aws documentation and and giving you information so you don't have to go read that documentation

so useful when you're setting up automation so guardrail number five so so the the fifth thing that i recommend doing is setting up guard duty and threat detection so god duty is aws's uh regional threat detection service uh so essentially you know like you know the problem in aws is you're going to have a lot of noise so you've turned on logging you've turned on cloudtrail you've turned off cloud watch um there's a lot of noise and and there's there's a there's a there's so much noise that it's all that's all it's almost impossible to figure out the signals and guard duty really gives you a good way to to detect signal from noise it's integrated

with organizations which is great because so it's it's basically uh if you've set up organizations you can designate one of the accounts as your uh as your main account for regard duty and and so and invite all other accounts uh uh to be managed by that main account what the way guard ud works is it monitors data from different logs such as vpc flow logs your dns logs and cloudtrail which as i mentioned has a lot of noise uh it has a lot of great information but a ton of noise um and it uses machine learning so what they're doing is they're do you they're using machine learning to figure out what your baseline is

what is good traffic normal behavior from attack behavior or anomaly right like we've never seen you do this and and and they also get uh data from a lot of feeds things like malicious ips that are running command and controls uh you know centers and things like that or they're they're known to attack um uh you know instances so they're so they're basically marrying uh machine learning and feeds into in guard duty so it's a very very powerful tool and uh something that if you're if you haven't turned on you probably should if you have your own thread detection service that's great i think you know actually you can absolutely use that uh and uh or you can if it doesn't do

everything that you want to do you can use a combination of both so that that really is the the fifth card rail so other best practices you logging and monitoring you you if you don't know what's happening you're absolutely blind and uh you know as a security team if you're doing cloud security you have to know what's happening in your cloud environment are you getting attacked who's attacking you what's going on what did you know did something violate one of our guard rails um you know how do i i need to remediate that so you have to set up logging and alerting um my suggestion is you can you can use you can basically bring in you know uh

all your uh audit logs you know your security logs and things like that into your company's uh seam whatever you're using and set up sort of alerts and things like that there because say most security teams are already used to using the system so you might as well just use it for for your cloud for your cloud logging and alerting as well another best practice is use a separate aws account and region to back up your data you know again separation of concerns these privilege things like that you know that that's that's a good practice i mentioned things like don't have root users don't have you know access keys things like that you use federated access single sign on

for all access don't have local users on production account there shouldn't be any need to have local users you can do things like block you know s3 buckets are a source of of breaches for a lot of corporations it's you know it's almost constant we've even had countries get breached by s3 open s3 buckets um so one of the things you can set up in an sap is block public access so you can actually give access to say you do have buckets uh you know that do need access let them and then block public access for all future buckets you could also consider using a web application fireball for like layer 7 attacks um you know aws

has one but there's a lot of at this point really good wraps out there so you can you should you could consider using that uh to look for uh layer seven attacks uh you know os top ten type attacks and other attacks um and and they're also pretty useful for doing things like rate limiting um and then you have things like aws shield for denial of service attack uh or a shield advanced uh in in in aws the other recommendation is to use infrastructure as code uh you don't want to hand roll all of this out and you don't want to be clicking you know buttons on um on on an aws console to set up services uh you

absolutely want to do like think something like terraform and use infrastructures code that's something that's code that can be audited you can do security reviews on that you can do automation on that um so you you so that's absolutely a fundamental thing you know have infrastructure as code and then you know they've uh ew has rolled out their metadata service version two um you know as you know there was an ssrf attack uh uh in in aws that was pretty uh pretty egregious so um you know so the recommendation is to use metadata service too so that's that's the sec that's some other best practices that you can do and you know there may be

other practices that may apply there may be other things that are relevant to your corporation to your organization um that um you know that may become a guardrail which is which is which is a perfectly fine thing to do so let's recap what happened because you know i know went through a lot so going back to our analogy of parcels of land and construction going on in parcels of land and no guard rails where you're being asked can we do this can we do that can i set up this building can i just sit at this building here can i open up a road here and there when you've done guardrail number one if you're that that was setting up

organizations and scps you've set up a hierarchical structure you know where all your say all your parcels of lands are you know so you end and uh going back to guardrail number two as well you've set up multi accounts you've got separate parcels of land and they're all in this organization and you've set up relevant scp so that's a very powerful uh things two steps that you've done already to to limit your blast radius to set up guardrails to set up maximum permissions that cannot be violated in any way guardrail three was you've implemented least privilege uh so all the people who are like you who occupy your your parcels of lands or who live in

these cities you've already implemented least privilege for them you know so you you've you've set up a set of tools in place that you limit uh to implement least privilege card rule number four was you know all your resources because you've implemented tagging and you've set up automation to manage scale because very quickly uh you have going to have so many resources and services and workloads running there's just no way to like audit this so automation is a great way to go to manage scale and then we've set up thread detection right we've got sort of a command center where we're looking at all the threats uh we're getting all these feeds from guard duty from uh

you know where we're like oh yeah that that instance is being attacked it's it's communicating with the known malicious ip uh or there's data exploration going on or that bucket you know has a policy that was never there so you've set up threat detections so you're already in a really good place with these guardrails and and that's it for today so uh you can reach me on linkedin um you know and i guess i am now open for any questions that any anyone may have

i think just as a reminder we can use the q a panel uh if you haven't just as a reminder if you look at the chat um area there's a question and answers area where you can put in your questions for today's discussion a couple questions in reference to the recording of this session that is something that um i will talk to lori and brent um derek about and see about availability i know last year we did um share the presentations as part of b-sides um so that's something we will have to follow up back back up on that's the only question i see in the chat so far okay wonderful please feel to contact me

if you have any questions if you think of anything after afterwards uh you know i can be contacted on linkedin or any anywhere else and uh happy to answer anything that comes up even after the conference well thank you so much for um presenting at the cloud track this is only our second year actually um offering the cloud track it's um supported by our csa tampa bay chapter so thank you very much for um participating and um it was a very good um presentation and i know i learned a lot from it so thank you so much