Alex Olivier: Beyond Code: Shaping Security in a Developer-Driven World

This talk discusses shaping security in a developer-driven world, emphasizing the importance of collaboration between developers and security teams to create robust authorization systems. The speaker, Alex Oliver, outlines his experience with designing enterprise solutions at various tech companies, including the challenges around implementing security practices as the scale of operations grows. He explains different layers of security, starting from infrastructure and networking to application-level security, and the crucial differences between authentication and authorization. The session introduces the concept of using a centralized authorization service to allow business teams to drive security policies without burdening developers with constant code changes. The aim is to create a more agile system that meets ever-evolving security demands while maintaining operational efficiency.

[Music] hi guys the hall four uh security award I'm introducing you and I'm your host Lucas nooski introducing the Alex Oliver co-founder uh and the CPO of caros and caros what uh what they are doing and he has designed Enterprise solution for the ground up serving various rols including engineer cons colant Tech lead and product manager always with a focus on optimizing and developer experience three career

Microsoft Cubit and numerous startups he designed platforms enable teams to accelerate their operation at scale and emphasing core components such as authorization data management and security and today Alex will tell you about beyond the code shaping security and developer driven World hi Alex welcome hello how you doing you can start show everybody your presentation I will enabl it on the screen now and good luck see you

thank you great thanks I guess hi everyone good morning afternoon evening wherever in the world you are based um yes so today we're going be talking about shaping Security in the developer driven World um so as you heard uh I am a leier I'm the chief product officer and co-founder of cbos which is an open source project around authorization but my career really has been as an

engineer and LLY into more the product side of it uh started out of Microsoft as a technical consultant and then worked in SAS businesses for the last 10 years across various different Industries and verticals MCH supply chain Fitness those sort of things um but always very much focused on the data devops and security side of things um one of the problems I had to keep solving is

around this authorization problem which we'll go into more detail on um but the common theme here is that we were trying to set up security practices in a way that both developers and uh product and and business teams can work together to make sure the systems are secure and can scale and grow with the business as the requirements as they change so when we talk about security

when I think about security um we're talking about different levels so at the base you have your infrastructure so you're running on Google Cloud Amazon web services uh you might be an aure you might be on Prem you have your based infrastructure your raw Compu they're sitting in a data center somewhere be your own or or in the cloud somewhere um and that you have like the

physical security at the infrastructure level next up I always start thinking about like the network layer so how are those machines connected together and uh inside of the cloud environments now you get things like vpcs security groups and those kind of Concepts to kind of lock down um who can access who can access the particular Network range or who can talk to the individual computer units Etc

nowadays you then have this kind of deployment layer which is kind of sort of a quasy deployment network type uh so thing so if you look at kubernetes for example you have all the the um cluster defined networking uh cni so Calico and all those kind of Technologies which provide another layer of security to lock down into container into inter pod or inter node communication at kind

of the deployment of the cluster level and similar sort of Concepts exist with some of the serverless platforms as well and now you're getting a bit further up to kind of more of the application layer so you got your infrastructure you got your network down you've got your deployment environment set up uh and what typically you then do is put some sort of API Gateway in place

so sto Kong there many others out there and these act as the kind of external uh line of defense for requests coming into your infrastructure into your deployment mechanism and that's going to be authorizing requests so for example making sure they're authenticated make sure they got valid token makeing sure they're uh doing routing based on path and those sort of things um sort of Defending at the

Gateway or at the edge location um access to to your services behind the scenes and then you have your application there and tradition if we kind of look at who owns these they developers with different sorts of names so your infrastructure your network your deployment so of kuties cluster type management traditionally might be a DeVos team or an infr team you know if you're an indie hacker

it might be yourself um if you use one of the more managed Services say um one of the serverless platforms out there these are being managed by someone else for you but ultimately these teams are existing there's Engineers setting up and managing deployments underneath and then when you come to the higher up level so the Gateway and your application layer this is where you now have the

dedicated application teams um so now you've gone away from base infrastructure and you might have uh feature teams or product teams or solution teams or depends how you're structured basically these are the teams that are building out uh application uh layer of of your stack and there's a security aspects that need to come in to layer if we look at that top SL kind of the application

