Breaking The Cloud: A Tale Of 3 Breaches

[Applause] no pressure on me now I guess thank you um first of all thank you for coming in I was kind of hoping there'll be one or two people as I embarrassed myself on the stage but seems like a full full room so I would appreciate uh the the the sancity of not making a fool of myself I guess for people who don't know who I am uh I've been in the cber security space for a little over I'll say 13 years primarily that was in Australia I moved over to the UK 7 months ago um and for the last seven years I've been working Cloud security last role was of the ciso before I left

that to become a full-time podcaster YouTuber now so I I run something called Cloud Skitty podcast uh about a few familiar faces so they know what we talk about basically as the name suggests primarily talking about Cloud security so the conversation that we having today is uh part of so we done Cloud security training and as part of that uh let's just say how do I describe this without embarrassing my team or myself so we were running a cloudcade training and as part of that one of the trainers left the GitHub access key well I wouldn't say it was fully just left in in GitHub it was kind of just left there someone who was a researcher uh in the class

decided to just give us a video of what that would look like if they could have just gone full um full explored mode on that they did not so this is kind of a talk about what it is even if you feel you're doing everything from a cloud security perspective how there are always these little holes that left behind as well so hopefully this is valuable for everyone who's coming in and for me to get a sense of the crowd is anyone AWS person Azure person AWS sweet uh Azure cool so okay for for gcp is anyone using any other cloud or no the cloud I was hoping there be one hand Oracle Cloud somewhere but

thankfully there wasn't um so outside of this uh as you can imag imag I enjoy men's fashion and coffee so that's kind of my thing um sweet so the story I I've got a the person was quite kind enough to give me a video now I did try recreating this on the actual AWS console but for people in the Amazon space it was reinvent and then once the Amazon Q the console looks very different so I'm going to show you the video instead of taking to the console so please bear with me as I just give you the video Itself by the way we made the video online on YouTube as well so if you want to go there oh

uh can you guys hear I don't want to there go perfect so essentially uh this is the file which is a terraform is that going to be visible it won't be visible I'm going to try and maximize so hopefully people can see it but is that still visible for people in the end perfect Has anyone used terraform before anyone perfect this is this is going to hit home for you guys so uh this is a Chapo State file for people who have not used Chapo state file or terraform in general is an infrastructure code language free open source Hashi cor doing awesome job with it I'm not going into the drama of what happened after now but essentially we

have been using it to build infrastructure and bring down infrastructure every time you run training as part of that uh for people who have tried integrating terraform into AWS it requires you to have an I am user uh for people in the Azure space IM am user is like a local user inside your AWS account which is separate to your ad account so hopefully that kind of levels the playing field um it's as much as a user which is an active directory user in the AWS context now uh chapor obviously could go down the path of doing some kind of a external role if you were to go down the path of terraform Cloud but most people

primarily use the I language they have a g repository that they use to build instu chain so this particular uh I guess the video that was shared starts off by uh showing we had username password in that state file that was P pushed into the GitHub repository that's what's highlighted kind of embarrassing password but anyways password 1 2 3 is not the best password one would say to skick it off things but essentially uh that was a ter Tero State file an endpoint and a username now on the onset the person didn't really know what that was they tried username password on J from cloud didn't really work but I think the interesting part was later as

it kind of progresses they thought that was the access key for AWS which it wasn't fortunately it was an API key that we were using and uh they kind of decided okay this clearly something important over here now endpoint that's mentioned over here the 892 960 something something entally what I'm trying to say over there is the fact that for people who use AWS accounts uh there couple of ways you can I guess use the CLI one is you have an access key you can get a im user created from the access key a a long-term one or the other way around is if you get access to the IM account itself you can just log in if you have

the account ID so this person chose to log in into that account and that's basically what they did after um I kind of realized the region was Stockholm because my region normally is either Sydney or Northeast but I'm not going to make an assumption over there but essentially at this point in time I'm super proud of our team then going oh everything seems to be read which is a good sign that we're doing security right so that even the person moving around yeah MF was not there that's okay like at least the personal L but everything else seems to be uh pretty much down to the pat where I feel I felt a bit comfortable like as I was watching

this video I felt Yep this is all good I'm not nothing to be worried about a lot of Reds over here as well there's a good permission boundary and as you kind of kept going through this video um the person comes across this terraform user also has an access key I don't know why we created an access key for it but we did um and I think later on I found out and terone people confirm this you still need an access key as well on top of it for doing CLI actions apparently so it's not just enough to have an IM user but you also need access Keys um now I don't know if this is still a thing this by

