Walid Benghabrit

Hervé Grall

Jean-Claude Royer

Mohamed Sellami

Karin Bernsmed
email: karin.bernsmed@sintef.no

Anderson De Oliveira
email: anderson.santana.de.oliveira@sap.com

Anderson Santana

De Oliveira

Abstract Accountability Language

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

On-line processing of personal data requires privacy assurance and transparency on how data protection principles imposed by regulatory frameworks are being implemented by service providers. In addition, data owners need to have means to legally hold service providers accountable for their data processing and usage. Accountability for computer systems, as defined in [START_REF] Weitzner | Information accountability[END_REF], can be viewed as a general posteriori control to ensure the enforcement of some announced promises. In the following, the term "clauses" refers to theses promises. Setting up an accountable system faces many challenges. First, there is no adequate language for accountability clauses representation; such clauses are generally stated in natural language, making it hard for computer programs to assert whether or not service providers are respecting their clauses. There is also a lack of automated assurance necessary to assert that a service provider's clauses are being carried out (for instance, the collection of events showing who created a piece of data, who modified it and how, and so on). In addition, effective and profitable use of on-line services relies on data transfer and storage across different services. These services may be hosted at heterogeneous environments and using different representations for their accountability clauses. This heterogeneity makes it difficult to check clauses compliance in an automated way and the data-owner has no means to verify that her/his preferences are being respected.

Different machine readable representations of privacy obligations have already been proposed [START_REF] Deyoung | Experiences in the logical specification of the HIPAA and GLBA privacy laws[END_REF][START_REF] Métayer | A formal privacy management framework[END_REF][START_REF] Piolle | Representing privacy regulations with deontico-temporal operators[END_REF]. However they only cover the preventive aspects of accountability and do not offer constructs to represent the other aspects (i.e. auditing and rectification). Despite some formal work, like [START_REF] Etalle | A posteriori compliance control[END_REF][START_REF] Jagadeesan | Towards a theory of accountability and audit[END_REF][START_REF] Feigenbaum | Towards a formal model of accountability[END_REF][START_REF] Zou | A formal service contract model for accountable saas and cloud services[END_REF], there is not yet a concrete formal language close to legal or contractual texts for data privacy obligations. To express accountability clauses we propose in this paper an Abstract Accountability Language (AAL), which is devoted to expressing accountability clauses in an unambiguous style and which is close to what end-users need and understand.

The content of this paper is as follows : Section 2 presents background on accountability and related work. The syntax and semantics of AAL are presented in Section 3. We show the expressiveness of AAL in Section 4. Finally, we discuss our results and present directions for future work in Section 5.

Background on Accountability

In [START_REF] Weitzner | Information accountability[END_REF], the authors argue that the usual "hide-it-or-lose-it" perspective on information is dominating but not adequate in a world where information should be communicated to third-parties. Classic privacy means and access control are insufficient to guarantee the protection of privacy since the data can be duplicated on the Web and it is possible to infer accurate details from public information.

In the context of the EU A4Cloud project 4 , we consider that accountability concerns data stewardship regimes in which organizations that are entrusted with personal data may be responsible and liable for collecting, sharing, storing and otherwise processing the data according to contractual and other legal requirements from the time the data are collected until when the data are destroyed. Legal accountability is a subset of accountability and covers accountability clauses imposed by laws and regulations. In this paper we use the term clause to denote anything an actor is required to do because of a promise coming from a contract or the legislation. This refers to a legal duty that the actor is forced to perform and it implies some sanctions for neglecting it.

The analysis of accountability done in the A4Cloud project identifies four roles related to the creation, storing and processing of data. These roles are already present in current regulations like "Directive 95/46/EC". Data subject: this role represents any end-user which has data privacy concerns. Thus the data subject is the original creator of a data and express preferences about the future management of his data. Data controller : it is legally responsible to the data subject for any violations of its privacy and to the data protection authority in case of misconduct. Data processor : this role is attributed to any computational actor which processes some personal data. It should act under the control of a data controller. Auditor : it represents data protection authorities which are in charge of the application of laws and directives related to data privacy.

As said before, several languages for specifying privacy preferences and policies. Despite the fact that they provide means for expressing formal and verifiable clauses, they are not readable by lawyers or privacy officers who may be involved in an accountable system. In addition, as far as we know, there are neither tool nor method to assist the design and the analysis of an accountable system proposed with these models. This makes it difficult for end-users to the compliance of a set of clauses (i.e. policy) with a given data privacy regulation or to compare two policies. In the previously cited research, authors also propose an approach to validate the correctness of their clauses, which is inadequate for non software verification specialists.

