IAM Requires a Solid Process Framework

Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Mathias Reinwarth. I'm an analyst and advisor at KuppingerCole analysts. in each edition of this Analyst Chat I have one guest joining me, often a fellow analyst or another interesting partner, and we have a 15 minutes or so chat around current topics. My guest today is Christopher Schutze. He is director of practice cybersecurity at KuppingerCole analysts. Hi Christopher. Yes. And thank you for inviting me again. Yeah. Great to have you.

And this actually can be considered as a third episode in a series of episodes that we start with two episodes together with Graham Williamson from our Asia Pacific team. And he talked about how to make identity and access management projects more successful. Its focus was on solution architecture in the first podcast that we did together. And the second one was about successful. I am project management, we crystal and I today want to talk about am processes.

So the overall landscape of processes that are required as a whole to make an IAM project and in the future, then an IAM operations more successful. What do you think Christopher is the key starting point when thinking of successful IAM processes?

The first thing really is that you do not think about in a single system, for instance, for getting information about your identity, which permissions or entitlements you have, you need something like an overall our process framework, which really covers all topics related to identity and access management, because therefore you can reuse some processes. You have specific processes for specific areas like ITA or excess Federation, or for sure privileged access management.

And you can use the same processes for things like application onboarding, for instance, or for management and some generic processes like sod management, risk management, and some standard processes for approval. So that means that I am, it should also always be considered as something that is well embedded into an overall on the one hand cybersecurity process framework, but also in the, at the end of the day into the business process landscape as well.

Yep, for Sure. And just think about one of our other podcasts is about identity fabric and the identity fabric is also covering not only identity lifecycle topic. The identity fabric also covers Federation topics and privileged access management topic. And the same thing is with processes. You have to think as an overall architecture, as a central point for processes, this really helps you to improve the process quality a lot. Okay.

That's understood from my side, when we then think of these IAM processes, what would you think are real specific IAM processes that are adding to the overall landscape of processes? So which which are really native IAM process aspects to look at, For sure, the classic China mobile liver processes. So the identity life cycle management processes, you employees start to work, employees move within the organization, have maternity leave or leaves the organization.

This is for internals, but maybe also for externals and therefore these processes for joining I'm a believer are the most essential thing, but for sure, and this is the thing very often under estimated you also need a good process. So use for excess week fests and for approval. So requesting new access to systems, to folders, to shares, to team space and some corresponding approval workflows behind that maybe by the responsible person or your manager. And then for sure you need processes for excess, right?

You maybe once a year or twice a year, that someone who is responsible again, maybe your manager has a look at your entitlements. If you still need them, or if they can be removed, maybe you are not longer in a specific project working and then it can be removed. And a thing we very often see in advisory that is missing is some good and some integrated model management, for instance, for roles or for business roles or for entitlements in general, because target systems which are integrated into an IGA solution are complex.

They change very often their internal model changes and you need processes to cover that, to integrate them into the ITA solution and to enable managers or responsible persons to request entitlements, to maintain entitlements and understand what the specific for instance, description of role means. So not in technical description, like an SAP, a technical role, so more understandable description of what does this set of entitlements mean for you, Right.

And I think you've mentioned before the identity life cycle management, we usually also recommend that there is a role lifecycle management and role ownership, so that you're on the one hand, always know who's responsible for a single role and what, how it is composed and that this person, a real life person can change over time as well. So that there's always somebody in the position to understand what the role is for who is the owner, who is the approval for such a role and who is capable of adjusting the role over time when embedded entitlements change. Exactly.

And this is mainly covered or should be covered if you think about the process framework in the mover process. So if I'm responsible for a role for a business unit, for an organization for approval, for excess reviews, the mover process must be designed in that way that if I move my position, maybe an, a recertification or something like that is started by my manager and it is checked, are I'm still responsible for that, or is there a need for a change in the process chain for responsibility? And this is a really important essential part.

And especially the mover process is one of the most complex processes we have in ITA or at the end for the old whole IRM process framework. Right. Okay. So if we then move one step further, this was IGA being composed of model management, identity, life cycle management, access request, and approval and access review. What else would you consider within a, a good a well-designed I am process framework For sure. Everything around privileged access management, things like the management or processes for the management of credentials.

