GF - Building Data Driven Access with the tools you have

um so I'm I'm actually going to just put the microphone here everyone can hear me at the back sounds great um yeah data driven access um so before I get into the uh the meat of this presentation and what we're going to be talking about just a little intro of me um so yeah who am I um that's what I generally like to do during the summer on weekends when I inevitably on a Monday call my boss and say I've damaged myself in some particular way um which is downhill mountain biking so um but I haven't damaged my hands yet so I'm still good to work um so who am I I'm uh 10 years

experienced in corporate it um I actually joined the IT world from the Apple Store where my job title was lead genius um I've been um so right now I um work for company called Ceda uh Ceda I am a engineering manager of tech techical operations um few things report upen to me uh it and devops um we call it Cloud engineering but I thought I just you know um so yes so C's um Healthcare technology company uh modernizing healthcare provider billing systems um don't let the accident fall you I am from the UK but I live in Denver and despite working for a Healthcare company I still do not understand the US system um which is why

I'm glad we do what we do so um one of my credentials for talking about this today uh because as you can see I am the evil manager word um well I've lived the journey across wide range of IM Technologies uh from a company that had a custom database abstraction with multiple feeds to active directory L app a custom shiel of implementation that you had to write XML to get new um uh providers added um to where we are weeda today which is kind of a we've got all the toys uh an OCT implementation with all the best case scenarios so this journey from you know what it used to be to what we have now

is um made me really passionate about access IM am and and uh SSO and stuff like that so um so yeah um well else I've got ADHD which means I've been freaking out about this talk for two months and finished it about 15 minutes ago um and as this is my first ever conference talk other than you two only two others have seen this my wife and my dog uh my dog Bobby um she didn't have much to say about this um but I thought if this sucks at least I put a picture of my dog up um so you can't be mad at me um my wife's reaction um you know she usually reacts when I

tell her an intricate detail about something she doesn't care about sounds great um but then she came back and was like wait a second this seems obvious why doesn't why does it take my company so long to terminate user accounts and remove access and stuff like that so um onto the talk I guess um so yeah what is it what what do I see datadriven access as um so in short data driven access gives you time gives you resources and removes the burden of access from it over to the people equipped to make those decisions um we use as much data as we can to drive automated access decisions and then we fill in the gaps um using

delegated access management to empower system owners to Grant access to the tools they own um so what what are we going to talk about today um I'm going to basically go through a journey of our I am stack and the lessons that we learn from implementing it uh if some of this seems obvious then that's great um but if you come back if you come away with even one thing from this talk then I think we're good I think we're successful um I was actually at Octane a couple years back and uh was watching a similar talk from from Netflix and I was like this seems obvious and then um they mentioned one thing that actually uh

completely filled a huge hole in my offboarding strategy so that was definitely worth it um I don't know if some of you are looking at this and you know we're going through some of the tools that we use and being you're thinking this is impossible um you know hoping to show that there are ways to you know manipulate the tools into doing what you need them to do um I don't want this to be a Sal pitch for any specific tool um there are loads of tools out there I can't talk about specific ones but I'm hoping to provide some inspiration for what you're using um this isn't a brag um I've been where you are so um yeah let's look at

the Ceda like a lightweight view of Ceda stack um so I've put perfect in quotations um because I think that we all know that you know uh we're always going to see what needs to be fixed and What needs to and what is broken but I was at the sphere last night and saw a pixel out because that's what I'm like so I just put that picture there because it kind of reminded me of what you know perfect actually is um but I'm going to go through the stack talk about the tools um try and give you some ideas that can relate to your environments um at Ceda we tell prospective candidates we you know one

good thing about working here is we have all the toys um provided you make a good use case for it use them to their fullest we're we're we're happy to you know use a tool an effective tool for for the use case cool okay um so I'll start with our source of Truth um and I've heard this sometimes that active directory is our source of Truth elap is our source of Truth um I am of the belief that something like a HR System is a source of Truth um and really um HR systems are you know kind of a big deal um they're the systems that get people paid so there's a lot of control there there's a

