Tech Paper: Citrix VDA Operating System Hardening Guide

Overview

When deploying any operating system, the settings are always targeted for the most compatible settings to ensure that the device works and is the most backward compatible. The Windows Operating system is no different. The latest Windows releases have settings to allow it to function with releases from 20+ years ago, with few restrictions on what can be done within the operating system.

Windows has its built-in Firewall, Antivirus, and Update settings that allow some protections. Still, users can launch anything they have access to, and by default, they have access to almost everything besides what is protected by local administrative access.

The 10 recommended areas in the following tech paper are covered, from getting started planning, configuring some recommended policies, controlling privileged access, and even configuring some security-based windows features. Most sections are broken into three sections: minimum, recommended, and high security. The minimum recommendations are just that, a starting point at default or just beyond default settings. This guidance provides some protections while still offering the most application compatibility and usability. The recommended settings start to secure the system and prevent some common attack methods while allowing the most common application compatibility and usability requirements. The high-security recommendations also provide the most secure deployment options with the most restrictive usability and targeted application compatibility.

Deploy all settings in a test scenario, validated by your IT team, and then scheduled and promoted to your test users before being promoted into production. With each level of recommendations, the risk of causing a useability or application compatibility issue may increase and require further testing and tuning.

Planning

Planning is one of the most crucial steps before hardening your VDAs operating system. These following items apply to all three levels of recommendations (Minimum, Recommended, and High Security), as planning is foundational to any successful and secure deployment.

What will be published?

There are three main options in Citrix to deliver resources with:

• Published Applications (Single Application)
• Published Desktops (Virtual Desktop)
• Remote PC Access Connections (Secure Connection to an existing VDA).

With each of these publishing methods, the same policies can be applied to each system since they are accessed remotely.

It's recommended to create a list of all resources that must be published and installed into the VDA to create a usable system for your users. This resource list helps you also collect the information that is helpful for further hardening of the system too.

For example:

| Published Resource | Type/Applications | | Published Application | EMR | | Published Desktop | EMR + Microsoft Office | | Remote PC Access | Accounting Application |

Which Operating System version?

Each operating system has generic security recommendations, but they also have specific recommendations based on specific features only in those specific versions.

Creating a list of each operating system and the build number for each published resource is recommended. Typically, there is some overlap as the same VDA image can be used for multiple use cases and even multiple publishing methods. This list helps you also collect the information that is helpful for further hardening of the system.

For example:

| Published Resource | OS Type | | Published Application | Windows Server 2019, Build 1809 (EMR Image) | | Published Desktop | Windows Server 2019, Build 1809 (EMR Image) | | Remote PC Access | Windows 10, Build 1909 (Finance Desktops) |

Software Requirements

The version of the software deployed in any operating system also affects the recommended deployment and security settings deployed.

Does the vendor support the software? The answer dictates if there is support from the vendor if there is an issue, and if updates and security updates are being released. There are some instances where legacy software has to be used, and the business has already accepted the risk of using it. Is the software supported on your targeted operating system? This is another level of support that dictates what operating system version you must use and if you run a supported one. Having an unsupported operating system is one of the riskiest items that a deployment can have. Without having support from the operating system vendor, you may not have access to support if there is an issue. Still, most importantly, you may not have access to security patches that can leave the system vulnerable to attacks. This might allow an attacker to compromise the system, and the vendor is not accountable without the operating system's support. This can also impact the effectiveness of Cyber Security Insurance and other legal implications if an attack happens due to this weakness.

For example:

User Requirements

These encompass the user's needs outside the application and the Citrix remote session. Many recommended settings can impact the system's usability and the applications required within the session. This level of planning will help with the following sections as it determines what settings can be configured based on the possible impact on the user workflow. Ensure that these items are documented so user requirements are documented when an audit or a new deployment is needed.

What must the user do within this application to be allowed within the operating system? This includes core windows systems\applications like Windows Explorer to include mapped drives, control panel applets, start menu, desktop shortcuts, and many others.

Does the application require administrative rights? Some applications require access to core operating system files or registry items. We recommend auditing these requirements from the vendor or debugging using tools like Microsoft Promon to see the programs, DLLs, and registry items that are accessed and what is getting "Access Denied" so that permissions can be adjusted. It is recommended to either use the same delivery group entitlement group or create AD groups to give access to these specific items.

