VMware vSphere Security Cookbook

Risk management, while outside the scope of this book, is a key foundation in the creation of a secure system. Proper risk assessment will not only identify what is being protected, the cost, and the criticality of those assets, but also identify the likelihood of the system or systems being breached. With the state of governance, compliance, and the growing requirement to notify customers of the security breach, it's more important than ever to create an auditable system based on well-defined security policies.

Not long ago, type I hypervisor systems, such as VMware ESX and Microsoft Hyper-V, were considered inferior for the task of running highly secure environments. The virtualization market has made substantial progress in the security space in a short span of time.

This chapter provides a brief overview and review of the risk and the associated components of risk pertaining to the virtualization environment. The ultimate goal is to determine the acceptable risk, which is the level of risk that a company is willing to take in order to conduct business.

The risk equation is composed of three components: threat, vulnerability, and cost.

Risk = Threat x Vulnerability x Cost

In brief, Cost is the damage measured in currency, as experienced in the loss of hardware or software. The cost also includes consulting hours or quantifiable staff time spent in remediating the damages caused. While cost is a key factor in the risk formula, it falls outside the scope of this book. Please refer to sites such as http://www.isaca.org for further information on risk and risk management.

The Threat component of the risk equation is measured in frequency or rate. For example, the threat of a user deleting a file will be greatly reduced if a user only has read permission on the file. By the same token, an organization with 10,000 computers has a much higher potential threat of a virus infection than an organization with 1,000 computers.

While there are threats associated specifically with the virtualization environment, a great deal of risk is caused by the misconfiguration of systems and policies. With the added complexity of virtualization comes additional layers that need to be addressed in order to make the environment secure. Without end-to-end security communication in the Storage Area Network (SAN), the storage switch, hypervisor host, and virtual machine are at risk. Likewise, communication between virtual networking components and physical networking components presents many opportunities for misconfiguration, thereby leading to the opportunity for a security breach.

The Vulnerability component, at a broad level, is measured as a percentage, which is similar to the case of a threat. The term vulnerability is most closely tied to a known deficiency or bug that presents a clear vector for compromise, and as such, caries a likelihood of 100 percent if the system is not patched to protect against said exploit.

Considering the risk equation, vulnerability is the component that has the most control. Vulnerabilities in the hypervisor platform will typically be patched by the vendor, in this case, VMware. By utilizing tools such as Update Manager, system administrators are able to keep the host systems patched in a timely and regular manner.

During the software patching cycle, it's important to do proper testing before applying a patch to a production system. This is even more critical for virtualized systems since a single virtualized host can hold a large number of virtual machines and thus will be affected adversely by a patch crippling a host.

Normal network vulnerabilities are still present in a virtualized environment. The mix between virtual networking and physical networking can present a different set of vulnerabilities based on the environment. It is important for the networking team and the server virtualization team to work together in order to ensure that both the physical and virtual networks are correctly configured and secure.

Understanding defense-in-depth

In addition to risk is the concept of defense-in-depth. The defense-in-depth model uses a layered approach, which not only increases the attacker's risk of detection but also reduces an attacker's chance of success. Defending the organization in depth means the application of a combination of people, processes, and technology to protect against threats at each layer. A good defense-in-depth architecture will build each layer of the security under the assumption that the other layer has been breached. If one layer is missing something, another layer might stop it and thereby stop the attacker.

In brief, the model consists of a series of interconnected components. The fundamental layer of policy and procedure affects every other layer. This layer includes both security policies and security procedures, as shown in the following figure:

The next layer is the Physical Security layer. This layer encompasses the remaining layers and includes secure facilities, mantraps, surveillance, and biometric identification devices.

The traditional host layer is now broken up into the virtual host and the virtual machine. The virtual host, also known as the hypervisor, includes signed drives, a secured kernel layer, and minimal management attack surfaces. The virtual machine layer includes the guest operating system, host hardening, patch management, and strong authentication. The guest operating system might also include a host-based firewall, intrusion detection system, and disk encryption system.

The data layer of the defense-in-depth model includes Access Control Lists (ACLs) and encryption.

The application layer includes hardening practices such as mechanisms to prevent SQL injection, as an example.

The network layer consists of an internal network and perimeter layers. These layers are traditionally separated by a security device such as a firewall. In a virtualized environment, both an internal network and a perimeter network can and often do reside within the same set of virtual host machines. In a complex networking scheme, it's even more critical to ensure that trusted network traffic and untrusted network traffic are properly separated in the virtual environment.

