For Thursday: Policy Audit

One of the basic decisions made by the XACML TC back in about 2001 was not to try to create a language with was reversible. That is, XACML will tell you is a certain request should be allowed, but it cannot enumerate all the requests which would be allowed or say who can do a particular access on a particular resource or say all the things a particular user can do.

In terms of the language, the reason was that it was felt that this would either result in a language with very limited semantics or it would make the language too difficult to understand and use. (IMHO, Java Roles is an example of the former and the Policy Machine aka NGAC, is an example of the latter.)

Aside from the language issue, there are many pragmatic reasons why queries like those listed above are not feasible in large scale environments. These include, that the large numbers of items returned (users, files, etc.) make the results useless, repositories may be unknown, temporarily offline or unable to enumerate all legal attributes or attribute values. The sheer size of the query means the underlying data may change before the query finishes. It’s even possible you could get inconsistent results because attribute values changed while the query was being processed.

IMO a more sensible approach than generating the list of 1 million user accounts that can say, read a certain file is to use a semantic analysis tool on the policy so you can instead say: The only users who can access this file are those who have Attribute A with a value of X, Y or Z.

However I understand that in practice, Security Auditors are not familiar with the above reality and still press for impractically long lists of access capabilities. This would be a good area for NCCoE to investigate, understand the limitations and publish and promote best practices to the communities of Security Auditors and Security Officers.

Hal

xacml message