the way happened uh I would say a last quarter so Q3 is when this happened so this fairly recent so I don't imagine terraform has changed a lot but we were still very confident as we watching this video we're going okay I've got read only ECU read only um for for context I guess for people who probably have are from an Azure or gcp that's what an IM am or an identity access management screen looks like for AWS and a im user essentially it depends on what you have as a role assigned to you that you can do what you want to um that's why most people go for read only now not all read only permissions have

only read only permission there write permissions to it as well uh as you would see in the next few minutes of it as well um the individual tried launching a launch launching an instance which is a virtual machine for Azure um usually when we have seen a pattern where if you talk to anyone who has had an incident in AWS going through an in instance creation path is probably risky because you instantly sometimes get an alert for hey there's an instance type which was not approved has been created or there's a if there's no guardrail for it or there's a someone picks it up easily so usually it's not recommended but the person chose to go down the path just to

see if they had the permission my assumption is to do cryptojacking is would have been the initial thinking here uh but I think as I'll let the person continue over a bit more uh oh this is this was the embarassing piece uh this is cloud trail for people who don't know cloud trail cloud trail is the auditing service in AWS essentially everything that happens in AWS is uh recorded by this service called cloud trail so everything from me logging in uh with my IM user or my single sign on user all the way to resetting my password and creating instances and everything else that was kind of like what cloud trail does and as the person progresses uh for people

who probably know cloud trail you'll realize this already that we didn't have cloud trail turned on now what's the importance of this turned on essentially whenever you do an instant response for a breach in AWS this is the first thing you go for you look for Oh either what has the person been up to in cloud trail so I can find out I can backtrack to what the person has been doing or the other way you do is uh as as a lot of people do so if you want to go loud is you just delete the cloud trail to begin with that's the two way people will re approach if you get access to an ad account now conveniently

I made it easy I didn't even turn it on so it didn't have to do anything else uh so it was a much more easier exercise for the individual but essentially if you are looking at this in your organization if you're ever trying to do a a killchain analysis A lot of the time instant response teams and forensic teams are looking for uh hey where are your cloud trail logs uh do you have an enty now there's a bit more complexity to what gets logged and how long it takes and all of that as well but essentially a lot of good practice is to have your cloud trail exported out of AWS I want I let the video

continue yep so that confirmed that I actually don't need even have a cloud trail account so that was so I didn't have basically any way even if they did something I would not even know what they did if they were to do something and walk away uh so that was the first thing they found which is still not bad right I think at this point in time I'm still going okay this person is not going to do much cuz read only permissions don't want to launch launch instance or but they found uh an instance running in the North Virginia region uh which is what I said in the beginning that we primarily operate in the northern Virginia region

and and Sydney region uh for for reasons being any new service that comes in from AWS 90% of the time that service is available in North Virginia region which is why you end up using that and uh we had a service which was left running my I'm I'm still confident at this point by the way like the person only has read only permission cannot do much uh session manager usage nothing happens or it does so I I must confess at this point and I did not realize that AWS has changed their console to the point that I don't need to be on a command promp anymore to log in into a box I could just do it from a console that's what

SSM and the system manager does uh but the person didn't do anything there either uh they found the role that was attached to the ec2 instance had an SSM management instance role and there was an additional uh so I guess you can see where this is going with this now essentially there was a role attached to the ec2 instance which was not a bad role the SSM management instance role but but then someone added an additional role which is not for my terao uh which was a which had permission to S3 allow which basically means it has access to all the S3 buckets in the entire account that I have that's kind of where it

starts woring me a bit but anyway I think it's too late at that point in time anyway so we like okay this is going to be how they're going to operate so they go back to the SSM session uh the S3 LS is basically to show um it should be visible it's visible um yeah that was basically to show that they can list all the uh so I used to have cloud trail turns on but I just decided to somehow not keep it on and the next thing they ended up doing was to search for once it comes up there was a answer someware uh bucket that was created that was basically totally an experimental bucket um

essentially for people don't know uh ransomware has been quite popular for a while and the way ransomware works in Amazon is that instead of what happens in like what you hear in the news where you're logged out of your system what people do in the AWS Contex is basically they if they have access to AWS account they would copy everything out of your S3 bucket and just leave a note with your Bitcoin and interest in there as well that's kind of how Ransom work Works in a cloud context so this Bucket over here was to show that experiment where hey you could just have a lot of information in your uh S3 bucket which delete and but but then again cloud

