University of Rome “La Sapienza”

(1)

University of Rome

“La Sapienza”

Engineering Faculty

Master Thesis in Computer Engineering

Autumn Session - October 2010

A contract-based event-driven model for cooperative environments:

the case of collaborative security

Leonardo Aniello

Supervisor: Prof. Roberto Baldoni Examiner: Prof. Luca Becchetti

Assistant Supervisor: Dott.ssa Giorgia Lodi

(2)

(3)

iii

to my family and my long-time and more recent friends

(4)

Acknowledgements

I believe that one’s results heavily depend on the context he lives daily. Looking back to my life and to the goals I’ve accomplished, I consider myself very lucky to have been surrounded by persons that have always given me the required serenity and the right boost to go ahead with my aspirations despite the usual big and small troubles that one has often to face.

At this regard, I’d like to thank with all my heart my mother and my father for having supported me in all these years, in spite of the several changes I’ve made about my future directions. And I can’t forget to thank all my friends in Terni and surroundings, from the high school ones to the others that I’ve met over time, for their loud company and strong understanding.

A special thank goes to Roberto Baldoni and Giorgia Lodi for having introduced and guided me through the nice experience of getting involved in a European project and for the help they’ve given me in the writing of my thesis. I’d like also to thank Stefano, Luca and Silvia for their contribution to my work.

(5)

Introduction

The raising availability of Internet connectivity and the increase of network bandwidth are boosting the use of the world wide web for providing more and more services. Supported services range from e-commerce to social networks, from telephone calls to business-to-business transactions. Therefore a huge amount of businesses are relying on the Internet. Moreover, the access to an unbelievable quantity of high-value and sensitive information is enabled and secured employing the Internet as Critical Infrastructure. What could be the next generation services provided by Internet? Besides, is Internet reliable enough for supporting all these services?

This work aims at addressing together these two questions, investigating the paradigm of cooperative environments as a possible mean of letting diverse organizations collaborate in the context of the security of Financial Institutions. A brief overview of cooperative environments is provided, in order to introduce the main topics of the whole work. All these aspects are supported by CoMiFin, a European project focused exactly on the security of Financial Institutions. A short description of CoMiFin is also given, together with a more detailed background about Financial Institutions scenario.

Cooperative Environments

For today’s software systems, the need of timely and adaptively reacting to unpredictable changes in the environment, so as to identify and notify possible opportunities and threats to interested actors, is becoming more and more crucial. On these lines, a very interesting class of systems is that of Sense and Respond (SRS). They detect and correlate external events, that is the sense phase, and then produce on time useful outputs, that is the respond phase.

A primary property of SRSs is the ability to produce timely responses. Part of the complexity of present environments is due to the high speed in which changes occur and it’s often crucial to react with a limited delay. For example, systems that monitor Critical Infrastructures have to notify anomalies as soon as possible, in order to prevent damages to people or things.

An important aspect of SRSs is that the quality of generated responses depends on how much input is gathered. Let’s consider a system in charge of computing the fastest route to reach a certain destination. If this system were based on roads’ topology only, such calculation wouldn’t take into account any problem due to traffic condition or road accidents. The employment of some automatic

1

(8)

mean to detect the current situation of roads would surely improve the quality of computed route.

We can say ”the more I could sense, the better I would respond”. So, another relevant property of SRSs is the ability of gathering input data from several sources, possibly heterogeneous and widely distributed.

This latter property can be seen as a way of putting together many different actors with the aim of obtaining some added-value benefit. Resuming route calculation example, roads’ topology, traffic conditions and real-time information about road accidents are correlated to get the fastest way.

Another interesting example is about failure detection. In distributed systems, load peaks and hardware/software failures can heavily affect the communication between nodes. The capacity of dynamically detecting failed nodes is fundamental for carrying out main distributed communication protocols, but the delays introduced by the network and the topology of the network itself can make hard for each node to have the same knowledge about the health of the other nodes. The idea is to let all the nodes collaborate sharing their own knowledge in order to achieve a common perception about which nodes are alive and which not.

In this regard, a very interesting area of research concerns the usage of SRSs to let a set of in- dependent systems collaborate for an established common goal, creating in this way a cooperative environment. A brief analysis of the properties satisfied by this class of systems is quite helpful to identify what is needed to obtain collaboration in practice. First of all, due to the large volume of input data and to the demand for elaborating them in a timely fashion, we need to use some parallel computing paradigm, so that computation could be speeded up as required to meet time constraints. This in turn implies the employment of a huge number of computational, storage and network resources, so that a parallel elaboration could be carried out on a big input data set.

An emerging technology suitable for supporting cooperative environments is cloud computing [26].

Besides its innovative business aspects, it concerns also with the over-the-Internet provision of dynamically scalable and often virtualized resources. Its scalability is useful to face any peak in the load or hardware/software failure. The virtualization is important for maximizing resource utilization. So, cloud computing can be the right mean for having at disposal the required amount of resources where the desired parallel computing framework can be then deployed.

CoMiFin

CoMiFin (Communication Middleware for Monitoring Financial Critical Infrastructure) [3] is an EU project funded by the Seventh Framework Programme (FP7), started in September 2008 and continuing for 30 months. The research area is Critical Infrastructure Protection (CIP), focussing on the Critical Financial Infrastructure (CFI).

An increasing amount of sensitive traffic is being carried over open communication media, such as the Internet. This trend exposes services and the supporting infrastructure to massive, coordinated attacks and frauds that are not being effectively countered by any single organization. In order to

(9)

3

identify threats against Critical Infrastructures and business continuity, CoMiFin aims to facilitate information exchange and distributed event processing among a subset of participants grouped in federations. Federations are regulated by contracts and they are enabled through the Semantic Room abstraction: this abstraction facilitates the secure sharing and processing of information by providing a trusted environment for the participants to contribute and analyze data. Input data can be real time security events, historical attack data, logs, and other sources of information that concern other Semantic Room participants. Semantic Rooms can be deployed on top of an IP network allowing adaptable configurations from peer-to-peer to cloud-centric configurations, according to the needs and the requirements of the Semantic Room participants.

A key objective of CoMiFin is to prove the advantages of having a cooperative approach in the rapid detection of threats. Specifically, CoMiFin demonstrates the effectiveness of its approach by addressing the problem of protecting financial Critical Infrastructure. This allows groups of financial actors to take advantage of the Semantic Room abstraction for exchanging and processing information, thereby allowing them to take proactive steps in protecting their business continuity, for example, through generating fast and accurate intruder blacklists.

