Okay. I want to introduce you to, okay, man, from book income, he will talk about the importance of a centralized access management system, which is a bit of a different approach. And I'm really looking forward to your presentation. Raise your hands for Manuel.
Is this the one? Yeah. Okay. Thank you very much. So yeah, Manuel here, I'm head of, I am for booking.com. Just a quick word for me. As my background is software engineering within the identity and access management space. Then I moved into product management and I'm basically leading that organization for, I am@booking.com. And today I wanted to talk about access management in a decentralized, in a sorry, in a centralized manner, we were having a discussion before about identity management and the benefits of doing decentralized identity management. This, as you can imagine is a little bit of a different concept. There we go. So I would like to start by setting the landscape a little bit. So we're talking about corporate access management, how our employees will be accessing our corporate resources. And basically I think it's important to understand what we are trying to achieve here.
If you're familiar with the concept of list privilege is basically making sure that everything revolves around that concept. Therefore users, employees, they get access to what they're supposed to access, but more importantly, they don't get access to anything. They, they shouldn't be accessing as per their needs. And there are two ways to do this, right? So you have all your corporate applications. You could take the approach of say, well, each application, each service is going to be managing their own access. I'm going to have probably an access policy that specifies how that needs to be done, what list privilege means. And they're going to, you're going to delegate that technical constraint, that component into each individual application. It is one manner, which is one way to do it. I will be going into why I believe this is the better option in which you have a single access management solution that control access defines who can access what in all your different corporate resources.
So, first of all, let's look at the challenges of doing this. So the, the challenges of implementing such a system, there's definitely going to be a financial investment required. So moving from, Hey, every application owner, they can do their own thing. They can manage their own thing to, we're going to provide a service for that to be done centrally. And I'm talking about the service. I'm not talking about the ownership of it, so you can still have, and you should still have your application owners, your data owners, your resource owners, controlling access to their resources, to the resources that they own. But there is a benefit in doing that centrally. And that comes with a cost. Of course, there's also going to be technical and operational effort. So moving everything that you were doing, let's say access to, to your HR system, access to your active directory, whatever that is, moving that to a central solution that is going to have some technical and operational effort, effort attached.
But more importantly, it requires a change in the organizational mindset, a change in, well, no, don't just go ahead and, and manage access by yourself in your system. Like, you know, what's happening, you know, what should be happening? Let's do that centrally. That is going to require a cultural change. And we'll see why. So basically the challenge that I often see that we often face when presenting this, this, this option from the system owners themselves, the data owners themselves is going to be something like this. Listen, we already control our users access directly within our application. We, we don't know why we should change this right now and invest some effort in order to achieve this by using this solution that you are proposing. Why is that something that we should do? Why what's the benefit? In other words, we already know who should be having access.
I already know I'm the owner of my system. Why do I need to do that? And as an engineer, I think that question carries a lot of value. First of all, because, well, it's a, it's a well fundamental question. Second of all, because it forces me and my team to have an answer and try, okay, so why, why are we doing this? What's the benefit of it? And that's what I want to, to answer today. So the different reasons why I think we should be doing this, we should be moving to a centralized management solution first reason in order to apply strategic restrictions. And what we mean by this is we, I agree that resource owners know, should know, and definitely do know who should have access to the resources. The thing is they don't always know who should not have access to the resources.
So let's say I own some kind of good repository. And I say, well, every developer should be having access to this repository because it's required by for whatever reason for developer work at my company. But I don't know whether there is a, let's say competitive class because we bought another company or something like that that prevents a specific team of developers working a specific project to access that, that repo. And that happens all the time. All the time. It comes from strategic restrictions that I don't understand, or I, I don't have visibility on. And actually the thing is there are so many restrictions going around and a very small percentage of those are relevant for me, that it wouldn't be, it would, would be. It wouldn't make sense for me to try to be aware of all of them and implement the ones that are applicable to me.
And if we did that, now we need to go to all the re resource owners and make sure have you implemented this restriction, which is applicable to you and 17 others. So instead if you do that centrally, you can simply say, well, people in this team, they cannot access this type of resource and that trickles down access for, for all of the resources. And so basically what this means is that centralized access management solution, it's moving the policy decision point, the PDP to one single place. And, and that's about it. It's you let the access management solution do its thing while the application owners only needs to care about, do they have access or not reason? Number two, we've talked about strategic restrictions. Now we talk about segregation of duties, which is definitely not the same thing. Ation of duties, as you know, is preventing the same individual for performing, from performing two tasks in the same process from unifying those tasks in the same person. And this is not really about awareness. It's it is not about me as a resource owner, knowing that I have to implement, let's say knowing that whoever approved, created an invoice cannot approve it is about, does my system have information about who the creator of the invoice was or do, does my system only have information about who the approver is?
Not only about not only that it might be about who authored an action, a part of the process, or it might be simply about who has access to something, even if they didn't do something, but you cannot access a particular data and a particular feature in an application at the same time. So basically segregation of duties might be, might require knowing some information that is not locally available to your system. And for that reason, if that is moved into a central place where that decision is made, we enable that that possibility that yeah, otherwise might not even happen. So again, the application doesn't really care about why you have access or why you don't have access. It only really cares about weather. You should have access or not. So that reasoning, that whole applying that access policy might happen in a central place and simply produce the outcome to consume by the applications, reason, number three, while reusing existing permissions.
So a permission of the type can an employee view, the customer's email address is something that you might require in a large number of applications systems in your, in your corporate stack. You definitely wouldn't want to have it created multiple times, maintain multiple times, especially with contradicting criteria. So you have in one application, I can see it. I can see the, the employee's email address and the other application I cannot, is there a discrepancy in the criteria there? So yeah, with this, you keep it in one single place, this where we call authorization as a service. So we have that concept of who can view employee email address, for example, sorry, customer email address, and we could be consistent. Of course, it also means it. You have less management, less management overhead, so less effort to maintain because instead of having 17 permissions that do the same thing, you have one owned by the responsible person in the business, as opposed to, well, someone who is working for that application.
Right? And yeah, you avoiding consistency. If you think about not only the members, but information about, well, is this, is this relevant for Sox compliance reasons or for PII or GDPR PCI. If you have multiple permissions to do the same thing, you will find that in some cases we identified this as PII and some others we didn't, and therefore there are different controls being applied to obtaining access to those permissions. Reason. Number three, well, you have a single pane of glass for who has access to what in your organization right now. If, if you have that distributed decentralized, it basically means if you need to answer the question who has access to something, you're going to have to go to different research owners, application owners and ask them for a who can do this in your system, or what can, what can this person do and collective information, reconcile it and, and present that when you have that access information properly formatted and stored and, and available, it becomes an Infor an asset for the organization. Cuz when my legal team comes to me, when my risk and control comes to me and ask that question, I can not only produce it, but leverage it in order to, to achieve some result. So if we are having an attack in the cybersecurity space, okay, so anyone who has access to X block it or anyone in, in, I don't know, in this particular region of the world, which at the moment is under attack, prevent access to these particular system, these type of things.
And yeah, these queries might be for multiple purposes, security compliance, legal, but in the end they come. And what I see is if you have this centralized, it is a simple query, simple answer. If you are not, it becomes a whole project of talking to a lot of people, gather a lot of information and again, reconciling and, and providing that as an output. So it reduces that effort to produce these answers that you can leverage. And of course, once you have that in a single place, when you have, once you have a single pan of glass to determine who has access to what now you can start to monitor and detect deviations from, from what you consider to be the good, what, what good looks like right. Otherwise? Well, I mean I have 150 systems that control access on their own way. Yeah. It's monitoring.
What good looks like basically is, is about obtaining reports from, from people and processing that information a little bit non actionable reason. Number five, well implementing consistent governance in the sense that now you need to build controls to make sure that you stick to what the good looks like, right? So you have your emergency access, you have your re-certification reconciliation, you have all those type of things. If you have one single access management solution, there are controls you're going to build only once. Otherwise you, you have to build them more than once more importantly, you need to perform them and maintain them more than once. So in the case of, for example, re-certification policy reviews. If I'm an owner of multiple systems and they are, they control access independently. Now I have to perform two different controls, two different intervals, different process. But if they are centralized in the same access management solution, I do that consistently and once, right?
And now it's again, when you can avoid deviating from your defined controls. So I have my controls that need to be performed every three months. If everything is in the same system, it's easier to detect if people are starting to do them every five months than if I have that distributed, decentralized over 150 different systems. And again, you can now monitor centrally. If, if things are going according to plan, if your controls are effective, if you are actually mitigating risk or not reason, number six, well improving the user experience now. Yeah. If, if you have one single access management solution and you have your, your, your employees being your users, they basically have to go to one single place to request access, to monitor their access, to perform whatever controls they have, as opposed to going to multiple places. And one of the things you don't wanna do when you are doing access management and I am in general is piece of your users because if you do things will start being ineffective really quickly because yeah, no, a lot of people don't care about what we are doing here.
They don't care about security and you need to get them to care. And one very important way to do that is make it easier for them to do what is relevant and remove waste, remove noise, noise, as much as possible. And by doing this, you basically don't put your practices at risk and you make sure that the controls you define the process, you define procedures, you define, they have less waste and, and they, and that basically translate into less inappropriate access because people will request where they have to and also will manage their permissions in the way they have to. So yeah, those are the reasons that, that I wanted to bring up now about how to build this, this tool, which is definitely out of the scope of this topic. It is definitely not going to be an easy thing to do, but I definitely think that the benefits presented here are the risks presented here that you want to avoid outweigh the cost, cost and effort in most of the cases, unless you have an organization that basically has three or four corporate systems, right? In, in, in the cases I've seen, we're talking about more north of a thousand different systems, but in, in any case, what you're trying to do is you're trying to transfer the access specific concerns of applications and solutions and services to a central PDP. So a central policy decision point and let, basically let the consuming system, the applications worry only about their actual purpose. So, and, and, and put that on, on the management solution, the, who can do what and yeah, that was it for me. So thank you very much.
