Formal Analysis of Workflow Systems with Security Considerations

Transcription

1 Formal Analysis of Workflow Systems with Security Considerations Weiqiang Kong Japan Advanced Institute of Science & Technology Kazuhiro Ogata NEC Software Hokuriku, Ltd. Kokichi Futatsugi Japan Advanced Institute of Science & Technology Abstract Security considerations, such as role-based access control (RBAC) mechanism and separation of duty (SoD) constraints, are important and integral to workflow systems. We propose the use of an equation-based method the OTS/CafeOBJ method to specify workflow systems with such security considerations, and verify some desired safety and liveness properties of workflow systems. Specifically, a workflow system, together with its security considerations, is modeled as an OTS, a kind of transition system. Then the OTS is written in CafeOBJ, an algebraic specification language. We express safety and liveness properties in CafeOBJ and verify that the OTS satisfies these properties by writing proof scores in CafeOBJ. We use a case study formal analysis of a workflow system that deals with travel expense reimbursement, to demonstrate our method of modeling, specifying and verifying. 1. Introduction As an integral part of workflow systems, workflow security has received extensive attentions, within which rolebased access control (RBAC) mechanism and separation of duty (SoD) constraints are important topics. RBAC is a natural mechanism to lighten the complexity of security administration, with the basic notion that permissions are associated with roles and users are assigned to appropriate roles. However, to satisfy the complex security policies of workflow systems, SoD constraints are also necessary, which aim at reducing the risk of fraud by not allowing any individual to have sufficient authority within the system to perpetrate a fraud on his own [3]. Some studies have been reported on building secure workflow models with security considerations of RBAC This research is conducted as a program for the Fostering Talent in Emergent Research Fields in Special Coordination Funds for Promoting Science and Technology by Ministry of Education, Culture, Sports, Science and Technology, Japan. mechanism and SoD constraints [2, 3, 6, 7]. The work by Atluri et al. [2] proposes a workflow authorization model (WAM), which specifies authorizations in a way that subjects gain access to required objects only during the execution of task, thus synchronizing the authorization flow with the workflow process. However, WAM has to be firstly represented by Petri nets and then use Petri nets theory to conduct safety analysis (i.e. RBAC mechanism and SoD constraints are not violated during workflow execution); besides, WAM does not consider task dependencies of a workflow. Knorr et al. [7] used Petri nets to model SoD constraints in workflow and then used a logical programming language to generate all possible execution chains of workflow. The limitation of this method is the computational overheads, especially for large business processes. Hung et al. [6] have developed an authorization model of workflows by multi-layered state machines from aspects of users, events and data. But this method cannot be used to analyze whether workflow processes can be successfully finished under security constraints, i.e., there is no deadlock in workflow due to too restrict security policies. In a word, most existing approaches to the specification of RBAC mechanism, and especially of SoD constraints are complicated and not suitable for the verification of desired security properties that workflow systems should possess; besides, the workflow process and authorization flow are separated during specification and verification in most approaches. In our method, a workflow system, together with its security considerations, is modeled as an OTS (Observational Transition System) [11], a kind of transition system. Activities, such as grant/revoke privilege to/from roles, are triggered by events that are generated by transition rules; and SoD constraints are specified in effective conditions that are attached to each transition rule. The OTS is then written in CafeOBJ [1, 5], an algebraic specification language. We express safety and liveness properties of the workflow system in CafeOBJ, and verify that the OTS satisfies these properties by writing proof scores in CafeOBJ and executing the proof scores with CafeOBJ rewriting engine. The verification of safety properties ensures that the RBAC mech-

