A Formal Security Model for Collaboration in Multi-

agency Networks

Salem Aljareh

Computing Science, Newcastle University, Newcastle upon Tyne, UK NE1 7RU

Nick Rossiter (Informatics), Michael Heather (Law)

University of Northumbria, Newcastle upon Tyne , UK, NE1 8ST

Abstract: Security problems in collaborative work between multiple agencies are

less well understood than those in the business and defence worlds. We develop a

perspective for policies and models that is task-based on a need-to-know basis.

These policies are represented by two protocols, the first CTCP (Collaboration

Task-based Creation Protocol) dealing with negotiation, decision and agreement

between the parties involved and the second CTRP (Collaboration Task-based

Run-time Protocol) responsible for the operation of the policy. The two protocols

and the relationship between them are defined in Petri-Nets. The overall model is

formally defined using a categorical pullback construction. Each of the protocols,

represented as Petri-Nets for state-transition purposes, is a category-valued

functor in the pullback.

1 INTRODUCTION

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 bodies and several works have been done (both

theoretical and practical), numerous organizations still 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 [Gollmann, 1999]. A review has been made

elsewhere [Aljareh & Rossiter, 2002] of the appropriateness of standard security

models for collaborative multi-agency systems. Most are either targeted at a specific

security requirement or are too static to represent a dynamic situation. All deal 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 [Anderson, 1996]. This model was recently

Aljareh S., Rossiter N. and Heather M. (2004).

A Formal Security Model for Collaboration in Multi-agency Networks.

In Proceedings of the 2nd International Workshop on Security in Information Systems, pages 157-169

DOI: 10.5220/0002671001570169

 SciTePress

examined [Aljareh & Rossiter, 2001] 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 [Aljareh & Rossiter, 2001].

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. An example of a prototype for informal

collaboration, handled using the model, is given elsewhere [Aljareh & Rossiter,

2002]. The general principles of the model are discussed and a diagrammatic notation

is devised. Two task-based collaboration protocols, expressed in this paper in the

form of Petri-Nets, represent the permitted states and transitions. The choice of Petri-

Nets as the notation is discussed. Finally the overall model is constructed formally as

categorical pullbacks to illustrate its foundation on established logical principles.

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 construct 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.

158

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

Collaboration: In our model we consider any deal/trade between individuals or

groups, which aims to benefit the sides involved as 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

Ownership: In this model an item of information 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, 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.

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.

Responsibilities: All responsibilities should be explicitly defined in the task policy.

This 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 COLLABORATIVE TASK CHARACTERISTICS

The characteristics of collaborative tasks are considered to be:

1. Flexible: can be a single activity or 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.

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 task. A

new collaboration task can be built starting from default tasks.

159

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 Collaboration Task Creation Protocol (CTCP) and the Collaboration

Task Runtime Protocol (CTRP) -- both detailed later in the following sections

CTCP 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

[Chu-Carroll & Carberry, 2000]. The work described here could be extended later to

Tas

ased Collaboration protocols

Collaboration Tas

based Creation

Protocol (CTCP)

Collaboration Tas

based Runtime

Protocol (CTRP)

Figure 1: General Architecture for secure Collaboration Environment

Policy

Material

Requirements

160

include such aspects as conflict resolution. CTRP will start after a successful

compilation of CTCP and as scheduled .in the task_policy (not necessarily

immediately after the end of CTCP).

The main function of CTRP is to process the task that was previously created by the

CTCP protocol and ensure that the task_policy is obeyed, the collaborators are aware

of the circumstances and the right action is taken.

6 REPRESENTATION OF PROTOCOLS IN PETRI-NET

NOTATION

We use the Petri-Nets model to represent our collaboration protocols to provide a

formal basis and a more applicable medium for computer scientists. Flow charts lack

a formal basis and can be ambiguous in representing states and transitions. Data flow

diagrams emphasise flows of data, not states, which are considered critical in security

systems.

Intr

oduc

Rethinking

Dismis

Agreemen

Create

Col-task

Figure 2: Petri-Net Graph representing the Collaboration

Task-based Creation Protocol (CTCP)

(Requirements, offer,

policy) * No of

Collaborators

ust

egotiation

161

Net theory was originally introduced in a PhD thesis of C. A. Petri. Later Reisig

[1985] introduced it to the software engineering area. More recent advances in this

formalism are described in [Reisig & Rozenberg, 1998]. The usefulness of Petri-Nets

