See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/301348543

White Paper: Cloud Security: Basic Principles

Research · April 2016

CITATIONS READS

0 6,447

2 authors:

Salam Ismaeel Sarah Asiri

Ryerson University Ryerson University
59 PUBLICATIONS 447 CITATIONS 3 PUBLICATIONS 3 CITATIONS

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Energy Consumption Based VM Consolidations in Cloud Data Centres View project

Broadband Modernization View project

All content following this page was uploaded by Salam Ismaeel on 24 May 2016.

The user has requested enhancement of the downloaded file.

Cloud Security: Basic Principles
Cloud Security: Basic
Principles
Salam Ismaeel, Sarah Asiri Ryerson University
May 23, 2016
1 Abstract
nterest in cloud computing has been
I growing significantly in the past years.
More businesses are now switching to
the cloud for data management, storage and
analysis. According to the official NIST def-
inition, cloud computing is a model that al-
lows ubiquitous, convenient, on-demand net-
work access to a shared pool of computing
resources such as networks, servers, storage
and applications, which can be provisioned
rapidly with minimal management effort
or service provider interaction[1]. However,
security concerns have always been associ-
ated with cloud adoption. In this paper,
we discuss security challenges in the cloud
environment and their remedies. We also
focus on encryption in the cloud and discuss
some security considerations for OpenStack
platform.
2 Introduction
Security is the preservation of confidential-
ity, integrity and availability of information.
Other properties such as authenticity, ac-
2
countability, non-repudiation and reliability
also fall under the security dome. Confiden-
tiality is the assurance that information is
not made available or disclosed to unautho-
rized individuals, entities or processes. On
the other hand, integrity is the assurance
that the data being secured hasn’t been
tampered.
To ensure the security of information pro-
cessing , data controllers must implement
appropriate technical and organizational
measures in order to protect it against [2]:
(i) Unauthorized access or disclosure: in
particular where the processing involves the
transmission of data over a network. (ii)
Destruction: accidental or unlawful destruc-
tion or data loss(iii) Modification: inap-
propriate alteration and data tamper. (iv)
Unauthorized use: all other unlawful forms
of processing.
Security is the most prevalent factor in-
hibiting the adoption of cloud computing.
Cloud computing can become disadvanta-
geous in maintaining a level of assurance
sufficient to sustain confidence in potential
customers. The reasons behind the impor-
tance of cloud security are [3]: Increasing
usage of cloud services in non-traditional
sectors; growing adoption of cloud services
in government departments; Rise in cloud
service-specific attacks; Growing usage of
cloud services for critical data storage; Rise
in employee mobility.
This paper gives an introduction about
the security issues in cloud environments
with some possible treatments. In the paper,
we put more focus on data encryption in
the cloud. Additionally, OpenStack security
considerations will be covered in the last
section of this work.
3 Security Issues in Cloud
There are numbers of security issues for
cloud computing, some of which are new,
which are exacerbated by cloud models, and
others are similar to traditional service pro-
vision models.
The security risks depend greatly on the
cloud service and the deployment model.
Security issues in the cloud can be classified
into [4]:
- Access: representing physical ac-
cess, credentials, authentication, au-
thorization, identity management, and
anonymization.
But according to the Cloud Security Al-
liance (CSA), the top threats to cloud com-
puting are: Abuse and nefarious use of
cloud computing; Insecure interfaces and
APIs, Malicious insiders, Shared technol-
ogy issues, Data loss or leakage, Account or
service hijacking and Unknown risk profile
[2, 5]. The next subsections describe each
threat separately.
A. Gap in Security In the cloud
environment, customers cede control to
the cloud provider; there is a related risk
that the Cloud Service Provider (CSP) will
not adequately handle the responsibility
of addressing security the way they are
supposed to, or even that Service Level
Agreements (SLAs) do not include any
provision of the necessary security services.
This risk is dependent on the service model
used in the cloud.

- Storage and computing: including data B. Unwanted Access Cloud computing

