Re: [xacml] Draft BTG Profile

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

Hi Martin

Given your two use cases below I would say that

1. is similar to our use case, but the solution you propose is somewhat
different to the one proposed in our BTG draft profile. The difference
appears to be as follows
a) you require the user to assert a particular attribute that it is not
normal to assert. The policy rule will grant access to the resource if
this "exceptional" attribute is asserted by the user
b) we only require the user to assert a normal attribute, but to request
a special permission "BTG". The BTG permission is granted for any users
who have this normal attribute. Once the BTG permission has been
granted, the state of the system changes (equivalent to the glass being
broken on the fire door) to BTG=true. The policy rule says that users
with normal attributes are granted access to the resource if BTG=true
(so they are normally denied access until the glass is broken).

2. This is out of scope of BTG and the draft profile is not trying to
address this aspect at all

regards

david


On 23/11/2010 21:55, Smith, Martin wrote:
> (Note―I don’t think this comment will reach the list as I am an 
> observer, not a member. If one of you--John/David―is a Member an wants 
> to forward this message to the list, please do so.)
> 
> In the contexts that we (in my part of DHS) have been considering 
> similar issues, we would basically agree that there are two important 
> “use cases” to cover, but we use slightly different terms, i.e.,
> 
> 1. Some access attributes may allow the requestor to assert them 
> (perhaps from a pick list of “authorized purposes” for the info may be 
> sought; perhaps with a warning (“You are asserting an authorized purpose 
> for accessing this info. Your access may be audited and legal action 
> taken if it is determined that the use was fraudulent or unauthorized.”) 
> For the BTG scenario, the assertion of “FIRE!” may be the ONLY access 
> attribute required, but of course the asserted “authorized purpose” 
> attribute might also be only one of several required attributes: 
> “JobRole=PassportOffice Clerk AND AuthorizedPurpose=”Validating 
> Application”.
> 
> 2. Access may also be conditional on some environmental attribute 
> obtained by the PDP or whatever at rule-evaluation time (and not 
> associated with or provisioned from the requestor’s credentials or the 
> requested resource’s metadata or value.) Examples: “CurrentThreatLevel; 
> “EmergencyDeclared”.
> 
> Martin
> 
> **/Martin F. Smith/**
> Director, National Security Systems
> US Department of Homeland Security
> NAC 19-204-47
> (202) 447-3743 desk
> (202) 441-9731 mobile
> (800) 417-6930 page
> 
> ------------------------------------------------------------------------
> 
> *From:*xacml-return-2257-martin.smith=dhs.gov@lists.oasis-open.org 
> [mailto:xacml-return-2257-martin.smith=dhs.gov@lists.oasis-open.org] *On 
> Behalf Of *Davis, John M.
> *Sent:* Tuesday, November 23, 2010 2:49 PM
> *To:* David Chadwick; xacml
> *Subject:* RE: [xacml] Draft BTG Profile
> 
> David,
> 
> 1. BTG is a common healthcare concept. The Draft BTG profile seems to 
> describe a concept somewhat different. I've included a short paper which 
> provides definitions, descriptions and requirements for BTG and 
> "emergency access" as two distinct and different concepts within the 
> healthcare domain. Here is a short description from HL7's Access Control 
> Service Functional Model:
> 
> /"Break‐glass is named after the glass panel that protects a fire alarm. 
> Everyone in the building is authorized to use the fire alarm to report a 
> fire, but the ramifications of misuse are substantial. The fragile glass 
> panel is sufficient to avoid accidental triggering, and it forces the 
> user to stop and think/
> 
> /before acting. In the context of this document, a “Break Glass” 
> scenario involves a situation where the access control policy will 
> authorize the user to access certain information or functionality, but 
> only after the user attests that one or more relevant conditions exist."/
> 
> 2. As described in the draft profile, the most important concept is that 
> the profile requires a BTG permission. This does not match the notion of 
> BTG as used in healthcare which is much more like a user controlled 
> "gateway" much such as a fire alarm. I'll explain by means of a use case:
> 
> In this healthcare scenario, a user is authorized to access patient 
> records (has appropriate permissions). Some records (e.g., VIP) are 
> sequestered behind a BTG barrier. A user attempting to access a VIP 
> record will be presented with a warning banner indicating that the 
> record is protected and that access will subject the user to increased 
> auditing (and perhaps other controls such as notifications to system 
> admins). In any case, the requester has two options; 1) abort or 2) 
> continue. If 2) is chosen the record is presented. The distinguishing 
> characteristic is that no elevation of user permissions and no special 
> "BTG permission" is required, the user is already in the "clinician" 
> group authorized to view records. This is analogous to students in a 
> high school. They are all members of a group who are "authorized" to 
> pull the fire alarm. Doing so falsely will subject the student to 
> discipline but the student does not need the teachers authorization to 
> pull the alarm when conditions warrant.
> 
> This is distinguished from emergency access of the first kind (normal 
> emergency room operations). In emergency access #1, the context of the 
> emergency (significant harm or risk of death to the patient) needs to be 
> presented so that the access control system evaluates the appropriate 
> policy set (e.g. A clinician at one hospital may not be authorized 
> access to records at another under normal conditions of “treatment”). In 
> emergency access #1, the XSPA SAML attribute assertion profile provides 
> an "Emergency Access" purpose of use attribute. This purpose of use 
> allows the PDP to select and evaluate the appropriate policy for the 
> "emergency" condition as opposed to normal "treatment". Again, it is not 
> the user permissions that are evaluated but the fundamental context of 
> the policy environment.
> 
> There is emergency access of the second kind which is a variation of 
> emergency access #1. In emergency access #2, the requester makes the 
> request for information under the purpose of use of treatment and 
> clinical role. Authorization to view the record under these conditions 
> is denied (perhaps an underlying privacy policy is being enforced). In 
> response the clinician responds by elevating permissions by asserting 
> the “emergency role” in the XSPA SAML Assertion profile thereby 
> elevating privileges under the same POU of “treatment” and overriding 
> the original policy decision. In our work in HL7 we have found the 
> “emergency” role/permission unnecessary as POU has the added benefit of 
> putting in place (and managing) an emergency context vice a simple role. 
> Emergency #2 is probably closer to what is intended by the Draft BTG 
> profile but is significantly different from what is described above.
> 
> I believe additional discussion is warranted on the fundamental concepts 
> of the Draft BTG profile, first to ensure common understanding of the 
> different forms of access, the uses of policy, purpose of use and 
> permission and second to establish sound use cases that will 
> sufficiently clarify the purpose and conditions under which use of such 
> a profile is warranted.
> 
> Regards, Mike Davis, CISSP
> 
> Department of Veterans Affairs
> 
> Office of Health Information
> 
> Security Architect
> 
> 760-632-0294
> 
> -----Original Message-----
> From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk]
> Sent: Tuesday, November 23, 2010 9:07 AM
> To: xacml
> Subject: [xacml] Draft BTG Profile
> 
> Dear List
> 
> about a year ago we discussed the standardisation of the Break The Glass 
> response (see Seth Proctor's message of 17 Dec 2009) and decided that a 
> profile to standardise the BTG response would be useful. Unfortunately 
> Seth left Sun before we got around to writing it.
> 
> Consequently Stijn Lievens and myself from Kent have produced a first 
> version (attached) for your consideration. I know its not in the correct 
> format yet, but we can fix that once the technical content has been agreed.
> 
> Comments appreciated
> 
> regards
> 
> David
> 
> -- 
> 
> *****************************************************************
> 
> David W. Chadwick, BSc PhD
> 
> Professor of Information Systems Security School of Computing, 
> 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
> 
> *****************************************************************
> 

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
School of Computing, 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

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