Attribute-Based Access Control (ABAC)

The Definitive Guide to Attribute-Based Access Control (ABAC)

Attribute-based access control (ABAC) has emerged as the next-gen technology for secure access to business-critical data. The complexities of today’s IT landscape – think cloud apps, data silos, mobile, IoT, Big Data – has exposed the limitations of role-based access control (RBAC) solutions, leaving organizations vulnerable on the data security front. By many, including Gartner and NIST, ABAC is now being considered as the dominant mechanism for the future. As part of a consortium tasked with creating a reference architecture for ABAC, NextLabs was selected by the National Institute of Standards and Technology (NIST) to help define the core capabilities and benefits of ABAC.

What is ABAC?

According to NIST, ABAC is defined as “an access control method where subject requests to perform operations on objects are granted or denied based on assigned attributes of the subject, assigned attributes of the object, environment conditions, and a set of policies that are specified in terms of those attributes and conditions.”

Attribute Based Access Control (ABAC) provides access to users based on who they are rather than what they do: for example, the business unit they work in and how they were hired. Attributes allow for an easier control structure because permissions can be based on the user’s type, location, department and so on, mirroring the physical aspects of the business. By looking at a user’s attributes—information that is already known and often stored in an HR system—ABAC permits you to express a rich, complex access control policy more simply. For example, if a user named Margret Smyth is promoted from the Marketing to management, her access permissions will be updated because her business attributes changed, not because someone remembered that she had admin permissions and took the time to update a configuration file somewhere.

The benefits of ABAC are many and there are some requirements that can only be achieved using an ABAC model. The most significant benefit is ABAC’s user-intuitive nature that hides technical permission sets behind easy-to-understand user profiles that anyone with authority can update, knowing that the user will have the access they need as long as their attributes are up to date. The other benefit of ABAC is the flexibility it gives; almost anything about the user and the business can be represented, allowing the business to think the business way, not the IT way. Which applications, what type of data users can access, what transactions they can submit, and the operations they can perform automatically change based on these contextual factors. The net effect is that organizations utilizing ABAC can make more concise decisions based on real-time operation information.

For example, using ABAC, access to business-critical data can be determined by attributes or characteristics of the user, the data, or the environment, such as group, department, employee status, citizenship, position, device type, IP address, or any other factors which could affect the authorization outcome. These attributes can be sourced from user identities, applications, and system resources, environmental attributes, they can also be retrieved from any other data source, such as IAM, ERP, PLM, employee information from an internal HR system or customer information from Salesforce, databases, LDAP servers, or even from a business partner for federated identities.

ABAC can be used in conjunction with Role Based Access Control (RBAC) to combine the ease of policy administration which is what RBAC is well-known, with flexible policy specification and dynamic decision making capability that ABAC is renowned for. Combining RBAC and ABAC into a single hybrid ABAC / RBAC (ARBAC) solution can provide a future-ready identity and access management solution capable of designing and enforcing rules based on individual profiles and business environment parameters. For example, ARBAC can be applied to enforce mandatory access control based on certain attributes while still providing discretionary access control through supercharged roles known as ‘job functions’ that are profiled based on user employment types. Alternatively, ARBAC can also be applied to implement the risk-adaptable access control concept, where access permissions can be made mutually exclusive through rules pertaining to segregation of duties for example.

The ARBAC hybrid approach allows the system to combine the IT and Business structures together. While basic access is provided automatically, the business can still provide additional access to specific users through roles that fit into the business structure. By making roles attribute-dependent, additional limitations can be put in place for certain users automatically without any additional searching or configurations, better organizing and reducing the number of access profiles that need to be kept track of. In a larger company with several business units and multifunctional employees, allowing access to be driven by attributes simplifies the process of determining correct access for users. As the result, a hybrid structure makes decision-making easier for enterprises when it comes to assigning user account access to workers. When the approach is combined with a matching user-centric control interface, IT is finally able to outsource the workload of onboarding and offboarding users to the decision makers in the business.

It is expected that, as time goes on, ABAC will become widely accepted as the authorization model of choice for businesses. A solution which can bridge the gap between RBAC and ABAC is therefore important — an indispensable, high-value software asset for the intelligent enterprise!

Resources:

• White Paper: Implementing Data Security Using Attribute Based Access Control (ABAC)

• White Paper: How to Ensure a Successful ABAC Implementation
• Datasheet: Entitlement Manager for Network File Shares
• Brochure: NextLabs Executive Overview

On-Demand Webinars:

• ABAC and Dynamic Authorization: DoD Client Story: The Secrets Behind a Successful Attribute-Based Access Control (ABAC) Deployment

• ABAC and Dynamic Authorization: Enhancing SharePoint Compliance with Attribute-Based Policies

• Brochure: CloudAz

• ABAC Practice Guide

• NIST ABAC Guide

• Business User’s Guide to XACML

The Transition from RBAC to ABAC

