Context-Aware Multifaceted Trust Framework For Evaluating Trustworthiness of Cloud Providers

Accepted Manuscript Context-Aware Multifaceted Trust Framework For evaluating trustworthiness of cloud providers Mohannad Alhanahnah, Peter Bertok, Zahir Tari, Sahel Alouneh

PII: DOI: Reference:

S0167-739X(17)30071-7 https://doi.org/10.1016/j.future.2017.09.071 FUTURE 3727

To appear in:

Future Generation Computer Systems

Received date : 13 March 2017 Revised date : 26 August 2017 Accepted date : 27 September 2017 Please cite this article as: M. Alhanahnah, P. Bertok, Z. Tari, S. Alouneh, Context-Aware Multifaceted Trust Framework For evaluating trustworthiness of cloud providers, Future Generation Computer Systems (2017), https://doi.org/10.1016/j.future.2017.09.071 This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and review of the resulting proof before it is published in its final form. Please note that during the production process errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.

Context-Aware Multifaceted Trust Framework For Evaluating Trustworthiness Of Cloud Providers Mohannad Alhanahnaha,∗, Peter Bertokb , Zahir Tarib , Sahel Alounehc a unaffiliated of Science, RMIT University c School of Electrical Engineering and Information Technology, German Jordanian University b School

Abstract With the rapidly increasing number of cloud-based services, selecting a service provider is becoming more and more difficult. Among the many factors to be considered, trust in a given service and in a service provider is often critical. Appraisal of trust is a complex process, information about the offered service’s quality needs to be collected from a number of sources, while user requirements may place different emphasis on the various quality indicators. Several frameworks have been proposed to facilitate service provider selection, however, only very few of them are built on existing cloud standards, and adaptability to different contexts is still a challenge. This paper proposes a new trust framework, called Context-Aware Multifaceted Trust Framework (CAMFT), to assist in evaluating trust in cloud service providers. CAMTF is flexible and context aware: it considers trust factors, users and services. When making recommendations, CAMFT employs a combination of mathematical methods that depend on the type of trust factors, and it takes both service characteristics and user perspective into account. A case study is also presented to demonstrate CAMFT’s applicability to practical cases. Keywords: Analytic Hierarchy Process, Cloud Computing, Trust, Fuzzy Simple Additive Weighting, Multifaceted

1. Introduction In recent years, we have witnessed the rapid growth of cloud computing. Among its major benefits are the ease of provisioning and management of computing resources, and reduction of running costs. At the same time, cloud computing faces several challenges, including the related issues of security, privacy and trust [1, 2, 3, 4, 5]. In particular, building trust between users and service providers in the cloud is a major challenge. Customers have little control over the way their data is stored and handled at the Cloud Service Providers’ (CSPs) premises, hence, they need guarantees that the data will be managed securely and reliably. This is related to trust and is based on a number of factors, some of which are expressed explicitly e.g. in service level agreements (SLAs), while others are implicit or based on user perceptions. Selecting an appropriate CSP for a particular task is a complex process, and several frameworks have been proposed to help it. Those frameworks usually consider trust from a single perspective, e.g security [6, 7]; only few of them have a broader view and include multiple aspects, such as competence, reputation and potential risk [8], or privacy, availability and response time [9]. As different users may have different requirements, some frameworks allow the inclusion of new, additional factors and parameters [9, 7]. However, some aspects still present a challenge, notably the adaptation to different application contexts [8] or the catering for the cloud’s dynamic nature [2]. ∗ Corresponding

author Email addresses: [email protected] (Mohannad Alhanahnah), [email protected] (Peter Bertok), [email protected] (Zahir Tari), [email protected] (Sahel Alouneh)

Preprint submitted to Elsevier

October 10, 2017

Unfortunately most frameworks do not rely on cloud standards,like standards proposed by IEEE1 , NIST2 or the International Telecommunication Union (ITU)3 , which makes it difficult to interface them with other systems. Trust in general has been discussed in many contexts, and the focus in this paper is on cloud services and its specific issues. This paper examines how trust is built between CSPs and users, what factors influence its establishment and how it is evaluated. We propose a new framework, called Context-Aware Multifaceted Trust Framework (CAMTF), that offers a systematic approach to evaluating the trustworthiness of Cloud Service Providers (CSPs). CMATF was designed with important basic principles in mind. Namely, it (i) takes existing standards into account (ii) evaluates trustworthiness from different aspects (iii) allows consumers to express their preferences towards certain trust factors (iv) has the ability to involve additional trust factors and (v) can be adapted to different application contexts. CAMTF uses information from Service Level Agreements (SLAs) and from evaluations by experts and by customers to rank CSPs. To provide flexibility, users can tailor the weightings and evaluation methods to their application contexts’ specific requirements. The proposed modular approach is context aware and relies on existing standards, thereby overcomes the major limitations of existing frameworks and builds upon their strengths. In summary, our contribution is an abstract framework that takes the users’ perception of trust into account and assists cloud consumers in selecting the Cloud Service Provider that best suits the requirements. The framework addresses trust establishment between cloud consumers and cloud providers, while overcoming the limitations of earlier solutions by using multifaceted criteria, by being context aware and by including the consumer’s perspective of trust [1]. It enables future extension by considering additional evaluation aspects, is adaptable to different contexts, and considers multiple subjective and objective aspects for evaluating the trustworthiness of cloud providers This paper gives a detailed description of the framework, and is organized as follows. Section 2 highlights concepts and existing works we relied on for devising CAMTF. Section 3 introduces CAMTF, describes its architecture and discusses its components. The workflow of CAMTF is explained in Section 4. The mathematical approach used in CAMTF for computing trust is described in Section 5. Using a running example, Section 6 shows how CAMTF can be utilized for computing trust. Section 7 discusses the distinctive features of CAMTF and compares it to related work. Finally, Section 8 concludes this paper. 2. Background A wide range of cloud services are available; some of them offer basic or non-essential services, while others are used for important or even mission-critical tasks. Trust is critical in all scenarios, that is, users expect the service to be delivered at the required level. A number of factors may need to be considered, such as the importance of the service to the user, the nature of data, or intellectual property constraints, among others. Each aspect comprises various factors and the weightings of those factors. Due to the complexity of the task, no general recipe for the CSP selection process can be given, however, equipping the user with systems or frameworks that facilitate it is still possible. The main purpose of trust evaluation is to reduce ’regret’ after a decision, i.e. the discrepancy between the action taken and the action that should have been taken in hindsight. Trust evaluation frameworks aim at reducing future regret by assisting consumers in selecting the most trustworthy cloud service provider. To be effective, frameworks need to obtain a wide range of data, and the decisions have to be based on a thorough analysis of the data. CAMTF was inspired by the work presented in [10, 1]: the authors made the case for comprehensive evaluation of trust, 1 http://grouper.ieee.org/groups/2302/ 2 http://www.itu.int/en/ITU-T/focusgroups/cloud/Documents/FG-coud-technical-report.zip 3 http://www.nist.gov/customcf/get

pdf.cfm?pub id=909024

2