2 anism and SoD constraints are correctly realized by the given workflow specification; and the verification of liveness properties ensures that the existence of security considerations will not prevent completion of the execution of workflow. In this paper, we use a case study formal analysis of a workflow system that deals with travel expense reimbursement, to demonstrate our method of modeling, specifying and verifying workflow systems with RBAC mechanism and SoD constraints. The rest of this paper is organized as follows. Section 2 outlines the OTS/CafeOBJ method. Section 3 describes the sample workflow system. Section 4 describes formal modeling of the workflow system. Section 5 describes how to express safety and liveness properties and mentions their verification; Section 6 concludes this paper. 2. The OTS/CafeOBJ Method OTS (Observational Transition System) is a definition of transition systems that is suitably written in equations. We assume that there exists a universal state space called Υ. We also assume that data types used, including the equivalence relation (denoted by =) for each data type, have been defined in advance. An OTS S consists of O, I, T where: O : A set of observers. Each o O is a function o : Υ D, where D is a data type and may differ from observer to observer. Given an OTS S and two states υ 1, υ 2 Υ, the equivalence (denoted by υ 1 = S υ 2 ) between them wrt S is defined as o O, o(υ 1 ) = o(υ 2 ). I : The set of initial states such that I Υ. T : A set of conditional transition rules. Each τ T is a function τ : Υ Υ, provided that τ(υ 1 ) = S τ(υ 2 ) for each [υ] Υ/ = S and each υ 1, υ 2 [υ]. τ(υ) is called the successor state of υ Υ wrt τ. The condition c τ of τ is called the effective condition. For each υ Υ such that c τ (υ), υ = S τ(υ). Observers and transition rules may be parameterized. Generally, observers and transition rules are denoted by o i1,...,i m and τ j1,...,j n, respectively, provided that m, n 0 and there exist data types D k such that k D k (k = i 1,..., i m, j 1,..., j n ). An OTS is described in CafeOBJ which can be used to specify abstract machines as well as abstract data types. A visible sort denotes an abstract data type, and a hidden sort the state space of an abstract machine. There are two kinds of operators in hidden sorts: action and observation operators. An action operator can change a state of an abstract machine; only observation operators can be used to observe the inside of an abstract machine. Declarations of observation and action operators start with bop or bops, and those of other operators with op or ops. Declarations of equations start with eq, and those of conditional equations with ceq. The CafeOBJ system rewrites a given term by regarding equations as left-to-right rewrite rules. The universal state space Υ is denoted by a hidden sort, say H. An observer o i1,...,i m O is denoted by a CafeOBJ observation operator. We assume that there exist visible sorts V k and V denoting D k and D, where k = i 1,..., i m. The CafeOBJ observation operator is declared as bop o : H V i1... V im -> V. Any state in I (namely any initial state) is denoted by a constant, say init, which is declared as op init : -> H. Suppose that the initial value of o i1,...,i m is f(i 1,..., i m ). This is expressed by the following equation: eq o(init, X i1,..., X im ) = f(x i1,..., X im ). X k is a CafeOBJ variable of V k, where k = i 1,..., i m, and f(x i1,..., X im ) is a CafeOBJ term denoting f(i 1,..., i m ). A transition τ j1,...,j n T is denoted by a CafeOBJ action operator. We assume that there exists a visible sort V k denoting D k, where k = j 1,..., j n. The CafeOBJ action operator is declared as bop a : H V j1... V jn -> H. τ j1,...,j n may change the value returned by o i1,...,i m if it is applied in a state υ such that c τj1 (υ), which can be,...,jn written generally as follows: ceq o(a(s, X j1,..., X jn ), X i1,..., X im ) = e-a(s, X j1,..., X jn, X i1,..., X im ) if c-a(s, X j1,..., X jn ). S is a CafeOBJ variable for H and X k is a CafeOBJ variable of V k, where k = j 1,..., j n. a(s, X j1,..., X jn ) denotes the successor state of S wrt τ j1,...,j n. e-a(s, X j1,..., X jn, X i1,..., X im ) denotes the value returned by o i1,...,i m in the successor state. c-a(s, X j1,..., X jn ) denotes the effective condition c. τj1,...,jn τ j1,...,j n changes nothing if it is applied in a state υ such that c τj1 (υ), which can be written generally as,...,jn follows: ceq a(s, X j1,..., X jn ) = S if not c-a(s, X j1,..., X jn ). If the value returned by o i1,...,i m is not affected by applying τ j1,...,j n in any state (regardless of the truth value of c τj1 ), the following equation may be declared:,...,jn eq o(a(s, X j1,..., X jn ), X i1,..., X im ) = o(s, X i1,..., X im ).

