What’s ABAC? How Attribute Based Access Control Works

Multi-cloud environments are getting plenty of buzz in recent years. It’s no wonder, really, that increased flexibility, risk mitigation, performance optimization and compliance adherence associated with the practice have drawn in new muli-cloud evangelists across the industry.

For all the great benefits multi-cloud offers, it does present one significant challenge: how do you ensure a single point of control while establishing consistent security policies for all users?

Your answer might lie in Attribute Based Access Control (ABAC). 

Let’s explore how IT departments leverage this technology to ensure security consistency across complex environments.

Why organizations are turning to ABAC policies

Traditionally, access control policies have followed role assignments — the Roles Based Access Control (RBAC) scheme. Users with specific role assignments get to access services, tools and information they need to complete their jobs. 

The obvious issue here is that multiple roles can have overlapping access privileges when they share (at least some) similar responsibilities. In such a situation, the RBAC policy assumes identical permissions for users of different role groups. In a worst-case scenario, this means that overlapping permission levels can allow an unauthorized user to take advantage of this permission leakage.

To tackle this problem, we turn to a policy-based alternative: Attribute-Based Access Control (ABAC), which utilizes request attributes to determine whether a user qualifies for access permissions.

ABAC refers to the policy-based access control mechanism that evaluates the characteristics of the access request, context attributes, resource attributes, and entity and action characteristics against organizational security policies. 

How ABAC works

IAM is the practice of making sure people have access to what they need, and can't access things that they don't need. It's part cybersecurity, part operational efficiency. There are a few ways to action on an IAM policy — ABAC is one option, here’s how it works.

On a technical level, the policy rules assigned to the ABAC identity and access management controls are boolean functions and can change dynamically to account for changing organizational policies.

An ABAC policy checks that all request attributes match predetermined rules before granting access. These attributes generally include:

• Subject: The user requesting system or resource access to carry out an action.
• Resource: The asset, file, application, API, or server the subject is attempting to access.
• Action: What the user is attempting to do with the resource (e.g., read, write, edit, copy or delete)
• Environment: The broader context of the request — checking for details like the time and location of the request, the device used, and the encryption or communication protocol used.

Security policies predicate over all of these values — if and only if all attributes collectively comply with all IAM policies, the ABAC returns a positive approval to the user requesting permission. 

The context-aware nature of this IAM model is suitable for cloud-based environments where IT services are provisioned dynamically and often in constantly changing states. In practice, ABAC allows administrators to apply security checks at extremely granular levels.

Security principles achieved through ABAC

Modular control over these values can allow organizations to ensure compliance, and enforce key security principles. ABAC IAM helps enforce two major security principles:

The principle of least privilege

The principle of least privilege access refers to granting only the authorization necessary to complete a task. Enforcing this principle requires the IAM control to execute two capabilities:

• Characterizing the request, which requires the IAM system to collect attribute values that accurately describe the nature of the request. 
• Identifying the minimum set of permissions applicable to the request, which sets the scope of assigned permissions. 

According to the least privilege access principle, the approved permissions should only grant the bare minimum resources and access necessary to complete the task. The challenge here is to accurately map attributes to permissions in a way that minimizes permissions overlap and leakage between other users, roles and authorizations — luckily, this is exactly where ABAC shines.

Separation of duty

It’s not at all uncommon that a user may require access to a resource only to complete one part of the larger process workflow. That workflow is likely distributed across multiple levels of permissions. 

The principle of separation of duty enforces limitations to the scope of permissions approval such that users can only complete a part of that process workflow. This requires other users with different (and higher) levels of permission authorizations to complete or proceed with the process workflows. 

In other words, the process of completing a critical task is separated into multiple steps. Each step requires a different set of permissions and no individual user can perform all process steps on their own. This separation is applied using IAM controls such as ABAC that extract attribute values corresponding to the request, its context, object entities and environment, among other security policy variables. 

The key motivation here is that an individual user account may be compromised by way of an external cyber-attack or some malicious intent. As long as the compromised user is not handed the key to all critical resources and capabilities, they may not complete sensitive operations without obtaining authorization, support and contributions from other users.

Benefits of ABAC policies

The power and flexibility of ABAC comes down to the fact that request attributes are easy to collect and even the most complex policy rules can be succinctly specified using logic-based functions. In fact, such functions are only limited to the language itself. 

The ABAC model may enforce IAM controls as a propositional logic problem: put simply, ABAC is a matter of understanding which attribute-value pairs satisfy a predefined security policy. If the attributes corresponding to a user request satisfy the requirements of a policy, the permissions are granted.

This is of course different from any Role Based Access Control IAM system that accounts for role assignments — often without consideration of the attribute-value pairs that carry a significantly richer knowledge about the request nature and its context.

Zooming out, ABAC policies present quite the list of benefits:

• Detailed access control: The ability to consider multiple attributes in determining access decisions, allowing organizations to develop complex access constraints.
• Compliance and risk management: The fine-tuning afforded by ABAC policies allows for purpose-built access rules focused on maintaining compliance.
• Policy centralization: Because policies are defined by attributes, not roles, changes to policies are scalable and modular, effectively eliminating the rigid and confusing overlapping that’s so common in role-based policies.
• Dynamic access control: Access attributes aren’t just static — these policies consider request time, location and more.
• Interoperability: Attributes can be defined alongside already implemented IAM systems, allowing for increased flexibility in some IT infrastructure edge cases.

Challenges of implementing ABAC

Unsurprisingly, the flexibility of ABAC itself also leads to a few challenges, some of which include:

• Complex policy designs: ABAC policies can become quite complex — designing and maintaining such policies requires focus on combinations of potentially incredibly granular attributes.
• Attribute management: Lack of standardized attribute definitions causes discrepancies in their use across siloed and geographically disparate departments requiring their own sets of security policies.
• Scalability: Organizations using ABAC may choose to enforce a complex and inefficient ABAC model requiring repeated manual interventions and therefore losing scalability. 
• Policy management: The ongoing maintenance ABAC policies require may be cumbersome. Strong ABAC policies are backed by clear processes for administration, versioning and lifecycle management.
• Standardization: ABAC lacks a standardized model for enforcing such a propositional logic, and there may not be a well-established attribute definition to evaluate against specific security policies

Many of the challenges of ABAC policies share direct relations with the benefits. Because ABAC is so flexible, it requires diligent planning, governance and implementation strategy to minimize potential issues or capitalize on benefits.

Assessing attribute based access control

The key objective here is to ensure that the functional advantages of ABAC controls remain intact while establishing a consistent, scalable and efficient IAM model. 

As a starting point, your organization can work toward developing a set of holistic and consistent security policies and attribute definitions, which can then run through an automated propositional logic program that can be adopted by all user groups at scale. By prioritizing constraints such as separation of duty and least privilege access, your organization can achieve new peace of mind in compliance and IAM functionality — as long as you bear in mind the many potential pitfalls of using such a flexible approach.

What is Splunk?

This posting does not necessarily represent Splunk's position, strategies or opinion.