Eugenio Cesario
email: cesario@icar.cnr.it

Francesco Folino
email: ffolino@icar.cnr.it

Massimo Guarascio
email: guarascio@icar.cnr.it

Luigi Pontieri
email: pontieri@icar.cnr.it

A Cloud-based Prediction Framework for Analyzing Business Process Performances

Keywords: Data Mining, Prediction, BPM, Cloud/Grid computing

This paper presents a framework for analyzing and predicting the performances of a business process, based on historical data gathered during its past enactments. The framework hinges on an inductive-learning technique for discovering a special kind of predictive process models, which can support the runtime prediction of some performance measure (e.g., the remaining processing time or a risk indicator) for an ongoing process instance, based on a modular representation of the process, where major performance-relevant variants of it are equipped with different regression models, and discriminated through context variables. The technique is an original combination of different data mining methods (namely, non-parametric regression methods and a probabilistic trace clustering scheme) and ad hoc data transformation mechanisms, meant to bring the log traces to suitable level of abstraction. In order to overcome the severe scalability limitations of current solutions in the literature, and make our approach really suitable for large logs, both the computation of the trace clusters and of the clusters' predictors are implemented in a parallel and distributed manner, on top of a cloud-based service-oriented infrastructure. Tests on a real-life log confirmed the validity of the proposed approach, in terms of both effectiveness and scalability.

Introduction

In many real-life application contexts, business processes are bound to the achievement of goals expressed in terms of performance measures (possibly representing an indicator security/risk or a measurement of quality), which are monitored continuously at run-time. Historical log data, gathered during past enactments of a process, are a valuable source of hidden information on the behavior of the process, which can be extracted with the help of process mining techniques [START_REF] Van Der Aalst | Workflow mining: a survey of issues and approaches[END_REF], and exploited to improve the process, and meet such performance-oriented goals. In particular, it is definitely relevant to this regard the recent stream of research on the automated discovery of predictive process models (see, e.g., [START_REF] Van Der Aalst | Time prediction based on process mining[END_REF][START_REF] Folino | Discovering context-aware models for predicting business process performances[END_REF]), capable to estimate a given performance measure over new instances of a process, as long as they are carried out. Indeed, such performance forecasts can help optimize the process at run time, by possibly developing advanced operational support services, such as task/resource recommendation [START_REF] Schonenberg | Supporting flexible processes through recommendations based on history[END_REF], and the notification of alerts (possibly associated with some form of diagnostics).

Technically, all current approaches to the (log-based) discovery of a performance prediction model rely on abstracting the given log traces into a summarized propositional form, suitable for recognizing patterns that are likely to be correlated to the analyzed performance measure (constituting the target of the prediction task). For example, in [START_REF] Van Der Aalst | Time prediction based on process mining[END_REF], an annotated finite-state machine (AFSM) model is induced from a given log, where the states correspond to different abstract representations of all the sequences of process activities appearing in the log. The discovery of such AFSM models was combined in [START_REF] Folino | Discovering context-aware models for predicting business process performances[END_REF] with a context-driven (predictive) clustering approach, so that different execution scenarios can be discovered for the process, and equipped with distinct local predictors. However, choosing the right abstraction level is a delicate task, requiring to reach an optimal balance between the risks of overfitting and of underfitting.

In order to free the analyst from the responsibility of choosing the right level of abstraction for the log's traces, it was proposed in [START_REF] Folino | A data-adaptive trace abstraction approach to the prediction of business process performances[END_REF] to induce the prediction model of each discovered trace cluster by applying any standard regression method to propositional representation of the traces falling in the cluster. The context-aware prediction models obtained with such a clustering-based learning strategy were empirically proven to improve the accuracy of previous solutions. However, both the approaches in [START_REF] Folino | Discovering context-aware models for predicting business process performances[END_REF][START_REF] Folino | A data-adaptive trace abstraction approach to the prediction of business process performances[END_REF] require that a number of frequent structural patterns are preliminary extracted from the log traces, in order to map the latter onto a space of performance-oriented target features, in order to guide the clustering phase towards the discovery of groups of traces with similar performance trends. Once such clusters have been discovered, a distinct performance predictor can be induced from each cluster, by either using an AFSMbased learner [START_REF] Folino | Discovering context-aware models for predicting business process performances[END_REF] or standard regression algorithms [START_REF] Folino | A data-adaptive trace abstraction approach to the prediction of business process performances[END_REF]. Such a pattern-based clustering technique suffers from two main drawbacks: (i) the computation of structural patterns is not guaranteed to scale well over large logs, seeing as the number of discovered patterns may be, in general, combinatorial in the number of process activities; (ii) the discovered trace clusters are not guaranteed to reach the highest predictive clustering model, due to the loss of information determined when converting the log into a propositional dataset.

Contribution Still relying on the core idea of [START_REF] Folino | Discovering context-aware models for predicting business process performances[END_REF][START_REF] Folino | A data-adaptive trace abstraction approach to the prediction of business process performances[END_REF] of combining performance prediction with a clustering technique, we try to overcome the two major limitations mentioned above at two levels. First, we resort to a rougher form of log sketch than [START_REF] Folino | Discovering context-aware models for predicting business process performances[END_REF][START_REF] Folino | A data-adaptive trace abstraction approach to the prediction of business process performances[END_REF] for clustering the log traces, which can be quickly computed by picking up a fixed number of performance values at predefined positions within the traces, but are yet capable of helping recognize groups of traces exhibiting similar performance over the time -as confirmed by our experimental findings. Moreover, we replace the traditional (hard) clustering of the logics-based predictive clustering framework [START_REF] Blockeel | Top-down induction of first-order logical decision trees[END_REF] used in [START_REF] Folino | Discovering context-aware models for predicting business process performances[END_REF][START_REF] Folino | A data-adaptive trace abstraction approach to the prediction of business process performances[END_REF] with a probabilistic clustering scheme, in order to reduce the risk of obtaining lowly accurate cluster predictors (due to the greedy clustering algorithm and to the underlying approximated representation of the log). In order to overcome the severe scalability limitations of [START_REF] Folino | Discovering context-aware models for predicting business process performances[END_REF][START_REF] Folino | A data-adaptive trace abstraction approach to the prediction of business process performances[END_REF] and make our approach suitable for large logs, both the computation of (probability-aware) trace clusters and of the clusters' predictors are implemented in a parallel and distributed manner, according to the Grid-services-based conceptual architecture defined in [START_REF] Cesario | Distributed data mining patterns and services: an architecture and experiments[END_REF] for the specification and execution of Distributed Data Mining (DDM) tasks. The underlying grid services were developed according to the WSRF (Web Services Resource Framework) specifications of the WS-Core (a component of the Globus Toolkit 4 (GT4) [START_REF] Foster | Globus toolkit version 4: Software for service-oriented systems[END_REF]), and deployed onto a private Cloud-computing platform. By the way, the usage of a Cloud infrastructure to automatically deploy virtual machines hosting a GT4 container is not new (see, e.g., [START_REF] Moltó | On demand replication of wsrf-based grid services via cloud computing[END_REF][START_REF] Sempolinski | A comparison and critique of eucalyptus, opennebula and nimbus[END_REF]), and it widely reckoned as a successful way of providing a high flexible and customizable environment for transparently and efficiently running costly computational tasks.

Preliminaries

Log data As usually done in the literature, we assume that for each process instance (a.k.a "case") a trace is recorded, storing the sequence of events happened during its unfolding. Let T be the universe of all (possibly partial) traces that may appear in any log of the process under analysis. For any trace τ ∈ T , len(τ) is the number of events in τ, while τ[i] is the i-th event of τ, for i = 1 .. len(τ), with task(τ[i]) and time(τ[i]) denoting the task and timestamp of τ[i], respectively. We also assume that the first event of each trace is always associated with task A 1 , acting as unique entry point for enacting the process. This comes with no loss of generality, seeing as, should the process not have such a such a unique initial task, it could be added artificially at the beginning of each trace, and associated with the starting time of the corresponding process instance.