This paper presents a language for accountability clause representation that is: i) Close to natural language: to be adequate to end-users who do not necessarily have skills in a certain policy language, ii) Machine understandable: to be enforceable and to offer means for implementing audit functionalities required for violations detection and evidence collection within an accountable system. iii) Expressed in a formal language: to promote its automatic compliance checking and verification, and iv) Abstract: to act as a pivot model between different accountability clauses representation models and as such promotes the interoperability of heterogeneous systems.

AAL is only the top part of the design of an accountable system; in [START_REF] Benghabrit | A cloud accountability obligations representation framework[END_REF] we present an end-to-end framework for accountability from natural clauses to concrete policy enforcement relying on our AAL language.

Abstract Accountability Language

To represent accountability clauses, we adopt the point of view of [START_REF] Feigenbaum | Systematizing "accountability[END_REF] with minor modifications. We consider that an accountability clause to be a triplet (uc, aa, rc). The informal meaning of such clause is: "Do the best to ensure the usage control (uc), and if a violation of the usage is observed by an audit (aa) then the rectification (rc) applies". Usage control covers classic access control but also data distribution (or data transfer). The audit part covers the detection, judgment and evidences collection steps 5 . Rectification subsumes punishment 5 and includes also sanction, remediation and compensation functionalities.

In contrast to [START_REF] Feigenbaum | Systematizing "accountability[END_REF] we consider not only clauses violators but also victims and not only punishment but also remediation and compensation for the victims. We focus here on accountability clauses as expressed in legal directives. To give a formal and rigid description of these clauses we define a formal and abstract language AAL for Abstract Accountability Language. In our abstract approach we assume that there is an implicit secure logging mechanism. These logs should be sufficient to provide effective detection of breaches and identification of violators.

Means to secure logs and auditing is out of the scope of this paper, but the interested reader can look at [START_REF] Vaughan | Evidence-based audit[END_REF]. In the following, we introduce the syntax of AAL in Section 3.1 and its associated semantics in Section 3.2.

Syntax

We present in Listing 1.1 the syntax of a minimal AAL kernel. An AAL program is divided in two parts: declarations and clauses. The declaration part allows users to declare system agents (with theirs types, actions that they can performs called provided services PS() and actions they can uses called required services RS() (line 3)), services (defined by a name Id, arguments Types, and optionally a purpose specifying the context of their usage Purpose (line 4)) and data (with their types (line 5)). We use a first-order type system supporting sub-typing for the data types declaration 6 . The clauses part, as mentioned before, an accountability clause (line 7) is a triplet (uc, aa, rc).

-Usage control uc, is a combination of actions 7 and conditions applied on variables that can be quantified (line 8). We represent actions in the following form: agent1.action [agent2](args) (line 15) where: agent1 (resp. agent2) is the agent using (resp. providing) the action and args the needed arguments. Optionally we can add a purpose and time 6 . The keyword THEN is used in the sense of implication, exp1 THEN exp2 means that when exp1 occurs then exp2 must also occurs. The exp1 ONLYWHEN exp2 construction means that exp1 occurs only if exp2 has been realized in the past. -Audit actions aa are introduced by the AUDITING keyword and are expressed as agent1.audit[agent2]() (line 9) where: agent1 is an auditor auditing agent2's logs. Such an audit operation can be more complex therefore we extends it by adding usage control [Usage THEN].

-Rectification rc is introduced by the keyword IF VIOLATED THEN (line 10) followed by an usage expression, that represents the actions to perform when the audit detects that the usage control uc has been violated.

Semantics

In order to interpret the language AAL, we resort to temporal logic [START_REF] Fisher | Temporal representation and reasoning[END_REF]. Lineartime temporal logic (LTL) is a modal logic with modalities referring to time. Indeed we focus on an extension with quantified data, known as first-order temporal logic [START_REF] Hodkinson | Decidable fragment of first-order temporal logics[END_REF]. Precisely, the grammar is defined in Table 1. Note that ϕ ranges over any set of propositions defined over the set of events: this set is assumed to be given, as well as the interpretation of each proposition as a subset of events.