Level security this is where I've spent kind of a lot of my time in career focusing um there's the 3A the AAA um things you need to think of when it comes to security so there's authentication authorization and audit so authentication is kind of a sole problem these days um you've all probably heard of things like o 2 you've heard of open ID connect you've heard of

uh these various authentication Solutions be it open source selfhosted things like uh keycloak there's the commercial Solutions like octo zero Cognito um you've got solution like super tokens now zadel Etc um which kind of have solved this authentication layer but when it comes to security there's the other two ones which are sometimes overlooked and I've certainly overlooked them in the past which is around authorization and audit

and this is what we're really going to focus on today now one thing to really think about when we look at s Beyond code how you sort of bring dat developer driven security into your stack is where are those requirements coming from because at this point it's less about feature cap abilities inside of your application or how a particular API endpoint works or how you're sending data

off to your shiny new llm um it's more about actually the business requirements so authorization and the audit log of those decisions that are made the requirements now are not really coming from a developer or or the product team they're more going to be likely external factors you're looking at security teams customer teams you know end users internal uh customer support teams that need to be able

to uh view things like like access controls permissions audit logs and those kind of things and this is where the ownership of security kind of gets a bit blurry and we're going to use authorization as an example of this just because that's where I spend a lot of my time on with seros um and we're going to drill into that so just to be sure I've mentioned

authentication and authorization a couple of times now and the key thing uh just to make sure we're on the same page is unfortunately these are two terms which get truncated down to or n and or Z quite a lot and which is quite annoying because there are two fundamentally different different uh things and different parts of your application architecture you need to worry about so authentication with

that n is about a user being prompted to provide a credential a username password or log in with some sort of third party identity provider and the application you get back an identity so I go to a service I log in say with my Google account my GitHub account or type in a username password there's a there's a component out there that's now verifying that credential and

now that authent authorization sorry authentication so even I get it wrong authentication layer gives you back a verified identity so okay this person is who they say they are they presented their credential to a challenge they given them that person is definitely who they are here's their name here's email address here's the user ID here's what roles they have and those sort of things authorization is the

Second Step so once you know who someone is what can they actually do inside of your system so or Z or saided part of the world you're in um authorization is about understanding okay this G's identity they're trying to do this particular action inside of our system are they authorized to do it should they be able outow to do this particular action inside of the system and

this is one of the ones where that overlap between developer and product or security teams comes really really key because as a developer you're really focusing about making sure your API systems and your architecture works as it should so you're driving that from a code perspective and then you have business teams uh or business-minded folk who are really defining okay here are the access model models that

you should have here are the roles here are the groups here the permissions here the how they roll up into higher level permissions here's our audit requirements because we're going through sock two ISO those sort of things and you end up with this kind of mismatch and how do you kind of join those two two together and meet in the middle to make sure that develop as

developers you can be uh very agile and kind of move very quick with your stack and as as business side of teams makeing sure that your requirements both you know business and also legal are met so to kind of demonstrate kind of what the story is and sort of how and when developers uh overlap those teams and how developers can really drive this in a way that's

scalable we're going to go and uh build and scale a company so you I'm sure many are familiar with this this uh phrase in this world nothing is certain but death and taxes uh when it comes to authorization and everchanging authorization requirements says every product person ever uh in my experience I've had to build these systems dozens of times in previous companies every time it took at

least three months to do right and then in multiple cases after six months we had to re build the thing again because the requirements changed and this is where that developer driven experience uh needs to align with basically what the business requirements are and how you can scale and grow so let's going to do that let's going to scale a company and hopefully this will resonate with

some of you you might be in an early stage you might be in a later stage around uh where some of the pains are and really how that then ties back to how you as a product team or development team can really set up uh your systems and your architecture for success in a way that is very develop but works tandem with those requirements so the first

stage is what I kind of call the Blissful days of roles so you're very early on you're just getting set up in kind of an MVP and you want to have this concept of either an admin or a user inside of your system so if we go and look at some application code you imagine somewhere in your codebase you got some API route coming in you've gone

off to your authentication provider you've got that user's identity so you have for example the user's email address available inside of your application code now inside your application code at the point where you want to work out what's going on or whether you action should be allowed or not you might go and put a very simple if statement if the user email address includes the company domain

