Alpha Barry: The Value of Identity Governance and Administration in Non-Regulated Companies

All right. I understand that. I'm the last one to present today. You already had five hours of interesting and complex discussions. So I'll try to be as entertaining as I can with the possible as possible with the topic like identity governance and admin.

Now, why do I want to talk about identity governance and administration and non-regulated companies? When I first entered the industry, then of course it was in more or less regulated environments, financial industry pharma, for example, and there there's no real debate about identity governance and admin later on I switched sides and started working a lot with industrial companies and manufacturing companies and their identity governance was far less prevalent, and it was far more difficult to then in turn capture the benefits of identity management.

If identity governance is not properly in place. So where did that come from initially? And basically what we found was this thing is in a regulated industry, you don't really have to argue the use of identity governance and administration because in re in a regulated industry, it's normally enforced by the regulator, like in the financial industry, the value is basically created on it. Systems is run through it systems.

So having clear identity governance is a prerequisite to be able to then manage access to individual applications that potentially could do a lot of financial harm if in the wrong hands. So there it's no question. It's also not a question. Other regulated industries, for example, in, in the German critical infrastructure, if you apply the German critics law, it enforces that you use security standards that in turn expect you to set up proper identity governance and identity management. So no problem there and the compliance requirements often quite detailed.

So you can only meet them if you deal with them on a process and or on and on and or on a tool level. So the implementation and the use of state of the art and entity and access governance, including proper tools is no question. You can always justify it as cost of compliance. And therefore you always will find a budget for that now in the non-regulated industry, it's completely different. So of course there's also compliance requirements, but these are normally focused on certain areas.

So of course you have to demonstrate that you have proper access policies and proper identity governance for areas like E R P where your financial auditor would, would expect you to exert an appropriate level of control. So of course you have it there, but in many other areas, it's not prescribed to have it, so you don't have it. And when you look closely, then in areas where identity and access governance controls are implemented, they're often implemented on a process and guideline level and not really on a tool level.

And when you then try to argue that this also gives you security benefits as a proper foundation of securing assets, it's quite hard to, to justify a budget for a tool based on just that. So when we started to work in non-regulated industries, we found that there is a need for a compelling business case. So that tool adoption for identity governance actually takes place and can actually be argued by it managers when talking to decision makers about the budget. But why would you want these in the first place?

I think a very important point is that modern identity governance and administration becomes quite important when you try to move towards a cloud transformation scenario and or a hybrid cloud scenario. Why is that? When you look at where companies come from, then the decentralized way identities often managed quickly becomes a problem when trying to move towards the hybrid cloud. I give you a few examples, what you often find in a legacy infrastructure, which is regionalized around multiple data centers around multiple different directory services and, and, and user directories.

What you find is often that you have separate user IDs, separate directory services for individual applications, for individual regions and in the legacy infrastructure that works just fine. Now, however, when you move towards a hybrid cloud scenario where you suddenly try to use globally uniform applications and globally uniform technology stack, you suddenly need a common global user ID to access that, which is a complete mismatch to the decentralized user ID and administration and, and directory structure that you had before. So you run into a question how to actually consolidate that.

And oftentimes you find the same person with multiple user IDs on various of these legacy directory services. So how do you actually consolidate that for a single user and find out is this really the single user? Next thing is in the, in the legacy infrastructure, you have local services and there is very often no need for a global connection between these services. So now for global services, you obviously also need global user directories, which whichever unified visibility across the whole landscape. So how do you consolidate that?

Given that probability is high, that in the past, these directories had different data structures, different data attributes per user. And so on third thing is that in the past, and in these localized applications, the user life cycles often independent for each of the ideas that are being set up. And given the low degree of complexity locally, it's often managed directly on a directory service. You find this, especially in medium sized companies, that user identities are directly managed.

For example, on the active directory, using simple tools or script that allow you to manipulate the user base within the ad. This is not how it works in a, in a large hybrid infrastructure. You have to have a federated architecture where you have one single source of truth for your users, which then deals with authentication authorization for the various cloud services that you're, that you're accessing. So here again, this is only possible. If you have a consistent central management of the user ID, how do you actually get to that?

And how do you actually get to a scenario where setting up these central user ideas has the right level of process security? Because a lot of the local services that we find with our customers do not really have a high process security. It's more administrative on an ho basis, and you need to get away. You need to get away from that. Now the last topic that is important is when you look into commercial aspects like licensing in the past, this has been done locally again and often with a paradigm where Licens per, per server or per application.

Now most modern software as a service offerings or cloud platform offerings are rather charged with subscriptions where a user is charged for a certain period of time, uses the service and here again, how do I get to that different licensing scheme? And how do I manage this efficiently? We've oftentimes seen with clients who are changing the paradigm, that there's a huge loss in the efficiency. When first trying to do this, let me give you an example. So couple of years ago, we did a fairly large transition to a hybrid cloud architecture.

