Hi Hal
On 16/12/2010 17:03, Hal Lockhart wrote:
> We seem to have made some progress, but it seems to me that there are a
> number of undefined requirements.
> 1. The usecases mentioned seem to include the possibility that a BTG
> condition can be associated with 1) a patient, 2) the Access Subject
> (party making the request), 3) Medical Application, 4) Medical facility
> or perhaps other scopes. If this is the case, how and to whom would the
> scope of a given BTG be specified?
In our implementation this is encoded into the BTG attribute type (that
shows whether the glass has been broken or not). So rather than having a
simple single BTG attribute, with values true and false, there are a
potentially infinite number of BTG attributes ie. we have changed the
scalar into a vector. You can regard the BTG attribute as a
multi-dimensional table in which each cell can be set to true or false.
The setting of the dimensions of the BTG attribute is a policy issue and
will vary from application to application.
Important Note. In the BTG profile we wrote, nothing is said about how
the BTG state attribute is encoded or specified. It was not planned to
standardise this attribute type since every implementation will have its
own preferred set of attributes.
> 2. This in affects the lifecycle of the BTG state, which has been
> discussed to some extent. Specifically, most of these scopes imply that
> once set, a particular BTG is in effect until it is turned off, whether
> manually or by some automated criterion.
this again is correct. In our implementation we have defined a ResetBTG
operation which allows an administrator to set a BTG attribute value
from True to False - the equivalent of replacing the glass in the fire
alarm. But we also (through obligations, specify an automated way for
the system to reset the state after a particular time has elapsed).
> 3. On the last call David described a 3 step model. 1) a request is made
> and denied and in some way it is reported that potentially a BTG state
> might permit the access 2) a request is made to assert BTG, which is
> authorization checked, assuming it is permitted, the new BTG state is
> somehow propagated. 3) The original request is repeated with the
> addition of the BTG assertion, which may result in the request being
> granted. I believe others proposed that steps 2 & 3 could be rolled into
> one. Is there any consensus on this point?
If you review what I said previously, I support both models ie. the PEP
can set the state independently of the PDP, in which case you do not
need a BTG operation (2 above) nor a ResetBTG operation since the whole
BTG state is handled within application specific code. However, if you
want to remove the burden from applications and place it in the context
handler, then you do need a standard BTG operation (and resetBTG
operation) in order to tell the context handler when to set the state
and reset the state.
> 3. No attention seems to have been paid to how a PDP would actually
> figure out that a denied request might (would definitely) succeed if BTG
> was asserted.
Good question. In fact this has to be left up to the policy writer to
ensure that rules 2a and 2b (reproduced below for ease of reference) are
completely in sync. If you screw up your policy then the PDP could tell
a user he needs to break the glass, then reject his request.
2a Kent. Grant Initiator access to Domain A objects with Target
sensitivity attribute=”X” IFF Initiator role=”Y” and BTG State =”Glass
Broken”.
2b Kent. Grant Initiator BTG access to Domain A objects with Target
sensitivity attribute=”X” IFF Initiator role=”Y” On grant return
obligations "notify manager, write to audit trail etc as determined by
application".
Of course software implementors could provide a policy user interface
that only allows the overall BTG conditions to be entered once and from
this both of the above rules are generated in XACML. So there are ways
to solve this problem.
The currently analogous case, missing attributes can be
> determined easily because it involves specific processing step. (If an
> attribute reference by a policy is missing and is marked in the policy
> as must be present, then report missing attributes.) It seems to me that
> assuming several applicable policies for a request, that determining if
> BTG would help in the general case could be quite difficult. I am
> interested in how this is being done currently in XACML PDPs. (David's
> policy language is different and I am not familiar with its capabilities.)
the policy language is not actually an issue, since rules 2a and 2b
above can presumably to translated into any access control policy
machine language. What our implementation has done is provide the
context handling wrapper that holds the BTG state. It can wrap any type
of PDP that supports the XACML interface.
regards
David
> Hal
>
>
Original Message-----
> *From:* Davis, John M. [mailto:Mike.Davis@va.gov]
> *Sent:* Thursday, December 09, 2010 1:15 AM
> *To:* David Chadwick; xacml
> *Subject:* RE: [xacml] Draft BTG Profile
>
> David,
>
> Updated the previous discussion and BTG with editorial corrections,
> additional definitions and linkage to “data segmentation”.
>
> 1. We have agreed BTG is defined by mode c.
>
> 2. We still (in my mind) need to expand the profile discussion
> beyond the single attribute of user role to a broader view of
> sensitivity attributes applicable to segmentation. This is the
> general case, providing a flexible capability to deal with a broader
> range of policies beside role attributes and to decide and enforce
> attribute based access control based upon segmentation and BTG.
>
> *Access Control System Modes*
>
> The following modes of access control system operation are defined
> based upon possession or lack of possession of access control
> attributes.
>
> a) those who have permission to access the resource (e.g., ANY
>
> permission that grants access)
>
> b) those who are denied access to the resource (e.g., possess NO
>
> permission for the resource)
>
> c) those who are normally denied access but may choose to BTG and gain
>
> access if they deem it appropriate (e.g. they break the barrier by
> "choice" rather than by asserting any further/special permissions).
>
> d) those who are normally denied access but may gain access by
>
> elevating privilege
>
> *e) Bypass. Insecure system state in which access control
> decision/enforcement is intentionally disabled or circumvented by
> authorized users. *
>
> Note 1: 1. Regarding "Bypass/override". This vocabulary is
> overloaded with Canada using it (as I recall) equivalent to BTG. A
> distinctly different meaning of bypass is a maintenance/programming
> mode (in which the system is purposely placed in a non-secure state
> circumventing security controls). :
>
> *BTG USE CASE*
>
> Example BTG Use Case illustrating both mode a) and c) above:
>
> Definitions:
>
> ·Access Control Information (ACI). Any information used for access
> control purposes, including contextual information. ISO 10181-3
> Access Control defines classes of access control ACI. Classes of
> access control decision information (ACI) include: Initiator,
> Target, Access request, Operand, Contextual, Initiator-bound,
> Target-bound, Access-request bound.
>
> ·Access Control Decision Information (ADI). The portion (possibly
> all) of the ACI made available to the Access Control Decision
> Function in making a particular access control decision. ISO 10181-3
>
> ·Attribute – Characteristic of a subject, resource, action or
> environment that may be referenced in a predicate (attribute
> statement that can be evaluated) or target. OASIS eXtensible Access
> Control Markup Language (XACML)
>
> ·Permission. An approval to perform an operation on one or more RBAC
> protected objects. . ANSI-INCITS 359-2004
>
> ·Security Domain. A set of users, a set of protected objects and the
> security policy that binds the two. ISO/IEC 15816 (ITU X.841)
>
> ·Segment (General). A subset of the information objects within a
> security domain whose members share one or more access control
> decision information attributes (e.g. all records with Target
> ADI=”VIP”, all records with Contextual ADI=”Psychiatric Ward”, all
> records with Target bound ADI=”Care Team AND patient record =”Smith”).
>
> ·Segment (HITECH). A subset of specific and sensitive individually
> identifiable health information within a security domain whose
> members share one or more access control decision information
> attributes.
>
> ·Target. The set of decision requests, identified by definitions for
> resource, subject and action, that a rule, policy or policy set is
> intended to evaluate. OASIS eXtensible Access Control Markup
> Language (XACML)
>
> Action: User (initiator) operates in Domain A and has proper
> permissions/roles to perform assigned tasks. In the course of
> activities, this user desires to search for a record within a
> defined VIP segment of Domain A under a purpose of use = “XXX” and
> Domain A policy=”YYY”:
>
> **
>
> Domain A POLICY: Grant Initiator access to Domain A objects with
> Target sensitivity attribute=”X” IFF Initiator role=”Y” and
> (Initiator sensitivity attribute = “X” OR BTG Warning=”Yes”).
>
> Note 1: Access to most domain data is obtained with role
> Y=”Clinician” and target sensitivity attribute = “Null”, however VIP
> records are marked with Sensitivity attribute = “VIP” and therefore
> the user must either already hold this attribute or assert the BTG
> Warning attribute at runtime.
>
> 1.The user authenticates and accesses the system using the
> “Clinician” role suitable for the purpose of use of “Treatment”.
>
> 2.S/He searches for a record
>
> 3.The record has Target attribute=VIP.
>
> 4.If the user possess the Initiator sensitivity attribute “VIP” (or
> better) then access is granted (this is NOT BTG),
>
> 5.If the user does not possess the “VIP” attribute, then the access
> control system throws an exception which causes the application to
> present the user with the BTG warning banner (e.g., Acknowledge
> understanding that your activities will be audited, supervisor will
> be notified, etc do you accept YES/NO?).
>
> 6.The user accepts the warning=”Yes”.
>
> 7.The request is resubmitted this time with the attribute BTG
> warning=”Yes” (this is BTG).
>
> 8.The access control system grants access (re-evaluates the policy
> including the run-time BTG warning acknowledgement which is now
> present).
>
> Note 2: Possession of the sensitivity attribute (STEP 4) is
> functionally equivalent to the proposed BTG Permission (can access
> VIP Segment objects where permission operation=”access” and
> protected object=”VIP Segment Objects”) and presumes a pre-existing
> authorization attribute. Asserting an authorization attribute
> already held is NOT BTG.
>
> Note 3:Lack of any authorization attribute specific to the segmented
> data and the user “Choice” to accept the BTG Warning is the key
> element of BTG that distinguishes it from other access modes.
>
>
> *Annex A HITECH Data Segmentation Provisions*
>
> */HITECH Provision Directing Consideration of Data Segmentation /*
>
> */‘‘/**SEC. 3002. HIT POLICY COMMITTEE. *
>
> ‘‘(a) ESTABLISHMENT.—There is established a HIT Policy Committee to
> make policy recommendations to the National Coordinator relating to
> the implementation of a nationwide health information
>
> technology infrastructure, including implementation of the strategic
> plan described in section 3001(c)(3).
>
> ‘‘(b) DUTIES.—
>
> ‘‘(1) RECOMMENDATIONS ON HEALTH INFORMATION TECHNOLOGY
>
> INFRASTRUCTURE.—The HIT Policy Committee shall recommend a policy
> framework for the development and adoption of a nationwide health
> information technology infrastructure that permits the electronic
> exchange and use of health information as is consistent with the
> strategic plan under section
>
> 3001(c)(3) and that includes the recommendations under paragraph
> (2). The Committee shall update such recommendations and make new
> recommendations as appropriate.
>
> ‘‘(2) SPECIFIC AREAS OF STANDARD DEVELOPMENT.—
>
> ‘‘(A) IN GENERAL.—The HIT Policy Committee shall recommend the areas
> in which standards, implementation specifications, and certification
> criteria are needed for the electronic exchange and use of health
> information for purposes of adoption under section 3004 and shall
> recommend an order of priority for the development, harmonization,
> and recognition of such standards, specifications, and certification
> criteria among the areas so recommended. Such standards and
> implementation specifications shall include named standards,
> architectures, and software schemes for the authentication and
> security of individually identifiable health information and other
> information as needed to ensure the reproducible development of
> common solutions across disparate entities.
>
> ‘‘(B) AREAS REQUIRED FOR CONSIDERATION.—*/For purposes /* */of
> subparagraph (A), the HIT Policy Committee shall /* */make
> recommendations for at least the following areas: /* */‘‘(i)
> Technologies that protect the privacy of health /* */information and
> promote security in a qualified electronic /* */health record,
> including for the segmentation /* */and protection from disclosure
> of specific and sensitive /**/individually identifiable health
> information with the /* */goal of minimizing the reluctance of
> patients to seek /* */care (or disclose information about a
> condition) because /* */of privacy concerns, in accordance with
> applicable /* */law, and for the use and disclosure of limited data
> /* */sets of such information./**//*
>
> */‘‘(8) C/**/ONSIDERATION/**/.—The National Coordinator shall ensure /*
>
> */that the relevant and available recommendations and comments /*
>
> */from the National Committee on Vital and Health Statistics /*
>
> */are considered in the development of policies. /*
>
> Link to NCVHS Privacy Recommendations 2006-2008 (combined )
>
> http://www.ncvhs.hhs.gov/privacyreport0608.pdf
>
> /Regards, Mike Davis, CISSP///
>
> /Department of Veterans Affairs/
>
> Office of Health Information
>
> Security Architect
>
> 760-632-0294
>
> *From:*Davis, John M.
> *Sent:* Thursday, December 02, 2010 7:37 AM
> *To:* David Chadwick; xacml
> *Subject:* Re: [xacml] Draft BTG Profile
>
> David,
>
> Thanks for the comments and lively discussion. Below are some
> follow-on definitions and an example…intended to clarify security
> concepts involved more than call up specific XACML mechanisms.
>
> 1. Regarding "Bypass/override". This vocabulary is overloaded with
> Canada using it (as I recall) equivalent to BTG. A distinctly
> different meaning of bypass that I’m more familiar with is a
> maintenance/programming mode (in which the system is purposely
> placed in a non-secure state circumventing security controls).
> Adding this to the list of access modes:
>
> a) those who have permission to access the resource (e.g., ANY
>
> permission that grants access)
>
> b) those who are denied access to the resource (e.g., possess NO
>
> permission for the resource)
>
> c) those who are normally denied access but may choose to BTG and gain
>
> access if they deem it appropriate (e.g. they break the barrier by
>
> "choice" not by asserting any further/special permissions).
>
> d) those who are normally denied access but may gain access by
>
> elevating privilege
>
> *e) Bypass. Insecure system state in which access control
> decision/enforcement is intentionally disabled or circumvented by
> authorized users. *
>
> 2. Here is a example BTG Use Case illustrating Case c above:
>
> *BTG USE CASE*
>
> Definitions:
>
> ·Security Domain. A set of users, a set of protected objects and the
> security policy that binds the two.
>
> ·Access Control Decision Information (ACI). ISO 10181-3 Access
> Control defines classes of access control ACI. Classes of access
> control decision information (ACI) include: Initiator, Target,
> Access request, Operand, Contextural, Initiator-bound, Target-bound,
> Access-request bound.
>
> ·Permission. Per ANSI-INCITS 359-2004 a /Permission /is an approval
> to perform an operation on one or more RBAC protected objects.
>
> user (initiator) operates in Domain A and has proper
> permissions/roles to perform assigned tasks. In the course of
> activities, this user desires to search for a record within a
> defined VIP segment of Domain A under a purpose of use = “XXX” and
> Domain A policy=”YYY”:
>
> Domain A POLICY: Grant Initiator access to Domain A objects with
> Target sensitivity attribute=”X” IFF Initiator role=”Y” and
> (Initiator sensitivity attribute = “X” OR BTG Warning=”Yes”).
>
> Note 1: Access to most domain data is obtained with role
> Y=”Clinician” and target sensitivity attribute = “Null”, however VIP
> records are marked with Sensitivity attribute = “VIP” and therefore
> the user must either already hold this attribute or assert the BTG
> Warning attribute at runtime.
>
> 9.The user authenticates and accesses the system using the
> “Clinician” role suitable for the purpose of use of “Treatment”.
>
> 10.S/He searches for a record
>
> 11.The record has Target attribute=VIP.
>
> 12.If the user possess the Initiator sensitivity attribute “VIP” (or
> better) then access is granted (this is NOT BTG),
>
> 13.If the user does not possess the “VIP” attribute, then the access
> control system throws an exception which causes the application to
> present the user with the BTG warning banner (e.g., Acknowledge
> understanding that your activities will be audited, supervisor will
> be notified, etc do you accept YES/NO?).
>
> 14.The user accepts the warning=”Yes”.
>
> 15.The request is resubmitted this time with the attribute BTG
> warning=”Yes” (this is BTG).
>
> 16.The access control system grants access (re-evaluates the policy
> including the run-time BTG warning acknowledgement which is now
> present).
>
> Note 2: Possession of the sensitivity attribute (STEP 4) is
> functionally equivalent to the proposed BTG Permission (can access
> VIP Segment objects where permission operation=”access” and
> protected object=”VIP Segment Objects”) and presumes a pre-existing
> authorization attribute. Asserting an authorization attribute
> already held is NOT BTG.
>
> Note 3:Lack of any authorization attribute specific to the segmented
> data and the user “Choice” to accept the BTG Warning is the key
> element of BTG that distinguishes it from other access modes.
>
> Regards, Mike Davis, CISSP
>
> Department of Veterans Affairs
>
> Office of Health Information
>
> Security Architect
>
> 760-632-0294
>
>
Original Message-----
> From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk]
> Sent: Tuesday, November 30, 2010 12:34 AM
> To: Moehrke, John (GE Healthcare)
> Cc: xacml
> Subject: Re: [xacml] Draft BTG Profile
>
> Hi John
>
> In an earlier posting John Davis identified 4 use cases, which are worth
>
> repeating again here
>
> a) those who have permission to access the resource (e.g., ANY
>
> permission that grants access)
>
> b) those who are denied access to the resource (e.g., possess NO
>
> permission for the resource)
>
> c) those who are normally denied access but may choose to BTG and gain
>
> access if they deem it appropriate (e.g. they break the barrier by
>
> "choice" not by asserting any further/special permissions).
>
> d) those who are normally denied access but may gain access by
>
> elevating privilege
>
> We both agree that c) is BTG, but we still dont agree on the mechanism;
>
> specifically, whether a permission to perform the BTG action is needed
>
> or not. I believe in the general case it is, John believes it is not and
>
> that it can be implied by context.
>
> There is also the issue of whether overriding access control is a
>
> different use case to BTG or is the same as the BTG use case above. I
>
> believe it is the same as the BTG use case. You believe it is different.
>
> Therefore it would be good if you could add a fifth use case to the
>
> above 4 which describes why override is different to them.
>
> On 29/11/2010 17:24, Moehrke, John (GE Healthcare) wrote:
>
> > I agree with much of the sentiment that we need to make sure we
>
> > understand the problem well before we solve it. I do however believe
>
> > that we have multiple useful use-cases. Some environments do indeed
>
> > want to have a permission that is only assigned to senior clinicians
>
> > where they are privileged to override. I do agree with Mike that this
>
> > should not be called BTG, as I agree with Mike that we should be
>
> > consistent with our understanding of what BTG is vs other use-cases.
>
> > We have tried to come up with just as catchy names of these other
>
> > use-cases.
>
> >
>
> > Another aspect of these set of use-cases that I am not seeing is that
>
> > in the case where a user override would allow something, there is a
>
> > predicate communication that likely preceded this. For example, how
>
> > did the clinician know that a document existed for which they are
>
> > being denied access with an override possibility?
>
> A normal intuitive guess is one answer. Here is one example of this. The
>
> doctor has a patient in A&E. The doctor looks up the patient name in the
>
> DB, and then asks to read the patient record. This is returned. He then
>
> asks to retrieve the DNA records (or other sensitive data such as AIDS
>
> etc.) and is denied access with a BTG response. He enters a reason
>
> (person is bleeding in A&E) and breaks the glass. He is then granted
>
> access. We have another live demo example and test here
>
> https://authz.tas3.kent.ac.uk:8443/btg/
>
> Typically this
>
> > predicate transaction needs also to understand that access is
>
> > contingent on future state change. If the user could not use an
>
> > override, then the predicate transaction should not return the
>
> > result. (note that this is also regionally defined in policy; as I do
>
> > know of regions/organizations that do want to tempt their clinicians
>
> > with objects that they couldn't get access to at all; whereas other
>
> > regions do not ever want to tempt their clinicians.)
>
> >
>
> > So, this is not just the use-case of the transaction where BTG flag
>
> > would be submitted, but this also affects other transactions too. I
>
> > don’t think this changes the potential solutions, but does broaden
>
> > the description when we get around to that.
>
> this does indeed broaden the potential use cases considerably if we are
>
> concerned with an action now that can effect another action many steps
>
> down in a workflow. I must admit that we have not yet considered such
>
> use cases
>
> regards
>
> David
>
> >
>
> > John
>
> >
>
> >>