automated certification for compliant cloud-based business processes by coreieeeprojects

8/3/2019 Automated Certification for Compliant Cloud-Based Business Processes by Coreieeeprojects

http://slidepdf.com/reader/full/automated-certification-for-compliant-cloud-based-business-processes-by-coreieeeprojects 1/10

BISE – RESEARCH PAPER

Automated Certification for Compliant Cloud-basedBusiness Processes

Cloud Computing workflows need to adhere to a variety of rules and offer high flexibility. This is at odds with the compliance certification currently being carried out in a manual

fashion. The paper presents Comcert, an approach for the automated analysis of workflows.If a workflow does not adhere to the given rules, re-usable rule patterns are used to pinpointthe workflow vulnerabilities. The results of this design time analysis can be used ascertificate by Cloud providers to signal compliance. Auditors can check the rule adherenceof workflows before workflow execution, and thanks to the rule patterns certification isopen to scrutiny by customers. Companies which so far have refrained from CloudComputing because of Compliance concerns can use the new analysis approach to check for rule adherence, and Cloud providers can demonstrate compliance through certificates.

DOI 10.1007/s12599-011-0155-7

The Authors

Dr. Rafael Accorsi ()Dipl.-Inf. Lutz LowisIIG Telematik Universität Freiburg

Friedrichstr. 5079098 [email protected]

Yoshinori Sato MScYokohama Research Laborator yHitachi

292 Yoshida-cho, Totsuka-ku,Yokohama244-0817 KanagawaJapan

[email protected]

Received: 2010-07-01Accepted: 2011-02-09Accepted after three revisions by

Prof. Dr. Müller.

This article is also available in Ger-

man in print and via http://www.wirtschaftsinformatik.de: Accorsi R,Lowis L, Sato Y (2011) AutomatisierteCompliance-Zertifizierung Cloud-ba-

sierter Geschäftsprozesse. WIRT-SCHAFTSINFORMATIK. doi: 10.1007/s11576-011-0269-z.

© Gabler Verlag 2011

1 Automating the Certificationof Business Processes

Certifying the adherence of business pro-cesses to compliance requirements is akey issue in the large-scale deployment of reliable Cloud Computing (Hayes 2009;ENISA 2009; CSA 2009, 2010). It mustbe checked that moving (parts of) busi-ness processes into the Cloud does not vi-olate existing rules, and that the processes

also adhere to new rules which the useof Cloud Computing may bring along.Currently, many companies refrain fromCloud Computing because of complianceconsiderations, most of all security andprivacy related ones.

Sustainable Cloud Computing includesthe capability of provably keeping con-trol over processes’ compliance. How-ever, two issues prevail on the way toachieving certification. Firstly, tools forautomating certification procedures aremissing. In consequence, certification isa long-winded, error-prone procedure.

This is at odds with the increased flex-ibility stemming from the realizationof Clouds as a means for companiesto timely adapt their business processeson demand. Secondly, the simultaneousconsideration of a multitude of regu-lations and contractual rules increasesthe complexity of checking compliance.A uniform way of expressing the resultingrequirements has not yet been establishedand research results are lacking (Breaux2009 is a notable exception). Overall,this situation and the associated risks of noncompliance inhibit enterprises from

outsourcing their tasks onto the Cloud(Chow et al. 2009) and, in general, pre-vent the full realization of the economi-cal potential of Cloud Computing (Etro2009).

Addressing these two issues, this pa-per presents a thorough classificationof compliance rules. Drawn from ma-

jor compliance regulations, the resul-tant requirements categorization com-prises three rule classes for which for-mal patterns are provided. Building uponthis classification, the paper introducesComcert, an approach for the automatedcompliance certification of business pro-cesses. Comcert employs Petri nets (Mu-rata 1989) as a notation-independent,uniform formalism to specify both busi-ness processes and compliance rules.Similar to security automata (Schneider2000), Petri net patterns modeling therules are analyzed in parallel to the pro-cess specification, flagging when the pro-cess structure indicates a rule violation.This gives Comcert a constructive char-

acter as it automatically identifies designvulnerabilities in process specifications.

Comcert thus contributes to automat-ing the certification of processes in theCloud and, in consequence, fostering itswider deployment. Allowing workflowsto be checked for compliance rules, in-cluding security and privacy rules, Com-cert helps to make Cloud Computing areal option for companies. Due to theuse of a general Petri net formalism, theapproach does not rely on a particularprocess notation, such as Business Pro-cess Modeling Notation (BPMN), Busi-

Business & Information Systems Engineering

IEEE TRANSACTIONS ON BUSINESS & INFORMATION SYSTEMS,Volume 3, Number 3 2011

mailto:[email protected]


http://www.wirtschaftsinformatik.de/


http://dx.doi.org/10.1007/s11576-011-0269-z

http://dx.doi.org/10.1007/s11576-011-0269-z

http://dx.doi.org/10.1007/s11576-011-0269-z

http://dx.doi.org/10.1007/s11576-011-0269-z








Fig. 1 Health care scenario with exemplary workflows

ness Process Execution Language (BPEL)

or Event-driven Process Chain (EPC).Checking both the control flow and thedata flow for rule adherence, Comcertprovides well-founded, reliable evidenceof (non)compliance.

Section 2 presents the motivation be-hind Comcert. Along with a Cloud-basedE-Health scenario with HIPAA rules asrunning example, a description of Com-cert’s use cases is given. Section 3 sum-marizes a selection of compliance textsand extracts a classification of compli-ance rules. From the classification, rulepatterns will be derived in Sect. 4, whichalso introduces the Comcert analysis al-gorithm. Section 5 concludes the paper.

2 Scenario Illustration

Of the many regulations that include us-age control requirements, the U.S. HealthInsurance Portability and Accountability Act (HIPAA 1996) is one of the mostdetailed ones. HIPAA regulates the useof protected health information (PHI)in business processes. Figure 1 illustrates

