Compliant Access By Design

Compliant Access by design is the capability to map out in advance the position appropriate access for employees, partners, and customers and the risk policies that will measure and ensure continued compliance. Defining position appropriate access for a large organization can be a daunting task and keeping it up to date even more so. However, defining this also acts as a guideline.

Absent such a guideline, IT organizations are forced to resort to costly and inefficient manual processes. Not only are these the wrong approach to take, but they will lead to even more, and greater, challenges in achieving Compliant Access. However, and crucial to note is that, defining and efficiently maintaining position appropriate access will only ever be possible using Role-Based Access Control (RBAC).

RBAC is one of the primary keys to an effective IAM security system and, together with roles, optimize the delivery of Compliant Access. Within RBAC, roles are bundles of access which are assigned to users and linked to an organization’s policies. Roles provide a definition of what access level is both needed and appropriate for each type of employee or supplier that must be provisioned across an organization’s on-premise and Cloud systems.

It’s not hyperbole when we say that the flexibility and power of an Identity and Access Management solution’s RBAC model can make or break many projects. So much so that if poorly designed, no amount of consulting or engineering will lead to a manageable role model and with the likely consequence being that the RBAC system itself becomes the source of project failure. In contrast, EmpowerID’s RBAC engine is by far the most sophisticated available and is often cited as the greatest single contributor to the success of customer projects. This is because EmpowerID does it differently and, for modeling role-based permission policies, offers a 3-tiered RBAC model comprised of a Business Role tier, a Functional Role tier, and a Technical Role tier.

The top, or Business Role, tier describes a user’s position in the organization. It’s obtained via a combination of their position as well as the hierarchical organizational location that represents where in the organization or in which context the user performs their Business Role.

This is visualized as two trees with people assigned to one or more Business Roles in combination with an organizational location. This “two-trees” or “polyarchical” RBAC approach, solves one of the general, fundamental weaknesses of RBAC.

Traditional RBAC models lack the organizational location aspect that Business Roles offer. This lack of component forces the role design to accommodate and create all the possible variations of that Business Role or job position: this is what’s known as “role explosion” and is the big problem with traditional RBAC systems. Often organizations who have become shackled with such an inflexible RBAC system will end up managing thousands of roles and be forced to create additional roles for each simple access case.

As an example, let's consider how both models address managing resource access needs for an employee common to banking institutions, the Teller.

Bank tellers perform similar functions and have access to similar systems as part of carrying out their daily duties. In such a case, using RBAC to manage access sounds relatively straightforward:

1. You create a "Teller" role and assign all tellers to the Teller role.
2. You then assign the access required to the Teller role.

At this point, only one role is needed and everything appears fine. However, what if the banking institution has branches located in multiple cities, regions and even countries? Although each teller needs access to a shared pool of resources, by their location, each would also need access outside the shared pool. Tellers in New York would require access specific to New York, but not have access to London or Sydney; tellers in London would need access to resources in London, but not New York or Sydney; and, tellers in Sydney would need access to resources in Sydney, but not New York or London.

In this case, using the same Teller role for all tellers is problematic because doing so would create a "super role," giving each teller access to resources beyond their scope, violating an organization’s risk policies and the concept of Compliant Access. Figure 1 shows what typically occurs, with a business role being created in each location.

Fortunately, EmpowerID’s Business Role and organizational location RBAC model solves this challenge for you. As shown in Figure 2, in this particular scenario, it would require only one Teller Business Role. EmpowerID allows you to differentiate the access assigned to a Business Role based on the organizational location of the entitlements. In this way, tellers in London, New York, and Sydney can all have the same Business Role without having access to each other’s entitlements.

As shown in Figure 2, with EmpowerID all that’s required is one Teller Business Role scoped on assignment by organizational location.

Business Roles represent job positions within an organization and are used to bundle and report appropriate Compliant Access. However, not all access is job based and organizations today are composed of cross functional teams that come together to work on initiatives or projects. Also, to enable the performance of specific tasks within a company’s business processes, the access assigned to Business Roles is commonly grouped into dependent bundles. For these reasons, a flexible middle layer comprised of Functional Roles is used. Functional Roles represent the tasks in a business process, teams, cross department collaborations, or projects that people might be working on.

