Evaluation of a Business Continuity Plan using Process ... - IEEE Xplore

TIC-STH 2009

Evaluation of a Business Continuity Plan using Process Algebra and Modal Logic Wolfgang Boehmer

Christoph Brandt

Jan Friso Groote

Department of Computer Science Department of Computer Science Department of Computer Science Eindhoven University of Technology SECAN-Lab Security Engineering Group P.O. Box 513, Den Dolech 2 Université du Luxembourg Technische Universität Darmstadt Luxembourg, Luxembourg 1359 5600 MB Eindhoven, The Netherlands Darmstadt, Germany 64283 Email: [email protected] Email: [email protected] Email: [email protected]

Abstract—Since (1996) Knight and Pretty published their study about the impact of catastrophes on shareholder value, the need for a business continuity management system (BCMS) became clear. Once a BCMS is in place, the corresponding risks can be insured against. The BS 25999 certificate can serve as proof of implementation. It requires defined business continuity plans (BCP). However, processes based on BCPs are rarely tested. Therefore, little knowledge is available to confirm their proper functioning and their non-functional properties. This paper addresses the verification of BCPs. We show how to model, simulate and verify normal business processes and business processes that are based on a BCP. As a formal method, we use process algebra and modal logic to explain the semantics of conceptual business process models. Our study places emphasis on questions regarding the potential capacity and duration of a process based on a BCP as well as those of an organizational security policy. By doing this, we are able to demonstrate that ex-ante evaluation is not only possible but also effective.

I. I NTRODUCTION The problem statement concerns interruptions to the central value chain (CVC) that a company is running, as well as their handling. Such interruptions can be caused by catastrophes or other major and rare incidents. We assume that a company is able to survive only a certain amount of time without its CVC. As a business continuity management system (BCMS) response, a business continuity plan (BCP) is put in place. There are different BCPs for different types of incidents that cause an interruption. The underlying idea is that a BCP keeps the company alive while it is recovering by the help of a disaster recovery plan (DRP). Because of the best-practice solutions in use today, there is little proven knowledge about the proper functioning of a BCP. Often, only some rare, nonrepresentative evidence from real BCP exercises is available. The first research question that we would like to discuss concerns the specification of the behavior of a CVC and the underlying process of a BCP. Regarding this, we would like to determine whether the BCP is able to back up a predefined number of business cases within a certain time span, usually handled by the CVC. The second research question is about certain organizational security policies. Concerning this, we would like to determine whether the CVC and BCP are compliant toward them.

978-1-4244-3878-5/09/$25.00 ©2009 IEEE

The contribution made by this paper consists of a new definition of the formal semantics of a CVC and a BCP, using advanced process algebra, a simulation of their behavior to determine their capacity, and fully automated model checking using modal logic to highlight whether an organizational security policy is valid. The paper is organized as follows. First, we introduce the context of a BCMS that handles the BCP and DRP of the CVC of a company. We next present a loan-granting process (LGP) as an example of a critical business process. We then demonstrate how to use mCRL2, an advanced process algebra with a sophisticated modal logic for model checking. Following this, we discuss how to define the formal semantics of the LGP and show state-space exploration and simulation results regarding the performance capacities of the process. We then present model-checking results to show compliance with an organizational security policy (segregation of duty) that can be proven automatically. Finally, we reference some related work and summarize our conclusions and prospective future work. II. B USINESS C ONTINUITY M ANAGEMENT S YSTEM A business continuity management system (BCMS) is a special management system that constitutes a framework for handling incidents threatening an organization. That is, it enables effective responses toward these incidents. Therefore, it helps to safeguard the interests of the organization’s key stakeholders and its reputation, brand and value-creating activities. Thus, a company that wants to safeguard their critical value chain (CVC) must focus on securing revenues by taking adequate risk countermeasures. Since 2007, the BS 259992:2007 [21], published by the British Standards Institution (BSI), has been available. It is an industry-wide recognized best-practice method that governs the creation of a BCMS. It encompasses a BCP (business continuity plan) and a DRP (disaster recovery plan). The time span available for the BCP to deliver a minimum business revenue is defined as the maximum tolerable period of disruption (MTPD). We will discuss the business process capacity (BPC) of the CVC, and some variants of continuity processes. In addition, the

