Security Procedures for VMware vSphere · VMware vSphere Page 1 4.0 & 4.1 Intended Readership These CESG Security Procedures should be used by System Designers, Risk Managers and

October 2015 Issue No: 1.2

Security Procedures

VMware vSphere 4.0 & 4.1 Customers can continue to use this guidance. The content remains current, although may contain references to legacy SPF policy and classifications.

Security Procedures

VMware vSphere 4.0 & 4.1

Issue No: 1.2 October 2015

The copyright of this document is reserved and vested in the Crown.

Document History

Version Date Comment

1.0 August 2011 First issue

1.1 August 2012 Updated for vSphere 4.1

1.2 October 2015 First public issue

Page 1


Intended Readership These CESG Security Procedures should be used by System Designers, Risk Managers and Accreditors in HMG Departments and Agencies intending to deploy VMware vSphere 4.0 & 4.1 for separating at most RESTRICTED virtual machines from UNCLASSIFIED virtual machines, along with the guidance provided by CESG IA Good Practice Guide 12, Use of Virtualisation Products for Data Separation: Managing the Security Risks (GPG 12) (reference [a]).

Executive Summary A virtualisation product is software that allows a single physical computer to act as if it was several distinct computers, called virtual machines. VMware vSphere is a virtualisation product, and these Security Procedures provide sufficient assurance to allow vSphere 4.0 or 4.1 to simultaneously run virtual machines protectively marked as RESTRICTED and UNCLASSIFIED, which is described in GPG 12 (reference [a]) as ‘Basic Virtualisation’.

Aims and Purpose These CESG Security Procedures summarise security information relevant to the secure configuration, management and use of VMware vSphere 4.0 & 4.1. They give advice based on knowledge gained through detailed technical assessment carried out by CESG, the UK National Technical Authority for Information Assurance. HMG Departments and agencies intending to rely on security features of these products must take note of this advice in their procurement decisions, risk management, deployment, operation and disposal.

Page 2


Contents:

Contents: ........................................... 2

Chapter 1 - Introduction ................... 3

Outline Description .......................... 3 CESG Approval ............................... 3 Suitability for Purpose ...................... 4 This document and HMG Standards and CESG Guidance ....................... 4

Relevance of Local Procedures ....... 4 Terminology ..................................... 4 Non-standard security domains ....... 5

Chapter 2 - Architecture ................... 7

High Level Network Architecture Diagram ........................................... 7

High Level Storage Architecture ...... 9

Chapter 3 - VMware Components and Approvals ................................. 12

Approved Components and limitations ....................................... 12

Components that have not been assessed ....................................... 13 Components that must not be used ...................................................... 14

VMware Tools ................................ 14

Chapter 4 - Restrictions on Approved Use ................................. 15

Cryptographic Operations .............. 15 VMware support ............................ 15

Third Party Drivers ......................... 15 Administration ................................ 16 Hardware access/passthrough ...... 16

Use of Passwords .......................... 16 Location of use .............................. 16

Emergency Plans .......................... 16

Chapter 5 - Parameter Settings ..... 18

Note regarding templates, cloning and deployment of new virtual machines ....................................... 18 Note regarding host profiling .......... 18 Guideline Organisation .................. 18

Guideline Templates ...................... 19 Virtual Machines ............................ 21

VMware ESXi Host ........................ 23

VMware vNetwork (Virtual Networking) ................................... 27 VMware vCenter ........................... 29

Appendix A ..................................... 31

Appendix B ..................................... 32

References ..................................... 35

Glossary ......................................... 36

Points of Contact ........................... 38

Page 3


Chapter 1 - Introduction

Key Principles

This document provides guidance on deploying vSphere 4.0/4.1

VMware vSphere 4.0/4.1, using VMware ESXi and configured with this guidance, can be used to separate virtual machines running at RESTRICTED, PROTECT descriptor, and UNCLASSIFIED

This document needs to be read in conjunction with VMware’s vSphere Hardening Guide

Outline Description

1. This document provides CESG guidance on how to deploy VMware vSphere 4.0/4.1 in a production environment. It is to be used in conjunction with the VMware vSphere 4.0/4.1 Hardening Guides as appropriate (references [b] and [c]), and provides additional CESG requirements and guidance. For this reason, the layout and style of this guide will be similar to VMware’s to avoid confusion. Future versions of VMware’s Hardening guide may change or remove some of the settings included in this document. CESG will review the impact of any changes and reissue these Security Procedures as required.

2. CESG advice is mandatory when it uses words such as ‘required’, ‘must’, or ‘must not’. When advice is mandatory, it means that not following it will break assumptions made in the assessment, likely opening up weaknesses or, at least, increasing the attack surface. Such an installation cannot be considered to be following these Security Procedures; if this needs to be done for operational reasons, CESG advice should be sought.

3. When advice is only ‘recommended’, however, or uses words such as ‘should’ or ‘should not’, it means that CESG considers it good practice, but it need not be followed if there is a business case not to. An installation not following recommended advice is still otherwise following these Security Procedures.

CESG Approval

4. VMware vSphere 4.0/4.1 using VMware ESXi has been assessed for ‘Basic Virtualisation’ according to GPG 12 (reference [a]) and CESG IA Developers’ Note 11, Requirements and Recommendations for a Basic Virtualisation product (reference [d]). It has been approved by CESG to secure protectively marked information as set out in the following table, provided the requirements of these Security Procedures are met:

Type Approval

Basic Virtualisation RESTRICTED virtual machines can be used alongside UNCLASSIFIED virtual machines on the same hardware

Table 1 – Approval for Basic Virtualisation

Page 4


5. Note that VMware vSphere 4.0/4.1 using VMware ESX (as opposed to ESXi) has not been assessed. This approval applies solely to the ESXi version. The ESX version is due to be superseded and will therefore not be assessed.

6. CESG recommends always using the latest approved version. As a result of assurance work, CESG has determined that updates to approved versions that do not change the major or minor version number normally retain their approval. If, exceptionally, a particular update loses its approval, CESG will state this in an explicit announcement.

7. Details of the version(s) of VMware vSphere that have been assessed and the issue number of this document that applies to each approved version appear in the CESG Directory of Assured Products.

Suitability for Purpose

8. Potential users should consult their Accreditor to confirm that the product is suitable for the intended purpose.

9. No assumption has been made about the use of each virtual machine. Consequently, an UNCLASSIFIED virtual machine could be connected to the Internet, though the usual guidance in CESG Information Assurance Good Practice Guide No. 8 – Protecting External Connections to the Internet (reference [e]) should be followed.

This document and HMG Standards and CESG Guidance

