Towards an integration of Security Requirements into

Business Process Modeling

Alfonso Rodríguez

, Eduardo Fernández-Medina

, Mario Piattini

Universidad del Bio Bio, Departamento de Auditoría e Informática,

La Castilla S/N, Chillán Chile.

Universidad Castilla-La Mancha, Departamento de Informática,

Paseo de la Universidad 4, Ciudad Real, España.

Abstract: Bus

iness Processes are considered as an essential resource for

companies to optimize and assure their quality by obtaining advantages with

respect to their competitors. Consequently, Business Process Modeling

becomes relevant since it allows us to represent the essence of the business.

A notation to model businesses must be able to capture the majority of the

requirements of the business. We have had the opportunity to check that

security requirements have been scarcely considered in nowadays’ most used

notations to model business processes. In this work, we will present the

security aspects that can be modelled from the business experts’ dominion

and that have been scarcely studied in the business process modeling, a

review of the main notations used for modeling and a proposal to represent

security requirements considering the knowledge of the experts in the

business.

1 Introduction

Business Processes, considered as a set of procedures or activities which collectively

realise a business objective or policy goal [30], form the essence of contemporary

organizations’ competitiveness. Each phase of the construction of business processes

becomes, therefore, especially relevant. Among these phases, the requirements

specification, considered as a process that effectively facilitates the necessary

communication between the different parts involved in the process [20], allows us to

rather ensure that the business process will be useful and functional for the objectives

of the organizations.

However, the notion of security is often neglected in business process models,

witch usually concentrate on modeling the process in a way that functional

correctness can be show [3]. This is due to the fact that the expert in the business

process dominion is not a specialist in security [14]. Furthermore, the requirements

engineers are not trained at all in security and the that have been trained have only

been given an overview of security architectural mechanisms such as password and

encryption instead of the actual

security requirements [10]. Nevertheless, many

security aspects can be modelled from the user or the business analyst view since

studies show that it is common that end users are able to express their security needs

Rodríguez A., Fernández-Medina E. and Piattini M. (2005).

Towards an integration of Security Requirements into Business Process Modeling.

In Proceedings of the 3rd International Workshop on Security in Information Systems, pages 287-297

DOI: 10.5220/0002579402870297

 SciTePress

at this level [18]. Consequently, during the modeling phase, the process owners

should face the security requirements as well [23].

Our proposal will allow business analysts to early specify security requirements

without having to deeply study implementation and/or architecture aspects. We think

that an appropriate notation will facilitate this task; hence, we have extended the

notation proposed by the Business Process Management Initiative (BPMI) by

incorporating into it some security aspects that are comprehensible and adequate.

The paper is organized as follows: in section 2, we will present the business

process security model considering the main notations used in the industry. In section

3, we will show the extension we propose for being able to represent security

requirements from the business analyst perspective and finally, in section 4 we will

present an example to appreciate the application of our proposal.

2 Business Process Security Model

In spite of the importance of security within business processes, business process

security modeling presents two main problems. On the one hand, the modeling itself

has been considered inadequate since those who specify security requirements are

requirements engineers that, accidentally, have tended to replace them by specific

restrictions of architecture [10]. On the other hand, security has been integrated very

late, often during the actual implementation of the process [3] or even later, during the

system administration phase. This can be partly explained by the fact that although

security is a transversal aspect that early affects the components of an application, it is

not properly understood and besides there is a lack of tools that support security

engineering [17].

However, it is more or less obvious that an approach oriented to the process

should also take into consideration security information in the business process

management [1]. In this sense, to model security within a business process will imply

to capture security requirements. This should be performed considering the following

perspectives: Static, about the processed information security, Functional, from the

viewpoint of the system processes, Dynamic, about the security requirements from the

life cycle of the objects involved in the business process, Organizational, used to

relate responsibilities to acting parties within the business process and the Business

Processes perspective, that provides us an integrated view of all perspectives with a

high degree of abstraction [14].

On the other hand, although the functional requirements of security tend to vary

between applications of different types, it cannot be said the same thing about security

requirements since any application at a high level of abstraction will have the same

class of valuation and potentially the same vulnerability of its assets [11]. That is the