identified essential issues that need to be taken into account by trust frameworks evaluating the trustworthiness of cloud providers, analyzed existing trust frameworks and indicated the main challenges. To enable proper evaluation, proper description of trust is needed. A general trust perception model (GTPM) was described in [10], categorizing trust factors as user-related or website-related. To assist evaluation, a number of trust evaluation frameworks have been proposed [11, 12, 13]. However, frameworks that assist in trust evaluation often consider a single aspect only, such as quality of service (QoS) [12], only very few include more than one criterion for trustworthiness [8]. At the same time some frameworks are extensible, i.e. can accommodate new trust factors or even new computation algorithms [8, 14, 9]. Application context plays an important role in assessing trustworthiness; for example trust needs to be evaluated differently for storing pictures for general viewing and for storing confidential documents. The majority of existing solutions focus on a specific context or application [14, 9, 12], and this resulted in the repetition of previous achievements albeit in different contexts. This is in spite of the fact that the users’ perception of trust is often considered, emphasized and reflected in the trust decision or evaluation. Guidelines for developing trust frameworks were presented in [1]. The concept of trust phases (Establishing Trust and Maintaining Trust) was introduced, and requirements for each phase were discussed with more focus on the trust establishment phase. Key criteria that should be maintained by any trust framework were also introduced, and a taxonomy of trust factors was presented. Figure 1 depicts a trust factor taxonomy that classifies trust factors into the aforementioned two categories: Service Level Agreement Trust Factors (SLA-TFs) and Non-SLA-TFs. Information extracted from service level agreements between the CSP and customers relate to four main areas: Security, Performance, Data Management and Personal Data Protection, and can encompass additional subfactors. Non-SLA Trust Factors were identified based on an SLA standardization initiative [15]. This model is further discussed in the next section. 3. CAMTF Architecture The general architecture of the proposed framework is shown in Figure 2. The actors that interact with CAMTF and their roles are as follows. • Cloud Service Customer (CSC), or consumer defines the requirements for evaluating the trust in Cloud Service Providers; • Cloud Service Providers (CSP) publish Service Level Agreements (SLAs); • Other Cloud Service Customers provide feedback on their interaction with Cloud Providers; and • Experts provide opinions about Cloud Providers (e.g. own evaluation, review). CAMTF relies on two types of information sources: (i) what CSPs agree to provide (i.e. Service-Level Agreements Figure 1: Taxonomy of Trust Factors - SLAs) and (ii) how other CSCs rate the CSPs under consideration (e.g. feedback, opinions). Accordingly, we work with (i) SLA trust factors (e.g. performance, security) and (ii) non-SLA trust factors (e.g. reputation). Consumers can set the importance of trust factors and correlate them with the context of their applications, which makes CAMTF flexible and context aware. 3

CAMTF performs its operations in two phases: preparation and evaluation. During the preparation phase, a customer defines the application context, and CAMTF builds a context that reflects the customer’s requirements, e.g. speed, available storage, up-time (mean-time-between-failures - MTBF), and the importance of each requirement. Next, CAMTF creates a knowledge base by collecting evidence from SLAs and from feedback by other customers. The result of this phase is a set of Cloud Service Provider (CSP) profiles for the given context, and each profile is an aggregation of all the evidences directly extracted/inferred from the SLA and non-SLA sources. At the beginning of the evaluation phase, a customer can customize the setup by adjusting weights of trust factors, to adapt to the actual data. Then the actual evaluation is performed and the results, i.e. the trust scores are presented for all CSPs in the specific application context, sorted from the highest score to the lowest one. The following subsections present a detailed description of CAMTF’s components and the operations being performed by each component. 3.1. Context Manager Different aspects are important for different applications, and the choice of trust factors and their evaluation need to reflect this. Customers can decide the relative importance of individual trust factors, and can tailor trust assessment to the context of their applications. For instance, some users may consider security and data management more important than performance, or they might choose not to include non-SLA Trust Factors in the evaluation. We consider a context as a combination of trust factors that are speCSC: Cloud Service Customer Legend: CSP: Cloud Service Provider cific to a certain category of applications (e.g. mobile, eHealth); it is Figure 2: CAMTF Architecture in fact a subset of the trust factors depicted in Figure 1. A context can be described in broad terms, e.g. the user is concerned about performance in general, or refer to fine-grained aspects, e.g. the user is concerned about particular service level objects P1-SLO-01 and P5-SLO-03, as shown in Figure 3. Service level objects represent technical aspects of the SLA, and they can be measured using either quantitative or qualitative approaches; proposals have already been put forward for identifying, measuring and monitoring SLOs [15]. Context awareness is an important feature of CAMTF. A dedicated CAMTF component, the Context Manager, handles the configuration and customization of the context, its user interface enables customers define the context of their applications. 3.2. Trust Evidence Extractor Once the context has been created, the Trust Evidence Extractor (TEE) starts the process of searching for trust information from different sources based on the trust factors identified in the context. Each of these sources is handled by a specific extractor. Briefly, an extractor receives as input the context defined by the Cloud Service Customer (i.e. the set of relevant trust factors) and executes a specific search algorithm seeking evidences from a certain source. TEE then aggregates the results of the extractors and creates a Cloud Service Provider profile.

4

Figure 3: Trust Factors tree

We defined three different extractors that collect trust evidence from the following sources: SLA, expert opinions and feedback from other customers that used the Cloud Service Provider earlier. CAMTF also provides extension points for other extractors to be easily plugged in. The SLA extractor outputs a structure that contains all found evidences that match the cloud customer requirements for the identified context. This reduces information distortion on one hand, while still enables accurate handling of data on the other. Every non-SLA extractor produces a score that is computed based on expert opinions or on feedback from other cloud customers, effectively converting possibly vague information to well-defined values. • SLA Extractor. SLAs do not have a standard format. This makes parsing and extracting evidence for specific trust factors difficult. The SLA Extractor automates the process of parsing plain text SLAs, and extracts evidence for the trust factors in the specified context. The evidence is then stored in a tree-like structure, called TF Tree, similar to the one shown in Figure 3. In this structure, the service level objects (i.e. the leaf nodes) store the information extracted from the SLA in plain text form without any processing, if information exists for the selected trust factors. The intermediate layers (i.e. Level 1 and Level 2) aggregate the evidence stored in their child nodes. Several interesting search algorithms for extracting evidence from SLAs have been proposed in the literature e.g. [16, 17], and they properly address the issue. Therefore this will not be further discussed here. • Non-SLA Extractors. Non-SLA extractors collect and process trust information from different non-SLA sources. We used two non-SLA extractors: Feedback Extractor and Opinion Extractor, but other extractors can also be used. In this work we assume that input has been collected in advance. For instance, crawlers can gather feedback, expert reviews and other data from different sites and reports, or questionnaires can be used to obtain data. 3.3. Preference Manager This manager enables a consumer to express requirements and preferences, including defining Service Level Object (SLO) values and weights. For instance, seeking high level of security can be reflected in large values of the weights associated with Service Level Objects located under security. In other words, the Preference Manager enables the framework to consider the consumer’s perception of trust. It builds a Preference Trust Factors Tree based on the Trust Factors Tree shown in Figure 3, and forwards this tree to the trust evaluator for processing. To reduce burden on consumers, the weights assigned to individual trust categories on level 1 in the Trust Factors Tree are propagated down for SLA trust factors. However, individual weights can also be explicitly assigned, if required. Customers can express their preferences in different ways, according to their knowledge, skills, abilities and needs. Experts can specify the values and 5

Legend:

CSC: Cloud Service Customer

CSP: Cloud Service Provider

Figure 4: CAMTF sequence diagram

weights of all Trust Factors and their SLOs. Customers with limited understanding or with specific needs can opt for specifying certain values and weights, and rely on the preference collector for assigning values to the missing inputs. There is a choice of default values, they can be the best value, maximum value, minimum value, a value correlated with the context or a value linked to a weight specified by the cloud customer. 3.4. Trust Evaluator This component’s main input comes from providers’ profiles that are evaluated for the specific context defined by the customer. These profiles contain trust evidence aggregated from SLA and non-SLA sources. Trust evaluation also uses the Preference Trust Factors Tree provided by the Preference Manager. It utilises the multi-criteria decision analysis technique Analytic Hierarchy Process (AHP) [18] that enables customers to define their preferences and be involved in the evaluation process. With the help of AHP, the Trust Evaluator supports a diverse range of trust indicators. 4. CAMTF Operation The previous section described the functions of CAMTF’s components as well as briefly indicated the interactions between these components. This section focuses on the operation flow of CAMTF, and explains it in more detail. The communicaton between CAMTF’s components and the sequence of steps are shown in Figure 4. The process starts with the customer defining the context and requirements. The customer also sets the preferences by specifying the values and weights of the trust factors. The Context Manager forwards the context definition to the TEE (Trust Evidence Extractor) and the Preference Manager sends the preference definition to the Trust Evaluator. A customer assigns the relative importance of SLA Trust Factors using linguistic ratings that are then converted into numerical scores. In the calculations, AHP even allows the use of scales such as (1-9) [18]; but to keep it simple and user friendly, we used the three-level rating (i.e. HI for Highly-Important, MI for Medium-Important and LI for Lowly-Important) and set their corresponding numerical scores to 1, 0.5 and 0 respectively. After weights have been given by the customer, the Preference Manager performs the following steps for preparing the Preference Trust Factors tree. 6

• Checking that each leaf node has a value and a weight. If the value is not defined, a default value will be assigned. If the weight has not been specified, the Preference Manager assumes all sibling leaf nodes are equally important. • Computing the weights at upper levels. In case the customer does not explicitly specify the weights, the Preference Manager computes the weight of a parent based on the average weight of its child nodes. • Normalizing the weights of child nodes that belong to the same parent. This means that the accumulated weight of child nodes is equal to one. This step is performed starting from leaf level up to the root level. The AHP method is used for normalizing the weights. The Trust Evidence Extractor utilizes the different extractors for collecting trusted evidences according to the context, and produces the profile of each Cloud Provider. The profiles are forwarded by the Cloud Provider Profile Manager to the Trust Evaluator, which received the preference definitions in advance. Finally, the Trust Evaluator computes the trustworthiness of each Cloud Provider, and presents it to the consumer. 5. CAMTF Methodology for Evaluating Trust This section describes our methodology for computing and evaluating trust in detail. The two types of trust factors have different characteristics: SLA factors tend to be objective while nonSLA factors tend to be subjective. To accommodate this difference, we use different mathematical approaches to evaluate them. AHP is used for computing SLA trust factors and for combining the computed inputs of the SLA and non-SLA trust factors in order to produce the overall trust value. For computing non-SLA trust factors, Fuzzy Simple Additive Weighting (FSAW) is used [19]. FSAW was also proposed in the literature for assisting in cloud service selection [9]. We have chosen this approach to compute non-SLA inputs as fuzzy logic is a convenient and expandable method for incorporating subjective inputs and FSAW helps in aggregating them in a simple way. Moreover, expandability allows the inclusion of additional inputs. 5.1. Evaluating Non-SLA Trust Factors When rating trust factors based on customer and exTable 1: Linguistic variables and Fuzzy Values [19] pert perception, we used finer Linguistic variables Fuzzy Value grain than with the weightVery poor (VP) (0,0,0,20) ings, as this gives a better picBetween very poor and poor (B. VP & P) (0,0,20,40) ture [20]. The scale here was Poor (P) (0,20,20,40) 1-9, as shown in Table 1, unBetween poor and fair (B. P & F) (0,20,50,70) der Linguistic variables. We decided that the trust facFair (F) (30,50,50,70) tors considered for evaluation Between fair and good (B. F & G) (30,50,80,100) are high-level Trust Factors Good (G) (60,80,80,100) (Level 1 Trust Factors in FigBetween good and very good (B. G & VG) (60,80,100,100) ure 3). The alternative was Very good (VG) (80,100,100,100) to allow customers/experts to evaluate at the SLO level, but that would have required substantial effort for reviewing the cloud providers. (E.g. in our case study there were 66 Service Level Objects). The algorithm for rating providers based on customer feedback/expert opinions uses FSAW [19]. Below is a brief description of FSAW’s basic concepts (as defined in [20], [19]) and details of the proposed approach. e = (a, b, c, d) over R, with A generalized left right trapezoidal fuzzy number is a fuzzy set A a ≤ b ≤ c ≤ d, with its membership function defined as: 7

 lAe(x)    1 µAe(x) =  r e(x)    A 0

a≤x≤b  1 b≤x≤c where lAe(x) = x − a  c≤x≤d b−a otherwise

 1 and rAe(x) = x − d  a
c=d c
The membership function maps a given input x to a real number in the interval [0, 1]. The maximum of µAe(x) is obtained when x ∈ [b, c]: µAe(x) = 1. Constants b and c are chosen in such a way that they express the most probable value of the evaluation data. Constants a and d represent the lower and upper bounds for the evaluation data and reflect the fuzziness of the data. The input collected by the extractors is represented as follows. Customer feedback/expert opinion coming in the form of linguistic variables is converted to fuzzy numbers based on the conversion scale shown in Table 1. Generally, the rating provided by a customer/expert on a provider, with respect to the trust factors (i.e. S for Security, P for Privacy, DM for Data Management, and PDP for Personal Data Protection) is described in the following way. Se = (as , bs , cs , ds ) Pe = (ap , bp , cp , dp ) g = (adm , bdm , cdm , ddm ) DM ^ P DP = (apdp , bpdp , cpdp , dpdp ) Further, we denote the perception of a particular customer/expert j (j=1· · · m, m is the number of feedbacks/opinions) on a particular provider i (i=1· · · n and n is the number of providers) as shown below. Seij = (asij , bsij , csij , dsij ) Peij = (apij , bpij , cpij , dpij ) g ij = (adm , bdm , cdm , ddm ) DM ij

ij

ij

ij

pdp pdp pdp ^ P DP ij = (apdp ij , bij , cij , dij ) Next, we define the operations we perform on trapezoidal fuzzy numbers when rating providers. e = (a, b, c, d) and B e = (e, f, g, h) be two trapezoidal numbers and k a real number. We have Let A the following basic operations.

e⊕B e = (a + e, b + f, c + g, d + h), a ≥ 0, e ≥ 0 • Addition: A • Multiplication: e⊗B e = (ae, bf, cg, dh), a ≥ 0, e ≥ 0 A e = (ka, kb, kc, kd), a ≥ 0, k ≥ 0 k⊗A 1 e = ( a , b , c , d ), a ≥ 0, k > 0 ⊗A k k k k k

• Defuzzification - the operation of determining the total crisp number: e = d(A)

1 (a + b + c + d) 4

(1)

Let us now consider a scenario where n providers are evaluated. These providers are indexed by i (where i=1· · · n) and a provider has been reviewed by m customers/experts. Reviews assess a provider against all trust factors of the specified context (i.e S, P, DM, PDP), and are indexed by j (where j=1· · · m). The reviews (linguistic ratings) are converted to fuzzy numbers based on the conversion scale shown in Table 1. The aggregated fuzzy rating is defined as follows. 1 ⊗ (Sei1 ⊕ Sei1 ⊕ ... ⊕ Seim ) Sei = m 1 Pei = ⊗ (Pei1 ⊕ Pei1 ⊕ ... ⊕ Peim ) m g i = 1 ⊗ (DM g i1 ⊕ DM g i1 ⊕ ... ⊕ DM g im ) DM m 8

1 ^ ^ ^ ^ P DP i = ⊗ (P DP i1 ⊕ P DP i1 ⊕ ... ⊕ P DP im ), m Here Si , Pi , DMi and P DPi represent the aggregated feedback for a Cloud Provider from all reviewers with respect to trust factors S, P, DM and PDP. The output of the non-SLA extractors is the aggregated fuzzy rating. The non-SLA rating is computed based on the aggregated fuzzy ratings stored in customer profiles. The aggregated fuzzy ratings provide evaluation for S, P, DM, PDP. The customer’s preference (weights assigned to trust factors) can also be expressed at a lower level (e.g. SLO level shown in Figure 3), if the customer chooses a finer grain approach. In such cases, the weights need to be propagated in a bottom-up manner in the tree (i.e. Trust Factors Tree); we do this by recursively assigning the sum of the children’s weights to the respective parent nodes. As shown in Equation 2, the weight vector is created based on the four weights propagated to S, P, M, PDP on Level 1. The final non-SLA rating, named Fuzzy Rating (FR), is computed   by multiplying the aggregated fuzzy ratings with the weight vector ws e (see equation 3). In FR, fi denotes trapezoidal fuzzy numbers that  wp   W = (2) represent the final fuzzy ratings of CSPi . They can be defuzzified  wdm  (converted to numerical values, i.e. crisp values), by applying the wpdp formula in Eq. 1. 

  fe1 Se1 e  f2   e    F R =  fe3  =  S2   · · · · · · Sen ff n