storage, unreliable computing, avail- may actually increase the risk of access to
ability, cryptography, sanitization and confidential information by: (a)Foreign gov-
malware. ernments because the data on the cloud
could be anywhere in the world, this in-
- Virtualization: related to managing vir- creases the risks of government surveillance.
tual images (VMs), monitoring virtual And consumers may not be notified if this
machines, virtualized traffic and virtual happens according to the privacy policies of
machine mobility. that country. (b) Provider chains have in-
adequate security mechanisms in place. (c)
- Internet and services: covering ad- Data theft from machines in the cloud, like:
vanced persistent threats and malicious Rogue employees of CSPs; Data thieves
outsiders, protocols and standards, web breaking into service providers machines;
services, web technologies and availabil- Other customers of the same service if there
ity. is inadequate separation of different cus-
tomers data in a machine that they share
- Network : focusing on mobile platforms in the cloud; Attackers may also break into
and perimeter security. the networks of the CSP, subcontractors

3
or co-hosted customers; and Attackers may
also use de-anonymization techniques.
The damage that can be caused in
these cases can be greater than non-cloud
environments, due to the scale of operation
and the presence of certain roles in cloud
architectures with potentially extensive
access including CSP system administra-
tors and managed security service providers.
C. Vendor Lock-In As there is no
standardized communication between and
within cloud providers and no standardized
data export format, it is difficult to migrate
from one cloud provider to another or bring
back data and process it in-house.
D. Inadequate Data Deletion The
problem lies in ensuring that data that
should be deleted is actually wiped securely
cannot be recovered by a CSP. This
problem is exacerbated in cloud because:
(a) multiple copies of the data is available
on the cloud (b) it might be impossible
to destroy a disk since it is storing other
customers data. These risks of data
exposure vary according to the service
model.
E. Compromise of the Management
Interface This poses an increased risk
compared to traditional hosting providers
because remote access and web browser
vulnerabilities can be introduced and hence,
access can be given via these interfaces to
larger sets of resources.
F. Backup Vulnerabilities This serves
as a form of backup, although it can lead
to additional liabilities and threats from
attackers. There is still potential for the
data to be lost, particularly with Storage as
a Service. A popular solution is a type of
4
hybrid storage cloud. However, in general,
cloud services can be more resilient than
traditional services.
G. Isolation Failure In SaaS model, the
customers are users of multi-tenant appli-
cations developed by CSPs, where personal
data and even financial data are stored by
CSP in the cloud, and it is the responsibility
of the CSP to secure that data. There is a
risk that the mechanisms that separate stor-
age, memory or routing between different
tenants might fail, and hence, for example,
other tenants could access sensitive infor-
mation that belong to other customers.
Virtual machines (VMs) are sandboxed
environments and therefore completely
isolated from each other. This assumption
makes it safe for users to share the same
hardware. The use of virtualization can
introduce new security vulnerabilities, such
as: (a) Attackers can escape the boundaries
of this sandboxed environment and have
full access to the host. (b) Cross-VM
side-channel attacks, where the attacker
breaches the isolation between VMs
allowing extraction of data via information
leakage due to the sharing of physical
resources. (c) Virtual network attacks,
which occur with inadequate data deletion
before memory is assigned to a different
customer or escape to the hypervisor, where
an attacker uses a guest virtual machine
to attack vulnerabilities in the hypervisor
software.
H. Missing Assurance and Trans-
parency Cloud customers need to obtain
assurance from cloud service providers that
their data will be protected properly. They
may also require that they are notified about
security and privacy incidents. However, in
some cases, taking this approach can be
difficult, particularly in cases of multiple
transfers of data.
Cloud-based storage of data that requires
privacy assurance (such as personal data)
is almost always deployed in private clouds.
Heterogeneous cloud infrastructures make
it difficult to have effective controls to check
privacy compliance in an automated way,
and the end user has no means to verify
that his/her privacy requirements are being
fulfilled.
An open problem is finding a balance
between data provenance and related
privacy or other regulatory constraints in
the cloud, where physical perimeters are
not clearly delimited.
I. Inadequate Monitoring, Compli-
ance and Audit If a cloud customer mi-
grates to the cloud, their previous invest-
ment in security certification may be put
at risk if the CSP cannot provide evidence
of their compliance with the relevant re-
quirements and does not enable the cloud
customer to audit its processing of the cus-
tomers’ data. Furthermore, it may be diffi-
cult to evaluate how cloud computing affects
compliance with internal security policies.
CSPs need to implement internal compli-
ance monitoring controls, in addition to an
external audit process.
However, provisioning of a full audit trail
within the cloud, particularly in public
cloud models, is still an unsolved issue.
4 Possible Treatment
Full protection of the enterprise or its cus-
tomers’ personal information in the IaaS
cloud is difficult, but not impossible [6].
This section summarizes some possible treat-
ments for the security problems listed in the
previous section [7].
5
(i) Data leakage: API access control
should be implemented strongly. En-
cryption techniques should be enabled to
protect the integrity of data in transit as
well as at rest. Furthermore, the protection
of data should be analyzed at the time of
design as well as run time.
(ii) Abuse of cloud : Enforcing strict
initial registration with validation processes,
enhanced service for coordination and
monitoring of credit card fraud, service for
monitoring blacklists (public) for one’s own
network blocks.
(iii) Insecure Interfaces and
APIs:Proper analysis of the security
model of the interfaces is important. Also,
Ensuring that strong access control and
authentication methods are incorporated
with the encrypted transmission.
(iv) Malicious Insiders: Supply chain
management should be enforced strictly
and comprehensive supplier assessment
should also be conducted a as part of
legal contracts specified in human resource
requirements. Transparency is needed to
be maintained in all information security
practices and compliance reporting. Deter-
mination of a security breaches notification
processes is needed.
(v) Shared Technology Issues: Se-
curity should be implemented during
configuration. Environment activity
should be monitored effectively. Powerful
authentication and control access should be
promoted for the process of administration
and activities. Service level agreements
(SLA) should be enforced for the remedy
of patching and vulnerability. Scanning
of vulnerability and configuration audits
should have to be conducted.

