Verifying Workflow Processes against Organization Security Policies Carlos Ribeiro
Paulo Guedes
[email protected]
[email protected]
Abstract WPDL
Workflow applications for large complex organizations often need to cross several security domains, each with different management and specific security requirements. The resultant cross-dependency between the workflow specification and the security policy of each domain can be hard to manage without specific tools. This work presents a static analyzer that automatically verifies the consistency between workflow specifications written in WPDL (Workflow Process Definition Language) and organization security policies, written in a security language specially designed to simultaneously express several security policies. The static analyzer takes advantage of the constraint nature of both workflow and security specifications, to use constraint programming techniques. The result is a compact and flexible verification tool that can be adapted to several workflow and security specifications.
1
Introduction
The security infrastructure of complex organizations is often comprised of several security domains, each one with different security needs. Some of these domains have different management and frequently use the security model of the underlying operating system. This scattering of policies over the organization and heterogeneity of models is unfavorable for workflow applications, since they often have to cross several security domains and hence simultaneously deal with several policies. Although several security policies have been proposed in the literature, none satisfies simultaneously all the security needs of all domains in most organizations. These organizations are the ideal environment for multi-policy platforms like the one we have proposed in [1]. This multi-policy platform is based on a security policy language (SPL) which is flexible enough to express several complex policies simultaneously and is simple enough to be implemented by an event monitor. In order to solve conflicts between policies, the platform disposes policies over a hierarchical tree of delegation resulting in a single global complex corpo-
SPL
CCL
CCL
CV Compatibility - yes/no
Figure 1: Structure of the compatibility analyzer rate policy. SPL solves the problem of enforcing simultaneously several complex policies. However, it does not solve the problem of ensuring that workflow specifications comply with the global security policy, neither the problem of ensuring that a policy modification does not prevent the execution of an important workflow process. For instance, suppose that the organizations security policy states that any document that receives information from internal department documents should be submitted to the same security constraints of the original documents, and a specific department states that its internal documents cannot be available outside the organization. Then, any workflow process that accesses an internal document of that department and sends an email to someone outside the organization cannot be allowed. If workflow specification and security policies are not jointly analyzed this situation is detected only when in runtime the workflow process repeatedly fails. These inconsistencies are often very easily solved if detected in an early stage of the design of the workflow specification, but are harder and more expensive to solve if they re detected only in the production stage. This work presents a static analyzer that automatically verifies if a workflow specification complies with a SPL policy, detecting inconsistencies before the workflow specification or the SPL policy is applied. We take advantage of the constraint nature of both security policy and workflow definitions, to express them on a common constraint language (CCL), which can then be checked by a consistency verifier (CV) us-
ing constraint programming techniques [2] (Figure 1). The novelty of this work is that it uses a generic security infrastructure, which is flexible enough to satisfy the requirements of several systems and domains, hence be shareable by most systems across an organization. The contribution of this paper is to show how a security specification written in a generic and flexible security language (SPL) can be checked for inconsistencies with a workflow process definition written in WPDL (Workflow Process Definition language) [3]. The remaining of this paper is organized as follows. The next section presents the most relevant related work. Section 3 briefly introduces SPL. Section 4 describes the consistency verification engine. Finally section 5 summarizes the paper and discusses current status.
2
Related work
In [4], Bertino et al also uses constraints to detect inconsistencies on assignment of roles to workflow tasks, and to plan effective inconsistent free role assignments. Although, the work is able to model several types of restrictions on role assignment, namely several forms of separation of duty, it does not consider any other kind of security or workflow restriction. Atluri and Huang [5] use a different approach to detect inconsistencies. They model security and workflow restrictions as Petri nets, and state that the safety problem in the authorization model is equivalent to the reachability problem in that type of nets. They assume a model where authorization restrictions are the subset of workflow restrictions that specifies users and roles authorizations. Our work differs from previous ones in that it separates the authorization system from the workflow system. This separation along with the flexibility and model-independence of the authorization system used allows for the definition of global security policies, which can be shared among several systems and domains. The definition of global security policies is essential to detect inconsistencies that result from the composition of policies from different domains, as the one described previously.
3
Security policy language (SPL)
SPL is a security language designed to express policies that aim to decide about the acceptability of events. The acceptability of each event depends on the properties of the event (e.g. author, target and action), on the context at that time and on the properties of past and future events. SPL entities are typed entities with an explicit interface by which their properties can be queried. Some of the entities manipulated by SPL are
policy Private( user set OrganizationUsers ) object set InternalDocs: // ?Private: // event.action = "SendEmail" & // event.target IN InternalDocs // :: // event.parameter[1] IN OrganizationUsers // } //
{ Policy data Rule name. Applicability expression. Separation marker. Aceptability expression.
Figure 2: Simple policy defining that objects belonging to InternalDocs can only be sent to users belonging to OrganizationUsers. internal to SPL, like rules and policies, but most are external, like users, files actions, objects and events. The properties of each external entity depend heavily on the platform (operating system, workflow engine) that implements those entities. The language is organized in a hierarchical delegation tree of security policies, in which the master policy is the root delegation starting point. A SPL policy is a structure composed of sets and rules, whose purpose is to express simple concepts like “separation of duty”, “information flow”, or “general access control”. Sets contain the entities used by the policies to decide on event acceptability. A rule is a function of Events that can assume three values: “allow”, “deny” and “notapply”. Its purpose is to decide on the acceptability of the current event. A rule can be simple or composed. A simple rule is a tuple of two logical expressions. The first logical expression decides on the applicability of the rule, and the second decides on the acceptability of the event. A rule can be composed of other rules through a specific three-value algebra with five logic operations: conjunction (’AND); disjunction (’OR); negation (’NOT); existential quantification (EXIST x IN set rule); and universal quantification (FORALL x IN set rule). These operations behave similarly to their binary homonyms if the “notapply” value is not used and the “allow” and “deny” values are used as true and false, respectively. The primary characteristic of this algebra is that the “notapply” value is the neutral element of every operation. For further proprieties and constructions allowed by this algebra, see [1]. Each policy has one special rule called the “query rule” which is identified by a query mark before the name. This rule is usually a composition of other rules in the policy and defines the behavior of the policy after being instantiated. Delegation is achieved when a policy is instantiated and used as a rule in the composition of other rules. Figure 2 shows a simple policy that states that documents internal to the entity defining the policy cannot be sent to someone outside the organization. The policy has two sets and one rule, the query rule. One
of the sets is a parameter to the policy and containsthe users that belong to the organization. The other is internal to the policy and contains the documents internal to the department. The rule uses the special variable “ce” to access the current event properties. The applicability expression of the rule states that the policy is defined only for events whose targets are documents internal to the department and whose action is to send an Email. The acceptability expression states that for those events that satisfy the applicability expression the only events allowed are the ones that sent the Email to a user of the organization. One of SPL key features is its ability to express restrict forms of obligation. The restricted forms of obligation that SPL can express are those in which the obligation is triggered by an event. For instance a rule stating that “if someone has read a document, he must register himself as one of the readers”, contains an obligation of this type. Expressing this kind of obligation does not require any new predicate, because it can be expressed with a rule that allows or denies the execution of the triggered action depending on the existence of a future event. However, implementing rules with dependencies on future events is harder then implementing rules with dependencies on past events. While past events can be registered in a log that can be queried like any other entity, future events are not known until the decision on the acceptability of the event. In [1], we show how the commit/abort transaction concept can be used to implement this type of rules.
4
Workflow/Security consistency verifier
Workflow processes have been expressed in many different models. Most of them use specialized workflow languages with specific flow constructions [3], some are based in colored annotated Petri nets [6], and a few others define processes as sets of constraints [7]. Although most of these models are not equivalent due to properties present in some of them and absent in others, it is often possible to create an equivalent model based on a different paradigm. SPL defines a constraint model with almost all the restriction operations necessary to express a workflow process. However, the SPL constraint model was designed to be implemented by an event monitor and it is not suited to be used by a symbolic constraint solver, or to express task dependencies. Hence, it is necessary to define an intermediate model that implements the restrictions of SPL and workflow systems, and that is suitable to be used by a symbolic solver. The proposed system is composed of two language translators that translate WPDL and SPL to a com-
Constraint
z }| { A ≤ B , B ≥ A ⇔ true | {z } |{z} Head
Guard
| A = B //Simplification rule
| {z } Body
A ≤ B, B ≤ C ⇒ true | A ≤ C // Propagation rule
Figure 3: Example of simplification and propagation rules. mon constraint language, and a consistency verifier engine, which knows how to handle the constraints placed by both languages. The remainder of this section shows how does the consistency verifier engine handles several types of constraints, and how are the WPDL and SPL languages translated into constraints.
4.1
Consistency verifier engine
The consistency verifier engine is a symbolic constraint solver that knows how to handle each type of constraint in order to detect conflicts. It is composed of a set of rules comprising the knowledge on constraint resolution, and an engine that knows how to handle those rules. Rules are expressed in the CHR (Constraint Handling Rules) language [8], for which several engines already exist. 4.1.1 Constraint handling rules. CHR is a highlevel language designed for writing user-defined constraint systems. CHR is essentially a committed-choice language consisting of guarded rules that rewrite constraints into simpler ones until they are solved. CHR rules are of two types: simplification rules and propagation rules. Simplification rules replace user-defined constraints by simpler ones. Propagation rules add new redundant constraints that may be necessary to do further simplifications. A CHR rule is composed of three parts: a head, a guard and a body (Figure 3). Each part is a composition of constraints. There are two kinds of constraints, the user-defined and the built-in constraints. User-defined constraints are relations that must hold between one or more entities, which assume the form of predicates or operations over those entities (e.g. less(1,2) or 1 < 2). Built-in constraints are simple constraints that can be directly solved by the underlying solver (e.g. A = B). A simplification rule works by replacing the constraints in the head by the constraints in the body, provided the constraints in the guard are true. A propagation rule adds the constraints in the body but keeps the constraints in the head (Figure 3). 4.1.2 Consistency verifier rules.Consistency verifier rules are divided in four major groups. Each group of rules knows how to solve constraints of a different type. One group solves constraints that enforce order
X X X X X X
≤ ≤ ≤ < <
C at T A in G at T, A notin G at T ⇒ f ail A in G, A notin G at T ⇒ f ail C = A ∪ B, X in C at T ⇒ X in A at T, X in B at T
Figure 8: Some rules that handle timed constraints. tification variable, then the existential quantification “∃x ∈ A : rule(x)” is equivalent to “c ∈ A and rule(c)” where “c” is a Skolen constant. Most constrained entities (user properties, user group elements) vary with time. Thus, a constraint that is valid now may not be valid in the future or in the past. It is therefore necessary to add a time attribute in order to freeze the constraints value. The time attribute may be associated with each entity or with each constraint. The former is closer to reality, considering that constraints are constants and entities vary with time. However, this would make constraints unnecessarily complex due to the higher number of time attributes by constraint. Moreover associating the time attribute with each constraint is in conformity with the constraint programming principles, in which constraints are the basic units of manipulation (figure 8).
4.2
WPDL/SPL to CCL translation
In order to be solved, the workflow specification and the SPL security policy must be translated into constraints that can be handled by the consistency engine. Since SPL is a constraint language, translating it into CCL is a direct process. Each policy is seen as a complex constraint composed of other simpler constraints. Thus, each policy definition is translated into one simplification rule, with one user-defined constraint in the head, several constraints in the body and no guard. The constraint in the head is a predicate with the name of the policy, applied to a tuple of all the explicit parameters of the policy and four implicit ones: current event, global and local variables, and a SPL rule representing the policy. The body of the rule is composed of one constraint for each SPL group or rule definition inside the policy. These constraints can then be further simplified by the rule of the consistency engine. Figure 9 shows the translation of the SPL policy presented in figure 2. The policy is translated into a simplification rule with two constraints in the body. One of the constraints states that the set “InternalDocs” is defined
privatePolicy(OrganizationUsers, event(Actor,Action, Target,Parameters, Time), Gobals, Locals, R) ⇔ Locals = locals(privatePolicy vars(InternalDocs)), R=rule(Action = ‘‘SendMail’’ & Target IN InternalDocs, Parameters[1] IN OrganizationUsers).
Figure 9: The figure shows the translation of the “privatePolicy” security policy into CCL. inside the predicate “locals”, in the “privatPolicy” section. The other states that the SPL rule to apply is defined by the predicate “rule” applied to the tuple composed by the applicability expression and the acceptability expression. Translating a WPDL process definition into CCL is also a direct process. WPDL is composed of several toplevel entities. The essential entities to translate are “activities” and “transitions”. Activity definitions are translated into simplification rules with a user-defined constraint in the head, and several constraints in the body. The constraint in the head is a user-defined predicate with the name of the activity applied to a tuple of terms. The constraints in the body are divided in three groups. The first group contains constraints on activity properties (e.g. participant assignment = john, participant assignment ∈ Role). The second group is a conjunction or a disjunction (depending on the “join” property of the activity) of transition constraints. The third group is composed by a constraint expressing the master security policy and a close or open constraint applied to the master policy. Transitions are also translated into simplification rules with a single predicate constraint in the head, named after the transition. The body of these rules is composed of three constrains. The first one expresses the condition that fires the transition. The second one expresses the dependency on the originator activity. The third one expresses the eventual dependencies on other transitions, e.g. the transition is on the “xor” priority list of the “split” attribute of the originator activity.
5
Conclusions
We have presented a tool that is able to statically verify the consistency between workflow and security specifications, reducing the costs of late detection in the workflow design process. In order to maximize the number of inconsistencies the tool is able to detect, the security specification is expressed in a flexible security language, which is capable of globally express the policy of complex organizations. To handle the complexity of the restrictions of this language the tool translates both security and workflow specifications into a common constraint language that can be checked using CHRs. Currently the consistency verifier engine is composed
of 229 CHRs running over the CHR solver provide with SICstus Prolog [10]. Some experiences were performed using compositions of SPL policies and workflow specifications to validate the process. Namely, the situation described in the introduction was tested using the “PrivatePolicy” described in figure 2, an information flow policy and a workflow process with three activities: read internal document; write document; and send document previously written. We also tested some other situations using separation of duty policies, workflow specifications with loops, and policies with cardinality constraints over role membership.
References [1] Carlos Ribeiro and Paulo Guedes, “Spl: An access control language for security policies with complex constraints,” Tech. Rep. RT/0001/99, INESC, Jan. 1999. [2] Kim Marriot and Peter J. Stuckey, Programming with Constraints: An introduction, MIT press, 1998. [3] WFMC, “Interface 1: Process Definition Interchange Process Model (WFMC-TC-1016-P),” Tech. Rep., Workflow Management Coalition, Brussels, Nov. 1998. [4] Elisa Bertino, Elena Ferrari, and Vijayalakshmi Alturi, “A flexible model for the specification and enforcement of role-based authorizations in workfiow management systems,” in Proceedings of the 2nd ACM Workshop on RoleBased Access Control (RBAC-97), New York, Nov. 6–7 1997, pp. 1–12, ACM Press. [5] V. Atluri and W.-K. Huang, “An authorization model for workflows,” in Proceedings of the Fourth ESORICS, E. Bertino, H. Kurth, G. Martella, and E. Montolivo, Eds., Rome, Italy, Sept. 1996, LNCS, pp. 44–64, SV. [6] C.A. Ellis and G.J. Nutt, “Modelling and Enactment of Workflow Systems,” in Application and Theory of Petri Nets 1993, M. Ajmone Marsan, Ed. 1993, vol. 691 of Lecture Notes in Computer Science, pp. 1–16, Springer-Verlag, Berlin. [7] Austin Tate, “Representing plans as a set of constraints - the model,” in Proceedings of the 3rd International Conference on Artificial Intelligence Planning Systems (AIPS-96), B. Drabble, Ed. 1996, pp. 221–228, AAAI Press. [8] Th. Fr¨ uhwirth, “Theory and practice of constraint handling rules, special issue on constraint logic programming,” Journal of Logic Programming, pp. 95–138, Oct. 1998. [9] Christopher J. Hogger, Essential of Logic Programming, Oxford University Press, 1990. [10] Johan Andersson, Stefan Andersson, Kent Boortz, Mats Carlsson, Hans Nilsson, Thomas Sj¨ oland, and Johan Widn, “SICStus prolog user’s manual,” Technical Report T93-01, Swedish Institute of Computer Science, Oct. 1995.