in the email address then they're an admin they should be able to go do everything great amazing very simple to do it's a oneliner pretty much um and you can lock down access that way uh if you didn't want to necessarily hardcode this you may want to go maybe look at using a scope inside of an O token or JWT uh to work out uh what if

someone has like an admin scope um but this logic is pretty core scen you're not going to um do very fine growing stuff with this but it will get you by you know you're proving your value you're you're testing out the waters you got an MVP stood up uh and you've kind of met the business requirements of I want be able to differentiate between internal user admins

and everyone else um and as developer you can put code in stage two so you've got that first version you're now scaling up a bit you've maybe got uh a point where you've got a viable predor you're selling it you actually might have the first couple of sales team members out there uh and you now reach the point where you start worrying about pricing and packaging and

so you might have some feature sets that you want to divvy up into a good better best type type uh packaging model um and what that invariably means is those packages are going to change so you want to be able to basically slice and dice and change the configuration uh of what packages people are on or what features they get so to implement packaging you might go

and extend that if statement inside of your codebase where you say if the user's email includes my company um or the comp or the users's company uh that they they're logged on or subscription has a package of Premium associated with it then they get access to use their premium capability now there are solutions for this you might go look at something like a feature flag tool that

supports user traits so your whole Opa feature ecosystem in cncf or launch darkley or or flagsm myth um type solutions kind of give you some of this uh flexibility and um but your code is now getting a bit more of added more logic to to your code base so this still very much developer driven because you as a Dev team are going to get a ticket that

says oh go and add this logic in go go and put this code in um then the requirements might change you might have a new package called premium plus you're now going to have to update all these checks in your in your codebase uh and you know your security model is going to be variable based upon those requirements another fun one is kind of the next stage

so great you've maybe proved your value you're selling your first product in Europe let's say uh and you want to start scaling out to other regions so this is firstand experience I was um heading a product for a m platform um heading up kind of the data side of of that system um and this is about about eight years ago now uh when the Safe Harbor agreement

fell through between the Europe and the US so the safe far agreement was a data sharing agreement between the European and US governments which basically set set into place some security best practices and and regulation requirements around how data is managed and what that ultimately meant though is as a technology business processing data uh on behalf of our clients and thus their their end users was that

we could store data either in the US or in Europe uh without kind of any issue now I'm sure many of you are aware of gdpr and all that world that changed once that agreement fell through and what we then had to do is actually go bate our entire data stack so we had literally had to go into our systems work out whose data was for European

clients who was for us clients split those two up and and keep them in their respective geographies so we're running data centers in Europe Europe and in the US um and that is the underline data store but we also needed to impart or apply that authorization logic to the application layer so going back into our application code we then had to go and extend these if statements

further where we're now checking what region the user belongs to and then working out which region to go and fetch that data from and making sure that someone in the US couldn't access someone in Europe's data or vice versa um so every single time we fetching data from our data store which was pretty much every request U and we were handling about 20 billion requests a day

at this point uh we had to do these checks in here to make sure things things are secure and locked and following the regulations and you know we could have gone down and looked at things like o Scopes again or maybe used a a language specific Library like castle in the node ecosystem or can can Canan in the Ruby ecosystem um but we're now having to again

drive this kind of developer driven definition of authorization inside of our codebase so the next stage we kind of matured once again and we kind of got a viable system we've done our proper work to split things up between different regions and environments um and now we want to start selling to kind of bigger businesses we're getting our first like Enterprise sales deals in where you get

the big numbers uh and and with that comes a whole L of requirements so through one of my previous companies we were working with one of the giant Airlines in the Middle East and working with one of the largest office supply retailers in the US at the same time and we had a very kind of small platform we had some basic roles in it and we signed

these agreements with them to use our system they came on board and we're like right we have between us 100,000 employees uh us system only has three user roles in it we can't shoot horn for three 100,000 employees into those three group three user roles we need much more fine grain checks and permissions so we're like ah okay well this is going to be a block on

a deal we need to make sure we get this done so it's back to the cbase back to developers kind of drive a solution for this and so now you start to add in concept like user groups so now our authorization checks of things like does the email address include a company domain is the user on a particular package and uh what group is that user belonged

to and then kind of granting permissions based upon that grouping and then still doing the further checks around data access uh location regionality those sort of and this gets a bit messy now because you now have like in a number of groups you now need to make sure you properly checking what group someone belong to uh you may at this point be looking at like directory systems