(vi) Account or Service Hijacking :

Employ restrictions for the sharing of
account credentials between services and
users. Two-factor strong authentication
methods should be implemented where
possible. Unauthorized activity should be
detected effectively. Cloud provider security
policies and SLAs should be understood
clearly.

(vii) Identity as a Service (IDaaS):

A federated identity means that user’s
profile (attributes and credentials) will
be linked together and stored across
several identity management systems.
One application of federated identity is
Single-Sign-On (SSO), which enables access Figure 1: High Level SSO Illustration of Intel’s
Identity Bridge Solution[9]
control to all cloud applications in an
enterprise. SSO allows only a single point
of login to be used by users to access cloud rate, as well as availability and disaster
services and web applications used by an recovery capabilities. This can be achieved
enterprise. This enables the exchange by employing dual redundant data centers,
of trust relationships between multiple load balancing and clustered servers and
domains where authentication information applications. (3) It is imperative to consider
is shared across these domains, which can deploying strong authentication techniques
reduce security threats and management to authenticate users, such a two-factor
complexity [8]. Figure 1 provides an authentication, One Time Password (OTP),
abstract view of how an SSO solution can and context-aware authentication.
provide many benefits to enterprises.

Before integrating SSO into the customer’s

cloud solution, it is important to take a
few points into consideration [9, 10]: (1)
SSO solution should successfully integrate
with directory systems, such as Active
directory, Microsoft or Oracle. Additionally,
integration with third-party SaaS services,
such as Google, should be enabled. (2)
It is important that SSO solutions are
capable of maintaining a high uptime
5 Encryption in the Cloud
In the cloud, where there are multiple
tenants and administrators working for
someone else it would seem obvious that
huge amounts of data would need to be
encrypted [5]. The two main practical
problems in application of an encryption
scheme in the cloud are choosing the

