The Future of IAM & Cybersecurity is Policy-Based

And I'll talk about the future of identity and cybersecurity is policy based, and I think a bit of different approach this morning, which is whiteboard, so to speak. So, so when I, when I started thinking about topics than I very frequently use a whiteboard. So sometimes on paper, sometimes I use the whiteboard app.

And so I, I wanna walk a bit through, through my, my thinking on, on a whiteboard about policies and why I believe they are important and how to make them work, et cetera. So it looks a bit like PowerPoint, but you'll see PowerPoint is the, the minor part of what is about to come in the next minute. So we had a lot of talk about policies. We had a lot of, lot of talk about authorization and authorization, really, yes, there's a lot of talk about tasks, et cetera.

But I think when we go a bit more towards the future than authorization is the hot topic finally, or again, we had it a couple of years ago and in that space, but beyond that, policies play a very, very important role. And the, the nice thing with policies is they have a standard structure that is very simple to understand. So this is about the subject action object and maybe constrained or, or, or context.

And yes, the constraint, the context that could be complex, that allows in some way also for nesting, saying, okay, this relates to another policy. Policies can have these relationships where you say, okay, one policy or a chain of policies are required to, to in fact allow something. So take Martin, I, I took the slim version by the way of Martin here. As you can see, yeah, there might be a policy that controls the access to a building. There might be a policy that controls the access to computer. There might be a firewall policy and so on.

So many, many more and more complex relationships. But policies, and I think this is something which already becomes clear here, policies are something that is ubiquitous to identity through cybersecurity and well beyond. It's something we find in our daily life, a lot, a lot of things we express as a policy trialed better, don't touch the hot oven, subject, action, object, et cetera. So it's something everyone understands, and as I've said, they are widely used, they're ubiquitous.

So when we look at these ubiquitous policies, then we have firewall policies, you know, we have authentication policies. So when you look at the typical access management solution that we are using policies for decades, we not necessarily name just policies, but at the end it is, we have s o d policies, we have policies and birthright provisioning, we have whatever the building access. So physical building access policies.

Yeah, we have some cybersecurity policies, but not always. We use policies as widely as we can. So maybe it's not the very best example yet. Authorization, yeah, exec was policy based, but unfortunately it was XML based as well. So in that combination, it didn't succeed as as expected. We have zero draft. When you look at the big zero trust picture of nist, then their policies seem as very much at the center. We have ESGs or environmental social governance, we have export control policies. So policies are all over the place.

And I think policy have, have, can have a very huge impact on what we are doing. So, so when we go into to I G A, so the identity governance and administration, user life cycles, identity provisioning, access governance piece, the areas where we have policies, I believe are the ones which are rather simple to use, but they are, that's maybe the problem. Too many areas without policies. So policies in iga when we look at this, so first let's start with the bad thing in iga, bad standing privileges or static entitlements.

This is what is, as I I, I think I said it a couple of times during the conference, this is the root cause of all that in identity management. So this is what really creates challenges. So the complex role management things, they are here because we have to deal with standing privileges across a lot of applications. Recertification is so, well, let's say name it ugly because it is about the standing privileges and the good thing, our dynamic policy based trust and time and shit is not shit access the automated part, this is really the good thing here.

And there are things which are simple and brun. So birthright provisioning, which we can do, where we use a maybe an organizational role, a business role, an organizational. So which department is someone in the location, other attributes that is something that can work and that can work well. We can also use this by the way, if, if something changes, this could impact the mover process. Even by the way I have, I have a rule here, and I believe, I'm con convinced also from, from my experience, that this can be matched, this value.

The rule is that at least 90% of the entitlements someone has should be assigned automated by rules. So the manual access entitlements, manually requested access entitlements should be below 10%. So this is the threshold I define here. You should compare where with where you are. And I strongly believe this can be achieved. There are s o d rules. Yes. So we have areas, but managing all the static entitlements and legacy software AD s a ad, SAP homegrown software Salesforce, that is a challenge. This morning when I was standing in front of the mural shaving, one thought passed my mind.

So we, we see all this upcoming regulations around sort of security by this sign one. This, honestly, I believe a part of everything around security by design should be no static entitlements anymore. Software that is built with static entitlements is not to my understanding in compliance with security by design because it's secure, insecure by design. So in fact, we must change this, okay? It's a bold statement, but I think I I, I'm pretty sure that I'm more on the right than on the wrong side of the statement.