so ldap act directory these kind of tools um to set up users groups and uh hierarchies lots of the identity providers do this as well now um and then you have to like pull in those groups and put some custom logic in here and all gets kind of again a bit messy and and you now have the business side of things pushing these requirements on the developers

when really it's the business security requirements that are driving this not developers wanted to go and code this up next stage you go to so you got through that you've set up these groups and now you're getting these larger larger deals um and you are getting all these security questionnaires and um SEC security questionnaires are things that do exist if you haven't seen one yet consider yourself

lucky for now but as you grow and as you scale and as you start building software or building products that are used by these larger businesses you will start getting these 5 10 15 30 100 page long security questionnaires uh from um your your perspective clients who are asking things like how you store data where you store data what are the access controls in place how do

you ensure that employee laptops are locked down you know these kind of things are are very common in these sort of security rfps or questionnaires that you'll receive and one of the ways to kind of mitigate or or kind of bypass I guess a big chunk of those questions is actually you as a business go out and get get um certifications so you might have a Chief

Information Security office at this point Who's start whose you job is to come in and make sure that you have things like ISO 27,000 one or sock two compliance if you're in payments maybe you'll need things like PCI compliance and the stage at when you do these will very much vary depending on your industry if you're in he heavy regulated Industries like healthcare you have to do

Hippa if you're in pay anything to with finance and payments you have to do PCI um uh if you're doing personal data processing you going have to make sure you at least minimum eing some of the specs around that um and then you go through these processes you you go and get audited and then you kind of go through an observation period and then you at the

end of it get a nice shiny certificate that says you are ISO compliant or so compliant or Hipp compliant Etc and what this basically means is you get to then go back to your prospects and say hey we already so to compliant and that basically eliminates the load of the questions um but in order to get these certificates uh and compliance regulatory kind of things in place

there's a load of requirements that come from an access control and security perspective and one of those is around audit blocks so now your diligent Dev team you've got that ticket coming in from this point your security team saying we must have strong audit logs in place so now every time you go and Implement your uh logic authorization checks and your application code you're going to have

to do all the checks you're doing before and then whenever a decision is made you're going to have to go and generate an audit log entry so this access was granted to this data in this region by this particular user and you're going to have to basically instrument your code every time these checks are done H and this is a real thing like every year I was

the one that got uh HED down to a conference room by an auditor and I had to demonstrate our access controls that we had in place inside of our system and you know early on this was quite tricky because we didn't really have these strong controls set up um and I was just sitting there trying to like GP through access logs that we had stored in an

S3 bucket to try to show that we were denying requests with identities and such and all got kind of a bit messy and uh you know there are certainly logging libraries that will help you with this there are dedicated audit log Solutions out there like boxy HQ uh which you can plug in and do this also but again it's these kind of security requirements um that are

coming in and really are impacting you as development teams and efficient themes to go and do things now one requirements that comes in isn't that doesn't necessarily come from the business side of things or or the scre of things is when you reach a point in your architecture where the topic of micros Services comes up and when this occurs again is going to vary based upon uh

when and uh what kind of system your building and kind of maturity inside of your architecture and such uh but this question will invariably come up and it may not be because you want to go to market servers but it may be because actually you maybe have a legacy application that you're modernizing and your your modern stack is going to be built a new text stack but

the two need to integrate uh they need to coexist so you might have like a a Dot N Java component you might have a go or rust or no typescript type component as well and now you're going to have to run these two services but they need to talk together so what that really means coming back to kind of this authorization problem is all that logic we

had encoded into our application before around checking users roles checking what groups they're in checking the email address checking what region they belong to creating order logs Etc all that logic now needs to be replicated into each of those Services each of those components in your stack so that logic would probably needs to be implemented in say your legacy Java component your modern go um Services you

might have because it's 2024 you might have some AI llm thing running in Python somewhere and this logic may need to implement it in that as well and that might be a one-off job but going back to the original prose that the security requirements will always change is when those requirements do change because you want to change a group you want to add a new region you

want to create a new package name you want to check a different email domain let's say you're going to have to go and replicate this logic across every code base that you have in each of the languages and every time you have to translate business requirements into code there's going to be a chance of error and CH there's a risk of things potentially going wrong or not

