[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Default behavior for unrecognized resource attributes?
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 From: Martin Smith [mailto:bfc.mclean@gmail.com] 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. It seems unreasonable to me to require this whenever XACML is used. Whether the attributes are in a single store or not, I don’t think organizations in general will be able to decide all the ways an attribute might be used in advance. For example, it classification level is not available, the location of the file might be used as a proxy for classification. 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. I can think of many counter examples. For example, consider an ERP database containing data used by many different organizations. Or consider the common practice of offering access to data via applications and also via an ad hoc query interface. Another example comes from the interops we have done, where Resource attributes are stored in the file which is the resource. As the files move around the organization the attributes will be used against local policy to determine what access should be allowed. Certainly the organization could restructure so these were not distinct policy domains, but we don’t want to require people to reorganize before they can even begin to use XACML. 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. Sorry, I thought from you comment there was some confusion about XACML capabilities, but apparently there was not. This point is not essential to my arguments. 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...) Here we simply disagree. I see this as something that will be true in some environments but not in others. 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.) I see governance as primarily insuring that the attribute values match the real world, not ensuring that they are consistent with some global policy model. Experience has shown that it is impossible to maintain total consistency between all data in a large scale distributed environment. Ray also referred to this limitation in his comment about “closed world assumption”. 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. Ok, so you accept a situation where every possible attribute value (of the ones you are talking about) appears at least once in some policy. But in this case it is possible that the policy containing value “x” will never be applicable to any situation that can actually occur. An what’s worse, in the general case it is not even possible to determine whether that is true or not. To do so for sure would require first obtaining all possible attribute values that actually are associated with Resources, Subjects, etc. and then evaluating the entire cross product of possible combinations. There is no way to shortcut this process. Even worse, the restriction you suggest would encourage people to write “dummy policies” which would reference all attribute values in some policies which will never be applicable, just to ensure they had a “valid” set of policies. 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]