VMware® View™ Security Hardening Guide - VMware Communities

VMware® View™ Security Hardening Guide W H I T E PA P E R

VMware® View™ Security Hardening Guide

Table of Contents VMware® View™ Security Hardening Guide Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Endpoint Hardening Practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 VMware View Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 PCoIP Endpoints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 VMware View Connection Server and Security Server Hardening . . . . . . . . . . . . . . . . . . 4 VMware vCenter Server & VMware ESX Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Detailed Recommendations for VMware View Security Server Hardening . . . . . . . . . 6 Parameter Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Component Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Operational Patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 View Security Server Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 VMware View Security Server Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 VMware View Security Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Guest Operating System Hardening – Windows 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 PowerShell Execution Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Local Mode Hardening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Kiosk Mode Hardening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Infrastructure Hardening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Keystore Hardening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Additional Security Practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Network Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Role-Based Access Control (RBAC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

W H I T E PA P E R / 2

VMware® View™ Security Hardening Guide

VMware View Security Hardening Guide Introduction This document provides general guidelines for security hardening practices across VMware® View™ components, setting role-based administration and user privileges, and deployment scenarios. Your organization may need to meet specific security standards to satisfy regulatory requirements based on your vertical industry. Since these standards and other compliance and regulatory requirements change frequently, this document does not attempt to address them; however, it is strongly advised that you understand these standards, why they are established, and how to adhere to them.

Endpoint Hardening Practices VMware® View™ Client VMware View Client always runs on the existing operating system (for example, Windows, MAC OS, or Linux) at the endpoint device. A good hardening practice is to enable and enforce endpoint 128-bit AES encryption. Endpoint devices such as thin clients, zero clients, mobile devices, and tablets are less vulnerable by nature because of the reduced attack surface and lockdown environment; however, it is recommended to keep the devices up to date with the latest firmware and security fixes. Specific recommendations for devices running soft clients include the following: • Utilize standard Windows hardening practices • Create, deploy, and maintain password protection policies • Keep software and security patching up to date • Verify firewall requirements • Install a reliable antivirus solution • Utilize endpoint intrusion prevention systems such as Cisco Security Agent • Use Active Directory, RSA SecurID or smartcard authentication • Deploy VMware View ADM templates to enable the list of brokers trusted for delegation, to disable third-party terminal services plugins, and to disable single-sign-on (extreme security precaution)

W H I T E PA P E R / 3

VMware® View™ Security Hardening Guide

PCoIP Endpoints The PCoIP Management Console enables administrators to centrally manage PCoIP endpoints equipped with Tara chipsets. It runs as a slim appliance on VMware® Player™ or VMware® vSphere™ infrastructure and can be used to do the following: • Access and update the configuration of all PCoIP devices • Apply the same configuration data to groups of devices • Update device firmware • Reset devices • Control the power state of host devices • View status information • Manage the monitoring of device event logs The PCoIP Management Console has a simple and intuitive web interface for device administration. Different profile templates can be created and applied to those management groups.

VMware View Connection Server and Security Server Hardening In a VMware View architecture, both Connection Server and Security Server services are run on Windows Server platforms and are therefore subject to the OS attack surface. The same hardening techniques utilized for your common Windows Server infrastructure should be used here and they include (but are not limited to) the following: • Utilize standard Windows hardening practices • Create, deploy, and maintain password protection policies • Keep software and security patching up to date • Verify firewall requirements • Install a reliable antivirus solution • Disable unneeded ciphers • Disable unneeded services and network protocols (only IPv4 needed) It is very common to see administrators disabling services in the Guest OS to optimize the end-user experience as well as to reduce the attack surface. Additional recommended practices include: • Replace default self-signed certificates with those from a trusted certification authority (either a commercial CA or an organizational CA) • Make sure all communications between View Clients and Security Servers or Connection Servers use HTTP over SSL3/TLS1 Security servers are a critical piece in your DMZ and expose the Windows attack surface to the external world. Make sure all hardening guidelines are strictly followed and that neither the virtual or physical Windows are members of the domain. All items listed above will apply to the Security Servers but in addition, if possible, utilize a different vSphere infrastructure to support your DMZ. The reason: despite the creation of multiple vSwitches, in a single host the virtual switching happens in a single process. And of course, make sure your security advisory board is comfortable with the solution. W H I T E PA P E R / 4

VMware® View™ Security Hardening Guide

Additional global security settings related to the overall VMware View solution that you might need to consider include: • Authentication method • Using Security Server or VPN for remote access • Firewall requirements • Setup of administrative RBACs • Limiting the Root Administrator role to a small number of individuals • Working with more restrictive built-in roles whenever possible • Using custom roles for specific needs For large deployments, organize resources (pools) into folders and delegate administrative roles to the folders (by geographical location, business unit, function, or compliance): • User entitlements • Desktop zoning and user data zoning • Multi-tenancy

VMware vCenter Server & VMware ESX Server Because vCenter Server runs on a Windows host, it is especially critical to protect this host against vulnerabilities and attacks. The standard set of recommendations applies: install antivirus agents, spyware filters, password protection, intrusion detection systems, and any other security measures. Verify your firewall requirements, and make sure to keep all security measures up-to-date, including application of patches. In addition: • Limit vCenter Server to highly privileged administrators, and then only for the purpose of administering vCenter Server or the host operating system • Install vCenter Server using a service account instead of a built-in Windows account • Restrict usage of the vSphere Administrator Privilege • Block access to ports not being used by vCenter • Replace default self-signed certificates with those from a trusted certification authority (either a commercial CA or an organizational CA) • Monitor and restrict access to SSL certificates—the directory that contains the SSL certificates only needs to be accessed by the service account user on a regular basis; occasionally, the vCenter Server system administrator might need to access them for support purposes • Disable unneeded services and network protocols There are a number of hardening recommendations for vCenter Server and ESX Server that are covered in the vSphere 4.0 Security Hardening Guide published by VMware. You can consider running the  “vmwarevSphereSecurityHardeningReportCheck” Perl script to retrieve the security check and email notifications.

W H I T E PA P E R / 5

VMware® View™ Security Hardening Guide

Detailed Recommendations for VMware View Security Server Hardening VMware View Security Server is recommended for DMZ deployments or environments with distinct networks. It helps connect to a VMware View Connection Server (VCS) and handles the secure tunnel termination from the VMware View Client installed at the endpoint device using packet-oriented AJPv13 and JMS communication with the VMware Connection Server. VMware View Security Server ensures only authenticated users to gain access from one network to another. With the correct firewall rules in place, virtual desktop access is possible only for authenticated users. Only authenticated users on an allowed protocol can access the datacenter. In addition, VMware View Security Server ensures that users can access only those virtual desktop resources for which they are authorized or entitled. A VMware View Security Server acts as an SSL offload, handling all HTTPS processing and all desktop protocol traffic that would otherwise occur on the VMware View Connection Server. For large deployment scalability and high availability (HA), please refer to the VMware View Architecture and Planning Guide.

Parameter Setting Specific products allow you to set (or not set) parameters, for example, VMware View Connection Server parameters such as authentication methods, or VMware View Security Server SSL settings. VMware is developing recommendations and best practices for these parameter settings. For example: • Configuring a Connection Server session timeout: Having a very long session timeout can increase the risk of neglected session hijacking. The Connection Server session timeout controls how long users can keep their session open after logging onto a Connection Server, after which time they need to re-authenticate to the Connection Server. The default is 10 hours and is specified in minutes. This setting is defined through VMware View Administrator in VMware View Configuration Global Settings. It applies to all Connection Servers in a replicated group. The default value of 600 minutes is recommended. After the session timeout has expired, a user connected to VMware View Connection Server will be logged off and will be required to log on again.

Component Configuration These recommendations apply to certain configurations of components, either to reduce risk or to provide a compensating control. Typically, they involve setting a parameter to a site-specific value or installing components in a manner that satisfy appropriate constraints, and so there is no definitive value to be checked against. Examples include configuring a time synchronization server, or protecting VMware View Security Servers with an external firewall. VMware is developing recommendations and best practices for these component configurations. For example: • Use a time synchronization server for VMware View Security Servers. Every VMware View Security Server should synchronize its time clock from a time synchronization server. Having an incorrect time clock on a Security Server makes SSL server certificate validation periods inaccurate and log analysis difficult. The recommendation: Configure all VMware View Security Servers to use the same reliable external time synchronization server. Use the date and time setting on the Windows OS to specify the name of an external time synchronization server. To test, verify on each Security Server that the clock is accurate and that it is set to synchronize from an external time source.

W H I T E PA P E R / 6

VMware® View™ Security Hardening Guide

Operational Patterns These recommendations apply to operating or interacting with the system administrative components, i.e. use SSL server certificates signed by a certificate authority, and use OCSP to manage certificate revocation when using smart card authentication. Again, VMware is developing recommendations and best practices for these operational patterns. For example: • Do not use the default self-signed server certificates on a VMware View Security Server. When VMware View Security Server is first installed, the SSL server defaults to self-signed certificates. These should be replaced by SSL server certificates signed by a commercial certificate authority (CA) or an organizational CA. The use of default certificates leaves the SSL connection more vulnerable to man-in-the-middle attacks. Changing the default certificates to trusted CA signed certificates mitigates the potential for this type of attack. Use a Web browser to make an HTTPS connection to the VMware View Security Server, using the capabilities within the browser to view the server SSL certificate. To test, verify that it is signed by the appropriate CA.

View Security Server Host View Security Server runs on Windows Server 2003 or Windows Server 2008. It is critical to protect this host against normal operating system vulnerabilities and attacks. The standard set of recommendations applies: install antivirus agents, spyware filters, intrusion detection systems, and other security measures according to your organization’s policies; and make sure to keep all security measures up-to-date, including the application of operating system patches. The following additional recommendations apply: • Keep VMware View Security Server system properly patched. By staying up to date on Windows patches, vulnerabilities in the OS can be mitigated. Employ a system to keep the VMware View Security Server system up to date with patches, in accordance with industry-standard guidelines, or internal guidelines where appropriate. • Provide Windows system protection on the VMware View Security Server host. Attackers who can obtain access and elevate privileges on the VMware View Security Server system can then take over the entire vSphere deployment. By providing OS-level protection, vulnerabilities in the OS can be mitigated. This protection includes antivirus, anti-malware, and other similar measures. Provide Windows system protection, such as antivirus, in accordance with industry-standard guidelines, or internal guidelines where appropriate. • Restrict administrative Windows login. The number of administrators with rights to perform administrative login to a VMware View Security Server should be minimized and carefully controlled. Create specific administrative login accounts for individuals and make those accounts a member of the local administrator’s group. • Implement an administrative password policy. If an unauthorized administrator gains access to the Security Server, then it is vulnerable to unauthorized modification. Therefore, set a password policy for all VMware View Security Servers. This should include minimum length, character types, and requirements to periodically change passwords. Set a password policy on each VMware View Security Server. • Remove unnecessary network protocols. If unnecessary protocols are enabled, the VMware View Security Server can be more vulnerable to network attack. View Security Server only uses IPv4 communication; other protocols such as file and printer sharing for Microsoft Networks and Novell IPX should be removed. In the Control Panel on each VMware View Security Server, look at the properties of each network adapter and remove or uninstall protocols that are not required. • Disable unnecessary Windows services. If unnecessary Windows services are running, the View Security Server can be more vulnerable to network attack. View Security Server only requires a small number of Windows services to be running. Security is enhanced when unnecessary services are disabled in Windows. This prevents them from automatically starting at boot time. Ensure that no Server roles are enabled. Disable any Windows services that are not required.

W H I T E PA P E R / 7

VMware® View™ Security Hardening Guide

VMware View Security Server Deployment View Security Servers are usually deployed in a DMZ to carefully control access from VMware View clients accessing VMware View over a hostile network such as the Internet. In a DMZ it is important to control network protocol access using a firewall. In addition, adhere to the following recommendations: • Use a time synchronization server for VMware Security Servers. An incorrect time clock on a Security Server makes SSL server certificate validation periods inaccurate and makes log analysis difficult. Therefore every VMware View Security Server should synchronize its time clocks from a time synchronization server. Configure all VMware View Security Servers to use the same reliable external time synchronization server. Use the date and time setting on the Windows OS to specify the name of an external time synchronization server. To test, verify on each Security Server that the clock is accurate and that it is set to synchronize from an external time source. • Use an external firewall in the DMZ to control network access. VMware View Security Servers are normally deployed in a DMZ. It is important to carefully control which protocols and network ports are allowed so that communication with VMware View Security Server is restricted to the minimum required. VMware View Security Server automatically handles TCP forwarding to virtual desktops within a datacenter and ensures that all forwarded traffic is only on behalf of authenticated users. Configure a firewall on either side of a VMware View Security Server to restrict protocols and network ports to the minimum set required between VMware View clients and the VMware View Security Server. Similarly, for communication between the VMware View Security Server and the datacenter, limit the protocols and network ports from the VMware View Security Server. To limit the scope of frame broadcasts, VMware View Security Servers should be deployed on an isolated network. This topology can help prevent a malicious user on the internal network from monitoring communication between the security servers and VMware View Connection Server instances. You may want to use advanced security features on your network switch to prevent malicious monitoring of VMware View Security Server communication with VMware View Connection Servers, and to guard against monitoring attacks such as ARP Cache Poisoning. See the administration documentation for your networking equipment for more information.

Vmware View Security Server Configuration • Do not use the default self-signed server certificates on a VMware View Security Server. When VMware View Security Server is first installed, the SSL server defaults to self-signed certificates. These should be replaced by SSL server certificates signed by a commercial Certificate Authority (CA) or an organizational CA. The use of default certificates leaves the SSL connection more vulnerable to man-in-the-middle attacks. Changing the default certificates to trusted CA Signed certificates mitigates the potential for these attacks. Information on how to replace VMware View Security Server SSL certificates can be found in the VMware View Administration Guide. To test, use a Web browser to make an HTTPS connection to the VMware View Security Server and use the capabilities within the browser to view the server SSL certificate. Verify that it is signed by the appropriate CA. In summary, VMware Security Servers play a critical role in your DMZ. Make sure all hardening guidelines are strictly followed and that the virtual or physical Windows systems are not in the same domain as the DMZ. All recommendations from this document will apply to the VMware View Security Servers. If possible, utilize additional VMware vSphere infrastructure products, such as VMware vShield, to support your DMZ instead of just creating or virtualizing multiple vSwitches. The reason for this is despite the creation of multiple vSwitches in a single host, virtual switching executes in a single kernel process. In general, you should minimize allowable ports and services available beyond the necessary ports required for display protocol (such as PCoIP), and follow the strictest firewall practices to harden your deployment. For large deployments, you should consider organizing resources pools into folders, then delegating administrative roles to the folders by geographic location, business unit, function, compliance, and so on.

W H I T E PA P E R / 8

VMware® View™ Security Hardening Guide

Guest Operating System Hardening – Windows 7 When deploying Windows 7, Office 2010, and Windows Server 2008 R2 with the Microsoft Deployment Toolkit 2010 Update 1, MDT is the recommended process and toolset for automating desktop and server deployment. For detailed information see: • Mastering VDI Templates updated for Windows7 and PCoIP (http://myvirtualcloud.net/?p=929) • VMware View Optimization Guide for Windows 7 (http://www.vmware.com/resources/techresources/10157) You will need to select among a large number of features and determine what will or will not be available to your users. In most cases administrators will automate the installation of the VMware View Client. It is important to know the command line parameters and features available to customize the deployment. There is essential information in the Administrator’s Guide and VMware View 4.5 Command Line Usage for deploying only the feature set required. As a guideline, here are the key items to consider when hardening the parent VM: • Base OS hardening • Refresh intervals (recompose/refresh) • Antivirus (http://www.vmware.com/resources/techresources/10089) • Patch base OS • View agent - USB devices and redirection - Drive redirection - Clipboard redirection - Printer redirection - GINA chaining - Offline/Local Mode - Single sign-on - Display protocols available - Smartcards When you are automating the installation of the VMware View Client, it is important to know the command line parameters and features available to customize the deployment. Refer to “VMware View 4.5 Command Line Usage” (http://myvirtualcloud.net/?p=1368P) for a rundown of almost all properties available do deploy and execute View components. Additional considerations include: • Some settings are managed by View Agent and others are managed by Active Directory GPO. Utilize the Mastering VDI Templates updated for Windows7 to know what you can manage in each level. • Guest/Host cut & paste and USB Access are controlled by the View Manager. Read the community article “Disabling Copy & Paste in PCoIP”. • Define your patch management strategy. Perhaps you will apply patches to the parent VM and recompose all virtual desktops once a month or every week, but what will you do in regards to critical updates? Your patch management strategy may or may not include a combination of recompose and standard patch management tools such as WSUS, SCCM and Altiris.

W H I T E PA P E R / 9

VMware® View™ Security Hardening Guide

PowerShell Execution Policy If you administered Windows XP, Windows PowerShell might not have been on the system, so the possibilities for management were limited. With Windows Vista and Windows Server 2008, Windows PowerShell 1.0 is available in the operating system. With Windows 7 and Windows Server 2008 r2, Windows PowerShell 2.0 is provided by default. Windows PowerShell provides a great deal of flexibility in using the shell for your automations and administrative tasks, but it also means that you need to consider a safe way to prevent users from running untrusted scripts. The AllSigned execution policy is the setting that most people consider to be the safe option. AllSigned requires that all scripts and configuration files be signed by a trusted publisher, including scripts that you write on the local computer. If you are a system administrator, you might want to set the execution policy to AllSigned for your non-technical users so that they are allowed to run a subset of safe scripts. Non-technical users who are administered by you will then be allowed to execute only the scripts that you have signed for them. When Windows PowerShell is first installed, it can be used interactively, but it won’t run scripts because the execution policy is set to the default of restricted. You can view the execution policy with the Get-ExecutionPolicy cmdlet. Accounts with administrator privileges can modify the policy with the following code:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

This is a good compromise because it allows local scripts to run, but it blocks scripts from the Internet or UNC mapped drives unless they are signed with a code-signing certificate that the system can accept. For more information about PowerShell execution policy settings, you can refer to Microsoft PowerShell 2.0 Best Practices published by Microsoft Press.

W H I T E PA P E R / 1 0

VMware® View™ Security Hardening Guide

Local Mode Hardening Malware on the host is the most common security concern and it is a legitimate one. As of today, the best practice advice for a customer with concerns in this area would be to pair the use of Local Mode with leading SSL VPN solutions on the host. The diagram below illustrates the Local Mode checkout flow with Transfer Server (TS) repository.

Figure 1: Local Mode deployment and provisioning

If the remote computer passes a pre-login assessment associated with a particular endpoint profile configured on the security appliance, a scan of the antivirus, anti-spyware, personal firewall, and other optional keylogger, file, registry, and process checks occurs. An advanced endpoint assessment option is available to automate the process of repairing out-of-compliance applications. This scan can be turned on or off by the system administrator. The administrator will then be able to configure rules that will be enforced on the endpoint machine for remediation purposes. These rules include: • Antivirus: brand and version, force file system protection (if the program supports this action), force virus definitions update - if not updated in last x days (if the program supports this action) • Personal Firewall: brand and version, firewall action (none, enable or disable; if the firewall supports that action), rules - allow or disallow applications or ports (if the FW program supports this action) • Anti-spyware: brand and version, force spyware definitions update - if not updated in last x days (if the AS program supports this action) In addition, sophisticated role-based posture checks with quarantine and remediation functions could be provided using the mainstream SSLVPN solutions.

W H I T E PA P E R / 1 1

VMware® View™ Security Hardening Guide

To meet the special security requirements of employee departure and information retrieval, Local Mode has three synergistic capabilities: • AES encryption of the virtual machine • Max time without server contact policy • AD based entitlements The virtual machines in Local Mode are all encrypted and the end user does not have direct access to the keys to unlock them. The keys are stored in the ADAM database on the server. The user’s access is then gated and granted access by the View Connection. A special keystore that is encrypted with the user’s own credentials is stored on disk for offline access. It is also possible to configure a “max time without server contact” to a number that is the longest time they can accept a user getting access to checked-out data post termination (and balancing that against how long certain users need to be off network, on the plane, business trips, and so on) without server contact. When an employee or contractor is not with a company, their entitlement to the desktop will be revoked in AD and View. At this point, the next time that system comes in contact with the server and the user attempts to log in, their access to the encrypted virtual machine will be revoked and their cached keystore will be removed. If a user never attempts to log in, or avoids network contact with the datacenter, their access to the virtual machine will be automatically blocked after the “max time without server contact” expires. At this point, the View Client itself will block access to the virtual machine, and the user will find the AES-encrypted virtual machine useless. For advanced superusers, consider using smart-card/PIN-based authentication rather than username/ password. The superuser’s attack is based on them knowing the credentials they used to login before. Without the smart cards, all the encrypted data left on the hard drive (or copy they made) is useless since users will no longer have a means to decrypt the keystore.

Kiosk Mode Hardening Kiosk Mode refers to using client ID or MAC addresses to tie together with the virtual desktop and bypass any manual logon process in View Client. Depending on the use cases, a basic hardening process can be put in place such as using GPO to disable USB devices not required in the kiosk station, or to disable cut-and-paste features since the kiosk is standalone without staff attendance.

Infrastructure Hardening For general security hardening practices, it is always recommended to keep the number of ports open to a minimum in a firewall-protected deployment environment, and to have a policy to manage ports in such environments. In addition, for applications in base virtual machine, consider the following: • Remove unneeded default applications • Restrict access to administrative applications • Restrict access to deployed applications

W H I T E PA P E R / 1 2

VMware® View™ Security Hardening Guide

Keystore Hardening Objects needed for SSL communication, including private keys, digital certificates, and trusted CA certificates, are stored in keystores. To meet security requirements, administrators should do the following: • Manage certificates in a keystore file • Secure them using file system permissions on the directory install_directory\VMware\VMware View\Server\ sslgateway\conf\

Additional Security Practices Network Security On the network security side, consider using a stateful inspection network firewall or vShield virtual firewall with a default-deny rule set and exceptions. Also, any Internet-facing server, such as Security Server, belongs in a DMZ with strong default-deny rules on the firewall to prevent data exfiltration. You can use a network IDS/IPS to monitor and prevent known attacks. For the SQL server configured for event monitoring or View Composer, put the database on an internal network, not the DMZ. This will also help harden your VMware View installation.

Figure 2: End-to-end security with vShield product family

W H I T E PA P E R / 1 3

VMware® View™ Security Hardening Guide

For vSphere-based environments, vShield solutions provide capabilities to secure the edge of the vDC, protect virtual applications from network-based threats, and streamline antivirus protection for VMware View deployments by offloading AV processing to dedicated security virtual machines. These new product offerings can start securing infrastructure almost immediately since all the underlying compute resources are already present in the vSphere environment. These same solutions in the traditional security model would have taken months to authorize and provision in the physical data center. The diagram below is a sample View multi-tenancy proof of concept with vShield components inserted in the architecture.

DC vShield App: an alternative to VLANs for segmentation and L2 isolation of virtual workloads. Plus, provides firewalling between virtual workloads

SS

CB VM

VC

VC & SQL

VC & SQL

vShield Edge: can provide DHCP services to all workloads within a port group VLAN

CB VM

SQL

DHCP ESX

SAN

VM

ESX

VM

wa re E

SX

VM

wa re E

VM

SS

CB

CB VM

VM

SX wa re ES X

DHCP

VM

VLAN

vShield Edge: edge network security to route (vShield 2.0) and firewall between different virtual networks

vShield Endpoint: AV protection of View workloads

DHCP

MPLS

DC

VLAN

WWW

DC

VM

VM

VM

VM

VM

VM

VM

VM

DHCP

VLAN

WWW

Figure 3: Using vShield product family in View deployment for multi-tenancy

Role-Based Access Control (RBAC) VMware View 4.5 supports Role-Based Access Control systems based on a user’s roles and responsibilities. Users aren’t given access to systems, but the roles are. In an RBAC, the administrator centrally manages the roles. Roles can effectively be implemented using security groups. Start by creating a security group representing each role. Then, assign permissions and rights to these groups. Depending on their job functions, you can add the users to the applicable security groups. For more information about the RBAC deployment, refer to the Chapter 2, “Configuring Role-Based Delegated Administration” in the VMware View Administrator’s Guide.

W H I T E PA P E R / 1 4

VMware® View™ Security Hardening Guide

Summary It is almost impossible to provide a single document with security hardening techniques that will just fit into your datacenter, private cloud, hybrid cloud or public cloud environment. Therefore, it is important that you know and understand the rules and regulations that affect your organization. As the majority of View components are based in Windows systems, the best practices for Windows system administration should be considered for hardening practices. A large portion of security comes down to authentication, authorization, accounting, and access control. In either physical or virtual environments, you want to know who is accessing your environment and what occurred in the access. You must take the necessary precautions and institute the necessary controls to ensure that only individuals who have authorization to have access can access the environment.

Contributors This document was co-authored by Andre Leibovici, Mark Benson, Gargi Mitra Keeling and Robert Baesman. Key content was contributed and consolidated by Cynthia Hsieh, who is the technical marketing manager primary responsible for the solution management and security related practices in the End User Computing Group at VMware.

VMware, Inc. 3401 Hillview Avenue Palo Alto CA 94304 USA Tel 877-486-9273 Fax 650-427-5001 www.vmware.com Copyright © 2011 VMware, Inc. All rights reserved. This product 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 is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies. Item No: VMW_11Q1_WP_SecHardeningGd_EN_P15