147

continuity processes should be compliant with organizational security policies (e.g. segregation of duty). We will show how these qualities can be analyzed ex-ante with the help of formal methods.

C arrived E0

Split-1

III. L OAN -G RANTING B USINESS P ROCESS

Customer Data, Tax ID, Pasport No., Name / Address D1

Here we discuss a simplified version of a loan-granting process (LGP) that can be found in an arbitrary bank. First, we present the normal business situation. We then discuss the business continuity situation.

Customer, Collaterals, Type, Value D2

Merge-1

Time 0 0 30 10 0 0 5 0 60 0 0 15 0 20 0 5 0 30 0

PC O1

store data in DB 1 F3a

DB 1 M1

data stored E1 (ID)

external credit office M2

check creditworthiness F3

PC O1

Split-2 customer rejected E2b (ID)

customer accepted E2a (ID)

DB 1 M1

internal rating application M3

PPC O2

evaluate rating F4 Rating Report, Overall Result, Context Information D3

Fig. 1. Receiving from . . . C, ETC E0 Split1, PC, C Split1, PC, C F1, F2 Merge1 E1a, PC F3a E1, PC F3 Split2 E2, PPC F4 E3, S, PPC F5 E4, M F6 E5, M, C F7

C O5 PC O1

data collected E1a (ID)

In a normal business situation (NBS) a LGP consists of a number of procedures: First, a processing clerk (PC) identifies the customer (C) in front of him. We assume that this activity will take about 30 min (T=30). In our formal model we will refer to this activity as F1 (A=F1). Second, the PC accepts the supporting documents from C (A=F2, T=10). According to our process model (see figs. 1 and 2), these activities can run sequentially or simultaneously. Third, the PC stores the data about C into the database DB1 (A=F3a, T=5). Fourth, the creditworthiness of C is checked by the PC, who makes a request to an external credit office (A=F3, T=60). This results in request C being accepted (E2a) or rejected (E2b). Fifth, the post-processing clerk (PPC) determines the rating for C (A=F4, T=15) by using data from DB1 and support from a rating application. Sixth, the PPC and the supervisor (S) create an optimized contract (A=F5, T=20). To do this, they access a price engine application and output management application (OMA). Seventh, the manager (M) prints the contract (A=F6, T=5). The result is an unsigned contract. Finally, C and M both sign the contract (A=F7, T=30). Sending to . . . Split1 F1, F2 Merge1, PC, C Merge1, PC, C E1a F3a E1, PC F3 Split2, PC E2a, E2b F4 E3, PPC F5 E4, S, PPC F6 E5, M F7 E6, M, C C, ETC

PC O1

getC MasterData F2

A. The Normal Business Situation

Process E0 Split1 F1 F2 Merge1 E1a F3a E1 F3 Split2 E2a F4 E3 F5 E4 F6 E5 F7 E6

C O5

getC ID F1

product choosen E3 (ID)

Normal Business Process – Part 1

product choosen E3 (ID)

PPC O2

create optimized contract F5

pricing engine M4 output management system M5

contract created E4 (ID)

Product Bundle, Name / ID, Price, / Detail, Changes D3

unsigned form D5

S O3

M O4

print contract F6

contract printed E5 (ID)

signed form D6

TABLE I PARTIAL P ROCESS -A LGEBRA V IEW OF THE N ORMAL P ROCESS

C O5

sign contract F7

M O4 contract signed E6 (ID)

B. The Business Continuity Situation In a business continuity situation (BCS), a LGP consists of a number of slightly different procedures. We assume here

148

Fig. 2.

Normal Business Process – Part 2

Process E0 Split1 F1 F2 Merge1 E1a F4a Split2 E2a E2b F5a alt1 F5a alt2 E4a F7 E6

C arrived E0

Split-1 Customer Data, Tax ID, Pasport No., Name / Address D1

getC ID F1

Customer, Content, Type, Value D2

getC MasterData F2

C O5 PC O1 C O5 PC O1

Merge-1


