Clouds Coalition Detection for Business Processes Outsourcing

Amina Ahmed Nacer, Mohammed Riyadh Abdmeziem and Claude Godart

University of Lorraine, Nancy France

Keywords:

Cloud Computing, Decoy Process, Privacy Preserving, Coalition, Know-How Exposure.

Abstract:

Companies outsourcing their BP (Business Processes) to the cloud must be sure that sensitive information

included in their BP are protected. While there are several existing methods that include splitting the model

into a collection of BP fragments before a multi-cloud deployment minimizing therefore the likelihood of a

coalition, a risk still remains. We propose in this paper an approach for detecting malicious cloud providers

that initiate or participate to a coalition. To do that, we rely on decoy processes having the same structure and

number of data as a real process, but with decision strategy making as well as data sets that are completely

different (fake) from the real one. Our objective is to detect unexpected exchanges of messages between

malicious clouds, that may signify an attempt to initiate or participate to a coalition. The level of reputation of

each cloud initiating or joining the coalition will be modiﬁed accordingly.

1 INTRODUCTION

The fast development of technologies forces compa-

nies to be innovative in order to stay competitive.

They must ensure a high degree of efﬁciency with re-

spect to delivery deadlines. The introduction of cloud

computing seems to be the ideal solution as it avoids

upfront infrastructure cost, and helps organizations to

focus on their core business activities, instead of their

system infrastructure.

In this context, companies are willing to outsource

their BP (Business Processes) to the cloud. However,

as the cloud introduces new security risks related to

its shared environment (Network and Agency, 2009;

Abdmeziem, 2016; Abdmeziem and Charoy, 2018),

they are still reluctant to do so, especially because of

the know-how included in BP models which is con-

sidered as particularly sensitive.

In our previous work (Goettelmann et al., 2015),

we suggested a method for splitting a BP model into

BP fragments, so that when these BP fragments are

externalized in a multi-cloud setting, a cloud provider

cannot understand a crucial part of company know-

how.

Although the simple splitting of a process makes

such a conspiracy more challenging, this work pri-

marily offers active support against a single malicious

cloud at a time and does not explicitly address the risk

of a conspiracy involving multiple malicious cloud

providers, which could pool their local knowledge of

the process model to discover larger critical know-

how.

In (Ahmed Nacer et al., 2016) we went one step

further in reducing this risk of conspiracy by intro-

ducing fake fragments at strategic points in the BP.

However, even if this solution reduces considerably

the possibility of conspiracy, a risk still remains. In

this context, we propose in this paper a solution for

detecting clouds initiating or participating to coali-

tions through the transmission of unexpected mes-

sages. Reputation of these clouds will be reduced ac-

cording to if they initiate or participate to the coali-

tion.

The rest of the paper is organized as follows: Sec-

tion 2 introduces our motivations and the context of

our work. Next section presents our cloud coalition

detection approach. Section 4 applies our approach to

our motivating example. Section 5 discusses the state

of the art and ﬁnally section 6 concludes and intro-

duces some future works.

2 MOTIVATIONS AND CONTEXT

OF WORK

This section starts with the description of a motivating

example, then it introduces the notion of obfuscation

based on sensitive fragments separation, and presents

a threat scenario on which our approach is based. Fi-

nally, it presents two attacker models which illustrate

530

Ahmed Nacer, A., Abdmeziem, M. and Godart, C.

Clouds Coalition Detection for Business Processes Outsourcing.

DOI: 10.5220/0011963400003464

In Proceedings of the 18th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2023), pages 530-537

ISBN: 978-989-758-647-7; ISSN: 2184-4895

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

Compagny’s Recruitment

Get

Recruitment

Request (GRR)

Chek

Candidate

Information

(CCI)

Selected for an

Interview (SI)

Reevaluation of

Application

(RA)

Accept for a

Trial Period

(ATP)

Refused

Candidacy(RC)

Hierarchy

Validation (HV)

Technical