Let us also assume that, like in [START_REF] Folino | Discovering context-aware models for predicting business process performances[END_REF], for any trace τ, a tuple context(τ) of data is stored in the log to keep information about the execution context of τ, ranging from internal properties of the process instance to environmental factors pertaining the state of the process enactment system. For ease of notation, let A T denote the set of all the tasks (a.k.a., activities) that may occur in some trace of T , and context(T ) be the space of context vectors -i.e., A T = ∪ τ∈T tasks(τ), and context(T

) = {context(τ) | τ ∈ T }.
Further, τ(i] is the prefix (sub-)trace containing the first i events of a trace τ and the same context data (i.e., context(τ(i] = context(τ)), for i = 0 .. len(τ).

A log L is a finite subset of T , while the prefix set of L, denoted by P (L), is the set of all the prefixes of L's traces, i.e., P (L) = {τ(i] | τ ∈ L and 1 ≤ i ≤ len(τ)}.

Let μ : T → R be an (unknown) function assigning a performance value to any (possibly unfinished) trace. For the sake of concreteness, we will focus next on a particular instance of such a function, where the performance measure corresponds to the remaining time (denoted by µ RT ), i.e. the time needed to finish the respective process instance. In general, we assume that performance values are known for all prefix traces in P (L), for any given log L. This is clearly true for the measure mentioned above. Indeed, for each trace τ, the (actual) remaining-time of

τ(i] is μRT (τ(i]) = time(τ[len(τ)]) -time(τ[i]).
SOA, OGSA and WSRF The Service oriented architecture (SOA) is a model for building flexible, modular, and interoperable software applications. The key aspect of SOA is the concept of service, a software block capable of performing a given task or business function. The most popular implementation of SOA is represented by Web Services, whose popularity is mainly due to the adoption of widely accepted technologies such as XML, SOAP, and HTTP. Also the Grid provides a SOA framework whereby a great number of services can be dynamically located, balanced, and managed, so that applications are always guaranteed to be securely executed, according to the principles of on demand computing. The Grid community has adopted the Open Grid Services Architecture (OGSA) as an implementation of the SOA model within the Grid context. In OGSA every resource is represented as a Web Service that conforms to a set of con-ventions and supports standard interfaces. OGSA provides a well-defined set of Web Service interfaces for the development of interoperable Grid systems and applications. WSRF has been defined as an evolution of early OGSA implementations [START_REF] Czajkowski | From open grid services infrastructure to ws-resource framework: Refactoring & evolution[END_REF]. WSRF defines a family of technical specifications for accessing and managing stateful resources using Web Services, as required by OGSA. In other words, WSRF depicts some specifications to implement OGSA-compliant Web Services. Another way of expressing this relation is that, while OGSA is the architecture, WSRF is the infrastructure on which that architecture is built on [START_REF] Sotomayor | Globus R Toolkit 4: Programming Java Services[END_REF]. The composition of a Web Service and a stateful resource is termed as WS-Resource. The possibility to define a state associated with a service is the most important difference between WSRF-compliant Web Services, and pre-WSRF ones. This is a key feature in designing Grid applications, since WS-Resources provide a way to represent, advertise, and access properties related to both computational resources and applications. In order to implement services in a highly decentralized way, it is commonly used a design pattern that allows a client to be notified when interesting events happen in a server. The WS-Notification specification defines a publish/subscribe notification model for Web Services, which is exploited to notify interested clients and/or services about changes that occur to the status of a WS-Resource. In other words, a service can publish a set of topics that a generic client can subscribe to; as soon as the topic changes, the client receives a notification of the new status.

Cloud Computing Cloud computing can be defined as a distributed computing paradigm in which all the resources, dynamically scalable and often virtualized, are provided as services over the Internet. Cloud systems are typically classified on the basis of their service model (Software-as-a-Service, Platform-as-a-Service, Infrastructureas-a-Service) and their deployment model (public cloud, private cloud, hybrid cloud). Software-as-a-Service (or SaaS) defines a delivery model in which software and data are provided through Internet to customers as ready-to-use services (e.g. Google Docs or MS Office 365). In this case, both software and data are hosted by providers, and customers typically can access them in a easy way (without using any additional hardware or software) on a pay-per-use basis. Platform-as-a-Service (or PaaS) provides users with a programming environment and APIs for creating Cloud-based applications exploiting the computational resources of the platform (like e.g. Google App Engine, and Microsoft Azure). Finally, Infrastructure-as-a-Service (or IaaS) is a model under which customers ask for physical resources (e.g. CPUs, disks) to support their computational requirements (e.g., Amazon EC2, RackSpace Cloud). Cloud computing services are further classified according to three main deployment models: public, private, and hybrid. In a public cloud model, providers directly manage their data centers, and publicly delivers services built on top of them through the Internet. In a private cloud schema, operations and functionalities are offered as-a-service and usually hosted in a company intranet or in a remote data center. Finally, a hybrid cloud is obtained by composing two or more (private or public) clouds that, yet linked together, remain different entities.

Reference Architecture for Distributed Data Mining

This section is meant to briefly illustrate the service-oriented architecture proposed in [START_REF] Cesario | Distributed data mining patterns and services: an architecture and experiments[END_REF] for carrying out Distributed Data Mining (DDM) tasks over a Grid.

The architecture, shown in Figure 1, supports the specification and execution on the Grid of DDM algorithms, designed according to a master-worker pattern. Specifically, it features two kinds of Grid Services: the GlobalMiner-WS and the LocalMiner-WS. The architecture was conceived to follow a typical DDM schema contemplating the presence of an entity acting as coordinator (the GlobalMiner-WS) and a certain number of entities acting as miners (LocalMiner-WS) on local sites. A resource is associated with each service: the GlobalModel Resource with the GlobalMiner-WS and the Lo-calModel Resource with the LocalMiner-WS. Such resources are used to store the state of the services, in this case represented by the computed models (globally and locally, respectively). Additionally, the resources are published also as topics, in order to be considered as "items of interest of subscription" for notifications. As it appears clearly in Figure 1, the two types of nodes are equipped with code libraries that implement the mining algorithms to be executed, which are named Global Algorithm Library (GAL) and a Local Algorithm Library (LAL), respectively. In the following we describe all the steps composing the whole process, by pointing out details of the interactions between entities composing the architecture. Let us suppose that a client wants to execute a distributed mining algorithm on a dataset D, which is split in N partitions, {D 1 , ..., D N }, each one stored on one of the nodes {Node 1 , ..., Node N }. In order to be processed correctly, any request to perform a mining task needs to follow a three-step scheme.

In the first step, a client wanting to submit a request must invoke the createResource operation of the GlobalMiner-WS to create a GlobalModel Resource. In turn, the GlobalMiner-WS dispatches this operation in a similar way: for each local site with a running LocalMiner-WS (assuming the GlobalMiner-WS to hold a list of them), it invokes the createResource operation (of the LocalMiner-WS) to create a Lo-calModel Resource. At this point, the client invokes the subscribe method to subscribe a listener (inside the Client) as consumer of notifications on the GlobalModel topic. Finally, the GlobalMiner-WS invokes the subscribe method to subscribe a listener as consumer of notifications on the LocalModel topic. As an effect of such subscription steps, as soon as a resource changes, its new value will be delivered to its listener.

The second step constitutes the core of the application, i.e., the execution of the mining process and the result return. The Client invokes the submitGlobalTask operation, by passing a GlobalTaskDescriptor, i.e. a complete description of the task to be executed (algorithm name, parameters, initialization type, etc.). By interacting with the Global Algorithm Library, the GlobalMiner-WS runs the code executing the steps to be done. During this phase, suitable data structures are initialized and a suitable set of Lo-calTaskDescriptor are created. It invokes the submitLocalTask operation, by passing a LocalTaskDescriptor. At this stage, each i th LocalMiner-WS begins the analysis of the local dataset for computing a local model and local statistics. Such a task is executed, with the support of the LocalAlgorithmLibrary, concurrently on different Grid sites. While every local task is in progress, the GlobalMiner-WS does not need to periodically poll if they are terminated: the notification mechanism, indeed, is able to deliver asynchronous messages warning about the termination of local tasks. As soon as a local computation terminates, the value of the LocalModel Resource is set by the value of the computed local model. The changes in this resource are automatically notified to the listener on the GlobalMiner-WS; this way, the local model computed at the i th local site is delivered to the global site. As soon as all the local models are delivered to the GlobalMiner-WS, the integration of all these local models is performed. According to the logic of the chosen algorithm (provided by the GlobalAlgorithmLibrary), the GlobalMiner-WS evaluates whether the algorithm is terminated (or not). If it is, the global model computed by the GlobalMiner-WS is stored on the GlobalModel Resource, which is immediately delivered (via the notification mechanism) to the client. Otherwise, the GlobalMiner-WS asks for further processing, by invoking one more time a submitLocalTask operation and waiting for the delivering of the result. Such latter actions are executed as many times as the GlobalMiner-WS needs, until the computation reaches some convergence condition.

In the final step, as soon as the computation terminates and its results have been notified to the Client, the Client invokes the destroy operation of the GlobalMiner-WS, which eliminates the resource previously created (GlobalModel). Similarly, the GlobalMiner-WS asks for the destruction of the LocalModel.

From a practical (user-side) point-of-view, any new DDM task can be executed on this architecture provided that it suitably implements the interfaces globalAlgorithm and localAlgorithm. Specifically, they export the signatures for those methods each distributed algorithm running on this architecture needs to invoke, i.e. initialize, com-puteGlobalModel, needsMoreIteration and finalize for the globalAlgorithm; initialize, computeLocalModel and finalize for the localAlgorithm.

The ultimate goal of this work is to devise a scalable approach to the discovery of a (predictive) Process Performance Model (PPM), capable to accurately predict the performance outcome of any ongoing process case, based on the information stored in its associated (partial) trace. Such a model can be viewed as a function µ : T → R that provides an estimate for μ all over the trace universe -including the prefix traces of all possible process instances. Discovering a PPM is an inductive learning task, where the training set takes the form of a log L, and the value μ(τ) of the target measure is known for each (sub-)trace τ ∈ P (L). Notably, current approaches to this problem [START_REF] Van Der Aalst | Time prediction based on process mining[END_REF][START_REF] Folino | Discovering context-aware models for predicting business process performances[END_REF][START_REF] Folino | A data-adaptive trace abstraction approach to the prediction of business process performances[END_REF] rely on preliminary converting the given process traces in to a propositional form, with the help of some suitable trace abstraction function. The rest of this section provides the reader with a few technical details on the trace abstraction functions considered in our approach, as well as on the specific (clustering-based and probability-aware) kind of PPM that we want to eventually learn from the abstracted traces.

Trace Abstraction An abstracted (structural) view of a trace summarizes the tasks executed during the corresponding process enactment. Two simple ways to build such a view consist in regarding the trace as a tasks' set or multiset (a.k.a. bag), as follows.

Definition 1 (Structural Trace Abstraction). Let T be a trace universe and A 1 , . . . , A n be the tasks in A T . A structural (trace-) abstraction function struct mode : T → R mode T is a function mapping each trace τ ∈ T to an an abstract representation struct mode (τ), taken from an abstractions' space R mode T . Two concrete instantiations of the above function, denoted by struct bag : T → N n (resp., struct set : T → {0, 1} n ), are defined next, which map each trace τ ∈ T to a bag-based (resp., set-based) representation of its structure: (i) struct bag (τ) = count(A 1 , τ), . . . , count(A n , τ) , where count(A i , τ) is the number of times that task A i occurs in τ; and (ii) struct set (τ) = occ(A 1 , τ), . . . , occ(A n , τ) , where occ(A i , τ) = true iff count(A i , τ) > 0, for i = 1, . . . , n.

The two concrete abstraction "modes" (namely, bag and set) defined above summarize any trace τ into a vector, where each component corresponds to a single process task A i , and stores either the number of times that A i appears in the trace τ, or (respectively) a boolean value indicating whether A i occur in τ or not. Notice that, in principle, we could define abstract trace representations as sets/bags over another property of the events (e.g., the executor, instead of the task executed), or even over a combination of event properties (e.g., the task plus who performed it).

As a matter of fact, the structural abstraction functions in Def. 1 are similar to those used in previous approaches to the discovery of predictive process models [START_REF] Van Der Aalst | Time prediction based on process mining[END_REF][START_REF] Folino | Discovering context-aware models for predicting business process performances[END_REF][START_REF] Folino | A data-adaptive trace abstraction approach to the prediction of business process performances[END_REF].

PPM discovery as predictive clustering: limitations of current solutions From a conceptual point of view, we rephrase the induction of a PPM, out of a given log, as a predictive clustering [START_REF] Blockeel | Top-down induction of first-order logical decision trees[END_REF] task, similarly to [START_REF] Folino | Discovering context-aware models for predicting business process performances[END_REF][START_REF] Folino | A data-adaptive trace abstraction approach to the prediction of business process performances[END_REF]. Essentially, the core idea underlying predictive clustering approaches is that suitably partitioning the training instances into clusters and inducing a specific predictor from each cluster helps obtain better predictions than using a single predictor (learnt from the whole training set). At run-time, for any new instance, the prediction is built by first assigning the instance to one of the clusters, and then making it undergo the predictor of that cluster. More precisely, these approaches assume that two kinds of features are available for any element z in the reference instance space, say Z = X ×Y : descriptive features and target features (to be predicted), denoted by descr(z) ∈ X and targ(z) ∈ Y , respectively. Then, a predictive clustering model (PCM), for a given training set L ⊆ Z, is a function q : X → Y of the form q(x) = p(c(x), x), where c : X → N is a partitioning function that assigns x to a cluster, and p : N × X → Y is a (possibly multi-target) prediction function. Clearly, whenever there are more than one target features, q encodes a multi-regression model.

Following this general scheme, and similarly to [START_REF] Folino | Discovering context-aware models for predicting business process performances[END_REF][START_REF] Folino | A data-adaptive trace abstraction approach to the prediction of business process performances[END_REF], we adopt a modular kind of PPM that consists of two different types of components: a partitioning function c that maps any trace to a distinguished cluster, and a collection µ 1 , . . . , µ k of PPMs, one per cluster. A propositional encoding enc(τ)is exploited for any possible trace τ, which mixes up the context data possibly available for τ with an abstracted view of the history of τ, obtained with the help of one of the abstraction function in Definition 1. The features appearing in enc(τ) play the role of descriptive attributes, while clearly considering the the performance values µ(τ) as the target of prediction. Clearly, applying standard predictive clustering solutions to such data would not make sense, since we are not interested in predicting the final performance measure of a complete trace (as are those stored in the above-described training set), but rather in making predictions on all possible prefixes (i.e. partial incremental versions) of any new trace as far as it unfolds, in a step-by-step fashion -as discussed in [START_REF] Folino | Discovering context-aware models for predicting business process performances[END_REF], learning the clustering model based on all partial traces in Pr(L) is costly and hardly effective. Therefore, both the approaches in [START_REF] Folino | Discovering context-aware models for predicting business process performances[END_REF][START_REF] Folino | A data-adaptive trace abstraction approach to the prediction of business process performances[END_REF] faced the problem heuristically, by dividing it into two sub-problems: (1) induce a predictive clustering model out of a summarized representation (named "log sketch") of the given log, where each (full) trace in the log is used as a single clustering instances, associated with a number of target values that capture the evolution of the µ at several relevant ("pivot") stages of the process (2) induce a PPM out of each discovered cluster. In particular, in [START_REF] Folino | Discovering context-aware models for predicting business process performances[END_REF][START_REF] Folino | A data-adaptive trace abstraction approach to the prediction of business process performances[END_REF], the computation of the target attributes for the traces relied on the preliminary extraction of frequent structural patterns chosen greedily, based on their apparent capability to discriminate among different performance profiles.

However, such a approach suffers from two main drawbacks: (i) the computation scheme cannot scale over large logs, mainly due to the fact that the extraction of structural patterns may take a time that is combinatorial in the number of process activities;

(ii) the discovered clusters of traces are not guaranteed to reach the highest predictive clustering model (due to both the very two-phase optimization scheme, and to the loss of information determined by converting the original log into a propositional dataset).

A new kind of (clustering-based) PPMs: PCB-PPM We here try to overcome both these limitations at two levels. First, we resort to a rougher form of log sketch than [START_REF] Folino | Discovering context-aware models for predicting business process performances[END_REF][START_REF] Folino | A data-adaptive trace abstraction approach to the prediction of business process performances[END_REF] for clustering the log traces, which does not require the computation of frequent structural patterns, but simply consists on extracting a fixed number of performance values at predefined positions of the traces. These additional (target-oriented) features, which are formally defined in the next Section (cf. Definition 3), are meant to introduce a bias towards the discovery of groups of traces exhibiting similar performance patterns over the time. On the other hand, we extend the traditional (hard) clustering of standard pre-dictive clustering settings with a probabilistic clustering scheme. This choice is meant to curb the risk of obtaining a poorly accurate PPM as a result of the heuristics clustering strategy adopted in [START_REF] Folino | Discovering context-aware models for predicting business process performances[END_REF][START_REF] Folino | A data-adaptive trace abstraction approach to the prediction of business process performances[END_REF] (due to both the very greedy clustering method and the usage of an approximated representation of the traces). In particular, as discussed in the following section, such a probabilistic clustering model is computed efficiently trhough a parallelized distributed version of the well-known EM method [START_REF] Dempster | Maximum likelihood from incomplete data via the EM algorithm[END_REF], hence solving the scalability limitations of [START_REF] Folino | Discovering context-aware models for predicting business process performances[END_REF][START_REF] Folino | A data-adaptive trace abstraction approach to the prediction of business process performances[END_REF].

We are now in a place to formally define the novel, probabilistic-aware clusteringbased, type of PPM that our learning approach is meant to extract from a given log.

Definition 2 (Probabilistic Clustering-Based PPM Model (PCB-PPM)). Let L be a log (over T ), with context features context(T ), structural abstract representations struct mode (T ) (where mode ∈ {set, bag}), and μ : T → R be a performance measure, known for all τ ∈ P (L). Let also enc(τ) = context(τ) ⊕ struct mode (τ) be the propositional encoding for each τ ∈ P (L), where ⊕ stands for tuple concatenation. Then a probabilistic clustering-based performance prediction model (PCB-PPM) for L is a pair M = c, µ 1 , . . . , µ k (where k is the number of clusters found for L) encoding a probabilistic predictive clustering model, where (i) c : enc(T ) × {1, . . . , k} → [0, 1] is a probabilistic clustering function that assigns any (possibly partial) new trace τ to each cluster with a certain probability (based on the encoding of τ), and (ii) µ i : T → R is a PPM associated with the i-th cluster, for i ∈ {1, . . . , k}. Model M is meant to estimate the unknown performance function μ as follows: for any trace τ ∈ T , the corresponding performance value μ(τ) is computed as ∑ k j=1 c(enc(τ), j) • µ j (enc(τ)).

In such a model, each cluster is equipped with a separate PPM, tailored to capture how μ depends on both the structure and context of any trace that may be assigned to the cluster. The prediction for any new trace τ is computed as a linear combination of the predictions made by the PPMs of all the clusters τ is estimated to possibly belong to, with their respective membership probabilities used as weights. In general, such an articulated kind of PPM can be built by inducing a predictive clustering model and multiple PPMs (as the building blocks implementing c and all µ i , respectively). In our approach, we face this sub-task by resorting to standard regression methods, defined for propositional data. As observed in [START_REF] Folino | A data-adaptive trace abstraction approach to the prediction of business process performances[END_REF], indeed, this frees the analyst from the burden of defining a suitable level of details over the representation of the relevant states of the process (as required in the case of the AFSM models used in [START_REF] Van Der Aalst | Time prediction based on process mining[END_REF][START_REF] Folino | Discovering context-aware models for predicting business process performances[END_REF]).

Solution Approach to the Discovery of a PCB-PPM

Figure 2 illustrates the main steps of our approach to the discovery of a PCB-PPM model, in the form of an algorithm, named PCB-PPM Discovery. Essentially, the problem is approached in three main phases. In the first phase (Step 1), the given log L is transformed into a propositional dataset D traces , containing one distinguished tuple for each trace of the log. As in [START_REF] Folino | Discovering context-aware models for predicting business process performances[END_REF][START_REF] Folino | A data-adaptive trace abstraction approach to the prediction of business process performances[END_REF], the tuple encoding any trace τ in L stores both the contextoriented attributes of τ and the summarized structural view struct mode (τ), produced according to the abstraction criterion mode (specified as input to the algorithm) -these two kinds of information are here represented as two different sub-tuples, concatenated

Input: A log L over some trace universe T , with associated target performance measure μ, an abstraction mode mode ∈ {set, bag}, a regression method REGR, the number K of desired trace clusters, and the number M of local miners for the clustering.

Output: A PCB-PPM model for L (fully encoding μ all over T ).

Method: Perform the following steps: one with the other. A series of performance-oriented attributes (denoted as pPro f (τ)) are stored as well in the propositional representation of τ, in order to bias the clustering phase towards the discovery of groups of traces that exhibit similar performance patterns over the time. These trace attributes are formally defined next. Definition 3 (Performance profile (for trace clustering)). Let T be a trace universe, and μ : T → R be a performance measure. Let h be a number in N + chosen by the analyst 1 . For any trace τ in T , the performance profile of τ (w.r.t. μ and m) is an h-sized (sub-)tuple pPro f (τ) = pPro f (τ, 1), pPro f (τ, 2), . . . , pPro f (τ, h) , such that, for each j ∈ {1, . . . , h}, it holds:

1 D traces := { context(τ) ⊕ struct mode (τ) ⊕ pPro f (τ) | τ ∈ L }; // see Def.
pPro f (τ, j) = τ[i j ], if i j < len(τ) NULL, otherwise where i j = ( j -1) × len(τ) h + 1.
Notably, computing such a representation of a trace's performance profile simply amounts to picking up a fixed number of performance values at predefined positions of the trace, which can be done in linear time in the size of the input log. By converse, the propositional log sketch used in [START_REF] Folino | Discovering context-aware models for predicting business process performances[END_REF][START_REF] Folino | A data-adaptive trace abstraction approach to the prediction of business process performances[END_REF] for trace clustering requires the preliminary extraction of frequent structural patterns, which is far more expensive (possibly combinatorial in the number of process activities) in terms of computation time.

In the second phase (Steps 2-3), a probabilistic clustering model is mined out of D traces by exploiting a distributed version of popular algorithm EM [START_REF] Dempster | Maximum likelihood from incomplete data via the EM algorithm[END_REF], implemented by function P-EM according to the data-parallel scheme of Figure 1. This function, described in details later on, requires the data to be preliminary split into different datasets {D 1 , . . . , D M }, based on some partitioning strategy. Specifically, here we simply divided the tuples of D traces into groups of (approximately) the same size (Step 2).

In the third phase (Steps 4-5), a regression model is induced from each of the discovered trace clusters, by applying the learning method REGR specified as input to the algorithm. In order to obtain a predictive model that can be applied to (new) ongoing process instances, the learner is provided with a set of training instances representing partial (prefix) traces, labelled each with the respective performance measurement. To this purpose, all the prefix traces in Pr(L) are preliminary stored into a propositional dataset D pre f ixes ), which encodes all the context-oriented and structure-oriented features of each trace (in addition to its target performance value). The discovered clustering model C is then applied to D pre f ixes in a "hard" way, in order to obtain a partition D 1 , . . . , D K of it, where each tuple z ∈ D pre f ixes is assigned to the cluster it appears the most likely to belong to (Step 5). These clusters of prefix traces are then exploited to train a list of regression models, one per cluster. This is accomplished by the distributed function P-REGR (Step 6), following the same distributed paradigm as P-EM -further details on the function too are given later on. Clearly, in such a regression task, for each prefix trace τ, the features in context(τ) and struct mode (τ) are considered as input values, while the performance measurement μ(τ) is the target variable to be predicted.

The rest of the algorithm is simply meant to put the discovered clustering model and regression models in the form of a PCB-PPM, and to eventually return the latter.

Function P-EM Expectation Maximization (EM) is a well-known method for inducing a probabilistic clustering model. The method relies on the assumption that the given dataset were generated by a mixture of K probability distributions of some given form (e.g., Gaussian), representing each a distinguished cluster. The clustering task then consists in trying to maximize the fit between the dataset and such a probabilistic model, by suitably setting, the membership probabilities of the data instances and the parameters of the overall generative model -indeed, this information is not assumed to be known in advance, and it must be estimated from the given data. Classic EM algorithm needs to be provided with an initial (typically randomly chosen) setting of the mixture model's parameters. Each EM iteration computes new estimates for these parameters that are proven not to decrease the likelihood of the model, denoted hereinafter as Per f EM . The process is repeated until the value of Per f EM converges to a local maximum.

Different distributed versions of EM algorithm have been presented in the literature. Our approach essentially exploits the distributed computation scheme defined in [START_REF] Cesario | Distributed data mining patterns and services: an architecture and experiments[END_REF], in accordance with the DDM framework of Figure 1.

In a nutshell, function P-EM takes as input different subsets, say D 1 , . . . , D N , of the dataset, and the maximum number of clusters, say K. The clustering process is distributed among N local miners (i.e., nodes equipped with an instance of LocalMiner-WS, as explained in Section 3), storing each one of the sub-datasets D 1 , . . . , D N , with a further node acting as coordinator (provided with an instance of a GlobalMiner-WS).

