[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Draft BTG Profile
In the Porto hospital implementation users could choose a purpose from a picking list or specify their own. But this is an implementation detail and not specific to the BTG PEP-PDP protocol is it? regards David On 03/12/2010 13:58, Smith, Martin wrote: > ADvid/John-- > > RE: >> 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). > > I think it is useful to regard this "choice" as an "assertion of > authorized purpose." After all, it's probably illegal to "BTG" on a > whim, and in many scenarios there will be a short list of "authorized > purposes" or "appropriate predicates" for an emergency action. > Capturing this assertion (in a log) along with other attributes (if > any) required for an access decision would be very useful to permit > analysis of "why" (along with "who, what and when") the decision was > made, and to provide a basis for (ex-post) enforcement of proper use > of "emergency" access. > > 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 > > > -----Original Message----- From: > xacml-return-2300-martin.smith=dhs.gov@lists.oasis-open.org > [mailto:xacml-return-2300-martin.smith=dhs.gov@lists.oasis-open.org] > On Behalf Of David Chadwick Sent: Friday, December 03, 2010 4:45 AM > To: Davis, John M. Cc: xacml Subject: Re: [xacml] Draft BTG Profile > > Hi John > > I am happy with your 5 access modes as described below, and note that > I am only talking about mode c) BTG and the other modes are out of > scope of the BTG discussion. With this clarification, can we now > agree that we are all talking about mode c) and that in particular > modes d) and e) are not cases of BTG. > > More comments below > > On 02/12/2010 15:37, Davis, John M. wrote: >> David, >> >> Thanks for the comments and lively discussion. Below are some >> follow-on definitions and an example…intended to clarify security >> concepts involved more than call up specific XACML mechanisms. >> >> 1. Regarding "Bypass/override". This vocabulary is overloaded with >> Canada using it (as I recall) equivalent to BTG. A distinctly >> different meaning of bypass that I’m more familiar with is a >> maintenance/programming mode (in which the system is purposely >> placed in a non-secure state circumventing security controls). >> Adding this to the list of access modes: >> >> 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) Bypass. Insecure system state in which access control >> decision/enforcement is intentionally disabled or circumvented by >> authorized users. * >> >> 2. Here is a example BTG Use Case illustrating Case c above: >> >> *BTG USE CASE* >> >> Definitions: >> >> ·Security Domain. A set of users, a set of protected objects and >> the security policy that binds the two. >> >> ·Access Control Decision Information (ACI). ISO 10181-3 Access >> Control defines classes of access control ACI. Classes of access >> control decision information (ACI) include: Initiator, Target, >> Access request, Operand, Contextural, Initiator-bound, >> Target-bound, Access-request bound. >> >> ·Permission. Per ANSI-INCITS 359-2004 a /Permission /is an approval >> to perform an operation on one or more RBAC protected objects. >> >> user (initiator) operates in Domain A and has proper >> permissions/roles to perform assigned tasks. In the course of >> activities, this user desires to search for a record within a >> defined VIP segment of Domain A under a purpose of use = “XXX” and >> Domain A policy=”YYY”: > > It is not clear if YYY is a single rule or a set of rules comprising > an overall policy. > >> >> Domain A POLICY: > > It is not clear if this is policy YYY or if YYY is different to > this. > > Grant Initiator access to Domain A objects with Target >> sensitivity attribute=”X” IFF Initiator role=”Y” and (Initiator >> sensitivity attribute = “X” OR BTG Warning=”Yes”). > > For the case of BTG, it would be clearer if this was separated into > two rule, the first of which can then be ignored in the BTG > discussion since as you point out later this is not a case of BTG. > > 1. Grant Initiator access to Domain A objects with Target sensitivity > attribute=”X” IFF Initiator role=”Y” and Initiator sensitivity > attribute = “X”. > > 2. Grant Initiator access to Domain A objects with Target sensitivity > attribute=”X” IFF Initiator role=”Y” and BTG Warning=”Yes”. > > So if we accept that rule 2 is the only rule of interest, then I > will tell you how we have implemented exactly the same thing, using > a different rule set > > 2a Kent. Grant Initiator access to Domain A objects with Target > sensitivity attribute=”X” IFF Initiator role=”Y” and BTG State > =”Glass Broken”. > > 2b Kent. Grant Initiator BTG access to Domain A objects with Target > sensitivity attribute=”X” IFF Initiator role=”Y” On grant return > obligations "notify manager, write to audit trail etc as determined > by application". > >> >> Note 1: Access to most domain data is obtained with role >> Y=”Clinician” and target sensitivity attribute = “Null”, however >> VIP records are marked with Sensitivity attribute = “VIP” and >> therefore the user must either already hold this attribute or >> assert the BTG Warning attribute at runtime. >> >> 1.The user authenticates and accesses the system using the >> “Clinician” role suitable for the purpose of use of “Treatment”. >> >> 2.S/He searches for a record >> >> 3.The record has Target attribute=VIP. >> >> 4.If the user possessthe Initiator sensitivity attribute “VIP” (or >> better) then access is granted(this is NOT BTG), >> >> 5.If the user does not possessthe “VIP” attribute, then theaccess >> control system throws an exception which causes the application to >> present the user with the BTG warning banner (e.g., Acknowledge >> understanding that your activities will be audited, supervisor will >> be notified, etc do you accept YES/NO?). > > In your implementation this exception will need to be specifically > defined so that the application knows to throw the BTG banner for > this exception, and not for other exceptions. So you have a > standardisation issue here. In our implementation the access control > system returns the BTG result, which is why we want to standardise > the BTG result. The application now knows to show the BTG banner > because the authz decision was BTG. > > >> >> 6.The user accepts the warning=”Yes”. >> >> 7.The request is resubmitted this time with the attribute BTG >> warning=”Yes”(this is BTG). > > In your implementation the PEP has changed the BTG state from BTG > warning=No to BTG warning =Yes. This means that the application has > to know what the state variable is (BTG warning) that is known by the > PDP, and this could vary from application to application unless it > is standardised. > > What we want to achieve is that the authz infrastructure changes the > BTG state so that the application does not need to. The application > code then does not need to know what the BTG state variable is, which > to my mind, is a good thing for application writers and portability. > > So in our implementation, the application now asks the authz > infrastructure if the user can perform the BTG operation. This of > course is granted by Rule 2b Kent, and the BTG state is changed to > Glass Broken by the authz infrastructure. The BTG related obligations > from Rule 2b kent are now returned to the application for it to > enforce. It does not appear that your implementation has such a > feature (at least you have not described it) but this is surely > essential. > > Once the obligations have been enforced the application then repeats > the initial access request, which is now granted by Rule 2a Kent > because the BTG state has been updated to Glass Broken. > >> >> 8.The access control system grants access (re-evaluates the policy >> including the run-time BTG warning acknowledgement which is now >> present). >> >> Note 2: Possession of the sensitivity attribute (STEP 4) is >> functionally equivalent to the proposedBTG Permission (can >> accessVIP Segment objectswhere permission operation=”access” and >> protected object=”VIP Segment Objects”) and presumes a pre-existing >> authorization attribute. Asserting an authorization attribute >> already held is NOT BTG. > > Agreed step 4 is not BTG therefore I suggest we simply scrub it from > the description since it is not relevant. > > >> >> Note 3:Lack of any authorization attribute specific to the >> segmented data and the user “Choice” to accept the BTG Warning is >> the key element of BTG that distinguishes it from other access >> modes. > > In my terminology it is "user choice to perform the break the glass > operation" which is equivalent to actually breaking the glass next to > a hotel firedoor. > > To conclude, we both have very similar notions of what BTG is, but > the differences are > > 1. Your method requires a standard BTG exception to be returned by > the access control system, whereas our method requires a standard > BTG response to be returned. It would be best if the standard way is > backwards compatible with existing non-BTG implementations and > reverts to a simple Deny in the case where the application does not > support BTG. Rich's proposed way of doing this, sending a Deny with a > new standardised BTG obligation appears to satisfy the backwards > compatibility issue and is XACML version independent. Would this be > acceptable to you > > 2. Your method requires the application to maintain the BTG state, > to know what it is, how to update it, and when to return it in an > access decision request. Our method requires the application to know > what the standard BTG operation is and to request this when the user > requests to break the glass. I have a proposal for this below. Our > method supports either the context handler/PIP infrastructure storing > the BTG state and updating it or the PDP storing the BTG state and > updating it. It does not preclude the application from doing this as > well (as in your method), but in this case no standardisation of the > BTG operation is needed, since it is the performing of the BTG > operation that causes the BTG state to change. > > 3. Your method does not appear to support the returning of > obligations when the glass is broken by the user. Our method does. > > PROPOSAL FOR STANDARDISING THE BTG OPERATION. > > 1. We standardise the BTG obligation that is used to signal the BTG > response > > 2. This BTG obligation has an additional optional attribute > assignment which is called BTG request context. > > 3. When a user attempts to access a BTG protected resource using > request context<access resource>, the access control system returns a > DENY response with the BTG obligation. > > 4. The application sees the BTG obligation and shows the BTG screen > to the user. > > 5. If the user decides to break the glass, the application either > > a. If the BTG obligation does not contain the BTG request context > attribute assignment, the application does its own thing, updates > the BTG state etc, and then repeats the request context<access > resource> but sets the BTG state to true this time. Access is now > granted. > > b. If the BTG obligation does contain the BTG request context, the > PEP sends this to the access control system. Note that the PEP only > needs to copy over what it has been given and does not need to know > or understand any of the parameters. It is up to the access control > system to fill in this BTG request context in whatever way it sees > fit. The access control system returns granted with an optional set > of obligations that should be enforced. The PEP enforces these > obligations then repeats the request context<access resource> to the > access control system. Access is now granted. > > regards > > David > > > > > >> >> 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 30, 2010 >> 12:34 AM To: Moehrke, John (GE Healthcare) Cc: xacml 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 >> >> ***************************************************************** >> >> --------------------------------------------------------------------- >> >> >> 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 >> >> >> /Regards, Mike Davis, CISSP/ >> >> /Department of Veterans Affairs/ >> >> Office of Health Information >> >> Security Architect >> >> 760-632-0294 >> > -- ***************************************************************** 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]