lot of auditability there's a lot of um uh you know actual control in how you grant that access so I always want to start with um a HR System as a source of Truth um and when we try and get the data from a HR System I'm I'm kind of saying that we're looking to get as much data resolution as possible um so some examples of like you know what I class to be good layers of dat resolution you know we got the easy stuff name Department title who your manager is um you know medium stuff location office um people are remote nowadays knowing if their remote is actually really important um two some of

the more kind of esoteric examples that really do help you with automation um are they a people manager you know job title is not enough to judge if someone is a people manager um sometimes you have to say does this person have more than one person report or more than zero people reporting into them if so there are people manager they could have manager in their job title but it doesn't necessarily mean that they're a people manager um and we use um Rippling at Ceda and I think that the the manager question was actually really key for us getting involved with the people team to um pick a ENT system that we could you know automate off of because we kind

of you know I sold it as a well we can add managers to all of the email groups to all of the slack groups to all of the things that they need to use from day you know from from day Zero like wouldn't that be cool you don't have to open tickets um so I think like you know our goal is for someone to have access to all the core systems they need from Day Zero um so for me um you know it was really important to uh relate that to the hrst HR to the HR team the people team um so that was a very very like quick kind of look at the source of of of

Truth um but I'm going to go back to that in a second um I also want to talk about source of data uh because um I think that you may also hear that o like we use OCTA I think you might also hear that that is a source of Truth um but I don't see it that way um and for um a few different reasons um I think that you know modern IDP should have a lot of these features um but a rich tool set of rules and automations and things that come out of the box that will let you actually um Drive some of the key automations off that source of Truth data um is really

important in a source of data and I also think that you know source of Truth is designed to be mutated in the actual you know Source itself um a source of data we can build Integrations outside of it um so I'm going to go into some examples of kind of what we've done to leverage octar as a source of data and and what you know you could potentially do as well if you have a source of data that has a API um so yeah let's look at some examples of that I've got a pretty good um example here um so this is an example of changing our source of data outside of OCTA if OCTA

was our source of Truth we wouldn't be able to change it outside of you know what is already existing um so this is an example of uh if someone's on call um we run a Lambda um on a schedule that pings the page of Duty API is this person on call um yes so you know add them to OCTA group hit the octra API add them to an OCTA group and put them into the on call group that then fires a bunch of rules that essentially say okay this person's on call they get added to a slack Group which gives them the handle of on call they get added to a o to a um AWS Group which elevates their

access while they're on call um which you know I think is a is a a good way of automating um and and keeping our access as low as possible but having an automation that elevates it if needed um so these Downstream systems um AWS Slack are we using a bunch of like API Integrations with an Octor not really um we're just doing a lot of rule logic in Octa um and I think this is one of the things that I'm I'm really passionate about um there are vendors out there that promise hundreds of custom Integrations um and they're uh you know they they they do have a high value um I always think that you should try and do

what you can in your platform um because if you have to change vendor if you have to change to a different system the the rules will still exist and can be easily changed and modified you know there are vendors out there that that will do hundreds and thousands of different Integrations like when we looked at that vendor it was about the same cost as an engineer um and I don't think that we have an engineer working 38 hours a week on this um but your situation it may work but for us um the rule logic works really well um now it does rely on the downstream application being a very good SSO citizen um and I'll talk more about that later

um but if you have that and the rules provide all the access you need then you can go even further we do kind of more advanced rule logic um this is something that I've called exclusion groups exclusion groups um let you use the Octor rule logic to say if the person is a member of this group and also not a member of an exclusion group then you can grant access if they are exclusion group don't Grant access and we have situations where a user might be in an exclusion group because they're in a different country um they can't access the data outside of the us or if something happens and we have to limit access we

can build models out of those exclusion groups to reduce access without removing the person from from OCTA um so you can take rule logic and this is an OCTA but you know look at your IDP look at your system to see how far you can take rule logic because um you can go pretty far with it and obviously sort of Truth all of these items can be used in rule logic and that's how we get a Boolean that gives you know makes someone a manager and they get added to those groups and slack groups and things um be careful a bit of caution um I was cleaning up my own mess last week because um I was using a manager field

