[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Draft BTG Profile
Hi John
On 30/11/2010 16:04, Moehrke, John (GE Healthcare) wrote:
> This makes good sense for an organizational emergency mode, but is not
> very scalable for a session or transactional emergency mode.
I beg to disagree here. We have done performance and scalability tests
on our implementation (using an in-memory BTG state database) and the
results are very impressive. We are currently writing this up for a
journal paper.
regards
David
Most of
> the use-cases are very specific to a single request for data (or a chain
> of requests).
>
> John
>
>> -----Original Message-----
>> From: Smith, Martin [mailto:Martin.Smith@DHS.GOV]
>> Sent: Tuesday, November 30, 2010 9:38 AM
>> To: Davis, John M.; David Chadwick; Rich.Levinson
>> Cc: Ludwig Seitz; xacml
>> Subject: RE: [xacml] Draft BTG Profile
>>
>> John/David, et. Al--
>>
>> And another thought . . .
>>
>> I had suggested: " Why not model "BTG=yes" as an environmental
> variable,
>> which is maintained as a resource (i.e., database) with appropriate
>> access
>> control (like "anyone in the hospital" or "a designated fire marshall
> or
>> alternate") on updating it? "
>>
>> We might think of the BTG "state" datum as a service (vs. element in a
>> database); and such a service might be provided by a real-world
> physical
>> device (a glass-protected alarm in this case) attached to the cloud,
>> which when activated would sound an audible alarm, of course, and also
>> make available its state ("glassBroken") if queried from the cloud by
> a
>> PDP. Thus the "attributes" requirement for someone to update BTG state
>> would be exactly what it already is: physical access to the alarm and
>> ability to break the glass. (Sorry--no access audit!)
>>
>> Makes for a nice economical unity between real-world environment and
>> cyber-decision-making.
>>
>> 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
>> (800) 417-6930 page
>> -----Original Message-----
>> From: Davis, John M. [mailto:Mike.Davis@va.gov]
>> Sent: Monday, November 29, 2010 1:42 PM
>> To: Smith, Martin; David Chadwick; Rich.Levinson
>> Cc: Ludwig Seitz; xacml
>> Subject: RE: [xacml] Draft BTG Profile
>>
>> This suggestion is appealing. It is general enough to support a
> number
>> of specific instances and policies without requiring a point solution
>> for a specific problem. There are a number of similar variables,
>> constraints and other attributes associated with access to an object
>> "purpose of use", "location", "separation of duty", "normal working
>> hours" already part of access control decisions. Environmental
>> variable, are one of the classes of access control decision
> information
>> found in ISO 10181-3 (environmental is one, others including target or
>> access request ACI might also be appropriate).
>>
>> It might even be possible to logically extend "BTG=yes" as
> environmental
>> variable model any ACI variable associated with a policy that includes
> a
>> BTG attribute.
>>
>> Regards, Mike Davis, CISSP
>> Department of Veterans Affairs
>> Office of Health Information
>> Security Architect
>> 760-632-0294
>>
>>
>> -----Original Message-----
>> From: Smith, Martin [mailto:Martin.Smith@DHS.GOV]
>> Sent: Monday, November 29, 2010 10:00 AM
>> To: David Chadwick; Rich.Levinson
>> Cc: Ludwig Seitz; xacml
>> Subject: RE: [xacml] Draft BTG Profile
>>
>> David, all--
>>
>> Why not model "BTG=yes" as an environmental variable, which is
>> maintained as a resource (i.e., database) with appropriate access
>> control (like "anyone in the hospital" or "a designated fire marshall
> or
>> alternate") on updating it?
>>
>> This would toss the whole thing outside XACML, and make it just one of
> a
>> very large set of specific scenarios in which the PDP has to query an
>> external (environmental) state (like "currentThreatLevel") maintained
>> somewhere "in the cloud."
>>
>> 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
>> (800) 417-6930 page
>>
>> -----Original Message-----
>> From: xacml-return-2280-martin.smith=dhs.gov@lists.oasis-open.org
>> [mailto:xacml-return-2280-martin.smith=dhs.gov@lists.oasis-open.org]
> On
>> Behalf Of David Chadwick
>> Sent: Monday, November 29, 2010 7:21 AM
>> To: Rich.Levinson
>> Cc: Ludwig Seitz; xacml
>> Subject: Re: [xacml] Draft BTG Profile
>>
>> Hi Rich
>>
>> On 28/11/2010 20:41, Rich.Levinson wrote:
>>> Hi David and Ludwig, et al,
>>>
>>> I have been following this discussion and it seems to simply revolve
>> around
>>> Policy definitions that Deny access under a given set of conditions,
>>
>> and state information. It is important to bear in mind which element
> is
>> updating the BTG state (or attribute).
>>
>> If the PDP understands that BTG is a special attribute (or state
>> variable) then it can act in a special way when it is mentioned.
>>
>> If the PDP does not understand BTG then no changes are needed to the
>> XACML specification (scenario iii) below).
>>
>> There are 3 scenarios, namely
>>
>> 1) PDP understands BTG and keeps the BTG state
>> ii) PDP understands BTG but does not keep the state
>> iii) PDP does not understand BTG
>>
>> I believe that your description below is addressing scenario ii) only
>> (correct me if I am wrong)
>>
>> but
>>> will
>>> Permit access if there is that given set of conditions PLUS there is
> a
>> BTG
>>> indicator that can be checked and if its value is
>> "glass-has-been-broken"
>>> (BTG = true), then access is permitted:
>>>
>>> * (given-conditions = true) AND (BTG = false) then Deny
>>> o + send back BTG as reason for Deny, and indicating
>>> obligations PEP has to tell user reason for denial and
>>> options user has to get access
>>
>> Rather I would say that these obligations are future obligations that
>> the PEP must enforce if the user decides to BTG. If the user does not
>> BTG, then no obligation enforcement is necessary. But if the user does
>> BTG, then the state has to be changed by the PEP, and it is the
> changing
>>
>> of the state that requires these obligations to be enforced. If they
>> cannot be enforced the state should not be changed. E.g. If the
>> obligation says to log this and email the manager, and the PEP is not
>> able to do this, then the glass should not be broken, since no-one can
>> be informed about it and the user will not have any explaining to do
>> later. (Note that in our design we have the concept of Fallback
>> obligations which are to be performed if the primary obligations
> cannot
>> be, in order to try to address this issue, but this is a second level
>> issue to the current problem.)
>>
>>> * (given-conditions = true) AND (BTG = true ) then Permit
>>> o + send back BTG indicating obligations PEP must enforce
>>> when in BTG = true state
>>
>> This is a very interesting take on the scenario. What you are
> suggesting
>>
>> here is that the BTG obligations should only be enforced when the user
>> actually exits the hotel through the firedoor. What I am suggesting
>> above is that the obligations are enforced when the user breaks the
>> glass, regardless of whether he decides to subsequently exit the hotel
>> or not. This is an interesting conceptual point that should be
> discussed
>>
>> further, because clearly it effects which obligations should be
> enforced
>>
>> when. It also effects how many times the obligations are enforced. In
>> your scenario they are enforced for everyone who subsequently leaves
> the
>>
>> hotel by the firedoor, in my scenario they are only enforced on the
>> person who breaks the glass. This again is an interesting conceptual
>> point. If I exit a hotel via an open fire door, should I have to
> explain
>>
>> this later to someone. If I view a patient record, which is for say a
>> VIP and someone has previously broken the glass for me, should I have
> to
>>
>> explain this later. If I break the glass on a VIP record but I do not
>> actually view the record, should I have to explain this later to
>> someone?
>>
>>
>>>
>>> I agree it wouild be useful to have a profile describing how to
>> implement
>>> this using standard XACML PolicySets, which, it seems to me can be
>>> done in some fairly straight-forward manners using designated URIs
> for
>>> AttributeIds and ObligationIds, the semantics of which can be
>> implemented
>>> by the PIPs and PEPs.
>>>
>>> For example, if there is a special AttributeId = "...btg", and a
>> trusted
>>> Issuer of this attribute, then the Policy can look for it within
>> the
>>> context
>>> of the request.
>>> Similarly, a Deny response could use a profile-specific
>> status-code or
>>> just some designated ObligationId to indicate there are
>>> AttributeAssignments
>>> with AttributeId URIs indicating what the PEP is supposed to do.
>>>
>>> Bottom line is I would want to understand what cannot be done w
> XACML
>>> 2.0 with
>>> a guiding profile using Attributes and Obligations, before defining
>>> alternate means, which
>>> might eventually prove to have needlessly added complexity to the
>> specs.
>>>
>>> Currently, the XACML 2.0 spec indicates that a PEP should only make
>>> specific decisions
>>> if it understands any Obligations that are returned with the
> decision,
>>> so it seems to me that
>>> a trusted Attribute with the BTG state plus a set of appropriate
>>> Obligations should be
>>> sufficient for this use case.
>>
>> You are most probably correct. The reason I proposed Consequences in
> our
>>
>> draft instead of Obligations, was that they were future obligations on
> a
>>
>> subsequent action rather than the current one, whereas with your model
>> above there is no need for future actions since you perform the
>> obligations each time the user accesses the resource and not when the
>> user breaks the glass.
>>
>> regards
>>
>> david
>>
>>
>>>
>>> Thanks,
>>> Rich
>>>
>>>
>>> David Chadwick wrote:
>>>> Hi Ludwig
>>>>
>>>> On 26/11/2010 08:32, Ludwig Seitz wrote:
>>>>> On Thu, 2010-11-25 at 17:05 +0000, David Chadwick wrote:
>>>>>> Hi Ludwig
>>>>>>
>>>>>> The model you have appears to be that each user must BTG himself,
>> and
>>>>>> then he is given the BTG attribute after agreeing to this. But
> this
>> is
>>>>>> not the model we have, and it is not the model of BTG in general
>>>>>> (e.g. a
>>>>>> fire door in a hotel).
>>>>>
>>>>> You claim your model represents the model of BTG in general. Can
> you
>>>>> support these claims?
>>>>
>>>> Yes in so far as it has been implemented and we have not yet come
>>>> across any BTG requirement that it cannot satisfy. So in that
> respect
>>>> it is as general as the HL7 model (which is not a universal
> standard
>>>> either)
>>>>
>>>>
>>>>>
>>>>> In a previous mail Mike Davis seems to suggest your model is
>> different
>>>>> from HL7's requirements, and currently the requirements from HL7
> are
>> as
>>>>> close as it gets for "a model of BTG in general".
>>>>>
>>>>>> Our model is state based, ie. there is a BTG state that is
>> initially
>>>>>> false (corresponding to unbroken glass) and can be set to true
>>>>>> (corresponding to broken glass) by a defined class of user in the
>>>>>> policy.
>>>>>>
>>>>>> Another class of user (typically a manager) can reset the state
> to
>>>>>> false
>>>>>> (ie repair the glass).
>>>>>
>>>>> I see no difference between a BTG state and a BTG attribute. Could
>> you
>>>>> please explain where you see a difference?
>>>>
>>>> Clearly none if the attribute holds the state!
>>>> But in your attribute model you did not say how the attribute value
>>>> was set to different values. This was added in our model.
>>>>
>>>>
>>>>>
>>>>>> this model is much more general and flexible since it can be
>> applied to
>>>>>> individuals (as in your case) or to roles (e.g. doctors) or to
> any
>>>>>> combination of attribute holding subjects.
>>>>>>
>>>>>> Furthermore the glass state
>>>>>> can be applied to a single resource or a group of resources. To a
>>>>>> single
>>>>>> action or a group of actions. You can find details in last years
>> ACSAC
>>>>>> conference
>>>>>>
>>>>>
>>>>> I'm all in favor of a flexible BTG model, but from what you
> present
>> here
>>>>> I fail to see how that cannot be done within the current XACML
> (v3)
>> core
>>>>> standard.
>>>>
>>>> This is not the issue. The issue is, can we have a standard defined
>>>> way of doing it. You suggest using Advice to signal BTG, so I say
> we
>>>> should have a profile to standardise the contents of the BTG
> Advice.
>>>> But I also request a standard way of doing it in XACMLv2 as well,
> and
>>>> Advice cannot do that.
>>>>
>>>>
>>>>> There is absolutely no requirement for a BTG attribute to be
>> associated
>>>>> with a specific subject or resource. What this comes down to, is a
>>>>> question of attribute management, and that's outside the scope of
>> XACML.
>>>>
>>>> Actually it is in a twilight world, since you have PIPs which
> manage
>>>> attributes, but you dont describe how they work. So you sort of
>>>> acknowledge that attribute management is needed, but then dont say
>> how
>>>> to do it. What we are wanting to do, is for a specific type of
> access
>>>> control - BTG - is allow the XACML infrastructure (context handler,
>>>> PIPs, obligation service etc) to manage the BTG attribute/state so
>>>> that applications dont need to. But in order to do this we need to
>>>> standardise more of the protocol between the PEP and the XACML
>>>> infrastructure so that BTG can be handled by the infrastructure,
>>>> thereby reducing the load on applications.
>>>>
>>>>> (note that I think BTG profile should nevertheless give
>> recommendations
>>>>> about how to do that).
>>>>>
>>>>
>>>> which is what we tried to do in a general way in the draft profile.
>>>>
>>>>
>>>>> My point remains: You seem to derive the necessity to make changes
>> to
>>>>> the core standard from your BTG model. I am not convinced they are
>>>>> necessary to realize your BTG model.
>>>>
>>>> Clearly no changes are needed to XACML if you dump all the work on
>> the
>>>> PEP and the application. This is the status quo today. What we
> would
>>>> like to achieve is that the application independent code can take
>> some
>>>> of the burden off the PEP. This is the motivation for the profile.
>>>>
>>>>>
>>>>> There is a more important problem though: Before coming up with
>>>>> solutions for BTG, we need a good definition of what the
>> requirements
>>>>> for BTG really are. Right now we are starting with a solution and
>> are
>>>>> trying to make the requirements fit, and that seems like a bad
>> approach
>>>>> to me.
>>>>
>>>> If you care to read our ACSAC paper you will find a set of
>> requirement
>>>> there which were derived from the hospital. So we started with a
> set
>>>> of requirements and derived an application independent way of
>>>> satisfying them.
>>>>
>>>> regards
>>>>
>>>> David
>>>>
>>>>>
>>>>> /Ludwig
>>>>>
>>>>>
>>>>>
>>>>
>>
>> --
>>
>> **********************************************************
>> *******
>> 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
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>> ---------------------------------------------------------------------
>> 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
*****************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]