Security considerations and best practices

Note:

Your organization may need to meet specific security standards to satisfy regulatory requirements. This document does not cover this subject, because such security standards change over time. For up-to-date information on security standards and Citrix products, consult https://www.citrix.com/security/.

Security best practices

Keep all machines in your environment up to date with security patches. One advantage is that you can use thin clients as terminals, which simplifies this task.

Protect all machines in your environment with antivirus software.

Consider using platform-specific anti-malware software such as the Microsoft Enhanced Mitigation Experience Toolkit (EMET) for Windows machines. Some authorities recommend using the latest Microsoft-supported version of EMET within their regulated environments. Note that, according to Microsoft, EMET may not be compatible with some software, so it should be thoroughly tested with your applications before deployment in a production environment. XenApp and XenDesktop have been tested with EMET 5.5 in its default configuration. Currently, EMET is not recommended for use on a machine that has a Virtual Delivery Agent (VDA) installed.

Protect all machines in your environment with perimeter firewalls, including at enclave boundaries as appropriate.

If you are migrating a conventional environment to this release, you may need to reposition an existing perimeter firewall or add new perimeter firewalls. For example, suppose there is a perimeter firewall between a conventional client and database server in the data center. When this release is used, that perimeter firewall must be placed so that the virtual desktop and user device are on one side, and the database servers and Delivery Controllers in the data center are on the other side. Therefore, consider creating an enclave within your data center to contain the database servers and Controllers. Also consider having protection between the user device and the virtual desktop.

All machines in your environment should be protected by a personal firewall. When you install core components and VDAs, you can choose to have the ports required for component and feature communication opened automatically if the Windows Firewall Service is detected (even if the firewall is not enabled). You can also choose to configure those firewall ports manually. If you use a different firewall, you must configure the firewall manually.

Note: TCP ports 1494 and 2598 are used for ICA and CGP and are therefore likely to be open at firewalls so that users outside the data center can access them. Citrix recommends that you do not use these ports for anything else, to avoid the possibility of inadvertently leaving administrative interfaces open to attack. Ports 1494 and 2598 are officially registered with the Internet Assigned Number Authority (https://www.iana.org/).

All network communications should be appropriately secured and encrypted to match your security policy. You can secure all communication between Microsoft Windows computers using IPSec; refer to your operating system documentation for details about how to do this. In addition, communication between user devices and desktops is secured through Citrix SecureICA, which is configured by default to 128-bit encryption. You can configure SecureICA when you are creating or updating a Delivery Group.

Note:

Citrix SecureICA forms part of the ICA/HDX protocol but it is not a standards-compliant network security protocol like Transport Layer Security (TLS). You can also secure network communications between user devices and desktops using TLS. To configure TLS, see Transport Layer Security (TLS).

Apply Windows best practice for account management. Do not create an account on a template or image before it is duplicated by Machine Creation Services or Provisioning Services. Do not schedule tasks using stored privileged domain accounts. Do not manually create shared Active Directory machine accounts. These practices will help prevent a machine attack from obtaining local persistent account passwords and then using them to log on to MCS/PVS shared images belonging to others.

Application security

To prevent non-admin users from performing malicious actions, we recommend that you configure Windows AppLocker rules for installers, applications, executables and scripts on the VDA host and on the local Windows client.

Manage user privileges

Grant users only the capabilities they require. Microsoft Windows privileges continue to be applied to desktops in the usual way: configure privileges through User Rights Assignment and group memberships through Group Policy. One advantage of this release is that it is possible to grant a user administrative rights to a desktop without also granting physical control over the computer on which the desktop is stored.

When planning for desktop privileges, note:

Some applications require desktop privileges, even though they are intended for users rather than for administrators. These users may not be as aware of security risks.

Treat these applications as highly-sensitive applications, even if their data is not sensitive. Consider these approaches to reduce security risk:

These approaches will not remove all security risk from applications that require desktop privileges.

Manage logon rights

Logon rights are required for both user accounts and computer accounts. As with Microsoft Windows privileges, logon rights continue to be applied to desktops in the usual way: configure logon rights through User Rights Assignment and group memberships through Group Policy.

The Windows logon rights are: log on locally, log on through Remote Desktop Services, log on over the network (access this computer from the network), log on as a batch job, and log on as a service.

For computer accounts, grant computers only the logon rights they require. The logon right “Access this computer from the network” is required:

For user accounts, grant users only the logon rights they require.

According to Microsoft, by default the group Remote Desktop Users is granted the logon right “Allow log on through Remote Desktop Services” (except on domain controllers).

Your organization’s security policy may state explicitly that this group should be removed from that logon right. Consider the following approach: