Cloud Security

Barry Denby
Griffith College Dublin

January 17, 2019

Cloud Security
I All computing systems must be secured from
attack. Threats fall into a few broad categories
I Malware: Code designed to break into a system
and either destroy or control systems or
information in one of two means
I Email attachment: someone runs the attachment
and malware spreads
I Buffer overflow/SQL injection etc: take advantage
of software bugs to gain access (does not need user
intervention)
I Rogue insider: Person working in the facility
containing the computation devices who has
malicious intent and physical access to the
system
Cloud Security

I In this particular lecture we will discuss how the

traditional risks of computing apply to the
cloud
I We will also discuss new risks and threats that
are associated with the cloud
I Particularly in relation to its public nature and
virtualisation
I As before most of this material is based on
Cloud Computing: Theory and Practice
Security: Target rich environment

I The cloud is a target rich environment (i.e.

many targets for someone to attack)
I This is because there are many applications
running on a cloud
I And will also have a large number of users
associated with them
I Users may also have information/logins on one
or more applications
Security: Target rich environment

I This is a draw for malicious activity and

criminal organisations
I For example if there are 1,000 on a cloud and
99% are secure then that means at least 10
can be exploited
I 10,000 means 100
I 100,000 means 1,000 etc
Security: Threats that are the same

I Some threats carry over from other network

centric environments so any threats from these
categories also apply in cloud
I As cloud is built on these categories
I Network-centric computing
I Network-centric content
I Service Oriented Architectures
I Grids and Distributed systems
I Web based services
Security: Reasons for moving to the cloud

I The main motivation for moving to the cloud

was the reduction in technical concerns
I This is true but for the security the exact
opposite is true as the concerns are greater
I As infrastructure is now shared with many
others
I And there is no guarantee that the cloud
provider will implement security for you
Security: Threat classes
I Traditional security threats
I Standard threats that would appear in a traditional
non-cloud computing environment
I All infrastructure must be protected from attack
from outsiders
I If infrastructure can be broken into the cloud is
vulnerable to attack
I Authentication: everyone who has access to the
cloud application should be given the smallest
privilege set necessary for their task
I Attack vectors in non-cloud applications also apply:
DDoS attacks, phising, SQL injection, cross-site
scripting, buffer overflow etc
Security: Threat classes

I System availability threats: standard threats

that would be encountered in a datacentre
I Power outages, Fire, Flooding, Malicious
destruction etc
I When such an event occurs a user can be faced
with data lock-in, wherein the data is not
accessible and be consequence the cloud
application fails to function
I Detrimental to large enterprise applications
Security: Threat classes

I Third party control threats where there are

concerns about data storage from outsiders
I Arises from lack of transparency and the
limited control a user has over where the data
is stored in the cloud
I For example a cloud provider may outsource
some of their data storage to other providers
I May not be specified by the cloud provider
I Difficult to determine who they are and a level of
trust
Security: Threat classes
I Espionage is also an issue in that there may be
malicious employees in the cloud provider who
could access or destroy your application data or
sell it onto other companies
I Difficult for a user to prove a provider has
accessed/modified data without consent
I Abuse of the Cloud: using the cloud for
malicious purposes
I Building many VMs and coordinating them to
cause a DDoS attack
I Using VMs to distribute spam
I Using VMs to distribute or control malware
Security: Threat classes

I Shared technologies, threats due to

multi-tenancy
I VMMs if not secured properly can be accessed
and controlled by a VM
I This will directly affect the security of all other
VMs managed by the VMM
I Can also lead to the installation of VMBRs
Security: Threat classes

I Insecure APIs: where a cloud provider has

produced an API that may be exploited by
attackers
I The API should protect applications and users
from attack at all times
I Bugs in the API could expose routes to
privilege escalation and application control
I Malicious insiders cloud also build backdoors
into the API to give them full access to an
application through a hidden API/function call
Security: Threat classes
I Data loss and leakage: if the cloud provider
does not replicate data properly or prevents
unauthorised access
I Difficult to have a full copy of data outside of
cloud if datasets are large
I Ensuring consistency is another issue should be
other copies of data available
I If the cloud provider maintains one copy of
data and should replication fail as well as
hardware then all data is lost
I By consequence the application completely fails as
there is no data to work with
Security: Threat classes

I Value of data >>> Value of an application

I Data loss can be irreparable
I Data leakage may occur as a result of malicious
cloud insiders observing and copying data
I Or if an application or the API it is built on is
coded in an insecure way
Security: Threat classes

I Account/Service hijacking: significant threat

all web facing services must account for
I There are many methods of stealing credentials
and they must be guarded against in a cloud
application
I Bad passwords are one of the most common forms
of account hijacking
I Unknown risk profile: Where the developer has
been exposed to ignorance to the risks cloud
computing poses to their applications
Security: Attack vectors