being implemented or not being uniformity in terms of things how logs are created Etc and there isn't really a solution to this if you just look at it kind of uh in terms of coding this into the application because every language every framework every library is going to be specific to that particular environment so there is kind of a new approach here and this is very much

a developer driven but business enabled or or basically enabling your business is to drive the security over your entire stack um to give this much more fine gr level of authorization so the bill vers bu dilemma or kind of everything as a service as we seem to be in this world now um going back to the original Point around like something that are solved so infrastructure is

a solv problem now are you going to use provider your network layer is again security of it is kind of solved by the uh by the hyperscalers you then have your deployment system so cetes is kind of a go-to now inside of that you have your um your kues defined Network layer which can add things um around access controls you then have your overlay networks or or

gateways that do things like with stto or gong um doing request or application kind of level authorization and then in the application layer um you have security kind of in place there that we can be through now authentication as I said the beginning is a bit of a s problem um you can now go out there very easily and go and pick off an authentication provider or

Z from prob I'm probably most familiar with but there's many kind of solutions out there um but what that really isn't up until now is kind of one for the authorization piece which is kind of that next level up uh from it authorization so if we were to kind imagine kind of how would we build this in a way that developers are involved but they don't necess

have to configure the authorization spec we can kind of imagine this little authorization Services service to bring security into the stack and if you imagine what this kind of blackbox would do the requests would come in saying I've got this user this identity trying to do this particular action on this particular resource so I'm Alex I'm trying to edit an expense inside of my system let's say

so that's the request that comes in the logic behind whether that request should be allowed or not is going to be defined by other parts of the business is can be defined by the product team the customer team the security teams the external Auditors in some case your kind of regulatory requirements and really that is policy this is going to Define okay under these conditions these action

should be allowed by these particular user groups or roles or or particular attributes um and that should be defined centrally statically and something that everything everyone can understand and that is kind of consumed by this authorizing service and what comes out the other side is an allow or deny decision Aly your application layer needs to know can this particular API call with this this particular context this

particular user do this particular action should that be allowed or not what really should come back from the authorization service is the Boolean allowed deny and that the logic behind that allow deny comes from this policy based approach so when we look at it from relationship between a developer and a security team a developer is defining the request to the service the policy that defines the decisions

being driven by the business side or business requirements and the output is a simple Boolean so if we can what this really means if we take what before was that big IFL style statement and convert it to policy what we want to do is create a static asset a versionable asset something that's a bit more human readable so you don't need to go need to know Java

or go or JavaScript or python or whatever you're using your stack um in this in the case of uh this we're looking at like a yaml file this is an example of seros is authorization policy seros is the open source project um gith help.com you want to have a look at it now but there'll be Links at the end but this is a policy so it's a

a static configuration based approach it defines the different resource types of my system it defines all the different action types that can be done against it and under which conditions and those conditions can be very simple has this user got a role which is a traditional role based Access Control check or it can be more fering attributes so looking at individual attributes about the person making the

request or the resource that they're trying to access to make a decision so here we can say this create action yeah this create action should only be allowed if the user has the role of user and the expression this condition is met and we're saying that the department attribute of the user making the request must be equal to sales um and this is where we're taking those

business requirements and mapping it into something that isn't application code you know is a DSL of some sort but it's a bit more human readable manageable for the business side of things rather than having to dive in understanding the actual application code inside of your services or inside your get repos so in terms of a deployment model again Ty this back to how we can be really

developer first and develop TR about this from architecture we're now in the world of I mentioned a few times kubernetes uh and this concept of scars has been around for a while so a scar is a container that runs alongside your application so you would take your application service and you would essentially connect to it as a c car running inside of the same pod in communities

terminology um an instance of this authorization service so we look at the systems that exist today you can get things like o proxies that run SC car that basically control access into your contain into your your service that runs in the same pod um things like logging and metrics collection can happen at SC cars as well we're looking at Ingress proxies as well and one of the

use the most useful characteristics for this is scars it coexists with your instances and then as your your cluster will scale up um so will the number of instances of your service as well as the authorization service in this case which is a very useful pattern because what this L be now means is we can have this component in our stack which is this authorization service which

is always running right alongside your application so we're not having to go and do these authorization checks to some external Services running on a different node or even worst case over the internet somewhere it it's always going to be collocated and running right alongside application so in practice what does this actually look like again tying this back to developers and security we're looking at like the the

