Debunking 5 Myths about Policy-based Access Control
Moving beyond the myths around PBAC to deliver broader security strategies.
Mark Cassetta, chief product officer at Axiomatics, discusses the myths about policy-based access control (PBAC) and how to deliver it as part of a broader security strategy, such as Zero Trust.
Policy-based access control (or PBAC) is one of the biggest trends for 2023 in identity and access management (IAM), and for good reason. Well-defined policies are at the core of critical security initiatives, including Zero Trust. But amid (or maybe because of) all of the attention around PBAC, misinformation has emerged, making it difficult for enterprise IAM teams to navigate a successful approach to policies and how they align or drive broader initiatives.
Complicating this is a flood of acronyms to describe this field, including attribute-based access control (ABAC), fine-grained access control (FGAC) and role-based access control (RBAC). Moreover, as this market continues to evolve and mature, proprietary solutions have emerged, adding additional complexity.
Here are a few of the myths that tend to pop up more frequently during conversations around the PBAC market or during discussions about PBAC implementation.
Myth 1: PBAC Is an Objective
Implementing PBAC is a great initiative, but it should not be viewed as an objective. An objective, while important, is both short-term and task-based. PBAC is a strategy that infers a longer-term commitment that can also be evolved in real-time in response to a change in enterprise requirements.
As is often the case with popular technology, some vendors market PBAC as an end result, which all but ensures a lack of success upon deployment. Implementing the technologies and creating a successful PBAC initiative is a long-term strategy that will change and grow in support of a modern approach to access control. This usually aligns with a broader strategic security initiative like Zero Trust, which requires a dynamic approach to cybersecurity.
See More: Consolidation and Regulation in Identity and Access Management
Myth 2: PBAC Is Easy
As more enterprises modernize their approach to policies and adopt elements of PBAC, there exists the temptation to seek out the easiest possible path to PBAC. But PBAC goes beyond implementing a solution, meaning there’s no way to “UI your way” to a successful PBAC initiative.
This is because PBAC is one component of a broader-based identity transformation that touches every aspect of the enterprise, from development to security to application and business teams. Implemented as part of a broader initiative, PBAC has broad-based impacts but also offers a powerful way to mitigate risk and ensure a more modern approach to access control that reflects the requirements of a complex enterprise.
For some enterprises, PBAC development and implementation might be quite straightforward, but for the largest, globally matrixed enterprises, a mix of legacy and cloud-native applications spread across a variety of environments will require a more thoughtful, nuanced approach. PBAC will be a critical element of this approach, but the path to success will be as part of a broader transformation that includes stakeholder engagement from multiple teams.
Myth 3: PBAC Is Based on One Standard
This myth appears to be gaining momentum. As is the case with any high-growth market, various segments within the PBAC field are seeing a growing number of new entrants, all of whom purport to have the ‘one true answer’ to PBAC. In many cases, this answer revolves around the standard they feel is best…and the one that aligns with their own solution. This was the case with authentication – one could not reasonably expect all applications to speak the same authentication standard, which is why there is currently a mix of legacy, proprietary as well as SAML and OpenID Connect (the latter two comprising the bulk of integrations).
The reality is that as was the case with other markets (i.e., authentication), there will be no one standard that creates a ‘silver bullet’ solution, paving the way for an effortless PBAC implementation. The standard that works best for a large enterprise in a highly regulated industry with several legacy applications may not be the same as the standard that works for a digital-first, cloud-only mid-sized organization. In fact, it’s likely that for most organizations, a few standards will be implemented in concert to create an orchestrated approach to PBAC.
For example, organizations seeking to deploy authorization policies that connect to multiple attribute sources for real-time decision-making will benefit from a language such as the Abbreviated Language for Authorization (ALFA). Originally inspired by the authorization standard XACML, ALFA is designed to address enterprise policy requirements that support the demands of audit and compliance. Organizations looking to build access control policies for cloud infrastructure (e.g., Kubernetes admission controllers) might look to OPA (the Open Policy Agent), whose architecture focuses on those use cases.
Though the debate on standards will continue to create confusion, keeping the use case front and center will help enterprises focus on implementing PBAC with the standard that meets their needs.
Myth 4: PBAC Should Replace RBAC
Much like the first myth, this is misplaced. Though there are vendors that offer PBAC solutions marketed as ‘better than RBAC,’ the truth is that RBAC is, in fact, a requirement of PBAC. RBAC isn’t the enemy or a bad approach to access. In fact, a user’s role is a primary way to determine what they should or should not have access to.
It is, in fact, a great (and sometimes easier) starting point. Where RBAC fails is when organizations try to use roles to address more context-based policies. It is at this point when the enterprise is ready to scale, shifting to ABAC becomes a critical path to success and avoids the issue of role explosion, whereby additional roles are continually added, creating management and maintenance headaches for IT and security teams.
See More: Why Authorization Is Key to Securing Today’s Enterprises
Myth 5: PBAC Is the New ABAC
Attribute-based access control, or ABAC, has been around for ages and is a central component of any PBAC strategy and at the heart of a successful approach to Zero Trust access control. (Cite NIST). While many believe PBAC is an evolution of ABAC, that’s simply not the case. Fundamentally, ABAC is PBAC and stresses the use of attributes that go beyond identity alone. PBAC stresses the way authorization is expressed via policy.
ABAC refers to attributes that provide critical context about a user and can include the role, location, device requesting access, etc. In ABAC, attributes are not just about who the user is but also what they want to do, what, where, when, why and how. Access control policies can consider various attributes not only as part of a decision to permit or deny access but also to determine the level or type of access once a user has been authenticated.
Although PBAC may seem like a newer term, it is a broad term that focuses on a different aspect of ABAC – policy.
As is the case with any popular technology, myths around PBAC will continue to pop up. However, enterprises that focus on delivering PBAC as part of a broader security strategy, such as Zero Trust, will ultimately see success.
How are you leveraging PBAC? Share with us on Facebook, Twitter, and LinkedIn. We’d love to hear from you!
MORE ON POLICY-BASED ACCESS CONTROL (PBAC)
