Re-Imagining Authorization and Access Management

I’ve been in many conversations, where customers of existing access management products - whether they deal with workforce access, privileged access, governance or compliance - express their frustration with the products. There are, of course, grades in how much dislike is expressed, but it’s a theme. This stands out in contrast to single sign-on or MFA products, which are generally well-liked by customers for their seamless and consistent delivery that leaves them feeling manageable and not time consuming.

My colleague, a former employee of a different security technology company, told me “I was once cat-called in an airport because of the logo on my backpack and someone’s love for our product!”

The lesson here is that access management products should be business enablers and accelerators that give back time to customers, with the potential to be loved like MFA or SSO products. So what is impeding the enthusiasm for access management or authorization, PAM, IGA and other identity tools?

Model Limitations Drive Complexity

When you get into the details of recent identity technology product announcements, various features or integrations come up, and in general it seems to be that these products are hoping to reduce solution complexity. Yet, if you look into how these new features are built, one sees a pattern that they are relying on the same relatively static and legacy models such as RBAC to address what are clearly dynamic access requirements that require continuous updates.

Modern day access management challenges need to operate at the speed a modern enterprise does, which really means the technology should be built on a foundation of dynamic, automated controls for how individual access decisions are made.

This is not to say that RBAC doesn’t work or should be thrown out - it is highly effective in providing birthright access, or the general access and systems you indisputably need. But conventional controls associated with RBAC and ABAC are not expressive enough to deal with the complexity and dynamism many systems or access management scenarios require.

Despite this, RBAC is used like a hammer to strike every access management problem with, like:

• Need to separate access to EU and US customers? Add two roles!
• Need to manage access to production AWS accounts? Add 5 roles to each one!
• Need to restrict customer data access in your back office tools? Create a role for every customer!

Even in the most sophisticated ABAC deployments, policies need to be managed and enforced in a number of places in every application that uses it. In addition, one also needs to manage the data sources for the attributes. As a result, managing ABAC can feel like trying to use 5 RBAC hammers at once!

If RBAC is the hammer that people try to hit every access management problem with, ABAC is like using 5 RBAC hammers at once!

Both these approaches are flawed because of the limitations of the models, their dependence on manual processes, static data, and insufficient centralization leading to additional policy work in apps or other tools to control more granular access.

New Models are Needed

The challenges identity teams face are steep: Protect growing, fragmented identity perimeters; Juggle cloud and on-prem environments; Manage access across hundreds or thousands of applications; And manage an enormous user population. These challenges cannot be met by new products that follow the same models that have been disliked by teams for over a decade, even if they have fancier user interfaces. What really needs to change is the underlying approach to how identity technology solves access management.

Any new approach to address modern access management challenges must:

• Provide Zero Standing Privileges: The attack surface is getting far too broad to allow users to have standing privileges to anything. As we’ve seen in recent high-profile cyber attacks, even a single compromised identity can be catastrophic when combined with over-permissioned users.
• Automate Permissions Elevation and Reduction: It’s not OK to say “use our IAM product’s fancy new automation feature to trigger a workflow that will migrate identity data from one system to another.” That is not automation, that is a basic integration. The kind of automation required to support zero trust architectures is one that doesn’t require administrators to manually check boxes or take steps to adjust access. There is a wealth of data in existing business systems that can and should be leveraged to understand what permissions are appropriate for any user at any given point of time.
• Centralize Policy Management: An organization may have hundreds, if not thousands, of apps which are often selected and managed by line-of-business teams. For an identity team at an enterprise of even a hundred employees, anything that requires updating policies within each app will not scale. Identity teams can streamline their programs with centralized policy management, so that policy changes can be executed promptly and consistently across applications.
• Make Policies Human-Readable: Any policy management system that decouples what can be readily understood by administrators or compliance officers from what is actually interpreted by the system is bound to cause a disconnect between stated policy and reality. Innovative data models can make policies inherently readable, so that what is understood by the compliance officer is actually the code that implements the policy.
• Bring Accountability through Auditability: A tragic side effect of RBAC and ABAC is that actual access is hard to audit. This leads to organizations certifying the membership or entitlement data instead of certifying that actual access complies to policy. Unfortunately, manual certification is fragile, error prone, time consuming and merely a snapshot in time. So when a breach occurs or an audit finds a discrepancy, it is hard to understand where the failure occurred and why. New models must provide full accountability by auditing every access decision in an easy-to-report way.

Enter, SGNL

SGNL was born out of the frustration with the status quo, and the inability of the industry to provide more than incremental solutions. Our continuous access management approach checks all the above described desirable qualities.

To see these attributes in action, request a demo!