[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Default behavior for unrecognized resource attributes?
Hi Martin, Ø 6. On the question of what I meant by "unknown": I meant not referenced within the policy set being applied by the PDP that feeds the PEP that protects the resource in question at the time of a request. This sounds like the Closed World Assumption [1], which has never worked for me in practice. For instance, it would inhibit adoption of example policies set forth by organizations such as ourselves because they don’t work without *removing* existing attributes from the system. Thanks, Ray [1] https://en.wikipedia.org/wiki/Closed-world_assumption From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Martin Smith Hal -- You raise several issues. 1. Agree that there are several uses/types of metadata bound to resources, including for access-control, search/discovery, basic management (file name, type, size, create date, etc.); if these are all kept together in one store, then yes, the access-related items would have to be identifiable as such. 2. I don't think I agree that "different policy domains" will be applicable to a specific resource. A given resource is subject to the same policies all the time (though the policy sets themselves may contain appropriate provisions for emergency access, for example.) In USG parlance, a records collection (i.e., info resource) is subject to a written (non-digital) policy that specifies "routine uses". Those uses (including who may have access for what purposes) applies all the time. 3. I don't understand your point on secret or top-secret. Yes, that would be implemented by an "or", or a value bag or whatever. 4. Regarding "data you don't need": this seems to be an example of thinking of user attribs (extra attribs are normal --- use what you want; go back ask ask for more if not presented initially) as analogous to resource attribs. They are not. There are no "extra" (access-control related) resource attribs. Each needs to be considered as each represents a policy-relevant characteristic of the resource. If each is not being referenced, that's an error of some sort and needs to be fixed. (Typically going to be lack of coordination between the maintainers of the digital policy sets and the data custodians adding resource tags, but it doesn't matter--still needs fixing, and the only safe thing to do is to DENY until it is found and fixed (at least temporarily...) 5. "one reason older AC models have failed is that they require somebody (security admin) to keep up to date information which he or she neither uses or has authoritative knowledge of" -- agree 100%. But part of the transition to ABAC is understanding how responsibilities change and how the three elements that come together for a decision (policy, user attribs and resource attribs--oh, OK, and "environmental" attribs) are coordinated. I also agree with Eric's earlier comment that the organization has to deal with these governance and process issues, and this is not in-scope of a technology standard like XACML. (Until somebody puts out guidance, however, this lack remains an important inhibitor to use of XACML, so those of us who want to see more ABAC implementation have a stake in standardizing the CONOPS that surrounds the use of the standard. As you know, John T and I tried to initiate a TC with this broader scope but didn't get enough interest to proceed within OASIS.) 6. On the question of what I meant by "unknown": I meant not referenced within the policy set being applied by the PDP that feeds the PEP that protects the resource in question at the time of a request. But perhaps I don't understand where you were going with this question. Best regards, Martin . On Tue, Oct 27, 2015 at 5:51 PM, Hal Lockhart <hal.lockhart@oracle.com> wrote: I am not sure I understand your proposal at all. In XACML there is no way to make any decision except by evaluating policy as defined in the specification. There is no such thing as an unknown tag (I think you mean attribute value not referenced by any policy). In a typical environment there will be many reasons why Resources (and Subjects and Actions and Environment) have attributes which are not used by any policy. They may be irrelevant to access control or they may be used in a different policy domain and not this one. In practice is not possible to keep perfect synchronization between the attributes provided for a decision and the attributes referenced by applicable policy. Maybe the value is referenced when a different user requests access, or at a different time of day, etc. In OpenAz we spent a lot of time on what to do in the opposite case, i.e. when you need an attribute value you don’t have. We came up with two solutions, mappers and the AMF – both imperfect but useful. But we did not even consider your case as a problem. IMO having data you don’t need is not a problem. (Unless it causes latency problems.) Consider you case. First, XACML can’t say “secret or higher”. This usecase has been discussed many times, but the philosophy of XACML is that there is no semantic model (that the policy knows about) so you have to say “secret or top secret” or something of that sort. If you say it must be secret then if it is any unknown value it will evaluate to false. If you say it cannot be secret, then all the “unknown” values will evaluate to true. If you want you can enumerate every possible value or you can only consider the ones that give access. Philosophically XACML intends to make use of information which is already present in the organization somewhere. I realize that in practice organizations are only starting to make use of Resource attributes, but this is a conversion problem, not a steady state one. IMO one reason older AC models have failed is that they require somebody (security admin) to keep up to date information which he or she neither uses or has authoritative knowledge of. I think the right way to do it is as much as possible to use information that the organization is already depending on. Instead of creating artificial things like Roles, we can access the attributes like organization and job title to depend directly on the information which would be used to determine the Users’s Role. This principle is so well established that in Common Law it is recognized as an exception to the hearsay rule. While you generally cannot prove anything with a document alone, the court will consider “Business Records” which are actually depended on by the organization to be valid evidence. Returning to your proposal, are you saying that a value is unknown if a) no reference to the attribute or b) no reference to that particular value? Do you mean c) no reference in the currently applicable policies or d) no reference in any policy even if those policies may never be applicable or e) no reference in any active policy held by any PDP? Hal From: Martin Smith [mailto:bfc.mclean@gmail.com]
Eric-- Certainly agree that policies CAN be written to add this check for unknown data tags, and to DENY in that case. My suggestion is, however, to provide for the case where the policy set fails to do this, but yet there is a tag that is not handled by any policy in the policy set used to protect a resource. This is an error case, but in such a case I suggest that the priority should be given to the decision of the data custodian to mark the data with the unhandled tag, which probably indicates an intent to invoke a policy rule that limits access. And example from a domain with which I'm familiar: Suppose data tags are bound to a document, and the tags are "SECRET", "NOFORN" and "PROPIN" (meaning "proprietary information.") The custodian relies on the access-control system to protect this document with a policy set that enforces requirements that the requester has a SECRET or above clearance, is a US citizen, and is not a contractor. If for whatever reason, the policy set that is active doesn't recognize the tag "PROPIN", for example, then the requirement for the requester not to be a contractor would not be enforced; in this case the data custodian would expect access to be denied. Of course, maybe the custodian is the one who made the error--maybe PROPIN is an obsolete tag. The tagging process is very likely not flawlessly synchronized with the policy update or the user provisioning processes, so this can certainly happen. In this case I see two reasons why a default DENY is appropriate: (1) the security "meta-rule" of default configuration of anything for no access vs all access; and (2) good incentives: getting an erroneous DENY is more likely to provide motivation to the requester to pester someone to get the error fixed than is an erroneous PERMIT. (Sidebar: this discussion illustrates one of several ways in which process for management of user attributes should not be assumed to be directly transferable to management of resource attributes (data tags.)) I am not sure where this suggestion would fit into the TCs guidance. It probably does not requires new XACML syntax. Maybe it's more like how the rules of precedence for application of rules in a policy set are specified or declared. Or maybe it's just something that could be included in non-normative "best practice" guidance (i.e., "It's a good idea to have a rule like the one Eric suggests in your active policy set to avoid accidentally providing access to a protected resource.") Best regards, Martin On Tue, Oct 27, 2015 at 8:21 AM, Erik Rissanen <erik@axiomatics.com> wrote: Martin, On 2015-10-27 12:49, BFC.McLean wrote:
-- -- 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]