Pe1 Pe2 ··· Pen

g1 DM g2 DM ··· gn DM

   g 1 ⊗ wdm ⊕ P ^ ^ P DP 1 Se1 ⊗ ws ⊕ Pe1 ⊗ wp ⊕ DM DP 1 ⊗ wpdp    g 2 ⊗ wdm ⊕ P ^ ^ P DP 2 ⊗W =  Se2 ⊗ ws ⊕ Pe2 ⊗ wp ⊕ DM DP 2 ⊗ wpdp       ···  ··· g n ⊗ wdm ⊕ P ^ ^ P DP n Sen ⊗ ws ⊕ Pen ⊗ wp ⊕ DM DP n ⊗ wpdp (3)

TEE combines the output of the non-SLA extractors with the outputs of the SLA extractor, and produces the profile of a provider in a specific context. 5.2. Evaluating SLA Trust Factors In the proposed framework, Analytic Hierarchy Process (AHP) has been employed for computing trust based on SLA trust factors, and for comparing providers. One of AHP’s main advantages in selecting the best available provider is that it supports the use of different types of trust indicators, such as boolean values, numeric values, or sets. T Fk Let vCSC be the value that represents the requirements of the Cloud Service Customer (CSC) w.r.t. a specific trust factor T Fk . For simplicity, we refer to this value henceforth as vc . T Fk Let vCSP (where i=1· · · n) be the values extracted from each of the n Cloud Providers’ SLAs i w.r.t. a specific trust factor T Fk . Hereafter, we refer to these values as vpi . Let DT Fk = {vc , vp1 , · · · , vpn } be the set of values provided by the Cloud Service Customer and Cloud Providers w.r.t. a specific trust factor T Fk . For simplicity, we refer to this set as D. We introduce the comparison operator, denoted as cT Fk : D × D → R, to assess values given by the providers against the customer’s requirements. The superscript T Fk indicates that the operator is defined for a specific trust factor T Fk . For simplicity, we refer to this operator as c. Based on the type of the operands, we define the comparison operator as follows. • Boolean. The comparison operator is defined in this case as: c(v1 , v2 ) =

