[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Draft BTG Profile
Hi Hal On 16/12/2010 17:03, Hal Lockhart wrote: > We seem to have made some progress, but it seems to me that there are a > number of undefined requirements. > 1. The usecases mentioned seem to include the possibility that a BTG > condition can be associated with 1) a patient, 2) the Access Subject > (party making the request), 3) Medical Application, 4) Medical facility > or perhaps other scopes. If this is the case, how and to whom would the > scope of a given BTG be specified? In our implementation this is encoded into the BTG attribute type (that shows whether the glass has been broken or not). So rather than having a simple single BTG attribute, with values true and false, there are a potentially infinite number of BTG attributes ie. we have changed the scalar into a vector. You can regard the BTG attribute as a multi-dimensional table in which each cell can be set to true or false. The setting of the dimensions of the BTG attribute is a policy issue and will vary from application to application. Important Note. In the BTG profile we wrote, nothing is said about how the BTG state attribute is encoded or specified. It was not planned to standardise this attribute type since every implementation will have its own preferred set of attributes. > 2. This in affects the lifecycle of the BTG state, which has been > discussed to some extent. Specifically, most of these scopes imply that > once set, a particular BTG is in effect until it is turned off, whether > manually or by some automated criterion. this again is correct. In our implementation we have defined a ResetBTG operation which allows an administrator to set a BTG attribute value from True to False - the equivalent of replacing the glass in the fire alarm. But we also (through obligations, specify an automated way for the system to reset the state after a particular time has elapsed). > 3. On the last call David described a 3 step model. 1) a request is made > and denied and in some way it is reported that potentially a BTG state > might permit the access 2) a request is made to assert BTG, which is > authorization checked, assuming it is permitted, the new BTG state is > somehow propagated. 3) The original request is repeated with the > addition of the BTG assertion, which may result in the request being > granted. I believe others proposed that steps 2 & 3 could be rolled into > one. Is there any consensus on this point? If you review what I said previously, I support both models ie. the PEP can set the state independently of the PDP, in which case you do not need a BTG operation (2 above) nor a ResetBTG operation since the whole BTG state is handled within application specific code. However, if you want to remove the burden from applications and place it in the context handler, then you do need a standard BTG operation (and resetBTG operation) in order to tell the context handler when to set the state and reset the state. > 3. No attention seems to have been paid to how a PDP would actually > figure out that a denied request might (would definitely) succeed if BTG > was asserted. Good question. In fact this has to be left up to the policy writer to ensure that rules 2a and 2b (reproduced below for ease of reference) are completely in sync. If you screw up your policy then the PDP could tell a user he needs to break the glass, then reject his request. 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". Of course software implementors could provide a policy user interface that only allows the overall BTG conditions to be entered once and from this both of the above rules are generated in XACML. So there are ways to solve this problem. The currently analogous case, missing attributes can be > determined easily because it involves specific processing step. (If an > attribute reference by a policy is missing and is marked in the policy > as must be present, then report missing attributes.) It seems to me that > assuming several applicable policies for a request, that determining if > BTG would help in the general case could be quite difficult. I am > interested in how this is being done currently in XACML PDPs. (David's > policy language is different and I am not familiar with its capabilities.) the policy language is not actually an issue, since rules 2a and 2b above can presumably to translated into any access control policy machine language. What our implementation has done is provide the context handling wrapper that holds the BTG state. It can wrap any type of PDP that supports the XACML interface. regards David > Hal > > -----Original Message----- > *From:* Davis, John M. [mailto:Mike.Davis@va.gov] > *Sent:* Thursday, December 09, 2010 1:15 AM > *To:* David Chadwick; xacml > *Subject:* RE: [xacml] Draft BTG Profile > > David, > > Updated the previous discussion and BTG with editorial corrections, > additional definitions and linkage to “data segmentation”. > > 1. We have agreed BTG is defined by mode c. > > 2. We still (in my mind) need to expand the profile discussion > beyond the single attribute of user role to a broader view of > sensitivity attributes applicable to segmentation. This is the > general case, providing a flexible capability to deal with a broader > range of policies beside role attributes and to decide and enforce > attribute based access control based upon segmentation and BTG. > > *Access Control System Modes* > > The following modes of access control system operation are defined > based upon possession or lack of possession of access control > attributes. > > 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" rather than 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. * > > Note 1: 1. Regarding "Bypass/override". This vocabulary is > overloaded with Canada using it (as I recall) equivalent to BTG. A > distinctly different meaning of bypass is a maintenance/programming > mode (in which the system is purposely placed in a non-secure state > circumventing security controls). : > > *BTG USE CASE* > > Example BTG Use Case illustrating both mode a) and c) above: > > Definitions: > > ·Access Control Information (ACI). Any information used for access > control purposes, including contextual information. ISO 10181-3 > Access Control defines classes of access control ACI. Classes of > access control decision information (ACI) include: Initiator, > Target, Access request, Operand, Contextual, Initiator-bound, > Target-bound, Access-request bound. > > ·Access Control Decision Information (ADI). The portion (possibly > all) of the ACI made available to the Access Control Decision > Function in making a particular access control decision. ISO 10181-3 > > ·Attribute – Characteristic of a subject, resource, action or > environment that may be referenced in a predicate (attribute > statement that can be evaluated) or target. OASIS eXtensible Access > Control Markup Language (XACML) > > ·Permission. An approval to perform an operation on one or more RBAC > protected objects. . ANSI-INCITS 359-2004 > > ·Security Domain. A set of users, a set of protected objects and the > security policy that binds the two. ISO/IEC 15816 (ITU X.841) > > ·Segment (General). A subset of the information objects within a > security domain whose members share one or more access control > decision information attributes (e.g. all records with Target > ADI=”VIP”, all records with Contextual ADI=”Psychiatric Ward”, all > records with Target bound ADI=”Care Team AND patient record =”Smith”). > > ·Segment (HITECH). A subset of specific and sensitive individually > identifiable health information within a security domain whose > members share one or more access control decision information > attributes. > > ·Target. The set of decision requests, identified by definitions for > resource, subject and action, that a rule, policy or policy set is > intended to evaluate. OASIS eXtensible Access Control Markup > Language (XACML) > > Action: 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”: > > ** > > Domain A POLICY: 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”). > > 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 possess the Initiator sensitivity attribute “VIP” (or > better) then access is granted (this is NOT BTG), > > 5.If the user does not possess the “VIP” attribute, then the access > 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?). > > 6.The user accepts the warning=”Yes”. > > 7.The request is resubmitted this time with the attribute BTG > warning=”Yes” (this is BTG). > > 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 proposed BTG Permission (can access > VIP Segment objects where 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. > > 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. > > > *Annex A HITECH Data Segmentation Provisions* > > */HITECH Provision Directing Consideration of Data Segmentation /* > > */‘‘/**SEC. 3002. HIT POLICY COMMITTEE. * > > ‘‘(a) ESTABLISHMENT.—There is established a HIT Policy Committee to > make policy recommendations to the National Coordinator relating to > the implementation of a nationwide health information > > technology infrastructure, including implementation of the strategic > plan described in section 3001(c)(3). > > ‘‘(b) DUTIES.— > > ‘‘(1) RECOMMENDATIONS ON HEALTH INFORMATION TECHNOLOGY > > INFRASTRUCTURE.—The HIT Policy Committee shall recommend a policy > framework for the development and adoption of a nationwide health > information technology infrastructure that permits the electronic > exchange and use of health information as is consistent with the > strategic plan under section > > 3001(c)(3) and that includes the recommendations under paragraph > (2). The Committee shall update such recommendations and make new > recommendations as appropriate. > > ‘‘(2) SPECIFIC AREAS OF STANDARD DEVELOPMENT.— > > ‘‘(A) IN GENERAL.—The HIT Policy Committee shall recommend the areas > in which standards, implementation specifications, and certification > criteria are needed for the electronic exchange and use of health > information for purposes of adoption under section 3004 and shall > recommend an order of priority for the development, harmonization, > and recognition of such standards, specifications, and certification > criteria among the areas so recommended. Such standards and > implementation specifications shall include named standards, > architectures, and software schemes for the authentication and > security of individually identifiable health information and other > information as needed to ensure the reproducible development of > common solutions across disparate entities. > > ‘‘(B) AREAS REQUIRED FOR CONSIDERATION.—*/For purposes /* */of > subparagraph (A), the HIT Policy Committee shall /* */make > recommendations for at least the following areas: /* */‘‘(i) > Technologies that protect the privacy of health /* */information and > promote security in a qualified electronic /* */health record, > including for the segmentation /* */and protection from disclosure > of specific and sensitive /**/individually identifiable health > information with the /* */goal of minimizing the reluctance of > patients to seek /* */care (or disclose information about a > condition) because /* */of privacy concerns, in accordance with > applicable /* */law, and for the use and disclosure of limited data > /* */sets of such information./**//* > > */‘‘(8) C/**/ONSIDERATION/**/.—The National Coordinator shall ensure /* > > */that the relevant and available recommendations and comments /* > > */from the National Committee on Vital and Health Statistics /* > > */are considered in the development of policies. /* > > Link to NCVHS Privacy Recommendations 2006-2008 (combined ) > > http://www.ncvhs.hhs.gov/privacyreport0608.pdf > > /Regards, Mike Davis, CISSP/// > > /Department of Veterans Affairs/ > > Office of Health Information > > Security Architect > > 760-632-0294 > > *From:*Davis, John M. > *Sent:* Thursday, December 02, 2010 7:37 AM > *To:* David Chadwick; xacml > *Subject:* Re: [xacml] Draft BTG Profile > > 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”: > > Domain A POLICY: 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”). > > 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. > > 9.The user authenticates and accesses the system using the > “Clinician” role suitable for the purpose of use of “Treatment”. > > 10.S/He searches for a record > > 11.The record has Target attribute=VIP. > > 12.If the user possess the Initiator sensitivity attribute “VIP” (or > better) then access is granted (this is NOT BTG), > > 13.If the user does not possess the “VIP” attribute, then the access > 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?). > > 14.The user accepts the warning=”Yes”. > > 15.The request is resubmitted this time with the attribute BTG > warning=”Yes” (this is BTG). > > 16.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 proposed BTG Permission (can access > VIP Segment objects where 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. > > 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. > > 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]