Zimory White Paper: Security in the Cloud pt 2/2

SECURITY IN
THE CLOUD
Part 2 – Threats and Solutions
White Paper, November 2012

SECURTY IN THE CLOUD – Part 2
Copyright© 2013, Zimory GmbH 1
TABLE OF CONTENTS
Executive Summary................................................................................... 2
Introduction and Problem Description........................................................ 2
Cloud Security: Conventional Options ....................................................... 3
Perimeter Security.......................................................................................................... 3
Resource Isolation ......................................................................................................... 4
VM Access ..................................................................................................................... 4
From secure physical to secure virtual networks........................................................... 4
Dangers and Differences ........................................................................... 5
Threat 1: Management Consoles................................................................................... 5
Threat 2: Multi-Tenancy of Managed Hosting Services................................................. 5
Multi-Layered Security as a Solution......................................................... 6
Compensation................................................................................................................ 6
Cost Savings.................................................................................................................. 7
Architecture Flexibility: A threat and/or a Solution?...................................................... 7
Threat........................................................................................................................ 7
Solution: Ability to Meet Security Requirements on Each Level............................... 8
Zimory Multilayered Security Approach ......................................................................... 8
Standards and compliance in the Cloud ................................................... 9
Conclusion ............................................................................................... 10
Contact Information.................................................................................. 11

EXECUTIVE SUMMARY
Once in the Cloud, various assumptions come to mind regarding security matters. For
example, most system and network administrators decide to approach virtual network
and virtual machine (VM) security the way they do their physical counterparts; applying
similar security paradigms.
Security architectures designed for physical networks often fail to provide the required
levels of security in the virtual world. Perimeter-based security alone is insufficient in a
virtualized infrastructure partially because of virtual machines – which are sometimes,
quite literally, moving targets. Dynamic networks, remote access requirements, and host
machines to be carefully locked down, are some of the security concerns to be found in
Cloud environments. With a little thought and imagination, however, securing your virtual
infrastructure is possible provided you are willing to take a closer look.
The following document intends to analyze challenges regarding security in a virtualized
environment, especially comparing implications of both physical and virtual environments.
Security challenges of the Cloud environment are listed and analyzed, to finalize with
possible solutions to face and resolve these challenges.
INTRODUCTION AND
PROBLEM DESCRIPTION
To paraphrase a popular aphorism, virtual systems are like physical systems, only more
so. It is probably safe to assume that most system and network administrators approach
virtual network and virtual machine security the way they do their physical counterparts;
applying similar security paradigms. As a starting point this might appear to make sense.
But only at a first glance. Applying knowledge gained from many years protecting public
and private networks and systems, this is an ultimately misguided approach.
In a standard network structure, physical security devices reside at the network perimeter:
Firewalls, Intrusion Detection Systems (IDSs), Virtual Private Network (VPN) gateways
and Kernel-based Virtual Machine (KVM) gateways. The idea of this structure is to
prevent intruders from entering the network. This security approach, however, does little
once the intruder is through. This leads to conclude that security in a virtualized
environment needs to augment perimeter devices with security at or on certain nodes.
The general resistance to this approach in physical environments is that it can add
latency to communications, increasing, at the same time, complexity in inter-system
communications. A second layer of security, at least at the hypervisor-level, is essential in
a virtual infrastructure. Such a layered approach to security can add greatly to the
protection of systems with a minimal impact on performance.

The peripheral firewall still limits access to the network, but direct access to hypervisors
requires an additional layer of authentication. Complexity is the worst enemy of security,
and a Cloud is nothing if not complex.
CLOUD SECURITY:
CONVENTIONAL OPTIONS
One cannot overstate the danger in a Cloud network topology. The threats are great and
require a fresh, or at least freshened up, approach to security. Virtual infrastructures
should force administrators, network managers and security consultants to rethink threats
and to be creative when preparing and responding to both prevention and detection of
attacks. Protection of the so-called “physical” layer needs to be reassessed and redefined
in a virtual world.
This section intends to analyze conventional options, their threats and implications,
including how far do their security standards go in a virtualized environment:
PERIMETER SECURITY
A standard security practice is to isolate machines physically in secure data racks.
Additionally, they are operationally isolated in network segments and then to restrict
access between sub-networks, for example, perimeter security is applied. Buecker,
Andreas and Paisley define a network security perimeter as the “combination of
automated network tools and the ability to globally enforce host-based security software
deployed to the mobile systems that you know access the network. Scanning and the
discovering of unknown devices also must be considered because by definition, these
unknown entities may constitute a perimeter breach.”1
In such a model, once the defensive controls in place at the perimeter are breached,
attackers are not significantly impeded inside the trusted network. There are at least three
additional considerations to a virtualized, shared resource infrastructure which make
isolation more complicated.
First, while host machines (hypervisors) can be physically isolated, in order to profit from
the separation, some of the advantages of virtualization are sacrificed; for example,
shared storage, high-availability, and reduction in hardware costs. Second, the hypervisor
has been identified as an attack gateway. And finally, to ease the management of virtual
infrastructures, a variety of vendor and third-party applications is available, controlling
private Clouds from a central management console. Since this console controls many
hypervisors, it needs special attention.
1
Buecker, Andreas, Paisley: “Understanding IT Perimeter Security”. IBM Corporation. 2008.

