BSidesSF 2024 - Temporary Access to the Cloud: A Case Study (Tomas Rabczak)

it is my pleasure to introduce uh Tomic and uh he's going to be talking about uh temporary access of the cloud take away Tomic cool all right thanks everybody for coming out thank you thank you uh yeah this is temporary access to the cloud a case study I'm going to take a moment here to appreciate my giant face on a movie theater screen that's so cool uh Brad Pit was up there um I'm not Brad Pit I'm Tommy cjack I'm a Staff software engineer at chime we have a lot to cover in this talk so I'm just going to go straight into it um let's go over the agenda here we're going to talk about uh

the problem uh we're going to go into ideation and data Gathering uh where we kind of collected metrics around access usage um at chime then we're going to dive into the design and development of the actual application so we'll Deep dive into the architecture uh we'll roll into product metrics which is kind of like a new obsession of mine um we'll talk about the roll out and how that went especially kind of from the perspective of a culture where folks were used to having permanent access and moving it to Temporary and then we'll finish it off with a retrospective kind of looking at what went well what maybe didn't go so well and if we were to do it over again

what we might do differently cool so the problem employees as an attack Vector this next slide is kind of funny because uh the access talk from the Discord team um presented this same metric but it's this awesome this one's from the 2024 data breach um but again 68% of breaches um involved a human element uh just always a staggering metric they recently changed it for 2024 to not include um like malicious insiders um so these are potentially just folks that are uh getting exploited for their access and not meaning to do it and yeah there's the headlines to back it up too uh plenty of head lines to share um Uber being hacked Microsoft um Engineers account likely led to the

hack as zenes uh falling for a fishing attack twilio suffered um an attack hackers claim it only took a 10-minute phone call to shut down MGM Resorts uh so that happened recently you may remember um and then this one is the absolute crazy one that's like happening uh with the AI stuff um a hacker deep fakes an employees voice in a phone call to breach the IT company um According to retool which that's just crazy okay um so yeah ideation and data Gathering so now that we've kind of presented the problem let's see if we can see what this problem looks like um at chime and so to kind of step back a little bit

about where the impetus of this came from segment actually had released a blog post called access service temporary access to the cloud um which is a great blog post where they lay out um a similar service that they built um kind of talking about the same things we'll be talking about today um and so it was mun that um saw this one and then brought it to the team and we decided to uh try to build this ourselves as well um one thing that was really cool was we actually had a call with segment before we started building this to kind of get their thoughts um how things went building it out if they had any other

recommendations uh we talked about like build versus Buy which we'll talk about later in the presentation but it's not something that I would have thought to do um but now that I'm like on the other side of it it like it would be totally cool if anybody came up to me and wanted to like talk more about this um so this kind of cross company collaboration I think we should be doing like way more of it cool so this is kind of a pretty similar to what our applications look like uh there's a lot of data in this table but this is breaking down all of the access across some of our top OCTA groups um and so you'll see things up

here like AWS snowflake uh strong DM um is a is a software as a service that provides um management for eks and kubernetes and then we have some internal applications here um but what I wanted to focus on was this right hand side so this is breaking down the users that have access how um what percent of those users have actually logged in in the last 30 days and used that access so the green side represents users that have logged in and the gray side represents users that have not logged in in the last 30 days so pretty stagger metrics um and that the gray part is sort of our attack surface here this is

like the problem in data and so what we're trying to do here is minimize that gray area as much as possible cool so design and development so uh kind of borrowing from segments access service um the goals that we set out for is that we wanted to make this self-service sort of going off of the idea of the shift left um empowering engineers and other team members non-security team members uh to get work done but make things more secure another thing is having this uh be just in time access um and so you're requesting access for when you need it uh streamlining the approval for flows making sure that it's easy for folks to actually um find the access they need

