[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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. 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. Regards, Mike Davis, CISSP Department of Veterans Affairs Office of Health Information Security Architect 760-632-0294 -----Original Message----- 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]