Does the application open other applications? Many applications require other applications to be launched for the application workflow to be usable. Some will require core operating system items, and others open other installed applications. Documenting these dependencies will also help understand those application relationships' requirements and possible support implications.

What session channels will they need access to? The most common requirements are access to Print, Copy\Paste, and other devices within the session. Each session item has related policies within Citrix and some OS policies.

For example:

Compliance Requirements

Depending on what compliance bodies your business or application can drastically change the recommended settings, as certain compliance bodies require many for specific operating systems and applications. Many compliance bodies focus on change control procedures, logging, incident response, and other IT business operations. Still, many will also require precise settings to be deployed and for those same settings to be auditable by configured policies and possible Red Team testing of those controls.

| Common Compliance Bodies | | | NIST | National Institute of Standards and Technology | | CIS Controls | Center for Internet Security Controls | | ISO | International Organization for Standardization | | HIPAA | Health Insurance Portability and Accountability Act / HITECH Omnibus Rule | | PCI-DSS | The Payment Card Industry Data Security Standard | | GDPR | General Data Protection Regulation | | CCPA | California Consumer Privacy Act | | AICPA | American Institute of Certified Public Accountants | | SOX | Sarbanes-Oxley Act | | COBIT | Control Objectives for Information and Related Technologies | | GLBA | Gramm-Leach-Bliley Act | | FISMA | Federal Information Security Modernization Act of 2014 | | FedRAMP | The Federal Risk and Authorization Management Program | | FERPA | The Family Educational Rights and Privacy Act of 1974 | | ITAR | International Traffic in Arms Regulations | | COPPA | Children's Online Privacy Protection Rule | | NERC CIP Standards | NERC Critical Infrastructure Protection Standards |

It is recommended that following the guidelines from each compliance body are observed at a minimum. Depending on those requirements, evaluate other common frameworks from Microsoft, NIST, and even third parties like CIS and HyTrust for specific recommendations for Domains, Desktops, Servers, and more. These frameworks have many options to make the deployment much more secure, reduce your attack surface, along with helping accelerate your audits and reduce your findings.

Reducing Attack Surface

One of the first steps to reducing the attack surface is to remove unnecessary software and services to help reduce the attack surface. The easiest way to accomplish this is a twofold approach. Optimization is excellent for User and Resource performance but also critical to security, as the less running software, the more secure the system is.

The first thing to ensure is that only the required software is installed. Each piece of software installed on the system can create possible vulnerabilities that can be exploited.

Next, ensure that the software version is the latest, if possible, supported by that vendor. Most pieces of software have security vulnerabilities discovered and eventually remediated with a patch or software revision.

Then ensure that any necessary services are disabled from the operating system by using an OS optimizer. Most optimizations help with the user density by disabling and configuring items that are not needed in a VDI deployment. There are also security benefits to removing and configuring these same components. The highest density benefits are removing Windows Programs (UWP) and disabling scheduled Windows 10 operating systems tasks. Use the Citrix Optimizer Tool, which is tuned to provide the most benefits with negligible impact on the user's workflow. Citrix Optimizer is available here. Two other popular VMware optimizers and a community project called BIS-F may also fit your needs. With any optimizer, you will want to test before and after optimization to ensure the user's workflows function as expected and there are no side effects.

Windows Policies

Setting Windows Policies is critical to securing any Windows Operating System. The operating system's default policies focus on compatibility and useability first, and security settings must be added to the configuration. This section will focus on Windows over Linux VDAs as Windows is still most Citrix Virtual Apps and Desktops deployments. There are thousands of Group Policy Settings, and working on them in sections based on your users' requirements is the best approach. Below are some of the types of Applications and areas to focus on, but we also recommend making decisions on each of these settings and validating that it meets your users' requirements. The following sections point to the areas of the Group Policy to evaluate with some recommendations, not each specific policy. A standard for all Desktops and Servers is recommended so all your systems can have a similar effective policy. There are deviations that can be architected by other policies or device placement in specific OUs. Administrative deviations are possible using an AD group with "Deny Policy" advanced permissions, so these settings don't apply to admins.