Role-Based Access Control (RBAC) was designed for a simpler world. Formalized by NIST in 1992, RBAC quickly became the standard for enterprises managing upwards of 500 employees. Outpacing previous models, RBAC was largely implemented within user provisioning systems, attempting to streamline the Joiner/Mover/Leaver process which gave enterprises the ability to manage access control by role, rather than an employee’s individual user ID. RBAC groups users and entitlements and can be based on business function or activity (e.g., “Accounts Payable Clerk” vs. “View data in financial systems”). Roles can be flat or hierarchical and can even include inheritance. They essentially provide an extra level of abstraction, acting as a collection of permissions or entitlements. And each role can be assigned to one or hundreds of users, greatly simplifying management.

In January 2014, NIST Special Publication 800-162: Guide to Attribute Based Access Control (ABAC) Definition and Considerations was published. Its publication significantly impacted the conversation on ABAC by providing a structured and authoritative framework for implementing this access control model. SP 800-162 did not replace RBAC but rather complemented it by introducing a more flexible and dynamic access control model.

One of the major contributions of SP 800-162 was the standardization and clarity it brought to the field. Before this publication, the concepts and implementations of ABAC varied widely across different organizations. By offering a standardized set of definitions and guidelines, SP 800-162 helped unify the understanding and application of ABAC, making it easier for organizations to adopt and implement this advanced access control model.

Additionally, the guide outlined a comprehensive framework for ABAC, detailing the key components such as user, resource, and environmental attributes, as well as policy decision and enforcement points. This comprehensive approach bridged the gap between theoretical concepts and practical implementation, providing organizations with a clear roadmap for adopting ABAC. By discussing the benefits and challenges associated with ABAC, SP 800-162 provided a balanced perspective that helped organizations weigh the pros and cons of adopting this model. It highlighted the flexibility and scalability of ABAC, while also addressing potential complexities and performance issues.

SP 800-162 significantly advanced the conversation on ABAC by providing clarity, a comprehensive framework, and practical guidance for implementation, thereby facilitating broader and more effective adoption of this access control model in various organizations. To learn more, read the NIST paper, co-authored by NextLabs, here.

Enhancing RBAC with ABAC

ABAC allows an enterprise to extend existing roles using attributes and policies. By adding context, authorization decisions can be made based not only on a user’s role, but also by taking into account who or what that user is related to, what that user needs access to, where that user needs access from, when that user needs access, and how that user is accessing the requested information. ABAC does this by using policies built upon the individual attributes using natural language. For example, a policy may be written as follows: “Doctors can view medical records of any patient in their department and update any patient record that is directly assigned to them, during working hours, and from an approved device.” By creating a policy that is easy to understand, with context around a user and what s/he should have access to, access control becomes far more robust. This functionality expands the scope of RBAC significantly. We no longer need hundreds of overloaded roles, and administrators can add, remove, or reorganize departments and other attributes without having to rewrite the policy. At the end of the day, fewer roles mean simpler role management and easier identity management. Moreover, ABAC enables the execution of business initiatives not previously possible via RBAC alone.

The Future of Access Control is ABAC

Traditionally, access control has been based on the identity of a user requesting execution of a capability to perform an operation (e.g., read) on an object (e.g., a file), either directly, or through predefined attribute types such as roles or groups assigned to that user.

Organizations implement Attribute-Based Access Control (ABAC) because they acknowledge traditional access control methods are not adequate for the challenges of the extended enterprise, including how to safely share confidential information and adhere to regulatory data requirements. ABAC allows you to design controls around the characteristics of data that warrant protection in the first place; this could be the type of content, project, security clearance, and so on. Attribute-Based Access Control also takes into account information about the user and the environment, including location, position, device, and network. Controls can be written as simple versions of information-sharing policies. Once written, a single policy can be deployed across multiple systems and hundreds of devices. Unlike traditional controls, which require permissions to be defined statically before an access attempt occurs, ABAC rules are evaluated dynamically with attributes presented at run-time. The attributes can come from multiple sources – even sources external to an organization. Plus, enforcement adapts to risk levels automatically. For example, if the classification of a document changes, or a user’s team membership changes, access rights are automatically adjusted. No need to request new roles or update permissions. request new roles or update permissions.

An example of an access control framework that applies ABAC principles is the XACML standard.

What is XACML?

XACML is an OASIS OPEN standard. XACML stands for “eXtensible Access Control Markup Language”. It is an XML-based language designed specifically for Attribute-Based Access Control (ABAC). The standard defines a declarative fine-grained, attribute-based access control policy language, an architecture, and a processing model describing how to evaluate access requests according to the rules defined in policies.

The NextLabs Approach

At the heart of the NextLabs portfolio is the Control Center Policy Management platform powered by our patented attribute-driven 4GL policy engine, dynamic authorization, and Attribute-Based Access Control (ABAC) technology.

Dynamic authorization is a technology in which authorization and access rights to an organization’s network, applications, data, or other sensitive assets are granted dynamically in real-time using attribute-based rules and policies. The policy is powered by a contextual 4GL policy language that enables business users to create domain-specific policies in plain English.