formula ψ ::= true | false | ¬ψ | ψ ∨ ψ | ϕ (propositional formulas) | ∃x.ψ (first-order formulas) | Xψ | Gψ | Fψ (temporal formulas (future)) | X -1 ψ | G -1 ψ | F -1 ψ (temporal formulas (past))
Table 1: Temporal Logic: Syntax

We will now describe the temporal operators. Assume that a finite sequence of events is given, as well as a position in the sequence. Xψ : ψ is true in the next position (in the sequence of events), X -1 ψ : ψ is true in the previous position, Gψ : for next positions, ψ is always true. Its dual (with respect to negation) Fψ : ψ will be true at some time. Symmetrically, G -1 ψ means that for previous positions, ψ has always been true; its dual (with respect to negation) F -1 ψ means that ψ has been previously true.

Instantiation and Extension for Accountability. In order to instantiate the general framework presented in the preceding paragraph, we need to define the set of events and the set of atomic predicates. The set of events is defined as the set of messages exchanged. A message is a structure with four components: source (emitter), target (receiver), the service name and a data (the content). Such a message is written as: source.service[target](data). The atomic predicates over the set of events are defined with patterns (terms with free variables) or with logical predicates (equalities, comparisons). Given a pattern ϕ, a message e and a valuation σ assigning closed terms to the free variables in ϕ, ϕ(e) is satisfied if the term ϕ[σ] is equal to message e. A predicate ϕ equal to a disjunction ∨ϕ i of patterns ϕ i can be extended to a sequence of message in order to define a projection: if π is a sequence of messages, then ϕ(π) is the sub-sequence of π containing all the messages e in π such that e satisfies some ϕ i for some valuation, and only these messages. We add a new modality for accountability :

formula ψ ::= . . . | Acc(ϕ : ψ)(ϕ : ψ) (Accountability)
Intuitively, a sequence π satisfies proposition Acc(ϕ 1 : ψ 1 )(ϕ 2 : ψ 2 ) at position p if the sequence before p satisfies ¬ψ 1 when projected with ϕ 1 and the sequence after p satisfies ψ 2 when projected with ϕ 2 . More formally, given a sequence π and two positions p and q such that (0 ≤ p ≤ q < |π|), we denote the subsequence of π starting at p and terminating at (q -1) by π p,q .

(π, p) Acc(ϕ 1 :

ψ 1 )(ϕ 2 : ψ 2 ) def ⇔ (ϕ 1 (π 0,p+1 ), p) ¬ψ 1 ⇒ (ϕ 2 (π p+1,|π| ), p) ψ 2
Interpretation. We give the main elements for the interpretation of AAL accountability clauses. Let (uc, aa, rc) an AAL clause with its three parts, the accountability clause is translated using the Acc modality G(aa =⇒ Acc(ϕ 1 : uc)(ϕ 2 : rc)). Actions are represented by messages : source.service[target](data). The Boolean operators (NOT,AND,OR) and quantification (FORALL,EXISTS) are translated in a straightforward manner : NOT ¬, AND ∧, ... . The operator MUST is translated in F , ALWAYS in G and MUSTNOT translated in G¬. The operator THEN is translated as an implies =⇒ . The ONLYWHEN operator is used for past and translated in => F -1 . The MAY operator is interpreted as a conjunction of MUSTNOT with the idea that what is not permitted is forbidden. For instance, if Required is the set of required actions for agent a, and act ∈ Required then MAY a.act is translated as b∈Required∧¬b=act G ¬b.

Validation : The Health Care Use Case

To validate the expressiveness and adequacy of AAL for accountability clauses representation, we extract clauses from a realistic use case documented in [START_REF] Bernsmed | Use case descriptions[END_REF] and illustrate their representation in AAL. This use case concerns the flow of health care information generated by medical sensors in the cloud. Patients will be connected to wireless sensors that monitor their vital signs (e.g., movement, temperature, etc.). The sensor data will be transmitted to the cloud where they will be further processed and stored. Figure . 1 represents a component diagram for the use-case. In this design, involved actors are represented as interconnected components. The interactions between the components are made via interfaces representing the different services offered and used by the actors. In the following we present three accountability clauses and their representation in AAL.