the E-Health scenario, using exemplary workflows and HIPAA rules. The sce-nario comprises a Cloud-based providerof electronic health records (EHR) andlocal health providers such as hospitalsand dentists. Each party has its ownworkflows, and some of the workflowsare connected to workflows of other par-ties. Note that Fig. 1 is not an actual pro-cess model, but a schematic representa-tion of the involved parties, their work-flows, and according HIPAA rules.

A workflow is a discrete and case-basedbusiness process, i.e., it has a defined start

and end point and handles a specific in-

stance of a business process. The twomain characteristics of a workflow are itscontrol flow and its data flow. The controlflow describes which activities happen inwhat order , and the data flow describeswhich data and resources are exchangedbetween these activities. For example, theCloud-based EHR provider in Fig. 1 runsa workflow that contains a control flowfrom the “request amendment” activity to the “amend PHI” activity. The dataflow consists of the incoming request andthe PHI amendment between the two ac-

tivities.In Fig. 1, a patient uses an online

EHR, such as Google Health or MicrosoftHealthVault offer. The EHR provider in-teracts with third parties such as hospi-tals and dentists. However, based on thepatient’s right to have her PHI amended(HIPAA:164.526a), the patient may re-quest – in this case, she does so throughthe EHR provider – that third parties up-date their records accordingly. Third par-ties, in turn, are obliged to forward theperformed amendments to all other rel-

evant parties (HIPAA:164.526c). Accord-ing to HIPAA:165.526e, these third par-ties must accept the amendment and per-form the corresponding updates.

The general scenario is that of a com-pany which wants to use Cloud ser-vices. Three questions result, one each re-garding the company, the auditor(s) andthe company’s customers. First, the com-pany would like to identify the parts of its business processes that can be out-sourced without violating rules regard-ing, for example, the location of serviceexecution. Second, auditors have to check

the rule adherence of the (partially) out-

sourced business processes. Third, cus-tomers should have the ability to assesswhether the “new” business processestreat personal data in a way that con-forms to privacy policies.

Current workflow analysis techniqueschiefly focus on control flow, i.e. onthe detection of activity errors causedby flawed workflow design, e.g. van derAalst (2003), Ehrig et al. (2007), Wongand Gibbons (2008). Ghose and Koliadis(2007) – and similarly Governatori et al.(2009) – present an approach for audit-

ing workflows for compliance that fo-cuses on activities and time limits. Theseapproaches employ modal temporal logicfor the analysis of workflows specifiedin BPMN. Focusing exclusively on data,Meda et al. (2010) introduce an approachfor checking data flows, and Atluri et al.(2001) present an approach for reasoningabout confidentiality properties in work-flows. Monakova et al. (2009), Liu et al.(2007), and Trcka et al. (2009) present anapproach for the automated verificationof BPEL processes which combines both

data flow and control flow perspectives.These approaches neglect usage controland, hence, cannot check for all of thecompliance requirements (see Sect. 3).For this reason, Comcert includes usagecontrol checks.

Given a workflow model and a set of rules, Comcert can answer all three ques-tions. Technically, there really is only onequestion: “Does workflow W adhere torule R?” From an organizational perspec-tive, the three views company, auditor,and customer differ because of the in-formation being available to each. The






company has all details at hand. The au-ditor sees what the company gives him– this can, but may not be every detail.The customer sees little to none of thebusiness process’ details. In the following,we focus on the technical rule adherencecheck, assuming that the relevant pieces

of information are available. Third par-ties, checking company details on behalf of the customers and creating compliancecertificates for public display, will not befurther discussed in this article.

3 Compliance Regulation Surveyand Classification

Given the strong demand for compliance,two questions emerge. First, which rulesdo workflows have to adhere to? Second,how can the rule adherence be checked?

The remainder of this section presents asurvey of compliance regulations to an-swer the first question. Section 4 will an-swer the second question by introducingthe Comcert approach.

3.1 Compliance Regulation Survey

OECD Guidelines The “OECD Guide-lines on the Protection of Privacy andTransborder Flows of Personal Data”(1980) define eight principles: the col-lection limitation, data quality, pur-pose specification, use limitation, secu-rity safeguards, openness, individual par-ticipation and the accountability prin-ciple. Organizational processes are nec-essary to, e.g., achieve high data qual-ity through record updates, or to fol-low the openness principle by inform-ing customers about the uses of personaldata. Regarding workflows, the princi-ples mainly concern the data flow. Datacollection should be limited (“collectionlimitation”) to the amount required fora specific purpose (“data quality”), anddata usage should not exceed that specific

purpose (“use limitation”).

European Community Directive 95/46/EC Within the European Community, theDirective 95/46/EC regulates “the pro-tection of individuals with regard to theprocessing of personal data” and “thefree movement of such data” (Euro-pean Commission 1995). Workflows ad-here to this directive if they use dataonly for a specific and specified pur-pose (95/46/EC:6.1.b) and do not usemore data than necessary for that pur-pose (95/46/EC:6.1.c). Companies shall

keep identifying personal data only aslong as necessary for a certain purpose(95/46/EC:6.1.e), shall obtain the cus-tomer’s consent to use personal data(95/46/EC:7.a), may not use certainkinds of personal data (95/46/EC:8.1),and have to inform customers about

how the companies use personal data(95/46/EC:10,12). In general, the appro-priate security mechanisms have to beused (95/46/EC:17.1), and personal datamay only be transmitted to other coun-tries if those countries provide an appro-priate level of security and privacy for thedata (95/46/EC:25).

German Tele Media Act (TMG) TheTMG describes how and what personaldata may be collected and used by onlineservices (TMG 2009). Specifically, per-sonal data (“personenbezogene Daten”)

may only be used in workflows if eitherthe law requires their use or the cus-tomer has given her consent (TMG:12).Companies must announce their privacy policy (TMG:13). Service usage must bepossible without being observed by oth-ers, and profiles may, if at all neces-sary, only be created using pseudonyms(TMG:13.4). Only the required personaldata shall be collected (TMG:15.1), andbilling shall not reveal usage detailsunlessotherwise agreed upon by the customer.