Scenario: Financial Institutions

Nowadays, the financial industry is witnessing technological and usage changes due to globalization, new trends towards the ”webification” of financial services such as home banking, online trading, remote payments, and increased competitions among financial stakeholders.

In such a context, it emerges that financial institutions’ infrastructures are no longer being confined within single organizational boundaries; they start becoming part of a global unmanaged financial ecosystem that consists of interconnected financial domains and other critical infrastructures like telecommunication supply, electricity supply in which cross-domain interactions spanning different administrative borders are in place.

As of today, the overall number of transactions being conducted over the above mentioned financial ecosystem is increasing. Specifically, it is increasing the portion of traffic that is carried out through public networks such as Internet, thus exposing the overall ecosystem to massive and coordinated attacks and frauds.

Protecting the ecosystem from faults and malicious attacks is then essential in order to ensure stability, availability, and continuity of key financial markets and individual businesses, since those attacks might also significantly compromise the results of financial transactions.

Currently, some threats or attacks targeted to different financial entities are difficult or even im- possible to be detected adopting local single-domain monitoring approaches. However, a novel approach based on inter-organization cooperation and information sharing can improve security threats detection capabilities.

The main objective of CoMiFin is to design and develop a distributed system that can enhance the

(10)

situation-awareness of financial organizations so as to allow them to better address security threats and timely trigger local protection mechanisms, thus preventing or mitigating dangerous effects.

In order to build the system, it has been considered a possible scenario within which proving the effectiveness of the CoMiFin solution.

My Contribution

Within the context of CoMiFin project introduced so far, my contribution has been twofold:

I’ve been actively involved in the analysis, design, development and installation of SR Man- ager, a component of CoMiFin system architecture that will be deeply described later;

I’ve developed a simple monitoring software aimed at collecting statistics about the performances of Agilis, a distributed parallel computing framework that will be detailed afterwards.

Organization

The thesis is organized as follow:

- in Chapter 1, the scenario of Financial Institutions is investigated in more details in order to catch the requirements the system is expected to meet;

- in Chapter 2, the architecture of CoMiFin system is illustrated by a top-down approach;

- in Chapter 3, requirements for SR Management components are identified and refined from high-level requirements, and the architecture of these components is described in more details;

- in Chapter 4, an insight of an SR for Intrusion Detection is provided, together with a possible architecture supporting it;

- finally, Chapter 5 outlines the conclusions obtained from this work and proposes some future directions for this area.

(11)

Chapter 1

Scenario and Requirements

As already stated in the introduction, the collaborative approach can offer benefits in several scenarios:

in the financial context, organizations can cooperate sharing their traffic data to improve their security defenses;

the calculation of shortest routes can be enhanced putting together info coming from sources of different nature, that is making them collaborate;

reliable failure detection services can be built on top of collaborative environments that make involved nodes exchange their knowledge about the health of other nodes.

This chapter, as well as the rest of thesis, is aimed at exploring in more details the current situation of financial environments. Most important threats are described and analyzed in order to get the basis for identifying the requirements that have been relevant for what concerns my contribution and that CoMiFin project is expected to address.

1.1 Reference Scenarios

The key elements of the overall CoMiFin financial scenario have been investigated starting from the structure of a single organization (or business entity) that may be willing to use the CoMiFin system and participate in the so-called CoMiFin cloud. Figure 1.1 depicts this structure. An organization can be thought of as logically divided into two principal parts: an internal part (the left hand side of the shaded rectangle in Figure 1.1) and an external part (the right hand side of the rectangle in the same figure). The internal part consists of the set of hardware and/or software components that communicate with each other using intra-domain communications; intra-domain communications are usually carried on over possibly proprietary and highly secure networks, using proprietary protocols. The internal part can be in turn constructed out of a set of internal networks (the dotted circles in Figure 1.1 ) that interact one another inside a major organization. These networks might define the boundaries of internal organizations that compose the major one.

5

(12)

Figure 1.1: Structure of business entity

Hardware and software resources deployed within the internal part are not accessible from the outside, since they are not directly connected to the Internet and are properly protected by hardware/software components in order to guarantee a high level of isolation. For instance, Figure 1.1 illustrates a bank corporation (i.e., Lloyds TSB) that may consist of a set of banks each of which can be located in different geographical areas by means of bank agencies. Each bank in the major corporation, and recursively each bank agency, can use an own proprietary network in order to carry out financial activities. The external part consists of the set of hardware and/or software components connected to the outside world (i.e., the Internet). In the bank corporation example of Figure 1.1, dedicated resources can be used for instance in order to provide end users with e-banking services that use communications over Internet. Communication and interaction between the external and internal parts are regulated by specific security policies and several levels of firewalls (which may include the definition of a DMZ for hosting external resources) in order to protect the internal part from attacks and unauthorized accesses.

Based on this organization structure, Figure 1.2 shows how a single organization can contribute to the construction of a global financial ecosystem, and the position in that scenario of the CoMiFin cloud.

In the CoMiFin scenario, there exist actors strictly related to the financial context, and critical service providers. Figure 1.2 depicts some financial actors such as banks (e.g., Unicredit, Lloyds TSB) and clearing houses (e.g., SWIFT), although any other organization related to the finance environment (e.g., insurances, regulatory agencies, government agencies), and critical service providers such as telecommunication companies (e.g., AT&T) and power grid companies can be also involved.

Each actor that is willing to exploit the functionalities offered by the CoMiFin system can participate in the CoMiFin cloud with a number of so-called end-points (the pattern filled circles in Figure 1.2). These end-points include dedicated software components that, along with the resources provided by each actor, are connected to the Internet in order to exploit Internet’s robustness. Events

(13)

1.1. REFERENCE SCENARIOS 7

Figure 1.2: CoMiFin in a Financial Scenario

will flow from the various end-points into the CoMiFin cloud: they will be processed by the CoMiFin monitoring system in order to obtain semantically enriched data (or processed data) for threat detection. The processed data will then be disseminated among the interested actors participating in the CoMiFin cloud.

In the considered scenario, regular transaction activities that Financial Institutions (FIs) perform are isolated from the activities carried out by the CoMiFin system. In particular, financial transactions are usually handled through dedicated networks and protocols (e.g, SWIFT) for inter- Financial Institutions activities or through proprietary secure internal or external networks that FIs maintain (e.g., between bank branches).