trail has to be turned on to know that someone's done that there's a whole background to it but that particular bucket was uh intentionally kept as a uh experimental bucket and as they kind of get through that I think that was towards the tail end of it as well yep so they couldn't download anything which is good thing so they okay so they can access uh the bucket but they could not change anything but there was something interesting that they did over here that I'm going to wait something just going to come up in a second this person moves a bit more forward oh yeah so uh apparently you could just do this is a silent test

without triggering any alarms uh when you do a dash dash dry run normally people have alerts for if someone scans an entire S3 bucket there's an alarm that set for hey by the way someone's scanning all your S3 buckets uh but dry run is technically not logged in cloud trail at least what I the way I saw it it's you can see that I ran a command quote unquote for uh S3 bucket now this may change as things more change uh but essentially what we realized was this was not getting logged into our seam solution cuz it's technically just testing the fact that hey can I do this and that's pretty much it it doesn't do

anything else apart it doesn't copy the file it just basically tests the fact that whether the person can download the file or not as well uh so make sure it kind comes yep so basically that's what the person ends up doing now I think after that the person just basically went created a folder copied across uh what was there to copy that's essentially the end of the video as well essentially uh but one would think they would stop for that particular perspective but then they come back no public IP they can copy the S3 bucket if they want to but they're choosing not to and they went for once it comes up jeez it's so much quicker when it's

happening in real time but like what is the person going to do um they didn't want to attach a public IP address come on oh yeah so for people who don't know about volume and snapshot essentially every server that you have in your AWS has an EBS volume technically it's just a volume uh a very well-known strategy if you ever get access to an AWS account is that you don't you don't want to if there's an agent in that volume how do you get information without being detected by the agent you make a snapshot of it and then you access a snapshot you don't access the uh volume itself so that's pretty much what that

is was towards the end I'm going I close that come back to my slide uh and start embarrassing myself even more but essentially what what you saw over there were three things that happened um a first of all we had the terraform State file with the terao IM IM user which is kind of like I think if you think about where it kind of came from totally own it we when we rejected it we had to delete the entire repository because it's not easy deleting from GitHub history history I don't know has anyone ever tried deleting something from get up history or someone has or a couple people like so that's how rare this is

in a room of almost I don't know 30 40 plus people uh two people have tried it I was probably one of them I failed all the stack Overflow articles don't work at least the once I tried did not work so at that point in time we decided to just kill the entire repository and move on with our lives and uh we recreated the thing cuz there's nothing else you can do so uh so for basically we didn't have if person did not inform us we probably would have kept it there as well so we're definitely grateful and they wanted us to show it and obviously um that's what we've been doing over the past few months or so just sharing with

people hey that even if you have a readon permission and you've been doing it for 7 years apparently uh you still have gaps that are left behind by uh changes you may have be going and the the the the changes are frequent enough that you can miss sometimes what the changes have been left by people even if you're using Tero um so the first thing they did was identified I was not using cloud trail um as someone who's basically getting an access to an AWS account the first thing I normally do is either I would just turn it off or I would basically make sure if there's a cloud trail turning on I would create a

separate user which is named similar to an existing IM user and then use that to do what I'm doing because then it gets logged into that and usually when people are going through logs they see a similar name if it's say if it's just Ashish and I just say remove make it to Ash or whatever but have like an extra e or extra end in the end people don't really notice it so you can go through and spend a lot of time in there if you want the other thing that the individual did was uh they tried finding out if they had access to S3 bucket which in this particular scenario because of the I am role on the ec2 instance they found

they were able to get to the S3 bucket which they could have copied but they could not pull it out of the uh if you notice the reason why the person was looking for a plastic or sorry the elastic IP was because uh it wasn't access from the internet so they couldn't take the data out from the internet they could basically do whatever they want inside which is what you would notice most infrastructure designed in a way that you can come inside but how do you leave that's kind of where I think most strategies kind of kind of play the role of if they're inside the environment if they are inside an ec2 or inside a server our

endpoint security would pick it up but if they are uh say in a network we will have uh network controls that they can't go leave the system as well so we had the basic controls but then uh the other other point which we did was uh the volume you can make a snapshot of it you can still access what's in there uh you can create your own ec2 instance and without the agent if you want to and uh add an external ID or external account ID there basically um this was not a thing until like a few years ago where it wasn't easy for you to share volumes between different accounts and different regions but as AWS has expanded these