3 start apply applied evaluate1 evaluate2 rejected1 rejected2 approved1 approved2 notify m-trans Figure 1. A simplified state-transition diagram of the workflow end 3. A Sample Workflow System The workflow system (taken from [7]) we have formally analyzed deals with travel expense reimbursements. This workflow system has been widely used to demonstrate RBAC mechanism and SoD constraints. Figure 1 shows the related state-transition diagram of this workflow. The workflow consists of five tasks represented as rectangles; seven ovals represent the states of the workflow system before and after execution of each task. Initially, the state of the workflow system is start. In the first task apply, an employee applies for the reimbursement of his/her travel expenses by filling out an application form. Two managers have to evaluate this application (tasks evaluate1 and evaluate2 ). Then based on the results of the managers, a secretary will transfer refund to the employee s bank account (task mtrans ) if both managers approved this application; or the secretary will notify the employee that his/her application has been rejected (task notify ) if either of the managers rejected it. Now we illustrate RBAC mechanism, static SoD (SSoD) and dynamic SoD (DSoD) constraints involved in this sample workflow. There are three roles in this workflow system: manager, secretary and employee. All users belong to role employee ; each user that belongs to role manager or secretary also belongs to role employee, but a user who belongs to role manager, cannot belong to role secretary, and vice versa (i.e., the roles manager and secretary have no shared users). SSoD constraints demand that different tasks are executed by different roles [3]. In other words, task apply can be executed by users belonging to role employee (i.e., all users), tasks evaluate1 and evaluate2 can only be executed by users belonging to role manager, and tasks notify and m-trans can only be executed by users belonging to role secretary. DSoD constraints demand that a user belonging to multiple roles (such as, a user belonging to roles employee and manager ) can dynamically activate only one of these roles ( employee or manager ) in the run-time. This sample Function Table 1. Functions used in the model assignedto(s) assumedby(r) auth(r, T, F) exe(t, S, F) Description returns roles that subject S belongs to; returns subjects that role R contains; denotes an authorization (also called authorization record), which means, for an application form F, role R is granted privilege to execute task T; denotes an execution (also called execution record), which means, for an application form F, task T is executed by subject S. workflow focuses on DSoD 1 constraints, which include: - A manager should not be allowed to evaluate his/her own travel claim. - A secretary should not be allowed to transfer the refund of his/her own travel expenses. - A manager should not be allowed to perform both evaluate tasks in a same workflow instance Modeling the Sample Workflow System We model the sample workflow system as an OTS. In this modeling, the workflow process consists of three subprocesses: mainpath that starts from the initial state of the workflow; path1 that starts from the task evaluate1 ; and path2 that starts from task evaluate2 ; and all these three sub-processes stop at the final state end of the workflow. The reason we regard the workflow process as three subprocesses is that: the concurrent execution of tasks evaluate1 and evaluate2 makes the workflow process have two different states at one time (such as rejected1 and approved2 by two different managers). According to the 1 In the rest of this paper, we will use SoD instead of DSoD if not otherwise stated. 2 In this paper, different workflow instances are represented by different application forms to be dealt with by this workflow system.

