Cloud computing adoption framework: A security framework for business clouds

Future Generation Computer Systems 57 (2016) 24–41
Contents lists available at ScienceDirect
Future Generation Computer Systems
journal homepage: www.elsevier.com/locate/fgcs
Cloud computing adoption framework: A security framework for
business clouds
Victor Chang a,∗, Yen-Hung Kuo b,∗, Muthu Ramachandran a
a School of Computing, Creative Technologies and Engineering, Leeds Beckett University, Leeds, UK
b Data Analytics Technology & Applications, Institute for Information Industry, Taiwan, ROC
h i g h l i g h t s
• We demonstrate CCAF multi-layered security.
• We explain the mappings between CCAF multi-layered architecture and core technologies
• We performed penetration testing and SQL injection on CCAF multi-layered security.
• Results and analysis by CCAF are better than those produced by the other tools.
• CCAF multi-layered security blends with policy, services and business activities.
a r t i c l e i n f o
Article history:
Received 11 July 2015
Received in revised form
9 September 2015
Accepted 27 September 2015
Available online 19 October 2015
Keywords:
Cloud computing adoption framework
(CCAF)
OpenStack
CCAF multi-layered security
Security for business clouds
a b s t r a c t
This article presents a cloud computing adoption framework (CCAF) security suitable for business
clouds. CCAF multilayered security is based on the development and integration of three major security
technologies: firewall, identity management, and encryption based on the development of enterprise
file sync and share technologies. This article presents the vision, related works, and views on security
framework. Core technologies have been explained in detail, and experiments were designed to
demonstrate the robustness of the CCAF multilayered security. In penetration testing, CCAF multilayered
security could detect and block 99.95% viruses and trojans, and could achieve ≥85% of blocking for 100
h of continuous attack. Detection and blocking took <0.012 s/trojan or virus. A full CCAF multilayered
security protection could block all SQL (structured query language) injection, providing real protection
to data. CCAF multilayered security did not report any false alarm. All F -measures for CCAF test results
were ≥99.75%. The mechanism of blending of CCAF multilayered security with policy, real services, and
business activities has been illustrated. Research contributions have been justified and CCAF multilayered
security can be beneficial for volume, velocity, and veracity of big data services operated in the cloud.
© 2015 Elsevier B.V. All rights reserved.
1. Introduction
Security, trust, and privacy always remain challenges for orga-
nizations that adopt cloud computing and big data. Although there
are demands for businesses to move their data to the cloud and
centralize management for data centers, services and applications
are designed to reduce cost and increase operational efficiency.
System design and deployment based on current security practices
should be simultaneously enforced to ensure compliance of all data
∗ Corresponding authors.
E-mail addresses: [e-mail] (V. Chang), [e-mail]
(Y.-H. Kuo).
and services with up-to-date patches and policies. A risk-based ap-
proach to the development of a security program that recognizes
(and funds) appropriate controls will ensure protection of all users
and confidentiality, integrity, and availability of data.
Some researchers have adopted a framework approach that al-
lows organizations to follow guidelines, policies, and standards.
For example, Zhang et al. [1] propose a usage-based security
framework (UBSF), which can consolidate guidelines and policies
with their framework, architecture, and digital certificates. Tak-
abi et al. [2] describe a comprehensive security framework via a
model that explains the method of working with different service
integrators and service providers. Zia and Zomaya [3] present a
wireless sensor network model with algorithms and a software en-
gineering approach. All these frameworks have recommendations
http://dx.doi.org/10.1016/j.future.2015.09.031
0167-739X/© 2015 Elsevier B.V. All rights reserved.