Session Policies

Creating a session requirements matrix for each use case is recommended to control what session policies need to be configured per job profile. Create a Zero Trust Policy for all session policies using the Security and Control Policy Template to start any Citrix Virtual Apps and Desktops deployment to ensure that all session channels are blocked by default. Suppose that any session policies need to be adjusted. In that case, create a policy for each policy deviation and use Active Directory groups for nesting your delivery group entitlement groups to make a seamless single group entitlement for the users.

For reference, the Citrix default policies and the list of policies that will be focused on for Security recommendations can be found here.

Use the following detailed session policy questionnaire to determine which job profiles require which virtual channels. The most common requirements are access to Print, Copy\Paste, and other devices within the session. Each of these session items has corresponding policies within Citrix and some OS policies.

For example:

Operations

Missing operating system patches are one of the most prolific findings in security audits. Typically there are two reasons why patches are not done regularly. First, a set schedule and time are not set aside each month for them, and there have been application compatibility issues in the past with patches.

OS and Application Patching Schedule

Based on the Windows release cycle, we can expect to update the operating system at least every month. Around two times a year, a critical patch must be applied, and the OS will now need to be upgraded every 30–60 months, depending on the version chosen. Plan then for at least 12 updates a year and have a process to deploy at least one other patch per day. With these anticipated updates for the operating system, providing application owners access to that same time window for testing and promoting these changes can be beneficial. Working with your IT team to create a process and time will increase the security of your deployment.

Purpose Built Updatable Image Design

Creating a process for implementing and promoting image updates that can lower the risk and impact if issues arise is recommended. Depending on your Machine Catalog, Delivery Group, and hosting design will determine what will be possible. We recommend having a Test Machine Catalog and Delivery Group for initial updates applied to and then promoted to a Quality Assurance (QA) Catalog and Group for Application Owner testing and validation. Then, you can have a Pre-Production Machine Catalog in a Production Delivery Group to reduce the impact in the same Production delivery group. Using multiple Machine Catalogs within a single Delivery Group enables the allocation of a certain proportion of VDAs to the latest version, while others are assigned to the current version. The feasibility of this approach may vary based on the application update needs, but it would remain unaffected by operating system updates. There have been issues with OS updates that are not found until they are rolled out and have more than one user, or they are load-based issues, so if you can afford to have the extra capacity, it helps lower your risk while increasing your security.

Application Control

Having an Application Control solution is imperative in the current cyber threat climate. Ensuring that no application can be launched is a cornerstone of OS security. A user being able to run anything they can access is risky, and deploying an application control solution is recommended. Many options for an Application Control solution are included with Windows or are paid add-ons. When we publish a specific application or a desktop to access a particular application or application, most users only need to run that specific program or program. Some applications launch other supporting applications and must be included in an application control solution. In the planning phase, have a list of primary executables and supporting executables to start this testing the solution listed.

Options for Configuration of Application Control

Choosing a Solution

The first step is to choose which Application Control solution works best for your team. There are many differences between these solutions based on your team's expertise, how your privileged account management delegation is set up, the number of applications to define, and what solutions you already own.

Implement in Audit-Only Mode

If your solution supports an audit-only mode, we recommend deploying it to existing VDAs to understand what must be in the allowed list. This may often catch other executables not noted in the planning phase. This may require Windows Event Log Forwarding, depending on the solution selected. The list of executables that might be discovered may also change which solution you want to deploy based on the number of applications to define or the number of groups they must each be delegated to.

**Enable Solution - Block Admin Applications

Enable the block ability from your Application Control Solution for administrative programs.

Recommended Admin Applications to Block

Most deployments don't require users' access to the PowerShell (PowerShell.exe, PowerShell_ISE.exe) command line or the editor. Currently, there isn't a single GPO that prohibits access to PowerShell that is equivalent to the command prompt. If there are other programs in use, we recommend disabling those too.

Allow List Only

After testing and validation, set your solution to allow execution of the defined applications only in the user context. This can be a long process depending on the number of applications, the number of delegation deviations, and which solution was selected. We recommend working with the simplest images first, if possible, with the least number of installed applications. It is not recommended to restrict all application launches on all images at once. Using the same groups used for Delivery Group entitlements to help filter the policies to control which applications can be launched on the same image by multiple groups or multiple images is recommended.

