IGA in the Financial Industry - Implementing IAM

Hello. Hi. So thank you for being here. My name is mark. And today I'd like to talk about our IM program.

I, our journey to IM implementing the IM system guarantee from data systems. And I learned something from the last presentations. Let's see if this works. Yeah. 20 minutes can be quite short, so I'm not gonna go all over the company stuff, but I wanted to just mention one sentence. So what is our vision at inter? We want to help everyone fulfill the dream of owning their own home. Let's dive right into the IM slides. So I wanna start by why did we do this? Why did we introduce this IM solution? This program?

On the one hand we had regulatory requirements, obviously regulatory compliance, all of these three letter acronyms NPAs nonpersonal accounts, high privileged accounts, creation of duty, et cetera, lease privileged recertification. All of that is something that we have to follow. We have to make sure that we are in compliance with these regulations. On the other hand, we wanted to make everything more automated so that we don't have that many manual tasks that we don't have to, or that we reduce errors. And reducing errors obviously leads to reduced risk audits.

Like they happen regularly in our company. So we had to produce different audit reports and make sure that they are accurate. And we don't wanna do that by hand. We want to have this automatic reproducible audit report, user life cycle, obviously on a regular basis. I think last night there was a talk from Siemens. They said they have like 300 movers and 5,000 joiners by month per month. We're not there yet. We're not that big of a company, but we still want to make it automated as automated as possible. And by that we can have a, a more flexible organization in terms of when are we growing?

Where are we growing to be able to make that as, as flexible as, as possible, another aspect, central audit services? Well, they, they kind of gave us a slap on the wrist in terms of some of the processes that we had in place for access management. They weren't too happy. So we had to do something about that. And with all of these points and aspects we were considering, well, do we do this? Do we get a system? Do we implement something new or do we stay where we are?

And try to work with the stuff that we have, obviously both options have costs and staying where we, we, where would also require us would still require us to follow the regulatory compliance and all of the other aspects. So eventually we decided, well, we have to do something and we have to introduce a proper system. How do we go about this?

Well, we didn't have any know how in house. So we had to get external consultants to help us with this. And what we learned is that this is not your average it project, where you just grab some it people, and then hope that everything goes fine. We need to get different departments and different stakeholders.

So, as I said before, we need it. We need HR to make sure that we get the proper data. We need some department managers, because they will be the ones that were actually using the system later on. We need someone from regulatory requirements that actually understands what those requirements are. And then I put IM team and parenthesis.

Well, because there was no team we're just getting started for the project plan. What we tried or what we learned what's important is to stay away from technology as long as possible, and actually design agnostic from technology, understanding regulatory requirements. I said it before, we tried to take care of the basic processes in terms of like the joiners movers, et cetera, the user life cycle. We didn't want to reinvent the view. We wanted to get the processes, the standard processes, and then maybe do some adaptions and customization maybe.

And since this goes across a lot of departments, as I said before, we, we need to make sure that people that are involved actually know what their task is, what their task is during the project, but also what their task is after it's done. We don't wanna have people that just cruise along in the project and then there's a finished product and they know don't, don't, don't, don't even know what to do with it. So how do we go about this?

Well, now let's talk about where are we now? What do we have? And obviously there's so many different, different blocks that we have. I just wanted to pick out some and talk about them.

In detail, HR data important is obviously very important. And at inter hub, we have our core platform, which we developed inhouse. And this platform is kind of like, if you have a hammer, everything looks like a nail.

So we, we had our, some of our HR data in this core platform. So for the IM program, we implemented a connector from the IM system to our core platform.

Well, turns out later HR decided we don't want to use that core platform anymore. We're going to Workday. So they moved the data to Workday. We had to change the connector. We had to do some updates, change the processes. And this is where it well makes sense to have technology, agnostic processes and workflows or independent workflows, to be able to get the data from different sources. And what we have today is we have a bite, directional connection to Workday. We get the data, we have different triggers with updates and stuff like that. Looking at roles, we have multiple roles.

We have a layered roles structure. On the one hand, we have like basic roles, obviously, which we assign rule based. We have technical roles and business roles. They usually are not assigned automatically. They have to be explicitly approved and all of the roles they are additive. So you can have multiple rows of on different types of layers. And this is how the access rights for each individual individual user is, are assigned eventually ion of duty.

Even though we have multiple rows, you have to take care and make sure that there are no toxic combinations and no toxic combinations on the level of the identity. So it doesn't matter how many accounts the person has. We have to make sure that there is no toxic combination possible. Why don't we do this with multiple layers on the one hand, as I said before, rule based is something that we want to do. We want to automate as much as possible and rule based assignments for non-critical access is something that we're trying to go after.

