Introduction

In navigating the traditional silos within organizations, I've encountered a common challenge - nomenclature. Remarkably, the interpretation of a single term can drastically differ from one person to another, often between business and IT. This discrepancy is especially evident when individuals from the identity space collaborate with those immersed in separation of duties (SoD) and compliance, who have spent their entire careers working within business applications such as SAP and Oracle. This intersection of domains signifies an ongoing convergence of IAM, IGA, and GRC or SoD Monitoring industries. As an amusing exercise, ask a group of these security experts to outline 'fine-grained' and then sit back and watch the fun ensue.

I see similar challenges when the topic of access control models comes up. What is a policy-based access control (PBAC), attribute-based access control (ABAC), or role-based access control (RBAC) model? The terms "policy" and "attribute" are leveraged in the PBAC and ABAC models. Technically, they can extend or facilitate RBAC models. I understand how these topics can be confusing. In this blog, I'll dig into these concepts more while highlighting the implications for IGA, automation, and compliance.

Attribute-Based Access Control (ABAC)

ABAC is a dynamic and context-aware approach to managing access rights. It's often associated with Access Management and authentication, serving as a cornerstone in the principles of least privilege and zero trust. ABAC is a logical access control model that is distinguishable because it controls access to objects by evaluating rules against the attributes of the entities (subject and object), actions, and the environment relevant to a request, as defined by NIST.

ABAC incorporates a variety of contextual attributes into its access control policies, such as geographical information, time, and device info. For instance, consider a multinational corporation using ABAC to control sensitive business data access. A policy can be established that permits only 'Regional Managers' to access specific financial reports and only during business hours from secured corporate network locations. This policy is evaluated at runtime, ensuring that access is granted or denied based on the most current information, including the context of the access request.

ABAC is also the backbone of dynamic authorization concepts, granting access in real-time based on pre-defined conditions. ABAC is especially beneficial in large, diverse environments where access requirements are intricate and frequently changing. By incorporating context into access decisions, ABAC offers a granular and secure approach to access control.

Policy-Based Access Control (PBAC)

PBAC is a dynamic access control model that leverages policies to manage identities, respective access, dynamic ownership, and more. These policies, formulated using a combination of attributes and logic, serve as the connecting thread between various access control models. PBAC allows your security model to seamlessly adjust to shifting business requirements and dynamic workforce. By integrating business terms and conditions into access decisions, PBAC offers a unique, effective, and adaptable approach to managing access in today's rapidly evolving business environments.

The true power of PBAC lies in its ability to automate IAM and IGA processes while enforcing compliance. Traditionally, the IT teams battle with SLAs, audit findings, and often time-consuming manual processes to actively manage identities and access acros s the organization. While workflow helps offload some of the burdens, the advent of PBAC allows for many of these processes to be automated, reducing the workload surrounding joiner-mover-leaver (JML) processes, streamlining access certifications, and reducing the need for access requests.

While PBAC can automate and streamline operations, it may also lead to complexities with growing policies, overlapping assignments, and risks. It's vital to govern these policies through regular reviews and to include SoD and sensitive access reviews as preventative and detective access controls, maintaining a balance between efficiency and security.

Role-Based Access Control (RBAC)

RBAC, as defined by NIST, is a model for controlling access to resources where permitted actions on resources are identified with roles rather than with individual subject identities. Role permissions may be inherited through a role hierarchy and typically reflect the permissions needed to perform defined functions within an organization. It's a straightforward and efficient way to regulate access to resources in large organizations with many users and systems.

In RBAC, permissions are associated with roles, and users are assigned to these roles. For instance, in a corporate setting, the 'Finance Manager' role might have access to financial reports, budgeting tools, and confidential financial data. When a new finance manager is hired, they are assigned the 'Finance Manager' role, which automatically grants them access to the necessary resources. This eliminates the need for manual assignment of permissions for each user, streamlining the access management process.

RBAC is a static model, meaning the roles and their associated permissions are pre-defined and do not change dynamically based on context or other factors. While this makes RBAC a reliable and predictable access control model, it is often limited and tough to maintain. Roles often become large, over-assigned, and a primary culprit for organizational access risk. Inherently, it needs more flexibility to adapt to changing business needs.

How Are ABAC and PBAC Models Different?

ABAC and PBAC are both forms of dynamic access control. Still, they operate differently based on runtime evaluation and policy enforcement, respectively.

In an ABAC model, access rights are evaluated in real-time, considering various contextual attributes like the user's position, location, action, device, and environmental context. For instance, employees may attempt to access a financial resource while working long hours from home. The ABAC system would assess this contextual information at runtime. Based on this evaluation, it might enforce an additional layer of authentication, such as multi-factor authentication (MFA), before granting access to the resource. This real-time decision-making ensures that the most up-to-date information is used in the access control decision.

On the other hand, PBAC focuses on managing access according to pre-defined policies outside of runtime. For instance, if an employee's job position changes (a change reflected in an authoritative source like an HR system), PBAC would automatically remove access associated with the old position and assign new access in alignment with the policy. Ensuring alignment between access rights and organizational policies is crucial in maintaining compliant operations.

In the scenario below, Mary was promoted to AP Manager after working as an AP Clerk for three years. She is thrilled about the opportunity and willing to work extra hours to excel in her new role. We can observe how PBAC and ABAC may affect her user journey on her first day.

In both models, attributes are the key input into the access decision. The attribute data that drives these models, whether ABAC, PBAC, or RBAC, can originate from one or multiple authoritative sources, with HR systems being a primary contributor. This data's integrity, accuracy, and timeliness are critical for precise and secure access control decisions. This highlights the interconnectedness of HR processes, data governance, and IGA. It also underscores organizations' need to prioritize data quality and governance in their IGA strategies.

Conclusion

The buzz surrounding ABAC and PBAC models is more than just marketing hype. By understanding and implementing these models, organizations can weave an identity fabric that is resilient, adaptable, and capable of intelligent automation. Complementing and expanding these models with RBAC concepts redefines the classic method of managing access, placing it in a context attuned to the organization's needs, highly responsive to change, compliant, and a catalyst for efficiency and automation.

Adopting robust policies, coupled with strict HR processes and data governance, is set to be a significant influencer in the evolution of the IAM, IGA, and GRC industries. This journey isn't about choosing one model over another but about understanding what's possible and embracing the sensible approaches for your organization.

IGA Automation with Fastpath

Established in 2004, Fastpath combines Identity Governance and Administration tools with Governance, Risk, and Compliance (GRC) and SoD monitoring tools for access governance.

This unique approach to access governance provides a detailed, permission-level view of access, eliminating inaccurate results and enabling informed decision-making through intelligent reviews. This fine-grained perspective is a significant differentiator for Fastpath in the IGA world, where most vendors rely on coarse-grained access rules that take roles or entitlements at face value. Fastpath's approach fills a critical gap, ensuring compliance and eliminating false-negative risk results across the application landscape.