and then um get it quickly but have it be approved and someone's looking at it to make sure that they need that access uh a final Point here is providing quick access in the case of like emergencies and incidents so you know if you have an application or a group that has some approvers and there's an incident that happens at 3:00 in the morning those approvers aren't going to be available to give access so we need some kind of break glass scenario um to allow uh users to be able to get that access in the case of an emergency so that's something that's in the back of our mind as well cool um so before we kind of Deep

dive into the architecture of the service itself this is all built on top of OCTA which is our single signon provider I'm sure many folks have heard of OCTA um just tldr manages user identities um as well as applications and then groups so you can assign groups to Applications put people into those groups um users and then that kind of manages the access uh you can do some nice things like enforce multiactor authentication but one of the features that we took advantage of right off of the um from the beginning was the support for skim based access management and that's important enough that I've put a slide for it so if folks haven't heard of skim before it's the system for

cross domain identity management and really all it is is that it's a specification for where you provide a set of ultimately like rest crud apis for user and group management inside of your application and so this is nice because you can utilize skim a provider like OCTA can utilize skim and create these Integrations with other applications where from our perspective we don't have to worry about the application we just use OCTA to put a user into a group and through the protocol um all of the user management operations happen in the background and so what that means is that we don't have to write any custom application code so when we put a user to a group in Octa we

don't have to write custom application code to go call an API for you know X application to do some extra user management there um so that was a nice feature uh going that route all right so what does exess service look like from an architecture perspective it's really just kind of a pretty um basic web service that sits on top of the OCTA API um and really the foundational API calls for OCTA that we use is add a user to a group and remove user from a group um backed by postgress um you see that there's no lines again connecting us to the applications we're utilizing skim to handle all that for us um we have some Crown jobs in terms of

syncing state from OCTA so you need to know who the users are of the company um who their managers are uh which groups should access service care about um because we we don't onboard all of the OCTA groups and all the applications uh we we pick and choose which ones get get into access Service uh cron jobs to expire the access request 15 minutes same as the Discord one um fetch usage events that's an interesting one because and we'll talk about this feature later we use that to enable activity refresh for Access and just the tldr of that for now is it means if you use your access it'll get extended and so uh we use

Panther as our seam that's our centralized um audit log store and so we can query Panther for various applications to see whether or not you've authenticated to it uh we send notifications via slack to both the requesters and the reviewers reviewers can review access requests through slack they don't have to go through the UI um I mentioned the emergency request feature uh we utilize a service called tines which hooks into our security operations center so anytime you create an emergency access request um our security operations center gets notified uh and they'll follow up to make sure that that isn't suspicious cool uh so this is the demo

let me see if I can full screen

this all right so this is what the application looks like um what I'm going to show here is me accessing an uh a kubernetes group and we'll go and create a new access request you have the ability to search for your group this is a kubernetes group that actually allows for instant access because it's non-prod and I'll pause here no I won't sorry about

that no pausing um so you have the option to choose activity based uh which we talked about earlier you give a business justification uh you can choose whether or not emergency access but we're not going to here once you submit it because this is a non-prod group you immediately get access to it and becomes active and you'll see when I toggle SDM it's that quick like you get access to the kubernetes cluster um and so you also have the option to revoke that access uh which the user can do and also the uh resource owners and a manager um if they have the permissions so here we revoke it and you'll see the cluster goes

away and we'll dig into these flows a little bit more but yeah so some key implementation features from the service I'd say syncing the state with OCTA is kind of one of the trickiest parts um it's a little bit tedious making sure that um you're syncing that state properly because you're calling the OCTA API to get all the users trying to make the manager connections the OCTA groups um I'm actually looking into utilizing skim in application in exess service itself to get um sort of web hook events from OCTA about new users and groups and so I would be able to get rid of the crown jobs which I think might actually work and would be a nice addition uh

sync Tas should be item potent um Crown jobs fail when they run again they need to not mangle the state um everything that talks to a third party is asynchronous including the calls to the OCTA API OCTA API has insane limits um on their API and it's both at the application Level and on an organization level which I'll dig into um later on in the presentation minimizing third party dependencies this is a very sensitive application and so we want to make sure that it's as secure as possible because any potential vulnerabilities um or authorization bypasses could be uh a really big deal uh reviews are only required for production groups so everything else is instant access and no one has to review