In contrast, in order to exploit the functionalities offered by the CoMiFin system, FIs or service providers sign a basic contract which regulates their participation in the CoMiFin cloud and the usage of the CoMiFin system.

An actor participating in the CoMiFin cloud will provide data produced by its own internal monitoring software and, in return, it will get processed data by the CoMiFin system that allows it to detect in advance possible threats and take the suitable countermeasures.

In this context, three case studies have been investigated with the aim to provide a clear image of the monitoring and communication capabilities offered by the CoMiFin system. The first two cases are related to some threats and failures that may occur in the global financial ecosystem such as

- DDoS attack [28]

malicious action aimed at making unavailable the services provided by financial actors such as banks, telecommunication suppliers, insurances, and security agencies.

- MitM attack particular threat that is carried out when an active attacker inserts himself between two communicating parties with malicious purposes.

(14)

In addition to these, one more case strictly related to the financial context has been discussed, as it introduces such typical financial crimes as Identity Theft and related fraud. This case considers the problems related to the misappropriation of identity information for criminal activities such as obtaining goods or services by fraud.

This section goes on with the detailed description of the aforementioned case studies and of the ways CoMiFin can possibly address them.

1.1.1 Distributed Denial of Service

Distributed Denial of Service (DDoS) attacks are carried out through geographically distributed attack infrastructures, commonly referred to as botnets. They can consist of huge numbers of zombie machines (some recent cases refer to more than one million of involved hosts) that are connected to the Internet and controlled by the same attacker. In order to create the attacker’s distributed infrastructure, a complex preparation phase is required. The CoMiFin monitoring system provides benefits in two different DDoS scenarios:

1. Early detection of a DDoS attack

Assumption: in this case the CoMiFin monitoring system can provide benefits only if it is possible to receive alerts about traffic spikes by the FIs and/or by Internet Service Providers (ISPs).

2. Post-processing analysis

Assumption: the involved critical infrastructures (e.g., ISPs, FIs) want to share traffic and system log data. In such a case there is no technical limit.

The preparation of this kind of attack can be very long. Usually, a specific malware propagates through a huge number of machines, replicating itself several times and exploiting some known vulnerabilities. Once the malware is installed on a machine, this becomes a so-called zombie. Addi- tional required code is then downloaded from some designated repository, so that the compromised machine can be ready to accept instructions from an entity called herder, that is in charge of controlling all the zombie hosts and coordinating the whole attack. To overcome the limitation of having a centralized coordinator, that would make the whole mechanism easy to block for security systems, the communication between the zombies and the herder is carried out using some P2P schemas or taking advantage from dynamic DNS.

The real attack begins when the herder orders it to the compromised hosts. The attack generally lasts a little time and involves a very big number of malicious machines. The goal of DDoS is saturating network connections of target host or however exhaust some of its resources in order to prevent it from correctly delivering its services. This can be obtained simply generating licit requests if the number of zombies is very high. If there are not so many malicious hosts, the requests to submit can be chosen so that they are able to heavily stress the attacked system, for example issuing queries for data that is hard to generate and that cannot be cached.

(15)

After it has been launched, a DDoS attack can be detected noticing a sudden peak in resource consumption that makes the target system unable to fulfill incoming requests. The only viable reaction is the network traffic analysis aimed at understanding the characteristics of the attack and identifying its sources, so that effective countermeasures (i.e. proper filtering rules) can be derived and possibly disseminated to other interested actors (i.e. other FIs or ISPs).

The added-value of CoMiFin results from its ability to gather traffic data from several sources (ie:

FIs and ISPs) and correlate them in order to recognize suspicious patterns. In this way, possible attacks to more systems of a particular FI or to several services of the same infrastructure can be detected earlier because they are more likely to stand out from the aggregated logs than from the log of single FIs. Moreover, deeper processing of network traffic can allow the identification of common properties of attack sources. These properties can be employed to define simpler and more effective filtering rules to disseminate to interested actors and to use for providing a common database of past attacks.

1.1.2 Man in the Middle

Man in the Middle (MitM) attacks are carried out by making a legitimate user start a connection with a rogue server, mimicking the legitimate server behavior. The rogue server is then able to initiate a fraudulent transaction with the real server by pretending to be the legitimate client.

Unlike the DDoS scenario, where the target is the FI, MitM attacks concern customer-based e- services, such as e-banking, e-payment, e-trading.

The CoMiFin monitoring system provides benefits in two different MitM scenarios:

Early detection of a MitM attack

Assumption: in this case the CoMiFin monitoring system can provide benefits only if it is possible to receive alerts about anomalous traffic patterns by the FIs.

Post-processing analysis

Assumption: the involved critical infrastructures (e.g., ISPs, FIs) want to share traffic and system log data. In such a case there is no technical limit.

This class of attacks requires the end user believe to communicate with a licit server, while in reality it is sending its requests to a malicious one. There several ways for getting this situation

a DNS server can be poisoned [25] in order to resolve specific hostnames to the IP address of a rogue server;

also a router can be compromised [21] so that packets are routed to a malicious server;

one of the emerging method is phishing [29], that consists is making the end user believe to interact with the legitimate web interface, while what it is actually watching is an indistin- guishable copy of the original one;

(16)

authentication mechanisms may present vulnerabilities that can be exploited to carry out MitM attacks

Once a customer has been lured to a rogue Web server used as MitM, the attack is extremely simple.

The user authenticates against the rogue server by sending its credentials. The rogue server stores the user credentials, relays them to the licit server, and forwards the response to the user on behalf of the licit server. This mechanism has a twofold purpose: it makes the attack much more realistic than a traditional phishing strategy, because the user receives the expected replies from the server;

furthermore, the MitM node is able to eavesdrop all data flowing between the client and the server, thus accessing to a great amount of critical information. It is also worth highlighting that the MitM attacker is able to modify on-the-fly the content of the transaction, for example by altering sensitive and critical information.

These attacks can be difficult to detect, because they appear as a normal transaction between a server and a licit (already known and registered) client. Current detection strategies are based on the identification of anomalous traffic patterns. In the instance of a simple MitM attack, in which only a very limited number of compromised servers is used to mediate the sessions of several users of the same service, it is possible for a single FI to detect a possible MitM attack through anomaly-detection algorithms. The underlying hypothesis is that customers usually access their financial services from a limited number of devices, and that the same device is not used by a large number of customers to access to the same financial services in a short period of time. Hence, a licit server receiving a high number of connections on behalf of different customers from the same device can trigger an alarm about suspicious activities.

