NIST Report Reflects Increasing Need for ABAC…but Over-Engineers Its Deployment

by Andy Han

The National Institute of Technology and Standards (NIST) held a conference a few months back on Attribute Based Access Control (ABAC).  The primary objective of the conference was to promote a special publication on ABAC and the event brought together leaders from various government programs, technology vendors, industry analysts and subject matter experts on authorization and access control.  The event and paper are recognition that the adoption of ABAC is accelerating and that we needed to put in writing a shared understanding of when and how to deploy ABAC.  There was agreement on the central of the drivers for the adoption of ABAC: Organizations, including the federal government, need to govern how information is shared across systems, applications, and organizations.  The document’s purpose is thus to (1) establish a standard definition of ABAC and a description of its functional components and (2) provide “planning, design, implementation, and operational considerations for employing ABAC within a large enterprise with the goal of improving information sharing while maintaining control of that information” (vii).

ABAC is endorsed by NIST as the best approach for this particular challenge because of the fundamentals of its design. ABAC allows organizations to pass attributes back and forth as information is shared across application, infrastructure, and organizational boundaries. Access control policies use those attributes to evaluate the relationships between subjects and objects and determine whether to allow an action. One of the core technical benefits of ABAC, according to the report, is “ABAC avoids the need for explicit authorizations to be directly assigned to individual subjects prior to a request to perform an operation on the object” (7).  You don’t need to have a master list of every possible access control scenario (if a user may be outside your organization and you don’t know their credentials, this may not be possible anyway). The report asserts that an enterprise implementation of this scope would require a standard way  to describe subject and object attributes, as well as a standardized way to digitally express what they call the “Natural Policy Language” (NPL), or “Statements regarding the managing and accessing of enterprise objects. NLPs are abstract concepts that can be translated to machine-enforceable access control rules” (13).

I think that the report does a good job outlining some of the key benefits of adopting ABAC. However, I and others I spoke with at the event had a hard time with the section on “ABAC Enterprise Deployment Considerations,” which looks at an abstract ABAC deployment, without a business context, which over-complicates the whole thing.  For instance, here’s the example scenario for an enterprise implementation of ABAC:


Try selling that to your CIO or CEO.

The report writers acknowledge the importance of starting the whole process by establishing business value, which entails asking (among other questions), “Which datasets, systems, applications, and networks need ABAC capabilities?” (18). In fact, devoid of application and business context, discussing the benefits of ABAC versus traditional RBAC or ACLs is just technical chatter.  Is a screw better than a nail?  Well it depends on the application.

This is the challenge with any overly ambitious plan for enterprise ABAC implementation. Sure, you want the capability to someday have consistent enforcement across the enterprise, so you need to do the big picture architectural thinking. However you also need to start with the particular: which means understanding requirements particular to a specific business context.

The first particular is always application – do the authorization requirements of the application require a dynamic, mandatory, or granular authorization?  If not, then there will be no business case for moving to ABAC.  Any change of model, like going from roles to attributes, has to offer a 10X benefit to justify the cost of making the change.  Understand the driver and application of ABAC, pick an application where you can realize a 10X benefit.  Can I reduce my access management costs by 10X?  Can I increase end-user productivity and collaboration by 10X?  Once we understand the application and business value then we have context in which to think about the deployment of ABAC.

Andy Han is responsible for Product Development and Product Marketing at NextLabs.

Mr. Han has 15 years of experience in the creation and management of enterprise software, specializing in application infrastructure and security products.

3 thoughts on “NIST Report Reflects Increasing Need for ABAC…but Over-Engineers Its Deployment

  1. Andy–I also like the NIST report because it is the first effort I’ve seen to treat the ABAC topic comprehensively, but I can see your perspective about “over-engineering.” My reaction was that while the report claims to talk about “business case” it actually presents a list of challenges and new risks. As you say–good luck selling this to management. The disappointing thing is that there is a very good business case to be made for ABAC. Yes, there are new issues, but ABAC solves many issues of “conventional” access-control schemes. And ABAC should lower costs on a life-cycle basis because it should save account-maintenance costs.
    Not sure why NIST thought it was appropriate for them to present a business case, vs. a technical description of standards, risks, etc. Still, the report does get an ABAC overview out there in a high-profile way . . .

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s