(

1 0

if

v 1 = v2 Otherwise

∀v1 , v2 ∈ D

Example: ability to select data geolocation, availability of support. 9

(4)

• Numeric. The comparison operator is defined in this case as:   1   v1 c(v1 , v2 ) = v2  v    2 v1

if

v 1 = v2

if

v1 > v2

if

v1 < v2

∀v1 , v2 ∈ D

(5)

Example: uptime, mean time between failures. • Set. The comparison operator is defined in this case as:   |v1 ∩ vc | c(v1 , v2 ) = |v2 ∩ vc |  |v1 ∩ vc |

v2 ∩ vc 6= ∅

if

otherwise

∀v1 , v2 ∈ D,

(6)

Example: the set of supported authentication protocols. • Range. The comparison operator is defined in this case as:   len(v1 ∩ vc ) c(v1 , v2 ) = len(v2 ∩ vc )  len(v1 ∩ vc )

v2 ∩ vc 6= ∅

if

otherwise

∀v1 , v2 ∈ D,

(7)

where len(vi ) denotes the difference between the upper bound and the lower bound of range vi (len(vi ) = vib − via , ∀vi = (a, b), with a < b). Example: uptime represented as a range (e.g. uptime > 99.9%).

To determine which provider is best suited to the customer’s needs, we evaluate each CSP against all other CSPs and also against the CSC’s requirements. In the process we look at the CSPs separately for each trust factor. First, we compare a CSP’s value to every other CSP for that trust factor and sum it up in a comparison matrix. We also normalize the matrix values in order to get a fair comparison. Later, we combine the results of all CSPs and all trust factors into a relative ranking matrix. By applying the CSC defined weights to the relative ranking matrix, we arrive at the final ranking of CSPs. In this process, the following steps are executed in order. 1. Define the Comparison Matrix (CM), which uses a pairwise comparison between the values extracted from providers and the customer’s requirements. We note that the pairwise comparison is performed on values of a specific trust factor. We show below the simplified representation of CM. Each column in the matrix represents a particular CSP, while the last column shows the CSC requirements that have been identified through the preference manager(see Section 3.3)

CSP1 CSP2

CM =

··· CSPn CSC

     

CSP1

CSP2

c(vp1 , vp1 ) c(vp1 , vp2 ) c(vp2 , vp1 ) c(vp2 , vp2 ) ··· ··· c(vpn , vp1 ) c(vpn , vp2 ) c(vc , vp1 ) c(vc , vp2 )

···

··· ··· ··· ··· ···

CSPn

CSC

c(vp1 , vpn ) c(vp1 , vc ) c(vp2 , vpn ) c(vp2 , vc ) ··· ··· c(vpn , vpn ) c(vpn , vc ) c(vc , vpn ) c(vc , vc )

     

(8)

2. Compute the sum of the entries in each column of the Comparison Matrix (CM). sumj =

n+1 X

CMij

j = 1, 2, ..., n + 1

(9)

i=1

3. Create a new matrix CM 0 by dividing all entries in CM by sumj , where j is the column of the entry. 10

CSP1 CSP2 0

CM =

··· CP Sn CSC

            

CSP1

CSP2

c(vp1 , vp1 ) sum1 c(vp2 , vp1 ) sum1 ··· c(vpn , vp1 ) sum1 c(vc , vp1 ) sum1

c(vp1 , vp2 ) sum2 c(vp2 , vp2 ) sum2 ··· c(vpn , vp2 ) sum2 c(vc , vp2 ) sum2

···

··· ··· ··· ··· ···

CSPn

CSC

c(vp1 , vpn ) sumn c(vp2 , vpn ) sumn ··· c(vpn , vpn ) sumn c(vc , vpn ) sumn

c(vp1 , vc ) sumn+1 c(vp2 , vc ) sumn+1 ··· c(vpn , vc ) sumn+1 c(vc , vc ) sumn+1

            

(10)

4. Compute the average for each row in CM 0 . This value reflects the relative rating of the provider with reference to a specific trust factor.

avgi =

n+1 P j=1

0 CMij

i = 1, 2, ..., n + 1

n+1

(11)

5. Define the Priority Vector (PV), which shows the providers that satisfy the customer’s requirement for a particular Trust Factor. The average avgn+1 can be interpreted as the threshold imposed by the customer, where avgi > avgn+1 means that CSPi meets the requirements of the customer, ∀i∈{1,· · · ,n}.   avg1  avg2     PV =  (12)  ···   avgn  avgn+1 6. Create the relative ranking matrix (RR) by aggregating the Priority Vectors (PVs) computed for each trust factor.

CP S1 CSP 2

RR =

··· CSP n CSC

     

P VT F1

P VT F2

avg1T F1 avg2T F1 ··· avgnT F1 T F1 avgn+1

avg1T F2 avg2T F2 ··· avgnT F2 T F2 avgn+1

···

··· ··· ··· ··· ···

P VT Fm

avg1T Fm avg2T Fm ··· avgnT Fm T Fm avgn+1

     

7. Create a Normalised Weight (NW) vector based on the preferences of the cloud customer. In the Normalised Weight vector (shown in Equation 13) nwT F1 , nwT F2 , · · · , nwT Fm represent the weights of Trust Factors that belong to the same parent. We calculate the Normalised Weight by constructing a weight matrix (similarly to Comparison Matrix), and then performing equations 9, 10 and 11.   nwT F1  nwT F2   NW =  (13)  ···  nwT Fm

The SLA Rating (SR) is obtained through the multiplication of the ranking matrix (RR) by the Normalised Weight (NW), as described in Equation 14. RCSPi represents the final rating of CSPi , computed based on the evidence extracted from its SLA.

11



 RCSP1  RCSP2     SR = RR × N W =   ···  RCSPn  RCSC

(14)

6. Case Study To illustrate the practical applicability of the proposed method, this section presents a case study in the domain of eHealth. We use the Home-based Patient use case of the AU2EU project [21], in which Emergency Call Centers (cloud providers) provide health care and Ambient Assisted Living (AAL) services to Home-based Patients (cloud customer). At the core of this use case is the installation and maintenance of a home emergency call infrastructure, AAL system packages and the coordination of Health/Home Care Service Providers. Home-based Patients need to register for AAL services, and the process involves providing their personal and health-related information to the Emergency Call Center. The patients’ data contain various sensitive information (e.g. health status, medication, contact information of relatives, etc.), so it is crucial to evaluate the trustworthiness of different Home Emergency Call Centers before starting the registration process. (A) Defining the context and preferences. In this scenario, the customer evaluates providers based on the SLAs and feedback from other customers; it is the choice of the Cloud Service Customer not to rely on expert opinions. The requirements of the customer are aligned with the case study described in [22] by mapping those requirements to the standard trust factors used in CAMTF, as shown in Table 2. Table 2: Cloud Service Customer requirements and their mapping to trust factors from the Trust Factors Tree

Home-based Patient Requirements

Security & Reliability

Data protection & Privacy

SLO

User authentication and identity assurance level Authentication Mean time required to revoke user access Log access availability Logs retention period Certifications applicable Data portability format Data transfer rate Data geolocation list Data geolocation selection Legend:

Trust Factors Tree Level 2 Level 1

S2-SLO-01 S2-SLO-02

S2

S2-SLO-03 S5-SLO-01 S5-SLO-02 S6-SLO-01 DM4-SLO-01 DM4-SLO-02 PDP5-SLO-01 PDP5-SLO-02

CSC: Cloud Service Customer

Security (S) S5 S6 DM4 PDP5

Data Management (DM) Personal Data Protection (PDP)

SLO: Service Level Object

The context presented in Table 2 is sent to the Trust Evidence Extractor (TEE) via the Context Manager (CM) to extract information from SLAs and from feedback by other customers. Besides the context, the customer also defines evaluation preferences related to the trust factors, as follows. • Values for the trust factors: to indicate the minimum requirements imposed by the customer. • Weights of the trust factors: to show the relevance of the trust factors in the overall evaluation.

12

Table 3 shows the values and weights expected by the Cloud Service Customer. While weights can be assigned to trust factors at any level in the Trust Factors Tree, in this scenario, the weights were defined at Level 1 as follows: Security - high importance, Data Management - medium importance and Personal Data Protection - high importance. Table 3: The Cloud Service Customer’s requirements and associated weights

Level 1 TF Tree

S

DM PDP

Legend:

SLO

TF value

S2-SLO-01

LoA3

S2-SLO-02

2FA

S2-SLO-03

full

S5-SLO-01

LoA3

S5-SLO-02

356

S6-SLO-01

HIPPA

DM4-SLO-01

HTML, PDF

DM4-SLO-02

15

PDP5-SLO-01

UK, NL

PDP5-SLO-02

yes

TF weight

H

M H

SLO: Service Level Object

TF: Trust Factor

LoA: Level of Assurance

2FA: Two Factor Authentication

M: Medium

H: High

(B) Extracting trust information from SLAs. Table 4 presents the trust information extracted from the SLAs of three different cloud service providers. Column Type shows the Trust Indicators used for representing the Trust Factors (i.e. SLOs). An individual Trust Factors Tree is created for each Cloud Provider, and filled with the information extracted from the relevant SLA. The Trust Factors Tree constructed for CSP1 is shown in Figure 5. Table 4: Trust evidence extracted from SLAs (see Table 2 for legend)

SLO

Type

CSP1

CSP2

CSP3

S2-SLO-01

number

LoA4

LoA1

LoA3

S2-SLO-02

number

2FA

user name

user name

S2-SLO-03

number

3

2

1

S5-SLO-01

number

full

partial

full

S5-SLO-02

number

356

90

180

S6-SLO-01

set

ISO 27001, SOC, HIPPA

PCI

SOC, HIPPA

DM4-SLO-01

set

HTML, PDF, RTF, CSV

HTML, PDF, RTF, CSV

HTML, PDF, RTF, CSV

DM4-SLO-02

number

15

5

10

PDP5-SLO-01

set

UK, NL, US

US

NL

PDP5-SLO-02

boolean

yes

no

no

(C) Extracting trust information from non-SLA sources. Table 5 summarises the feedback received about the cloud providers. The process of converting the feedback to fuzzy numbers was described in Section 5.1. The final aggregated fuzzy ratings, depicted in the last 13

Figure 5: Trust Factors Tree of CloudP rovider1

column of Table 5, are aggregated with the Trust Factors Tree (see Figure 5) into the complete profile of CSP1 for the context defined by the Cloud Service Customer (shown in Table 2). It should be noted that a provider can have multiple profiles, one for each context. Table 5: Cloud Service Customer Feedback (see Table 1 for legend)

Factor

Security

Performance

Data Management Personal Data Protection

Cloud Providers CSP1 CSP2 CSP3 CSP1 CSP2 CSP3 CSP1 CSP2 CSP3 CSP1 CSP2 CSP3

CSCs feedback F B. F & G B. P & F B. P & F F B. F & G G B. F & G G B. F & G F B. P & F

B. P & F F G F B. F & G G G P B. F & G F B. F & G G

B. F& G G B. P & F P P B. P & F G B. F & G B. P & F G P B. P & F

B.

B. B.

B.

F VG F& F F F& F& VG F VG F F&

G

G G

G

Aggregated fuzzy rating (22.5,42.5,57.5,77.5) (50,70,77.5,92.5) (22.5,42.5,65,85) (15,35,42.5,62.5) (22.5,42.5,50,70) (30,50,72.5,92.5) (52.5,72.5,80,100) (35,55,70,85) (30,50,65,85) (50,70,77.5,92.5) (22.5,42.5,50,70) (22.5,42.5,65,85)

(D) Computing the SLA-based trust score. The first step is to map the values stored in the Trust Factors Tree of the provider’s profile to one of the following types: (i) boolean, (ii) numeric, (iii) set, or (iv) range. Each of these types has a specific representation. S2-SLO-01 describes Levels of Assurance (LoA) {LoA4, LoA3, LoA2, LoA1} according to ISO/IEC 291154 . LoA4 indicates the highest level of confidence, while LoA1 shows little or no confidence in the asserted identity. These values are statically mapped to the set {4,3,2,1} (i.e. LoA4 → 4, LoA3 → 3, etc.). We map the values of S2-SLO-02 in a similar manner. Specifically, the set of authentication mechanisms {Multi-Factor Authentication (MFA), Two Factor Authentication (2FA), username} is mapped to {3,2,1}. After this mapping, we follow the formulas described in Section 5.2, and calculate the SLA ratings for the trust factors in a bottom-up manner. We start at the SLO-level in the Trust Factors Tree, and the scores are incrementally propagated upwards to the parent nodes. The final score of the evaluation will be stored in the root node. 4 www.oasis-open.org/committees/download.php/44751/285-17Attach1.pdf

14

The Comparison Matrix (CM) given below is calculated for S2-SLO-01, and the CM is computed for every trust factor at the SLO-level in a similar manner.  CSP 1 CSP 2 CSP 3 CSC  1 4/1 4/3 4/3 CSP 2  1/4 1 1/3 1/3    =  CSP 3 3/4 3/1 1 3/3  CSC 3/4 3/1 3/3 1 CSP 1

CMS2−SLO−01

Then, the Priority Vector of S2-SLO-01 is calculated by successively applying the formulas in equation 8 to equation 12:  0.3636 CSP 2  0.0909    = CSP 3  0.2727  CSC 0.2727 CSP 1

P VS2−SLO−01



The Priority Vector shows that the threshold imposed by the Cloud Service Customer is 0.2727. Cloud Provider1 and Cloud Provider3 have higher values than that, so they meet the cloud customer’s criterion for this trust factor, while Cloud Provider2 fails to meet it. Similarly, we calculate the Priority Vectors for all siblings of S2-SLO-01 in the Trust Factors Tree (i.e. S2-SLO-02 and S2-SLO-03). We then aggregate these Priority Vectors to obtain the relative ranking matrix (RR) of trust factor S2.  P V S2-SLO-01 0.3636 CSP 2   0.0909 = CSP 3  0.2727 CSC 0.2727

P V S2-SLO-02 P V S2-SLO-03

0.3333 0.1667 0.1666 0.3333

CSP 1

RRP VS2

0.3333 0.2222 0.1111 0.3333

   

Now RRP VS2 is multiplied by the weights defined by the cloud customer to obtain the final Priority Vector for S2. If no explicit weights are assigned to the trust factors, CAMTF assumes that they have the same importance during evaluation. Since weights are assigned to trust factors at Level 1 in this scenario, S2-SLO-01, S2-SLO-02 and S2-SLO-03 will be assigned the same weight (0.33). The overall Priority Vector of S2 then becomes:  P V S2-SLO-01 0.3636 CSP 2  0.0909  = CSP 3  0.2727 CSC 0.2727

P V S2-SLO-02 P V S2-SLO-03

0.3333 0.1667 0.1666 0.3333

CSP 1

P VS2

0.3333 0.2222 0.1111 0.3333



 0.3434  0.3333     0.3333  =  0.1599    0.1835  0.3333 0.3131 





The Priority Vector of S2 indicates that only Cloud Provider1 satisfies the requirements with regards to S2, the values for CSP2 and CSP3 are below the customer’s threshold. We compute the values of the Priority Vectors for Security (S), Data Management (DM) and Personal Data Protection (PDP) in a similar manner. For readability reasons we show the transposed Priority Vectors as follows: P VST

=

T P VDM =



CSP 1

CSP 2

CSP 3

CSC

0.3245 0.1197 0.2413 0.3144



CSP 1

CSP 2

CSP 3



CSC

0.3245 0.1197 0.2413 0.3144

15



0.40

0.4 0.35

0.34

0.35

0.32

0.3

0.37

0.35

0.34

0.34

0.29

0.30

0.25

0.24

0.25

0.21

0.2

0.21

0.20

0.20

0.15

0.13

0.15

0.13

0.1 0.10

0.05 0.05

0 CSP1

CSP2

CSP3

CSC

0.00

SLA

Non-SLA CSP1

(a) SLA-based trust scores

CSP2

Total Score

CSP3

(b) Overall trust scores

P VPTDP =



CSP 1

CSP 2

CSP 3

CSC

0.3095 0.1984 0.2539 0.2381



Finally, the priority vectors of S, DM and PDP are aggregated to obtain the total priority vector, and then the resulting matrix is multiplied by the weights provided by the Cloud Service Customer (S: 0.4, DM: 0.2, PDP: 0.4). The final PV shows the SLA-based trust scores for each Cloud Provider. The result given below and in Figure 6a reveals that Cloud Provider1 is the only one satisfying the cloud customer’s SLA requirements. P V SLA =



CSP 1

CSP 2

CSP 3

CSC

0.3392 0.1251 0.2148 0.3209



(E) Computing Non-SLA-based trust score. Table 5 shows how other cloud customers evaluate the three providers, the last column indicating the overall score. To reflect the Cloud Service Customer’s preferences, the overall score of each provider is multiplied by the weights defined by the Customer: S - 0.4, DM - 0.2, PDP - 0.4 (see equation 3).

F RCSP 1



S

22.5  42.5 =   57.5 77.5

DM P DP

52.5 72.5 80 100

   50 0.4  70   0.2  = 77.5  0.4 92.5

 39.5  59.5     70  88 

The fuzzy ratings of CSP2 and CSP3 are calculated in a similar manner. After de-fuzzifying the scores (by using equation 1), we obtain the numerical ratings. To enable fair comparison with the SLA ratings, the numerical ratings are also normalised. The final ratings are presented in Table 6, and we can observe that CSP1 has the highest non-SLA-based trust score, followed by CSP2 and CSP3. Table 6: Non-SLA-based trust scores

Cloud Service Providers CSP1 CSP2 CSP3

Fuzzy Ratings (FR) (39.5, 59.5, 70, 88) (36, 56, 65, 82) (24, 44, 59, 79)

Defuzzified ratings 64.25 59.75 51.5

Normalised final ratings 0.3661 0.3405 0.2934

(F) Overall trust evaluation. After calculating the SLA and non-SLA based trust scores, we aggregate them to obtain the overall trustworthiness of the providers. This is performed by employing AHP, where the given weights to SLA and non-SLA Trust Factors are high-importance and medium-importance respectively. Figure 6b depicts the final results, i.e. the overall trust score of each CSP, and shows that CSP1 has the highest overall trust level among the three providers.

16

7. Discussion Establishing trust between customers and providers is a core issue in cloud computing. It is a difficult task, as consumers have little control over the way their data are handled in the cloud. This paper proposes a trust evaluation framework to facilitate this task via assisting customers in selecting the provider that best suits their requirements. We started with the trust evaluation process, and aimed at providing a tool that can be used in various scenarios. The result is a versatile system that can consider diverse user needs in a range of environments, and can provide advice based on previous user experiences and objective guidelines. The previous sections described CAMTF’s mathematical approach and its use in a case study. In this section, we look at CAMTF’s distinctive features and then compare CAMTF with other, existing works and show CAMTF’s advantages over them. 7.1. Distinctive features of CAMTF The most important features of the system were designed to help the decision maker, and also provide flexibility by allowing adjustments to different requirements. Using the criteria identified in [1] for evaluating trust frameworks in the context of Cloud Computing, we look at the following aspects. 1) Compliance with standardization efforts 2) Being multifaceted 3) Context awareness 4) Consumer perception of trust 5) Extensibility. (A detailed analysis of these aspects can be found in [1].) Compliance with standards. SLAs come in many forms, and their interpretation can be complex. CAMTF reduces any confusion and misinterpretation by relying on standardization initiatives; the SLA trust factors are based on EU guidelines for SLAs [15]. Standardization also includes proper identification of activities: CAMTF focuses on the establishment of trust in the broad context of trust management. Multifaceted evaluation and context awareness. Application scenarios need to consider a large number of factors that may need to be tailored to a given context. The underlying evaluation model of CAMTF for selecting the best Cloud Provider is domain-independent, and is based on multifaceted trust factors. At the same time, parameters of the trust factors can be customized according to the cloud application context, which make it context aware. Consumer perception of trust. The identified trust factors include subjective and objective estimation of trustworthiness. Such diversity in the trust factors reduces the Cloud Service Customer’s future regret, i.e. the feeling when the choice was not right, and improves the chances of correct trust decision. Furthermore, CAMTF allows cloud customers to express their perception of trust and identify weights of trust factors. Extensibility. To prepare for various applications, CAMTF is expandable and can incorporate additional trust factors. The methods used, AHP and Fuzzy Simple Additive Weighting (FSAW) offer flexibility and expandability. Also, FSAW supports additional consideration of uncertainty. Systems often need to evolve during their lifetime, and algorithms and methods may need to be updated. To enable future development, CAMTF supports different mathematical approaches for computing trust. 7.2. Related Work A number of solutions have been proposed in the literature for addressing different aspects of trust in the context of cloud computing. Table 7 summarizes the features of several trust frameworks, and it also indicates the level of support for aspects mentioned in the previous section. The frameworks support several of the above mentioned criteria to varying degrees, however, as the last row shows, CAMTF is the only one satisfying all. The important aspects are discussed below. Managing security is an important aspect of building trust in cloud computing. One solution monitors metrics of security requirements stated in SLAs, detects any violation, and provides mitigation [23]. This work utilizes standardization SLA initiatives like CSAs Cloud Control Matrix (CCM) and C-SIG SLA. While the offered level of security has a strong influence on the evaluation