The added-value of CoMiFin results from the possibility to early detect MitM attacks to different organizations thanks to the correlation of traffic logs coming from the organizations themselves.

Once identified, suspicious IP addresses can be promptly and automatically disseminated to FIs and ISPs in order to let them properly update their blacklists and check existing logs to locate any past attack.

1.1.3 Identity Theft

Person’s identity and the ability to prove it are central to any commercial and financial activity.

Financial organizations need to verify an identity before issuing goods or services. They need identity evidence to open bank accounts, obtain credit cards, finance, loans and mortgages, to obtain goods or services, or to claim benefits. To this purpose, they need to ensure that:

the person paying or applying for credit is who he/she say he/she is and lives where he/she claims to live;

the person’s name and address, and other information related to identity (e.g., SSN, fiscal code, driver license number) are correct.

This section provides an overview of the motivations for considering identity theft and related fraud crimes in CoMiFin, describes the preparation and the execution of these kinds of attacks,

(17)

and presents some prevention and mitigation activities that can be managed by the CoMiFin communication system. Here, identity theft is considered in its broadest meaning whereas related frauds refer to financial crimes.

Fraudsters can impersonate a person and take out various forms of credit using a good name. This phenomenon is commonly known as identity theft and identity fraud. There is a temporal and functional difference between these two types of crimes

Identity theft is the misappropriation of the identity (such as the name, date of birth, fiscal code, SSN, current address or previous addresses, credit card number) of another person, without their knowledge or consent.

Identity fraud is the use of a misappropriated identity in a criminal activity, to obtain goods or services by deception. An identity fraud usually involves the use of stolen or forged identity documents (including credit card numbers), hence it comes after an identity theft.

The economic cost to society, to enterprises and more directly to FIs provides significant motivation for the design of a comprehensive framework to prevent and arrest the growth of identity fraud and related crimes from their current levels. Statistics are impressive, as outlined below.

According to the Federal Trade Commission (FTC), ”identity theft cost American consumers US $5bn and businesses US $48bn last year” [24]. US lenders report losses of $1 billion a year due to identity fraud, but US authorities cannot accurately work out the total cost of identity fraud because of its complexity. Credit card fraud (25%) was the most common form of reported identity theft in 2006.

In February 2006, the UK Home Office ”reported that the annual cost of identity fraud had reached £1.72 billion” [30] up from ”£1.3 billion in 2002”.

In Canada, the Better Business Bureau estimated that the identity theft and identity fraud

”annual cost was $2.5 billion to Canadian consumers and businesses, and the total annual cost to the Canadian economy was estimated at $5 billion”.

The Australian Institute of Criminology (AIC) estimates the cost of fraud to Australia is in excess of AU $5 billion a year, which represents almost a third of the total cost of crime in the nation (AU $19 billion) [23]. The cost of identity fraud in Australia was estimated to be

”AU $1.1 billion a year with an estimation error of AU $130 million in 2001-02” [27].

Generally, there are two types of attack methods: to data repository or to person.

The attack of a data repository, for example a database containing all the identities of a certain service, can be carried out when sensible data is on move or exploiting temporary and uninten- tional exposures. Moreover, a malicious person working inside an organization can steal this kind of sensible data.

The attacks directed to persons can employ several channels. The most important and growing at

(18)

the moment is the e-mail, that is the mean used to carry out phishing attacks. Also traditional mail and internet website are exploited to cheat people.

This category of frauds is of interest for CoMiFin. In fact these threats are increasingly growing thanks to e-commerce and e-banking services provided by FIs and other related organizations.

People committing identity theft and fraud are used to create new false identities or to take some- one else credentials to perpetrate financial crimes, that are obviously crucial for FIs. Moreover, effectively facing this issue is a very valuable service for FIs, because identity related frauds are dangerously undermining the confidence of customers to FIs, causing potential future huge losses.

Finally, there are practical difficulties in investigating these crimes and the percentages of resolved cases are very low. So, FIs either writing-off amounts appropriated as loss or the use of alternative modes of recovery via mercantile agents as a cost-effective response.

CoMiFin project is focused on credit card frauds. The possibility to share information about identity thefts and credit card transactions between FIs and credit card companies can be usefully employed to maintain and distribute effective lists of suspicious web sites.

1.2 Requirements

The scope of CoMiFin is very wide. In fact it focuses on an absolutely complex topic that nowadays is becoming more and more critical and concerns many different aspects, ranging from the practical ways of making FIs cooperate to the devising of algorithms for detecting/predicting threats to the addressing of security and performance issues. Due to the extent of this project, my work and contribution have concerned some specific questions only. In this section, such questions are described in order to assess the actual requirements that have driven me during my master thesis.

At this purpose, I’ve identified five main areas of interest 1. general CoMiFin requirements

2. SR management requirements 3. privacy and security requirements 4. event processing requirements

5. performance monitoring requirements

1.2.1 General CoMiFin Requirements

This section is about the general and highest level characteristics that CoMiFin system is expected to exhibit. These requirements introduce also some key concepts and definitions that hereinafter will be used often, anticipating some design choices that will be exhaustively explained in the next chapter.

One of the most crucial achievement to fulfill is about giving real evidence that the system is able

(19)

1.2. REQUIREMENTS 13

to improve the security of FIs. The advantages of employing CoMiFin instead of enforcing security in the usual ways should be clear. More threats should be likely to be detected or predicted, earlier enough to let the FIs effectively react by their own or on the basis of suggestions provided by CoMiFin system. Moreover, the proposed solution should be cost-effective for participating organizations.

One of the main key concepts that has heavily influenced the development of such system is that of collaboration, already described in the introduction. The ability of CoMiFin to prove its strengths is principally based on the assumption that the involved actors have the strong will to cooperate each other for the common goal of raising their security level. Obviously, the quality of such cooperation depends also on which organizations are actually participating. The services provided by FIs (and targeted by the threats CoMiFin is willing to face) are increasingly relying on complex chains of other low-level services supplied by other kinds of providers. Power providers, telco providers and ISPs are as necessary as FIs for the correct delivery of that services. This implies that the participation of all the organizations involved in this chain is another decisive prerequisite for the success of the whole project.

Another primary concept that has been devised in the context of the project is that of Semantic Room (SR). The concept of SR is an abstraction aimed at creating a mean for the collaboration.

