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?
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.
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?
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. 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.)
Hal
-----Original Message-----
From: Davis, John M.
[mailto:]
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 gdata segmentationh.
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=hVIPh, all records with Contextual
ADI=hPsychiatric Wardh, all records with Target bound ADI=hCare Team AND
patient record =hSmithh).
·
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 = gXXXh and Domain A policy=hYYYh:
Domain
A POLICY: Grant Initiator access to Domain A objects with Target
sensitivity attribute=hXh IFF Initiator role=hYh and (Initiator sensitivity
attribute = gXh OR BTG Warning=hYesh).
Note
1: Access to most domain data is obtained with role Y=hClinicianh and
target sensitivity attribute = gNullh, however VIP records are marked with
Sensitivity attribute = gVIPh 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 gClinicianh role suitable
for the purpose of use of gTreatmenth.
2.
S/He
searches for a record
3.
The
record has Target attribute=VIP.
4.
If
the user possess the Initiator sensitivity attribute gVIPh (or better) then
access is granted (this is NOT BTG),
5.
If
the user does not possess the gVIPh 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=hYesh.
7.
The
request is resubmitted this time with the attribute BTG warning=hYesh (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=haccessh and protected object=hVIP Segment
Objectsh) 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 gChoiceh 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
eeSEC. 3002. HIT POLICY COMMITTEE.
ee(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).
ee(b) DUTIES.—
ee(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.
ee(2) SPECIFIC AREAS OF STANDARD DEVELOPMENT.—
ee(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.
ee(B) AREAS REQUIRED FOR CONSIDERATION.—For purposes of
subparagraph (A), the HIT Policy Committee shall make
recommendations for at least the following areas: ee(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.
ee(8)
CONSIDERATION.—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
examplecintended 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 Ifm 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 =
gXXXh and Domain A policy=hYYYh:
Domain
A POLICY: Grant Initiator access to Domain A objects with Target
sensitivity attribute=hXh IFF Initiator role=hYh and (Initiator sensitivity
attribute = gXh OR BTG Warning=hYesh).
Note
1: Access to most domain data is obtained with role Y=hClinicianh and
target sensitivity attribute = gNullh, however VIP records are marked with
Sensitivity attribute = gVIPh 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 gClinicianh role suitable
for the purpose of use of gTreatmenth.
10. S/He
searches for a record
11. The
record has Target attribute=VIP.
12. If
the user possess the Initiator sensitivity attribute gVIPh (or better) then
access is granted (this is NOT BTG),
13. If
the user does not possess the gVIPh 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=hYesh.
15. The
request is resubmitted this time with the attribute BTG warning=hYesh (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=haccessh and protected object=hVIP Segment
Objectsh) 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 gChoiceh 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:]
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
> donft 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:] 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:] 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:] 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 gBreak
>>>> Glassh 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 gtreatmenth). 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
>>>> gemergency roleh in the XSPA SAML
Assertion profile thereby
>>>> elevating privileges under the same POU
of gtreatmenth and
>>>> overriding the original policy
decision. In our work in HL7 we
>>>> have found the gemergencyh
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:] 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:
>>>>
>>>> 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:
>> 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:
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
