“Take a deep breath. I am about to tell you all the great things your new IGA solution is going to deliver to you — Improved Security, Automation, Vanishing tech-debt and a vastly improved user experience.
How will we do this? Okay, we will do this by essentially connecting your applications to the IGA solution, import permission sets, map them containers called business/enterprise roles to manage fine grained authorisation. We will then publish these containers on out access request portal so users can request and remove access. We will integrate your sources of truth for HR and IT Directory data to build a single view across identities, access profiles and then build a governance mechanism where the right user will have access to the right things. Oh! Are you doing all that with your existing solution? Don’t worry, we will do it better. Did you mention SAP ECC? Not a problem (silent expletive under the breath). Right, you are in the middle of a cloud transformation programme and have applications moving to GCP, AWS and Azure Cloud all at the same time. No, are you going through an acquisition as well? Really? Yes, there are always those pesky “SaaS” types that do not support modern authorisation frameworks. We will not ask you to re-build them, are you crazy? Segregation of Duties did you say? Alright. How exciting!!
We can still do it, i mean, the first part, you know, deploying the kit etc in, say 3 months? The rest, hmm…let me see. How many applications did you say you have? Okay, 1500? 4 million entitlements? Reasonably, 3 years….well perhaps four. So, that is, Improved Security & Compliance, Automation, Vanishing Tech debt and vastly improved user experience — in 4..or so…years……..that is a very bright investment isn’t it? Hang on, are you still with me?” — An imaginary conversation
Four years is a long time in the world of Cyber Security. Long enough for the platform to become the technical debt it had claimed to erase initially. Why are we still doing IGA the way it is done today?
I mean, most organisations have some kind of a fulfilment mechanism for people who need access to systems. Most enterprises do have reasonable joiner, mover leaver processes even if they are imperfect in parts, even unwieldy. Why go through the four year rigor of connecting thousands of applications and end up with the same patchy automation and control landscape that you had begun with? Why go through the stress of convincing application owners to “onboard” their applications, amidst thousand other priorities when the end goal is that of landing them in a soup called the Access Request Portal?
Is there really a business case for investments in Access Governance as it is practiced today? What breaks if we do not do get on this 3–4 year rodeo?
The ugly answer is, very little.
Why IGA then?
Fallacy #1 : IGA and improved security
The reality is that, today, if you have an recurrent issues with global processes like JML or application specific gaps in access control, the natural solution is not a new shiny tool. The pinch point is your processes and execution model.
Let us pivot to the problem statement. The problem (that we tell ourselves) we are trying to solve, is that of inappropriate or illicitly acquired access that is ephemeral or persistent and that which can be misused or exploited to compromise the integrity of systems, processes or data.
Isn’t it then a adverse tangent that we resolve to solve this by spending a few hundred thousand person hours to onboard hundreds of applications, with complex access models, approval hierarchies and provisioning logic to create yet another imperfect fallible system of record?
The orthodoxy that we follow today in IGA programmes was first conceptualised back in the 90s. We built identity management systems on strait jacketed platforms — LDAP directories and on premise HR systems and applications. Directories, HR systems, applications and workloads have moved to the cloud, but the orthodoxy has not changed much. It has been the same old rinse and repeat for the last 20 years.
Today, we know that occurence of risk is a consequence of debilitating but finite access patterns, causality can be discerned, the Edge can be much better secured today than it could be a few years ago, Signal based models do not wait for an IGA solution to determine whether a person should have real time access. Yet, why do we still spend precious resources on expensive integrations and retro-fits? Enterprises are rich repositories of access context data, but the orthodoxy says the only way to get this data is to “connect” through a connector, import and manage it in that straight jacket of an Access Governance solution. Instead of the technical activity of configuring imperfect but functional global workflows, are we better off establishing a baseline for access context and risk associated with it? Can we get to this point in weeks instead of years?
Fallacy #2: IGA and Improved automation
IGA programmes are not for the most part about improved security baselines. It is acceptable for providing the “assurance of security” (false?), but that is a whole different fallacy in itself. CIO’s have little patience for pitches that trot out the benefits of a 4 year IGA programme. They do want to bask in the limelight of an intuitive system that touches every user in the enterprise and that drastically improves the end user experience with IT services, IGA included. They, or their offices, envision a pat in the back from the finance team for making a hefty opex line item disappear for “momentary” Capex pain.
Unfortunately, more often than not, IGA programmes disappoint on both counts. Not only do they compound UX issues, but to make matters worse, the end of that painful Capex line item is met with a hefty Opex payload that obliterates any financial relief that the CIO/CTO may have been adventurous enough to project.
Take self-service and UX for example. IGA solutions are as good as data they are fed. We can apply machine and deep learning all we can, but without organisational and business process context, it cannot really iterate on permission data autonomously, improve it and deliver an effective user experience. In moving a manual process that is administered by the application helpdesk, from the back office to the self-service portal, the IGA programme exposes the untidy plumbing of system speak to unwitting business users. In their first flush of achievement of having onboarded an application, IAM Managers often underestimate the deprecation in end user self-service experience.
In short, there is no use case for “self-service” until hard dollars can be associated with automation or getting rid of numbing tech-debt. Be careful about the promise of “automating” manual processes. End user experience is invaluable to your sponsors. If the back plumbing is untidy, they are better off covering it behind a half decent helpdesk. They would not want to spend from their hard-won budgets to then also spite their brand.
You can stand on a mountain and shout this problem statement into the wilderness all you want. The echoing answer will be “Don’t do it” eight out of ten times.
Summary
I look forward to the day when work commences on self-healing data stores for permission sets that can derive intelligence and establish causality from access patterns before either auto remediating or triggering such remediations for data owners. On behalf of our long suffering end users, I am pining for an experience that does not take me to twenty different systems of record to do my job. Where i am spared the system speak and can understand and comprehend access that i am requesting in plain business language. I am looking for dynamic policy enforcement at the point of incidence. I am looking forward to the end of multi-year multi-million dollar IGA programmes that keep us all fed and watered. There are stubborn bottlenecks, but that vision is more achievable today than it ever was.
The views expressed here are based on the authors own experience and knowledge and does not represent artefacts, output or perspectives of any organisation. The text has been wholly human generated.