Matthias Reinwarth: User & Authorization Management. Real Benefits For The Business, Effective Projects, Efficient Operation And A High Level Of Acceptance

I wanted to take a step back and have a look at what organizations are currently facing and how they can just improve in place with their own way of doing identity and access management. It is built upon this identity fabric concept as well, but I really want to highlight a few aspects where we really can hopefully benefit from.

And some, some lessons learned that the audience can take with them home when it comes to user management at much more importantly, authorization management. So a quick look at my agenda very, very briefly. I want to have a look at observations and findings when it comes to identity and access management, especially access management and where could be some issues and some obstacles. I want to have a look at access and access policies as a concept. I want to talk about organization policies and guidelines this time.

These are different policies and about processes, and finally about making things measurable so that you can control them. So that is my agenda. A bit of cherry picking across the areas of identity and access management, just to make sure that things can get better in place. Just like the identity fabric is aiming at as well. So starting with my first item on the list is the observations and the findings. And these are challenges that we usually see when we talk to end user organizations when it comes to user and especially authorization management.

And I will show that all because there's not too much time for me right now, but we usually see user complaints, especially when things are not really going well. When processes are not that streamlined as they could be. So access re reviews, complex recertification campaigns that often leads to user complaints. On one hand, when users don't get the access in the timely fashion that they requested. On the other hand, those who have to do the re-certification campaigns, just complaining that this is not what they are paid for. They might be, but they are.

They don't want to do that second manual work. And every arm provisioning process that is not done in, in an automated fashion is usually something that takes more time. The same is true for complex manual recertification. In general, we always often have lengthy processes. So these bumpy processes that take a long time, have lots of stakeholders involved. These are usually leading to IAM, having not that good connotation within an organization. And if things don't work out wrong, this leads to escalations because usually people don't do their job.

They don't execute their tasks until an escalation happens. And this means we need to make life much more simple when it comes to IEM processes, if things don't go right, they might lead to audit findings. And usually that, that is something that we've heard already before audit findings can be a good incentive to make things better. But in the end, it's not about being compliant, but yeah, being, being able to deliver for the business to really make sure that the organization is working the way it should be. And the worst case of course is project failure.

And we talk about that later as well, when it comes to I am and I G or IGA, however, you, you phrase it how, when these projects are failing, they are too complex, not well planned, wrong approaches just does not fit into the organization. And these are the findings that we want to talk about right now. So first of all, this, this, this access to systems is mostly of importance. And we talk when we talk about access this requesting an, an access, right, and approving that this is only just a part of the equation.

So there are many more facets of access when we are talking about access management and governance. And I have various dimensions on that slide. I don't want to talk through all of them, but in general, there are very different approaches towards granting access. And that goes also along the lines of what is actually the access granted for. So it's structured data versus big data versus unstructured data. What kind of criticality is behind that access? Is it privileged or non-privileged?

Are we talking about access to data, to systems, to services, to the network, to devices, and are we doing that on premise or in cloud services and all this means different aspects of access and all of this needs to be done in a somewhat different fashion, but overall we need something that unifies these different types of access.

And that is something that we strongly believe in that we need to have when we are talking to the end users, when we are talking to the business who are the owners of access and systems that we have something that we consider to be common language for defining and maintaining the rules for access. And that is often forgotten in access management. So managing and controlling access for all identities and all systems.

You see, this is again the thought of the identity fabric behind that. So we should, for all identities and all systems have this common language where we can define and maintain rules for access. And these rules, we have have a look at in the next slide.

And it actually does not mean that the, that, that this has an influence on the actual implementation of access control, but that it's just a common process, a common repository and a common language, and that all leads to a common source for creating cross system access control mechanisms, what however they are implemented that could be attribute based. That could be role based access management.

That could be dynamic authorization management, just to make sure that you get to this simple, easily communi capable language of maintaining rules for access and these rules for access that we want to have a look at, we call them due to the lack of a better word access policies. And, and these are mainly for aspects to look at. And those four combined are easily used to talk to, to end users to the business, but also to audit to it to IM guys, of course, as well, to make sure that we really understand who should have access under which circumstances.

And we, if we look at these four aspects, this is quite straightforward. First of all, somebody needs to have access. It's the subject, the user where he, or she wants to gain access to something. And this user is determined by a set of attributes, but because in the end, it's an identity as a reflection of a real life entity.

So the, these attributes are important. So data quality is vital when it comes to understanding who I am and for a subject for the identity, that means that need to be strong, ideally verified and good, well vetted identities in place. Second aspect to look at is the action. It's a specific action that the user intends to perform on something. So the action needs to be specified as well.

And that also is again done via attributes and attributes towards the action specified with additional attributes, maybe adding some criticality, adding some urgencies, adding some additional information to the actual action. So the subject wants to do something, do something with, through the action on a resource. So that would be the actual, mostly digital resource that is affected when this subject performs the requested action. So as an example, Matthias wants to read a document on SharePoint. So this is the access that I want to achieve. And we add another dimension, which is context.

So the environment of all attributes defining at it during runtime and in general. So it might be the time of day. It might be the, the day of the week. It might be the network area where I'm coming from when it comes to accessing a system from, from remote. So in the end, it end up as materials having gain, wanting to have access towards this SharePoint file. And when I'm do that with my well known iPad, that is registered, and I'm doing that as a, as a usual time of day and during the working week, and I'm doing that from Germany, that might be okay.

So if I do that with an unregistered device, which is not well maintained, maybe outdated, and I'm doing that from an unexpected network location, that might be something to consider. So having these four aspects in mind that might lead to simple access policies that can be easily defined together with a business, this user, and this team should have read and write access to the following resources under the following circumstances. So that is something that we consider to be access policies.

