International Conference on Recent Innovations in Engineering & Technology, ISBN : 978-93-83060-46-7,19-20 April 2014, GITA, BBSR

103


A Survey of Cloud Computing Security:
A Brief Study


Vikas Singh
Dept. of CSE, GITA , Bhubaneswar, Odisha, India
E-mail : Vikas.singh22@gmail.com


Abstract Cloud computing is a flexible, cost-effective, and
proven delivery platform for providing business or consumer
IT services over the Internet. However, cloud Computing
presents an added level of risk because essential services are
often outsourced to a third party, which makes it harder to
maintain data security and privacy, support data and service
availability, and demonstrate compliance. Cloud Computing
leverages many technologies (SOA, virtualization, Web 2.0); it
also inherits their security issues, which we discuss here,
identifying the main vulnerabilities in this kind of systems and
the most important threats found in the literature related to
Cloud Computing and its environment as well as to identify
and relate vulnerabilities and threats with possible solutions.
Keywords Cloud computing; Security; SPI model;
Vulnerabilities; Threats; cornerstone; side channel;
virtualization.
I. INTRODUCTION
Nowadays cloud computing has become a growing
interest for organizations looking to reduce their IT
costs by offloading infrastructure and software costs
onto 3rd party organizations who offer software-as-a-
service (SaaS) (e.g. Google Apps [3]), platform-as-a-
service (PaaS) (e.g. Google App Engine[2]), and
infrastructure-as-a-service (IaaS) (e.g. Amazon EC2
[1]). However, due to the relative infancy of cloud based
computing services, there exists uncertainty about the
level of information security offered by these services.
IaaS cloud services are largely reliant on virtualization
technology, which is seen as providing all the security
and process isolation a customer might want. While
virtualization offers some potential security, there are
drawbacks and complexities of which cloud providers
and customers should be aware. This paper will
summarize and critique a selection of recent literature in
the area of cloud security, with a specific focus on
virtualization security. Literature pertaining to the
benefits and drawbacks of virtualization in a cloud
context will be examined in Section II. Section III will
look at side-channel information leaks which are
particularly critical in a virtualized cloud environment.
Issues pertaining to security auditing and cloud
management will be examined in Section IV. Section V
will conclude this paper.
II. VIRTUALIZATION
Virtualization is a cornerstone of IaaS cloud
computing. Only by virtualizing numerous machines
onto a single piece of hardware, is a cloud service
provider able to achieve the degree of utilization that
makes cloud computing a profitable endeavour.
However, virtualization is also billed as a powerful
security apparatus when, in reality the very flexibility
offered by virtualization can create security concerns.
Garfinkel and Rosenblum provide a broad, if brief,
overview of some of these security concerns [8]. The
key issues the authors examine include scaling,
diversity, transience, software lifecycle, data lifetime,
mobility and identity. Scaling and diversity are
problematic because the ease with which virtualization
enables the creation of new VMs can lead to an
explosive growth in the number of different VMs within
an organization. This problem is compounded by the
fact that VMs can regularly appear and disappear from
an organizations network or become dormant for an
extended period of time. The authors point out that this
creates two problems: patch management becomes
difficult in such an environment, both due to the volume
of VMs to be patched and the length of time it might
take to patch a long-dormant machine. Additionally,
numerous dormant VMs can make it difficult to
completely eliminate worms or viruses from a
virtualized cloud environment, as a dormant infected
VM can re-emerge and cause new outbreaks of a piece
of malware. Furthermore, the ability to roll-back a VM
to an earlier version runs the risk of un-patching a
previously patched security hole (software-lifecycle) or
A Survey of Cloud Computing Security: A Brief Study

International Conference on Recent Innovations in Engineering & Technology, ISBN : 978-93-83060-46-7,19-20 April 2014, GITA, BBSR
104