10. Advice given in these Security Procedures is consistent with HMG policy and guidance, as set out in the HMG Security Policy Framework (reference [f]), HMG Information Assurance Standard No’s 1 & 2 – Information Risk Management (IS1 & 2) (reference [g]), HMG Information Assurance Standard No. 4 – Protective Security Controls for the Handling and Management of Cryptographic Items (IS4) (reference [h]) and HMG Information Assurance Standard No. 5 – Secure Sanitisation (IS5) (reference [i]).

11. These Security Procedures are also consistent with the guidance in CESG Information Assurance Good Practice Guide No. 12 – Use of Virtualisation Products for Data Separation (reference [a]) and CESG Information Assurance Developers’ Notes No. 11 – Requirements and Recommendations for a Basic Virtualisation Product (reference [d]).

Relevance of Local Procedures

12. Before beginning installation and operation, users must establish whether any Departmental or local standards, which may be more rigorous than national policy, should be followed in preference to those given in these Security Procedures.

Terminology

13. VMware vSphere is the name given to the entire virtualisation product and the system it is running on. Key components are:

Page 5


The ESXi host(s) – one (or more) physical machines that run the ESXi hypervisor

VMware vCenter Server – the management software that either runs on a standalone machine, or a virtual machine on one of the ESXi hosts

Storage device – a generic term for some form of data-at-rest storage, be it local disk, a disk array, a SAN, or something else

14. A ‘security domain’ refers to a way of dividing the virtual machines on a platform, so that each group of one or more virtual machines share a common threat model. Generally, this is the same as saying they share the same protective marking though, as noted in GPG 12 (reference [a]), there can be situations where system architects or data owners want separate security domains at the same protective marking.

15. This document will usually refer to security domains as ‘red’ or ‘black’ (or, similarly, ‘red side’ or ‘black side’), based on terms commonly used in the design of cryptographic systems. The red side contains the more sensitive data (such as RESTRICTED material), while the black side contains the less sensitive data (such as UNCLASSIFIED material). The assessment assumed that the black side will be compromised and attacks will be against the red side from the black side; however, this doesn’t rule out data exfiltration from misuse of the red side. The guidance set out in these Security Procedures reflects this.

16. By extension, the document will refer to red and black virtual machines, network cards, networks, data, etc, according to which security domain they are in.

17. This document uses RFC 2119 (reference[j]) terminology to indicate requirement levels, and should be referred to for further details.

Non-standard security domains

18. The default assumption in these Security Procedures is that VMware vSphere is separating (and hence protecting) virtual machines in the red security domain from attacks coming from a (compromised) black security domain. CESG advice should be sought in cases where symmetrical protection might be needed (e.g. where the two security domains are RESTRICTED and PROTECT MEDICAL and the data owners are particularly concerned about attacks in both directions).

19. In rare cases, a particular use of VMware vSphere might have more than two security domains (such as UNCLASSIFIED, PROTECT STAFF, and RESTRICTED). Detailed guidance on these cases cannot be given in a general document such as this, but a rough guide would be to treat the intermediate security domains as being on the red side of anything less sensitive, and on the black side of anything more sensitive, so they are appropriately protected from the other security domains. In other words, any pair of security domains considered in isolation should be treated as black and red with respect to each other.

Page 6


20. For example, if there are three security domains UNCLASSIFIED, PROTECT STAFF, and RESTRICTED:

The UNCLASSIFIED security domain is always on the black side

The RESTRICTED security domain is always on the red side

The PROTECT STAFF security domain is a red side security domain from the point-of-view of the UNCLASSIFIED domain (as that would be the situation if the RESTRICTED domain didn’t exist), and a black side domain from the point-of-view of the RESTRICTED domain (as that would be the situation if the UNCLASSIFIED domain didn’t exist)

The need to run separate red and black networks means that the PROTECT STAFF domain needs a third network, otherwise (from the point of view of one of the other domains) it would require sharing red and black data on the same network

Page 7


Chapter 2 - Architecture

Key Principles

This guidance assumes standard flexible network and storage architectures

Red and black networks must be connected to physically separate network cards. The red network may share a physical network card with the management and vMotion networks

Storage devices can be attached in two ways:

o A storage device containing data for a single security domain only, accessed through that domain’s network only

o A storage device containing data for one or more security domains, where ESXi has exclusive access to the device and can control the access

Seek CESG advice when deploying VMware vSphere on non-standard architectures

High Level Network Architecture Diagram

21. Figure 1 shows the recommended network architecture of each physical host deployed with VMware vSphere, in particular the use of separate networks, separate physical network cards (pNICs), and separate vSwitches. It shows the ideal case, where every network is on its own pNIC, but it is acceptable for one or more of the red network, the management network, and the vMotion network to share a pNIC.

Page 8


Figure 1 - vSphere network architecture showing virtual machine separation

22. The network cards connected to the segregated Black and Red networks (the “Black pNIC” and “Red pNIC”) must be physically separate network cards. A network card that supports multiple networks must not be used for both red and black networks unless it has been evaluated by CESG for this purpose. For blade servers, this physical separation requirement continues from the port on the blade server to the physical connection on the chassis. Any switches within the blade server must only be connected to a network at a single classification unless their use for network separation has been evaluated by CESG.

23. The Management Network and vMotion networks are considered to have the same impact level as the Red Network and must be accredited to this level. It is recommended that all three networks are separated for performance reasons. If these networks are combined, they should be separated with virtual networking such as VLANs.

24. vMotion can generate large volumes of traffic without warning and therefore VMware and CESG recommend, for performance reasons, that a separate high speed (1Gbps or above) pNIC be used for vMotion traffic; management traffic could also be assigned to this pNIC.

25. VMware vCenter Server, if used for administration, may be a physical host on the management network or a virtual machine on an ESXi host connected to

Page 9


the management network. CESG recommends the use of a separate physical host connected to the management network for vCenter Server, to prevent a problem with a host or storage system preventing management of the cluster. Otherwise, availability risks can be mitigated with the policies listed in the storage and vMotion sections.

26. Virtual machines must only be connected to vSwitches at the same protective marking. They must not be used across security domains (e.g. as a firewall virtual machine); support for this could be assessed in future if there is sufficient demand. Similarly, vSwitches must also only be connected to physical networks of the same protective marking.

27. VMware kernel network interfaces (vmknics) should only be connected to vSwitches on the management side, that is the vMotion, management and storage networks. Such vmknics should not be placed on the Red network and must not be placed on the Black network. See figure 1.

High Level Storage Architecture

28. As noted under Terminology, the term ‘storage device’ will be used for any form of data-at-rest storage, such as local disks, disk arrays, SANs, etc.

29. Figure 2 shows the recommended storage architecture, with two ESXi hosts connected to a variety of different storage options, not all of which are needed on any single deployment.