RESOURCE ISOLATION
One of the most significant differences between Cloud and traditional technical
environments is the role of the hypervisor, and by extension, the direct attacks on the
hypervisor. Access to the “physical” layer of a virtual machine occurs via a console of the
host machine and is, effectively, a KVM. Meanwhile, the host machine on which the
hypervisor is running- the actual physical hardware on which VMs and network devices
operate- becomes the family jewel of the virtual system. An attack on one of these
machines would have implications for tens or perhaps hundreds of systems. Having a
single machine compromised in your network is bad enough, but losing a host machine
can be catastrophic, as it controls many tens or even hundreds of virtual machines and
network devices. Even if the machine is not actually hacked, Disruptive Denial of Service
(DDoS) attacks can have serious implications for all guests systems sharing the host
resources.
VM ACCESS
Almost by definition, a public Cloud is running somewhere outside your organization’s
facilities. Even a private Cloud can be housed outside your physical reach. It is important
to protect all data moving in and out of the Cloud environment. Therefore, how you
access your virtual machines probably extends beyond the traditional KVM, VPN or
remote SSH access. Several of the big Cloud vendors offer tools to simplify the
management of your virtual machines based on flavors of Virtual Network Computing
(VNC) originally developed by Olivetti Research Labs.
Access to VMs during boot takes place via a VNC session launched from the host
machine. VNC uses the RFB protocol which sends the encryption key and encrypted
password over to the network, making it vulnerable to sniffers. In addition, some
implementations of VNC limit password length to 8 characters, which can be a significant
security lapse. VNC access essentially acts as a virtual KVM, giving the administrator
access to the machine as it boots. Regardless of the security typology the administrator
has built into the VM OS - firewalls, IDS, tripwire, Bastille, etc. - it is more than
theoretically possible to hack the VM via an insecure back door on the host.
FROM SECURE PHYSICAL TO
SECURE VIRTUAL NETWORKS
Consider a simple example in the transition from secure physical network to secure virtual
and take the case of KVM/VNC. If disabling VNC support is not an option, a relatively
simple answer would be to create a proxy between the external network and the
hypervisor on the internal network. This allows users to connect to a Web-based session
via HTTPS, using the proxy to connect to the VMs via the host and Remote Framebuffer
Protocol (RFB). This topology adds an additional layer of security and eliminates a direct

connection between the host and an external client. It also, isolates the RFB protocol
inside your trusted network between the proxy and the hypervisor.2
DANGERS AND DIFFERENCES
Having analyzed some of the conventional approaches for facing security issues in a
virtualized environment, this section will present the most latent dangers and basic
differences of security in a virtual network.
THREAT 1: MANAGEMENT CONSOLES
The most important and vulnerable components in virtualization topologies: Management
consoles. A common security threat comes from the topology of many virtualized
environments. Often the management console is the target of an attack. The threat is
compounded because several virtualization providers (VMware's vCenter or Citrix's
XenCenter) provide Windows-only management clients. This lack of options forces to put
the following aspects on the balance: Using a single point of management for virtual
infrastructures against the explicit attack danger. If this machine is compromised, the
entire environment is at risk. In mid to large-sized installations this usually means several
hypervisors, thus compounding all of the problems discussed above for host machines.
A hacked management machine will have dramatic consequences to say the least. It is
sometimes said that if your “green” Cloud resides in a data center that used dirty coal or
nuclear power, it was not better described as a “brown” Cloud. What is the color of a
hacked Cloud? Red? Black? Whichever, it is certainly a dark Cloud.
Compromised management consoles or hypervisors with access to many VMs present a
whole other level of aggression. That threat must be anticipated, having evolved in
parallel with virtualization technologies.
THREAT 2: MULTI-TENANCY OF MANAGED
HOSTING SERVICES
A potentially significant and little known consequence of shared resources arises from a
peculiarity of multi-tenant managed hosting services, where hard disk address space is
reused. In some cases, it is possible for a system to read information leftover from a
previous instance. In April 2011, Context published a white paper detailing their tests
against Amazon EC2, Gigenet, Rackspace and VPS.net. The document concludes that
providers who do not delete wipe disks, risk exposing data between different customers.
"You can spin up a new VM, see what’s on the disk and copy it. Then you delete that VM,
2
For more Information, see Guacamole. http://guac-dev.org/