V. Chang et al. / Future Generation Computer Systems 57 (2016) 24–41 25
on guidelines to use. However, there are no details on the actual use
of these proposals and also no clear evidence of adoption of these
proposals to business clouds, whose requirements include ease of
use, adaptability, best practice compliant, and support by large-
scale experiments such as penetration testing to validate robust-
ness of such proposals [4,5]. Indeed, without such a clear ‘‘line of
sight’’ between conception and implementation, such frameworks
are unlikely to achieve operational status.
The cloud computing adoption framework (CCAF) has been de-
veloped to meet the requirements of business clouds and ensure
that all implementations and service deliveries overcome all the
technical challenges. Real-life case studies show how different
cloud computing designs and their development and service deliv-
ery overcome both technical and organizational challenges. In the
first example, CCAF was the framework used to develop cloud stor-
age and bioinformatics solutions for biomedical scientists based
in the United Kingdom at Guy’s Hospital and King’s College Lon-
don [6]. This framework ensured the deliveries of storage services
to back up thousands of terabyte-sized medical data. Bioinformat-
ics services can simulate DNAs, proteins, genes, tumors, and organs
of the human body. The use of this security is limited to authenti-
cation, encryption, and users with authorized access. In the second
example, CCAF is used to provide guidelines for financial model-
ing, so that the best practice and call prices can be computed with
respect to the change of risks. Advanced computational techniques
have been used to calculate risks and market volatility [7]. Security
is limited to password authentication and users with authorized
access and biometrics checks for financial simulations. In the third
example, investigations of hacking methods have been studied and
made as part of prototype requirements. User requirement and lit-
erature review have identified factors for a successful implementa-
tion. All the collected and synthesized data have been instrumental
in the development of CCAF Version 1.1, which emphasizes on the
security policies, recommendations, techniques, and technologies
to be updated in the framework [8]. In the aforementioned exam-
ples, a more comprehensive cloud security solution is required to
ensure robustness and resistance of the services to attack, hack-
ing, and unauthorized attempts to gain access. More experiments
and simulations are required to validate the robustness and ef-
fectiveness of the proposed security framework. This motivates
us to consolidate our CCAF framework by providing a holistic ap-
proach involved with service integration, OpenStack security, and
multilayered security to enhance security for business clouds. An
integrated security framework is proposed for business clouds to
have the multilayered security in place and the large-scale pen-
etration testing and experiments to validate the robustness and
effectiveness of our approach. All these proofs of concepts and
lessons learned are important to big data in the cloud as follows.
First, it ensures that all the cloud services are safe and secure, in-
cluding the incoming and outgoing data of the organizational data
centers hosted on hundreds and thousands of virtual machines
(VMs). Second, it ensures that large amount of data and large data
sets can be processed and analyzed safely in the cloud, which also
explains the necessity of large-scale penetration testing to validate
the framework.
The organization of this article is as follows: Section 2 presents
the literature for security. Section 3 describes our core security
technology for enterprise file sync and share (EFSS), including the
architecture and layered components. Section 4 explains the mul-
tilayered approach with core technologies and results from large-
scale experiments for penetration testing, SQL (structured query
language) injection, and data scanning. Section 5 illustrates top-
ics of discussion, and Section 6 summarizes conclusion and future
work.
2. Literature
The following are the different types of security frameworks
proposed so far. Zhang et al. [1] propose their UBSF for collab-
orative computing systems. They explain their motivation, tech-
niques used, architecture, and conditions for experiments. The
decision on the use of UBSF is made based on subjects, objects,
authorization, obligations, and conditions. With support from lit-
erature and hypotheses, they explain their model’s mechanism of
work in collaborative ways. The usage-based authorization archi-
tecture uses sensors, directory service, policy decision point (PDP),
and usage monitor (UM) to functions. Steps have been described
to justify the effective function of UBSF. In order to assist UBSF,
Zhang et al. [1] include a prototype system architecture. They use
OpenLDAP and OpenSSL to enforce security. They have three types
of digital certificates: user, attribute repository (AR), and resource
provider (RP). They explain the use of these certificates in their
workflow of security processes. They also adopt extensible access
control markup language (XACML) to enforce policy specification,
which aligns with the UBSF approach for security. Ko et al. [9]
investigate trust for cloud computing and propose a TrustCloud
framework that focused on accountability. It has three layers:
(1) system layer that covers all the underlying hardware and plat-
form; (2) data layer that contains the data for the work; and
(3) workflow layer that uses workflow to execute all the services
and requests. In addition, two nonfunctional layers are associ-
ated with these three layers. The first layer is laws and regula-
tions, which ensures all services follow the legal requirements of
the country in which the service was delivered. The second layer
is policies, which are the consolidated service-level agreements
and the best practice approach. This framework is considered as a
conceptual framework focused on the recommendations and best
practice, as they do not include quantitative analyses, computa-
tional demonstrations, and case studies. Pal et al. [10] present their
cloud security that has emphasized on the architecture and steps
of interactions between different services. They explain the role of
each major user, their agents, and all the 15 steps involved. They
use unified modeling language (UML) diagram to justify their ap-
proach and architecture to explain the relationship between the
user, provider, proxy server, user agent, and provider agent. They
present two algorithms and experimental results. They validate
their approach using ‘‘trust value updation’’. However, their as-
sumption is based on the probabilities of 0.8 and 0.2 of having
a trusted and nontrusted user, respectively. There is no evidence
supporting this, and they do not use any reference or survey to
justify their research. This also depends on the sample size, demo-
graphics, and the country in which the research was conducted.
The National Institute of Standards and Technology (NIST) [11]
framework provides a common language for establishing cyber-
security. The core NIST framework provides a set of activities to
identify, protect, detect, respond, and recover without more spe-
cific examples and case studies implementing a full-security solu-
tion. However, our work on CCAF extends to detailed activities and
implementation on security for cloud computing and big data.
All these examples have security framework. However, the
proposals described above do not demonstrate their contributions
to business clouds. In other words, when businesses adopt cloud
computing solution, they should be able to provide architecture,
approaches for their framework, and steps and experiments to
support the robustness and validity of the framework. Our proposal
on CCAF provides details on core technologies in Section 3, and the
theoretical framework mapping of core technologies is shown in
Section 4 with experimental results validating our framework. Key
topics, including security policy, business and security alignment,
framework and core technology integration, relation of the big data
in cloud, and overall contributions with limitation, are discussed