NextLabs’ Control Center provides policy management, dynamic policy evaluation, enforcement services, attribute management, integration points, audit reports, and automation tools to allow organizations to centrally administer, deploy, and enforce identity-aware data-centric ABAC and information control policies. Policies are centrally managed and decoupled/externalized from the protected application, which means they can be modified without requiring code changes or application downtime. This enhances organizational agility and leaves the company in a much better position to respond to always-changing business conditions and regulatory environments.

The solution can be grouped into the following Control Center components:

• Digital Policy Management – Web-based GUI to digitize information control, compliance, and data security requirements into policy with facility for policy lifecycle management and governance.
• Central Management with Delegated Administration – Web-based central management console to perform most day-to-day administrative tasks, including user management, configuration management, server management, and policy governance. The built-in delegated administration model allows ownership and administrative tasks to be delegated to individual business units to enable collaboration and more scalable policy definition and management.
• Attribute Management – Capability to enroll and manage attribute, sync existing attributes from various internal and external attribute sources into the Control Center attribute store periodically, and dynamically retrieve attribute values from any sources in real time using built-in connectors and APIs.
• Dynamic and Real-Time Policy Evaluation – Distributed Policy Engine to dynamically evaluate policy to determine data access and entitlement no matter where data resides, using runtime attributes presented at run-time. Policy Engine works in offline mode and is available in multiple form-factor: server, client, and cloud.
• Identity and Data-Centric Enforcement – Automate identity and data-centric information controls – whether its user-driven, program to program, machine to machine, or API-driven.
• Reporting and Monitoring – Report Server and web-based Reporter application aggregates audit log, provides centralized reporting, alert, and monitoring for risky access activities across applications; thereby enabling single-pane visibility into information access, usage, and compliance risks.
• ICENET fault-tolerant & secure communication – Secure and async communication between Policy Server and Policy Engine for policy distribution and logs aggregation with offline support
• Software Development Kit (SDK) – NextLabs’ SDK enables the integration of custom applications with the NextLabs platform. Through this SDK, organizations can enforce security, governance, and compliance policies for their custom applications, just as they can for their “off the shelf” applications, using Control Center as a centralized policy enforcement platform.

NextLabs Control Center is available both as a SaaS as well as an enterprise software license. Control Center is built-on a cloud-native architecture and provides the full benefit of container infrastructures such as auto-scaling, elasticity, resiliency, auto-deployment, and seamless upgrade.

Highly Scalable 4GL Based Policy Engine

NextLabs Policy Engine is a distributed policy decision point (PDP) that can be deployed in a private, public, or hybrid cloud architecture. Its high scalability policy evaluation engine supports offline evaluation, dynamic attribute fetching, and in-memory policy result and attributes caching for super-fast policy evaluation.

NextLabs Policy Engine is built on a XACML-based 4GL policy language called ACPL with web-based policy development and management GUI that makes it easy for non-technical users to define, test, deploy, and review policies in an English like natural language syntax. It eliminates much of the complexities associated with authoring policies in XML, which requires a considerable amount of programming knowledge. Policies written in ACPL are simple to learn, understand, write, and maintain. That means business users can create and maintain policies on their own without needing a technical expert.

Control Center’s Policy Engine provides a flexible Policy Component Model that allows policy administrators to define reusable policy and policy components that can be leveraged by business users to translate data security, regulatory and business requirements into digital policies. Each policy comprises a set of predefined building blocks called policy components that are linked with operators and other logical constraints, and then further refined by contextual conditions. Implementing policies involves:

1. Creating a policy model for subjects (user, hosts application, and any), resources, and operations,
2. Creating reusable policy components, and
3. Using policy components to construct policies using Policy UI.

The policy model determines the subject types (user, host, and application) and resource types (transactions, data sets, documents, and other resources) that can be covered by policies. Policy components represent categories or classes of entities, such as users, resources, and actions. Policies use components as building blocks to represent rules that control information access and use.

The web-based policy authoring GUI – Policy Studio provide an easy to use and drag-and-drop UI to make authoring reusable policy components and complex policy quick and easy. It allows a policy author to create reusable policy components to be used in policies. Policy Studio also provides detailed policy audit, version history, and reporting features making it simple to audit or review policy changes.

All policies and components are managed across their lifecycle-from draft to deployment to deactivation or deletion. The attribute-based access control lifecycle management features ensure that each policy is validated and approved before deployment to production systems. Additional lifecycle management features include delegated administration, versioning, approval workflow, and full audit trails.

Extensive Support of COTS Applications Out-Of-The-Box

NextLabs provides the most extensive support of Out-Of-The-Box (OOTB) Policy Enforcer (PEP) for COTS application covering both structured and unstructured data environment to accelerate time to market and allow organizations to rapidly meet their security and compliance objectives.

NextLabs’ suite of the OOTB Enforcers protects business-critical application data at both the application layer and the database layer. Moreover, when data leaves an application in an unstructured form (such as files), NextLabs’ Rights Manager automatically classifies and protects these data files with Enterprise Digital Rights Management (EDRM).