Welcome back to my blog series on Security Design Decisions. Here, I’ve explored the need for a solid security framework, particularly how Citrix Consulting uses a layered approach to security as more and more companies invest in security automation. In previous posts, I focused on the User Layer and on the Access Layer. In this post, I’ll concentrate on the resource layer.

The resource layer — the final layer in the Citrix methodology — interacts with end users. The resource layer is used to provide virtual application and desktop services. Virtualizing applications and desktops provides a secure means to deliver resources to end users, but without proper controls in place, it can be “jailbroken” to gain a foothold in the environment.

Jailbreaking is the ability to abuse an application running either in virtualized or physical environment. For example, an end user might find a way to launch “cmd.exe” even if it is not visible within the application menu. The following three mitigation strategies provide recommendations to prevent jailbreaking and securing the resource layer:

  1. Segregation model – isolate end-users and applications
  2. Policies – setting effective Citrix and Microsoft polices
  3. VDA hardening – securing server and desktop delivery to end users

Segregation model – isolate end-users and applications

A segregation model is applied in order to separate types of users and applications based on a sensitivity level categorization. Sensitivity level is based on three elements: the types of data (high value or low value) being accessed, end-users’ value and risk, and application value and risk.

For example, we should not place an application that processes high-value data in the same silo as an application that processes low-value data. The environment can be exploited since it’s sharing common resources, such as memory space, which can be accessed using exploit tools to extract the sensitive data. Similarly, we should not provide high-risk users with access to a persistent desktop, because this can be exploited by potentially placing a backdoor or converting the machine into a botnet.

By assigning an appropriate virtualization model, we can design the virtual resource silos to meet the needs of each use case. The table below provides all the general use cases and the possible recommendation for each.

Category High Value [1] High Risk [1] Regular Employee High Value Application(s) High Risk Application(s) Regular Application(s)
VDA Type
Single User Yes Yes Viable [2] Yes Yes Viable [2]
Multiple Users Yes No Yes No No Yes
FlexCast Model
Persistent Yes No Viable [2] Viable [2] No Yes
Non-persistent Yes Yes Yes Yes Yes Yes

[1] High-value users are the type that have significant value if compromised (eg. C-Level executives and IT Administrators). High-risk users are the type that pose significant risk to the environment (eg. contractors). For additional information on high-value and high-risk user types, review part 1 of this blog series.

[2] This decision is solely based on the business requirements by addressing the following questions (a) what are the requirement for a regular employee to be provided a dedicated persistent desktop and (b) what is the objective for publishing regular application from single server instance.

Policies – setting effective Citrix and Microsoft polices

Policies are baselines for the environment which are translated to technical or physical control. Policies dictate or enforce what action can or cannot be performed in an environment.

There are various types of policies that can be applied based on what we need to control. For example, we may leverage firewall policies to control the network traffic, Citrix policies to control user permissions within their virtual sessions, and Microsoft Group Policy Objects (GPO) to apply restrictions on the operating system. Policies can be developed by addressing the five questions outlined below:

  1. Identify what the policy is controlling – It is important to identify the required security controls that should be placed within the environment with the support from the security team or applying the existing corporate security baseline. For example, we may want to disable copy and paste operations between host(s), disable access to external drives, and any action that can cause data leakage without authorization.
  2. Identify where the policy will be applied – We need to identify where the policy will yield the best control either at the user or computer level or both. We should not be applying similar policies for high-risk users as compared to low-risk users. Both Citrix and Microsoft Windows environments offer policies that can be configured and applied to specific groups of users or computers. For example, if it is required to control access to operating system related objects, such as storage drives, network drives, task managers etc., we can apply Microsoft GPO. If it is required to disable certain HDX policies, we can leverage Citrix policies.
  3. Identify when the policy will be applied – Time-based policy provides enforcement on certain time of the day or the week. We can allow access to resources (internal or external) based on time or day range. This prevents attacks from happening anytime 24x7x365 and/or reduces access to the high value data environment during the time where human based monitoring is weakest.
  4. Identify how the policy will impact the end-user experience – Security is a balancing act to ensure the environment is secure and provides a satisfying end-user experience. We should not enforce security controls that prevent end-users from performing their daily tasks. The policy has to be enforced on a test group and the outcome analyzed before rolling it out onto production. Based on experience, users will often find insecure loopholes if they feel overly restricted by corporate policies. For example, bypassing policies to access certain websites or uploading files to cloud based storage to bring work home if access to USB drives are prohibited.

VDA hardening – securing server and desktop delivery to end users

The Virtual Delivery Agent is installed on servers and desktops in order to allow virtual desktop or application access to users. This is where we should apply the technical control as end user(s) are logged into a machine interactively. For example in a multi-user VDA environment, the user is vulnerable as the activity can be observed or they could have their session hijacked. In order to reduce the impact, we should establish an operating system image baseline prior to deploying to end-user(s). When building a secure master image, we should consider the following:

  1. Disable unused Microsoft Windows services
  2. Uninstall unused application(s)
  3. Prevent access to tools that can provide shell access or file copy agents (e.g. command prompt, PowerShell console, Task Manager, FTP client and etc.)
  4. Enable capturing of logs to a central secure server(s)
  5. Enable a password-based screen saver
  6. Apply appropriate Citrix and Microsoft Policies based on categorization
  7. Apply validated Windows Update patches
  8. Install Host Intrusion Prevention solution
  9. Install Data Leak Prevention solution
  10. Install anti-virus solution

For additional information on VDA Hardening refer to the following whitepaper.

To summarize, here are some key takeaways when designing a secure Resource Layer:

  1. We should separate high-value components in a single user environment with either persistent or non-persistent model depending on business requirements
  2. We should always separate high-risk components into a single user model with non-persistent access. We recommend wiping the virtual desktop clean after each reboot to avoid potential threat residual (e.g. viruses or malware) from any previous access.
  3. Identify the what, who, where, when and how of the policies to better customize the security controls
  4. Ensure the policies are tested thoroughly to ensure optimal end-user experience
  5. Establish a minimum VDA hardening baseline policy
  6. By default, we should implicitly deny any access that does not have a rule or permissions defined and access to all resources should be logged for audit purpose

Look out for part 4 of this blog-series, where we’ll examine control layer and the security-related design decisions made in this process. The Citrix Consulting Security Practice can help you with you design and hardening needs – feel free to reach out to us, or you can read more about our security practice.

For more information about Citrix security solutions, visit www.citrix.com/secure.

ponemon banner