I wouldn’t be doing my job if I didn’t investigate the risks in taking an attribute-based approach to access controls. ABAC cannot replace good governance. Perceptions around scalability and management of an ABAC model must be addressed, along with the perceived complexity of policy frameworks and legacy integration capabilities that aren’t capable of making just-in-time decisions.
All effective security programs start with quality governance and policy management, and ABAC is no exception. The access control policies that can be implemented against attributes are only as good as the available attributes themselves. This same risk plagues identity- and role-based models, spurring the growth of identity governance applications, cross-functional boards, and change controls. Expanding governance beyond roles to even more attributes can feel overwhelming.
The sense of expansion raises multiple concerns about scaling and managing ABAC implementations. Roles within an RBAC authorization system are relatively static and small, and all the claims needed for a decision are present within that set of roles. The larger number of attributes from a wider variety of sources means more state to manage in the system, and managing state can be the hardest part about scaling software systems.
As you saw in the section about use cases, attribute-based models bring up all sorts of use cases and situations you may never have contemplated. Perhaps you were only considering ABAC as a single time-bound policy vector, and now you feel you’ve opened up a whole can of worms. Roles are a higher order construct. They’re much more familiar to practitioners, which makes it feel like attributes are more complex and will require more thought to implement. ABAC policies aren’t a single IF/THEN statement, they evaluate multiple criteria all at once: yes/no/no/yes/yes/no/no/no. Too many attributes feel like too many security alerts that are going to need machine learning to make practical sense of them.
Frameworks like XACML are perceived to be similarly complex: hard to write and difficult to implement. NIST explains that an ABAC model must also consider how attributes are managed and stored for every information point, where policy decisions are made, and how policy is administered and enforced.
Complicating this perception is the reality that legacy systems have been slow to adopt APIs and plugins to integrate ABAC decision-making. This risk plagued early attempts to use Active Directories as a source of role attributes, which were limited in scale and scope. Let’s face it, an attribute-based model only makes sense if an application can use those attributes to make a decision in real-time. The cumbersome nature of integrations with on-premises systems do not lend themselves to dynamic cloud environments.
And yet dynamic cloud environments are where we are all headed.
But before you despair of having the capability to address the growing risks presented by today’s distributed operations, let me conclude this series by introducing MachinaTM, the attribute-based policy decision engine from Ionic Security. Standards–and the technology available to implement them–have changed, mitigating or even eliminating risks like the ones outlined here.
Part 6/7 ABAC Blog Series: Policy is the New Perimeter