manager Fields can change a lot easier than like a depart we have like a really good process for departments if a manager leaves the company then you have to clean up that mess which is what I was doing last week um because it's a lot quicker for someone to leave the company than it is to change the department so a word of warning if you are using you know fields to automate be careful of using manager job title things that can change easy um because yeah you'll be cleaning up a mess like I did um employe life cycle uh this is one that you know I think that we're particularly proud of um and again this

is using um Octor builtin or additional um workflows um when I joined Ceda um I'm boarding used to be you know the responsibility of the it team a lot of manual work a lot of tickets granting access doing a lot of things uh to get people into systems um offboarding used to be a 40st step manual process um every time someone left the company that was a process that was prone to errors um you know it took a lot of time um we as a company need to be here for compliant so we had to solve this and um this is a very dense diagram um but I really want to kind of you know show what you can do and this

is in octa's workflow module um when it comes to offboarding someone um or onboarding somebody um just some very quick you know looks at the onboarding process um we are able to uh take consume a onboarding request from the hris so nobody is creating the account manually the HR does that when somebody starts uh in Octa workflows we start to um create uh we use some of the built-in modules to create a system of record um to start logging what applications that person has access to and then we even have custom API steps as well at the oning um so I had like one cool thing that one of my team implemented uh a couple weeks

back was a API call to purchase a Google license if we don't have any Google licenses buy the license for that person that's all automated and then evidence generation at the end because we are kind of responsible for being audited um the offboarding process 40 different offboarding steps have been kind of condensed into this um uh flow which again is um it is not responsible for off boarding somebody um we're not getting pinged and being like hey this person's leaving can you make sure to deactivate their account on this data this time we get an API call from our HR System and at the appropriate time they're off boarded um and then this executes um I think some really cool

things from this um which is uh you know never nice but there are some interesting things here um so after the Octor workflow step um we reach out to different systems depending on what makes sense so um octa's Logic for offboarding Google licenses isn't as good as another tool that we use called lumos which I'll go into in a second um uh so we make an API call to Lumas to do a more robust Google offboarding process you have to keep a license active for 30 days and then we have to remind people after that time I don't think we're quite perfect there but that's the that's the vision um and then we uh hit a system called retriever

if that person is remote um then we will hit a service called retriever which sends a box and un label to that person to send their um um item back and that saved hours of uh my team being in um uh my team being at FedEx sending boxes to people for send their machines back so um really really useful there um I'm sure if you can think of any other systems that you can make a custom API call to then you can extend like what it is your system does um final step of the process um delegated access management so this one of the things that I'm also really passionate about um you know who is

providing access to your systems so we've done the data we've got as much Birthright access as possible um we've done the automations where possible now you know not every tool is um something that someone should have access from day Zero so who is granting that access is it it are they equipped to do that like do they understand the level of access that they're granting do they have to run around and and get approvals and you know get that those kind of things or can we move that over to a uh delegated access management system um like a system like figma like you know our design team knows who needs access to figma I don't I have no idea designers I

guess um but they as owners of the system will know who needs access uh people can request access that can get approved by a manager and then that access is granted upon acceptance so no tickets being created um we use the to could lum um which is a pretty good Tool uh to do this um and I think that once we introduced Lumas for Access requests we dropped our it tickets by about 2,000 over the course of a year um which was huge for the team um so yeah um so that's like a really quick rundown of um our stack and you know where we've come to and some of the challenges we've gone through um

but yeah as I said I know change is hard um we had to you know get to this point it was a journey um and this wasn't intended to be a brag about you know oh how great we are or whatever um when I joined Ceda we had a uh kind of semi-automated system where um the HR System didn't integrate with anything um and the H the people team had to drop a Google like a CSV onto a Google Drive which would then be consumed by a Lambda and then fed into the Octor API um so um we didn't have delegated access management 40 step manual offboarding process so all of these things we've had

to um you know come AC get over to get to where we are today um and um yeah so I'm going to finish this out with some of the challenges the that I am very aware of um SSO probably hear from vendors yeah we do we do SSO it was actually mean to do SSO now this is a polite slide in my internal meetings it's a lot more swear and angry um but you know this is some of the problems you can have with what constitutes SSO like you have to have the Enterprise Plus+ super mega OMFG plan um or you have to um uh you know SSO tax um we do SLE login we don't do provisioning so

