Page |1

Security threats and vulnerabilities for

compute cloud and storage cloud

ALARIFI, SUAAD

Student Number: 100603756

SUPERVISOR: STEPHEN WOLTHUSEN

Submitted as part of the requirements for the award of the MSc in

Information Security at Royal Holloway, University of London.

I declare that this assignment is all my own work and that I have acknowledged all
quotations from the published or unpublished works of other people. I declare that I have
also read the statements on plagiarism in Section 1 of the Regulations Governing
Examination and Assessment Offences and in accordance with it I submit this project report
as my own work.

Signature Date 02 September 2009

 Page |2

Table of Contents
Executive Summary............................................................................................Page 3
Chapter 1: Introduction...................................................................................... Page 4
Chapter 2: Literature Review.............................................................................. Page 7
1. HISTORY OF CLOUD COMPUTING...................................................................... Page 7
2. CLOUD COMPUTING DEFINITION........................................................................ Page 7
3. CLOUD COMPUTING SECURITY PAPERS AND INFORMATION RESOURCES.. Page 7
4. CLOUD SECURITY INITIATIVES............................................................................ Page 9
5. THE POSITION OF THIS RESEARCH.................................................................... Page 9
6. LIMITATIONS.......................................................................................................... Page 9
Chapter 3: Cloud Communication Security........................................................... Page 11
1. INTRODUCTION..................................................................................................... Page 11
2. CLIENT-TO-CLOUD CONNECTION....................................................................... Page 12
3. ROUTING AND DNS SECURITY THREATS........................................................... Page 18
4. CONCLUSION........................................................................................................ Page 19
Chapter 4: Client Side Security.......................................................................... Page 20
1. INTRODUCTION..................................................................................................... Page 20
2. PHYSICAL SECURITY........................................................................................... Page 20
3. WEB BROWSERS’ SECURITY................................................................................ Page 21
4. MALICIOUS CODE................................................................................................. Page 21
5. CONCLUSION........................................................................................................ Page 24
Chapter 5: Provider Side Security....................................................................... Page 25
1. INTRODUCTION..................................................................................................... Page 25
2. VIRTUALISATION SECURITY IN THE CLOUD...................................................... Page 26
3. UNSECURE APPLICATIONS, AND PATCHING MANAGEMENT.......................... Page 36
4. APIS SECURITY..................................................................................................... Page 38
5. PRICING MODEL ATTACK, EDOS (ECONOMIC DENIAL OF SUSTAINABILITY). Page 38
6. CONCLUSION........................................................................................................ Page 39
Chapter 6: Storage cloud Security...................................................................... Page 40
1. INTRODUCTION..................................................................................................... Page 40
2. HOW STORAGE CLOUD WORKS......................................................................... Page 41
3. STORAGE CLOUD THREATS................................................................................ Page 41
4. STORAGE CLOUD AVAILABILITY......................................................................... Page 42
5. DATA CORRECTNESS........................................................................................... Page 42
6. CONFIDENTIALITY................................................................................................. Page 44
7. CLOUD RAID......................................................................................................... Page 46
8. CONCLUSION........................................................................................................ Page 48
Chapter 7: Research Contribution and Conclusion................................................Page 49
References........................................................................................................Page 50
Appendix A.......................................................................................................Page 55
 Page |3

Executive Summary
The idea of cloud computing is providing IT functions as a service. Cloud providers rent their underlying
infrastructure and servers to organisations as a service. This research introduces the technologies used in
cloud computing and surveys most existing security threats to and vulnerabilities of the cloud. It also
presents an overview of cloud computing security and covers most security areas related to compute
cloud and storage cloud. The researcher gathered large number of previous papers, articles, blogs, and
interviews about cloud computing security and analysed them. Some gaps were found for some cloud
computing security issues that are not covered by any other research, such as the special damage that
worms can do to the cloud by consuming bandwidth, which could affect the cloud pricing model, which is
pay per use. The researcher tried to cover these gaps using her experience and study in information
security.

Compute cloud and storage clouds fall under the infrastructure as a service (IaaS) category of cloud
computing. There are four core chapters in this research, i.e., cloud communication security, client side
security, provider side security, and storage security.

Cloud communication threats and vulnerabilities are discussed in chapter 3. Communication security is a
major part of cloud overall security and is important to enhance the overall cloud security. This chapter
discusses the security of the connection between clients and their providers. The chapter covers some
major issues, e.g., confidentiality, authentication, routing, and DNS security. It also discusses some threats
and attacks, e.g., sniffing, impersonation, weak passwords, private keys, session hijacking, DoS/DDoS
attacks, Man-in-the-Middle attacks, downgrade attacks, cookie threats, and MD5 digitally-signed
certificate threats. Chapter 4 discusses client side security, which is a part of cloud security that is
complicated and hard to control, because cloud clients can work from anywhere using any machine,
which makes their security hard to maintain by providers. The chapter discusses clients’ physical
security, web browser security, and malicious codes. Chapter 5 discusses provider side security, which
covers virtualization security, application security, patching management, APIs security, and some
attacks, such as economic denial of sustainability attack. Chapter 6 addresses concerns with storage
security, including availability, data correctness, and confidentiality issues. Cloud physical security and
cloud perimeter security are out of the scope of this research.
 Page |4

Chapter 1: Introduction
In the last few months, many conferences, interviews, articles, and websites have addressed cloud
computing. Cloud computing has captured the interest of both business people and IT people. Business
people look at cloud computing as a way to reduce expenditures on IT and the shortage of professional
workers. Furthermore, it helps them to stop thinking about technologies and allows them to focus on
business. On the other hand, IT people have different expectations about cloud computing. Some of them
think that it is the wave of the future, while others believe that it is just a passing fancy. So, what is cloud
computing, really?

According to National Institute of Standards and Technology (NIST), cloud computing ‘is a pay-per-use
model for enabling available, convenient, on-demand network access to a shared pool of configurable
computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly
provisioned and released with minimal management effort or service provider interaction’ [MG09b].
Virtualization is the enabling technology for cloud computing, and its basic unit is the data centre [PM08].

Many papers have discussed the benefits and weaknesses of cloud computing from a business point of
view. The benefits include high utilization, agility, pollution reduction, and cost reduction. The
weaknesses include vendor lock-in and regulatory satisfaction. However, for the purposes of this
research, the most important factors are the benefits and weaknesses from an information security
perspective. First, cloud computing could improve overall security by increasing availability without the
need for redundant servers and it allows easy expanding, since one of the main properties of cloud
computing is the ability to expand dynamically when required on a pay-per-use basis. Second, cloud
computing provides a better opportunity to automate many security processes, such as patching, because
of virtualization technologies. Furthermore, locating an enterprise’s data centrally in the cloud could
improve security by preventing data from spreading in different computers and devices. In addition,
moving to the cloud could be one extra option of the risk transfer solutions.

On the other hand, cloud computing inevitably has many negative consequences for information security.
First, enterprises lose control of their data when sent to the cloud. Second, it is not clear yet how to
measure cloud performance and the quality of security. In addition, there is a need for a high level of trust
between providers and enterprises, and there is a need for trust measurement and indicators.
Furthermore, to date, there are no cloud computing standards, which means that the level of security
varies by provider and affects interoperability. There is also a problem with compliance and satisfying
regulatory requirements. Also, there are some difficulties associated with performing penetration tests
and security scanning in the cloud. Last, there is a problem with the transparency and reliability of
providers they offer their services as block boxes without revealing the security details.
 Page |5

As described above, there are many issues associated with the security of cloud computing. In a survey
conducted by the International Data Corporation (IDC) in August 2008, security was the number one
concern about cloud computing services, as shown in Figure 1.1 [IDC08].

Figure 1.1 [IDC08]: IDC’s survey results 2008

Because of the security concern, some enterprises chose to send only their non-critical functions to the
cloud. However, it is expected that this situation will change when newly established organizational
requirements start from the beginning in the cloud for all of its critical and non-critical functions.
Furthermore, other some non-critical data in the cloud may grow in size and importance and become
critical with time. For cloud computing to flourish and be widely used, the security concerns must be
resolved.

There are three well-known types of cloud computing. The first is Infrastructure as a Service (IaaS), such
as Amazon EC2, which supplies virtualized infrastructure to be used in processing, storage, and
networking functions. Enterprises can rent these functions and use them to run their operating systems
and applications [CSA09]. The second type of cloud computing is known as Platform as a Service (PaaS),
and an example is Google’s Apps Engine, which supplies a virtualized platform to be used by clients to
develop applications [CSA09]. In PaaS, clients only use the programming language and tools that are
supported by the provider [CSA09]. The third type is known as Software as a Service (SaaS), and an
example is Salesforce, which supplies applications to be used by the clients, and those applications are
hosted in the providers’ servers [CSA09].

This research covers security threats and vulnerabilities for computing clouds and storage clouds that fall
under the IaaS category of cloud computing. There are four core chapters in this research, i.e., cloud
communication security, client side security, provider side security, and storage security. Physical
security and perimeter security are out of the scope of this research.

Cloud communication threats and vulnerabilities are discussed in chapter 3. Communication security is a
major part of cloud overall security and is important to enhance the overall cloud security. This chapter
discusses the security of the connection between clients and their providers. The chapter covers some
 Page |6

major issues, e.g., confidentiality, authentication, routing, and DNS security. It also discusses some threats
and attacks, e.g., sniffing, impersonation, weak passwords, private keys, session hijacking, DoS/DDoS
attacks, Man-in-the-Middle attacks, downgrade attacks, cookie threats, and MD5 digitally-signed
certificate threats. Chapter 4 discusses client side security, which is a part of cloud security that is
complicated and hard to control, because cloud clients can work from anywhere using any machine,
which makes their security hard to maintain by providers. The chapter discusses clients’ physical
security, web browser security, and malicious codes. Chapter 5 discusses provider side security, which
covers virtualization security, application security, patching management, APIs security, and some
attacks, such as economic denial of sustainability attack. Chapter 6 addresses concerns with storage
security, including availability, data correctness, and confidentiality issues. The next chapter, Chapter 2,
presents the literature review.
 Page |7

Chapter 2: Literature Review

1. HISTORY OF CLOUD COMPUTING

Cloud computing idea is not new; the first thought about cloud computing was In 1961 at MIT Centennial
when John McCarthy said ‘computing may someday be organized as a public utility just as the telephone
system is a public utility’ [MG09b]. One of the first authors who wrote about cloud computing was
Nicholas G. Carr in his book Does IT Matter in 2004. He also wrote another book with almost the same
idea in 2007 with the title The Big Switch. Both books talks about computing power as a utility and based
on the idea of sharing resources. There are also number of books about cloud computing from business
perspective however, until now there is no books about cloud computing that discuss the technical details
about cloud computing from security perspective. The first realization for cloud computing idea was in
2006 by Amazon when it inaugurates the test version of Amazon EC2 [TSY09]. Their idea was mainly
renting their infrastructure to organization via the Internet [TSY09]. Cloud computing is as returning to
mainframes and supercomputers. It is also some forms of outsourcing which a popular concept in
business. Some old services that Internet users are familiar with such as web based email services such as
hotmail and yahoo are also some forms of cloud computing software as a service because they are
services in shared environments provided via the Internet using web browsers.

2. CLOUD COMPUTING DEFINITION

There are large numbers of cloud computing definitions some of them are absolutely different than each
other. It is widely thought that there is a need to have a constant, clear and complete definition for cloud
computing. Having this definition is important ‘to determine the areas of research and explore new
application domains for the usage of the Clouds’ [VRCL09]. One of the most popular definitions for cloud
computing was produced by National Institute of Standards and Technology (NIST). They define cloud
computing as ‘a model for enabling convenient, on-demand network access to a shared pool of
configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be
rapidly provisioned and released with minimal management effort or service provider interaction. This
cloud model promotes availability and is composed of five essential characteristics, three delivery
models, and four deployment models’ [MG09a]. The details of this definition can be found in Draft NIST
Working Definition of Cloud Computing which is in the appendix A. They publish the definition in a
separate document in their web site and update it regularly.

3. CLOUD COMPUTING SECURITY PAPERS AND INFORMATION RESOURCES

The idea of cloud computing and the technologies used are not new. For instance, virtualization, which is
the enabler of cloud computing, is a relatively old technology, and virtualization security is a widely
discussed topic. There are relatively few papers about cloud computing security. Most of them provide an
introduction to cloud computing security for one component of security, such as privacy in cloud
computing or privacy. Due to the shortage technical papers on cloud computing security and since the
idea of cloud computing is not new, cloud computing security can be tackled by separating the topic into
 Page |8

subtopics and compare to other similar topics that are widely analysed. For instance, the first subtopic is
cloud communication channel security which can be compared to online banking security due to the fact
that both deal with sensitive and attractive data for attackers on the Internet, using web browsers and
essentially the same security technologies, such as SSL VPN. Therefore, any paper that discusses online
banking security can be used for cloud communication security, such as Symantec’s white paper on
“Threats to Online Banking” [CW05]. Furthermore, many resources are available for technical details, such
as IETF RFC2716 - PPP EAP TLS Authentication Protocol [AS99] and the NIST Guide to SSL VPNs
[FHOP08].

The second subtopic is client side security, which can be compared to teleworker or telecommuter
security and remote access, because both are outside the organization’s perimeters, and they suffer the
same threats and vulnerabilities. NIST has published two helpful guides for this area of security, which
are the “NIST User’s Guide to Securing External Devices for Telework and Remote Access” [SS07] and the
“NIST Guide to Malware Incident Prevention and Handling” [MKN05]. The latter Guide is considered in this
research because malware is still the number one threat to client systems.

The third subtopic is provider side security, which can be broken down into virtualization security, data
centres security, and enterprises security in general. For instance, for virtualization security, VMware
white papers are a good resource for the technical details and facts, such as “Virtualization Overview”
[VMW09a] and “Understanding Full Virtualization, Paravirtualization, and Hardware Assist” [VMW09b].
Symantec’s advanced threat research also has produced a useful product called “Attacks on Virtual
Machine Emulators” [PF06]. Large numbers of papers are available on virtualization security and data
centres security. In addition, cloud provider services have a unique property, i.e., the pricing model (pay
per use), and this could be the only new source of threat that is dedicated to cloud computing such as
Economic Denial of Sustainability attacks (EDoS) and consuming network bandwidth by worms to
increase the cost, which may also affect the cloud pricing model. EDoS was developed by Christofer Hoff, a
Chief Security Architect at Unisys, and he discussed it in his blog with the title “Cloud Computing Security:
From DDoS (Distributed Denial Of Service) to EDoS (Economic Denial of Sustainability)” [CH08].

The fourth subtopic is storage cloud security, which can be compared to remote storage in untrusted
environments security. There are many published papers and standards about remote storage in general
and about encryption, which is essential for storage confidentiality. One example is “NIST Guide to Storage
Encryption Technologies for End User Devices” [SSS07]. There are also numbers of papers about storage
cloud, such as standards published by Storage Networking Industry Association (SNIA), e.g., “Storage
Security Best Current Practices” (BCPs) [SNIA08] and “Cloud Storage Reference Model” [SNIA09]. In
addition, papers about storage cloud have been produced by researchers in universities and research
centres, such as “Ensuring Data Storage Security in Cloud Computing” [WWRL09]. Furthermore, many
papers about grid computing storage are also useful for storage cloud, such as “Reliability in Grid
Computing Systems” [CD09].
 Page |9

There have been attempts to develop standards for cloud computing, such as the one prepared by the
Cloud Security Alliance in April 2009, entitled “Security Guidance for Critical Areas of Focus in Cloud
Computing” [CSA09]. In the author’s opinion, this is the most comprehensive security guidance available
about cloud computing security. Furthermore, Amazon prepared a useful paper entitled “Amazon Web
Services: Overview of Security Processes” about Amazon cloud security in general [Ama09a], which can
help researchers determine which technologies are used in the cloud. Also, the cloud computing
community group, which is based in the cloud computing Google Group, has a very useful cloud
computing incidents database (CCID) [Clo09].

4. CLOUD SECURITY INITIATIVES

Until now, the most obvious players in cloud computing security area have been some providers, such as
Amazon, IBM, the United States Department of Defense (DoD), the Cloud Security Alliance (a non-profit
organization that seeks to improve the security of cloud computing), and the European Network and
Information Security Agency (ENSIA), which funds research in cloud computing risk assessment.

5. THE POSITION OF THIS RESEARCH

The author believes that there is a need for research that satisfies the following requirements:

¬ Gathers large number of previous papers, articles, blogs, and thoughts of security researchers
about cloud computing
¬ Introduces the technologies used in cloud computing
¬ Surveys all cloud computing threats and vulnerabilities
¬ Clarifies the current blurred vision of cloud computing security
¬ Draws the big picture of cloud computing security

Research such as this could help other cloud computing researchers know where to start in their quest to
produce papers that are more focused on security. This is the idea of this research, and each section of it
can be a topic for separate research.

6. LIMITATIONS

Some obstacles face research in cloud computing security. The first and foremost obstacle is the lack of
technical details about current cloud computing services. Providers want clients and researchers to deal
with their services as a black box. They reveal few details, and some of them may provide security
through obscurity. Another obstacle is the instability or the lack of consistency of the concept of cloud
computing. The concept grows every day from different directions, which makes it difficult to understand
and analyse from a security perspective.

Furthermore, a research publication from the University of California, entitled “The Eucalyptus Open-
source Cloud-computing System”, stated that ‘most cloud computing systems in operation today are
proprietary, rely upon infrastructure that is invisible to the research community, or are not explicitly
designed to be instrumented and modified by systems researchers interested in cloud computing
 P a g e | 10

systems’ [NWG+08]. In the same paper, the researchers developed and introduced a new, open-source
system for cloud computing IaaS, called EUCALYPTUS. The system interface and tools emulate the
Amazon EC2 interface and tools, and it is useful for academic research and testing [NWG+08].
 P a g e | 11

Chapter 3: Cloud Communication Security

1. INTRODUCTION

Cloud communication suffers from a wide range of threats and vulnerabilities. These threats and
vulnerabilities must be collected and analyzed to enhance the overall security of the cloud. Cloud
computing communication security is the most important issue of all the issues related to cloud
computing security. There is a number of reasons that lead to give cloud communication security extra
attention. First, the Computing Community Incident Database (CCIDB) shows that the majority of cloud
computing security incidents documented for 2008 and early 2009 were related to communication
channels. The documented security incidents included such incidents as the man-in-the-middle attack,
session hijacking, and impersonation attacks. The rest of the documented incidents included malware
infections and data breaches, which are related to client security that is addressed in the next chapter
[CSA09, Clo09]. Furthermore, Amazon EC2 service, a major compute cloud provider in the market,
recently announced that it has fixed the problem of secure shell (SSH) spoofing attacks to their machine
images, which is also related to the security of communication [AS09]. Such spoofing attacks are an
indicator that cloud communication security is targeted.

The second reason that gives cloud communication security its importance is the nature of cloud
computing services. Cloud computing users (clients) remotely access their data and services in their cloud
provider’s network. This remote access requires that clients’ sensitive data be sent to the provider’s
network over the public Internet, which makes them vulnerable to several attacks. Data transmitted from
clients to cloud and vice versa can pass through completely hostile networks, so the cloud provider
should not rely on the security of the underlying networks. If an attacker successfully reads and
understands all of the traffic between clients and their cloud provider, the situation is as dangerous as
dealing with sensitive and non-sensitive data on a fully-compromised workstation. The assumption that is
made here that attackers can sniff and obtain copies of all traffic between clients and providers. This
assumption is reasonable because the traffic goes over the Internet, which is an insecure, public network.
Worst-case assumptions are generally used in information security research in order to be on the safe
side.

The third reason for focusing on communication security is the special attributes of cloud data. Cloud data
that flow over the Internet have special features that are different from any other data. They are different
in volume, degree of sensitivity, and format. First, compute cloud data have relatively high volume. Each
keystroke may generate a packet. In the author’s opinion, connection to the cloud carries the same data as
internal buses inside the computer in view of the fact that users are remotely connected to their
machines. All commands are sent remotely to different parts of the client’s virtual machine, such as the
processor, memory, and I/O devices, in the cloud. Storage cloud data have high volume as well, because
users usually need to store hundreds of gigabytes of data, and these data must be sent over the Internet.
Second, both compute and storage clouds’ data that flow over the Internet are sensitive in nature, such as
 P a g e | 12

credential information, personal data, and financial reports. Finally, cloud data stream format and shape
could be unique, such as API commands, and may be recognized during transmission.

In this section, cloud communication security threats and vulnerabilities are discussed and analyzed.
There are three areas of communication in the cloud, which are client-to-cloud connection, cloud-to-cloud
connection, and inter-cloud connection. The terms “client-to-cloud connection,” “cloud-to-cloud
connection,” and “inter-cloud connection” were first used by Char Sample and Diana Kelley in their
publication entitled “Cloud computing security: Routing and DNS security threats“ [SK09b]. The same
terms are used in this research. The client-to-cloud connection is the communication channel between a
client and her or his cloud provider, and it is the most vulnerable of the three channels. The inter-cloud
connection is the communication channel between different hosts inside the cloud itself. For instance,
virtual machines in one host may be migrated to another host in the same cloud for load-balancing
purposes. The cloud-to-cloud connection is the communication channel between different clouds. For
instance, for backup purposes as a best practice, a copy of data must be stored in another host in another
location, i.e., in another cloud. Therefore, there must be a communication channel between the clouds.
The first and third types of cloud communication are almost the same from a security perspective; both
are built over the Internet and threatened by the whole outside world. However, the inter-cloud
connection occurs within the perimeter of the cloud provider’s network, which makes it more secure.
The inter-cloud connection is threatened by unauthorised access, neighboring clients, and the cloud
employees. This chapter discuss only the security of client-to-cloud communication because it is the one
that is most threatened, and it covers threats and vulnerabilities for the other two types. Furthermore, the
security of the main way of communication between clients and providers which is SSL VPN channels is
discussed. SSL VPN (Secure Sockets Layer Virtual Private Networks) is most popular mechanism for
providing secure access to remote resources in the cloud [FHOP08]. This chapter also covers the security
of DNS services and routing services. DNS (Domain Name System) is the system that is responsible for
translating domain names to IP addresses and vice versa [CR06].

2. CLIENT-TO-CLOUD CONNECTION

The client-to-cloud connection is the communication channel between a client and her or his cloud
provider. This communication channel is targeted by hackers and suffers from different kinds of threats
and vulnerabilities. In the author’s opinion, from a security perspective, there is a high similarity between
transmitted cloud data and online banking transmitted data. Generally, both are sensitive and very
attractive to attackers. However, cloud data have a much higher volume than online banking data, which
affects performance if cloud data are treated with the same security techniques used for online banking
data. For instance, different cryptographic primitives can be used to encrypt a kilobyte of data or
gigabytes of data to maintain performance. In general, however, the same security threats and
vulnerabilities exist for the client-to-bank connection and the client-to-cloud connection.

There are two essential factors that govern the communication channel between the client and her or his
cloud provider. The first of these factors is security and specifically confidentiality, meaning that the
 P a g e | 13

transmitted data should not be sent in clear but should be encrypted. The second factor is performance,
meaning the data must be dealt with on the fly to cope with the high-volume nature of cloud data.

Cloud providers and online banking alike must build a secure communication channel with their clients
over the Internet. Most providers use a point-to-point VPN to create the required secure communication
channel and enhance performance. There are two main choices for building VPNs which are IPsec and
SSL. Most cloud providers prefer VPN through SSL than through IPsec for a number of reasons. First, SSL
is already available in almost all browsers, and there is Java applet for non-browser products, while IPsec
requires that a special client application be installed. Second, SSL is routinely used in e-commerce and
online banking, so the ISP (Internet Service Provider) does not block the traffic, while IPsec traffic is
blocked by many ISPs [CF03]. Third, SSL works well with network address translation (NAT), while IPsec
does not [CF03]. Fourth, SSL does not require as much public key infrastructure (PKI) overhead as IPsec
[LM08], whereas both provide almost the same level of security [SK09a, CF03]. In addition, SSL-based
VPN can ensure that clients comply with the cloud provider’s security policies [LM08], and this will be
addressed in more detail in the client security chapter. It is widely thought that IPsec will become more
acceptable in the future because of IPv6 support; however, it may take many years for this to happen
[CF03].

The current situation is that providers are using SSL-based VPN. Since the SSL-based VPN connection has
some considerable security threats and vulnerabilities, we will discuss the security of SSL VPN in detail in
this research.

2.1. SSL VPN SECURITY THREATS AND VULNERABILITIES

SSL VPN has a number of threats and vulnerabilities. It is used to provide confidentiality and
authentication, either unilateral or mutual. Furthermore, it allows parties to negotiate and agree on a
session key in a way that protects confidentiality and integrity. To explain how SSL works, the protocol
will be simplified in three stages. First, establish a TCP connection between the client’s browser and her
or his provider. Then, run the SSL handshake protocol on TCP/IP and agree on the encryption algorithm
and a session key. Digital certificates are used to provide authentication service and exchange the session
key in a confidential way. Authentication is done during the handshake protocol using digital certificates
provided by a certificate authority (CA) that is trusted by all parties. In cloud computing, unlike e-
commerce, there is a need for mutual authentication in which the client authenticates the identity of the
provider and vice versa [IBM08]. The client is required to authenticate the provider, just as is the case in
e-commerce, to prevent several attacks, such as phishing attacks. The provider is required to authenticate
the client using an SSL-encrypted session, just as is the case in remote access, to prevent anonymous
users from connecting to the cloud [SHS09]. The authentication protocol is called Extensible
Authentication Protocol - Transport Layer Security (EAP-TLS). TLS and SSL are similar, and TLS can be
considered as a more formal version of SSL. Microsoft created EAP-TLS, and the Internet Engineering
Task Force (IETF) adopted it as RFC 2716 [AS99]. After the handshake protocol has been completed
successfully, both parties will have the same symmetric key, which they will use to exchange messages in
 P a g e | 14

a confidential manner. When a client wants to connect to her or his cloud provider, he or she first needs
to have digital certificates that are signed by a registered CA. Some cloud providers, such as the Amazon
EC2 service, offer to provide X509 certificates to their clients. If the clients have a digital certificate, they
should connect first using the SSL-to-SSL VPN gateway in the provider’s network. The network may have
one or more SSL VPN-gateway servers, either real machines or virtual machines e.g., by using OpenVPN
[FHOP08]. This SSL VPN-gateway server works as an access server and a router. It should be placed after
the firewall or in the same server with the firewall. The important points here are that this server should
be protected by a firewall and all unnecessary services and programs should be removed from the server
[FHOP08]. The SSL VPN gateway is responsible for authentication, authorisation, and routing. After
receiving an access request, the server will authenticate the client and forward the client’s traffic to its
host if the client has sufficient privileges to access the host, as illustrated in Figure 3.1. The connection
between the gateway and the host is an inter-cloud connection, and it is also protected by SSL. If the
communication channel between the gateway and a host is not encrypted and the SSL-encrypted data are
originally in plaintext, the data will be sent in clear to the host and can be intercepted by any client in the
cloud, which violates all aspects of security [FHOP08]. Therefore, it is essential to protect the channel
between the gateway and clients. The other inter-traffic-connection channel is between the gateway and
the gateway administrator’s workstation. The gateway administrator is responsible for specifying
authentication and authorisation policies, and the connection between the gateway and the administrator
is also protected by SSL [FHOP08].

Figure 3.1: SSL VPN access

Now that SSL VPN has been explained, we will discuss the security of SSL VPN as a communication
channel between a client and her or his cloud provider. It is assumed that the client’s workstation on
which the SSL VPN is being executed is secure.

Sniffing Threat

The SSL VPN connection is affected by almost all kinds of network threats. One such threat is sniffing,
which is a threat to confidentiality. Sniffing is a passive threat, but if the client’s credentials are sniffed,
the more serious threat of impersonation may be enabled [IBM08]. An attacker who sniffs an SSL
connection will not gain any information because SSL encrypts all traffic between parties. However, if a
 P a g e | 15

short key length or a weak encryption algorithm is used, an attacker might be able to break the
encryption scheme and read all messages that are exchanged.

Impersonation

Another threat is impersonation, which aims to bypass the authentication process as a legitimate client.
SSL VPN is designed to stop impersonation, but an attacker might be able to successfully impersonate a
legitimate user by exploiting vulnerabilities that may exist in the system. Most vulnerabilities are the
result of incorrect implementation of the SSL VPN connection, which may cause the SSL VPN to use weak
encryption primitives or short keys, as has been shown before. For instance, if a short encryption key is
used, i.e., 64 bits or less, attackers can find the key by launching a brute-force attack. The key lengths in an
SSL secure session vary ‘from 40 bits to 256 bits, depending on the browser and the operating system of
the user as well as the certificate installed on the server’ [Sec09]. Another example of using a weak
encryption primitive is using a single DES that is believed to be broken. To protect against spoofing
attacks, packet filters must be deployed in the provider’s network [DW03].

Weak passwords

Another popular vulnerability occurs when the client uses a password that is too simple, such as a
dictionary-driven password or a password with small space. If a dictionary-driven password is used,
attackers can launch a dictionary attack. In general, it is widely thought that, in sensitive environments,
such as cloud providers’ networks, it is no longer acceptable to use static passwords to authenticate
clients. Providers should avoid using static passwords and, as an alternative, they should use other
dynamic authentication means, such as tokens. It is also widely thought that providers should use at least
two factors authentication means [GC08]. In reality, cloud providers use two authentication factors,
which are digital certificates and passwords that are either static or dynamic. Therefore, it is not enough
for the attacker to find the password to be able to impersonate the client; the attacker must also have the
client’s private key as well, so having both provides an extra layer of security. Providers also are careful to
exercise the common techniques for protecting the security of passwords, such as saving only encrypted
passwords and locking the account after a specific number of log-in attempts. Unauthorised access is a
threat to all aspects of security which are confidentiality, integrity, and availability.

Stealing private keys and hijacking sessions

Another possible vulnerability is when the attacker manages to access the client’s or the provider’s
private keys, since this could facilitate a phishing attack. The attacker can impersonate the cloud provider
to the clients and thereby have the clients reveal their credentials. If an attacker can acquire the client’s
private key, the attacker can decrypt messages in the handshake protocol and obtain the session key,
enabling her or him to read all data in the session, modify information, or enter new data and commands.
This process of taking over an active session is called session hijacking, and it is a serious threat to
 P a g e | 16

confidentiality, integrity, and, in many cases, availability, since the attacker can take the client offline with
a denial-of-service (DoS) attack before hijacking the session.

DoS/DDoS Attacks

Another major threat to cloud computing is DoS and distributed-denial-of-service (DDoS) attacks, which
affect availability. DOS/DDOS attacks are always a persistent threat for any services connected to the
Internet, and cloud computing services are not an exception. Furthermore, SSL VPN is based on TCP
connection, which is inherently vulnerable to DoS/DDoS attacks, such as SYN Flood attack and Smurf
attack. However DoS/DDoS attacks will take longer to affect cloud-computing services than other services
on the Internet [BW08]. The distributed nature of cloud computing allows it to resist DoS/DDoS attacks
longer, but they can still occur. Cloud providers restrict their clients’ access to their excess capacity as a
countermeasure against DoS/DDoS attacks [BW08]. Normally, this limit is high enough to allow the client
to do her or his job without being aware of the limit. The purpose for the limit is to protect neighbour
clients in the same cloud from disruption because of service disconnection [BW08]. The other technique
to prevent DoS/DDoS attacks is by transferring targeted virtual machine to another data centre when
suspicious DoS/DDoS traffic detected in the inbound traffic. Originally, this technique is used as a
countermeasure for DoS/DDoS which target applications but it can be applied to targeted virtual
machines too [KJ09]. There should be anomaly-detection techniques to detect the abnormal traffic and
alerting the system.

Man-in-the-Middle Attack

Having discussed a number of general threats and vulnerabilities, we will now examine more specific
attacks against SSL VPN. One attack that frequently occurs is the SSL “Man-in-the-Middle” (MITM) attack,
which is a greater risk when faulty implementation of the SSL connection exists on the client side [PB02],
i.e., when the client’s browser accepts any CA-signed certificate or does not perform certificate validation
to the root CA [PB02]. When the client uses a public or unprotected workstation, an attacker could
preload a trusted root authority certificate in that machine and deceive the browser [PB02]. Normally,
current versions of web browsers will warn the client if the CA-signed certificate is not recognized, if the
certificate has expired, and/or if the name of the certificate does not match the DNS name of the server
[PB02]. Clients who are not experts may not understand the warning, and they may accept the faulty
certificate just by trusting the padlock, which gives a fault sense of security. In this situation, it is clear
that education programs to increase the clients’ awareness of these threats are very critical. As a
countermeasure against MITM attacks, cloud providers should prevent older versions of browsers and
some versions of operating systems from accessing the cloud. In general, if the SSL VPN connection is
implemented properly from a protected workstation with mutual authentication and patched browsers
and operating systems, there will be no chance for attackers to launch MITM attacks against clients who
use this approach.
 P a g e | 17

