Viewing Business Process Security from Different Presepctives
In:
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: http://www.jstor.org/stable/27750897 . Accessed: 31/01/2015 04:15
Your use of the JSTOR archive indicates your acceptance of the Terms & Conditions of Use, available at . http://www.jstor.org/page/info/about/policies/terms.jsp
.
Viewing
Business-Process
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
is
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 111.68.106.99 on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions
90 GABYHERRMANN AND G?NTHER PERNUL
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
Framework
of Security and
Integrity
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 111.68.106.99 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
91
Purchase
Dispatch
Lloyd
White, Smith
White
final product specification to supplier (6)
delivery (7)
quality control (8)
legend: (^) exclusive-or data/material
^)
?
task be processed ?
, xyz
authenticity flow direction
|
confidentiality
?
legal binding by High
Figure 1. Business Process Level Security Semantics
"Order
Management"
Extended
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 111.68.106.99 on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions
92 GABYHERRMANN AND G?NTHER PERNUL
Description Layer Layer 3 of content
Representation
method
Graphical
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
forsecurity
repository of studies
Layer 2
Detailed
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.)
crypto-library,
Table
1 Three-Layered
Architecture
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 111.68.106.99 on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions
INTERNATIONALJOURNAL ELECTRONIC COMMERCE OF
93
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.
Modeling
Perspectives
Security Semantics of Business
of Business
Processes
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 111.68.106.99 on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions
94 GABYHERRMANN AND G?NTHER PERNUL
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 111.68.106.99 on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions
INTERNATIONALJOURNAL ELECTRONIC COMMERCE OF
95
informational
Figure 2. The Five Perspectives
on Business-Process
Representation
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.
Modeling
a Business
Process
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 111.68.106.99 on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions
96 GABYHERRMANN AND G?NTHER PERNUL
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 111.68.106.99 on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions
INTERNATIONAL JOURNAL ELECTRONIC COMMERCE OF
?? ?
97
public key of applicant verification algorithm certificate number of certificate begin, end of validity mmmm limitation details
certification authority
? ? ? ?
verification
digital signature supplier digital signature customer algorithm supplier verification algorithm customer
Figure 3.
Informational
Perspective
Extended
by Security
Semantics
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 111.68.106.99 on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions
98 GABYHERRMANN AND G?NTHER PERNUL
supplier
receive draft contract signed by supplier
Figure 4.
Functional
Perspective
Extended
by Security
Semantics
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 111.68.106.99 on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions
INTERNATIONAL JOURNAL ELECTRONIC COMMERCE OF
99
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
Relevant
certificate expires or is declared invalid
Figure 5.
Dynamic
Perspective
Extended
by Security
Semantics
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
Process
Perspectives
and to process the framework and
security requirements of business processes:
two concepts needed the architectural
This content downloaded from 111.68.106.99 on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions
100 GABYHERRMANN AND G?NTHER PERNUL
enterprise
dispatch department
purchase department
quality control department
archive department
signatory party
negotiation party
SIG-MGR set of authorizations
Figure 6. Organizational
Perspective
Extended
by Security
Semantics
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 111.68.106.99 on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions
INTERNATIONAL JOURNAL ELECTRONIC COMMERCE OF
101
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
Conclusion
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 111.68.106.99 on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions
202 GABYHERRMANN AND G?NTHER PERNUL
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 111.68.106.99 on Sat, 31 Jan 2015 04:15:03 AM All use subject to JSTOR Terms and Conditions
INTERNATIONALJOURNAL ELECTRONIC COMMERCE OF
103
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) (http://www.iid.de/ralmien/iukdg.htrnl#a3 [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. ispo.cec.be/eif/policy/Welcome.html#digital). 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 (pernul@wi-inf.uni-essen.de) 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
commerce,
database
in a European-funded databases and
security,
and
advanced
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.
interoperable
has
GABY
HERRMANN
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
(herrmann@wi-inf.uni-essen.de) From 1992 of Karlsruhe, Germany.