days you can share volumes and snapshots across multiple accounts as well because everyone these days no one really has a one account aw structure as well these days everyone has multiple accounts so uh that was the demo but essentially for people who are still kind of thinking what the happened hopefully I could swear but anyways too late um they I we had the terraform access key as I said now in terms of an organization that may be working on Amazon instances and trying to see what they look like usually from a risk perspective things what you're looking at is that obvious one is reputation damage but there's always some lwh hanging fruit that's always remains behind I think that's

kind of what the messaging for us from all this was even though we thought we had everything we had a cspm as well to make the things easier but essentially just a common mistake of having a im role this is a business logic flaw this is not a vulnerability and most of your choling does not pick up on a quote unquote business logic flow this is where people do pen testing and all of that comes in uh the idea behind this was uh if there are low hanging fruits if the changes made to the system we should have been able to pick it up that's at least was the uh the the reason why we thought this was something

worthwh sharing as well uh but this is what the uh the structure looked like and for people who probably have never seen teram before essentially that's what uh the Manifest file is this is assume me with a sh of beard uh that's basically I would do a terraform plan terraform apply and uh the Manifest file is what tells the uh the environment that hey this is what I need to create these many servers these many volumes or whatever and the the solution instead of going for a state file which is stored in your local repository in GitHub uh the recommendation usually is to use terraform Cloud uh now terraform cloud is something which has has a free

tier as well you don't have to pay for it even though there's a whole Enterprise tier to it I did not know there was a free tier I just assumed that was a paid SAS service and uh you can use your state file to be stored in the terraform Cloud instead of your local repository so at least you give away that risk to someone else at that point in time so this is my uh one of one thing that we learned from this incident that we stopped using terraform locally we just started using terraform cloud and moved across our state files over to uh moved over to teram Cloud at that point in time which still allows

the same flexibility you can still run it from your laptop you can still do pretty much what you could do before as well um the obviously as I'm pointing out this is a file that was in my laptop uh now that's been moved over to the chap from cloud environment now um I do want to call it out for some re season um I think when I gave this talk a couple of months ago at DTX Europe This is Not By the way my employer I think just make sure cuz the the last company I was working for they did not have this and it was fairly recent that they had a breach as well but this is not that

particular breach it's calling it on up front before someone does ask me and knows about it but uh leaving that out there for uh you folks right now The Tale of Three Cloud breaches I kind of explained what happened but what was truly The Tale of Three Cloud breaches as we were going through this exercise uh we were kind of trying to see why is it that it's not a common knowledge to kind of share this information about business logic flaws in applications all of us have seen it in on premise environments all the while usually we used to do uh what's it called a pen test that used to be an obvious solution for us to find out hey is there a

business logic flaw that I'm missing out on but what seems to be happening and I'm guilty of this as well as a as a pest in Cloud people normally go I just want to do the application I don't want to do the network lay because I've got a cspm or I've got another Network tool that I'm looking at that's going to take care of it this was not picked up by that and this would not be picked up by any of those tools cuz they're looking at is your S3 bucket open to the internet which is not the same as this where someone just accessed it and tried copying it out as well uh another thing

why you would also find this as a flaw is DLP or data leakage is not a thing in AWS I mean um hopefully no aw people get pissed off but the reality is uh that most Cloud providers even Microsoft uh Azure they have adlp solution which works really work in Azure space but if you're multicloud that fails at that point in time and most LP Solutions are designed for on premise not for cloud so if you actually had someone in your ad account copying out a lot of data out basically imagine your entire ec2 instance volume being copied across it would not get picked up uh by a native product in a OBS you need to have some

kind of a solution for it um now the solution may vary for different people depending on what is important for you uh but that doesn't exist which brings me back to The Tale of Three Cloud preaches um the first one which is the Uber and data dog uh breach that happened some time ago that was essentially because their access keys were logged on to the were escaped on the well I won't say Escape but they were just shared on the internet accidentally and that's kind of how that happened um fgx uh they had basically a crypto wallet which with their secret manager uh which is the aw secret manager so they got all access to all

the passwords from there Capital One I probably would put an exception category but it's still worthwhile calling out Capital One had an AWS employee who kind of transferred over so it's technically not an internal or an external person it was just an AWS just I don't know how anyone would actually deal with it I don't think anyone's threat model covers an actual AWS employee trying to hack you but that was an exception scenario but essentially uh the the idea over there was they found that one of the ec2 instances had an IM am role which had access to a web server which is a web server facing the internet with the vulnerability that they exploited and

