[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]