We have business roles on one hand technical roles on the other hand. Well, because there's different owners. So the technical roles, as the name says are application oriented, asset oriented. They have technical owners, the business roles have business or organizational related owners. That's why we need to distinguish those. And then obviously with multiple layers and aggregation, we can remove complexity.

Think about like the it security Analyst role that contains multiple technical roles from all of the different application that a security Analyst has to use recertification, obviously, depending on the type of criticality of the access, right? We have different requirements for recertification. Previously. This was done in our core platform today. We used the IM system for re-certification. We have all of our assets in there. We have even manual provisioning assets in there. And these are also re-certified in the IM system. We have also expanded the descriptions.

This is something that we get from managers quite a lot. We really want to understand what we're doing here. So you need to make sure that the, the description for each role is understandable on, on a manager level. Let's look at some of the workflows. These are some of the workflows that we have currently implemented. Obviously we have like the joiner workflows or the, the, the regular user lifecycle workflows. We have workflows to create roles, business roles, and stuff like that. NPA I mentioned before nonpersonal accounts, they're quite prominent in terms of regulation for us.

So there's lots of regulation for nonpersonal accounts, and we're constantly changing the workflows for that. We have a creation workflow and we have a management workflow for, for NPAs UMO access. Obviously the, the most used workflow probably, and then manual provisioning. As I said before, if we have a system that doesn't have a live connection to our IM system, we have to do manual provisioning task, get the administrator, go to the system, assign the access, right, go back to IM check off that they actually assigned the right or removed it.

And then we know that the, the access rights are as they should be. Most of the workflows were designed with external help, as I said before, because we didn't really have all of the know how in house and we we're still improving the workflow. So this is an iterative process. All of the learnings that we took from the first workflows are featured and helped to improve the next workflows. But there obviously were some challenges. And I mean, the goal should be to have a seamless user experience.

And I don't know about you, but like the other day in, in the hotel here, I was trying to use the shower. And there's like so many knobs and levers, and I don't know what, and you don't really know how to turn the damn thing on. And then later on you find out where there are instructions in another room, how to use the shower, and this is not user experience. It doesn't make any sense. I don't know what, what people are thinking, but we're not gonna talk about showers, but the thing is, that's what we're trying to do.

We're trying to make it as seamless as possible for the end user to use the system because we don't make it hard for them. We want to, we want to make it clear for them. What happens next, who will be doing the next task, et cetera. Also with the user face user interface, obviously people should know which workflow is for which task for managers. They have a lot of underplayed want to make it as, as seamless, as possible as straightforward experience for them to use the system. And then finally, we also had to connect our core platform. Why do we have to do that?

Well, it is our core platform, like most or all of the critical data that we have lifts inside that one platform. And we needed to be able to have a very dynamic connection so that if stuff changes in our core platform, we can adapt in the, I am tool for that. We're both a connector and the connector actually does a lot in terms of if there is a new role or a new access, right inside the core platform, everything that's necessary will be created in the IM tool automatically. And you can go into the tool, create a new role with this access, right? That has just been created.

Everything happens automatically. So where, where we, where are we going? This is something that we're planning for, for the future regulatory compliance is top of mind.

I, I mentioned it in the first slide actually, and now we have some changes coming up in terms of regulation for us, it's actually something that they it's like entirely new reg regulations. They don't really change the core, but they change the way, how they express stuff, how they control if we follow regulation. So what will help us hopefully is that when we initially designed all of the workflows and the processes, we didn't really go after the regulation and try to follow and make sure, well, we're following this regulation. It's fine.

We thought about, well, where's risk, where's risk associated, which steps are critical and make sure that we covered these dust. We think that that shouldn't be that large of an, of an issue re-certification is also very important. So we want to expand and enhance, re-certification get more understandable descriptions for managers and also make sure that we can re-certify rules for the automatic assignments. And also re-certify roles from both, both ends automation. I said before is still top of mind. So we want to have as much automation going on as we can.

So this helps us on one hand to make it easier for the users to make everything faster, because they don't have to wait for a couple of days for access, right assignment, maybe for approvals and stuff like that. But it also will be a factor in terms of how we deploy new changes and buck fixes. We want to also automate that process as far as possible. And then finally, this is something we're planning for this year in order to be able to keep our IM system up to date and also secure to take advantage of all of the new features. We want to go and migrate to the new and the current release.

Sorry, and this is something we're planning right now. So this is not a smaller project because it's not just your installation technical stuff. We also want to make sure or have to make sure that we test the workflows. We test the connections we test out of the outgoing and incoming data. We want to minimize downtime, obviously because I am as a crucial system. And obviously we have to make sure that we have like backup plan. If something goes wrong, that's it from my end. Thank you very much. If you have any suggestions, questions, comments, you can reach me at Twitter or at my email.