start another, and so on. An attacker could continuously automate the process of
harvesting more and more data, then gather it all and go through it to look for credit card
numbers, personal data or credentials. It’s just like ‘Hoovering’ up the data from the Cloud
Provider and using it to carry out an attack.”3
Clouds deliver scalable services that provide computing power for multiple tenants,
whether those tenants are business groups from the same company or independent
organizations. This translates into shared infrastructure— CPU caches, graphics
processing units (GPUs), disk partitions, memory, and other components—that was never
designed for strong compartmentalization. Even with a virtualization hypervisor to
mediate access between guest operating systems and physical resources, there is
concern about attackers gaining unauthorized access and control of your underlying
platform with software-only isolation mechanisms. Potential compromise of the hypervisor
layer can, in turn, lead to a potential compromise of all the shared physical resources of
the server that it controls, including memory and data and other virtual machines (VMs)
on that server.
Nevertheless and as stated by the European Network and Information Security Agency-
ENISA “it should be considered that attacks on resource isolation mechanisms (eg,.
against hypervisors) are still less numerous and much more difficult for an attacker to put
in practice compared to attacks on traditional OSs.”4
Security risks and threats regarding Cloud Computing are well identified, which also leads
to facilitate how these issues are faced and resolved.
MULTI-LAYERED SECURITY
AS A SOLUTION
Having the situation described above in mind, especially the list of issues in a virtualized
environment, it is possible to present multi-layered security as a solution to face and
solve these security issues. Some of the advantages of implementing this approach are
Compensation, Cost Savings and Architecture Flexibility.
COMPENSATION
A multi-layered approach to security in virtual infrastructures has distinct advantages over
peripheral-only security models. A multi-layered approach allows the system to
3
Search Security: “Information Security: Investigation Reveals Serious Cloud Computing Data Security Flaws”.
Retrieved from: http://searchsecurity.techtarget.co.uk/news/2240148943/Investigation-reveals-serious-Cloud-
computing-data-security-flaws?asrc=EM_USC_17307047. May 2012
4
Catteddu, Daniele and Hogben, Giles: “Cloud Computing Security Risk Assessment”. European Network and
Information Security Agency- ENISA: 2009.

compensate in case one layer is compromised, making more granular security policies
available, depending on locations and protocols.
COST SAVINGS
The expected savings from a Cloud virtualization environment arises from economy of
scale. The ability to roll out many servers as required is a great incentive for cash
strapped IT departments.
ARCHITECTURE FLEXIBILITY:
A THREAT AND/OR A SOLUTION?
Depending on the perspective from which you see this aspect, it can be considered both
a threat and a solution.
Threat
From a security perspective, the same flexible architecture allowing you to create 3000
servers with the click of a button, also allows you to make 3000 mistakes just as fast. A
single security hole can become a nightmare if it is rolled out across an entire PaaS or
SaaS data center.
Many pundits have already called for IT to retire the perimeter-centric approach to
security. The flexibility offered by layered security is especially relevant for virtual
infrastructures.5
5
Honan, Brian: “Layered Security: Protecting your Data in Today’s Threat Landscape” Tripwire.2011

Solution: Ability to Meet Security Requirements on Each Level
The following table presents basic requirements in Cloud environments, applying
multi-layered security approaches.
Security
Requirements
User Access
Control List
(ACL)
Network ACL Encryption Hardening
Layer
Hypervisor X X
Virtual
network
X X X X
Host
system
X X
Virtual
machines
X X
The table above can be used as a good starting point for listing and analyzing
requirements in Cloud environments. The table leads to conclude that wider use of
encrypted disks, Public Key Infrastructure (PKI) interfaces, isolated- VLANs and
host-based firewalls are all options which can significantly increase security in the Cloud.
ZIMORY MULTILAYERED SECURITY APPROACH
Zimory Cloud Suite offers an IaaS management solution that implements a modular
architecture, based on the Service Oriented Architecture (SOA) design patterns6
:
 Database isolation
 No single point of failure, in case for example, of a Denial of Service- DoS attack.
 Enterprise application server, JBoss was the chosen technology to be Zimory’s
Enterprise Application Server.
 Certificates as a guarantee for securing all inter-system communication.
 Layered security
 VNC and SSH proxies
 Clear separation of authentication process from authorization and encryption as a