German Federal Data Protection Act (BDSG) The BDSG (2009) refines theDirective 95/46/EC and allows the pro-cessing of personal data only if permit-ted by law or the explicit consent of a customer (BDSG:4). Transmission of personal data to third parties, possibly in other countries, may only happen if an appropriate level of security is given(BDSG:4.b). Customers have the rightto have their records updated or deleted(BDSG:6). Technical and organizationalsecurity must be provided by the process-

ing company, mainly access control andusage control (BDSG:9). Third partiesproviding additional processing must ad-here to the same rules (BDSG:11). Also,processing must follow a certain purpose(BDSG:28), and companies must informtheir customers about how personal datais being used (BDSG:34).

Gramm-Leach-Bliley Act (GLB) Focus-ing on the financial sector, the GLBmostly describes affiliations betweenbanks, securities firms, and insurancecompanies (GLB 1999). GLB:501 a and

b demand that so-called “nonpublic per-sonal information” (NPPI) must be pro-tected by establishing appropriate secu-rity standards. GLB:502 forbids disclos-ing NPPI to third parties, neither directly nor through affiliates. GLB:503 demandsthat financial institutions inform cus-

tomers about the current privacy pol-icy. The related, cross-sector regulationSarbanes-Oxley-Act (SOX 2002) is evenmore abstract from a workflow pointof view and does not contain any rulesdirectly pertaining to workflows.

Health Insurance Portability and Account-ability Act (HIPAA) The HIPAA Ad-ministrative Rule regulates the use of health data. Of the presented compliancesources, HIPAA is the most detailed oneregarding workflow rules. For this reason,it serves as our running example and con-cludes this survey.

While the security part (subpart C of part 164) demands general security pre-cautions, the privacy part (subpart E of part 164) describes how PHI may beused in workflows. Based upon a “defaultdeny” approach (HIPAA:164.502.a), PHImay only be used or disclosed for treat-ment, payment, or health care operationspurposes (HIPAA:164.502.a.1). A “min-imum necessary” (HIPAA:164.502.b) re-quirement holds for both the senderand the receiver of PHI: If a contracted

third party receives PHI which it doesnot require by the contract, the re-ceiving side is obliged to inform thesending side (HIPAA:164.504.e.2.ii.C).As usual, the patient’s consent mustbe obtained before using or disclos-ing any PHI (HIPAA:164.506.a.1) andif PHI is used or disclosed withoutconsent, this must be documented andresolved later (HIPAA:164.506.a.3.C.ii).Certain PHI may be used without au-thorization, e.g., for directory purposeswithin a hospital (HIPAA:164.510.a.1),

but other PHI require extra authoriza-tion to be used/disclosed, e.g., psy-chotherapy notes (HIPAA:164.508.a.2).Patients may request to restrict the useand disclosure of their PHI to cer-tain elements (HIPAA:164.502.c), havea right to be informed about theirPHI (HIPAA:164.524.a.1) within a cer-tain amount of time (30 days, seeHIPAA:164.524.b.2.i). Also, patients havethe right tobe providedwith a listof theirPHI’s disclosures over the last six years(HIPAA:164.528), and may ask to havetheir PHI amended (HIPAA:164.526.a.1).






Table 1 Classification of Compliance Rules

HIPAA 95/45/EC OECD BDSG TMG GLB

↔ Inform customers about policy/usage√ √ √ √ √ √

↔ Obtain customer consent√ √ √ √ √

↔ Check third parties√ √ √ √

↔ Update customer records √ √ √ ↔ Delete after use

√ √

Treat special data separately √ √

Use for specific purpose√ √ √ √ √

Use pseudonyms or de-identify √ √ √

Limit to minimum necessary √ √ √

Such amendments must then be for-warded by the amending institution(HIPAA:164.526.c), e.g., a hospital, to allinvolved parties which must accept that

amendment (HIPAA:164.526.e) and up-date their records accordingly.

3.2 Compliance Rule Classification

The workflow related sections of theabove compliance regulations can be or-ganized in a few basic classes of rules, asshown in Table 1.

The rule categories in the second leftcolumn were obtained by sifting throughthe compliance sources in the top rowand listing all rules that directly pertain toeither the control flow (e.g., some activity

has to happen before another) or the dataflow (e.g., treatment of documents andtheir content) of workflows. After consol-idating those rules that only used slightly different wording to describe the same re-quirement, the nine categories remained.

Given these nine categories, we trans-formed the corresponding rules into aPetri net representation as described inSect. 4. Then, we analyzed the represen-tations for similarities and differences. Itshowed that most of the rules (5 out of 9)referred to the order of activities, and two

each referred to the workflow’s branchingconditions and the data being processed.The resulting three rule classes are sym-

bolized by the icons in the very left col-umn. A double headed arrow for cat-egories that require certain activities to(not) be performed before or after otheractivities. A single headed branching ar-row for categories describing the flow of data. Finally, a rectangular label standsfor categories directly relating to data el-ements.

Access control is important for Cloud-based workflows, but it is not sufficient

for covering all the above rule classes.While access control covers the first re-lease of data, it neither covers furtherreleases nor additional uses. In the E-

Health scenario, a health professionalcould obtain PHI with the stated pur-pose of treatment, and then use it for an-other purpose, e.g., advertising, in a fol-lowing activity. In contrast to other clas-sifications and taxonomies of compliancerequirements, such as (Breaux and Antón2008), (Wagner 2002) and (Sadiq et al.2007), which address only a single legis-lation, the classification presented drawsits categorization from different legisla-tions, thereby being more suitable forCloud providers, which have to simul-taneously comply with multiple regu-

lations and contractual terms (service-level agreements). In particular, Com-cert checks usage control, without whichmany compliance requirements cannotbe covered. This way, the new approachextends previous work in usage control(Park and Sandhu 2004 provide a modelto capture usage control rules, Pretschneret al. 2006 present an enforcement mech-anism) to the analysis at designtime.

