Over the course of the last year or so, I have been hearing IT organizations of all shapes and sizes focused more and more on one key concept … SECURITY!
If your organization is like many of those we have been working with lately, you are probably wondering which of those knobs to turn and checkboxes to select so that your XenMobile deployment is ‘secure’. Or maybe you just want to know what other customers are doing on this front and what you should be thinking about.
Well, do I have good news for you! Those are exactly the questions this post will attempt to answer. One thing it will NOT cover is the decision-making process around placement of XMS (DMZ vs. internal) and the use of SSL Bridge vs. Offload. That might be a good topic for a follow-up post if there is enough interest. 😉
I know you didn’t think we were going to get through a post on security without a disclaimer, so let’s get that out of the way early.
DISCLAIMER: This post is meant to provide guidance on fundamental security considerations when implementing XenMobile. It is not intended to be an exhaustive list and does not cover security considerations outside of the product itself. Customers should carefully review architecture decisions and policy configurations with their security team to validate that they align with each organization’s unique security and user experience requirements. Citrix is not liable for any security breaches or issues that may result from configurations or architecture decisions made as a result of the content in this post. Some of the settings detailed in this article may also have a significant impact on user experience and should not be implemented without proper testing and validation.
On to the good stuff!
Let’s start with some of the more obvious things.
FIPS Mode: If your organization requires FIPS, XenMobile can be configured to meet that requirement. But it isn’t a one-time configuration. You need to be sure to have a FIPS NetScaler in place, enable FIPS during XMS install and configure the associated client properties. Be sure to make this decision early. This is not something we want to try to be turning on/off after users are enrolled! Outside of the public sector, this is not something we see a whole lot of.
Timeout Values: If you haven’t read my other post on XenMobile Timeouts and how they work, there is no time like the present :). Understanding these timeout values is CRITICAL to aligning user experience with security requirements. That post also provides some guidance on what we commonly see in terms of timeout settings at our more security conscious customers.
So why mention it here? Because we have seen a few customers learn the hard way that making timeouts too restrictive can actually have an adverse impact on security. If the timeout values are so low that users can’t be productive, they may look to find other less secure ways to do what they need to do, ultimately compromising your security posture rather than helping it! I can’t stress enough the importance of a comprehensive Pilot and user acceptance testing cycle to get these values right.
Device Passcode: Requiring a device passcode is especially critical when considering the use of iOS devices, where data protection is, in many cases, driven by the presence of a device passcode. Apple’s documentation provides more information on this if you are interested, but long story short, applications are storing potentially sensitive information in the Keychain. With a device passcode enabled, that keychain data is more secure. The presence of a device passcode also adds an additional layer of protection before a potential attacker can even attempt to access containerized (wrapped) enterprise applications and data. The large majority of our high-security customers are enforcing the use of a device passcode in some capacity.
Console Access: This is another one that is often overlooked. The degree of exposure depends a bit on the version of XenMobile you are deploying, but you know that load balancer you set up for XMS/XDM access? It can also be used to gain access to certain administrative functionality from outside of your company’s network. Most of our secure customers choose to restrict console access via one of the few options available. The most common is detailed in this post by Avinash.
Secure LDAP: This one should be obvious, but I still see about half of our customers configuring LDAP connections over port 389. Even customers that consider themselves ‘secure’ are doing this. If you go this route, passwords are being sent across your internal network and maybe even through your DMZ IN PLAIN TEXT!!! This should not even be done in a POC if it can be avoided because in most cases you are still using production credentials that could grant an attacker access to production systems. Take the extra time to secure and load balance those connections.
The configurations above usually get a lot of attention and are pretty well understood these days, so let’s look at a few others that are every bit as important, but often overlooked. Here are some of the heavy hitters we commonly see missed.
Max Login Attempts: This can actually be configured in a few different places when it comes to XenMobile. All are critical to prevent a malicious user from turning your XenMobile deployment into an avenue to execute brute force and account lockout attacks. The XenMobile Lockout Limit can be specified during LDAP configuration on XMS. There is also a similar NetScaler Gateway configuration at the vServer level. To prevent account lockout attacks via XMS or NG, both should be set to one less than your AD account lockout limit. This way the user/attacker will be locked out of XMS or NG before their AD account is locked. The third configuration is a hidden client property called PASSCODE_MAX_ATTEMPTS, which determines the number of attempts that can be made against the offline version of the WorxPIN or password on the device before an online logon is required. The default value is 15, which is typically lowered to something more in-line with the AD account lockout limit in secure environments. Configuring an additional authentication factor (such as RADIUS) as the primary credential can also add value on this front.
Certificate Pinning: Certificate Pinning is a XenMobile feature that is designed to reduce the risk of man-in-the-middle attacks. This setting is ‘off’ by default and must be enabled via the Auto-Discovery service. This setting is something our most secure customers are sure to enable. The caveat is that if your certificate key pair is mismanaged/compromised, there is a risk that users could be forced to re-enroll, so be sure to consider that when deciding whether or not to enable certificate pinning. More details are available via the WorxHome documentation.
Content Flow: MDX policies are available to control how data not only flows (or doesn’t flow) out of the container but also how it may flow in. Most organizations don’t seem to perceive this to be much of a security threat and are much more focused on preventing data leak. Before coming to such a conclusion, it is critical to consider how enrolled devices and wrapped apps are interacting with backend components. For example, are WorxMail users bypassing any mail content filtering solutions you may have deployed? If so, your organization may also want to consider preventing data flow from unwrapped apps into wrapped apps.
Restrictions: There are a number of restrictions available via MDM and MDX policy with XenMobile, but which ones are important? That differs a little from organization to organization, but there are a few trends that seem consistent no matter where we go. Our security conscious customers are usually doing all they can to disable cloud/web related services such as Siri, iCloud backups, etc. But it is also critical to be on the lookout for services such as the iOS keyboard mic that are cloud based when you wouldn’t necessarily think so. These features/functions may be sending sensitive data where you don’t want it to be going. Always be sure to consult vendor documentation if you are unsure. The same is true of features such as AirDrop, AirPlay and AirPrint that allow users to send data to other devices with little effort. From there it is all about giving users the minimum amount of access they need to be productive. This changes a bit when we are talking about BYO devices, where we want to be as minimally invasive as feasible. In this scenario we want to control as much as we can via MDX policy and limit our use of MDM policies.
User Entropy: User entropy is enabled when the ENCRYPT_SECRETS_USING_PASSCODE client property is set to ‘true.’ This setting adds an additional variable (user entropy) to the composition of encryption keys. This means an extra layer of security, but there is also a significant impact to the number of WorxPIN/Password prompts that users would expect to see. For this reason, the majority of our customers tend to leave this option set to ‘false.’ Only our most security conscious customers choose to enable this setting.
In summary, there is a lot that goes into securing a XenMobile deployment. Don’t try to design these things in a bubble.
Involve your enterprise security, legal and compliance teams so that everyone can get on the same page about what makes sense for your organization. XenMobile provides an immense number of options and controls to assist with mobile security, but the right ones need to be enabled to make your specific solution effective. Hopefully this post helps give you some food for thought to get those conversations going in the right direction.
One last thing: security is VERY important, but don’t forget about BALANCING that with the user experience impact. Finding a happy medium is critical to a successful deployment.
Think there are other options that are crucial to consider? Feel free to drop me a comment below.
Architect | Citrix Consulting