Clause 1: The data subject's right to access, correct and delete personal data. This clause is statically ensured by the AccesRightInterface (noted ARI* in Figure . 1) interface. However, this preventive means cannot be sufficient since for instance the actor Y might not implement actions properly. Thus the hospital clause should be written in AAL, making explicit the audit step and the rectification that applies in case of violation. them. We assume that the hospital defines a specific protocol to get the explicit consent. In a first time the hospital sends its policy to the patient (sendPolicy) which then replies to the hospital with its consent or not (explicitConsent). Clause 3: The data controller must notify the data subjects of security or personal data breaches. In case of a security or privacy incident that is related to the patients' personal data, Cloud providers X and Y must notify m platform, m must notify the hospital and the hospital must notify the patients. We assume that the hospital has been informed (or has detected) a violation with the violation action. The usage clause is below. The three clauses presented above shows that AAL is capable of expressing the accountability requirements for all actors involved in the use case.

Conclusion

Accountability makes clear the responsibilities of data controllers, in particular in the case of data breaches, reinforcing trustworthiness in the cloud. We propose for the first time a domain specific language (DSL) to express rules close to sentences in laws, data directives and contracts. This language is equipped with a formal logical background and is the first stone towards clauses enforcement trough accountable design and verification. We demonstrate the expressiveness of AAL on a use case that includes real examples of clauses from data protection legislation. Our proposal defines conditions and event sequences which are relevant to express complex chains of actions. The syntax of AAL is simple and abstract enough making it human readable and such it can easily be used by non specialist users. At the same time, AAL is based on a temporal logic semantics making it machine readable. Such semantics allows early expression simplifications, well-formedness checking and verification of expected properties. We start such a work in [START_REF] Benghabrit | Accountability for Abstract Component Design[END_REF] using the mCRL2 model-checker. We are currently developing a Web based framework called AccLab 8 , to support these concepts.

Accountability clauses written in AAL are quite close to natural language. However, there is still work to fill the gap with data protection legislation. The exact shape of AAL is not definitive since more experiments will be needed. We have started thinking on design and verification but one important aspect is to develop techniques for manual and automatic clauses enforcement.

  AgentDec | ServiceDec | DataDec 3 AgentDec ::= AGENT Id TYPE '( ' AgentType * ') ' RS '( ' service * ') ' PS '( ' service * ') ' 4 ServiceDec ::= SERVICE Id TYPE '( ' Type * ') ' [ Purpose ] 5 DataDec ::= DATA Id TYPE '( ' Type * ') ' SUBJECT agent 6 AgentType ::= " Subject " | " Controller " | " Processor " | " Auditor " 7 Clause ::= CLAUSE Id ': ' Usage [ Audit Rectification ] 8 Usage ::= [ Quant Variable ]* ActionExp 9 Audit ::= AUDITING [ Usage THEN ] agent . audit '[ ' agent '] ' ' () ' 10 Rectification ::= I F _ V I O L A T E D _ TH E N Usage 11 ActionExp ::= Action | NOT ActionExp | Modality ActionExp | 12 Cond | ActionExp ( AND | OR | THEN | ONLYWHEN ) ActionExp 13 Exp ::= Variable | Constant | Variable . Attribute 14 Cond ::= [ NOT ] Exp | Exp [ '= ' | ' != '] Exp | Cond ( AND | OR ) Cond 15 Action ::= agent . service [ '[ '[ agent ] '] '] '( ' Exp ') ' [ Time ] [ Purpose ] 16 Quant ::= FORALL | EXISTS 17 Variable ::= Var ': ' Type 18 Modality ::= MUST | MUSTNOT | MAY | ALWAYS 19 Type , Var , Attribute , Id , agent , Constant , Purpose ::= literal Listing 1.1: AAL Syntax

  EXISTS p : Patient EXISTS d : Data ( d . subject = p ) THEN ( MAY p . read ( d ) OR MAY p . write ( d ) OR MAY p . delete ( d )) AUDITING DPA . audit [ hospital ]() I F _ V I O L A T E D _ T H E N MUST DPA . sanction [ hospital ](...)Clause 2: The data subject's informed consent. Data subjects must consent to the processing of their personal data, before any personal data is collected about AccesRightInterface which defines read, write and delete functionalities.