I There are three actors that are present in the

cloud computing environment
I User: The end user who is interacting with the
application
I Service: The application the developer has
produced to run on the cloud and serve users
I Cloud infrastructure: the supporting machines
upon which the application runs
I The interaction between all these components
will be illustrated on the following slide
Security: Attack vectors
Security: Attack vectors

I As can be seen from the diagram there are six

potential vectors of attack in a cloud system
I All attack vectors must be secured against in a
cloud application
I You have zero idea where or when the next
attack will come
Security: Other concerns
I There are other concerns that must be taken
care of which affect the attack vectors seen
previously
I No system is completely secure
I Given enough time and resources any system
can be broken into
I You need to ensure that the cost to the
attacker to break into your system is far in
excess of the potential reward if they break in
I And that there are methods of tracking
intruders if they do break in
Security: Other concerns
I Data is more vulnerable in long term storage
than in transit
I Transit is short bursts of data over communication
links that can be affected by man in the middle
attacks
I Storage can be attacked for longer periods of time
and will require stronger security
I Both must be secured against
I Usually a method of encryption is used
I Life cycle of data
I In a cloud there is no guarantee as to when deleted
data will be rendered unusable and deleted.
I This poses a risk should the data not be destroyed
for a period of time it may be accessible to others
I Data may not be erased from backups thus there is
still potential for access
Security: Other concerns
I Processing
I Your application may be threatened by malicious
VMs or VMBRs
I It is also possible that employees of the cloud
provider can interfere with the processing of your
application.
I Standardisation: there is no standarisation
among cloud vendors
I Standarisation usually leads to increased
competition thus accelerating development and
security of APIs and platforms.
I Vendor lock in can expose you to bugs that are not
fixed or addressed by the provider
Security: Other concerns

I Auditing: Most systems need to know exactly

I Who accessed the system
I How and where they did it
I What actions they took
I When they happened
I This is necessary for determining attack origins
I Requires extensive reliable logging facilities
I Currently very difficult to do reliably in the
cloud
Security: Other concerns

I Multi-tenancy: A core reason for cost reduction

in the cloud
I Also a security concern particularly in SaaS
applications
I If one user of the service is broken into
potentially all users are exposed
I A nightmare if sensitive data is involved.
I Malicious tenant can try to interfere with your
processing
Security: Other concerns
I Legal frameworks: these don’t tend to evolve
as rapidly as technology
I May be difficult for users to defend their rights
with cloud technologies
I Large cloud vendors have sites in multiple
countries
I In cases like this it’s hard to determine which laws
should apply
I Particularly if a single action involves two or more
countries
I Outsourcing
I It may be possible that a cloud provider uses
another provider to enable some functionality
I Who’s liable if the functionality fails?
I Who’s responsible for implementing security?
Security: Privacy

I Privacy ensures that an individual, group, or

organisation has the right to prevent personal
information from being disclosed to others
I Major concern in any cloud system or web
facing system
I Privacy is also limited by law for reasonable
things like taxation and freedom of speech
I Socail networks and voluntary information
sharing has lead to information stockpiles that
when stolen can lead to identity theft
Security: Privacy
I The main privacy concerns with the cloud are
the following
I Lack of user control: Once data is submitted to
the provider the user loses control of the data
I No idea of location
I Could lose access to the data
I Data could be stored indefinitely on backup
I Unauthorised secondary use
I The provider may sell your data to other providers
to make alternate streams of revenue
I Users have no control over how and when this is
performed
I Often no idea as to what data is given or to whom
Security: Privacy

I Dynamic provisioning: Privacy concerns due to

outsourcing of data by the provider
I What data does the outsourced provider see?
I Are they secure and trustworthy?
Security: Virtual Machines

I Security issues and solutions arising from VM

use in the cloud
I VMs and VMMs are potential targets of
attacks in the cloud
I These are things that must be secured against
Security: VMM based threats
I Starvation of resources and denial of service
I badly configured resource limits
I rogue VM with capability of bypassing resource
limits
I VM side channel attacks: Malicious attack on
VMs by a rogue VM on the same VMM
I Lack of proper isolation of inter-VM traffic
I Limitation of packet inspection devices to handle
high speed traffic
I VM instances built from insecure VM images
I Buffer overflow attacks or other bugs in the
VMM
Security: VM based threats

I Deployment of rogue or insecure VMs

I Unauthorised users may start insecure instances or
perform admin actions on VMs
I Improper configuration of access controls on VM
administrative tasks
I Presence of insecure and tampers VM images
in repository
I Lack of access control to the VM image repository
I Lack of mechanisms to verify the integrity of the
images