17

of trust, concentrating exclusively on it may not give a complete picture. Trust evaluation frameworks that consider only one facet, such as security of Cloud Providers, may not reduce future customer regret sufficiently, even if they use the CSA checklist [14, 7]. Noteworthy shortcomings of previous work include reliance on a single source of information [7], or not telling the approach for extracting and aggregating information when using several sources such as Cloud Providers, users and experts [14]. CAMTF improves decision making by evaluating trust based on multiple aspects. Table 7: Comparison of trust frameworks

Reference

Based on standards # #

Chakraborty and Roy [24] Ghosh et al. [8] Garg et al. [13] Luna et al. [7] Habib et al. [14] Wang and Wu [11] Casola et al. [25] Qu et al. [9] Hammadi et al. [26] Li et al. [27] Badidi [28] Redl et al. [29] Huang and Nicol [30] Haq et al. [31] Pawar et al. [32] Rizvi et al. [33] Singh and Sidhu /[34] Somu et al. [35] CAMTF Legend:

# # # # # # # # #

Multifaceted #

Consumer Perception of trust

#



Expandable #

#

# #



# #

# Fully supported =

# # # # # # # #

Context awareness # # # # # # # # # # # #

, Partially supported= , Not supported = #

The framework presented in [8] allows consumers to express their perception of trust. This is limited, however, to specifying the importance of the context, without providing additional flexibility to identify the importance of other factors. In contrast, [11, 25, 34] take into account consumer requirements without restrictions. Notably, [34] involves also other parties like security auditor, and employs multiple criteria for evaluating trust. However, the SLA is not identified according to a standardization approach. A framework for ranking Cloud Providers is introduced in [35] based on different criteria, and utilizes Minimum Distance-Helly Property (MDHP) for ranking them, but this work does not rely on standardization initiatives. The work in [8] recognizes multiple contexts, but uses only broad type of cloud services: Infrastructure as a Service, Platform as a Service, Software as a Service. The authors acknowledge, however, that each context can have multiple sub-contexts. The framework in [28] is designed for a specific type of cloud services (i.e. Software as a Service), thus provides only partial context awareness. Due to the dynamic nature of the cloud [2], trust evaluation has to be dynamic. In other words, any trust value should be re-computed when the need arises. While acknowledging the importance of the assessment conducted by auditors, we need to be aware that such an assessment reflects the trust only at a particular point in time, i.e. when the assessment is performed [30]. Additionally, ambiguity has been identified in several existing trust frameworks [24, 36, 3, 13]. However, it is unclear whether they are addressing the problem of selecting the optimal Cloud Provider and establishing trust, or their focus is on maintaining trust. This ambiguity is reinforced by the fact that some of these works [24, 3, 13] do not rely on standardization efforts for selecting