Downgrade Attack

Another attack is the downgrade attack of the SSL connection. In the downgrade attack, an attacker forces
both parties to use weak encryption primitives or even clear text by tampering with the negotiations
between them [RK03]. For instance, if both client and provider support both weak and strong encryption
algorithms, the attacker could surreptitiously force the use of the weak algorithm for communication by
intercepting the cipher suite, changing it to the weakest possible choice, and sending it to its destination
[BR05]. The SSL downgrade attack can be defeated by an integrity check over the entire range of the
handshake messages. It is also possible to stop this kind of attack by not supporting weak algorithms. All
versions of SSL support weak algorithms. Furthermore, SSL v2 does not provide any integrity checking
for handshake protocol messages. Therefore, downgrade attacks are possible with SSL v2 [BR05]. An
integrity check can defeat the downgrade attack only if the compromised key is the symmetric key. On the
other hand, if the compromised key is the private asymmetric key, the downgrade attack will work well
[BR05]. As has been shown, the integrity check is critical in the SSL connection to prevent downgrade
attacks. It is also used to prevent replay attacks. In general, it is highly recommended that SSL with
integrity check be used for all of the handshake messages, as is done by SSL v3. The integrity check is
critical for defeating the downgrade attack, and it also can defeat other attacks, such as the replay attack.

Cookies Threats

More vulnerability exists when cookie-based authentication is used. In cookie-based authentication,

cookies are used to store some session authentication data, such as session ID, to maintain the
continuation of the session and to assist the authentication process [IC08]. The cloud provider saves the
cookie on the client’s computer and retrieves it the time that client accesses the cloud until the session’s
lifetime has expired or when the client logs out [IC08]. The client’s browser should support using cookies.
Using cookie-based authentication makes the SSL connection vulnerable to session-hijacking attacks if a
wireless network is being used. When an attacker successfully copies this cookie, he or she could launch a
session-hijacking attack by simply visiting the cloud provider and impersonating the legitimate client.
Realizing the existence of this threat, Graham Roberts, at the Black Hat Conference USA 2007, introduced
his new sidejacking tool, which is able to read and copy cookies over insecure, wireless, public networks.
To prevent this attack, SSL-based authentication should be used to guarantee that authentication data are
encrypted when transmitted over wireless networks. This threat, along with any other wireless threats, is
critical for cloud computing security because it is a feature of the cloud that clients can access it from
anywhere using any available network, whether it is secure or not.

MD5 Digitally-Signed Certificates

The final vulnerability of communication security that is discussed in this research is digital certificates,
which are signed using the MD5 hash function. MD5 is a cryptographic hash function with 128-bit hash
value. In 2005, Marc Stevens, Arjen Lenstra, and Benne de Weger, from the University of Technology in
The Netherlands, revealed the results of their research, which showed that two different X.509
 P a g e | 18

certificates with the same owner name signed using MD5 could have the same signatures. In 2007, they
published a paper that expanded the same vulnerability to two certificates with different name fields
[SLW06]. Finally, at the Chaos Computer Conference in 2008, the researchers showed that they were able
to sign any certificate using the MD5 hash function and fool web browsers [MA09]. The danger of this
vulnerability for cloud computing is evident, since digital certificates are vital in cloud computing for
authentication purposes. Also, MD5-signed certificates are still in use, e.g., ‘RapidSSL, FreeSSL, TC
TrustCenterAG, RSA Data Security, Thawte, and Verisign all had issued certificates in 2008 that had been
signed with MD5’ [MA09]. As a result of this vulnerability, cloud providers should not trust any MD5-
signed certificates, which may restrict some clients from using the service. If this security check is not
performed, the cloud provider may grant an attacker access to its clients’ accounts, which violates the
three aspects of security.

3. ROUTING AND DNS SECURITY THREATS

The domain name system (DNS) is responsible for a function called name resolution. Name resolution is a
function of translating domain names to IP addresses. It also allows multiple servers to work under one
single domain name for servers that are in high demand [CR06]. When a client writes her or his cloud
provider’s domain name address in the web browser, i.e., the SSL VPN-gateway URL, the DNS server will
return the gateway IP address, which allows the client to reach the gateway and log in. Undoubtedly, this
function is critical from a security perspective. If the DNS server is malicious, it could return the address
of an “evil-twin cloud” [SK09b], which may fool the client and steal her or his data, affecting
confidentiality, integrity, and availability [SK09b].

The problem with DNS services is that it works by using a connectionless protocol, UDP, which makes
their messages easy to fake [IBM08]. Cloud providers deal with this security threat either by requiring
clients to use the IP addresses instead of domain names or by implementing DNS security, such as
DNSSEC. The latter choice is more common in cloud computing. DNSSEC uses digital signatures to
maintain the integrity of DNS-exchanged data and to protect clients against the evil-twin-cloud threat
[SK09b]. Clients’ machines as well as provider’s servers must be aware of DNSSEC so that they can use
DNSSEC services [SK09b].

The next threat with DNS is that it reveals the cloud provider’s structure, servers’ names, and IP
addresses, which are regarded as confidential data, and revealing these data is a great help for attackers
in finding their targets in the cloud network [IBM08]. The solution for this threat is to use a split-DNS
function [IBM08]. The idea of the split-DNS function is to configure two DNS servers such that one is
external for public domain names and can be accessed from the Internet, and the other is internal for
private domain names and can be accessed only from inside the network [IBM08].

In 2005, a security expert named Eric Johanson introduced a new DNS vulnerability [EJ05]. The threat can
be exploited when an attacker registers a domain name that is exactly the same as the one that he or she
tried to imitate using a set of characters, such as Cyrillic characters, rather than Latin characters, which
demonstrates a phishing attack [CW05]. Not all browsers are vulnerable to this threat; generally, those
 P a g e | 19

that are vulnerable to this threat are some of the browsers that support the International Domain Name
(IDN) [EJ05].

The next security issue is routing and the DoS threat. Because the cloud data takes an insecure route over
the Internet, an attacker can simply drop or reroute all the traffic from the client to the provider. These
types of attacks are called Reroute/data drop attacks or DoS attacks [SK09b]. This attack will interrupt the
cloud service, and the nasty part of the attack is that the client would not know why he or she could not
connect to the cloud. This attack affects availability, and it is difficult to discover and defeat.

4. CONCLUSION

As has been shown in this part of the research, the security of communication channels between clients,
their cloud provider, and other cloud providers is a major part of cloud overall security. Communication
channels are threatened by a large variety of threats, vulnerabilities, and sophisticated attacks, such as
phishing attacks, sniffing, impersonation, weak passwords, unauthorised access, the stealing of private
keys, session hijacking, DoS/DDoS attacks, Man-in-the-Middle attacks, downgrade attacks, cookie-based
authentication vulnerabilities, MD5-signed digital certificates, evil-twin cloud, and Eric Johanson
vulnerability. Furthermore, a lot of security techniques are already in use to deal with these threats and
vulnerabilities, such as mutual authentication, two factors authentication, DNSSEC, and awareness and
education. In addition, proper implementation of security techniques, such as SSL VPN, can eliminate
most of these threats and vulnerabilities. In the author’s opinion, the worst scenario for communication
security is unauthorised access, i.e., when an attacker gains access to a client’s account. In this case, the
attacker can copy and change that client’s data and may attack other virtual machines in the same server
or in the same cloud, as will be shown in chapter 5. The situation will be worst if the client’s workstation
is infected. As has been said before, the assumption here is that the client’s workstation is clean and
secure, but this is not always the case. The combination of a Trojan Horse or malware with an external
attack has a very strong effect on security, and this will be discussed in more detail in the next chapter.
 P a g e | 20

Chapter 4: Client Side Security

1. INTRODUCTION

Cloud computing clients could work from anywhere using any machine, which makes their security hard
to maintain by providers. Since clients’ machines are live outside providers’ perimeters, providers have
little control over them. The second factor which contributes to making maintaining security more
difficult is the machines owners in the client side; clients are able to work from their own machines, their
organizations’ machines or maybe from a sharing machine in a cyber café.

Cloud clients’ security can be compared to teleworker or telecommuter security; both are outside the
organization’s perimeters and their security is difficult to maintain. They suffer different kinds of threats
and vulnerabilities. Physical security, malicious code and web browser security are the top three sources
of threats for clients’ security, each of which is discussed in this chapter.

Physical security is the first source of threat due to the uncontrolled clients’ working environment. The
second source is malicious code. For instance, if a client’s machine is infected with malware, the infection
could then transfer to the cloud and may subsequently infect other clients in the same cloud, which
threatens the whole cloud’s security. The third source is web browsers, due to the importance of being
the main tool used to access the cloud.

Clients are responsible for providing adequate security within their machines, and this could be included
in their contracts in relation to more obligations. However, cloud providers should not rely on this and
should do their homework by maintaining clients’ security with the few tools that they have in this area.
As such, they can just use a communication channel, such as SSL VPN, in order to ensure some security
guarantees on clients’ machines, do some education to increase clients’ awareness and use legal pressure.
Furthermore, they should regularly audit clients and perform outside scanning.

2. PHYSICAL SECURITY

The first threat for client security is physical theft. If a client’s machine is stolen or lost and consequently
falls into malicious hands, client data and credentials can be misused which may compromise
confidentiality, integrity and availability. As has been previously noted, the cloud provider does not have
any control in this area.

Clients are able to work from their own laptops or from sharing computers. Providers can improve this
area by ensuring both education and awareness. They can also control the source of access and allow
access only from enterprise-owned machines.

Furthermore, there are number of technical-supported solutions. For instance, protecting clients’
machines could be achieved via two factors authentication, such as smart cards (something you have),
and passwords (something you know). Biometrics authentication could also be considered here too.
 P a g e | 21

Furthermore, sensitive data should be encrypted, and keys should be stored in a secure place. Other
essential security techniques comprise changing passwords regularly; even if the cloud provider has
password policy which is highly expected, this policy does not govern clients’ access to their machines
and, therefore, once again, this could be achieved by education and awareness and legal obligation. There
is another helpful technique for PDAs and cell phones, which is remotely erasing the contents of these
devices when they are stolen [SS07]. This is a service provided by some telecommunication companies.

The last threat regarding physical security is physical eavesdropping by people who are around clients in
coffee shops, family members at home, or colleagues at work. This threat occurs because clouds’ clients
can work from anywhere and could therefore leave their machines unattended without signing out. One
of the solutions for this problem is by highly recommending users lock their user accounts when leaving
their systems unattended, and using a password-protective screensaver.

3. WEB BROWSERS’ SECURITY

The next security issue to be considered is the security of web browsers. Web browsers are the main tool
used by clients to access the cloud, and are therefore considered to be one of the major sources of threats
and vulnerabilities to client’s security and, as a result, cloud security. Web browsers enable a number of
active contents in clients’ machines, such as ActiveX, plugins, JavaScript, Java Applets, and Cookies, each of
which may represent a source of threat to the overall security. Furthermore, a number of Trojans and
viruses infect web browsers, steal clients’ data, and then send such data to the attacker. Another issue
regarding web browsers is blocking pop-up windows and web content filtering, which may download and
install malwares and other types of infections.

3.1 OpenSSL Vulnerability in Debian and Ubuntu

In 2006, the Linux-based operating system Debian updates its version of OpenSSL to fix an uninitialized
memory error [SG09b]. The update was done by removing the offending code that generates this error
[SG09b]. Other Linux-based operating system Ubuntu adopts the same version of OpenSSL [SG09b]. In
late 2008, a seriously damage vulnerability was found in this special version of OpenSSL [CIS08].
Researchers discover that this offending code is used by Pseudo Random Number Generator (PRNG) to
generate keys [SG09b]. The result of removing this code is making OpenSSL generates small variety of
keys; each generated key is one of 32,767 keys for specific length and type [SG09b]. This vulnerability
makes finding keys by attackers in vulnerable systems is a trivial task. They can brute force it by trying
the 32,767 possible keys. This is a serious concern for Linux users and servers in the cloud. It may enable
other threats such as unauthorised access.

4. MALICIOUS CODE

The biggest threats to clients’ workstations are malicious code or malware [CW05]. Attackers can fully
control a client’s workstation if he or she successfully installs and executes a malicious code on it. This
malicious code has the ability to send sensitive client data and activities, open closed ports, disable the
 P a g e | 22

antivirus software and/or download more malicious codes. Therefore, malwares threaten the three
dimensions of security.

According to NIST, the formal definition of malware is as follows: Malware ‘refers to a programme that is
inserted into a system, usually covertly, with the intent of compromising the confidentiality, integrity, or
availability of the victim’s data, applications, or operating system (OS) or of otherwise annoying or
disrupting the victim’ [MKN05]. There are four categories for malware, which are viruses, worms, Trojan
Horses, and malicious mobile code [MKN05].

4.1 VIRUSES

The most significant feature for viruses is their ability to copy themselves and infect files, programmes
and operating systems, which is how they spread [MKN05]. They need human intervention to be
installed. If a client machine is infected with a virus, its virtual machine or its storage area in the cloud
may consequently become infected too. The virus will transfer to the cloud and may ultimately infect the
whole cloud and all other clients. Most viruses have the ability to encrypt themselves in addition to
another layer of encryption by SSL, which makes them more difficult to detect.

As illustrated, viruses are major threats to the cloud and, as a countermeasure to this threat, installing
updated antivirus software on client- and provider-side is critical. In a storage cloud, providers have full
control on their storage servers, and they can therefore simply install and regularly update antivirus
software in their storage servers, whereas in the computer cloud, providers can install antivirus in host
operating systems on their physical server but don’t have any control on clients’ virtual machines which
are hosted in their servers.

In client-side machines, providers have limited control on clients’ machines. Clients and their enterprises
are responsible for installing antivirus and keeping these updated. Clouds’ providers can ensure that
clients’ machines have up-to-date antivirus by requiring this in the security policy and enforcing this
using SSL.

SSL VPN has the capability to run endpoint checks on the clients’ machines so as to ensure that clients are
compliant with the provider’s security policy. SSL can check that a client has updated antivirus, a patched
operating system, performed some integrity checks and check if specific applications are installed or not
[LM08, FHOP08]. SSL VPN performs these checks before establishing a secure session with the client
[FHOP08]. If a client’s machine does not satisfy the security policy, he or she will subsequently not be
allowed to establish an SSL connection, and will be unable to access the cloud.

4.2 WORMS

Much the same as viruses, worms are able to make copies of themselves. However, the difference between
worms and viruses is that worms can spread and execute themselves without user intervention, while
viruses require human intervention to start execution [MKN05]. Primarily, worms designed to consume
 P a g e | 23

system resources, such as processor power and memory. In the author’s opinion, the problem of
consuming computing power, memory and bandwidth is critical in cloud computing, owing to the pricing
model in cloud computing, which is ‘pay per use’ model. If a client’s virtual machine is infected by a worm,
this may unexpectedly cost the client a huge amount of money.

4.3 TROJAN HORSES

Trojan horses ‘are non-replicating programmes that appear to be benign but actually have a hidden
malicious purpose’ [MKN05]. Trojan horses replace genuine applications or files with malicious ones.
Online banking environments, which are similar to cloud computing environments, to some extent always
suffer from Trojan Horses. For instance, Trojan.Blinder creates a new small white box to cover the
spoofed URL with the genuine one which may fool clients and make them reveal their credentials to the
Trojan Horse which, in turn, sends the data to the attacker. This Trojan uses JavaScript to perform the
malicious task [CW05].

Another Trojan horse is PWSteal.Bankash, which replaces genuine DLL files with a malicious one, which
allows the Trojan to read all data in the web browser prior to encryption. This Trojan can steal clients’
data and credentials, and may allow the attacker to gain unauthorised access to clients’ virtual machines
in the cloud [CW05]. Furthermore, some Trojan Horses inject themselves into browsers’ memory spaces,
which provides access to browser data [CW05].

As has been shown, these Trojan Horses can steal clients’ data, even if there is an SSL encryption in place,
because SSL encryption is covers data in transition while Trojan horse steal data before transition. It can
also bypass virtual keyboards by installing key loggers in the infected machine and again stealing client
data [CW05].

4.4 COUNTERMEASURES

As has been illustrated, malwares represent serious danger to client security and, as a result, cloud
security. The first thing to defeat this threat is by having organization policies and procedures for dealing
with malwares [MKN05].