in providing a theoretical basis for handling object life cycles has been demonstrated

by van der Aalst and Basten [2001]. In collaboration networks, similar to the multi-

agency services investigated here, Furuta and Stotts [1994] presented an evolution of

the Trellis model by providing a formal Petri net basis for prototyping the control of

such a network.

In the security area an industrial use of Coloured Petri-Nets was developed by

Rasmussen and Singh, [1996] making it possible to perform simulations. The nets

were debugged by constructing reachability graphs. Joshi and Ghafoor [2000]

specified a multi-level security model for multimedia using a time- augmented

coloured Petri-Net model. For cryptographic protocols Crazzolara and Winskel

[2001] use Petri-Nets to illustrate how their semantics can be used to prove security

properties. Ryan [2003] notes that causality, critical in the analysis of security

protocols, is closely related to information flow and that causal structures are rather

more explicit in Petri-Nets than in many other areas.

In general Petri-Nets have been widely used for the modelling and analysis of systems

that are characterized as being concurrent, asynchronous, distributed, parallel and

non-deterministic [Jensen, 1996]. All these features apply in the collaborative, multi-

agency systems studied here. Activities in the systems: a) overlap in timing; b) are run

independently rather than according to some common time signal; c) are run over

many different servers; d) involve the splitting of tasks into subtasks which run in

parallel until some common join point is reached; and e) may not give the same result

in negotiation each time the protocols are run.

The Petri-Net in Figure 2 represents the CTCP protocol. The initial state represents

for each collaborator their 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. Following

discussion of this initial state the task, at first an offer from one side or a requirement

from another, is accepted as an offer for further negotiation or rejected without any

further details. Policy considerations are normally omitted during the introduction

transition.

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.

162

Figure 3: Petri-Net Graph representing the Collaboration Task-based Run-time

Protocol (CTRP)

Task

Init Process

Preparation

Assessmen

End

Abor

CTCP

Update

Task process

Init Process

Pre

aration

Log

Assessmen

End

Abor

CTCP

Update

Figure 4: Exception occurring during CTRP, followed by an abort

and a return to CTCP (see section 6 for notation)

163

This task will be limited in scope by the task policy, which is a composition of all

collaborators' policies, meeting all sides’ requirements.

The Collaboration Task Runtime protocol (CTRP), illustrated in Figure 3, starts after

the task has been completely created by the CTCP 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 CTCP 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 CTCP. An exception is raised when the policy

has been violated as in Figure 4.

In our model exceptions are divided into three types according to the handling

process:

1. Exceptions with which the task can still continue to its normal end. Exceptions of

this type are handled within the CTRP protocol by the task update component.

Figure 4 shows the path of the exception type as a double line =..

2. Exceptions with which the task must be terminated and another task is required to

complete the planned function. Such cases are handled partially in the CTRP

protocol. The task in such cases is aborted and the process log (task history) used

by the CTCP protocol to create another task to redo the function that could not be

done by the terminated task in view of the exceptions that have arisen. The

exception handling path for this type is shown as a thick line in Figure 4.

3. Exceptions with which the task must be terminated and there is no need for any

further actions. There are cases where the task immediately terminated and no

further actions are possible. Exceptions from this type are handled within the

CTRP protocol through the ABORT component. The exception handling path for

this type is shown as a dotted line in Figure 4.

7 FORMALISATION WITH CATEGORICAL PULLBACKS

The relationship between the protocols CTCP and CTRP can be represented

rigorously by the categorical pullback shown in Figure 5. Pullbacks are examples of

cartesian closed categories [Mac Lane, 1998].

164

c x a

∃

C X

A ∆ C/B

∀

c x a

Figure 5: Categorical Pullback of System (A) over Environment (C) in the context of

Purpose/View (C/B)

This figure shows the relationship between four categories (denoted in bold font). C is

the complete environment, A is a particular system to which a user may require

access, C/B is a slice category or subcategory of C and C X

A is a limit, representing

the relationship between C and A in the context of B. The limit can be viewed as a

subcategory of the product C X A over B. Three functors map between C X

A and

C/B. ∃ is the existential quantifier selecting some C/B for a particular C X

A, ∀ is

the universal quantifier selecting C/B that satisfy all the rules determined by ∆ as the

diagonal functor selecting a limit C X

A for a particular subcategory C/B. ∆ is right

adjoint to ∃ and left adjoint to ∀, written ∃ -| ∆ -| ∀. Two natural transformations are

