Validating access control policies with Alloy

We present two projects that are being developed in our research group. The first is on inconsistency detection in XACML policies. The second one develops a novel access control paradigm, called process-based access control, and has inconsistency detection as part of its goal. The model analyzer Alloy is being used in both projects. 1. Background and motivation The old way of controlling computing systems was by hard-coding all control in monolithic programs. Then the concept of application program came up pre-packaged with a number of features. Everybody now knows how to activate or deactivate features by checkbox selection. In telephony, the Intelligent Network architecture allows users to choose and possibly build their telephony features out of prefabricated components. However, when the IN concept was introduced, some sort of critical threshold was crossed, because the phenomenon of feature interaction was discovered. We had a highly distributed system that was constructed from independent components, each capable of complex independent behavior. The features composed in this way can produce behavior that can contradict the intentions of coexisting features, or basic system requirements. In many cases, more flexibility in customization is desired than what can be obtained by checkbox selection, however the full power of a programming language is not required. We are then in the area of policy languages. Firewalls and routers can be programmed by using policy languages. Internet telephony can be programmed by languages such as CPL, the Call Processing Language [7]. The policy languages that apply in these areas are specialized languages, that specify what the user expects in various cases. The power of these languages is usually rather constrained, both in order to simplify programming and in order to prevent certain behaviors. However interactions are still possible, in fact they acquire a whole new dimension [8] [1]. Many types of interactions can be explained in terms of inconsistencies in sets of rules. Typical examples are the following: one rule leads to blocking a call, while another that is simultaneously enabled leads to forwarding it; one rule allows a certain user to access a certain document, while another rule forbids such access; one rule in the firewall lets in a certain packet, while another rule blocks it. Therefore, many feature interactions can be detected by looking for inconsistencies in sets of rules. In some systems, many policy interactions are taken care of by priority mechanisms that are built in the policy execution system. For example, in telephony features, the first rule that matches a condition may be applied and other following rules that match the same condition are then ignored. However, this does not solve the problem for two reasons. The first reason is the fact that the coexistence of two conflicting rules in a system could be an error and therefore should be brought to the attention of the user. The second reason is the fact that if the inconsistencies are due to a combination of rules that reside in different locations, then it may be very difficult to ensure that only one of these rules is applied, and even if this is possible, it may be contrary to the intention of one of the parties involved. In this paper, we propose an approach to policy interaction detection that is based on the use of a logical model checker. The specific tool we propose is Alloy [4]. 2. Access control policies Access control policies are policies that determine who, and under what conditions, can access certain systems resources, especially data resources. Firewalls are network level mechanisms for enforcing access control, and some of the concepts discussed below apply to the analysis of firewalls. However we are mainly interested in higher level languages, where access control rules can be specified in terms that are directly related to the roles and purposes of users. RBAC (role-based access control) [2] [3] is a well-known access control paradigm, and the paradigms we will discuss below intend to be more general than RBAC, in the sense that the latter can be expressed in them. The practical problem here is that access control policies are often complex, difficult to understand, and developed incrementally. They will be administered by lawyers, clerks, and other people who won’t be necessarily computer-literate, so they must be made manageable for these people. Hence, methods and tools are needed to identify and report semantic errors. We are pursuing two research areas, where the second one is more ambitious and longerterm 1) Analysis of access control policies expressed in the OASIS standard XACML language 2) Study of new access control methods, namely ‘process-based’ ones. 2.1 Inconsistencies of policies expressed in the XACML language XACML, the eXtensible Access Control Markup Language, intends to be a language for the expression of a wide range of access control policies. It is defined as a set of XML schemas . [11] A simple example of rules expressible in XACML is the following (where X is the URL of a XML file): • Rule1: A person may read any medical record in the X namespace for which he or she is the designated patient • Rule2: A person may read any medical record in the X namespace for which he or she is the designated parent or guardian, and for which the patient is under 16 years of age • Rule3: An Administrator shall not be permitted to read or write medical elements of a patient record in the X namespace. It is easy to see that when the subject is both administrator and patient, both permit and deny responses are allowed by the rules for X. It should be noted that XACML has methods to take care of such conflicts. These have the self-explaining names of “denyoverrides”, “permit-overrides”, “first applicable”, and “only-one applicable”. However, as mentioned, conflicts should be brought to the attention of the user because the user may be unaware of them, leading to unintended access decisions. Although a very simple example had to be selected for this brief paper, clearly the use of automatic methods will enable the discovery of much more involved inconsistencies, as are possible in sets of policies containing hundreds of rules. We have defined the semantics of XACML in terms of the Alloy notation, and shown the feasibility of the approach. We are completing the work by implementing an automatic translator from XACML to the Alloy notation. As a by-product of this research, we have also developed a translator from XACML notation into a more user-friendly natural language notation that can be used in a user interface for generating XACML scripts. 2.2 Process-based access control and inconsistency detection This second project goes well beyond validation and intends to first develop a new access control paradigm. The latter is based on models of enterprise processes. Using high level policies, enterprise control systems will soon be self managing [6] [10]. High level policies will be decoupled from enterprise structural elements, such as roles, and applied to processes. While policies deliver the purpose required by a designer, the governance model, thus created, is prone to ambiguity, complexity, and interactions. In this project we will show how to help enforce policies, reduce complexity, and detect interactions in enterprise privacy management systems. In the past, several methods have been used to capture enterprise requirements. ebXML, XACML [11], and EPAL [9] are good examples of policy languages that implement enterprise policies. RBAC helped reduce complexity by decoupling users from permissions and grouping them into roles [2] [3]. RBAC has succeeded in representing hierarchical organizations that are divided by function (example: finance, accounting, manufacturing); however, it is less successful at capturing organizations that are based on service, product, or activity (ex: loan application), which may include several people from different departments. All these techniques are restricted to functional enterprises and not process (Activity) based organizations. None of these techniques or languages addresses the issue of policy interactions. We propose the use of process-based access-control methods in the specification of privacy systems. A process has a target usually, and is broken into discrete steps. Each of the steps can be assigned to a role with an access right. We show that a process-based model, including roles, actions, and permissions, can correctly represent policy intent and hence enable enforceability of privacy policies. We show how such a model can be described in UML and then we show how policy interactions in the model can be detected by using an analyzer such as Alloy. Our philosophy: By grouping business activities in processes, we can specify how roles and resources relate in a business context. After compiling the set of processes, we attach one or more policies to each process. A policy specifies access rights of roles participating in processes. After analysis, a semi-formal UML model is created. The model is translated into Alloy and interactions and inconsistencies are detected. In order to address requirements of the evolving enterprise, one that is focused on business activities rather than structure, the project is broken down into three stages: Our first goal is to find a meta-model that captures enterprise specifications. In stage two, we create a model following the methodology, this should reduce complexity. In stage three, we translate the model into a formal language to verify it, and to identify conflicts that can then be removed. This technique has already been demonstrated on some small examples, and we are now exploring its applicability in a more general setting. Issues to be addressed are delegation and separation of concerns. Delegation occurs when a user assigns his role to another person, separation of concerns occurs when