A Task-based Security Model to facilitate Collaboration in Trusted Multi-agency Networks

Salem Aljareh

Computing Science

University of Newcastle upon Tyne
+44 191 222 6053


Nick Rossiter

Computing Science
University of Newcastle upon Tyne
+44 191 222 7946





Security problems in collaboration work are less well understood than those in the business and defence worlds. Earlier work in the medical area in Britain has highlighted some of the principles involved but has neglected some important areas. Most of the security models developed to date are inadequate in the collaboration area. We develop a perspective for policies and models that is task-based on a need-to-know basis. These policies can be represented as Petri nets to identify the functions and states involved. We have also developed a general architecture for a secure collaborative environment. An example is given of the application of our techniques to a problem involving negotiation, decision and agreement in a collaboration environment.  


Collaboration networks, security models, multi-agency service.


Information of an individual is absolutely secure, as long as nobody else has access to it, which is true only in the case where an individual is completely independent. As a consequence information is naturally sharable among groups such as team, committee, organization, country and federation in a manner based on trust. However to achieve an accepted level of trust is quite a complicated issue because as the collaboration grows wider, more participants are involved with divergent policies. Although designing secure models for collaboration environments has been a target of a number of academic and commercial research and several works have been done (both theoretical and practical), still numerous organizations keep their systems (especially the trusted systems) unconnected with outsiders.

Basically security systems are built out of the available mechanisms to meet a security policy based on a selected security model [9]. The Bell-Lapadula Model (BLP) was the first formal model [3]. It is a state machine capturing the confidentiality aspect of the access control. It has been considered as a base or (at least a benchmark) for most security models and is used to design most of the available operating systems to support access control. Security policy in BLP is based on security levels and an access control matrix, which supports the traditional access rights (read, write, execute, append) but not the more recent access rights such as those required in a collaboration environment (viewing, coupling) [15]. However BLP deals only with confidentiality, not with the other computer security aspects such as integrity and does not address the management of access control as well as it has been proven that BLP could contain a convert channel[1]. To conclude the BLP model is suitable for an environment where polices are static.

Subsequent models attempted to fill the gaps left open in BLP. For instance the Harrison-Ruzzon-Ullman Model (HRU) [10] defines an authorisation system to address the problem of changing access rights, which was not addressed in BLP. In contrast to BLP, where access rights are usually assumed to be static, in the Chinese Wall Model [5] the access rights have to be re-examined at every state transition, to avoid conflict of interest. The Biba Model [4] deals with the integrity aspect. The Clark-Wilson Model [7] considers security requirements for commercial applications. It has two mechanisms to enforce integrity: the well-formed transaction and the separation of duties. The Information-Flow Model deals with the problem of the convert channel that has not been addressed by BLP and considers a system as a secure system if there is no illegal information flow.

Most of the security models that were designed subsequently were targeted at a specific security requirement. For instance multi-agency services and collaboration networks are based to some extent on these general models. However all these models are dealing with a single policy, whereas by definition the multi-agency and collaboration environment involves more than one policy.

A motivating example of an application that involves multi-agency services is the medical information services. The only model designed to meet the security requirements for the medical records in the UK was the BMA (British Medical Association) Security Policy Model [2]. This model was recently examined [1] against the multi-agency security requirements and it was found that the issue of sharing clinical information including collaboration activities with other agencies such as police, social services or the education authority was not clearly considered. For instance the need-to-know problem was not addressed in the BMA model, as the BMA does not accept that need-to-know is an acceptable basis for access control decisions. However there might be a case where need-to-know cannot be avoided. For instance a service provider such as an insurance company offers its services conditioned by some information about the patient who applies for such services. An example is given in [1].

In this paper, we propose a security model that we argue will alleviate the security difficulties that may arise in attempts to build a collaboration network. The model is constructed from a task-based perspective, as this approach seems to offer the best way forward, as discussed later. The general principles of the model are discussed and a diagrammatic representation is devised. Two task-based collaboration protocols, expressed in this paper in the form of Petri Nets, represent the permitted states and transitions. An example of informal collaboration is used to illustrate the application of the model.

2. A Task-based Perspective for Collaboration Networks