4 Table 2. Equations defining condition of transition rule evaluate1" -- condition of transition rule evaluate1 op c-evaluate1 : Sys Subject Subject Obj Quality -> Bool -- Sys, Subject, Obj, Quality are sorts of: -- state space of OTS, subject, application form, and application form s quality respectively. eq c-evaluate1(s,sub1,sub2,f,q) = (mainpath(s,f) = applied and path1(s,f) = p1start and pripath1(s,f) = auth(manager,evaluate1,f) and (SUB1 /in assumedby(manager)) and (if (exe(apply,sub2,f) /in eh(s,f)) then not(sub1 = SUB2) else true fi) and (if (exe(evaluate2,sub2,f) /in eh(s,f) and (SUB2 /in assumedby(manager))) then not(sub1 = SUB2) else true fi)). three sub-processes, we define six observers in the OTS: mainpath, path1, path2, primainpath, pripath1 and pripath2. Among them, the first three observers observe current states of the three sub-processes; and the last three observers observe current authorizations defined on the three sub-processes with the purpose to check: currently, privilege to execute some task has been granted to which role. And such a privilege is denoted by an authorization (also called authorization record shown in Table 1). Additionally, two special observers are defined to satisfy SoD constraints: ah and eh, which are used to observe the elements of authorization history and execution history respectively. For each workflow instance, there exist one authorization history of actual authorizations granted to roles and one execution history of actual executions of tasks by subjects. Authorization/Execution history is denoted by a queue, whose elements are authorization/execution records. During the execution of workflow, all authorizations that have been granted to roles (i.e. authorization records) are added to the the queue of authorization history, and all executions of tasks by subjects (i.e. execution records) are added to the queue of execution history. Besides the observers in OTS, some functions used in our model are presented in Table 1. There are five transition rules in the OTS according to five tasks in the sample workflow. In the following, we will describe the effective conditions of these transition rules, and how these transition rules change the state 3 of the OTS. We present three sets of equations of the specification: one for any initial state of the OTS, and the other two for transition rule evaluate1. The equations defining any initial state (represented by init in the codes) are as follows: eq mainpath(init,f) = start. eq path1(init,f) = p1start. eq path2(init,f) = p2start. eq primainpath(init,f) = auth(employee,apply,f). 3 Here state of the OTS includes: states of the three sub-processes, states of authorizations defined on the three sub-processes, and states of authorization and execution histories (i.e. elements in authorization and execution histories). eq pripath1(init,f) = null. eq pripath2(init,f) = null. eq eh(init,f) = empty. eq ah(init,f) = auth(employee,apply,f). Constants start, p1start and p2start represent the initial states of the three sub-processes respectively. Variable F represents an application form, which is used to distinguish different workflow instances executed concurrently. Initially, role employee is granted the privilege to execute task apply on application form F and this authorization (record) is put into the queue of authorization history (denoted by the fourth and last equations respectively); and no authorizations exist on sub-processes path1 and path2 (denoted by the fifth and sixth equations); and no execution record exists in the execution history (denoted by the seventh equation). The equations defining how a state (say, S) of the OTS changes if transition rule evaluate1 is executed are shown in Table 2 and Table 3. 4 A comment starts with -- and terminates at the end of the line. The commas before ah(s,f) and eh(s,f) are the data constructors of queues of authorization history and execution history. For example, exe(evaluate1, SUB1, F), eh(s, F) denotes the queue of execution history obtained by adding the execution record exe(evaluate1, SUB1, F) to the queue eh(s, F). Operator _/in_ is the membership predicate of queues. Variable Q is used to represent the quality of the application form, and it has two possible values: good and bad. The effective condition of transition rule evaluate1 is denoted as c-evaluate1 (shown in Table 2), which demands that: the state of mainpath is applied and path1 is in its initial state p1start ; and role manager has been granted the privilege to execute task evaluate1 on the current application form F, and there exists a subject (say, SUB1) that belongs to role manager. In addition, due to the SoD constraints, c-evaluate1 also demands that: first, the subject (SUB1) who is to be assigned to execute task evaluate1 4 Due to space limitation, only transition rule evaluate1 is demonstrated in this paper, which is the most representative one among all the five transition rules.

