When reviewing host security and assessing risks, you should consider the
context of cloud services delivery models (SaaS, PaaS, and IaaS) and
deployment models (public, private, and hybrid). Although there are no
known new threats to hosts that are specific to cloud computing, some
virtualization security threats—such as VM escape, system configuration
drift, and insider threats by way of weak access control to the
hypervisor—carry into the public cloud computing environment. The dynamic
nature (elasticity) of cloud computing can bring new operational
challenges from a security management perspective. The operational model
motivates rapid provisioning and fleeting instances of VMs. Managing
vulnerabilities and patches is therefore much harder than just running a
scan, as the rate of change is much higher than in a traditional data
center.In addition, the fact that the clouds harness the power of thousands
of compute nodes, combined with the homogeneity of the operating system
employed by hosts, means the threats can be amplified quickly and
easily—call it the “velocity of attack” factor in the cloud. More
importantly, you should understand the trust boundary and the
responsibilities that fall on your shoulders to secure the host
infrastructure that you manage. And you should compare the same with
providers’ responsibilities in securing the part of the host
infrastructure the CSP manages.
1. SaaS and PaaS Host Security
In general, CSPs do not publicly share information related to their host
platforms, host operating systems, and the processes that are in place
to secure the hosts, since hackers can exploit that information when
they are trying to intrude into the cloud service. Hence, in the context
of SaaS (e.g., Salesforce.com, Workday.com) or PaaS (e.g., Google App
Engine, Salesforce.com’s Force.com) cloud services, host security
is opaque to customers and the responsibility of securing the hosts is
relegated to the CSP. To get assurance from the CSP on the security hygiene
of its hosts, you should ask the vendor to share information under a
non-disclosure agreement (NDA) or simply demand that the CSP share the information via a
controls assessment framework such as SysTrust or ISO 27002. From a controls assurance perspective, the CSP
has to ensure that appropriate preventive and detective controls are in
place and will have to ensure the same via a third-party assessment or
ISO 27002 type assessment framework.
Since virtualization is a key enabling technology that improves
host hardware utilization, among other benefits, it is common for CSPs
to employ virtualization platforms, including Xen and VMware hypervisors, in their host computing platform
architecture. You should understand how the provider is using
virtualization technology and the provider’s process for securing the
virtualization layer.
Both the PaaS and SaaS platforms abstract and hide the host
operating system from end users with a host abstraction layer. One key
difference between PaaS and SaaS is the accessibility of the abstraction
layer that hides the operating system services the applications consume.
In the case of SaaS, the abstraction layer is not visible to users and
is available only to the developers and the CSP’s operations staff,
where PaaS users are given indirect access to the host abstraction layer
in the form of a PaaS application programming interface (API) that in
turn interacts with the host abstraction layer. In short, if you are a
SaaS or a PaaS customer, you are relying on the CSP to provide a secure
host platform on which the SaaS or PaaS application is developed and
deployed by the CSP and you, respectively.
In summary, host security responsibilities in SaaS and PaaS
services are transferred to the CSP. The fact that you do not have to
worry about protecting hosts from host-based security threats is a major
benefit from a security management and cost standpoint. However, as a
customer, you still own the risk of managing information hosted in the
cloud services. It’s your responsibility to get the appropriate level of
assurance regarding how the CSP manages host security hygiene.
2. IaaS Host Security
Unlike PaaS and SaaS, IaaS customers are primarily responsible for
securing the hosts provisioned in the cloud. Given that almost all IaaS
services available today employ virtualization at the host layer, host security in IaaS
should be categorized as follows:
Virtualization software security
The software layer that sits on top of bare metal and
provides customers the ability to create and destroy virtual
instances. Virtualization at the host level can be accomplished
using any of the virtualization models, including OS-level
virtualization (Solaris containers, BSD jails, Linux-VServer),
paravirtualization (a combination of the hardware
version and versions of Xen and VMware), or hardware-based
virtualization (Xen, VMware, Microsoft Hyper-V). It is important
to secure this layer of software that sits between the hardware
and the virtual servers. In a public IaaS service, customers do
not have access to this software layer; it is managed by the CSP
only.
Customer guest OS or virtual server security
The virtual instance of an operating system that is
provisioned on top of the virtualization layer and is visible to
customers from the Internet; e.g., various flavors of Linux,
Microsoft, and Solaris. Customers have full access to virtual
servers.
3. Virtualization Software Security
Since the CSP manages the virtualization software that sits on top
of the hardware, customers will have neither visibility nor access to
this software. Hardware or OS virtualization enables the sharing of
hardware resources across multiple guest VMs without interfering with each other so that you can
safely run several operating systems and applications at the same time
on a single computer. For the purpose of simplicity, we made an
assumption that IaaS services are using “bare metal hypervisor”
technologies (also known as type 1 hypervisors), such as VMware ESX,
Xen, Oracle VM, and Microsoft’s Hyper-V. These hypervisors support a variety of guest OSs, including
Microsoft Windows, various Linux “flavors,” and Sun’s
OpenSolaris.
Given that hypervisor virtualization is the essential ingredient
that guarantees compartmentalization and isolation of customer VMs from
each other in a multitenant environment, it is very important to protect
the hypervisors from unauthorized users. A new arms race between hacker
and defender (CSP) in the realm of virtualization security is already
underway. Since virtualization is very critical to the IaaS cloud architecture, any attack that could compromise
the integrity of the compartments will be catastrophic to the entire
customer base on that cloud. A recent incident at a tiny UK-based
company called Vaserv.com exemplifies the threat to
hypervisor security. By exploiting a zero-day vulnerability in
HyperVM, a virtualization
application made by a company called Lxlabs, hackers destroyed 100,000 websites hosted by
Vaserv.com.
The zero-day vulnerability gave the attackers the ability to execute
sensitive Unix commands on the system, including
rm -rf, which forces a
recursive delete of all files. Evidently, just days before the
intrusion, an anonymous user posted on a hacker website called
milw0rm a long list
of yet-unpatched vulnerabilities in Kloxo, a hosting control panel that integrates into
HyperVM. The situation was worse for approximately 50% of Vaserv’s
customers who signed up for unmanaged service, which doesn’t include
data backup. It remains unclear whether those website owners will ever
be able to retrieve their lost data.
CSPs should institute the necessary security controls,
including restricting physical and logical access to hypervisor and
other forms of employed virtualization layers. IaaS customers should
understand the technology and security process controls instituted by
the CSP to protect the hypervisor. This will help you to understand the
compliance and gaps with reference to your host security standard,
policies, and regulatory compliances. However, in general, CSPs lack
transparency in this area and you may have no option but to take a leap
of faith and trust CSPs to provide an “isolated and secured virtualized
guest OS.”
3.1. Threats to the hypervisor
The integrity and availability of the hypervisor are of utmost importance
and are key to guaranteeing the integrity and availability of a public
cloud built on a virtualized environment.
A vulnerable hypervisor could expose all user domains to
malicious insiders. Furthermore, hypervisors are potentially
susceptible to subversion attacks. To illustrate the vulnerability of
the virtualization layer, some members of the security research
community demonstrated a “Blue Pill” attack on a hypervisor. During
Black Hat 2008 and Black Hat DC 2009 Joanna Rutkowska, Alexander Tereshkin, and Rafal Wojtczuk from Invisible Things Lab demonstrated a number of ways to compromise Xen’s
virtualization. Although Rutkowska and her team have identified problems
with Xen implementations, generally they seem quite positive about the
Xen approach. But their demonstration does illustrate the complexity
of securing virtualized systems and the need for new approaches to
protect hypervisors from such attacks.
Since virtualization layers within public clouds for the most
part are proprietary and closed source (although some may employ a
derivative of open source virtualization software such as Xen), the
source code of software used by CSPs is not available for scrutiny by
the security research community.
4. Virtual Server Security
Customers of IaaS have full access to the virtualized guest VMs
that are hosted and isolated from each other by hypervisor technology.
Hence customers are responsible for securing and ongoing security
management of the guest VM.
A public IaaS, such as Amazon’s Elastic Compute Cloud (EC2), offers a web services API to
perform management functions such as provisioning, decommissioning, and
replication of virtual servers on the IaaS platform. These system
management functions, when orchestrated appropriately, can provide
elasticity for resources to grow or shrink in line with workload demand.
The dynamic life cycle of virtual servers can result in complexity if
the process to manage the virtual servers is not automated with proper
procedures. From an attack surface perspective, the virtual server
(Windows, Solaris, or Linux) may be accessible to anyone on the
Internet, so sufficient network access mitigation steps should be taken
to restrict access to virtual instances. Typically, the CSP blocks all port access to virtual servers and
recommends that customers use port 22 (Secure Shell or SSH) to administer virtual server instances. The cloud
management API adds another layer of attack surface and must be included
in the scope of securing virtual servers in the public cloud. Some of
the new host security threats in the public IaaS include:
Stealing keys used to access and manage hosts (e.g., SSH
private keys)
Attacking unpatched, vulnerable services listening on standard
ports (e.g., FTP, NetBIOS, SSH)
Hijacking accounts that are not properly secured (i.e., weak
or no passwords for standard accounts)
Attacking systems that are not properly secured by host
firewalls
Deploying Trojans embedded in the software component in the VM
or within the VM image (the OS) itself
4.1. Securing virtual servers
The simplicity of self-provisioning new virtual servers on an
IaaS platform creates a risk that insecure virtual servers will be
created. Secure-by-default configuration needs to be ensured by
following or exceeding available industry baselines.
Securing the virtual server in the cloud requires strong
operational security procedures coupled with automation of procedures.
Here are some recommendations:
Use a secure-by-default configuration. Harden your image and use a standard
hardened image for instantiating VMs (the guest OS) in a public
cloud. A best practice for cloud-based applications is to build
custom VM images that have only the capabilities and services
necessary to support the application stack. Limiting the
capabilities of the underlying application stack not only limits
the host’s overall attack surface, but also greatly reduces the
number of patches needed to keep that application stack
secure.
Track the inventory of VM images and OS versions that are
prepared for cloud hosting. The IaaS provider provides some of these VM images. When
a virtual image from the IaaS provider is used it should undergo
the same level of security verification and hardening for hosts
within the enterprise. The best alternative is to provide your own
image that conforms to the same security standards as internal
trusted hosts.
Protect the integrity of the hardened image from
unauthorized access.
Safeguard the private keys required to access hosts in the
public cloud.
In general, isolate the decryption keys from the cloud where
the data is hosted—unless they are necessary for decryption, and
then only for the duration of an actual decryption activity. If
your application requires a key to encrypt and decrypt for
continuous data processing, it may not be possible to protect the
key since it will be collocated with the application.
Include no authentication credentials in your virtualized
images except for a key to decrypt the filesystem key.
Do not allow password-based authentication for shell
access.
Require passwords for sudo or role-based access (e.g., Solaris,
SELinux).
Run a host firewall and open only the minimum ports
necessary to support the services on an instance.
Run only the required services and turn off the unused
services (e.g., turn off FTP, print services, network file
services, and database services if they are not required).
Install a host-based IDS such as OSSEC or Samhain.
Enable system auditing and event logging, and log the
security events to a dedicated log server. Isolate the log server
with higher security protection, including accessing
controls.
If you suspect a compromise, shut down the instance,
snapshot your block volumes, and back up the root filesystem. You
can perform forensics on an uncompromised system later.
Institute a process for patching the images in the
cloud—both offline and instantiated images.
Periodically review logs for suspicious activities.
Table 1 lists
security controls at the host level.
Table 1. Security controls at the host level
| Threat
outlook | High |
|---|
| Preventive
controls | Host firewall, access
control, patching, hardening of system, strong
authentication |
| Detective
controls | Security event logs,
host-based IDS/IPS |