even un-deleting sensitive data such as personal
information or cryptographic keys (data lifetime). The
mobility of VMs is problematic because if a physical
machine is compromised then any VM on that machine
may potentially be compromised. This means that the
user of a VM has to consider the security of every
machine that previously played host to their VM.
Finally, the authors suggest that it can be difficult to
identify ownership of a VM when common identifiers
such as MAC addresses are selected arbitrarily by
VMMs. While the authors make valid points about the
security issues with virtualized environments, they seem
to skim over the fact that these issues have existed for
decades in non-virtualized environments. Additionally,
in a cloud context some of these virtualization issues can
be resolved with relative ease. Cloud offerings such as
Amazons EC2 offer a specific set of VM images which
can be deployed, and these images are tied directly to
user accounts. This effectively eliminates issues with
VM diversity and establishes clear VM ownership. If a
cloud provider allows any customer VM to be executed
within its VMM this presents a security concern and
more aggressive VM isolation may be necessary.
Perhaps by using virtual LANs a provider can achieve a
measure of network isolation between co-located VMs.
Issues with rollback and data lifetime are more subtle. A
cloud provider could potentially provide a VMM and
corresponding infrastructure that is logically separated
from the rest of their cloud environment. VMs which are
rolled back, or have not been adequately patched would
be required to run in this environment. Only by patching
their VM would a client be able to execute their VM
outside of the isolated environment. Such a strategy
could be improved by having the cloud provider identify
the specific versions of software running on a clients
VM, and compare this information to a database of
known vulnerabilities. This way, the service provider
could potentially quantify the risks associated with
executing a clients VM. Such version information
might be gathered using virtual machine introspection or
using a system service that is installed on all of the VM
images provided by the service provider.
A strategy for VM image management is offered by
Wei et al [11]. Here, the authors re-iterate many of the
risks first pointed out by Garfinkel and Rosenblum.
They also point out that the ability to share VMs
between individuals is critical to a cloud environment
and this sharing needs to be accurately characterized and
recorded. To that end they outline the design for a VM
image management system called Mirage. Central to
Mirage is the idea that images should be treated much
like files in a document management system. Images
can be checked in and out by users, any new images
derived from an image will be linked together. In this
way history of an image can be tracked as it is changed
and run by different users. The second key feature of
Mirage is the concept of filters, which when applied to
an image would replace any sensitive textual data with
random data. For the purpose of security, this feature is
limited to a simple textual find and replace. Finally,
Mirage would be responsible for maintaining images by
patching and performing malware scans on the image
repository. In order to overcome performance penalties
(both in space and time), Mirage only stores differences
between VM images therefore a given VM image is
composed of an original image, plus all of the changes
that were applied to that image over time. This reduces
the cost of image maintenance.
The most obvious problem with the Mirage system
is the authors claim that filters should be based on
simply replacing text, and not the result of executing
code as this is beneficial for security. However,
automatic text replacement in an image still presents a
serious security concern in the way of a code injection
attack. Having a VM author intentionally apply a
malicious filter to their VM may seem silly. However,
many individuals (even those with significant computer
experience) regularly install software on their computers
unintentionally (i.e. malware, bloat ware, etc.), so it may
not be difficult to imagine a VM owner unknowingly
applying a malicious filter to their VM image. This is
especially true if the cloud provider maintains a
repository of community authored filters. Such an attack
could be made even more subtle if the code injection
was spread over numerous filters, such that no single
filter was apparently malicious, but several filters when
applied to a single VM image result in a code injection.
One apparent way to prevent such an exploit would be
to only allow the cloud service provider or the VM
owner to author filters used on the owners VM image.
However, in an age when community contributions to
software systems are increasingly common place, such a
restrictive authorship scheme might seem restrictive to
cloud customers. Finally, the authors did not address the
problem of patching VM images stored in a repository
based on image differences. Vulnerabilities could be
spread across numerous deltas of a single VM image,
the process of figuring out which deltas to change, and
changing them without disrupting normal VM operation
is not a trivial problem.
Christodorescu et al. take a more sober view of
virtualization as a security mechanism [7]. They
describe a threat model which is much more challenging
than those provided by the previous authors.
Specifically, they assume that customers can run any
VM on a cloud VMM and that the cloud provider has no
a priori knowledge about the software (OS,
applications, malware, etc.) running on the guest VM.
A Survey of Cloud Computing Security: A Brief Study

International Conference on Recent Innovations in Engineering & Technology, ISBN : 978-93-83060-46-7,19-20 April 2014, GITA, BBSR
105

