More on the topic of NIST and Access Control

Continuing the discussion, NIST and Access Control, I disagree with some of the distinctions between Attribute and Policy Based Access Control (ABAC and PBAC). Most of this disagreement is really in where attribute- and policy-based controls begin and end, and their characteristics, than in the concepts themselves.

In the report surveying access control models, NIST indicated that "one limitation of the ABAC model is that ... there can be disparate attributes and access control mechanisms among the organizational units. It is often necessary to harmonize access control across the enterprise." This distinction of specific silos of attribute-based control versus more enterprise-coordinated (but still attributed-based) control is the distinction between ABAC and PBAC in the report. For me, I consider this all policy-based access control, where the scope of "harmonization" varies (perhaps by conscious decision or priority of implementation).

It seems reasonable that an organization would work to fully harmonize its access to shared data or resources. That word, "shared", is important. For data and attributes specific to one organizational unit (or domain or application), it is reasonable to have individual policies (i.e., there is nothing to harmonize to). However, once data is shared across applications and org units, there is a need to harmonize - since subjects could be granted or denied access to the same data or resources by different units or applications.

So, there is a need to consider attribute-based control in specific areas AND in the enterprise as a whole. And, there is a need to be consistent with respect to the attributes and the policies. This seems true whether you call this ABAC or PBAC.

The NIST report goes on to say, PBAC "requires not only complicated application-level logic to determine access based on attributes, but also a mechanism to specify policy rules in unambiguous terms." This is not controversial, but I would clarify the term "application-level" in "application-level logic".

I agree that you need "guards" related to an application's need for and use of policy. However, you could obtain this by intercepting application/user attempts to access resources and then applying policy. Of course, you likely also have to map the application details into the attributes of your policies. This is where the Semantic Web concepts (such as OWL's SubClassOf, EquivalentClasses, DisjointClasses, etc.) come into play. As for "guards" themselves, there is a good example of this in KAoS Guards, implemented in the infrastructure from Florida's Institute for Human Machine Cognition (KAoS).

The second part of the quoted sentence talks about the need to specify policies in "unambiguous terms". This was one of the key points of my earlier post - one where we need end-user and government/organizational participation. BTW, I will be so bold as to also endorse the ontology work of the KAoS team as a basis for both access control (authorization) and obligation policies (see the entity rendering of their OWL ontology at http://ontology.ihmc.us/policy.html).

So, where do I start to disagree a bit more with the NIST position? It is in the area of an "Authoritative Attribute Source" ("the one source of attribute data that is authorized by the organization"). I cannot argue with taking this as a first line goal. Fred Wettling also pointed this out in his comments to my earlier post ... that there needs to be "a rethinking of the hub and spoke models of access control of the past. This raises the question of where identity-based attributes are stored and how/when they are validated. Can peer-to-peer communications rely on attribute assertions from the peers? In some cases yes. In other cases, third-party validation may be required. In both cases a centralized infrastructure may NOT exist. That is a challenge that may be addressable through some level of standardization of vocabulary, policy, and rule structures."

While I agree that one authorized attribute source is required by some scenarios, it is not mandated in all scenarios or even required for PBAC. As noted above, a common understanding of the semantics of the attributes and their "qualities" (including where and how they are obtained) is needed. This can be managed and mitigated by semantic alignment and policies about the data itself.

Just some more food for thought in the continuing dialog about access control and policy-based security/management/...

Next time, I promise to finally write about Risk Adaptive Access Control.

Andrea