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: [EXTERNAL] [xacml] Default behavior for unrecognized resource attributes?


Mike--As you say, real-world examples help the discussion. Thanks. 

Some initial reactions (maybe more later based on more careful consideration): 

1.  Assuming I understand your description of the security (access) labeling process, I think that sounds like a very good approach.  I actually prefer to see the separation of content from access attribute management, for the reasons you state. I am sure there is variation on where that metadata is stored and how it's discovered by a PIP, but that's really not the heart of the issue I was trying to raise. 

2.  I also like your "view" concept. It seems similar to the idea of the IEPD (which itself is somewhat similar to the serialized version of a result-set which is roughly map-able to a query.) I think of these things as equivalent to paper forms, since we are all used to exchanging standard forms and generally comfortable with the idea of determining what controls there should be on their distribution and handling. This "view" approach also provides a way to deal with the issue raised by alternatives like trying to label data table columns for sensitivity:  data in a result set may aggregate data from many columns in many tables and the sensitivity of the collected data may be higher than any of the columns.   

So, I'm not sure if I have anything to disagree with in your message, but I have a question: in the USG, the organization that collects data from the public is responsible for how it is used, not only by the collecting organization but also is supposed to make sure that if it provides a copy of the data to another organization that organization also observes the "routine uses" advertised for that data collection.  In most current practice, this obligation is handled by a memorandum between the two organizations, but actual enforcement is left entirely to the second organization. In the health-care sector, is any of this "enforcement" done via a commitment by the second organization to use an agreed digital rule set to control access to the data collected by the first organization and then provided to the second?  

Regards,

Martin


  




On Mon, Jan 4, 2016 at 4:44 PM, Davis, John M. <Mike.Davis@va.gov> wrote:

Hey Martin,

 

At this point, in the  discussion.  I wanted to elaborate on: “resource "attributes" may be contained in resource content is built into the XACML spec.  Again, not an argument but elaboration.

 

Real world use cases in healthcare are a valuable shortcut for our communication.  I want to assure you that I am also speaking from behind a huge amount of existing healthcare security and privacy standards work which we may or may not share in common.  As such we may not be fully communicating.  Of course even healthcare is based upon existing ISO, NIST and other SDO standards that we undoubtedly share.  Just know that there are a number of healthcare standards that encompass both XACML and Delegated Access Control (e.g. OAuth, OpenID,  ) into a “reasonably”  workable access control framework for interoperability (in my view interoperability is the principal purpose of standards).  The main healthcare distinction is in the healthcare specific codesets/valuesets and details of the labeling scheme.  This framework includes ABAC, Data Segmentation for Privacy, a healthcare security and privacy classification system, a complete set of codes, messaging with ability to carry coded values for each entry, section, composition, policy fragments etc.  among others. Note:  OK, for the example:

 

Cross Organizational/Domain health information sharing real-world use case.

 

Assertion:

In the real world, protected information is shared between organizations with distinctly different and variable access control policies. 

 

References:

a)      HL7 Privacy and Security Healthcare Classification System

b)      HL7 Privacy, Access and Security Services:  Security Labeling Services

c)       HL7 Privacy, Access and Security Services: Access Control Services Conceptual Model

 

Core Concept to be demonstrated: 

Security and Privacy labels for access control are best treated as variable attributes of a labeling policy not intrinsic values of  the core information objects themselves but rather linked instead to the representations of those objects at runtime (e.g. at the time of an access control decision).

 

Discussion:

One of the things we learned in healthcare was that the security attributes of an object are fungible.  That means that rules that allow for object classification may  either be a) relatively static (as in laws, regulations=jurisdictional policy), b) moderately changeable (as in local directives=organizational policy) or c) dynamic (as in patient consent =patient policy).  In all cases however, the policy may change.  Here’s what happens:

 

1.       A clinical record contains “Clinical facts”.  These facts are legally “real”, such as the patient either has HIV or does not, is drug dependent or is not, has mental health issues or does not, etc.  These are hard attributes of the data applied to the record.  They are NOT security labels.

2.       How this factual data is labeled for security and privacy depends on classification rules.  The classification attributes are themselves policy based.  Policy is not a fact so much as a current state of a classification attribute.  So “clinical value=HIV” may or may not cause the security label “security value=HIV” to be applied depending upon the labeling policy in effect.  Classification labels are applied based on national, state law or part of the patient’s consent directive. The distinction here is that the security  label is NOT a fact itself (except at the instant of labeling) but a variable dependent upon current state and conditions.  As such the object label cannot with certainty be permanently attached to the record (which would itself cause constant churning and relabeling) but needs to be maintained in a database which stores the labeling parameters rules that apply …at a specific point in time… for each individual patient…and dependent upon the purpose for which the information is to be used (labeled as sensitive for marketing operations , not sensitive for treatment) .  This labeling activity is accomplished by a “Security Labeling Service”.  The representation of the information object labeled as an specific instance of an extract, message etc. is applied by this service.