And these need to be maintained in the way that I'm described on the slide before, where does this come into place that comes into place in our identity fabric? We've talked about that earlier. And we have talked about that many times, and we use that in, in every aspect where we want to explain this access from the users to the left, to the systems, to the right. And we say that it's a set of services. So we need to have, and there just this little box access policy management appeared here as well.

We need to have this as part of the identity fabric to think of access policies that are then mapped to different kinds of authorization mechanisms. Be it attribute based at run time, dynamic authorization management, or just mapping this rule, this access policy towards an assignment role assignment rule, assigning roles to a person during their life cycle management when they're changing their job position, for example. So that is something that we think makes perfect sense, and it's an easy tool to move forward. Many of the IGA tools have such, such a functionality in place.

So the idea is to, to use it, to use it as a means for conveying access management rights tool user, and to user groups. So that is something that, of course then if we have these access policies in place can lead to automation and to improve all these obstacles that we've talked about in the first slide. So that is one thing that I really wanted to point out to get to a common language. Another thing that I wanted to hint at, and that is really of important is this slide where I want to point out where we think that organization policies and guidelines and processes play well together.

And just to mention it, once again, these are different policies. I've talked about access policies before these simple means of defining access rights as a basis for actual ACC yeah. Authorization decisions. These are policies at a, at a corporate level, at a group level at an organization level.

So if we go from top to bottom, we need to understand that an organization needs to have well defined policies and guidelines, guidelines, starting from the it security, or even a, a, a corporate policy down to a it policy, to an it security policy, to an IAM policy and guidelines that lead to well defined requirements towards IAM. We often have the case that IAM people have to do things themselves because they don't have these policies. They are not well prepared with these guidelines and responsibilities and accountabilities. So it is often done on a more Hennish level.

So we, if we put it the right way, and we should ask for that, we should ask for policies and guidelines that then map to processes that really reflect the policies on an operational point of view. We need to have the right people in place in the organization that deal with these policies and the guidelines. We can then map that to technology and use that as the basis for granting access to information and systems and having this in place again helps and cures some of these findings and observations that we've seen in the first slide.

And just taking that step back and really talking to the, yeah, to the team that is responsible for policies and guidelines might be cybersecurity, might be corporate governance. And to make sure that IAM is doing things according to overall policies and guidelines that really helps and speed things up and make sure that concepts are complete. We've talked about larger projects failing. So we strongly believe at cooking a call that large projects have most probably to fail because we don't think that larger projects do make perfect sense in a larger organization.

So what we usually think of is a, an overall identity and access management program that then spawns individual slice elephant slice projects that then execute individual tasks, ideally being capable of running in parallel or, and, and, or building upon each other to make sure that this program evolves the IAM infrastructure over time. And this is also the thought that we have when we think of this identity fabric, again, evolving an existing identity and access management evolving, and an identity and access management that is in the process process of being created.

It is really important to have these red four lines on top. This are of course only examples to have an overall identity concepts, policies, and guidelines that we've talked about, identity and lifecycle, identity, lifecycle management, access management, access governance, and Pam all subsequently building one on the other, and then mapping to individual processes projects that reflect the individual building blocks within the program. And that really helps in structuring the overall program and getting to manageable and hopefully more efficient and successful projects over time.

So really slice it down here at that point, have five minutes left and I'm right on time. The final thing that I really want to to point out is that we really should make sure that we really understand what is going on in our identity and access management. And that is why we at KuppingerCole really recommend applying KPIs and KRI. So key performance indicators and key risk indicators when it comes to the understanding how we are improving. And of course we want to improve when we look at identity and access management, that is why we're here today.

When we look at the identity fabric for moving to a more, more modern approach towards identity and access management. When we look at risk indicators, of course, we want to reduce the impact from risks. We want to manage by risk. So we want to start a risk based approach when it comes to improving our situation, want to have proper control actions for risks. And in turn, we can prove the success in the operations and the projects based on what we do in IAM for the overall organization, for compliance for cybersecurity, but also for user experience and user satisfaction.

So, as an example, what could we look at when we look at KPIs for the identity lifecycle management, and this is something that I've taken from a rather data document that we have in our library for quite some years, K and KPI for access governance. And there's really a simple way to measure things. So if we look at, for example, the second line often accounts, if we start out with access governance, we will, might, we might find some hire numbers of orphan accounts because user lifecycle management did not go too well before.

So our ideas of course, to have a number for the percent percentage of orphan accounts, and to cut that down over time towards 0%, if we look at the systems we want to include in identity life cycle management, we of course want to increase the coverage. We increase, want to increase the percentage towards close to 100%, but be realistic. Not everything makes perfect sense to, to include in identity lifecycle management. Some things can be left manual or can be left even out, but those who should be should be. So these are a few examples for KPIs, make things measurable.

If they are measurable, you can manage those. And that's it for almost for my presentation for these quick learnings inside the identity fabric, where we can improve things over time and just right now, not buying another solution or not buying another technology, but by doing things right, as a summary, learn from the experiences, understand what these observations and obstacles that we've identified are based on why they are happening. Have unified concepts in a common language.

And I've mentioned that for the access policies, but this is true for well defined architectures for policies guide like guidelines and implementation processes get towards a project roadmap. So this program, plus individual projects over time with a con a continuous funding with a continuous evolution of an identity and access management, because it is not a project, it is a program it needs to evolve over time and finally measure and manage, prove success, demonstrate improvement, and manage the results over time. So these are my recommendations, my key findings within an identity fabric.

And if there are some issues identified that cannot be healed with what you have in place, then the identity fabric approach might also be the right way to move forward to modernizing the overall infrastructure.