separate process
 No fixed initialization vectors (IV)
 Widespread use of one-way hash functions for passwords and secure
information.
6
Schneider Bruce: “Cryptography Engineering: Design Principles and Practical Applications”, 2nd Edition. Wiley
Publishing, 2010.

Regarding external security, Zimory presents the following security guarantees:
 Isolated components, realm concepts
 External LDAP to provide authentication and system authorization
 External CMDB
 Gateway component to protect host machines
 Management infrastructure is protected from VMs
Note: use tokens for component communication
Interprocess communication, however, is only as secure as its weakest link. If the key
were on the same network as the data, what would be the point of encrypting it? Access
to the website equals access to the database. Security takes place by good access
control on the website and database, not by encrypting the data.
By combining well-established cryptographic techniques, with proven networking
architectures and secure system administration techniques, Zimory can achieve a secure,
adaptable and extensible enterprise product.
STANDARDS AND COMPLIANCE
IN THE CLOUD
The highly dynamic nature of most Cloud-based applications - which often lack built-in
auditing, encryption and key management controls - makes it expensive and impractical
to apply the Peripheral Component Interconnect (PCI) standard to most Cloud
applications.
Public standards also extend to the area of identity distribution and management.
Authorization and access bring their own set of challenges with the wide-spread adoption
of dynamic hosting - meaning that virtual machines move from physical host to physical
host and that these hosts can be in different data centers or even in different countries.
Controlling access to the same resource as it moves between different physical locations,
regarding fail-over or replication purposes for example, requires a careful design to
determine how user accounts will be synchronized across locations. Moving resources
across national borders, on the other hand, requires compliance with security
requirements that may vary according to country or regional laws. The Cloud security
alliance has the following recommendations when designing identity architectures in the
Cloud.
“Avoid trying to extend an internal directory services into the Cloud service and/or
replicating the organization’s directory services over the Internet (generally very insecure)
or via a back-channel (leased line or VPN) as this exposes an organization’s entire DS
into an environment the organization does not control. Also be wary of the promise of

RSO (Reduced-Sign-On) products as RSO generally works by compromising on-log-in
security internally, more so when trying to extend RSO to a Cloud environment.”7
Threats are multiple and risks can be quite big. Security in the Cloud is and will continue
to be a matter of studying and applying best practices and standards to face and resolve
eventual issues.
CONCLUSION
The complexities of Cloud architectures when defining the authorization/access layer
present some challenges when compared to traditional Identity and Access Management
(IAM) systems. These challenges need to be addressed early in the design process to
avoid security problems at deployment. Evidently, the chosen type of IAM depends on
your business and Cloud model requirements: whether you are deploying IaaS, PaaS or
SaaS, for example.
As systems grow and change to meet new business requirements, the basic security
elements also need to grow and adapt with them. While developers continuously attempt
attempted to anticipate future uses for the system, even product developers can be
unable to imagine all the possible configurations required by customers.
Therefore, the Zimory Cloud Suite attempts to adopt a more holistic approach. By
combining the individual components of our system in a secure network, our product can
react more granularly to threats as they occur. Zimory Cloud Suite can, for example, alter
or replace individual components rather than having to re-engineer the entire product.
These characteristics are the basis of our carrier grade system that meets the highest
security and quality standards.
7
Cloud Security Alliance, CSA Guide “Security Guidance For Critical Areas Of Focus In Cloud Computing V3.0”
2011, p 149.

CONTACT INFORMATION
Zimory GmbH
Alexanderstrasse 3,
10178 Berlin
Germany
Email: info@zimory.com
Tel: +49 (0)30 609 85 07-0
For the latest information, please visit www.zimory.com
The information contained in this document represents the current view of Zimory GmbH
on the issues discussed as of the date of publication. Because Zimory must respond to
changing market conditions, this document should not be interpreted to be a commitment
on the part of Zimory, and Zimory cannot guarantee the accuracy of any information
presented after the date of publication. The information represents the product at the time
this document was published and should be used for planning purposes only. Information
is subject to change at any time without prior notice.
This document is for informational purposes only.
ZIMORY MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
© 2009 Zimory GmbH. All rights reserved. Zimory is a registered trademark of Zimory
GmbH in Germany. All other trademarks are the property of their respective owners.

Zimory White Paper: Security in the Cloud pt 2/2

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Zimory White Paper: Security in the Cloud pt 2/2

Semelhante a Zimory White Paper: Security in the Cloud pt 2/2 (20)

Último

Último (20)

Zimory White Paper: Security in the Cloud pt 2/2