So for instance, for technical accounts that it is frequently changed or rotated or things like that, therefore you need processes. You need processes for deliver the initial credentials the first time too. And this is more the integration into the general processes like application onboarding, you need to integrate them. Right. Okay. There is another series of podcast episodes that I do together with, with Paul Fisher, our colleague from London, and that will cover Pam in more detail. So they will also be a episode about the Pam processes. I'm quite sure. Okay. We have IGA.

We have, we have Pam, what else should we think of, Oh, this didn't cover the whole pump topic for sure. We also have three other important areas like session management. So who is able to review session if one access and privileged function in one of the systems. This is an important thing, especially when talking about GDPR requirements. And then for sure we need integration processes.

So for instance, into cm solution, maybe if pum specific attributes information about and lock in processes, process or behavior often user should be integrated into an cm system, or for sure, the, the integration into an ILM system that maybe to request for privileged access is managed by the IGA solution. Or at least I can see in the ITA solution, which privileged excesses I had at which point in time.

And besides that we have for surely extended capabilities like sings for cloud development for those technical users, A digital business makes sure that we need to cooperate with other organizations, which of course in turn have their own set of identities that we most probably don't want to maintain ourselves, but just consume them, use them for communicating, for giving access to our systems. That would be then the third area that we should consider. Right? Exactly. This is Federation at the end.

And first of all, if you think about Federation, it should improve your internal effort or minimize your internal effort for onboarding or managing external identities. But first of all, you have to integrate the external organizations. So you need some onboarding processes here to onboard a set of identities to trust an external identity provider and it's statements about identities. This is the first step.

Usually you have something like an sponsor here or an responsible person on site of the external partner who is at the end responsible to allow new identities from the external source to access here. And then for sure, you need to stand up processes for excesses, for policy management and things like that, but really mainly Federation and very special part of excess management. You need to have the onboarding processes and then you can maintain those identities by the external partner. And this is much more efficient than integrate them into your, for instance, ITA.

Like we did that in the past. So create some external identity types in an interim lightened, the management system, Which also gets more and more difficult because of regulations and the protection of PII. So if they maintain their identities themselves, it's much better than us having to do that. Exactly. And especially if at the federated partners responsible, you do not have to care about the lifecycle of the identity because if the external identity is leaving the external organization, he or she should also not have access to your organization anymore because it's identities.

Right. Understood. So we have the three main pillars that we just thought of, first of all, IGA, then the protection of privileged accounts and third, the consuming of third-party identities, access and Federation. What else should we look at to get to a full picture of IAM process landscape? For sure, we have to topic application onboarding. I've mentioned it with the IGA and Pam processes, mainly it's really about onboarding a new application into your IRM service portfolio or into your identity fabric. So you need processes for onboarding.

Maybe you create some kind of blueprints for typical authentication and authorization models, which types of users are allowed and things like that just improves the quality and the speed of onboarding a new application. Really a lot besides sets. You also need something to maintain those applications. Maybe if the entitlement model is changing, a responsible person for the application is changing or some general processes change. And at the end, for sure, at one point in time, application will not be needed anymore. And then you need some kind of offboarding process, Right?

When I think I'm just like I am, has changed over time as a whole. Also the application onboarding has to adapt to the changing more hybrid environment. So application is no longer just the, the one that is running in your own data center as a legacy app, that's easy to implement. And to talk to the application owner, you also have to think of software as a service applications provided from the cloud hybrid applications and even maybe applications as designed and defined and developed in a more agile environment piece. Yeah. Dev ops agile containerized modularized services that are provided.

So application onboarding still and continuously is a challenging set of processes as well. So to sum it up, we have learned that first of all, I am processes need to be well-integrated into the overall process framework of an organization there into the cybersecurity and the business processes as well. So including sod management risk and the individual IGA process colors that we talked about are then the challenge for the overall organization in the IAM field. Anything you want to add Christopher to, to this, this short summary? Did I miss something?

No, it was a very good summary at the end. The famous last words is really think about it as an integrated approach. Don't think about single pillars. Think about the overall thing.

Think big, Right. And I think the think big is also of importance. Just to add one thought. We now have outlined a set of processes to think of also that it's the shooters or something for a different podcast episode as well, or for more than one, I tend to find the right people to talk to, to define these processes. I think that is the next important step to really get these processes into a state that they are actually useful at feasible from an organization. Thank you very much, Christopher, for joining me today for this episode of the podcast. Thank you. You're welcome.

Bye-bye .