To cope with this model the authors offer a novel
technique for virtual machine introspection. By
examining the location of a VMs interrupt descriptor
table (IDT), they can identify the version of operating
system being used. Then, using a body of known secure
code (white-list) for the operating system, they work
outwards from the IDT and validate linked code (system
calls, kernel modules, etc.) against the white-list. Code
that is validated becomes trusted and provides a new
starting point from which to expand the search for
malicious code.
A practical problem with the authors VMI
approach is that it only allows for introspection on VMs
whose OSes are in the set of white-listed code. Given
both the number of available operating systems and the
frequency with which they change (especially the
varieties of Linux) maintaining an up-to-date and
comprehensive white-list would be a challenging task.
More importantly, the elephant in the room, as it
pertains to VM security in the cloud, is the assumption
that the VMM is fundamentally secure. The authors
threat model explicitly assumes that the VMM is
correct, trusted and cannot be breached, the model
goes even further assuming that the cloud environment
contains VMs which cannot be breached. These are
rather dangerous assumptions. If a VMM is
compromised, this in effect, would invalidate the
pretence of security for each client VM running on the
compromised VMM. Given that virtually all operating
systems are susceptible to malicious exploit, it would be
naive to assume that a piece of software as complex as a
VMM is vulnerability-free. If a VMM is running on top
of a traditional OS, this only compounds the security
risk as it means that both the OS and the VMM might be
exploited. If the VMM is the lowest level of software,
it means that the VMM itself must take on the role of
self-monitoring. This is an uncertain prospect at best, as
any sort of self-monitoring mechanism (e.g. anti-virus,
anti-rootkit, etc.) could be subverted in much the same
way as the more pernicious varieties of malware used to
target traditional operating systems.
III. SIDE-CHANNEL INFORMATION LEAKAGE
The co-location of multiple VMs on a single piece
of hardware presents malicious VM owners with the
opportunity to glean potentially sensitive information
from victim VMs sharing the same hardware resource.
In their paper, Ristenpart et al. studied information
leakage in Amazons EC2 cloud service [10]. They
present an in-depth analysis that showed a variety of
strategies that VM owners might use if they were
interested in engaging in malicious behaviour in a cloud
environment. First, they discuss a technique for mapping
the location of EC2 VM instances. Specifically, they
determine which instance parameters contribute to the
placement of a VM on a specific piece of hardware.
Then, using network mapping tools they show a method
for determining whether two VMs are co-located on the
same hardware. Once the authors were able to determine
co-tenancy with certainty, they discussed both brute-
force and strategic techniques for instantiating a VM on
the same host as a victim VM. Next, they displayed the
ability to use a disk-cache side channel to provide a
means of communication between two VMs.
Essentially, the sender VM allocates a buffer then reads
either the even or odd bytes (to indicate a 1 or a 0) to
prime the cache. At the same time, the receiver also
allocates a buffer then waits to be pre-empted by the
VMM in favour of the sender. After control is regained,
the receiver measures the time it takes to access all the
even addresses and odd addresses in the cache, and is
able to discern if the sender has sent a 1 or a 0. In this
way two supposedly independent VMs are able to
communicate in spite of the supposed VM isolation.
They conclude with techniques for using side channels
for estimating web-traffic on victim VMs and
performing keystroke timing attacks (though the latter
was not performed on EC2).
The authors work provides a compelling insight
into the kinds of knowledge a malicious user can glean
from operating a VM within Amazons EC2 service.
They do however stop short of demonstrating the ability
to actually steal useful information from a victim VM in
this environment. This is surely due to the illegality of
such actions, and the restrictive Amazon terms-of-
service agreement. The authors opted not to point out
that their technique for instantiating a malicious VM on
the same hardware as a victim VM is phenomenally
challenging if the victim VM is an individual machine
with high up-time. Their claims of 40% successful
placement only hold if the attacker can instantiate their
VM within a couple of days of the targets instantiation.
This may seem like a generous time window, and it may
even be possible to force re-instantiation of a target VM
through a distributed denial-of-service attack on the
target machine. But if a single long running VM is being
targeted, co-location becomes much more difficult. The
authors claimed 8.4% successful co-placement via
brute-force when no knowledge of the victims
instantiation time was available. However, in this case
the authors used a victim pool of over 1500 target VMs,
so its no surprise that they were able to co-locate with
some of these targets. If the target pool consists of a
single VM, it may be nearly impossible to achieve co-
location. Two major issues with the authors side-
channel attack are that the victim needs to actively
listen to the channel to achieve communication, and that
A Survey of Cloud Computing Security: A Brief Study

International Conference on Recent Innovations in Engineering & Technology, ISBN : 978-93-83060-46-7,19-20 April 2014, GITA, BBSR
106

