OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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