A collaboration business, by definition, is based on the needs of the collaborators from each other. Each side needs information or a service from the other participants. The obvious question that someone will immediately ask before he/she releases any confidential information or responds to an enquiry is: What for? For what purpose is the information required? Usually the expected answer will be the naming of a task for which the information required is essential, sometimes with a further explanation of the benefit of this task for the two sides (collaboration proposal). The information owner may like to restrict the use of this information by some conditions (security policy). If they reach initial agreement a detailed negotiation will then take place until they reach a considered level of trust, which leads to a collaboration agreement to perform the task. One reasonable condition might be to limit the use of the information by other tasks. For instance it could be specified that the information should not be used outside the task for any purpose.

We have decided to build our model as a task-oriented model for the following reasons:

1.       Fundamentally any collaboration scheme is based on specific tasks: there is no collaboration without a task.

2.       The task-based approach is promising to address the need-to-know problem, satisfying a user requirement in any multi-agency services environment.

3.       The collaboration task is the common object between the collaborators.

4.       Shared information ownership can be granted to the collaboration task.

5.       The task is scalable, flexible and dynamic.

6.       Explicit responsibility is recognized in the task-based approach.

Overall the basis for any collaboration is an aim to share resources in order to achieve common benefits by performing shared operations. Other task-based approaches to security are discussed later.

3. General principles for our Model

3.1 Collaboration

 In our model we consider any deal/trade between individuals or groups which aims to benefit the sides involved is a kind of collaboration. The following are some forms of collaboration:

·        Trading between customers and service providers.

·        Joint operation projects

·        Research group collaboration.

·        The clinician and the patient trade/relationship: the clinician's job exists because of the patient, and the patient needs the clinician for treatment. So both need each other and benefit each other. The clinician may need to know some information from the patient as part of the course of treatment. The relationship is in general based on trust. In this example there are two sides trading benefits through the task called treatment. 

3.2 Ownership

An item of information, in this model, is owned initially by its natural owner that is the person to whom the information relates. For instance information about the baby is owned by the baby although this information is controlled by guardian/parents. In computer security terms this is called grant access or delegation. Once this information is required to be shared among collaboration parties, an access will be granted to what we call the collaboration-task and will be controlled by the task-policy. The information owner and/or the access controller will be part of the negotiation that results in the task policy.

3.3 Authorization

A participant in a collaboration network, called task-participant will be authorised to gain access to a collaboration-task. This authority will be limited by what we call task-policy.

3.4 Responsibilities

All responsibilities should be explicitly defined in the task policy in the way each individual collaborator (task-participant) knows their responsibilities such as the required duties, the rules to follow (including ethical codes), the limitations (e.g. time, use of material and information) and the penalties.

4. Collaboration task characteristics

1.       Flexible:  can be a single activity of group of activities sharing same policy, each of which can be selected as the need arises.

2.       Dynamic: can be updated even while it is running (supporting post-hoc justification). For instance a nurse can be replaced by another one if he/she is not, for any reason, able to complete his/her duty in a surgical operation. However any change in the task elements should be fully and carefully documented. (Accountability).

3.       Secure: should be fully protected using all the available mechanisms.

4.       Scalable: can be upgraded, for instance to fill some gaps in the original one. A new collaboration task can be built starting from default tasks (task template).

5.       Accountable: all collaboration protocol states and all task run-time events of the collaboration must be well documented.

5. Diagrammatic Representation of Model

The architecture in Figure 1 illustrates the general components of our model. The main component is the collaborators (two or more), each of which will need to define three elements: requirements (what does he/she/it/they aim to gain from the other side), policy (rules that need to be obeyed) and material (e.g. information to release or services to offer). The second component is a pair of task-based collaboration protocols -- the Task Creation Protocol (TCP) and the Task Runtime Protocol (TRP), both detailed later in the following sections.


















TCP includes a negotiation between all collaborators where the proposed task will be discussed including all collaborators’ policies and requirements. This process (negotiation) continues until a decision is taken either by rejecting the proposal or by accepting it. The acceptance of a proposal will lead to a formal agreement/contract, which will produce the proposed collaboration task in its final stage including all of the policies and requirements.  Negotiation can of course be a very complex task [6]. The work described here could be extended later to include such aspects as conflict resolution. TRP will start after a successful compilation of TCP and as scheduled .in the task_policy (not necessarily immediately after the end of TCP).

The main function of TRP is to process the task that was previously created by the TCP protocol and ensure that the task_policy is obeyed, the collaborators are aware of the circumstances and the right action is taken. TRP is detailed in the following chapters. In a special case of the abnormal termination of the task process the collaborators may need to go back to the TCP protocol to create an alternative task.



6. Formalisation of Protocols

