Eliminating Toxic Combinations with ABAC

Axiomatics   ·   Monday, February 29th, 2016

Over the past 20 years, the IT road map has changed substantially. Cloud computing, smartphones and online services are part of our daily routines. And access control has been predominantly managed with a role based access control approach – which is proving to be static and thereby not adequate for today’s dynamic IT environment. The time is now to look beyond RBAC for access controls, and use a dynamic, intelligent model. It’s time for ABAC.

From static roles to dynamic rules

The Role Based Access Control (RBAC) promise was to simplify administration of permissions for large numbers of users. RBAC models categorize users based on similar needs and group them into roles. Permissions are assigned to roles rather than to individual users, and the objective is to reduce the number of assignments. The more users and permissions one single role captures, the greater the administrative efficiency gains.

Delivering on that promise is however difficult or impossible. In reality, the authority varies not only between individuals but also for a single user over time. The role concept uses approximations for the sake of simplicity; which means at any point in time, permissions assigned to individual users by means of roles will deviate from an ideal state.

Approximation comes at a cost. A never-ending struggle to refine role definitions and to achieve a sound segregation of duties approach must be maintained. This struggle has become accepted as a necessary evil rather than recognized as the effects of poorly designed access controls. The illustration reveals the problem.

Users in the middle assigned both role 1 and 2 represent an unacceptable fraud risk. They can potentially subvert business critical processes. They likely do not need the permissions that combined create toxic combinations. But removing any of them will inflict on the ability of users in the other two groups to do their jobs. Thus, either you live with the risk, or you start a new role engineering project. And you accept having to do so over and over again as this heavy cycle repeats itself and the roles themselves continue to fail.

Attribute Based Access Control (ABAC)

Ideally, users should be assigned permissions which represent a true reflection of current business policies and rules, risk mitigating precautions and context-related security measures.

This is what the next generation entitlement management, Attribute Based Access Control (ABAC), delivers. ABAC implements business rules in context-aware and risk-mitigating policies. Rules combined in policies and policy sets become an exact definition rather than an approximation of authorizations based on business rules. They use attributes to describe when access should be permitted or denied. Attributes identify the user, the information asset, the action and the context in which access is being made.

The move from roles to rules thus allows the implementation of precise and fine-grained authorization. This in turn also lays the foundation for dynamic and context-aware authorization. Rules are interpreted in real-time while considering context-related attributes such as risk indicators, time and location, user behavior patterns, the relation between the user and the information asset, etc.

Where RBAC provides coarse-grained, predefined and static access control configurations, ABAC offers fine-grained rules which are evaluated dynamically in real-time.

Global scaling beyond old domains and firewalls

In legacy access control models the user population as well as the sensitive information assets were assumed to be known in advance. In modern globally- connected environments this is not necessarily true. A trusted identity provider may vouch for a previously unknown user’s identity and provide descriptive attributes. But the user is not known in advance and cannot in advance be mapped to roles in the target system. It is therefore difficult or impossible to manage access in information exchange across domain borders.

ABAC, by contrast, can use a broad set of descriptive attributes which are evaluated at run-time. ABAC does not depend on user IDs being known in advance. It easily supports scenarios of scaling both horizontally and vertically for secure information sharing across the internet.

Leveraging RBAC investments made

ABAC rules mandate that permissions be granted or denied depending on the values of named attributes. Existing roles become authoritative “subject attributes”. Roles therefore retain their value and serve as important privilege-giving attributes which help define the user when ABAC authorizations are made.

In this sense Attribute Based Access Control (ABAC) leverages investments made in RBAC models while moving beyond. The problem with the toxic combination in the example above could be resolved without a change in the role concept. An ABAC rule can state that “yes, if you have both role 1 and 2 you may use permission 1.C provided you have not already used the permission 2.C on that same information object since the combination would constitute an SoD violation”. Thus, roles are maintained and used but their limitations have been overcome.