In recent years, our Citrix Consulting Security Practice has focused on two project types: building highly secure environments and conducting security assessments of existing customer environments. The focus of these engagements is ultimately to help these customers improve the security of the Citrix solutions they already have deployed and explore how supplementing these existing Citrix solutions with additional technology or configuration could positively affect their security posture. To do so, we review the solution from the ground up, ranging from the network controls in place all the way to the endpoint device itself, considering context, people, and processes as we evaluate.
As anyone who has architected, engineered, or administered a Citrix environment over the years can attest, one of the intricacies to hardening these deployments is the number of other components the solution interacts with. While this gives us a lot of flexibility in terms of the controls we can implement and how they are enforced, it also requires consistency and careful coordination across the systems, as well as understanding the changing security and business risks your organization may face over time.
While every customer and environment are different and adheres to different local and governmental regulations, compliance guidelines, and internal policy, there are some themes that come up repeatedly — regardless of the vertical, locale, or customer. The goal of this article is to help you understand what those themes are and why they matter. In the subsequent article, we will provide additional information that directly relates to these themes and will get you started in improving the security posture of your current or upcoming Citrix deployment.
Disclaimer: This article is intended to provide general guidance on common themes observed during the course of these engagements. It is not intended to be an exhaustive or comprehensive hardening guide, and all recommendations should be carefully reviewed with your internal security, risk, and compliance teams to review alignment with your organization’s policy. Some of these configurations may also have an impact on user experience, administrative complexity, etc. All proposed remediations should first be carefully tested and validated in a non-production capacity before being implemented in a production environment.
Top 10 Findings
Without further ado, we give you the Top 10 findings from Citrix Consulting security assessments.
- Reduce the Attack Surface: The more we can reduce and simplify the attack surface, the less that must be protected. Systems are sometimes left with default values or enabled features that are not required. Any opportunity we have, to simplify the system to protect and limit the exposure, the better.
Citrix implementations interact with other systems and infrastructure. This can be both a blessing and a curse. On one hand, it means we have a tremendous number and flexibility of options for enforcing controls, virtualizing the context of where the user, application, data, and services reside. On the other, it means we need to be extremely diligent in minimizing the attack surface of complex systems with many moving components, integrating with existing business systems and controls.
Customers with a successful strategy for reducing their attack surface have a few things in common that span a few of the other themes we touch on later. They are consistent with their posture and approach at all levels of the infrastructure, and they evaluate systems beyond functional business and technical requirements. They also spend time thinking about risk, trust, and privilege. They don’t assume the default value is the best setting in their scenario. They often leverage the benefits of abstraction provided by the various forms of virtualization to reduce the exposure on each component. They spend time quantifying exposure associated with unmanaged device access and think about the trust levels of different components and the minimum level of privilege that each requires.
- Embrace Segmentation: Citrix virtualization and networking technologies provide robust methods for segmenting users, applications, and data while still providing a seamless user experience. These capabilities can be a great asset when designing zero trust systems. It allows us to control where, when, and how applications and data are consumed by users, providing additional methods to protect systems of various trust and privilege levels.
It is common for customers to have a user community that performs a variety of job functions while accessing the same Citrix backend resources. If these users are interacting with data and resources that have similar confidentiality and integrity requirements, that’s not necessarily a bad thing. Where this can go very wrong is when we allow higher-risk activities like web browsing and email on the same VDA that contains or allows connection to highly sensitive data. In the past, creation of multiple XenApp silos was discouraged due to the operational overhead, but automation and tools have matured to a point where they should be encouraged when providing a significant benefit, such as segmentation of different trust levels.
The initial focus of remediation tends to be on identifying and segmenting users of different privilege levels and segmenting applications that vary significantly in trust level. Email and web browsers are the most common vectors to bring malicious software into an environment or to exfiltrate data, so special focus should be spent on their deployment. For further separation of web browsing, a number of our customers are taking it a step farther and getting that traffic out of their data center completely with tools like the Secure Browser service.
- Apply the Principle of Least Privilege: The Principle of Least Privilege can be interpreted to ensure that each user or session context only has the minimum permissions required to perform a task or function. On paper, it is a model that most customers intend to follow, but it is also one of those things that can easily fall into disarray if not regularly audited and reviewed. Accounts that have amassed permissions over time are of particularly high value to an attacker as a way to escalate their privileges in an environment. Ultimately, using good business justification before granting permissions, stringent change control, and periodic auditing are effective high-level steps that can be taken to avoid permissions getting out of hand. The previous concept of segmentation can be leveraged here to allow a single user to run at the minimum privilege level for each individual application.
- Tune Citrix Policies: Virtual channels such as client drive and clipboard mapping are powerful tools to enable users to interact with a session in a way that feels more local and native. They can also be low-complexity ways for bad actors to introduce malicious code into an environment or exfiltrate data from it. A good number of virtual channels are enabled by default, as well. The good news is these are checkbox-type fixes that are pretty easy to implement. Similar to the least privilege concept, users should be granted access to only those virtual channel functions they absolutely require to perform their jobs. The filtering can be pretty granular and can be enforced dynamically via SmartControl. Similar controls can also be enforced via the Gateway Service if you are publishing web/SaaS resources to users via the Workspace App embedded browser capabilities.
- Protect User Credentials: User and administrator credentials should be protected and not stored on systems or transferred across the network in less secure methods. It is possible to inadvertently leave credentials, passwords, hashes, tickets, or tokens behind on systems, which can be harvested using tools such as Mimikatz in a pass-the-hash or pass-the-ticket attacks. This can occur in a variety of ways, including logging on via RDP or while completing other operational tasks. Once the hash or ticket is obtained, it is effectively as good as having the user’s password, allowing a bad actor to move laterally and exploit other systems that the account has privileges over, without knowing the user’s password. These credentials may also be transferred over the network using lesser algorithms, such as LM or NTLMv1, if policy has not been used to restrict.
Mitigation for these concerns will benefit from applying defense in depth principles as there are several methods that can help. We want to limit where the actor can go at the network level through segmentation and restrict permissions and capabilities of accounts to the minimum required. As we leverage newer operating systems, defaults, policies, and features have become more capable. We can disable the weaker algorithms from being used and be mindful of what we are leaving behind on systems, as we update and manage images. There are also system capabilities like Credential Guard in Windows 10 and Server 2016 that will move these sensitive credentials into an isolated area of the system with Virtualization-based security.
- Ensure Availability: When we talk about hardening and security, we spend a lot of time focusing on confidentiality and integrity, but availability, the all-important third side of the security triad, can be easily overlooked when we are focused on hardening, attack surface, lockdowns, etc. Even if you get all of that other stuff just right, if the environment is down, it does no good for anyone. When designing mission-critical systems, be sure to take the time to document and plan your availability requirements, business continuity needs, metrics such as RPO and RTO, and failure models (i.e., should the system fail open or fail closed). Once completed, ensure regular testing of disaster recovery and business continuity strategies meet requirements set.
- Encrypt All Sensitive Traffic Flows: This one seems obvious, but in most environments, it is overlooked in at least one place, often without anyone being aware. Some customers are really disciplined about user credentials, but less so about admin credentials. Others are the reverse. We also often get this response: “Well, that’s only on my internal network, right?” For most environments, that’s true. Things like XML traffic, access to web-based admin consoles from Director and Citrix Networking Appliances are all typically transmitted over a trusted or internal network segment. While that’s better than leaving plaintext credentials exposed to the Internet or an untrusted segment like your DMZ, 28 percent of threats (up 3 percent from the year before) come from INTERNAL actors. And that doesn’t even count the ones where an external actor has already gained a foothold on your internal network and is now snooping for an account with more keys to the kingdom. The key takeaway here is that we want to make sure credentials are secured both in transit and at rest wherever possible.
- Prevent Session Breakouts: A breakout or escape occurs when a user launches a different application that the administrator was not intending to provide to users from within another application. Command shells and other highly sensitive applications can be used maliciously if they are not prohibited with techniques such as application whitelisting.
The methods for these breakouts range from the mundane, such as using Open, Save, Print, or Help dialog boxes within applications to run an unexpected application, to the far more creative, like using MS Paint (I kid you not) to open a Command Prompt. There are some great resources available listing many policies that can be used to restrict the common ones we already know about, but it would be a pretty lofty goal to eliminate all possible methods via permission or application policies. Defense in depth principles should be applied here, with network isolation and application whitelisting being the most effective defenses possible. Most customers can start with application blacklisting, disallowing sensitive applications, and work towards application whitelisting, where we only allow trusted executables to be run within the environment.
- Revisit External Access: In our experience, customers with legitimate business reasons to add an access method sometimes don’t go back and either clean up legacy solutions or enforce new/updated hardening baselines like multi-factor in those solutions. In an ideal world, there would be a single, unified ingress method like Citrix Gateway through which any and all hardening requirements could be enforced and audited. If that’s not practical or possible for your organization, we at least want to make sure the access avenues are inventoried and justified and enforcement is consistent. Unless you are very diligent about isolation of backend components, your overall security posture will only be as strong as your weakest link on the front end.
- Mature Operations and Maintenance: The above actions are only as effective as the people maintaining them and the processes for establishing and enforcing them. Environments initially configured properly need to be maintained, modernized, monitored, and updated as configurations naturally drift over time during troubleshooting or implementation of new use cases. They need to be audited periodically and should always follow good change-management processes.
We also commonly have discussions with customers around visibility and centralization of audit data. Customers usually have the tools they need to centralize and aggregate log data, forensic information, and alerts but either haven’t configured enough data to be captured, or the opposite, haven’t tuned the system sufficiently, so the alerts are just noise. Training and practice of incident response teams on how to utilize this information so they know how to respond if or when something does happen is critical, before an incident occurs, not during. These operational processes “tie it all together” when it comes to the enforcement of a mature security posture that can stand the test of time.
During the follow-up to this article, we will revisit each of these findings and provide guidance and recommendations to address these challenges in your environment and improve the security posture of your current or upcoming Citrix deployment. We look forward to the continued security conversation.
— Eric Beiers, Lead Security Architect, and Ryan McClure, Sr. Enterprise Architect