Receiving from . . . C, ETC E0 Split1, PC, C Split1, PC, C F1, F2 Merge1 E1a, PC F4a Split2 Split2 E2a, PC E2a, M F5a E4a, M, C F7

Time 0 0 30 10 0 0 60 0 0 0 90 90 0 30 0

TABLE II PARTIAL P ROCESS -A LGEBRA V IEW OF THE E MERGENCY P ROCESS

PC O1

accept customer F4a

Sending to . . . Split1 F1, F2 Merge1, PC, C Merge1, PC, C E1a F4a Split2, PC E2a, E2b F5a C, ETC E4a, PC E4a, M F7 E6, M, C C, ETC

Split-2 customer rejected E2b (ID)

C arrived E0a

customer accepted E2a (ID)

PC O1

create standard contract F5a

PC O1

M O3

Split-0

XOR

customer returned E0b (ID)

form filled E4a (ID) unsigned form D5

signed form D6

C O5

check business value F0

customer picked E0 (ID)

C O5

sign contract F7

M O4

Split-1 contract signed E6 (ID)

Fig. 3.

Business Continuity Process – Variants A.1 and A.2

Customer Data, Tax ID, Pasport No., Name / Address D1

getC ID F1

Customer, Content, Type, Value D2

getC MasterData F2

C O5 PC O1 C O5 PC O1

Merge-1

that the business continuity process will take care of the fact that business-critical IT systems are not available. The overall purpose is to make a minimum business functionality available. 1) Variants A.1 and A.2: The first two variants of the business continuity process that we would like to present are defined as follows: First, a PC identifies C (A=F1, T=30). Second, the PC collects the supporting documents from C (A=F2, T=10). These two activities can be performed sequentially or in parallel. Third, the PC makes a decision on whether the customer is accepted or rejected (A=F4a, T=60). If C is rejected, C drops out of the process. Fourth, the PC (variant A.1) or M (variant A.2) creates a standard contract for C (A=F5a, T=90). Finally, C and M sign the contract (A=F7, T=30). 2) Variant B: The third variant of the business continuity process contains an additional first step. During this step the PC determines the business value of C in order to decide whether the customer is picked for the business continuity process or rejected. The rationale behind this decision is to process only those customers who have a high business value


Fig. 4.

Business Continuity Process – Variant B, Part 1

for the bank to meet the minimum business objectives in the continuity case. In other words, the PC checks the business value of C (A=F0, T=60). Following this, the process continues as described in variant A.1 by identifying the customer (A=F1, T=30) and collecting the supporting documents (A=F2, T=10). IV. P ROCESS A LGEBRA : M CRL2 Here we would like to introduce mCRL2 [7] as a suitable formal platform to define the semantics of event-driven process chains [18] used to model critical business processes. The specification language mCRL2 is a process algebra encompassing data and time and including a modal logic. It is therefore helpful for specifying and analyzing a broad range of systems. As presented in [7], the process algebraic

149

structure helps to formally specify the communication between subcomponents of a system without touching the rest of it. Therefore, component-based and hierarchical systems are well supported.

sort map eqn act proc

A. The Process Language The primary notion in the mCRL2 process language [7] is an action, which represents an elementary activity or a communication of some systems. Multiactions enable the specification of actions that are executed together. As a consequence, these multiactions allow the separation of parallelism and communication. When two actions can be executed at the same time, a multiaction including those actions is the result. Communication can then be applied to these multiactions to make certain actions communicate with each other. B. The Data Language The mCRL2 data language [7] is a functional language based on higher-order abstract data types, extended with concrete data types: standard data types and sorts constructed from a number of type formers. It can be used to parameterize processes and actions. Because the data language is higher order, functions are first-class citizens and can therefore be used just as easily as other data can [6], [8]. C. The Modal µ-Calculus By adding explicit minimal and maximal fixed-point operators to Hennessy–Milner logic, the modal µ-calculus [8] is obtained. Modal formulas are extended with data, similar to processes. Thus, modal variables can have arguments, actions can carry data arguments as well as time stamps, and existential and universal quantification is possible. D. Example: Dining Philosophers The use of mCRL2 can easily be demonstrated by modeling the dining philosophers problem (DPP) [4]. In the following case the DPP consists of three philosophers and three forks that are shared. Each philosopher has a plate. The forks are placed between the philosophers, to the left and right of each plate. In order to eat the dishes that are served, each diner needs to use two forks. In the following model, the sort PhilId contains the philosophers. The nth philosopher is denoted by pn . The sort ForkId contains the forks (fn denotes the nth fork). The functions lf and rf designate the respective left and right forks of each philosopher. The process Phil(pn ) models the behavior of the nth philosopher. It first takes the left and right forks (in any order; possibly at the same time), then eats, subsequently puts both forks back (again in any order) and finally repeats its behavior. The process Fork (fn ) defines the behavior of the nth fork. It can perform up(p, fn ) for any philosopher, meaning that the fork is picked up by philosopher p. Then it performs down(p, fn ), meaning that the same philosopher puts the fork down, and repeats the behavior.