Decision (TD)

Final

Decision (FD)

Figure 1: Recruitment process.

Cloud2

Get Recruitment

Request (GRR)

Chek Candidate

Information

(CCI)

Selected for an

Interview (SI)

Reevaluation of

Application (RA)

Hierarchy

Validation (HV)

Cloud 1

Technical

Decision (TD)

Final

Decision (FD)

Cloud 3

Refused

Candidacy (RC)

Accept for a

Trial Period

(ATP)

Receive

Fictive

Activity

Send

Receive

Send

Receive

Send

Fictive

Activity

Receive

Send

Receive

Figure 2: The recruitment process as a collaboration of BP fragments.

how the power of an attacker can be exploited, to ex-

tract important BP-know how.

2.1 Motivating Example

Figure 1 depicts

a selection process of a company

that wants to recruit staff. The objective of this pro-

cess is to accept or reject a candidacy. Depending on

candidate record (professional experience, technical

knowledge, police record, . . . ) the recruitment pro-

cess is treated in different ways. The candidate can be

selected for an interview, accepted for a trial period or

directly refused for the job. At any point in the pro-

cess, the hierarchy can directly intervene. The ﬁnal

decision is taken on the basis of the decision notiﬁca-

tion combined with hierarchy decision.

The company is prepared to externalize the exe-

cution of its business processes to the cloud, but it

wants to maintain its method for accepting or reject-

ing a candidate. In order to achieve this goal, the com-

panie’s IT services provider chooses to separate the

BP model’s logic into a collection of BP fragments.