reason why the most appropriate security requirements to be represented are those

that are of the same type for all organizations since at this level we are not thinking

about implementation. In addition, it is clear that the early identification of

requirements, in this case, security requirements will allow us to save development

and maintenance costs, so, it is obvious that it will be very useful to have a notation in

which it is possible to specify security requirements.

288

Our proposal is based on two fundamental points. On the one hand, it is necessary

to establish what notation will be used and on the other hand, it will be necessary to

decide about the security requirements that will be considered.

2.1 Notations for Business Process Modeling

In business process modeling, the main objective is to produce a description of reality,

for example, the way in which a commercial transaction is carried out to understand

and eventually modify it with the aim of incorporating improvements into it. As a

consequence, it is important to have a notation that allows us to model the essence of

the business as clearly as possible. This notation must allow us to incorporate

different perspectives giving place to different diagrams in which rules, goals,

objectives of the business and not only relationships but also interactions are shown

[8]. A great part of the success of the modeling has to do with the ability to express

the different needs of the business as well as to have a notation in which these needs

can be described. This is why when choosing an approach and/or notation, the

properties of the object to be modelled must be taken into account, in other words, the

business process, the environment features and the underlying reasons for the use [5].

Among the techniques that have been used for business process modeling are the

following ones: flow diagrams, the family of techniques known as IDEF (Integration

Definition for Function Modeling), Petri Nets, simulation, techniques based on

knowledge (artificial intelligence) and Role Activity Diagrams [13].

At present, and according to the state of the business process modeling industry

[19], it is possible to identify the Unified Modeling Language (UML) [21] and the

Business Process Modeling Notation (BPMN) [7], among the main standards, thus,

we will focus our analysis on both of them.

The use of UML is very spread in relation to business process modeling[8, 16-18,

27], since it is a consolidated language, easy to learn and it allows a fluent

communication between the different actors about the model. However, UML has

three problems that can undermine the business process modeling [12]; since (i) as

UML has not been designed to model business processes, it may occur that some

modeling aspects are not appropriately dealt with or are studied with a different

orientation from the one needed by an expert in the business domain. On the other

hand, (ii) UML takes it for granted an approach oriented to objects in the business

process conception in which business objects should have been defined earlier, thus

limiting the view of the process oriented to the business in which first of all, control

and message flows are identified and then business modeling objects are implicitly

defined. Finally, (iii) UML is usually more oriented to system architects and software

designers due to the fact that it has been developed to facilitate the creation of

software thinking of a mainly technique audience.

Regarding BPMN, it is a new proposal whose notation considers a unique diagram

for the representation of processes, Business Process Diagram (BPD). This diagram

was designed to facilitate its use and understanding and to offer an expressive force

that allows us to model complex businesses by assigning them in a natural way to

execution languages such as BPEL4WS (Business Process Execution Language For

Web Services). To do so, the notation is supported by a modeling language, Business

289

Process Modeling Language (BPML) and a query language, Business Process Query

Language (BPQL) [22].

In this paper, we will use BPMN because we consider that, although there are

several reasons to use this notation [22], the most important one is that it offers us a

modeling technique that is quickly understood by all users of the business, from

business analysts that make drafts of the processes to technical developers that are

responsible for the technological implementation of those processes and finally

business people that will manage and control those processes. Moreover, it creates a

standardization that connects design with implementation of business processes [7,

31].

2.2 Security requirements in the business process modeling

To model security requirements within business processes, we have to pay attention to

two aspects that we think that are important. First of all, we do not have to forget that

the individual who models the process is an expert in the business dominion and

therefore, he/she has an idea of security without any kind of technical expression and

perturbations that somebody who is thinking in the implementation or in

technological solutions will have. Secondly, and for the same reason, we have to

consider the part of security that is most agreed by non specialist users and whose

meaning and representation is more or less standard.

The works related to security specifications developed by experts in the business

dominion are: (i) scarce [3, 14, 18], (ii) oriented to security in the transaction [25] or

(iii) are directly focused on information systems in general [28]. Therefore, and taking

into consideration that business processes have a close relationship with workflow

