Re: [xacml] Draft BTG Profile

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

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

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