There is a large number of security countermeasures which can be employed in order to control this
danger, such as antivirus software, host-based intrusion detection system, personal firewalls, regular
scanning from outside, the scanning of files before opening, blocking certain type of files, forbidding
certain applications, removing unwanted services, patch operating system and applications, using least
privilege rules by not running on administrator privilege if possible, forbidding removable media, and
regularly clearing web browser caches and cookies (list collected from NIST Guide to Malware Incident
Prevention and Handling) [MKN05]. Another way of defeating this threat is client education and
awareness for. It is also essential to keep an open communication channel with clients, such as via email,
in order to keep them updated about the latest malwares threats. Furthermore, the cloud provider should
provide 24-hour helpdesk services and support in order to answer clients’ concerns, to help them deal
 P a g e | 24

with malwares, and to report any suspicious behaviours in clients’ machines so as to be ready on the
provider side.

5. CONCLUSION

Client security is the second core factor to cloud overall security. Maintaining clients’ security is not an
optional task for cloud providers but is crucial to ensuring safer and more trusted clouds.

Client security has a variety of threats and vulnerabilities, as this chapter illustrates. Physical thefts are
one essential threat, which is relatively hard to eliminate. Furthermore, vulnerabilities exist because of
the continued use of old versions of web browsers. In addition, there is the major threat to clients’
security, which is malware. For instance, this particular danger threatens cloud security in the form of
worms and consuming computing power, bandwidth and money. Moreover, additional threats exist, such
as social engineering clients and allowing remote access to clients’ machines, although these are out of the
scope of this research.
 P a g e | 25

Chapter 5: Provider Side Security

1. INTRODUCTION

Infrastructure as a service provider offers processing power, storage and/or networking capabilities to its
clients [CSA09]. Organizations — or even individuals — can rent these services and ultimately construct
their virtual servers or machines on them, such as mail servers or web servers. Security responsibilities in
the cloud are shared between clients and the provider. On the one hand, clients are completely in control
of their virtual machine’s security as they have complete management, and even cloud’s administrators
cannot access these virtual machines. These virtual machines can be maintained by ensuring there is
properly managed access control, constant up-to-date antivirus software, patched operating systems, and
secure applications, in addition to some firewall configuration and management. On the other hand,
providers are responsible for the security of the underlying infrastructure, which requires controlling
physical security for their data centres, such as in terms of access to buildings, perimeter security for their
networks, such as Firewalls and IDS, in addition to controlling security of their servers, such as host
operating system security and virtualisation platform security. What is more, providers are responsible
for providing clients with the assurance that the resources which they rely on are secure, and that clients
are also protected from each other.

The difficult formula to solve here is that a high percentage of security control is in the clients’ hands,
while security assurance is the provider’s responsibility; this subsequently greater emphasis on security
measurements and metrics. Furthermore, noticeably less control in the provider’s hands does not mean
less work to do but, in contrast, can actually mean harder work in terms of providing assurance. For
instance, patching management is one of the critical areas of security, and it is the client’s responsibility;
the provider has no control on the patching of clients’ virtual machines but they are still required to
assure that clients do their homework properly.

As has been said above, it is widely thought that IaaS security is in the clients’ hands, and providers have
less security capabilities and control. This idea is illustrated in Cloud Security Alliance paper of April,
2009, which states that ‘IaaS provides few, if any, application-like features, provides for enormous
extensibility but generally less security capabilities and functionality beyond protecting the infrastructure
itself since it expects operating systems, applications and content to be managed and secured by the
consumer’ [CSA09]. In the author’s opinion, it is more accurate to say that IaaS providers have more
difficult security tasks to overcome than to say ‘less security capabilities and functionality’ [CSA09].
Furthermore, it is dangerous and unrealistic to rely on the expectation and assumption that clients will
manage and secure their own operating systems and applications. In information security, the worst
scenario is always assumed. With this in mind, it would be safer to state that managing and securing
virtual machines are clients’ responsibilities, whereas it is assumed that they don’t fulfil their
responsibilities, and so then plan and act under this assumption.
 P a g e | 26

Information security challenges facing IaaS providers are discussed in this chapter. A variety of threats
and vulnerabilities exist in different components of the provider’s network. The first and foremost
technology which is considered fundamental to IaaS provider’s network is virtualisation. The security of
virtualisation in the cloud is the topic for the following section.

2. VIRTUALISATION SECURITY IN THE CLOUD

2.1. VIRTUALISATION OVERVIEW

The core concept of virtualisation is separating operating systems and their underlying physical
infrastructure by a virtualisation layer [DISA08]. There are different types of virtualisation technologies
used in cloud computing: The first common type in cloud computing is para-virtualisation platform, such
as Xen, which is widely used and is the main virtualisation platform in Amazon EC2 and IBM cloud
computing. In para-virtualisation, virtualisation software — or VMM — is a thin layer between underlying
physical server and its guests’ operating systems. Guests’ operating system kernels should be modified ‘to
replace nonvirtualizable instructions with hypercalls that communicate directly with the virtualization
layer hypervisor’ [VMW09b]. This platform has relatively high performance; however, there is the need
for modifying guests’ operating systems, which creates some obstacles. It prevents modified virtual
machines from returning back to run on standalone servers [VMW09a] or other types of virtualisation
platforms. In regards to normal servers without virtualisation, the OS runs in system mode, which is the
highest privileged level; however, in a para-virtualised environment, VMM works in system mode and
guests’ operating systems in user mode [VMW09b].

Moving the OS from system to user mode prevent guests’ operating systems from directly accessing
hardware. All requests should go through the virtual machine manager (VMM), which is responsible for
translating requests and for managing resources, which may ultimately help to protect resources from
not being tampered with by guests. The structure of the para-virtualised platform is shown in Figure 5.1.

Figure 5.1: Para-virtualisation

The second type of virtualisation platform in cloud computing is bare metal hypervisor, or is otherwise
referred to by the Defence Information Systems Agency in the US (DISA) as Type I VMM [DISA08]. In this
approach of virtualisation, the hypervisor is installed directly on the physical hardware and works as ‘an
operating system or kernel that has mechanisms to support virtual machines. It must perform scheduling
 P a g e | 27

and resource allocation for all virtual machines in the system and requires drivers and hardware
peripherals’ [DISA08]. In the case of bare metal hypervisor, there is no need to modify guests’ operating
systems, and each virtual machine has a dedicated VMM.

VMMs are responsible for providing full virtual hardware services to virtual machines, such as virtual
BIOS, virtual memory, and virtual CPU [VMW09b]. Guests’ operating systems work in user mode — ring 1
— but they believe that they work in system mode — ring 0 — and that all system calls made will be
trapped and emulated by the VMM and subsequently translated on the fly by the hypervisor to the
specific hardware resources [VMW09b]. Microsoft’s virtual server — Hyper-V, which is used by Microsoft
cloud — and VMware products are examples of bare metal virtualisation platforms. The structure of bare
metal virtualisation is shown in Figure 5.2.

Figure 5.2: Bare metal regular

There is another form of bare metal hypervisor, which is hardware-assisted. In this form, the hypervisor
works in ring -1, minus one, and uses CPU-specific instructions in order to place the system into a virtual
mode [PF06]. There is no need to modify guests’ operating systems due to the fact that they run in their
normal privileges level which is ring 0 [PF06]. The hypervisor here controls the data structures and
registers and provides shadow copies for the guest. In this way, the guest is able to continue normal
execution whilst the hypervisor protects the important data structures and registers [PF06].

The third popular approach of virtualisation in cloud computing is hosted hypervisor or Type II VMM. In
hosted hypervisor, the hypervisor runs as an application on top of a host operating system [DISA08]. In
this type of virtualisation, hardware management — such as resource allocation and processor
scheduling — is the responsibility of the host operating system [DISA08]. The structure of hosted
virtualisation, as shown in Figure 5.3, has the least performance amongst others.
 P a g e | 28

Figure 5.3: Hosted hypervisor

In virtual environments, the same operating systems and applications are used as in regular physical
environments; therefore, the same vulnerabilities and threats exist. However, in virtual environments,
there are extra layers and thus extra complexity, which ultimately means more sources of threats and
vulnerabilities.

2.2. VIRTUAL ENVIRONMENT THREATS AND VULNERABILITIES

Virtual environments suffer from a variety of threats and vulnerabilities. The first source of threats in the
typical virtual environment is the virtualisation software itself.

2.2.1 VMM OR HYPERVISOR SECURITY:

If the attacker gets control of the hypervisor, he or she then has a high chance of controlling the whole
machine. Attacks against the hypervisor are known as Hyperjacking Attacks [LS06]. Hyperjacking attacks
try to control the hypervisor from using different strategies. The first widely known strategy is against
virtualisation-assisted hardware, which is used for hardware-assisted hypervisor. The attack is enabled if
a machine supporting virtualisation does not have a hypervisor installed. In this case, the attacker is able
to install a malicious hypervisor, which can change the status of the main operating system to be a guest
operating system and to ultimately gain control of the machine [PF06]. Although there is a hypervisor
installed in cloud computing servers, the same attack can nevertheless be carried out if the installed
hypervisor is a hosted hypervisor in a virtualisation-assisted machine. In this case, the host-based
hypervisor works as an application in the host operating system. In this instance, the malicious
hypervisor can move this host operating system and its applications, and make it a guest operating
system. Figure 5.4 illustrates the situation before and after the attack.
 P a g e | 29

Figure 5.4a: Before the attack

Figure 5.4b: After the attack

This is a theoretical attack and this requires additional practical experiments to prove the results.
Nevertheless, it is nasty because, as Symantec Advanced Threat Research states, ’neither the operating
system, nor the user, will be aware of it. Furthermore, the hypervisor is actually more privileged than the
operating system itself, since it sees the interesting events first and can hide them even from the host
operating system. Moreover, once a hypervisor is active, no other hypervisor installed later can gain full
control of the system. The first hypervisor is in ultimate control’ [PF06]. The malicious hypervisor can be
installed either by accessing the physical server, convincing users to install a malicious code, or via the
use of malwares which spread the code.

The second hypervisor attack strategy directly controls the hypervisor by exploiting some vulnerability in
the hypervisor itself or in the configurations, such as in the Xbox 360 Hypervisor Privilege Escalation
Vulnerability [SeF07]. The overview of this vulnerability, as in Security Focus website, they said ‘We have
discovered vulnerability in the Xbox 360 hypervisor that allows privilege escalation into hypervisor
mode. Together with a method to inject data into non-privileged memory areas, this vulnerability allows
 P a g e | 30

an attacker with physical access to an Xbox 360 to run arbitrary code such as alternative operating
systems with full privileges and full hardware access’ [SeF07]. Another example is Xen
hypervisor_callback Guest Local Denial Of Service Vulnerability [SeF09]. The details for this vulnerability,
as in Security Focus, are ‘Xen is prone to a denial-of-service vulnerability because the application fails to
properly do checks in 'hypervisor_callback'. An attacker in the guest system can exploit this issue in order
cause the guest kernel to oops, effectively denying service to legitimate users’ [SeF09].

There are hypervisor vulnerabilities announced each day, and clouds’ administrators should follow-up
and keep hypervisors both updated and patched.

2.2.2 DETECTING VIRTUAL ENVIRONMENT:

The starting point for attackers to accomplish their tasks of attacking servers is determining whether they
are in virtual environment or not; if yes, this will subsequently trigger other more serious attacks, such as
escaping from the VM attack. This is an essential step and is not as simple a task as it seems owing to the
hypervisor, which is between the hardware and the guest’s operating system, with all instructions going
through the hypervisor, including CPUID instruction, therefore, the hypervisor has the control for what
the guest operating system sees and can subsequently hide its existence. However, as shown in the
Symantec Advanced Threat Research [PF06], there is a large number of revealed evidence of the
hypervisor existence, which means that hypervisor developers do not take the idea of concealing the
hypervisor seriously, whilst from the author’s point of view, this could make attackers lives more difficult.

In the wild today, there are a number of tools used in order to discover the existence of hypervisors.
There were two reasons for developing tools in order to discover virtual environments, such as Scooby
doo, redpill and LDT [AM06]: The first reason is because attackers want to avoid honeypots or honeynets,
which are developed in virtual environments; the second reason is because most antivirus testing
experiments are carried out on virtual machines, and virus developers therefore try to develop viruses,
which change their behaviour in virtual machines to fool antivirus companies [LS06]. Nowadays, one
more reason is added, which is due to the spread of server virtualisation and cloud computing.

One of the tricks used in order to detect the virtualisation environment is by filling Translation Lookaside
Buffers (TLBs) with previously known data. TLB is a cache which helps to carry out a fast virtual address
mapping process by caching recently used addresses. The attacker here fills TLB with known data, and
then executes any hypervisor instruction. The chosen instruction should not affect the memory and does
not change the TBL, such as CPUID instruction. The attacker then tries to gain access to the same pages
again, and subsequently counts the time needed to access; if it is the same as the time needed to access
new pages, that means the TBL is flushed and there is a hypervisor in that machine [PF06].

There is more ways of catching the hypervisor, such as checking the hardware device names as some
hypervisors use constant names [PF06]. Another way is by checking the local time source, as the time is
usually not accurate if the machine is multitenant machine [PF06].
 P a g e | 31

The last few ways of discovering the existence of the hypervisor are just a few examples; there are many
more ways and tools for achieving this task depending on the brand of the hypervisor. However, hiding
the existence of the hypervisor recently gets more attention, and the task may subsequently become more
difficult in the future.

2.2.3 VIRTUAL MACHINES ROOTKITS:

There are a number of rootkits targeting virtual environments in the wild, such as SubVirt, Vitriol and
BluePill. Most of those rootkits have the same ideology. One example will be illustrated in this paper,
which is SubVirt.

SubVirt was developed by Samuel King, Peter Chen, Yi-Min Wang, Chad Verbowski, Helen Wang and Jacob
Lorch from University of Michigan in addition to Microsoft Research in their paper ‘SubVirt:
Implementing Malware with Virtual Machines’, which was published in 2006 in IEEE Symposium on
Security and Privacy [KCW+06a]. The SubVirt scenario is similar to another scenario as discussed above
under hypervisor attacks. The idea behind SubVirt is installing a second operating system which becomes
the host operating system with a hypervisor, and converting the previous operating system to virtual
status. The second operating system can be installed using several different methods, such as remote
exploit, infected USB, or by convincing one of the users to install the tool either deliberately or
accidentally. The targeted machine has a virtualisation-assisted CPU. The tool updates the boot sequence
and makes the machine load the new malicious hypervisor before the original operating system, as shown
in Figure 5.5 (taken from the SubVirt developers’ presentation) [KCW+06b].

Figure 5.5a: Before installing the SubVirt

Figure 5.5b: After installing SubVirt

SubVirt uses a VirtualPC hypervisor for Windows machines and VMware hypervisor for Linux machines
[PF06]. In general, these kinds of rootkits are popular in virtual environments because rootkit tools need
to work in the system mode in order to avoid detection. Most hypervisors run in system mode.
 P a g e | 32

2.2.4 MULTITENANT SECURITY:

Multitenancy — which is the ability to host multiple virtual machines in the same physical box — is one of
the major sources of threats in cloud computing environments. Cloud computing servers are able to host
a number of virtual machines, which are unrelated to each other, and which belong to different
enterprises, providing different services. Ideally, in regular enterprise networks, the network will be
segmented depending on the required trust level. Furthermore, there are perimeter security controls and
gateways which shield the network and control the inbound and outbound traffic.

In regards to cloud computing, all of these roles are broken by multitenancy principals when different
machines with different owners and different trust levels are sharing the same physical machine. It is
hard to control inbound, outbound and inter-virtual machine traffic. Furthermore, the perimeter security
controls evaporate because, for instance, virtual machine X, which belongs to enterprise X, can
communicate with virtual machine Y which belongs to enterprise Y, all without leaving the physical
server and without passing the perimeter security controls. The realistic assumption here is that X does
not trust Y and vice versa.