got access to the IM role which had access to the S3 bucket that they made public so similar scenario now if I kind of bring back to what I just explained what we did now we had three strikes in all of them we had the access Keys we had S3 bucket with sensor of data as well which was clearly not well well guarded IM user did not have an MFA and I mean Capital One was all three or three or for for us at that point in time but essentially uh there are examples of it but I think they're spoken about in the context of there was an S3 bucket left open on the internet

so the entire Focus just goes on and S3 bucket open on the internet not to the fact that by the way there's a im role in your organization which is uh over permissive um I wanted to show this as well this is the attack miter framework they do now have a cloud version which is uh there they don't have a specific one version for AWS AR or Google Cloud they however have a general one and if you kind of look at the the first 3 if I can zoom into that one essentially this is your um most obvious one which is the S3 bucket EBS volume databases anything which is of storage or with access being allowed on the

Internet is usually the way the the way people find those data or you have a valid account which in my case was a terraform user account that they found uh trusted relationship this is I'm not spoken about enough essentially if you are using AWS uh AWS doesn't have all the services for what you need for your um I guess engineering needs you might have I don't know data dog or something all the other for whatever you're doing uh similar to how we were using terap you would have uh made IM users or you would have made uh IM roles specifically for those providers those are not technically monitored the same way uh because they have an external ID um

that's being what what they do is essentially quote unquote collect information um they have an IM role as well which it can be permissive which was permissive in my case but uh in most cases they usually ask for readon access to collect information from virtual machine but you may be working with a third party uh that is integrated into your databas account but require a lot more than that so worth while calling out that those three are still the more common ones this hasn't really changed much and U yeah going to give the example I think so the last few are just giv me example of the fact that uh pretty much what I call out we had the third party

credential in Cloud account uh sensitive information for IC as well all right this is kind of towards the tail end of it as well but essentially what I want to talk about is the mitigation for low hanging fruits now um technically one would say that if we had a pull request this could have been picked up earlier instead of just one person just know being allowed to because they're senior uh just letting them push through now I'm not saying that you should not let someone push through based on experience there is a level of trust trust required for the GitHub repositories that you're maintaining or gitlab repositories you're maintaining or bit bucket or whatever else you use um but the idea is

that um we took away the fact that even if it's a a senior person we still improved our GitHub workflow now we have a pull request uh workflow there's an approval process even if it's more senior person there's still someone else who has to validate before they actually push anything into a uh IC Library we we had the right kind of control in the code context in the application didn't have for I or any other repository for I because technically it's a separate team we're not technically developers we're technically Builders so the same rules didn't apply but I would teally say they definitely do apply to us as well um the other thing that we ended up doing was

secret rotation one thing that we did I and maybe lesson we learned was the fact that um if you create Keys it should be fairly easy for you to rotate the keys as well uh we had those keys used as static keys in other places as well moment you kill one key suddenly nothing everything else stops working and you're like oh it's probably being used to somewhere else as well so having a process I think in cybercity we are told about data life cycle secret life cycle key life cycle that's why they talk about it essentially as part of our Disaster Recovery planning now we also have this uh method where are we able to rotate a

key without affecting something else so we started using secret manager um even though it had a hack before but we started using secret manager for keeping secrets instead of static files that's was one of the takeaway for us from that as well uh that's essentially for the credentials in terms of users uh the mismanagement of users I would say this is a work in progress especially if you have uh I guess we don't have a large team we have still 20 of us it's not really a huge team but people who have a larger team having a uh periodic user review you however you do it uh these days you can have solutions that can

look at your IM roles and tell you beforehand if there are permissive or not but it definitely helps you uh at least get to a point where you feel comfortable that none of the IM users that are there in your AWS accounts are new and not known to you but also if you can get away for from using IM am users uh this is the best thing possible but something that I learned as well which is probably worthwhile sharing is that AWS would recommend that you should have IM IM role external ID on the IM role as the best practice but one thing they don't mention is the fact that for that to happen the person on the other end

should be on AWS as well just kind of like their way of I guess growing the ecosystem if you want to say that which is why terraforms of the world and other people they primarily use I am user now obviously if you're a big enough organization you can ask them to go down go down that path and they create an AWS account but essentially that that's that's one of the reasons why you would find a lot of providers they just ask you for an IM user they don't ask you for a role cuz that's what Amazon says because that helps the Amazon ecosystem as well so just to let you know it's a bit of a gray area as to why some