init

P h i l I d = s t r u c t p1 | p2 | p3 ; ForkId = struct f1 | f2 | f3 ; l f , r f : P h i l I d −> F o r k I d ; l f ( p1 ) = f 1 ; l f ( p2 ) = f 2 ; l f ( p3 ) = f 3 ; r f ( p1 ) = f 3 ; r f ( p2 ) = f 1 ; r f ( p3 ) = f 2 ; g e t , p u t , down , l o c k , f r e e : P h i l I d × F o r k I d ; eat : PhilId ; P h i l ( p : P h i l I d )= ( get (p , l f (p )) | get (p , rf (p ) ) ) . eat (p ) . ( put (p , l f ( p ) ) | put (p , r f ( p ) ) ) . Phil ( p ) ; Fork ( f : ForkId ) = sum p : P h i l up ( p , f ) . down ( p , f ) . F o r k ( f ) ; b l o c k ({ g e t , p u t , up , down} ,comm({ g e t | up −>l o c k , p u t | down −> f r e e } , P h i l ( p1 ) | P h i l ( p2 ) | P h i l ( p3 ) | Fork ( f1 ) | Fork ( f2 ) | Fork ( f3 ) ) ) ;

Fig. 5.

mCRL2 Specification of Dining Philosophers

The system consists of three Phil and Fork processes that run in parallel. Communication between get and up as well as between put and down is enforced. The resulting communication is lock and free. The communication operator, ΓC (p), allows communication only when possible. The blocking operator, ∂B (p), ensures that nothing else happens. The mCRL2 toolset is used to generate the state space in order to check certain properties of the system. Additionally, modal formulas in the µ-calculus can express desired (temporal) properties. These are solved by transforming the system behavior and formula to a parameterized Boolean equation system that is subsequently solved. By model checking, a deadlock in the dining philosophers can be easily found, yielding to trace lock(p1 ,f1 ) · lock(p2 ,f2 ) · lock(p3 ,f3 ). The detected deadlock represents a situation in which each of the philosophers has taken one fork and waits for another one without being able to put the first one back. One solution is to cross the arms of one of the philosophers. The result is a simple LTS (Labelled Transition Systems) consisting of 36 states and 104 transitions with no deadlock states. V. C ASE S TUDY In this case study we will investigate the dynamic behavior of the CVC and that of A.1, A.2, and B. We present the scenario, some snippets of the mCRL2 specification, the process capacity, and a safety and liveness requirement. The full model and all details are given in [3]. A. The Scenario Apart from the pure process description, we assume that there are two process instances running in parallel with two processing clerks (PC), one post-processing clerk (PPC) for back-office work, one supervisor (S) for controlling jobs, and one manager (M) who can sign contracts. In the business continuity situation, only one PC is available full-time and one M part-time. We assume that no PPCs or Ss are available. B. The Specification In the mCRL2 specification of E1 (fig. 6), a customer (C) passes through the proc instance. It first communicates with F3a, then makes the assumption that some information

150

proc E1= sum c : Customer , t : Time . F3a E1 r ( c , t ) . i n f o r m a t i o n s t o r e d i n f i l e ( c , t ) . E1 F3 s ( c , t ) . E1 ;

f o r a l l e : PClerk , c : Customer . [ t r u e ∗. F1 getC ID ( e , c ) . t r u e ∗. F 3 c h e c k c r e d i t w o r t h i n e s s ( e , c ) ] f a l s e