shown. η

is the unit of adjunction comparing objects C with objects C X

A and ε

cxa

is the counit of adjunction comparing objects C X

A with objects A. η

is an inverse

projection (π*) and ε

c x a

is a projection (π).

In terms of our CTCP/CTRP model given above:

The diagonal functor ∆ corresponds to the protocol CTCP whereby a limit C X

A is

selected for a particular purpose C/B through negotiation. CTCP selects a relationship

between C and A for a particular purpose such that the diagram in Figure 5

commutes, that is ι

o π

c x a

= ι

o ε

c x a

. As a Petri-Net CTCP can be represented as a

monoidal category [Asperti, Ferrari & Gorrieri, 1990]. CTCP is therefore a category-

valued functor. C X

A corresponds to the policy rules derived through the

negotiation in CTCP.

The existential functor ∃ is a type constraint: there must exist for all policy rules in C

A an entry in the system C/B.

The universal quantifier functor ∀ corresponds to the protocol CTRP: all the rules

held in the negotiated policy (the limit C X

A) are applied for a particular purpose

(C/B). Like CTCP, CTRP is a category-valued functor with its Petri-Net defined as a

monoidal category.

Overall CTCP is right-adjoint to ∃ and left-adjoint to CTRP. CTRP is right-adjoint to

CTCP.

Exceptions are much less likely to occur in the strongly typed categorical model than

in a set model. If they did occur they would be handled at the natural transformation

level. The unit of adjunction η

is given as 1

Æ CTRP o CTCP(c) and the counit of

adjunction as CTCP o CTRP(c x a) Æ 1

c x a

. The former measures the change in c as

165

the functors CTCP and CTRP are applied in turn. The latter measures the change in (c

x a) as the functors CTRP and CTCP are applied in turn. The unit and counit both

give a measure of consistency as the application is run with the possibility of

exceptions being raised if divergence is noted.

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 prospects for

formal approaches in the security area.

The idea of task-based has been introduced before in a number of models [Fischer-

Hübner & Ott, 1998; Steinke, 1997; Thomas & Sandhu, 1994]. All were at the basic

level of this approach. The focus by the last two (Steinke; Thomas & Sandhu) was on

whether a task-based security model could be an alternative authorisation and access

control model to the subject-object traditional authorisation models. The first paper

(Fischer-Hübner & Ott) tried to address the privacy problem using the task-based

approach. We have intended 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 [1997] 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 hierarchical systems, where the responsibilities are visible.

2. Thomas & Sandhu [1994] introduced the task-based approach initially as an

approach to address integrity issues in computerized information systems from an

enterprise perspective. Subsequently Thomas & Sandhu [1997] 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-Hübner & Ott [1998] 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.

166

· 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 & 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 & Ott model does not

include collaboration ventures.

4. Mahling, Coury & Croft [1990] 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.

Formalising security models is an important matter as this a way in which guarantees

can be secured about the reliability of a model. Security rules for multi-agency

systems need to be formulated at the policy level. At this level, category theory seems

to be appropriate as it provides not only appropriate abstractions for this level but

also, in a multi-level architecture, mappings to lower levels such as mechanisms. For

interoperability a multi-level approach constructed in category theory has already

proved very promising [Rossiter, Nelson & Heather, 2003]. The use of Petri-Nets, for

detailed state transitions, within a categorical framework, for control of types and

levels, looks to be a way forward for formalising security in information systems.

More advanced techniques such as Timed Petri-Nets and Stochastic Petri-Nets should

be useful in gaining greater expressibility. Validation techniques in Petri-Nets could

also be used for verifying the model. The benefits of using Petri-Nets will be highest

where collaboration occurs between multiple agencies. This is a natural area for

applying Petri Nets with its concurrency, asynchronicity, distribution, parallelism and

non-determinism.

9 CONCLUSIONS

This paper has introduced a task-based model to facilitate collaboration in trusted

multi-agency networks. Our model is based on the fundamental aspect of the

collaboration environment, which is the task-based perspective. Two task-based

collaboration protocols (CTCP and CTRP), expressed in this paper in the form of

Petri-Nets, are used to represent the permitted states and transitions. The extent to

which task-based approaches have been used before in security systems has also been

discussed.

The two protocols and the relationship between them are defined in Petri-Nets. The

overall model is formally defined using a categorical pullback construction. Each of