6
suitable type of encryption based on application functionality. The power
business requirements and specifying the of such encryption is that no practical
algorithm within that class [11]. attacker can crate a valid ciphertexts
or modify a legitimate ciphertext with-
Full Disk Encryption (FDE) is one of the out the user noticing . However, this
well known techniques in which encryption sacrifices search, document preview, and
of the entire hard drive occurs while the other types of an application’s functionality.
device it is installed in is powered off
or first powered on, before the user or II. Selective encryption: It is done
administrator provides authentication to by encrypting only sensitive data such
enable the device to boot up. It protects as social security numbers or account
data from being compromised if the server numbers. Selective encryption is often
or its storage is lost or stolen. But FDE used in sharing applications when content
does absolutely nothing to protect a Server inspection and identification capability is
Area Network (SAN) that is powered on used to determine sensitive data, enabling
and running on a cloud data center from users to encrypt based on a policy. Search
Malware, insider threats, and other current functionality in this type of encryption may
threats. not be available.

There are three useful layers of encryption

III. Format Preserving Encryption
used outside the FDE encryption:
(FPE): FPE keeps the length and the
• Application layer Encryption: by format of the original text. Such function-
implementing encryption and decryp- ality is useful when a specific format is
tion routines within the application. required by the application. The FPE very
useful if the application requires server-side
• File Encryption: individually en- input validation checks, and the security
crypt files as they are written to the requirements can tolerate equality leakage.
disk, and decrypt the required file only
when needed, leaving the rest of the IV. Searchable encryption: In some
files encrypted. applications, we can waiver some security
• Database Encryption: Individual to utilize searching ability. In general,
database records, or even particular security weakness it shares is that the
fields within a record, can be main- equality of keywords is leaked making
tained in an encrypted state and only certain statistical attacks possible. There
decrypted individually when proper au- are three different approaches in searchable
thorization is granted. encryption: (1) Keyword extraction: by
preserving the search keywords on en-
This is done by one or more of the seven crypted documents. This method is useful
types of encryption: if we usually search documents for certain
keywords only. (2) Word-by-word : by
I. Regular (Unstructured) data encryp- encrypting each word individually, making
tion: It is the best candidate to encrypt the document searchable by any word. But
data in storage but severely impacts with equality leakage, makes statistical

