[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 *****************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]