4 The Comcert Approach

Petri nets are well-suited for reasoningabout workflows (van der Aalst 1998), asthey provide an adequate formal seman-tics for workflow specifications in BPMN,BPEL and EPC (Lohmann et al. 2009).Building upon their standard definition(Murata 1989), Comcert uses Petri netsto formalize both workflows and rules.Under the assumption that, with theirgraphical representation, Petri nets aremore intuitive than the complex formu-las of, e.g., linear temporal logic, this of-fers the advantage of making the com-pliance check comprehensible for a wider

group of users while still delivering soundresults.

The main idea behind Comcert’s analysis is to transform a workflow into onePetri net and the rules into additionalones. Rule adherence is determined by traversing each path of the workflow

and triggering the according transitionsin the rule Petri net (RPN) for eachworkflow activity. Similar to security au-tomata (Schneider 2000), each RPN con-tains special places which, after the work-flow has been traversed completely, eitherindicate rule adherence or a violation.

Comcert is suitable for the automateddetection of design vulnerabilities atworkflow level. Regarding other levels,such as software and hardware, differentapproaches are required (Lowis and Ac-corsi 2010). Overall, certification and ver-ification techniques are tailored for a par-

ticular workflow notation. Comcert ab-stracts away from the particular notationand employs a Petri net meta-model forboth the workflow and the rules, resp.compliance requirements representation.

Details of Comcert’s Petri net defini-tions will be given when introducing theanalysis patterns. First, we discuss thetransformation of workflows and rulesinto Petri nets.

4.1 Workflow Representationand Transformation

Workflow nets are employed as a tar-get meta-model to formalize workflows(van der Aalst 1998). A workflow net isa special kind of Petri net with distinctsourceand sink places where allthe nodeslie on some path between the source andthe sink place. A token in the source placedenotes a new execution (so-called case),whereas a token in the sink place denotesa complete execution (end of a case). Thefollowing illustrates the transformationof workflows into workflow nets.

Example 1 BPMN offers three main el-ements for the formalization of a work-flow’s control flow: activities, events, andgateways. Figure 2a illustrates some of these elements. The boxes stand for ac-tivities (or tasks), x-gateways for the ex-clusive choice (left-hand side) and simplemerge (right-hand side). The circle in theleft denotes the start event, whereas thebold circle in the right stands for the endevent.

The corresponding workflow net de-rived from Fig. 2a is depicted in Fig. 2b.






Fig. 2 Exemplary BPMNand workflow netrepresentation

Place p2 is called an “OR-split” and p3 an“OR-join”.

The transformation of workflow de-scriptions into workflow nets can be gen-erally automated, e.g., with Oryx (2010)and SAP Galaxy (Saha 2008). The pre-cision of the generated model variesaccording to the source workflow. ForBPMN, for example, there are mappingswhich restrict the original model to hav-ing a single start and end event (Dijkmanet al. 2008). Moreover, activities withmultiple concurrent instances, as well assome kinds of gateways, such as OR-

gateways, cannot generally be mappedinto workflow nets. Similarly, only aparticular class of EPC models can bemapped into workflow nets (van Don-gen et al. 2007). In contrast to that,the “feature-complete” transformation of BPEL workflows is possible, e.g. withWofBPEL (Ouyang et al. 2005). Com-cert uses workflow nets with extendedannotations. It employs the tool BW2PN (IIG 2010) to transform a BPEL workflowwith its WSDL specification into a Petrinet stored as Petri Net Markup Language(PNML). BW2PN ignores certain BPEL

features such as fault or exception han-dlers, so that compact, small Petri netscan be created. This is a trade-off be-tween feature completeness and readabil-ity. If the scenario demands including ex-ception handling, other tools can be usedto create feature complete Petri nets.

4.2 Comcert Patterns for ComplianceRule Representation

Comcert assesses the compliance of aworkflow by analyzing the five estab-lished elements required to check for rule

adherence in workflows: activities, data,location, resources, and time limits (Cur-tis et al. 1992; Stohr and Zhao 2001;Sadiq et al. 2007; Svirskas et al. 2007;COMPAS 2008; Breaux 2009; Cabanillaset al. 2010).

A rule describes which activities may,must or must not be performed on whatobjects by which roles. In addition, a rulecan further prescribe the order of activ-ities, i.e. which activities have to happenbefore or after other activities.

The formalization of rules as Petri netspatterns has been proposed by Katt et al.

(2009) and Huang and Kirchner (2009).In contrast to Katt et al., Huang andKirchner cannot cope with the expressionof usage control policies. Katt et al. em-ploy Usage Control Colored Petri Nets(UCPN) for the formalization and en-forcement of diverse types of obligations,i.e. actions to be performed before, dur-ing and after an activities. However, theirapproach assumes that the rules are inte-grated into the workflow, so that UCPNcannot be singled out for reuse for otherworkflows. Acting as a security automata

(Schneider 2000), rules in Comcert arecaptured as Petri net patterns and are notintegrated into the workflow. Togetherwith the classification of compliance re-quirements, this makes it possible to or-ganize compliance rules in categories ac-cording to their intent and semantics,thereby facilitating their formalization asre-usable Petri net patterns or templatesin other modular policy languages for us-age control.

Comcert captures rules as Petri net pat-terns. A rule Petri net (RPN for short)consists of the standard Petri net ele-

ments places P (depicted as circles), tran-sitions T (rectangles), arcs A (lines) andtokens (dots). Arcs connect either P toT or T to P , and tokens are alwayscontained in a place. Places immediately leading to a transition are this transition’ssource places, places immediately follow-ing a transition are this transition’s sink

places. A transition is active if its sourceplaces contain tokens; an active transitioncan fire. Upon firing, a transition con-sumes tokens from its source places and

produces tokens in its sink places. Stan-dard firing behavior is to consume one