and then the last one here is that I'm kind of a lazy developer so the less I have to manage the easier my job is and so kind of taking that shift left mentality all of the group and approver configurations are in terraform and the resource owners themselves can just make PRS and onboard applications onboard groups um themselves and so that means less things that we need to manage ourselves so very simple this is what a configuration looks like in terraform you're giving it the name of an Octor group a description that's going to going to help requesters be able to find um that role easier the approval type here there's one of three um no approval

that's the instant access owner manager here means that either the resource owner or the requesters manager can approve the requests and then the last one is um owner only and so that doesn't allow a requester's manager um to approve it and then you just specify the approvers as as emails cool and so what does that look like when you actually apply this um these properties that we're using are actual they're custom OCTA group profile attributes so the one in the middle here is just a Boolean flag that's actually what we're querying on the back endend when we go to list the groups so that access service knows which groups it should care about um we have the

approval type there which is an enum and then um this service is just all OCTA groups everywhere so the approvers um we actually create another group um to house the approvers and so in this example you have this theoretical application called app one admin we go and create an approvers group for that application put those user users in it and so our Crown Jobs go and query that to actually um set up the state in our internal database this is s is going to get a low level okay emergency access requests so this is what it looks like when you make an emergency access request you see a Banner that says like hey heads up um

you need to share the the link to this request with anyone that has access to access service um and so this is kind of the middle ground that we decided on we didn't want emergency access to be instantaneous access to production groups we wanted there to be still some kind of control and given that the reason we built this feature was to respond to incidents um the way that our incident process works at chime is that there's at least two people that respond to it there's usually going to be some kind of engineer and then there's going to be an incident coordinator so you're always supposed to have someone else that you can share this access request

to to get access to um and some teams will um sort of proactively put themselves into these groups based off of on call pager Duty things um that's a feature in the backlog to try to do that automatically but it's not something we do today cool um so yeah this is again what the form looks like we have the ability to do activity based or standard most featur most of our users go with activity based uh this is the state diagram for an access request goes from pending you can cancel it or wait on a review decision um if you get an approval it goes into processing which we actually added recently because we were hitting

the OCTA API rate limits so in the UI when folks were approving a request they it would just hang for up to a minute because the back end was waiting for that um rate limit to get reset so we had to move that to a background um async job and then add this processing state so it's really just like a transitory State that's in there for maybe like a second or two um before it moves to active and so from that point it can either expire or um users managers or resource owners can revoke that request this is the slack integration uh so this is what the reviewer sees when they get um an access request to review

they approve deny or view the request in the UI if they deny the request they're going to see a model that's going to require them to put a reason that they're denying the request um once that request is approved again we're sending out notifications to multiple reviewers so we have to go and update all of those notifications and um switch it to showing that it's actually already been reviewed which is a pretty nice feature because before this uh reviewers would go into the UI and see that it's already been approved um which is a little bit of a pain because you couldn't do it through slack and you had to be on the VPN um so this was kind of

a nice feature I think the GitHub slackbot does a similar thing um which this was motivated by uh this is what the requestor sees in slack when they've been granted access they get um a warning message before their access expires and then they get another message when it's actually expired with a link to request all right audit events so yeah audit events are very important uh for Access service not only for our Auditors but also for us in the case where we need to maybe debug an issue uh users can also see the audit events for themselves um and so yeah you can export to a CSV here which is what our Auditors use um to

review access cool product metrics um yeah so product metric I feel like is not really a thing that the security industry security Engineers maybe have utiliz very heavily in the past and I'm here to make a case that it's like very awesome and everyone should utilize product metrics if they can um I think for two important reasons in my opinion one uh for example the top one is permanent versus temporary access this is was our North Star metric um and so this is what we were looking at to try to drive down Perman access so having like a looker dashboard that showed that um that broke it down across all apps and then for individual ones um