Joining an SR, an organization has at disposal a contract-regulated channel for sharing raw data (i.e. network traffic logs) and obtaining useful information for coping with security attacks. The aim of an SR is putting together different actors to give them back the advantages derived from their cooperation. From a technical point of view, an interesting challenge coming from this interaction is the capacity of integrating several different domains that could be considerably heterogeneous and widely distributed through the world.

Thanks to the concepts of collaboration and SR, we can get into details about the way CoMiFin has been though to work. The actors that have joined an SR look for a common goal, for example the detection and the prediction of DDoS attacks, or the blacklisting of sites suspected of being the source of MitM attacks. They share log files and other resources of interest, by means of the ability of the SR to integrate different domains and to gather a huge amount of input data. At this aim, another relevant technical requirement concerns the capability to interface the existing monitoring systems that are already installed on the resources of participants. These input data are properly processed depending on the objective of the SR, and the resulting outputs (being either the lists of suspected addresses or some advice about the suitable countermeasures to take) are then disseminated to all the interested organizations.

1.2.2 SR Management Requirements

The SR concept introduced so far is central in all the activities carried out by CoMiFin system. The management of the different SRs needs to be fully supported by the functionalities provided by the system. In order to define a distributed monitoring system and allow data, events and information to

(20)

be exchanged among different domains, a global private interconnection infrastructure is required.

CoMiFin communication system shall support the creation of an overlay monitoring network on top of the Internet and shall provide basic communication functionalities.

The organizations interested in taking part to CoMiFin should be supported by the system in the creation of new SRs as well as in the join to existing SRs. Moreover, all the operations related to the SR lifecycle management should be available. The possibility to leave a previously joined SR or the option to disband an existent SR should be supplied.

As mentioned before, the join to an SR is regulated by a contract that should define the services offered and the rules to obey, together with some specification about the quality of the declared facilities and other possible technical and organizational aspects that characterize the SR itself.

1.2.3 Privacy and Security Requirements

Being committed to improve the security of FIs and ISPs on large scale, CoMiFin can’t miss to prove itself to be attack-proof against security threats. This is consistent with the philosophy of CoMiFin based on the protection of all the critical infrastructures taking part in the chain that supports the delivery of financial services. In fact, from this point of view, CoMiFin system itself is really a critical infrastructure.

Another important class of requirements about security concerns the communication of data. The main properties to guarantee are the classic following four one

1. confidentiality

Message confidentiality means that the content of a message can be accessed only by its legitimate recipient(s). Possible recipients are a single CoMiFin participant, a subset of CoMiFin participants or all CoMiFin participants. The best solution to handle secure group communications depends on the purpose that induces CoMiFin participants in sharing information with others. These processes shall be regulated by well defined policies defining data formats, the minimum level of security to be guaranteed by the participants during the communications, information security rules, processing rules, QoS levels and other aspects.

2. integrity

Integrity means that the content of the transmitted message has not been changed during the transmission operation. That is, the recipient of the message is sure that data is identically maintained, so that the received message is the same originally sent.

3. authentication of the sender(s)

Message authentication allows all the recipients of a message to determine which of other the CoMiFin participants is the sender. If authentication information is generated according to appropriate cryptographic techniques, such as digital signatures, it is also possible to provide non-repudiation properties

4. non-repudiation of the message

(21)

Non-repudiation means that the recipient of a message is able to demonstrate to a third party that a specific CoMiFin participant sent the message itself. This property represents the basis on which cryptographic proofs of misbehavior can be built

A critical point for secure communication is the interface between CoMiFin system and the internal network of participants. CoMiFin system requires to access Internet resources and receive inputs from appliances and devices deployed in the internal network of the CoMiFin participant. To guarantee higher levels of security, CoMiFin resources should be deployed only in isolated network compartments. Multiple layers of firewalls (packet filtering and application gateways) should be used to regulate the traffic flow between CoMiFin cloud and participant’s internal network, as well as the traffic flow between CoMiFin cloud and Internet resources.

Moreover, there should be the possibility for involved organizations to anonymize the data they provide. In fact, CoMiFin system shall prevent its participants from gaining knowledge about identity and operations of other CoMiFin participants that are not willing to share such information.

At the same time, it shall collect and maintain sufficient information to perform meaningful data analysis.

Also the interaction with the end users should be properly secured. At this aim, besides the classic employment of username-password authentication to access any CoMiFin service accessible by browser, a step more should be added to guarantee an acceptable level of security. It’s worth noticing that all the SR Management functionalities described before will be available through a web interface. Since the operations that can be executed thanks to these functionalities have a strong impact both on the contract and on the membership of SRs, they must be considered highly critical. This means that a single malicious user could break the vital services provided CoMiFin, becoming a real single-point-of-failure for the whole system. A viable solution for addressing this issue can be the application of the principles of Segregation of Duties (SoD). The basic idea behind the SoD is that to complete an operation that is considered critical, the intervention of at least two different users is required. This way, the single-point-of-failure could be avoided.

1.2.4 Event Processing Requirements

This section describes the requirements about the processing activities carried out by the system on input data provided by participants and the dissemination of related outputs. CoMiFin system shall be able to collect, analyze and process large (and possibly disjoint) event streams in order to produce derived events, extract complex threats detection patterns and detect mounting attacks, imminent failures and other potentially dangerous activities. Event processing capabilities shall include:

event filtering and classification;

event pre-processing and formatting;

event aggregation and correlation

(22)

Moreover, the system shall be able to identify and suggest countermeasures and security policies to be applied for preventing or reacting to malicious activities and for mitigating the effects of attacks, failures and threats both at a local domain level and at the overall interconnected infrastructure level.

1.2.5 Performance Monitoring Requirements

The contract that regulates an SR includes a section for QoS specification, where performance constraints are likely to be set. In order to check the compliance to these constraints, monitoring activities should be carried out to assess the actual performances offered by the system. For example, interesting metrics for the processing performance could be the response time and the throughput.

(23)

Chapter 2

CoMiFin Architecture

This chapter describes the architecture of CoMiFin system. The aim is designing a flexible architecture able to address all the requirements identified in the previous chapter.

