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