it was just really useful you can take a screenshot put it into a metrics meeting um but the other one is also that it just like shows that the application is alive and working which sounds weird to say previously maybe you would open up some kind of development console and call like do count on access request and be like all right that number went up cool like things are theoretically working but when you break down the metrics into these individual Parts it really just kind of brings the application alive and also allows you to really monitor and set up alerts on things so these are just some examples in terms of monitoring metrics these are

things that you might like set up alerts for right so groups that require an approval but there are no or a low number of approvers um folks leave the company and so you know Alice and Bob if they both leave the company you now have a group that requires an approval but they don't have any um other interesting metrics just like meeting approval times uh stale requests ones that have been in a pending state for more than five days um segment again had a blog post just about tracking meaningful security uh product metrics which I'd recommend cool so here's some examples uh this is kind of like that Northstar metric that I was talking about this is

uh an application name has been changed but um this presents an application that used to be fully permanent and then we transitioned it to Temporary and so all of the people that had access to this you're seeing about like 900 on the bottom um after 30 days which is what we defaulted the migration to 50% of that access dropped off and that number 50% has been pretty consistent with the numbers that we've been seeing across these migrations um and so like that dip right there is like all of the value of this product so just like seeing that I don't know it sounds stupid and simple but it's there it is it's working um all right roll out some may

be wondering how long did this take to build uh I went back to GitHub and looked at the first commit that was February of 2022 uh in October of 2022 we did a soft release which meant that you can still request access the old way which was through an IT ask Channel or you can request access through access service um in February 2023 one year after the first commit we did a production cut over and so um all requests for the supported applications have to go through access service in May of 2023 we rolled out activity refresh uh which is if you use it it'll get extended if not it expires and then September 2023 um is when we started

moving all existing uh permanent access to Temporary and that's something that we're still working on today cool so for that roll out the plan here was to first start by dog fooding access service just within the security team so the idea here was you know people would remove access for themselves that they had that was permanent from that point forward they would request access from access service got feedback iterated on things The Next Step was to choose an external team that had a good track record with us that had worked with us in the past um and had a the track record of championing security and so then we used access service with them got feedback and

iterated um from that point forward we made groups available to all users um that's the the point in the timeline where you could either go through it ask or through access service um at that point we were in a pretty good State and we were kind of ready to really make this the main path to get access um for engineers but we needed to get um sort of the Buy in first from the engineering organiz ation so we started doing Road shows for our internal engineering teams leadership and stakeholders and so this was really us just kind of meeting with the individual leadership teams and showing them access service presenting the problem showing them the metrics of

like hey look at all the access that's out there and how much is actually being used um and so getting them on board first before we started to roll it out uh this was a a real key um thing that I think contributed to the success of the roll out then transition the permanent access we've got uh access service ask Channel and slack uh for any questions that come up we also did a premortem which is interesting I've never done one of those before uh so the idea here is that unlike a postmortem you do this before things go bad and you try to think of the things that might go wrong with the application before they do and then sort

of potentially um retroactively fix them so we identified you know security bugs that would be it's kind of a an easy one we talked about ACTA API rate limits um where the approval approvals are out of office uh that's something that drove some features long wait times pending requests um the break glass scenario for emergency access all these things came up in the premortem cool changing a culture of persistent access uh after we rolled this out um and folks started having to make requests access service we started getting a very common question in our access service ask Channel and all these questions are hey it looks like I can only request one month um how do I get permanent access

um and so these questions kept on coming in um and so we had to start working on this idea of changing the culture of persistent access uh we talked about the road shows that we did um so I think from that perspective we had leadership on board um but we needed to start creating features that helped kind of reduce friction um and made it easier so I think that was a valid thing people saying hey um like I'm using this access all the time like why is it expiring and then you're just making me create another request like immediately um which I think was valid and so we went the route with all right if you are

