Nabeel Nizar
17 September ago

IGA Is on the Ropes, but UARs Are Going Strong

Updated: Feb 10

Identity Governance & Administration (IGA) entered the Identity and Access Management (IAM) domain to provide access governance. IAM lacked a simple, streamlined way for business users to assign access based on roles and attest that their direct reports' access meets regulatory requirements.


The intention was for IGA to automate the way organizations granted role-based access and conduct reviews of access to critical applications and infrastructure. But "the best-laid plans..." as the saying goes. Before long, IGA grew beyond its humble origin. Proponents declared that merging the administration of accounts and credentials, provisioning, and the management of entitlements, with identity governance — which addresses the segregation of duties, role management, logging, analytics, and reporting — would streamline the security.  


Almost 15 years later, the process is still as cumbersome as doing it on spreadsheets. Maybe it's a good thing that the IGA domain is going away, but the need to do User Access Reviews (UARs) still exists. 


Why IGA Fails to Deliver

Why didn’t IGA deliver as promised? The concept sounded good initially, but the implementation fell short. Instead of easy solutions, IGA produced complex processes that required more management and configuration than necessary. Solution creators lost sight of the original problems they intended to eliminate. How did this happen? And where does that leave organizations that simply need an efficient User Access Review process? 


The Best Intentions

Like many failures, this one began with the best of intentions. Vendors attempted to build connectors into applications to pull user access information directly from the app. The goal was to speed up the process and allow cross-application integration. Instead, customers ended up refocusing those connectors on lifecycle management, specifically provisioning and deprovisioning. IGA implementation suddenly evolved into a lengthy IT project with steps that dragged on for months, sometimes years. Connectors took several months to build, integrate, test, and deploy while the compliance users were still not getting what they needed.


Role-Based Access (RBAC)

Another distraction came in the form of role-based access (RBAC). RBAC was supposed to be the solution to simplification. Designing and building roles to make the access review process more manageable would speed things up, making reviews less complicated. Unfortunately, creating effective roles is not an easy task. In established organizations, roles can be quite complex. Thus RBAC further distracted from the underlying purpose of IGA — delivering access reviews.


Self-Service Access Requests

With none of the other attempts being effective, the final distraction to expedite the process was implementing self-service access requests. The idea was simple; if you are already building a catalog of critical access in the organization, it is reasonable to use it to kick off requests. With many organizations still struggling with RBAC, having users simply request any access they want seems like a practical solution. So what was initially intended to only be for exception-based requests then became the norm for all access requests increasing the workload for access approvers.


At the end of the day, while IGA was supposed to be a solution to automate and simplify access reviews, it got pulled in multiple directions based on ancillary functional requirements.


The Holy Grail - Simplified User Access Reviews

Does this failure to deliver mean a simplified process for ensuring ‘least privilege’ and access meeting regulatory requirements is forever out of reach? No, the solution is surprisingly simple; User Access Reviews as they were meant to be. That’s right, the impetus for the entire IGA domain is also the solution. UARs were a central feature required when the Sarbanes-Oxley Act (SOX) of 2002 went into effect. Yet, most organizations still struggle to find a simple and efficient way to complete them today.


It’s time for organizations to focus on getting UARs completed successfully. The good news is that effective tools already exist. There’s no reason to re-invent the wheel in this case. Take Identity Lifecycle Management (ILM) such as user provisioning and de-provisioning and let an Identity as a Service (IDaaS) solution handle it. Use information technology service management (ITSM) to manage access requests and offload segregation of duties (SoD) into a GRC solution.


Moving your other processes to existing solutions that have them mastered lets you focus on getting your access reviews going so you can increase your productivity and organizational agility.


Enter IDaaS, For User Provisioning

With the evolution of applications and the cloud transformation, most apps are now SaaS-based, leveraging a standard user authentication and authorization model. In other words, you could now rely on standards-based connectors for provisioning and deprovisioning. There is no longer a need for proprietary connectors having to be rolled out and integrated.