the attack becomes less feasible as the other co-resident
VMs become more active. With potentially 6 other
machines (besides the target and attacker), the disk-
cache side-channel can become extremely noisy.
Finally, the authors technique for estimating web-
traffic was based on an experiment which involved the
downloading of a 3Mb text-file, for the purposes of
increasing server load. Even in the age of rich web-
applications, a 3Mb webpage still seems infeasible. To
this end, the authors give no indication as to whether
their attack would even work on a realistic sized
webpage. Aviram et al. offer a technique for potentially
combating side-channel information leaks [5]. Because
CPU timers provide a reference clock, it can tell a
malicious VM owner when their VM has been pre-
empted (possibly by the target VM), thus indicating to
the attacker that they should attempt to read a side-
channel such as the disk-cache discussed earlier. The
authors suggest a cloud computing environment devoid
of high-resolution clocks and other timing indicators
which would aid in such side-channel attacks. This is
done by essentially providing customers with a
deterministic compute-cloud gateway. In this way, users
could only supply deterministic inputs to the gateway,
and all timing information is inaccessible to client VMs;
be they honest or malicious.
The authors technique, while interesting as an
academic exercise seems to conflict with customers
expectations regarding IaaS. Customers purchase cloud
infrastructure services with the expectation that they will
offer the same functionality as a customer hosted
solution, but at a reduced cost. However, providing what
is essentially an API to a compute cloud drastically
reduces the capabilities of the cloud service. While it is
clear that in addition to eliminating timing channels, this
tactic also reduces the attack surface of a compute
cloud. It is therefore, extremely unlikely that customers
will go opt to go through the trouble of ensuring that
their applications will work with a deterministic
gateway. It is also likely that some types of applications
would simply not be possible in a deterministic
environment, such as stochastic simulations and other
applications where high-resolution timing is necessary.
Overall, the authors technique seems much more
conducive to a PaaS or SaaS environment, as opposed to
the IaaS environment they have described. Ultimately, if
side-channel attacks are a serious point of concern for
prospective cloud customers, it might be preferable for
customers to pay the cloud provider to ensure that none
of the customers VMs reside on the same hardware as
other customers. This completely eliminates the risk of
side-channel attacks in a virtualized cloud environment.

IV. SECURITY MANAGEMENT
Because a cloud based virtual environment is a
remotely hosted service, there may be a tendency among
users to fall victim to complacency or ignorance,
believing that the cloud provider will responsibly
manage active virtual machines. In reality, customers
must competently administrate their VMs to prevent
attacks, just as they would in a non-virtualized
environment. Bleikertz et al. offer a method for
performing security audits in Amazons EC2 service [6]
which may aid cloud customers in mitigating some
security risks. The authors technique rests on their
ability to automatically assess potential routes of attack
for VMs by assigning VMs to security groups. In EC2 a
security group can contain multiple VMs, and
administrators can then filter incoming network traffic
that is sent to VMs in a particular security group by
applying firewall-like rules to the group in question.
Using the EC2 API the authors are able to automatically
query the security rules applied to those groups for a
collection of VMs and construct reachability graphs for
the VMs in question. This tells the administrator which
VMs are connected by which ports. The authors then
extend the reachability graphs by scanning the
applications running on the VMs for vulnerabilities then
applying a rating of low, medium, or high to the edges
connecting the VMs in the reachability graph. This
allows administrators to quickly locate high-risk
avenues of attack within their collection of cloud-based
VMs.
The technique suggested by the authors is billed as
providing security audits for cloud-based virtual
infrastructures. However, in reality, the approach
suggested by the authors could also be applied to non-
virtualized resources. The only difference is that EC2
provides an API and a grouping mechanism that allows
for the easy export of the raw data necessary for
automatic generation of reachability and attack graphs.
Such graphs could be created in a non-cloud
environment though it would likely not be as easy to
implement as it would require parsing through firewall
rules on servers and routers. One of the key flaws of the
authors work is their reliance on an automated
vulnerability scanner (Nessus [2]), to identify high risk
applications running on VMs. Vulnerability scanners are
fine tools, but comprise only one part of a penetration
testers arsenal. By relying on a single automated
vulnerability scanner in order to measure the potential
risk to a VM, the authors run the risk of easily
overlooking high-risk attack paths in a set of
interconnected VMs. This ultimately means that the
authors attack graphs are only as reliable as the scanner

A Survey of Cloud Computing Security: A Brief Study

International Conference on Recent Innovations in Engineering & Technology, ISBN : 978-93-83060-46-7,19-20 April 2014, GITA, BBSR
107