From a security perspective, the threat of virtual machines in the same host attacking each other could
destroy the whole cloud computing idea. In order to deal with this major obstacle in cloud computing
security, providers move all regular security controls — either perimeter security control or between
LANs security controls — to the virtual world [CSA09]. They apply the same security principals and tools
in the regular network but in a virtual version, such as virtual firewalls, virtual IDS/IPS, log inspection,
integrity monitoring and web application protection [CSA09]. Therefore, virtual machines of the same
host should be segmented and protected from each other. In this instance, virtual switches can also be
used. There are two question here which need to be answered. The first question is, ‘are those virtual
security controls as effective as old style controls?’ A document entitled Security Guidance For Critical
Areas of Focus in Cloud Computing, as prepared by the Cloud Security Alliance in April, 2009, said that,
‘virtual appliance gateway versions of these network controls can provide some monitoring functions, but
cannot effectively block traffic that runs between VMs on the same physical box’ [CSA09]. However, the
author believes that this is an inaccurate generic judgment, and that the area of virtual controls requires
more research and should be expected to develop more in the future. The second question is, ‘what is the
security goal for these controls?’ If the same concept is used as in wireless networks or in mobile
networks for specifying virtual controls security goal, the security goal will be able to provide security
level the same as a physical control security level. However, as it has been said before, this is a relatively
new area and requires further research.

What is more, when virtual machines are connected to each other using virtual switches or virtual hops,
the same threats and vulnerabilities as in LAN networks appear. For instance, if a virtual machine is
running in promiscuous mode and is connected to other virtual machine using virtual hop or virtual
switch which does not fail safe, then that virtual machine will be able to have copies of all packets in that
particular physical server, which may ultimately lead to other attacks and could consequently affect the
 P a g e | 33

security of neighbouring virtual machines. This is just an example in terms of LAN threats, although there
are so many threats and vulnerabilities in LAN networks and so many researches available in this area.

The concept of protecting virtual machines from each other and simultaneously protecting the host from
guests’ virtual machines is called ‘isolation’, and is a virtualisation software task in addition to
maintaining communication between virtual machines themselves and between virtual machines and the
host. It is essential to ensure malicious or compromised virtual machine do not affect other virtual
machines or the host.

2.2.5 VIRTUAL MACHINE ESCAPING:

According to Martin Wimmer from Siemens AG, virtual machine escaping is ‘considered to be the most
challenging and threatening type of attack’ [MW08]. Wimmer also states, ‘VM escape represents a critical
attack scenario offering attackers extensive control possibilities’ [MW08]. The same attack is discussed in
details in Alan Murphy’s paper ‘Security implications of the virtualised Data Centre’ [AM06]. Murphy
defines virtual machine escaping as ‘jumping out of the confines of the virtual environment and into the
physical environment’ [AM06].

The idea of escaping virtual machines is finding a way to make the hypervisor run guests’ arbitrary code
on the hypervisor privilege [MW08]. As previously discussed, hypervisors usually run in system mode
while guests’ operating systems always run in user mode and never in system mode. In reality, operating
systems need to work in system mode in order to be able to interact with hardware. And, as it has been
said before, the virtualisation software in virtualised environment is responsible for translating and
communicating virtual machines privilege commands, such as interrupting requests. For instance, each
virtual machine should have an interrupt table in the memory. The normal location for the interrupt table
in memory, same as in standalone machine, will be reserved for the host interrupt table [AM06]. On the
other hand, the guest will save its interrupt table in the normal location of its virtual memory space while,
in reality, the hypervisor has mapped this location to another location in the physical memory. When
guests’ operating system call its interrupt table, the hypervisor will then transparently translate this call
to the real location [AM06]. If a malicious virtual machine tries to attack the CPU, it would then just crash
itself and would not affect the host or other virtual machines [AM06]. However, if that malicious virtual
machine ‘can find a way to exploit virtual microcode, then they may be able to manipulate the host kernel
and CPU’ [AM06]. Normally, this would be possible only if there was a weakness in the hypervisor; for
instance, in December, 2005, vulnerability was found in VMware VMnat which allowed virtual machine
escaping [PF06]. When VMnat deals with specially crafted EPRT files and PORT FTP command, it
performs unchecked copy operation which results in heap buffer overflow, which may consequently run
arbitrary code [MW08, AM06]. All buffer overflow vulnerabilities could cause virtual machine escaping.
For instance, if there is a buffer overflow vulnerability in one of the host’s network drivers, guests’
applications could then be in a position to exploit this vulnerability by sending specially crafted network
packets to the vulnerable device driver, which could cause an arbitrary code to be executed [PF06].
 P a g e | 34

2.2.6 DENIAL OF SERVICE ATTACK IN VIRTUAL ENVIRONMENT

Due to the fact that the physical server’s resources are shared between virtual machines, there is
consequently the danger of a bad behaviour virtual machine consuming all of the resources and
preventing other virtual machines from using them. This is a Denial of Service attack, and is considered as
a serious threat in shared environments.

A malicious virtual machine could ‘saturate the virtual network and drive down performance of the entire
physical server’ [SBD08]; it could also consume other resources, such as CPU time and memory. Another
approach of conducting denial of service attack is by exploiting virtualisation software vulnerabilities, if
they exist. For example, Peter Ferrie, a researcher in Symantec Advanced Threat Research, found
vulnerability to be apparent on Parallels Platform, which causes Denial of Service. He successfully
generated a fatal error by executing Store Interrupt Descriptor Table SIDT instruction with the trap flag
set, which caused abnormal termination to the platform and thus DoS [PF06]. In addition to Parallels,
VMware suffer from several Denial of Service vulnerabilities due to flaws in VMware implementation
[MW08]. Although there are patches for most of discovered vulnerabilities, the problem occur with
unpatched machines and/or undiscovered vulnerabilities. Another simpler technique for performing
Denial of Service attack is when an attacker who has access to the virtual machine isolates it from its
network by disconnecting the network adapter [DISA08].

There are number of solutions to DoS threats in virtual environments. First, virtualisation software
should be kept patched in order to prevent attackers from exploiting known vulnerabilities; second,
virtualisation software should limit the resources allocated to each guests [Mic08]; furthermore, a
bandwidth monitoring programme could be installed in each virtual machine connection so as to prevent
saturating bandwidth [SBD08]. In addition, there are also other techniques help to prevent DoS attacks,
such as load balancer, ACLs to segment VLANs and redundancy DNS server. DoS attack is a popular topic
of research and there is a huge amount of research available.

2.2.7 THREATS DUE TO DYNAMIC NATURE OF VIRTUAL MACHINES

One of the main features of virtual machines is encapsulation. The current status of a virtual machine can
be saved as a single image, which makes it easy to copy and move from one server to another [VMW09c].
This capability of virtual machines is what is known as the dynamic nature of virtual machines. Virtual
machines are moved from server to server for several reasons, such as load balancing and tuning [JS08];
this makes virtual machines portable, easy to manage and subsequently increases availability [VMW09c].
However, at the same time, it makes maintaining consistent security more difficult, and defining security
policies difficult [CSA09, JS08].

Cloud Security Alliance compared this virtual machine feature to laptops in the enterprise [CSA09]. One of
the most obvious problems with virtual machine migration is the spreading of viruses and malwares,
when infected virtual machine moves from one server to another [VSM09]. If a cloud provider maintains
 P a g e | 35

centralised consistent security policy and distributes this policy amongst all virtual security controls on
all servers, this may ultimately reduce the risk because of dynamic nature of virtual machines due to the
consistence virtual environment in servers. The only remaining problem in addition to the spreading of
viruses is the virtual machine’s integrity [JS08].

When virtual machines move from server to server — sometimes in another geographical area — virtual
machines could be changed, either deliberately or accidentally. Therefore, virtual machines should apply
data integrity and data origin authentication services; this could be done using several different methods,
such as digitally signing virtual machines’ files. The other aspect of security which should be maintained
while transferring virtual machines is confidentiality. In view of the fact that when a virtual machine
encapsulates in a file for transition purposes, this file contains all of this virtual machine’s data and status;
usually, this data is confidential, and should not fall into the wrong hands. Therefore, virtual machine files
should be encrypted during transmission.

The mobility ability of virtual machines changes the old fashion of static traditional physical servers,
which ‘don’t tend to change very often’ [JS08]. This increases complexity and requires improving old
security techniques.

2.2.8 VIRTUAL MACHINES’ SECURITY:

As previously discussed, clients are responsible for their own machine’s security. Virtual machines face
the same threats and vulnerabilities as standalone machines in addition to additional threats as a result of
virtualisation and multitenancy. For instance, if a virtual machine is a virtual mail server, clients should
maintain security for this server, such as via operating system security, applications security, disabling
unwanted services, installing antivirus software and keeping it updated, applying host-based firewalls
and IDS. They should follow the best practice for this type of server, which is, in this example, mail server
standards.

One of the most effective security practices in relation to virtual machine security is initiating secure
virtual machine imaging right from the beginning. Nevertheless, in relation to cloud computing, where do
images come from and who is responsible for their security?

In cloud computing, each client creates its own virtual machine using an image. This image could be
uploaded by the client or by other clients, and subsequently made available to other clients or by the
cloud provider. If the client creates its image, he or she may use a vulnerable image. For instance, he or
she could decide to build a virtual machine without any antivirus software installed on it; a bad security
practice like this could affect client virtual machine security and may ultimately affect the entire cloud
security.

Cloud providers should assure the minimum accepted level of security in their clients’ images, which
could be done by applying secure by default rule: ‘Secure by default configuration needs to be assured by
following or exceeding available industry baselines’ [CSA09].
 P a g e | 36

The second source of images is other clients. This feature — allowing the sharing of images — is applied
in Amazon EC2. The problem here is that a malicious client could upload an unsecure or even an infected
image, and makes it available to other clients. Therefore, cloud providers should perform full checks
before making those images available in order to stop malicious clients from spreading their infected
images. This, however, is not the case in Amazon EC2, which allows the sharing of images, and Amazon
EC2 does not conduct effective checking before allowing the sharing of images [ND08]. However, the
author has not found these observations concerning Amazon EC2 in Amazon EC2 service security paper
(Web Services: Overview of Security Processes), but Nitesh Dhanjani, a security researcher and co-author
of ‘Hacking: The Next Generation (Animal Guide)’, carried out some tests on Amazon EC2 servers, and
published his observations in his article ‘Amazon's Elastic Compute Cloud [EC2]: Initial Thoughts on
Security Implications’, which was published in April, 2008 [ND08]. The author is not aware whether this
problem still exists in Amazon EC2 or whether it has since been fixed.

The last source of images is the cloud provider. These images are expected to be secure, patched and
tested. However, the problem with this approach is when a security weakness discovered in one of the
template images. In this instance, this vulnerable image could then be deployed by a large number of
clients, which would make it difficult to notify clients to update their virtual machines. As has been said
before, maintaining virtual machine security is the clients’ responsibility, and providers’ administrators
don’t have access to those virtual machines. However, providers should find a way of tending to this
problem as there is a very high possibility of discovering vulnerabilities in images over time. This topic
will be covered in more detail in the section on Patching Management and Unsecure Application.

There is still the risk that an attacker can tamper with available secure templates images and insert bugs
into them. Therefore, the author believes that that virtual image templates must have some form of data
origin authentication practice, such as digitally signed images.

The last mentioned threat here in relation to virtual environments is the potential data leakage if
malicious or compromised virtual machines connect to CD-ROM drives or USB drives in the host server
and subsequently gain access the CD or USB media in the drive [DISA08]. This threat is minor; however,
there is still the need to note this kind of threat in this research as it is widely thought that people tend to
forget this, and an example like this could engage readers’ attention to these threats and ultimately help
to prevent them.

3. UNSECURE APPLICATIONS, AND PATCHING MANAGEMENT

In cloud computing, malwares are still a major security threat. According to Cloud Security Alliance, ‘the
ability for malware to remotely exploit vulnerabilities in these systems and applications remains a
primary threat to virtualised environments and is an even greater risk in instance-based cloud computing
environments where patch management responsibilities lie with the system lessee’ [CSA09]. Therefore,
managing secure, tested and patched applications is vital in terms of maintaining security.
 P a g e | 37

3.1. UNSECURE/UNTESTED APPLICATIONS

The first problem with unsecure application management is that there are no guarantees what
applications clients install and use on their machines. Clients could decide to run proprietary unsecure or
untested applications. There are number of suggested solutions to this problem. First, providers could
prevent clients from installing applications until the cloud providers’ system analysts test those
applications; however, this could create inconvenience because it will restrict clients and delay them by
making them wait until providers decide whether or not to allow this application, which may
consequently lead to losing two of the most powerful cloud computing features, which are agility and
automation. Another solution would be strengthening the isolation layers between guests’ virtual
machines, which prevents unsecure applications in one machine from affecting other machines. In this
case, unsecure applications will affect only the machine which is installing the application. However,
strengthening isolation layers is not an easy task, and will never be perfect. Therefore, providers should
not solely rely on this solution. The third possible solution for managing this problem is by forcing
machines with unsecure applications to temporarily migrate to another zone, which works as a kind of
quarantined zone, until this virtual machine is patched or upgraded; this solution more keenly
emphasises the importance of security measurements and metrics.

3.2 PATCHING MANAGEMENT

In 2008, Verizon Business Risk Team published a study concerning data breach investigations, which
states that, ‘...hacking and malcode proved to be the attack method of choice among cybercriminals.
Intrusion attempts targeted the application layer more than the operating system and less than a quarter
of attacks exploited vulnerabilities. Ninety percent of known vulnerabilities exploited by these attacks
had patches available for at least six months prior to the breach’ [BHV08]. It is concluded from the study
that applying patches to applications when they are available could prevent about 90% of hacking and
malcode attacks.

Providers can help and try different ways of keeping virtual machines patched whereby, for example,
clients could be legally obligated to manage patching by contracts. Education and awareness are also
useful for the purpose of alerting clients about patching importance. Furthermore, it is widely considered
that some patches affect usability and stability of systems [MW08]. Therefore, many clients are afraid of
installing patches, although this was in regular servers. In virtual machines, patching is safer because, if
anything goes wrong, virtual machines have the ability to roll back [LS06]. Furthermore, clients can clone
their virtual machines and apply patches to the clone and then swap to the virtual machine [SBD08]; this
method of patching is useful when striving to avoid unsuccessful patching and/or reducing downtime
[SBD08]. These features could also further encourage clients to patch their systems.

Providers should also offer 24-hour support facilities in order to answer clients’ queries concerning
patching and other security issues. What is more, providers can acquire lists of all running applications
and services for each client and subsequently alert them if any new patch becomes available. All of the
 P a g e | 38

aforementioned methods could actively encourage clients to patch their machines. However, the actual
responsibility for patching still remains with the clients.

3.3 PATCHING OFFLINE VIRTUAL MACHINES

One more security issue which needs to be analysed when discussing patching management is patching
offline virtual machines. Virtual machines can be offline for several reasons, such as for the purpose of
archiving, testing and back-up purposes [McA08]. Some of them may stay offline for long period of time,
which consequently causes them to be out-of-date from a security viewpoint. Furthermore, such
machines may have unpatched applications, unpatched operating systems and/or antivirus software
requiring updates. The problem is that these out–of-date virtual machines could wake up and go online at
any moment, which may subsequently pose a threat to the security of the cloud [CSA09]. Furthermore, no
security scanning or automated patching management service will discover them because they are offline
[LS08]. Bringing those virtual machines online from time to time — just for the purpose of updating them
— are time- and effort–consuming, and this security issue is always forgettable [McA08].

In the market today, there are number of security tools which deal with patching offline virtual machines,
such as a tool from Shavlik Technologies [Sha09] and another tool from McAfee VirusScan Enterprise
[McA08]. Most of these tools automatically apply patches without bringing virtual machines online.
However, the author is not aware about how useful those tools are, and rather believes that more
research is needed in this area.

The most important security message to remember here is that providers should not forget or
underestimate the risk of out-of-date offline virtual machines on their clouds’ security.

4. APIS SECURITY

Clients can interact with the infrastructure by using a set of Application Programming Interfaces (APIs)
provided by the cloud. This set of APIs is used in order to create, manage virtual machines and manage
firewalls. Those APIs should have some form of data origin authentication and confidentiality.

Origin authentication is used to prevent an attacker from creating and manipulating virtual machines and
for accepting only genuine clients. For instance, Amazon EC2 accepts only digitally signed APIs using X5.9
certificate [Ama09a]. On the other hand, confidentiality is essential for preventing other clients and the
outside world from monitoring specific client activities by reading its APIs. SSL is usually used for APIs
encryption.

5. PRICING MODEL ATTACK, EDOS (ECONOMIC DENIAL OF SUSTAINABILITY)

The attack was first introduced by Christofer Hoff, a Chief Security Architect at Unisys, in November, 2008
[CH08]. The idea of the attack was to exploit the cloud pricing model — pay per use — by making a large
amount of legitimate requests for the services which targeted virtual server offers. This virtual server
could be any type of server, such as virtual mail server, virtual web server, or virtual ecommerce server.
The large amount of requests does not target availability as in DoS attacks; it targets the economy of the
 P a g e | 39