life cycle of a request for an end user so an end user to application request comes in then request is coming into your infrastructure inside your infrastructure you have your services deployed so imagine this application block here as your comm's cluster inside of it you have instances of your microservices running um and each of those services at some point will handle a request based on the where

the Ingress Gateway sends that particular request so request comes in and basically in that request you know two things firstly you know who's making the request because there's going to be something that identifies the user in most cases so you might have a wwt um you might have a session cookie you might have some sort of other token associated with the request and you can go after

to your identity provider to verify that token and fetch back any kind of roles or attributes by the particular user making the request or they could even be in the token directly and the second thing you know based on the request is what resource they're trying to access so this is a get a request for the expenses endpoint and that URL has an ID in it you

can go off to the underlying data sources your own database or some third party API and go and fetch out um that data from that particular data source so now in your application you now know who the user is their roles their their teams groups those sort of things you also know the particular resource it ID it attributes that they're trying to make press to and then

traditionally going back to all the if statements we showed earlier this is when you then have that if star logic if else case switch star logic hardcoded which is inspecting the attributes by the principal or the user making the request and and go and compare it to the values about the resource they're trying to access and come up with this loud deny decision so so in that

case your authorization log will be hardcoded in here but in this case we're going to extract that out into this authorization service that would been kind of um hypothesizing about so now when the request comes in you know the user you know the resource trying to do some action rather than hardcoding all that logic you would use an API or use an S SDK to make a

call out to that authorizing service and you send to it I have this principle so is a user but equally could be a service account or an API key or something there this ID they have the attributes they're in this team this group this office this IP those sort of things they're trying to access a particular resource so they're trying to edit a expense resource with these

ID attributes Etc and the particular actions they're trying to do create read update delete approve deny comment flag whatever they are so that request goes over to that authorizing service that authorizing service has loaded into those policies so those policies uh if we take seros again source project I'm not trying to sell you anything as an implementation of exactly this um that that um Sero service that

you're run on side of it connects out to a policy store so those policies could be in a GitHub repo when you get repo they could be just on dis or built into the Container or up on S3 or GCS um they can be sold on database but that authorization service has those policies led into it so inside of that instance it will take that request about

principal resource action it will go off to the policy policy store that it's got loaded in it will pick out which IES it needs to evaluate so this is a request for an expense resource it will start going through and evaluate those policies uh this particular request is for an expense they're trying to do the edit action it will then go and evaluate all the conditions and

work out whether the action should be allowed or not and what comes up with that Boolean allowed deny answer now before it returns request what it can do is make a audit log so that instance should then go and output an audit log at this time this principal tried to do this action on this resource it was either allowed or denied by this particular policy that decision

can be outputed to your existing loging infrastructure send off to a Sim you whatever you're using for Incident Management tracking those sort of things uh and then what goes back to the application is just that allow or deny um or a conditional in some use cases which I w't go into now so in your application code all that authorization logic that we were building up previously is

now a single if statement if the authorization service says allow do the action if not return some sort of error so what this now means is a developer is you've gone and implemented the API calls or the SDK once inside of your system so you've got out you you've written your handlers to go and fetch the identity from your identity provider youve you know how to go

and fetch the state about your data that they're trying to uh in your data store that they're trying to access you package up all that information and just send it to the authorization service what comes back is a Boolean so now in your implementation it's a single if statement if the authorization server says true then allow the request if not return a forward to Etc so what

this now means is when those requirements change on authorization and the security requirements change you as a developer don't have to touch the application code again all that needs to change is those policies that sit over in that policy repository so either you as a developer team the product team the security team the customer team whatever could be updating that authorization rules in that Central store and

all your authorization services will update whenever there's a change but your application implementation does not change tool so what we're really doing is sharing that responsibility developers focus on implementing the checks the business side of things is focus on implementing the business logic and thus we are coming to this world where teams can work harmoniously together to really Implement best security practices inside of the stack the

side so that that change happens kind of asynchronous asynchronously plus you get this nice ordered log because every decision is going through an authorization service instance and each one of those instances will generate an order log exactly what happened so you get this nice clean architecture so before we had these bigl statements after it's now that single if statement to really go and check what is going