Figure 2 – VMware ESXi storage architecture

30. A storage device that is only going to contain data belonging to a single security domain can be attached either directly to a virtual machine (via the Black or

Page 10


Red network as appropriate), or to the hypervisor, but must not be connected to both as this would increase the attack surface of the hypervisor. If it is connected to the hypervisor, it must use Virtual Machine File System (VMFS) and be made available to the VM only as a virtual disk, and must not be directly visible on either the Red or the Black networks (though it can be made indirectly visible as a network share hosted by the VM).

31. A storage device that is to contain multiple security domains is more complicated. The simplest solution would be a storage device accredited to hold more than one security domain. Unfortunately, at the time of writing, no such device has been evaluated. CESG does not currently consider the use of Logical Unit Number (LUN) zoning a sufficient security measure to guarantee separation. However, using ESXi with VMFS to control access to a storage device has been assessed.

32. If a storage device is to contain multiple security domains, only ESXi can be used to maintain the separation between the security domains. The storage device must be dedicated to one or more ESXi hosts; the only other hosts allowed to access it must be those allowed to access all security domains on the device (such as a networked backup server). This precludes a non-ESXi host that would be accessing Red data only. The separation of VMFS has been assessed as capable of separating security domains; other network technologies, such as Network File System (NFS), have not been assessed and therefore must not be used for separating multiple security domains on a single device.

33. Although LUNs or Fibre Zoning must not be considered a security barrier, it is still good practice to use them with ESXi’s access control, as an extra precaution.

Storage devices attached to the ESXi host

34. The boot device for the virtual machine should be a virtual hard disk stored as a VMDK file on a storage device dedicated for use by ESXi. This storage device may contain VMDK files for both Red and Black virtual machines but must be considered as Red for sanitisation and decommissioning purposes.

35. The storage device must be presented to the virtual machine as a virtual hard disk, and not through a pass-through interface to the device itself (e.g. it must not appear in the virtual machine as an iSCSI or Fiberchannel device).

36. Owing to the need to use ESXi to control access, the storage device must not be used by non-ESXi servers (such as those providing legacy services), except for servers such as network backups that treat the storage device as a single unit.

37. Backups can contain both trusted and untrusted data, and so should be treated with care.

Page 11


38. Local storage on the ESXi hosts may be used, including for virtual machine boot devices. However, all hardware on the virtual machine must still be emulated. IDE pass-through and physical RDMs must not be used.

Storage devices attached to virtual machines

39. Storage devices that are not being shared by multiple security domains may be connected to the vSwitch that the virtual machine sees (identified above as the Red vSwitch and Black vSwitch) and may be identified as iSCSI or Network Attached Storage (NAS) devices on the virtual machines. These may also be used outside of the ESXi environment, as long as they are not be used for data separation.

40. If the storage network and Red network are combined then the ESXi storage device must be protected from unauthorised access from any machine (whether virtual or physical) on the same network. VLANs within ESXi can be used to provide this protection for virtual machines.

Page 12


Chapter 3 - VMware Components and Approvals

Key Principles

Not all components of VMware vSphere have been assessed and approved

Use of unassessed components is at the data owner’s risk

Certain components must not be used for the deployment to be considered approved

Approved Components and limitations

vCenter Server (Standalone)

41. vCenter Server is approved for use if it is connected to the management network only.

Update Manager

42. Update Manager is approved for use if it is connected to the management network only. It may be a virtual or physical machine. This must be air-gapped from the Update Manager connected to the Internet to receive the updates.

vMotion and Storage vMotion

43. vMotion and Storage vMotion are approved for use under the control of vCenter Server only. If vCenter Server is a virtual machine (not recommended), reservation rules must be used to ensure availability of host resources for vCenter Server Virtual Machine or Distributed Resources Scheduler (DRS) and Distributed Power Management (DPM) must be disabled.

Distributed Resources Scheduler and Distributed Power Management

44. A vCenter Server VM should be exempt from DRS and DPM, so rules should be configured to prevent resource starvation from the VM running vCenter Server. CESG recommends that vMotion should be on separate physical network cards if DRS or DPM are used. Where this is not possible, CESG requires steps to be taken to ensure the availability of network bandwidth to the management network, and recommends that similar steps be taken for the storage and Red networks.

Distributed Virtual Switch

45. The Distributed Virtual Switch is approved for use across multiple ESXi hosts. The use of Cisco Discovery Protocol has not been assessed.

Host Profiles

46. Host Profiles may be used if all hosts in the cluster are identical hardware. Where hardware is different but network topology is identical, host machines should be divided into different clusters of machines with identical hardware and each profile associated with a single cluster of identical machines. Where

Page 13


network topology is different, host machines should be managed by a separate instance of vCenter Server.

VLANs

47. VLANs may be used for separation of networks in the same security domain (e.g. vMotion and management), and this is encouraged, but must not be used to separate security domains.

NIC Teaming

48. NIC Teaming may be used.

High Availability

49. High Availability (HA) is only approved for detecting host failures. Virtual machine HA, relying on VMware Tools, is not approved. Use of High Availability requires assured availability of the management network. To assure this, CESG recommends that at least one pNIC be dedicated to management traffic and at least one more pNIC (dedicated or shared with storage or vMotion but VLAN separated) be available.

Thin Provisioning (not recommended)

50. Thin provisioning can over-allocate storage resources. CESG recommends allocating the entire virtual disk at the creation of the virtual machine. Thin provisioning is not recommended since over-allocating storage space allows a denial of service attack from the Black machines rapidly increasing their storage requirement. Thin provisioning of either the Red or the Black virtual machines (on a single storage device) is permitted but should be risk managed to avoid starvation. Thin provisioning of both Red and Black machines in the same storage area must be avoided (although it may be risk managed in the same cluster but on different storage devices).

Components that have not been assessed

51. These components have not been assessed, so their use is at the data owner’s risk:

Data Recovery

Fault Tolerance

Hot Add

vSphere Management assistant

PowerCLI

Dynamic Storage Management

Storage I/O Control

Network I/O Control

vCenter Server (linked mode)

Page 14


Alternative management software

52. Some of these components may be assessed in future, if there is sufficient demand.

Components that must not be used

53. These components break the security domain separation enforced by the ESXi architecture. If any of the following are required, CESG consultancy should be sought for risk management:

Virtual Serial Port Concentrator

vShield Zones

vSafe

Virtual Machine Communication Interface (VMCI)

VMware Tools

54. VMware Tools may be installed, but with an important caveat. Many of the host interfaces used by the components of VMware Tools will be locked down or disabled by this guidance; thus, many of the components of VMware Tools will not work correctly. VMware can provide guidance on installing only those tools that may be used.

