[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Break the Glass policies
David -- I have not delved in obligations, so I can't make any meaningful comment. The list of exceptional circumstances are certainly derived from policy, and it would be far better (less expensive, more reliable) if they could be maintained there (in PDP) rather than having to be coded (and updated) in every application. No idea how this would be implemented, I'm afraid . . . Martin -----Original Message----- From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk] Sent: Wednesday, December 16, 2009 5:54 PM To: Smith, Martin Cc: Ludwig Seitz; xacml; Waterman, K. Krasnow <CTR>; Hammar, Patricia <CTR>; John, Anil; Tom Karygiannis Subject: Re: [xacml] Break the Glass policies Hi Martin Smith, Martin wrote: > David -- Agree with your considerations. FWIW, I was visualizing this > from the ujser interaction POV (w/o worrying about implementation or > efficiency.) What I imagined was a person issuing a query, and then > getting a pop-up Yes this is what our hospital application does. BTW we have a very simple public demo here http://issrg-testbed-2.cs.kent.ac.uk/ > saying: "You are not authorized access to the requested information > EXCEPT in the following circumstance(s): [drop-down list of > circumstances]. Hmm. where does the application get these circumstances from? Would they be part of the policy and returned as obligations with the BTG response? Or would they simply be configured into the application? We have envisaged a different set of messages, which we called Consequences, that would pop up to warn the user of the consequences of breaking the glass. These would also be returned as obligations (to be displayed to the user by the PEP) in the BTG response. We already have obligations on grant or deny, so could have them on BTG as well. If any of these applies to your request, select it and > then press the CERTIFY botton to certify that the circumstance applies > to this access request. Otherwise press CANCEL. Note: this transaction > and your certification will be recorded." The note you specify above is one of the Consequences that we envisaged. By encoding them as obligations in the policy you get much greater freedom what to tell the user. > > Well, I hope it would be a bit less wordy that that. <g> I am sure if this feature was already implemented in PDPs, then applications would be much more likely to make use of it regards David > > Martin > > > -----Original Message----- > From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk] > Sent: Tuesday, December 15, 2009 4:38 PM > To: Smith, Martin > Cc: Ludwig Seitz; xacml; Waterman, K. Krasnow <CTR>; Hammar, Patricia > <CTR>; John, Anil; Tom Karygiannis > Subject: Re: [xacml] Break the Glass policies > > Hi Martin > > at the NIST PMI conference in September the DoD had a similar concept of > overriding access control for operational reasons, but the main > difference to BTG is that in the DOD model a system component evaluates > the operational need and either overrides or does not on behalf of the > user. With BTG we are giving power back to the user to make the informed > choice. One thing that our hospital trials uncovered is that you do need > the audit and checks afterwards, otherwise it is hypothesised that once > users learn that there are no consequences for always BTGing, they > always will do it. > > The purpose for us defining the BTG model and third response it to build > the complexity into the application independent PDP layer with > consequent simplicity in the PEP layer, and simplicity in specifying the > BTG policies. We therefore hope it will make this type of access control > much easier to implement in all sorts of application scenarios. > > regards > > David > > > Smith, Martin wrote: >> David, all -- >> >> In looking at access policies based on formal policy authorities (like > >> laws and frederal regulation) we've seen a number of cases where the >> only practical source of a person or environmental "attribute" is >> assertion by the requestor. The "BTG" attribute is an assertion that >> an emergency situation exists. We also have come to the same >> conclusion that you have (apparently), namely that ex-post enforcement > >> (via audit of access logs) is a sufficient basis for enforcement for >> many kinds of policies. >> >> Another general class of self-assertion situations is where a law or >> policy says "you can share information 'for the purpose of' > something." >> Example: passpost clerks can view personal passport records 'for the >> purpose of' varifying information in the course of processing a >> passport renewal application, (but not for other purposes, like >> browsing the information of celebrities.) In many of these scenarios >> one might imagine a data source for the attribute that did not depend >> on self-assertion, but those data may not be available at least in the > >> short run. >> >> I have not considered implementation of this enforcement strategy >> (self-assertion plus log audit) to be a standards issue, so much as a >> tooling issue (does a PDP product support pop-up requests for >> self-asserted information?) But if making a BTG profile stimulates >> vendors to add capability for collecting self-assertion data, I'm for >> it! >> >> Martin Smith >> US Department of Homeland Security >> >> >> >> -----Original Message----- >> From: xacml-return-1875-martin.smith=dhs.gov@lists.oasis-open.org >> [mailto:xacml-return-1875-martin.smith=dhs.gov@lists.oasis-open.org] >> On Behalf Of Ludwig Seitz >> Sent: Monday, December 14, 2009 2:52 AM >> To: David Chadwick >> Cc: xacml >> Subject: Re: [xacml] Break the Glass policies >> >> Hi David, >> >> you might want to look at this: >> http://portal.acm.org/citation.cfm?id=1263871 >> >> I think it is very similar to what you want to achieve. >> >> Regards, >> >> Ludwig >> > -- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, 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]