on so what's the advantages or challenges of kind of this approach so logic is defined centrally again is kind of offloading it for developers so we work work on different things policiy can evolve independently of code it's going to agnostic to any language or framework or architecture so your legacy systems can call this authorization service because it's just a request in the day your new components um

Can can do this also uh it lends itself to a very nice GitHub story as well so those policy files are static assets you can check them into a git repo uh with the seros open source project we even provide um CI tooling so you can actually write tests against your policies uh independently uh and then have those as part of your CI plus you get that

consistent audit Trail because all the decisions are being done by the centralized service you're always going to have that clean assistant at this time this user tried to do this action this resource was allowed or I but just pick a policy without any issue challenges are you know there is another servers to run so hopefully you've seen kind of this stateless decoupled approach means it can run

as as a side car you don't really have to think about scaling it um there's a new DSL you potentially going have to learn but depending on what tool you use it could be quite obvious even to non-technical people how the logic works and obviously there is now a new component in your critical path but hopefully the advantages kind of outweigh some of that risk uh for

you as well so tying it back uh to our security every level infrastructure is handled by your hyperscaler or your in-house data centers your network level is now handled by um those platforms those Services as well your your deployment model handles things like inter network uh intercluster inter node networking your gateway will handle that sort of Frontline request sdo Kong Etc and at the application Level layer

you really now move to a world where before it was purely developers but now you can actually start bringing in the security business teams to those top level authorization pieces so security every level really is collaborative approach between development and the business side of things and and one of the one of really should be thinking about when you're architecting systems how can you enable the right team

to WR work at the right level of security across your stack so mention seros a few times um I work on seros as the company um but at the core it's an open source project uh if you want to find out more about that you can go to C.D is the website or github.com seros we have a very active slack community so if you join that and

ping me a message on there I'll make sure we send you some swag we got some cool t-shirts and plushies and things uh that that we can send out uh and we've got users across all sorts of vertical in Industry that are solving this problem and really making sure their development and security teams are working together uh to build a much more secure system from the ground

up inside of their architectures and that is my talk oh hello hi ah there we go hey thank you yeah it was it was too much security I think on my microphone but of course now everybody will know what doesn't mean the authorization and education for sure and uh how you manage authorization plans for every team member and uh before the question will appear then I will

only want to ask about the management of every um every rule of authorization in your application there is an uh a backend tool for better understanding on mostly mostly using the Y file yeah absolutely so our view was authorization should be a solved problem for developers so the core of everything I showed you this yaml everything like that is part of the open source project a patent

you two licensed go and grab it and run with it you never need to speak to us um but we appreciate that there are teams that need to have much more of a managed workflow and we have seros Hub which you can find out more about seros dodev which is a whole management control plane it's a commercial product that sits on top of the open source core

and that gives you a full management IDE environment it's a cicd platform it does um authorization at the edge or on devices for our embedded version um and also launching soon as the ability to bring all your audit logs together into single pane of glass so it's a tool really for um both product teams but also the products and security teams and S of a business they

have a single place to work together on their authorization logic all right and uh how is your feeling how the how the secure team and developers working with together using so the best bit of feedback I think I've ever had working this project is from a chief information security officer for a large utility business um who said for the first time he actually understood without having to

ask a developer how the authorization logic Works uh before that that relationship was very One Way one-sided but now we are seeing those team working together and again all about letting developers do what they're good at which is like implementing building and architecting systems and then offloading the business requirements to the relevant team inside of a business so we have hundreds not thousands of users of the

open source project now H and then we have the commercial product on top so what H um to help those teams work in a collaborative ID environment yeah this is this is the next level of of authorization I think and understanding because sometimes the security May to only say that everything is working and developer say mostly mostly in in a specific way on my computer as well

yes indeed very much EX yeah this is this is that was quite nice and thank you very much maybe uh still waiting for a few questions if any appear if not you can always contact directly to Alex right and uh and everything should be um yeah should be clear and if somebody somebody want to ask feel free to contact him and that's it and there is the

open source project if you say um if you said and everybody may even join to the slack channel right slack chat and drop grab the T-shirt or uh or the small small thing from the company absolutely but but uh that was the really really nice speech thank you very much and uh I'm I'm really appreciated you joining us and see you next time and I'm welcome everybody

to the next session and secure the work byebye thank you much have a day for