owner of this virtual server. Due to the pricing model existent in cloud computing, each request means
more use of the service and, consequently, a larger bill to pay. If the attack continues and the bill grows
out of control due to these artificial requests without returning profits, this could return the client’s
server back home because old fashion, in-house hosting, would be of greater cost benefit to the affected
client.

These kinds of attacks have a direct effect on business profits. The author notes interesting points
regarding EDoS attack: First, it does not affect confidentiality, integrity and/or availability, which are the
CIA model of security, which could require adding more security goals for the three goals CIA model;
second, EDoS may be the first attack dedicated to cloud computing, and it is expected that attackers will
realise this attack and cloud providers will try to develop solutions for this seriously damaging attack.

6. CONCLUSION

As it has been shown in this chapter, providers face a variety of threats, such as virtualisation threats,
applications vulnerabilities, malicious or compromised clients, exploiting hosts’ or guests’ operating
systems vulnerabilities, hypervisor vulnerabilities, malicious code and EDoS. A number of suggested
solutions have been discussed.

Providers’ security is a shared responsibility between the providers and their services renters. However,
the assurance — which is the hardest task — is the provider’s responsibility. Threats and vulnerabilities
have been discussed here, and do not cover all of security areas in clouds’ provider side; some security
areas, such as load balancing, monitoring administrative activities, security logs, auditing, compliance,
segregation of duties, integrity monitoring and more, also need to be taken care of.
 P a g e | 40

Chapter 6: Storage cloud Security

1. INTRODUCTION

Storage cloud is one of the services offered by IaaS. Many researchers and websites have referred to
storage cloud as SaaS, which means “storage as a service,” but this usage is easily confused with the term
“software as a service,” which is one of the areas of cloud computing. Other research organizations, such
as the Storage Networking Industry Association (SNIA) that produces storage cloud standards, refer to
storage cloud as “data storage as a service” (DaaS), which is a unique and much more suitable
abbreviation [SNIA09].

In storage cloud, clients store their data into cloud servers, ‘which are running in a simultaneous,
cooperative, and distributed manner’ [WWRL09]. The existence of storage cloud is as a response to the
growing demand for storage capacity and high availability. Storage in the cloud can be used as an
extension to local storage servers. Clients can expand according to their needs, and they pay for the
number of gigabytes per month they use [MK09]. Clients can use storage cloud for several purposes. First,
storage cloud is used to store active databases and files, and the client can work on them while they are in
the cloud. Active data means data that are manipulated in real time by operations such as add, delete, and
append. Second, clients can use storage cloud for backup services. Using cloud for backup services is
popular and widely known. Vance Checketts, the Chief Operating Officer for EMC Mozy, said ‘Online
backup is a really great way to start people down a path to cloud computing’ [DB08]. He also said,
‘Customers will have already paid the price of getting into the cloud. So we will be able to say how about
doing X, Y, and Z?’ [DB08]. Third, the storage server can be used by the compute cloud to store files from
virtual machines. As was stated in chapter 5, the virtual machine is encapsulated in one file, and this file is
stored in storage cloud when the virtual machine is not active. The last use for storage cloud to be
mentioned here is that applications can use the cloud to store their data [WWRL09].

In storage cloud, clients do not have their data locally anymore. Sending data to the cloud introduces new
risks and threats to the data. Protecting stored data is a shared responsibility between clients and
providers. On one hand, the clients should encrypt their sensitive data when they are in transit and at
rest, and they should maintain their keys properly. They also should have clear classification for data to
be able to decide which are sensitive and which are not. Furthermore, clients should keep their machines
secure and updated to prevent attackers and malware from stealing their credentials and accessing the
cloud. Clients also should use secure communication channels to connect to the cloud, and, as was
discussed in chapter 3, this is usually accomplished by using SLL VPN. On the other hand, the provider is
responsible for maintaining data security and providing assurance. Maintaining data security involves
maintaining correctness, availability, and confidentiality of the data. Correctness covers integrity, fault
tolerance, and recovery mechanisms, whereas availability is related to service disconnect and latency.
Confidentiality covers several areas, including encryption, authentication, access control, and data
disposal. In addition, providers should supply clients with security tools to allow them to ‘make
 P a g e | 41

continuous correctness assurance of their stored data even without the existence of local copies’
[WWRL09]. In addition, providers must assure clients that their employees do not have access to the
clients’ data [ABC+07]. Maintaining data security and assurance in storage cloud are discussed in this
chapter.

2. HOW STORAGE CLOUD WORKS

As all other cloud services, virtualization is a key concept in storage cloud. It allows sharing resources and
reducing cost. Storage virtualization is ‘a form of resource virtualization, where a logical storage is
created by abstracting all the physical storage resources that are scattered over the network’ [JR07]. All
physical storage servers work together as one powerful storage server, which forms virtual servers to be
used by clients [JR07]. All clients are sharing the same storage pool, which requires strong isolation
between them. Because all physical servers are connected to each other, attacks and/or infections can
propagate throughout the cloud [SG09a]. A vulnerability in a virtual server could be exploited and affect
the entire cloud, so it should be considered as a ‘point of entry and launch pad for a possible attack’
[SG09a]. In storage cloud environment, the provider is responsible for maintaining the isolation between
clients. They should also ‘assure that a virtual server image is afforded the same protection as if it were a
physical server’ [SNIA08].

Clients can access cloud storage either by mapping the cloud storage virtual server to a network drive or
by using APIs [DB08]. Usually, API sets are published, but some storage providers, such as Vaultscape, use
unpublished APIs, and Vaultscape’s position is that ‘access to the API is only available via a contract with
Vaultscape’ [vau09]. They argue that using unpublished APIs is more secure because, as they said, ‘Since
the API is public, then it is immediately open to hacking, and, since customer data are in transit to and
from this API, then they are ultimately vulnerable to access’ [vau09]. In the author’s opinion, this is a kind
of security through obscurity, and it could give a false sense of security because these APIs could be
reversed engineered, makingthe entire cloud vulnerable.

There are many technologies that can be used to extend the storage of local servers by using storage
cloud virtual servers through the Internet. For this purpose, all distributed-data storage systems, such as
the Google file structure, can be used [BMQ+07]. The Google file structure extends local storage by cloud
storage and increases the total storage space and ‘data processing speed when data and processing power
are spread out efficiently’ [BMQ+07]. Another popular technique is to use the storage area network
(SAN), which provides almost the same functionality as the Google file system [BMQ+07].

3. STORAGE CLOUD THREATS

There are number of sources of threats against storage data and cloud services. Such sources were
discussed in detail in research conducted at the Illinois Institute of Technology and the Worcester
Polytechnic Institute, entitled Ensuring Data Storage Security in Cloud Computing [WWRL09]. The
research identified four different types of threats. The first threat was a malicious provider who tries to
save money by moving ‘rarely accessed data to a lower tier of storage than agreed’ [WWRL09]. This
threat may affect availability when these rarely-accessed data are needed. The second threat was a
 P a g e | 42

malicious provider who tries to conceal incidents and the loss of data from clients [WWRL09]. The
provider may attempt to conceal such incidents to escape legal sanctions or to prevent damage to its
reputation. In this case, clients may never know about these incidents, even though this threat could
affect the integrity of data. The third threat is a weak adversary who tries to modify or corrupt data to
prevent an authorised client from retrieving his or her original data [WWRL09]. This threat affects the
integrity and the availability of the data. The fourth threat was a strong adversary who tries to modify or
corrupt data in a way that gives the appearance of internal consistence [WWRL09]. To keep data
internally consistent, the attacker must access all storage servers in order to accomplish her or his
malicious task. In this scenario, the provider and the client may not discover the illegal modification of
data, and the client may rely on invalid data. As the research indicated, this is the worst-case scenario
[WWRL09], and it affects the integrity and confidentiality of the data. Threats against storage cloud
services affect availability, and this issue is addressed in the next section.

4. STORAGE CLOUD AVAILABILITY

As has been stated earlier, maintaining availability is the provider’s responsibility. Cloud always has a
reputation of having high availability, but there is almost always a single point of failure for most cloud
providers. For instance, if the servers that are responsible for load balancing, PKI servers or
authentication gateways fail, service will likely be interrupted until these critical servers are back in
service. Some service providers, such as Vaultscape, which provide archiving services, claim to have
100% availability because of their special methodology of replicating data between dual master sites
[vau09]. However, very little information about their methodology is available.

Another issue related to availability is latency, which is a chronic problem in storage cloud because of two
factors. The first factor is that clients usually store and deal with large files and with data that consume
high bandwidth, large space, and require high access rates. Transferring large amounts of data requires
coordination between ‘many heterogeneous network components and maintain stable high-bandwidth
connections for long periods’ [CD09]. The second factor is that clients’ data must be sent over the public
Internet, which is a complicated and unguaranteed environment, especially for latency. This is because,
while using the Internet to transmit data, some or all of the data may be lost, have to be sent several
times, or take a long time to be delivered. Therefore, it is widely thought that applications’ data that are
sensitive to latency, such as on-line transactional data, should not be stored in the cloud except for backup
or archiving, according to Jonathan Buckley, Chief Marketing Officer at Nirvanix, which is a storage cloud
provider company [DB08].

5. DATA CORRECTNESS

The next security matter in storage cloud is data correctness. It is concerned with identifying corrupt data
and unauthorised data modification to prevent the storage and use of such data [BB99]. Data can be
corrupted by several means, including an attacker, malicious codes, and accidental errors. Data
correctness covers integrity, fault tolerance, and recovery mechanisms.
 P a g e | 43

5.1 Integrity

The provider should determine the integrity of data without revealing or accessing the data. Furthermore,
the data should be checked in the cloud without moving them to clients’ machines, and this check should
be done automatically for all data [WWRL09]. There are many techniques and protocols for maintaining
the integrity of data in the cloud. Earlier techniques for determining the integrity of data did not work
properly in the cloud, because most of them are designed to check static data in a single server. Integrity-
check protocols for the cloud should consider dynamic data, which are data that can be changed
instantaneously. They also should consider the fact that data in the cloud rest in a single virtual server
while many copies exist in other servers in different geographical areas [WWRL09]. Storing redundant
data in multiple locations is essential for reducing threats to the integrity of the data [WWRL09], because,
if data were stored in a single server, they would be lost if a disk failed or even if the server was down for
any reason. These distributed protocols should also be able to diagnose the error, discover which server
has the error, and correct the error. Another issue is caching data in the write operation, especially if the
data are accessed by multiple clients at the same time. A similar problem arises in the Amazon storage
cloud, Amazon S3. Amazon states on its website that ‘Amazon S3 does not currently support object
locking. If two puts are simultaneously made to the same key, the put with the latest time stamp wins. If
this is an issue, you will need to build an object-locking mechanism into your application’ [Ama09b].
Researchers from the Illinois Institute of Technology and Worcester Polytechnic Institute claimed that
they designed a protocol for checking the integrity of data that satisfies all storage cloud requirements
however, more testing needed to this protocol [WWRL09].

5.2 Fault tolerance

Fault tolerance is ‘the ability to ensure continuity of service in the presence of faults or events that cause a
system to operate erroneously’ [CD09]. It requires detecting and recovering faults to allow the cloud to
continue to provide its services [CD09]. Used software components should be tested to eliminate faults
and check reliability; if the software passes the tests, then it can be certified [CD09]. These tests can be
performed using various tools, such as fault injection tools, which work by ‘injecting faults into a system
under test and observing its behaviour’ [THS06]. In storage cloud, providers have more control over the
application used than in compute cloud. In many cases, storage cloud provides these applications to its
clients. However, as in grid computing, cloud computing clients may design their applications with built-
in fault tolerance to be able to rely on them [CD09].

One of the sources of faults in storage cloud is clock synchronization, which is always needed in any
distributed environment to be used in different protocols. Different components in the cloud may utilize
independent clocks, which makes it hard to distinguish between clock drafting and real faults [CD09].
This source of threat was taken from a research paper about storage in grid computing by S´ebastien
Tixeuil, William Hoarau, and Luis Silva from Universite Paris-Sud PARIS XI, France [CD09] about grid
computing, but, because of the propinquity between grid and cloud computing, we found that this
particular threat can also apply to storage cloud.
 P a g e | 44

5.3 Recovery mechanisms

Mechanisms for automatic recovery from failures are essential to maintain the correctness of data and
allow minimum disruption [SHS09]. ‘Recovery must also ensure consistency of related changes, whereby
they are made as a whole or not at all’ [SHS09]. Furthermore, error propagation is always a problem in
distributed systems. Therefore, recovery tools should coordinate the recovery process between different
components in the cloud. There are two sources of recovery in the cloud. The first source of recovery is
log files that contain all changes to data and allow the recovery system to restore before images
(backward recovery) or after images (forward recovery) [SHS09]. The other possible source of recovery
in the cloud is data redundancy [CD09].

6. CONFIDENTIALITY

Normally, enterprises have different classifications of data. Some data should be kept secret, because
their disclosure could affect the business of the entire enterprise. Therefore, when these enterprises store
their data in the cloud, data confidentiality should be maintained properly. Encryption, authentication,
access control, residual data, and data disposal are main factors for confidentiality, and they are discussed
in this section.

6.1 Encryption

Encryption is the main security control to protect sensitive data from unauthorised disclosure [SSS07].
The nature of data, their degree of sensitivity, and the amount of stored data determine the suitable
encryption solution [SSS07]. For instance, clients can choose to encrypt their sensitive data twice, once by
using a key and encryption algorithm of their choice and also by using a key that is shared with the
provider. The procedure of encrypting data twice is required if clients do not trust the provider and do
not trust the provider’s security controls for very sensitive data. In storage cloud, it is safer for clients to
assume that a malicious party will compromise the storage providers’ servers and that attempts will be
made to retrieve sensitive data. Then, they can take these potential events into account when planning
their security policies [SHS09].

There are several security concerns in storage cloud. First, if the client’s device that stores encryption
keys is compromised, encryption may not be able to prevent the attacker or the malware from reading
the client’s sensitive data [SSS07]. NIST’s Guide to Storage Encryption Technologies for End User Devices
gives two examples for this case; one of the examples is stated as follows: ‘an attacker disabling or
reconfiguring storage encryption, malware installing a keylogger that captures passwords used for
storage encryption authentication, or malware acquiring a copy of a storage encryption key from the
device’s memory’ [SSS07].

The second security concern occurs after encryption has been performed in that there could be some
residual, unencrypted data, as happens when a file is encrypted, then deleted, and an unencrypted
 P a g e | 45

version of the deleted file can be retrieved by storage cloud employees or anyone who is able to
physically access servers through the use of some forensic tools [SSS07].

Another concern is with the storage of databases. Clients can encrypt their databases before sending them
to the cloud, but they will not be able to execute queries on these encrypted databases, which is essential
when dealing with databases in most cases.

The last concern is that, even if files or data are encrypted, when clients work on them, they should work
on unencrypted versions of these data in the memory. Because storage cloud is a shared environment, if
an attacker could directly access the memory by buffer overflow or any other technique, he or she can
read these unencrypted data.

One of the essential areas in dealing with encryption is encryption primitives, such as key lengths,
encryption algorithms, and random number generators. Providers and clients should follow the
standards when dealing with encryption primitives. For key management and protection, they should
have plans and procedures ready. For instance, encryption keys should be protected properly in an
encrypted form or in tamper-resistant, cryptographic tokens [SSS07]. Furthermore, the strength of the
key should be matched with its use and its expected lifetime. Lost, damaged, or compromised keys must
also be dealt with.

6.2 Authentication

Storage encryption requires successful authentication before allowing access to encrypted data. A variety
of authentication techniques can be used, such as passwords, cryptographic tokens, and biometrics
[SSS07]. Storage cloud could receive requests for retrieving or modifying data, either through the Internet
or from within the cloud. The sources of these requests should be authenticated. Usually, SSL and digital
signature techniques are used for authentication. For instance, Amazon S3 uses HMAC-SHA1 signature to
authenticate requests using the client’s private key [Ama09a]. In addition, administration requests should
also be authenticated and logged. Storage cloud receives administration requests for the purpose of
encryption management, updating software, managing user accounts, and/or recovering data in case of
faults [SSS07]. Logging all accesses and requests is essential for accountability purposes. ‘The
combination of encryption and authentication helps control access to the stored information’ [SSS07].

6.3 Access control