using your access and we can tell then we'll refresh it for you but if you don't use that access it'll expire um another one that was popular was uh we actually switched it over um having instant access for roles that weren't production this enabled a lot of people uh to get access do debugging so that was a popular feature um the emergency access in the case of incidents and so what we're working on right now is we have a 90-day cap on access it's just what lines up with our quarterly access reviews for our Auditors and so in before access service that would just be you know managers get a batch of access and they have to go through and

reapproved so we're building that into access service to allow managers to just

reapproved managers can extend that access for them cool and so then we started getting feedback that people liked it um this is another thing where I think being in the security industry this is not a common thing to get people that like the thing that you're working on also sounds weird but that's just like the nature of it and so that's why I think sort of moving toward a culture where you're actually building things that both secure your company and enable people um that's kind of a nice marriage there because you get positive feedback from it um here's some positive feedback on the instant access feature this is my favorite one when folks are pessimistic

about the service before it rolls out and then they get one over um that there's just something special about that cool retrospective all right so build versus buy um we actually met with a lot of vendors to talk about this at the time there there wasn't a huge amount but this list has just like grown quite a lot um and pretty consistently across all these vendors the one concern that we had that was a blocker for us was that we had to hand over OCTA super admin API key this is the keys to the castle to your entire company um and so that just wasn't a risk that we were comfortable taking on and so we decided

to build it ourselves um at the time access was not available to us but shout out to Discord for open sourcing diversion that is awesome I very much would love to open source access service and it's something I'm working on um but this is definitely bumping it up to the top of the backlog okay not so good OCTA API rate limits so I don't have a lot of time here um yes it's on the application Level and the organization level so what is the organization level mean that means that exess Services OCTA API key could knock out requests across the entire organization so any application utilizing an OCTA API key could get blocked because I've made too many

requests um so we had to be very sensitive to that and in fact we have logic that backs off before we hit the rate limit to make sure we don't actually hit the rate limit um when we moved strong Dam over to skim um that ended up adding a lot of new users and not a lot of new seat licenses which ended up being expensive discoverability is still a problem that we're working with I think the tagging feature in discord's Access uh is is really neat and trying to help users find the role that they actually need and that's something that we're still actively working on um the request for permanent access came in but I would say that this is uh

tapered off and really we're only seeing that for new folks that maybe come to the company and they're not used to access service um one other thing is that we did not do a great job committing to the temporary access during the roll out we were kind of like on the fence and fuzzy about it because folks would come in saying like hey I I just need to do my job can you give me like a Birthright rule to this um to this group we be like all right maybe we can make an exception and so I think the right thing would have been to just really commit to hey this is what we're going to be using

hopefully we've built this service in a way that makes it easier for you and if it isn't please let us know and we'll try to work on that snowflake roll grants I wish I can get into but that would take me like 10 minutes the tldr of that is that uh you can stack snowlake rolls hierarchy and so it's very difficult to do usage attribution on a roll level for snowflake um but if anyone wants to talk about that I'm happy to do it so what went well yeah I think we created an application that both enabled engineers and then pretty significantly reduced our attack surface um by limiting app Integrations to ones that support skim it meant that we don't

have to write the custom code it also um pushed us to move existing apps to skim uh which is ultimately a better system for us the slow and iterative roll out with dog fooding gave us a lot of opportunity to make sure that the the user interface and the user experience was solid before it went out to the company yeah so I think we also did a pretty good job for articulating what the access sprawl issue was like to the leadership instant access again was a really popular feature we had the emergency access that was something that a lot of folks were hesitant about uh I said that we spent money on seat licenses but you can also save money on

seat licenses there are some applications that users might request access to and they maybe use it once and they don't use it again so when that expires they get removed and the seat license gets removed that can save you money the access refresh feature having our usage events query a single place that being Panther also forced us to get more logs into Panther um which having a centralized place for those audit logs is a good win too cool things that I would have done differently if I started over over we started on the level of OCTA groups and we've pretty much ignored the entity of an OCTA application and I think that was not as an an efficient of a move and if