55. The virtual machine configuration detailed in Chapter 5 - will incur the following restrictions on features and functionality of VMware Tools:

VMware Tools service will not execute correctly

VMware Tools control panel will not execute correctly

Host time synchronisation is disabled

Copy and paste to guest using VMware MKS Console is disabled

Drag-and-drop files to guest using VMware MKS Console is disabled

56. The device drivers contained within the VMware Tools package have been assessed and should be installed using the instructions provided in Appendix B.

Page 15


Chapter 4 - Restrictions on Approved Use

Key Principle

There are some restrictions on the use of VMware vSphere that must be followed for its deployment to be considered approved

Cryptographic Operations

57. Software encryption products running in a virtual machine could make incorrect assumptions as to the amount of entropy they have available. This could result in keys being incorrectly generated within a virtual machine.

58. As a result, a CESG Assisted Products Scheme (CAPS)-approved software product run in a virtual machine does not retain its CAPS approval unless that approval has been annotated to say it still applies in a virtual machine. It may still encrypt sufficiently well for privacy, or for separation within a security domain, but it does not reduce the Protective Marking of the data from RESTRICTED to UNCLASSIFIED.

59. An external source of entropy can mitigate this risk, and CESG expects that CAPS products relying on external entropy will generally be quickly approved for use in virtual machines. In the absence of such approval, customers should seek CESG guidance before deploying a system using external seeding.

60. Similar concerns apply to non-CAPS encryption products: if they obtain their entropy from the virtualised platform, their key strength may be reduced. While CESG policy only applies to CAPS products, anyone deploying non-CAPS encryption products (e.g. FIPS140-2 for personal data) should be aware of this risk, and take steps to mitigate it if necessary.

61. The concerns can also be mitigated by avoiding the use of cryptography within a virtual machine. For example, instead of terminating Transport Layer Security (TLS) links at a server in the virtual machine, they can be terminated at a TLS concentrator in front of the server; this may also have performance benefits.

VMware support

62. Memory dumps from PSODs (VMware ESXi’s ‘purple screen of death’), and log files, may contain sensitive data from the Red-side virtual machines. They must be protectively marked appropriately, and must not be shared with VMware without an approval for release process from the relevant information asset owners.

Third Party Drivers

63. Third party ESXi drivers may introduce vulnerabilities into ESXi. Particular care needs to be taken with the network driver for the Black network interface card. This must be a driver distributed by VMware with ESXi and it must be kept up to date. Drivers not distributed by VMware will not have been tested with ESXi, and may introduce instabilities and other problems.

Page 16


64. CESG recommends that only drivers distributed by VMware are used.

Administration

65. VMware ESXi kernel NICs (vmknics) must not be connected to the Black network for any purpose. As a result, management of Black VMs cannot be done from the Black network. Administration of Black virtual machines, such as restarting a crashed virtual machine, can be done via vCenter Server on the management network, but this will involve vCenter administrators cleared for both the Black and Red sides.

66. CESG recommends not using vCenter Server for the day-to-day administration of services running on VMs, both for performance reasons and to minimise the opportunities for a compromise of vCenter Server. Remote access technologies such as Terminal Services, remote desktop, or a web interface over TLS, are preferred.

Hardware access/passthrough

67. All host hardware used by virtual machines should be presented as virtual hardware managed by ESXi. Virtual machines must not have direct access to physical hardware, such as with a pass-through driver. CESG consultancy should be sought for any system where direct access to hardware is required.

68. For Network interface cards, E1000 and VMXNET3 are the approved virtual devices; other vNICs have not been assessed. CESG recommends that different devices are used for different security domains, so that a successful attack against one device does not lead to an immediate attack against the other device. The E1000 is slightly preferred for the Black security domain, as it is a fully-virtualised device.

Use of Passwords

69. Passwords should follow the guidance in HMG Information Assurance Standard No. 7 (IS7) – Authentication of Internal Users of ICT Systems Handling Government Information (reference [k]).

70. If passwords are written down for storage, they must be given the same protective marking as the data that they are protecting.

Location of use

71. VMware vSphere has not been TEMPEST certified and should only be deployed in an environment where the TEMPEST and/or Electromagnetic Security threat level has been assessed as negligible or low. If VMware vSphere is being considered for deployment in an environment where the threat level is assessed as moderate or above then advice should be sought from CESG. There is, obviously, no TEMPEST separation between virtual machines.

Emergency Plans

72. Although no additional emergency planning is required for VMware vSphere, it is important that the product and any services, particularly essential operations,

Page 17


which are supported are included in any business continuity and disaster recovery plans. Plans should include appropriate storage and handling of key media, as well as system resilience requirements.

Page 18


Chapter 5 - Parameter Settings

Key Principles

Certain parameters must be set to achieve the security of Basic Virtualisation

These settings are in addition to those of the VMware vSphere Hardening Guide

Some virtual machine settings do not survive templating/cloning and must be re-applied

Some host settings are not included in host profiles and must be initially set on each host

Note regarding templates, cloning and deployment of new virtual machines

73. The settings in this Chapter require various settings that are to be applied to a new virtual machine. Some of these settings are not preserved by virtual machines templates or cloning of virtual machines. Creating new virtual machines, whether from scratch, from a template or by cloning an existing virtual machine will need to have the lockdown guidance applied. Appendix B provides further information on how to apply these settings.

Note regarding host profiling

74. Host profiles do not save all host configuration settings specified in these Security Procedures. The host settings below should be applied to each host manually before deployment, rather than using host profiling. Host profiling can be used after this initial setup, as the settings which are not captured by host profiling will not be affected by host profiling operations.

Guideline Organisation

75. This guide will follow the organisation and naming conventions of the VMware vSphere Hardening Guide (references [b] and [c]) for clarity. Threat and risk descriptions may be classified above UNCLASSIFIED and will be referenced in a separate Appendix. The recommended/required row indicates if the guidance is required to be set by CESG or if it only is recommended. Below outlines the three-letter codes identifying the area of vSphere the recommendation refers to:

Virtual Machine

VMX: Virtual machine parameters

VMP: General virtual machine protection

VMware ESXi Host

HIN: Installation

HST: Storage

HCM: Host Communication

HLG: Logging

Page 19


HMT: Management

HCN: Host Console

HPC: Host Procedural Control

VMware vNetwork (Virtual Networking)

NAR: Network Architecture

NCN: vNetwork Configuration

NPN: Physical Network

VMware vCenter Server

VSH: vCenter Server Host

VSC: vCenter Server Communication

VSD: vCenter Server Database

VCL: vSphere Client Components

VUM: VMware Update Manager

Guideline Templates

