Break the Glass policies

[David Chadwick <d.w.chadwick@kent.ac.uk>]

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: D.W.Chadwick@kent.ac.uk
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

*****************************************************************