However, in EmpowerID, we use the term Management Roles (rather than Functional Roles) for this layer. This middle layer, or tier—the Management Roles tier—is looser and more flexible than the Business Role tier. This is because, unlike Business Roles, Management Roles are not so rigidly tied to a Person’s job within the organization. Moreover, and because they act in the middle layer, it may help to think of Management Roles as a type of flexible glue that supports access requests, role ownership, and many other types of temporary access.

The bottom tier in the EmpowerID RBAC model is comprised of Technical Roles known as Access Levels. Access Levels are the system or application-specific roles used to connect the policies in EmpowerID to the actual permissions those policies grant to resources contained within external systems or applications.

An example of an Access Level would be the Mailbox Publishing Editor Access Level, which would grant permissions to a mailbox delivered as ACLs within Office 365. Access Levels can grant these “Rights” within external systems and “push” them out via the provisioning engine. For example, a special Access Level named Member grants the user group membership for groups or applications roles in any external managed systems.

It’s these Access Levels that define Compliant Access within EmpowerID itself. In this regard, Access Levels are bundles of low-level permissions knows as “operations”. When any users logged into the EmpowerID web console or through its APIs perform any tasks, or actions, these actions are evaluated to determine if they are entitled to perform that actual operation. This evaluation can be by any assignment path against the resource or context in which the user is requesting access.

For example, one action could be requesting to be a member of an SAP Role in the IT Shopping cart, whereas another could be to terminate a user account in a Microsoft Azure tenant. If the user is authorized to perform that operation, subsequent, additional actions can take place; however, if they lack authorization, further actions and operations will be denied. Management of the EmpowerID RBAC model itself is governed by these same low-level checks with RBAC management activities represented as operations.

“If defining and maintaining a role structure is critical to Compliant Access Delivery, how do organizations tackle the overwhelming challenge of getting started and generating their initial roles?”

Without the right tools and techniques, role-based security projects can easily become delayed as organizations work to define their initial set of roles. However, and unlike how other software does it, EmpowerID’s approach leverages data from your existing systems. It does this in 2 steps: first, to create an initial structure; second, our sophisticated machine learning algorithms then uncovers the existing “implicit” roles already in use within your organization by analyzing current access assignments for users.

These existing roles then become the starting point for defining standardized access roles and adopting RBAC. However, the first step in this process is to inventory the data from all your key systems to discover and outline the initial structure.

Establishing Business Roles and organizational locations is usually the starting point for EmpowerID projects. The best sources for this data are usually an organization’s HR or Human Capital Management system (HCM) and Active Directory. HR systems such as Workday, SuccessFactors, or SAP HCM maintain a rough organizational structure as well as positions occupied by all employees. Even when only available as user attribute data these systems still provide an invaluable source for initial Business Roles and organizational locations and to get the analysis rolling.

EmpowerID’s out of the box connector model supports inventorying this data into what are known as “External Roles” and “External Locations”. Once inventoried, EmpowerID knows which external roles and locations exist within the organization and which users are assigned at any point in time. Note: Active Directory is often a rich source for the organizational locations as some portions of the AD OU tree also represent a hierarchical view of the company.

Once this external data resides within the EmpowerID system, it can be used to generate an initial Business Role and organization location tree. EmpowerID does not require a one to one match as role and location mapping technology allows for the Business Role and Location trees in EmpowerID to be designed independently of the actual external structures, which may be more rigid and not optimally designed for managing access. However, when mapped, users are automatically and continuously associated with the proper EmpowerID Business Roles and Locations based on their current assignment to external roles and locations in those systems. This is important to note as this is a key driver in EmpowerID’s automated and continuous Compliant Access Delivery. Any subsequent changes in the authoritative system will trigger a reevaluation and adjustment of Compliant Access for each user. This now happens automatically and without any laborious or expensive manual administration or intervention.