76. The following guideline templates, adopted for consistency from the VMware vSphere Hardening Guide, are used to specify the appropriate Parameter Settings, Component Configuration and Operational Patterns.

Type A: Parameter Setting

77. This template is used when the recommendation specifies a configuration parameter to set (or not set) in specific products.

PARAMETER ELEMENT DESCRIPTION

Code Code String

Name Short name of guideline

Description Description of the interface or feature that the parameter governs

Threat Description of the specific threat exposed by this feature. Include characterisation of vulnerability. This may be above UNCLASSIFIED and referenced in a classified Appendix

Recommended/Required Recommended or required by CESG

Parameter Setting

Where the parameter is defined, and what are the recommended/required values. Values that must not be set are formatted bold and coloured red. Also indicates if there are preferred ways of setting the value

Effect on functionality If this setting is adopted, what possible effects does it have on functionality? Does some features stop working, is there some information missing from a UI, etc?

Page 20


Type B: Component Configuration

78. This template type is used when the guideline recommends a certain configuration of components, either to reduce risk or to provide a compensating control. Typically, these involve setting some parameter to a site-specific value or installing some components in a manner that satisfies some constraint, so there is no definitive value to be checked against.

CONFIGURATION ELEMENT DESCRIPTION

Code Code String


Description Description of the component being addressed and the configuration being recommended

Risk or Control Description of the risk being mitigated, including characterization of vulnerability if applicable. This may be above UNCLASSIFIED and referenced in a classified Appendix

Recommendation Level Recommended or required by CESG

Parameters or Objects Configuration

All the parameters or objects involved, and how they should be configured

Test Any procedure or way to show evidence that the guideline is being followed, if this is possible

Type C: Operational Patterns

79. This type of template is used to describe recommendations on how to operate or interact with the administrative components of the system.

OPERATIONAL ELEMENT DESCRIPTION

Code Code String


Description Description of the operational pattern or condition

Risk or Control Description of the risk being mitigated. This may be above UNCLASSIFIED and referenced in a classified Appendix

Recommendation Level Recommended or required by CESG

Condition or Steps Concise description of the specific conditions to meet or avoid, and/or the steps needed to achieve this

80. Examples of each of these template types are available in Guideline Templates section of the VMware vSphere Hardening Guide (references [b] & [c]).

Page 21


Virtual Machines

81. The following parameter settings must be applied to each virtual machine configuration. Appendix B has further details on how to apply these settings.


Code CESG_VMX01

Name Disable VMCI

Description

VMCI allows communication between virtual machines and virtual machines to ESXi host. This functionality is not currently used by default; if you would like to use this feature please contact CESG for advice before doing so

Threat When VMCI is enabled, a VMCI device is exposed to the virtual machines. As a precaution CESG requires this device be disabled to lower the attack surface

Recommendation Level Required

Parameter Setting

vmci0.present = “FALSE”

Ensure the following settings aren’t present in the configuration file (x represents a number): vmci0.pciSlotNumber = “xx”

vmci0.id = “xxxxxxxxx”

Effect on functionality VMCI device will not be exposed to the virtual machines.


Code CESG_VMX02

Name Disable VMsafe

Description

VMsafe™ provides a security architecture for virtualized environments and an API-sharing program to enable partners to develop security products for virtualized environments. Although the VMsafe APIs are disabled by default, CESG requires that VMX51 and VMX52 are followed, ensuring it is not enabled

Threat An attacker might compromise all other virtual machines by making use of the VMsafe introspection channel


Parameter Setting

As per VMX51 and VMX52, ensure the following parameters are not present in the VMX file:

ethernetX.networkName=”vmsafe-appliances”

where X is a digit.

vmsafe.enable=TRUE

vmsafe.agentAddress=”www.xxx.yyy.zzz”

vmsafe.agentPort=”nnnn”

Effect on functionality VMsafe will be disabled

Page 22



Code CESG_VMX03

Name Restrict Backdoor

Description The Backdoor provides a method of communication between the virtual machine and ESXi. Applying this setting restricts availability of the backdoor

Threat An attacker might attempt to gain control through the use of the Backdoor channel


Parameter Setting monitor_control.restrict_backdoor = “TRUE”

Effect on functionality The restricted functionality is only used by VMware Tools. Without VMware tools being installed, there should be no noticeable effect on functionality

VMware Hardening Guide Minimum Settings

82. The following settings from the VMware’s hardening guide must be applied as a minimum:

VMX01(Prevent virtual disk shrinking): Enterprise

VMX02 (Prevent other users from spying on administrator remote consoles): DMZ

VMX03 (Disable copy/paste to remote console): Enterprise (4.0 only); this setting has been removed in 4.1, as copy/paste is disabled by default, and it must not be enabled

VMX10 (Ensure that unauthorised devices are not connected): Enterprise

VMX11 (Prevent unauthorised removal, connection and modification of devices): Enterprise

VMX12 (Disable virtual machine-to-virtual machine communication through VMCI): Enterprise

VMX20 (Limit virtual machine log file size and number): Enterprise. We do not recommend the SSLF setting for HMG systems, as that would disable logging

VMX21 (Limit informational messages from the virtual machine to the VMX file ): Enterprise

VMX22 (Avoid using independent nonpersistent disks): DMZ

VMX23 (Use secure protocols for virtual serial port access): Enterprise (4.1 only)

Page 23


VMX24 (Disable certain unexposed features): SSLF (4.1 only)

VMX30 (Disable remote operations within the guest): Enterprise (4.0 only) or SSLF (4.1 only)

VMX31 (Do not send host performance information to guests): Enterprise

VMX51 (Restrict access to VMsafe CPU/memory APIs): Enterprise (4.0 only); this setting has been removed in 4.1

VMX52 (Control access to virtual machines through VMsafe CPU/memory APIs): Enterprise

VMX54 (Restrict access to VMsafe network APIs): Enterprise (4.0 only); this setting has been removed in 4.1

VMX55 (Control access to virtual machines through VMsafe network APIs): Enterprise

VMX56 (Restrict access to VMsafe Network APIs): n/a (4.1 only); the guidance under HMT12 (see below) should be used instead

VMP01 (Secure virtual machines as you would secure physical machines): Enterprise

VMP02 (Disable unnecessary or superfluous functions inside virtual machines ): Enterprise

VMP03 (Use templates to deploy virtual machines whenever possible): Enterprise

VMP04 (Prevent virtual machines from taking over resources): DMZ

VMP05 (Minimize use of the virtual machine console): Enterprise

VMware ESXi Host

83. The ESXi host should be locked down according to the VMware vSphere Hardening Guide (references [b] & [c]). The following settings from the VMware Hardening Guide should be applied:

HIN01 (Verify integrity of software before installation): Enterprise