token of each source place and to produceone token in each sink place.

Within a Cloud-based workflow, mul-tiple locations can be involved in oneworkflow, especially when services areoutsourced to other countries. Each ele-ment of a net can carry predicates, whichare used to describe further details, e.g.,about the location of an activity or theemergency status of a patient. Such pred-icates are used to enable extended firingbehavior.

Extended firing rules are introduced tomake the firing behavior of some transi-

tions deterministic (in Fig. 3, determin-istic transitions resp. transitions with ex-tended firing rules carry a dotted rect-angle inside). These transitions fire independency of token and activity predi-cates, including tokens (not) being avail-able in certain places. In Fig. 3 for exam-ple, transition A in Pattern a fires in de-pendency of an activity’s location, tran-sition B in Pattern e fires in dependency of a token being present in the place

flag . Using extended firing rules reducesthe visual complexity of the RPNs be-cause it requires (in some cases, much)






Fig. 3 Rule Petri net patterns (excerpt)

fewer places and transitions than a stan-dard Petri net would require for the sametasks.

RPN places can have different seman-tics, the two most important ones are in-dicated by OK and ERR in Fig. 3. A to-ken in OK signals rule adherence of thecorresponding workflow path. Rule vio-lations are identified through tokens inERR. Section 4.3 will sketch how tokensand workflow paths are linked throughthe coloring resp. numbering of tokens.

Transforming and refining a naturallanguage policy into a RPN is supportedthrough RPN patterns. Rules for each of the five elements activities, data, loca-tions, resources, and time limits can betransformed with these patterns. Because

of space constraints, we only present a se-lection of patterns in the remainder of this section.

Pattern a in Fig. 3 serves to detect thepresence of required activities. As long asthe activity A (transition A in the pattern)is not found in the workflow model, theRPN remains in its initial state, indicat-ing an error through a token in the placeERR. If and when the activity A is en-countered while scanning the workflowmodel, transition A in the RPN fires. Thisremoves the token from ERR and createsa new one in OK . At the end of the work-

flow, the RPN then shows adherence tothe rule that activity A must be presentin the workflow: a token in OK signalsadherence, a token in ERR means a vio-lation. Inverting the semantics (OK be-comes ERR and vice versa) allows check-ing for the absence of forbidden activi-ties.

With the RPN Pattern b, it is straight-forward to check for the location of anactivity’s execution. When the activity Ais found in the workflow model, the tran-sition A fires in dependency of the ac-tivity’s location, which must be available

through, e.g., an annotated predicate. If the location matches the required one, atoken in OK is created, signaling rule ad-herence. A forbidden location causes the

production of a token in ERR, indicat-ing a rule violation. Because the workflowmodel may contain the activity A mul-tiple times, the firing does not consumeany tokens, which again is part of the ex-tended firing behavior.

If data elements must be processed by a certain activity after their first occur-rence in the workflow model, Pattern c can check adherence to this rule. The firstoccurrence of the data element dat causesthe transition dat to fire and produce atoken in ERR, where it remains as long asthe activity A does not process the data

element in the workflow model. Transi-tion A will remove the token from ERRand create a new one in OK otherwise.

The deletion of a data element beforethe workflow’s end can be checked forwith Pattern d. When a token in flag shows that the data element dat has beenused, an activity that deletes dat will trig-ger the transition Del which removes theflag token and creates a new one in OK . If dat has not been deleted when the work-flow reaches its end, the transition Endputs a token in ERR.

Typical correctness or soundness re-quirements for Petri nets include beingfree of deadlocks, leading from start toend on all or at least one path, andnot leaving any tokens in non-end places(Trcka et al. 2009). Tokens are possibly left behind when an AND switch is fol-lowed by an OR join. The notion of “cor-responding pairs” has been introducedfor the according analyses (Liu and Ku-mar 2005). Pattern d has the same struc-ture as the pattern for correspondingpairs of AND switches with AND joins.Assume the renaming of dat to AND-

switch, Del to AND-join, and End to OR- join. For every opening AND switch inthe workflow, a token in flag is created. If a closing AND join follows, the flag token

is deleted and a new one is put in OK , in-dicating a corresponding pair. If a closingOR join follows, the flag token is deletedand ERR receives a new one, signalingthat potentially, at this point a token hasbeen created in the workflow model with-out being consumed before the end of theworkflow.

Checking for the order of activities ismore complex, as Pattern e shows. Therule is that activity B may only happen if activity A was performed before. In thepattern, transition A fires when activity

A is found, producing a token in place

OK/flag . Upon activity B in the workflowmodel, transition B fires. Both transitions

A and B have extended firing rules. If a to-ken in OK/flag is present, activity A hasbeen performed before and B creates atoken in OK . If OK/flag is empty, a to-ken in ERR is created, showing that Boccurs in the workflow model before A,which is against the rule. To further sup-port the analyst, the pattern will also in-dicate if the activities A and B happen inthe wrong order. In that case, B will haveproduced a token in ERR before A fires.

If A finds a token in ERR, it produces atoken in the place WrongOrder instead of OK/flag .

Some rules set time limits for startingor ending an activity, but actual execu-tion times cannot be determined at de-signtime. Still, even at designtime evi-dence of possible violations can be ob-tained by assuming the use of control ac-tivities. Such control activities check theactual execution times during runtimeand create a warning if a time limit ruleis violated. Checking for the presence of such control activities in the workflow






Fig. 4 Comcert analysis algorithm

model, Comcert indicates possible viola-tions of time limits. With a pattern simi-lar to Pattern e, Comcert checks whethera workflow model contains the requiredcontrol activities in the desired order.Please note a small but important differ-ence to Pattern e: While in Pattern e, therule allows that A occurs without B fol-lowing, in the pattern for control activi-ties it is a rule violation if A occurs with-out an afterward control activity.

4.3 Comcert Analysis

The compliance survey in Sect. 3 shows