Firstly, the CoMiFin Service model is introduced. It allows its clients to form business relationships, called Semantic Rooms (SR), which can be leveraged for the information sharing and processing purposes. Each SR is associated with a contract determining the set of services provided by that SR along with the data protection, isolation, trust, security, availability, fault-tolerance, and performance requirements. The CoMiFin middleware incorporates the necessary mechanisms to share the underlying computational, communication and storage resources both across and within each of the hosted SR’s so as to satisfy the requirements prescribed by their contracts.

The processing within an SR is accomplished through a collection of software modules, called CoMiFin Applications, hosted within the SR. The architecture for the application hosting support is derived based on the types of the hosted applications, and their resource management requirements.

The design of the CoMiFin middleware faces many challenges stemming from the need to support on-line processing of massive amounts of live data in a timely fashion, wide distribution, resource heterogeneity, and diverse SLA constraints imposed by the SR contracts. In the architecture pro- posal, these challenges are addressed by following a top-down approach wherein the system is first broken down into a collection of high-level components whose functionality and interaction with each other are clearly specified. The state-of-the-art is then further elaborated for each of the proposed components and several design alternatives are presented to serve as a starting point for the ensuing design and development effort.

2.1 The CoMiFin Service Model

The primary functionality supported by the CoMiFin middleware is to facilitate information exchange and processing among participating principals for the sake of identifying threats against their IT infrastructure and business. The information sharing is facilitated through the SR abstraction, which provides a trusted environment for the participants to contribute and analyze

17

(24)

the input data. The input data can be real time security events, historical attack data, logs, etc.

This data can be generated by local monitoring subsystems (such as system management products, Intrusion Detection Systems (IDSs), firewalls, etc.) installed within the IT of the participating principals, but also from external sources.

The processing within the SR is accomplished through various types of applications, which can support the following functionality:

1. data pre-processing, which may include filtering and anonymization;

2. on-line data analysis for real-time anomaly detection (such as complex event processing);

3. off-line data analysis;

4. long-term data storage for the future off-line analysis and/or ad-hoc user queries.

The results of the processing can be either disseminated within the SR, or exported to other SRs and/or external clients. The output might include descriptions of the suspicious transactions, users, network addresses, attack signatures, etc. The rules for information sharing and resource provisioning within the SR are governed by the SR contracts.

2.1.1 CoMiFin Principals

CoMiFin principals are those organizations that can exploit the functionalities made available by the system. Specifically, in current design and implementation, the following types of entities can be involved:

FI stakeholders are the Financial Institutions primarily targeted by CoMiFin. Provided services are aligned with the needs of these organizations: banks, insurance companies, in- vestment management organizations;

FI Utilities forming the operational environment of financial institutions are the organizations that can influence the IT of the FI stakeholders (ISP, Telco, Power Grid, SW services, HW providers, external service providers);

Additional FI players are organizations that play an important role in the interaction of FI stakeholders (government agencies, regulatory agencies, FI associations, brokers, stock exchange, rating agencies);

CoMiFin Providers are organizations that offer various types of IT resources for the operation of the system (ISP, ASP, HW/SW provider, hosting businesses, cloud computing platform provider);

CoMiFin Authority is an organization that is trusted by the principals. The CoMiFin Au- thority (CA) is responsible for the organization and operation of the whole CoMiFin system.

It can host some centralized parts of the system. Typically, a CA is a trusted third party,

(25)

2.1. THE COMIFIN SERVICE MODEL 19

such as a central bank, a regulatory body or an association of banks. Such an authority not necessarily provides resources for CoMiFin but is needed for the management of contractual processes;

CoMiFin Partner is a business entity or organization interested in the CoMiFin services.

Unless otherwise stated, the term Partner will be used instead. A CoMiFin Partner subscribes to the system by signing a basic contract and can belong to either FI stakeholders, FI utilities, additional FI players, CoMiFin Providers;

2.1.2 Semantic Rooms

An SR is a federation formed by a subset of partners for the sake of information sharing and processing. Partners can participate in a specific SR performing a join operation.

Each SR is associated with a contract that defines the set of processing and data sharing services provided by that SR along with the data protection, isolation, trust, security, dependability, and performance requirements. Since SRs will typically encapsulate various types of data processing services (such as on-line event processing, or long-running analytics and intelligence extraction), the data processing scenarios will be used to illustrate the discussion of the SR functionality below.

Figure 2.1 depicts the SR data handling. As shown in this figure, SR participants provide raw data that are then processed in order to produce processed data. Raw data may include real-time data, inputs from human beings, stored data (e.g., historical data), queries, and other types of dynamic and/or static content.

Processed data can be used for internal consumption within the SR (the lined arrow in Figure 2.1):

in this case, derived events, models, profiles, blacklists, alerts and query results can be fed back into the SR so that the participants can take advantage of the intelligence provided by the processing.

In addition, a (possibly post-processed) subset of data can be offered for external consumption (the diamond arrow in Figure 2.1). The processed data can be rendered by means of Graphical User Interfaces (GUIs) or Dashboard applications.

Figure 2.1: SR data hadnling

(26)

Semantic Rooms Members and Clients

The organizations that participate in an SR are called SR Members. They have full access to both all the raw data that the members agreed to contribute by contract, and the data being processed and thus output by the SR. The Members can also be in charge of performing processing and dissemination.

In addition to the SR Members, there might exist SR Clients. They cannot contribute raw data directly to the SR but can be the consumers of the processed data the SR is willing to make available for the external consumption. Figure 2.2 illustrates the SR Client and Member roles.

The CoMiFin Partner that instantiates a new SR becomes the SR Administrator of such SR. It

Figure 2.2: SR Members and Clients is in charge of

defining the details of SR contract;

managing/supervising the on-going SR operations;

possibly cancel the join of Members;

finally disband the SR.

SRs can communicate with each other. In particular, processed data produced by an SR can be injected into another SR (e.g., through the SR client role above). The ability for SRs to communicate with one another may enable a composition of multiple services, provided by each individual SR, into higher-level functionalities. For instance, processed data in the SR related to

”DDoS attacks in banks” can be used by a more specialized SR such as ”DDoS attacks in banks of a country” whose data can be in turn used by the SR related to ”DDoS attacks of a bank in a specific country” in order to provide CoMiFin partners with richer services.

Semantic Room Contract

An SR Contract is used to define the set of rules for accessing and using data processed within the SR. There is a contract for each SR. Partners willing to participate in the SR must sign it.

According to state of the art on contracts definition, an SR contract includes four main parts

(27)

2.2. COMIFIN ARCHITECTURE 21

1. details of the involved parties 2. contractual statements