HIN02 (Keep ESX/ESXi system properly patched): Enterprise (4.1 only, see CESG_HPC01 for 4.0)

HST01 (Ensure bidirectional CHAP authentication is enabled for iSCSI traffic): DMZ

Page 24


HST02 (Ensure uniqueness of CHAP authentication secrets): DMZ (the Specialized Security Limited Functionality (SSLF) level is overkill for most uses, but can be enabled)

HST03 (Mask and zone SAN resources appropriately): Enterprise. While CESG does not consider LUN zoning a sufficient security measure in its own right, it is still better than nothing

HCM01 (Do not use default self-signed certificates for ESX/ESXi communication): Enterprise

HCM02 (Disable managed object browser): SSLF

HCM04 (Ensure that ESX is configured to encrypt all sessions): Enterprise (4.0 only)

HCM05 (Disable Welcome web page): DMZ (4.1 only; see CESG_HCM01 for 4.0)

HCM06 (Use SSL for Network File Copy): not applicable (4.1 only); this setting is unnecessary, assuming that the management network is adequately protected, and VMware warn it has not been extensively tested;

HLG01 (Configure remote syslog): Enterprise

HLG02 (Configure persistent logging): Enterprise

HLG03 (Configure NTP time synchronization): Enterprise

HMT01 (Control access by CIM-based hardware monitoring tools): Enterprise

HMT02 (Ensure proper SNMP configuration): Enterprise

HMT03 (Establish and maintain configuration file integrity): DMZ

HMT10 (Prevent unintended use of VMsafe CPU/memory APIs): Enterprise (4.0 only); this setting has been removed in 4.1

HMT11 (Prevent unintended use of VMsafe network APIs): Enterprise (4.0 only)

HMT12 (Prevent unintended use of VMware VMsafe network APIs): Enterprise (4.1 only)

HMT15 (Audit for loading of unauthorized kernel modules): Enterprise (4.1 only)

HMT20 (Ensure that vpxuser auto-password change meets policy): DMZ (4.1 only)

Page 25


HMT21 (Ensure that vpxuser password meets length policy): DMZ (4.1 only)

HCN01 (Ensure that only authorized users have access to the DCUI): Enterprise (4.0 only)

HCN02 (Enable lockdown mode to restrict root access): Enterprise

HCN03 (Avoid adding the root user to local groups): Enterprise (4.0 only)

HCN04 (Disable tech support mode): SSLF (4.0 only)

HCN05 (Disable DCUI to prevent all local administrative control): SSLF (4.1 only)

HCN06 (Disable Tech Support Mode unless needed for diagnostics and break-fix): Enterprise (4.1 only)

84. The following settings should be applied to comply with CESG guidance.


Code CESG_HPC01 (4.0 only; covered by HIN02 in 4.1)

Name Keep ESXi system properly patched

Description Ensuring ESXi is up to date can mitigate vulnerabilities in the hypervisor

Risk or Control An attacker can obtain access to the ESXi host compromising all VMs and data on that host


Condition or Steps

Ensure the host is kept up to date with patches released by VMware. VMware Update Manager may be used to achieve this. VMware publishes security advisories these should be monitored and acted upon appropriately


Code CESG_HPC02

Name Restrict Access to Host

Description

Access to the physical host must be restricted to only those who are cleared to view RESTRICTED data and have a need to have access. This also applies to terminal access to the server, including out-of-band management consoles such as iLO and DRAC

Risk or Control Access to the physical host could result in compromise of RESTRICTED data, Denial of Service attacks etc


Condition or Steps Seek guidance from SPF Security Policy No. 5 for appropriate physical protection

Page 26



Code CESG_HCM01 (4.0 only; see HCM05 for 4.1)

Name Disable welcome web page

Description

There is a web page accessible from the ESXi hosts management interfaces. This page isn’t needed and so should be disabled to reduce the attack surface and reduce the information displayed about the host

Threat This page may include information about the host useful to an attacker

Recommended/Required Recommended

Parameter Setting Instructions for how to disable the welcome web page can be found in VMware Knowledge Base article 1016039, available at http://kb.vmware.com/selfservice/microsites/microsite.do

Effect on functionality The welcome web page cannot be accessed


Code CESG_HCM02 (4.0 only; see HCM06 for 4.1)

Name Use of SSL for Network File Copy (NFC)

Description NFC is used to migrate or clone VMs between two ESXi hosts over the network. By default SSL is not used for the data transfer

Threat VM contents are visible in the clear on the management network, increasing the risk that an attacker may be able to read them if the management network is not adequately isolated and secured


Parameter Setting

Add the following to vpxd.cfg to enable NFC SSL <config>

<nfc>

<useSSL>true</useSSL>

</nfc>

</config>

Effect on functionality Using SSL for NFC may reduce performance of VM cloning and migrations. VMware advise that using SSL for NFC may cause some operations to fail in certain circumstances

http://kb.vmware.com/selfservice/microsites/microsite.do

Page 27



Code CESG_HCM03

Name Disable Virtual Machine Communication Interface (VMCI) kernel module

Description

The VMCI kernel module enabling VM to hypervisor communication as well as VM to VM communication when in unrestricted mode. These security procedures specify that all virtual machines should be configured to have the VMCI device disabled. If the VMCI kernel module is disabled virtual machines which have configured incorrectly, with the VMCI device enabled, will not power on

Threat When VMCI is enabled, a VMCI device is exposed to the virtual machines and VMKernel. As a precaution CESG requires this device be disabled to lower the attack surface


Parameter Setting

The following command should be executed each time the host powers on: esxcfg-module –u vmci

See Appendix B for more information.

Effect on functionality VMCI kernel module will be disabled. Virtual machines which are configured with a VMCI device present will not power on

VMware vNetwork (Virtual Networking)

General guidance

85. The network must be configured as shown in the architecture diagram. The Black network must use its own vSwitch (or vSwitches) and must use physically independent network cards.

86. The Management, Storage and vMotion networks may contain unfiltered data from the Black Virtual Machines and hence may potentially contain malicious data. Access from the Red network and virtual machines must be restricted. CESG recommends that this is done using separate networks. A VLAN is a permitted alternative. However, vMotion can place high demands on bandwidth, potentially impacting network availability to other services. Hence, where availability assurance is required, CESG requires that the use of Distributed Power Management (DPM) and Distributed Resources Scheduler (DRS) (automatic triggers for vMotion) require vMotion to be on a separate network.

VMware Hardening Guide Minimum and Recommended Settings

87. The minimum settings listed below must be applied, while further settings are recommended as good practice:

NAR01 (Ensure that vSphere management traffic is on a Restricted network): Enterprise at a minimum, with SSLF recommended. The

Page 28