map d u r a t i o n F 1 : Time ; eqn d u r a t i o n F 1 = 3 0 ; proc F1= sum c : Customer , t : Time . S p l i t F 1 r ( c , t ) . sum e : P C l e r k , u , u ’ : Time . a s s i g n p c l e r k r ( e , t , u , u ’ ) . sum v , v ’ : Time . a s s i g n c u s t o m e r r ( c , u ’ , v , v ’ ) . % Perform t a s k r e l e a s e c u s t o m e r s ( c , v ’+ d u r a t i o n F 1 ) . r e l e a s e p c l e r k s ( e , v ’+ d u r a t i o n F 1 ) . F1 Merge s ( c , v ’ + d u r a t i o n F 1 ) . F1 ;

Fig. 6.

Fig. 8. mCRL2 Specification of the Segregation of Duty (Four-Eye Principle)

f o r a l l c : Customer , t : Nat . [ t r u e ∗. E0 c ( t , c ) ] mu X . [ ! e x i s t s u : Nat . E6 c ( u , c ) ] X

mCRL2 Specification for E1 and F1

Fig. 9.

eligible for a loan, while others are not (indicated by †). The endtimes are obtained by highway state-space exploration of width 10,000 [5]. The average times are determined using random simulation. Our interpretation of table III is the following: A.2 is safer and not particularly bad on average, although its potential end serving times appear bad compared to A.1. As an alternative to A.1, we consider B, in which the filtering of customers is performed initially. We see that this has a mixed effect on the average throughput times, but hardly any on the latest times that customers can be in the system. Note that B is a variant on A.1. Clearly, this allows us to study alternative process models and enables us to develop an optimal BCP.

proc C u s t o m e r ( c : C u s t o m e r ) = sum t : Time . E0 3 ( c , t ) . C u s t o m e r ( c , t ) ; C u s t o m e r ( c : Customer , t : Time ) = sum t ’ : Time . a s s i g n c u s t o m e r s ( c , t ’ , t , max ( t , t ’ ) ) . sum u : Time . r e l e a s e c u s t o m e r r ( c , u ) . C u s t o m e r ( c , u ) + sum t : Time . E6 r ( c , t ) . d e l t a ; s o r t P C l e r k = s t r u c t pc1 | pc2 ; proc P C l e r k ( e : P C l e r k , t : Time ) = sum t ’ : Time . a s s i g n p c l e r k s ( e , t ’ , t , max ( t , t ’ ) ) . sum u : Time . r e l e a s e p c l e r k r ( e , u ) . P C l e r k ( e , u ) ; proc P C l e r k s = P C l e r k ( pc1 , 0 ) || P C l e r k ( pc2 , 0 ) ;

Fig. 7.

mCRL2 Specification for Customer and Processing Clerk

is stored in a file by C and communicates with F3 before restarting automatically. According to the specification of F1, a customer and a clerk are assigned to this task once the split process has fired. Following this, the activity F3 finishes, and both are released. The merge process get the customer with the time the customer spent in F1. Then F1 restarts. In the mCRL2 specification for a customer (fig. 7), a customer is first created by event E0 and is then assigned and released by different processes. Finally, the customer drops out of the business process once it reaches event E6. Processing clerks are basically assigned and released through different tasks. Because we assume that there are two distinct processing clerks, we have two data structures here and two separate instantiations. C. Capacity Estimations Process CVC BCP A.1 BCP A.2 BCP B Process CVC BCP A.1 BCP A.2 BCP B

1† 570 1540 1000 60 1† 283 729 475 60

2 670 1570 2420 1770 2 459 1151 1018 1275

3† 595 1540 1000 1650 3† 434 893 671 344

4 665 1570 2340 1770 4 473 1105 1049 1469

5 670 1570 2300 1770 5 503 1182 1422 1427

6† 595 1540 1000 1650 6† 378 870 756 632

7 670 1570 2360 1770 7 522 981 986 1347

8† 590 1540 1000 1650 8† 461 819 677 359

9 665 1570 2340 1770 9 465 1165 1386 1548

mCRL2 Specification: Every customer is Served