Fig. 1 :

 1 Fig. 1: Component diagram for the health care use case.

  EXISTS p : Patient EXISTS d : Data (( p = d . subject ) THEN MAY p . sensor [ X ]( d ) ONLYWHEN d . subject . ex pl ic i tC on s en t [ hospital ]( " true " )) AND ( MAY p . e xp li ci t Co ns e nt [ hospital ]( b : Boolean ) ONLYWHEN hospital . sendPolicy [ p ]( " processing policy and purpose " )) AUDITING DPA . audit [ hospital ]() I F _ V I O L A T E D _ T H E N MUST DPA . sanction [ hospital ](...)

  EXISTS p : Patient EXISTS d : Data ( MUST hospital . violation ( d ) AND ( p = d . subject )) THEN MUST hospital . notify [ p ]( " data breach " )

www.a4cloud.eu

As stated in Section 2, prevention, detection, judgment, evidence and punishment are the five steps of accountable system.

Due to space limitations, we do not detail it in this paper.

Actions are prefixed by modalities : MUST for obligation, MUSTNOT for prohibition and MAY for permission.

This work has been partly funded from the European Commissions 7th Framework Programme (FP7/2007-2013) under grant agreement no: 317550 (A4CLOUD).


Pramod S Pawar
email: pramod.s.pawar@bt.com

Muttukrishnan Rajarajan
email: r.muttukrishnan@city.ac.uk

Theo Dimitrakos
email: theo.dimitrakos@bt.com

Andrea Zisman
email: andrea.zisman@open.ac.uk

Trust Assessment Using Cloud Broker

Keywords: cloud trust, cloud broker, multi-cloud, reputation

de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Despite the advantages and rapid growth of cloud computing, most organizations still continue with their concerns about trust and security of cloud providers. Several challenges [START_REF] Habib | Cloud Computing Landscape and Research Challenges Regarding Trust and Reputation[END_REF] such as specification of SLAs, standards, security measures, selection of service providers and computation of trust still persists, implying that the cloud environments are still not sufficiently trustworthy from customer's perspective. To deal with the challenge of identifying dependable cloud service providers for the service, cloud marketplaces are gaining popularity and allow consumers to select providers that best match their requirements. However, their complex requirements and the numerous choices available to the consumer make it difficult to decide on a provider to host their service. In addition, their concern about the trustworthiness of the providers remains unanswered. The cloud characteristics [START_REF] Mell | The NIST Definition of Cloud Computing[END_REF] such as elasticity and the complex deployment models like multi-cloud and federated clouds create major challenges in trust assessment of cloud providers. A unanimous trust assessment across all deployment architecture may not be suitable, this creates a compelling requirement to have a suitable separate trust assessment for every deployment architecture.

The assessment of the cloud computing environment leads to crucial requirements which are essential to evaluate the cloud provider's trustworthiness and they are: a) An independent mediation layer capable of performing variety of trust assessment to evaluate the cloud providers b) An evaluation framework that is trusted enough such that malicious providers cannot manipulate the evaluation process c) An evaluation of cloud providers based on fine-grained QoS parameters together with consumer feedbacks, recommendations and additional distinguishing parameters that relate to the cloud computing environments [START_REF] Habib | Cloud Computing Landscape and Research Challenges Regarding Trust and Reputation[END_REF]. Due to the complexity of service requirements and difficulty of trustworthiness evaluation of the cloud providers, third parties like cloud brokers can play an important role to assist the consumer in selecting an appropriate provider and also assist in deployment of the service.

The work presented in this paper was developed under the FP7 EU-funded project called OPTIMIS [START_REF] Ferrer | OPTIMIS: A holistic approach to cloud service provisioning[END_REF]. This paper, proposes the trust evaluation of the cloud providers with the use of OPTIMIS Cloud Broker (CBR) as a mediation layer. As a first step towards integration of trust and reputation systems in cloud environment, a set of parameters beyond QoS are identified that includes: SLA, Compliance, interoperability, geographical location of data centers, deployment models, security measures, user recommendations and feedbacks [START_REF] Habib | Cloud Computing Landscape and Research Challenges Regarding Trust and Reputation[END_REF]. The trust model [START_REF] Pawar | Trust Model for Optimized Cloud Services[END_REF], [START_REF] Pawar | Opinion Model Based Security Reputation Enabling Cloud Broker Architecture[END_REF] cohesively works with the cloud broker in different modes using SLA and cloud characteristic parameters for evaluating the trustworthiness of the providers, and is robust against malicious group of entities performing reputation based attacks. The OPTIMIS cloud broker supports SLA, compliance with data protection and locations, multi-cloud and federated cloud deployments, security as value additions and integrates trust model enabled with SLA monitoring and user ratings in terms of feedback for the service used.