[24, 29], we have paid special attention to security and workflow works, [2, 6] and

workflow management systems works (WfMS) [15]. We have realized that most of

these works emphasize access control, defining it as identification, authentication and

authorization according to the conditions specified in the taxonomy of factors and

subfactors of security quality [11] through the use of access based on roles, RBAC [4,

6, 9, 26].

Consequently, and taking into account the fact that security requirements must be

easy to assimilate by business analysts and have, at the same time, a clear meaning for

security experts, we have considered the following ones: (i) access control, which

must be considered as the degree to which the system limits access to its resources

only to its authorized externals

, (ii) security auditing, which is the degree to which

the security personnel will collect, analyze and inform about the state and use of the

security mechanisms and (iii) privacy which is the degree to which unauthorized parts

are avoided from obtaining sensitive information

[10, 11].

For example; human users, programs, processes, devices or other systems

For example; identity of users, data or private communications

290

3 BPMN Extension for security modeling

To capture security requirements within the business process modeling, it is useful to

have a notation that must be supported by a set of graphical concepts that allows us to

represent the security semantics [14]. As we have previously indicated, BPMN offers

us an orientation to the business analyst domain since it represents an opportunity to

capture security requirements at a level of abstraction that, in our opinion has not been

considered enough. BPMN does not explicitly consider mechanisms to represent these

requirements. However, among the set of symbols used for the construction of the

BPD [7], Artifacts can be used to express such requirements. Artifacts were designed

to extend the modeling basic notation by adding them the possibility of representing

specific situations [31]. They are composed of Data Objects that allow us to show the

data required or produced by the activities, Groups that allow us to put together

several activities in order to make analysis easier or improve documentation and Text

Annotations that allow us to provide additional information for BPD reading. In spite

of the fact that artifacts can be used to express security requirements, we consider that

an explicit identification of them will facilitate modeling and will help us to obtain a

better interpretation by security specialists.

The mechanism of extension stated by BPMN lets us add marks or indications to the

already defined graphical elements [7]. In our proposal (see Figure 1), we have

associated a symbol to represent each security requirement in a relatively standard

way.

The representation of these security requirements within a business process performed

by business experts will be understood as the need to incorporate (through the systems

development process) the mechanisms and the technology that allow us to satisfy the

intention of access control, security audit and privacy that has been specified.

Access

Control

Security

Auditing

Privacy

Fig. 1: Notation associated with security requirements

The BPD elements about which we propose to consider the security requirements

representation are shown in Table 1. The highlighted rectangle that we have

incorporated into the BPD notation indicates the place in which the security

requirement must be specified.

291

Table 1. BPD elements incorporating security requirements.

Element Notation

Pool: It represents an actor or a role within a business process.

Graphically, it is an interval containing other BPD elements such

as an Activity

Lane: It corresponds to subdivisions of a Pool that are

extended throughout this Pool in a horizontal or vertical way.

Lane is used to organize and categorize Activities.

Activity: It is the generic term used to identify the work

performed by a company. This category includes processes,

subprocesses and tasks.

Message Flow: It corresponds to the information transferred

during a business process between two Pools that are able to

send or receive messages. A Message Flow can be

represented between two activities as long as they are located

in two different Participants.

Data Object: It provides information

about what the process performs. Data

objects can be represented as

documents, data and other objects that

are used and updated by the process.

Generally, they are shown associated to

Activities or Sequence Flows.

Artifact: It is used

to provide additional

information about a

business process and

it has not influence

in the sequence or

flow of this business

process.

Group: It is a visual mechanism that

joins elements of a business process. Its

main purpose is to highlight certain

sections of the diagram with the aim of

documentation and/or analysis.

Now, we are going to describe the relationship between each one of the BPD elements

(see Table 1) and the requirements of access control, security audit and privacy.

− Pool/ Lane: These elements will be described together since both of them specify

roles. As Pool and Lane include other BPD elements in which security

requirements can be also indicated, it is necessary to verify the coherence existing

between the specifications performed in Pool or Lane and the elements they

contain

− Access Control: It indicates that, for this particular business process, the

activities associated to Pool or Lane are more sensitive. Hence, it is necessary

