Blog posts tagged with 'xenapp'
This is an interview with Andrew Innes. Andrew is the Platform Architect for user interaction components of XenApp and XenDesktop, notably Web Interface and the desktop integration clients. His job entails finding creative ways to improve the usability and security of these products, and helping strike the right balance between them.
Here is Andrew: 
Q: Andrew, what are the security issues Citrix Admins should be aware of with Web Interface?
A: Hi Kate. There are two main categories of issues admins need to think about: security of the web server itself and security of the whole XenApp or XenDesktop delivery system. For the web server itself, there are all the standard hardening rules to follow, especially if it is facing the Internet - I won't try to summarize these here. The aim is to prevent intrusions into the web server itself or the network behind it.
It's worth mentioning though that Web Interface has undergone probably hundreds of evaluations in customer environments as well as regular security audits within Citrix as part of our secure development process. It has been engineered with all the known web application threats in mind, and we track 'webappsec' developments closely to build in defenses against new styles of attack as they emerge.
Hardening the web server itself is the #1 recommended best practice for everyone. Some customers will still want to employ extra measures, such as a web app firewall or other monitoring systems to spot potential attacks. NetScaler can easily be configured to provide web app firewall, SSL and detailed logs.
For the Citrix specific aspects of security, the admin should start by understanding the business reason for publishing resources (apps, desktops, documents etc) via the web, and the appropriate policies on access rights and restrictions. These feed into the design requirements for the delivery system, including the configuration of Web Interface. The aim here is primarily to ensure authorized users are allowed access in the intended way while unauthorized users are denied access, and that policies are not circumvented.
Web Interface has a brokering role in the delivery system, making it an effective place to enforce certain policies, for instance ensuring strong authentication happens before access is granted. It can be augmented with Citrix Access Gateway to scan end point devices to make fine-grained access decisions; in this case Web Interface plays a supporting role in upholding those policy mechanisms. It also implements a number of sensitive features, like password change and password reset, which can be enabled when the usability gains outweigh the security considerations.
Q: What are the prescribed security precautions Citrix Admins should use with WI?
A: There are a few standard precautions we recommend all customers follow:
- Require SSL on the Web Interface server; this protects user credentials in transit and helps prevent spoofing attacks (like those that could result from the recent DNS vulnerabilities).
- Use SSL or IPSec for requests to the XML service on XenApp or XenDesktop; again this protects credentials.
- Follow best practices for web server administration; this protects against accidental or malicious reconfiguration.
- Disabling the HTTP port, or having it redirect to the HTTPS port can be helpful. Then to prevent potential phishing attacks (MITM against the HTTP connection that redirects to a replicated WI site) the Internet Option setting "Websites in less privileged web content zone can navigate into this zone" should be disabled.
Where possible, we encourage customers to consider using the Kerberos or smart card support in XenApp which avoids the need to send passwords at all.
Q: Do you have any Knowledge Base articles to reference that might be of help?
A: There is a collection of technotes for Web Interface which cover useful points, but my favorite reference is the Troubleshooter's Guide for Web Interface.
I conferred with some of the security experts at Citrix on the topic of people and security. Their advice came in several key areas:
Physical access to IT assets: Gaining physical access to machines greatly increases the damage and theft of data a malicious user can do. For this reason, admins should restrict physical access to sensitive resources - for example, restricting access to the XenApp farm to Citrix administrators with authorized access cards.
Citrix products offer a great advantage in making it unnecessary to have applications and data locally stored, so physical access is less of an issue. Some of our most security sensitive customers publish the application that can manipulate sensitive data but disable client drive mapping and the clipboard virtual channel and print screen functionality so that no data can leave the data center.
Unattended and unlocked user workstations are also a liability and a policy that requires users to lock workstations when they leave the work area is strongly suggested. System configuration to lock workstations after a few minutes of inactivity and password-protected screen savers are also good measures.
Separation of Duties: Security policy should be such that no one person or role holds all control. This means assigning roles in a manner in which it takes more than one person to accomplish certain tasks. For example, if the task is releasing a binary to a customer, a software developer should not QA their own code. Similarly, an administrator's activities should be monitored by a separate auditing role.
Citrix brings value here as well, with a separate role for Citrix Administrators who share control of the overall system with Local and Network Administrators. The Citrix Administrators manage only the Citrix environment, so there is additional separation of duties.
Least Privilege: The old "need to know" basis! Well in this case, "need to have permission to do." People's roles in an organization and access rights should be broken down to grant users only the privileges that they need for their particular jobs. This applies to admins as well - for example, the database admin should not have management rights on the mail server or security console or the network.
Citrix allows you to publish applications using different roles to further restrict access to certain data and privileges.
The whole point of least privilege is that if an attacker is able to compromise an account, they can only do a small subset of tasks on the network/database/machine.
Password Policies:
There are several ways people can weaken corporate security with their management of passwords. The problem with passwords is users would like them to be easy to remember. As a result, they may attempt to simplify things by using the following bad practices:
- Write down their passwords
- Set all of their application passwords to the same thing
- Use really easy-to-guess passwords, like their dog's name
- Use the same password every other time they change it (just alternating)
- Using trivial and short passwords, like 123
- Never changing their passwords
These user antics are not good for corporate security! Security Policy should specify:
- Password length
- Password complexity (require special characters, mix of letters and numbers, etc.)
- Password history enforcement (force a new password and don't allow repeats for a certain number of passwords.)
- Disallowing the use of dictionary words in the password
- Prohibit the use of obvious words, like Citrix, in a password
- Password expiry, forcing password changes
Enforcement of this policy is a different matter. Citrix Password Manager can help administrators enforce these policies in a corporate setting. Plus, with CPM you can configure such that users do not even know their own passwords, very effectively preventing sharing. As a side benefit, if the user leaves, de-provisioning and assuring the user can no longer access any assets is much easier, since the user didn't know their passwords in the first place.
I spent some time recently chatting with Ross Duncan, VP of Channels at Gemalto, due to my role as product manager for Citrix Password Manager.While Citrix remains "strong authentication agnostic", Ross raised some great points: - Passwords are bad - I don't think anyone will argue this point! There have been many solutions to enforce management of passwords to mitigate the inherent weakness. Then those "solutions" that make passwords more complex can cause user convenience problems - plus bad behavior such as passwords written down, using the same password for many applications, and so on. Then the help desk calls are both extensive and expensive. - eSSO means putting all the keys to the kingdom in one place. This allows IT to use hyper-secure passwords (20+ characters, special characters, etc.) that change rapidly. However, the end user now has only ONE password to know - therefore there is a case to augment it with a strong authentication device like Gemalto smart cards. - Coupling of eSSO and smart cards brings the ultimate in convenience with maximum security - the user inserts their card, enters their PIN, and they can securely access the system. This is much easier then entering user name/password - easier and more secure. - Vendors like Gemalto are integrated with Citrix Password Manager, smooth roaming/Hot Desktop, XenApp and CAG, which is convenient for customers.
We also discussed the merits of converging logical and physical security. This always looks great on powerpoints, but it has been a real slow starter in real life. It's been discussed for 8 years that I personally know about, but the actual implementations are lagging. It always struck me this way: the physical security personnel and the IT security personnel are usually in different areas within and organization, and there are numerous political barriers to having the two groups work together and contribute budgets to make a badge/technology/management decision together. I know Gemalto has partnerships to do this, but it seems to me to face obstacles. Would like to hear comments!