We use the Petri Nets model to represent our collaboration protocols to provide a formal basis and to make it more readable for computer scientists. Flow charts lack a formal basis and can be ambiguous in representing states and transitions. Net theory was originally introduced in a PhD thesis of C. A. Petri and Reisig [14] introduced it to the software engineering area in 1985. More recent advances in this formalism are described in [13]. The usefulness of Petri Nets in providing a theoretical basis for handling object life cycles has been demonstrated by van der Aalst and Basten  [19]. The Petri Net in Figure 2 represents the TCP protocol.

The initial state represents the aim of each collaborator including requirements, policies and offers. For instance, in the patient-doctor collaboration, the patient’s requirements are treatments, the patient’s policy is to keep personal information secret, the doctor’s requirements may include information about the patient and the doctor’s offer is a treatment course. These aspects will be initially discussed as to whether the task (at first an offer from one side or a requirement from another) is accepted as an offer or rejected without any further details. The introduction transition will not include discussion about the policies. If the proposed task is found to be reasonable then all collaborators will enter into a detailed negotiation in which all aspects including requirements, services and polices will be clarified for all collaborators. After that one of three decisions will be taken: the first option could be one of the collaborators needs more time to think about the task/offer; the second option could be that the expected level of trust could not be ensured so the task is simply dismissed; the third option is that all collaborators trust each others so that an agreement between all collaborators will take place. This agreement at the end will be formulated in what we call the collaboration task. This task will be limited in scope by the task policy, which is a composition of all collaborators' policies, meeting all sides’ requirements.

The task Runtime protocol (TRP), illustrated in Figure 3, starts after the task has been completely created by the TCP protocol and when its schedule time, according to the task-policy, is due. Before starting the process of the task some tasks need some preparations. Then the task process starts following the policy that has been approved in the TCP stage. Each state of this process is monitored, assessed (verified against the task-policy) and then documented. The task assessment may result in one of the following:

1.       The task is proceeding satisfactorily, following the policy and the plan and has not finished yet, so the task should persist.

2.       The task needs an update to meet its requirements. Depending on how the updates affect the process: the task may restart or continue from the last state of the process.

3.       The task reaches its scheduled end, hence the task terminates normally.

4.       There might be a case where the task abnormally terminates, for instance the task-policy has been violated, or the task exceeds the scheduled time without valid reasons. The abnormal termination could lead either to the end of the task and then the collaboration or to a new session of the TCP.

7. Example of Informal Collaboration

Let us consider a situation of a son asking his father for some cash:

7.1 The Task Creation protocol (TCP)

7.1.1 Introduction:

Son: father, I need 20 pounds [requirements].

Father: what for?

Son: to buy a book. [Purpose]

Father: well I do not have enough cash and I cannot drive to the ATM at the moment. [Initial discussion]

Son: Would you please lend me any of your cards (Debit or Credit) with the PIN, so I can go myself? [Proposed task]

7.1.2 Negotiation:

Father: well, you understand that you will not use this card for any other purpose, you will not withdraw more than 20 pounds, and you will not give away the card or its PIN to anybody else [Policy].

Son: Yes, I do understand that [accepting policy].

7.1.3 Decision:

Father based on his experience with his son will go for one of the following three options:

1.       Take more time to think about the matter and to ask more questions. [Back to negotiation],

2.       Cannot trust his son, so he cannot give him his card. [Dismiss the task], or

3.       Trust his son and give him the card [commit the task].

7.1.4 Agreement:

·        Father: I agree to give you my card along with the PIN but you should remember that:

·        You return the card to me within 20 minutes of obtaining the money.

·        You will not withdraw more than 20 pounds and you will not use the card for any other purpose.

·        You will use the money to buy a book.

·        You should not give the card nor disclose the PIN to anybody else.

·        This agreement is based on trust between us.

·        Son: Yes, I do understand all these conditions.

7.1.3 Rejection:

Father: I will go myself later to obtain for you the money that you want.

7.2 The Task Runtime Protocol (TRP).

7.2.1 Preparation:

Farther: Explains to his son how to use the card and gives it to him.

7.2.2 Task process:

Son takes the card and starts using it.

7.2.3 Task assessment:

Father watches the time, maybe checks his account with another card if it takes more time than expected and takes decisions accordingly. Meanwhile he updates his relationship of trust with his son in the light of this experience.

7.3 Example modelling:

In this example we have two collaborators (task-participant1=son and task-paticipant2=father), task_name = borrow credit/debit card, purpose = withdraw 20 pounds to buy a book, policy = {withdraw only 20 pounds, not to use the card for any other purpose, return the card after getting the money, and not to give it away}, and security-base = {trust based on experience}.

8. Discussion

We consider two aspects of our work. Firstly the extent to which task-based approaches have been used before in security systems; secondly the usability and computability of task-based approaches in the security area.

The idea of task-based has been introduced before in a number of models [8],[16], [17]. All were at the basic level of this approach. The focus in [16, 17] was on whether a task-based security model could be an alternative authorisation and access control model to the subject-object traditional authorisation models. While in [8] Fischer-Hubner and Ott tried to address the privacy problem using the task-based approach.  We intend in our model to use all of the power of this idea (task-based approach) to address the security problem of the collaboration networks and the multi-agency services environment. In more detail:

1.       Steinke [16] outlines the general features and characteristics of the task-based approaches such as:

·        The need-to-know is related to the operation, which needs to be performed.

·        Any information needs can be related to a task.

·        Tasks are common entities that exist and relate directly to both users and to information.

·        Tasks limit the access to the information from the start to the termination of the tasks.

·        Tasks already exist, and are identifiable, flexible and dynamic.

The Group Security model (GSM) by Steinke was described as a security model, which provides access to information on the base of a user's task.

However some features of GSM are already rather obvious in existing information systems infrastructure. For instance in any relational database, it is always possible to grant users/roles to functions, procedures, and packages rather than grant them to the information objects (e.g. tables, views). These functions, procedures and packages are in fact tasks and group of tasks and also can be functionally minimized. GSM considers the discretionary security approach to deal with ownership. Overall GSM is more suitable for hierarchy systems, where the responsibilities are visible.

2.       Thomas and Sandhu [17] introduced the task-based approach initially in 1994 as an approach to address integrity issues in computerized information systems from an enterprise perspective. Subsequently in 1997 they [18] developed their approach to produce a paradigm for access control and authorisation management. The developed model is called Task-based authorisation control TBAC. 

3.       Fischer-Hubner and Ott [8] in their model attempted to address the privacy aspect using the task-based approach. The nature of the task-based approach eases the handling of the main privacy requirements such as:

·        Purpose binding: personal data obtained for one purpose should not be used for another purpose without informed consent.

·        Necessity of data collection and processing: the collection and processing of personal data shall only be allowed, if it is necessary for tasks falling within the responsibility of the data processing agency.

In contrast to the models of Steinke and of Thomas and Sandhu, this model takes a forward step to de-centralise the authorisation using a 4-eyes principle. However there were no end-user requirements supporting this model and the 4-eyes principle is not enough to ensure de-centralisation. The set theory which was used to represent this model is not proven, nor is it in a framework (Petri nets, Category theory, LaSCO, Ponder, VDM, Z, ...) where proof is done by following constructive principles or through a guaranteed mechanism. Finally the Fischer-Hübner and Ott model does not include collaboration ventures.

4.       Mahling, Coury and Croft [12], 11 years ago, tried to build a task-based collaboration model. However this work starts from a relatively late stage in the negotiation where the plan, agreement and tasks are relatively clear. In addition their work does not consider the case of the multi-agency environments where the policies of the collaborators are different.

We argue that the real challenge for the task-based approach is the multi-agency services environment, where responsibilities are distributed and the ownership is dynamic.  None of the existing approaches have considered the multi-agency aspects in detail.  Furthermore the other issue of any computer system design including security system is the usability [11]. This issue was ignored in most of the above security models.

Usability and computability are almost equally important issues. It is not sufficient to a computer system to be robust, dependable, and cover all the expected functions (computability). It also has to be accepted by its users, in other words it has to be user-friendly (usability). Social specialists and some groups of information and computer specialists argue that the issue of “usability” has more to do with developments and implementations of computer systems than their computability. Certainly the computer security issue is not an exception from this rule. Indeed usability factors such as politics, organization policy and rules, human behaviours and modes, groups and individuals’ interests are very much involved in the design of a secure computer system. For instance long and difficult security procedure may affect the system availability and/or encourage users to skip some steps of the procedure.  In addition to its coverage of the issue of computability, our model will also suitably fulfill the usability requirements since it considers direct participation of the users. For example it is not necessary, in our task-based model, to fully computerize a given task; it depends very much on the result of the negotiation between the involved parties in that task.

9. Conclusions