to intensify access control mechanisms. Such specification must be

292

complemented with Text Annotation to indicate the required security degree

(high, medium, low)

− Security Auditing: It indicates that all events related to Pool or Lane will be

registered for a further analysis in relation to security auditing. If Text

Annotation is used, the security auditing will be limited only to the events

there indicated.

− Privacy: This security requirement indicates the need to avoid that

unauthorized parts obtain sensitive information (for example the identity of

Pool or Lane). It is necessary to add information through the Text Annotation

in which the desired degree of protection of privacy will be specified (high,

medium, low).

− Activity: When any security requirement is specified for this BPD element, we

have to pay attention to the security specifications of the elements that contain this

Activity. (Pools, Lanes, Groups or other Activities). At the same time, we have to

pay special attention to the specifications existing between the elements that an

Activity contains (other Activities or Data Objects). Our purpose here is to

maintain coherence within the security requirements specifications.

− Access Control: It indicates that access to the execution of the activity must be

limited. This security requirement is valid only if the Pool or the Lane that

contain the Activity have not access control specification. The access control

specification must be complemented with Text Annotations in which the

required security level is specified (high, medium, low).

− Security Auditing: It indicates that it is required to register the events taking

place in the Activity. If Text Annotation artifact is used to indicate the events

about which the security auditing will be performed, we will understand that

the security auditing is limited only to those events that have been indicated

− Privacy: This security requirement will not be represented in an Activity since

we do not think it is very concrete in relation to the abstraction level in which

these specifications are being carried out.

− Message Flow: The security requirements that are specified for this element are

related to the content, origin, and destination of the Message Flow.

− Access Control: The indication of this security requirement must be interpreted

as the need to protect the Message Flow. This implies that Pools must be

validated when the message flow is sent and received. It must be

complemented with Text Annotation to indicate the required security degree

(high, medium, low).

− Security Auditing: The indication of this security requirement implies that we

are aimed at registering all events related to Message Flow sending and

reception.

− Privacy: It establishes the need to protect the identity of participants and the

confidentiality of the Message Flow content. It must be complemented with

Text Annotation to specify the required degree of protection (high, medium

,low)

Required security abstract levels that represent the higher or lower criticality noticed by the

business analyst regarding access control or privacy depending on each particular case.

293

− Data Object: The security requirements for this element are related to the content

of the Data Object.

− Access Control: This security requirement is not directly specified on Data

Object. Access Control can be extended from the specification performed in

the Pool or Lane containing it through the activities that send or receive it.

− Security Auditing: The indication of this security requirement implies that all

events related to the sending or reception of the Data Object must be

registered.

− Privacy: It establishes the need to maintain the confidentiality of the Message

Flow content. It must be complemented with Text Annotation to specify the

required degree of protection (high, medium, low).

− Group: According to its definition, a Group can include any of the BPD elements

described in Table 1. For this reason, the indication of security requirements

performed on Group will spread to all elements involved by it. In such a case, we

must consider the particular specifications of each element that it groups in order

not to produce either inconsistencies or contradictions.

4 Case study using the proposal of extended BPMN

In Figure 2, it is shown an example of a BPD that has been specified using BPMN.

This example describes a process of acceptance, review and preparation for the

publication of papers prepared by the students of the Audit and Computer Science

Department, of the Faculty of Business Science at the Bio Bio University. With these

papers, every year it is edited a journal containing the best papers that have been

prepared in that year. In this business process, it is described the way to carry out the

process in an electronic way incorporating the security requirements into it by using

the proposed extension.

The business analyst describes a process that is basically carried out by three

Pools: The first one is Student, who prepares papers to be sent to the journal and

eventually corrects the papers if it has been accepted. The second one is Editor who

prepares the papers that will be sent to be reviewed, removes authors’ information and

add a guide line for evaluation, orders papers according to the obtained qualification,

eventually sends papers that have been accepted to be corrected and prepares a draft

with the papers that will be published. The last one is Reviewer who, in seven days

time, will have to review the papers to complete an evaluation guide line and send

them back to Editor together with the completed evaluation guide line.

The business analyst has considered it appropriate to include aspects related to