When a user is authenticated, her or his access right should be specified by access control policy. Some
users can just read, and others are allowed to modify. There are several access-control policies available,
but the most important point here is the default status of access control to the data. Providers should use
the deny-by-default policy for any newly-generated object until clients change the access control by
themselves later.
 P a g e | 46

6.4 Delete operation and residual data in storage cloud

The delete operation is always done by removing the mapping from the public name to the object, and
this process should be done across the distributed system [Ama09a]. In storage cloud, there should be a
strong garbage-collection mechanism to remove unmapped files from the system, otherwise attackers
may find ways to specify the location of deleted data in the system and retrieve them. Furthermore, as
stated above, any malicious user who has access to physical storage can use forensic tools to retrieve
these deleted data, and the same thing can happen to temporary files in the system. Another threat is
slack space for files. When a stored file requires less space than the file allocation unit, the remaining free
space in this allocation is called slack space [SSS07]. Slack space may still contain portions of files, and
malicious clients could misuse these data [SSS07].

6.5 Data disposal

When a storage server expires, the provider should remove all clients’ data from the server by following
standards, such as NIST SP 800-88, Guidelines for Media Sanitization to Prevent Data Misuse. Furthermore,
all copies of used keys should be destroyed [SSS07]. Another point is that, when a client leaves the cloud
permanently, the provider should destroy the departed client’s data immediately. In such a case, the
provider has the dilemma of being able to prove that all copies of the client’s data were destroyed
properly. In this case, a trusted third-party auditing service may be required.

7. CLOUD RAID

What do storage providers use to manage their resourses? One of the methods they use is called Cloud
Redundant Array of Independent Disks, or cloud RAID, which is used for distributing stored data and
access among larger pools of storage disks in the same cloud or in other clouds [NET09]. The storage
devices are arranged into arrays to ensure reliability and performance. These storage devices are said to
be in a RAID array [NET09].

7.1 Redundancy

In efforts to ensure reliability, it must be remembered that stored data can be affected either by errors or
deliberate attacks. RAID systems provide a way to retrieve these lost data. Redundancy is provided to
prevent data losses in case of failures [SNIA09]. For instance, when a drive fails, clients would not be
aware of this failure, and they will continue to work on their stored data. Storage providers should have a
way for retrieving these data so that the reliability of the data will be not affected. There are two easy
ways to retrieve data. First, the RAID system makes hot, spare copies of all data instantaneously and, in
case of a failure, retrieves the lost data from these spare copies automatically; this is called “Mirroring”
[NET09]. Otherwise, they can calculate extra data across the array; this is called “Parity bits” [NET09].

Parity is a process of adding check bits to data to detect errors. Data consist of a series of bytes, which
represent, for example, characters, sounds, and pictures. The simple form of parity is work by adding an
extra bit to each byte of data to indicate whether this byte has even or odd number of 1’s [Ada05]. The
 P a g e | 47

RAID system can check the reliability of a byte by checking the parity bits to determine if they match the
number of bits in the byte; if they do, the byte is accepted as a healthy byte, but, if they do not match, the
byte is rejected [Ada05]. This is only a detection technique, but it can be extended by adding more parity
bits, which would allow it to be used for corrections, such as Error Correction Code (ECC) and XOR parity
[Ada05]. Both previous techniques are used in RAID systems, depending on the type of RAID.

7.2 Performance and Data Stripping

Cloud RAID should also ensure performance, because large amounts of data are being processed. High
performance is achieved in RAID systems by ‘distributing I/O load evenly across disks with no system
management or application involvement’ [PIP09]. Data stripping which is the basis of RAID, is responsible
for balancing the I/O load across the array [PIP09]. ‘Stripping is a method by which a block of data can be
broken down to smaller pieces and simultaneously written to multiple locations’ [Ada05]. It aims to
increase the performance by keeping all drives in the array busy [PIP09]. It distributes data efficiently
depending on their need for resources, such as frequently-used files in comparison to idle files [PIP09].

7.3 RAID levels

There are different levels of RAID, and each level provides a different service and is suitable for a specific
use. The most popular RAID levels are levels 0, 1, 3, and 5. For instance, RAID 0 does not provide
redundancy, which means that, if a drive fails, all data are lost, while RAID 5 provides redundancy
through extended parity with the ability to regenerate lost data [NET09].

7.4 Storage Cloud Standards

Developing storage cloud standards is critical for cloud interoperability. ‘Without a consistent method for
storing and retrieving data, it will become necessary to program to each service provider implementation,
effectively causing lock-in to that solution or creating significant overhead for development’ [CE08].
Interoperability is essential for enhancing availability, but, because of the lack of standards, clients must
write a program for each storage cloud interface [CE08].

One of the first attempts to develop a standardised storage cloud interface was made by SNIA, which
published a document entitled “Cloud Storage Reference Model,” which standardised storage clouds’
interfaces [SNIA09].

In the storage cloud market today, the most commonly used application programming interface (API) is
the standard REST/SOAP protocols. For instance, Amazon S3 service uses the REST/SOAP protocol, but it
includes proprietary functions for storing and retrieving data [CE08]. The same is true for Nirvanix's
Internet Media File System [CE08].
 P a g e | 48

7.5 eXtensible Access Method (XAM)

SNIA XAM is one of the RAID mechanisms that aims to provide interoperable storage clouds interfaces by
using XAM specification [SNIA07]. It is mainly developed for fixed-content data. By adopting XAM’s
specifications, it allows different storage clouds to exchange and share data [SNIA07]. It also tries to solve
security issues, such as compliance.

7.6 Redundant Array of Independent Cloud (RAIC)

Another solution to the problem of lack of interoperability is to use middleware between clients and their
providers [CE08]. ‘The middleware would provide a set of standardized services, which would allow data
to be stored in either cloud, or both, depending on the requirement’ [CE08]. This is what is called
Redundant Array of Independent Cloud (RAIC) [CE08]. There are two types of RAIC, i.e., RAIC 0 and RAIC
1. In RAIC 0, data are distributed between different clouds without providing redundancy [CE08]. This is
similar to RAID 0. In RAIC 1 data are replicated between different clouds, which provides redundancy
services by having multiple copies [CE08].

8. CONCLUSION

Some of the most important security concerns in storage cloud are discussed in this chapter, but there are
many additional concerns, such as data governance and legal aspects; as Danny Bradbury said, ‘If a cloud
storage provider in the UK subcontracts to an infrastructure provider in another country, what legal and
technical problems might that create?’ [DB08]. Furthermore, backup management is an important security
concern for storage cloud. Data privacy is also a concern when dealing with private customers’ data. In
addition, a disaster recovery plan is needed, perhaps as Danny Bradbury stated, ‘even using two
providers’ [DB08]. Lately, there were two published incidents about data-storage providers. The first
incident was in August 2008 when The-Linkup storage cloud lost a large amount of its clients’ data, which
led to closing down the company [DB08]. The other incident was when Flexiscale storage cloud clients
were ‘unable to access their data after an engineer accidentally deleted a main storage volume and a bug
in the system restricted customers to read-only access when dealing with their data’ [DB08]. These two
incidents show the importance of a disaster recovery plan as well as the importance of developing storage
cloud standards. In today’s market, the author has found only one storage cloud standard, which was
developed by the Storage Networking Industry Association (SNIA), a non-profit organization that
addresses concerns in the data storage industry [SNIA09].
 P a g e | 49

Chapter 7: Research Contribution and

Conclusion
In conclusion, this research introduces the technologies used in cloud computing and surveys most
existing threats to and vulnerabilities of the cloud. It also presents an overview of cloud computing
security and covers most security areas related to compute cloud and storage cloud. The researcher
gathered large number of previous papers, articles, blogs, and interviews about cloud computing security
and analysed them. Some gaps were found for some cloud computing security issues that are not covered
by any other research, such as the special damage that worms can do to the cloud by consuming
bandwidth, which could affect the cloud pricing model, which is pay per use. The researcher tried to cover
these gaps using her experience and study in information security. This research does not discuss
technical details in depth, because cloud computing is a wide, ramose area, and large numbers of
technologies are used there. Therefore, the researcher found that it was much better to develop and
overview of this subject in this research in preparation for more detailed research later. Each section of
this paper can be a topic for separate research.

This research covers the security of communication channels in the cloud, which represents a critical part
of overall cloud security. It also discusses client-side security, shows clients’ responsibilities, and
addresses the problem of having little control of clients’ machines. It also discusses provider-side
security, e.g., the special Economic Denial of Sustainability attack, and suggests adding an extra section,
related to economics, to the confidentiality, integrity, and availability model. The last part of the research
is about cloud storage security, which is a major concern of the widely used cloud services. In this section,
all security issues under storage cloud are discussed, and suggestions are made for maintaining storage
cloud security.

In general, understanding how cloud’s services are provided and how data are managed is essential for
maintaining security. Using cloud services does not free clients from security responsibilities; clients and
providers alike should understand and fulfil their security responsibilities when using cloud services.
There is a need for more research in cloud computing security, especially in the area of compliance in
cloud computing security. There is also a need for standards and best practices for cloud computing
security to support interoperability between different providers.

Enhancing and regulating cloud security will engage more organisations in providing cloud services and
will improve the services. Furthermore, providers’ transparency regarding security is required to develop
trust between them and targeted organisations. Dealing with services as a black box does not help to
improve security, and users should be convinced that providers offer satisfactory baseline security.
 P a g e | 50

References:
[1] [ABC+07] Ateniese G., Burns R., Curtmola R., Herring J., Kissner L., Peterson Z., & Song D. (2007). Provable Data
Possession at Untrusted Stores. IBM Corporation, Retrieved from www.cs.berkeley.edu/~dawnsong/papers/p598-
ateniese
[2] [Ada05] Adaptec. (2005). Chapter 4. Adaptec Certified Storage Professional. Adaptec, Retrieved from
http://www.ugrad.cs.ubc.ca/~cs318/notes2005/Lect19b-WhitePaper-RAID-ACSP_RAID_Ch4-328-04.pdf
[3] [AM06] Murphy A. (2006). Security Implications of the Virtualized Data Center. SANS Institute, Retrieved from
http://www.sans.org/reading_room/whitepapers/sysadmin/security_implications_of_the_virtualized_data_center_1796?
show=1796.php&cat=sysadmin
[4] [Ama09a] Amazon AWS (2009). Amazon Web Services: Overview of Security Processes. Amazon, Retrieved from
http://awsmedia.s3.amazonaws.com/pdf/AWS_Security_Whitepaper.pdf
[5] [Ama09b] Amazon. Amazon Simple Storage Service Developer Guide (API Version 2006-03-01). Amazon Web
Services, Retrieved 15 August, 2009, from
http://docs.amazonwebservices.com/AmazonS3/latest/index.html?Introduction.html
[6] [AS09] Stamos A. (2009). Cloud Computing Security. iSECpartners, Retrieved from https://www.isecpartners.com
[7] [AS99] Aboba B., & Simon D. (1999). PPP EAP TLS Authentication Protocol. RFC2716 , Retrieved from
http://www.faqs.org/rfcs/rfc2716.html
[8] [BB99] Becker S., & Berkemeyer A. (1999). The Application of a Software Testing Technique to Uncover Data Errors
in a Database System. Software Engineering & Computer Science, Florida Institute of Technology, Retrieved from
www.geocities.com/docubase/TestingDatabases.pdf
[9] [BHV08] Baker W., Hylender D., & Valentine A. (2008). 2008 DATA BREACH INVESTIGATIONS REPORT. VERIZON
BUSINESS RISK TEAM, Retrieved from www.verizonbusiness.com/resources/security/databreachreport.pdf
[10] [BMQ+07] Boss G., Malladi P., Quan D., Legregni L., & Hall H. (2007). Cloud Computing. High Performance On
Demand Solutions (HiPODS). IBM Corporation, Retrieved from
http://download.boulder.ibm.com/ibmdl/pub/software/dw/wes/hipods/Cloud_computing_wp_final_8Oct.pdf
[11] [BR05] Bellovin S., & Rescorla E. (2005). Deploying New Hash Functions. Columbia University & Network
Resonance. CRYPTOGRAPHIC HASH WORKSHOP. NIST, Retrieved from
http://csrc.nist.gov/groups/ST/hash/documents/Bellovin_new-hash.pdf
[12] [BW08] Wolff B. (2008). Security and Cloud Computing. BlueLock, Retrieved from
http://blog.bluelock.com/blog/bluelock/0/0/security-and-cloud-computing
[13] [CD09] Dabrowski C. (2009). Reliability in grid computing systems. John Wiley & Sons, Retrieved from
http://w3.antd.nist.gov/Measurement%20Science%20for%20Complex%20Information%20Systems_files/Dabrowski-
GridReliabilityEarlyView.pdf
[14] [CE08] Evans C. (2008). Redundant Array of Inexpensive Clouds - Pt II. The Storage Architect, Retrieved from
http://storagearchitect.blogspot.com/2008/12/redundant-array-of-inexpensive-clouds_16.html
[15] [CF03] Ferraro C. (2003). Choosing between IPsec and SSL VPNs. SearchSecurity, Retrieved from
http://searchsecurity.techtarget.com/news/interview/0,289202,sid14_gci940324,00.html
[16] [CH08] Hoff C. (2008). Cloud Computing Security: From DDoS (Distributed Denial Of Service) to EDoS (Economic
Denial of Sustainability). Message posted to http://rationalsecurity.typepad.com/blog/
 P a g e | 51

[17] [CIS08] CISCO (2008). 2008 Annual Security Report. CISCO, Retrieved from
http://www.cisco.com/en/US/prod/collateral/vpndevc/securityreview12-2.pdf
[18] [Clo09] Cloud Computing Community (2009).CloudComputing:Incidents Database. Cloud Computing Community,
Retrieved from http://wiki.cloudcommunity.org/wiki/CloudComputing:Incidents_Database
[19] [CR06] Chandramouli R., & Rose S. (2006). Secure Domain Name System (DNS) Deployment Guide. National
Institute of Standards and Technology, Gaithersburg, Retrieved from http://csrc.nist.gov/publications/nistpubs/800-
81/SP800-81.pdf
[20] [CSA09] Cloud Security Alliance (2009). Security Guidance for Critical Areas of Focus in Cloud Computing. Cloud
Security Alliance, Retrieved from www.cloudsecurityalliance.org/guidance/csaguide.pdf
[21] [CW05] Wüeest C. (2005). Threats to Online Banking. Symantec Security Response, Dublin Retrieved from
www.symantec.com/avcenter/reference/threats.to.online.banking.pdf
[22] [DB08] Bradbury D. (2008). Can you entrust your data to the cloud (data security in cloud computing). Computer
Weekly, 24 - 25
[23] [DISA08] DISA Field Security Operations (2008). ESX SERVER SECURITY TECHNICAL IMPLEMENTATION GUIDE.
Department of Defense, Retrieved from http://iase.disa.mil/stigs/stig/esx_server_stig_v1r1_final.pdf
[24] [DW03] Worden D. (2003). iSeries Security in an e-business environment. West Michigan IBM iSeries User Groups I-
94 & WMSUG, Retrieved from iseries.homestead.com/files/2003Nov-Security.pdf
[25] [EJ05] Johanson E. (2005). The state of homograph attacks. Johanson E, Retrieved from
http://www.shmoo.com/idn/homograph.txt
[26] [FHOP08] Frankel S., Hoffman P., Orebaugh A., & Park R. (2008). Guide to SSL VPNs. National Institute of Standards
and Technology NIST, Gaithersburg, Retrieved from http://csrc.nist.gov/publications/nistpubs/800-113/SP800-113.pdf
[27] [GC08] Conti G. (2008). The Need for 2 Factor Authentication in Cloud Computing - Defcon and ISACA. Privacy and
Identity Theft, Retrieved from http://blog.ironkey.com/?p=438
[28] [IBM08] IBM (2008). IBM Perspective on Cloud Computing. IBM Corporation, Retrieved from
ftp://ftp.software.ibm.com/software/tivoli/brochures/IBM_Perspective_on_Cloud_Computing.pdf
[29] [IC08] IT Community (2008). IP Session Hijack. Toolbox for IT, Retrieved from
http://it.toolbox.com/wiki/index.php/IP_Session_Hijack
[30] [IDC08] IDC (2008). IT Cloud Services User Survey, pt.2: Top Benefits & Challenges. IDC, Retrieved from
http://blogs.idc.com/ie/?p=210
[31] [JR07] Reuben J. (2007). A Survey on Virtual Machine Security. Helsinki University of Technology, Retrieved from
www.tml.tkk.fi/Publications/C/25/papers/Reuben_final.pdf
[32] [JS08] Snyder J. (2008). Virtual Machines, Networking Security, and the Data Center: Six Key Issues and
Remediation Strategies. Juniper Networks, Retrieved from www.juniper.net/us/en/local/pdf/whitepapers/2000286-
en.pdf
[33] [KCW+06a] King S., Chen P., Wang Y., Verbowski C., Wang H., & Lorch J. (2006). SubVirt: Implementing malware
with virtual machines. University of Michigan & Microsoft Research, Retrieved from
Www.eecs.umich.edu/~pmchen/papers/king06.pdf
[34] [KCW+06b] King S., Chen P., Wang Y., Verbowski C., Wang H., & Lorch J. (2006). SubVirt: Implementing malware
with virtual machines. University of Michigan & Microsoft Research, Retrieved from
www.eecs.umich.edu/~pmchen/papers/king06.slides.ppt
 P a g e | 52