26 V. Chang et al. / Future Generation Computer Systems 57 (2016) 24–41
in Section 5. Finally, research conclusion and future work are
discussed in Section 6.
3. Core technologies
Prior to the introduction of CCAF, this section uses a concrete
instance of the CCAF to be an example to explain CCAF core tech-
nologies and implementations. In order to meet the requirements
of moving big data in a semipublic business cloud, an enterprise
cloud storage application – the semipublic EFSS service – is chosen
to be the CCAF instance to explain the mechanism of protection of
enormous enterprise files (a kind of unstructured big data) by CCAF
in a business cloud environment.
In order to provide enterprises with the convenient cloud file
sync and share service while taking enterprise concerns, such as se-
curity, compliance, and regulation, into consideration, the service
was been deployed by either on-premise or hybrid cloud model to
target high-value EFSS market [12–14]. Existing EFSS systems fo-
cus on system security and manageability, which encrypt data on
transfer and at rest, and also support system audit trail. As part of
the core technologies of the CCAF framework, important EFSS se-
curity issues should be well addressed, particularly for businesses
with critical data services. The following are the EFSS security is-
sues:
(1) Employee Privacy: In order to prevent data leak, enterprise
data are usually encrypted in existing EFSS systems. However,
most existing EFSS systems only use single master key to
encrypt entire data space, which can prevent enterprise data
leaks from outside but not from inside. For example, an
EFSS system administrator (information technology (IT) or
management information system (MIS) in the enterprise) can
spy enterprise-sensitive data by self-granted authority.
(2) Share Link: The share link is widely adopted to share data with
business partners who do not have an EFSS system account.
From enterprise’s perspective, the share link is convenient, but
not secure, as it involves new security loophole that might
be used to leak data to unauthorized domain without leaving
enough audit trail [15]
(3) Cloud File Synchronization: The nature of the cloud file
synchronization is a security loophole to enterprises. It
synchronizes shared and collaborative enterprise data from
a managed EFSS service to employees’ endpoint devices, and
enterprises then have less/no control on the synchronized
enterprise data. The synchronized enterprise data can then be
distributed from the endpoint devices to other unauthorized
domains via e-mail, USB disk, and other communication
interfaces available on the endpoint devices.
(4) Enterprise Directory Integration: In order to enable single
sign-on (SSO) in the enterprise, most existing EFSS systems, via
direct network connection, integrate its authentication with
existing enterprise directory (e.g., active directory (AD) and
lightweight directory authentication protocol (LDAP)). It also
introduces two new security issues. First, the EFSS system can
access employees’ profiles available in enterprise directories.
Second, the EFSS system can log employees’ credential infor-
mation during authentication, as their usernames and pass-
words pass through the EFSS system to enterprise directory to
conduct the actual authentication. Both cases provide EFSS sys-
tem with chances to obtain authorized information.
An integrated security approach, which integrates several key
components to form a scalable secure EFSS system to address
the enterprises’ concerns by leveraging the on-premise OpenStack
infrastructure [16], is introduced in the following sections. EFSS has
been integrated with the CCAF framework as an overarching model
for cloud security in businesses.
Architecture and Design of the Integrated Security Approach
The key components of the secure EFSS system are virtual
appliances that can be provisioned and run on the OpenStack
compute service, Nova, and the data (e.g., metadata in database and
uploaded enterprise files in user storage space) generated by these
components are stored in the OpenStack storage services: Cinder
and Swift for block storage and object storage, respectively, where
the OpenStack storage services are managed by the storage system
controlled by the enterprise. The separation of the compute and
storage makes the Secure EFSS system is scalable and more secure
than existing EFSS systems.
All key components/virtual appliances, including load balancer,
firewall, virtual file system (VFS) service, directory service, log
service, message queue (MQ) service, and database service, are
provisioned from an integrated image stored in the OpenStack
VM image management service, Glance, to form the secure EFSS
system as shown in Fig. 1. The VFS service of the proposed secure
EFSS system provides clients with a representational state transfer
(REST) application programming interfaces (API) set to manipulate
a directory structure and files of a VFS. The back end of the
VFS is the database service, which stores metadata to represent
the directory structure and the nodes’ attributes of the directory
structure. Enterprise files uploaded by clients are leaf nodes of
the directory structure, and they have a node attribute to indicate
encrypted objects in the Swift. Because no data are stored in the
VFS service, it can dynamically provision more VFS VMs to fulfill
the increasing demand of EFSS system in a scalable and distributed
manner.
The interactions of the REST key components and their benefit
to security and scalability are shown in Fig. 1. The load balancer
is located in the demilitarized zone (DMZ), which dynamically
distributes every request made by the sandbox-based cloud file
sync app to one of the VFS VMs for handling the requests
according to the loads on it for maximizing the overall VFS
service performance. Moreover, a firewall is located between the
load balancer and the VFS service to form a secure deployment
scheme, which defends external direct network attacks for internal
services. Once the VFS service receives a request, it first sends the
authentication information of the request to the directory service
to check the identity and authority of the request. Subsequently,
the VFS service handles the request and logs related audit trails
to the log service. During VFS service, the overall service status,
including concurrent serving requests, CPU, and memory usages,
is reported to MQ service, which actively calls OpenStack compute
service API to provision and de-provision VFS VM to handle the
peak and idle situations of the secure EFSS system.
Designs of key components of the proposed integrated security
approach are introduced in the following subsections, which
include user storage space modeling, distinct share link, zero-
knowledge cloud scale file sharing system, sandbox-based cloud
file synchronization, out-of-band authentication, and a NoSQL
adoption consideration.
3.1. User storage space modeling
In order to ensure scalability of the system, metadata generated
by key components, particularly by the VFS service, are stored
in a MongoDB cluster, which is a document-based NoSQL
database that increases scalability by sacrificing the relationship
between documents [17,18]. Furthermore, user accounts are
used as database sharding key to shard the user storage space
to mitigate the MongoDB scalability limitation, which affects
database performance when too many documents are inserted into
a data collection process. Then, every user has a directory structure
formed by metadata stored in his/her own data collection, which
physically isolates the user’s metadata. Therefore, every user’s