3.       Based on #2, it is possible to classify and label the runtime copy or “View*” of a healthcare resource as “Very Restricted, Restricted, Normal, …) without necessarily labeling the resource itself in situ.  It is also possible to classify the view of  individual entry level items based upon attributes of classification, sensitivity, and integrity(meaning trustworthiness), and compartment (group to which the data belongs, e.g. pharmacy) etc..  It is also possible to label data as to the policy set that applies to its use (for example a response to a treatment query labeled “Do not  Re-disclose without Patient Consent”).  (*For clarity I am defining “View” as the current instance of a labeled representation of a resource in context and at a specific point in time such as screen display, extract for communications, processing, messaging or other purpose.)

As part of the trust agreement for sharing, we might expect the recipient to honor the label and policy even if that policy is not part of the recipient’s domain. The international HL7 Privacy and Security Classification System defines all of these labels, their use and their vocabularies.

 

Conclusion: 

Because the labeling of an object may change, as described above , we cannot treat security and privacy labels as fixed attributes permanently attached to an object and just store it as if it were a clinical fact in the patient record.  The variability might mean that the object classification changes from one moment to the next.  A large healthcare organization may also span multiple jurisdictional boundaries for the same patient.  HIV in one state may be classified as sensitive and in another it is not.  From the healthcare organizations perspective, since the patient record may exist in multiple jurisdictions (states, provinces, countries, etc) so the labeling applied (and consequently the access control decision) for the same record may possibly vary and cannot be known except at runtime.  The patient clinical facts do not change but the labels do.  It is therefore not possible to say patient XYZ’s record is HIV sensitive with certainty under all circumstances because that statement depends on what state you are in and what the patient has said about that information.  So clinical facts do not change but the security labels for those facts may.

 

RE:  “resource "attributes" may be contained in resource content is built into the XACML spec”.  This is true when the resource attributes (labels) are dynamically assigned to representations of a resource at the time a decision is to be made.  It need not imply that the resource attributes are immutable constants.

 

An example from another domain (not perfect):  Water composition is known as H2O.  The mass of a given amount is known.  All facts.  Whether it can be labeled as a solid, liquid or vapor is not known unless you know something about its current state.  Water state is subject to the laws (rules) of physics.  Healthcare security and privacy labels are similar to labels for water state.  You can’t determine the security and privacy label for the representation of a healthcare object security with certainty unless you know something about its current state which is subject to variable jurisdictional, organizational and patient labeling rules..

 

 

Regards, Mike Davis

VHA Security Architect

760-632-0294

 

 

 

 

 

From: Martin Smith [mailto:bfc.mclean@gmail.com]
Sent: Sunday, January 03, 2016 8:27 PM
To: Davis, John M.
Cc: Hal Lockhart; William Parducci; XACML TC
Subject: Re: [EXTERNAL] [xacml] Default behavior for unrecognized resource attributes?

 

Mike-- Thanks for the thoughtful response and Happy New Year!  You raise some good issues. 

 

Here are some initial reactions: 

 

1.  The idea that resource "attributes" may be contained in resource content is built into the XACML spec. This is illustrated in your example in which part of the patient record (i.e. that the patient is DOD-affiliated) is serving both as "payload" data and access-control metadata. The goal of accounting for all access-control resource attributes requires figuring out where they are, and I haven't thought specifically about how to identify those parts of content that should be considered as metadata.

 

2.  Your example of "emergency access" (and the DOD one, too) raises another issue I hadn't focused on:  the role of the combining algorithm. Suppose one can collect all the policies that refer to all the access-related metadata associated with a resource and determines that each resource attribute is used by at least one of those policies. Even so, if the combining algorithm stops processing once it finds one rule that is satisfied, then the goal of giving each resource attribute a chance to "protect" the resource is not achieved. So, it looks like the profile I'm hoping to develop must set some conditions for the combining algorithm.

 

3. Regarding: " . . . different policies based upon attributes of the requester, environmental etc. . . . "  Lets look at this from a "data-centric" point of view. The set of constraints (policies derived from laws, regs, contracts, etc.) that applies to a particular protected resource does not vary (unless laws, etc. change.) To be compliant, every access must meet every constraint that applies to that resource. Each resource attribute is there because it identifies an access-relevant characteristic that is linked to a policy that applies to that resource. If that policy is not included in the policy set that is processed for a request to access the resource, then something is wrong. (This does not mean that a particular rule cannot be pre-empted by another rule that expresses a permitted exception, like an emergency provision, and which is effectively given precedence via the combining algorithm.) 

 

4.  I am a little puzzled by your distinction between the "sensitivity" of a resource (which seems to be related to privacy policies) and other access-relevant characteristics.  It seems to me that all the access-relevant characteristics of a resource ought to be expressed in terms of resource attributes. Might be worth some discussion. 

 

Again, thanks for your thoughts and questions, and particularly for the real-world implementation examples. 

 

Regards,

 

Martin

 

 

 

 

 

 

 

 

  

 

 

 

 

 

 

 

 

On Sat, Jan 2, 2016 at 10:59 AM, Davis, John M. <Mike.Davis@va.gov> wrote:

Martin,

 