security into the business process modeling. To do so, he/she uses the proposed

extension, incorporating access control security requirements into the message flow

generated between Student/Editor and Editor/Reviewer. This means that Pools must

be validated for message flow to be sent and received. Furthermore, access control

has been specified on the Activity “Review of corrections” performed by the Student,

thus limiting the execution of this activity only to Student Pool. It has been specified

security auditing on Editor Pool, thus indicating that we want to emphasize the

sending/reception of message flow, the activity that this Pool has and the execution of

processes “to prepare papers for review”. At last, privacy has been specified on

294

Reviewer Pool, indicating that the degree of protection must be high, which means

that his/her identity must be protected.

In spite of the fact that security requirements must have a concrete expression in

the business process implementation, we think that this is a first stage that should be

defined. From this definition, it will be possible to establish the correlation between

specification and implementation at this level.

Fig. 2. Business Process for the electronic preparation of journal of the Audit and Computer

Science Department.

5 Conclusions

Business process modeling is gaining importance due to the impact it can have on

companies’ competitiveness. Our work considers that we should pay more attention to

295

the business requirements specification at the high levels of abstraction because we

think that the problem must not be only focused on a good solution based on IT.

Security is one of the aspects that has been considered closer to the implementation of

the business itself. We believe that the business process performance could be

improved if security requirements are early captured. We have proposed a BPMN

extension that provides business experts with an efficient vehicle to express security

requirements. Future work should deeply study aspects related to use another

notations (e.g. UML 2.0), and to the interpretation and implementation of security

requirements by experts.

Acknowledgements

This research is part of the following projects: MESSENGER (PCC-03-003-1)

financed by the “Consejería de Ciencia y Tecnología de la Junta de Comunidades de

Castilla-La Mancha” (Spain), CALIPO (TIC2003-07804-C05-03) and RETISTIC

(TIC2002-12487-E) granted by the “Dirección General de Investigación del

Ministerio de Ciencia y Tecnología” (Spain).

References

1 Anttila, J., Kajava, J. and Varonen, R.; Balanced Integration of Information Security into

Business Management, Proceedings of the 30th EUROMICRO Conference. (2004). p:558-

564.

2 Atluri, V.; Security for Workflow Systems, Information Security Technical Report Vol. 6 (2)

(2001). p:59-68.

3 Backes, M., Pfitzmann, B. and Waider, M.; Security in Business Process Engineering,

International Conference on Business Process Management (BPM 2003) Vol. 2678 of

LNCS. (2003). p:168-183.

4 Bertino, E., Ferrari, E. and Atluri, V.; A Flexible model Supporting the Specification and

Enforcement of Role-Based Authorizations in Workflow Management Systems, Proceedings

of Second ACM Workshop on Role-Based Access Control, Fairfax (Virginia). (1997). p:1-

12.

5 Bider, I.; Choosing Approach to Business Process Modeling - Practical Perspective. In

http://www.ibissoft.se/english/howto.pdf. (2003).

6 Botha, R. A. and Eloff, J. H. P.; A framework for access control in workflow systems,

Information Management & Computer Security Vol. 9/3. (2001). p:126-133.

7 BPMN; Business Process Modeling Notation (BPMN), Version 1.0 -May 3, C., BPMI.org.

8 Castela, N., Tribolet, J., Silva, A. and Guerra, A.; Business Process Modeling with UML,

Proceedings of the 3st. International Conference on Enterprise Information Systems, ICEIS

2001. Vol. 2. Setubal, Portugal. (2001). p:679-685.

9 Chaari, S., Ben Amar, C., Biennier, F. and Favrel, J.; An Authorization and Access Control

Model for Workflow, 1th International Workshop on COmputer Supported Activity

Coordination CSAC 2004. Porto, Portugal. (2004). p:31-40.

10 Firesmith, D.; Engineering Security Requirements, Journal of Object Technology Vol. 2 Nº

1 January-February 2003. (2003). p:53-68.

296

11 Firesmith, D.; Specifying Reusable Security Requirements, Journal of Object Technology

Vol. 3, Nº 1,January-February 2004. (2004). p:61-75.