This paper has introduced a task-based model to facilitate collaboration in trusted multi-agency networks, after a wide investigation of the exiting security models concerning the multi-agency environment and collaboration networks. Our model is based on the fundamental aspect of the collaboration environment, which is the task-based perspective. Two task-based collaboration protocols (TCP and TRP), expressed in this paper in the form of Petri Nets, are used to represent the permitted states and transitions. An example of informal collaboration is used to illustrate the application of the model. We have also discussed the extent to which task-based approaches have been used before in security systems. In addition to its coverage of the area of computability, our model suitably covers the usability requirements.

10. References

1.       Aljareh, S. and Rossiter N.  Toward security in multi-agency clinical information services. In proceedings of workshop on dependability in healthcare Informatics Edinburgh, 22nd-23rd March 2001, 33-41.

2.       Anderson, R. A security Policy Model for clinical information systems. In Proceedings of the IEEE Symposium on Research in Security and Privacy, Research in Security and Privacy, pp. 30–43. IEEE Computer Society, Technical Committee on Security and Privacy, IEEE Computer Society Press, Oakland, CA, May 1996.

3.       Bell, E. D. and LaPadula, L. J. Secure Computer Systems: Mathematical Foundations. Mitre Report ESD-TR-73-278 (Vol. I–III), Mitre Corporation, Bedford, MA, Apr 1974.

4.       Biba, K. Integrity Considerations for Secure Computing Systems. Mitre Report MTR-3153, Mitre Corporation, Bedford, MA, 1975.

5.       Brewer, D. F. C. and Nash, M. J. The Chinese Wall Security Policy. In 1989 IEEE Symposium on Security and Privacy, pp. 206–214. Oakland, CA, 1989.

6.       Chu-Carroll, J., and Carberry, S., Conflict Resolution in Collaborative Planning Dialogues, International Journal of Human-Computer Studies, 53(6), 2000, pp 969-1015.

7.       Clark, D.D. and Wilson, D. R. A Comparison of Commercial and Military Computer Security Policies. In 1987 IEEE Symposium on Security and Privacy, pp. 184–194. Oakland, CA, 1987.

8.       Fischer-Hübner, S. and Ott, A. From a Formal Privacy Model to its Implementation. Proceedings of the 21st National Information Systems Security Conference, Arlington, VA, October 5-8, 1998.

9.       Gollmann, D. Computer Security. ISBN: 0 471 97844 2, John Wiley and Sons, 1999.

10.    Harrison, M.A., Ruzzo, M.L. and Ullman, J.D. Protection in operating systems. Communication of the ACM, 19(8) pp 461-471, August 1976.  

11.    Kling, R. Information and computer scientists as moral philosopher and social analysts. Computerization and controversy: Value conflicts and social choices. Academic Press Inc, 1991, pp 32-37.

12.     Mahling, D.E., B.G. Coury, and W.B. Croft. User Models in Cooperative Task-oriented environment. Proceeding of the 23rd Annual Hawaii IEEE International Conference on System Science, 1990, pp 94-99.

13.    Reisig, W. and Rozenberg G. Lectures on Petri Nets: Advances in Petri Nets. Lecture Notes in Computer Science, 1998, 1491.

14.    Reisig, Wolfgang. Petri Nets: an introduction. Berlin; New York: Springer-Verlag, 1985.

15.    Shen. H.  H. and Dewan, P. Access control for collaboration environment CSCW 1992 pp 51-58.

16.    Steinke, G. A task-based Approach to Implementing Computer Security. Journal of computer Information Systems, fall 1997, pp 47-54.

17.    Thomas, R. K. and Sandhu, R. S. Conceptual Foundation for a Model of Task-Based Authorization. Proceedings of the 7th IEEE Computer Security Foundations Workshop, Franconia, NH, June 1994, pp 66-79.

18.    Thomas, R. K. and Sandhu, R. S. Task-based Authorization Controls (TBAC): A Family of Models for Active and Enterprise-oriented Authorization Management. Proceedings of the IFIP WG11.3 Workshop on Database Security, Lake Tahoe, California, August 11-13, 1997

19.    Van der Aalst, W. M. P, and Basten, D, Identifying Commonalities and differences in Object Life Cycles using Behavioral Inheritance, Application and Theory of Petri Nets 2001, 22nd International conference ICATPN, Newcastle, 2001, 32-52.




 Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage, and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.


SAC 2002, Madrid, Spain

© 2002 ACM 1-58113-445-2/02/03...$5.00

[1] Convert channel is an information flow that is not controlled by security mechanisms.