We use the BPMN (Business Process Modeling Nota-

tion (http://www.bpmn.org)) for modeling our BP models.

In addition, these process models are supposed to be well

structured (Polyvyanyy et al., 2012)

Figure 2 describes such a collaboration of BP frag-

ments obtained by the splitting algorithm described

in (Goettelmann et al., 2015); each fragment being

assigned to a different cloud, and the fragments being

connected with send and receive messages.

2.2 BP Obfuscation by Splitting Its

Logic Using Sensitive Tasks

The main concept of BP obfuscation is to split a BP

model into BP fragments, with each of them being

deployed on different clouds. As a result, each cloud

provider has just a partial view of the BP model.

While splitting a BP model in several BP frag-

ments is effective for obfuscating a BP model, differ-

ent splittings are possible and the problem is to choose

the best one regarding different QoS parameters. For

supporting this objective, one principle is to separate

the more sensitive information in different BP frag-

ments.

While this principle remained at the level of best

practice in previous work, we have proposed in (Goet-

telmann et al., 2015) a formalization of the notion of a

sensitive activity, and an algorithm for automatically

Clouds Coalition Detection for Business Processes Outsourcing

531

identifying the most sensitive tasks

(containing the

more BP know-how) and assigning them to different

clouds.

Our assumption is that the most sensitive infor-

mation is located in some speciﬁc fragments where

important decisions and syntheses are made.

More precisely, we locate decisions in the BP

fragments preceding (x) or-split gateways triggering

alternatives fragments. In addition, we consider that

a decision is complemented in the fragment follow-

ing the (x) or-join gateway closing the opening (x)or-

split succeeding the decision fragment. In our moti-

vating example (ﬁgure 1), Check Candidate Informa-

tion (CCI) is a decision task and Technical Decision

(TD) its complement. Both are sensitive tasks.

Respectively, we locate syntheses in the fragments

succeeding and-join gateways synchronizing several

ﬂows executing in parallel. Also, syntheses are often

prepared in the fragment preceding the opening and-

split gateway corresponding to the closing and-join

gateway: we consider that these fragments are also

sensitive ones. In our motivating example, Final De-

cision (FD) is a synthesis task and Get Recruitment

Request (GRR) its complement. Both are also sensi-

tive tasks.

After identifying those sensitive fragments, the al-

gorithm returns a set of constraints for splitting the

centralized process in a business process collabora-

tion deploying sensitive tasks in different clouds. The

principle is to separate, as much as possible, a sensi-

tive task and its complement in two different BP frag-

ments assigned to two different clouds (other aspects

regarding sensitive tasks are considered in this algo-

rithm but are of no interest for this paper) .

Back to our motivating example, the centralized

resident selection BP can be split into the BP fragment

collaboration depicted in ﬁgure 2 which follows the

above principles.

2.3 BP Fragments Collaboration

As introduced in the previous section, applying the

principle of sensitive complementing activities sepa-

ration leads to the deﬁnition of interacting BP frag-

ments. However the number of BP fragments can de-

pend on other parameters, including other security ar-

tifacts and QoS properties. Then these BP fragments

are assigned to clouds for execution, but different as-

signments leading to different cloud conﬁgurations

are also possible at this step.

In other words, several cloud conﬁgurations are

possible for deploying a BP and there is a need for se-

We use the traditional notion of a task in BP modeling,

encompassing atomic and composite process activities.

lecting the most secure conﬁguration that reduces the

risk of a malicious cloud provider initiates a coalition

or accepts to be part of it.

Note that regarding the splitting of a BP model

into BP fragments and the weaving of these BP frag-

ments, we rely on previous work (Khalaf et al., 2007),

including ours (Yildiz and Godart, 2007). This is

brieﬂy illustrated in ﬁgure 3 where a simple process

is split down into three BP fragments connected with

send and receive operations for sending and receiving

orchestration messages.

2.4 Threat Scenario

Even if the decomposition of a BP process into

BP fragments offers active defense against malicious

cloud assaults, a risk still remains. Indeed, the above

solution provides active support against one malicious

cloud at a time, but does not explicitly address the risk

of conspiracy of several malicious cloud providers.

The idea is that for discovering a sensitive infor-

mation, an attacker has:

• to possess both a sensitive task and the corre-

sponding complementing one: in the context of

a BP fragments collaboration, we formalize this

risk as the ability for a cloud executing a sensitive

task to discover a path between such a sensitive

task and its complementing one, following for-

ward the send operation(s), and/or backward the

receive operation(s) of this fragment.

• to collude with clouds on the paths between such

sensitive complementing tasks.

2.5 Attacker Model

We consider in this paper the following attacker

model:

Constructed Coalitions from Paths. In this case,

we assume that a malicious cloud provider deploy-

ing a sensitive task initiates a coalition and tries to

convince all clouds on the path linking it to the one

deploying the complementing task. All paths linking

clouds are built from send and receive synchroniza-

tion messages.

For example, ﬁgure 3 represents a collaboration of

three fragments assigned to three clouds (C

, C

and C

own two complementing sensitive tasks (A

and A’), but, as there is no direct exchange messages

between C

and C

, none of them is aware of the other.

However, following the exchange messages (send and

receive operations), they can build the path(s) linking

them. If C

follows the send01 message and collude

ENASE 2023 - 18th International Conference on Evaluation of Novel Approaches to Software Engineering

532

Cloud 2 Cloud 1Cloud 3

Send01

Send02

Receive

Figure 3: BP fragments with send and receive operations.

Cloud 2 Cloud 1Cloud 3

Send01

Send02

Receive

Cloud 4

Receive

Send03

Receive

Figure 4: Pre-established coalition.

with C

, it will be able to see all exchange messages

of C

(send and receive). Therefore, from C

and fol-

lowing its send02, C

will be aware of C

while using

the path C

−C

(built from the exchange mes-

sages). Respectively, using its receive02 in a ﬁrst step,

and colluding with C

, C

will be able to reconstruct

the path linking it to C

, C

Pre-Established Coalitions. In this case, a coali-

tion may have already been initiated in a previous

execution, thus allowing a direct exchange between

two clouds (without convincing all clouds in the path

separating them to be part of the coalition), even if

no synchronization messages connect them directly

or indirectly. As seen in ﬁgure 4, Cloud 1 and 4 de-

ploying sensitive tasks are separated by other clouds

participating to the collaboration. However, a direct

link is connecting them resulting from a previous es-

tablished coalition.

3 CLOUDS COALITION

DETECTION

We present in this section an approach for detecting

malicious cloud providers that initiate or participate

to a coalition. To do that, we rely on decoy processes

having the same structure and number of data as a

real process, but with a decision strategy making and

values of data that are completely different from the

real ones.

Before diving into more details about the ap-

proach, we need to consider the following questions

• when to consider deploying decoy processes ??

• how to construct a decoy process?

• how to deploy them in a multi-cloud context?

• how to detect possible coalitions?

• how to reevaluate reputation level of malicious

clouds?

3.1 When to Consider Deploying Decoy

Processes?

More precisely, the question is: do we deploy this de-

coy process with the initial BP process ? Or do we

consider it before deploying the real process?

Our choice is to consider the decoy process be-

fore deploying the real BP process. Indeed, our ob-

jective is to detect clouds that initiate or participate to

the coalitions, to decrease their level of reputation

More precisely, we consider that a cloud initiating a

coalition is less reputable than a cloud that participate

to it, which itself is less reputable than a cloud that

neither initiates nor participates to the coalition.

After detecting those clouds and reducing their

level of reputation, the initial BP process will be

deployed following the constraints introduced in

(Ahmed Nacer et al., 2016).

3.2 How to Construct a Decoy Process?

More precisely the question is: do we keep the same

speciﬁcations as the initial process in term of number

of activities, data and gateways ?

Our choice is to respect the initial speciﬁcations

while using fake activities (black box activities) with

the same number of input/output data randomly gen-

erated for each task on the on hand. On the other

hand, we recommend to keep the same number and

type of gateways (see ﬁgure 5). This choice is moti-

vated by the following reasons:

Reputations are valued between [0,1]: 0 for a cloud not

being trusted, 1 for the most trusted one.

Clouds Coalition Detection for Business Processes Outsourcing

533

• We consider that modifying the number of activ-

ities and data can raise suspicions about the pos-

sibility of use of a decoy process. Therefore, it is

important to keep the same number with a content

modiﬁcation (using black box activity with ran-

dom generated data).

• Modifying the number and type of gateways

clearly change the general structure of the pro-

cess.

Extract specifications

acitivities

and type

of data

and type

of gateways

Construt a decoy process

using these specifications

Real process

Decoy process

Figure 5: Decoy process construction.

3.3 How to Deploy Them in a

Multi-Cloud Context?

More precisely, the question is to to which clouds the

fragments of the decoy process are assigned?

We argue that clouds deploying sensitive frag-

ments are the most likely to initiate, or participate to

a coalition. As our objective is to detect those clouds,

we recommend to :

• Separate fragments that represents sensitive activ-

ities according to the structure of the process as

follows (Ahmed Nacer et al., 2016)

– assign the fragment preceding an opening

X(OR)-split gateway and the fragment follow-

ing the corresponding closing X(OR)-join gate-

way to two different clouds.

– assign fragment preceding an opening AND-

split gateway and the fragment following the

corresponding closing AND-join gateway to

two different clouds.

– assign fragments arising from alternative ﬂows

following an OR-split gateway to different

clouds.

he alternative ﬂows following an or-split

• In the ideal case (no other functional and nonfunc-

tional constraints), to assign the remaining frag-

ments to different clouds, in order to detect as

many malicious clouds as possible.

3.4 How to Detect Possible Coalitions?

After deploying the decoy process, we analyze the ex-

change messages between the different clouds of the

collaboration. We consider that there is a potential

attempt to initiate or participate to a coalition if:

• There are messages exchanges between two

clouds deploying sensitive fragments without hav-

ing a direct synchronization messages (send or

receive) linking them in a normal scenario of the

process execution.

• There a is a synchronization message send from

a cloud C

to a cloud C

which should have been

destined to another cloud C

in a normal process

execution.

• There a is a synchronization message receive to

a cloud C

which should have been received by a

cloud C

We consider that if one of these scenarios occurs,

there is a possibility of a coalition attempt. Therefore,

the clouds considered as initiating and/or participat-

ing to the coalition are considered as malicious ones.

Before deploying the initial BP process, we need to

reevaluate their level of reputation before applying

our separations constraints introduced in section 2.2.

3.5 How to Reevaluate Reputation

Level of Clouds?

As introduced below, we consider that a cloud initiat-

ing a coalition is more malicious than a cloud partic-

ipating to it. Therefore, to reevaluate the reputations’

levels, we use the following criteria

• Attack Type: if it is a cloud initiating or partici-

pating to a coalition.

• The Number of Exchanged Messages in Each

Attack: we take into consideration the number

of exchange messages in an attack scenario. We

consider that the more a malicious cloud exchange

unexpected messages, the more it is considered as

a malicious one, reducing therefore even more its

cloud reputation.

Table 1 depicts our cloud reputation reevaluation ap-

proach for both criteria.

As seen, each cloud initiating or participating to a

coalition will be penalized on the fact of having initi-

ated/participated to the coalition. Moreover, the num-

ber of unexpected exchanged messages will be taken

into consideration. Indeed, we consider that the more

it exchange messages (send messages), the less it is

reputable, reducing therefore even more its level of

reputation.

ENASE 2023 - 18th International Conference on Evaluation of Novel Approaches to Software Engineering

534

Table 1: Clouds reputation reevaluation.

Type of attack Reevaluation based on type reevaluation based on nb

messages

Initiation Rep = Rep ∗ 1/2 Rep = Rep − (nb ∗ 0.2)

Participation Rep = Rep ∗ 3/4 Rep = Rep − (nb ∗ 0.1)

It must be noted that we consider that if a reputa-

tion level of a cloud falls below a minimum threshold,

it will be excluded from the list of candidate clouds

for the deployment of the initial BP process.

4 APPLICATION TO THE

MOTIVATING EXAMPLE

To illustrate the utility and the applicability of our ap-

proach, we apply it to our motivating example (sec-

tion 2.1) to detect the different clouds participating to

the coalition.

The ﬁrst step is to extract initial BP speciﬁcations

in terms of

• number of activities: we keep the same number

with black box activities.

• number of data : we keep the same number of

data while generating them randomly for the de-

coy process.

• number and type of gateways: we keep the ex-

act number and type of gateway (one opening and

closing X(OR) gateway and one opening and clos-

ing (AND) gateway).

Using these speciﬁcations, the resulted decoy pro-

cess is depicted in ﬁgure 6.

The next step is to deploy the decoy process us-

ing the set of clouds of table 2 according to the rules

introduced in section 3.3 as follows

• separate(A,A

′

)

• separate(B,B

′

)

• separate(C,C

′

)

• separate(C,C

′′

)

• separate(C

′

′′

)

• separate(D,E)

The resulting deployment that follows the rules in-

troduced in section 3.3 is depicted in ﬁgure 7.

As introduced in section 3.4, many scenarios can

refer to an attempt to create or participate to a coali-

tion. In this case, we can see that there is unexpected

exchange of messages between cloud 1 and cloud 5.

These two clouds are deploying sensitive fragments

without having a direct message exchange in a nor-

mal scenario. However, as seen in ﬁgure 7, cloud 5

Table 2: Cloud’s reputation.

Cloud Reputation

cloud0 0,6

cloud1 0,5

cloud2 0,4

cloud3 0,6

cloud4 0,5

cloud5 0,7

cloud6 0,1

cloud7 0,4

cloud8 0,2

sends two messages to cloud 1 which responds with a

send message. Therefore, we can conclude that cloud

5 initiated a coalition with cloud 1 which accepted to

be part of it.

Moreover, we notice that cloud 4 is sending an un-

expected message to cloud 2 thus meaning an attempt

to initiate a coalition

By applying our approach of clouds reputation

reevaluation, the new reputations of cloud 1, cloud 5

and cloud 4 is computed as follows:

• Rep(cloud1) = (Rep(cloud1) ∗3/4)−0.05 = 0.4

• Rep(cloud5) = (Rep(cloud5) ∗1/2)−(2 ∗0.1) =

0.2

• Rep(cloud4) = (Rep(cloud4) ∗1/2)−(1 ∗0.1) =

0.15

As we consider that a reputation level of 0.3 is a

threshold minimum for accepting a cloud to be part

of clouds candidate for BP deployment, the new list

of clouds candidate with new reputation levels is de-

picted in table 3.

Table 3: Clouds candidate after applying our approach.

Cloud Reputation

cloud1 0,4

cloud2 0,4

cloud3 0,6

cloud6 0,8

cloud7 0,4

cloud8 0,4

Clouds Coalition Detection for Business Processes Outsourcing

535

Decoy Process

C E

C’

C’’

B’

A’

Figure 6: The resulted decoy process.

A’

B’

C’’

Send

Receive

ReceiveSend

Normal synchronisation messages

Unexepcted messages send and

receive

Cloud 1

Cloud 2

Cloud 3

Cloud 4

Cloud 5Cloud 5

Send

C’

Figure 7: Decoy process deployment.

5 RELATED WORKS

This work is related to Business Process Outsourc-

ing (BPO) which is gaining more and more impor-

tance and where many approaches have already been

proposed (Ge et al., 2021)(Suresh and Ravichandran,

2022). In this context, Arnold and al. (Arnold, 2000)

proposed a model for BP outsourcing based on four

elements : (1) the subject making the decision of out-

sourcing, (2) the objects to be outsourced, (3) the part-

ners which are all possible suppliers for the consid-

ered objects, (4) and the design which represents the

strategy of outsourcing. In the same vein, Yang and

al. (Yang et al., 2007) proposed a methodology for de-

cision outsourcing based on the perspective, the envi-

ronment and the risk of outsourcing. However, none

of them take into account the cloud computing con-

text.

More related to the cloud context, Rekik and al.

(Rekik et al., 2015) proposed a model for selecting the

tasks to be outsourced to the cloud based on their level

of performance degradation and on the cost of deploy-

ment. Bentousni and al. (Bentounsi et al., 2012) pro-

poses an anonymization-based approach for preserv-

ing the client business activity privacy while sharing

process fragments between organizations in the cloud.

Zemni and al. (Zemni et al., 2011) propose a frame-

work for Privacy-Preserving Business Process Frag-

mentation by avoiding sensitive association. How-

ever, none of these works consider the risk of know-

how disclosure by a collusion of several clouds.

The idea of a decoy process is directly inspired

from useless code for obfuscating a software (Beau-

camps and Filiol, 2007), but we are, to our knowl-

edge, the ﬁrst using it for supporting the privacy of a

BP collaboration in a multi cloud context, while tak-

ing into consideration the possibility of coalition.

6 CONCLUSION

Companies nowadays are ready to use cloud comput-

ing technology to enjoy of its many beneﬁces. How-

ever, because of the new security risks introduced,

ENASE 2023 - 18th International Conference on Evaluation of Novel Approaches to Software Engineering

536

they must be sure that their decision strategy included

in their BP is preserved.

Even if the splitting of the process reduces the risk

of know how exposure, malicious cloud providers can

mine important information by combining their local

knowledge.

As a contribution to this topic, we proposed in

this paper an approach for detecting clouds initiating

or participating to a coalition by using a decoy pro-

cess. Each cloud participating or initiating a coalition

will have its reputation level reduced. The ﬁnal set of

clouds will be used to deploy our initial BP process.

Important cost may be incurred by introducing de-

coy processes. But on the one hand, this may be the

price to pay for know how protection, and on the other

this can be minimized by our suggestions, which man-

aged strategically BP deployment.

Regarding future works, we aim to apply our ap-

proach to a real case where we aim to use real Cloud

resources while analyzing log ﬁles, to detect the un-

expected messages.

REFERENCES

Abdmeziem, M. R. (2016). Data conﬁdentiality in the In-

ternet of Things. PhD thesis.

Abdmeziem, M. R. and Charoy, F. (2018). Fault-tolerant

and scalable key management protocol for iot-based

collaborative groups. In Security and Privacy in Com-

munication Networks: SecureComm 2017 Interna-

tional Workshops, ATCS and SePrIoT, Niagara Falls,

ON, Canada, October 22–25, 2017, Proceedings 13,

pages 320–338. Springer.

Ahmed Nacer, A., Goettelmann, E., Youcef, S., Tari, A.,

and Godart, C. (2016). Obfuscating a business process

by splitting its logic with fake fragments for securing

a multi-coud deployment. In the IEEE international

Congress on Services (SERVICES), page 8.

Arnold, U. (2000). New dimensions of outsourcing: a com-

bination of transaction cost economics and the core

competencies concept. European Journal of Purchas-

ing & Supply Management, 6(1):23–29.

Beaucamps, P. and Filiol,

E. (2007). On the possibility

of practically obfuscating programs towards a uniﬁed

perspective of code protection. Journal in Computer

Virology, 3(1):3–21.

Bentounsi, M., Benbernou, S., Deme, C. S., and Atallah,

M. J. (2012). Anonyfrag: an anonymization-based

approach for privacy-preserving bpaas. In 1st Inter-

national Workshop on Cloud Intelligence (colocated

with VLDB 2012), Cloud-I ’12, Istanbul, Turkey, Au-

gust 31, 2012, page 9.

Ge, L., Wang, X., and Yang, Z. (2021). The strategic

choice of contract types in business process outsourc-

ing. Business Process Management Journal.

Goettelmann, E., Ahmed-Nacer, A., Youcef, S., and Godart,

C. (2015). Paving the way towards semi-automatic

design-time business process model obfuscation. In

Web Services (ICWS), 2015 IEEE International Con-

ference on, pages 559–566.

Khalaf, R., Kopp, O., and Leymann, F. (2007). Maintaining

data dependencies across BPEL process fragments. In

Service-Oriented Computing - ICSOC 2007, Fifth In-

ternational Conference, Vienna, Austria, September

17-20, 2007, Proceedings, pages 207–219.

Network, E. and Agency, I. S. (2009). Cloud Computing:

Beneﬁts, risks and recommendations for information

security. ENISA.

Polyvyanyy, A., Garc

ıa-Ba

nuelos, L., and Dumas, M.

(2012). Structuring acyclic process models. Infor-

mation Systems, 37(6):518 – 538. BPM 2010.

Rekik, M., Boukadi, K., and Ben-Abdallah, H. (2015).

Business process outsourcing to the cloud: What ac-

tivity to outsource? In Computer Systems and Appli-

cations (AICCSA), 2015 IEEE/ACS 12th International

Conference of, pages 1–7. IEEE.

Suresh, S. and Ravichandran, T. (2022). Value gains in busi-

ness process outsourcing: The vendor perspective. In-

formation Systems Frontiers, 24(2):677–690.

Yang, D.-H., Kim, S., Nam, C., and Min, J.-W. (2007).

Developing a decision model for business process

outsourcing. Computers & Operations Research,

34(12):3769–3778.

Yildiz, U. and Godart, C. (2007). Towards decentralized

service orchestrations. In Proceedings of the 2007

ACM Symposium on Applied Computing (SAC), Seoul,

Korea, March 11-15, 2007.

Zemni, M. A., Benbernou, S., and Sahri, S. (2011). Pri-

vacypreserving business process fragmentation for

reusability.

Clouds Coalition Detection for Business Processes Outsourcing

537