V. Chang et al. / Future Generation Computer Systems 57 (2016) 24–41 27
Fig. 1. Secure EFSS system architecture in the OpenStack.
metadata can be protected by owner’s encryption key without
leaking of sensitive metadata when database service is hacked.
3.2. Distinct share link
Sharing of cloud files between an enterprise and external
business partners can be easily performed using a share link.
However, it is insecure as web crawlers can simply download it by
scanning e-mails and social network accounts [19]. This problem
can be overcome by a distinct share link that secures sharing of
cloud files and builds a secure sharing relationship between two
user storage spaces, which are isolated data collections sharded
from the user storage space [20].
The distinct share link is an additional layer associated with per-
missions, identities, and access conditions. It encapsulates a share
link, decreases diffusibility of the share link, adds traceability as
well as controllability to the share link, and then sends it to recip-
ients with attached identities. A recipient trying to gain access to
a distinct share link has to input his/her identities for access con-
dition check. After passing all checks, the distinct share link layer
prepares an ephemeral representation to access the share link.
Because every distinct share link access requires identity (trace-
ability) that is controlled by permissions and access conditions
(controllability), its diffusibility and convenience are decreased.
In order to overcome this problem, a recipient-defined identity
function is introduced, which allows the recipient to define
own identity (e.g., password and secret code) for each received
distinct share link. Hence, the recipient can define easy-to-
remember identities to received distinct share links. It also resolves
the problem of share link identity management, that is, share
links with different identities (e.g., passwords) are too much
information to be remembered by a single recipient.
In addition to the aforementioned benefits, the distinct share
link further supports sandbox feature for creating a collaborative
workspace with external business partners, where every individual
has own permission, and any inappropriate action (e.g., delete
all files) can be performed only in a specific shared folder, but
not in the entire personal user storage space. It is worth noting
that with cloud storage, any performed inappropriate action can
be undone, for example, previous cloud file version and deleted
shared files can be recovered from file change history and recycle
bin, respectively.
The distinct share link is also used to implement the internal
cloud file sharing in the proposed secure EFSS by building a secure
sharing relationship between two isolated user storage spaces
(data collections). Fig. 2 depicts the mechanism of building the
internal cloud file sharing by distinct share link. The top-left part
of the figure presents two internal cloud file sharing relationships:
(1) users A and C receive an object shared from user B and (2) user
B receives an object shared from user C. The callout box shown
in the top-right part of the figure further explains the sharing
relationships associated with the object (ID: WXYZ) in the former
sharing relationship. It shows that three distinct share links are
used to share the object (ID: WXYZ) with the recipients: user A,
user B, and an e-mail address. Moreover, all the three distinct
share links can be parsed into three parts: (1) the service endpoint
(e.g., https://distinct.url/); (2) the UID part for identifying user
storage space, that is, location of the data collection; and (3) the SID
part for identifying the metadata (table in Fig. 2), which contains
information about the sharing relationship in the located data
collection. After retrieving the metadata, the ‘‘ObjectID’’ can be
used to refer to either a shared object or share link point to a shared
object.
The aforementioned external and internal sharing cases have
similar distinct share link creation and access processes. The key
difference between the two cases is the identity delivery process.
In external sharing, the identity is first defined by the distinct share
link creator, subsequently it is delivered by oral or identity itself
(e.g., e-mail), and finally it might be redefined by the recipient.
The internal sharing automatically performs similar processes by
system with the following steps: (1) generates random keys as
identities in the sharing source, (2) encrypts generated identities
by a recipient’s public key, and (3) delivers the encrypted identities
from the sharing source to the sharing destination for further use.
3.3. Zero-knowledge cloud scale file sharing system
All cloud files are stream-encrypted by different random
symmetric keys and stored in the Swift object storage when