you know is your team buying a system where somebody's going to have to create individual users um you know we we do provisioning we don't do group sync so they're going to have to move them into groups manually um I've actually been on calls with vendors telling them how to implement SSO um and it's surprising how many don't um so um I understand that SSO can be a big problem especially if you're getting requests from teams to I want this tool I need this tool um so some tips really uh you know be involved with procurement um it's not the most interesting thing but you have to be in the step um to help the teams

understand you know why what they might want is going to cause problems um you know if they have a system that needs 400 people in it explain why they're going to have to have the Enterprise plan um or they're going to have to try another vendor um but also work with them and you know how many is it a critical system how critical is the data how many users does it have does it have five people and it's like not that critical then maybe the team can manage it themselves and I think that you know what we Sin from a lot of the alterations that we've done previously is that if we have to build a custom

feed then maybe we can is the implementation cost going to be worth it not sure but it's very you know building a Lambda that consumes an API that drops an SFTP file onto a onto a drive you know is is is possible um so you can you know get around it don't accept that you're going to have to go in and manually provision each user um I would you know hate for for us to have to do that um The Glorious world of HR systems I tried to find a you know the most modern HR System I could that is about right um but yeah as you said previously um I know the pain of struggling with bad HRS

systems um and that was really what got me involved with our people team to make the choice of Rippling and to understand you know if we had more capabilities we could help them even more um and before that we we had to make do and do this Lambda that you know consumed a CSV file dropped it onto Google drive it wasn't perfect but it did also kind of put the pain over to our people team which meant they were also invested in helping us uh get that done as well um and I think like as well changes you know it can also come from within um really proud of my team that are not accepting how things are you

want your teams to be lazy you want them to ask why am I doing this over and over again this makes no sense you know Empower your team to to not be helpless um and give them you know support to go beyond whatever can be done in the UI can they code something custom you know um I'm really proud that we've got a fantastic team that are growing into Engineers by asking these questions um and a lot of what you saw was actually executed by the team I'm just here taking the credit for it because I'm the MW um so we wouldn't be where we were without the team um and get the data you

know if you're spending let's say if you're spending X time at FedEx shipping boxes then if you're getting a system that does that automatically then you're going to save why amount of uh of of time um and yeah you know as I said from the beginning um I hope that you've taken something away from this today if you have I'll consider it a success um data driven automation gives you time resources and removes the burden of access from it um over to people that can make those decision s um look at the tools you have uh do you need the or singing or dancing 100 integration application management platform or can you do something with

what you've got with a simple API call um and uh how can you make more from the data that you already have if you do have a good linkage with a system can you use that data to make and to do more automation um so yeah thanks for letting me talk about this and uh showing up I really appreciate [Applause] it ready for some questions then yeah anyone have any questions all right thank you hi there um how do you handle a source of truth that is a little too malleable like people have too much access to change things or um doesn't tie directly into like spending or earning cuz I know you mentioned that

the start yeah I think this I I actually heard someone ask this question last night as well um when I was kind of pitching this are you like you're saying that your HR System is too malleable yes um I you know I think like that's tricky right and do I have a good answer for you other than to get involved with the team and explain why this is a problem and um you know if if that is something that you are using as a source of truth then it needs to be truthful right and not easily changed cuz um get involved with the team um if they are doing things like departmental changes get involved with putting a process

behind that so they inform you if they change that um because yeah you don't want them oh we'll just change the department and then everyone loses access um and I think we've done pretty well there but there's definitely work to do um yeah I wouldn't consider a sort of TR to be that malleable but apparently it's the case so

this is really good stuff great presentation you showed um towards the beginning of your presentation a flowchart where you had a mapping defined between a person that is on this team at this time right their on call needs to inherit this access by being in these groups right so I we kind of think of that as a mapping between who you are and what job you have and what permissions you inherit now I think the one that you showed was relatively simple right it had about three outputs but in a more complex Enterprise you might have 10 15 20 outputs right so how do you take care of managing those mappings if you know your OCTA crashed

and lost everything right or you got hit by a bus right like how do you reconstruct all of that stuff for somebody that's not involved in this process one one thing I didn't show during this presentation um was uh I've kind of and and I didn't show it because we haven't fully implemented it yet but the I've got a document about basically making namespaces so um there's a philosophy well yeah at least a philosophy of this is the type you know app colon application Name colon access level that's the kind of group that has access to the application and then you have an account collection that will drive that and then you have like exclusion groups ex colon Etc so um I