We'll come back to this, this IGA aing later, by the way, so can policies simplify legacy IGA approaches? This is always the point. And I remember, so there's one person in the room, I I had a conversation probably some 6, 7, 8 years ago about trust and time access and, and the hope of getting away from, from these standing privileges . And I think there's always the, the point that comes up not from him, that is so complex to do so, so policies for legacy. So what we have today, we have users, we put their users in groups or roles, groups with entitlements.

And these entitlements in fact are subjects in action that are assigned to a user or group, for instance, for files. So this is this static mapping in a bit of a simplified manner, but it's basically this, what we could do is we could say we have the users, we put them into groups, and we have sets of entitlements still. And what we can do is we can for a session, so if we use the authentication of the information from the access management system or not perfect, but doable for a certain time, do sort of a dynamic bin binding where we say the subtract, which could be an individual or a group.

This, we bind it to that specific sort of set of entitlements. So that might, may require, like we had in, when we go back to Sam, so where we frequently had this, okay, we map that user from the other organization to technical account.

Not, not the most beautiful solution, but better than setting entitlements at the end of the day because we, we don't have this permanent binding anymore. So there are ways to overcome this and I I really ask the, the, the people from the IGA vendors in the room to think about it. How can we at least add a bit of trust and time and policy-based assignments, policy-based dynamic bindings to iga. This is not rocket science, this is doable. So do it and make the world a bit better because that will also reduce the number of re-certifications that need to be done.

And you will really make your customers happy. Authentication policies. That's where, where everything's here, we're doing it. What we mainly do is we do a bit of cost screen saying, okay, Martin is allowed to, to do that and that, but we have there, so we have the authentication policy there, well established a bit too fast. So adaptive authentication, we have the context we use. So device behavior, location, I think I wrote yesterday maybe we called behavior better identity threat because identity threat, everyone says, oh, scary, we must do something.

When you say user behavior, some, some will say, oh, they are tracking the users. So the connotation of these terms is a bit different, even while there's a lot of similarity in, and we match this to risk and then we decide about step syndication, et cetera. We have OS scopes, which are a bit of a cost grain access control could make them a bit more granular, which is happening in several areas. We see upcoming extensions to os we see what happens in the, in the, the, in the banking, open banking space. So it's all here. And we have, that's something I have really to say.

We have a lot of cool, cool orchestration tools out there right now to say, okay, we implement these policies in the access flow in the journey. So there's a lot of things there. And this is maybe a good blueprint also for some other areas because we, at the end, the industry knows how to do things. We have the authorization policies with the PX P triangle, more the old-fashioned way. It's a proven model. It's definitely not wrong. Even while I call it old-fashioned here, that might be a bit unfair. It's specifically it's way too rarely used.

So these authorization policies in the old style, they are a user goes to an application. The application connects with a p p, I'll bring up the terms in a minute. There's a pdp, the policy searching point which receives information from pi, like like a database or an L directory. There is the repository point with the policies in, there's the policy see administration point where the admin then is working on the policies. And as I've said, there are a lot of p piece with something in between like the enforcement decision, information representative administration, et cetera.

So this is something we have seen around for, for for a while. When you look at exact, it's basically this. Some of that you'll find when you look at the N zero trust policy thing, et cetera. When we look at it a bit more in the modern way. So OPA not being perfect, no doubt, but being widely used by developers of digital services. Interestingly, because what you see this OPA is people like if, if they don't need to care about the authorization piece when developing software, so better u let's use something that cares for that instead of reinventing the five etched wheel again and again.

So the digital service developers like it, they, they also like using identity services. They like to build against APIs instead of reinventing everything.

So in, in that way, so we have the users and then they are, they, that could be also users could be. So maybe I should have put in some, some none. So they are not that human when I paint them, sure, they not even look really like humans. But I maybe should have put in some, some silicon identities here as well because a lot of these sort of accounts or identities are factually services accessing resources. But on the other hand, very frequently on behalf of, of humans.

So I could have also created the big painting around identity relationships, which by the way sometimes happen when I do these whiteboard things and I start painting and then I add something and then after a few minutes no one can read it anymore because it's, it becomes too complex. So I try to keep these things a bit leaner and apologize for my handwriting. By the way, Yoko always said I could have become a doctor with my handwriting. So we have the resources, the components, the applications, databases, et cetera. They have APIs and then there's a service service mesh.

Again, access APIs. We have to open policy agent chasing queries for, for asking for the decisions.

Again, we have a policy store, we have a language to describe policies, and we have data stores which are factually policy information points like the whatever Azure active directory. Not sure what the name is today of the Azure active directory, but probably tomorrow it's another one. The database and, and a lot of other things. So this is the scenario we have, but basically it's, it's a very similar scenario because in the end we have a policy enforcement, you have policy decisions, you have policy repositories, you have everything there as well.