For example:

Endpoint Protection

Endpoint protection is paramount in any operating system. The amount of malware consistently growing daily puts any system without endpoint protection from any vendor at an increased risk level. There are many vendors in this space, and now with the creation of Endpoint detection and response systems, there are even more choices with more traditional and EDR-based systems.

Minimum

Deploy a solution on all VDAs, Citrix Infrastructure Servers, and all other systems if possible. Ensuring it is the latest client paired for your operating system build is also recommended. Ensure that the exclusions and best practices are applied as well.

High Security

Deploy an EDR-based solution, if possible, to gain some of the features that most EDRs have. Most EDR solutions look for known malicious files and processes but may also look for unusual data movement on the network and locally even over USB.

For example:

Logging

You cannot provide a proper incident response without adequate logging. This problem is magnified in a non-persistent deployment as the system, as the logs, will often be lost during a reboot if not kept on persistent storage or forwarded to a SIEM. There must be a tiered approach to logging. Also, do not forget about the other systems listed. The following is a typical logging priority list that recommends ensuring log retention, forwarding, and alerts for critical events. Many of these systems rely on Windows Event logs, and others require Syslog, so that you need a solution for each event type. Logging can also be helpful for troubleshooting and event correlation when there is a problem or outage.

1. Networking
   • a. Firewall
   • b. Switches
   • c. Wireless
   • d. Content Control\Proxy
   • e. Load Balancers\Gateways
   • f. VPN Servers
2. Domain Controllers
3. File Servers
4. Database Servers
5. Web Servers
6. Backup Servers
7. Hypervisor Systems
8. VDI Systems (Brokers)
9. Other Application Servers
10. Key Employee Computers
    • a. C-Suite
    • b. Finance
    • c. HR
    • d. IT
    • e. Privileged Account Workstations
11. Managers and Team Leads
12. All other systems

Basic AD Security Related Event Log Events to Monitor and Alert

The following table lists known Windows Event IDs typically associated with alerts, as they might indicate systems compromise via the typical attack paths most choose. Reference the following for more details.

If you are also using a NetScaler for load balancing, web application firewall, Citrix Gateway, or other services, we recommend visiting the NetScaler syslog guide.

Privilege Delegation

Defining your IT roles, permissions for your VDI deployment, and overall privileged accounts is critical. The goal of any privilege delegation is to ensure that administrators have the appropriate permissions needed to fulfill their assigned job roles. Depending on the products deployed, you may have more or fewer groups based on your needs. These are just examples of some of the common delegation points. The recommended items are done outside the VDA OS hardening tasks. Without some of these core principles deployed, your company is at an increased risk. Visit Microsoft Privileged Access Accounts for additional information.

Minimum

Separate Administrative Accounts We recommend ensuring that any user with more than Domain User rights has a separate account. Too many attacks have started or escalated due to administrators using their accounts to check email or browse the web. We recommend putting these in a protected OU with delegated permissions to prevent editing these users' accounts other than a few individuals in your domain in a custom delegation group. It is also recommended to have a naming standard with a common prefix suffix to help with auditing. The most common is using prefixes like "adm-", "admin-", "sa-" and "p".

Service Account Naming Standard Use Naming Standards for all service accounts to separate them from standard accounts when doing account reviews. Place these accounts in a separate OU to limit access to edit these accounts. The most common is using prefixes like "svc-", "service-", "s-" and "s". It is also recommended that within the account description or on a shared document, a list of what each service does for easy reference for password resets.

Use Custom Groups for each Administrative Delegation We recommend custom AD groups to delegate all administrative roles within your deployment. Do not use Default Groups like Domain Admins to give access to remote into systems, manage privileged systems, manage accounts in AD, manage Citrix, and other systems. Using groups with a naming standard will also help organize these groups for easy auditing and application on those systems. A common prefix is also most common with other naming standards for each system group. When common names describe these roles, you can search for all groups for the Service Desk, VDI, AD, and other systems. It can also be helpful for specific permissions like "Read Only" and "Full Control" to search and apply these roles on multiple systems. There may need to be multiple groups within each system that must be shared for each major role delegation. The complexity of delegation increases the number of systems and permissions needed but also increase your deployment's security and flexibility.

