| Date post: | 01-May-2023 |
| Category: |
Documents |
| Upload: | khangminh22 |
| View: | 0 times |
| Download: | 0 times |
An Adaptive Trust-aware Brokerage Model for Cross-cloud Federation
By
Usama Ahmed
CIIT/FA14-PCS-004/LHR
PhD Thesis
In
Computer Science
COMSATS University Islamabad
Lahore Campus - Pakistan
Fall, 2019
ii
COMSATS University Islamabad
An Adaptive Trust-aware Brokerage Model for Cross-cloud Federation
A Thesis Presented to
COMSATS University Islamabad, Lahore Campus
In partial fulfillment
of the requirement for the degree of
PhD (Computer Science)
By
Usama Ahmed
CIIT/FA14-PCS-004/LHR
Fall, 2019
iii
An Adaptive Trust-aware Brokerage Model for Cross-cloud Federation
A Post Graduate Thesis submitted to the Department of Computer Science as partial
fulfillment of the requirements for the award of Degree of PhD in Computer
Science.
Name Registration Number
Usama Ahmed CIIT/FA14-PCS-004/LHR
Supervisor Syed Asad Hussain Professor, Department of Computer Science COMSATS University Islamabad (CUI) Lahore Campus Co-Supervisor Adnan Ahmed Assistant Professor, Department of Computer Science COMSATS University Islamabad (CUI) Lahore Campus
iv
v
vi
vii
viii
DEDICATION
To My mother
For her faith in me
To My wife
For her patience and support
To My daughters
For their love and smiles
Without which the completion of this work would not have been possible
ix
ACKNOWLEDGEMENTS
I would like to extend thanks to the all those people who so generously contributed to the
work presented in this thesis. Special mention goes to my enthusiastic supervisor, Professor
Syed Asad Hussain. My PhD has been an amazing experience and I thank Prof. Asad
wholeheartedly, not only for his tremendous academic as well as administrative support.
Similar, profound gratitude goes to Mr. Imran Raza, who has been a truly dedicated mentor.
I am particularly indebted to Mr. Imran Raza for his consistent support, sharing his
expertise so willingly and for being so dedicated to his role.
I am also thankful to Professor Omer F. Rana at Cardiff University, UK for hosting me
there during my fellowship and providing me opportunity to carry out my research in a
challenging environment.
I would also like to acknowledge Higher Education Commission, (HEC), Pakistan for
providing me an Indigenous Fellowship for my PhD, and also an opportunity under
International Research Support Initiative Program (IRSIP) to visit Cardiff University, UK
as a guest researcher.
In the last, but by no means least, I am grateful to my employer Government College
University, Faisalabad for being truly supportive by providing sabbatical for the entire
period of my PhD.
Usama Ahmed CIIT/FA14-PCS-004/LHR
x
ABSTRACT An Adaptive Trust-aware Brokerage Model for Cross-cloud
Federation
Establishing trust in cloud computing has been a major concern for cloud users since the
very beginning of pay-as-you-go service. In the recent years, cross-cloud federation has
enabled cloud providers to share or lease resources from each other. Contrary to the
hesitation of cloud users for cloud adoption, it is now the cloud providers that are reluctant
to take part in federation due to lack of trust on their unknown counterparts. A recent void
has been observed to address the challenges of trustworthy resource exchanges within the
federation. This research has established that trust awareness among cloud providers
requires a comprehensive trust framework that is aligned with the nature of federation.
A detailed requirement analysis for trust in cross-cloud federation has been performed in
this research. This analysis is based on four founding principles of cloud-to-cloud trust
paradigm namely bi-directionality, composite trust, delegation control and resource aware
trust evaluation. Afterwards, requirements originated from these principles are aligned with
the attributes of trust and cloud federation with the help of a detailed requirement matrix.
Keeping in view this requirement matrix, an adaptive trust-aware brokerage model has
been developed. This model offers dynamic trust establishment approaches that are a
function of relationship among service providers. Three different approaches i.e.
Conjunctive Accumulation of Trust (ConAccT), Numerical Accumulation of Trust
(NAccT) and Cooperation Threshold Estimation (CTE) are developed as part of the
proposed model. ConAccT is based on belief calculus and may be useful in case of highly
competitive collaborating scenarios where detailed analysis of trust is required to decide
cooperation among Cloud Service Providers (CSPs). NAccT approach is based on
numerical calculus and is useful in less competitive scenarios and can be combined with
metrics other than trust i.e. performance, availability, resource specifications etc. CTE
approach is an extension to NAccT and presents a use case of utilizing the performance
metric of a CSP combined with its trust metric to evaluate risk of failure in a collaborative
project. The significance of these approaches has been verified by implementing the
adaptive trust-aware model as a trusted broker based Clouds4Coordination (C4C) system
xi
developed for Architecture/Engineering/Construction (AEC) industry. This C4C system is
currently implemented in United Kingdom in collaboration with Cardiff University, UK
and Rutgers Discovery Informatics Institute (RDI2), USA. Experimental evaluation of
these approaches suggests their suitability in varying scenarios of collaborative computing
in construction industry. It has been verified that trust-aware relationships within the
federation stays for a longer duration of time during collaborative projects. Moreover, an
in depth analysis of proposed approach has shown that trust awareness is beneficial in terms
of successful service delivery, earlier project completion and reduction in uncertainty of
collaboration. A comparative analysis with state-of-art approaches have demonstrated the
efficiency of proposed approaches to identify participants of federation that can cause
potential risks and unnecessary delays in the projects.
xii
TABLE OF CONTENTS
1 Introduction ...................................................................................................... 1
1.1 General Context ......................................................................................... 2
1.2 Motivation.................................................................................................. 3
1.3 Problem Statement ..................................................................................... 4
1.4 Contributions ............................................................................................. 5
1.5 Thesis Organization ................................................................................... 6
2 Cross-Cloud Federation and Trust: Theoretical Foundations .................... 8
2.1 Introduction................................................................................................ 9
2.2 Inter-cloud model..................................................................................... 10
2.3 Inter-cloud architectural classification .................................................... 12
Multi-cloud architecture ....................................................................... 13
Federation architecture ......................................................................... 15
2.4 Cross-cloud federation ............................................................................. 16
Fundamental concepts .......................................................................... 18
Inter-cloud initiatives ........................................................................... 21
2.5 Trust management overview - Social perspective ................................... 24
Trust in social psychology ................................................................... 24
Trust in philosophy .............................................................................. 25
Trust in economics ............................................................................... 26
2.6 Trust management overview - Technical context ................................... 26
Hard trust.............................................................................................. 27
Explicit trust ......................................................................................... 27
Soft trust ............................................................................................... 28
2.7 Trust management systems ...................................................................... 28
Trust sources ........................................................................................ 30
Trust methods ....................................................................................... 32
Properties of trust management systems .............................................. 33
2.8 CSA STAR program ................................................................................ 35
Cloud Control Matrix ........................................................................... 36
xiii
Consensus Assessment Initiative Questionnaire .................................. 36
2.9 Summary .................................................................................................. 36
3 Recent Trends in Trust Management .......................................................... 38
3.1 Introduction.............................................................................................. 39
3.2 Single sourced trust models ..................................................................... 40
Models using policy as a source of trust .............................................. 40
Policy based models with multi-cloud support .................................... 42
Models using recommendation as a source of trust ............................. 42
Recommendation based models with multi-cloud support .................. 44
Evidence as a source of Trust .............................................................. 45
3.3 Multi-sourced trust models ...................................................................... 46
Trust models with supportive evidence ............................................... 46
Trust models with supportive evidence for multi-cloud ...................... 48
Trust models with policy and recommendation as source ................... 50
3.4 Trust models with federation support ...................................................... 52
3.5 Summary .................................................................................................. 54
4 Research Methodology .................................................................................. 55
4.1 Introduction.............................................................................................. 56
4.2 Overview of research ............................................................................... 57
4.3 Exploratory Research .............................................................................. 59
Cross-cloud trust paradigm .................................................................. 59
Theoretical framework for cross-cloud federation .............................. 61
Conceptual cross-cloud framework ..................................................... 64
Requirement Analysis .......................................................................... 67
4.4 Applied research ...................................................................................... 69
Implementation .................................................................................... 71
Data collection ..................................................................................... 71
Data processing and analysis ............................................................... 73
4.5 Validation and evaluation ........................................................................ 73
4.6 Summary .................................................................................................. 73
5 System Design and Architecture .................................................................. 75
xiv
5.1 Introduction.............................................................................................. 76
5.2 Empirical system design .......................................................................... 77
Cloud4Coordination federation ........................................................... 77
Cloud Federation Broker ...................................................................... 83
5.3 Trust evaluation approaches – Analytical design .................................... 86
Trust representation ............................................................................. 87
Trust evaluation ................................................................................... 87
5.4 Conjunctive Accumulation of Trust (ConAccT) ...................................... 92
Representation as service dependency model ...................................... 92
Trust evaluation for composite services .............................................. 95
Result significance and selection criteria ........................................... 100
5.5 Numerical Accumulation of Trust (NAccT) ......................................... 101
5.6 Cooperative threshold estimation (CTE) ............................................... 102
Risk and collaboration ....................................................................... 103
Perceived risk ..................................................................................... 104
Perceived competence ........................................................................ 104
5.7 Summary ................................................................................................ 107
6 Experimental Evaluation ............................................................................ 108
6.1 Introduction............................................................................................ 109
6.2 Experimental Setup ................................................................................ 109
6.3 Experimentation and Results ................................................................. 110
Experiments for ConAccT and NAccT ............................................. 110
Experiments for CTE – The risk based service selection .................. 122
6.4 Summary ................................................................................................ 134
7 Conclusions and Future Work ................................................................... 135
8 References ..................................................................................................... 139
APPENDIX - A ................................................................................................. 152
APPENDIX - B ................................................................................................. 153
APPENDIX - C ................................................................................................. 156
xv
LIST OF FIGURES
Figure 1: A typical cross-cloud federation.......................................................................... 2 Figure 2: Inter-cloud variants (a) multi-cloud architecture (b) federation architecture .... 13 Figure 3: Application development patterns for multi-cloud deployments (a) replication of application (b) multi-tiered applications (c) logic fragmentation (d) data fragmentation 14 Figure 4: A cross-cloud federation supporting MMOG application ................................. 17 Figure 5: Inter-layer and Intra-layer resource federation .................................................. 19 Figure 6: A block representation of trust management system functionality ................... 29 Figure 7: CSA STAR program assessment and certifications [136] ................................ 35 Figure 8: Research methodology illustration .................................................................... 57 Figure 9: Delegated trust in cross-cloud federation .......................................................... 60 Figure 10: Bi-directional trust for cross-cloud federation ................................................ 61 Figure 11: Abstract illustration of composite trust ........................................................... 62 Figure 12: Delegation control for cross-cloud federation ................................................. 63 Figure 13 Context awareness in cross-cloud federation ................................................... 63 Figure 14: Abstract illustration of proposed system ......................................................... 78 Figure 15: System design and interaction of entities within the federation ...................... 82 Figure 16: Profile Management processes and their interactions ..................................... 84 Figure 17: Resource manager details and interaction with other modules ....................... 85 Figure 18: Representation of individual trust values of CSPs .......................................... 92 Figure 19: A composite service with singular and concurrent relations ........................... 93 Figure 20: Composite trust for service S .......................................................................... 97 Figure 21: singular dependency based trust ...................................................................... 98 Figure 22: Concurrent dependency based trust evaluation ............................................. 100 Figure 23 Dependency graph for service A in NAccT ................................................... 101 Figure 24 Perceived competence metric and workflow .................................................. 106 Figure 25: Trend for all trust parameters for 5 CSPs in random .................................... 112 Figure 26: (a) Composite belief and expectation (b) variation in uncertainty and (c) disbelief for experiment 1 ............................................................................................... 113 Figure 27: Comparison of NAccT and ConAccT approaches for experiment-1 ............ 114 Figure 28: Comparison of NAccT, ConAccT and STA approach in case of (a) composite trust and (b) maximum uncertainty for experiment 1 ..................................................... 114 Figure 29: (a) Composite belief and expectation (b) Composite disbelief and (c) variation in uncertainty for experiment 2 ....................................................................................... 115 Figure 30: Comparison of NAccT and ConAccT approaches for experiment-2 ............ 116 Figure 31: (a) Composite expectation and belief (b) Composite uncertainty for experiment 3....................................................................................................................................... 116 Figure 32: Composite trust based on NAccT and ConAccT for experiment 3 ............... 117 Figure 33: A chain of singular dependency .................................................................... 117 Figure 34: Composite trust as of NAccT and ConAccT ................................................. 118 Figure 35: (a) composite trust and (b) uncertainty for singular dependency federation . 118 Figure 36: A mesh of concurrent dependency ................................................................ 119 Figure 37: Composite belief and expectation for concurrent dependency federation .... 119 Figure 38: Composite trust as evaluated by NAccT and ConAccT for experiment 5 .... 120
xvi
Figure 39: Composite (a) uncertainty and (b) trust for concurrent dependency federation in experiment 5.................................................................................................................... 120 Figure 40: Composite belief and expectation for concurrent dependency in experiment 6......................................................................................................................................... 121 Figure 41: Composite (a) trust (b) uncertainty for joint dependency federation in experiment 6.................................................................................................................... 121 Figure 42: Composite trust for concurrent dependency as evaluated by NAccT and ConAccT in experiment 6 ............................................................................................... 122 Figure 43: CTE based service selection for a construction project ................................ 123 Figure 44: (a) Aggregated time to complete (b) aggregated project performance in case of CTE based selection ........................................................................................................ 124 Figure 45: Aggregated (a) model writing and (b) metadata synchronization time for project......................................................................................................................................... 125 Figure 46: Aggregated (a) update and (b) fetch time for project .................................... 125 Figure 47: (a) Aggregated time to complete (b) project performance in case of competence based selection ................................................................................................................ 126 Figure 48: Aggregated (a) model writing and (b) metadata synchronization time for project......................................................................................................................................... 127 Figure 49: Aggregated (a) update and (b) fetch time for project .................................... 127 Figure 50: (a) Aggregated time to complete (b) project performance in case of trust based selection .......................................................................................................................... 128 Figure 51: (a) model writing and (b) metadata synchronization time for project ........... 128 Figure 52: (a) update and (b) fetch time for trust based selected project ....................... 129 Figure 53: (a) Aggregated time to complete (b) project performance in case of random selection .......................................................................................................................... 129 Figure 54: (a) model writing and (b) metadata synchronization time for project ........... 130 Figure 55: (a) update and (b) fetch time for trust based selected project ....................... 130 Figure 56: Comparison of ATTC in case of all selection mechanisms .......................... 131 Figure 57: Comparison of aggregated project competence in case of all selection mechanisms ..................................................................................................................... 131 Figure 58: Comparison of writing time for all selection mechanisms ............................ 132 Figure 59: Comparing metadata synchronization time for all selection mechanisms .... 133 Figure 60: Comparing fetch time for all selection mechanisms ..................................... 133
xvii
LIST OF TABLES
Table 1: Comparison of edge computing implementations ........................................... 11 Table 2: Differences between multi-cloud and federation ............................................. 13 Table 3: Overview of recent advancements in inter-cloud initiatives ........................... 23 Table 4: Influence of cloud-to-cloud trust principles on trust management systems .... 64 Table 5 Objective analysis of TMS in cloud computing ............................................... 66 Table 6 Matrix for requirements of trust in cross-cloud federation ............................... 70 Table 7: Quantitative parameters of proposed research ................................................. 72 Table 8: Symbols and representation ............................................................................. 87 Table 9: Individual trust representation of five CSPs .................................................... 91 Table 10: Composite trust for service S as evaluated by ConACCT ............................. 96 Table 11 Singular dependency trust for CSPs ............................................................... 98 Table 12 Concurrent dependency trust for CSP ............................................................ 99 Table 13: System specification for experimentation ................................................... 109
xviii
LIST OF ABBREVIATIONS
ACB Autonomic Cloud Broker
AEC Architecture/Engineering/Construction
AR Augmented Reality
ATTC Aggregated-Time-To-Complete
C4C Clouds4Coordination
CAIQ Cloud Assessment Initiative Questionnaire
CAPEX Capital Expense
CCM Cloud Control Matrix
CCFM Cross-Cloud Federation Manager
CEx Cloud Exchange
ConAccT Conjunctive Accumulation of Trust
CSA Computer Security Alliance
CSP(s) Cloud Service Provider(s)
CSU(s) Cloud Service Users(s)
DAG Directed Acyclic Graph
DCC Dynamic Cloud Collaboration
DDoS Distributed Denial of Service
DHT Distributed-hash-table
ENISA European Network and Information Security Agency
FCM Federated Cloud Management
FedMgr Federation Manager
GMBS Generic Meta-Broker Service
GTL Global Trust Level
HPC High Performance Computing
IaaS Infrastructure as a Service
ICAF Intercloud Architecture Framework
IdPs Identity providers
IFC Industry Foundation Classes
IMPS Instant Messaging and Presence Service
IoT Internet of Things
xix
LIST OF ABBREVIATIONS (CONTD.)
MMOGs Massively Multiplayer Online Games
NAccT Numerical Accumulation of Trust
NIST National Institute of Standard and Testing
OPEX Operation Expense
P2P Peer-to-Peer
PaaS Platform as a service
pCP primary Cloud Provider
PERMIS PrivilEge and Role Management Infrastructure Standard
QoP Quality of Protection
QoS Quality of Service
RDI2 Rutgers Discovery Informatics Institute
REM Reference Evaluation Model
SaaS Software as a Service
SAML Security Assertion Markup Language
SDG Service Dependency Graph
SecLA Security Level Agreement
SIP Session Initiation Protocol
SLA Service Level Agreement
SLO Service Level Objective
SOA Service Oriented Architectures
STAR Security, Trust & Assurance Registry
TaaS Trust as a Service
TRESs Trust and Reputation Evaluation Systems
TMS Trust Management Systems
TSPs Trust Service Providers
TTP Trusted Third Party
V2X Vehicle-to-everything
vTPMs virtualized Trusted Platform Modules
XMPP Extensible Messaging and Presence Protocol
1
Chapter 1
1 Introduction
2
1.1 General Context
Cloud computing has attracted a lot of attention in the recent years as a pay-as-you-go
computational paradigm offering on-demand services to the users in accordance with
certain Service Level Objective (SLO) [1]. However, with the latest trends in computing,
single cloud data centers often prove inefficient to deal with unpredictable computational
demands of certain applications. Also single cloud model prove ineffective in case of
prolonged downtime even for non-critical applications [2]. Use of multiple clouds known
as inter-cloud model has gained popularity as it provides sufficient ability for a Cloud
Service Provider (CSP) to maintain SLOs while keeping Capital Expense (CAPEX) and
Operation Expense (OPEX) to a minimum.
From a Cloud Service User (CSU) perspective, multiple cloud usage helps avoid vendor
lock-in, provides platform diversity and sufficient responsiveness to the consumers across
the globe. This concept of inter-cloud emerged just a few years ago after the advent of
cloud computing. Inter-cloud architectures can be broadly categorized as i) multi-cloud and
ii) federation. A multi-cloud architecture recommends using various independent CSPs to
facilitate a consumer and results in a user-cloud relationship governed by individual
agreements of respective clouds. Consumers or their representative service is directly
responsible for arbitration, resource provisioning, scheduling, data and application security
[3]. Contrary to this, a federation comprises of various CSPs interconnecting their
respective infrastructures for sharing of resources in either static or dynamic ways [4].
Figure 1: A typical cross-cloud federation
3
This dynamic interconnection of CSPs, known as Cross-Cloud Federation (CCF) [5] is
depicted in Figure 1. CCF offers a complex scenario of resource sharing at each layer of
the cloud service model [5] with the following characteristics.
Minimum setup time: Discovery of required resources, negotiation and relationship
establishment in shortest possible time before a resource exchange takes place.
Contract renegotiations: Resource requirements may diminish over time resulting
in termination of relationship before a stipulated period of time. Long-term
contracts are not feasible, hence dynamic and reconfigurable contracts are needed.
Hierarchical resource exchanges: A resource exchange may take place among
CSPs in a hierarchical manner. For example, CSP-A might be leasing a resource
from CSP-B, however, CSP-B might have already leased the same resource from
CSP-C.
1.2 Motivation
In recent years federation of clouds has established itself as a market model where
CSPs can buy and sell resources or services to each other. This mechanism of leasing
resources has proved to be an enabler for extensive usage of High Performance Computing
(HPC), big data, scientific workflows and parallel processing applications. These
applications can now scale by making use of resources and services merged from different
cloud providers. Despite these promising benefits of cloud federation, its adoption has been
hindered by the lack of trust among its participants [6].
Trust has always been a major concern for consumers since the very beginning of cloud
computing. Consumers have always remained hesitant in adopting cloud computing due to
the loss of control over their data and application in case of such outsourced computing
paradigm [7]. However, the major orientation of this problem has been towards trust
establishment between a consumer and its service provider. In case of cloud federation,
however, it’s the participants of federation that are faced with an intrinsic apprehension of
trusting their counterparts for guaranteed service delivery. Therefore, trust establishment
among cloud providers participating in a federation has been a major motivation for this
research.
4
1.3 Problem Statement
Relationship among cross-cloud CSPs requires stringent security provisioning and
relationship management as the participating CSPs, having unique infrastructures, are not
known to each other. Moreover, the details of Quality of Service (QoS) provisioning,
security enforcements and privacy are also not known to each other [8] and this lead to the
lack of confidence among unknown CSPs. The hesitation of a CSP to contribute in CCF is
due to the concerns of security and privacy while placing its customers’ data in the premises
of other CSPs [6]. In addition to this, convincing a customer to delegate control of its data
to a federation, when a CSP is itself reluctant to join a federation is much more challenging
than conventional cloud paradigm.
Establishing trust on a CSP is of paramount importance before delegating control of user’s
data and application within a federation. This trust is mostly computed as a unique
numerical value to reflect the trustworthiness of a CSP. However, cross-cloud federation
makes the evaluation of trust more challenging due to the transitive nature of trust i.e. user’s
trust on its home CSP and home CSP’s trust on other CSPs. Existing solutions for trust and
reputation evaluation in cloud computing are suitable for establishing trust between the
user and its home CSP. However, these solutions do not cater for the specific requirements
of cloud-to-cloud trust paradigm. These requirements arise from the heterogeneous,
multilevel and dynamic nature of the cross-cloud federation and services.
Establishing trust in a cross-cloud federation requires a cloud-to-cloud trust model aligned
with the specific nature of federation. Novel methods are required to accommodate the
multilevel relationship management among CSPs. However, heterogeneous specifications
of CSPs are difficult to compare over a unique metric space before selecting the best CSPs.
Moreover, dynamic collaborations create more contract violations requiring trust
mechanisms to adapt to the evolving state of the federation. Once these mechanisms are
established, trustworthiness of a federated service can be a unique value computed on the
basis of interconnection between these CSPs.
5
1.4 Contributions
The overall objective of this thesis is to propose a brokerage model that is capable of
managing the state of affairs within a CCF in a trusted and reliable manner that is adaptive
to the changing dynamics of federation. This broker is expected to initiate and maintain
trusted relationships between cloud providers that are a part of federation. For this reason,
the broker makes use of security and performance related information regarding the cloud
providers in a standard format and process it as a function of their relationship. In order to
achieve the aforementioned objectives, this thesis has following contributions:
It highlights the necessity of trust within a federation to be addressed in a manner
different than other conventional and multi-cloud computing paradigms. A cross-
cloud trust framework has also been proposed.
A novel design of a broker that acts as a central entity in federation market place
for trusted resource exchanges is discussed.
A novel approach based on belief calculus and graph theory for evaluating fine-
grained trust of a service within federation as a function of its dependency structure
is presented.
A novel approach for coarse-grained evaluation of trust based on numerical
calculus and service dependency graph has also been proposed.
It has also introduced a risk based service selection strategy for federated clouds
based on trust and performance as a mean for decision to collaborate.
The significance of this model has been verified on Clouds4Coordination (C4C)
System developed in CometCloud federation framework for
Architecture/Engineering/Construction (AEC) industry. C4C framework has been
implemented in United Kingdom in collaboration with Cardiff University, UK and
Rutgers Discovery Informatics Institute (RDI2), USA.
Empirical evaluation of this model has signified its suitability in varying scenarios
of collaborative computing as a use case of construction industry. Trust-aware
relationships within the federation stays for longer duration of time.
6
1.5 Thesis Organization
The thesis is organized as follows:
Chapter 2 discusses the theoretical concepts necessary to develop an understanding
of trust in cross-cloud federation. This discussion differentiates the cross-cloud
federation from other architectures that are developed as a mean to enhance the
capabilities of conventional cloud computing. A brief discussion on various
theories of trust has been provided to comprehend trust from social and technical
perspective. This discussion is helpful for understanding the recent trends within
trust management. Moreover, a description of Cloud Assessment Initiative
Questionnaire (CAIQ) by Cloud Security Alliance (CSA) [9] has been included in
this chapter. CAIQ has been utilized as a data source for trust evaluation.
Chapter 3 highlights the state-of-the-art in Trust Management within the cloud
computing paradigm. Most of the literature is focused on conventional cloud
computing, in which a consumer is only interested to opt in for a service delivery
from only one cloud service provider. However, it also summarizes the recent
trends available in cloud computing landscape for trust management in multi-cloud
and federation architectures. The available literature is classified based on the
number of trust sources it uses to collect the trust indicators.
Chapter 4 presents the research methodology specifying requirements for trust in
cross-cloud federation, and a basic cloud-to-cloud trust framework. Afterwards,
this proposed framework is used to provide a quantifiable analysis of state-of-the-
art Trust Management Systems (TMSs) to identify their shortcomings. A
consolidated requirement matrix is also presented that helps to identify the trust
management areas that are needed to be aligned with the specific requirements of
trust within federation.
Chapter 5 discusses the detailed design of proposed trust-aware brokerage model
implemented as a trusted broker based C4C system. It highlights the entities, roles
and their interactions along with system workflow. Also, this chapter presents the
design of proposed broker highlighting details of its various modules and their
7
internal working. Details of proposed analytical approaches as a contribution to
resolve specific problems of trust in cross-cloud federation are also presented in
this chapter.
Chapter 6 presents the experimental validation of the proposed approaches along
with the implementation details from system setup and evaluation perspectives. The
proposed approaches have been validated against a set of CAIQ self-assessment
reports of various CSPs published in the CSA Security, Trust & Assurance Registry
(STAR) [10] and competence metrics as derived from various real world BIM
workloads.
Chapter 7 summarizes the entire thesis by deriving conclusions and future
directions for upcoming research in the domain of cross-cloud federation. It has
been highlighted that the proposed model can be enhanced in different directions,
creating many opportunities for future work.
8
Chapter 2
2 Cross-Cloud Federation and Trust: Theoretical Foundations
9
2.1 Introduction
This chapter discusses the theoretical concepts necessary to develop an understanding
of trust in cross-cloud federation. It starts with a brief description of inter-cloud and Edge
Computing (EC) model as a mean to enhance the capabilities of conventional cloud
computing. Although being an extension to the same cloud computing model, they are not
comparable as they differ in their essential characteristics. Both models address specific
shortcomings in the cloud computing model with their distinctive features. Inter-cloud
model is associated with processing huge amounts of data requiring High Performance
Computing (HPC) infrastructure with no real-time requirement. This leads to the concept
of sharing workloads and infrastructure across multiple clouds. On the other hand, Edge
Computing is mostly concerned about offering responsiveness to user for data having real-
time requirements. This leads to an idea of having ‘edge cloudlets’ in the vicinity of the
user that can act as an intermediary between user and the main cloud. Afterwards, the
discussion follows the inter-cloud model limiting the scope to cross-cloud federation. A
detailed insight into the working of cross-cloud federation and its available prototypes is
provided to differentiate it from multi-cloud architecture.
The dissimilarities between the multi-cloud and federation architectures indicates new
challenges which are significant to apprehend the motivation for this research. Trust
evaluation has already seen enormous evolution since the inception of cloud computing
due to the worries of consumer regarding loss of control over its data. However, cloud
federation architecture being entirely different from its counterparts require new trust
mechanisms to cope with the uniqueness of offered challenges. However, in order to
comprehend the evolution in trust mechanisms there is a dire need to develop a basic
understanding of concepts underlying trust management.
A brief discussion is provided to understand trust from both the social and technical
perspective and to follow the evolution of generic concepts into formal models of trust
management. An informal architecture of a Trust Management System (TMS) is provided
for elaborating the process of trust management along with the generic components
involved in trust management for cloud computing. These generic components are i) trust
sources, from where the trust indicators are collected and ii) trust methods, which act upon
10
these indicators to deliver a unique view of the system for which the trust is attributed. A
TMS must also possess few properties that usually dictates how the system behaves under
various circumstances. A detailed discussion on sources, methods and properties of a TMS
is followed by a description of CAIQ by CSA as a suggested source to utilize for this
proposed research. CAIQ is a standard three level security assessment framework that
allows the cloud providers to demonstrate their security capabilities to the consumers.
These security capabilities can also be certified by the third party auditors for level-2
certification. A continuous monitoring program is currently under progress to provide
level-3 certification.
2.2 Inter-cloud model
Cloud computing has seen enormous evolution since the time of its inception. The
standard model of cloud computing [1] in which a client uses a single distant cloud data
center, poses numerous challenges related to connectivity, availability, latency, location
jurisdiction, and integrity of data. Unavailability of cloud services due to network or data
center failure, for instance, can leave thousands of customers without access to critical
services. Recent years have seen an increased dependency on the cloud with the increasing
amounts of data being generated and uploaded by every user. Utility of this data ranges
from large-scale storage and high-performance computations to real-time decision support
systems utilizing intelligent technologies such as Internet of Things (IoT), Vehicle-to-
everything (V2X) communications and Augmented Reality (AR) etc. Therefore, it is
difficult to provide sufficient responsiveness and dependability to global customers using
a single cloud. Due to this reason, there is a need to enhance the basic model of cloud
computing for accessibility, elasticity, reliability and enhanced QoS. Cloud computing
landscape is now filled with edge computing and inter-cloud models to support a variety
of autonomous and intelligent systems according to their needs. Both these models share a
set of similarities derived from conventional cloud computing, but they are not a
replacement of each other.
The goal of edge computing is to bring the cloud in the closer proximity of a user. This can
be done by implementing a limited cloud-like functionality in the edge devices; routers,
switches, base stations etc. These mini-clouds, linked to their parent clouds, act on the data
11
generated by a user aimed for a prompt decision support e.g. in an autonomous vehicle or
healthcare. The data is aggregated, analyzed and after the decision, very less amount of
data is ultimately sent from the edge to the core network for further analysis. Currently
there are three implementations of edge computing namely i) Fog computing, ii) Mobile
Edge Computing (MEC) and iii) cloudlets [11]. A comparison of basic features of these
three implementations is given in Table 1. However, lack of standardization affects the
classification of features of each of these implementations.
Table 1: Comparison of edge computing implementations
Characteristics Mobile-Edge computing Cloudlet computing Fog computing
User type Mobile General General
Context awareness
High Low Medium
Use cases
Mobile sales transactions, location dependent queries (travel recommendations), multimedia applications on mobile devices
Local video surveillance, video caching, traffic control
IoT, connected vehicles, smart grid/smart city, health care, smart delivery (high-scale package drone delivery), real-time subsurface imaging, video surveillance
Devices Servers running in base stations
Data Center in a box Routers, Switches, Access Points, Gateways
Location Radio Network Controller/Macro Base Station
Local/Outdoor installation
Varying between End Devices and Cloud
Proximity One Hop One Hop One or Multiple Hops
Latency Local video surveillance, video caching, traffic control
Low Low
Access Mechanisms
Mobile Networks Wi-Fi Bluetooth, Wi-Fi, Mobile Networks
Internode Communication
Partial Partial Supported
Architecture Mobile Orchestrator based Cloudlet Agent based Fog Abstraction Layer based
The edge computing technologies mostly complements the IoT systems and smart devices
in terms of responsiveness in decision-making. The infrastructure or devices employed for
edge computing are not comparable to their core counterparts both in terms of functionality
12
and computational ability. Edge computing has its shortcomings for storing and computing
large scales of data originating from different scientific disciplines. For example, data
models from Architecture, Engineering and Construction (AEC) industry, Medical
Imaging (MI), Bioinformatics etc. requires high-performance computing but with no real-
time requirements. To enhance the capability of conventional cloud computing for such a
type of data, inter-cloud model has appeared as a de-facto resolution. A few seminal works
[2] state different circumstances in which the usage of multiple clouds can be taken to
advantage. Inter-cloud terminology has also been termed as “cloud of clouds” [12] and as
“Cloud Fusion” [13]. A formal definition [3] of inter-cloud model is as follows:
“A cloud model that, for the purpose of guaranteeing service quality, such
as the performance and availability of each service, allows on-demand
reassignment of resources and transfer of workload through an
interworking of cloud systems of different cloud providers based on
coordination of each consumers requirements for service quality with each
provider’s Service Level Agreements (SLA) and use of standard interface.”
The inter-cloud model facilitates consumers to engage various cloud providers for
distribution of their workloads in order to attain the benefits that include (i) Multiple
geographical locations (ii) Application resilience and (iii) Avoidance of vendor lock-in.
CSPs can also have significant incentive from participating in inter-cloud architecture e.g.
in terms of resource elasticity. Ensuring enough resources by over-provisioning at all times
for unanticipated workload spikes is always costly in terms of price and power
consumption of a data center. Keeping excessive resources in a ready state all times leads
to increased CAPEX and OPEX. Cloud providers can use the inter-cloud for on-demand
expansion and to transfer their excess workloads to other clouds when required. This can
also lead to improved SLA between customers and cloud providers as it is known that
workloads can be shifted to other clouds in case of data center outage or resource scarcity.
2.3 Inter-cloud architectural classification
Inter-cloud model can be broadly categorized into two types of architectures as i)
multi-cloud and ii) federation as shown in Figure 2. Basic differences between both the
architectures are summarized in Table 2 and are elaborated in the next subsection.
13
(a) (b)
Figure 2: Inter-cloud variants (a) multi-cloud architecture (b) federation architecture
Table 2: Differences between multi-cloud and federation
Criteria Multi-Cloud Federation
Service Providers Multiple Multiple
Portfolio Independent Collaborative Provider
Interconnection None
Static (Horizontal) Dynamic (Cross-cloud)
Service Composition Single level (i.e. customer to
CSP) Multilevel (customer to a chain of
CSPs)
Service Junction Cloud Delivery Platform (Service/Libraries)
Federation entry point (Home cloud)
Service Agreement Multiple (per cloud based) Single (Home cloud) User-Provider Relationship
Dynamic Static
Provisioning Customer or its representative
service Home cloud
Scheduling Multi-cloud API’s Transparent to user
Multi-cloud architecture
Multi-cloud architecture advocates the use of various independent CSPs to facilitate a
consumer and results in a relationship governed by individual agreements of respective
clouds. Cloud consumers can diversify their applications in terms of location and vendors
so that their businesses are more flexible to policies, availability requirements and
governance. In order to take full advantage of multiple clouds, different application
development patterns are proposed in literature for distributing resources among multiple
cloud providers [14]. These patterns can be identified as i) Replication of application ii)
Multi-tiered applications iii) Logic fragmentation and iv) Data fragmentation. These
patterns are elaborated in the Figure 3.
14
(a) (b)
(c) (d)
Figure 3: Application development patterns for multi-cloud deployments (a) replication of application (b) multi-tiered applications (c) logic fragmentation (d) data fragmentation
However, application specific requirements should not be violated when utilizing these
patterns. Appropriate methods are required for resource provisioning and scheduling that
can deal with the application requirements in terms of performance and control [3]. These
methods of application brokering usually fall in the category of architectural patterns.
Resource provisioning, scheduling, data and application security etc. are the direct
responsibility of cloud consumers or their representative service. Architectural patterns for
multi-cloud can be broadly categorized into two sets of mechanisms:
Services – Application provisioning is the responsibility of a service at the client
side. This service may be hosted within the client premises or externally. A few
prominent inter-cloud projects include OPTIMIS [15], Contrail [16], mOSAIC [17]
and STRATOS [18]. In addition to these projects, commercially available services
include RightScale [19], EnStratus [20], Scalr [21] and Kaavo [22].
15
Libraries – Most of the times, it is required to embed the brokerage functionality
into the application. Such brokers can directly manage the application provisioning
and scheduling across multiple clouds. This approach may use inter-cloud libraries
such as the LibCloud [23], JClouds [24] and DeltaCloud [25].
Federation architecture
Contrary to the multi-cloud, interconnection and sharing of infrastructures of two or
more cloud providers is called cloud federation. This concept offers the advantages such
as traffic load balancing and accommodation of unusual spikes in resource demand [26].
In cloud federation, cloud providers can lease their vacant resources to other cloud
providers such that the leased resources act as a temporary portion of buyer’s infrastructure.
Cloud federation is beneficial to cloud providers from two perspectives. Firstly, it is helpful
in generating revenue out of idle or underutilized resources. Secondly, it allows CSPs to
accommodate unusual spikes in resource demand by expanding their footprints without
making heavy investments in infrastructure. The basic idea of federation is to provide
transparent access to a number of resources and services that are distributed among
multiple independent providers. As an important aspect of federated services, customer-
facing SLA must be extended somehow to service partners. Usually, a cloud federation is
realized in the following two ways [4].
Horizontal federation – Two or more CSPs come in contract with each other for
price and usage provisions are agreed beforehand, to facilitate resource exchange
and service composition. It allows CSPs to share information related to
infrastructure, behaviour and QoS leading to better trust assessment. There is no
requirement for the discovery of resources as the relationships are static and long-
term. However, it lacks scalability and diversity in service composition for dealing
with varying demands of diverse application platforms.
Cross-cloud federation – It is realized when two or more unfamiliar CSPs come in
contract with each other at run-time [27]. It is dynamic and diverse, offering
advantage to CSPs for expanding their service footprints easily on varying
platforms. Cross-cloud federation has several phases such as discovery (searching
for candidate clouds/resources), matching (selecting the provider that closely
16
matches the requirements), authentication (a context of trust relationship
established between the selected clouds) etc.
2.4 Cross-cloud federation
In a cross-cloud federation, any event of resource lease triggered by a home CSP
with respect to a specific consumer is termed as a transaction. All further resource leases
that originate pertaining to this transaction are its sub-transactions. In a generalized
approach, any transaction (or sub-transaction) passes through several phases, starting from
the discovery of resources, matchmaking and authentication [27]. The discovery process
finds resources required by a Home CSP from foreign CSPs willing to lease their additional
resources. Discovered resources must fulfill some minimum criteria e.g. QoS parameters,
location and/or availability at any given duration of time, etc. Once a set of resources
meeting the minimum requirements are found, the best matching resource is selected and
negotiated for terms of use. The process of authentication is then carried out to establish a
relationship context between the CSPs. The basic properties of a cross-cloud federation can
be summarized as follows.
Highly dynamic structure – Relationships between CSPs are short-term and
frequently updated. The underlying structure of federation is therefore highly
dynamic.
Multilevel composite service formation – Service contracts and composition occur
in layers forming new contracts hierarchically linked to their parent contracts. A
violation of any provision in a subset of contracts may affect other dependent
services in a cascading manner such that overall service composition is affected.
Heterogeneity in service providers – Different clouds joining the federation may
have different infrastructure, security requirements and contracting languages [28,
29]. This offers the benefits of diversity and scalability in service composition.
Cross-cloud federation has its utility across a number of different application domains,
ranging from research & academia, engineering & construction, financial industry, real
time data processing and online gaming to name a few. For example, consider the case of
Massively Multiplayer Online Games (MMOGs). A large number of players across the
17
globe use these MMOGs to become a part of a huge and dynamic virtualized world.
However, due to the high workload variability with stringent QoS requirements [30],
implementation of a highly scalable MMOG service is definitely an enormous challenge.
Traditionally, aggressive over-provisioning of resources is used for MMOG services to
handle the worst-case scenarios e.g. large number of online players [31]. However, a large
portion of these resources remains unused at all times. Any typical MMOG service can
benefit from cross-cloud federation in order to alleviate the need of aggressive
overprovisioning for achieving better scalability. Such a scenario can be further elaborated
by considering a MMOG service hosted in a cloud which is a part of cross-cloud federation
made up of four CSPs as illustrated in Figure 4.
Figure 4: A cross-cloud federation supporting MMOG application
Each CSP in the federation owns a set of distinguished virtualized resources within their
infrastructure. A consumer ‘n’ (Individual / End User / Enterprise) can sign a contract SLAn
with one of the CSPs in federation against the MMOG service(s) offered by that CSP. This
SLAn containing various threshold bound parameters related to QoS e.g. maximum latency,
network availability, user limit etc., serves as a guarantee to the performance of that CSP.
This CSP now acts as a home CSP while other CSPs in federation are foreign CSPs with
respect to that consumer. Among all CSPs in the federation, the only entity bound to
18
provide a guaranteed gaming experience to user is the home CSP. No foreign CSP in the
federation is bounded to provide direct service delivery to the consumer and hence not
accountable to the consumer.
In Figure 4, the home CSP is unable to provide a guaranteed MMOG service delivery to
the End User with SLA1 at any point in time ‘t’ due to resource scarcity. For this reason, it
must lease resources from its federated peers after signing a SLA with them. This SLA
must be a subset of the contract signed between home CSP and End User [6, 27]. In this
illustration, the home CSP has leased resources from foreign CSPs A and B, after signing
sub-contracts named as ‘SLA1-a’ and ‘SLA1-b’ with CSP A and B respectively. Both CSPs A
and B are now legally bound to provide the contracted resources to the requester CSP A
not violating the parameter thresholds mentioned in ‘SLA1-a’ and ‘SLA1-b’ for an upright
performance. Further at any point in time “tn+1” to maintain the service delivery parameters
mentioned in the ‘SLA1-b’, foreign CSP B can feel the need to lease a set of resources from
CSP C. Another SLA will be signed between B and C as ‘SLA1-b-c’ being a subset of the
‘SLA1-b’ thus forming a hierarchy of service contracts within the federation.
Fundamental concepts
Following the illustration in Figure 4, three fundamental concepts that are primary to
develop a comprehensive understanding of the CCF are identified. First of them is
‘Federated resource’ that describes how resource leasing or borrowing takes place between
CSPs. The second one is ‘Federation visibility’ that defines how a federation is perceived
by different actors within the CCF. The third one is the ‘Federation management’ that
discusses the architectural choices for all underlying mechanisms within the federation.
Details of these concepts are as follows.
Federated resource – Cross-cloud federation presents a complex scenario of
sharing resources at each layer of the cloud service model [5, 32]. A federated
resource is the type of resource [4] leased in any transaction. This concept relates
to the formation of composite services from different CSPs. Figure 5 illustrates the
concept of inter-layer and intra-layer resource federation [5] between a home CSP
and a foreign CSP. Both CSPs have the same software or application layer (SaaS)
at the top, the middleware layer (PaaS), and the OS and infrastructure layer (IaaS)
19
at the bottom. At the home CSP, a service e.g. an application request is bound to be
fulfilled as long as it is within SLA limits. Users access the application layer of the
home cloud, which evaluates the abundance of local resources to serve the requests.
If the application layer is unable to serve the request as per SLA, it forwards the
request to the foreign CSP hosting the same service. This phenomenon is indicated
by a horizontal line from home cloud to foreign cloud in Figure 5 and is called
Intra-layer federation.
Figure 5: Inter-layer and Intra-layer resource federation
Federating services at other layers of cloud service model i.e. PaaS and IaaS,
follows the same method of Intra-layer federation. However, in a case when the
foreign cloud does not host the same application, the request can be delegated to
the lower layers. For instance, the SaaS layer can forward the request to the PaaS
layer, which means provisioning of necessary platform software to host the
application. Similarly, if that is not feasible, the PaaS layer can send a request to
the IaaS layer to deliver virtual machines so that necessary platform software can
be installed. This concept is known as Inter-layer federation.
Federation visibility – A very important concept at the core of cross-cloud
federation is Federation Visibility. Different actors in the federation may have
different perspective of the federation. For example, an end user has a limited
visibility level which means that they can access and visualize the cloud federation
as a single entity. Different levels of federation visibility are as follows.
o End user – has a limited visibility level just to access and utilize services.
20
o Enterprise – obtain resources and services from the cloud and offer them to end users in a transparent way.
o Developers – their visibility is restricted to the APIs provided by their home CSP.
o Cloud Service Providers – they have complete visibility of the federation to which they are a part. However, CSPs may or may not share details regarding their internal infrastructures.
Federation management – The entire process of resource leasing can either use
P2P [27] or centralized [33] mechanism for discovery and shortlisting of resources
before finalizing a resource exchange. Hence from an architectural perspective, a
federation can be managed in either of these two ways [3] i.e. Peer-to-Peer (P2P)
or centralized. In P2P mechanisms, clouds communicate, negotiate and exchange
resources with each other using their inbuilt agents and without any third party
involvement. The basic problems of discovering and exchanging resources may be
solved using the concept of ‘presence’ from Session Initiation Protocol (SIP),
Instant Messaging and Presence Service (IMPS) and the Extensible Messaging and
Presence Protocol (XMPP) as suggested by Celesti et al. [27]. However,
establishing a trust context between peers may require a centralized trusted Identity
Providers (IdPs) to facilitate authentication.
In centralized federation, a central entity such as a broker is responsible to facilitate
resource exchanges among CSPs. This entity operates as a repository to keep an
inventory of available cloud providers’ resources. A traditional cloud broker as
defined by National Institute of Standards and Technology (NIST) [1] is “an entity
that manages the use, performance and delivery of cloud services” by negotiating
a relation among CSPs and customers. Previous research on conventional cloud
computing has strongly advocated the use of a cloud broker following the same
explanation [33-35].
However, this description of a broker requires reconsideration with the advent of
cloud federation and its increased adoption by service providers for enabling
composite services [34]. Recent work emphasizing the necessity of brokerage for
cloud federation includes a comparison of brokerage frameworks by Villari et al.
21
[4], a collaboration framework for federation by Demchenko et al. [35] and inter-
layer federation architecture [5] along with a survey of federation challenges by
Toosi et al. [8]. The utility of brokerage in cloud federation has been well
established in works by Buyya et al. [2, 36] and Abdo et al. [33].
Inter-cloud initiatives
The recent research initiatives for inter-cloud paradigm with a review of their
respective problem domain are discussed in this section. Various centralized and
distributed architectures for multi-cloud and federated clouds exist in literature with a very
few initiatives focusing on the entire paradigm of inter-cloud architecture. An overview of
recent advancements in inter-cloud initiatives has been given in Table 3.
The InterCloud [2] project at University of Melbourne comprises of a centralized Cloud
Exchange (CEx) that act like a marketplace. A CSP can become a part of this marketplace
to sell its resources to other CSPs or application brokers by installing Cloud Coordinator
(CC) agent. The CCs of the participating CSPs periodically update details of their resources
in the information registry within CEx. Brokering in this model is either SLA based or
directly managed. Using the SLA approach, a cloud provider negotiates on behalf of the
client, whereas in directly managed brokering, clients acquire resources from CEx directly.
Dynamic Cloud Collaboration (DCC) [37] for centralized federation has proposed a
primary cloud provider (pCP) that acts as the central entity to facilitate the federation. This
pCP is the first CSP in the federation that initiates its formation. The other CSPs that join
later are called the collaborating clouds. A repository of all services within the federation
is maintained by pCP which supports SLA based application brokering. Users of this
federation send their requests to pCP that allocates resources from the federation. However,
it is unclear from the description of this proposed work whether clients can state
requirements regarding their choice of location for the allocated resources. Moreover, this
work is extended in [38] to facilitate a marketplace in which resources are auctioned for
exchange.
A model to facilitate cloud resource federation at IaaS layer is presented as Federated Cloud
Management (FCM) [39]. The proposed model depends on an FCM repository which
stores virtual appliances of all services in federation. These appliances are then replicated
22
to all IaaS providers in federation. Client only interacts with Generic Meta-Broker Service
(GMBS) by defining the parameters of required service. After defining the parameters, the
provisioning and scheduling of resources are transparent to the client. Each IaaS provider
involved in this federation has a respective broker called CloudBroker which manages the
allocation and de-allocation of Virtual Machines (VMs). Application calls from different
users are then forwarded to suitable VMs. Whenever a user’s request is received at GMBS;
it assigns this request to a suitable CloudBroker. This assignment relies on information
retrieved from FCM repository and on the real-time metrics from the CloudBrokers.
Kecskemeti et. al. has extended this FCM scheme to perform self-adaptable management
of the federation [40]. Their basic aim is to achieve resource optimization with no violation
of the SLAs. However, this scheme does not optimize cost for all clients of federation.
Contrary to the mentioned works for centralized federation, the authors in [27] present a
P2P architecture for federation establishment. They highlight the necessity of cloud
federation and propose enhancements to cloud architecture for cross-cloud federation
paradigm. They propose a Cross-cloud Federation Manager (CCFM) as a middleware
which facilitates a CSP to set up a federation with other CSPs using a three-phased
approach of discovery, match-making and authentication. They recommend using P2P
mechanism for discovery of resources and feedback based reputation system for
categorizing the resources.
However, Abdo et. al. introduces a cloud broker to enhance the CCFM architecture [33].
They establish that a central entity should be present for discovery and matchmaking of
best fit resources within a cross-cloud federation. They justify their proposal by
implementing a centralized broker enhancing the performance and limiting overhead of the
CCFM. A business model for adoption of broker is also presented as a viable option for
cloud providers.
Authors in [41] analyze the feasibility and performance of an Autonomic Cloud Broker
(ACB) in live data center environment forming a federated cloud scenario. They compare
centralized and distributed schemes for hybrid cloud federation in live environment
constituting multiple data centers in India. It is verified that utilizing an ACB in federated
environment is a viable approach. The centralized scheme of federated hybrid clouds is
23
then implemented in [34] with a broker acting as central entity. Their proposed broker is
responsible for resource provisioning, migration decision making and for establishing a
federation wide SLA management.
A European project named RESERVOIR [26] extends an ongoing research for
interconnected grids. It has a P2P architecture which the CSPs can negotiate with each
other for exchanging resources. Multiple clouds are used by employing an abstract layer
name Claudia which acts as a mediator for executing services within the cloud federation.
Application developers specify their scalability requirements which are then fulfilled by
performance parameters of the SLA specification.
Another European project Contrail [16] uses a centralized entity acting as an entry point to
the federation. Its responsibilities include periodic monitoring of the CSPs’ states and
construction of a homogenous SLA across entire federation. User’s requests are mapped to
the required resources using a dedicated component called Federation Runtime Manager
(FRM). A detailed application specific SLA is required for application brokering. This
SLA is then used by FRM module to provision resources for minimization of the costs.
Table 3: Overview of recent advancements in inter-cloud initiatives
In [35] the authors present an Inter-Cloud Federation Framework for interoperability
among cloud providers as a part of Inter-Cloud Architecture Framework (ICAF). Their
work is an excellent attempt to establish fine grained requirements for cloud federation and
Referenced research
Categorization
Centralized Decentralized Trust
Aware SLA
Aware Cross-cloud
Support [2] - - -
[27] - -
[33] - -
[34] - - -
[35] - -
[42] -
[37] - - -
[39] - - -
[41] - -
[26] - - -
[16] - - -
24
its components. Their subjective discussion on the subject involves the requirement of trust
and reputation assessment of cloud providers in federation. However, they have not
discussed the specific scenario of cross-cloud federation and its challenges in trusted
resource exchange.
CometCloud [42] is another federation framework by Rutgers Discovery Informatics
Institute (RDI2). CometCloud is based on a decentralized coordination space, and supports
highly heterogeneous and dynamic cloud/grid infrastructures, integration of public/private
clouds and cloudbursts. This coordination space is also used to support a decentralized and
scalable task space that coordinates the scheduling of multiple tasks submitted by a
dynamic set of users. These tasks are performed by dynamically provisioned agents. These
agents known as “workers” may be available in private and/or public cloud resources based
on the QoS constraints of the current task. These QoS constraints along with policies,
performance history and the state of resources are used to determine the appropriate size
and mix of the public and private clouds that should be allocated to a specific application
request. The goal of CometCloud is to enable a virtual computational cloud that integrates
local computational environments (datacenters) and/or public cloud services on-the-fly and
provides a scheduling agent to manage cloud federation.
2.5 Trust management overview - Social perspective
Trust is a complex social phenomenon and is a critical factor of everyday life. Detailed
explanation and semantics of trust have always been investigated in conjunction with the
context in which the trust phenomenon is being applied [43, 44]. There has been some
significant definitions of trust, mostly in context of Sociology [45-48] and a few in terms
of Philosophy [49], Economics [50], Psychology [51, 52] and organizational management
[53]. The following section delivers a brief overview of trust from perspective of social
psychology, philosophy, and economics before moving to its technical perspective.
Trust in social psychology
Trusting behavior in social psychology implies allowing oneself to be in a potentially
vulnerable position relative to another person, while possessing some knowledge of the
other that inspires trust in his goodwill, i.e. in his good intentions [47]. Thus risk and some
information about the potentially trusted person or situation are seen as necessary
25
conditions for trust to exist. Most researchers see trust as a function of imperfect
information [54]. Granovetter [55] states "the person who knows completely need not
trust; while the person who knows nothing, can on no rational grounds afford even
confidence". Thus in total ignorance it is possible only to have faith and/or gamble. Again
under perfect information, there is no trust but merely rational calculation.
Many of the psychologists define trust as a personal trait [56, 57], while others as in [58]
stress its social aspects. Jack R. Gibb, a psychologist and clinician, has presented a trust
level theory [59]. According to this theory trust level is the central variable determining
the interaction of the processes and the resulting effectiveness of the systems. Gibb finds
that trust is instinctive, unstrategized and, as a feeling, is close to love. The reciprocal and
self-enforcing nature of trust is generally noted; trust tends to evoke trust, and distrust
evokes distrust. Also, as trust erodes, the things causing distrust might first be considered
as accidental incidents, but after repeated evidence of intentionality distrust takes over [60,
61]. Trust is usually seen as situation-specific [62]. Moorman et al. make a very important
point when they note that both belief and behavioral intention must be present for trust to
exist [63]. Trust is limited, if one only believes in the trustworthiness of the other, without
being willing to rely on it. Also, if one is willing to rely on another party without believing
in that person's trustworthiness, then this reliance may be more a function of power and
control than of trust.
Trust in philosophy
Great philosophers Plato and Aristotle have only indirectly implied trust while
discussing cooperation and friendship and the virtues of the human being [64, 65]. Usually
moral philosophers see trust as good, and the disappointment of known trust as always
wrong [64]. Philosophers see trust in a variety of forms and versions: it can be unconscious,
unwanted or forced, or it may be trust of which the trusted is unaware [64]. It may be a
question of encounters between strangers, or of long-term trusting relationships. According
to Hobbes as quoted in [66] a trusting person would not set up any safeguards. Philosophers
emphasize the trusting attitude, often unconscious, as being part of a basic conduct of life.
Reliance is seen as a narrower concept; somebody might be relied upon in certain respects.
26
Reliance is therefore also viewed as an outcome of grounded expectations, and as separate
from trust.
Trust in economics
Economists have not traditionally paid much attention to the role of trust in market
exchange [67]. The neo-classical ideal market, with perfect information and pure
competition between independent and faceless traders, does not involve trust as a central
concept, since the competitive market is supposed to control any deception. Also, rational
choice theory excludes differences among actors, which means that no one of them is more,
or less, trustworthy than the others [68]. That is to say, if the actors were all perfectly
honest, doing their best to fulfill their commitments, then there would be no problem of
trust.
The shift in focus towards imperfectly competitive markets in which a small number of
traders build long-term relationships and make relation-specific investments, has drawn
attention to this issue. Those economists who do see the notion of trust as relevant and
useful, regard it as mutual confidence, "implicit contracting," where by an individual or
firm trusts a second individual or firm to do what it has promised to do [61]. Economists
believe that repeated games such as the Prisoner's Dilemma [69] have demonstrated the
effects of learning, communication and the "shadow-of-the-future" (the existence of
potential future transactions); the participants will cooperate when it pays them to do so,
i.e. if it is rational. Trust is then seen as a response to expected future behavior. It is advised,
however, that credible commitments, self-enforcing agreements and reservations ensure
rational behavior of the actors who are regarded by mainstream economists as opportunists
(i.e. seeking self-interest with guile) by nature. According to some economists trust is an
"externality", a good or commodity with real economic value, which increases efficiency,
but not a commodity which can be traded on the open market [61].
2.6 Trust management overview - Technical context
From a consolidated view point gathered from various definitions, trust can be a factor
of i) expectation – A specific behavior is expected from the trustee, ii) Belief - The expected
behavior will occur, as evident from the trustee’s performances. iii) Risk - The belief is
worth taking a risk. Trust in an entity has always been considered a measure of assessment
27
to act as a base of decision-making as to what extent the entity will behave as expected.
Considering the technical context, trust realization approaches can be categorized into three
schools of thought as i) Trusted Computing or “hard trust”, ii) Application oriented or
“explicit trust” and iii) Trust Management Systems (TMS) or “soft trust” approaches.
Hard trust
In this approach, service platforms are considered as ‘trusted’ if they have a provable
existence of certain security primitives. Trusted Computing allows customer to verify that
CSPs do not tamper with VMs. These approaches rely on a Trusted Third Party (TTP) for
implementing a hardware based Trusted Platform Module (TPM) within the computing
infrastructure of service providers [70]. However, as the original TPMs are developed for
the physical hardware, their applicability to virtual environment is challenging. This
shortcoming is overcome by developing virtualized TPM specifications (vTPMs) [71].
These can be implemented as software based TPMs for each VM running with the CSP.
Recent works by Santos et.al [72], Krautheim [73], Schiffman et al. [74] and Sadeghi [75]
are representative of hard trust approaches. However, in general, hard trust approaches
focus on the evaluation of an individual platform, and therefore are not applicable on
composition of multiple providers [76]. Moreover, many obscurities arise due to the nature
of these approaches that can only be addressed by using dynamic trust models [77].
Explicit trust
This approach implements the protection mechanisms on the end user platform. This
ensures that user information is submitted to the service provider in such a manner that
creates obscurity. These approaches utilize cryptographic techniques as their underlying
mechanisms and are as follows.
Secure multi-party computation is one of the mostly used mechanisms in
cryptographic protocols. The Sharemind system is a good practical example using
this technique [78].
Fully homomorphic encryption [79, 80] is a recent technique which enables
arithmetic operations on the data that is encrypted using any cryptographic method.
The outcome from any such operation is obtained only when the result is decrypted.
28
Mowbray et al. [81] provide a scheme for ensuring privacy in the cloud by
obfuscating sensitive data.
Data splitting is another ‘explicit trust’ approach however it is not based on
cryptographic mechanisms. The basic idea is to split data before submitting to
different CSPs. Recent works for explicit trust includes RAIN by Jaatun et al. [82,
83], HAIL [84] and RACS [85] etc.
Soft trust
The soft trust approach involves aspects such as basic social sentiments, perceptions
and interaction experiences of human beings. This approach is based on the assumption
that hard trust or explicit trust mechanisms are never perfect [86]. Recent surveys [6, 86]
show that all schools of thought may have their own strong points for establishing trust on
cloud providers. However, employing a trust mechanism other than soft trust in a large-
scale cloud computing infrastructure is infeasible due to their computational intensiveness
[6]. Moreover, both the hard and explicit trust mechanisms enable to establish trust on a
single platform, but not on the composition of entities [76] such as a federation.
2.7 Trust management systems
In the context of distributed and multi-agent systems, the concept of trust is mostly
bound to “performance”, “security” and “privacy”. These factors are represented in the
form of trust models focusing on the formal definitions, semantics and modeling of trust.
Trust modeling in distributed systems has its roots in the seminal works by Zadeh [87, 88],
Dampster & Shafer [89], Marsh [90, 91] and Josang [92, 93].
The most significant of these works for trust modeling has been presented by Marsh [90].
He proposed a formal treatment of trust evaluation by integrating different trust concepts
from sociology, social psychology and philosophy. Recently, context dependent
implementation of trust models is observed in different types of distributed systems leading
its way to the emergence of TMS. These systems have been observed in many
environments including ad-hoc networks [94], multi-agent systems [95, 96], intrusion
detection systems [97, 98] and wireless communication [99, 100]. Moreover, TMS usage
has been reported in social networking [101], e-Market places [102-104] and semantic web
29
[105-107]. Similarly, trust management has been necessitated in earlier works for
conventional cloud computing [86, 108-110], multi-cloud [111] and federated cloud
architectures [6].
Figure 6: A block representation of trust management system functionality
In general, a TMS seeks to deliver a trust assessment as a representative view of the overall
confidence in the ability of a system. Figure 6 shows a block representation of a TMS
functionality involving entities of cloud consumer, cloud service provider and trust
management authority responsible for governing the overall system environment. A TMS
is basically built on two fundamental components namely trust sources and trust methods.
Trust sources include but may not be limited to certified assessments, policy matters, SLAs,
recommendations, audit reports or third party monitoring etc. Trust indicators from these
sources are passed to the second component referred in the following sections as trust
methods. Trust indicators are collected, aggregated and evaluated based on formal models
of trust assessment within the trust method component. Afterwards, the evaluated result of
overall assessment of entity is disseminated for use, comparison and update within the
infrastructure [112, 113]. The overall functionality of the TMS and its underlying
components is governed by a set of properties discussed in the next subsection.
30
Trust sources
Sources of soft trust are the origins of trust values based on human behavior,
perception and interaction experiences with the system. In this section, trust sources are
classified into three categories based on their type of trust indications. From the following
discussion, it can be concluded that trust decision based on individual source may address
one aspect of the trust but not others. Therefore, a viable solution may be to implement all
kinds of trust sources in the TMS to facilitate better trust decisions.
Recommendation as a source – Recommendation is the most widely used source
of trust in the grid [114], service oriented environment [115, 116] and also in cloud
environment [73, 113]. Recommendations are of two types, namely i) explicit
recommendation and ii) transitive recommendation. Explicit recommendation is
the one that is provided to a cloud consumer by a close and trusted relation (e.g.,
friends) about personal experience. It is also known as first hand recommendation.
On the other hand, transitive recommendation is the one that is received by cloud
consumer from its trusted relationship, but not related to a personal experience. This
recommendation is received by the recommender from some other trusted source.
In the cloud federation model utilizing composite services, users are least
concerned for providing feedback regarding participants of such a service. Contrary
to this, the cloud providers that are leasing/borrowing resources from others must
be the primary source of recommendation based trust within the federation. This is
one of the key differences that makes the problem of trust awareness in federation
unique as compared to conventional or multi-cloud models.
Policy as a source of trust – Policy as a trust indicator is another way for trust
establishment among various parties. Mostly it has been used in grid computing
[117], P2P systems [118], web based applications [119], Service Oriented
Architectures (SOA) [120, 121] and in cloud environments [72, 122, 123]. This
approach utilizes the SLA signed between the user and the CSP for security
assurance and trust establishment. This SLA may include maximum latency,
maximum connected users, etc. related to QoS [124-126]. A major issue with the
SLA is that it ignores essential elements of security and privacy. However, a new
31
trend to include security provisions or Quality of Protection (QoP) attributes [127]
of encryption algorithm, key length etc. as a part of this contract is prevalent and is
known as Security Level Agreement (SecLA). However, there has always been an
uncertainty regarding the conduct of a CSP for keeping up with its SLA [128].
In case of cloud federation, an SLA-bound transaction between a consumer and its
home CSP may result in multiple sub-transactions. Therefore, a hierarchy of SLAs
may be signed between the participants of the federation keeping in view the
consumer SLA. There are two challenges associated with this hierarchy of SLAs as
far as their usability for trust evaluation within federation is concerned. The first
challenge is to represent and deliver the SLAs of sub-transactions as a subset of the
SLAs of parent transactions. The superset of these sub-SLAs must be the SLA
signed between the consumer and the CSP. The second challenge is related to
heterogeneity in contracting languages of CSPs. Thus the evaluation of these multi-
level SLAs requires some mechanisms of homogenous SLA formalization [129].
This is one of the major challenges of cross-cloud federation.
Evidence as a source of trust – The terms and conditions as mentioned in the service
contract serve the basis to measure the performance and security strength of a CSP
and estimate the level of variation from the defined thresholds. These performance
evidences may be used as a source of trust within the TMS [130, 131]. However, a
major issue with utilizing evidence as a trust source is the lack of cloud users’
capability to monitor QoS parameters and verify SLA in a fine-grained manner
[131]. Therefore, a trusted third party offering these services is mandatory for the
cloud users to collect evidence. In case of private cloud, its own trust authority may
perform this task. In public clouds, users and small organizations may utilize a
commercially available entity to serve as a trust broker [132, 133]. Such a
monitoring from third party agents, brokers and auditors, etc. serve as an elevated
level of confidence in the users.
Attribute assessment as a trust source – Assessment of attributes and functionalities
offered by a CSP is a popular trend in cloud computing. Such attributes may contain
logical controls that reflect the capabilities and competencies of cloud providers.
32
However, the sources of attribute assessment must be trustworthy. A few of these
sources include the service provider itself, cloud auditor or accreditor, and cloud
broker etc. In case of self-assessment of cloud provider such an assessment may be
compromised by dishonesty. A transparent mechanism is the formal accreditation
of a CSP from a trusted independent authority or cloud auditor. A cloud auditor’s
assessment is usually regarded as a reliable information source for trust judgment
and is necessary for a healthy cloud market [134]. The Cloud Security Alliance
(CSA) has proposed a detailed and transparent attribute assessment mechanism
called the Consensus Assessment Initiative Questionnaire (CAIQ). This CAIQ is a
part of “Security, Trust & Assurance Registry (STAR)” program [10]. An efficient
trust evaluation mechanism must rely on more than one source of trust information
for precise decision making [134]. However, trust evaluation based on policy
verification and recommendation is not suitable for the federation with
heterogeneity in its participants’ infrastructures, services, and contracting
languages. Trust based on attribute assessment is most suitable for a CCF as
participating CSPs can be assessed over homogenous feature space.
Trust methods
Trust methods are a collection of different operations and functions that are performed
within a TMS to generate a comprehensive representation of the system’s trust. As shown
in Figure 6, the basic function of any TMS is to collect raw input in the form of trust
indications from different sources and convert them into a representable form. Afterwards
information from all sources is aggregated before making them available to the trust
evaluation function. This trust evaluation function evaluates the resultant trustworthiness
of the system based on formal trust models. This evaluation operation can be from one of
two categories i.e. static or dynamic. Static approach is a simple mathematical operation
that does not cater for the evolving nature of the underlying system. However, the dynamic
or adaptive operation involves a trust update function that allows the trust decisions to
evolve with the nature of system. In case of highly dynamic nature of cross-cloud
federation, adaptive approaches are highly recommended as federation participants can join
or leave at any time.
33
The output of the trust evaluation function is often a numerical representation showing
confidence in the provider. This result or trust assessment is then distributed or
disseminated to the trust requester or the entire system. This assessment of a provider
serves as a utility to the consumer and mode of governance to the authority within the
system. A consumer can utilize this assessment for making decision regarding service
selection. After service contracts, a consumer acts as a source of trust of indicator by
providing recommendation for the contracted service. This recommendation is again an
input to the trust evaluation function, which may further be utilized to update the trust
decisions regarding the same provider.
This trust assessment may serve as an input to the governance domain of any authority
regulating the entire system. This authority may be a consumer itself or any Trusted Third
Party (TTP) such as brokers, accreditors, auditors or certification authorities. The objective
of such authority is to monitor and audit the providers for compliance with the policy
requirements established with the consumer. This compliance check serves as a source of
evidence to help in reporting the overall performance of the cloud provider to the TMS.
Properties of trust management systems
The overall functionality of a generic TMS is governed by a set of properties. These
properties define the behavior of underlying components of any TMS. These properties are
described as follows.
Objective – The basic objective of the TMS is to provide the consumer with a
unique value reflective of the behavior of the service provider. This unique value
may represent the trust, reputation or both regarding a service provider. Trust and
reputation are different, but related terminologies. Trust is always context based
and is held as a relationship goal between the two entities. However, reputation is
the accumulated public belief towards an entity. Trust and reputation go hand-in-
hand with each other, however, few systems only account for both trust and
reputation. The more is the dynamic nature of cloud services the more is the
requirement for encompassing both in the system.
Context – Currently TMS mainly focus on the cloud customer’s perspective i.e.
user-to-cloud trust paradigm. However, federation architecture implies a cloud-to-
34
cloud trust paradigm. It is therefore essential to differentiate a TMS based on
supported perspective.
Visibility – In a multi-stakeholder collaboration environment such as the cross-
cloud federation, trust plays a somewhat different role. It is considered to facilitate
cooperation, to render more robust collaboration, to boost performance and to make
innovations possible. This is only possible when trust decisions are openly visible
within the environment in the local and global perspective. Such an openness is
necessary so that a trusted party must not unilaterally delegate the assigned task to
other CSPs without apprising others concerned.
Security – A TMS must resist against malicious attacks and mischievous behaviors
of both insiders and outsiders [135]. Potential attacks against the TMS include the
whitewashing attack [136], self-promoting [137], and slandering attack [138]. A
TMS lacking security mechanisms is easily penetrable and can be manipulated by
an attacker. In case of federation, the attackers are most likely among the competing
peers and more resourceful than an outside attacker.
Accuracy – A TMS, by virtue of its trust evaluation function, must be accurate in
computing the trust values. Accuracy can be determined by the ability of the
function to disqualify malicious or illegitimate sources of trust indicators such as
identification of legitimate feedback sources etc.
Privacy – A TMS must ensure to limit the degree of private and sensitive
information of cloud consumer that might be disclosed intentionally or
unintentionally during interactions. For example, a privacy breach of a higher
degree exposing the cloud service consumers' user names, passwords and dates of
birth etc. is as harmful as behavioral information i.e. consumer and service
interaction patterns, interests etc. In case of cross-cloud federation, this risk is even
higher when the trust management system is supporting clouds that are competing
peers.
Control – Trust dissemination and control requires mechanisms of monitoring,
audit and enforcement of policies for compliance. The attributes that constitute the
35
foundation of trust plays an important role in cloud service monitoring. These
attributes can be used to check that a provider behaves as expected. The TMS uses
the conclusion drawn from this observation to revise the trust of the provider in
question. The third-party based TMS systems are far better than their P2P
counterparts [33, 34] in terms of reliability, performance and enforcement.
Scope – A comprehensive system must provide fine-grained level of applicability.
In this work, three different levels of TMS aimed at cross-cloud federation are
anticipated. The highest view is that of cloud level, that means a cloud is considered
as a single entity and its trust and reputation is evaluated. The second level is that
of service level, i.e. IaaS, PaaS, SaaS offered by the provider. The third level is the
resource level, with each resource having its separate trust level. A TMS can offer
authentic and reliable trust decisions only when it has a detailed applicability.
2.8 CSA STAR program
CSA STAR is a three level program with a free publicly accessible STAR registry. As
depicted in Figure 7, level one of STAR allows CSPs to publish self-assessments of their
security controls, in a “Consensus Assessments Initiative Questionnaire (CAIQ)” which is
built upon the Cloud Control Matrix (CCM) framework.
Figure 7: CSA STAR program assessment and certifications [136]
At level two, an independent third party audit is made for CAIQ attestation and
certification of the cloud provider. A mechanism for continuous monitoring based
36
certification at level three is currently under development [10]. CSA STAR Continuous
Monitoring enables automation of the current security practices of cloud providers.
Providers publish their security practices according to CSA formatting and specifications,
customers and tool vendors can retrieve and present this information in a variety of
contexts.
Cloud Control Matrix
The CSA Cloud Control Matrix (CCM) provides a control framework that gives
detailed understanding of security concepts and principles that are aligned with the CSA
guidance in sixteen domains. The foundations of the CCM rest on its customized
relationship with other industry accepted security standards, regulations, and controls
frameworks such as the ISO 27001/27002, ISACA COBIT, PCI, NIST, Jericho Forum and
NERC CIP and augments or provides internal control direction for service organization
control reports attestations provided by cloud providers. As a framework, the CSA CCM
provides organizations with the needed structure, detail and clarity relating to information
security tailored to the cloud industry.
Consensus Assessment Initiative Questionnaire
Based upon the CCM, the CAIQ offers a method to assess the competencies and
capabilities of CSPs for different attributes i.e., compliance, governance, security etc.
CAIQ can be used by cloud providers to outline their security capabilities to customers,
publicly or privately, in a standardized way using the terms and descriptions considered as
a best practice by the CSA. The assessment is categorized by the control groups, and then
mapped to major compliance and regulatory standards [10]. Using the information and
conversational control assertions from the CAIQ, an organization can build a robust
Request for Proposal (RFP).
2.9 Summary
This chapter has outlined various fundamental concepts regarding trust management
in cross-cloud federation. Inter-cloud model and its architectures are discussed as a
revolutionary approach to enhance the capabilities of conventional cloud model. Various
key features of cross-cloud federation are highlighted to distinguish the same from multi-
37
cloud and horizontal federation. This chapter has also discussed various mechanisms of
achieving trust and have highlighted the utility of attribute assessment as the most feasible
trust source for cross-cloud federation.
38
Chapter 3
3 Recent Trends in Trust Management
39
3.1 Introduction
Trust management in cloud computing has seen enormous development in the past
few years due to increase in the amount of data shared with the cloud. Recent advancements
in trust management offers a range of literature from conceptual and theoretical
frameworks to complex formal models. Most of this literature is focused on conventional
cloud computing in which a consumer is only interested to opt for a service delivery from
only one cloud service provider. In such a case, the consumer is interested in having a
knowledge about the trustworthy provider among them. A recent research trend focuses on
inter-cloud computing model. A significant amount of work has been done on trust
modeling in inter-cloud model, however, most of it focuses on multi-cloud architecture.
The remaining work in inter-cloud trust incorrectly attribute it to cloud federation without
investigating the core differences between multi-cloud and federation architectures.
The concept of trust establishment in multi-cloud architecture is mostly the same as that of
conventional cloud computing. The fact is, that multi-cloud architecture shares many
similarities with conventional cloud computing regarding trust evaluation. Firstly, in both
architectures, the focus of trust evaluation is to facilitate the consumer for the selection of
trustworthy home CSP. Moreover, trust models in both architectures deal with individual
CSPs to form a single level and direct relationship with the consumer. In any case, selection
of one or more than one CSP requires the same underlying trust management techniques.
Hence, the trust models employed in conventional cloud computing are applicable in multi-
cloud architectures with little or no modification and vice versa. However, the case for trust
management in cross-cloud federation is unique due to its properties discussed in the
section 2.4.
Keeping in view this discussion, this chapter aims to summarize the recent literature
available in cloud computing for trust management in conventional, multi-cloud and
federation architectures. However, in order to follow the evolution of trust modeling and
to identify the trends, it is necessary to classify the current literature based on parameters
other than the type of the architecture. For this reason, the literature is classified based on
the number of trust sources used to collect the trust indicators. Two major categories are
identified as i) Single sourced trust models and ii) Multi-sourced trust models. Single
40
source based models are those that utilize any one of the sources of trust, whereas the multi-
sourced trust models utilize more than one trust source. Mostly, it has been observed that
the policy and recommendation based trust is often complemented by the supportive
evidence and that too is gathered by a third party overlooking the entire process on behalf
of the user. Afterwards, a review of trust models currently available for federation is
provided to highlight the lack of contribution to this significant domain.
3.2 Single sourced trust models
Models using policy as a source of trust
Trust establishment can be based on audit assessment and accountability of the CSP
as proposed in TrustCloud framework [139]. The authors outline the risks arising due to
the absence of accountability in cloud systems. Detective mechanisms are recommended
instead of their preventive counterparts to increase accountability. The authors introduce
the concept of file-centric activity logging complementing the traditional method of
system-centric activity logging. They have based their theory on the fact that now-a-days
end-users are less concerned about the clouds’ performance and they focus more on
integrity and accountability of their data. Using concepts from Cloud Accountability Life
Cycle (CALC) and the abstraction layers of logs, both real-time and post-mortem
approaches are equally important at different levels of granularity. A consolidated view is
offered to the cloud users regarding accountability of the CSP, thus reducing the
complexity of the task. However, the authors have not mentioned any method to evaluate
trust on the basis of logs and auditability. Moreover, no methods have been outlined to
propagate this audit and accountability information to other users or providers.
Trustworthiness of a CSP can also be evaluated using different QoS parameters as
identified in [140]. These parameters are given a quantitative value based on the policies
of the consumer i.e. the signed SLA but are then normalized to fall within range of [0, 1].
Afterwards, the consumer assigns weights to these parameters and trust is evaluated as the
weighted average. The weight assignment method is subjective in nature and hence the
overall trust evaluation lack adaptability. The proposed trust evaluation framework
facilitates the consumer to use the services of a third party agent or evaluator for assessment
of SLA parameters. However, this framework is performance centric basing the trust
41
evaluation entirely on QoS parameters and neglecting the scrutiny of security features for
any CSP.
In another work, Habib et al. [141] suggested a framework for trust-awareness centered on
the notion of verifying security controls keeping in view the user requirements. The authors
utilize the concept of trust properties as defined by CSA self-assessment framework. The
framework resolves the issues arising due to heterogeneity of cloud providers, thus
providing a standard uniform trust metrics for all. The proposed work uses the mechanism
of hybrid trust in which two types of trust mechanisms are used i.e. hard and soft trust.
Both mechanisms are combined for verifying the trust attributes of the given CSP. Hard
trust is based on the security mechanisms within the CSP infrastructure. On the other hand,
soft trust is an outcome of previous experiences and performance feedbacks related to any
entity provided by the consumer. Moreover, a decision model is suggested to facilitate
users to establish trustworthiness of the CSP. The authors have elaborated their notion on
using soft trust mechanisms by extending their work in [76] and using Consensus
Assessment Initiative Questionnaire (CAIQ). This work establishes a Trust Management
(TM) system for cloud marketplace that provides flexibility in assigning a trust value to a
CSP based on parameters selected by the users. The overall trust degree is uniquely
represented as a graphical output instead of a numerical score for easy comprehension of
the cloud user. However, there is no detailed deliberation on how to actually combine
different soft and hard trust mechanisms in the form of a unified assessment. Moreover,
their trust model lacks the mechanisms to verify or enforce trusted relationship among
participants.
Another framework in [142] uses concept of trusted third party supported security auditing
for establishing users’ trust on a CSP. The framework allows the CSUs to give their
security preferences regarding their required services. The presence of security controls
and internal security policies of CSPs are validated by a trusted Third Party Auditor (TPA).
This TPA refers to the Security Trust and Assurance Registry (STAR) database of the
Cloud Security Alliance (CSA) for this validation. This validation is performed by
analyzing the CAIQ responses from the CSP and afterwards Security Control Validation
(SCV) mechanism facilitates the validation of CAIQ controls. No detail on working of such
42
mechanisms is provided by the authors and they anticipate to develop various algorithms
for their proposed framework.
Policy based models with multi-cloud support
The concept of an overlay network is employed in trust evaluation by establishing a
trust-overlay network [143] on top of multiple data centers. The objective of this trust-
overlay is to constitute a reputation evaluation system for trust establishment among CSPs
and users by means of Distributed-Hash-Table (DHT) based overlay networks. These
networks belong to multiple data centers collaborating to manage trust and enforce security
objectives. Data coloring along with software watermarking is proposed to safeguard data
items and software components. These techniques support authentication for multiple
participants, single sign-on, and access control provisions regarding data in private as well
as public clouds.
Compliance management is another method to achieve trust in multiple clouds. Using the
same strategy, Brandic et. al [144] has introduced an architecture called Compliant Cloud
Computing (C3) which serves as a middleware to certify and audit applications before
deployment. This middleware is responsible to select providers that comply with the user
requirements. Moreover, it also acts as enforcement engine for compliance level
agreements. Authors have also proposed a novel language in which compliance related
requirements could be specified regarding security, privacy, and trust. This language uses
the domain specific knowledge and compliance level agreements to construct
requirements. The C3 architecture utilizes the concept of composite services in which more
than one cloud provider is participating. However, details regarding evaluation of such
composite trust for these services are lacking in their architecture.
Models using recommendation as a source of trust
In [145] the authors suggest using virtualization techniques to enforce security in cloud
provider infrastructure. They propose to construct an overlay network based on a hierarchy
of DHT. Access to datacenters is controlled by their proposed reputation systems
developed using this overlay network. Access to data at the file-access level is also limited
with the same overlay network. Moreover, an architecture for cloud based applications is
proposed that utilizes several security mechanisms to strengthen their security and privacy.
43
Their reputation system keeps a record of security lapses at all levels of access. Both cloud
users and the cloud providers can equally benefit from the proposed architecture.
A trust management system based on fuzzy set theory has been proposed in [146]. Authors
propose to utilize user recommendations from their interaction with a cloud provider as the
source of trust. User recommendations are distinctly evaluated as direct and indirect
feedback. The idea of trust chaining is introduced along with a method to prevent the
behavior of cheating middle nodes.
Although using recommendations as a source of trust has been the most common method
of trust evaluation as they provide the social standing of any CSP. However, false
feedbacks can seriously jeopardize overall results of any trust management system.
Distinguishing sources of feedbacks as reliable or malicious and categorizing them on the
basis of their credibility is one way to deal with this problem. A “Trust as a Service” (TaaS)
framework [147] by Noor and Sheng is an adaptive model for the purpose of credibility
assessment, which is able to differentiate between feedback from reliable and malicious
sources. This is performed by considering consumers’ capabilities and reaching a
consensus over its feedback.
Recommendation as source of trust has also been used in a resource aware trust model
[148]. This model helps CSPs to allocate resources to customers based on a dynamic per
transaction based trust value. An entropy based trust evaluation is used initially to evaluate
trust of each resource before the resource is assigned to the user. After a transaction is
completed, trust of the given resource is evaluated on the basis of user feedback regarding
the subject resource. An adaptable trust evaluation method is used which updates the trust
values for a cloud provider after every transaction. However, other methods of trust
management such as aggregation and dissemination etc. are not discussed here.
Artificial intelligence based techniques for trust establishment is another less visited
perspective. A Genetically Modified Ant Colony Optimization (GM-ACO) [149] is
proposed to build a list of Trust Metric Parameters (TMPs) with respect to CSPs. The
proposed algorithm is based on the principles of Ant Colony Optimization (ACO)
hybridized with Genetic Algorithm (GA). The proposed model distinguishes the trusted
cloud providers based on the rules similar to those generated by ants in ACO. Moreover,
44
the trust accuracy rate is also adjusted by GA algorithm by optimizing the control
parameters.
Recommendation based models with multi-cloud support
Evaluations of recommendations in a multiple cloud scenario introduces the concept
of domain-based trust evaluation. This concept has been employed in a model in which
both the customer and CSP can select services and resources from heterogeneous domains
[150]. When a customer initially avails resources from a CSP, it utilizes recommendation
based trust from its familiar CSPs to evaluate the trust value. When a transaction is finished,
it updates the trust value and revises the recommendation score of respective CSP. CSPs
depend on their trust agents of their respective domains to manage trust values for them.
These agents store and maintain the domain specific trust scores in a table. This trust score
is utilized whenever a CSP cooperates with other CSPs, provide service to customers or
recommends trust, etc. However, their research does not explain the mechanism for
evaluating trust and its components; rather it just focuses on the establishment of the
method to propagate trust in case of multiple collaborative clouds.
Another scheme facilitating cloud providers to cooperate and share resources with each
other based on reputation score is presented in [151]. Recommendations from peer cloud
providers are used as a source of reputation. Two functions are proposed based on beta
reputation system for selecting the highly reputed collaborator. First one is the ‘node
ranking schema’ and the other is the ‘node selection strategy’. In node ranking, every
action of the node is evaluated and ranked as either being satisfactory, unsatisfactory or
nothing. Afterwards any node is selected randomly or otherwise the highest reputed or
probabilistically reputed node is selected. This scheme does not take into account the
multilevel nature of services that are formed as a result of cooperation. Although this
scheme takes into account the reputation collection from peer clouds, mutual trust and
delegation are not considered. Also, it does not take into account the security threats arising
from fake reputation scores from peer clouds.
A distributed trust evaluation protocol with privacy protection for Intercloud has been
presented in [152]. The proposed work utilizes a feedback as a trust source indicator.
However, keeping in view the privacy protection requirements, the feedback is protected
45
by homomorphic encryption with verifiable secret sharing. Moreover, to cater to the
dynamic nature of Intercloud, trust evaluation is conducted in a distributed manner such
that it is workable even when some of the parties are offline. The authors have verified the
applicability of the proposed approach using formal security models and simulations.
However, the approach only support feedback based trust and does not consider
complementing it with any other source. Moreover, the aging factor and context
dependency of feedback has not been considered.
Evidence as a source of Trust
QoS parameters are also used to predict the behavior of various resources before they
are provisioned to a user on its request [153]. This prediction model is based on historical
information regarding stability and availability of cloud provider’s resources that are
required by the user. Performance indicators from the prediction model are used as the
foundation for the trust evaluation model, which gathers the best available resources in
advance to better serve the request of a user. Their model, although being a multiple-
attribute method, utilizes a manual method to allocate weights to trust parameters. These
parameters were set at the same value i.e. 0.25 thus lacking adaptability in evaluation of
trust attributes.
Authors in [154] has proposed a QoS compliance verification as a trust enforcement
mechanism for big data applications. The proposed mechanism enables workflow
orchestration, monitoring, and adaptation of QoS parameters and relies on trust evaluation
to detect QoS performance degradation. It also proposes an automatic reconfiguration
method to guarantee QoS of the workflow. The monitoring and adaptation schemes can
detect and repair different types of real time errors and trigger different adaptation actions
including workflow reconfiguration, migration, and resource scaling. The authors have
formalized the cloud resource orchestration problem using state machine that can capture
different dynamic properties of the cloud execution environment. Experimentation has
been performed using Intelligent Monitoring in Intensive Care III (MIMICIII) system.
However, the proposed work does not explicitly relate to trust evaluation or its methods.
Moreover, the proposed work is more inclined towards resource optimization and QoS
guarantees and lesser towards the effect of such incidents on the credibility of the provider.
46
3.3 Multi-sourced trust models
Trust models with supportive evidence
A Trustworthy Service Oriented Architecture (TSOA) can be achieved in cloud
environment by enforcing mechanisms of robust accountability [122]. The design for such
a TSOA separates the service space of cloud into two distinct domains, namely i)
Accountability Service Domain (ASD) and ii) Business Service Domain (BSD).
Accountability is incorporated in all business related services and their respective
processes. They log irrefutable evidence in ASD that is analyzed by the Accountability
Service (AS). This evidence is validated against the business logic and respective SLA
registered by the same business service. Any business descriptive language can be used to
incorporate this accountability into business process and can be automated with little or no
impact on the implementations of the business process.
The concept of D-S evidence theory along with sliding window is extended for the trust
and reputation evaluation model in cloud computing [155]. Dynamic interaction of both
Cloud Subscriber (CS) and CSP is evaluated as evidence based direct trust by D-S evidence
theory. Evidence as a result of interaction is considered to decay over time. Hence, sliding
window is used to reflect the timeliness value of the interaction evidence. Value of
recommendation trust collected from various entities is considered as second-hand
evidence. Conflict in recommendation is eliminated by combining them using subjective
weight assignment method and treating it as the reputation score. However, this approach
does not fully describe the relation of interaction evidence with the reputation trust value.
Various trust parameters of security, availability and reliability paradigm has been utilized
as a source of trust thus creating an adaptive trust model named as Cloud-Trust [156]. The
proposed model uses an objective mechanism for evaluating the performance of cloud
services in complying with SLA guarantees. Users record their interactions with CSP rather
than providing their rating through feedback. The proposed Cloud-Trust model is used to
define, collect and analyze various trust parameters of CSPs and performs knowledge
discovery over numerous trust parameters. The proposed solution is proven efficient for
dynamic service behavior; however, it does not cater for multilevel agreements for
composite services. The proposed model is not suitable for federated clouds, as it does not
47
resolve the issues related to heterogeneity of cloud providers within the federation.
Moreover, their entire model revolves around the compliance and monitoring of SLA
signed with the end user or the customer, which is not possible in federation.
Another method for utilizing evidence collects dynamic performance parameters of the
providers’ services and correlates with fuzzy QoS requirements of the user as presented in
[157]. The system architecture involves two basic steps to be performed. The first step is
to capture users’ subjective opinions regarding a service and its different QoS attributes.
This can be achieved through methods of fine-tuning fuzzy membership functions. The
second step covers the entire process of application deployment. This may include
submission of requirement, discovery of service, trust evaluation, selection of service and
finally the deployment. User requirements are fed to the system using a web interface. The
Discovery Service fetches the services in accordance with the users’ functional and QoS
requirements. The trust evaluation service calculates the trust levels of the matching
services. Afterwards, it takes the user requirements and the historical performance of all
services to deliver candidate services along with their respective trust values. A Cloud
Benchmark Service (CBS) is used to observe the performance of cloud providers and the
results are published publicly.
Neural networks have been employed to forecast the trust of cloud based services in [158].
Authors extends the Particle Swarm Optimization (PSO) technique PSO-NN to optimize
initial settings of the neural network. This is achieved by finding suitable parameters for
the neural network in order to forecast trust of services with much accuracy. The accuracy
of their algorithm is evaluated with different numbers of training data sets and training
times.
Operational architecture of a trust label system anticipated to act as a TMS for cloud
services is presented in [159]. The proposed system is developed using Delphi
methodology [160] and specifies a range of important metrics for communicating cloud
trustworthiness to CSU. However, this article demonstrates the use of Service Execution
and Data Management metric groups only. For data management group, the authors present
a location control model which helps consumers to specify locations where they want to
store their data. The execution metric group provides service level monitoring using a
48
service monitor framework. This framework is composed of various tools to monitor
different metrics and to communicate the monitored data to the trust label interface.
Integration of all these modules to support trustworthiness computation is anticipated by
the author in future work.
Monitoring QoS parameter is the most significant method of trust evaluation. Authors in
[161] suggest exploiting correlation between QoS attributes to significantly resolve issues
of predicting missing assessment, detecting malicious feedbacks and accuracy problems of
trust values. They propose to use Naive Bayes model and the n-gram Markov model to
design a more efficient trust model for cloud environments. The trust model initially takes
into account the user’s requirements as a base to evaluate trust. Afterwards, the qualitative
and quantitative assessments of a cloud provider by a user is aggregated.
Trust models with supportive evidence for multi-cloud
Contrary to the centralized trust management system as mentioned above, utilizing
distributed Trust Service Providers (TSPs) for multi-cloud architecture has been proven
beneficial [162]. These TSPs are distributed among CSPs, and they gather trust values from
different sources regarding compliance of a CSP to its offered SLA and feedback from
CSUs. The proposed model is a two-layer architecture consisting of both subjective and
objective trust models having local and global trust values for each resource. The trust
evaluation model then relies on the trust propagation network for distributing the trust
evaluation results among all TSPs. However, this model uses the traditional subjective
probability method for direct trust evaluation, rather than direct service behavior.
Moreover, this model utilizes the user feedback for cloud-to-cloud trust evaluation, which
does not suffice in case of dynamic and multilevel relationship formation. The mechanism
of combining both direct trust and indirect trust have not been discussed in detail.
Therefore, it is difficult to conclude anything regarding the adaptability of this model with
dynamic service behaviors.
A TMS for Opportunistic Cloud Services (OCS) involving evidence from SLA based
monitoring is proposed [163]. This TMS involves five operations namely expectation, data
monitoring, data management, analysis, and decision making. The expectation operation is
same as signing an SLA with user having all service related attributes. This SLA is used
49
afterwards as a baseline by data monitoring function to monitor the performance of a
service. Data management function is responsible for collecting evidence data and
afterwards forwarding it to analysis and decision making functions. The proposed TMS
also takes into account the recommendations for the cloud provider to define a context
dependent trustworthiness computation. However, their trust evaluation approach is not
identified as being adaptive in highly dynamic environment of cloud computing.
Moreover, the functionality of OCS is defined as being similar to that of cross-cloud
federation, however, they still consider trivial non-hierarchical methods of trust
aggregation, evaluation and dissemination.
Li et al. [164] have presented a service brokering scheme named T-broker for selecting
trusted service from multiple CSPs in a collaborative cloud environment. Their scheme has
a trusted third party-based broker, the T-broker that facilitates trust management and
service recommendations for users. T-broker uses an adaptive model for evaluating the
trustworthiness of resources from CSPs. Their adaptive model combines the result from
the real-time monitoring with the feedback given by the user regarding the performance of
a given resource. However, T-broker does not elaborate mechanisms for dealing with
heterogeneity in contracts of different CSPs. Moreover, this scheme employs user
feedback, which is not the case with the cross-cloud federation.
A middleware framework for Service Operator-aware Trust Scheme (SOTS) [165] is used
for discovery of matching resources in multiple clouds. Trust evaluation is modeled as a
Multi-Attribute Decision-Making (MADM) problem. Their proposed trust evaluation
approach is adaptive and is based on information entropy theory. A centralized broker is
responsible for making trust decisions and offering resources based on users’ trust and
functional requirements.
A trust establishment framework resilient to collusion attacks is proposed in [166]. Initial
trust values are assigned using a bootstrapping mechanism. A trust-based hedonic coalition
game is also proposed that enables different providers and their services to form
distributive trustworthy multi-cloud communities. Trust establishment is based on a
polynomial-time services discovery algorithm that enables services to inquire about each
other’s behavior based on their tagging in online social networks. A trust bootstrapping
50
mechanism is then used that combines both this endorsement mechanism in social
networks with the decision tree classification technique. This results in initial trust values
to be assigned to the newly deployed services. A trust aggregation technique is then
proposed that uses the Dempster-Shafer evidence theory [167]. A credibility update
mechanism is used to ensure that trust results are accurate even in case of collusion attacks.
Afterwards the multi-cloud community formation is modeled as a trust-based hedonic
coalition formation game. This work identifies their trust management solution viable for
federation and service formation involving multiple clouds. However, this approach is
more inclined toward multi-cloud architecture as it does not involve hierarchical service
formation which is a unique characteristic of federation.
Trust models with policy and recommendation as source
Manuel et. al. [168] introduced a mechanism to evaluate trust of cloud resources using
a resource broker. The broker selects suitable resources from heterogonous clouds
depending on the user requirements. The proposed system provides improved trust through
the broker by implementing Kerberos and PrivilEge and Role Management Infrastructure
Standard (PERMIS) mechanisms for authentication and authorization respectively. The
trusted broker makes assessment for the trust value of resources based on their security
level, feedback evaluation and resource capability. The overall trust score, however, is a
simple aggregation with equal weights of these three trust scores, which does not cater for
dynamic service behaviors in multiple service compositions. In addition, the proposed
model does not elaborate the mechanism to cater for the heterogeneity of cloud providers.
A SLA based trust model utilizes third party intermediary agents to facilitate trust
establishment between consumers and cloud providers [123]. Their agent called SLA-agent
performs activity monitoring, trust decisions and best fit service selection based on SLA
parameters. Trust decisions are based on service delivery feedback about cloud providers
from both the consumer and SLA-agents. However, the research is only subjective, and
authors have not shared any detail of trust model in terms of SLA parameters, evaluation
and aggregation of feedbacks and overall trust calculation. The theoretical foundation of
their proposed model dictates that the fusion of trust evaluation parameter is performed
manually and thus is not feasible for use in dynamic service compositions.
51
The notion of verifying CAIQ assessment and complementing it with user feedback is
presented in [169]. A third party audit framework acts as a baseline for a user to evaluate
services or providers with whom the user is working for the first time. Afterwards, the
feedback from the user is incorporated in the audit score to build a trust score of the service
provider. A time decay function is also used to give more weightage to the recent
feedbacks. The results of the cumulative feedback combined with the audit score is used
as a representation of the service provider trustworthiness score. However, the function
used to combine both trust indicators is a static addition operator and lack any kind of
adaptability in case of dynamic cloud environments.
“Select Cloud Service Provider” (SelCSP) [170] is another model for selecting a
trustworthy CSP from a set of CSPs. Trustworthiness and competence of a CSP is
combined for an overall risk estimation of interaction. Trustworthiness is computed as a
result of experience achieved through interactions or from feedback regarding each
provider’s reputation. Competence of a CSP is measured based on transparency of QoS
parameters declared and assured in its SLA. Afterwards, both trustworthiness and
competence are merged to compute the overall interaction risk that provides an overall
approximation of the risk involved in any given interaction. However, their mechanism of
trust evaluation uses subjective methods to evaluate QoS parameters, rather than service
behavior from real-time sources against QoP attributes.
Credibility of feedbacks can be verified by using correlation of various QoS attributes and
feedback result [171]. This approach utilizes technical requirements of users and considers
the heterogeneity of providers, services and users when evaluating trust parameters.
Correlation between different QoS attributes (i.e. Availability, Reliability, Time Efficiency
and Data Integrity) is used for an overall trust assessment. A trust manager is responsible
for selecting matching services based on QoS requirements of user and a trust value. The
trust level of services is computed based on feedback from previous interactions of various
users.
Heterogeneity of service providers and services along with user feedback may be handled
using standard approaches for cloud assessment. CAIQ can be used as a method for trust
and reputation evaluation mechanism as proposed in [172]. Trust information is modeled
52
in terms of opinions formalized in subjective logic. Cloud providers submit their
assessment report in the form of CAIQ before service delivery to the user. These
assessment reports can be requested by the user via the Cloud Trust Protocol (CTP). After
the service delivery, a user provides feedback opinion for the cloud provider. Only latest
service delivery feedback is kept in record without any aging factor. However, credibility
of service feedback from the client is not discussed in this approach.
A Security Measurement as a Trust (SMaaT) framework for cloud selection has been
presented in [173]. The authors extend an Analytical Hierarchical Process (AHP) for
service selection from the customers’ perspective. Monitoring of different Service Level
Objectives (SLO) present in the Security SLA (SecLA) is performed to rank the security
aspects and assign trust values based on these security parameters. The AHP allows
calculation of attribute weights depending on user preference and the estimation of
interdependencies between the attributes. The article only contains theoretical contents
related to their proposed approach and hence the credibility of the approach cannot be
established.
3.4 Trust models with federation support
Trust management in cloud federation is a least focused research area, having only
few trust evaluation models. One such model [174] is based on the notion that previous
models of TMS are unfit for cloud federation architecture due to the novel requirements of
cloud-to-cloud trust. However, the proposed model still involves the user for its feedback
and is a simple average of SLA based and feedback based trust score. Moreover, their
evaluation model lacks adaptability which is the prime concern of federation due to its
evolving nature. Additionally, their work is only supported by a specific use case of
federation with two participating clouds and a central entity and lacks any word for
problems of heterogeneity. This piece of work is the only trust evaluation system designed
for federation. However, it still lacks mechanisms to cope with the specific case of cross-
cloud federation.
A Joint Trust and Risk Model (JRTM) is introduced for federated cloud services [175]. The
model is based on CSPs’ performance history. It addresses provider and consumer concerns
by relying on trusted third party like a Trust as a Service (TaaS) provider to collect soft and
53
hard trust data elements, allowing for continuous risk monitoring in the cloud. The negative
and positive tendencies in performance are differentiated and the freshness of the historic
data is considered in their model. However, the TaaS provider depends only on the
transparency of the CSP to provide monitoring reports to it and lack any mechanism to
verify such reports. Trust is based on the ability of a CSP to eliminate the risk for a cloud
consumer, which can be categorized as security, privacy and service performance risks.
JRTM is verified using Monte-Carlo simulation methodology to verify its applicability to
the cloud environment. However, this model does not take into account its applicability to
the federation, although it discusses the service composition in cloud federation.
A coalitional graph game, called trust-aware cloud federation formation game has been
proposed in [176] to support cooperation among cloud providers in a federation. Authors
have considered a specific case of Map-heavy/Reduce-heavy programs while considering
the trust and reputation among the participating cloud providers to achieve maximum profit
for their participation. A cloud provider rates another cloud provider based on its direct
interaction which is considered as a local rating. These local ratings are propagated in the
federation network and are considered as global reputation score of a cloud provider. This
reputation score is afterwards used in the formation of trust-aware coalitional game to
maximize the profit of the participating provider. However, the proposed mechanism does
not take false feedback and other security vulnerabilities in recommendation based trust
mechanisms.
Authors in [177] have proposed a lightweight trust establishment algorithm based on
trust ratings of cloud providers for each other. The proposed mechanism is an extension to
the Trust Network Analysis with Subjective Logic (TNA-SL) algorithm [178] for cloud
environments. The algorithm is based on subjective logic in which each rating is expressed
as an opinion. The opinions regarding a cloud provider within the federation network are
combined using subjective logic and represents the overall global trust of the provider. The
proposed algorithm however, utilizes recommendation and feedback rating in the
federation. This approach has an inherent risk of being susceptible to bad mouthing and
collusion attacks. Moreover, the authors have neither considered the service composition
structure nor the service delivery context to accumulate feedbacks.
54
3.5 Summary
This chapter discusses the recent literature available for trust management in
conventional, multi-cloud and federated cloud architectures. An overview of the literature
has identified the recent trends for trust in conventional and inter-cloud environments. A
lot of work has been done recently for trust management in multi-cloud environment.
However, trust management in federated clouds is a less visited area. Understanding of the
requirements of federation and its dissimilarity with the conventional and multi-cloud
environment is the need of the day.
55
Chapter 4
4 Research Methodology
56
4.1 Introduction
This chapter describes the methodology used for analysis, design, implementation and
verification of the proposed research. This methodology is a two phase approach with an
initial exploratory phase followed by an applied research phase. Initially, a theoretical
framework has been defined based on specific qualitative requirements of trust in cross-
cloud federation. This framework contains four founding principles mapped to the nature
of federation. These principles are listed as i) Trust bi-directionality ii) Composite trust iii)
Delegation control and iv) Context awareness. Moreover, the influence of these principles
on the architectural classification, sources, methods and properties of TMS is defined to
formulate a conceptual framework for cloud-to-cloud trust establishment.
The proposed framework serves as the base on which any anticipated or already available
TMS can be verified for applicability to federation. A TMS may either explicitly address
the trust principles of CCF or implicitly with the presence of certain trust attributes.
However, these trust attributes must align with the dynamic, heterogeneous and multilevel
nature of federation to fully satisfy the proposed framework. A quantitative review of state-
of-the-art TMSs is presented to identify their trends and shortcomings. This review has
helped to draw significant assessments to aid in carrying out the applied phase of this
research. It has been observed that context awareness is largely incorporated in recent
works. However, other principles, namely trust bi-directionality, composite trust and
delegation control have never been addressed in literature. Also, it can be observed that
many of the existing works exhibit necessary properties and functions that can be brought
in line with the requirements of CCF. To help address this alignment of TMSs with
requirements of CCF, a requirement matrix is presented that outlines the probable areas
that require necessary changes in their underlying structure along with recommendations
for these changes.
After defining the trust requirements, the applied research phase utilizes an empirical-
analytical research methodology. Requirements originated from the exploration phase of
research are used in the design of an adaptive trust-aware brokerage model using
Clouds4Coordination (C4C) system [179]. The proposed model uses quantitative
parameters such as CAIQ assessment and performance data of the CSP collected by the
57
broker. The details of empirical-analytical design are provided in chapter 5 along with
experimentation and results in chapter 6.
4.2 Overview of research
The existing literature lacks a comprehensive framework for establishing trust in such
a scenario of delegated trust i.e. user trusting the home CSP, which in turn has to trust its
sub-providers (foreign CSPs). Due to this reason, no trust specifications or models can be
instituted without first realizing the precise trust requirements of cloud federation.
Figure 8: Research methodology illustration
This research focused on bridging this gap before proposing a trust-aware brokerage model
for cross-cloud federation [180]. A combination of two methodologies i.e. exploratory
research at the first phase and applied research at the second phase has been utilized to
achieve the research objectives as depicted in Figure 8.
58
The exploratory process starts with the theoretical concepts derived from the initial
investigation. These concepts are used to define a cross-cloud trust paradigm. This trust
paradigm establishes the uniqueness of cloud-to-cloud trust from conventional and multi-
cloud scenario of user-to-cloud trust. This paradigm is a basis for a theoretical framework
that defines founding principles of cloud-to-cloud trust. These principles define concepts
that strongly relate to the specifications of cross-cloud federation.
A conceptual framework is afterwards presented on the basis of theoretical framework.
This conceptual framework defines the mapping between all the theories introduced in this
research. For this purpose, the principles of theoretical framework are declared as
dependent variables. All other concepts derived from architectural perspective and trust
specifications are declared as independent variables. The dependency relation among these
variables is then thoroughly investigated to specify relationships between principles of
cloud-to-cloud trust and concepts of trust management and properties of federation.
This framework is then used to review the available literature for trust in cloud computing
for their usability in cross-cloud federation trust. As a result of this analysis, a requirement
matrix has been produced to identify the relationships between all variables of this study.
This requirement matrix helps to refine the hypothesis of this research in form of necessary
provisions and to develop an in-depth analysis of cross-cloud trust problem. Moreover, the
outcomes of this exploratory phase of research are refined empirical design, data-collection
methods and selection of experimentation.
In the second phase, applied research with analytical-empirical methodology has been used
with quantitative parameters. A trust-aware brokerage model has been proposed that offers
adaptive trust establishment as a function of relationship among service providers. Two
different perspectives are addressed by presenting both fine grained and coarse-grained
trust methods for varying scenario of federated services. The former method is based on
belief calculus and may be useful on its own in case of highly competitive collaborating
scenarios where detailed analysis of trust is decisive for usefulness of cooperation among
peers. The latter approach is based on numerical calculus and is useful in less competitive
scenarios and is afterwards combined with performance metrics of cloud provider as a risk
based strategy.
59
The proposed model is implemented as Trusted Third Party (TTP) broker in CPython. This
broker is integrated with Clouds4Coordination (C4C) System [179] developed at Cardiff
University, UK for AEC industry. Two data sources have been utilized for verification of
the proposed model. For trust evaluation, actual dataset in the form of CAIQ from Cloud
Security Alliance (CSA) STAR program has been utilized. For performance evaluation,
various Building Information Modeling (BIM) workloads acquired from reliable sources
have been used. Numerous experiments are conducted for the purpose of data processing
and analysis. Details of entire research process including research methods, design,
instrumentation and analysis is given in the following sections.
4.3 Exploratory Research
In this phase of research, the problem of trust in cloud federation has been investigated
thoroughly using exploratory research methodology. This method has been carried out in
order to investigate detailed problem analysis using qualitative parameters. The output of
this first phase of research is a conceptual framework that has been built on the theories
taken from inter-cloud computing (section 2.2) and trust management (section 2.7) in
general and cloud federation in particular (section 2.4). The aim of this framework is to
gain familiarity with the cross-cloud trust phenomena and to acquire new insight in order
to formulate a more precise research hypothesis.
Cross-cloud trust paradigm
Trust establishment has been a major concern in cloud computing and a lot of research
has been done for TMS. The reason is that consumers primarily doubt CSPs’ intentions
and trueness instead of mistrusting their capabilities [181]. Moreover, consumers’
hesitation for cloud adoption is due to the fear of losing control over their applications and
data entrusted to their cloud provider [182, 183]. Therefore, the research on trust
establishment in cloud computing has always attributed itself for attaining consumers’ trust
on a CSP.
Trust management is also necessitated in multi-cloud architecture [111]. However, the
TMS in multi-cloud architecture lack diversity and have been mostly the same as that of
conventional cloud computing. The fact is, that multi-cloud architecture shares many
similarities with conventional cloud computing regarding trust evaluation. Firstly, both
60
types of TMS focus on facilitating the consumer for the selection of trustworthy home CSP.
Moreover, these TMS deal with individual CSPs to form a single level and direct
relationship with the consumer. In any case, selection of one or more than one CSP requires
the same underlying trust management techniques. Hence, it can be stated that the TMS
employed in conventional cloud computing are applicable in multi-cloud architecture with
little or no modification and vice versa [174]. However, the case for trust management in
cross-cloud federation is unique in its own due to the properties of such a federation.
Figure 9: Delegated trust in cross-cloud federation
Cross-cloud federation offers the perspective of delegated trust, i.e. a consumer’s trust on
its home CSP, and home CSP’s trust on foreign CSP(s) [6] as depicted in Figure 9. This
transitivity issue must be considered while addressing the problem of trust management in
cross-cloud federation. This transitivity is proposed to be reduced by splitting the problem
of trust in cross-cloud federation into two distinct trust domains i.e. consumer-to-cloud
trust and cloud-to-cloud trust. The cloud-to-cloud trust domain dictates the need for
establishing trust between CSPs participating in the federation. Despite the benefits that
can be availed from a cross-cloud federation, CSPs are hesitant to contribute in it, mainly
due to the lack of confidence and trust among themselves [6]. It is a fact that behavior of a
federated service from a CSP is reflective of the behavior of its sub-providers. A violation
of contract by a foreign CSP can have a cascading effect on the performance of home CSP
[129], eventually causing distrust with the consumer. This is why it is argued that
61
addressing the concerns of cloud-to-cloud trust is sufficient to address the problem of
transitive trust in cross-cloud federation. A home CSP can safely provide guarantees of
trustworthy service delivery to its customer when it is confident with foreign CSPs to
entrust its customers’ data.
Theoretical framework for cross-cloud federation
Despite of extensive work on TMS in cloud computing, a void however, has been
observed in addressing the challenges of cloud-to-cloud trust. Based on the unique
formulation and properties of CCF, it is important to establish the uniqueness of cloud-to-
cloud trust over its consumer-to-cloud counterpart. Once recognized as unique domain,
already available research on trust management can be reviewed for its applicability to
address concerns of cloud-to-cloud trust. Otherwise, an alternative would be to devise
newer methods or align the already available ones to the underlying concepts of CCF.
Four founding principles that make up the cloud-to-cloud trust framework are identified,
namely i) Trust bi-directionality ii) Composite trust iii) Delegation control and iv) Context
awareness. The basic concepts of these principles and their necessity in cross-cloud
federation is described as follows.
Trust bi-directionality – Conventional TMS facilitate the consumer to identify the
trustworthy CSP but a CSP is never interested in knowing the trustworthiness of a
consumer. Cross-cloud federation, similarly, implies a home CSP identifying
trustworthy foreign CSPs to place its consumers’ data and application. However, in
such a case, foreign CSPs are also faced with an increased threat.
Figure 10: Bi-directional trust for cross-cloud federation
Home CSP
62
They might never know or control the ownership and manipulation of any data and
application that is residing in their premises. Thus it is argued that in cross-cloud
federation, there is a need of bi-directional or mutual trust relationship i.e. the home
CSP’s trust on foreign CSP and vice versa as depicted in Figure 10.
Composite trust – Federated clouds combine resources from multiple providers to
form a composite service. To better understand the concept of composite service,
and in turn the concept of composite trust, consider the following example. The end
user service is delivered as SaaS application from its home CSP. This application
has been compiled by using service from foreign CSP A. CSP A has its IaaS
delivered by CSP Q. An abstraction of this relationship is depicted in Figure 11. In
such a scenario, home CSP is entirely responsible for guaranteed service delivery
to the customer. Therefore, only the knowledge of individual trust levels of every
CSP may not suffice. An evaluation of trustworthiness for this composite service
in entirety is necessary to predict its performance in the course of time.
Figure 11: Abstract illustration of composite trust
Delegation control – In scenarios of collaborative computing such as cross-cloud
federation, trust should not be unilaterally delegated [184]. To understand the
concept of trust delegation, consider Figure 12. The home CSP is depicted to deliver
a service to customer. After a brief period, home CSP requires to lease additional
resources from its trusted peer B such that B would be actively involved in service
composition. In such a scenario this trust relationship of home CSP with B does not
63
and should not imply that the users’ data entrusted to home CSP can be delegated
to B without the knowledge of the user.
Context awareness – The concept of composite trust is complemented by context
awareness within trust assessment. A valid context may be from a business or
project point of view like contingency planning etc. From another context, a cloud
provider may lease different type of resources with different settings e.g. storage,
compute etc. Trust as a value of global assessment of a CSP is not recommended
for fine-grained evaluations. Each context must be individually assessed for its trust
value in addition to its provider’s trust level as depicted in Figure 13.
Figure 13 Context awareness in cross-cloud federation
Existing TMS do address the concerns of consumer-to-cloud trust, but their applicability
to CCF is still a question that needs elaboration. It is argued that a suitable TMS for cross-
cloud federation is the one that addresses the above-mentioned challenges of cloud-to-
Home CSP
Home CSP
Figure 12: Delegation control for cross-cloud federation
64
cloud trust. Trust management systems in conventional and multi-cloud computing
environment lack methods that align with the respective properties of cross-cloud
architecture. A further quantifiable deliberation on the recent trust management techniques
may be helpful to provide insights on developing an appropriate trust management solution
for cross-cloud federation.
Conceptual cross-cloud framework
This section defines the conceptual mapping of various theories and principles of trust
in cross-cloud federation as defined in theoretical framework. All parameters necessary to
establish the evaluation of TMS have already been identified. These parameters include
architectural classification (Section 2.3), general attributes of TMS (Section 2.7) as
independent variables and cloud-to-cloud trust principles as dependent variables. These
parameters are laid out in Table 4 with dependent variable on the vertical axis and
independent variable on horizontal axis to define their relationship. As illustrated in Table
4, Trust bi-directionality only influences methods of trust representation and few
properties. Composite trust has its influence on all methods and properties except the
objective of TMS. Moreover, Delegation control does not influence any method but the
architectural classification and a few of the properties. Similarly, Context awareness has
its effects on representation and evaluation of trust along with some properties.
Table 4: Influence of cloud-to-cloud trust principles on trust management systems
This conceptual mapping is afterwards used to present a quantitative analysis of all
significant TMS to complement their subjective assessment presented in the chapter 3. This
Methods Trust Properties
Arc
hite
ctur
al
Cla
ssif
icat
ion
Sour
ces
Rep
rese
ntat
ion
Agg
rega
tion
Eva
luat
ion
Dis
sem
inat
ion
Obj
ecti
ve
Con
text
Vis
ibili
ty
Secu
rity
Acc
urac
y
Priv
acy
Con
trol
Scop
e
Trust bi-directionality
Composite trust
Delegation control
Context awareness
Legend Influenced Not Influenced
65
analysis is carried out not only to build a consolidated view of the ability of these TMS but
also to verify their applicability to the CCF. As a first step, it is identified that whether a
TMS explicitly fulfill the requirements of trust in CCF or not. In case of a negative
evaluation, the second step is to verify whether it offers the necessary attributes of trust in
general. If that is the case, the presence of requisite attributes is verified for each cloud-to-
cloud trust principle as defined by their influence in Table 4.
Concluding the efforts for explicitly addressing the concerns of cloud-to-cloud trust from
Table 5, context awareness is largely incorporated in recent works. All other principles,
including trust bi-directionality, composite trust and delegation control are neglected areas.
Moreover, from Table 5 it can be observed that many of the existing works exhibit
necessary properties and functions that can be aligned with the requirements of cloud-to-
cloud trust. This objective analysis of Table 5 helps to comprehend the trends in research
and development of TMS. It can also be observed that cloud-to-cloud trust is one of the
least focused area of research. Moreover, this analysis is the key to understand the
shortcomings of existing solutions and to identify where focus is required. Following
conclusions can be drawn from Table 5.
Trust bi-directionality – Referring to Table 4, bi-directionality requires
homogeneous representation methods, and must exhibit some of the properties of
TMS that may further be aligned to CCF context. It can be observed from Table 5
that only 9 TMS appear as candidate systems that exhibit homogeneous aggregation
methods. Out of these 9 candidates only 1 TMS exhibit all five properties for
introducing bi-directionality. The other eight lacks one or more than one attribute,
however, rendering them closely acceptable for the mentioned purpose.
Composite trust – As mentioned in Table 4, composite trust not only requires
homogeneous trust representation but also methods for multi-level aggregation,
evaluation and dissemination. All properties of TMS must be aligned to this multi-
level nature of composite trust methods with the exception of TMS objective that
should always refer to trust and/or reputation. Out of all representative systems, not
a single TMS candidate offers such a capability to implicitly offer any method to
deal with composite trust.
66
Table 5 Objective analysis of TMS in cloud computing
Lit
erat
ure
Arc
hite
ctur
al
Cla
ssif
icat
ion
CCF Specifications Trust Specifications
Sour
ces
Methods Properties
Tru
st b
i-di
rect
iona
lity
Com
posi
te
Tru
st
Del
egat
ion
cont
rol
Con
text
aw
aren
ess
Rep
rese
ntat
ion
Agg
rega
tion
Eva
luat
ion
Dis
sem
inat
ions
Obj
ecti
ve
Con
text
Vis
ibili
ty
Secu
rity
Acc
urac
y
Priv
acy
Con
trol
Scop
e
[140] SD P SSt T U AA CL [76, 141]
SC P H SSt T U V CL
[139] SC P Sa T U AA RL
[142] SC P H T U AA CL
[143] MP P SSt Re U CL
[144] MD P H Sa SAd T U AA RL
[148] - R SAd T U RL
[147] SC R SAd T U Pe CL
[149] SP R SAd T U
[145] SP R H Sa SSt Re U/C RL
[146] SC R H Sa SAd T U V SL
[150] MD R H Sa SSt T U/C M RL
[151] MC R H Sa SAd R C CL
[152] MD R H Sa SSt T C CL
[153] - E SSt T U M RL
[154] SC E H Sa Re C M CL
[155] - R/E Sa SAd T/Re U CL
[156] SC R/E H Sa SAd T U M RL
[122] SD P/E Sa SSt T U AA SL
[158] - P/E SAd T U M SL
[157] SC P/E H Sa SAd T U M SL
[159] SC P/E H Sa - - T U M SL
[161] SC P/R/E Sa SAd T U M CL
[164] MC R/E Sa SAd T U M RL
[162] MD P/R/E Sa T U M RL
[165] MC R/E Sa SAd T U AA RL
[163] MC P/R/E H Sa SSt T/Re U M SL
[166] MD R/E Sa SAd T C M SL
[123] SC P/R SSt T U M CL
[170] SC P/R H Sa SSt T/Re U Tr SL
[169] SC P/R H Sst T U AA CL
[168] SC P/R Sa SSt T U RL
[171] SC P/R H Sa SAd T U V CL
[172] SC P/R H SSt T U RL
[173] - P/E T U M CL
[174] FC P/R Sa SSt T C CL
[175] FC E H Sa SAd T U Tr CL
[176] FD R H Sa SSt Re C CL
[177] FP R H Sa SSt T C CL
Legends
= Present, = Not Present, -/NA = Not Applicable, SC = Single cloud with Centralized management, SD = Single cloud with Decentralized management, SP = Single cloud with Peer-to-peer, MC = Multiple clouds with Centralized management, MD = Multiple clouds with Decentralized management, MP = Multiple clouds with Peer-to-peer, FC = Federated cloud with Centralized management, H= Homogenous representation, Sa = Simple aggregation Ha= Hierarchical aggregation, SAd = Simple Adaptive, SSt = Simple Static, HAd = Hierarchical Adaptive, HSt = Hierarchical Static, P = Policy, R = Recommendation, E = Evidence, T = Trust, Re = Reputation, U = User centric, C = Cloud centric, M = Monitoring, AA = Audit and Accounting, V = Verification, Pe = Penalty, Tr = Transparency, CL = Cloud Level, SL = Service Level, RL = Resource Level.
67
Delegation control – Referring to Table 4, unilateral delegation of trust can be best
avoided with centralized architectures along with a few of the properties of TMS
that may further be aligned to CCF context. It is observed that fourteen TMS appear
as candidate systems that have centralized architecture. However, none of these
TMS exhibit all four properties necessary to introduce controlled delegation within
CCF.
Context awareness – As observed from Table 5 there are sixteen TMSs that
explicitly offer context awareness mechanisms. However, keeping in view the
conventional requirements of trust, only two of these are effective as they exhibit
the necessary properties of trust as derived in section 2.7.3. Keeping in view the
CCF requirements, unfortunately adaptive trust evaluation methods with
homogenous representation to support a multi-level relationship in CCF are not
available in the literature as yet. However, there are six TMSs that are partial
candidates to address cloud-to-cloud trust requirements with a homogenous
representation supporting adaptive evaluation of trust. Out of these six partial
candidates TMS, only one exhibits necessary properties influenced by context
awareness in CCF.
Requirement Analysis
To this point, a basic cloud-to-cloud trust framework has been identified. Moreover, a
review of the current research has helped to summarize the capabilities of existing TMS
and their lack of contribution in achieving trust within a CCF. An overview of the
evaluation of TMS helps to draw the following significant assessments.
Almost all of the discussed schemes lack to establish a complete TMS having both
trust and reputation assessment.
No significant work has been reported in literature for trust and reputation
evaluation from a cloud centric i.e. cloud-to-cloud trust perspective.
The present research on TMS lacks focus on mechanisms of multilevel aggregated
trust evaluation for composite services.
Existing trust models have never been instantiated in TMS to evaluate bi-directional
trust of entities.
68
Keeping in view these assessments it can be concluded that a novel TMS is required for
CCF that contain newer methods aligned to the specific nature of CCF. This section
outlines the probable areas that require necessary changes in their underlying structure
along with recommendations for these changes. Table 6 shows a detailed matrix containing
the influence of identified parameters of trust evaluation and CCF on each other.
In this matrix, two categories of trust parameters have been identified. One category
consists of parameters that have a set of choices to select from i.e. architecture and trust
method types. Both of these parameters have two values from which one of them is to be
chosen. For example, out of all identified parameters, a large number is compatible with
the centralized architecture, rendering it as a recommended choice. The other category
consists of trust parameters that have no set of choices. However, these parameters
influence certain other parameters and hence are necessary to be incorporated. These
parameters mostly require a change or alteration in their underlying methods to be fit for
CCF. For example, from the intersection of privacy and trust sources as highlighted in
Table 6, it is recommended that the information collected from trust sources must
incorporate mechanisms for privacy. Moreover, the intersection of trust sources with
multilevel nature of federation suggests that the methods for assessment of policy,
recommendations and evidence must align with the multilevel nature of CCF. Following
the same patterns, a few guidelines can be provided as recommendations for a
comprehensive and most suitable trust management solution for CCF.
Centralized trust management – In cross-cloud federation, the necessity of a central
entity such as a broker for resource discovery and matching is already an
established fact. Similarly, in case of trust dissemination, enforcement, control and
compliance, a centralized model is a trustworthy choice. A trust-aware broker
encourages the CSPs to have higher confidence in federation as trust decisions are
authentic and reliable. Moreover, the benefits of a centralized trust management
system as evident from Table 6 surpasses its drawback of being a single point of
failure.
Multi-sourced trust indicators – A primary objective of a trusted federation is to
allow CSPs to entrust their customers’ data to each other for greater mutual
69
interests. It is crucial to select key indicators of trust to maximize decision
performance. The key indicators of trust must be collected from a combination of
policy, recommendation and evidence base to indicate a CSP’s social standing and
assurance of its future outcomes.
Adaptive trust fusion – The dynamic nature of federation establishes the need for
adaptive fusion of trust values collected from multi-source trust indicators. This
ensures that the overall trust evaluation follows the evolving and ever changing
structure of the federation.
Homogenous policy formalization across entire federation – Converting
heterogeneous policies of all CSPs to homogenous metric space is necessary for
uniform evaluation and comparison of the trust values of their respective resources
from all trust resources.
Novel methods within federation – As mentioned earlier, a CCF can achieve the
requisite properties of trust by aligning its underlying methods with the nature of
federation. However, certain parameters in cloud-to-cloud trust requires newer
methods as these parameters have never been addressed in literature in the
perspective of trust. These include novel methods for i) evaluating cumulative trust
of a composite service ii) controlling unilateral delegation of trust and iii) dealing
with the multilevel and hierarchical nature of federation.
4.4 Applied research
The preceding phase of exploratory research has helped draw significant assessments
for working out the design of proposed trust-aware brokerage in CCF. Specifically, a trust
model must explicitly address the trust principles of CCF (dependent variables). Otherwise,
the presence of certain trust attributes (independent variables) may allow a model to qualify
for applicability in CCF, however, these attributes must align with the dynamic,
heterogeneous and multilevel nature of federation. The proposed analytical and empirical
design of trust-aware brokerage is based on this assessment. The details of methodology
used in this phase of research is given as follows.
70
Table 6 Matrix for requirements of trust in cross-cloud federation
Architecture Trust Sources Evaluation
Method Trust Properties cross-cloud Properties
Cen
tral
ized
Dis
trib
uted
Polic
y
Rec
omm
enda
tion
Evi
denc
e
Stat
ic
Dyn
amic
Obj
ectiv
e
Con
text
Vis
ibili
ty
Priv
acy
Secu
rity
Acc
urac
y
Con
trol
Scop
e
Dyn
amic
for
mat
ion
Mul
tilev
el
Het
erog
eneo
us
Trust Sources
Policy
Recommendation
Evidence
Evaluation Method Static
Dynamic N N N
Trust Properties
Objective
Context
Visibility NC
Privacy N N N
Security
Accuracy
Control N N
Scope
cross-cloud Properties
Dynamic formation N N N N N
Multilevel NC NC NC NC NC NC NC NC NC
Heterogeneous NC NC NC N N
C-to-C Trust Paradigm
Trust bi-directionality NC NC NC N NC N N N N NC NC
Composite trust NC NC NC NC NC NC NC NC NC NC NC NC
Delegation Control NC NC NC NC NC NC N
Context Awareness NC NC NC N N N NC NC NC NC N
Legends = Applicable N = Necessary NC = Necessary requiring change Empty = Not concerned
71
Implementation
The implementation of trust-aware model for cross-cloud federation has been carried
using a custom built Trusted Third Party (TTP) broker and its agent built using CPython.
They are integrated with C4C federated cloud system built using Cometcloud [42]
federation framework. The broker agent resides within the cloud providers infrastructure
and makes use of Linux system level commands to obtain trust and performance data from
C4C nodes. This trust and performance data is expressed in the form of quantitative
parameters described in Table 7. Further details of instrumentation and implementation
have been discussed in chapter 6.
Data collection
Experimental evaluation of the proposed model makes use of real world dataset from
CSA STAR registry [29]. This registry contains a set of CAIQ self-assessment reports of
various reputable CSPs. A number of other authors have also made use of this data set,
such as S.M. Habib et al. [76, 141], S. Rizvi et al. [142, 169] and Algamdi et al. [185].
This research has used the data published in CAIQ v3.0.1 format from CSPs having level-
2 certification. These CSPs include but are not limited to Acer Cyber Center Services,
Amazon, GitHub, Google, IBM, SAP and Salesforce etc. The CSA STAR registry enables
a standards-based, community wide perspective on cloud security offerings, enabling end
users to “accelerate their due diligence and leading to higher quality procurement
experiences”1. The registry uses a number of industry standards, such as Cloud Controls
Matrix (CCM), CAIQ (as used in this work), and the Cloud Audit and Control Trust
Protocol. The CSA has worked with a number of international certification agencies, e.g.
ENISA (European Security Agency) and the Chinese CEPREI, ensuring that the outcome
has a wider applicability across a number of different international markets. The associated
CSA STAR Watch initiative provides a tool in a database structure to monitor and assess
public and private cloud providers.
Moreover, the proposed risk based strategy make use of the aforementioned CAIQ
data and the performance results derived from C4C system are hosted at Cardiff University,
1 https://cloudsecurityalliance.org/media/press-releases/csa-star-registry-surpasses-100-entries-new-csa-
star-watch-tool-now-in-open-beta/
72
UK. A real world data set consisting of various BIM models of different sizes have been
utilized in these experiments. Details of BIM modeling and BIM workloads used in this
research can be found in APPENDIX - B and APPENDIX - C respectively. The details of
this experimentation can be found in section 6.3.
Table 7: Quantitative parameters of proposed research
Metrics Parameter Description
Utility Classification
(HB = Higher is better, LB = Lower
is better)
Trust
Positiveness Average number of positive declarations for any CSP HB
Negativeness Average number of negative declarations for any CSP LB
Belief The expected behaviour based on positiveness HB
Disbelief The expected behaviour based on negativeness LB
Uncertainty Uncertainty in expectation LB
Initial expectation Prior knowledge regarding expectations HB
Individual Trust Expected trust value based on belief, disbelief and
uncertainty of a CSP HB
Perceived Risk Risk of engaging a CSP in the formation of a
composite service. LB
Time
Writing time Time taken by a CSP to write workload data (objects)
LB
Synchronization time
Time taken by all CSPs to synchronize metadata for data objects put within the shared execution space
update time Total time taken by a workload to be written to shared federation space and metadata to get synchronized in
federation
Fetch time Time taken by a CSP to fetch workload updates from
shared execution space
Aggregated Time to Complete (ATTC)
Time taken by the project to complete. A project may involve multiple object updates and fetches by any
service provider
Performance
Write Performance Number of Objects written to disk per seconds by a
CSP
HB
Synchronization performance
Number of metadata objects synchronized per seconds by a CSP
update performance Number of objects updated per seconds
Perceived Competence
Number of objects per ATTC
Decision
Composite Trust Expected trust value of a composite service evaluated as a factor of individual trust and dependency relation
of all service providers. HB
Cooperation Threshold
Expected value to decide whether to engage in resource exchange with a CSP
LB
Project Performance Performance of entire project with any chosen set of
CSPs HB
73
Data processing and analysis
The data processing and analysis include utility classification, workload classification
and characterization, services exercised by workload, data summarization techniques,
dependency and relationship analysis. The selected quantitative parameters have been
classified in Table 7 based on their utility as i) Higher the better (HB) and ii) Lower the
Better (LB).
Two major types of workload that are used in any research are synthetic and real workloads.
This research has used real workloads in the form of BIM models available at reliable
sources. Two or more workloads can contain different number of objects with varying
details and features packed within a BIM model of same size. Therefore, these workloads
have been classified primarily into six different types based on their model size regardless
of number of objects. Afterwards, an averaging characterization method has been used to
workout mean number of objects in any of these types. Two different types of services are
executed by the workload as i) update (collective of write and synchronize) and ii) fetch.
4.5 Validation and evaluation
Analytical modelling and actual measurement based techniques are used for the
validation and evaluation of the proposed model by two different sets of experiments. One
set of experiments validates and compare fine-grained trust evaluation and coarse-grained
trust evaluation based on CAIQ dataset. The other set of experiments evaluates risk based
service selection strategy using CAIQ dataset and BIM data models. The testbed details
have been presented in chapter 5. The values of resources and runtime parameters are
extracted and compared with empirical and practical results for the validation and
evaluation. The detailed experimentation setup and results have been presented in
chapter 6.
4.6 Summary
This chapter has described the details of a two phase research methodology used in
this research to solve the problem of adaptive trust-aware brokerage in cross-cloud
federation. A cloud-to-cloud trust framework has been adopted with i) Trust bi-
directionality ii) Composite trust iii) Delegation control and iv) Context awareness as its
74
basic principles. Afterwards, a quantifiable review of the already available TMSs for
conventional and inter-cloud architectures has been presented. The analysis is aimed to
verify their applicability to the cloud-to-cloud trust paradigm. Various shortcomings have
been observed in the current research for fulfilling the basic requirements of trust within
cross-cloud federation. Therefore, a novel approach towards trust management in cross-
cloud federation has been proposed. This proposed approach has been implemented and
verified using applied research with analytical-empirical methodology. Details of testbed
design and experimentation are presented in subsequent chapters.
75
Chapter 5
5 System Design and Architecture
76
5.1 Introduction
This chapter discusses the empirical-analytical design and provides details of the
entire trust-aware brokerage model. The proposed model is implemented as a broker based
Clouds4Coordination (C4C) [179] system. This broker named Cloud Federation Broker
(CFB) is a trusted centralized entity responsible for administrating the entire brokerage
model. C4C is a cross-cloud federation system developed as a tool to enable collaborative
computing among members or disciplines of Architecture/Engineering/Construction
(AEC) industry. Three novel approaches are implemented within the CFB to support
trusted resource exchanges between disciplines of C4C system.
A number of other entities are also present in the entire system that may appear in different
roles within the entire federation. For instance, a CSP can either be present in the role of a
home CSP or a foreign CSP depending on its interaction with the Cloud Service User
(CSU). All entities within the federation interact with each other either directly or
indirectly. Only the interactions relating to trusted resource exchanges and performance
are considered a part of the proposed model e.g. the interactions between a CSP and the
broker. All other interactions, for example, Cometcloud framework native calls are
considered out of scope for this research.
Any interaction within the system can be broadly categorized into either a one-time
interaction or a recurring interaction. Whenever a CSP joins the federation, it is required
to register itself with the broker providing its credentials and the CAIQ report endorsed by
CSA. This CAIQ assessment report is utilized to evaluate the individual trustworthiness of
the respective CSP. This individual trust is then utilized in all further interactions until and
unless there is a significant change in the CAIQ assessment endorsed by CSA.
There are four inline modules that constitute the CFB, namely i) Profile Management ii)
Resource Management iii) Transaction Management and iv) Trust Management modules.
One auxiliary module named “Cloud Genie” is present in the CSP infrastructure and
interacts with the CFB. Working details for all modules are briefly described, however,
major focus of this chapter has been on the Trust Management module and its components.
The Trust Management module implements the proposed trust evaluation approaches as
77
Conjunctive Accumulation of Trust (ConAccT), Numerical Accumulation of Trust
(NAccT) and Cooperation Threshold Estimation (CTE). Both ConAccT and NAccT
approaches stem from a different theory of trust, with the former providing fine-grained
trust evaluation suitable for highly challenging and large scale competitive environments.
The later, NAccT approach provides coarse-grained trust evaluation based on numerical
calculus and has been further been extended as a risk based service selection approach.
These approaches are validated by use case strategy for a real world application scenario
taken from AEC industry of UK.
The proposed approaches aim to address the challenges associated with the trust in cross-
cloud federation that have been discussed in the previous sections. The composite nature
of federated services has been completely apprehended in proposed approaches. Moreover,
the trust evaluation of the composite service as function of its composition represented in
a graph based structure makes it completely adaptable to the changing dynamics of the
federation. Whenever a CSP joins or leaves the active transaction, at any level of
federation, the trust values of the entire service composition are recomputed to keep up
with the changes in the service structure. The proposed CFB acting as a third party control
entity has also significantly resolved the problem of unilateral delegation of trust within
the federation.
5.2 Empirical system design
This section discusses the design of the proposed trust-aware brokerage model from
the empirical angle. The proposed model has been implemented as a trusted broker based
C4C federation system in which various AEC disciplines participate for collaborative
computing. The Cloud4Coordination system has been developed using CometCloud
autonomous federation framework, which is an overlay federation engine to support large
scale distributed applications. The components of the proposed model are depicted in
Figure 14 with details of the entire system given in the following sections.
Cloud4Coordination federation
Construction projects are a complicated activity involving many diverse professions
and organizations. These organizations range from Small and Medium Enterprises (SMEs)
to large multinational corporations that collaborate over the life-cycle of project. These
78
organizations usually participate in the construction project for different time frames, and
in the meanwhile, they contribute variable amounts and types of data, or sometimes no data
at all, to the project. In such a context, the federation is used to enable collaboration
between various disciplines i.e. designers, suppliers and facility managers etc. for a range
of design and construction tasks.
Figure 14: Abstract illustration of proposed system
For any project, each of these disciplines join the C4C system (realized using the
CometCloud system) by sharing their data from their own data center or cloud. The key
challenge in the C4C project is the creation and management of the federation space
through CometCloud, where discipline specific service providers can join and leave at any
moment of time during the project lifetime without any preliminary evaluation (i.e.
assessment of their trust). The process of enabling a new discipline to join the federation
has risks implications which need to be mitigated in order to prevent project failure. In the
C4C federation, each site participating in the project must support a local cloud
environment. Each discipline has a CometCloud deployment with one master (agent) and
several workers, where masters receive project tasks from other disciplines and workers
execute tasks and return results to local masters. Each master locally hosts a project model
formed from Industry Foundation Classes (IFC) objects, a data format used in the
engineering and construction sector.
79
The coordination mechanism in the C4C system is based on propagating events to the
relevant discipline, i.e. disciplines participating in the project are notified when a new
project is created. When a project creation notification is circulated, a master retrieves and
updates the project and then creates a new version of the project on the local cloud. The
entire federation is managed by a “Federation Manager” (FedMgr) which is in fact the
owner of the project (i.e. home cloud). This federation manager represents the organization
that creates the project and can always retrieve the latest version of the project. A key stage
of the C4C process is when a new discipline is added to the project and to the federation.
Here, the FedMgr requests the broker to establish trustworthiness of the new discipline
before inducting this new discipline in the project. Once a discipline qualifies the given
criteria, and is added to a project, the broker keeps track of its performance during the
course of entire project. This entire mechanism of a discipline’s trust evaluation and
selection is discussed in subsequent sections.
5.2.1.1 System entities and their roles
A number of different entities that constitute the C4C based cross-cloud federation
system are described as follows. These entities may appear in different roles under different
circumstances and interact with each other influenced by certain rules that govern the
federation.
AEC Organization / Discipline / Cloud Service Providers – In the context of C4C
system every AEC organization or discipline is the owner of multiple artifacts
generated for the purpose of a project. The generated artifacts or data may be hosted
within a private cloud, or in some instances, resources from a multiple CSPs may
be used. Increasingly, various CSPs can be involved, requiring support for merging
and federation of data sets representing different parts of a BIM model
(APPENDIX - B). Any discipline represented by a CSP may appear in the
federation in any of the two roles of home CSP known as FedMgr or the foreign
CSP. The home CSP is the one primarily responsible for starting the project on the
consent of cloud service user.
Cloud Service User / Project owner – A Cloud Service User (CSU) or the owner of
project is the entity responsible for either – (i) identifying the requirements for the
80
project (i.e. the types of capabilities that need to be supported); (ii) carrying out
operational management of the AEC project; (iii) managing interactions across the
various entities involve in an AEC project. This may include individuals or group
of users and organizations that opt out for services from an AEC organization. A
CSU is connected to the home CSP through its service without any intervention
from the cloud federation broker.
Cloud Security Alliance – Recommendations and strategies from Cloud Security
Alliance (CSA) are used as a trust source of audit assessment and evidence for the
proposed trust evaluation approaches. CSA offers the CAIQ/CCM framework for
cloud security assessment, auditing and certification named as CSA STAR
program. Using this certification mechanism ensures that a common approach is
used to compare multiple cloud providers. The certification levels proposed by the
CSA are also recognized within the community, ensuring that a new provider
interested in federation can support pre-defined set of security requirements. The
details of CSA STAR certification program are given in section 2.8.
Cloud Federation Broker – Trust-aware interactions between different AEC
organizations participating in the federation are administrated by this Cloud
Federation Broker (CFB). This is done by facilitating the participants of the
federation with anticipated trustworthiness and risk estimation before collaborating
in a project. The broker-agent “Cloud Genie” is installed in the premises of each
successfully registered discipline provider. Broker and its agent are responsible for
starting the federation process, on request from the Federation Manager, across the
various disciplines that are involved in the project. If a new discipline or provider
is to be included in the project, it has to be registered and assessed by the broker.
Moreover, in case of trust dissemination, enforcement, control and compliance, a
broker is a trustworthy choice. A risk aware broker encourages the CSPs to have
higher confidence in federation as interaction decisions are authentic and reliable
instead of peer recommendations
81
5.2.1.2 System workflow and interactions
The C4C federation system contains multiple entities interacting with each other to
support the entire workflow of the proposed system as illustrated in Figure 15. The
federation consist of multiple disciplines, each offering a set of different services or
capabilities for the project. The typical C4C process starts when FedMgr engages others
disciplines to coordinate on a certain project and keeps on adding or removing as desired.
However, the proposed architecture extends this mechanism to include a request from
FedMgr to the CFB and a reply from CFB to FedMgr regarding selection of discipline
from the list of registered disciplines. This request is initiated by FedMgr every time a
discipline is to be added to the project.
Each discipline interested in joining the federation has to be registered with the CFB by
providing its credentials (name, endpoint, metadata, authentication information etc.) and
its CAIQ assessment endorsed by CSA. This CAIQ assessment for every discipline is
further fed to the Trust Representation process where necessary information in the form of
trust parameters is extracted as discussed in section 5.2.2.4. These trust parameters are
input to the individual trust evaluation process (section 5.3.2), which evaluates the CAIQ
based trust for any given discipline. These three processes i.e. registration, trust
representation and individual trust evaluation are one time processes during the
membership of any discipline with the CFB.
Once a discipline is a registered participant of the federation, it can participate in a project
by leasing or acquiring its resources (or capabilities) as and when required. The CFB keeps
track of available resources offered by a discipline with the help of a broker agent present
within the discipline’s cloud infrastructure. This agent helps the broker to maintain a
Federated Resource List within the Profiler, containing a discipline wise list of resources
that are either Waiting to Acquire (WTA) or Ready to Lease (RTL). A WTA is a resource
demanded by any discipline that is required by the project and has not yet been matched.
An RTL is an additional resource offered by a participant of a federation and has not yet
been matched. Usually, a discipline generating a WTA is a part of an ongoing project and
a discipline generating RTL is not a part of a project but announcing of its capabilities are
to be taken onboard.
82
Any discipline, requiring an additional capability or resource generates a Request for
Resource (RFR) to the FedMgr. The entire process of engaging a new discipline to the
project with requisite resources is as follows.
Figure 15: System design and interaction of entities within the federation
The FedMgr upon receiving a RFR generates a request add_new_discipline {x, trid,
criteria} and forward it to the CFB. Here ‘x’ is any discipline required in project,
trid is the project identification number and is null for the first time when the
federation is yet to be created, criteria and threshold is any attribute-value pair for
the required resource, including trust, risk and competence values.
This RFR is directed to the Transaction Manager, which verifies the availability of
matching resource(s) and respective providers from the Federated Resource List.
Multiple eligible providers for discipline ‘x’ from the Profiler repository that fulfil
the criteria mentioned in the incoming request are forwarded to the Trust Manager.
The Global Trust Evaluation service within the Trust Manager now evaluates the
anticipated values of trust-aware decision metric (use of any of the proposed
approaches from section 5.4 to 5.6) of the requesting service as it is going to be
based on its dependency on each candidate resource. All possible service
83
compositions with eligible disciplines are passed to the Decision Support in the
transaction module.
After service compositions are received at the Transaction Manager, it may fetch
additional details e.g. overall capacity of the requisite disciplines. This may
facilitate comparative decision across multiple variables (if needed)
complementing the trust, risk and performance criteria. The available capacity at
any time instance ‘t’, however, is not considered as it may fluctuate in the meantime
the decision is made. In any case this list of service compositions is forwarded to
the Federation Manager.
The federation manager is free to choose the best possible service composition and
generates a Request to Engage (RTE) for that given discipline to engage it in the
project. A new transaction is generated whenever a RTE is not associated with any
ongoing transaction (i.e. trid value is null). On the other hand, if the RTE contains a
transaction identity, this resource exchange is termed as a sub-transaction of that
particular transaction. This entire mechanism starting from the generation of RFR
till the engagement of resource(s) by a RTE is a recurring process with respect to
any participant of federation.
Adding new discipline to the federation also engages the ‘cloud genie’ on the
requisite discipline to monitor the performance during the course of the project and
update the broker with the performance of the discipline in a timely manner. Every
time a project is finished the broker computes the competence of the discipline
based on the performance reported by the broker.
Cloud Federation Broker
This section presents a detailed architecture of the proposed Cloud Federation Broker
(CFB). A brief description of internal components of proposed broker is as follows.
5.2.2.1 Profile Management
This is the basic module responsible for maintaining profile for each CSA STAR
certified CSP registered within the federation. The process of registration signifies that a
CSP accepts the terms and conditions of the collaborative computing paradigm and abides
84
by the rules that govern the use of broker services. Figure 16 depicts the internal working
and flow of information when a CSP interacts with this module and its underlying
processes. This module has following four processes.
Figure 16: Profile Management processes and their interactions
Registration – Every CSP at the time of registration submits the CSA certified
CAIQ assessment along with its credentials such as login information, CSP
endpoint URL, service(s) URL, service(s) type etc. to Registration process.
Afterwards “Cloud Genie” is installed in the premises of a successfully registered
CSP.
Authentication – Every interaction of a CSP with the broker requires authentication
and authorization by this service.
Profiler – All events and activities pertaining to a CSP are recorded by this service
to build respective profiles for audit and accountability purposes.
Trust Representation – This service is initialized once a CSP submits its CSA
certified CAIQ assessment to the broker. Initial trust parameters based on CAIQ of
each CSP that join the federation for the first time is extracted by this service.
Details of these parameters can be found in subsequent sections.
85
5.2.2.2 Resource Management
This module is responsible for maintaining all available resources within the
federation. This module has following two processes as shown in Figure 17.
Figure 17: Resource manager details and interaction with other modules
Biddings – This service is responsible for maintaining a list of all Ready to Lease
(RTL) and Waiting to Acquire (WTA) offers from different CSPs. A RTL from a
CSP means the required resource is available for exchange with any CSP. A WTA
from a CSP means a resource is required by the requesting CSP. The bidding
service keeps a list of all RTA and WTA offers so that it can be matched to respective
demand.
Monitor – This service also collaborates with “Cloud Genie” which submits the
available resource(s) and their respective SLA initially and updates periodically or
in case of any change.
5.2.2.3 Transaction Management
This module is responsible for executing, managing, maintaining and closure of all
relationships between peers of the federation. This module has following two services.
86
Lease Transaction service – responsible for maintaining a list of all transactions.
Each transaction is related to a participating CSP as either the home transaction or
as the foreign transaction. Any transaction may pass through four stages during its
lifetime as i) initiated ii) engaged iii) in progress iv) terminated
Compare and Recommend – Each WTA request is matched to its corresponding
RTL request and matched according to any specific criteria set by the requesting
CSP. This criterion, for example, may consist of resource type and trust level, but
can be varied to include other parameters accordingly. The recommended matches
are then forwarded to the requester CSP.
5.2.2.4 Trust Management
Trust definitions – This service is responsible for interacting with the user to fine-
tune the trust parameters for trust evaluation.
Individual trust evaluation – This service is responsible for evaluating individual
trust of a CSP based on its initial assessment provided at the time it joins the
federation. The details of this evaluation are further discussed in section 5.3.2.
Global trust evaluation – This service computes the anticipated trust of a composite
service requested by the CSU. This global trust value can be based on any of
proposed trust evaluation approaches as discussed in sections from 5.4 to 5.6
relative to the given circumstances and requirements of the resource exchange.
5.3 Trust evaluation approaches – Analytical design
This section presents the details for trust evaluation approaches implemented within
the Trust Management module of CFB. Trust evaluation is performed as a two-step
process, with a one-time trust evaluation of a CSP whenever it joins the federation. The
second step is a recurring process in which trust of CSP is utilized to compute an overall
global trust of the composite service. The outcome of individual trust evaluation is an
opinion based representation of confidence in a CSP while the global trust represents the
overall trust of the delivered service adaptive to its dynamic composition.
87
Trust representation
The approach for the CAIQ assessment is based on the notion that each CSP joining
the federation must be registered and level-II certified by CSA STAR. Every answer in the
CAIQ assessment of that CSP is stored in a shared repository on the basis of its respective
control group.
Table 8: Symbols and representation
Symbol Representation p Positive declaration q Negative declaration un unanswered na Not applicable N Total Applicable ρ Average Positiveness δ Average Negativeness 𝕆 Opinion ζ confidence λ belief γ disbelief φ uncertainty ε Initial expectation T Individual trust T’ Dependency trust T Composite trust
Further to this, for each control group the values for p, q, na and un is evaluated and stored
in a repository. This leads to trust evaluation on the basis of the stored information. A list
of symbols and their representation is given in Table 8.
Trust evaluation
For an individual trust evaluation based on the assessment of a CSP, each control group is
represented as an opinion, and modeled as a subjective belief (beta distribution and
Dempster-Shafer belief theory [92]) extended to support CAIQ assessment. This extended
approach allows the elements of “Subjective Probability” based evidence space to be
combined with “subjective logic” based opinion space. An opinion space is a quadruple
based on the parameters belief λ, disbelief γ, uncertainty φ, and initial expectation ε. The
overall trust of CSP’s assessment (λ, γ, φ, ε) is then defined as
, , , T .
88
Contrary to the Dempster-Shafer theory, in Bayesian trust models, trust is interpreted as a
subjective probability such that the trust value of an entity is based on currently available
evidence along with the prior subjective knowledge.
The consideration of the prior knowledge allows the user to integrate their dispositional
trust in the model e.g. in case of recommendation or feedback based models. However, in
case of trust based on attribute assessment regarding a CSP in CCF, knowledge regarding
a CSP’s behavior prior to joining the federation is not much helpful. Instead, there should
be some other mechanism to evaluate the trust based on the amount of current evidence
available regarding that CSP i.e. the dispositional trust should be based on the total number
of CAIQ declarations that are applicable in any case.
Moreover, the ‘opinion space’ allows to deal with trust evaluation for federation when there
are situations that have uncertainty attached to their belief i.e. they are not binary events.
The beta density function for Bayesian representation of trust as subjective probability is
indexed by two parameters α and β. Given pr as the probability of occurrence of events,
the beta (α, β) distribution for binary events (ε = 0.5) can be expressed using a gamma
function Γ as:
( ) 11( ; , ) (1 )( ) ( )
given 0 1, 0, 0
with 0 if 1 and 1 if 1
f pr pr pr
pr
pr pr
(1)
1Expected value = ( ) . ( ; , ).
0
1 ( ) 11. . (1 ) .( ) ( )0
E pr pr f pr dpr
pr pr pr dpr
(2)
CAIQ declarations being non-binary events, cannot be directly handled by the classical
Bayesian probability based trust models. Therefore, for non-binary events (when ε=[0,1]),
89
0
0
2
2(1 )
p p p
q q q
(3)
Given p is the total number of positive declarations, p0 is the prior knowledge for
expectation of p, q is the number of negative declarations and q0 is the prior knowledge for
expectation of q. The dispositional structure of CAIQ [186] with N =(r + s) as the total
number of declarations that are applicable as prior evidence, when taken into account gives
the following results.
0
0
2 (1 )
2 (1 ) (1 )
p qp
N
p qq
N
(4)
From Eq. (3) and (4), α and β can now be given as follows.
2 (1 )
2 (1 ) (1 )
p qp
N
p qq
N
(5)
The expected value of overall trust can thus be given as
2 (1 )( )
2 (1 ) 2(1 )(1 )
p qp
NE prp q p q
p qN N
(6)
Which can be further resolved to
2 ( ( ))
( ) 2 ( ( ) 2(1 )( ( ))
2 ( ( ))
( ) 2( ( )) ( ) 2( ( ))
pN N p q
p q N N p q N p q
pN N p q
p q N N p q p q N N p q
(7)
( )
[( ) 2( ( )]( )
2( ( )) ( ) ( ).
( ) 2( ( )) ( ) 2( ( ))
pN p q
p q N N p q p q
N p q N p q N p q
p q N N p q p q N N p q
(8)
90
Based on the parameters belief λ, disbelief d, doubt φ, and initial expectation ε, the overall
trust of CSP’s assessment (λ, γ, φ, ε) is defined as T (λ, γ, φ, ε) = λ + φ.ε. Mapping .
to E(pr) gives the following.
.( ). .
( ). 2.( ( )]
( ).1 .
( ). 2.( ( ))
p N p q
p q p q N N p q
p q N
p q N N p q
(9)
And thus λ and φ can be finally given as follows.
.( ).( ). 2.( ( )]
( ).1
( ). 2.( ( ))
where ,
.( )
( ). 2.( ( )]
and 1
p N p q
p q p q N N p q
p q N
p q N N p q
p
p q
N p q
p q N N p q
q
p q
(10)
Finally, E(pr) can be given as
( ) ( ). 1 .( ) 2( ( )) ( ) 2( ( ))
p N p q p q N
p q p q N N p q p q N N p q
(11)
Therefore, for all ε < 1, the extended opinion space for CAIQ based trust is summarized as
follows.
1
(12)
91
where ,
and
( )
2 ( ) ( )
p
p q
q
p q
N p q
N p q N p q
(13)
In the equation (13) ρ is the average positiveness of a control group and δ is the average
negativeness of group. Both ρ and δ are calculated on the basis of p and q for each group.
A control group is said to have zero trust value given p + q = 0. Confidence, ζ, is calculated
based on N, p and q, given N= (p+q+un) - na. The overall trust T of a CSP is the average
opinion of all groups selected for any given transaction.
In order to elaborate the concept, consider CSPs S, A, B, C and Q having values of N, p, q
and un as specified in Table 9 computed from their respective CAIQ assessment. A three
dimensional graphical illustration of these trust parameters for individual CSPs is presented
in Figure 18. Belief is represented on X-axis, disbelief on Y-axis and uncertainty on Z-
axis. Among these representative CSPs, Q is top rated CSP as having the maximum trust
value.
Table 9: Individual trust representation of five CSPs
N p q un λ γ ϕ T
S 264 234 30 0 0.8864 0.1136 0 0.8864 A 295 200 95 0 0.6780 0.3220 0 0.6780 B 295 200 30 65 0.8679 0.1302 0.0019 0.8698 C 255 100 100 55 0.4989 0.4989 0.0022 0.5011 Q 219 175 19 25 0.9010 0.0978 0.0012 0.9132
However, when comparing all CSPs on a precise level, taking into account the detailed
belief system, S is considered the best suitable CSP as having the maximum belief and no
uncertainty in trust value. This difference in perspective of utilizing the trust evaluation is
the basis for three different approaches of trust evaluation as given in subsequent sections.
92
Figure 18: Representation of individual trust values of CSPs
5.4 Conjunctive Accumulation of Trust (ConAccT)
This section describes the proposed Conjunctive Accumulation of Trust (ConAccT)
approach for CAIQ enabled cross-cloud federation. ConAccT is a novel approach utilizing
rules of inference defined in Subjective Logic [187] based ‘opinion space’ taking into
account a graph based service dependency model for evaluating cumulative trustworthiness
of a composite service. The details of this approach including the trust representation and
trust evaluation are mentioned in the following section.
Representation as service dependency model
In conventional cloud computing model, the trustworthiness of a CSP solely depends
on the behavior of its services and attributes of its underlying system. Trust evaluation in
cloud federation is challenging as different cloud providers concurrently strive to deliver a
service to the end user. As this service is dependent on multiple providers, arranged in a
specific hierarchy, its trustworthiness must reflect the behavior of this chain of providers
and their complex dependency relation [6]. This dependency relation when taken into
account assures that trust decisions are authentic and adaptive to the dynamics of the
federation.
Keeping in view a simple example depicted in Figure 19, a service S has its dependency
on resources from CSP A, which is further dependent on B and C. Both B and C are equally
93
dependent on Q. Here S is the root node and is directly dependent on A and indirectly
dependent on many others including the leaf node Q.
Figure 19: A composite service with singular and concurrent relations
5.4.1.1 Dependency relations in composite services
In federated services, the dependency between service components may result from a
relationship formation due to sharing of resources with each other at any level of the cloud
service model. Such a dependency can be defined as follows.
Definition 1 – In composite services, the fact that trust of a service is dependent on
the trust of its provider and the trust of all its succeeding sub-providers is termed as trust
dependency. Given the composite service S and V as a set of sub-providers of S, and f being
a subjective logic function as defined in equation (14), f(S) is given as:
( ) ( )f S f S V (14)
This dependency may be direct, or otherwise transitive forming a chain of dependency in
any given transaction. For example, if a CSP A offering a service SA to the consumer leases
a resource from CSP B, it is said that “A depends on B” represented as A B. Similarly, if
CSP B leases a resource from CSP C for the same service, it is said that “A depends on B
and B depends on C” thus forming a chain of transitive dependency. Keeping in view the
above statements, two types of dependency relations corresponding to the resource
federation are identified and are elaborated as follows.
Singular dependency – A service SA at SaaS layer is offered from a CSP A to the
customer. SA is dependent on another service SB from CSP B. This is termed as
singular dependency and is denoted as ds(AB)
Concurrent dependency – A service SA at SaaS layer is offered from CSP A to the
customer. Service SA is using additional service SB from CSP B and SC from CSP C.
94
This dependency of SA on both B and C at the same time is termed as concurrent
dependency and is denoted as dc(SB,C)
5.4.1.2 Service Dependency Graph
A Service Dependency Graph (SDG) represents the dependency structure of composite
service with the following definitions.
Definition 2. An SDG is a directed graph DG = (V, E, R) with V being a finite set of
vertices, E being finite set of directed edges and R being the set of dependency relations
i.e. singular and concurrent. In SDG, each vertex v ∈ V is a service and e ∈ E is a directed
edge given ∀e = (v1, v2), where v1, v2 ∈ V and v1 is the requestor and v2 is the granter vertex
and v1 is the predecessor of v2 and v2 is the successor of v1.
Definition 3. In SDG a service v1 ∈ V is said to be dependent on service v2 ∈ V given
e = (v1, v2) ∈ E or p = (v1, v2) ∈ P, given P is a directed path in SDG with v1 being the start
vertex and v2 is the ending vertex thus forming a transitive dependency, i.e. if v1 v2, v2v3
then v1v3.
Definition 4. In SDG, the entry vertex without any predecessors is the root of an SDG
and the composite service delivered to the end user whereas the leaf is the exit vertex
without any successors. A SDG may have at least one or more leaves.
Based on these definitions, a representation of composite service can be given as
SDG = (V, Ep, Es, Rp, Rs) (15)
Where
V = {vi | vi = root/leaf and root > vi or vi > leaf}. In a SDG, there is only one root but one or more leaves.
Ep = {Epi} and Epi is a set of predecessors of vi, i.e. Epi = {pi,j | pi,j and vi ∈ V and pi,j vi}
Es = {Esi} and Esi is a set of successors of vi, i.e. Esi = {sij | vi and si,j ∈ V and vi si,j}
Rp represents a set of dependency relations between Ep and V, which includes ds(vi si) and dc(vi si,sj).
Rs represents a set of dependency relations between V and Es, which includes
ds(vi si) and dc(vi si,sj).
95
Algorithm: Create subgraph(s) from Service Dependency Graph Input: A SDG Output: All possible edges within the graph, primary subgraph,
internal subgraph(s), root node, leaf node(s), internal node(s)
1 Begin: 2 Let the service dependency root be S and leaf be Q 3 Create stacks all_sub_graph, pri_sub_graph,
internal_sub_graph 4 Push S into pri_sub_graph and mark as visited 5 for each successor u of S do 6 Push u into pri_sub_graph 7 Push pri_sub_graph into all_sub_graph 8 for each internal node i of internal nodes do 9 Push i into internal_sub_graph 10 for each successor j of i do 11 Push j into internal_sub_graph 12 Push internal_sub_graph into all_sub_graph 13 return all_sub_graphs, root_node, leaf_node, internal_nodes 14 end:
Trust evaluation for composite services
The proposed approach evaluates global trust of S as a factor of trust from all its
successors. At the start of this process with given node(s) V, the entire SDG is processed
from the root S to the terminal Q for generating all possible subgraph(s) using the proposed
algorithm. The algorithm runs with a complexity O(|V|+|n|-1), where n is the number of
subgraphs computed so as to get Ep and Es for V and to mark V for obtaining its dependency
trust. This dependency trust is going to be the composition of a node’s own trust value and
its successor’s dependency trust which in turn is composed from trust of their immediate
successors.
Following the same traversal, the SDG terminal is finally processed. For Q, Ep = {ϕ} as
having no further dependencies, it is established that '( ) ( )T Q T Q , where T’ is the
dependency trust and T is the individual trust of a given CSP derived from equation (12).
Further to this, evaluation requires visiting the chain of successors of Q i.e. Es = {B, C, A,
S} such that this traversal is representative of the dependency relation between all nodes.
Since both B and C have individual single dependency on Q, their respective dependency
trust must reflect the singular dependency.
96
Step 1: '( ) ( )
Step 2: '( ) ( ) '( )
Step 3: '( ) ( ) '( )
'( ) ( ) '( )
Step 4: '( ) ( ) '( )
'( ) '( ) '( )
Step 5: '( ) ( ) '( )
T Q T Q
T B T B T Q
T C T C T Q
T AC T A T C
T AB T A T B
T A T AB T AC
T S T SDG
T ATS
(16)
As node A is dependent on both B and C simultaneously, its respective dependency trust
must reflect the concurrent dependency on both B and C. The overall dependency trust of
S is eventually the sequential dependency trust of S on A. All trust dependencies in this
graph (both singular and concurrent) can be computed in this way and the global composite
trust value SDGT for the SDG in Figure 19 can be finally obtained. This entire traversal is
presented as a step by step process in equation (16), having ‘ ’ and ‘’ as singular and
concurrent trust operators defined in the further sections.
The consolidated results computed from the traversal of SDG are presented in Table 10
and illustrated in Figure 20. The results presented in each row of Table 10 refer to each
step of equation (16) with the final row giving the composite trust for service S. The results
presented in Table 10 are further elaborated with the underlying details of trust evaluation
for both singular and concurrent dependency in the following sections.
Table 10: Composite trust for service S as evaluated by ConACCT
Node Predecessors Successors Dependency Resolution
λ’ γ’ φ’ ε’ T’(node)
1 Q B,C None Q’ = Q 0.901 0.0978 0.0012 0.99 0.9022
2 B A Q B’=ds(BQ) 0.7833 0.2153 0.0014 0.9801 0.7847
3 C A Q C’=ds(CQ) 0.4508 0.5479 0.0013 0.9801 0.4521
4 A S B, C A’=dc(AB’,C’) 0.4188 0.5809 0.0003 0.9703 0.4191
5 S None A S’=ds(SA’) 0.3713 0.6285 0.0002 0.9606 0.3715
97
5.4.2.1 Singular dependency trust
According to the subjective probability theory, forming an opinion about an object
dependent on another object must be the result of combining their individual opinions in
such a way that new opinion reflects the truth of both simultaneously [188]. The
dependency trust of a singular structure such as AB or AC etc. is proposed to be
evaluated by means of singular trust operator ‘ ’ as follows.
,( ) ( ) ( )T x T x T y (17)
when T(x) = T (λx, γx, φx, εx) and T(y) = T (λy, γy, φy, εy), T’(x) is given by T(λx,y, γx,y, φx,y,
εx,y) and is computed as follows.
(1 ) (1 )`
, 1
,
(1 ) (1 )
, 1
,
x y x y x y x yx y x y
x y
x y x y x y
x x y x x yx y x y
x y
x y x y
(18)
Figure 20: Composite trust for service S
98
Considering the CSPs B, C and Q from Table 9, and their dependency structure as depicted
in Figure 19, the trust values computed by equation (17) are given in Table 11 and
illustrated in Figure 21.
Table 11 Singular dependency trust for CSPs
5.4.2.2 Concurrent dependency trust
Trust evaluation of concurrent structures can be viewed as an abstraction of combining
opinions for a single object in such a way that reflects both opinions in a fair and equal
way. The proposed method to evaluate dependency trust T’ for such concurrent structures
is proposed to be evaluated by means of concurrent trust operator ‘’ as follows.
,( ) ( ) ( )T x T x T y (19)
when T(x) = T (λx, γx, φx, εx) and T(y) = T(λy, γy, φy, εy), T’(x) is given by T(λx,y, γx,y, φx,y,
εx,y) and is computed as follows.
Node(s) λ’ γ’ φ’ ε’ T’ B’=d(BQ) 0.7833 0.2153 0.0014 0.9801 0.7847 C’=d(CQ) 0.4508 0.5479 0.0013 0.9801 0.4521 AB’=d(AB’) 0.5314 0.468 0.0006 0.9703 0.5320 AC’=d(AC’) 0.3059 0.6935 0.0006 0.9703 0.3065
Figure 21: singular dependency based trust
99
( ),
( ),
,
( ),
2
where 0 and ,
y yx xx yk
y yx xx yk
yxx yk
y y y yx x x xx yy yx x
y yx xk k
(20)
and for 0
,1
,1
, 0
,1
k
yxx y
yxx y
x y
yxx y
(21)
As illustrated in Figure 19, CSP A is dependent on both CSP B and C forming two distinct
dependencies as AB and AC which can be derived from equation (17) as T’(AB) and
T’(AC). However, the dependency trust of A must reflect both its dependencies on B and C
in fair and equal way. For instance, consider the trust parameters for A, B and C in Table 9
and their dependency as depicted in Figure 19. The trust values λ’, γ’, φ’ and ε’ are
computed by equation (20) (since k0) to give T’ = λ + φ.ε. The derived trust values are
given in Table 12 and illustrated in Figure 22.
Table 12 Concurrent dependency trust for CSP
Node(s) k λ’ γ’ φ’ ε’ T’
A’=d(AB’,C’) 0.0012 0.41878 0.58092 0.0003 0.9703 0.41907
100
Result significance and selection criteria
The proposed ConAccT approach aims to deliver a representative view of the
trustworthiness of composite services delivered to a consumer by virtue of CCF. The
significance of the obtained results is apparent when used as a CSP selection criteria before
engaging in a transaction. When comparing multiple SDGs it is recommended to make a
fine-grained comparison regarding their global trust values. Considering a case when two
SDGs have the same composite trust value, the one with the greater belief gets a preference
over the other. If both have the same belief values, the selection criteria should be based
on their disbelief values with a lower disbelief as more preferable than the other one. Given
an SDGx with ( , , , )Tx x x x x and SDGy with ( , , , )Ty y y y y , they are comparable in
the following cases:
Case 1 – If |λ’(SDG1) – λ’(SDG2)| < e1 and |γ’(SDG1) – γ’(SDG2)| < e2, SDG1 and
SDG2 are equivalent, if and only if 0 < e1 and e2 << 1 given e1 and e2 are thresholds
as specified by service requester. For example, considering service level threshold
0 < e1 and e2 < 0.002, two SDGs, SDG1 having T’= (0.7215, 0.2785, 0, 0.99) and
SDG2 having T’ = (0.7215, 0.2775, 0.001, 0.99) are considered equivalent and
comparable for their trust level.
Figure 22: Concurrent dependency based trust evaluation
101
Case 2 – If λ’x – λ’y > 0, SDGx is more preferable.
Case 3 – If λ’x – λ’y = 0 and γ’x - γy’ < 0, SDGy is more preferable.
5.5 Numerical Accumulation of Trust (NAccT)
This section describes the proposed Numerical Accumulation of Trust (NAccT)
approach for CAIQ enabled cross-cloud federation. NAccT is an extension to the classical
trust models in which trust is a Single Numerical Expected Value (SNEV) of confidence
in a CSP [76, 142, 169]. The proposed approach utilizes a Service Dependency Graph
(SDG) along with the evaluated SNEV to estimate the cumulative trustworthiness of a
composite service. This assures that trust decisions are adaptive to the dynamics of the
federation and not merely the static averaging or consensus of trust values of multiple
CSPs.
An SDG for a service A is a directed acyclic graph (DAG) with service providers as
nodes and their relationship as directed edges as illustrated in Figure 23.
Figure 23 Dependency graph for service A in NAccT
Service A constitutes of direct dependencies on service B and E, from which B has multiple
dependencies on C and D, forming a transitive dependency of A on C and D. Given a set
of cloud providers P in SDG and their relation given by R P P with ( , )a b R giving
a dependency "a depends on b", all relationships in SDG for service A given as {(A,B),
(B,C), (B,D), (A,E)} can be termed as direct relations if and only if there exists an edge, but
no vertex between a and b.
In order to resolve all (specifically transitive) dependencies of service A and to evaluate
the composite trustworthiness for this SDG, evaluate graph for all possible induced
102
subgraphs such that { }y
SDG sdgs s with each subgraph {( , , ),( , , ), ( ,..., ),....}y
ssdg s i y s j y s y is
set of path(s) from root node (s) to a leaf node y Y given ‘S’ as the service,‘s’ is the
starting node, ‘y’ is the terminal/leaf node and ‘i, j,…’ are the intermediate nodes.
Considering a service with three leaves, for instance, there must be three subgraphs with
varying lengths and weights depending on the edges and vertices. For the given SDG for
service A, three transitive subgraphs can be given by {(A, B, C), (A, B, D), (A, E)}.
Given the individual trustworthiness of each CSP as the weight of the vertex, and edge
weight as accumulated trust of relationship between two adjacent vertices a and b, given
by Trust (a, b), the cumulative trust for any subgraph nSDGs can be given as
1
1
1
1
( )
where paths in SDG=1
( )( )
where paths p in SDG > 1
y
s ss
y ys
s ss
pp
c c
T SDGc c
(22)
Where is the number of vertices in the subgraph ySDGs . p is the negative weight of the
path ‘p’ and is inversely dependent on the number of vertices involved in the path such that
.... 11 2 3 n . The longer the path of trust, the weaker is the relationship. When all
SDGs for a service S have been traversed, the overall global trustworthiness of the service
can be evaluated as
( )Y
yS y s
y
T SDG sdg (23)
where y is the weight of the subgraph ‘y’ given as the indegree of ‘y’ for this subgraph.
5.6 Cooperative threshold estimation (CTE)
Trust evaluation by itself only forecasts the future behavior of entity and can be
applied to varying situations and phenomena. However, the outcome of this situation
(interaction after taking a decision based on trust) must be taken into consideration for any
next perceived interactions. This outcome may be based on subjective opinion or any
103
objective outcome about this interaction. This section describes an enhancement to NAccT
approach by integrating the trust evaluation mechanism with performance monitoring of
the cloud providers to enable a risk based approach. This risk is evaluated as a Cooperative
Threshold Estimation (CTE) [189] score to anticipate success of future collaborations
among the members of federation.
Risk and collaboration
Collaboration gives rise to a variety of issues causing concern and anxiety for
administrators [190], and hence a range of different factors is integral to the success of
collaboration. In recent years, much research has been directed at gaining an understanding
of these challenges involved in inter-organizational collaboration. Contributions are based
on a wide range of theoretical perspectives including corporate, social, economic,
institutional, and political [191] and cover a range of collaborative relations including, for
example, public-private partnerships, industrial networks, and strategic alliances [192,
193].
The issue of trust in particular has been reported to be significant and hence important in
the nurturing of collaborative processes. Indeed, literatures across the fields of psychology,
economics, sociology, and organizational sciences focus on trust in the contexts of both
intra- and inter-organizational collaboration [194, 195]. Risk being a fundamental concept
central to the notion of trust [196] can specifically be considered as the fear that a partner
may inadvertently or deliberately act as opportunist and as a consequence may jeopardize
performance of collaboration. A prominent concept closely associated with risk is the
notion of vulnerability [45, 197], which closely relates to the “trustor” being susceptible to
similar risks due to its dependency on the “trustee” to deliver a business function. The
existence of trust helps to reduce risk of opportunistic behavior whenever it is viewed as a
mechanism of inducing confidence. On the other hand, risk taking in turn supports a sense
of trust whenever initial expectations are fulfilled [91]. Therefore, collaborations are
argued to be particularly beneficial when initiated on the basis of trust among entities [198].
Moreover, centered on the notion of profitability and mutual gains, the organizations are
generally fascinated by the concept of cooperation. There are situations within which
cooperation is necessary and others where, although cooperation may be necessary, there
104
is a choice about who to cooperate with. Considering context as a situation with reference
to point in time relative to a certain organization, every collaboration is inherently context
dependent. Collaboration is likely to succeed if the organizations trust each other on the
basis of perceived risks, competence and importance or gain of this collaboration.
The objective of this CTE approach is to estimate the extent to which a CSP ‘x’ is useful
to the project ‘α’ in a given context ‘c’. Anticipated project Cooperation Threshold (CT),
as evaluated by the proposed CFB is given by
_ ( , , )_ ( , , ) ( , , )
_ ( , ) ( , )
Perceived Risk x ccooperation threshold x c I x c
Perceived Competence x c T x cc
(24)
Where Perceived_Risk (x, α, c) is the overall risk assessment based on the proposed method
of utilizing trust as an enabler for risk based project cooperation, Perceived_Competence
(PC) is based on performance metric of the given CSP ‘x’ by trust-aware broker along with
‘T’ being any temporal consideration(s) resulting from previous results if any, thus
formulating a ‘CSP Profile’. Whereas ‘I’ is the importance of collaboration as anticipated
by the entities participating in the project ‘α’ in a given context ‘c’.
Perceived risk
A CSP profile is a consolidated view of the trust and competence of a given discipline
registered with the broker. Initially, when a discipline joins the federation and has no
performance history available, its profile is only based on a trust evaluation as a result of
CAIQ assessment and the level of certification achieved by the CSP collectively known as
its trust posture given as
1
__
perceived risktrust posture
(25)
The perceived risk of a CSP is inversely proportional to its trust evaluation i.e. risk
increases with a decrease in trust value and vice versa.
Perceived competence
Perceived competence is the measurement of overall performance of a given CSP in
context of the tasks assigned to it at any given time. This competence, for instance, can be
based on response time for a single task, or job completion time for batch processing task.
105
Since C4C is a batch processing system, therefore, two levels of competence can be
evaluated i.e. the entire project completion time as project competence and task based
competence for individual disciplines. The project competence or project performance
measures the success of identifying a group of disciplines through the proposed
approaches. Task based competence of each discipline is based on number of objects
assigned to it in the form of BIM model (APPENDIX - B), and the time taken by the
discipline to process them.
To support this form of perceived competence, each site is said to have a local C4C
environment, which enables other sites to interact with it. In the workflow presented in
Figure 24, discipline A creates the C4C project which is formed from Industry Foundation
Classes (IFC) objects stored at a local client A. Once a model is complete as per instructions
of project owner, it is to be updated in the shared federation space so that other disciplines
may work on it as per their role in the project. For example, considering discipline A as
Architects, that have finalized an outline of a building as required by the customer, it should
now be updated to the civil engineering discipline C or any other. All sites participating in
the project are notified about the new project being created (based on role(s) in the project).
The update process starts when the local client A pushes the model data into the cloud. The
cloud owned by discipline A writes the new objects and their metadata on the disk.
Afterwards a metadata HashMap is created and advertised in the shared federation space.
All sites receive the update notification and update the metadata for the C4C project. This
process of update is represented in Figure 24 by Update Start and Update Finish. The
amount of time taken from U1 to U6 is called the update time and is the given by
_ _ _u p d a te tim e w ritin g tim e sy n c h ro n iza tio n tim e . This process is similar in case of
more than two sites participating in the project. For the lifetime of a project, whenever a
discipline N updates a model with a newer version ‘v’ in the shared space similar process
is followed. This results in a similar round of notifications and metadata propagated to
interested site(s). All sites eligible for version ‘v’ updates their metadata with this new
version so that they may fetch that version at any later stage if required.
106
Figure 24 Perceived competence metric and workflow
In the lifetime of a project, a participating discipline may want to retrieve an updated
version of model to work on that. This process of retrieving the model is termed as Fetch
process. Figure 24 shows a civil engineering discipline C interested to work on the model
updated by discipline A recently. The fetch process from discipline C is represented to
occur between ‘Fetch Start’ and ‘Fetch End’ in Figure 24. This includes finding a location
for all the objects marked as updated in the metadata, requesting the discipline(s) for
updated model(s), receiving model(s), merging all the different updates and writing the
model in the shared space. Once a merged model is created for a given discipline, it is
returned to the local client for that discipline for requisite working and updates. A model
fetched at the local client is afterwards updated with any changes and may afterwards be
updated to the shared space following the update model process. The total time it takes for
fetch process starting from F1-F8 in Figure 24 is denoted by the fetch time. Update and
fetch times are utilized as individual perceived competence of any given disciplines as
_ _ _ _
__
number of IFC objects processedperceived competence
time taken (26)
The global time metric called “aggregated-time-to-complete”(ATTC) for a project is a sum
of all these individual times: (i) object writing time Tw, (ii) metadata synchronization time
107
Ts and (iii) fetch overhead time Tf, for the entire project i.e. ATTC = Tw + Ts + Tf . The
ATTC measurement is applied to the entire project and is counted towards the success of
collaboration in terms of performance. The global project performance is then given by
_ _ _ __
num objects processed in projectproject performance
ATTC (27)
5.7 Summary
This chapter has discussed the architectural and analytical design for adaptive trust-aware
brokerage model as it has been implemented as a part of this research. The proposed broker
has implemented three different trust-aware approaches considering two different
perspectives on trust. All approaches consider federated services as graph based structures
representing their dependencies and dynamic connectivity. Some federated services are
based on competitive, and challenging providers thus only requiring fine-grained results
for trust-awareness based on security capabilities. This phenomenon has been considered
in the Conjunctive Accumulation of Trust (ConAcct) approach giving a detailed trust
assessment and decision support for the participants. Another approach named Numerical
Accumulation of Trust (NAccT) provides a coarse-grained approach to trust, where trust
can afterwards be used as a component of other decision making approaches with different
parameters in order to make a concluding choice. Another approach, Cooperation
Threshold Estimation (CTE) has been proposed that makes use of NAccT based trust profile
and competence of the cloud provider to enable a risk based selection of federated services.
108
Chapter 6
6 Experimental Evaluation
109
6.1 Introduction
This chapter presents the experimental validation of the proposed adaptive trust-aware
brokerage model. This model has been deployed as broker based Clouds4Coordination
federation system in which the broker acts as a centralized administration authority to
overlook the matters of federation. This chapter describes the implementation details from
system setup and evaluation perspectives. Analytical modeling and actual measurements
based techniques has been used for experimental evaluation. The proposed ConAccT,
NAccT and CTE approaches have been implemented within the broker to verify their
applicability in the C4C federation system. Both ConAccT and NAccT approaches are
validated and compared against a set of CAIQ self-assessment reports of various CSPs
published in CSA STAR registry [29]. The CTE approach has been validated against the
similar set of CAIQ reports added with the real performance data gathered using real life
BIM models collected from various reliable sources. The CTE approach has been
compared for its efficiency with performance based selection approach in [179], and trust
based approach in [76] and random selection to depict lack of any approach. Details of
BIM modeling and BIM workloads used in this research can be found in APPENDIX - B
and APPENDIX - C respectively. The proposed model is deployed in Google cloud
platform with 9 platforms depicting different cloud providers (disciplines) and 1 platform
as the proposed trust-aware broker. These experiments have been performed keeping in
view the trust and performance metric set forth in section 4.4.
6.2 Experimental Setup
The proposed broker is implemented in CPython and executes as a service within a
Linux based system. SQLite serves as a repository to store all data related to this system
including CSP details, trust evaluation and transaction details, etc.
Table 13: System specification for experimentation
Type OS Compute Memory Storage Available Zones
(no. of nodes)
CSP Nodes Ubuntu
16.04.5 LTS 1 vCPU 3.75 GB 10 GB
europe-west2-a (3) us-east1-b (3)
asia-east1-a (2) europe-west4-a (1)
Trust-aware CFB ------ same as above ------ asia-south1-a (1)
110
Provision of service and signing SLA with the end user or the consumer is not in the scope
of the broker and is the responsibility of the individual CSP. The virtualized environment
has been deployed in Google cloud datacenter in multiple zones across the globe. All
compute nodes are running with the specifications given in Table 13.
6.3 Experimentation and Results
For experimental evaluation of proposed approaches various trust and performance
metrics are selected as highlighted in section 4.4.2. The experiments have been conducted
in two phases. In the first phase, the experimentation related to ConAccT and NAccT
approaches has been performed using only the trust metric. The purpose of comparing these
two approaches is to validate them for CCF model. This validation considers the case when
selection is only based on trust regardless of the underlying characteristics of resource
exchanges or any other performance metric. As and when applicable both approaches are
compared with Simple Trust Aggregation (STA), in which the composite trust is merely
the average trust of all CSPs involved in the service composition. In the second phase,
experimentation related to CTE approach i.e. an extension of NAccT approach, utilizing
both trust and competence metric has been performed. The proposed model has been
deployed using 10 nodes with one trust-aware CFB node and nine CSP nodes. In case of
first set of experiments related to ConAccT and NAccT, all CSPs are considered equivalent
in competition with each other. In case of second set of experiments i.e. CTE approach,
these nine CSPs represent 3 different categories of C4C disciplines with each category
having three competitors. All nodes have different trust and performance levels. Details
of these experiments are given in the subsequent sections.
Experiments for ConAccT and NAccT
Analytical modeling and actual measurements based techniques have been used for
these experiments. Both ConAccT and NAccT approaches are validated against a set of
CAIQ self-assessment reports of various CSPs published at the CSA STAR registry [29].
These experiments have been performed with the following aims.
111
To identify generic trends in trust values as CSPs collaborate on demand to form
composite services.
To identify the necessity for considering dependency structures when evaluating
trust for services composed of more than two CSPs.
How to forecast the best possible arrangement of CSPs with maximum utilization
and longstanding relation?
What is the most preferable dependency structure (ds, dc or random) to consider for
CSPs with uncertainty in their beliefs?
A service Sx is delivered by a CSP x having trust value E(S). In order to maintain its user-
facing SLA for this service, the CSP requires additional resources/services from other
CSP(s). To follow the scope of these experiments, SLA is considered to be comprised of
only the threshold for trust level of the service S i.e. E’(S) threshold. The nature of
resources/services exchanged among these peers is out of the scope of these experiments.
Consider the service Sx composed of n components namely S1, S2, S3, S4 … Sn, such that
each component can be delivered by any CSP as they have similar level of Quality of
Service (QoS) and other parameters except their trust level. These foreign CSPs
interconnect their infrastructures in a random formation to support service delivery to home
CSP. Each formation termed as “transaction” randomly consist of singular and parallel
dependencies as defined in section 5.4.1. The best possible transaction is then selected to
offload the respective service components to continue service delivery to the user.
6.3.1.1 Experiment 1
In this experiment, the service S is considered from the home CSP x having trust value
E(x) = E(S) = 0.99. A total of 5 foreign CSPs are considered to be collectively delivering
the same service S such that not a single CSP is resourceful enough to deliver it alone. In
order to maintain SLA with the customer(s) while expanding its service footprint, the home
CSP is interested in knowing the best possible formation in which the service components
to be mapped to the foreign CSPs such that a threshold limit of Emin(x) = 0.9 and E’(S) =
0.8 is enforced in all iterations where x is any CSP.
112
The initial values of trust parameters b, d, u and E for each CSP is iterated with an
optimistic initial expectation of 0.99 for each CSP. The overall contribution of this
experiment is twofold (i) to depict the method of identifying an optimal combination of
CSPs feasible for any composite service formation, (ii) to establish the necessity of taking
the dependency structure into account when evaluating trust for composite services.
Figure 25 shows the trend for all trust parameters of CSPs involved in transactions. The
trend shows the values for belief, disbelief, uncertainty and atomicity in composite
formation. The arrangement of CSPs in transaction having less scattered trust parameters
is the optimal formation, i.e. transaction 2. The closer the values are to each other, the better
the chances for a transaction to continue scaling by adding more CSPs. Figure 26(a) shows
the trend for composite belief and expectation. Figure 26(b) depicts the variation in
uncertainty for all given formations. Figure 26(c) depicts the overall composite trust for
service S composed of 5 CSPs combined in random formations. The most preferable
formation is the one with maximum trust value i.e. transaction 2.
Figure 25: Trend for all trust parameters for 5 CSPs in random
113
Despite the fact that all transactions involved the same CSPs, there is a variation in
trust values for all arrangements. This non-linearity is due to the proposed trust dependency
model without which a linear model would have only depicted the same result in any case.
The same has been depicted in Figure 27 comparing the results for NAccT, ConAccT
approaches. Since NAccT approach has used a single numerical value in evaluating trust,
therefore the results are less random than ConAccT approach. Figure 28 depicts a
comparison between ConAccT, NAccT and STA approaches on the basis of composite trust
value and maximum uncertainty faced in any transaction. Figure 28 (a) shows that STA
Figure 26: (a) Composite belief and expectation (b) variation in uncertainty and (c) disbelief for experiment 1
(a)
(b) (c)
114
based trust is always the same for every transaction due to the presence of same CSPs.
Hence this method of obtaining trust as the average of all CSPs’ trust values is not feasible
for dynamic environments like CCF. Moreover, as depicted in Figure 28 (b), ConAccT
approach has successfully identified the service compositions that have uncertainty in their
trust values by making them the least possible of all choices. This however, is not the case
with NAccT and STA approach as they lack any consideration for manipulating trust under
uncertainty. In both ConAccT and NAccT cases transaction 2 is the best possible option for
federating service S.
Figure 27: Comparison of NAccT and ConAccT approaches for experiment-1
Figure 28: Comparison of NAccT, ConAccT and STA approach in case of (a) composite trust and (b) maximum uncertainty for experiment 1
115
6.3.1.2 Experiment 2
Experiment 1 is repeated with a threshold Emin(x) such that 0.9 ≥ E(x) ≥ 0.8 and E’(S)
≥ 0.7 is enforced in all iterations. A total of 8 candidate foreign CSPs are selected with
qualifying E(x) ≥ Emin(x) participate in delivering the composite service S such that they
are randomly arranged in a way that E’(S) ≥ 0.7. Figure 29 depicts the composite belief,
expectation, disbelief and uncertainty in case of 8 CSPs randomly arranged for composite
service formation. As evident from Figure 30 Transaction 1 is the preferable service
composition among all, from both NAccT and ConAccT perspectives as more CSPs can
be added to this transaction without violating the threshold values.
Figure 29: (a) Composite belief and expectation (b) Composite disbelief and (c) variation in uncertainty for experiment 2
(a)
(c) (b)
116
Figure 30: Comparison of NAccT and ConAccT approaches for experiment-2
6.3.1.3 Experiment 3
For this experiment, two CSPs providing service S1 and S2 with uncertainty in their
trust values are considered. Both CSPs lease resources from the same set of foreign CSPs,
but in different random formations. As is evident from Figure 31 and Figure 32, there is a
decline in the composite belief of both CSPs. However, uncertainty of both services has
eventually declined when they have leased resources from other CSPs. This indicates a
potential benefit for CSPs to join the CCF. The proposed ConAccT approach has
successfully emphasized the benefit of taking part in CCF from the perspective of trust.
Since the other two approaches NAccT and SAT does not directly deal with uncertainty,
they are unable to highlight such benefit.
Figure 31: (a) Composite expectation and belief (b) Composite uncertainty for
117
6.3.1.4 Experiment 4
In order to evaluate the effect of the singular dependency structure on the composite
trust evaluation, a service S with maximum trust value is considered (i.e. b=0.99, d=0.01
and u=0). The service S and its corresponding foreign CSPs are bound to lease a resource
from only one other CSP such that a chain of sequential dependency is formed as shown
in Figure 33.
A total of 5 foreign CSPs qualify with E(x) ≥ 0.9 to maintain E’(S) ≥ 0.8. A significant
observation from Figure 35 is that sequential dependency results in a sudden decrease of
trust values. Moreover, sequential dependency makes an increase in uncertainty even when
there is no uncertainty in individual trust evaluation of CSPs. Figure 34 represents the
composite trust from both NAccT and ConAccT perspective with transaction 3 being the
preferred choice in both cases.
Figure 33: A chain of singular dependency
Figure 32: Composite trust based on NAccT and ConAccT for experiment 3
118
6.3.1.5 Experiment 5
In order to evaluate the effect of the concurrent dependency structure on the composite
trust evaluation, a service S is considered to be offered from random CSPs with different
initial trust values. Only the corresponding home CSP of service S can lease resource from
other CSPs such that a concurrent dependency is formed as shown in Figure 36.
Figure 34: Composite trust as of NAccT and ConAccT
Figure 35: (a) composite trust and (b) uncertainty for singular dependency federation
(a) (b)
119
Figure 36: A mesh of concurrent dependency
A total of 6 foreign CSPs qualify with E(x) ≥ 0.9 to maintain E’(S) ≥ 0.8. A significant
observation considering the results in Figure 37 and Figure 39 is that concurrent
dependency results in a gradual decrease of trust values and no uncertainty is introduced
in trust relationship. Moreover, as evident from the comparison in Figure 38, both NAccT
and ConAccT approaches give similar results in case of composite trust i.e. transaction 1
as the best. However, NAccT approach does not provide any analysis regarding the
uncertainty of CSPs.
Figure 37: Composite belief and expectation for concurrent dependency federation
120
6.3.1.6 Experiment 6
Experiment 5 is repeated by utilizing a service S from different CSPs with uncertainty
in their trust values. Each of these CSPs interact with 6 foreign CSPs to evaluate the effect
of concurrent dependency structure on the composite belief and expectation as shown in
Figure 40. A significant observation from Figure 41 is that concurrent dependency results
in a gradual decrease of trust values and also a gradual decrease in uncertainty is observed
in trust relationship. Figure 42 compares the composite trust evaluation from both NAccT
Figure 39: Composite (a) uncertainty and (b) trust for concurrent dependency federation in experiment 5
(a) (b)
Figure 38: Composite trust as evaluated by NAccT and ConAccT for experiment 5
121
and ConAccT approaches. It can be observed from Figure 42 that the transaction having no
uncertainty i.e. Transaction 4, has gradually started to gain importance and can continue
for longer duration than other transactions.
Figure 40: Composite belief and expectation for concurrent dependency in experiment 6
Figure 41: Composite (a) trust (b) uncertainty for joint dependency federation in experiment 6
(a) (b)
122
Experiments for CTE – The risk based service selection
These experiments are performed for validation of CTE approach and have used the
trust and performance metrics as defined in Table 7. Each experiment is considered a
project initiated by a project owner with varying workloads. Every project ‘P’ (groups of
tasks P={T1,T2,T3,….Tn} where T=update | fetch) is considered to be complete when each
discipline has at least i) made one update to the project and ii) fetched one version of final
model from the shared space.
For every task Tn, the total time of completion is considered as defined in [179] with the
exception that the time epoch starts when the data arrives at the discipline instead of starting
when the user sent it. This epoch ends when the FedMgr receives notifications of
completion from all the subscribers for the assigned tasks. Moreover, individual
performance of each subscriber (discipline) is also measured for every task. This time
epoch starts when the task is received at the discipline and ends when the task is finished
and reported back to the publisher via notify. For each site the risk is the interval t between
going offline due to security vulnerability and is considered proportional to its CAIQ based
trust. Higher the trust, higher will be the time between going offline and less the risk to the
project. The detailed methodology of performing experiments and measured parameters
has already been discussed in section 4.4.
Figure 42: Composite trust for concurrent dependency as evaluated by NAccT and ConAccT in experiment 6
123
This set of experiments aims to evaluate the i) performance efficiency and ii) accuracy of
the proposed approach. The efficiency of the system is measured in terms of its
performance in different scenarios of varying workloads i.e. model sizes of i) 300KBs
mentioned as default model ii) 689KBs iii) 956KBs iv) 3.44MBs v) 5.34MBs and vi) 8.94
MBs (APPENDIX - C). The accuracy of a system depends on the fact that the system is
successfully able to identify reliable and trustworthy service compositions. Moreover, it
will also be observed how the perceived risk is related to delays in the project.
6.3.2.1 Experiment 1
This experiment explains the basic working of the proposed approach. In this
experiment the usage of cooperation threshold in selection of a discipline provider is
elaborated. A total of three disciplines i.e. Architecture, Civil Engineering and Structural
Engineering are required to execute a construction project. For each discipline, three
different providers (a total of 9 discipline providers) are offering their respective expertise
with perceived competence, trust and cooperation threshold values. A discipline provider
(or a CSP) is said to be the best possible selection having the lower threshold value.
Figure 43: CTE based service selection for a construction project
Among all the available disciplines, the Architects-2, Civil-3 and Structural-2 are the best
CTE based selection in their respective domains as shown in Figure 43. Moreover, in case
the selection is made on the basis of performance [179], Architect-2, Civil-1 and Structural-
1 are the possible choices. Also, in case of SNEV based trust [76], the Architects-1, Civil-
2 and Structural-3 are the best choices.
124
6.3.2.2 Experiment 2
In this experiment, the discipline providers are selected based on their Cooperation
Threshold values. These disciplines are then engaged to execute the different types of
workloads as described in previous section. For each discipline, out of all candidate
discipline providers, the one with the best cooperation threshold value is selected i.e.
Architects-2, Civil-3 and Structural-2 to measure the overall project completion time as
depicted in Figure 44. This aggregated time to complete (ATTC) is the cumulative time of
parsing and writing the model in the federation space given in Figure 45 (a) along with the
synchronization of metadata in Figure 45 (b) and fetching time is depicted in Figure 46 (b)
for all disciplines.
Figure 44: (a) Aggregated time to complete (b) aggregated project performance in case of CTE based selection
The ATTC given in Figure 44 (a) depicts that time taken for smaller sized model is the
greater than the time taken for large sized model. The project performance in terms of
aggregated competence of all disciplines is shown in Figure 44 (b). This figure depicts
lesser performance of project in case of smaller models and higher performance as the
model size is increased. Figure 45 (a) depicts the cumulative model writing time for the
project with the maximum time taken by the smallest model and the lowest writing time
for the largest model size. Figure 45 (b) shows the metadata synchronization time for all
workloads and depicts a linear increase in the synchronization times. The writing time and
synchronization time is collectively depicted as update time in Figure 46 (a) showing
aggregated update times for the given workloads. The overall fetch time for the given
(a) (b)
125
workloads as depicted in Figure 46 (b) also follow a linear approach scaling from lower to
higher times with respect to increase in size of the model.
Figure 45: Aggregated (a) model writing and (b) metadata sync time for project
Figure 46: Aggregated (a) update and (b) fetch time for project
6.3.2.3 Experiment 3
In this experiment, the disciplines are selected based on their performance score [179]
they acquired from any projects that they have been a part of. The selected providers are
engaged in the project to execute the different types of workloads as described in
section 6.3.2. For each discipline, out of all candidate discipline providers, the one with the
best performance is selected i.e. Architect-2, Civil-1 and Structural-1 to measure the overall
project completion time as depicted in Figure 47 (a) and performance as depicted in Figure
47 (b).
(a) (b)
(a) (b)
126
Figure 47 (a) shows ATTC for the workloads given to disciplines selected on the basis of
performance. It can be observed that less time is taken for smaller sized model and
maximum time is taken to complete the project with large sized model. The project
performance in terms of aggregated competence of all disciplines shown in Figure 47 (b)
depicts the less number of objects processed per milliseconds in case of smaller models
and larger number of objects per milliseconds as the model size is increased. Figure 48 (a)
depicts the cumulative model writing time for the project with the maximum time taken by
the smallest model and the minimum writing time for the largest model size.
This variation in writing time is due to the number of objects that are processed by the
worker and then transferred in the form of a file to be written to disk. The writing time and
synchronization time is collectively depicted as update time in Figure 49 (a) showing
aggregated update times for the given workloads. The overall fetch time for the given
workloads as depicted in Figure 49 (b) however follow a linear approach scaling from
lower to higher times with respect to increase in size of the model.
Figure 47: (a) ATTC (b) project performance in case of competence based selection
(a)
(b)
127
Figure 48: Aggregated (a) writing and (b) metadata sync time for project
Figure 49: Aggregated (a) update and (b) fetch time for project
6.3.2.4 Experiment 4
This experiment is performed by selecting disciplines based on their individual trust
values [76] without considering their connectivity in any service composition. The selected
providers are engaged in the project to execute the different types of workloads as described
in section 6.3.2. For each discipline, out of all candidate discipline providers, the one with
the highest trust value is selected i.e. Architects-1, Civil-2 and Structural-3 to measure the
overall project completion time as depicted in Figure 50.
Figure 50 (a) shows ATTC for the workloads given to disciplines selected on the basis of
trust values. It can be observed that less time is taken for smaller sized model and maximum
time is taken to complete project with large sized model. The aggregated project
performance of project as shown in Figure 50 (b) depicts less number of objects processed
(a) (b)
(a) (b)
128
per milliseconds in case of smaller models and larger number of objects per milliseconds
as the model size is increased. Figure 51 depicts the cumulative model writing time and
metadata synchronization time for project with the maximum time taken by the smallest
model and the lowest writing time for the largest model size. Figure 52 shows the overall
update time and fetch time for different models. It shows that most of the variations in
project performance has been due to the writing time. This variation in writing time is due
to the setup time that each discipline takes to start processing a model. This setup time is
the same for each model despite the number of objects and size of the model. Smaller
model has to wait a similar amount of time as compared to large model, but the number of
objects processed in smaller models is less eventually depicting their lack of performance.
Figure 50: (a) ATTC and (b) project performance in case of trust based selection
Figure 51: (a) model writing and (b) metadata synchronization time for project
(a) (b)
(a) (b)
129
Figure 52: (a) update and (b) fetch time for trust based selected project
6.3.2.5 Experiment 5
This experiment is performed by selecting disciplines randomly i.e. one of the
disciplines is selected based on trust, the other one is based on CTE and the third one is
based on perceived competence. Figure 53 (a) shows ATTC for the workloads given to
disciplines selected on random basis. It can be observed that time taken to complete a
project increases with the increase in size of the model. The aggregated project
performance as shown in Figure 53 (b) depicts less number of objects processed per
milliseconds in case of smaller models and larger number of objects per milliseconds as
the model size is increased. This variation is due to the difference in performance
capabilities of the collaborating disciplines.
Figure 53: (a) ATTC (b) project performance in case of random selection
(b) (a)
(a) (b)
130
Figure 54: (a) model writing and (b) metadata synchronization time for project
Figure 55: (a) update and (b) fetch time for trust based selected project
The discipline chosen on the basis of trust may not perform as competently as compared to
the discipline selected on the basis of perceived competence. However, it can be observed
that the overall performance has started to decline as the number of objects is increased.
Figure 54 depicts the model writing and synchronization time. No extreme variations are
observed in the writing and synchronization i.e. update time in Figure 55 (a). The update
time has nearly been same for all model sizes and has not varied with the change in number
of objects thus causing a decline in overall project performance. Total time taken for
fetching the model is depicted in Figure 55 (b). This variation in fetch time contributed in
the increase in performance of the project but to a very limited extent.
(a) (b)
(a) (b)
131
6.3.2.6 Comparison and discussion
The above experiments have been performed to compare the efficiency of the
proposed CTE approach with three different selection mechanisms i.e. the performance
[179], trust [76] and random selection. The idea is to see what effect does the change in
model size has on the CTE based selection i.e. how the CT value varies with the variation
in project scope in case of different model sizes.
Figure 56: Comparison of ATTC in case of all selection mechanisms
Figure 57: Comparison of aggregated project competence in case of all selection mechanisms
132
As is evident from Figure 56, the ATTC for CTE selection has always remained consistent
with the increase in workload size. Comparing the remaining three approaches, the
performance-based selection has performed better than the remaining two i.e. trust based
and random selection in case of all model sizes. However, the ATTC value in these three
mechanisms have increased with the increase in model size.
Moreover, as depicted in Figure 57, with the increase in number of objects that are
processed in a project, the CTE approach has significantly shown better efficiency
(aggregated project competence) than all other selection methods. In case of performance
based selection, a discipline can achieve higher values by collaborating in projects without
being observed for its vulnerabilities and risk to the overall project. Such a discipline may
have gained its performance value by executing shorter duration tasks and has taken benefit
of its ability to complete those tasks before going offline due to a vulnerability. This can
have significant impact on the aggregated competence of a project in case a new project
has variable duration tasks. Meanwhile, selection based only on trust does not guarantee
an in-time completion of project due to lack of performance consideration thus have a high
ATTC value.
Figure 58: Comparison of writing time for all selection mechanisms
Figure 58 presents a comparison of writing time for CTE based selection with performance,
trust and random selection mechanisms. It can be observed from this figure that the CTE
133
approach has taken more time to write small sized workloads as compared to performance
based selection. Also this figure depicts lots of variation in writing times for all selection
criteria as the model size is increased. This variation in writing time is due to the number
of objects received and the level of details for each object processed and written by the
C4C worker.
Figure 59: Comparing metadata synchronization time for all selection mechanisms
Figure 60: Comparing fetch time for all selection mechanisms
134
In case of synchronization times depicted in Figure 59, less time is taken by performance
based selection for small sized model. However, the proposed CTE approach surpasses all
other selection criteria with lesser synchronization times as the model size is increased.
Similarly, the comparison for overall fetch time for all selection criteria is depicted in
Figure 60. All selection mechanisms show a linear increase in fetch time scaling from lower
to higher times with respect to increase in size of the model. The proposed CTE approach
has been consistent in spending a lot less time in model fetching than all other criteria.
Keeping in view the above comparisons, it can be concluded that CTE approach has
successfully been able to identify efficient discipline providers in a C4C federation system.
In some cases, discipline providers might have good efficiency for smaller workload
because of performance manipulations. These providers, if selected, can perform better in
case of smaller workloads but are unable to cope with large workloads. These types of
discipline providers introduce higher risk for the entire project.
6.4 Summary
This chapter details the experimentation setup and results for the proposed trust-aware
brokerage model. The proposed approaches to the trust establishment problem in cross-
cloud federation has been extensively experimented for their effectiveness in providing
correct forecast of trustworthiness of the providers. The ConAccT approach is shown to
have provided a detailed view of the providers’ trustworthiness in a competitive
environment where more than merely a unique number is required to identify the trend
within the provider’s trustworthiness. The NAccT approach has been complemented with
a risk based strategy for selection of services within the cloud federation. A comparative
analysis with state-of-art approaches have demonstrated the efficiency of proposed
approaches to identify participants of federation that can cause potential risks and
unnecessary delays in the projects.
135
Chapter 7
7 Conclusions and Future Work
136
7.1 Conclusions
The problem of trust awareness in cross-cloud federation is unique and challenging
due to the dynamic, heterogeneous and multilevel nature of composite services within the
federation. The necessity of a third party broker for this type of federation is already an
established fact. The proposed work has first highlighted the inevitability and prominence
of a novel trust evaluation model for cross-cloud federation. In order to achieve this
objective, this thesis has first highlighted the theoretical concepts necessary to develop an
understanding of trust in cross-cloud federation. The major focus of this discussion has
been to differentiate the cross-cloud federation from other architectures that are developed
as a mean to enhance the capabilities of conventional cloud computing. A brief discussion
has also been provided to understand trust from both the social and technical perspective
to follow the evolution of trends within trust management. Moreover, a description of
Cloud Assessment Initiative Questionnaire (CAIQ) by Cloud Security Alliance (CSA) as
a suggested source to utilize for this proposed research has also been discussed.
Followed by this preliminary discussion the state-of-the-art in trust management within the
cloud computing paradigm has been discussed. Most of the discussed literature has been
focused on conventional cloud computing, in which a consumer is interested to opt for a
service from only one cloud service provider. Recent trends available in cloud computing
landscape for trust management in multi-cloud and federation architectures has also been
highlighted. The available literature has been classified based on the number of trust
sources it uses to collect the trust indicators. After accumulating all the defined concepts,
a conceptual framework for cloud-to-cloud trust has been presented along with specific
requirements for trust in cross-cloud federation. A consolidated requirement matrix has
also been presented that can help to identify the trust management areas that need to be
aligned with the specific requirements of federation.
Afterwards, the proposed framework has been used to provide a quantitative analysis of
state-of-the-art TMSs to identify their trends and shortcomings. Existing works in trust
evaluation for cloud computing have proved deficient to fulfil the requirements of cloud-
to-cloud trust paradigm. Novel solutions for trust in cross-cloud federation require that the
137
mechanisms underlying the trust and reputation evaluation need to align with the principles
of federation construction.
Following the requirements of cloud-to-cloud trust, the proposed research, therefore, put
forward a novel trust-aware brokerage model that is adaptive to changing structure of
federated services. This model has been implemented as a Clouds4Coordination federation
system and is administrated by a proposed trusted broker to establish and enforce trusted
resource exchanges.
A detailed empirical-analytical design of this trust-aware broker has also been presented
along with various entities, roles and interactions within the C4C system. Two different
perspectives i.e. fine-grained and coarse-grained trust evaluation have been presented.
These perspectives are implemented as three different approaches i.e. Conjunctive
Accumulation of Trust (ConAccT), Numerical Accumulation of Trust (NAccT) and
Cooperative Threshold Estimation (CTE). ConAccT is a fine-grained approach based on
belief calculus and may be useful in case of highly competitive collaborating scenarios
where detailed analysis of trust is decisive for usefulness of cooperation among CSPs.
NAccT is a coarse-grained approach based on numerical calculus and is useful in less
competitive scenarios. NAccT approach is afterwards extended as CTE and utilized with a
competence based approach to evaluate the overall risk of failure in a collaborative project.
The significance of these approaches has been verified by implementing as a trusted broker
based Clouds4Coordination (C4C) system developed for
Architecture/Engineering/Construction (AEC) industry. This C4C system is currently
implemented in United Kingdom in collaboration with Cardiff University, UK and Rutgers
Discovery Informatics Institute (RDI2), USA.
The proposed research has been validated through experimental evaluation of the proposed
approach. The outcome of these experiments has shown that the proposed model is
successful in identifying generic trends in trust as CSPs collaborate to form composite
services. Moreover, benefits of joining a federation in terms of lowering uncertainty in
service provisioning to users has also been identified. The proposed model has been shown
to adapt its trust decisions with the dynamic nature of federation. Moreover, the usability
of trust-aware brokerage has been verified across the C4C system. It has been observed
138
that the trust-aware selection of federation participants when combined with the outcome
of previous interactions gives an advantage over selection based on performance only.
7.2 Future Work
The proposed research can be strengthened in different directions, giving many
opportunities for future work. One of the significant direction is extension of this approach
in case of various composite service deployment strategies i.e. loop, switch etc. Belief
calculus and Bayesian probability based approaches can be utilized to cater for even more
complex and dynamic structures.
Another significant direction is to establish mechanisms for trust evaluation based on any
given context in which resources are being shared. CAIQ/CCM offers two orthogonal
contexts, i.e. technical and strategic to support different trust objective. For example, a
cloud provider may either be interested in leasing a single resource i.e. storage or only
concerned with the attributes related to Disaster Recovery within its peers. These two
different contexts can be evaluated from their respective viewpoint with the support of
CAIQ/CCM.
Moreover, the dynamics of trust bidirectionality in case of cloud-to-cloud trust should be
further explored for detailed analysis of mutual trust establishment among peers. Although,
the approaches available in the literature can be instantiated in both directions however,
their viability in varying scenario of mutual gains/profitability is not verified. A significant
direction is to involve a perspective of selfishness-aware schemes based on game theoretic
or behavioral forecasting approaches.
Also, real time mechanisms for monitoring performance are recommended as a future
direction for the proposed work. For this purpose, prediction-based resource utilization
models can also be utilized to anticipate risk when used in conjunction with trust evaluation
model. Decentralized brokerage model can also be explored for its usability in controlling
unilateral delegation of trust for user data and application. P2P and Blockchain models can
be explored in case of such scenarios to make a user aware of anything not transparent
regarding its data and application.
139
Chapter 8
8 References
140
[1] P. Mell and T. Grance, "The NIST definition of cloud computing," 2011. [2] R. Buyya, R. Ranjan, and R. N. Calheiros, "Intercloud: Utility-oriented federation
of cloud computing environments for scaling of application services," in International Conference on Algorithms and Architectures for Parallel Processing, 2010, pp. 13-31.
[3] N. Grozev and R. Buyya, "Inter‐Cloud architectures and application brokering: taxonomy and survey," Software: Practice and Experience, vol. 44, pp. 369-390, Mar 2014.
[4] V. Massimo, B. Ivona, and T. Francesco, Achieving Federated and Self-Manageable Cloud Infrastructures: Theory and Practice. Hershey, PA, USA: IGI Global, 2012.
[5] D. Villegas, N. Bobroff, I. Rodero, J. Delgado, Y. Liu, A. Devarakonda, et al., "Cloud federation in a layered service model," Journal of Computer and System Sciences, vol. 78, pp. 1330-1344, Sept 2012.
[6] K. Bernsmed, M. G. Jaatun, P. H. Meland, and A. Undheim, "Thunder in the Clouds: Security challenges and solutions for federated Clouds," presented at the 4th IEEE International Conference on Cloud Computing Technology and Science (CloudCom '12), 2012.
[7] R. Chow, P. Golle, M. Jakobsson, E. Shi, J. Staddon, R. Masuoka, et al., "Controlling data in the cloud: outsourcing computation without outsourcing control," in ACM workshop on Cloud computing security, 2009, pp. 85-90.
[8] A. N. Toosi, R. N. Calheiros, and R. Buyya, "Interconnected cloud computing environments: Challenges, taxonomy, and survey," ACM Computing Surveys (CSUR), vol. 47, p. 7, Jul 2014.
[9] CloudSA. (2018, Dec 05, 2017). Cloud Security Alliance. Available: https://cloudsecurityalliance.org/star/
[10] cloudsa, "CSA Security, Trust & Assurance Registry (STAR) - Cloud Security Alliance," 2018.
[11] K. Dolui and S. K. Datta, "Comparison of edge computing implementations: Fog computing, cloudlet and mobile edge computing," in Global Internet of Things Summit (GIoTS '17), 2017, pp. 1-6.
[12] K. Kelly. (2015, 19 September, 2017). The Technium: A Cloudbook for the Cloud. Available: https://kk.org/thetechnium/a-cloudbook-for/
[13] Y. Sakashita, K. Takayama, A. Matsuo, and H. Kurihara, "Cloud fusion concept," FUJITSU Scientific & Technical Journal (FSTJ), vol. 48, pp. 143-150, Apr 2012.
[14] J.-M. Bohli, N. Gruschka, M. Jensen, L. L. Iacono, and N. Marnau, "Security and privacy-enhancing multicloud architectures," IEEE Transactions on Dependable and Secure Computing, vol. 10, pp. 212-224, Jul 2013.
[15] A. J. Ferrer, F. HernáNdez, J. Tordsson, E. Elmroth, A. Ali-Eldin, C. Zsigri, et al., "OPTIMIS: A holistic approach to cloud service provisioning," Future Generation Computer Systems, vol. 28, pp. 66-77, Jan 2012.
[16] E. Carlini, M. Coppola, P. Dazzi, L. Ricci, and G. Righetti, "Cloud federations in contrail," in European Conference on Parallel Processing, 2011, pp. 159-168.
141
[17] D. Petcu, C. Crăciun, M. Neagul, S. Panica, B. Di Martino, S. Venticinque, et al., "Architecturing a sky computing platform," in European Conference on a Service-Based Internet, 2010, pp. 1-13.
[18] P. Pawluk, B. Simmons, M. Smit, M. Litoiu, and S. Mankovski, "Introducing STRATOS: A cloud broker service," in IEEE 5th International Conference on Cloud Computing (CLOUD '12), 2012, pp. 891-898.
[19] RightScale. (2016, July 12, 2017). RightScale. Available: http://www.rightscale.com/
[20] EnStratus. (2015, Dec 11, 2015). EnStratus. Available: https://www.enstratus.com/ [21] Scalr. (2017, July 12, 2017 ). Scalr: The Hybrid Cloud Management Platform.
Available: https://www.scalr.com/ [22] Kaavo. (2017, Aug 01, 2017). Cloud Management Software Available:
http://www.kaavo.com/ [23] A. Foundation. (2017, Sept 05, 2016). Apache LibCloud. Available:
http://libcloud.apache.org/ [24] A. Foundation. (2016). JClouds: The Java Multi-Cloud Toolkit. Available:
http://www.jclouds.org/ [25] A. Foundation. (2016). Apache DeltaCloud. Available:
http://deltacloud.apache.org/ [26] B. Rochwerger, D. Breitgand, E. Levy, A. Galis, K. Nagin, I. M. Llorente, et al.,
"The reservoir model and architecture for open federated cloud computing," IBM Journal of Research and Development, vol. 53, pp. 1-11, Jul 2009.
[27] A. Celesti, F. Tusa, M. Villari, and A. Puliafito, "How to enhance cloud architectures to enable cross-federation," in Cloud Computing (CLOUD), 2010 IEEE 3rd International Conference on, 2010, pp. 337-345.
[28] D. Bernstein, E. Ludvigson, K. Sankar, S. Diamond, and M. Morrow, "Blueprint for the intercloud-protocols and formats for cloud computing interoperability," in Fourth International Conference on Internet and Web Applications and Services (ICIW '09) 2009, pp. 328-336.
[29] P. H. Meland, K. Bernsmed, M. G. Jaatun, A. Undheim, and H. N. Castejón, "Expressing Cloud Security Requirements in Deontic Contract Languages," in 1st International Conference on Cloud Computing and Services Science (CLOSER '12), 2012, pp. 638-646.
[30] V. Nae, R. Prodan, and A. Iosup, "SLA-based operation of massively multiplayer online games in competition-based environments," in International C* Conference on Computer Science and Software Engineering, 2013, pp. 104-112.
[31] H.-J. Hong, D.-Y. Chen, C.-Y. Huang, K.-T. Chen, and C.-H. Hsu, "Placing virtual machines to optimize cloud gaming experience," IEEE Transactions on Cloud Computing, vol. 3, pp. 42-53, Jan 2015.
[32] J. B. Abdo, J. Demerjian, H. Chaouchi, K. Barbar, G. Pujolle, and T. Atechian, "Cloud Federation? We Are Not Ready Yet," in IEEE Intl Conf on High Performance Computing and Communications, IEEE 6th Intl Symp on Cyberspace Safety and Security, IEEE 11th Intl Conf on Embedded Software and Syst (HPCC, CSS, ICESS), 2014, pp. 831-834.
142
[33] J. B. Abdo, J. Demerjian, H. Chaouchi, K. Barbar, and G. Pujolle, "Broker-based cross-cloud federation manager," in 8th International Conference for Internet Technology and Secured Transactions (ICITST '13) 2013, pp. 244-251.
[34] P. Khanna, S. Jain, and B. Babu, "BroCUR: Distributed cloud broker in a cloud federation: Brokerage peculiarities in a hybrid cloud," in International Conference on Computing, Communication & Automation (ICCCA '15), 2015, pp. 729-734.
[35] Y. Demchenko, C. Ngo, C. De Laat, J. A. Garcia-Espin, S. Figuerola, J. Rodriguez, et al., "Intercloud architecture framework for heterogeneous cloud based infrastructure services provisioning on-demand," in 27th International Conference onAdvanced Information Networking and Applications Workshops (WAINA '13) 2013, pp. 777-784.
[36] R. Buyya, S. Pandey, and C. Vecchiola, "Market-oriented cloud computing and the cloudbus toolkit," arXiv preprint arXiv:1203.5196, Mar 2012.
[37] M. M. Hassan, B. Song, C. Yoon, H. W. Lee, and E.-N. Huh, "A novel market oriented dynamic collaborative cloud service infrastructure," in World Conference on Services-II (SERVICES-2 '09) 2009, pp. 9-16.
[38] M. M. Hassan, B. Song, and E.-N. Huh, "A market-oriented dynamic collaborative cloud services platform," annals of telecommunications-annales des télécommunications, vol. 65, pp. 669-688, 2010.
[39] A. Marosi, G. Kecskemeti, A. Kertesz, and P. Kacsuk, "FCM: An architecture for integrating IaaS cloud systems," IARIA, 2011.
[40] G. Kecskemeti, M. Maurer, I. Brandic, A. Kertesz, Z. Nemeth, and S. Dustdar, "Facilitating self-adaptable Inter-Cloud management," in 20th Euromicro International Conference on Parallel, Distributed and Network-Based Processing (PDP '12), 2012, pp. 575-582.
[41] P. Khanna, S. Jain, and B. Babu, "Cloud Broker: Working in federated structures," in 2014 International Conference on Advances in Computing, Communications and Informatics (ICACCI '14), 2014, pp. 1273-1278.
[42] H. Kim and M. Parashar, "CometCloud: An autonomic cloud engine," Cloud Computing: Principles and Paradigms, pp. 275-297, 2011.
[43] I. Marková and A. Gillespie, Trust and distrust: Sociocultural perspectives: IAP, 2007.
[44] D. E. Denning, "A new paradigm for trusted systems," in Workshop on New security paradigms, 1993, pp. 36-41.
[45] D. Gambetta, "Can We Trust Trust?," Trust: Making and Breaking Cooperative Relations, electronic edition vol. 13, pp. 213-237, Feb 1988.
[46] Y. Yamamoto, "A morality based on trust: Some reflections on Japanese morality," Philosophy East and West, vol. 40, pp. 451-469, Oct 1990.
[47] N. Luhmann, Trust and power: John Willey & Sons, 1979. [48] B. Barber, The logic and limits of trust. New Brunswick, NJ: Rutgers University
Press, 1983. [49] O. lagerspetz, Trust. The tacit demand vol. 1: Springer Netherlands, 1998. [50] H. S. James Jr, "The trust paradox: a survey of economic inquiries into the nature
of trust and trustworthiness," Journal of Economic Behavior & Organization, vol. 47, pp. 291-307, Mar 2002.
143
[51] J. B. Rotter, "Interpersonal trust, trustworthiness, and gullibility," American psychologist, vol. 35, p. 1, Jan 1980.
[52] M. Deutsch, "Cooperation and trust: Some theoretical notes," in Nebraska Symposium on Motivation, M. R. Jones, Ed., ed Lincoln, NE: University of Nebraska Press, 1962, pp. 275-319.
[53] R. C. Mayer, J. H. Davis, and F. D. Schoorman, "An integrative model of organizational trust," Academy of management review, vol. 20, pp. 709-734, Jul 1995.
[54] J. D. Lewis and A. Weigert, "Trust as a social reality," Social forces, vol. 63, pp. 967-985, 1985.
[55] M. Granovetter, "Problems of explanation in economic sociology," Networks and organizations: Structure, form, and action, pp. 25-56, 1992.
[56] M. Deutsch, "Trust and suspicion," Journal of conflict resolution, vol. 2, pp. 265-279, 1958.
[57] J. B. Rotter, "A new scale for the measurement of interpersonal trust 1," Journal of personality, vol. 35, pp. 651-665, 1967.
[58] P. Blau, "1964 Exchange and power in social life. New York: Wiley," 1964. [59] J. R. Gibb, Trust: A new view of personal and organizational development: Guild
of Tutors Pr, 1978. [60] S. WOOD, "BEYOND CONTRACT-WORK, POWER AND TRUST
RELATIONS-FOX, A," ed: MCB UNIV PRESS LTD 60/62 TOLLER LANE, BRADFORD, W YORKSHIRE, ENGLAND BD8 9BY, 1975.
[61] L. G. Zucker, "Production of trust: Institutional sources of economic structure, 1840–1920," Research in Organizational Behavior, vol. 8, pp. 53-111, 1986.
[62] R. H. Frank, Passions within reason: the strategic role of the emotions: WW Norton & Co, 1988.
[63] C. Moorman, R. Deshpande, and G. Zaltman, "Factors affecting trust in market research relationships," the Journal of Marketing, pp. 81-101, 1993.
[64] A. Baier, "Trust and antitrust," Ethics, vol. 96, pp. 231-260, 1986. [65] L. T. Hosmer, "Trust: The connecting link between organizational theory and
philosophical ethics," Academy of management Review, vol. 20, pp. 379-403, 1995. [66] J. Dunn, "Trust and political agency," Trust: Making and Breaking Cooperative
Relations, electronic edition, Department of Sociology, University of Oxford, pp. 73-93, 2000.
[67] E. H. Lorenz, "Neither friends nor strangers: Informal networks of subcontracting in French industry," Markets, hierarchies and networks: the coordination of social life, pp. 183-191, 1991.
[68] N. G. Noorderhaven, "Trust and inter-firm relations," 1992. [69] P. R. Milgrom, "Axelrod's" The Evolution of Cooperation"," ed: JSTOR, 1984. [70] T. C. Group. (2016, Feb 12, 2016). Trusted Computing Group. Available:
http://www.trustedcomputinggroup.org/ [71] R. Perez, R. Sailer, and L. van Doorn, "vTPM: Virtualizing the Trusted Platform
Module," presented at the 15th Conference on USENIX Security Symposium, 2006.
[72] N. Santos, K. P. Gummadi, and R. Rodrigues, "Towards Trusted Cloud Computing," presented at the HotCloud, 2009.
144
[73] F. J. Krautheim, "Private Virtual Infrastructure for Cloud Computing," HotCloud, vol. 9, pp. 1-5, Jun 2009.
[74] J. Schiffman, T. Moyer, H. Vijayakumar, T. Jaeger, and P. McDaniel, "Seeding clouds with trust anchors," in ACM workshop on Cloud computing security workshop, 2010, pp. 43-46.
[75] A.-R. Sadeghi, C. Stüble, and M. Winandy, "Property-based TPM virtualization," in International Conference on Information Security, 2008, pp. 1-16.
[76] S. M. Habib, S. Ries, M. Mühlhäuser, and P. Varikkattu, "Towards a trust management system for cloud computing marketplaces: using CAIQ as a trust information source," Security and Communication Networks, vol. 7, pp. 2185-2200, Nov 2014.
[77] A. Nagarajan and V. Varadharajan, "Dynamic trust enhanced security model for trusted platform based services," Future Generation Computer Systems, vol. 27, pp. 564-573, May 2011.
[78] D. Bogdanov, S. Laur, and J. Willemson, "Sharemind: A framework for fast privacy-preserving computations," in European Symposium on Research in Computer Security, 2008, pp. 192-206.
[79] C. Gentry, "Fully homomorphic encryption using ideal lattices," in 41st annual ACM Symposium on theory of computing (STOC '09), 2009, pp. 169-178.
[80] N. P. Smart and F. Vercauteren, "Fully homomorphic encryption with relatively small key and ciphertext sizes," in International Workshop on Public Key Cryptography, 2010, pp. 420-443.
[81] M. Mowbray, S. Pearson, and Y. Shen, "Enhancing privacy in cloud computing via policy-based obfuscation," The Journal of Supercomputing, vol. 61, pp. 267-291, Aug 2012.
[82] M. G. Jaatun, Å. A. Nyre, S. Alapnes, and G. Zhao, "A farewell to trust: An approach to confidentiality control in the cloud," in 2nd International Conference on Wireless Communication, Vehicular Technology, Information Theory and Aerospace & Electronic Systems Technology (Wireless VITAE '11), 2011, pp. 1-5.
[83] M. G. Jaatun, G. Zhao, A. V. Vasilakos, Å. A. Nyre, S. Alapnes, and Y. Tang, "The design of a redundant array of independent net-storages for improved confidentiality in cloud computing," Journal of Cloud Computing: Advances, Systems and Applications, vol. 1, p. 13, Dec 2012.
[84] K. D. Bowers, A. Juels, and A. Oprea, "HAIL: A high-availability and integrity layer for cloud storage," in 16th ACM conference on Computer and communications security, 2009, pp. 187-198.
[85] H. Abu-Libdeh, L. Princehouse, and H. Weatherspoon, "RACS: a case for cloud storage diversity," in 1st ACM symposium on Cloud computing, 2010, pp. 229-240.
[86] I. Uusitalo, K. Karppinen, A. Juhola, and R. Savola, "Trust and cloud services-an interview study," in Cloud Computing Technology and Science (CloudCom), 2010 IEEE Second International Conference on, 2010, pp. 712-720.
[87] L. A. Zadeh, "Information and control," Fuzzy sets, vol. 8, pp. 338-353, Jan 1965. [88] L. A. Zadeh, "The role of fuzzy logic in the management of uncertainty in expert
systems," Fuzzy sets and systems, vol. 11, pp. 199-227, Jan 1983. [89] G. Shafer, A mathematical theory of evidence vol. 42: Princeton university press,
1976.
145
[90] S. P. Marsh, "Formalising trust as a computational concept," PhD PhD Thesis, Department of Computing Science and Mathematics, University of Stirling, 1994.
[91] S. P. Marsh, "Trust in distributed artificial intelligence," presented at the 4th European Workshop on Modelling Autonomous Agents in a Multi-Agent World (MAAMAW '92), Berlin, Heidelberg, 1994.
[92] A. Jøsang, "The right type of trust for distributed systems," in workshop on New security paradigms, 1996, pp. 119-131.
[93] A. Jøsang, "A trust policy framework," presented at the First International Conference on Information and Communications Security ICIS '97 Beijing, China, 1997.
[94] J.-H. Cho, A. Swami, and R. Chen, "A survey on trust management for mobile ad hoc networks," IEEE Communications Surveys & Tutorials, vol. 13, pp. 562-583, Nov 2011.
[95] S. D. Ramchurn, D. Huynh, and N. R. Jennings, "Trust in multi-agent systems," The Knowledge Engineering Review, vol. 19, pp. 1-25, Mar 2004.
[96] T. D. Huynh, N. R. Jennings, and N. R. Shadbolt, "An integrated trust and reputation model for open multi-agent systems," Autonomous Agents and Multi-Agent Systems, vol. 13, pp. 119-154, Sept 2006.
[97] C. Fung, J. Zhang, I. Aib, and R. Boutaba, "Trust management and admission control for host-based collaborative intrusion detection," Journal of Network and Systems Management, vol. 19, pp. 257-277, Jun 2011.
[98] M. G. Pérez, J. E. Tapiador, J. A. Clark, G. M. Pérez, and A. F. S. Gómez, "Trustworthy placements: Improving quality and resilience in collaborative attack detection," Computer Networks, vol. 58, pp. 70-86, Jan 2014.
[99] H. Yu, Z. Shen, C. Miao, C. Leung, and D. Niyato, "A survey of trust and reputation management systems in wireless communications," Proceedings of the IEEE, vol. 98, pp. 1755-1772, Oct 2010.
[100] M. C. Fernández-Gago, R. Román, and J. Lopez, "A survey on the applicability of trust management systems for wireless sensor networks," in 3rd International workshop on Security, Privacy and Trust in Pervasive and Ubiquitous computing (SECPERU '07) 2007, pp. 25-30.
[101] F. G. Mármol, M. G. Pérez, and G. M. Perez, "Reporting offensive content in social networks: toward a reputation-based assessment approach," IEEE Internet Computing, vol. 18, pp. 32-40, Mar 2014.
[102] Y. Wang and J. Vassileva, "A review on trust and reputation for web service selection," in 27th International Conference on Distributed Computing Systems Workshops (ICDCSW '07), 2007, pp. 25-32.
[103] A. Jøsang, R. Ismail, and C. Boyd, "A survey of trust and reputation systems for online service provision," Decision support systems, vol. 43, pp. 618-644, Mar 2007.
[104] J. Sabater and C. Sierra, "Review on computational trust and reputation models," Artificial intelligence review, vol. 24, pp. 33-60, Sep 2005.
[105] D. Artz and Y. Gil, "A survey of trust in computer science and the semantic web," Web Semantics: Science, Services and Agents on the World Wide Web, vol. 5, pp. 58-71, Jun 2007.
146
[106] J. Golbeck, "Trust on the world wide web: a survey," Foundations and Trends® in Web Science, vol. 1, pp. 131-197, Feb 2008.
[107] Y. Zhang, H. Chen, and Z. Wu, "A social network-based trust model for the semantic web," in International Conference on Autonomic and Trusted Computing, 2006, pp. 183-192.
[108] K. M. Khan and Q. Malluhi, "Establishing trust in cloud computing," IT professional, vol. 12, pp. 20-27, Sept 2010.
[109] S. M. Habib, S. Ries, and M. Muhlhauser, "Cloud computing landscape and research challenges regarding trust and reputation," in 7th International Conference on Ubiquitous Intelligence & Computing and 7th International Conference on Autonomic & Trusted Computing (UIC/ATC '10), 2010, pp. 410-415.
[110] A. Ghosh and I. Arce, "Guest editors' introduction: In cloud computing we trust-But should we?," IEEE Security & Privacy, vol. 8, pp. 14-16, Nov 2010.
[111] C. Ngo, Y. Demchenko, and C. De Laat, "Toward a dynamic trust establishment approach for multi-provider intercloud environment," in IEEE 4th International Conference on Cloud Computing Technology and Science (CloudCom '12), 2012, pp. 532-538.
[112] T. H. Noor, Q. Z. Sheng, Z. Maamar, and S. Zeadally, "Managing Trust in the Cloud: State of the Art and Research Challenges," Computer, vol. 49, pp. 34-45, Feb 2016.
[113] S. M. Habib, S. Ries, and M. Muhlhauser, "Towards a trust management system for cloud computing," in 10th International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom '11), 2011, pp. 933-939.
[114] P. Domingues, B. Sousa, and L. M. Silva, "Sabotage-tolerance and trust management in desktop grid computing," Future Generation Computer Systems, vol. 23, pp. 904-912, Aug 2007.
[115] F. Skopik, D. Schall, and S. Dustdar, "Start trusting strangers? bootstrapping and prediction of trust," in International Conference on Web Information Systems Engineering, 2009, pp. 275-289.
[116] S. Park, L. Liu, C. Pu, M. Srivatsa, and J. Zhang, "Resilient trust management for web service integration," in IEEE International Conference on Web Services (ICWS '05) 2005.
[117] S. Song, K. Hwang, and Y.-K. Kwok, "Trusted grid computing with security binding and trust integration," Journal of Grid computing, vol. 3, pp. 53-73, Jun 2005.
[118] S. Song, K. Hwang, R. Zhou, and Y.-K. Kwok, "Trusted P2P transactions with fuzzy reputation aggregation," IEEE Internet computing, vol. 9, pp. 24-34, Nov 2005.
[119] S. D. C. D. Vimercati, S. Foresti, S. Jajodia, S. Paraboschi, G. Psaila, and P. Samarati, "Integrating trust management and access control in data-intensive web applications," ACM Transactions on the Web (TWEB), vol. 6, p. 6, May 2012.
[120] H. Skogsrud, B. Benatallah, F. Casati, and F. Toumani, "Managing impacts of security protocol changes in service-oriented applications," in Proceedings of the 29th international conference on Software Engineering, 2007, pp. 468-477.
[121] H. Skogsrud, H. R. Motahari-Nezhad, B. Benatallah, and F. Casati, "Modeling trust negotiation for web services," Journal of Computer, vol. 42, pp. 54-61, Feb 2009.
147
[122] J. Yao, S. Chen, C. Wang, D. Levy, and J. Zic, "Accountability as a service for the cloud," in IEEE International Conference on Services Computing (SCC '10), 2010, pp. 81-88.
[123] M. Alhamad, T. Dillon, and E. Chang, "Sla-based trust model for cloud computing," in 13th International Conference onNetwork-Based Information Systems (NBiS '10), 2010, pp. 321-324.
[124] M. K. Tripathi and V. K. Sehgal, "Establishing trust in cloud computing security with the help of inter-clouds," in Advanced Communication Control and Computing Technologies (ICACCCT), 2014 International Conference on, 2014, pp. 1749-1752.
[125] R. N. Calheiros, R. Ranjan, A. Beloglazov, C. A. De Rose, and R. Buyya, "CloudSim: a toolkit for modeling and simulation of cloud computing environments and evaluation of resource provisioning algorithms," Software: Practice and experience, vol. 41, pp. 23-50, Jan 2011.
[126] A. G. García and I. Blanquer, "Cloud services representation using SLA composition," Journal of Grid Computing, vol. 13, pp. 35-51, Mar 2015.
[127] K. Bernsmed, M. G. Jaatun, and A. Undheim, "Security in Service Level Agreements for Cloud Computing," in 1st International Conference on Cloud Computing and Services Science (CLOSER '11), 2011, pp. 636-642.
[128] D. Catteddu and G. Hogben, "Cloud Computing Risk Assessment," European Network and Information Security AgencyNovember 20, 2009 2014.
[129] A. Al Falasi, M. A. Serhani, and R. Dssouli, "A model for multi-levels SLA monitoring in federated cloud environment," in 10th International Conference on Ubiquitous Intelligence and Computing and 10th International Conference on Autonomic and Trusted Computing (UIC/ATC '13), 2013, pp. 363-370.
[130] S. A. De Chaves, R. B. Uriarte, and C. B. Westphall, "Toward an architecture for monitoring private clouds," IEEE Communications Magazine, vol. 49, pp. 130-137, Dec 2011.
[131] J. Spring, "Monitoring cloud computing by layer, part 1," IEEE Security & Privacy, vol. 9, pp. 66-68, Mar 2011.
[132] R. Righi, D. Kreutz, and C. Westphall, "Sec-mon: An architecture for monitoring and controlling security service level agreements," in XI Workshop on Managing and Operating Networks and Services, 2006, pp. 73-84.
[133] F. Wuhib and R. Stadler, "Distributed monitoring and resource management for large cloud environments," in IFIP/IEEE International Symposium on Integrated Network Management (IM '11), 2011, pp. 970-975.
[134] J. Huang and D. M. Nicol, "Trust mechanisms for cloud computing," Journal of Cloud Computing: Advances, Systems and Applications, vol. 2, p. 9, Dec 2013.
[135] K. Hoffman, D. Zage, and C. Nita-Rotaru, "A survey of attack and defense techniques for reputation systems," ACM Computing Surveys (CSUR), vol. 42, p. 1, Dec 2009.
[136] K. Lai, M. Feldman, I. Stoica, and J. Chuang, "Incentives for cooperation in peer-to-peer networks," in Workshop on economics of peer-to-peer systems, 2003, pp. 1243-1248.
[137] J. R. Douceur, "The sybil attack," in International Workshop on Peer-to-Peer Systems, 2002, pp. 251-260.
148
[138] S. Ba and P. A. Pavlou, "Evidence of the effect of trust building technology in electronic markets: Price premiums and buyer behavior," MIS quarterly, pp. 243-268, Sept 2002.
[139] R. K. Ko, P. Jagadpramana, M. Mowbray, S. Pearson, M. Kirchberg, Q. Liang, et al., "TrustCloud: A framework for accountability and trust in cloud computing," in IEEE World Congress on Services (SERVICES '11), 2011, pp. 584-588.
[140] S. Chakraborty and K. Roy, "An SLA-based framework for estimating trustworthiness of a cloud," in 11th International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom '12), 2012, pp. 937-942.
[141] S. M. Habib, V. Varadharajan, and M. Muhlhauser, "A trust-aware framework for evaluating security controls of service providers in cloud marketplaces," in 12th IEEE International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom '13) 2013, pp. 459-468.
[142] S. Rizvi, K. Karpinski, B. Kelly, and T. Walker, "Utilizing Third Party Auditing to Manage Trust in the Cloud," Procedia Computer Science, vol. 61, pp. 191-197, Jan 2015.
[143] K. Hwang and D. Li, "Trusted cloud computing with secure resources and data coloring," IEEE Internet Computing, vol. 14, pp. 14-22, Sept 2010.
[144] I. Brandic, S. Dustdar, T. Anstett, D. Schumm, F. Leymann, and R. Konrad, "Compliant cloud computing (c3): Architecture and language support for user-driven compliance management in clouds," in 3rd International Conference on Cloud Computing (CLOUD '10), 2010, pp. 244-251.
[145] K. Hwang, S. Kulkareni, and Y. Hu, "Cloud security with virtualized defense and reputation-based trust mangement," in 8th IEEE International Conference on Dependable, Autonomic and Secure Computing (DASC '09), 2009, pp. 717-722.
[146] X. Sun, G. Chang, and F. Li, "A trust management model to enhance security of cloud computing environments," in Second International Conference on Networking and Distributed Computing (ICNDC '11), 2011, pp. 244-248.
[147] T. H. Noor and Q. Z. Sheng, "Trust as a service: A framework for trust management in cloud environments," in International Conference on Web Information Systems Engineering, 2011, pp. 314-321.
[148] U. Divakarla and K. Chandrasekaran, "A novel approach for evaluating trust of resources in cloud environment," in Region 10 Conference (TENCON '16), 2016, pp. 459-463.
[149] J. Bharath and V. S. Sriram, "Genetically Modified Ant Colony Optimization based Trust Evaluation in Cloud Computing," Indian Journal of Science and Technology, vol. 9, Jan 2017.
[150] W. Li and L. Ping, "Trust model to enhance security and interoperability of cloud environment," in 1st International Conference on Cloud Computing Beijing, China, 2009, pp. 69-79.
[151] A. Celestini, A. L. Lafuente, P. Mayer, S. Sebastio, and F. Tiezzi, "Reputation-based cooperation in the clouds," in IFIP International Conference on Trust Management, 2014, pp. 213-220.
[152] Y. Dou, H. C. Chan, and M. H. Au, "A Distributed Trust Evaluation Protocol with Privacy Protection for Intercloud," IEEE Transactions on Parallel and Distributed Systems, vol. 30, pp. 1208-1221, 2018.
149
[153] H. Kim, H. Lee, W. Kim, and Y. Kim, "A trust evaluation model for QoS guarantee in cloud systems," International Journal of Grid and Distributed Computing, vol. 3, pp. 1-10, Mar 2010.
[154] H. T. El-Kassabi, M. A. Serhani, R. Dssouli, and A. N. Navaz, "Trust enforcement through self-adapting cloud workflow orchestration," Future Generation Computer Systems, vol. 97, pp. 462-481, 2019.
[155] X. Wu, R. Zhang, B. Zeng, and S. Zhou, "A trust evaluation model for cloud computing," Procedia Computer Science, vol. 17, pp. 1170-1177, Jan 2013.
[156] X. Li and J. Du, "Adaptive and attribute-based trust model for service level agreement guarantee in cloud computing," IET Information Security, vol. 7, pp. 39-50, Mar 2013.
[157] C. Qu and R. Buyya, "A cloud trust evaluation system using hierarchical fuzzy inference system for service selection," in IEEE 28th International Conference on Advanced Information Networking and Applications (AINA '14), 2014, pp. 850-857.
[158] C. Mao, R. Lin, C. Xu, and Q. He, "Towards a Trust Prediction Framework for Cloud Services Based on PSO-Driven Neural Network," IEEE Access, vol. 5, pp. 2187-2199, Jan 2017.
[159] V. C. Emeakaroha, K. Fatema, L. v. d. Werff, P. Healy, T. Lynn, and J. P. Morrison, "A Trust Label System for Communicating Trust in Cloud Services," IEEE Transactions on Services Computing, vol. 10, pp. 689-700, Sept 2017.
[160] H. A. Linstone and M. Turoff, The delphi method: Addison-Wesley Reading, MA, 1975.
[161] M. Mrabet, Y. ben Saied, and L. A. Saidane, "Modeling correlation between QoS attributes for trust computation in cloud computing environments," in 17th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing, 2017, pp. 488-497.
[162] W. Fan and H. Perros, "A novel trust management framework for multi-cloud environments based on trust service providers," Knowledge-Based Systems, vol. 70, pp. 392-406, Nov 2014.
[163] E. Kuada, "Trust Management System for Opportunistic Cloud Services," in IEEE 2nd International Conference on Cloud Networking (CloudNet '13), 2013, pp. 33-41.
[164] X. Li, H. Ma, F. Zhou, and W. Yao, "T-broker: A trust-aware service brokering scheme for multiple cloud collaborative services," IEEE Transactions on Information Forensics and Security, vol. 10, pp. 1402-1415, Jul 2015.
[165] X. Li, H. Ma, F. Zhou, and X. Gui, "Service operator-aware trust scheme for resource matchmaking across multiple clouds," IEEE transactions on parallel and distributed systems, vol. 26, pp. 1419-1429, May 2015.
[166] O. A. Wahab, J. Bentahar, H. Otrok, and A. Mourad, "Towards Trustworthy Multi-Cloud Services Communities: A Trust-based Hedonic Coalitional Game," IEEE Transactions on Services Computing, vol. 11, pp. 184-201, Jan 2018.
[167] T. M. Chen and V. Venkataramanan, "Dempster-Shafer theory for intrusion detection in ad hoc networks," IEEE Internet Computing, vol. 9, pp. 35-41, Nov 2005.
150
[168] P. D. Manuel, S. T. Selvi, and M. I. Abd-El Barr, "Trust management system for grid and cloud resources," in First International Conference on Advanced Computing (ICAC '09), 2009, pp. 176-181.
[169] S. Rizvi, J. Ryoo, Y. Liu, D. Zazworsky, and A. Cappeta, "A centralized trust model approach for cloud computing," in 23rd Wireless and Optical Communication Conference (WOCC), , 2014, pp. 1-6.
[170] N. Ghosh, S. K. Ghosh, and S. K. Das, "SelCSP: A framework to facilitate selection of cloud service providers," IEEE transactions on cloud computing, vol. 3, pp. 66-79, Jan 2015.
[171] M. Mrabet, Y. ben Saied, and L. A. Saidane, "A new trust evaluation approach for cloud computing environments," in International Conference on Performance Evaluation and Modeling in Wired and Wireless Networks (PEMWN '16) 2016, pp. 1-6.
[172] A. Algamdi, F. Coenen, and A. Lisitsa, "A trust evaluation method based on the distributed Cloud Trust Protocol (CTP) and opinion sharing," provider, vol. 5, p. 18.
[173] O. Ghazali, A. M. Tom, H. M. Tahir, S. Hassan, S. A. Nor, and A. H. Mohd, "Security Measurement as a Trust in Cloud Computing Service Selection and Monitoring," Journal of Advances in Information Technology, vol. 8, May 2017.
[174] A. Kanwal, R. Masood, and M. A. Shibli, "Evaluation and establishment of trust in cloud federation," in 8th International Conference on Ubiquitous Information Management and Communication, 2014, p. 12.
[175] E. Cayirci, A. Garaga, A. Santana, and Y. Roudier, "A cloud adoption risk assessment model," in IEEE/ACM 7th International Conference on Utility and Cloud Computing (UCC '14) 2014, pp. 908-913.
[176] L. Mashayekhy, M. M. Nejad, and D. Grosu, "A Trust-Aware Mechanism for Cloud Federation Formation," IEEE Transactions on Cloud Computing, 2019.
[177] H. Kurdi, A. Alfaries, A. Al-Anazi, S. Alkharji, M. Addegaither, L. Altoaimy, et al., "A lightweight trust management algorithm based on subjective logic for interconnected cloud computing environments," The Journal of Supercomputing, vol. 75, pp. 3534-3554, 2019.
[178] A. Jøsang, R. Hayward, and S. Pope, "Trust network analysis with subjective logic," in Proceedings of the 29th Australasian Computer Science Conference-Volume 48, 2006, pp. 85-94.
[179] I. Petri, O. F. Rana, T. Beach, and Y. Rezgui, "Performance analysis of multi-institutional data sharing in the Clouds4Coordination system," Computers & Electrical Engineering, vol. 58, pp. 227-240, 2017.
[180] U. Ahmed, I. Raza, and S. A. Hussain, "Trust Evaluation in Cross-Cloud Federation: Survey and Requirement Analysis," ACM Computing Surveys (CSUR), vol. 52, p. 19, 2019.
[181] L.-q. Tian, C. Lin, and Y. Ni, "Evaluation of user behavior trust in cloud computing," in International Conference on Computer Application and System Modeling (ICCASM '10), 2010, pp. 567-572.
[182] R. Chow, P. Golle, M. Jakobsson, E. Shi, J. Staddon, R. Masuoka, et al., "Controlling data in the cloud: outsourcing computation without outsourcing
151
control," presented at the Proceedings of the 2009 ACM workshop on Cloud computing security, Chicago, Illinois, USA, 2009.
[183] K. Julisch and M. Hall, "Security and Control in the Cloud," Information Security Journal: A Global Perspective, vol. 19, pp. 299-309, Nov 2010.
[184] B. Christianson and W. Harbison, "Why isn't trust transitive?," in Security protocols, 1997, pp. 171-176.
[185] A. Algamdi, F. Coenen, and A. Lisitsa, "A trust evaluation method based on the distributed Cloud Trust Protocol (CTP) and opinion sharing," presented at the International Conference on Computer Applications & Technology, (ICCAT'17), 2017.
[186] S. Ries, "Trust in ubiquitous computing," Technische Universität, 2009. [187] A. Jøsang, Subjective Logic: A Formalism for Reasoning Under Uncertainty:
Springer, 2016. [188] A. Jøsang and D. McAnally, "Multiplication and comultiplication of beliefs,"
International Journal of Approximate Reasoning, vol. 38, pp. 19-51, 2005. [189] U. Ahmed, I. Petri, O. Rana, I. Raza, and S. A. Hussain, "Risk-based Service
Selection in Federated Clouds," in 2018 IEEE/ACM International Conference on Utility and Cloud Computing Companion (UCC Companion), 2018, pp. 77-82.
[190] C. Huxham and S. Vangen, "Working together: Key themes in the management of relationships between public and non-profit organizations," International Journal of Public Sector Management, vol. 9, pp. 5-17, 1996.
[191] B. Gray and D. J. Wood, "Collaborative alliances: Moving from practice to theory," The Journal of Applied Behavioral Science, vol. 27, pp. 3-22, 1991.
[192] J. Child and D. Faulkne, "Strategies of Cooperation: Managing Alliances, Networks, and the United Kingdom," Physica-Verlag, 1998.
[193] F. McDonald and J. Genefke, Effective collaboration: Managing the obstacles to success: Palgrave, 2001.
[194] R. J. Bies, T. Tripp, R. Kramer, and T. Tyler, "Trust in organizations: Frontiers of theory and research," Thousand Oaks, CA, US: Sage Publications, Inc Thousand Oaks, CA, pp. 246-260, 1996.
[195] C. Lane and R. Bachmann, "The social constitution of trust: supplier relations in Britain and Germany," Organization studies, vol. 17, pp. 365-395, 1996.
[196] D. M. Rousseau, S. B. Sitkin, R. S. Burt, and C. Camerer, "Not so different after all: A cross-discipline view of trust," Academy of management review, vol. 23, pp. 393-404, 1998.
[197] A. K. Mishra, "Organizational responses to crisis," Trust in organizations: Frontiers of theory and research, vol. 261, 1996.
[198] S. Vangen and C. Huxham, "Nurturing collaborative relations: Building trust in interorganizational collaboration," The Journal of Applied Behavioral Science, vol. 39, pp. 5-31, 2003.
152
APPENDIX - A
Author’s List of Publications
Usama Ahmed, Imran Raza, and Syed Asad Hussain. 2019. Trust Evaluation in Cross-Cloud Federation: Survey and Requirement Analysis. ACM Comput. Surv. 52, 1, Article 19 (February 2019), 37 pages. https://doi.org/10.1145/3292499
Usama Ahmed, Ioan Petri, Omer Rana, Imran Raza and Syed Asad Hussain, "Risk-Based Service Selection in Federated Clouds," 2018 IEEE/ACM International Conference on Utility and Cloud Computing Companion (UCC Companion), Zurich, Switzerland, 2018, pp. 77-82. doi: 10.1109/UCC-Companion.2018.00038
Usama Ahmed, Imran Raza, and Syed Asad Hussain. 2019. Information Centric Trust management for Big Data Enabled IoT. Institution of Engineering and Technology (IET), UK (Book chapter - in press)
Usama Ahmed, Imran Raza, Omer F. Rana and Syed Asad Hussain, “ConAccT: Conjunctive Accumulation of Trust in CAIQ enabled Cross-cloud Federation” (submitted to IEEE Transactions on Services Computing)
Usama Ahmed, Ioan Petri, Omer F. Rana, Imran Raza and Syed Asad Hussain, “Federating Cloud Systems for Collaborative Construction and Engineering” (submitted to IEEE Transactions on Industrial Informatics)
153
APPENDIX - B
Business Information Modelling (BIM)
Overview
BIM is an acronym for Building Information Modelling. It is a highly collaborative process that
allows multiple stakeholders and AEC (architecture, engineering, construction) professionals to
collaborate on the planning, design, and construction of a building within one 3D model. It can
also span the operation and management of buildings using data that owners have access to. This
data allows owners and stakeholders to make decisions based on pertinent information derived
from the model — even after the building is constructed. In the past, blueprints and drawings were
used to express information about a particular building plan. This 2D approach made it very
difficult to visualize dimensions and requirements. Next came CAD (Computer Aided Design),
which helped drafters see the benefit of plans in a digital environment. Later on, CAD turned 3D,
which brought more realistic visuals to blueprints. Now, BIM is the standard but it’s more than
just a 3D model.
BIM Objects
BIM objects, the components that make up a BIM model, are intelligent, have geometry, and
store data. If any element is changed, BIM software updates the model to reflect that change. This
allows the model to remain consistent and coordinated throughout the entire process so that
structural engineers, architects, MEP engineers, designers, project managers, and contractors can
work in a more collaborative environment.
How Is BIM Information Shared?
BIM, as a whole, refers to the process of all parties involved in the construction and lifecycle
management of built assets, working collaboratively and sharing data. However, the true power of
BIM lives in the “I” (information). All of the information gathered— from conception to
completion— isn’t just stored, it’s actionable. The data can be used to improve accuracy, express
design intent from the office to the field, improve knowledge transfer from stakeholder to
stakeholder, reduce change orders and field coordination problems, and provide insight into
154
existing buildings for renovation projects later on. This information in a BIM model is shared
through a mutually accessible online space known as a common data environment (CDE), and the
data collected is referred to as an 'information model'. Information models can be used at all stages
of a building’s life; from inception to operation— and even renovations and renewals.
Future of BIM
Because of the clear benefits, it’s certain that BIM is here to stay. It has defined goals and
objectives that are clearly beneficial to all those who work their way through the levels.
Undoubtedly, the future of construction will be even more highly collaborative and digital. As
BIM becomes increasingly more sophisticated, 4D, 5D, and even 6D BIM will start to play a part
in the process. Furthermore, around the globe, there is an attempt to reduce waste in construction.
Much of this is attributed to supply chain inefficiencies, clashes, and reworking. By working
collaboratively in a BIM environment, all of this becomes much less likely, setting the stage for a
better tomorrow.
BIM in United Kingdom
In May 2011 UK Government Chief Construction Adviser Paul Morrell called for BIM
adoption on UK government construction projects1. Morrell also told construction professionals
to adopt BIM or be "Betamaxed out"2. In June 2011 the UK government published its BIM
strategy,3 announcing its intention to require collaborative 3D BIM (with all project and asset
information, documentation and data being electronic) on its projects by 2016. Initially,
compliance will require building data to be delivered in a vendor-neutral 'COBie' format, thus
overcoming the limited interoperability of BIM software suites available in the market. The UK
Government BIM Task Group led the government's BIM program and requirements,4 including a
free-to-use set of UK standards and tools that define 'level 2 BIM'.5 In April 2016, the UK
Government published a new central web portal as a point of reference for the industry for BIM
1 "BIM Roundtable Discussion". Thenbs.com. Retrieved 17 October 2014. 2 "Adopt bim or be 'Betamaxed out' says Morrell". Building Design. Retrieved 17 October2014. 3 "Modern Built Environment - innovateuk". Ktn.innovateuk.org. Retrieved 17 October2014. 4 "BIM Task Group - A UK Government Initiative". Bimtaskgroup.org. Retrieved 17 October 2014. 5 "The level-2 BIM package". BIM Task Group. Retrieved 17 October 2014.
155
Level 2.6 The BIM Task Group continues to develop BIM adoption within the government
departments.
Outside of government, industry adoption of BIM from 2016 has been led by the UK BIM
Alliance,7 formed to champion and enable the implementation of BIM Level 2 by 2020, and to
connect and represent organisations, groups and individuals working towards digital
transformation of the UK's built environment industry. Established as an independent, not-for-
profit, collaboratively-based organisation, the UK BIM Alliance's structure has been developed
around an executive team and three core activity areas: engagement, programme and operations
(internal support and secretariat functions). In November 2017, the UK BIM Alliance merged with
the UK chapter of BuildingSMART. 8
6 "BIM Level 2". BSI Group. Retrieved 19 April 2016. 7 Solutions, WebCider Business. "UK BIM Alliance". ukbimalliance.org. 8 "UK BIM Alliance and buildingSMART to merge". BIM plus. CIOB. 5 November 2017. Retrieved 21
January 2019.
156
APPENDIX - C
Building Information Modeling (BIM) Workloads
(a) Model size 300Kbytes
(b): Model size 689Kbytes
157
(c) Model size 956Kbytes
(d) Model size 3.44 MBs
158
(e) Model size 5.34Mbytes
(f) Model size 8.940MBytes
