xacml — archive

Break the Glass policies

From: David Chadwick <[email protected]>
To: [email protected]
Date: Sat, 12 Dec 2009 23:45:00 -0000

I have just returned from ACSAC in Hawaii where I presented a paper on the BTG-RBAC model. BTG is equivalent to breaking the glass on a firedoor. You are not normally granted access but in an emergency you are if you decide to BTG. This model requires the PDP to return one of three responses to the PEP instead of the traditional two (grant and deny) (forgetting for now indeterminate and not-applicable) The semantics of the new "permission to BTG" response are - this user is not granted access, but will be granted access if he/she decides to break the glass. The application can then display a screen to the user asking if they wish to BTG and warning them that they will be held accountable for their actions if they decide to BTG. At real hospital trails in the main hospital in Porto, Portugal, where my PhD student works, results show that nearly 50% of doctors decided not to BTG when given the opportunity to do so. (The results are presented in our ACSAC paper along with the model). If the user decides to BTG then this grant is accompanied by a set of obligations which can perform audit, email the user's manager, reset the broken glass in 30 minutes etc at the wish of the policy writer. We have implemented a number of these obligations. Whilst a complete implementation requires a truly stateful PDP, we have implemented support for BTG (with some limitations) using Sun's XACML PDP with a stateful wrapper that holds the BTG state in an obligation object. (We will be writing a paper on this sometime in the New Year). Either way, the PEP is given an extra response, "permission to BTG" when it asks if the user can access a particular resource. The reason we have done it this way, rather than getting the PEP to make multiple calls to the PDP and hold the BTG state itself, is simple, it makes it trivial for any application to support BTG policies, which can be simply added to the access control policies of any stateful or stateless PDP (XACML or otherwise). So, after this very long introduction, my question to the group is Can we standardise the BTG response and add it to the XACML standard as a new response in the response context. 1. Ideally I would like to create a fifth enumerated value for decision, called BTG 2. As a sort of hack, we could create a new Major status code called BTG, but this is a hack, status codes are optional and the response is neither grant or deny but is genuinely intermediate to these. It is not indeterminate or not-applicable either, so which decision would accompany this status code? 3. We can always invent our own minor status code and put BTG there without perturbing the XACML standard, but this is effectively the group saying we dont see a requirement for BTG policies. Comments please. regards David ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: [email protected] Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************