[35] [KJ09] Jackson K. (2009). Cloud Computing: The Dawn of Maneuver Warfare in IT Security. Cloud computing
journal, SYS CON MEDIA, Retrieved from http://cloudcomputing.sys-con.com/node/994396
[36] [LM08] MacVittie L. (2008). Cloud Computing Infrastructure: Secure Remote Access. F5 DevCentral, Retrieved from
http://devcentral.f5.com/weblogs/macvittie/archive/2008/07/14/3447.aspx
[37] [LS06] Liston T., & Skoudis E. (2006). On the Cutting Edge: Thwarting Virtual Machine Detection. Intelguardians
Handler – SANS Internet Storm Center, Retrieved from
http://handlers.sans.org/tliston/ThwartingVMDetection_Liston_Skoudis.pdf
[38] [LS08] Lumension Security (2008). Putting Security First in the Newly Virtualized World. Lumension Security,
Retrieved from www.sapphire.net/downloads/VirtualizationFinal.pdf
[39] [MA09] Adams M. (2009). SSL MD5 PKI vulnerabilities threaten Web security. SpamStopsHere, Retrieved from
http://www.spamstopshere.com/blog/2009/01/08/ssl-identity-vulnerabilities-threaten-web-security/
[40] [McA08] McAfee (2008). McAfee VirusScan Enterprise for Offline Virtual Images. McAfee, Retrieved from
http://www.sikkerhed.biz/download/datasheets/ds_vse_offline_virtual_image.pdf
[41] [MG09a] Mell P., & Grance T. (2009). Draft NIST Working Definition of Cloud Computing. National Institute of
Standards and Technology NIST, Retrieved from http://csrc.nist.gov/groups/SNS/cloud-computing/cloud-def-v15.doc
[42] [MG09b] Mell P., & Grance T. (2009). Effectively and Securely Using the Cloud Computing Paradigm. National
Institute of Standards and Technology, Gaithersbur, Retrieved from http://csrc.nist.gov/organizations/fissea/2009-
conference/presentations/fissea09-pmell-day3_cloud-computing.pdf
[43] [Mic08] Microsoft TechNet (2008). TechNet Library. System Center Virtual Machine Manager TechCenter. Microsoft
TechNet, Retrieved from http://technet.microsoft.com/en-us/library/bb963714.aspx
[44] [MK09] Kontio M. (2009). Architectural manifesto: An introduction to the possibilities (and risks) of cloud computing.
IBM Technical library Retrieved from http://www.ibm.com/developerworks/library/ar-archman10/
[45] [MKN05] Mell P., Kent J., & Nusbaum J. (2005). Guide to Malware Incident Prevention and Handling. National
Institute of Standards and Technology, Gaithersbur, http://csrc.nist.gov/publications/nistpubs/800-83/SP800-83.pdf
[46] [MW08] Wimmer M. (2008). Virtual Security: About the Security Pros and Cons of Server Virtualization. Siemens AG,
Retrieved from www.first.org/conference/2008/papers/wimmer-martin-papers.pdf
[47] [ND08] Dhanjani N. (2008).Amazon's Elastic Compute Cloud [EC2]: Initial Thoughts on Security Implications. O'Reilly
Media, Retrieved from http://www.oreillynet.com/onlamp/blog/2008/04/amazons_elastic_compute_cloud.html
[48] [NET09] NETGEAR (2009). ReadyNAS 3200 Software Manual v1.0. NETGEAR INC, Retrieved from
http://www.readynas.com/download/documentation/UM/ReadyNAS3200_SMv1.0_26Jun09.pdf
[49] [NWG+08] Nurmi D., Wolski R., Grzegorczyk C., Obertelli G., Soman S., Youseff L., & Zagorodnov D. (2008). The
Eucalyptus Open-source Cloud-computing System. Computer Science Department, University of California, Santa
Barbara, Retrieved from http://open.eucalyptus.com/documents/nurmi_et_al-
eucalyptus_open_source_cloud_computing_system-cca_2008.pdf
[50] [PB02] Burkholder P. (2002). SSL Man-in-the-Middle Attacks. SANS Institute, Retrieved from
http://www.sans.org/reading_room/whitepapers/threats/ssl_maninthemiddle_attacks_480
[51] [PF06] Ferrie P. (2006). Attacks on Virtual Machine Emulators. Symantec Advanced Threat Research, Retrieved from
www.symantec.com/avcenter/reference/Virtual_Machine_Threats.pdf
[52] [PIP09] Pippard Inc. RAID - Redundant Array of Independent Disks white paper. Pippard Inc, Retrieved 24 August,
2009 from www.pippard.com/PDF/RAID_What_is_it.pdf
 P a g e | 53

[53] [PM08] McFedries P. (2008). The Cloud Is The Computer. IEEE spectrum, Retrieved from
http://www.spectrum.ieee.org/computing/hardware/the-cloud-is-the-computer
[54] [RK03] Rescorla E., & Korver B. (2003). Guidelines for Writing RFC Text on Security Considerations. RFC 3552. IETF,
Retrieved from http://www.ietf.org/id/draft-iab-sec-cons-03.txt
[55] [SBD08] Schreck G., Balaouras S., & Dines R. (2008). Server Virtualization Security: 90% Process, 10% Technology.
Forrester Research, Retrieved from http://i.i.com.com/cnwk.1d/html/itp/Tripwire-Forrester_VRT.pdf
[56] [Sec09] Secorio. SGC SSL. Secorio, Retrieved July 20, 2009 from https://www.secorio.com/index.php?SGC_SSL
[57] [SeF07] SecurityFocus (2007). Xbox 360 Hypervisor Privilege Escalation Vulnerability. SecurityFocus, Retrieved from
http://www.securityfocus.com/archive/1/461489/30/0/threaded
[58] [SeF09] SecurityFocus (2009). Xen 'hypervisor_callback()' Guest Local Denial Of Service Vulnerability. CVE-2009-
1758, SecurityFocus, Retrieved from http://www.securityfocus.com/bid/34957
[59] [SG09a] Spenser M., & Gehling B. (2009). Modern Storage Network Technology and Storage Virtualization: New
Advantages, Barriers to Acceptance, and Possible Solutions. School of Business, Auburn University Montgomery,
Retrieved from www.sedsi.org/Proceedings/2009/proc/p081010038.pdf
[60] [SG09b] Gauci S. (2008, July). When best intentions go wrong. IN secure, 17, 8-10 Retrieved from www.net-
security.org/dl/insecure/INSECURE-Mag-17.pdf
[61] [Sha09] Shavlik. Creating a Secure Base in a Virtual World. Shavlik, Retrieved July 23, 2009 from
www.trustedstrategies.com/papers/secure_base_in_virtual_world.pdf
[62] [SHS09] Scarfone K., Hoffman P., & Souppaya M. (2009). Guide to Enterprise Telework and Remote Access Security.
National Institute of Standards and Technology NIST, Gaithersburg, Retrieved from
http://csrc.nist.gov/publications/nistpubs/800-46-rev1/sp800-46r1.pdf
[63] [SK09a] Sample C., Kelley D. (2009). Cloud computing security: Choosing a VPN type to connect to the cloud.
SearchSecurity, Retrieved July 10, 2009 from
http://searchsecurity.techtarget.com/tip/0,289483,sid14_gci1359127,00.html
[64] [SK09b] Sample C., Kelley D. (2009). Cloud computing security: Routing and DNS security threats. SearchSecurity,
Retrieved from http://searchsecurity.techtarget.com/tip/0,289483,sid14_gci1359155,00.html
[65] [SLW06] Stevens M., Lenstra A., & Weger B. (2006). Target Collisions for MD5 and Colliding X.509 Certificates for
Different Identities. Technische Universiteit, Eindhoven, University of Technology Retrieved from
http://www.win.tue.nl/hashclash/TargetCollidingCertificates/TargetCollidingCertificatesAnnouncementv1.1.pdf
[66] [SNIA07] SNIA (2007). XAM Initiative Overview. Storage Networking Industry Association SNIA, Retrieved from
http://www.snia.org/forums/xam/forums/xam/resources/XAM_Initiative_Overview.pdf
[67] [SNIA08] SNIA (2008). Storage Security Best Current Practices (BCPs) Version 2.1.0. Storage Networking Industry
Association SNIA, Retrieved from http://www.snia.org
[68] [SNIA09] SNIA (2009). Cloud Storage Reference Model Version 0.3. Storage Networking Industry Association SNIA,
Retrieved from http://www.snia.org
[69] [SS07] Scarfone K., & Souppaya M. (2007). User’s Guide to Securing External Devices for Telework and Remote
Access. National Institute of Standards and Technology, Gaithersburg, Retrieved from
http://csrc.nist.gov/publications/nistpubs/800-114/SP800-114.pdf
[70] [SSS07] Scarfone K., Souppaya M., & Sexton M. (2007). Guide to Storage Encryption Technologies for End User
Devices. National Institute of Standards and Technology NIST, Gaithersburg, Retrieved from
http://csrc.nist.gov/publications/nistpubs/800-111/SP800-111.pdf
 P a g e | 54

[71] [THS06] Tixeuil S., Hoarau W., & Silva L. (2006). An Overview of Existing Tools for Fault-Injection and Dependability
Benchmarking in Grids. CoreGRID Technical Report, Retrieved from
http://www.coregrid.net/mambo/images/stories/TechnicalReports/tr-0041.pdf
[72] [TSY09] T System (2009). White Paper Cloud Computing: Alternative sourcing strategy for business ICT.T-Systems
Enterprise Services GmbH, Retrieved from http://download.sczm.t-systems.de/t-
systems.com.mx/es/StaticPage/64/07/80/640780_WhitePaper_Cloud-Computing-ps.
[73] [vau09] vaultscape. Using a Storage Cloud for Archive. vaultscape, Retrieved 10 August, 2009, from
http://www.prnewswire.com/mnr/vaultscape/36941/docs/36941-
Should_you_use_a_storage_cloud_for_your_archive.pdf
[74] [VMW09a] VMWARE. Virtualization Overview. VMWARE WHITE PAPER. VMWARE, Retrieved July 19, 2009 from
http://www.vmware.com/files/elqNow/elqRedir.htm?ref=http://www.vmware.com/pdf/virtualization.pdf
[75] [VMW09b] VMWARE. Understanding Full Virtualization, Paravirtualization, and Hardware Assist. VMWARE WHITE
PAPER. VMWARE, Retrieved July 19, 2009 from www.vmware.com/files/pdf/VMware_paravirtualization.pdf
[76] [VMW09c] VMWARE. Virtualization Basics. VMWARE, Retrieved July 21, 2009 from
http://www.vmware.com/technology/virtual-machine.html
[77] [VRCL09] Vaquero L., Rodero-Merino L., Caceres J., & Lindner M. (2009). A Break in the Clouds: Towards a Cloud
Definition. ACM SIGCOMM Computer Communication Review, Retrieved from http://ccr.sigcomm.org/online/files/p50-
v39n1l-vaqueroA.pdf
[78] [VSM09] VSM News Staff (2009). News Analysis: Virtualization Security at the Forefront. Virtual Strategy Magazine,
Retrieved from http://www.virtual-strategy.com/Press-Releases/News-Analysis-Virtualization-Security-at-the-
Forefront.html
[79] [WWRL09] Wang C., Wang Q., Ren K., & Lou W. (2009) Ensuring Data Storage Security in Cloud Computing. US
National Science Foundation, Retrieved from http://eprint.iacr.org/2009/081.pdf
 P a g e | 55

Appendix A
Draft NIST Working Definition of Cloud Computing
Authors: Peter Mell and Tim Grance
8-21-09

National Institute of Standards and Technology, Information Technology Laboratory

Note 1: Cloud computing is still an evolving paradigm. Its definitions, use cases, underlying
technologies, issues, risks, and benefits will be refined in a spirited debate by the public and
private sectors. These definitions, attributes, and characteristics will evolve and change over
time.

Note 2: The cloud computing industry represents a large ecosystem of many models, vendors,
and market niches. This definition attempts to encompass all of the various cloud approaches.
Definition of Cloud Computing:
Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of
configurable computing resources (e.g., networks, servers, storage, applications, and services) that
can be rapidly provisioned and released with minimal management effort or service provider
interaction. This cloud model promotes availability and is composed of five essential characteristics,
three service models, and four deployment models.

Essential Characteristics:

On-demand self-service. A consumer can unilaterally provision computing capabilities, such

as server time and network storage, as needed automatically without requiring
human interaction with each service’s provider.

Broad network access. Capabilities are available over the network and accessed through
standard mechanisms that promote use by heterogeneous thin or thick client
platforms (e.g., mobile phones, laptops, and PDAs).

Resource pooling. The provider’s computing resources are pooled to serve multiple
consumers using a multi-tenant model, with different physical and virtual resources
dynamically assigned and reassigned according to consumer demand. There is a
sense of location independence in that the customer generally has no control or
knowledge over the exact location of the provided resources but may be able to
specify location at a higher level of abstraction (e.g., country, state, or datacenter).
Examples of resources include storage, processing, memory, network bandwidth,
and virtual machines.

Rapid elasticity. Capabilities can be rapidly and elastically provisioned, in some cases
automatically, to quickly scale out and rapidly released to quickly scale in. To the
consumer, the capabilities available for provisioning often appear to be unlimited
and can be purchased in any quantity at any time.
 P a g e | 56

Measured Service. Cloud systems automatically control and optimize resource use by
leveraging a metering capability at some level of abstraction appropriate to the type
of service (e.g., storage, processing, bandwidth, and active user accounts). Resource
usage can be monitored, controlled, and reported providing transparency for both
the provider and consumer of the utilized service.

Service Models:

Cloud Software as a Service (SaaS). The capability provided to the consumer is to use the
provider’s applications running on a cloud infrastructure. The applications are
accessible from various client devices through a thin client interface such as a web
browser (e.g., web-based email). The consumer does not manage or control the
underlying cloud infrastructure including network, servers, operating systems,
storage, or even individual application capabilities, with the possible exception of
limited user-specific application configuration settings.

Cloud Platform as a Service (PaaS). The capability provided to the consumer is to deploy
onto the cloud infrastructure consumer-created or acquired applications created
using programming languages and tools supported by the provider. The consumer
does not manage or control the underlying cloud infrastructure including network,
servers, operating systems, or storage, but has control over the deployed
applications and possibly application hosting environment configurations.

Cloud Infrastructure as a Service (IaaS). The capability provided to the consumer is to

provision processing, storage, networks, and other fundamental computing
resources where the consumer is able to deploy and run arbitrary software, which
can include operating systems and applications. The consumer does not manage or
control the underlying cloud infrastructure but has control over operating systems,
storage, deployed applications, and possibly limited control of select networking
components (e.g., host firewalls).

Deployment Models:

Private cloud. The cloud infrastructure is operated solely for an organization. It may be
managed by the organization or a third party and may exist on premise or off
premise.

Community cloud. The cloud infrastructure is shared by several organizations and supports a
specific community that has shared concerns (e.g., mission, security requirements,
policy, and compliance considerations). It may be managed by the organizations or a
third party and may exist on premise or off premise.

Public cloud. The cloud infrastructure is made available to the general public or a large
industry group and is owned by an organization selling cloud services.

Hybrid cloud. The cloud infrastructure is a composition of two or more clouds (private,
community, or public) that remain unique entities but are bound together by
 P a g e | 57

standardized or proprietary technology that enables data and application portability

(e.g., cloud bursting for load-balancing between clouds).

Note: Cloud software takes full advantage of the cloud paradigm by being service oriented with a
focus on statelessness, low coupling, modularity, and semantic interoperability.