7
attacks possible. (3) Search by prefix : by
leveraging a local search tokenization index,
i.e. local plaintext index of search word
as data is sent to a cloud provider. The
main problem in this approach is that
the user requires access to the local index
before going to the cloud. Also, this local
index represents a good target for attackers.
V. Order-Preserving Encryption (OPE):
in this type, the ciphertexts preserve order
of plaintexts. This make it easy to search,
sort, query the ciphertexts. But totally
effects the confidentiality of the ciphertext
because of the leakage of the relative
distance between it and the underlying
plaintexts.
VI. Data tokenization: It depends on
the creation of a token for each plaintext,
and storing the data and tokens locally
and then passing the tokens to the cloud
application. This enable the user to search
for keywords and sort through the data on
the server. But it has the same drawbacks
as the order-preserving encryption (OPE).
In addition, the local storage for the data
and the corresponding tokens should be
protected.
VII. Fully Homomorphic Encryption
(FHE): The cloud receives the ciphertext
of the data, performs computations on the
ciphertext, and returns the encoded value
of the result [12]. The main problem in
that higher-level operations and real world
functionality are still many years away.
8
6 Encryption Key Manage-
ment
One of the most difficult processes in public
cloud computing is key management. When-
ever, we have strong key management we
should get strong security. Because key
generation and management for cloud com-
puting paradigm is not standardized, in this
section the best practices for encryption key
management are summarized [5, 13, 14]:
- Maintain control of all private/secret
encryption keys. It’s fine to use en-
cryption services offered by the cloud
provider or a reputable third party, as
long as the party offering the services
do not get access to the encryption
keys.
- Use the best practices regarding the key
management and encryption products
from reliable vendors.
- Use off-the-shelf-technology where pos-
sible. By storing encryption keys sep-
arately from encrypted data. Encryp-
tion keys also should not be stored
within application configuration files
or compiled into the application itself.
- The key scope should be maintained at
the individual or group level.
- Configure encryption to be transparent
to users. To make security usable, it’s
critical that encryption be as transpar-
ent as possible, ideally so that users
aren’t even aware it’s in use.
- Use standard algorithms and do not
use proprietary encryption algorithms.
In summary, organizations with sensitive
data stored in clouds should encrypt this
data in a matter that they maintain control Dashboard (horizon) It is a public
over the encryption keys. These keys should facing manner with all the usual security
be stored separately from the encrypted concerns of public web portals. Identity
data to prevent a single compromise from (keystone) Security concerns here related
granting access to both the keys and the to trust in authentication, management of
data they protect. Moreover, encryption authorization tokens, and secure communi-
should be configured to be transparent to cation.
users so that it does not affect usability. Image (glance) Trusted processes for
managing the life cycle of disk images
are required, as are all the previously
7 OpenStack: Security Do- mentioned issues with respect to data
mains security.
Data processing (sahara) Security con-
This section gives an overview of OpenStack siderations for data processing should focus
Services security considerations and Open- on data privacy and secure communications
Stack security domains. All these part need to provisioned clusters.
further studying and analysis. The goal is to
give a brief idea about these topics. All the- Other Consideration OpenStack re-
sis information are mainly given by Open- lies on messaging for internal communica-
Stack Organization, specially from [15]. tion between several of its services. By de-
fault, OpenStack uses message queues based
7.1 OpenStack Security on the Advanced Message Queue Protocol
Consideration (AMQP). The message queuing system is a
primary security concern for any OpenStack
OpenStack components’ security considera- deployment.
tions are: At last, securing the access to the
Compute (nova) The security of databases and their contents is yet another
Compute is critical for an OpenStack security concern.
deployment. The techniques used should
include support for strong instance iso-
7.2 OpenStack Security Domains
lation, secure communication between
Compute sub-components, and resiliency A security domain includes users, applica-
of public-facing API endpoints. tions, servers or networks that share com-
Object Storage (swift) and Block mon trust requirements and expectations
Storage (Cinder) In the two modules, within a system. Typically they have the
security should focus on access control and same authentication and authorization re-
encryption of data in transit and at rest. quirements and users.
Other concerns may relate to system abuse, Although you may desire to break these
illegal or malicious content storage, and domains down further, generally these four
cross authentication attack vectors. distinct security domains (Public, Guest,
Networking (neutron) Security concerns Management and Data) form the minimum
with the networking service include network that is required to deploy any OpenStack
traffic isolation, availability, integrity and cloud securely. These security domains
confidentiality. can be mapped independently or combined

9
to represent the majority of the possible is considered trusted. However, when
areas of trust within a given OpenStack considering an OpenStack deployment,
deployment. there are many systems that bridge this
domain with others, potentially reducing
Public The public security domain is the level of trust you can place on this
an entirely untrusted area of the cloud domain.
infrastructure. It can refer to the Internet
as a whole or simply to networks over which Data The data security domain is
you have no authority. Any data that concerned primarily with information
transits this domain with confidentiality or pertaining to the storage services within
integrity requirements should be protected OpenStack. Most of the data transmitted
using compensating controls. This domain across this network requires high levels
should always be considered untrusted. of integrity and confidentiality. In some
cases, depending on the type of deployment
there may also be strong availability
Guest Typically used for compute
requirements.
instance-to-instance traffic, the guest
security domain handles compute data
generated by instances on the cloud but Bridging security domains A bridge
not services that support the operation is a component that exists inside more than
of the cloud, such as API calls. Public one security domain. Any component that
and private cloud providers that do not bridges security domains with different trust
have stringent controls on instance use levels or authentication requirements must
or allow unrestricted internet access to be carefully configured. These bridges are
VMs should consider this domain to be often the weak points in network architec-
untrusted. Private cloud providers may ture. A bridge should always be configured
want to consider this network as internal to meet the security requirements of the
and trusted, only if the proper controls are highest trust level of any of the domains
implemented to assert that the instances it is bridging. In many cases the security
and all associated tenants are to be trusted. controls for bridges should be a primary
concern due to the likelihood of attack.

