One Policy to Rule Them All
by Deborah Volk on September 22nd, 2009

Thanks to Anil John's tweets, I've been alerted to National Institute of Standards and Technology (NIST) workshop on Access Management. Having worked for DARPA a long time ago in a land far away, I am not afraid of terms such as Plenary Session or Hotwash, they make any proceeding seem important and rife with danger. Someone abused their access privileges or shared a password? Call the NSA to erase him. (Let's see if there are going to be any information security incidents after that..)

I know that some are not aware that NIST does good work in the information security realm. Among other things, they publish a series of documents called Special Publications (800 series) that cover many basic and not so basic security topics. While not particularly groundbreaking, they're thorough and vendor neutral and can serve as a good overview of technologies or approaches for just about any information security initiative. Unfortunately, the technology landscape evolves at a fast clip and there's a fair amount of dated material, ranging from slightly dated to ancient. Caveat emptor.
On the access mangement front, NIST is far from dated. Part of the workshop is a Survey of Access Control Models paper that looks at (drumroll, please) access control models and their evolution. According to the paper, there's the venerable Access Control List (ACL, resource-centric, doesn't scale), Roles-Based Access Control (RBAC, lacks granularity, doesn't scale beyond broad categories of people), Attribute-Based Access Control (ABAC, scale leads to maintenance and consistency issues), Policy-Based Access Control (PBAC) and finally Risk-Adaptive Access Control (RAdAC, complex to implement, requires a lot of computing resources).Surprisingly, the paper doesn't mention Mandatory vs Discretionary Access Control (MAC vs DAC) classification. ACL is a DAC, the rest of the model are MACs.

The pro/con analysis of different models presented in the paper is very good, I agree with most (if not all) of it. From an ontological perspective, I can support the paper's position of representing RBAC, ABAC and PBAC as three different classification nodes but really they're all variation on the same theme. At the implementation time, there are attributes (employee position, department, status, etc) that go into rules ("allow all employees to edit internal wiki", "deny wiki edits to all engineers between 2am and 5am") that make up a policy. In role-based access control, there are rules that define a role, in ABAC there are rules that float by themselves and in PBAC there are rules bound into policies. The paper acknowledges this by noting that the gap between PBAC and ABAC is mainly enterprise focus with PBAC being a "harmonization" of ABAC and that PBAC will extend the policy and access to many resources.
What I found interesting is a presentation by NIST's David Ferraiolo that talks about a universal Policy Machine or, to be more exact, a universal access control stack that can slice, dice and cook you breakfast. As the presentation notes, the main problem with access control today is very simple - the implementation is nothing like the policy. In other words, the policy might be a complex document with legal nuances but by the time the requirements filter down from the original policy document through the business to IT to implementation to delivered result, you might as well have asked for a submarine with nuclear warheads and instead gotten a toy hammer. The presentation refers to this transformation as "dismal state of affairs". (Something is rotten in the state of Denmark!) The reasons for the policy/implementation gap are many; the author cites lack of interoperability (i.e. a challenge in having application X and device Y and operating system Z all getting their "direction" from one central decision point) in heterogeneous environments as one key problem.

Furthermore, access control as defined in the paper is broader than just access to resources. It includes unauthorized dissemination of information, e.g. via a copy and paste into email and other out-of-band actions involving endpoints such as flash drives. From the author's perspective, access control should encompass the entire computing stack and then some - OS, devices, applications and data. To this end, the author proposes a universal Policy Machine that has "just enough" expressiveness in the "language" used to implement attribute-based rules so that this Policy Machine can become that one decision point all applications, devices and operating systems will use for access control. Reading this I had a science fiction flashback and my brain came up with this as a visual representation of a Policy Machine (hint: it zaps you)
The presentation closes with a promise of a working prototype of a Policy Machine that covers files and Open Office suite of apps, including copy and paste. In my next blog I will attempt to build the Policy Machine from stock parts, similar to what Jonathan Godwin (my personal hero) does with car engines.

Posted in Oracle Identity Manager, Access Management    Tagged with no tags


Hilary Hosmer - November 21st, 2014 at 2:27 PM
I enjoyed this write-up, particularly the review of NIST's access control paper. You may be interested in my multiple security policy work which preceded NIST's by a decade.
The Multipolicy Machine (1990-1996), especially The Multipolicy Paradigm for Trusted Systems presented at the New Security Paradigms Workshop, 1993, was the basis for both NIST's Policy Machine and OASIS' XACML (eXtended Access Control Markup Language).
Deborah Volk - November 21st, 2014 at 2:37 PM
Hilary -

Thanks for your comment, glad you liked this (old!) blog post. Is the paper/presentation you're referring to?
Hilary Hosmer - January 6th, 2015 at 8:51 PM
Yes, belatedly, Deborah. I am now working with INCITS and NIST personnel on the Next Generation Access standard Control (NGAC).
Leave a Comment

2012 (1)
2011 (2)
2010 (2)
2009 (64)
March (11)
April (18)
May (18)
June (4)
July (1)
August (1)
September (5)
October (5)
December (1)