organizations choose to go IM user versus IM Ro and it's pretty well known that the uh best practi is you go for IM am Ro now in terms of benchmarking uh CIS Benchmark is an obvious one but it kind of fails itself after the first account so I would't recommend it I just kept it there because I think it's definitely worthwhile checking into if you have not looked into yet uh but there's one from CSA uh they do a multicloud one uh most Cloud providers I mean most of mostly everyone including us we're all multicloud uh we have Ash or gcp as well and the idea behind has always been the fact that okay um how do

we do security uh in a unified way across the board across all three Cloud providers um initial starting point was a benchmark for ash and gcp because we primarily AWS shop um adding Azure gcp meant that we just just didn't have a starting point so we started going with CIS Benchmark to start off with and that kind of started building from there uh so if anyone else is in a similar State they can do the same as well uh last one is probably the hardest one as as easy as I have it as a on line item of asset inventory it is a problem that has not been solved since the joint time of joined it and we still don't know what

assets we have everywhere in all our on premise AWS accounts and aure as well but um there are uh that is still definitely one of the ways to know if there are extra resources that are being created so the uh the conclusion is uh obviously knowing where your knowing users and secrets is always a good idea user review definitely helps like a periodic user review definitely helps um security controls are good to have but uh you need to have an additional control for uh business logic flaws that's kind of what we were affected by that nothing to do with S3 bucket open to the internet nothing to do with EBS volume open to the internet it just was

a simple case of the business logic that was used to protect that system or application was not right um education for application for educ education for employees who going to be creating those resources Paramount as well uh in terms of monitoring threat we started adding uh scenarios for I think we've been grateful for every time we've given this talk we've B basically had people talk about similar scenarios that they experience so we've been able to kind of add more thread detection on our end as well that kind of definitely helps to kind of keep building on that Library uh as many of you who may be from a third detection background it's never a you

have all the answers in one go we are always evolving there's always new changes coming in I think in fact now as of aw3 invent for people who been following it they had so many uh Bedrock announcements play something playroom or whatever it's called play Rock um essentially now there's a lot of AI being used as well so so that's a whole another gamut of what other kind of controls you can actually apply uh turns out AWS themselves don't really have anything apart from saying IM role is a great way you should make sure your applications have the right I am permissions like thank you but no thank you anyways that's kind of like what the

conclusion of that was but uh that's kind of what the talk is I have got time for questions if anyone has questions but thank you for your time thank

you there a gentleman with a mic if anyone has a questions otherwise I'll be here as well cool no one wants to share their breaches anymore cool um I think if there's no question oh sorry there's a question over here in the front

thanks thanks hey uh you said about using an I am role instead of an I am user I didn't think Al so IM role instead of an IM IM user yeah so yeah so I think the general practice is to use temporary credentials basically what they say and the best approach do that would be using IM roles because that allows you to create temporary access credentials that's what the general practice recommendation is but your third party would just say oh we don't use that that's why we have to use IM IM users but to you you need a user with which to be able to assume that I am roll you can't just log in using I am

roll you have to if you have an external ID you can so if you have a so I am user can have an external ID or an ID attached to it which allows you to request SS credentials but but but that still is is linked to an IM user on the back end as then there's still an IM user that you can use them to request the credentials and then you can assume that oh yeah yeah as in yeah so you still have an IM am user somewhere who's ultimately or most scenarios people would say single sign on is a better way uh use single sign on to instead of using IM IM user complete ditch that you

can still use uh SS if you have single sign on if you can uh cuz nowadays identity center from Amazon is free as well I can definitely and they have a local like we met a um a tech startup here which is fully like they W all they were in Cloud no active directory don't even know what waterfall methodology is like but um they ended up using identity Center for their user directory for the single sign on and for connecting with IM RS across the board so that is the recommended way if you just want to be fully native to AWS yeah any other questions oh one more here for this particular setup would it

been like Prisma or skat site detected that that's because it's a business logic it's not so the what they would detect is the fact that hey by the way I can see this three-step four-step process to the fact that it's open to the internet but they would expect us to put this as a custom rule into the tool like even if we Wiz Prisma Cloud whatever else you want to take uh at least we are I think we're using whz one of the cspn we don't use them anymore because we don't have that much in the cspm or need for cspm but whatever cspm we had is not detected we had to put that as a custom rule in it yeah and

they did call it out that if if it's a business specific rule then you should add it yourself is what the wording we got from them so thank you for the question any other questions before sweet going once going twice awesome thank you so much for your time I really appreciate this thank you