the protocols, represented as Petri-Nets for state-transition purposes, is a category-

167

valued functor in the pullback. The use of Petri-Nets within a categorical framework

looks to be a promising way forward for security problems.

REFERENCES

Aljareh, S., & Rossiter N., 2001, Toward security in multi-agency clinical information services,

Proceedings Workshop on Dependability in Healthcare Informatics, Edinburgh, 22nd-23rd

March 2001, 33-41.

Aljareh, S., & Rossiter, N., 2002, A Task-based Security Model to facilitate Collaboration in

Trusted Multi-agency Networks, ACM Symposium on Applied Computing (SAC) 2002,

Madrid, 744-749.

Anderson, R., 1996, A Security Policy Model for clinical Information Systems, Proc. IEEE

Symposium on Research in Security and Privacy, 30–43.

Asperti, A., Ferrari, G. L., & Gorrieri, R., 1990, Implicative formulae in the `Proofs as

Computations' analogy, Proc 17th ACM SIGPLAN-SIGACT Symp Principles

Programming Languages, 59-71.

Chu-Carroll, J., and Carberry, S., 2000, Conflict Resolution in Collaborative Planning

Dialogues, International Journal of Human-Computer Studies, 53(6) 969-1015.

Crazzolara, F., & G. Winskel, G., 2001, Petri-Nets in cryptographic protocols, Proc. 6th

International Workshop on Formal methods for Parallel Programming: Theory and

Practice, San Francisco

Fischer-Hübner, S., & Ott, A., 1998, From a Formal Privacy Model to its Implementation,

Proc. 21st National Information Systems Security Conference, Arlington, VA.

Furuta, R, & Stotts, P D, 1994, Interpreted collaboration protocols and their use in groupware

prototyping, Proceedings of the 1994 ACM conference on Computer supported cooperative

work, Chapel Hill, North Carolina, United States, 121 – 131.

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

Jensen, K., 1996, Colored Petri-Nets - Basic concepts, analysis methods and practical use,

Springer, second edition 1.

Joshi, J., & Ghafoor, A., 2000, A Petri-Net Based Multilevel Security Specification Model for

Multimedia Documents, ICME2000, IEEE International Conference on Multimedia and

Expo, MP10.12 533, Purdue University, USA.

Mac Lane, S, 1998, Categories for the Working Mathematician, 2nd ed, Springer-Verlag, New

York.

Mahling, D.E., Coury, B. G., & Croft, W. B., 1990, User Models in Cooperative Task-oriented

environment. Proc. 23

Annual Hawaii IEEE International Conference on System Science,

94-99.

Rasmussen, J. L., & Singh, M., 1996, Designing a Security System by Means of Coloured

Petri-Nets. Proc. 17th International Conference in Application and Theory of Petri-Nets

(ICATPN'96), Osaka, Japan, Lecture Notes in Computer Science, 1091 400-419.

Reisig, W., 1985, Petri-Nets: an Introduction. Berlin; New York: Springer-Verlag.

Reisig, W., & Rozenberg G., 1998, Lectures on Petri-Nets: Advances in Petri-Nets. Lecture

Notes in Computer Science, no. 1491.

Rossiter, N., Nelson, D. A., & Heather, M. A., 2003, Formalizing Types with Ultimate Closure

for Middleware Tools in Information Systems Engineering, 5th International Conference on

Enterprise Information Systems (ICEIS), Angers, France 366-373.

Ryan, P, 2003, Theoretical Challenges Raised by Information Security, Workshop on Issues in

Security and Petri-Nets (WISP), ICATPN.

168

Steinke, G., 1997, A Task-based Approach to Implementing Computer Security, Journal of

Computer Information Systems, 47-54.

Thomas, R. K., & Sandhu, R. S., 1994, Conceptual Foundation for a Model of Task-Based

Authorization, Proc. 7

IEEE Computer Security Foundations Workshop, Franconia, NH,

66-79.

Thomas, R. K., & Sandhu, R. S., 1997, Task-based Authorization Controls (TBAC): A Family

of Models for Active and Enterprise-oriented Authorization Management. Proc. IFIP

WG11.3 Workshop on Database Security, Lake Tahoe, California pp.

Van der Aalst, W. M. P., & Basten, D., 2001, Identifying Commonalities and differences in

Object Life Cycles using Behavioral Inheritance, Application and Theory of Petri-Nets

2001, 22

International Conference ICATPN, Newcastle, 32-52.

169