Free Essay

Viewing Business Process Security from Different Presepctives

In: Business and Management

Submitted By assarhanif
Words 6003
Pages 25
Viewing Business-Process Security from Different Perspectives Author(s): Gaby Herrmann and Günther Pernul Source: International Journal of Electronic Commerce, Vol. 3, No. 3, Developing the Business Components of the Digital Economy (Spring, 1999), pp. 89-103 Published by: M.E. Sharpe, Inc. Stable URL: . Accessed: 31/01/2015 04:15
Your use of the JSTOR archive indicates your acceptance of the Terms & Conditions of Use, available at .




Security fromDifferent

Perspectives Gaby Herrmann and G?nther Pernul are crucial success factors inelectronic commerce. ABSTRACT: Security and integrity a framework that includes the securityand integrity This paper offers requirementsof business processes in businessprocess execution. An

themodeling and refinement securityand integrity of requirements. High-level security of requirements business processes are viewed fromfivedifferent perspectives. The tasks involved in the different perspectives are described, and the modeling of security re quirements isoutlined by focusingon the example of the legal binding of contracts. KEYWORDS binding, important

part of the framework


AND PHRASES: Business process, business-process reengineering, legal semantics. security

of markets in recent years, many enterprises Because of the globalization have located their offices and production sites all over theworld. They need to cooperate in order to conduct business. Because of distribution and open ness, special care must be devoted in such systems to the security and integ rityof corresponding business processes. To participate in electronic commerce and to optimize their business processes, many enterprises must reengineer their existing business processes, devoting special care to security and integ in this article sup rity requirements as they do so. The approach proposed in order to improve security and ports business-process reengineering integrity. In addition, it supports the reuse of already generated solutions on the technical domain level [3]. Following a common classification scheme, the reuse approach may be classified as domain-based. Business processes are usually described in business-process models that is represent reality at a high level of abstraction. A business-process model designed by a domain expert, and must, at the very least, contain the follow ing components: information about organizational units involved in process tasks ing the business process (e.g., departments, agents, roles, machinery), to be performed and their cooperation, informational units and their usage and structure, and a statement about the behavior of all of the objects in volved. The domain experts specifying business processes are usually not about such security specialists. At a very high level they have knowledge requirements as sensitivity, legal binding, high integrity, copyright, and the like, and will assign them to business-process components. To implement a business process, a more detailed analysis is necessary. a business process is not an isolated Usually activity within an enterprise, for there are interactions with databases, processing units, people involved, and so on. Typically, models already exist. Ifnot, new models must be devel (data oped. As an example of an already existing model, consider a database and a document that is processed within a business process. The model) business-process model mainly describes events, conditions, and the flow of the structuring of the documents between the parties involved. However,
InternationalJournalofElectronicCommerce / Spring 1999,Vol. 3,No. 3, pp. 89-103. Copyright ? 1999M.E. Sharpe, Inc.All rights reserved. 1086-4415/1999 $9.50 + 0.00.

This content downloaded from on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions


object "document" and its relationships to other objects are described in the data model of the database. The security requirements specified in business process models must be represented and analyzed in the other models. As an example, the requirement of legally binding the partners to a contract in a document processed in the business process) requires that (represented the data structure provide specific information fields representing the docu ment stored in the database. Thus, when a domain expert specifies security requirements in the business-process model, certain steps must be taken in it is proposed here that business pro the related models. As a consequence, cesses be viewed from different perspectives, each perspective relating to one aspect of the process. is models representing security semantics in business-process Although an important topic (e.g., see [11]), not much work on ithas been published. Inmost cases, a very narrow definition of security is used. The authors try to as used in operating sys and access-control methods adapt authorization tems and database systems to the special need of business-process manage ment (e.g., see [171).At least in the opinion of some authors, such models are to themanagement of business processes [7]. There only partially applicable several steps forward in the development have been of a security model for a Policy [1, 2, 4, 13]. Bu?ler has developed management business-process Resolution Model that emphasizes authorization and access controls [4]. Atluri et al. describe possible dependencies of tasks with different security levels and a method for executing themwithout compromising security [1]. Bertino et al. focus on the use of role-based authorization inworkflow management and Hung devote special concern to activity management [2]. Karlapalem tasks with possible agents based on role modeling [13].All these by matching works focus on specific areas of business-process and there has as security, yet been no general discussion of broader scope. A framework is necessary that implements all possible security require ments of business processes. In this paper, the high-level security require ments of business processes are viewed from five different perspectives. The example of legal binding of contracts is used to describe the tasks involved in the different perspectives and outline the modeling of security require ments. The example is viewed from all five perspectives. A framework for a business-process security infrastructure is also outlined.

Example and Specification


of Security and


A very high-level model of a business process ment will be used to illustrate different security in business processes (see Figure 1). The notation tion is simple and self-explanatory: The first row

responsible for the execution of tasks, and the left column represents the agents carrying out the tasks. First, companies that can act as possible sup pliers are determined. They are invited to submit offers (task 2). Offers must be valid for a specific period of time and must be authentic. If not, the deci

focusing on order manage and integrity requirements in the graphical representa represents the departments

This content downloaded from on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions

INTERNATIONAL JOURNAL ELECTRONIC COMMERCE OF departments] agents/roiei Department of quality control





White, Smith


final product specification to supplier (6)

delivery (7)

quality control (8)

legend: (^) exclusive-or data/material


task be processed ?

, xyz

authenticity flow direction




legal binding by High

Figure 1. Business Process Level Security Semantics




sion about whom to choose as supplier (task 3) will be based on uncertain information. In task 4, negotiations with the chosen supplier take place and lead either to completion of the contract (task 5) or to choosing another sup plier (task 3). Negotiations have several security requirements: First, the com munication partners must be authentic. Second, the negotiations should be confidential. A completed contract must be legally binding on both contract partners. The ordered goods, it is assumed, will be produced according to the specifications of the customer, and the final specifications must be given

This content downloaded from on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions


Description Layer Layer 3 of content



Supporting method
3.2 analyzing methodology of graphical concepts semantics 3.1 case and set

High-level specifica tions of security requirements of business processes


repository of studies

Layer 2


specifications of

Intermediate language

security requirements

Repository of informationon how basic building blocks can be determined from security requirements

1 Layer

Security hardware and security software building

Program, program modules, hardware blocks

Repository of hardware and blocks software building (elements are security APIs, security dongle, etc.)



1 Three-Layered


for Process

Security Specification.

to the supplier after the completion of the contract (task 6) at the latest. To if the specifications are leaked, secrecy is avoid competitive disadvantages After production the goods are delivered demanded. (task 7) and quality takes place The preceding illustrates the fol control (task 8). example lowing security requirements: authenticity, legal binding, and confiden tiality (secrecy). It is a longway from specifying requirements to final processing. The frame work shown in Table 1 is proposed for processing the specified requirements [9]. A domain expert analyzes and specifies the business processes of the a application domain, including security and integrity requirements, at high

level of abstraction. The framework supports analyzing, modeling, and imple mentation of the security requirements of the business process. It consists of a into two sublayers three-layered architecture. The top layer is divided 3.2 and sublayer 3.1). Layer 3.2 contains well-defined concepts used (sublayer to represent the security semantics of the real world and a method to analyze The domain expert may use these con them from different perspectives.

This content downloaded from on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions



cepts to express the security requirements of a business process (business process perspective). In a real-world application, domain experts modeling business processes are not necessarily security experts, and thus their understanding of security at a high level of abstraction. Additional requirements may be vague and work is necessary to transform the specified security requirements into an executable form. For this, detailed knowledge of security concepts is needed and a security administrator must be consulted. Therefore, sublayer 3.1 con tains a repository with reusable case studies for handling security require ments. These case studies look at security requirements inmore detail and offer possible ways to implement them. The security administrator takes the as input, and high-level security specifications of the business-process model more detailed representations by using a repository transforms them into located at sublayer 3.1. This transformation refines the security requirements to the level of the basic security elements used to implement the security a requirements (e.g., verify the digital signature of supposed signatory). Layer 2 of the architecture contains guidelines (expressed in an intermediate lan guage) for dividing basic security elements into basic building blocks. Layer 1 of the architecture offers a repository of hardware and software compo nents that are needed to implement the building blocks. If a workflow-man agement system executing a business process does not support the security se requirements, an application programmer is responsible for developing at layer 2 and the software curity software. In this case, the specifications components at layer 1may be helpful and supportive. If the development of corresponding security software is not possible, the security requirements of the business process must be reduced or the business process will not be executable. In the remainder of this paper the focus ismainly on layer 3 and sublayer 3.2.


Security Semantics of Business

of Business


Processes is described by a process model containing characteristics relevant to the purpose of the [6], a combination of the following perspec consistent, and complete view of a business

In general, a business process information about the process to business target. According tives produces an integrated, process: informational perspective represents the information entities, their structuring, and the relationships between them. A common the information perspec for analyzing and modeling methodology The tive is the Entity-Relationship approach [51. The functional perspective shows what activities (processes) are occurs between activities. The performed and which data flow functional perspective represents only the flow of data within the [8]. system. Itmay be modeled by using data flow diagrams

This content downloaded from on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions


The dynamic perspective represents all possible states for each information entity, and states transitions thatmay occur within the life cycle of the information entity.Although there are many different techniques available, a very common technique is to use state-transition diagrams [16]. The organizational perspective shows where and by whom activities are performed. This perspective corresponds to the organigram of an organization and to role models. Since each perspective focuses on a very specific aspect of a business pro cess, some knowledge ofmodeling techniques is necessary in order to specify the perspectives. Usually, the expert in the business do and to understand main who is specifying the business process finds itdifficult to see the rela tionships between the business process and other models already existing in the organization. To analyze security requirements, it is very important to develop an integrated view of all aspects of a business process. In addition to the four perspectives mentioned, the framework presented supports a fifthperspective, which is here called the business process perspective. The business-process perspective represents the flow of work in terms of activities and information flow from the viewpoint of the entire business process. It consists of an integration of the functional and dynamic perspectives, and references the informational and Itmay be modeled organizational perspectives. by using a method similar to that given in Figure 1. Figure 2 is a graphical representation of the relationships among the five perspectives. The informational perspective, functional perspective, dynamic perspective represent detailed aspects of a perspective, and organizational business process, while the business-process represents an ab perspective contains models stract and integrated view of it. Each of the perspectives that support different levels of abstraction. A description of a business pro at cess from the business-process refers to elements of models perspective either already exist in the organization or other perspectives. These models must be developed. For example, if organizational units in a business pro cess are already described in an existing organigram, theymay be referenced in the business process. Otherwise, the organigram must be extended in or der to develop a consistent view of the business process. Examples of busi ness-process perspectives are given in Figures 3 through 6. They are related

"order manage to the task "completion of the contract" of business-process as given in Figure 1. ment," In general, any requirement on a business process is represented from For example, the require different perspectives with varying consequences. ment of "time dependency" of task execution strongly influences functional and dynamic perspectives, but influences the organizational perspective less, and does not influence the informational perspective at all. This is in con trast to requirements referring to security and integrity of business processes.

This content downloaded from on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions




Figure 2. The Five Perspectives

on Business-Process


These are more complex because of a busi they influence all perspectives ness process at the same level of importance. The five perspectives will again be referred to below when the security requirement "legal binding of a contract" is analyzed from all perspectives and it is shown how the perspectives fit into the framework.


a Business


Every business process is integrated into the totality of activities of the enter prise. Before a new business process is initiated, the enterprise and other business processes generally already exist, and at least parts of them are struc Therefore, models may exist of the organizational already modeled. ture of the enterprise (organizational perspective), of the structure of a data base (informational perspective), of already existing activities (processes) and the data flow between them (functional perspective), and of the life cycles of the information entities (dynamic perspective). The model of a new busi ness process must relate to these existing models and must extend them appropriately. A domain expert specifies the business-process perspective, including the and integrity requirements. Afterward, the person in charge of de security a data model will examine it, and, if necessary, veloping and maintaining extend itwith whatever new information entities are necessary to support

the examined business process. If the data model already contains the infor mation entities, their life cycles may be examined (dynamic perspective). A functional perspective, programming expert will specify the corresponding and someone familiar with the structure of the enterprise will modify the

organizational perspective, ifnecessary. To implement the specified security a security administrator is requirements (see business-process perspective), and the perspectives may have to be modified involved, according to the

This content downloaded from on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions


statements of the security administrator in coordination with the experts for the other perspectives. The following subsection gives an responsible example. Modeling

of Contract Completion

Including Legal Binding

legally binding if the agreement between the contract partners is provable. A common method of provability is the use of signatures. If the contract is a traditional document (on paper), a way to implement its legally binding char acter is to have it signed by the contract partners. The example to be dis cussed pertains to a situation inwhich an electronic document is to be signed. law on communications The example is based on the German [12] and the set of corresponding regulations pertaining to digital signatures [18]. In gen eral, the following is required tomake a digital signature legally binding: A digital signature is a seal based on the signed data. The seal is implemented with asymmetric cryptography, created by using the private key of the sig natory. The correctness of signed data and the identity of the signatory can be ascertained by using his/her public key, which must be certified by a certification authority. Each certificate is assigned a period of validity. What cryptographic algorithms and certification infrastructure should be used is in the example the digital signa left open to the involved parties. Although tures are analyzed based on German law [12,18], regulations in other coun tries will be similar. The European Union's proposed European Parliament and Council Directive on a common framework for electronic signatures [14] for the regulations in Germany. may have consequences In order to study the effects of a digital signature, it is necessary to first of the business process. To verify a refer to the informational perspective on a document, the seal of each signatory and the corre digital signature are necessary. Therefore, the informational perspective sponding certificates of the business process must be extended by information about the signato ries, the certificates used, and the (trusted) parties responsible for issuing the certificates. Figure 3 extends a customer-supplier relationship by appropri ate data structures. These are of a new relationship type CERTIFICATE, and a contract. The represent modification of relationship type representing the a document that should be signed, and the agreed fact is represented by customer and supplier must be extended by one relationship type between field for the seal (digital signature) of each signatory and by information about the algorithm used for signing. In addition, customer and supplier are a a certificate relat specializations of generic-type applicant thatmust have a certification ing the applicant to authority.

"order management" and out This subsection focuses on business-process contract completion and the security re lines the different perspectives of quirement of "legal binding" on the contract partners. The components of existing models or attributes not affected by security requirements are shown in the example using ordinary type. The attributes with relevance to legal are given in boldface. binding To guarantee legal binding of a contract, different regulations are required in accordance with the corresponding law. Inmany countries, a document is

This content downloaded from on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions

?? ?


public key of applicant verification algorithm certificate number of certificate begin, end of validity mmmm limitation details

certification authority

? ? ? ?


digital signature supplier digital signature customer algorithm supplier verification algorithm customer

Figure 3.




by Security


of invalidity of the certificate. That is expiration/declaration why the certificate's users must have the ability to re-sign the corresponding docu ments before the certificate of the former digital signature expires or is de clared invalid. In case of re-signing, the new digital signature must refer to the former document, the former digital signature, and a timestamp. The to re-sign documents has effects on other processes in the enter necessity prises (e.g., archiving process). Introducing legal binding into the business process also affects the organi zational perspective. To check the validity of digital signatures and initiate

For a contract to be processed, an information flow takes place. This is represented in the functional perspective of the business process. To guaran tee that the contract is legally binding, the functional perspective of the busi ness process must be modified, as shown in Figure 4. The process works as follows: The document must be signed digitally by each contract partner, and the signatures must be verified. Because a certificate of a public key may have expired (by time elapsed or by declaration of invalidity), additional actions are necessary to guarantee the provability of digital signed contracts. These actions lead, for example, to extensions of the functional perspective of a process responsible for archiving. Again, in Figure 5 extensions due to security requirements are given in boldface. As with the functional perspec tive, the legal binding of a contract affects the dynamic perspective. Figure 5 shows the life cycle of entity type CONTRACT in terms of its different states. The state ''Valid" is necessary to handle the expiration or declaration of va a lidity of certificate. In order to guarantee that the signature remains prov a certification able, authority must inform the users of a certificate about

This content downloaded from on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions



receive draft contract signed by supplier

Figure 4.




by Security


is necessary, and this leads to further actions, a new role in the organization an extension of the organizational perspective. The additional role may be if the certifi called SIG-MGR and is responsible for re-signing documents roles may cates are no longer valid and for verifying signatures. Additional The role SIG-MGR may need the follow for key management. be necessary access to relevant certificates, the right to re-sign con ing authorizations: certificate of the enterprise is expired or tracts when the corresponding and the right to ask a contract partner to re-sign a contract declared invalid, if the contract partner's relevant certificate is expired or declared invalid. PARTY may also exist in organizations The role SIGNATORY signing con

tracts in the traditional way, but needs to be extended by a new right to access relevant certificates, as shown in Figure 6. The semantics of digital signatures are not always clear. In some cases, a signatory party may demand that the contract partner sign the correspond a specific period of time. There are several possible ing document within reasons for this requirement. For example, if signatory party A has signed

This content downloaded from on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions



First contract partner signs Draft 1 Draft V

First signature is proved as valid Draft 2

Second contract partner signs

Second signature is proved as valid Valid

Draft 2'

First signature is ^proved as invalid

Second signature is ' proved as invalid

Contract r is I?~~l \ fulfilled

state Draft! Draft I' Draft2 Draft!' Valid Valid' Fulfilled Expired

meaning no contract partner has signed yet one contract partner has signed signature is valid all contract partners have signed legal binding is provable relevant certificate is expired contract is fulfilled contract is expired but not fulfilled


certificate expires or is declared invalid

Figure 5.




by Security


and gives the document to contract partner B (which has no time restriction for the signing process), B will be able to delay the signing process and look whereas A is already bound by his/her signature. for a more favorable offer, These time restrictions may be a variation of the semantic meaning of a digi tal signature, and must be expressed in the business-process model. in the business-process model has different ef Each semantic meaning fects in the other perspectives. The given example showed that the consider ations of legal binding on a contract influence all aspects of the business extensions to existing models may seem quite com process. The proposed in security. However, to readers unversed the outlined extensions are plex identical formaking documents legally binding in any business process re

quiring this functionality in identical legal environments. Therefore, these extensions may be reused. In such cases, only modifications for considering or agents are necessary. The reusable components different departments should be included in the repository of layer 3 of the three-layered architec ture outlined earlier so as to be available for the security administrator. The relationship between the perspectives and the architectural framework will be discussed below.

Relationship Architecture The preceding

Between discussion

Business introduced



and to process the framework and

security requirements of business processes:

two concepts needed the architectural

This content downloaded from on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions



dispatch department

purchase department

quality control department

archive department

signatory party

negotiation party

SIG-MGR set of authorizations

Figure 6. Organizational



by Security


Figure 7.

Part of the Repository

at Layer 3

the five perspectives. The example of completing a legally binding contract will now be used to show the relationship between these two components. Processing security requirements starts at the highest level and isperformed

architecture contains well-defined concepts thatmay be used to represent the security semantics of the real world. The next step is to analyze the business process from different points of view to derive its security requirements.

a Gayer3) of the by a domain expertspecifying businessprocess.The top layer

This content downloaded from on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions



their security requirements, the business-process model is passed to the workflow engine and processed. If theworkflow environment is not able to handle the security requirements, the security of the system must be im proved. This situation is covered by layers 2 and 1 of the proposed architec ture, and the high-level specifications from layer 3 are transformed at layer 2 into a more formal representation (in an intermediate language). This inter mediate language is also used to describe the functionality of the software and hardware security modules located at layer 1 of the architecture. As the same is used to specify the requirements and describe the func language tionality of code, this technique can locate relevant code already used for security in the software library located at layer 1. The use of this technique reduces the effortneeded to implement themissing security elements of the workflow-management system.

The process continues by focusing on the assigned security requirements. To process them, a tool that checks the syntactic and semantic correctness of to business-process the assigned elements will be security enhancements With respect to the example, assigning legal binding to an object necessary. of type contract is syntactically and semantically correct. The next step is more performed by a security administrator, who handles the requirements in detail. The administrator may look at the repository located at layer 3.1 of the framework, which offers reusable components to implement security re quirements. If matching components are not available, the different perspec must be examined and corresponding models must be changed as tives appropriate. The security-relevant extensions are stored in the repository. If an of the models is not possible, then the security adequate modification requirements are not satisfied during the execution of the business process. In the example, assume that reusable submodels are available for legal bind ing of an electronic contract. Figure 7 shows the relevant part of the reposi tory. It contains the elements introduced earlier. So far, there has been no examination of how to describe the information stored in the repository at layer 3.1, or how to retrieve relevant information are expressed from it.At this point, the different perspectives by means of notation used and natural language. An identifier is used to retrieve re the usable components. The language ALMOST (A Language for Secure Modeling Business Transactions) has been developed to describe the information on layer 2 [15]. It is used to bridge the gap between basic security elements and the software and hardware modules (layer 1) used for their implementation. At this step in the processing of security requirements, it is necessary to two situations: If the run-time environment of the distinguish between is able to process all necessary activities and system workflow-management

The ideas presented in this paper are part of a larger project whose goal is to a security infrastructure for business processes and, develop subsequently, forworkflow management. The types of security requirements necessary for such an infrastructure have been identified (see [10]), and the building blocks

This content downloaded from on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions


to implement themmust be constructed. Business processes and their and the ef security semantics have been looked at from five perspectives, of security constraints on the different perspectives have been studied. fects The main focus was on the security constraint "legal binding," and the build were identified. ing blocks needed to realize this requirement Future work in several directions will be necessary. First, the implementa tion of the building blocks (model extractions for reuse) for each identified The building blocks must type of security requirement must be developed. on different levels of abstraction. On the highest level, theymust be modeled be understandable by those who are not security experts (domain experts), on the most detailed level, no additional information about security while to realize the security requirements should be necessary (application level). Second, combinations of security requirements must programmer's be examined, such as legal binding or anonymity of signatories. Such re are necessary, for example, for anonymously trading digitally quirements must be developed for represented rights. Third, navigation mechanisms to view a single security re in and among the five perspectives navigating quirement from the different perspectives. needed

REFERENCES for 1.Atluri, V; Huang, W.-K.; and Bertino, E. An execution model secure workflows. In Proceedings of IFIP 11.3 Workshop on multilevel Database Security, 1997. 2. Bertino, E.; Ferrari, E.; and Alturi, V. A flexible model supporting the inworkflow and enforcement of role-based authorizations specification In Proceedings of the Second Association for Computing systems. management Machinery Workshop on Role-based Access Control, 1997. 3. Bongard, B.; Groniquist, B.; and Ribot, D. Impact of reuse on organiza tions. In Proceedings of Reuse'93, 1993. 4. Bu?ler, Ch. Access control inworkflow management systems. In

1995, pp. Proceedings of IT Security'94. Vienna, Munich: Oldenbourg-Verlag, 165-179. 5. Chen, P. P. The entity relationship model: Towards a unified view of data. Association for Computing Machinery Transactions on Database Systems 1, 1 (1976), 9-36. and Over, J.Process modeling. Communication of 6. Curtis, B.; Kellner, M; theAssociation for Computing Machinery, 35, 9 (1992), 75-90. 7. Ellmer, E.; Pernul, G.; Quirchmayr, G.; and Tjoa, A.M. Access controls in cooperative workflow environments. Association for Computing Machin ery SIGOIS Bulletin, 15, 2 (1994), 24-27. and Sarson, T. Structured System Analysis: Tools and Tech niques. Englewood Cliffs, NJ: Prentice-Hall, 1979. 9. Herrmann, G., and Pernul, G. A general framework for security and In Proceedings of theTenth integrity in interorganisational workflows. International Bled Electronic Commerce Conference. Bled: Moderna organi 8. Gane, CP, zacija, 1997, pp. 300-315.

This content downloaded from on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions



G., and Pernul, G. Towards security semantics inworkflow In Proceedings of theHawaii International Conference on management. vol. 7. Los Alamitos, CA: IEEE Computer System Sciences, Society, 1998, pp. 766-767. 11.Hudoklin, A., and Stadler, A. Security and privacy of electronic com merce. Proceedings of theTenth International Bled Electronic Commerce Confer ence. Bled: Moderna 1997, pp. 523-535. organizacija, 12. Informations-und Kommunikationsdienste-Gesetz (IuKDG) (version of 7/ 13/1997) ( [inGerman]). 13. Karlapalem, K., and Hung, P. Security enforcement in activity manage on ment systems. In Proceedings ofNATO-ASI Workflow Systems and Inter

10. Herrmann,

Springer Verlag, 1998, pp. 165-194. operability. Berlin, Heidelberg: 14. Proposal for a European Parliament and Council directive on a com mon framework for electronic signatures (version 5/13/1998) (http:// www. 15. R?hm, A.; Herrmann, G.; and Pernul, G. Modelling Secure Electronic Business Transactions inALMO$T. University of Essen, 1998. 16. Rumbaugh, J.,et al. Object-Oriented Modeling and Design. Englewood Cliffs, NJ: Prentice-Hall, 1991. 17. Shen, H., and Dewan, P. Access control for collaborative environments. Proceedings ofCSCW'92. ACM Press, 1992. 18. Signaturverordnung (SigV) (version of 10/8/1997) (http://www. iid. de/rahmen/sigv.html [in German]). PERNUL ( is a professor in theDepartment G?NTHER of Information Systems at theUniversity of Essen, Germany. Before that,he taught in theDepartment ofApplied Computer Sciences at theUniversity of Vienna, Austria. He has held visiting positions at theDatabase Systems Research and Development Center at theUniversity of Florida as well as at the College of Computing at the Georgia Institute of Technology. He received an M.A. degree from theUniversity of Vienna in 1985 and his Ph.D. degree with honors from theUniversity of Vienna in
1989. His research interests the are electronic of

database research applications. Pernul has participated project on security



in a European-funded databases and




ESPRIT frequently III

published in scientific journals and conference proceedings on aspects of information He is amember of the Association for systems security. Computing Machinery (ACM), the Association of InformationSystems (AIS), the IEEE Computer Society, theGerman Gesellschaft f?r Informatik (Gl), theAustrian Computer Society (OCG), and the IFIP WG 11.3 (Database Security), and an observer of the IFIP WG 11.8 (SecurityEducation). He also serves on the steeringboard of theCommunications and Multimedia Security conference series.





research interests sity. Her main and modeling of security eling,

in theDepartment of Communication Systems at theUniversity of Essen, and since 1995 she has been with theDepartment of Information Systems at the same univer are workflow semantics. management, business process mod

the University

( From 1992 of Karlsruhe, Germany.

studied to 1995 she was

at science computer a research assistant

Similar Documents