production VM traffic must not be from Black Virtual Machines. These must be isolated on their own vSwitch and pNIC (VLAN is not sufficient separation)

NAR02 (Ensure that vMotion traffic is isolated): SSLF must be used if DRS or DPM are used, and this is still recommended if they are not

NAR03 (Ensure that IP-based storage traffic is isolated): Enterprise at a minimum, with SSLF recommended

NAR04 (Strictly control access to management network): DMZ at a minimum, SSLF recommended (4.0); Enterprise at a minimum, DMZ recommended (4.1)

NCN02 (Ensure that there are no unused ports on a distributed vSwitch port group): DMZ is required for the management, storage and vMotion vSwitches, and recommended for all remaining vSwitches

NCN03 (Ensure that the “MAC Address Change” policy is set to reject): Enterprise recommended. Where this functionality is required, the virtual machines requiring it should run on their own vSwitch, isolated from those that do not require it. VLAN may be used for this isolation

NCN04 (Ensure that the “Forged Transmits” policy is set to reject): Enterprise recommended. Where this functionality is required, the virtual machines requiring it should run on their own vSwitch, isolated from those that do not require it. VLAN may be used for this isolation

NCN05 (Ensure that the “Promiscuous Mode” policy is set to reject): Enterprise recommended

NCN06 (Ensure that port groups are not configured to the value of the native VLAN): Enterprise

NCN07 (Ensure that port groups are not configured to VLAN 4095 except for Virtual Guest Tagging): Enterprise recommended

NCN08 (Ensure that port groups are not configured to VLAN values reserved by upstream physical switches): Enterprise recommended

NCN10 (Ensure that port groups are configured with a clear network label): Enterprise recommended

NCN11 (Ensure that all vSwitches have a clear network label): Enterprise recommended

NCN12 (Fully document all VLANs used on vSwitches): Enterprise recommended

NCN13 (Ensure that only authorised administrators have access to virtual networking components): Enterprise recommended

NPN01 (Ensure that physical switch ports are configured with spanning tree disabled): Enterprise recommended

Page 29


NPN02 (Ensure that the non-negotiate option is configured for trunk links between external physical switches and virtual switches in VST mode): Enterprise recommended

NPN03 (Ensure that VLAN trunk links are connected only to physical switch ports that function as trunk links): Enterprise recommended

VMware vCenter

vCenter Server Host

88. The guidance in VMware’s hardening guide should be applied with VSH06 taking settings from DMZ security level:

VSH01 (Maintain supported operating system, database, and hardware for vCenter): Enterprise

VSH02 (Keep vCenter Server system properly patched): Enterprise

VSH03 (Provide Windows system protection on the vCenter Server host): Enterprise

VSH04 (Avoid user login to vCenter Server system): Enterprise

VSH05 (Install vCenter Server using a service account instead of a built-in Windows account): DMZ

VSH06 (Restrict usage of vSphere administrator privilege): DMZ

VSH07 (Check for privilege re-assignment after vCenter Server restarts); Enterprise (4.1 only)

VSH10 (Clean up log files after failed installations of vCenter Server); Enterprise (4.1 only)

VCenter Server Communication

89. All settings in VMware’s hardening guide for this section should be applied:

VSC01 (Do not use default self-signed certificates): Enterprise

VSC02 (Monitor access to SSL certificates): DMZ

VSC03 (Restrict access to SSL certificates): SSLF

VSC04 (Always verify SSL certificates): Enterprise

VSC05 (Restrict network access to vCenter Server system): DMZ

VSC06 (Block access to ports not being used by vCenter): DMZ

VSC07 (Disable managed object browser): DMZ

VSC08 (Disable vSphere Web Access): DMZ

VSC09 (Disable datastore browser): SSLF

Page 30


VCenter Server Database


VSD01 (Use least privileges for the vCenter Server database user): Enterprise

VCenter Client Components


VCL01 (Restrict the use of Linux-based clients): DMZ

VCL02 (Verify the integrity of vSphere Client): Enterprise

VCenter Update Manager

92. All settings within VMware’s hardening guide should be applied:

VUM01 (Use least privileges for the Update Manager database user): Enterprise

VUM02 (Keep Update Manager system properly patched): Enterprise

VUM03 (Provide Windows system protection on the Update Manager system): Enterprise

VUM04 (Avoid user login to Update Manager system): Enterprise

VUM05 (Do not configure Update Manager to manage its own virtual machine or that of its vCenter Server): Enterprise

VUM06 (Do not use default self-signed certificates): Enterprise (4.1 only)

VUM10 (Limit the connectivity between Update Manager and public patch repositories): DMZ at a minimum, with SSLF recommended

Page 31


Appendix A

VMware Icon and Diagram Copyright and Disclaimer

93. The statements below are regarding CESG diagrams created with official VMware Icons and Diagrams:

This document was created using the official VMware icon and diagram library. Copyright © 2009 VMware, Inc. All rights reserved. This library is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents

VMware does not endorse or make any representations about third party information included in this document, nor does the inclusion of any VMware icon or diagram in this document imply such an endorsement

http://www.vmware.com/go/patents

Page 32


Appendix B

Applying VMX Settings

94. At present no automated method exists for applying the vmx file settings required in this guidance to new virtual machines. After the deployment of a new virtual machine, whether it be from a template, clone of an existing VM or creation of a new virtual from scratch, and before first power up the following settings in the vmx file must be checked for and added or removed as appropriate. A text editor (for example notepad) can be used to open and edit the vmx file.

95. Recommended settings in the vmx file and settings from VMware’s hardening guide (reference [b]) file are not detailed here. However, the same method of editing the vmx file should be used to check for and preserve these.

96. Editing the vmx files should be done the following order

1. Remove the virtual machine from vCenter server inventory

2. Download the vmx file from the appropriate datastore

3. Edit the vmx file according to the guidance

4. Upload the vmx file to the appropriate datastore, overwriting the original vmx file

5. Add the newly edited vmx file to the vCenter server inventory

97. The virtual machine must be removed from and then added to the vCenter server inventory to refresh vCenter server’s virtual machine database.

Settings that must be applied manually to each virtual machine

98. The following settings are not preserved by cloning a virtual machine or by the use of templates. They must be changed by editing the vmx file every time a new virtual machine is created. The virtual machine must then be removed from the vCenter server’s inventory and then added again to refresh vCenter server’s virtual machine database.

Settings that must be present that are not preserved by default

vmci0.present = “false”

Settings that must not be present that are added by default

vmci0.present = “true”

vmci0.pciSlotNumer = “xx”

vmci0.id = “xxxxxxx”

Settings that must be applied that are preserved

99. The following settings must be applied to any new virtual machine created. Once applied, the cloning to a template, deployment of a virtual machine from a