that although compliance regulationscontain various rules, the compliance orrule adherence of workflows can be deter-mined by checking for a few types of ruleclasses. Analyzing the control flow anddata flow in a workflow model with re-spect to the five elements activities, data,locations, resources, and time limits cov-ers these classes. While presenting theanalysis algorithm, the Petri net contain-ing the workflow will be referred to asworkflow model, and the Petri nets con-taining the rules will be referred to as

RPNs.Filling the patterns of Sect. 4.2 with ac-tual values that correspond to a workflowleads to RPNs that are ready for anal-

ysis. The names of activities, data ele-ments, locations and resources should beused consistently between the workflow,the workflow model, the natural languageor XML-style rules, and the RPN. With-out consistent naming, a mapping mustbe available so that the analysis algo-rithm can determine which element inthe workflow model corresponds to whatelement in the RPN.

For the patterns that carry predicates,the workflow and rule attributes must beassigned to the transitions andtokensof aRPN. Comcert uses colored Petri net to-kens to differentiate between control flowtokens and data flow tokens. In addition,data flow tokens have colors that indi-cate the type of data elementand resourcethey represent.

Comcert analyzes a workflow modelfor rule adherence by following each pathfrom the workflow’s start to its end andtriggering the corresponding RPN transi-tions along the way. Correspondence de-pends on several aspects. Basically, the

names of workflow and rule transitionsare compared. Upon encountering a cer-tain workflow transition, the rule transi-tions with the same name are triggered,firing if the required tokens are availablein the RPN.

The extended firing behavior men-tioned above results from consideringpredicates and the available tokens. Foreach source place it can be defined howmany (including null) tokens of whichkind (control token, data elements to-ken) are required for firing and will be

consumed when firing. How many andwhich tokens will be produced in whichsink place can be defined accordingly.

For some of the patterns, a transitionname comparison is sufficient, e.g., forPattern a that checks for the presenceof required activities. Checking for datadeletion as in Pattern d requires that ei-ther there is a transition with a uniquename, e.g., “delete”, or that a transitioncarries a “delete” annotation.

Some patterns will always yield aboolean decision, e.g., checking for a re-quired order of activities with Pattern e.

Other patterns depend on certain predi-cates being evaluable, i.e., certain work-flow model attributes being available. Forpractical application, those patterns canbe extended with an end place that sig-nals an unresolved analysis result. For ex-ample, Pattern b would then indicate ruleadherence with tokens in OK , rule vio-lations with tokens in ERR, and occur-rences of unresolved cases with tokens ina place called, e.g., UNRES. Comcert sup-ports the indication of missing annota-tions by creating “unresolved” tokens of a certain color whenever the rule adher-ence of a workflow activity, data element,

resource or time limit cannot be resolved.While visiting each path through theworkflow model, Comcert triggers theapplicable RPNs, so that finally, the RPNtokens indicate rule adherence or ruleviolation, depending on the semanticsof the place they reside in. Each pathreceives its own number, following thescheme of binary trees, but extended tomore than two possible branches. Forexample, 3.4.1 marks the path that isreached when taking the third branch of the first split, then the fourth branch of the second split, and the first branch of

the third split. For space reasons, furtherdetails have to be omitted. Analysis withthis numbering scheme allows an unlim-ited number of branches and includesloop detection. Analysis complexity willbe discussed below.

With a workflow model and a set of RPN at hand, the Comcert analysis algo-rithm is described by the pseudo code de-picted in Fig. 4.

Example 2 In the Workflow 1 (top of Fig. 5), a hospital requests PHI for treat-ment purposes. The EHR provider then






Fig. 5 Exemplary workflow with according rule Petri net

wants to create a document out of thisPHI and send it to a third party. How-ever, instantiating Pattern e for the or-

der of activities, the RPN (right side of Fig. 5) rules that the activity “ObtainConsent” must be performed before theEHR provider is allowed to “Send Docu-ment”. Upon finding the workflow transi-tion “Obtain Consent” after “Send Doc-ument” in Workflow 1, Comcert sets theRPN to the state “WrongOrder” (indi-cated by the token “1” in the RPN). Thisinformation can be used to fix the work-flow.

Now let us assume the workflow con-tains the required activities in the correct

order as shown in Workflow 2 (bottom of Fig. 5). “Send Document” happens after “Obtain Consent”, so a token (numbered“2” in Fig. 5) in the place OK is created.In this case, the workflow adheres to therule and a corresponding certificate canbe issued.

Some other approaches first create alltraces (paths through the Petri net) andthen analyze those traces in a second step(Meda et al. 2010). Comcert performsboth tasks at once by creating uniquecontrol tokens for each workflow pathwithin the Petri nets. Flooding the net in

this way makes sure that every path is vis-ited while at the same time allowing theanalysis of single traces resp. paths.

Comcert, just like other Petri net analysis algorithms, has to cope with the statespace explosion problem. In the worstcase, the analysis runtime is exponentialto the number of branching places andtransitions in the workflow model. We donot expect this to be a problem in prac-tice, because typical industrial workflowsdo not contain more than a few hundredactivities. For example, the Comcert pro-totype analyzed a workflow model that

contained more than 300 places and 300transitions, resulting in more than 7000workflow paths, in less than 2 seconds on

a 1.2 GHz processor, using less than 6MBof memory. While tests have shown thatnested loops considerably increase analy-sis time andmemory usage, typical work-flow models consisting of up to a fewhundred placesand transitions can be an-alyzed in seconds. In fact, small work-flows of about 100 activities mostly re-quired less than 15 ms to analyze.

The above example exhibits a usefulproperty of Comcert. Besides the cer-tification of a workflow, the approachalso provides for pointers to flaws in theworkflow, along with the affected part of

the rule being violated. For example, theannotated error state that results fromthe analysis of the flawed Workflow 1 inFig. 5 identifies the missing activity “ob-tain consent” between Step 1 and Step 2of the workflow. With patterns such asPattern e, Comcert is able to even identify those activities in the workflow that occurtoo late, i.e., would make the workflowadhere to the rule if they occurred ear-lier. When activities occur in the wrongorder, such as “obtain consent” and “senddocument” in Fig. 5, the required order