10 675 1570 2340 1770 10 536 1356 1464 1462

D. Safety Property According to Kindler [11], a safety property expresses informally that something (bad) will not happen. In our case, we would like to prove that the clerk who identifies the customer will never be the one who judges his or her creditworthiness. Therefore, we can conclude that the segregation of duty (foureye principle) is respected here. The corresponding modal µformula that can be checked with the help of the mCRL2 toolsuite is given in fig. 8. E. Liveness Property In the same way, a liveness property can be informally defined [11]. It states that eventually something (good) can or must happen. In our case, we would like to prove that every customer will always be served eventually. The corresponding modal µ-formula that can be checked with the help of the mCRL2 toolsuite is given in fig. 9. The safety formula holds only in scenario BCP A.2. In the cases of BCP A.1 and B, the four-eye principle is not respected. The liveness property fortunately holds in all scenarios. VI. R ELATED W ORK

TABLE III L ATEST AND AVERAGE C USTOMER -S ERVING E NDTIMES

Via simulation we are able to obtain the latest and average customer-serving endtimes for the business processes (see table III). Customers arrive every 10 minutes. Some are

There is a strong tendency to use formal techniques for process modeling. Below, we mention studies that underline their need, and discuss the availability of several techniques. Primarily, the work of Nemzow [14] discusses various strategies for protecting an organization from both natural and man-made disasters. IBM proposes [9] the use of an

151

integrated business continuity and resilience plan, because traditional approaches to disaster planning have failed to keep organizations operational. Quirchmayr [17] presents an overview of business continuity management and addresses the question of how a system should be built in order to cope with a successful intrusion. Landry and Koger [13] show ten common disaster-recovery myths. They claim that many organizations are unprepared or make unrealistic assumptions. Tjoa, Jakoubi, and Quirchmayr [20] discuss the approach of a business process modeling and simulation methodology that is risk-aware. They propose the advancement of the businesimpact analysis and risk assessment in use today. A. and M. Zalewski, Sztandera, and Ludzia [22] mention that the importance of business continuity and disaster-recovery plans has grown considerably in recent years. They explain that these plans are typically textual documents and that the performing of exercises is still the main measure used to verify them. A way to model these is by Petri nets, as suggested by van der Aalst [1]. Petri nets are not only suitable for modeling, but they can also be used for various verification purposes. Closer to our approach is the work of Puhlmann [15], [16], who suggests the use of the π-calculus to explain the semantics of business processes. This is a little strange because classical data-enlarged process algebras such as mCRL2 are much more mature for modeling and analysis, and the typical features of the π-calculus do not seem to offer any additional value for business processes. There are several other modeling formalisms. Thurner developed an approach to formalizing and verifying eventdriven process chains [19]. Koubarakis and Plexousakis [12] developed a formal framework for business-process modeling and design. Their language permits the verification of certain correctness properties. Boehmer developed a solution [2] to evaluate the performance of a business continuity management system according to the BS 25999. To date, tool overviews for business processes have neglected to mention the process algebraic tool suites, because these are generally not used for business-process simulation. See, for instance, the overview by Jansen-Vullers and Netjes [10]. VII. C ONCLUSIONS AND F UTURE W ORK A couple of conclusions based on the results of this study can be made: First, it is possible to define the semantics of an event-driven process chain as it is used today for the purpose of business-process modeling. Second, it is possible to use this semantics to check the functional and non-functional properties of a business workflow in a fully automated fashion. Third, it is possible to simulate all possible state transitions to investigate the dynamic nature of a business process. It is therefore possible to evaluate a CVC and a BCP as part of a BCMS in an ex-ante way. By doing this, we can make a sound statement about the effectiveness and efficiency of a BCMS. Further, we can make sound statements about questions regarding the compliance of business processes with organizational policies. We believe that this will lead to a