I were to do it over again I would start at the OCTA application because you can utilize the uh app Group assignments and just query that off of the application I think I saw discord's access also do that and so um I'm actually going to be moving toward that model in the next Sprint um oh yes so this is cool for the usage events you know this idea of powering activity refresh um we were I was all in on I I want to get role level attribution you know if you are looking at data read versus just um infro read for example um I want to know that you're using those like specific roles I've been recently rolling out just like

have you logged into the application not if you've used the role just like have you opened the application and successfully authenticated to it as a user um that's going to get you actually pretty far so the zenes graph that I showed you with that huge 50% drop that was utilizing in the back end just did you log in to zendesk so I think I would have started there it's great to have um usage events and configurations on the OCTA group level but um yeah that's something I'd point out big shout out to the team um yeah this is this is great effort took us we're on like year two right now um so yeah and questions I

guess thank you all right big thank you to our speaker speaker toas um we are as per usual taking questions via slido uh if you haven't already set that up it is besid sf.org qna and that will contain information on how to submit question uh we have quite a backlog of questions for you uh a lot of interest in this talk uh first question how many people are responsible for ongoing internal maintenance support and enhancements um support and enhancements I'd say two technically um yeah so it's me and then uh as of recently um sahana has been helping out with new features and then in terms of Maintenance you know we get some help from it support

Rory is from it engineering but this idea that a lot of the configurations live outside of access service um not a lot of required and thankfully things don't break um so I guess I'm good at my job um yeah all right next question any thoughts about Ro based access it seems to be intention with the idea of pruning unused permissions of role based access um yeah and I think that is something that um we are using here and so I think from a pattern we are transitioning more toward like team roles and but from access servic perspective it doesn't really care about those things like everything's just an OCTA group on the back end so if you

want to call it like um payments processing team or you want to call it like processing service cluster access um access service doesn't care about it so that's more of a strategic thing on the company how you want to organize your OCTA groups but yeah I think that's that seems to be a good way to go all right next question uh were there any concerns around reliability did you need a fallback plan if the service goes down yeah so again not all of our applications are on boarded to access service and so there is still the way uh the sort of Legacy method or the the alternative method is going through it ask and so in the case where it is 3:00

in the morning you're responding to an incident and access service is down then we would page someone from it or someone that has access to be able to add that person to the group but it hasn't happened yet on what uh next question it's just paper have you had any issues with less Technic technical folks uh having trouble setting up a new group with terraform yeah that's a really great question up until this point we've only been working primarily with engineers and Engineering teams with onboarding zenes and some of our customer support tooling that uh the pool and the demographic of users has definitely opened up and so I think from that perspective we're still there to help in

that transition but um we have like plenty of PRS and examples that show how to do it and it was like four lines so still pretty easy next ohly archived one but I believe the question was uh what's the timeline on open sourcing that's a great question um I don't have an answer unfortunately I mean it would be awesome if we can get it out by the end of the year um it's I I built the application with the intent of open sourcing it and so I Tred to keep as many sort of internal chime dependencies out of the application as possible but the way that our infrastructure works um that some of that just wasn't possible so I just have

to figure out how to kind of make those dependencies optional or be able to remove them so that it doesn't get in the way of other people integrating it outside of the OCTA super admin topic what were your main reasons for building versus buying a solution I think outside of the OCTA super admin one which was definitely the biggest one on its surface the service didn't seem that complicated to build I'd mentioned in the architecture slide that you're calling two apis ultimately add and remove user from group um I mean it's definitely has been more complicated in that especially as we build out the features but yeah I think it was something where we wanted to keep

