Welcome back to my blog series on Security Design Decisions exploring the need for a solid security framework. The focus of this series is on 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, the Access Layer, and Resource Layer. In this blog post, I’ll concentrate on the control layer.
The control layer provides a unified foundation that supports the User, Access and Resource Layers. Think of it as a command center of an airplane – a lot can go wrong if a malicious user takes control.
Proper control should be placed to ensure administrators spend most of their time managing and supporting the environment using tools from this layer. This is where policies are translated into configurations (e.g. Group Policy Object) and where databases containing the infrastructure configuration and customization are stored. The environment is built based on the silo(s) decided in the Resource Layer (high and low value application, high and low risk users) and users or groups assigned to their respective authorized resources.
The following four strategies — Multilateral Security, Vulnerability Management, Configuration Management, and Access Management can be implemented to securely design this layer.
This layer is composed of the following five (5) interrelated segments as illustrated in Figure 1.
- Access controllers – Components that are used to enforce configured policies, perform authentication and authorization, for e.g. Citrix StoreFront and Citrix NetScaler.
- Delivery controllers – This silo is where the core control servers are stored, for example, Citrix XenApp and XenDesktop, Citrix Provisioning Services, Citrix XenMobile Server.
- Infrastructure controllers – In this third silo, all the supporting infrastructure components such as Database servers, Active Directory, DNS services, Citrix Licensing Server, Certificates services, and NTP services are stored.
- Storage – All the Citrix servers and supporting infrastructure virtual disks are stored in this layer in a file or object format.
- Network Connectivity – The core component that provides connectivity across the stack. Any form of failure or breach within the network layer will cause a systematic collapse of the components built on top of it.
|Access Controllers||Delivery Controllers||Infrastructure Controllers|
Each segment should reside in a physical cluster of servers and be connected to a central redundant switch with assigned VLANs. This reduces the failure domain and provides the ability to containerize any malicious act within the silo, not allowing it to overflow to the next. Communication between the silos should be monitored and should trigger an alert if an anomaly is detected. A logical kill switch should be implemented between silos to isolate the impacted environment in event of any intrusion.
For example, Citrix NetScaler AppFirewall is able to detect any web-based anomaly and prevent it from entering the enterprise network. This prevents the risk of impacting other infrastructure and sandboxes the malicious activity within the silo, which can be analyzed to determine root cause.
The Control Layer consists of critical servers such as Citrix XenDesktop and XenApp, Citrix Provisioning Services and administrative portion of Citrix StoreFront and Citrix NetScaler as well as dependent critical infrastructure servers such as Microsoft Windows Servers and database servers.
All the components that directly or indirectly relate to this layer need to be proactively monitored for potential vulnerability. This holds true for the other layers discussed within this blog series. All an attacker requires is an exploitable vulnerability to gain access to the environment and perform a malicious act. This can expose the enterprise to unwanted risk, which can be systematically reduced with a proper vulnerability management process.
The objective for vendors releasing patches or hotfixes is to address the bugs that may cause the aforementioned risk; however, without properly testing the software updates, system functionality and/or availability may be impacted. We have to ensure a proper change management strategy is applied and tests are done in an isolated environment before applying updates to production.
Server or appliance misconfiguration is one of the key concerns in security. Improper configuration or not being able to configure the correct options can expose the environment to various types of threats from inside and outside of the enterprise realm.
A formal configuration management process should be in place to ensure things like default accounts are changed or disabled (e.g. change the NSROOT default password) and that only the required configurations to support the business are enabled. Additionally, the implemented configuration has to be audited by an authorized third party to ensure it meets the assurance level set forth by the business unit.
The Control Layer is generally accessed by administrators to manage the environment. As mentioned in Part 1 of the blog series — we should not allow operational users to have complete administration rights.
The administrator’s role should be specific to his/her job scope. For example, a Help Desk administrator should not be allowed to create or modify settings within the Citrix environment.
Another commonly overlooked area in administration management is privilege creep. This happens when an administrator from one role moves to another — the new role gets added to the existing role instead of removing the previous privilege. Over time, the user will end up having privileges to perform multiple administration tasks and this can a pose a risk. To avoid this, it’s important to conduct periodic auditing of the privileges assigned to users identify and remove privilege creep.
Besides managing user accounts, it is also important to restrict service account permissions. The recommendation is to assign limited privileges and not full administrative rights as this can enable a malicious user to launch an attack using the privileged account.
Another component often overlooked is the ability to remotely or locally execute PowerShell scripts. The ability to execute PowerShell script provides tons of administrative benefits and exposes the environment to additional risks. Rather than disabling remote execution of PowerShell scripts, which can severely hamper environment management, it is recommended to deploy a dedicated jump server to execute PowerShell scripts with no access to the internet, allowing only authorized users to login and monitor the jump server periodically for any potential exploits.
To summarize, here are some key takeaways when designing a secure Control Layer:
- Separate the Control Layer into Access Controllers, Delivery Controllers, Infrastructure Controllers, Shared Storage and Network Connectivity
- Isolate Citrix related traffic within a single VLAN and monitor ingress and egress traffic for any anomaly
- Deploy a logical kill switch to isolate the environment if an attack is detected
- Proactively monitor and manage the application’s vulnerability and set forth a formal process to perform patch management
- Change or disable default configurations and only enable settings required to support the business.
- Audit administrator roles and remove any privilege creep
- Do not assign administrative privilege to a service account
- Assign a jump server with no internet connectivity dedicated to run PowerShell scripts and monitor the jump server periodically to ensure there are no exploit running locally
Look out for Part 5 of this blog-series, where we’ll examine the Physical Layer and the security-related design decisions made in this process. The Citrix Consulting Security Practice can help you with your design and hardening needs.
Feel free to reach out to The Citrix Consulting Security Practice , or read more about our security practice.
For more information about Citrix security solutions click here.