Please elaborate. As I understand it, access control attributes of a resource are there to be used by a policy that determines what decision and obligations need to be made based upon the presented claims of a requester and other contextual attributes.    In VA, we control sensitive patient information but it is also common to have different policies based upon attributes of the requester, environmental etc.  For example, consider the following:

 

Case 1:  VA receives a routine request from entity A for access to patient X records.  The policy requires that A present attributes (clearances, tokens etc ) for portions of a record marked with sensitivity  “HIV”.  If A does not present the HIV clearance, then the decision may be to deny or an obligation is thrown to redact or mask the HIV information before responding.  However, if A asserts the purpose of use of “Emergency Access”( = imminent death or injury), then the information is released solely based on the purpose of use alone. 

 

Case 2:  VA receives a request from DoD for access to patient X.  The policy requires allows release to any member of DoD based purely on  affiliation (e.g. DoD).  Here the decision is made and the record released without any reference whatsoever to the resource attributes.

 

Summary

Case 1 Shows that the context of the case can determine whether resource attributes are even considered at all as the request itself may drive different policies for a given resource (Normal vs Emergency access).

Case 2 shows that there exist real-world examples where the sensitivity attributes of a resource are irrelevant to the decision.  In fact, it is the policy that determines which resource attributes are relevant based upon evaluation of the request, context etc  (e.g. purpose of use, organization, Role, location) applied before any consideration of resource sensitivity.

 

Am I mis-understanding?  It appears to me that your point 3 is incorrect.  Do you really mean that all attributes of a resource referenced in a given policy must be accounted for in the decision?  The point is that the sensitivity of a security attribute is relative to the context and in some cases (e.g. HIV) need not be evaluated at all (POU=emergency access).  Finally, it would seem that in some cases considerations other than resource sensitivity attributes might be the source of policy for an access control decision (e.g. compartment to which the user belongs=access is granted if requester is a member of the pharmacy group)

 

 

Regards, Mike Davis

VHA Security Architect

760-632-0294

 

 

From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Martin Smith
Sent: Tuesday, December 29, 2015 7:23 AM
To: Hal Lockhart; William Parducci; XACML TC
Subject: [EXTERNAL] [xacml] Default behavior for unrecognized resource attributes?

 

Hal, all-

 

I am pursuing Hal's suggestion below to explore the possibility of developing a profile that would assure that all access-related attributes of a resource are used by the set of policies applied to a request. 

 

To summarize the need: 1. in sensitive environments, all access-control policies applicable to a request have to be enforced; 2. access-control attributes of a resource are there for a reason: to advertise some characteristic of the resource that requires limiting access to it. 3. Therefore, If the set of policies applied to adjudicate and access request does not reference each resource attribute, something is wrong. 4. In a sensitive environment, the appropriate response is caution: to Deny access to the resource pending resolution of the disconnect between the collection of policies and the resource attributes associated with the resource. I ran this summary by a current USG IDAM policy expert who agreed it would be a useful control, but of course this is not definitive validation. 

 

As Hal says, in other environments it may be appropriate to ignore resource attributes that are not used (referenced by any applied policy) for some requests. 

 

Moving on to how the goal of the profile can be implemented with the tools available in the existing Core spec, I have dug in a bit but I'm sure I don't understand all the capabilities anywhere nearly as well as others in the TC and those who have implemented it, so I am hereby asking for suggestions/corrections. 

 

1 .My initial thought is that whatever else is needed, one thing is the ability for the PDP to ask the context handler to retrieve all (access-related) attributes of the requested resource. I don't see a way to retrieve "All" of a resource's attributes. 

 

2. I was thinking the next step would occur after all (other) policies applicable (based on their Target expressions) to the current request have been gathered. (per description in 2.9 Policy Distribution and 2.10 Policy Indexing of the spec.)  At that point, one would like to compare the list of resource attributes to the list of attributes mentioned in this set of policies. 

 

3. Finally, if there were any un-referenced resource attributes, a Deny would be returned to the PEP, optionally with a list of the un-referenced resource attributes. 

 

I see nothing in the spec that looks like it would perform the work in 2. and 3. but as I said I am not at all expert on its capabilities. 

 

Of course perhaps there might be a totally different way to accomplish the goal that I am not seeing. 

 

Suggestions?

 

 

Martin

 

 

 

 

On Thu, Oct 29, 2015 at 2:19 PM, Hal Lockhart <hal.lockhart@oracle.com> wrote:

I think the summary of my reaction to your comments is that many of these things will be true in some environments, but none of them will be true everywhere. XACML aspires to be suitable for all access control environments, or at least to be as widely useful as possible. Therefore, it does not seem to me to be a good idea to require behavior in the core standard which is not useful in many environments.

 

Perhaps there is some way your requirements could be met by a profile which would only apply where it is needed.

 

More comments are inline.

 

Hal

 

 

Martin F Smith, Principal

BFC Consulting, LLC

McLean, Va 22102



 

--

Martin F Smith, Principal

BFC Consulting, LLC

McLean, Va 22102



 

--

Martin F Smith, Principal

BFC Consulting, LLC

McLean, Va 22102




--
Martin F Smith, Principal
BFC Consulting, LLC
McLean, Va 22102
703 506-0159
703 389-3224 mobile


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]