We need these, we need policies for automation, for dynamic workloads because we can't keep in control of this complexity when we have DevOps where applications are constantly changing delivered to the execution environment, which is for itself, again, very complex. There's a lot of components we use, we need this. So this is also the key more D challenge here. So we have nowadays compared for instance to traditional privileged access management, we have many services compared to few human users. We have many services compared to a few Windows Linux servers and applications.

We have a dynamic world. We have an from infrastructure as a service, an elastic world with workloads going up and down. So we need policy based automation, otherwise we will fail. We can't handle a dynamic agile environment with static and principles. This will not work. And honestly, we always talking about the complexity of identity management. So we need to apply it everywhere because everything is complex and dynamic and so on.

Take, take organizational changes. So you have your IHA and then the organization changes.

You, you built your own model and until you're done after three years, you had two fundamental organizational changes already. That's not so dynamic. But even two dynamic for what we are doing, the policies are at the core of the zero trust architecture. So I repainted the picture from the NIST here, basically something where we also have a pap and PDP and pap and so on. Basically very similar picture, broader than identity, but basically the same thing. So you have a lot of systems helping in verification. So you need to turn your head a bit to read it like I am Siemens, sir.

And you have more systems helping there. So you get a lot of data, a lot of signals here that help you in in, in doing that that can be consumed for making decisions. What else? Policies and decent identity are perfect match. Absolutely. So we have the wallet with the proofs.

I, as, as you all have learned, I tend to use that term decentralized identity because I've believe it describes everything. Well take the, whichever term you want, I'll stick to that one. And I don't want to discuss about what is the exactly correct term for what. It doesn't help us to, to, to really move forward. We have a service, we need authentication and authorization in that service. So Martin opens the wallet with a strong authentication, doesn't rub us his fingerprint cause have a blaster here. So fingerprint doesn't work well with, with that sum.

So number two is, I, i so to speak, open the wallet. I the access to the proofs is there, I already have some, some proof that I had a strong authentication and I can authorize wire proof. So if I have certain proofs, I can use them in a policy, I can use them for that.

So it's, it's a really logical match here. What do we need to do? We need to make this entire thing work. And this will require a multi-speed approach in organizations. That's something we should be very clear. We can use policies all over the place, but some things are easier to do now and others will take a bit longer. So think in a multi-speed approach, but start with your conceptual work now look at the standards and to the community work, continue working on the standards, continue improving them. We need better software, so to speak, security by design, privacy by design.

We need policy life cycles. So policy without a life cycle, that's not a good idea. We need life cycles for creating, changing, et cetera. Ownership. We need policy governance. And with policy governance, we need data governance because the point is we have a policy. And so recer policy is simple. They are easy to understand. They're not too many. But the point is data is used to start from the p i p to make the decision. And this is what we need to bring together. We need the data governance piece as well.

So we as identity people need to care more about data governance and start talking with data people, not only for that, for many other reasons as well. And we need to do this in different speeds for OPA digital services. We can start now, but we should, should build the framework, the governance framework and the the management framework now for everything when we proceed and move forward. I'm perfectly on time. Thank you for listening to me.

Okay, if I can switch this on, I'll check quickly whether wrong session here, whether there are questions in here. It looks like he has, he doesn't show me the questions currently, unfortunately. May maybe I can manage this. Here we go. Q and a.

Okay, there are questions. So let's look, maybe we take one.

Oh, what to do with clients organizations dealing with more than 5,000 different roles, still not recognizing they have a problem. I think this is one, one interesting question to pick.

So, so, so the point is, you know, I think many of of you right now will say, Hey, only 5,000, where's the problem? I've seen way, way, way, way bigger numbers of roles.

I, I think honestly I think everyone knows that roles are challenging because once you've gone through a role management project, you've learned something about it. And I think also recertification, I still haven't met a single organization worldwide which said, hey, my departmentals managers are, are really waiting for the next certifi or re-certification campaign because it's the biggest fund in their life. I haven't heard about that yet. So I I I, I think the, the point is that that's probably more the, the lack of an answer on how could we solve it, what can we do to address this?

And I think this is what we need to look at. How can we solve it? I hope I gave you some ideas around that. How can we get better, which needs the help of the industry, the help of all the software renders and of us as identity professionals to make it work. So I thank you. I'm the one standing between you and the coffee. So I'll let you go to the coffee break now and see you later. Again. Thank you.