In a traditional physical environment, overall security is often more difficult to achieve, simply because there are more components and the risk of misconfiguration is higher. For example, securing a mission-critical application is more efficient when the majority of components are virtual and can be configured together by a team or an individual. In a physical environment, the same tasks could span numerous individuals around the globe. The virtual environment provides the administrator with an encapsulated landscape, which provides a better structure for tracking critical components.

The remainder of this chapter will highlight the threats and vulnerabilities to core services utilized in a virtualization environment, including storage, networks, hypervisors, virtual machines, and physical security.

Hypervisor threats from attackers are growing in popularity. In fact, the vulnerability that allows a virtual machine to escape to the hypervisor has been documented in a certain number of 64-bit operating systems that have been virtualized. In addition, a limited number of Intel CPUs are vulnerable to a local privilege-escalation attack. The attack essentially allows the virtual machine access to a ring of the kernel on the hypervisor host. While this did affect several hypervisor platforms, it did not affect the VMware ESX platform.

VMware continues to innovate in the area of isolating components of the virtual landscape with various products, including Network Virtualization Platform (NSX). NSX is designed with the Software Designed Data Center (SDDC) approach in mind. Achieving true isolation in a multitenant cloud model is the goal. Increased isolation and controls will help to minimize hypervisor threats.

The following is an example of a guest VM affecting the host at the workstation level, not at the server level. The vulnerability listed in the National Vulnerability Database (http://nvd.nist.gov) is as follows:

In this case, the user with administrative privileges in the guest operating system was able to execute the code against the host. Keep in mind that this was not just any host; this was a VMware workstation, which is a different type of hypervisor.

Hypervisor vulnerabilities affect the ability to provide and manage core elements, including CPI, I/O, disk, and memory, to virtual machines hosted on the hypervisor. As with any other software system, vulnerabilities are identified and vendors work toward patching them as quickly as possible before an exploit is found.

Several key vulnerabilities exist at this time, specific to VMware ESXi, including buffer overflow and directory traversal vulnerabilities. The following information is taken from the National Vulnerability Database (http://nvd.nist.gov):

Note that the access vector for both of these vulnerabilities is termed network exploitable, meaning that the vulnerability is remotely exploitable with only network access. The attacker does not need local access to exploit this type of vulnerability. The vulnerability listed in the National Vulnerability Database (http://nvd.nist.gov) is as follows:

When attackers find a vulnerability such as this and see that no authentication is required to exploit and the access vector is network exploitable, they move this up the list as a potential low-risk, high-value target.

It should be noted that at the time of writing this book, these vulnerabilities were active; however, VMware releases patches on a regular basis and some or all of the example vulnerabilities might have already been remediated.

Virtual machine (VM) threats vary by the guest operating system (OS) that is loaded into the VM. Each operating system has its own list of threats, with the Microsoft Windows OS at the top of the list. Given its popularity, the Windows operating system has been a prime target for years as attackers find different ways to compromise the OS itself or the popular Internet Explorer browser within Windows.

Over the past few years, Adobe and its Adobe Reader product have become a target for attackers. Since Adobe Reader is installed on the majority of Windows and Apple operating systems, compromising Adobe can potentially allow an attacker to access a very large number of computers.

Although the guest operating system is contained within each virtual machine, it interacts with the hypervisor by way of the virtual hardware that supports the VM as well as by the specific tools that allow the VM to interact with the hypervisor, through which the hypervisor provides specialized services to the VM.

There is evidence reported by Symantec that certain malware attempts to determine whether the operating system is running in a virtual machine. This detection can be done in a number of ways, including checking whether VMware tools are running. For more details, check the Symantec link in the References section.

The vulnerabilities listed here are likely to be out of date as they have been remediated by the respective vendors. The following are a few guest operating system vulnerabilities at the time of writing this book.

The following vulnerability is one of an ever increasing number of vulnerabilities from Adobe, Adobe Reader, and Acrobat listed in the National Vulnerability Database (http://nvd.nist.gov):

The following vulnerability is for a kernel-mode driver in Windows 7, listed in the National Vulnerability Database (http://nvd.nist.gov):

Any vulnerability found in a standalone desktop machine might have applicability in a virtualized environment. In fact, an infected Windows desktop, for example, has the opportunity to do more damage in a virtualized environment than if it were a standalone machine. If a virtualized environment was not configured correctly, a runaway desktop machine could take resources away from other virtual machines on the same host, impacting the performance of many as opposed to a single machine.

Network threats are the largest in number due to the nature of the Internet and enterprise data connectivity. Since virtual switches function similar to physical switches, most, if not all, threats that have faced the traditional networking environment continue to face the virtualization environment. Even threats to specific Cisco IOS versions, for example, can affect the virtual network environment since there is a Cisco Nexus 1000 virtual switch available for VMware. There are several types of network attacks that generally fall into the following categories:

Other types of network threats do exist, but for the purposes of this overview, the general types explained give you the background required for configurations in the virtual environment.

Network vulnerabilities are the most exploited type of vulnerability due to the large population of devices connected to the Internet. Network vulnerabilities affect endpoint devices, such as web servers, and core devices, such as routers and switches.

Network vulnerabilities across many vendors currently exist. Here are two example vulnerabilities from Cisco. Both represent bugs in the switch-level OS. This vulnerability is listed in the National Vulnerability Database (http://nvd.nist.gov) as follows:

The next vulnerability allows an attacker to cause a denial of service using a modified packet sent to the device. This example is listed in the National Vulnerability Database (http://nvd.nist.gov) as follows:

The two examples are very specific, but both reinforce the common threat of denial of service and why frameworks such as defense-in-depth are important. If an attacker is able to cause a denial of service in the network device, a sensor somewhere on the network should be in place to send the proper alert.

There are many different types of storage that can be used by VMware vSphere; however, for the purposes of this brief explanation of storage threats, we will focus on storage area networks (SAN) and network-attached storage (NAS). From a protocol perspective, Fibre Channel and Internet Small Computer System Interface (iSCSI) will be briefly reviewed in the context of which threats and potential vulnerabilities they bring to the risk equation.

In the past, there was a clear delineation between SAN storage and NAS, but in recent years, high-performing devices have become much more popular for small- and medium-sized businesses. Likewise, most enterprises that historically used Fiber Channel exclusively now tend to have some iSCSI in their storage environment. Both protocols are inherently insecure on their own. In the case of Fiber Channel, sending information in clear text would seem to be the major risk; however, this is mitigated largely due to the physical characteristics of the fiber that the data passes over. That's not to say that Fiber Channel can't be exploited, but the nature of its closed-loop system makes it a lower risk.

iSCSI, on the other hand, uses the same RJ-45 network cables and physical switches that the normal IP traffic utilizes within the network. Without a proper process for securing iSCSI, traffic is very vulnerable to attack and exploit. It's crucial to isolate iSCSI traffic in order to separate switches or by VLAN. Additionally, the use of Challenge Handshake Authentication Protocol (CHAP) authentication will ensure that only approved iSCSI endpoints can communicate with the storage system.

At the time of writing this book, there were no publicized vulnerabilities for any of the major SAN or NAS vendors specific to the access protocols' Fiber Channel or iSCSI. The following two vulnerabilities are for storage vendor management, listed in the National Vulnerability Database (http://nvd.nist.gov).

A number of the vulnerabilities listed specific to storage center around some form of management and authentication information being sent or stored in clear text:

Another example from Hitachi shows vulnerability in the Network Node Manager that allows remote attacks:

Both of these example vulnerabilities are in the management layer of the storage device, not within the data stream specific to the protocol transferring information between the SAN or NAS drivers and the hypervisor.

The topic of physical security might seem out of place in a book on virtual security; however, it plays a key role. As referenced in the defense-in-depth model, the most thorough design and implementation can be breached if physical security fails. For example, if one can physically access a console logged in with administrative credentials, security controls are effectively neutralized.

Physical threats by nature are threats that require physical access to the hardware in order to exploit the systems. In the case of virtualization hardware, the threat vector is somewhat lessened if you assume that the hardware will reside in some form of secure datacenter structure, be it a secure facility or room. In addition, carrying out administrative tasks on management desktops situated in secure locations without access to any public networks will also reduce risk.

Even with equipment residing in a secure facility, there are a number of threats that remain, including nonmalicious factors such as extreme weather and power outages. Other threat vectors include security and authentication mechanisms to the facility and within the facility to the server location. Typically, in a highly secure facility, a cage within the datacenter is used to secure the server hardware. Entry into the cage is limited to certain personnel and controlled by biometric or card reader devices.

Another potential threat is the personnel that staff the facility. A dishonest employee, even one who has been fully vetted and background-checked can gain access to sensitive equipment and potentially the data residing on that equipment. Alternatively, a dishonest employee can grant access to an outsider who is intending to attack a particular company's server or virtualization environment contained in the facility.

Physical vulnerabilities include any weak links between the outside and the server equipment within the facility belonging to the customer. Vulnerabilities can mean the existence of the threats mentioned in the previous section, most notably weak authentication and questionable personnel.

Vulnerability such as a poor location or inadequate power grid should be immediately remediated by moving equipment to another facility without said vulnerabilities. Additional vulnerabilities that need to be considered include any aspect of the facility that will lend itself to a single point of failure, including the lack of redundant power or redundant Internet connections. Commercial datacenters are usually happy to showcase their redundancy.

As with all the threats and vulnerabilities mentioned in the previous sections, a detailed plan and checklist should be used when evaluating the design and implementation of each of these parts that make up a secure infrastructure. Adequate disaster recovery planning is also key as well as ensuring data security during a disaster. Confirm that should a disaster occur, the data will be secure at the disaster recovery website or websites.

This book contains a number of security, compliance and encryption topics that might not be second nature to the reader. This section will provide an overview of concepts and methods discussed in the book along with references for further information.

Data classifications

Data classifications are used to assign data at the right level of protection and security based on the content type and sensitivity required. Personally Identifiable Information (PII) and Protected Health Information (PHI) are two of the classifications referenced.

Cryptography

Symmetric Encryption: This utilizes a shared secret key to encrypt and decrypt messages. Both the sender and recipient utilized the same key to encrypt and decrypt information passed between them. The key can take the form of a complex string, for example. The encryption algorithm along with its key length determine the relative strength of the key. The strongest current block cipher is Advanced Encryption Standard (AES).

Asymmetric Encryption: This utilizes a public key and a private key. A message encrypted by the private key can only be decrypted by the public key and vice versa. The public key is available to anyone, while the private key is kept secret. Public key certificates utilize asymmetric encryption and provide information about the organization to which the certificate was issued.

Certificates

Certificates provide digital identification and a mechanism to establish trust. We can think of a certificate as a driver's license or government issued ID card. The trusted root authority can be thought of as the government in this example. The license or ID can be thought of as the certificate. When someone checks our ID to verify our identity, they trust the authority that issued that ID. Likewise, when a certificate is issued from a trusted authority, we can be assured the identity represented by the certificate is genuine.

Also known as digital certificates or X.509 certificates, these certificates are widely used by websites to prove their identity to the web browser. Certificates can also be used for mutual authentication where not only does the web browser trust the website, but also the web site trusts the web browser.

Public Key Infrastructure (PKI) generates certificates in both public and private scenarios. A Certificate Authority (CA) is the mechanism that responds to proper certificate requests and returns certificates to the requesting party. Verisign, Thawte, and Digicert are examples of public CAs, meaning a certificate issued by them is trusted by the majority of commercial web browsers by default. A private CA is usually set up within a corporate network, and the certificates issued are only trusted by machines on the corporate network.

Virtual Private Networks

Virtual Private Networks (VPN) provide a network tunnel between two endpoints through which information is encrypted (protected) from the network traffic outside the VPN tunnel. There are two main types of VPN tunnels in use today: IPSEC and SSL. IPSEC stands for Internet Protocol security, while SSL stands for Secure Sockets Layer.

The goal of this introductory chapter was to provide an overview of the threats and vulnerabilities that apply to a virtual infrastructure. From a security and compliance standpoint, every system should undergo a proper risk assessment. The risk equation has been presented along with a high-level introduction to the defense-in-depth philosophy.

Example threats and vulnerabilities have been highlighted for the hypervisor, guest virtual machine, network, storage, and physical categories. As threats continue to evolve and vulnerabilities are identified, vendors such as VMware provide patches and updates to keep their products secure and ensure system integrity. It is always a good idea to check new software versions for vulnerabilities before performing an upgrade.

While this chapter provided an overview and baseline information, the remainder of the book will be presented in the typical cookbook format. Each chapter will provide specific recipes for securing your vSphere infrastructure.