[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Draft BTG Profile
Hi John In an earlier posting John Davis identified 4 use cases, which are worth repeating again here a) those who have permission to access the resource (e.g., ANY permission that grants access) b) those who are denied access to the resource (e.g., possess NO permission for the resource) c) those who are normally denied access but may choose to BTG and gain access if they deem it appropriate (e.g. they break the barrier by "choice" not by asserting any further/special permissions). d) those who are normally denied access but may gain access by elevating privilege We both agree that c) is BTG, but we still dont agree on the mechanism; specifically, whether a permission to perform the BTG action is needed or not. I believe in the general case it is, John believes it is not and that it can be implied by context. There is also the issue of whether overriding access control is a different use case to BTG or is the same as the BTG use case above. I believe it is the same as the BTG use case. You believe it is different. Therefore it would be good if you could add a fifth use case to the above 4 which describes why override is different to them. On 29/11/2010 17:24, Moehrke, John (GE Healthcare) wrote: > I agree with much of the sentiment that we need to make sure we > understand the problem well before we solve it. I do however believe > that we have multiple useful use-cases. Some environments do indeed > want to have a permission that is only assigned to senior clinicians > where they are privileged to override. I do agree with Mike that this > should not be called BTG, as I agree with Mike that we should be > consistent with our understanding of what BTG is vs other use-cases. > We have tried to come up with just as catchy names of these other > use-cases. > > Another aspect of these set of use-cases that I am not seeing is that > in the case where a user override would allow something, there is a > predicate communication that likely preceded this. For example, how > did the clinician know that a document existed for which they are > being denied access with an override possibility? A normal intuitive guess is one answer. Here is one example of this. The doctor has a patient in A&E. The doctor looks up the patient name in the DB, and then asks to read the patient record. This is returned. He then asks to retrieve the DNA records (or other sensitive data such as AIDS etc.) and is denied access with a BTG response. He enters a reason (person is bleeding in A&E) and breaks the glass. He is then granted access. We have another live demo example and test here https://authz.tas3.kent.ac.uk:8443/btg/ Typically this > predicate transaction needs also to understand that access is > contingent on future state change. If the user could not use an > override, then the predicate transaction should not return the > result. (note that this is also regionally defined in policy; as I do > know of regions/organizations that do want to tempt their clinicians > with objects that they couldn't get access to at all; whereas other > regions do not ever want to tempt their clinicians.) > > So, this is not just the use-case of the transaction where BTG flag > would be submitted, but this also affects other transactions too. I > don’t think this changes the potential solutions, but does broaden > the description when we get around to that. this does indeed broaden the potential use cases considerably if we are concerned with an action now that can effect another action many steps down in a workflow. I must admit that we have not yet considered such use cases regards David > > John > >> -----Original Message----- From: Davis, John M. >> [mailto:Mike.Davis@va.gov] Sent: Monday, November 29, 2010 10:46 >> AM To: David Chadwick Cc: xacml Subject: RE: [xacml] Draft BTG >> Profile >> >> David, >> >> I did not say that permissions were not necessary, I said that two >> permissions were not necessary. I fully appreciate the fact that >> the user has permissions regarding the protected objects. This is >> clearly stated in the OASIS XSPA profiles of XACML, SAML and >> WS-Trust, providing for both structural and functional role >> attributes. >> >> XSPA also provides for purpose of use categories to account for >> different "context" situations including emergency access (commonly >> known as purpose of use). >> >> The fact that the user already has permission to the data in the >> context of the purpose of use provides rationale why additional >> permissions for break glass is unnecessary. Your definition of BTG >> is actually closer to an "override" or "Bypass" mode which is >> undesirable in real life. Perhaps you are missing the concept that >> the user participates in many "contexts" or purposes of use. To >> follow your rationale, a redundant BTG permission would be required >> for each. >> >> In attempting to understand your profile and concepts, we must >> start with defining them. I've provided mine taken from an >> international SDO. Your terms warrant a clear definition as >> well. >> >> 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: Saturday, November 27, 2010 >> 2:15 AM To: Davis, John M. Subject: Re: [xacml] Draft BTG Profile >> >> Hi John >> >> Actually you misunderstood what I said about the third class of >> user and wrongly inferred what the related permissions were. In >> fact the third class of user (those allowed to BTG) have TWO >> permissions associated with them and not just one as you assumed. >> The first permission states "this class of user is allowed access >> to the resource if the glass is broken" and the second permission >> states "this class of user is allowed to break the glass". By >> having these two permissions we achieve the following effects: >> >> 1. This class of user is normally denied access to the resource >> because the glass is not broken, and 2. This class of user can >> decide if they want to break the glass or not, and if they do >> decide to, then this action is granted to them. Once they have >> taken this action, they then become entitled to access the >> resource. >> >> Further responses are below >> >> On 26/11/2010 19:30, Davis, John M. wrote: >>> David, >>> >>> 1. Defining terms so that we are all on the same page is very >>> important. >> >> I agree with this. This is why we have standards. >> >> Also HL7 is an international SDO recognized by ISO which >>> might be more useful to you than a single hospital. My question >>> is regarding the following where you wrote: >>> >>> " c) those who are normally denied access but may choose to BTG >>> and gain access if they deem it appropriate." >>> >>> Simply changes the permissions asserted is not BTG. If as the >>> BTG paper states a user already possesses a "BTG permission", >>> then you are simply back to a variation of a), e.g.: >>> >>> -User attempts to access using "normal" permissions-access >>> denied -User chooses to assert "BTG permission"-access granted >> >> Please see the fuller explanation above as to why your >> interpretation is not correct >> >>> >>> Perhaps the application of " BTG permission" invokes additional >>> response from the security system but if it is still >>> fundamentally a permission which the user already has which they >>> choose to apply in some context then it is still case a). >>> >>> 2. The possibilities might be clarified as follows: >>> >>> a) those who have permission to access the resource (e.g., ANY >>> permission that grants access) b) those who are denied access to >>> the resource (e.g., possess NO permission for the resource) c) >>> those who are normally denied access but may choose to BTG and >>> gain access if they deem it appropriate (e.g. they break the >>> barrier by "choice" not by asserting any further/special >>> permissions). d) those who are normally denied access but may >>> gain access by elevating privilege (e.g. by: >>> >>> -Context (life threatening circumstance) -Workflow (such as when >>> a user is granted addition privileges but only within the context >>> of the workflow) -Other?) >> >> Yes I agree that there are these 4 different classes of user. The >> BTG model we used only considered the first three classes and did >> not consider d) above because we did not regard this as a case of >> BTG. As you say, it is a case of elevating privileges. (And this is >> nothing special or new, as operating systems have had it for a long >> time e.g. a user who is both an administrator and a normal user can >> gain root access by login out as a normal user and logging in as >> administrator or by performing a switch user command.) >> >> >>> >>> >>> 3. So in my VIP access case, users see a "break glass barrier" >>> as a warning dialogue. They choose to gain access by breaking >>> the glass on the barrier or they do not. They don't need any >>> additional permissions to do either, they "choose" the path. >> >> correct. We both agree on this from a user-view perspective. >> >> I see no need for >>> nor any architectural advantage in the BTG profile unless your >>> purpose is to provide an mechanism to remotely BTG. >> >> Our purpose is the following: to implement BTG in the application >> independent layer so that the application dependent layer does not >> need to implement it. In this way we make it very easy for all >> applications to support BTG. If you want all applications to >> implement BTG in their own specific way, then the profile we have >> proposed is not needed, since there is no BTG standard needed. >> >> >> >> I propose that >>> this not as a BTG permission" so much as a "promise" in response >>> to an BTG challenge presented as an obligation. >> >> Sorry but I did not follow this sentence. Could you be more >> explanatory please. >> >> >>> >>> 4. That said, my question to you really goes back to the >>> definition of things. I'm suggesting BTG may be an overloaded >>> term not universally shared and that a clear definition would not >>> only be helpful but is imperative. >> >> I tend to agree with you on this last point. >> >> It is clear from our exchanges so far, that we have had (and may >> still have) differing views on BTG. You saw your emergency access >> example 2 below as a case of my BTG, whereas I see it as a case of >> escalating privileges and not BTG. >> >> But by enumerating 4 cases as you did in 2. above I think we now >> both agree on this classification >> >> regards >> >> David p.s. I note this was not sent to the XACML list. Was this on >> purpose or not? I think it would be good to copy them in on our >> exchanges >> >>> >>> 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: Thursday, November 25, >>> 2010 6:13 AM To: Davis, John M. Cc: xacml Subject: Re: [xacml] >>> Draft BTG Profile >>> >>> Hi John >>> >>> thanks for your long explanation of the HL7 position. >>> >>> Our BTG work has been done in conjunction with Porto's main >>> hospital in Portugal, along with the University of Porto. So it >>> would appear that some Europeans at least have a different >>> interpretation of BTG to the US work in HL7. >>> >>> We have published a number of papers on BTG access in medical >>> situations and I will gladly send them to you if you wish. >>> >>> The fundamental concept is this: >>> >>> 1. For any given resource, there are three classes of user as >>> specified in the access control policy a) those who have >>> permission to access the resource b) those who are denied access >>> to the resource c) those who are normally denied access but may >>> choose to BTG and gain access if they deem it appropriate. >>> >>> I would say that class c) users exactly fit your VIP record >>> access example below, and this is the class of user who are being >>> dealt with in this profile. >>> >>> The profile is a generic profile and is not tied to health care >>> resources. It can be used in any scenario where they have the >>> above three classes of user >>> >>> regards >>> >>> David >>> >>> >>> On 23/11/2010 19:49, Davis, John M. wrote: >>>> 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 >>>> >>>> >> ********************************************************** ******* >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> >>>> >> >>>> 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 >>> >>>> >> -- >> >> ********************************************************** ******* >> 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 >> >> ********************************************************** ******* >> >> --------------------------------------------------------------------- >> >> 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 > > -- ***************************************************************** 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 *****************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]