5 Table 3. Equations defining state changes caused by transition rule evaluate1" -- change the states of three sub-processes of workflow -- states of mainpath and path2 are not changed by evaluate1, so omitted here. ceq path1(evaluate1(s,sub1,sub2,f,q),f1) = (if F1 = F then approved1 else path1(s,f1) fi) if c-evaluate1(s,sub1,sub2,f,q) and Q = good. ceq path1(evaluate1(s,sub1,sub2,f,q),f1) = (if F1 = F then rejected1 else path1(s,f1) fi) if c-evaluate1(s,sub1,sub2,f,q) and Q = bad. -- change authorizations defined on sub-processes -- authorizations defined on mainpath and path2 are not changed by evaluate1, so omitted here. ceq pripath1(evaluate1(s,sub1,sub2,f,q),f1) = (if F1 = F then auth(secretary,notify,f) else pripath1(s,f1) fi) if c-evaluate1(s,sub1,sub2,f,q) and Q = bad. ceq pripath1(evaluate1(s,sub1,sub2,f,q),f1) = (if F1 = F then auth(secretary,m-trans,f) else pripath1(s,f1) fi) if c-evaluate1(s,sub1,sub2,f,q) and Q = good. -- change execution and authorization histories ceq eh(evaluate1(s,sub1,sub2,f,q),f1) = (if F1 = F then exe(evaluate1,sub1,f),eh(s,f) else eh (S,F1) fi) if c-evaluate1(s,sub1,sub2,f,q). ceq ah(evaluate1(s,sub1,sub2,f,q),f1) = (if F1 = F then auth(secretary,m-trans,f),ah(s,f) else ah(s,f1) fi) if c-evaluate1(s,sub1,sub2,f,q) and Q = good. ceq ah(evaluate1(s,sub1,sub2,f,q),f1) = (if F1 = F then auth(secretary,notify,f),ah(s,f) else ah(s,f1) fi) if c-evaluate1(s,sub1,sub2,f,q) and Q = bad. ceq evaluate1(s,sub1,sub2,f,q) = S if not c-evaluate1(s,sub1,sub2,f,q). should not be the same subject who has executed task apply (this is done by checking whether there exists such execution record in the execution history of current application form); and second, if task evaluate2 has been executed by another manager (say, SUB2), then the subject (SUB1) who is to be assigned to execute task evaluate1 should not be the same subject who has executed task evaluate2. If the effective condition c-evaluate1 is satisfied, then the transition rule evaluate1 will change the state of the OTS (shown in Table 3), which includes: change the state of sub-process path1 to approved1 if Q = good or to rejected1 if Q = bad ; and grant role secretary the privilege to execute task m-trans if Q = good or grant role secretary the privilege to execute task notify if Q = bad ; and also, add execution record exe(evaluate1, SUB1, F) to the queue of execution history, and add authorization record auth(secretary, m-trans, F) or auth(secretary, notify, F) to the queue of authorization history according to the two possible values of Q. Here note that F1 = F in each equation is used to check whether the application form to be dealt with is the correct application form (the correct one is represented by variable F ). Otherwise, if c-evaluate1 is not satisfied, this transition rule will not change the state of the OTS, which is represented by the last line in Table 3. Other transition rules apply, evaluate2, notify and m-trans have been defined with equations in a similar way. 5. Verification of Desired Properties In this section, we describe the safety and liveness properties, which we have verified that the sample workflow system has. The informal descriptions of the safety and liveness properties are as follows (1-4 are safety properties and 5 is a liveness property): 1. A subject can execute a task if and only if a role has been granted privilege to execute this task and the subject belongs to this role. 2. A manager cannot evaluate his/her own application forms. 3. A secretary should not be allowed to transfer the refund of his/her own travel expenses. 4. A manager cannot perform both evaluate tasks in a same workflow instance. 5. The workflow can run successfully from the initial state to the final state with security considerations. For any reachable state s, any subject sub, sub1, sub2 and any application form form, Table 4 shows formal definitions of the above properties accordingly. 5 We have formally verified that these safety properties (INV1 to INV4) and liveness property (LIV) hold for the 5 In Table 4, INV1 only deals with the case task apply of property 1, while the other four cases, according to the remaining four tasks of the workflow, are defined in a similar way. And c-apply(...) is the effective condition of transition rule apply.