12 Ghalimi, I.; BPMN vs. UML. In

http://www.intalio.com/education/notes/note.xpg?id=BPMN_vs_UML. (2002).

13 Giaglis, G. M.; A Taxonomy of Business Process Modelling and Information Systems

Modelling Techniques, International Journal of Flexible Manufacturing Systems Vol. 13

(2). (2001). p:209-228.

14 Herrmann, G. and Pernul, G.; Viewing Business Process Security from Different

Perspectives, Proceedings of 11th International Bled Electronic Commerce Conference

"Electronic Commerce in the Information Society". Slovenia. (1998). p:89-103.

15 Hung, P. and Karlapalem, K.; A Secure Workflow Model, Australasian Information Security

Workshop (AISW2003). Vol. 21. Adelaide, Australia. (2003). p:33-41.

16 Jürjens, J., Secure Systems Development with UML, Springer Verlag, (2004). 309 p.

17 Lodderstedt, T., Basin, D. and Doser, J.; SecureUML: A UML-Based Modeling Language

for Model-Driven Security, UML 2002 - The Unified Modeling Language, 5th International

Conference. Vol. 2460. Dresden, Germany. (2002). p:426-441.

18 Maña, A., Montenegro, J. A., Rudolph, C. and Vivas, J. L.; A business process-driven

approach to security engineering, 14th. International Workshop on Database and Expert

Systems Applications (DEXA). Prague, Czech Republic. (2003). p:477-481.

19 Mega; Business process Modeling and Standardization. In

http://www.bpmg.org/downloads/Articles/Article-MEGA-

BusinessProcessModeling&StandardizationEN.pdf. (2004).

20 Nuseibeh, B. and Easterbrook, S. M.; Requirements Engineering: A Roadmap, ICSE 2000,

22nd International Conference on on Software Engineering, Future of Software

Engineering Track. Limerick Ireland. ACM. (2000). p:35-46.

21 OMG; Object Management Group. In http://www.omg.org/. (2004).

22 Owen, M. and Raj, J.; BPMN and Business Process Management; Introduction to the New

Business Process Modeling Standard, A Popkin Software, W. P. In

http://www.bpmn.org/Documents/6AD5D16960.BPMN_and_BPM.pdf. (2003).

23 Palkovits, S., Rössler, T. and Wimmer, M.; Process Modelling - Burden or Relief? Living

Process Modelling within a Public Organisation, ICEIS 2004, Proceedings of the 6th

International Conference on Enterprise Information Systems. Porto, Portugal. (2004). p:94-

102.

24 Reijers, H. A.; Business Process Management Attempted Concepticide?, IRMA

International Conference (2004). p:128-131.

25 Röhm, A. W., Herrmann, G. and Pernul, G.; A Language for Modelling Secure Business

Transactions, Proceedings 15th. Annual Computer Security Applications Conference.

Computer Society Press., Phoenix, Arizona. (1999). p:22-31.

26 Sandhu, R. and Samarati, P.; Authentication, Access Control, and Audit, ACM Computing

Surveys Vol. 28 Nº1 March 1996. (1996). p:241-243.

27 Sparks, G.; An Introduction to UML, The Business Process Model. In

http://www.sparxsystems.com.au/WhitePapers/The_Business_Process_Model.pdf. (2000).

28 Tryfonas, T. and Kiountouzis, E. A.; Perceptions of Security Contributing to the

Implementation of Secure IS, Security and Privacy in the Age of Uncertainty, IFIP TC11

18th International Conference on Information Security (SEC2003) Vol. 250. Athens,

Greece. (2003). p:313-324.

29 W.M.P. van der Aalst, Hofstede, A. H. M. t. and Weske, M.; Business Process

Management: A Survey, International Conference on Business Process Management (BPM

2003) Volume 2678 (LNCS). Eindhoven, The Netherlands. (2003). p:1-12.

30 WfMC, Workflow Management Coalition: Terminology & Glossary., Document Number

WFMC-TC-1011, Document Number WFMC-TC-1011, (1999). 65 p.

31 White, S. A.; Introduction to BPMN. In http://www.ebpml.org/bpmn.htm. (2004).

297