Managing XACML Policies: A DL Perspective
by Markus Stocker
Recently, we have been working on a XACML-DL, an approach originally developed by Vlad Kolovski et al. based on his PhD. I’ve spent some time developing an API for the XACML-DL services, i.e. policy verification, policy subsumption, and policy redundancy with the primary aim of improving usability.
In a nutshell, XACML-DL is a translation of a subset of XACML 2.0 to OWL DL, i.e. policy sets and policies are translated into DL concept descriptions. This allows us to use standard DL reasoning services over XACML policies, which brings some useful features. The XACML-DL application is primarily intended to be a support tool for policy management, e.g. policy creation, maintenance, evolution (however, it is not limited to this use).
On the road towards our goal of replicating the XACML InterOp Demo with XACML-DL, we encountered a number of problems. First, Sun’s XACML Implementation (CVS) had to be tweaked to support XACML 2.0 which is required for the InterOp Demo. Second, the XACML-DL mapping does not fully cover XACML 2.0 and unfortunately even not all of the language subset used in the InterOp Demo. Setting aside some straightforward elements, e.g. Environment, the XACML 2.0 Condition element requires some theoretical work to find a mapping to DL. Nevertheless, it is worth talking about the XACML-DL application as its features may be useful in certain environments.
Verifying XACML Policies
So let’s talk a bit about policy verification. The XACML architecture includes a Policy Decision Point (PDP) which essentially takes a XACML (access) Request, evaluates it over policy sets, and returns a XACML Decision — permit and deny are two possible outcomes.
Shallow Testing
In policy management, the idea of evaluating XACML requests can be seen as Unit Testing for policy sets; for example, to (automatically) check system security. The obvious thing to do is “shallow testing”; write tests against policies which include the desired outcome — permit or deny — and let the testing framework tell you whether changes in policies or policy sets have changed the behavior of the policies when faced with access requests.
The analogies with Unit Testing are obvious and intended. It’s a reasonable thing for policy developers to do to verify that changes to policy don’t have unintended consequences.
Deep Testing
Our enhancement to this policy verification strategy is “deep testing”: policy verification in XACML-DL is able to uncover security issues that are not uncovered by testing against a PDP. We use the underlying OWL-DL reasoning services to automate generation of exhaustive tests against the policies and policy sets to provide a much deeper, comprehensive test coverage automatically. And we’re able to discover security issues, primarily around separation of duty constraints, that are not discovered in shallow testing.
Currently, our application is primarily intended to be an API that provides access to the XACML-DL services. As such, we’re only providing a command line application which supports the features of the API. For example, for the policy verification service described above the following command
java com.clarkparsia.policy.PolicyCmd --service verification --input-policy-base /my/policyset.xml --input-test-base /my/request/directory --deep-verification --verbose --explainwill load the policy sets in policyset.xml and the (Unit) tests in the directory are evaluated using “deep verification” (i.e., deep testing). The application will return detailed information (––verbose) about the tests (e.g. the decision for each test) including a counter example for the tests that fail (––explain).
Deep Testing and XACML ROI
Deep testing (or verification — we need to settle on one term for this, clearly!) is one of the features of XACML-DL and consists in the evaluation of XACML requests using an OWL-DL reasoner, in contrast to shallow testing which is the standard PDP XACML Request evaluation. With deep verification we test the satisfiability of a DL concept expression which is constructed from three input parameters: (1) XACML policy file, (2) XACML test condition, and (3) the type of test condition (e.g. permit, deny). Because we can use Pellet to check if there exists a model for a concept expression, deep testing automatically verifies all possible conditions, while with shallow verification we have to explicitly think about and encode them as test cases.
And that’s tedious, error-prone, and exactly the kind of job that policy engineers and developers should do but typically won’t, exactly because it’s annoying.
But using our approach to managing policies, we can generate that stuff automatically, thus radically increasing the confidence one can have (rationally) in the quality and coverage of one’s policies. There’s no point moving to XACML if all you end up doing is building a game-able system for attackers. The ROI to XACML, that is, to externalizing security policy out of application code, is only real if the underlying policies enforce the policy designer’s actual intent.