Example Citrix Custom Groups and Delegations ADM-VDI-Full-Admins: These users will typically be local admins on all the Citrix Infrastructures Server Roles and VDAs, have complete control of the profile share, and be entitled to the Administrator roles within each Citrix Component. They will also have at least VM Administrator rights on the hypervisor hosting in scope VMs.

ADM-VDI-Image-Admins It may only be local admins on the master image and maybe the patching responsible for updates of the image. If this is for an application team, it is recommended that a custom group per team must maintain the applications per image. They may also have at least VM User rights on the hypervisor hosting these image VMs.

ADM-VDI-ServiceDesk Will have the roles of Help Desk or Service Desk in the Citrix Studio and Director. This allows them to manage sessions, troubleshoot within Director, and view configuration settings within Citrix Studio. For most deployments, the Service Desk may not need access to any other Citrix Server role components like StoreFront Server, License Server, SQL, FAS Servers Read-only rights to WEM and Provisioning Server might help troubleshoot or spot issues. The amount of privileged you give your service desk will be based only on our policies and their expertise. There may also be multiple levels of subpermissions for each of these functions.

ADM-VDI-ReadOnly-Director Allows this user the right to view items within Citrix Director. This can be helpful for an Application Owner to see the usage of their system along with the leadership team to track the use of the system.

ADM-VDI-ReadOnly-Studio This may be needed for Configuration Validations from other teams or Application Owners.

Recommended

Migrate away from the AD Default Privileged Groups Using the default groups for administrative elevation gives more permission than most need. People and service accounts are often just added to Domain Admins because it works and is easy. Many default groups have inherited explicit rights on all machines and throughout the domain structure. Audit Default-privileged groups to identify all users, contractors, and service accounts that may reside in them. Removing the administrator account from default groups is not recommended as it can cause issues. Instead, treat the account as a highly sensitive privileged account, and its change the password regularly and stored securely.

Continual Account Review Audits We recommend scheduling regular account reviews with your Active Employee list and AD account listings to ensure that only Active employees have accounts. Consider checking your third-parties accounts based on active agreements with these vendors. Audit Service accounts regularly to ensure they are still needed and have just the required permissions for those roles.

Define Account Policy Requirements Setting an account policy standard following your compliance bodies is advisable. These settings play a crucial role in ensuring the account security of the domain and ought to strike a balance between maximum security and ease of use. There are many standards for Password Age, Password Complexity, Length Requirements, Password History, Lockout Thresholds and Duration, Kerberos Ticket Settings, Logon Restrictions, and many more items. These policies are typically defined at the domain's root for all users and accounts. There may be other policies for privileged accounts and key employees to ensure a more secure standard.

Reference Links Account Policy Links Domain Password Requirements Microsoft 365 Password Policies

Define User Assignments

Audit your Default Domain Policies User Rights assignment. Many default settings are built for backward compatibility and ease of use without deploying custom settings. Just like Windows policies, it is essential to know the oldest systems to ensure they will still function. Tie these options to your custom privileged groups to ensure that only specified users can join computers to the domain, access the system remotely, log into specified systems, and more. It can be helpful to make AD groups per user right assignment so that they can be nested into a privileged group to allow specific permissions to specific users. User Rights Assignment decisions are typically made for the root of your domain in addition to the location of your desktops and servers.

Microsoft User Rights Assignments Overview and Details

Define Security Options

Review your Default Domain Policy to audit these Security Options. These options are central to the security of any domain. These settings control the behavior of the local machine with settings like renaming the guest and administrator accounts, permissions within the system from print driver install to SMB versions, and many other settings. Each of these settings has a recommended setting beyond the default, but they will also be based on the oldest operating system you must support.

Security Options Overview

High Security