18

the evaluation criteria. CAMTF addresses the phase of establishing trust, and utilizes existing standards. 8. Conclusion This paper proposed a Context-Aware Multifaceted Trust Framework (CAMTF) for evaluating the trustworthiness of Cloud Providers as well for assisting Cloud Consumers in selecting the best and most trustworthy Cloud Provider. CAMTF takes into account limitations of the frameworks presented in the literature, and also offers cloud consumers to select the granularity in expressing their requirements and their perception of trust. CMTF uses mathematical methods such as Analytic Hierarchy Process (AHP) and Fuzzy Simple Additive Weighting (FSAW), while also allows other mathematical approaches to be utilized. A case study demonstrated the implemented system’s applicability in practical settings. Some issues have not been fully explored in this paper, such as automating the process of extracting SLAs, these present a potential avenue for future work. Also, incorporating uncertainty in this framework is a potential research area. Furthermore, it my be worth exploring approaches for optimizing the functionality of the preference manager and making it smarter. In many scenarios the system may need to be protected against insider attacks, which is an emerging issue in cloud computing [4]. Acknowledgment This project was partially funded by the EU FP7 project 611659 (AU2EU). Also, we would like to thank the anonymous reviewers for their suggestions and constructive feedback. References [1] M. Alhanahnah, P. Bertok, Z. Tari, Trusting cloud service providers: Trust phases and a taxonomy of trust factors, IEEE Cloud Computing 4 (1) (2017) 44–54. doi:10.1109/MCC.2017.20. [2] S. Pearson, Privacy, Security and Trust in Cloud Computing, Springer London, London, 2013, pp. 3–42. [3] A. Hammadi, O. K. Hussain, T. Dillon, F. K. Hussain, A framework for sla management in cloud computing for informed decision making, Cluster Computing 16 (4) (2013) 961–977. doi:10.1007/s10586-012-0232-9. [4] M. J. Alhanahnah, A. Jhumka, S. Alouneh, A Multidimension Taxonomy of Insider Threats in Cloud Computing, The Computer Journal 59 (11) (2016) 1612–1622. doi:10.1093/comjnl/bxw020. [5] Z. Tari, X. Yi, U. Premarathne, P. Bertok, I. Khalil, Security and privacy in cloud computing: Vision, trends, and challenges, Cloud Computing, IEEE 2 (2) (2015) 30–38. doi:10.1109/MCC.2015.45. [6] S. M. Habib, S. Ries, M. Muhlhauser, Cloud computing landscape and research challenges regarding trust and reputation, in: 2010 7th International Conference on Ubiquitous Intelligence Computing and 7th International Conference on Autonomic Trusted Computing, 2010, pp. 410–415. doi:10.1109/UIC-ATC.2010.48. [7] J. Luna, A. Taha, R. Trapero, N. Suri, Quantitative reasoning about cloud security using service level agreements, IEEE Transactions on Cloud Computing PP (99) (2017) 1–1. doi:10.1109/TCC.2015.2469659.

19