that risk inous and it just seemed like a feasible and doable thing um within a relatively short time frame uh how do you onboard new AWS accounts is this automated uh yeah so those four lines that I mentioned it's pretty much that you just add a new one um there's some infrastructure that has to uh some other CH TF some other TF changes that have to happen in the background um but for from the perspective of access service it's just adding those four lines and pointing it at the AWS role so we have SSO and skim setup for AWS so it all automatically just happens all right uh next question interpreted a little bit um what uh why bother with

the requests for non-production networks uh what additional capability are you getting uh if you're already enforcing MFA um okay so the question here is why are we enforcing some kind of request to be created for non-production accounts um but we're in enforcing MFA so yeah we are enforcing MFA on the um you know OCTA and like having to log in potentially at the time um but at first it was that we had sort of everything going through an approval process and then we migrated toward the non-prod becoming instant access um but yeah I guess maybe it was just like already part of the system and it's Prett easy to request that access so no one's actually complained about

that one yet but if they do great uh last question we have on the docket um uh as authentication events might be used for centralized applications like AWS SSO are there any other recommendations uh on this parameter yeah so I mentioned uh the things that I would do differently just looking at authentication SSO um we'll get you pretty far again we did start with ro level attribution and so we we do have Ro level attribution for AWS right so there's going to be a cloud trail log that gets created that's an assume Ro event and so we do query those and we have role level attribution for AWS for strong DM for snowflake minus the RO

hierarchy stuff that we're dealing with so those applications do support it and it makes total sense for those where you have hundreds of roles for one application but as we onboard more applications we're finding that they're you know internal applications with four five six roles um that the application off works well all right we had a couple more questions trickle in if you're ready for them yeah absolutely first one um how much concern is there around the emergency break glass feature being used as an attack Vector uh before you can respond to an event um I think the fact that we still require some other form of approval uh so two things are ultimately still

required you need to be creating the request from a managed device because you can only request you can only create requests through the UI so you have to be able to log in on the VPN which requires a managed device then you don't get instant access to that you still need to get it approved by someone and so you would need to collude with another person another uh another person at the company um granted reviews can happen through slack off VPN um but the request has to be made on VPN and so you still need someone that has access to access service that's a user in Access service U so with those two things combined and the additional layer that

we send alerts to our security operations center to follow up on these things um I think that we I feel like we're in a pretty good spot there great uh we have more questions trickling in we have the room for another three minutes I'm going to try and get through as many of these as we can and we're going to have to cut it off there sure uh next question is for uh from Road uh would you have uh bought rather than built what features should have OCTA offered to make this easier for a wider range of companies um yeah I think I haven't surveyed the landscape of what the buys would look like now um you we Discord

open source their access that would absolutely be the first thing that I would look at um but in terms of buying if it's not the Super admin key or features that OCTA could provide one thing that's annoying is that the OCTA API kind of makes it difficult to not make lots of requests and that is why we hit these OCTA API rate limits a lot um constantly making a request for one resource and then making many requests for others things like OCTA groups and getting who's in the approvers um so I think there's some tweaks that could happen in the API to make that schema look a little bit better and a little bit nicer to query

um also ACTA could probably build this feature into their application like I you all should do it if there's somebody here do it because people are building this I I know other people have built this we know Discord built it Chimes built it but I know other people that have built this internally and so they're just like we we've recreated the wheel as an industry so many times for this problem and so I feel like it should be a native feature all right next question oh give him an Applause if you want it's great talk um next question uh does this have capabilities to Grant temporary access to things like SSH uh or RDP servers or

is this just limited to SSO apps in Octa that are onboarded to the access yeah just SSO apps this is um yeah fully fully OCTA service on OCTA all right uh last question I can partially answer this will the SP slides be made public uh if you're not already aware bsides records all of these talks uh they're being live streamed to YouTube now recorded talks will be released at some point in the future um do you have plans to release the SL talk as well yeah um yeah I'd love to share them and make them available wherever I know besides has a page for that but um can figure something out there all right uh that's it for

questions we're coming up at the top of the hour uh thanks again thas for this uh excellent presentation thank you audience for all the great questions um have a goodie B for you here thank you so much for your time