The remaining paper is structured as follows. Section 2 describes the different modes of operation of cloud broker. Section 3 describes type of trust in each of the cloud broker modes. Section 4 provides trust evaluation using cloud broker. Section 5 provides the related work and finally, section 6 provides the concluding remarks.

2

Cloud Broker Service This paper considers the OPTIMIS Cloud Broker (CBR) [START_REF] Ferrer | OPTIMIS: A holistic approach to cloud service provisioning[END_REF] for assessing trust of the Infrastructure Providers(IP). The OPTIMIS Cloud Broker (CBR) as shown in Fig. 1 has architecture that enables multi-cloud deployment, provisions value added service for the consumer's service deployed via cloud broker and also performs Trust, Risk, Eco-efficiency and Cost (TREC) assessment. Details of the components and the multi-cloud deployment process is available from the OPTIMIS toolkit website [START_REF]OPTIMIS Toolkit | Home -Cloud, but better[END_REF].

Cloud broker modes of operation

The OPTIMIS cloud broker has the capability to operate in four different modes: a) cloud service recommendation b) cloud service intermediation c) cloud service aggregation and d) cloud service arbitrage. Cloud broker used in cloud service recommendation mode enables the user to get recommendations from the cloud broker about the most suitable cloud infrastructure provider for hosting their service, based on the degree of Trust, Risk, Eco-efficiency and Cost (TREC). The cloud broker as a recommender reduces the effort from the consumer to identify a suitable cloud service provider for its service. However the actual deployment of the service to the cloud infrastructure is performed by the consumer after obtaining deployment solution from the cloud broker. Cloud broker used as cloud service intermediation provides management functionalities like Value Added Services (VAS) that are cloud provider specific, which may be essential for the consumer's service that is deployed in the cloud provider environment. As an intermediary, the cloud broker also takes complete responsibility of the consumer's/user's services to identify the most suitable IP based on TREC, then performs the deployment on the selected IP, and then manages smooth functioning of the service during its operational stage. The use of cloud broker as cloud service aggregation provides management functionalities for multi-cloud deployment and operation of a service by combining services from multiple cloud infrastructure providers. The cloud broker also provides VASs that are independent of cloud providers. Cloud broker used as cloud service arbitrage can be considered as dynamic aggregation wherein the multi-cloud deployment of consumer service is dynamically decided based on the service requirements. In this mode of operation, the cloud broker system decomposes the service requirements at component level and negotiates with multiple cloud providers for each of the service components to formulate an optimized deployment solution taking into account the basic service requirements as well as additional requirements such as TREC, compliance and security.

Trust Assessment using Cloud Broker

This section describes the trust assessments performed using the different modes of cloud broker. Table 1 summarizes the feature provided by cloud broker in different modes of operation. Analysis of the summary information reveals that cloud broker in cloud service recommendation mode is only responsible to provide the deployment solution which determines that a standard trust model with cloud specific characteristics is sufficient for trust assessment of the cloud providers. Cloud broker as cloud service intermediation additionally provides value added services like security service and as for a comprehensive trust assessment it is essential to evaluate security reputation of the cloud provider. The cloud broker as cloud service aggregation/arbitration additionally provides support for multi-cloud deployment that compels the requirement of trust assessment for a group of cloud providers.

Deployment Solution Deployment of Service Provider specific VAS Provider Independent VAS Static Multi- cloud deployment Dynamic multi- cloud Recommender X Intermediary X X X Aggregator X X X X X Arbitrage X X X X X X
Table 1. Features for cloud broker used in different modes

Cloud broker as cloud service recommendation

In this mode of operation the consumer interacts with cloud broker only for getting the deployment solution to identify the trustworhty cloud providers and takes the responsibility of deployment. In this mode the cloud broker uses the trust model as proposed in Pawar et al. [START_REF] Pawar | Trust Model for Optimized Cloud Services[END_REF], [START_REF] Pawar | Trust Model for Cloud Based on Cloud Characteristics[END_REF]. The Trustworthiness of an cloud Infrastructure Provider (IP) is modelled using opinion obtained from three different computations, namely (i) compliance of SLA parameters (SLA monitoring), (ii) service provider satisfaction ratings (SP ratings), and (iii) service provider behaviour (SP behaviour). The SP behaviour is defined in terms of the credibility [16] for each of the SP based on the feedback provided. In addition to the credibility, the trust model is complimented with early filtering to reduce the impact of malicious feedback providers [START_REF] Pawar | Trust Model for Cloud Based on Cloud Characteristics[END_REF]. The cloud broker uses this trust model to provide recommendations about the cloud providers. The trustworthiness (T) of an IP is modelled as below: T=Expectation (W (SPB SPR )Ʌ SLA )