Specifically, in the initialization phase (method initialize), the coordinator randomly initializes, for each of cluster C k (with k = 1, . . . , K), the center m k , the covariance matrix Σ k and the mixing probability p(m k ), and sends a copy of these data to each local node.

The method computeLocalModel, implemented by each local miner, consists of three steps that are described next. First, the local miner estimates (for each x ∈ D, for each k = 1, . . . , K) the probability p(m k |x) that x belongs to cluster

C k -precisely, it computes p(m k |x) = p(x|m k )•p(m k ) ∑ K k=1 p(x|m k )•p(m k )
, where p(m k ) is the mixing probability and p(x|m k ) is the prior probability, taking the specific form of a Gaussian distribution. Then, it computes a collection SS (i) of local statistics, consisting of the following values:

f (i) = ∑ x∈D i [-log ∑ K k=1 p(x|m k )p(m k )]; s1 (i) k = ∑ x∈D i p(m k |x); s2 (i) k = ∑ x∈D i p(m k |x)x; and s3 (i) k = ∑ x∈D i p(m k |x)(x -m k ) T (x -m k ), (with k = 1, . . . , K).
As a last step of computeLo-calModel, these local statistics are sent to the coordinator.

In order to implement method computeGlobalModel, the coordinator needs to combine local information stored in the data summaries SS (1) , . . . SS (N) (received from the local nodes), and update the clustering model. In particular, for each cluster C k , the updated versions of the center m k , the covariance matrice Σ k , the mixing probabilities p(m k ) for k, k = 1, . . . , K are produced -namely,

m k = ∑ N i=1 s2 (i) k / ∑ N i=1 s1 (i) k , Σ k = ∑ N i=1 s3 (i) k / ∑ N i=1 s1 (i) k , and p(m k ) = ∑ N i=1 s1 (i)
k /|D|. Moreover, a performance measure Per f EM is computed for the resulting clustering model as follows: Per f EM = ∑ N i=1 f (i) . At the end of each iteration of this computation scheme, the coordinator must check (through an invocation of method needsMoreIteration) if the measure Per f EM has converged to a (local) optimum or the number of iterations has reached a given bound. If one of these conditions holds, the algorithm finishes; otherwise a new iteration of the algorithm starts, where the coordinator sends a copy of the novel clustering parameters (i.e., m k , Σ k and p(m k ), for k = 1, . . . , K) to the local miners, and so on.

Function P-REGR Due to space limitations, we do not describe this function in detail. In fact, rephrasing this function in terms of the framework in Figure 1 is simple enough for being explained without any precise formalization.