Page 33


template and cloning of a virtual machine operation preserve these settings. They only need to be applied once to new virtual machines created from scratch.

Settings that must be present

monitor_control.restrict_backdoor = “TRUE”

Settings that must not be present

ethernetX.networkName = ”vmsafe-appliances”

where X is a digit.

vmsafe.enable = “TRUE”

vmsafe.agentAddress = ”www.xxx.yyy.zzz”

vmsafe.agentPort = ”nnnn”

Virtual machine deployment and VMware Tools advice

100. CESG recommends that virtual machines are first created in pre-deployment configuration, without any vNICs added to the virtual machine hardware configuration.

101. As this guidance requires the monitor_control.restrict_backdoor

setting to be set to TRUE installing VMware Tools, and therefore VMware

drivers, can be problematic.

102. Before the guidance from the VMware hardening guide (reference [c]) and this document is applied the virtual machine’s operating system should be installed.

103. Once the operating system has been installed VMware Tools should be installed as normal.

104. After installing VMware Tools the virtual machine can now be prepared for deployment. The virtual machine must be powered down, vNICs added and the configuration settings from VMware’s hardening guide and this document applied.

105. Once the above steps have been completed you may now deploy the virtual machine by either simply powering it on, or preferably creating a template from this virtual machine to be deployed. Before each deployed virtual machine is powered on the configuration must be edited to ensure all configuration settings are present, see Applying VMX Settings (paragraph 94).

Applying Host Settings

Disabling kernel modules

106. At present no method exists to persistently disable the VMCI kernel module. The VMCI kernel module may be unloaded on the host but this must be done on every boot of the host.

Page 34


107. To list the current kernel modules loaded the following command can be executed:

esxcfg-module –l

This can be piped to grep to search for specific module status. For example:

esxcfg-module –l | grep vmci

108. There exists a command to disable kernel modules:

esxcfg-module –d <module name>

However, this command does not work correctly in ESXi as ESXi is loaded from an image at boot.

Page 35


References Unless stated otherwise, these documents are available from the CESG website. Users who do not have access should contact CESG Enquiries to enquire about obtaining documents. [a] CESG IA Good Practice Guide No 12, Use of Virtualisation Products for Data

Separation: Managing the Security Risks (Not Protectively Marked) – latest issue available from the CESG website.

[b] VMware vSphere 4.0 Security Hardening Guide – May 2010. Available at: http://www.vmware.com/resources/techresources/10109.

[c] VMware vSphere 4.1 Security Hardening Guide – June 2011. Available at: http://www.vmware.com/resources/techresources/10198.

[d] CESG IA Developers’ Note No 11, Requirements and Recommendations for a Basic Virtualisation Product (UNCLASSIFIED) – latest issue available from the CESG website.

[e] CESG IA Good Practice Guide No 8, Protecting External Connections to the Internet (Not Protectively Marked) – latest issue available from the CESG website.

[f] HMG Security Policy Framework (SPF) Tiers 1-3 (Not Protectively Marked) are available at: http://www.cabinetoffice.gov.uk.

[g] HMG IA Standard Nos. 1 & 2, Technical Risk (Not Protectively Marked) – latest issue available from the CESG website.

[h] HMG Information Assurance Standard No 4, Protective Security Controls for the Handling and Management of Cryptographic Items (OFFICIAL SENSITIVE) – latest issue available from the CESG website.

[i] HMG Information Assurance Standard No 5, Secure Sanitisation (OFFICIAL) – latest issue available from the CESG website.

[j] RFC 2119 – Key words for use in RFCs to Indicate Requirement Levels – March 1997. Available at: http://www.ieft.org/rfc/rfc2119.txt

[k] HMG Information Assurance Standard No 7, Authentication of Internal Users of ICT Systems Handling Government Information) – latest issue available from the CESG website.

http://www.vmware.com/resources/techresources/10109

http://www.vmware.com/resources/techresources/10198

http://www.security-matters.gsi.gov.uk/

http://www.ieft.org/rfc/rfc2119.txt

Page 36


Glossary CAPS CESG Assisted Products Scheme

CESG The UK National Technical Authority for Information Assurance

CHAP Challenge Handshake Authentication Protocol

CIM Common Information Model

DCUI Direct Console User Interface of ESXi

DMZ De-militarised zone

DPM Distributed Power Management, a component of vSphere

DRAC Dell Remote Access Controller

DRS Distributed Resources Scheduler, a component of vSphere

ESXi VMware’s bare-metal hypervisor, a component of vSphere

IDE Integrated Drive Electronics, a common hard-drive interface

iLO Integrated Lights-Out

LUN Logical Unit Number

NAS Network Attached Storage

NFS Network File System.

NTP Network Time Protocol

pNIC Physical Network Interface Card

PSOD “Purple Screen of Death”, the ESXi fatal error display

RDM Raw Device Mapping

SAN Storage Area Network

SNMP Simple Network Management Protocol

SSL Secure Sockets Layer

Security Domain One or more virtual machines that share a common threat model

SSLF Specialized Security Limited Functionality

TEMPEST The phenomenon and investigation of compromising emanations

TLS Transport Layer Security

vCenter Server VMware’s management software, a component of vSphere

VLAN Virtual Local Area Network

VM Virtual Machine

VMCI Virtual Machine Communication Interface

VMDK Virtual Machine Disk, the VMware virtual disk file format

VMFS Virtual Machine File System, a VMware file system

Page 37


vmknic VMware kernel network interface card

vMotion Live migration of virtual machines, a component of vSphere

VMsafe A VMware security architecture and API

vmx file Virtual Machine configuration file

vNIC Virtual Network Interface Card

vSphere VMware’s enterprise virtualisation product

vSwitch Virtual Switch, a component of vSphere

Page 38


Points of Contact CESG Enquiries Hubble Road Cheltenham GL51 0EX Telephone: 01242 709141 Email: [email protected]

VMware UK Limited UK Headquarters Theta Building Lyon Way, Frimley Camberley GU16 7ER Telephone: 08000 327 597 / 0800 882 408

mailto:[email protected]

CESG provides advice and assistance on information security in support of UK Government. Unless otherwise stated, all material published on this website has been produced by CESG and is considered general guidance only. It is not intended to cover all scenarios or to be tailored to particular organisations or individuals. It is not a substitute for seeking appropriate tailored advice.

CESG Enquiries Hubble Road Cheltenham Gloucestershire GL51 0EX Tel: +44 (0)1242 709141 Email: [email protected] © Crown Copyright 2015

Documents

Security Procedures for VMware vSphere · VMware vSphere Page 1 4.0 & 4.1 Intended Readership These CESG Security Procedures should be used by System Designers, Risk Managers and