of activities can be displayed to the an-alyst. Based on this automated identifi-cation, flaws can be corrected with auto-mated process rewriting as described by Höhn (2009).

5 Summary

A chief requirement for the provisionof sustainable Cloud Computing is theability to certify the adherence of busi-ness processes to regulatory require-ments. Currently, certification is manual,

which is definitely at odds with the dy-namics and flexibility offered by, e.g., theSoftware as a Service paradigm. The busi-

ness models behind modern service tech-nologies in general and Cloud Comput-ing in particular essentially depend onbusiness processes being tailored to theindividual needs of customers. Failing toreliably support adaptivity will hamperthe widespread adoption of Cloud Com-puting.

This paper provides two main contri-butions: A classification of compliancerules, and Comcert, an automated ap-proach for the certification of businessprocess compliance. Comcert is a well-founded approach based on Petri nets

that allows a company, an auditor or acustomer to check whether a businessprocess, formalized in standard languagessuch as BPMN and BPEL, adheres tocompliance requirements. In the eventof noncompliance, the resultant evidenceindicates the flawed fragments of the pro-cess. To further facilitate the certificationprocess, this paper also classifies recur-ring types of compliance requirements,demonstrating how to formalize them asPetri net patterns for subsequent verifica-tion.

The analysis results do not formally prove that under all circumstances theworkflow will adhere to all compliancerules at runtime. Rather, Comcert pro-duces evidence of a workflow model’srule adherence, or, in the case of non-adherence, identifies design vulnerabili-ties. For example, in the health care sce-nario, compliance violations can be iden-tified at a very early point in time, sothat design vulnerabilities regarding thetreatment of EHR data can be resolvedbefore patients file HIPAA complaints.This avoids or reduces remediation costs,






which typically are very high when vul-nerabilities are fixed later. Even thoughno formal proof in the strict sense isachieved, a complete analysis in the styleof model checking is performed. The re-sults are summarized in a compliancecertificate that demonstrates the work-

flow’s rule adherence.Completeness of the checks is achievedin the sense that for all defined rule pat-terns, every occurrence of a pattern isdetected within the workflows. However,rule pattern completeness is undecidablein general, because there is no formal way of proving that future attackers will notbe able to think of new attacks againstwhich additional rules would have to bedefined. Overall, the goal of Comcert isto ease and automate compliance checksand provideadequate tool support. Com-panies can use Comcert to check work-

flows for rule adherence, either whenabout to put (parts of) their own work-flows into the Cloud, or for certificationto signal potential industrial or privatecustomers that data will be processed ina compliant way.

Experiments carried out with Com-cert demonstrate that it effectively detectspossible compliance violations in work-flows. While the rule patterns – captur-ing explicit information flow, i.e., con-trol flow and data flow characteristics –account for the most relevant proper-ties in practice, subtle structural vulner-abilities within the implicit informationflow cannot yet be detected using Com-cert. Such subtle vulnerabilities poten-tially lead to information leaks, which arenot acceptable in high security scenarios.To also suit to such certification (Accorsiand Wonnemann 2011), we plan to ex-tend Comcert with patterns to identify the so-called “covert-channels” (Lamp-son 1973).

References

Accorsi R, Wonnemann C (2011) Strong non-leakguarantees for workflowmodels. ACM,SAC, pp. 308–314

Atluri V, Chun SA, Mazzoleni P (2001) A Chi-nese wall security model for decentral-ized workflow systems. ACM conferenceon computer and communications secu-rity. ACM, New York, pp 48–57

BDSG (2009) Bundesdatenschutzgesetz. Ger-man Federal Ministry of Justice

Breaux TD, Antón AI (2008) Analyzing regula-tory rules for privacy and security require-ments. IEEE Trans Software Eng 34(1):5–20

Breaux TD (2009) Legal requirements acquisi-tion for the specification of legally compli-ant information systems. PhD thesis, NorthCarolina State University

Cabanillas C, Resinas M, Ruiz-Cortés A (2010)Hints on how tofacebusinessprocesscom-pliance. In: Resinas M, Ruiz-Cortés A, PastorJA, SanchoMR (eds) Proc JISBD 4, pp 26–32

Chow R, Golle P, Jakobsson M, Shi E, Stad-don J, Masuoka R, Molina J (2009) Control-ling data in the cloud: outsourcing compu-tation without outsourcing control. In: Proc2009 ACM workshop on cloud computingsecurity. ACM, New York, pp 85–90

COMPAS (2008) Compliance-driven models,languages, and architectures for services.EU FP7 Project 215175, deliverable 2.1“State of the art in the field of compliancelanguages”

CSA (2009) Security guidance for criti-cal areas of focus in cloud computing.Cloud Security Alliance. http://www.cloudsecurityalliance.org/ . Accessed 2010-06-29

CSA (2010) Top threats to cloud comput-ing. Cloud Security Alliance. http://www.cloudsecurityalliance.org/ . Accessed 2010-06-29

Curtis B, Kellner MI, Over J (1992) Processmodeling. Comm ACM 35(9):75–90

Dijkman R, Dumas M, Ouyang C (2008) Se-mantics and analysis of business processmodels in BPMN. Information & Software

Technology 50(12):1281–1294Ehrig M, Koschmider A, Oberweis A (2007)

Measuring similarity between semanticbusiness process models. ACS CRPIT 67:71–80

Etro F (2009) The economic impact of cloudcomputing on business creation, employ-ment andoutput in Europe. Reviewof Busi-ness and Economics 54(2):179–218

European Commission (1995) Directive95/46/EC on the protection of individualswith regard to the processing of personaldata and on the free movement of suchdata

ENISA (2009) Cloud computing—benefits,risks and recommendations for informa-

tion security. European Network Informa-tion and Security AgencyGhose A, Koliadis G (2007) Auditing busi-