Basically, the method initialize of interface globalAlgorithm simply consists in assigning the given K datasets to different local miners (i.e. instances of LocalMiner-WS). Each local miner is responsible for extracting a single regressor out of one of the datasets by using the selected regression algorithm REGR (hence playing as the actual implementation of method computeLocalModel in localAlgorithm). Once each local regressor has been induced, it is passed to the global miner (i.e. the node implementing an instance of GlobalMiner-WS), which does not need to perform any further computation -method needsMoreIteration in globalAlgorithm is "immaterial" in that it always returns false. Finally, the method computeGlobalModel of GlobalModel only must store all the local regressors received from the remote sites, into a list, ensuring that they follow the same mutual order as the clusters they have been induced from.

Experimental Results

In order to test our approach, we implemented both the distributed functions P-EM and P-REGR (see Section 5) as a composition of Grid Services, according to the model of Figure 1. The services have been developed by using the Java WSRF library provided by the WS-Core, a component of the Globus Toolkit 4 [START_REF] Foster | Globus toolkit version 4: Software for service-oriented systems[END_REF]. These GT4-based Grid Services The LocalMiner-WS services (using either in P-EM or in P-REGR) were distributed as uniformly as possible over a number of dedicated virtual machines in the Cloud -in practice, M local miners were deployed onto V virtual machines by assigning M/V local miners to each machine. Each virtual machine, instead, is instantiated on a distinct node of the Grid. It is worth noticing that two distinguished nodes were kept reserved for the GlobalMiner-WS services of the functions P-EM and P-REGR, and another one for the main algorithm PCB-PPM Discovery -acting as a client of those GlobalMiner-WS's.

The rest of the section discusses a series of experimental activities that we conducted to assess the validity of our approach, in terms of both effectiveness and scalability. To this purpose, we used a collection of 5336 log traces generated by a real transshipment system. Each trace stores a sequence of major logistic activities (4 on the average) that were applied to a distinguished container, passing through the system in the first third of year 2006. Basically, each container is unloaded from a ship, temporarily placed by the dock, and then carried to a yard slot for being stocked. Symmetrically, at boarding time, the container is first placed close to the dock, and then loaded on a cargo. Different kinds of vehicles can be used for moving a container, including, e.g., cranes, "straddle-carriers", and "multi-trailers". This basic life cycle may be extended with further transfers, devoted to make the container approach its final embark point or to leave room for other ones. Several data attributes are available for each container as context data, which include: the origin and final ports, its previous and next calls, various properties of the ship unloading it, physical features (such as, e.g., size, weight), and some information about its contents. As in [START_REF] Folino | Discovering context-aware models for predicting business process performances[END_REF], we also considered several "environmental" context features for each container: the hour (resp., day of the week, month) when it arrived, and the total number of containers that were in the port at that moment.

In all the tests described next, the remaining processing time (for all the prefix traces extracted by this log) was considered as the target performance measure to predict.

Effectiveness Results