didn't put that into this presentation because uh I thought it' be a bit too students but um I have got a doc that I'm working on to try and show that in more uh and but I want my team to also implement it before I start to shout about how cool it is uh but yeah like a n basically I'm making like nay spaces with Octor

groups hey uh nice presentation um I think that you need to have a certain amount of maturity in the company for doing things like this what do you think about all the groups that are involved in this for because maybe it is has more maturity than HR or processes internally what do you think yeah I think like as well um I'd say it's like obviously our implementation isn't perfect there's definitely stuff that's in it like that's in Octa that needs to be cleaned up Tech debt um I think that we've kind of matured at the same rate as our people team and um if that isn't the case then you know I think that um work

to I know I keep saying it I know it sounds you know um rich but work with them to understand that like if you can get this right then all of this stuff that frustrates you we can automate it and I keep going back back to like email groups like we're not there we're not perfect on the email groups yet but they understand that like if we can get more data I can they're not going to have to add people into a Google group they're not going to have to automate that um offboarding they're not going to have to create a ticket for it to offboard people right they can handle that themselves they're not going to have to

try and find an IT person to do it um yeah I think like and maybe that maybe we're lucky with that that our people team have matured at kind of the same rate um but yeah I said like try and sell the what can happen if you get it right any other questions all

right so uh in my organization we're uh starting an exercise about relabeling our D data with you know the evolution of of pii laws um do you have any sort of like in systems or mappings in your um in this infrastructure to to sort of say okay this is something that needs you I think you mentioned needs to stay in the US or otherwise and and how did you go about that um think we go off standard Hippa um the systems it's basically I think standardized with HIPPA which is you know you know Green systems are do do not contain P you know Phi um yellow systems could be um and I'm looking Aaron red systems do have um uh Phi in

them and we do have to control access yeah this was uh one of the early things that we did from the security side and not the it side was try and simplify access down to red yellow green um uh maybe haven't explained it perfectly uh but um uh red is uh sensitive patient data yellow is sensitive data that is not patient data so this will be employee data financial data things like that and green is lunch menus I don't care if it's on the internet um your team you know obviously each company's different in terms of the access levels that they need to do but we focused on just that really simple like red yellow green Traffic Light thing to

start um and there are in fact rules in Octa named you know red us only red and so on and we can use the OCTA rules to map team constraints and application constraints to those um those labels thank you so the the kiss keep it simple silly any other questions oh

yes so I mean great perspective on datadriven access right and and one of the things that um we always speak to when we uh talk about access is entitlements um and the way entitlements feed into your entitlements repository and the way they Branch out into the systems there is always a delay component in right I mean so you know maybe your entitlements refresh happens overnight flows to down Downstream systems maybe the next day whatever right so how do you uh bridge the gap between the time you know an access is supposed to be revoked um you know till it gets to your entitlement repositories and those individual entitlements are truly reflected down right cuz to avoid

failure such as bad connections from somebody or you you know too many unauthentic unsuccessful attempts cuz Hey that service ID is still tied to that person and um you know your system of record and that causes trouble down the line so how what's your uh I mean is there I mean given the cloud approach I think it's more Cloud Centric but is there a Magic Bullet to to I think that goes back to the uh SSO being a good SSO citizen um and I don't think everything's perfect there so if all else fails we obviously do remove login by losing SSO and you can't log in without that um but if an application is a good SSO citizen Octor is really good

at essentially when that person's access is revoked it will fire Sim calls for every person that every application that person had access to which if your application is a good s associat is then it will remove that access um and I think that we we Al the security team have done a really good job um with lumos as a delegated access management platform which has a also a temporary amount of access time so we do just in time access for AWS access um elevation and that also does the same thing where because it's a good CZ and it removes the access um when that time is is is up but it's not perfect there are systems that people still exist in

but uh fortunately for the most important ones it does actually remove access any other questions I'm glad you left a decent amount of time for questions everyone wanted to know more so I want to thank you for your talk and um big round of applause everyone [Music]