(1)

W (SPB SPR ) ɅSLA =(W SPB W SPR ) Ʌ W SLA ( 2
)
where W SLA, W SPR , W SPB are opinions obtained from the SLA monitoring (SLA), SP ratings (SPR), and SP behavior (SPB) values, respectively. The symbol Ʌ is the conjunction operator used to combine the opinions, and is the discounting operator used as the recommendation operator.

Cloud broker as cloud service intermediation

The cloud broker in the intermediary mode of operation, have capabilities to provision value added services such as security services. In this mode, the cloud broker inherits and expands on the role of security auditor, enabling the cloud broker to obtain access to security events due to the high value of trust placed, which may not be possible with the wider community. The cloud broker provisions the consumers with security reputation of cloud IP based on their security requirements. The reputation of a cloud IP [START_REF] Pawar | Opinion Model Based Security Reputation Enabling Cloud Broker Architecture[END_REF] is calculated in terms of its trustworthiness(T) using opinion obtained from computations, namely i) Incidence Monitoring(M): Security incedence events received from monitoring ii) Enterprise User Rating(EUR): Ratings provided by the enterprise user for satisfaction of the security features provided by cloud service providers. The trustworthiness (T) of cloud IP is given as:

T = Expectation (W M Ʌ W EUR ) = Expectation (W M Ʌ EUR ) (3)
Where W M Ʌ EUR = (b M Ʌ EUR , d M Ʌ EUR , u M Ʌ EUR , a M Ʌ EUR ).

Cloud broker as cloud service aggregation/arbitration

The cloud broker used as cloud service aggregation/arbitration is capable of devising multi-cloud deployment solution based on user requirements. This enables the cloud broker to perform trust assessment for a group of providers. Consider that the deployment solution provided contains two target cloud providers. Let T 1 and T 2 be the trust computed for the first and the second cloud provider. The individual trustworthiness T 1 and T 2 , of the cloud provider are computed based on the parameters, SLA monitoring, SP rating and SP behavior, as described in Section 3.1. The global trust or the group trust for the cloud provider computed by the broker is as follows:

T 12 = (W 1 /(W 1 + W 2 )) T 1 + (W 2 /(W 1 + W 2 )) T 2 (4)
Where W1 and W 2 are weights assigned for trust computed for each of the cloud providers such that W1 + W 2 = 1.

Evaluation

This section evaluates the trust assessment performed using cloud broker as a cloud service recommendation. The Trust model is evaluated using a simulation with a typical simulation run of 250 iterations, a total of 100 SP nodes and one cloud broker node trying to evaluate a single IP. This paper uses categorized groups of malicious feedback provider and two metrics as considered as in [START_REF] Jia | A Trust and Reputation Model Considering Overall Peer Consulting Distribution[END_REF]. The malicious groups are: complementary, exaggerated positive and exaggerated negative. The SP nodes are tagged with one of the four categories: normal group (G1), exaggerated positive group (G2), exaggerated negative group (G3) and complementary group (G4). The experiments use different ratios G1:G2:G3:G4 of SP nodes. The remaining section is as follows: Section 4.1 demonstrates the trust model robustness due to credibility use in trust model. Section 4.2 demonstrates sensitivity of the model to uncertainty.

Average credibility decreases with time