Effective provisioning into SaaS apps also required enabling single sign-on (SSO). Hence, it makes absolute sense to have that functionality handled by an IDaaS solution like Okta, Ping, AzureAD, OneLogin, or Oracle’s Identity Cloud Service. These solutions and others like them already have the ILM space built-in for user provisioning and deprovisioning. At this point, adding an IGA solution to handle user provisioning is only complicating things rather than simplifying. Real-time synchronization of accounts and passwords is best handled by a transactional sync engine. Not to mention, you can then help your organization by eventually going passwordless. But more on that in a future blog. In the meantime, keep an eye on Okta and Microsoft as they’ve quietly been working on UARs. IAM-as-a-Service will finally be here in an IDaaS offering.


Access Requests Don’t Really Need IGA 

While IGA can handle access requests, these requests are currently being standardized with ITSM solutions such as ServiceNow (SNOW). Organizations are already starting to build their catalog of applications on configuration management databases (CMDBs) and integrating the risk classifying/tagging. So it makes complete sense to move all of your access requests into something like a SNOW, Remedy, or another ITSM solution that can deliver this functionality and so much more. This removes one more piece of functionality touted by IGAs. And suppose you’re looking for an access request and review in one platform. In that case, ClearSkye provides a User Access Review module built on the SNOW platform, further reducing the complexity around IGA deployments.


With SoD Management Context is King

The problem with SoDs is that they are a governance problem best served by a governance risk and compliance (GRC) solution. While many IGA solutions have tried to converge application SoD into their offerings, claiming to break down the silos between business and IT, they often lacked a full-featured SoD solution that catered to the business needs. Their focus was simply showing that mutually exclusive roles A and B cannot belong to one person, but this was not what an auditor wanted.


Audit wants to know what functions, contained within Roles A and B, were actually executed by a user and details of the transaction. The actual transaction should come with an output of documentation from the execution used to determine the risk. For example, if user A created a vendor and paid the vendor, they want to know precisely who the vendor was and the amount paid. This helps determine if the risk is acceptable or not. Instead, IGA’s delivered a slew of “potential SoD conflict” alerts which were too much to effectively consume and evaluate in a timely manner.


Could this have been solved by building roles right from the beginning? Or maybe if everything wasn’t an exception-based request? In any case, the argument for converging SoDs into IGA was ineffective. It never truly solved the problem though it provided the risk of an SoD violation within the context of an access review campaign and helped prevent them during an access request workflow. But more on SoDs in a future blog. Meanwhile, I’d recommend checking out what Pathlock and Fastpath have been doing around access orchestration for your critical business applications.


It Doesn’t Have To Be Hard

The landscape for IT is historically dynamic; thus, organizations need to evolve how they achieve security and compliance. With UARs, this currently means including Cloud Infrastructure Entitlements (CIEM), Privileged Access, Structured & Unstructured Data, and APIs. As new technologies emerge, organizations need to be agile enough to identify the change and adapt.


In the face of an ongoing cybersecurity skills gap, organizations don't always have the resources to implement these solutions themselves. Tight budgets and a lack of skilled security professionals have many organizations struggling. Widespread remote work, constantly changing compliance mandates, and a steady onslaught of cybercrime add to these challenges. Security teams are already overburdened, yet you need to strengthen your security posture now more than ever. Modernization of legacy technology is crucial, but it can be difficult without the experience or the expertise to navigate the process.


Legion Star has the knowledge and experience to help you modernize. We'll find a User Access Review solution perfect for your organizations' needs, and handle all your day-to-day operations from creating Certification Campaigns to support. Our partnership with industry-leading solution providers such as SailPoint, SecurEnds, Saviynt, and ClearSkye means that you can expect the best experience and faster deployments. It's time to ramp up your security and get back to a compliance-driven User Access Review Process.


Click here to learn more!

289 views
Recent Posts