Since the ultimate goal of our approach is to predict a performance measure (namely, the remaining processing time) over partial log traces, the effectiveness of our approach was evaluated by computing (via 10-fold cross validation) three standard error metrics, quantifying all how much the predicted values differ from the real ones in the average: root mean squared error (rmse), mean absolute error (mae), and mean absolute percentage error (mape). For ease of interpretation, the results have been divided by the average processing time (over all the log's traces).

As a term of comparison we considered two approaches that were defined in the literature for the discovery of a clustering-based PPM: AA-TP [START_REF] Folino | A data-adaptive trace abstraction approach to the prediction of business process performances[END_REF], and CA-TP [START_REF] Folino | Discovering context-aware models for predicting business process performances[END_REF]. By the way, it is known from the literature such these techniques were all capable to neatly improve the achievements of non clustering-based predictors. In a sense, the quality of the forecasts that a clustering-based PPM eventually provides can be considered as an indirect indicator of the validity of its underlying clustering model (which has indeed a "predictive clustering" nature, and serves the purpose of supporting the prediction task). Following this line of reasoning, no quality measure is shown here for the discovered clusters, in addition to the very accuracy of the predictions that they allowed to make.

For our empirical effectiveness analysis, we run PCB-PPM Discovery by heuristically setting the number K of clusters to log 2 (|L|) , where |L| is the number of traces in the given log, while always keeping M = 16.

Tables 1 shows the average errors made by our algorithm, for two different instantiations of the regression method REGR (namely, and IB-k and RepTree) -in both cases we resorted to the implementations available in the popular Weka [START_REF] Witten | Data Mining: Practical Machine Learning Tools and Techniques[END_REF] library. In particular, the first half of the table regards the case when the bag mode is used for abstracting traces, whereas the second half concerns the usage of set abstractions.

The values shown for AA-TP were computed by averaging the ones obtained with different settings of its parameters, namely minSupp ∈ {0.1, . . . 0.4}, kTop ∈ {4, ∞}, and maxGap ∈ {0, 4, 8, ∞}. For CA-TP, instead, we report the average of the results that it obtained with different values of the horizon parameter h (precisely, h = 1, 2, 4, 8, 16), and the best-performing setting for all the remaining parameters.

In order to correctly interpret the results in Table 1, it is important to notice that the kind of clustering used by AA-TP and CA-TP is more precise than the one adopted in our approach, as discussed in Section 4. In spite of this, PCB-PPM still achieves better results in terms of mae and mape than AA-TP (our rmse outcomes, instead, are slightly worse than AA-TP's ones), and more accurate outcomes (over all error metrics) than CA-TP, irrespective of the abstraction function (i.e. BAG or SET ) used. The former behavior can be explained as an effect of the probabilistic clustering scheme that underlies our PCB-PPM's, and makes the prediction of trace performances more robust to the discovery of sub-optimal trace clusters. The lower prediction errors produced by both PCB-PPM and AA-TP, w.r.t. CA-TP, find a justification on their capability to fully exploit the context information available for the log traces in both the clustering and prediction phases -whereas CA-TP uses them during the clustering step only.

Efficiency Results

To test the scalability of our approach, we first generated 4 distinct datasets with different sizes (namely, DS1, DS2, DS3, DS4), obtained by replicating every trace in the given log L for 256, 512, 1024, and 2048 times, respectively. We studied the scalability, speedup and efficiency performances when varying the number of grid nodes (from 1 to 16) that were actually used. For space reasons, we next focus on the case where REGR = RepTree and mode = BAG -similar trends were obtained, indeed, with the SET abstraction and IB-k. Similarly to what done in the effectiveness tests, the number of desired trace clusters was set to log 2 (|L|) . Figure 3 (a) shows the execution times spent against each of the datasets, when using 1 to 16 Grid nodes. We can simply observe that these times strongly decrease for all datasets when incresing the number of available nodes. It is important to observe that the time needed to process the dataset DS4 (i.e., the biggest one, with more than 10M traces and 43M of events) is longer than 4 hours when using a single node, while it decreases to only 16.3 minutes when exploiting 16 nodes. In Figure 3 (b) the execution speed-up curves are depicted for each of the datasets. The speed-up is almost linear for all datasets up to the case where 8 Grid nodes are used; an appreciable trend of gain is maintained over higher numbers of nodes. Notably, a speed-up value of 15 is obtained for the extreme case of dataset DS4 when using all of the 16 nodes, hence substantiating the scalability of our distributed computation strategy and of the underlying framework. Finally, Figure 3 (c) shows the system efficiency, vs the number of nodes and for different datasets. As shown in the figure, a good efficiency trend can be seen as long as the number of nodes increases. As a matter of fact, for the largest dataset DS4, the efficiency on 8 nodes is equal to 0.99, whereas on 16 nodes it is equal to 0.94, i.e. the 99% and 94% of the computing power of each used node is exploited, respectively.

Conclusions

We have presented a novel context-aware clustering-based approach to the discovery of predictive models for supporting the forecast of process performance measures. The ap-proach overcomes the severe scalability limitations of similar solutions currently available in the literature, and takes advantage of a distributed implementation of its more expensive computational tasks, based on a collection of ad hoc grid services, deployed on top of a cloud-computing platform. It is worth noticing that, despite the approach introduces some approximation in the computation of trace clusters (for the sake of efficiency), the accuracy of the predictions obtained in a real-life application scenario is quite satisfactory. This is likely due to the capability of our probabilistic clustering scheme to compensate such a loss of precision in the clustering phase.

As future work, we plan to integrate more powerful regression methods into our approach, as well as investigate the possibility to exploit sequence-oriented kernel-based methods for both the clustering of the traces and for inducing each cluster's predictor.

1 Fig. 1 :

 11 Fig. 1: Architectural Model of Distributed Data Mining Services.

3 . 2 Fig. 2 :

 322 Fig. 2: Algorithm PCB-PPM Discovery.

Fig. 3 :

 3 Fig. 3: Efficiency results of PCB-PPM for different data sizes when RepTree is used as regressor.

Table 1 :

 1 Average errors made by PCB-PPM Discovery (here denoted as Ours) and the competitors, for different abstraction modes (namely, BAG and SET). The best outcomes are in bold. For scalability analyses, different subsets of these nodes, namely, of size N = 1, 2, 4, . . . , 16, were allocated to the execution of the whole PCB-PPM Discovery.

	Metric	Ours	Ours	BAG AA-TP	AA-TP	CA-TP	Ours	Ours	SET AA-TP	AA-TP	CA-TP
		(IB-k)	(RepTree)	(IB-k)	(RepTree)		(IB-k)	(RepTree)	(IB-k)	(RepTree)
	rmse	0.217	0.213	0.205	0.203	0.291	0.299	0.294	0.287	0.286	0.750
	mae	0.061	0.059	0.064	0.073	0.142	0.102	0.098	0.105	0.112	0.447
	mape	0.117	0.111	0.119	0.189	0.704	0.225	0.189	0.227	0.267	2.816
	were deployed onto a private Cloud computing infrastructure, by instantiating a pool of
	virtual machines (one for each grid node). Precisely, we used a physical Grid consisting
	of 18 nodes, each running a Linux CentOS 7.0 distribution and equipped with 1TB
	(SATA) hard drive, a dual-core processor Intel Xeon E2 2650 2GHz, and 128GB of
	RAM.

In all the tests described here, we simply set h as the 40th percentile of the log's traces length.


Angelo Furfaro
email: a.furfaro@dimes.unical.it

Teresa Gallo
email: t.gallo@dimes.unical.it

Domenico Saccà
email: sacca@dimes.unical.it

Modeling Cyber Systemic Risk for the Business Continuity Plan of a Bank

Keywords: Business Continuity, Disaster Recovery, Systemic Risk, Cyber Threat, Goal-Oriented Methodology, Requirements Engineering

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

During the last few years, the diffusion of cyber threats has seen a steep growth at a rate which is predicted to increase in the near future [START_REF][END_REF]. Cyber security threats include events such as accidental cyber-related incidents or deliberate actions coming from external entities such as hacker attacks and virus/worm/malicious software infiltrations [START_REF] Chaudhary | The five critical attributes of effective cybersecurity risk management -white paper[END_REF]. These threats might directly affect industrial control systems and processes and need to be properly managed [START_REF] Kosub | Components and challenges of integrated cyber risk management[END_REF]. The effects of a threat exploit on a given system, may propagate through communication networks causing damages to other interconnected systems and giving rise to a ripple effect. This phenomenon, where a threat triggers a knock-on effect among different enterprises, is known as systemic risk and has been the subject of many studies in the financial and economic domains [START_REF] Cerutti | Systemic risks in global banking: What available data can tell us and what more data are needed? Working Paper 18531[END_REF].

Provisions against the cyber systemic risk are usually directed to establish a strategy for circumscribing negative effects, e.g. by activating alternative solutions to the damaged systems, and to slow down, and possibly to stop the propagation towards the other interconnected systems.

Nowadays, a big-enterprise IT system is usually geographically distributed, pervasive and ubiquitous for its internal and external users. Therefore, each of such systems consists of a network of subsystems where the cyber systemic risk must be reduced as much as possible. Cyber security risk has to be continuously monitored, while real-time recovery and support procedures, assuring an enough degree of system availability, have to be provided [START_REF]Business continuity oversight expectations for systemically important payment systems (SIPS)[END_REF][START_REF]Principles for financial market infrastructures[END_REF]. Systemic effects have to be reduced and global collaboration among all stakeholders, both public and private, should be provided for an effective proactive prevention of a cyber shock of our global, not only financial, networked systems [START_REF] Goldsmith | Systematic approaches to cyber insecurity[END_REF].

In a recent white paper [START_REF]Cyber Risk a Global Systemic Threat: A White Paper to the Industry on Systemic Risk[END_REF], the Depository Trust & Clearing Corporation (DTCC) affirms that a global cyber systemic risk could become less dangerous if the defense is both collective and coordinated, otherwise the failure is quite sure. The last DTCC report on systemic risk [START_REF]Systemic risk barometer: Results overview 2016 -Q1[END_REF] is very alarming on the cyber risk for the worldwide financial markets. Therefore, instead of providing specific cyber risk defenses for each system, a global cyber systemic risk [START_REF] Sommer | Reducing systemic cybersecurity risk. Oecd/ifp project on future global shocks[END_REF][START_REF] Tendulkar | Cyber-crime, securities markets and systemic risk[END_REF] strategy should be devised and enforced by means of the adoption of shared rules, regulations and common approaches.

This paper focus on the banking context and, specifically on the business continuous plan (BCP) and its disaster recovery plan (DRP), as regulated by the Bank of Italy for the banking operators located in Italy [START_REF]Guidelines on business continuity for market infrastructure[END_REF]. However, each Bank operating in the European Union must provide similar guidelines for BCP and DRP of their banking operators.

The definitions of BCP and DRP are driven worldwide by many sectoral rules and regulations [START_REF] Rissman | US regulators issue guidance on disaster recovery and business continuity planning for hedge funds[END_REF], without any global coordination. A supervising institution, having the authority to push and actually drive the different BCPs, would be able to manage the global systemic risk by a coordinated strategy. Moreover, the 2016 edition of "The Global Risks Report" [START_REF]The global risks report[END_REF], by the World Economic Forum, outlines the need for cooperation among stakeholders for risk management and cites some tests performed in Germany.

We model, by means of a goal oriented methodology [START_REF] Van Lamsweerde | Goal-oriented requirements enginering: a roundtrip from research to practice[END_REF] named GOReM [START_REF] Citrigno | Mastering concept exploration in large industrial research projects[END_REF], the requirements for the cyber systemic risk treatment for a bank operating in Italy. All Italian banks follow rules and regulations delivered by the Bank of Italy. However, each European Nation has a central banking institution which establish similar guidelines for the local banks. Then, the developed models might be applied, with small adaptations, to whichever bank in Europe.

In particular, the models obtained using GOReM, follow what established by Bank of Italy in the guidelines [START_REF]Guidelines on business continuity for market infrastructure[END_REF]. Those models allowed to easily highlight how a BCP has two different ways to handle the cyber systemic risk. The first includes critical processes which might develop contagion only to the internal stakeholders of the bank (including counterparts cooperating to the business of the bank). In this case the ripple effect of an incident is treated at the bank level and the Bank of Italy is only notified. The second cyber systemic risk treatment is related to the safeguard of systematically important processes of the payment systems and of the access to financial markets. In this case, both BCP and the handling of a possible ripple effect of an incident on other banks and, more generally, on external entities, is strongly centralized by the Bank of Italy. The latter is a hierarchical control, although with rigid response time, which might introduce delays in the tentative to slow down or stop contagion in the European and even worldwide financial system [START_REF] Cerutti | Systemic risks in global banking: What available data can tell us and what more data are needed? Working Paper 18531[END_REF].

GOReM has already been successfully employed in the context of some industrial research projects, involving enterprises such as ACI Informatica [START_REF]Project funded by the Italian Ministry of Education[END_REF] and Poste Italiane [START_REF]District of cyber security[END_REF]. The numerous GOReM practical models in different contexts, including that of system security compliance in cloud [START_REF] Furfaro | Requirements specification of a cloud service for cyber security compliance analysis[END_REF], allowed to improve the methodology potentialities and to achieve a very good satisfaction of the many stakeholders, which are different in backgrounds and for desired goals.

The rest of the paper is structured as follows: Section 2 describes an overview of GOReM; the requirements specification of a Cyber Systemic Risk in Bank is presented in Section 3. Finally, results and conclusions are drawn in Section 4.

An overview of GOReM

This description of GOReM is a small overview which we use often with the aim to give a mean to understand the models hereafter introduced. GOReM uses the UML notation [START_REF]Unified Modeling Language TM[END_REF]. As a consequence, it is easy to employ and it simplifies the concept sharing among a wide variety of stakeholders [START_REF] Caire | Visual notation design 2.0: Towards user comprehensible requirements engineering notations[END_REF]. The resulting requirements modeling activity has been recognized by the users to be easy and effective. Typical activities of requirements engineering (RE) [START_REF] Van Lamsweerde | Goal-oriented requirements enginering: a roundtrip from research to practice[END_REF], i.e. elicitation of requirements, analysis, validation, verification and management, are expressed in GOReM mainly in term of: (i) stakeholders and their goals, (ii) use cases and involved processes and (iii) work-product documentations. The methodology consists of three main phases, each of which is devoted to modeling specific aspects of a RE process: Context Modeling, Scenario Modeling and Application Modeling (see Fig. 1).

Context Modeling aims at clearly representing the reference domain. The work-products of this phase are: a Stakeholder Diagram, which shows a, often hierarchical, specification of all the stakeholders involved in the specific context; each stakeholder is in turn characterized by a set of Softgoals [START_REF] Glinz | On non-functional requirements[END_REF] they intend to pursue; a Softgoal Dependency Diagram, which shows the relationships between the stakeholders and the softgoals, as well as the relationships among softgoals (i.e., contributes, hinders, includes, extends, specializes); moreover, the Rules and Regulations that govern the context are individuated and analyzed in a work-product.

Scenario Modeling specifies different business scenarios in terms of Roles that are played by the involved stakeholders, their specific Goals, and the specific Rules and Regulations that govern the business scenario. A SWOT Analysis (Strengths, Weaknesses, Opportunities and Threats) is often performed with the aim to guide decisions on future work.

Application Modeling defines application scenarios in order to specify the functionalities which should be provided by a single business scenario resulting from the previous phase. Each application scenario is characterized by These phases are repeated iteratively and feedback among them is allowed in order to support an incremental refinement process. Furthermore, scenarios and applications are specified concurrently. A BPM model [3] of the reference process for GOReM, along with its main work-products, is reported in Fig. 1.

Modeling the banking cyber systemic risk

This Section describes a comprehensive subset of the requirements specification of the business continuity for Italian banks, as established by Bank of Italy in its guidelines in [START_REF]Guidelines on business continuity for market infrastructure[END_REF], as it has been worked out, employing GOReM, in the context of the project [START_REF]District of cyber security[END_REF].

The context model of the business continuity in a bank and the description of one of the possible business scenarios, that is the risk treatment in bank, are first described. Then, one specific application scenario, concerning the treatment of cyber systemic risk for the so called "systematically important processes" [START_REF]Guidelines on business continuity for market infrastructure[END_REF] of a bank, is modeled in terms of actors, use cases and processes.

The Context Model: banking business continuity

The banking system has a complex organizational infrastructure. In the following, we model a small subset with the only objective to give an idea of the effectiveness and powerfulness of employing GOReM for this purpose.

The term Business Continuity (BC) refers to all of the organizational, technical and staffing measures employed in order to: (i) ensure the continuation of core business activities in the immediate aftermath of a crisis and (ii) gradually ensure the continued operation of all business activities in the event of sustained and severe disruption [START_REF]Escb definitions of major business continuity terms in relation to payment and securities settlement systems[END_REF].

To this end, each bank must define a Business Continuity Plan (BCP), i.e. a formal document stating the principles, setting the objectives, describing the procedures and identifying the resources for business continuity management concerning critical and systemically important corporate process [START_REF]Guidelines on business continuity for market infrastructure[END_REF]. The bank must also use internal audit, testing activity and continuously improvement implementations of its BCP, with the aim to: (i) analyze well the exposure to risks, (ii) identify vulnerabilities, and (iii) evaluate, implement and maintain updated, appropriate BC and Disaster Recovery (DR) solutions. A critical part of the BCP is the Disaster Recovery Plan (DRP), i.e. a document establishing the technical and organizational measures to cope with events that put electronic data processing (EDP) centers out of service.

Despite suitable tools and countermeasures are constantly in action to prevent their occurrence, unfortunately accidents happen. In this cases, it is essential that a BCP is promptly put in operation, to ensure the continuity of services. Hence, the appropriated Disaster Recovery procedures, as specified by the DRP, have to begin immediately.

Fig. 2 shows a GOReM diagram that depicts the stakeholders which were identified for this context, their softgoals and the dependencies among them.

The main stakeholders are: the Bank of Italy; Banking System Operator, which can be of two different types, i.e. Operator of technological infrastructures or networks, and operating companies, i.e. wholesale markets in government securities, multilateral wholesale trading facilities in government securities, multilateral deposit trading systems, securities settlement systems, central counterparties and central securities depositories, with registered offices and/or operational headquarters in Italy; Bank personnel, i.e. people, including corporate bodies, which work internally in the bank; Service Provider, i.e. external stakeholders that provide IT services and other commodities, by stipulating specific contracts with the bank; Selling Net; Shareholder and Customer.

Each stakeholder is associated to a set of softgoals as it can be seen from Fig. 2. The identified softgoals are resumed in the following. SG1: Supervising the non-interruption of the bank's services. SG2: Every operator has to put into execution the suitable provisions, according to the BCP, for ensuring business continuity and disaster recovery in reaction to threats. SG3: Planning, keeping into operation, validating and testing, auditing and monitoring, updating the BCP. This softgoal is shared by all kinds of considered bank operators. SG4: Guaranteeing the service level specified in the contract (i.e. external providers must stipulate a contract with the bank that specifies a service level agreement among the parties and that has to be compliant to the business continuity needs). SG5: Safeguarding assets from threats. Shareholders need to be ensured about the safety of their financial assets. SG6: Guaranteeing secure and continuous operation of the bank. Both customers and selling nets need always working and safe banking services. Fig. 2 also outlines the existing dependencies among Softgoals. In particular, the achievement of SG3 and SG4 contributes to SG2. Similarly, reaching SG2 has a positive effect on SG5 and analogously the same holds for SG3 on SG6.

Scenario Model: Risk treatment

The scenario we choose to model is about the treatment of risks coming from bank defaults, financial and market crashes, human mistakes, cyber threats and so on. This scenario includes situations such as: destruction or inaccessibility of important structures, unavailability of critical information systems, unavailability of human resources essential to corporate processes, interruption of operation According to the Bank of Italy guidelines [START_REF]Guidelines on business continuity for market infrastructure[END_REF], operators must define, monitor, test and maintain updated, a BCP for coping with the above situations of crisis involving the operators or significant counterparts as, other group members, major suppliers, prime customers, specific financial markets, clearing, settlement and guarantee systems.

An important step in applying GOReM is the identification of the roles played by each involved stakeholder. Each Stakeholder, while playing a given role, has some specific goals he want to reach inside the scenario. The stakeholders-roles mapping alongside the role-specific goals are resumed by the diagram reported in Fig. 3.

Table 1 details each goal of the considered scenario while Table 2 lists a subset of the rules and regulations of interest for the scenario of Risk treatment. A unique identifier is associated to each rule/regulation and some relationships of warning with respect to others rules/regulations is given (column W) for indicating the need of a deeper analysis when applied in practice. G12 Check, at fixed times, the BCP and its updating by examining the test programs, taking part in the tests and checking the results, and suggesting changes to the BCP on the basis of the shortcomings found G13 Analyze the criteria for escalation in the case of incidents, by evaluating the length of time required to declare the state of crisis G14 Test the BCPs of the outsourcers and other critical suppliers and may decide to rely on the controls performed by the structures of the latter if they are deemed professionally capable, independent and transparent G15 Examine the outsourcing contracts to make sure that the level of safeguards conforms the corporate objectives and standards

Banking System Operator

Damage Impact reported G16 Produce an impact analysis, preliminary to the drafting of the BCP and regularly update the impact analysis, with the aim to determine the level of risk for each corporate process and highlight the repercussions of a service outage. The impact analysis considers, in addition to operational risks, also such other risks as market and liquidity risk G17 Document the residual risks, not handled by the BCP, which must be explicitly accepted by the competent corporate bodies Critical process responsible G18 Identify relevant processes relating to corporate functions whose nonavailability, owing to the high impact of the resulting damage, necessitates high levels of business continuity to be achieved through preventive measures and BC solutions activated in case of incident Checker of BC measures G19 Shareholders, together with the bank system operators and the selling net , as well as with customers, cooperate in defining the procedures for testing the planned business continuity measures in real crisis scenarios G20 Determine an appropriate frequency of the testing task for each measures G21 Write down and notify the results of tests to the competent corporate bodies and transmit, for the matters under their respective competence, to the operational units Service provider

Application Model: Cyber Systemic Risk for banks in Italy

The application model we consider is related to the Cyber Systemic Risk as dealt with by the Bank of Italy. This is one of the application models that might be derived from the above presented Risk Treatment scenario. This application model deals with business continuity and safeguards for the so referred "Systematically Important Processes", which are identified and controlled directly by the Bank of Italy and which govern essential services in the payment system and in the access to the financial markets. A malicious exploitation of a cyber threat for these processes might evolve in a systemic crisis inside other operators and on the whole financial system. For those processes, the Bank of Italy controls, asks for updates, and manages every risk of crisis and incidents.

The Bank of Italy requires that the operators, involved in systematically important processes, work actively for adjustment of the BCP. These operators must comply with stricter business continuity requirements than those which normally apply to all operators. In particular, these requirements are concerned with the recovery time of systemically important processes, the location of standby facilities, and the resources allocated to crisis management (see section III of [START_REF]Guidelines on business continuity for market infrastructure[END_REF]). Some use cases are extensions of some others which are supposed to be already defined in another application model, named "Business continuity management", where the constraints by the Bank of Italy are less stringent and related to critical processes which are not systematically important processes. A short description of these use cases is given below.

BC supervisor /

BCP adjustments and compliance monitoring (eUCa). This use case extends the use case UCa which is part of the use cases concerning critical processes which do not belong to the set of those considered systematically important. BC and DR plans, defined in the application model "Business Continuity Management", require some adjustments to become compliant with the stricter requirements defined by the Bank of Italy. The operator must also ensure continuous compliance with the special requirements and all this must be done by the responsible for these activities (i.e. the actor "BC and DR plans requirement adjustment and compliance responsible").

Main incidents and recurrent criticality check (eUCc). This use case extends the use case UCc (Business continuity plan checking). The Bank of Italy requires at least one a year of test for the safeguards provided for the continuity of the systemically important processes. Operators must actively participate in tests and market-wide simulations, organized or promoted by authorities, by markets and by the main financial infrastructures. In addition, this use case prescribes the drafting of a yearly report about: the main features of the business continuity plan; the adaptations that have been made to it; the additions implemented during the year; the tests conducted on the main incidents and criticalities.

Managing crisis notification to and from Bank of Italy (eUCd). This use case extends the use case UCd, related to notification to Bank of Italy, when the blockage of essential infrastructures is related to internal critical processes. In this case, the actor "crisis manager" must instead communicates promptly to the Bank of Italy every cyber attack and state of crisis coming from some threat to its systemically important processes. Furthermore, the use case includes the sending of an assessment report, drafted according to UC4. In addition, this use case dictates that the "crisis manager" receives the notification, coming from the Bank of Italy, that other operators are subject to a cyber attack, which might cause contagion to some of its systematically important processes. Then, this actor should raise an alert so that recovery procedures may immediately begin (see UC3).

Systemically important processes breach management (eUCe). This use case extends the use case UCe. The actor "systemically important processes manager" activates immediately the recovery procedures as indicated by the BCP and DRP when a breach to some process under its observation occurs. As specified by the guidelines, these procedures govern: (i) the recovery time that, if the cause of the blockage is internal to the operator, must not exceed four hours and the restart time must not exceed two hours.

If the blockage is due to an external contagion, the operator must activate his DR within two hours from the restart of the first affected operator.

For information systems with on line duplication of operational data the time between the recovery point and the incident should zeroed. In case of extreme situations, promptly recovery of systemically important processes, using protected off line PCs, faxes, and telephone contacts with selected counterparts, is allowed. (ii) the location of standby facilities, which must be distant from their primary facilities, possibly outside the metropolitan area in which the primary facility is located and it must be served by utilities (i.e. telecommunications, electricity, water) different from those serving the primary facility. (iii) the resources allocated to crisis management. Human, technological and logistical resources needed to keep systemically important processes operating are established in the BCP.

BC requirements the management of systematically important processes (UC1). Stricter BC requirements for systematically important processes are established by Bank of Italy. This use case directly controls the operators adjustment and the compliance of their BCPs to the evolving requirements imposed by the Bank of Italy.

Establish which operator has systematically important processes (UC2). The Bank of Italy is in charge to individuate the specific set of operators having systematically important processes.

Manage the crisis declaration coming from operators (UC3). For incidents that may have significant impact on systemically important processes, the declaration of the state of crisis is managed by CODISE, part of Bank of Italy, which begins this activity with an initial assessment of potentially damaged operators.

Internal and external impact assessment (UC4). In the occurrence of crisis, the actor "systematically important processes manager", prepares the assessment of the impact on operations of its central and peripheral structures and of the current relations with customers and counterparts.

Fig 6 and Fig. 7 report two activity diagrams that respectively model the process of handling cyber systemic risk for important banking processes and the process of managing the possible know-on effect of a cyber systemic incident inside the important processes of an operator.

Results and Conclusions

We tested the suitability of GOReM for modeling the context of business continuity in of a Bank and the requirements related to handling of the cyber systemic risk as regulated by the guidelines issued by the Bank of Italy. In the complex and touchy scenario of banking, the relevant models have been defined and graphically represented [START_REF] Caire | Visual notation design 2.0: Towards user comprehensible requirements engineering notations[END_REF]. GOReM allowed to easily identify stakeholders, roles and specific goals from which the main use cases and processes, have been derived. The result of this study is a requirements specification that may be employed as a good starting point for the devising a global approach towards the management of the cyber systemic risk in the financial and banking domain. In fact, it gives the adequate planning independence to the single bank, but under the riverbed of the constraints dictated by a supervisor authority, like the Bank of Italy for the Italian banking operators. Moreover, this vision could scale at the behavior of a node inside a bigger network, where other nodes are the other Bank of the other European Nations. In turn, this model might be applied to a coordinated European supervision institution, e.g. the European Systemic Risk Board [START_REF]Handbook on the assessment of compliance with ESRB recommendations[END_REF]. Even more, it is also desirable to scale worldwide under the control of a global authority, which might coordinate business continuity and disaster recovery for preventing and managing a cyber systemic risk, for the global financial world. As a final consideration, special attention should be paid to the time needed for a given operator to react to a cyber incident: be "promptly" might not be an adequate answer. Two observations come from this modeling experience:

(i) Cyber systemic effects are here handled by a central authority, which in this case is the Bank of Italy, that establishes the state of crisis and manages the know-on effect on other operators. This centralization may result in a waste of time even though prudential politics suggest that this is a good strategy. (ii) Time of response to a state of crisis that is communicated after some "hours" (see use case eUCe) might be a very large interval of time, especially at a worldwide level, compared to the speed of cyber threats.

A possible solution might be in modifying the hierarchical organization in a more horizontal and collaborative one, which might come only from common decided rules and regulations [START_REF]Market intermediary business continuity and recovery planning[END_REF]. However, Cyber Systemic Risk treatment in Europe and worldwide is nowadays urgent. According to [START_REF] Nouy | Single supervisory mechanism after one year: the state of play and the challenges ahead[END_REF], while business areas are already supervised, the supervision agreement for network and information security is still a work in progress. This is a big delay for cyber systemic risk that must be regained soon.

Fig. 3 .

 3 Fig. 3. Scenario Model for Risk treatment: SoftGoals-Roles-Goals Diagram

  service levels agreed with the operators, as formally state in the signed contract, in the case of crisis and ensure the continuity provisions to be put in place in keeping with attainment of corporate objectives and with the indications of the Bank of Italy Damage alerter G23 Notify promptly the operator of any incident, in order to allow immediate activation of the BC procedures Operator maintain updated the DRP, with reference to central and peripheral information systems

Fig. 4 .

 4 Fig. 4. Application Model for Cyber Systemic Risk: Actor Diagram

Fig. 5 .

 5 Fig. 5. Application Model for Cyber Systemic Risk: Main Use Case Diagram

Fig. 6 .Fig. 7 .

 67 Fig. 6. Application Model for Cyber Systemic Risk: Sistemically important processes Management Process

Table 1 .

 1 Scenario model for Risk treatment: Role and Goal Description

	Stakeholder Role		Goal Description
		BC supervisor /	G1	Each operator has its suitable Business Continuity Plan and the im-
	Bank of Italy	Damage	impact		pact of possible damages undergone by its Banks for specific systemi-
		receiver			cally important processes, is managed
		Systemically impor-	G2	Systematically important processes are individuated and assigned for
		tant processes es-		being protected by a suitable operator
		tablisher
		BC	guidelines	G3	Each operator refers to guidelines for business continuity aligned with
		maker			the actual European level of risk knowledge
				G4	Establish objectives and strategies for BCP of the bank
		Corporate bodies,	G5	Assign human, technological and financial resources sufficient to attain
		i.e. considered part		the objectives of the BCP
		of the bank	G6	Approve the BCP and successive modifications resulting from techno-
		personnel			logical and organizational adjustments and formally accept the resid-
	Bank personnel			G7	ual risks not covered by the BCP Control the results of checks on the adequacy of the BCP and of its
					measures, done at least once a year
				G8	Designate the person responsible for business continuity planning
				G9	Promote the development and regular checking of the BCP and its
					adaptation to any significant organizational, technological or infras-
					tructural innovations and in the case of detection of shortcomings or
					the materialization of new risks
		BC Responsible	G10 Supervise the planning of the BCPs by means of the coordination of
					every involved BC planner
		BC Planner	G11 Establish the BCP for the operator, compliant to the guidelines pro-
					vided by Bank of Italy
		BC Internal Audit

Table 2 .

 2 Scenario model for Risk treatment: Rules and Regulations Diagram

	Id Rules and Regulations	Type	Location/	W
			Adopter
	A CPMI-IOSCO consultative paper "Guidance	Best practice EU	B, C
	on cyber resilience for financial market infras-
	tructure", November 2015
	B Opinion of the European Central Bank of 25	Policy	EU	A, C
	July 2014 on a proposal for a directive of
	the European Parliament and of the Coun-
	cil concerning measures to ensure a high com-
	mon level of network and information security
	across the Union (CON/2014/58)
	D Guidelines on business continuity for market	Best practice Italy	A,B,
	infrastructures			E, F
	E Legislative Decree 385/1993 (the Consolidated	Law	Italy	A,
	Law on Banking)			B, G
	F Legislative Decree 58/1998 (the Consolidated	Law	Italy	A,
	Law on Finance)			B, H
	G Business continuity oversight expectations for	Best practice European	E, F,
	systemically important payment systems, is-		Union	H
	sued by Eurosystem in June 2006
	H Principles for Financial Market Infrastruc-	Best practice European	E, F,
	tures, issued by Bank for International Settle-		Union	G
	ments Committee on Payment and Settlement
	Systems (CPSS) and IOSCO Technical Com-
	mittee, April 2012

Acknowledgments

This work has been partially supported by the "National Operative Programme for Research and Competitiveness" 2007-2013, Technological District on Cyber Security (PON03PE 00032 2 02), funded by the Italian Ministry of Education, University and Research, and the Italian Ministry of Economic Development.