Use Privileged Workstations It is recommended that all administrative work is done from dedicated machines rather than from each administrator's workstation. This allows more comprehensive logging from these systems, allowing better visibility of your deployment's changes. There are third-party Privileged Account Management systems that help build this system out and audit and control access to these machines with even screen recording and log correlation depending on the vendor chosen. If you cannot afford a PAM solution, work in phases to deploy your system. It is recommended to deploy a highly available set of servers/desktops that only defined administrators can remote into and dedicate the VLAN with ingress and egress control available. Require Multifactor authentication to log into these systems if available. Once these systems are deployed, you want to install all the administrative tools for the targeted administrators. Ensure that these systems have logs retained locally and forwarded to your SIEM for log retention and visibility so alerts can eventually be set up. Then the final steps are implementing access control lists to limit source administrators from sensitive systems from this VLAN and another highly controlled VLAN that machines might be put on in an emergency virtually or physically in the event of a failure of these systems. Audit the primary and secondary privileged account workstation (PAW) VLANs, and send alerts to all responsible team members if any devices are added. With this final phase, you can only administer these systems from these PAWs so that normal users cannot even get to the management UIs for these systems on their typical client networks or from a VDA.

Microsoft Overview of Privileged Account Workstations

Obfuscation

When your deployment is attacked, and there is an initial foothold, there are benefits of using obfuscation to slow the attacker down so that you're logging and alerting systems that can hopefully catch them before the next pivot. Having a password manager or another system is highly recommended before starting any obfuscation to be able to track the association. This obfuscation can start with privileged accounts not the same name as the user in AD. Privileged account obfuscation can be using the same unique last name or usually other unique name combinations so they can still be audited. Service accounts can also be obfuscated by using different prefixes or names of people. Also, remember you want to be able to audit these accounts. Sensitive server names can also be obfuscated with test and development prefixes or names that do not correlate to the role. The most potent obfuscation is user obfuscation, where their first and last names are not used for the account name, which usually combines characters and numbers. User obfuscation is the most disruptive but can also be rolled out to new users and slowly phased into. This is usually one of the last steps of a security remediation plan.

Local Groups Privileged Account Groups

Windows Features

Many security features are built into Windows that must be evaluated for deployment. This list will only be able to highlight a fraction of the features. Still, it showcases the ones that provide the most significant security impact to Citrix Virtual Apps and Desktops deployments.

Local Administrator Password Solution (LAPS)

In most deployments, the administrator password is the same for all desktops and servers because it may have been defined in the "Default Domain Policy" only. Often, there may not be a local admin password standard, as the desktops or servers built by different people or images use a different password, and there isn't a set standard. With LAPs deployed, each machine under that policy has a unique password stored within Active Directory and protected by an ACL. Having dedicated privileged accounts with proper delegation between roles is critical when deploying this solution to ensure that only authorized users can view and use the password. This solution can be rolled out in phases based on your OU structure to ensure everything works as expected and can reduce the risk of Pass-the-Hash (PtH) credential replay attacks.

How to Change a Local Administrator Password with Group Policy LAPs Tool Download

Windows Event Log Forwarding

If you do not have a SIEM to configure, configure Windows Event Log Forwarding, as this solution is free with a license of Windows. Depending on the number of events per second, the main requirement is disk space and some Windows Event Collector servers. We recommend enabling log forwarding on all Domain Controllers first, as this information is instrumental in any incident response investigations and troubleshooting. Tuning can be required based on the number of WEC servers for availability and stability and the number of events, disk space, and I/O. These systems collect logs specified by Group Policies for Audit Policies and Advanced Audit Policies

WEF Setup Guide Basic Security Audit Policies Advanced Audit Policies

Managed Service Accounts

Managed Service Accounts are designed to provide applications like SQL and Exchange with automatic password management. It simplifies Service Principal Names management for these accounts, which can help mitigate Kerberos attacks.

Managed Service Account Step-by-Step Guide

Summary

This tech paper covered the 10 recommended areas for securing your Citrix VDA/OS, including getting started planning, configuring some recommended policies, controlling privileged access, and configuring some security-based windows features. This guidance provided protections and recommended settings to help secure the system and prevent some common attack methods. It is advisable to first deploy any recommended settings in a test scenario. Have your IT team validate them, schedule, and promote them to your test users, and only then promote them to production. With each level of recommendations, the risk of causing a useability or application compatibility issue increases and requires further testing and tuning.

References

Windows 10 Security Mitigations

Citrix Security considerations and best practices