upon which it is based. As a result, the authors security
auditing technique should be used only with the
understanding that it offers a single limited view of the
security vulnerabilities of virtualized servers in a cloud
environment.
Due to the remote nature of cloud services, the
ability of a customer to respond to security incidents in
their cloud software or VMs is significantly curtailed, if
not completely eliminated. Grobauer and Schreck
provide a broad yet insightful look at the difficulties
faced by cloud customers attempting to respond to
security incidents [9]. The authors examine in detail, the
four phases of incident handling (IH): preparation,
detection, analysis, containment eradication and
recovery. In each of these phases they discuss the
difficulties forced upon cloud customers, which
primarily stem from the lack of knowledge and
administrative control of the cloud infrastructure. They
then offer potential solutions to the perceived challenge.
For example, detection is difficult in a cloud
environment because customers have no knowledge of
what vulnerabilities may exist at the hardware (network
/ host) and virtualization layers. Additionally, customers
would not have access to event monitoring of this
infrastructure which is necessary for the identification of
potentially malicious attacks. Analysis is challenging
because proper analysis requires access to system logs
which very likely contain private information belonging
to all the customers who shared the same host during the
attack. The authors do point out that virtualization does
offer some benefits when it comes to IH. Specifically,
the ability to pause a VM and take snapshots offers
excellent mechanisms for attack containment and post-
attack forensic analysis.
One of the other excellent contributions by the
paper is the authors examination of how IH differs
depending on the cloud services being offered. They
point out that IH is easiest in IaaS environments,
because in this case, the customer has the greatest
control over their virtualized machine. However, despite
this, IH still suffers from many of the pitfalls mentioned
earlier. In PaaS and SaaS environments, the customer is
even more at the mercy of the cloud service provider.
Interestingly, the authors discussed the problems
surrounding SaaS as though they were new. However,
cloud-based software services such as Yahoo Mail and
Google Apps have been around for nearly a decade. The
key element that has changed is that for the first time,
commercial enterprises are now paying for these
services. So, while the handling of security incidents
may still be challenging, it is the responsibility of these
paying customers to ensure that their service contracts
fully stipulate the division of responsibilities and service
expectations in the event of a security breach.
V. CONCLUSION
This paper has provided a summary and analysis of
some of the current literature in the area of cloud
security. Still in its infancy, cloud computing has yet to
address many of the security concerns which may be
blocking the more wide spread adoption of this
technology. The flexibility of virtual machines running
on a cloud service, presents a variety of security
concerns. However, by only allowing service-provider
VMs and enforcing rigorous management of VM
images, many of these challenges can be overcome.
However, the handling of security incidents in the cloud
seems much more challenging as desires of the
customers investigating a security breach run contrary to
the privacy interests of the cloud service provider.
While side-channel attacks present an interesting
avenue for attack, the enormous challenge of using a
side-channel to steal relevant data in a noisy production
cloud seems like a poor investment of an attackers
time. This is especially true in light of the difficulties
involved in targeting a single VM. Rather, one of the
largest potential security risks in the cloud is the
assumed layer of security provided by the virtual
machine manager or hypervisor. It is virtually certain
that as more companies move to the cloud, attackers will
begin to focus more of their efforts there. When this
happens, the underlying VMMs and hypervisors will
surely provide a target too tempting to ignore.
VI. REFERENCES
[1] Amazon EC2, http://aws.amazon.com/ec2/
[2] Google App Engine,
http://code.google.com/appengine/
[3] Google Apps, http://docs.google.com/
[4] Nessus, http://www.nessus.org/
[5] Aviram, A., Hu, S., Ford, B., and Gummadi, R. 2010.
Determining Timing Channels in Compute Clouds. In
Proceedings of the 2010 ACM workshop on Cloud
computing security workshop (CCSW '10).
[6] Bleikertz, S., Schunter, M., Probst, C.W., Pendarakis,
D., and Eriksson, K. 2010. Security audits of multi-tier
virtual infrastructures in public infrastructure clouds.
In Proceedings of the 2010 ACM workshop on Cloud
computing security workshop (CCSW '10).
[7] Christodorescu, M., Sailer, R., Schales, D.L.,
Sgandurra, D., and Zamboni, D. 2009. Cloud security
is not (just) virtualization security: a short paper. In
Proceedings of the 2009 ACM workshop on Cloud
computing security (CCSW '09).
[8] Garfinkel, T., and Rosenblum, M. 2005. When virtual
is harder than real: Security challenges in virtual
A Survey of Cloud Computing Security: A Brief Study

International Conference on Recent Innovations in Engineering & Technology, ISBN : 978-93-83060-46-7,19-20 April 2014, GITA, BBSR
108

machine based computing environments. In
Proceedings of the 10th HotOS.
[9] Grobauer, B., and Schreck, T. 2010. Towards incident
handling in the cloud: challenges and approaches. In
Proceedings of the 2010 ACM workshop on Cloud
computing security workshop (CCSW 10).
[10] Ristenpart, T., Tromer, E., Shacham, H., and Savage,
S. 2009. Hey, you, get off of my cloud: exploring
information leakage in third-party compute clouds. In
Proceedings of the 16th ACM conference on Computer
and communications security (CCS '09).
[11] Wei, J., Zhang, X., Ammons, G., Bala, V., and Ning P.
Managing security of virtual machine images in a
cloud environment. 2009. In Proceedings of the 2009
ACM workshop on Cloud computing security (CCSW
'09).