The Chinese Wall Policy. This policy is located somewhere between DAC and MAC as it combines features of both techniques. It is influenced by the common ...
Position paper presented at the ACM CSCW’94 Workshop on Distributed Systems, Multimedia, and Infrastructure Support in CSCW, Chapel Hill, North Carolina, October 22, 1994. In: ACM SIGOIS Bulletin, Vol. 15, No. 2, Dec. 1994, pp. 24-27.
Access Controls for Cooperative Environments Ernst Ellmer, Guenther Pernul, Gerald Quirchmayr, A Min Tjoa University of Vienna Institute of Applied Computer Science and Information Systems Information Engineering Group Liebiggasse 4, A-1010 Wien { ee | guenther | gq | amt }@ifs.univie.ac.at
Introduction With security issues increasingly gaining importance, cooperative environments and especially workflow systems have to incorporate techniques dealing with this problem. Existing concepts have, with very few exceptions [1], so far been focused on operating and database systems and little effort has been seen as far as workflow reference models are concerned. That is why this paper tries to evaluate the applicability of concepts originally developed for database and operating systems to workflow management systems.
A Reference Framework for Workflow Management In this section we describe a reference framework for workflow management systems. Several components of workflow management are identified. The essential building blocks of workflow management systems are listed below. Let CA = {ca1,..., can} be a set of cooperative activities where a cooperative activity cai ∈ CA represents a high level “business process” of a certain type carried out by a group of people (a workgroup) within an organization in a cooperative and coordinated manner. Note that cooperative activities are not instantiated. A cooperative activity doesn’t refer to one real world process but describes the structure and behavior of a type of real world processes. Let PM = {pm1,..., pmn} be a set of process models for the cooperative activities CA where pmi is the process model for cooperative activity cai. Note that the above definition does not allow multiple process models for one cooperative activity. An organization O is a real world body (a corporation) which performs cooperative activities. An organizational model OM is a model of the organizational structure of a corporation O. Let P = {p11,...,pnm} be a set of currently executing processes where pij is an enactable instance of pmi in a certain state of execution. Be aware of the difference between a process model pmi and an enactable instance of the process modeled pij. While the first one describes the structure and behavior
2
of one type of “business processes” (cooperative activity), the second one represents a concrete process instance, which means that the conceptual objects modeled in pmi are bound to objects existing in the real world, e.g. files or employees. A workflow management system WFMS is a computer system enabling various users to access: • the organizational model OM through supporting the modeling of the organization O, • the set of process models PM through supporting the modeling of the cooperative activities CA and allowing to analyse the process models. • the set of running processes P through a runtime process supporting system supporting • the instantiation of process models PM, • the association of agents defined within OM to subactivities of processes P, • the execution of subactivities by associated agents, • the evolution of running processes, • the monitoring of the states of execution of running processes by providing a set of tools. Figure 1 visualizes the definitions above and their interconnections.
CA = {ca1,..., can}
O
W
OM PM
F M
P
S
Figure 1: A Reference Framework for Workflow Management
3
A Taxonomy of Security Requirements in Workflow Management In this section we will give a taxonomy of security needs in workflow management based on the reference framework developed in section one. A WFMS enables a user to access the organizational model OM, the process models PM, and the running processes P by providing a set of functions, i.e. organizational modeling, process modeling, process model analysis, process instantiation, agent management, process execution support, process evolution, process monitoring. In this paper, we regard enforcing security in WFMSs as restricting access to OM, PM, P, i.e. preventing users from viewing (read access) OM, PM, P on the one hand, and performing some of the functions mentioned above (write access) on the other hand. Therefore we propose the following taxonomy. 1. Restricting access to OM 1.1 Preventing users from reading OM users are not aware of the existence of OM 1.2 Preventing users from reading parts of OM users don’t see parts of OM 1.3 Preventing users from writing to OM users are not able to carry out the organizational modeling function 2. Restricting access to PM 2.1 Preventing users from reading pmi ∈ PM users are not aware of the existence of a certain process model 2.2 Preventing users from reading parts of pmi ∈ PM users don’t see parts of a certain process model 2.3 Preventing users from writing to pmi ∈ PM users are not able to carry out the process modeling function 2.4 Preventing users from analyzing pmi ∈ PM users are not able to simulate a process model 3. Restricting access to P 3.1 Preventing users from reading pij ∈ P users are not aware of the existence of certain executing processes 3.2 Preventing users from reading parts of pij ∈ P users are not aware of the real structure and behavior of a certain process 3.3 Preventing users from creating a new pij ∈ P users are not able to perform the process instantiation function
4
3.4 Preventing users from associating agents to subactivities of pij ∈ P users are not able to perform the agent association function 3.5 Preventing users from executing subactivities of pij ∈ P users are not supported to perform process steps (subactivities) 3.6 Preventing users from evolving pij ∈ P users are not able to perform the process evolution function 3.7 Preventing users from monitoring pij ∈ P users are not able to see the status of current execution of a process
The Role of Existing Security Approaches Workflow systems may be used in a wide range of diverse application scenarios reaching from systems processing non sensitive information to systems with very high security requirements. This is not in contrast with more traditional computerized systems and motivates a discussion wether existing approaches to achieve a certain degree of security are also applicable to general workflow environments. The following is a discussion of the most prominent approaches to security and their relationship to workflow management.
Discretionary access controls Discretionary access controls (DAC) are based on the concepts of security objects (the target of protection), security subjects (transactions active on behalf of an agent), privileges (defining what kind of access a subject has to a certain object), and in order to represent content-based access rules a set of predicates. Furthermore, two different principles are implemented in DAC-Systems: the principle of ownership of information and the principle of delegation of rights. An access right may be propagated between subjects (delegation of rights) while with ownership of information it is meant that DAC systems assign the ownership of information to the creator of an item and allow him to grant access to other users. Discretionary security is enforced in most commercial operating systems and database management systems, and has also been suggested for workflow management systems before [1]. In our opinion DAC-based information protection may only have potential in workflow systems processing less sensitive information and information may be assigned to agents having ownership privileges.
Mandatory access control models While discretionary models are concerned with defining, modeling, and enforcing access to information, mandatory security models are in addition concerned with the flow of information in a system. Mandatory security requires that security objects and subjects are assigned to certain security levels (the list of levels is hierarchically ordered) and a level for an object represents its sensitivity while a level for a subject its trustworthiness to not disclose sensitive information. Mandatory access control (MAC) requirements are often stated based on Bell and LaPadula [2] (BLP) and formalized by two rules. The first (simple property) protects the information from
5
unauthorized disclosure, and the second (*-property) protects it from contamination or unauthorized modification by restricting the information flow from high to low. • Subject s is allowed to read data item d if clear(a) ≥ class(d). • Subject s is allowed to write data item d if clear(a) ≤ class(d). Mandatory access controls are very efficient and required for systems gaining evaluation at the higher levels of trust of evaluation criteria (i.e. [3], [4]). Some of the concepts may also be applicable for workflow environments (for example, controlling the flow of information between subjects) however, MAC-based protection based on BLP has one major limitation: n-person access restriction. This is, that subjects assigned to different security levels may not edit the same security objects. This restriction is necessary to limit the information flow between subjects at different security levels but may also limit MAC-based protection in workflow systems.
Object-Oriented security (The Personal Knowledge Approach) In this model [5] users as well as security objects are represented by encapsulated objects (in the sense of object-oriented technology). The data part of an object corresponds to the ‘knowledge’ of the object which may correspond to information about the object itself or about the relationship to other objects. The operation part of an object corresponds to the possible actions the object may perform. The approach is built on the assumption that an object represented in the database knows everything about itself and if it wants to know something about another object represented in the database that object must be ‘asked’. Knowledge about different objects cannot be stored permanently and therefore must be requested whenever the information is needed. For workflow systems some potential of this security technique may exist. Of particular interest are the concept of encapsulation within the object-oriented framework and the possibility of representing the workflow agents as security objects. This gives raise to express the semantics of role specific behavior of agents by using object-oriented concepts.
The Clark and Wilson Model This model [6] is based on the notion of security subjects, (constraint) security objects, a set of well-formed transactions and the principle of separation of duty. Subjects are assigned to roles. Based on their role in an organization users have to perform certain functions. Each business role is mapped into functions and ideally at a given time a particular user is playing only one role. A system function corresponds to a set of (well-formed) transactions that are necessary for the users acting in the role. In this model it is essential to state which user is acting in what role at what time and for each role what transactions are necessary to be carried out. Access to information is permitted only through the execution of well-formed transactions and each well-formed transaction operates on an assigned set of data and assurance is given that all relevant security and integrity properties are satisfied. Separation of duty requires that each set of users is assigned a specific set of responsibilities based on the role of the user in the organization. The Clark and Wilson model may have potential in workflow systems. However, this model does not support ad-hoc querying facilities (such as typically necessary for monitoring and tracking) because
6
access is only granted through predefined well-formed transactions.
The Chinese Wall Policy This policy is located somewhere between DAC and MAC as it combines features of both techniques. It is influenced by the common practice of British stock brokers to prevent from using ‘insider knowledge’ and has first been formalized by Brewer and Nash [7]. It can be summarized as follows: Consultants are assumed to consult different companies and are supposed to be users of the computer system storing information about companies. At the beginning every user has free choice to read any data. After he has read the data of one company a Chinese Wall is built between the chosen company and its competitors and from now on the user is not allowed to read data behind the wall, but he still can read data from companies not competing with the first company. For example, assuming that he has chosen a bank first, he still can consult an oil company. With this technique, an irregular direct information flow can also be prevented in workflow systems. However, the technique needs to be extended to also cover indirect information flow. As an example, two oil companies may have their accounts with the same bank. As there is no conflict of interest between banks and oil companies a given consultant may advise both. However, from having access to bank related information he may gain insider information about an oil company which may help him to advise the second oil company. For workflow applications it is essential to carefully design conflict of interest relations among participating cooperative activities.
Role-based Security Role-based security is used to group users into higher level abstractions, called roles. This is necessary because in large organization the number of users may be high and therefore difficult to administrate. Users belonging to a role share the same responsibilities within the organization and have the same access privileges to information. In most cases, a role hierarchy is used to represent associations between user roles and individual users are assigned as instances of certain roles. This technique is not an isolated approach to security but must be seen together with one of the approaches discussed above. For workflow applications we see an enormous potential for this technique because it may help to represent and organize agents in a high level and system independent manner.
Conclusions However important security issues may be for workflow environments, it seems that this topic is only now beginning to be of interest for the community. That is why our contribution is mainly aimed at generating a discussion resulting in greater awareness. Therefore we have tried to evaluate existing security concepts according to major requirements imposed by WFMSs without making a final decision for one model or another because at this stage such a decision would be premature.
References [1] Shen, H., Dewan, P. (1992). Access Control for Collaborative Environments.
7
Proc. of the 1992 ACM Conf. on CSCW. [2] Bell, D. E., and LaPadula, L. J. (1976). Secure Computer System: Unified Exposition and Multics Interpretation. Technical Report MTR-2997. MITRE Corp. Bedford, Mass. [3] TCSEC (1985). Trusted Computer System Evaluation Criteria. (Orange Book). National Computer Security Center, DOD 5200.28-STD. [4] ITSEC (1991). Information Technology Security Evaluation Criteria (ITSEC). Provisional Harmonized Criteria, COM(90) 314. Commission of the European Communities. [5] Biskup, J., and Brüggemann, H. H. (1988). The Personal Model of Data: Towards a Privacy-Oriented Information System. Computers & Security, Vol. 7, North Holland (Elsevier). [6] Clark, D. D., and Wilson, D. R. (1987). A Comparison of Commercial and Military Computer Security Policies. Proc. 1987 Symp. on Research in Security and Privacy, IEEE Computer Society Press. [7] D. F. C. Brewer, M. J. Nash (1989). The Chinese Wall Security Policy. Proc. of the IEEE Symp. on Security and Privacy, 1989.
