I had the opportunity to speak to a group recently regarding Identity Governance (IGA) programs and building them out, successes, and failures. In that conversation, I talked to the main goals of IGA and how to improve their impact to the organization. In building this content, it made me rethink and look at the ‘modern’ IGA landscape and vs. how I would traditionally measure success of an IGA implementation.
One of the main points of the presentation I gave, along with other conversations I have with IGA, is the concept of visibility. IGA programs and platforms are great with what you give them and the processes and policy around them. But, for the most part, our measure of success up until a handful of years ago was limited to MAYBE 25% coverage of our applications and identities (and I considered that successful). Which meant we had roughly 75% of our environment that was still manual or was not connected to any organizational policy and process. This wasn’t by design or intent, was just availability of resources, connectors, knowledge, or all the above. Which, to put into perspective, looked like the below. For most organizations I work with, that on average have 500+ applications, that means 375+ applications are not connected to any organizational governance process or policy which leads to a HUGE risk gap.
Now, with standardization (thank you SCIM) and focus on API design, automation, and maturity of IAM programs. we are moving the needle a bit and I would measure success in the 40% or so range of full or partial connected applications like the below. But, that still leaves 300+ applications on average that are disconnected or have no visibility or reporting into IGA and IAM program.
Now, this begs the question, why is visibility and connectivity so important to IGA programs? The intent of an IGA program is to have at least some level of automation around who SHOULD and SHOULD NOT have access to applications and data within an organization. But, if we have over half our applications with no visibility into the IGA program, how are we managing access appropriately and reporting on it?
The awesome thing about asking that question is over the last handful of years, as we have matured and focused on IGA and general IAM programs, we have started evaluating alternative definitions of what ‘connected’ really means. Traditionally, connected meant we had full, closed-loop, connectivity and automation for a target application. Which, for things like LDAP/AD and other larger platforms, we had rich connectors that could handle those. Anything that did not fit into that box, would stay disconnected / unknown. But, we have started to move towards more loose definitions around if we have a process, initiated by the IGA program, then is technically connected, is just manually fulfilled. Modules like Service Now integration and other ticketing automation have really accelerated this. While way better, still not ideal.
So, how do we move the ‘manual’ needle more to provide some level of automation around those disconnected / manual fulfillment applications? Two big areas I see growth to help shift the coverage. RPA / Bots and ETL / data abstraction layers. With this additional tooling and availability, we are starting to shift the graphic to near 100% coverage, just different definition of what is fulfilling that automation. We’re starting to look like the below.
So, how are RPA tools and ETL / data abstraction layers helping? To start, you may have a large population of service management / ticketing based applications initiated and managed by the IGA program. If these are standardized applications and processes, you can look at RPA / bots to essentially take those requests, process them, then close the original request so that the IGA program can close its task and maintain the lifecycle of that identity and access going forward. This is a huge win for identity and compliance teams. To get even better, you are starting to seeing connectors and other automation directly initiate RPA tasks via the APIs built into RPA technologies (e.g. UIPath Orchestrator).
For ETL / data abstraction layers, this is where I am starting to see some really cool technologies and focus. I had the opportunity to sit through a demo with Easl Technology (see https://www.easltech.com/) and they provide a data movement layer (push and pull) for traditional ETL processing, data cleanup, etc. But, this can also be used to build standard interfaces for IGA programs to be able to connect and get access to and update identity data in different platforms. With this, you could have a standard interface to use a generic connector and get access to large population of applications behind the Easl technology.
With this new way of starting to look at and define connected applications using things like ticketing, RPA, and ETL / abstraction layers. We can confidently start say we have visibility and can take action on identity and policy changes in our environments. So, as you build out your IGA program, or are looking to mature and onboard more applications, look beyond traditional connectors and tooling available to get the coverage you need in your program.