ness process compliance. Springer LNCS4749:168–180

GLB (1999) Gramm-Leach-Bliley Act. In:Congress of the USA

Governatori G, Hoffmann J, Sadiq SW, WeberI(2009) Detectingregulatory compliance forbusiness process models through semanticannotations. Springer LNBPI 14:5–17

Hayes B (2009) Cloud computing. Comm ACM51(7):9–11

HIPAA (1996) Health insurance portability andaccountability act. In: Congress of the USA

Höhn S (2009) Model-based reasoning on theachievement of business goals. In: ACMsymposium on applied computing. ACM,

New York, pp 1589–1593Huang H, Kirchner H (2009) Component-based security policy design with coloredPetri nets. Springer LNCS 5700:21–42

IIG (2010) BW2PN: BPEL+WSDL to Petri nettransformation. Software tool developedat the University of Freiburg, IIG Telemat-ics. http://www.telematik.uni-freiburg.de/comcert/. Accessed 2010-06-29

Katt B, Zhang X, Hafner M (2009) Towardsa usage control policy specification withPetri nets. Springer LNCS 5871:905–912

Lampson B (1973)A note on the confinementproblem. Commun ACM 16(10):613–615

Liu Y, Müller S, Xu K (2007) A staticcompliance-checking approach frame-work for business process models. IBMSystem Journal 46(2):335–361

Abstract

Rafael Accorsi, Lutz Lowis, Yoshinori Sato

AutomatedCertificationfor Compliant Cloud-basedBusiness Processes

A key problem in the deployment of

large-scale, reliable cloud computing

concerns the difficulty to certify the

compliance of business processes op-

erating in the cloud. Standard audit

procedures such as SAS-70 and SAS-

117 are hard to conduct for cloud-

based processes. The paper proposes

a novel approach to certify the compli-

ance of business processes with regula-

tory requirements. The approach trans-

lates process models into their cor-

responding Petri net representationsand checks them against requirements

also expressed in this formalism. Being

based on Petri nets, the approach pro-

vides well-founded evidence on adher-

ence and, in case of noncompliance, in-

dicates the possible vulnerabilities.

Keywords: Business process models,

Cloud computing, Compliance certifi-

cation, Audit, Petri nets



http://www.cloudsecurityalliance.org/




http://www.telematik.uni-freiburg.de/comcert/











Liu R, Kumar A (2005) An analysis and taxon-omy of unstructured workflows. SpringerLNCS 3649:268–284

Lohmann N, Verbeek E, Dijkman RM (2009)Petri net transformations for businessprocesses—A survey. Springer LNCS5460:46–63

Lowis L, Accorsi R (2010) Vulnerability analy-sis in SOA-based business processes. IEEE

Transactions on Services Computing (in

press)Meda HS, Sen AK, Bagchi A (2010) On detect-

ingdataflow errors in workflows. Journal of Data and Information Quality 2(1):1–31

Monakova G, Kopp O, Leymann F, Moser S,Schäfers K (2009) Verifying business rulesusing a SMT solver for BPEL processes. GILNI 147:81–94

Murata T (1989) Petri nets:properties, analysisand applications. Proc IEEE 77(4):541–580

Organisation for Economic Co-Operation andDevelopment (OECD) (1980) OECD guide-lines on the protection of privacy andtransborder flows of personal data

Oryx (2010) The Oryx project. http://bpt.hpi.uni-potsdam.de/Oryx/WebHome . Ac-cessed 2010-06-29

Ouyang C, Verbeek E, van der Aalst WMP,

Breutel S, Dumas M, ter Hofstede AHM

(2005) WofBPEL: a tool for automatedanalysis of BPEL processes. Springer LNCS3826:484–489

Park J, Sandhu R (2004) The UCONABC usagecontrol model. ACM Transactions on Infor-mation and System Security 7:128–174

Pretschner A, Hilty M, Basin D (2006) Dis-tributed usage control. Comm ACM 49:39–44

Sadiq S, Governatori G, Namiri K (2007) Mod-

eling control objectives for business pro-cess compliance. Business process man-agement. Springer LNCS 4714:149–164

Saha D (2008) A hitchhiker’s guide to galaxya.k.a. Netweaver business process mod-elling. http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/10947 . Accessed2010-06-29

Schneider F (2000) Enforceable security poli-cies. ACM Trans Inf Syst Secur 3(1):30–50

SOX (2002) Sarbanes-Oxley act. In: Congressof the USA

Stohr EA, Zhao JL (2001) Workflow automa-tion: overview and research issues. Infor-mation Systems Frontiers 3(3):281–296

Svirskas A, Courbis C, Molva R, BedžinskasJ (2007) Compliance proofs for collabora-tive interactions using aspect-oriented ap-

proach. IEEE Congress on Services 1:33–40

TMG (2009) Telemediengesetz. German Fed-eral Ministry of Justice

TrckaN, van derAalstWMP, Sidorova N (2009)Data-flow anti-patterns: discovering data-flow errors in workflows. Springer LNCS5565:425–439

van der Aalst WMP (1998) The application of Petri nets to workflow management. Jour-nal of Circuits, Systems, and Computers8(1):21–66

van der Aalst WMP (2003) Challenges in busi-ness process management: verification of business processing using Petri nets. Bul-letin of the EATCS 80:174–199

van Dongen BF, Jansen-Vullers MH, Verbeek HMW, van der Aalst WMP (2007) Verifica-tion of theSAP reference modelsusingEPCreduction, state-space analysis, and invari-ants. Computers in Industry 58(6):578–601

Wagner G (2002) How to design a general rulemarkup language. GI LNI 14:19–37

Wong PYH, Gibbons J (2008) Verifying busi-ness processcompatibility. In: Internationalconference on quality software. IEEE, pp

126–131



http://bpt.hpi.uni-potsdam.de/Oryx/WebHome


http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/10947






automated certification for compliant cloud-based business processes by coreieeeprojects

Documents