3. Service Level Specifications (SLSs) 4. the signatures of the involved parties

2.2 CoMiFin Architecture

The framework that supports the Semantic Room abstraction over a pool of (locally and geographically) distributed computational, storage, and network resources is shown in Figure 2.3. In the framework we can clearly identify two principal layers: the SR management layer which is responsible for the management of the SR, and the Complex Event Processing and Applications layer which realizes the SR processing and sharing logic. In addition, all the architectural components of both layers above can utilize various commodity services for

exchanging control and monitoring information among them (such as load and availability),

managing resource allocation to the complex event processing and applications both off-line and at run time through the use of controllers and schedulers,

storing processing state and data. In the following subsections we describe in more detail the layers of our framework

Figure 2.3: The framework

(28)

2.2.1 SR Management

This layer is responsible for supporting the SR abstraction on the top of the individual processing and data sharing applications provided by the Complex Event Processing and Applications layer.

It embodies a number of components fulfilling various SR management functions. Such functions include the management of the entire SR lifecycle (i.e., creation of an SR, instantiation of an SR, disband of an SR, management of the SR membership), the registration and discovery of SRs and SR contracts, the configuration and planning of SRs, the management of the communications among different SRs, and the management of trust and reputation within SRs. In addition, each SR member interfaces an SR through the use of a component of this layer termed SR gateway.

This component transforms raw data into events in the format specified by the SR contract. In general, this transformation is necessary as depends on the specific SR objective to be met and com- prises three distinct pre-processing steps; namely, filtering, aggregation, and anonymization. This latter consists of applying different anonymization techniques in case privacy and confidentiality requirements are prescribed by the SR contract.

2.2.2 Commodity Services

A number of services can be used by both layers previously mentioned in order to provide functionalities such as communication, storage, resource and contract management, and monitoring.

These services are transversal to the other layers and are described in isolation in the following, highlighting several design alternatives available at the state of the art and that can be used for their implementation.

Storage Services

The Storage Service layer of the architecture consists of a collection of components providing various kinds of storage services to the other layers. This layer can embody services for long term storage of large data sets, such as monitoring logs and historical data , and for low latency storage of limited amounts of real-time data.

Communication

The Communication layer consists of a collection of components providing various kinds of communication services to the other layers. This layer can include large-scale group communication services, reliable low-latency, high throughput message streaming services that are useful for supporting real time event streaming from within the external components into an SR, and pub- lish/subscribe services.

Resource and Contract Management

The Resource and Contract management layer is responsible for allocating physical resources (such as computational, storage, and communication) to the SRs so as to satisfy the business objectives

(29)

(such as performance goals, data and resource sharing constraints, etc.) prescribed by the SR contracts. A capacity planning study might be completed in the preliminary phase of an SR startup. In such a way, the Resource Management layer ”can be aware” of the maximum capacity that each SR has to provide in terms of computational power, throughput, memory and storage.

To this end, this layer can include a scheduler and placement controller for initial allocation of the services to the physical resources, and a runtime load balancer for possible dynamic re-allocations.

As each SR can count on a set of (locally and geographically) distributed data and computational resources, we find convenient to consider the following three alternatives for the SR deployment that can be all three supported by our framework:

SR-owned platform

the computational resources of each SR are owned by its members, although one member is deputy as an SR administrator. The computational platform of an SR is fully dedicated to the complex event processing and applications of that SR.

Third party-owned platform

the computational resources are owned by a third party. The computational resources could be shared among the complex event processing and applications of the SRs. The collocation and data flows can be subject to some restrictions specified by the SR contract. This alternative corresponds to the so called ”SR as a service”

Mixed platform

the computational resources of each SR are owned by the members of that SR. This platform runs the logic of its SR, but it can occasionally offer hosting services for running the logic of other SRs. This case is allowed only after explicit request coming from another SR where its complex event processing and applications exceed the capacity of its computational platform and implies some business (and trust) relationship among the involved SRs.

Metrics Monitoring

The Metric Monitoring layer is responsible for monitoring the architecture in order to assess whether the requirements specified by the SR contract are effectively met. As the Metrics Monitoring is a transversal layer of the framework, it operates at both the SR Management and Complex Event Processing and Applications layers. In particular, at the SR Management layer it is in charge of periodically collecting monitoring information related to the management of SRs (e.g., SR membership information) in order to detect whether that management violates the requirements included into SR contracts. The Metrics Monitoring keeps track of the dynamic behavior of the SRs and check whether or not SRs and SR members themselves are honoring their respective contracts.

In case the Monitoring detects that SR contracts are close to be violated, it interacts with SR Management components in order to trigger proper reconfiguration activities.

At the Complex Event Processing and Applications layer (see below), the Metrics Monitoring is in charge of periodically evaluating whether or not the resource management required by this layer is

(30)

effectively able to support the execution carried out within this layer. In addition, it is responsible for detecting whether or not the processing execution violates all those requirements specified into the SR contracts. The Metrics Monitoring uses ”sensors”, possibly located at physical resource and container levels, in order to obtain the set of information required for enforcing the metrics of interest (in our current implementation we favored the use of Nagios monitoring technology [12]

for metrics monitoring purposes).

2.2.3 SR Complex Event Processing and Applications

This layer consists of applications implementing the data processing and sharing logic required to support the SR functionality. A typical application being hosted in an SR will need to fuse and analyze large volumes of incoming raw data produced by numerous heterogeneous and possibly widely distributed sources, such as sensors, intrusion and anomaly detection systems, firewalls, monitoring systems, etc. The incoming data will be either analyzed in real-time, possibly with assistance of analytical models, or stored for the subsequent off-line analysis and intelligence extraction. This suggests a characterization of the applications supported by an SR, whose runtime instances can be hosted within various runtime container components. In particular the application containers, which can be either standalone or clustered can be the following:

Event Processing Container

This container is responsible for supporting event-processing applications in a distributed environment. The applications manipulate and/or extract patterns from streams of event data arriving in real-time, from possibly widely distributed sources, and need to be able to support stringent guarantees in terms of the response time and/or throughput.

Analytics Container

This container is responsible for supporting parallel processing and querying massive data sets on a cluster of machines. It will be used for supporting the analytics and data warehousing applications hosted in the SR.

Web Container

This container will provide basic web capabilities to support the runtime needs of the web applications hosted within an SR. These applications support the logic enabling the interaction between the client side presentation level artifacts (such as web browser based consoles, dashboards, widgets, rich web clients, etc.) and the processing applications.