[8] N. Ghosh, S. K. Ghosh, S. K. Das, Selcsp: A framework to facilitate selection of cloud service providers, IEEE Transactions on Cloud Computing 3 (1) (2015) 66–79. doi:10.1109/TCC.2014.2328578. [9] L. Qu, Y. Wang, M. a. Orgun, Cloud Service Selection Based on the Aggregation of User Feedback and Quantitative Performance Assessment, in: 2013 IEEE International Conference on Services Computing, IEEE, 2013, pp. 152–159. doi:10.1109/SCC.2013.92. [10] E. Costante, J. Hartog, M. Petkovi´c, Understanding perceived trust to reduce regret, Comput. Intell. 31 (2) (2015) 327–347. doi:10.1111/coin.12025. [11] L. Wang, Z. Wu, A Novel Trustworthiness Measurement Model for Cloud Service, in: 2014 IEEE/ACM 7th International Conference on Utility and Cloud Computing, 2014, pp. 928– 933. doi:10.1109/UCC.2014.151. [12] A. M. Hammadi, O. Hussain, A framework for sla assurance in cloud computing, in: 2012 26th International Conference on Advanced Information Networking and Applications Workshops, 2012, pp. 393–398. doi:10.1109/WAINA.2012.280. [13] S. K. Garg, S. Versteeg, R. Buyya, A framework for ranking of cloud computing services, Future Generation Computer Systems 29 (4) (2013) 1012–1023. doi:10.1016/j.future.2012.06.006. [14] S. M. Habib, S. Ries, M. M¨ uhlh¨auser, P. Varikkattu, Towards a trust management system for cloud computing marketplaces: using caiq as a trust information source, Security and Communication Networks 7 (11) (2014) 2185–2200. [15] C-SIG SLA, Cloud Service Level Agreement Standardisation Guidelines, Tech. rep., Brussels (2014). URL https://ec.europa.eu/digital-single-market/news/ cloud-service-level-agreement-standardisation-guidelines [16] S. Mittal, K. P. Joshi, C. Pearce, A. Joshi, Parallelizing natural language techniques for knowledge extraction from cloud service level agreements, in: Big Data (Big Data), 2015 IEEE International Conference on, IEEE, 2015, pp. 2831–2833. [17] M. Pastuszko, B. Kryza, R. S. Lota, J. Kitowski, Processing and Negotiation of Natural Language based Contracts for Virtual Organizations, in: Proceedings of Cracow’09 Grid Workshop, Cracow, Poland, 2009. [18] T. L. Saaty, How to make a decision: The analytic hierarchy process, European Journal of Operational Research 48 (1) (1990) 9–26. [19] S.-Y. Chou, Y.-H. Chang, C.-Y. Shen, A fuzzy simple additive weighting system under group decision-making for facility location selection with objective/subjective attributes, European Journal of Operational Research 189 (1) (2008) 132–145. doi:10.1016/j.ejor.2007.05.006. [20] G.-S. Liang, Fuzzy mcdm based on ideal and anti-ideal concepts, European Journal of Operational Research 112 (3) (1999) 682 – 691. [21] Collaborative services for ehealth and ambient assisted living (aal) use case, http://www. au2eu.eu/about/pilots/ehealth-pilot.html, accessed: 2017-07-15 (2015). [22] J. Zic, B. Lange, T. Ignatenko, D. Pletea, P. Koster, Detailed description of use cases, Tech. rep., accessed: 2016-07-15 (2015). URL {http://www.au2eu.eu/uploads/Publications/deliverables/AU2EU_D1.1.1.pdf} [23] R. Trapero, J. Modic, M. Stopar, A. Taha, N. Suri, A novel approach to manage cloud security sla incidents, Future Generation Computer Systems 72 (2017) 193 – 205. doi:http://dx.doi.org/10.1016/j.future.2016.06.004. 20

[24] S. Chakraborty, K. Roy, An sla-based framework for estimating trustworthiness of a cloud, in: Trust, Security and Privacy in Computing and Communications (TrustCom), 2012 IEEE 11th International Conference on, IEEE, 2012, pp. 937–942. [25] V. Casola, A. Fasolino, N. Mazzocca, P. Tramontana, An AHP-Based Framework for Quality and Security Evaluation, in: 2009 International Conference on Computational Science and Engineering, Vol. 3, IEEE, 2009, pp. 405–411. doi:10.1109/CSE.2009.391. [26] A. Hammadi, O. K. Hussain, T. Dillon, F. K. Hussain, A framework for SLA management in cloud computing for informed decision making, Vol. 16, IEEE, 2013, pp. 961–977. doi:10.1007/s10586-012-0232-9. [27] A. Li, X. Yang, S. Kandula, M. Zhang, Cloudcmp: Comparing public cloud providers, in: Proceedings of the 10th ACM SIGCOMM Conference on Internet Measurement, IMC ’10, ACM, New York, NY, USA, 2010, pp. 1–14. doi:10.1145/1879141.1879143. [28] E. Badidi, A framework for software-as-a-service selection and provisioning, arXiv preprint arXiv:1306.1888. [29] C. Redl, I. Breskovic, I. Brandic, S. Dustdar, Automatic sla matching and provider selection in grid and cloud computing markets, in: Proceedings of the 2012 ACM/IEEE 13th International Conference on Grid Computing, GRID ’12, IEEE Computer Society, Washington, DC, USA, 2012, pp. 85–94. doi:10.1109/Grid.2012.18. [30] J. Huang, D. M. Nicol, Trust mechanisms for cloud computing, Journal of Cloud Computing: Advances, Systems and Applications 2 (1) (2013) 9, lack of standardized SLAs. doi:10.1186/2192-113X-2-9. [31] I. U. Haq, R. Alnemr, A. Paschke, E. Schikuta, H. Boley, C. Meinel, Distributed trust management for validating sla choreographies, in: P. Wieder, R. Yahyapour, W. Ziegler (Eds.), Grids and Service-Oriented Architectures for Service Level Agreements, Springer US, 2010, pp. 45–55. [32] P. S. Pawar, M. Rajarajan, T. Dimitrakos, A. Zisman, Trust Model for Cloud Based on Cloud Characteristics, in: Trust Management VII, Vol. 401, 2013, pp. 239–246. doi:10.1007/978-3642-38323-6 18. [33] S. Rizvi, J. Ryoo, Y. Liu, D. Zazworsky, A. Cappeta, A centralized trust model approach for cloud computing, in: 2014 23rd Wireless and Optical Communication Conference (WOCC), 2014, pp. 1–6. doi:10.1109/WOCC.2014.6839923. [34] S. Singh, J. Sidhu, Compliance-based multi-dimensional trust evaluation system for determining trustworthiness of cloud service providers, Future Generation Computer Systems 67 (2017) 109 – 132. doi:http://dx.doi.org/10.1016/j.future.2016.07.013. [35] N. Somu, K. Kirthivasan, S. S. V.S., A computational model for ranking cloud service providers using hypergraph based techniques, Future Generation Computer Systems 68 (2017) 14 – 30. doi:http://dx.doi.org/10.1016/j.future.2016.08.014. [36] O. Jules, A. Hafid, M. A. Serhani, Bayesian network, and probabilistic ontology driven trust model for sla management of cloud services, in: Cloud Networking (CloudNet), 2014 IEEE 3rd International Conference on, IEEE, 2014, pp. 77–83.

21

Mohannad Alhanahnah Bio: is a Research Assistant in the Department of Computer Science and Engineering at The University of Nebraska-Lincoln, Nebraska, USA. Alhanahnah holds MSc degree from the University of Kent in Computer Security. He also holds several industry certificates as CISSP, CEH, CCNP Security and Security+. His research interest in addressing security issues in the context of Cloud Computing and Internet of Things. Contact him at [email protected].

Peter Bertok: Bio: is an associate professor in the School of Computer Science at RMIT University, Australia, where he’s a member of the Cyberspace \& Security Group (CSG). His research interests include access control, privacy protection and communication security. Bertok has a PhD in computer engineering from the University of Tokyo, Japan. Contact him at [email protected].

Zahir Tari Bio: is a professor in the School of Computer Science at RMIT University, Australia, where he’s a member of the Cyberspace \& Security Group (CSG). His research interests include security in critical systems (such as SCADA) and performance/reliability in large-scale distributed systems (such as the cloud). Tari has a PhD in computer science from the University of Grenoble. Contact him at [email protected].

Sahel Alouneh Bio: Sahel Alouneh is an Associate Professor of computer engineering and the Dean of Faculty of Electrical Engineering and Information Technology at the German Jordanian University. His research interests include computer networks, big data security, cloud computing, software security, MPLS security and recovery, Wireless networking security, Software testing, computer design and architecture.

Highlights:      

Facilitating the process of selecting the optimal CSP by showing real case study.  Incorporating uncertainty is very important for evaluating trust.  Showing the features of the trust framework which can be customized and adopted.   Showing how SLA is not presented in standardized way in other frameworks.  Reducing the confusion that comes along the trust evaluation process.