significant reduction in BCMS development costs as well as a reduction in risks caused by non-functional BCPs and a reduction in insurance costs through a better understanding of the business continuity costs. Future work will encompass the evaluation of further business cases and the ongoing development of the formal model. R EFERENCES [1] W.M.P Aalst van der. Formalization and verification of event-driven process chains. Information and Software Technology, 41(10):639–650, 1999. [2] W. Boehmer. Survivability and business continuity management system according to bs 25999. In SECURWARE ’09, volume 0, Athens/Glyfada, Greece, June 2009. IEEE Computer Society. [3] W. Boehmer, C. Brandt, and J.F. Groote. Evaluation of a business continutiy plan using process algebra and modal logic. Technical Report, Technical University of Eindhoven, 2009, to appear. [4] E. W. Dijkstra. Hierarchical ordering of sequential processes. In Acta Informatica, pages 1:115–138, 1971. [5] T. Engels, J. F. Groote, M. van Weerdenburg, and T. Willemse. Search algorithms for automated validation. J. Log. Algebr. Program, (2009, to appear). [6] J.F. Groote et. al. Process Algebra for Parallel and Distributed Processing. Chapman & Hall/CRC (ed) Alexander, Michael and Gardner, William, 1.st. edition, 2008. [7] J. F. Groote, A. Mathijssen, M. van Weerdenburg, and Y. S. Usenko. From ucrl to mcrl2: Motivation and outline. In Proc. Workshop Essays on Algebraic Process Cacluli (APC 25), pages 162:191–196, Bertinoro, Romagna, Italy, 2006. Electronic Notes in Theoretical Computer Science, Springer-Verlag. [8] J.F. Groote and M.A. Reniers. Modelling and Analysis of Communicating Systems. CRC Press, To appear. 2009. [9] IBM. Panic slowley. integrated disaster response and bulit-in business continuity. ibm.com/itsolutions/uk/governance/businesscontinuity, 2006. [10] M.H. Jansen-Vullers and M. Netjes. Business process simulation - a tool survey. In K. Jensen (ed.). 7th Workshop and Tutorial on the Practical Use of CPN 06, Volume 579 of DAIMI, pp. 77-96. Uni. of Arhus, Denmark, 2006. [11] E. Kindler. Safety and liveness properties: A survey. EATCS-Bulletin, 53:268–272, June 1994. [12] M. Koubarakis and D. Plexousakis. A formal framework for business process modelling and design. Inf. Syst., 27(5):299–319, 2002. [13] B. J. L. Landry and M. S. Koger. Dispelling 10 common disaster recovery myths: Lessons learned from hurricane katrina and other disasters. J. Educ. Resour. Comput., 6(4):6, 2006. [14] M. Nemzow. Business continuity planning. Int. J. Netw. Manag., 7(3):127–136, 1997. [15] F. Nestmann, U. & Puhlmann. Business Process Specification and Analysis. Chapman & Hall/CRC (ed) Alexander, Michael and Gardner, William, 1.st. edition, 2008. [16] F. Puhlmann. Why do we actually need the pi-calculus for business process management? In W. Abramowicz & H. C. Mayr, editor, 9th Int. Conf. on Business Information Systems (BIS 2006), pages 77–89. Dept. of Information Systems, Poznań University of Economics, 2006. [17] G. Quirchmayr. Survivability and business continuity management. In ACSW Frontiers ’04, pages 3–6, Darlinghurst, Australia, 2004. Australian Computer Society, Inc. [18] A.-W. Scheer. ARIS-Modellierungs-Methoden, Metamodelle, Anwendungen. Springer, Berlin/Heidelberg, 2001. [19] V. Thurner. Formal fundierte Modellierung von Geschäftsprozessen – Geschäftsprozesse anschaulich und präzise dokumentieren. ISBN 38325-0683-7. Logos Verlag, Berlin, 2004. [20] S. Tjoa, S. Jakoubi, and G. Quirchmayr. Enhancing business impact analysis and risk assessment applying a risk-aware business process modeling and simulation methodology. In ARES ’08,, pages 179–186, Washington, DC, USA, 2008. IEEE Computer Society. [21] BSI (UK). Business continuity management system – part 2: Specification. ISBN 9780580599132, 11 2007. [22] A. Zalewski, P. Sztandera, M. Ludzia, and M. Zalewski. Modeling and analyzing disaster recovery plans as business processes. In SAFECOMP ’08, pages 113–125, Berlin, Heidelberg, 2008. Springer-Verlag.

152