Security has been the talk of the town for years, and there can be severe consequences if it is left neglected. According to a recent global survey conducted by Citrix and Ponemon Institute, 83% of businesses claim that their company is at risk due to the complexity of the IT infrastructure and organization. Another Ponemon Institute study found that many IT departments are understaffed.

The intent of this blog post is to explore the need for a solid security framework as more and more companies are now investing in security automation to fill in the gap.

ponemon bannerWhen designing new implementations, Citrix Consulting uses a layered approach: User Layer, Access Layer, Resource Layer, Control Layer and Hardware Layer. There are important security decisions associated with each of these layers, which I’m going to cover in this series of blog posts, starting here with the User Layer.

User Groups

Humans are the biggest threat in information security. Identifying the user groups is the primary step before moving into design or deploying any Citrix solutions. Enterprises must perform an in-depth assessment of user workflows to better define what resources each user group requires access to.

Users generally fall into one of these three categories: (1) regular employees (2) high-value target (IT Administrators, C-Level Executives) and (3) high-risk users (contractors or anonymous users). Properly classifying users will allow IT to apply different security measures to different user groups to align the environment with the principle of least privilege, whereby users are only authorized to access services they require.

While on the subject of least privilege, let’s take a moment to discuss administrator accounts. If we apply the principle of least privilege, we should avoid single super administrator group that can access to everything. Administrative rights should be split across multiple groups following the separation of duty principle for various IT workflows. For example, a level one Help Desk support engineer has access to Director, but cannot make changes in Studio, whereas the Citrix engineering team has full administrator rights to Studio but no elevated rights on the SQL servers hosting the Site database.

Citrix FlexCast Model

Once we have the user groups, we can identify the best Citrix FlexCast model for each. Key decision points here are between server OS (multi-user) and desktop OS (single user) workloads and between persistent and non-persistent. Generally, multi-user (server OS) workloads are more cost effective but inherently riskier as high-value and high-risk personnel can co-exist on the same system. Most of our security-conscious customers prefer VDI workloads for this reason. Persistent machines both provide the user with greater flexibility or control and provide enterprises with easy access to forensic data. This flexibility comes with some risk: it is more time consuming to patch and cannot easily be reset in the event of security breach. Non-persistent machines are easier for IT to manage and control, but come at the cost of complex forensic data analysis as most information is wiped on reboot. This does not mean that non-persistent workloads are always the answer because they are less risky; this choice just has operational impacts that must be accounted for in a design. Good security is focused on protecting businesses data and user interests, even if it may result in some inconvenience.


Once it has been determined what users will be given access to, it should be decided where they will be provided access from: inside the corporate network, remote, or both. It is never a good security practice to provide all users with remote access to all corporate resources. Rather, we should identify users that requires remote access and the corresponding resources based on the business policies. Complicating this is that we are at the dawn of hyper-mobility with businesses allowing users to Bring Your Own Device (BYOD) in order to reduce costs; however, this provides many data security challenges as IT loses control over the endpoint device and can turn “internal” users into “external” ones. Context aware security such as SmartAccess and SmartControl via NetScaler and XenApp/XenDesktop can assist with applying granular security policies based on user and/or device identification.

Certificates (client and devices)

One of the ways of identifying users and devices is through certificates. Certificates can be categorized into client certificate and device certificate. A client certificate is used to validate an end user where they are unable to challenge their access to the environment. Device certificate is used to identify client’s physical machine. By doing so, enterprise is able to enforce use of only authorized users and machines. One important detail with certificates is that it can be exportable from one location to another. It is recommended that these certificates are non-exportable and considering strong storage methods such as Hardware Security Module (HSM), which provide greater assurance compared to software-based solutions.

Citrix supports a variety of logon methods outside of certificate-based authentication, including explicit domain username and password, single sign-on (SSO), and Smart Card. Generally, most security guidelines will recommend n-factor authentication, which is used to refer to the enforcement of multiple methods of authentication to mitigate the risk of a single form being compromised. However, in all cases, users must take appropriate steps to ensure their credentials are guarded and if compromised, that the company is informed immediately.

Authentication methods will be discussed further in Part II- Access Layer.

To summarize, some key takeaways when designing a secure User Layer:

  1. Classify users into groups in order to align security policies with the principle of least privilege
  2. Avoid “super” administrator roles and adhere to separation of duty guidelines
  3. Determine an appropriate FlexCast model by balancing user and security requirements, considering factors such as security breach response and forensic analysis procedures in addition to user workflows
  4. Carefully evaluate remote access authorization and security controls. Leverage SmartAccess policies to better assess users and devices and apply corresponding session security policies.
  5. BYOD initiatives place greater stress on corporate data protection, similar to those of remote access as the endpoint device is uncontrolled. Consider measures such as Endpoint Analysis and SmartAccess to help assess these devices before granting them access to the corporate network.
  6. Users are their own worst enemies when it comes to password management. Consider n-factor authentication and/or “password-less” options such as certifcates to help mitigate this risk.
  7. Configure device certificates to be non-exportable

Security is important for your business and is an innate significance to us at Citrix. We have more technical information for XenApp and XenDesktop-related security available here. In part II of this blog-series, we’ll examine access layer and the security-related design decisions made in this process.

ponemon footer banner