Management The management se-

curity domain is where services interact.
Sometimes referred to as the ”control
plane”, the networks in this domain trans-
port confidential data such as configuration
parameters, user names, and passwords.
Command and Control traffic typically
resides in this domain, which necessitates
strong integrity requirements. Access to
this domain should be highly restricted and
monitored. At the same time, this domain
should still employ all of the security best
practices. In most deployments this domain
8 Summary
We can notice by the end of this chapter,
there are several challenges and research
area within the topic of Cloud Security form
the formal aspects to empirical research
outlining novel techniques. All of the
users whether individual or organization
should be well aware of the security threats
existing in the cloud.
And because OpenStack is the most inter-

10
 esting platform during our course,security risk and remedy,” in Computational In-
considerations in OpenStack Services were telligence and Networks (CINE), 2015
given. But still, the chapter should cover International Conference on. IEEE,
more details about Keystone project that 2015, pp. 192–193.
provides Identity, Token, Catalog and Pol-
icy services for use specifically by projects [8] M. Stihler, A. O. Santin, A. L. Mar-
in the OpenStack family. con Jr, and J. D. S. Fraga, “Integral fed-
erated identity management for cloud
computing,” in New Technologies, Mo-
References bility and Security (NTMS), 2012 5th
International Conference on. IEEE,
[1] T. G. Peter M. Mell. (2011) The nist 2012, pp. 1–5.
definition of cloud computing.
[9] J. Reavis, “How intel cloud sso works,”
[2] S. Pearson and G. Yee, Privacy and Tech. Rep., 2015. [Online]. Available:
security for cloud computing. Springer http://www.opendatacenteralliance.org
Science & Business Media, 2013.
[10] T. Eid, “Cloud single sign-on for saas
[3] V. Chary and A. Krishna. (2012) providers,” Tech. Rep., 2015. [Online].
Cloud security. [Online]. Available: Available: https://www.intralinks.com
http://www.slideshare.net/VenkateshChary/cloud-
[11] A. Boldyreva and P. Grubbs, “Making
security-ppt encryption work in the cloud,” Network
Security, vol. 2014, no. 10, pp. 8 – 10,
[4] D. Fernandes, L. Soares, J. Gomes,
2014.
M. Freire, and P. Incio, “Security
issues in cloud environments: a [12] S. Ruj and R. Saxena, “Securing cloud
survey,” International Journal of data,” Cloud Computing with e-Science
Information Security, vol. 13, no. 2, Applications, p. 41, 2015.
pp. 113–170, 2014. [Online]. Available:
http://dx.doi.org/10.1007/s10207- [13] M. Ali, S. U. Khan, and A. V. Vasi-
013-0208-7 lakos, “Security in cloud computing:
Opportunities and challenges,” Infor-
[5] C. S. Alliance. (2011) Security guid- mation Sciences, vol. 305, pp. 357–383,
ance for critical areas of focus in cloud 2015.
computing v3.0. [Online]. Available:
https://cloudsecurityalliance.org [14] K. Scarfone, “The true story of
data-at-rest encryption and the cloud,”
[6] H. Albaroodi, S. Manickam, and Tech. Rep., 2015. [Online]. Available:
P. Singh, “Critical review of openstack https://www.firehost.com
security: Issues and weaknesses,” Jour-
[15] OpenStack. (2015) Openstack se-
nal of Computer Science, vol. 10, no. 1,
curity guide. [Online]. Available:
p. 23, 2013.
http://docs.openstack.org/sec/
[7] A. Aich, A. Sen, and S. R. Dash, “A
survey on cloud environment security

11

View publication stats