The purpose of the credibility parameter is to ensure that the feedback provided by malicious nodes be weighted less to reduce the influence of malicious nodes and thus to correctly model the reputation of the trustee. In this experiment, the ratio of nodes G1:G2:G3:G4 is given as 70:10:10:10. After the cloud broker node performing transaction with the IP, it computes difference between the feedback provided and the real QoS provided by the IP. This enables cloud broker to compute the current credibility of feedback providers i.e. SPs. In each iteration, credibility of SPs are updated con-sidering its previous credibility and then the average credibility is computed for each group G1, G2, G3 and G4. The result in Fig. 2 shows that the average credibility for the malicious node groups G2, G3 and G4 decreases drastically within a few iterations and then remains low throughout rest of the iterations. This result indicates that malicious node achieve low credibility with time and that the feedbacks provided by the malicious nodes will have a low influence on the reputation computation since the feedbacks provided by these malicious nodes are weighted less. provider has any impact on robustness of the model. For this experiment, keeping the reliability trust provided by feedback provider constant, it is executed for two cases of uncertainty for the feedback provided. In the first case a high uncertainty is maintained as u=0.11, while for the second case the uncertainty is reduced to 0.01. In both cases the malicious nodes ratio of 70:30:0:0 is considered for the experiment. It is observed from Fig. 3 that the trust model is sensitive to uncertainty in the feedback value provided. Smaller the uncertainty, the corresponding diff value would be small. This result validates that with increase in evidence available, uncertainty in the feedback value reduces and the system robustness increases.

Related Work

Trust and reputation have been the focus of research for several open systems and the rapidly growing cloud computing technology also appreciates the importance of trust in the cloud computing environment. This is partially observed through the trust and reputation systems that have being discussed in [START_REF] Ferrer | OPTIMIS: A holistic approach to cloud service provisioning[END_REF], [START_REF] Pawar | Trust Model for Optimized Cloud Services[END_REF], [START_REF] Pawar | Trust Model for Cloud Based on Cloud Characteristics[END_REF], [START_REF] Alhamad | SLA-Based Trust Model for Cloud Computing[END_REF]. In OPTIMIS [START_REF] Ferrer | OPTIMIS: A holistic approach to cloud service provisioning[END_REF], trust is one of the core component used by SP, along with risk, eco-efficiency and cost for evaluating the IP for their service. Alhamad et al. [START_REF] Alhamad | SLA-Based Trust Model for Cloud Computing[END_REF] proposes a trust model for cloud computing based on the usage of SLA information and provides a high level architecture capturing major functionalities required. Pawar et al. [4][7] include SLA compliance information to model trust and also proposed a trust model based on cloud characteristics supported with credibility and early filtering mechanism to reduce the impact of malicious feedback providers. Significant research exists in the area of brokers used in various areas of computer science. Cloud brokers [START_REF] Habib | Cloud Computing Landscape and Research Challenges Regarding Trust and Reputation[END_REF], [START_REF] Nair | Towards Secure Cloud Bursting, Brokerage and Aggregation[END_REF] are also gaining popularity to identify dependable cloud service providers. The importance of cloud brokerage is also emphasized by Gartner research [START_REF] Gartner | Cloud Services Brokerage: The Dawn of the Next Intermediation Age[END_REF], which defines different types of brokerage. In line with Gartner research [START_REF] Gartner | Cloud Services Brokerage: The Dawn of the Next Intermediation Age[END_REF], Nair et al. [START_REF] Nair | Towards Secure Cloud Bursting, Brokerage and Aggregation[END_REF] propose the use of cloud broker as 1) cloud service intermediation 2) cloud service aggregation and 3) cloud service arbitrage and provide an abstract architecture for the brokerage. The OPTIMIS cloud broker architecture, is in line with the concepts defined in [START_REF] Nair | Towards Secure Cloud Bursting, Brokerage and Aggregation[END_REF] and [START_REF] Gartner | Cloud Services Brokerage: The Dawn of the Next Intermediation Age[END_REF]. In addition, it supports trust assessment, matching of consumer requirements, establishing agreements and also provides value added services such as security.

Conclusion and Final Remark

This paper communicates that a unanimous trust assessment across the cloud computing environment may not be suitable and exploits the use of OPTIMIS cloud broker and its various modes to perform variety of trust evaluations of the cloud providers. This paper uses the opinion based trust model to perform trust assessment of cloud providers to provide recommendations, security reputation and a group reputation in the different modes of cloud broker. The paper provides evaluation results for the trust assessment performed by the cloud broker in the recommendation mode and reserves the evaluation of the security reputation and group reputation as future work.

Fig. 1 .

 1 Fig. 1. High level component architecture of the Cloud Broker

Fig. 2 .Fig. 3 .

 23 Fig. 2. : Average Credibility for different groups of SPs. G1:G2:G3:G4 is 70:10:10:10

Acknowledgement

This work has been partially supported by the EU within the 7th Framework Programme under contract ICT-257115 -Optimized Infrastructure Services (OPTIMIS).