For organizations working with consultants and other role modeling tools, EmpowerID supports leveraging the roles and locations designed in these systems. The Role Modeling Inbox integrates external role and access management with EmpowerID by providing a set of inboxes into which roles and access changes can be published. Configurable rules within EmpowerID determine if these upstream decisions are automatically put into effect or must go through workflow approval processes before becoming active.

Most organizations at this point in the role design process will have an initial Business Role and organizational location tree. Unfortunately, for many, this is where the initial setup process finishes. They will then go into production creating additional Management Roles as needed. They can also then create new policies for assigning compliant access and provisioning to managed systems. The problem here is that all current user access assignments are static and not managed by this structure. This means that when a user moves within the organization and their Business Role and Location changes, the static access will remain unless manually removed.

For our own EmpowerID process, at this stage, we have a little more. One requirement of Compliant Access is that the entitlements granted are appropriate for the position. To recap, at present, we currently have a rough skeleton of the Business Roles within the organization and also know which users occupy which positions and within which portion of the company. What we are currently missing is a link between these positions and the access currently assigned to the actual users.

The users are already assigned to Business Roles and Locations and the system has an inventory of the entitlements they hold from each of the already inventoried systems. What is required to optimize and proceed with Compliant Access Delivery is to reassign these direct user-assigned entitlements to the appropriate Business Roles and organizational locations. Doing so will convert them from individual static assignments that lack any business context or justification to full-business-context role-managed assignments.

Attempting to do this manually would be an impossible task and is why, specifically, we built our own analysis engine. EmpowerID’s engine supports both the more common "bottom-up analytical" analysis, where using machine learning entitlements are used to uncover and visualize clusters of access, as well as the new "top down analytical role mining" approach.

In top-down analytical role mining, an organization's existing Business Role and organizational location hierarchy is used as the basis of the analysis. This structure will be conditional in that it will need to already exist, i.e. will already have been gathered from an external system(s) such as SAP HCM, it will be maintained independent of the IAM system, and it will operate on its own course. EmpowerID uses analytical techniques to take the inventoried direct entitlement assignment data of exactly who has access to what and will then try and optimally fit these assignments on the Business Role and Location tree.

An algorithm starts with each entitlement at the bottom of the two trees (most specific roles and locations) and then crawls up each tree until it finds the highest point that entitlement could be optimally assigned. At this high point, all of the people in that role and location and their children would be present. It is here that the entitlement could now be assigned, by Role and Location, producing no net change, but now making the entitlement role-managed. Furthermore , fuzzy logic matching can now be further employed to relax the tolerances to help optimize placement, i.e. instead of looking for a 100% match this can be lowered to a 90% match. It’s a process of trial-and-error. Once a desired match is found, the customer can then choose to publish this as a managed assignment. Once assigned, it is now controlled and managed by RBAC.

After completing top-down role mining, much of each user’s access will be delivered and controlled via Business Roles. The top-down model is effective for optimizing access based on what a person does within an organization. The remaining unoptimized access assigned to users consists of less structured team or matrix-based access and exceptions. This access can also be optimized using a technique known as bottom- up analytical role mining. Bottom-up role mining is a multi-step process that involves creating, running and analyzing "Role Mining Campaigns."

Role Mining Campaigns analyze entitlement and user data using powerful machine learning algorithms to produce optimal "candidate roles" containing combinations of people and entitlements. These are then analyzed and accepted or further manipulated to create subsets of combinations. Once candidate roles are accepted, they can be published as standalone Management Roles, mapped to Business Roles and Locations, or used to create new Business Roles and Locations.

Once an organization has generated its roles, the burden for maintaining accurate membership can be alleviated by employing a Dynamic-Roles model. This means that roles, when possible, are assigned to users dynamically by attribute-based policies. EmpowerID leverages this technique extensively to maintain a user’s correct Business Role and Location assignments based on their assignment to external roles and locations in the authoritative systems, such as HR. This model also supports automation of assignment to other role types based on sophisticated attribute-based policies known as Query-Based Collections.