Re: [xacml] Break the Glass policies

["Rich.Levinson" <rich.levinson@oracle.com>]

Hi David,

At the RSA 2008 Interop, we demonstrated an "emergency override" 
capability that I believe is equivalent to BTG, and was even referred to 
as BTG during requirements analysis. We did not require a new return 
code, but simply implemented this as part of the policy definitions - 
basically, a user requested access and was denied, then re-requested 
access with a new Permission (HL7) provided in the request, which 
enabled access.

The details are in section 2.2.4 of the document that may be found on 
the XACML TC main page:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml#expository
The doc is described here:
http://www.oasis-open.org/committees/document.php?document_id=28030&wg_abbrev=xacml
The zip file containing the doc is in this zip file:
http://www.oasis-open.org/committees/download.php/28030/XACML-20-RSA-Interop-Documents-V-01.zip

Based on that implementation of the capability I would like to 
understand better the need for a "permission to BTG" response. In 
particular, why not just return the "permission" as an Obligation to the 
PEP to notify the user of this option?

    Thanks,
    Rich



David Chadwick wrote:
> 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
>
> *****************************************************************
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php