6 Table 4. Formal definitions of safety and liveness properties INV1: c-apply(s, sub, form) and sub /in assumedby(employee) implies auth(employee, apply, form) /in ah(s, form) INV2: ((exe(evaluate1, sub, form) /in eh(s, form) or exe(evaluate2, sub, form) /in eh(s, form)) and sub /in assumedby(manager)) implies not(exe(apply, sub, form) /in eh(s, form)) INV3: (exe(m-trans, sub, form) /in eh(s, form) and sub /in assumebdby(secretary)) implies not(exe(apply, sub, form) /in eh(s, form)) INV4: (exe(evaluate1, sub1, form) /in eh(s, form) and exe(evaluate2, sub2, form) /in eh(s, form)) implies not(sub1 = sub2) LIV: (mainpath(s, form) = start and path1(s, form) = p1start and path2(s, form) = p2start and primainpath(s, form) = auth(employee, apply, form) and pripath1(s, form) = null and pripath2(s, form) = null) leads-to mainpath(s, form) = end workflow system. Precisely, safety properties in this paper are invariants, and proofs of invariants often need induction, especially induction on the number of applied transition rules. The liveness property is described as a leads-to property, and proofs of leads-to properties consist of proofs of several ensure properties. An ensure property (p ensures q) is similar to a leads-to property (p leads-to q). Both p ensures q and p leads-to q basically mean that: if a system reaches a state where p holds, then the system will eventually reach a state where q holds. But in p ensures q, p keeps holding until q becomes true, while p does not necessarily in p leads-to q. The verification of safety and liveness properties have been done by writing proof scores showing that the workflow system satisfies these properties in CafeOBJ and executing the proof scores with CafeOBJ rewriting engine. Additionally, the liveness property is verified under the assumptions that: there exist at least three managers and two secretaries. In this paper, we do not describe details on how to verify the properties due to space limitation. (see [8, 11] for more details.) 6. Conclusion In this paper we have described the modeling of a workflow system together with some security considerations and verified the safety and liveness properties that should be satisfied by the workflow system. Compared with our previous work [9, 10], the case study in this paper can be considered as another step toward expanding the application areas in which CafeOBJ can be used well. The primary advantages of our method are as follows: - The workflow system, together with the RBAC mechanism and the SoD constraints, is described in terms of equations, which are easier to understand; and the verification is done by means of equational reasoning, which moderates the difficulties of proofs. - Different workflow instances are distinguished explicitly during specification and verification, which reflects the important feature of concurrent execution of workflow systems. - The analysis of workflow processes is combined with authorization flows. In other words, our method analyzes whether the workflow process is executable along with the authorization flow. Most other work on the other hand, analyzes these two aspects separately. Future work: we are going to use model checking technique to analyze such workflow systems. Although model checking technique is usually used to verify finite systems, it is a good complement of theorem proving technique and is generally easier to use. As a sibling language of CafeOBJ, Maude [4] is a specification and programming language, which has model checking facilities. It would be a good choice for us to carry out our future work. References [1] CafeOBJ web site. [2] V. Atluri and W.-K. Huang. An authorization model for workflows. In ESORICS 1996, volume 1146 of LNCS, pages Springer, [3] E. Bertino and E. Ferrari. The specification and enforcement of authorization constraints in workflow management systems. ACM Transactions on Information and System Security, 2:65 104, [4] M. Clavel, F. Durán, S. Eker, P. Lincoln, N. Martí-Oliet, J. Meseguer, and C. Talcott. Maude 2.0 manual: Version March [5] R. Diaconescu and K. Futatsugi. CafeOBJ report. Number 6 in AMAST Series in Computing. World Scientific, [6] P. C. K. Hung and K. Karlapalem. A secure workflow model. In AISW on ACSW frontiers (2003), pages Australia, [7] K. Knorr and H. Weidner. Analyzing separation of duties in Petri Net workflows. In MMM-ACNS 01, volume 2052 of LNCS, pages Springer, [8] K. Ogata and K. Futatsugi. Proof score approach to verification of liveness properties. Preparation for publication. [9] K. Ogata and K. Futatsugi. Formal analysis of suzuki&kasami distributed mutual exclusion algorithm. In FMOODS 02, pages Kluwer, [10] K. Ogata and K. Futatsugi. Formal verification of the hornpreneel micropayment protocol. In VMCAI 2003, volume 2575 of LNCS, pages Springer, [11] K. Ogata and K. Futatsugi. Proof scores in the OTS/CafeOBJ method. In FMOODS 03, volume 2884 of LNCS, pages Springer, 2003.