We're talking about nearly 50,000 users in, in that case. And when we came, we are called into the project. The project was struggling. It had been going on for more than a year. The architecture being set up fairly quickly, but migration activities being extremely painful with very low numbers being protest processed month by month, when looking into the problem, we found that there wasn't really a technology issue. There was more of a data issue.

So what they tried to do was to directly take identities from local directories and use these to set up users in a centralized directory on the respective public cloud service. So what, what happened there, of course, across these local directories, there was no unified scheme to identify users. So you would identify individual users based on things like name or email address, but these were not unique across the structure. So when trying to consolidate that into, into one directory, it simply didn't work. Users would get lost. The wrong user would be associated with the wrong identity.

So, so this prevented them from success and also attributes were inconsistent. So we often found cases where in one directory, the user attributes, like is this person currently in employment or is the person retired, would, would not match with the, with the next directory? So how do you deal with that? Clearly when you take a technology only approach towards a migration like that, there is no chance to resolve problems like this. What we suggested then, and what was done at the, at the end was to actually introduce an identity governance and admin layer to actually make the project work.

And this is really what this technology can be used for to grab the data from the local directories, process it in a proper way, and then run through a process where based on the data that's available, every user is properly identified, properly. IDD data is being checked. Data is consolidated and also established workflows in all cases where the issues with the individual user couldn't be resolved on the, on an it level.

So just to give you an order of magnitude out of these 40 to 50,000 users, we identified between 10 and 15,000 thousand, that needed to be manually corrected by HR staff and using a system like this who were actually able to deploy a fairly efficient workflow to allow HR staff across multiple locations, across multiple countries to do this work in a reasonable timeframe with reasonable effort.

So this then allowed us to, again, give you an order of magnitude to process and successfully transform these 40, 50,000 users in less than six months using an approach like that with a, with a proper architecture and the right tools to do this. And this, from my perspective is one key point that non-regulated companies should understand that a cloud transformation with a large existing user base that is currently not managed using a proper identity governance approach can only successfully be transformed.

If such an approach is introduced before you actually undertake the transformation and that it is a correct visit to create a consistent global user directory based on this approach before trying to do the cloud migration, otherwise there's a risk that a lot of money can be wasted before you then move to the approach and still do it after the transformation, there were additional benefits. So what we saw then is that this client who in the past had processed users along the life cycle of the digital identity, very manually could automate a lot of these things. Let me give you a few examples.

So while before the project, the provisioning process for a new user was manual in the sense that HR would set up a record in the HR system, they would trigger it admin via a non-automated process by email, or by sending Excel sheets. See, as the guys who join this month, this could then be fully automated by linking the HR system to the identity and access governance tool.

So a, a new employee would automatically trigger a provisioning process where user would be set up. Initial ID would be sent out based on the based on departmental structure, initial group memberships and initial system access rights would be handed out as the next step. We introduced self services for business management. A big complaint had been that giving access to an individual business application took quite a time using these, these manual processes. So what we set up is then an automated process.

I mean, I'm not naming the tool. I mean, it's one of the tools you all know that we use there where business managers by themselves could requisition access to a certain system for one of their users. And then depending on the consent of the system owner, people could be granted access within a business day.

Next point, I already mentioned the issue of licensing and the struggles that many companies faced when initially starting to move from a classical permanent license scheme to a subscription scheme question is also what do I validate the, the bill of the cloud service provider against, and here again, once we had identity governance set up properly, and based on that could go into professional identity and access management, then the tool would generate the reports to validate the provider bill against, is it the right number of users?

Is it the right number of users actually have access to the product and to the various modules of the product? So from a manual process, with a low level of sophistication, we could move to a validation process, which was to 80 plus percent automated with on with only exceptions being processed manually by a controller, again, a significant business gain and significant value gained because suddenly the client was able to challenge the, the, the, the provider bills properly with valid data.

Then another problem that that we have seen is that oftentimes the HR system did not contain all data that is relevant about the user.

So here again, there was a way to add data to the system, with the safe service concept for the, for the individual user to ensure that things like what's my office location, who's my current manager and so on and so forth can, could always be done from two points, both from the HR side and also from the, from the person by the person themselves and last but not least the same process that allowed us to automatically add users also allowed us to automatically get rid of the user or deactivate the account when people left the company.

So here again, with the connection to the HR system, the deactivation could be done fully automated, taking out a lot of manual work and security risks that resulted from the previous process. So overall, just to recap, recap a little bit, because I have to come to the end, I am a hundred percent convinced that identity and access governance done in a proper way, returns business value for a non-regulated company.

In the context of the cloud transformation, it's a transformation enabler because without identity governance and administration, from my perspective, it's impossible or nearly impossible to cleanse and conduct consolidate legacy identities towards a central directory that's cloud and that's cloud enabling. And it also is a huge boom for automating a significant share of the user lifecycle processes.

Again, generating business value. And if a business case like that can be made transparent and can be made clear to business management and can be agreed upon all the other benefits of proper IGA and proper identity and access management on the security side will come as a boom to the it department. Thank you very much for your attention.