Different implementations of the Complex Event Processing and Applications layer can be supported by our framework. In particular, it can be possible deploying an SR that uses a central server for the implementation of both event processing and analytics containers. In this case, financial institutions of the SR send their own data to the central server). The central engine performs the correlation and analysis of the data and sends back to the financial institutions the generated processed data to let each financial institution adopt its own countermeasures in a timely fashion.

(31)

However, although this solution is fully supported by our framework, it suffers from the inherent drawbacks of a centralized system. The central server may become a single point of failure or security vulnerability: if the server crashes or is compromised by a security attack, the complex event processing computation it carries out can be unavailable or jeopardized. In addition, the volume of events the central server can process in the time unit is limited by the server’s processing and bandwidth capacities, thus limiting the system scalability. Therefore, in our current implementation of the architecture we favored the use of technologies that allow us to realize a decentralized complex event processing.

(32)

(33)

Chapter 3

SR Life Cycle Management

The most of my contribution to CoMiFin project has been focused on the development of the SR Manager component. It is in charge of managing the life cycle of the SRs and all the interactions with the Partners and users of CoMiFin system. A more detailed description of SR model and involved users is provided so that design choices can result clearer. Since it is the main element for the management of SR life cycle, its interactions with the other CoMiFin components are also fundamental for better understanding its internal organization.

This chapter is organized accordingly to the aforementioned topics.

Firstly, the requirements specific to SR Manager are identified and refined. All the matters about SR abstraction are issued, from the details of SR life cycle to the structure of the contract. An exhaustive explanation is also given about the way users can be managed in order to apply SoD principles.

Subsequently, an high-level design is presented, based on the interactions with the other components as well as with the end users, so that a functional overview of SR Manager can be provided.

Then, an architecture is exposed, together with a formal description of the data model on which the SR Manager in based.

Finally, few words are spent about some implementation details, such as employed technologies.

3.1 Requirements

This section puts the basis for the next functional design of the component. Concepts that are very important for SR model are definitely defined, such as Basic Contract, Contract Schema. The life cycle of an SR is then completely specified, so that more formal approaches can be used to implement related software modules. The way SoD actually applies to user management is also described.

27

(34)

3.1.1 SR Model

So far, the concepts about SRs have not been deepened enough to be able to proceed with the design of the related management functionalities. In fact, the life cycle of a generic SR should be formally defined. Before an SR could be instantiated, a contract should be specified, so a precise knowledge about contract structure should be provided. Moreover, an explanation on how a generic organization is expected to participate in CoMiFin is missing. In order to tell the whole story, this section is structured as follow

Basic Semantic Room and registration: explains the way an interested actor can take part to CoMiFin;

Contract and schemas: defines the structure of a contract and introduces the important distinction between SR Schema and SR Instance;

SR life cycle: the various phases of the existence of an SR are specified.

Basic Semantic Room and Registration

In the previous chapter, the CoMiFin Authority (CA) entity has been introduced. The fact that it is trusted by every Partner is crucial and can be exploited to enforce some restricted rules for participating in CoMiFin. With the aim of reusing existing concepts, the participation of an entity to CoMiFin has been modeled employing the notion of SR. The system comes with a fixed SR called Basic Semantic Room whose Administrator is the CoMiFin Authority. An entity willing to become a Partner has to join the Basic SR, signing the related Basic Contract. At the moment, the exact content of such contract has not been decided, it will become surely clearer once the system will be going in production. The actual point to get here is the fact the becoming a CoMiFin Partner corresponds to join the Basic SR.

Obviously, the mechanisms used to let an organization join the Basic SR are different from those employed to make a Partner join a generic SR, because in the first case the organization must be registered to the system and given the required accounts. Moreover, to avoid that any company participate to CoMiFin, a point should be set where a decision could be taken about accepting or not a new Partner. To address this issue, a registration phase has been included, where an entity interested to join CoMiFin specifies its general information and submits its request to participate to the CA, which in turn decides whether such entity owns all the characteristics to take part into the system and applies its own choice.

Contract and Schemas

This section is about SR contracts and concerns more generally the information needed to create a brand new SR, with the aim of understanding which could be the best way of formulating such functionality. Before going on, it’s important to give a more formal specification of the SR abstraction. It is defined by the three following principal elements:

(35)

the contract

each SR is regulated by a contract that defines the set of processing and data sharing services provided by the SR along with other QoS requirements. The contract also contains the hardware and software requirements a member has to provision in order to be admitted into the SR.

the objective

each SR has a specific strategic objective to meet. For instance, there can exist SRs created for implementing large-scale stealthy scans detection, or SRs created for detecting Man-In- The-Middle attacks.

the deployment

the event processing engine of each SR is implemented using a specific technology and a particular set of software.

A simple example can help to introduce next choices. Let’s assume that there exists an SR with its own members aimed at tackling DDoS attacks and that its event processing engine is implemented in a certain technology. Afterwards, other CoMiFin Partners decides to form another SR for facing the same DDoS threat, but with an event processing engine using a different technology, maybe because a better technology has came out or for example because the license of the other is not suitable per these Partners. It’s clear that the two SRs share many characteristics, in fact they are likely to be different only for the technology employed and maybe for the value of some QoS parameter.

As another example, consider again an SR for DDoS but constrained to have only Italian members.

This could happen for example because Italian banks and interested telco providers have found a convenient common agreement for this collaboration. Then, assume that a similar agreement is reached also in Spain, so that another SR for DDoS is created, this time forced to accept only Spanish members. In this case also, the two SR are almost equals, in that they differ only for the membership.

These examples are to show the potential need of instantiating the same SR in different ways. In order to address this requisite, a distinction has been made between the schema of an SR and the instance of an SR. The idea is that when an SR is created, an SR schema is defined, specifying a set of information that will be discussed later. The instantiation of an SR boils down to the creation of an SR instance starting from an SR schema. Such an instantiation consists in the definition of further information besides the ones derived from the SR schema. Another distinction that arises naturally is the one between a contract schema and a contract instance. An SR schema is associated with a contract schema that defines a set of information. An SR instance derived from that SR schema is associated with a contract instance that is based on that contract schema. Furthermore, an SR schema can define a set of possible deployments, each of one corresponding to a different set of software that set up an instance. When an SR is instantiated, one of those deployments is chosen.

University of Rome “La Sapienza”