Citrix

Produktdokumentation



Ganzes Dokument herunterladen

Device and App Policies

Jan. 12, 2017

Note

 This section applies to XenMobile Cloud and XenMobile on-premises deployments.

XenMobile device and app policies enable you to optimize a balance between factors, such as:

  • Enterprise security
  • Corporate data and asset protection
  • User privacy
  • Productive and positive user experiences

The optimum balance between those factors can vary. For example, highly regulated organizations, such as finance, require stricter security controls than other industries, such as education and retail, in which user productivity is a primary consideration.

You can centrally control and configure policies based on users' identity, device, location, and connectivity type to restrict malicious usage of corporate content. In the event a device is lost or stolen, you can disable, lock, or wipe business applications and data remotely. The overall result is a solution that increases employee satisfaction and productivity, while ensuring security and administrative control.

The primary focus of this article is the many device and app policies related to security.

Policies That Address Security Risks

XenMobile device and app policies address many situations that may pose a security risk, such as the following:

  • When users try to access apps and data from untrusted devices and unpredictable locations.
  • When users pass data from device to device.
  • When an unauthorized user tries to access data.
  • When a user who has left the company had used their own device (BYOD).
  • When a user misplaces a device.
  • When users need to access the network securely at all times.
  • When users have their own device managed and you need to separate work data from personal data.
  • When a device is idle and requires verification of user credentials again.
  • When users copy and paste sensitive content into unprotected email systems.
  • When users receive email attachments or web links with sensitive data on a device that holds both personal and company accounts.

Those situations relate to two main areas of concern when protecting company data, which are when data is:

  • At rest
  • In transit

How XenMobile Protects Data at Rest

Data stored on mobile devices is referred to as data at rest. The mobile application management (MAM) capabilities in XenMobile enable complete management, security, and control over XenMobile Apps, MDX-enabled apps, and their associated data. The Worx App SDK, which enables apps for XenMobile deployment, leverages Citrix MDX app container technology to separate corporate apps and data from personal apps and data on the user's mobile device. This allows you to secure any custom developed, third-party, or BYO mobile app with comprehensive policy-based controls.

In addition to an extensive MDX policy library, XenMobile also includes app-level encryption. XenMobile separately encrypts data stored within any MDX-enabled app without requiring a device PIN code and without requiring that you manage the device to enforce the policy.

Policies and the Worx App SDK enable you to:

  • Separate business and personal apps and data in a secure mobile container.
  • Secure apps with encryption and other mobile Data Loss Prevention (DLP) technologies.

MDX policies provide many operational controls, so you can enable seamless integration between MDX-wrapped apps, while also controlling all communication. In this way, you can enforce policies, such as ensuring that data only is accessible by MDX-enabled apps.

Beyond device and app policy control, the best way to safeguard data at rest is encryption. XenMobile adds a layer of encryption to any data stored in an MDX-enabled app, giving you policy control over features such as public file encryption, private file encryption, and encryption exclusions. The Worx App SDK uses FIPS 140-2 compliant AES 256- bit encryption with keys stored in a protected Citrix Secret Vault. For information about XenMobile encryption and iOS 9, see "iOS 9 Compatibility" in About the MDX Toolkit and "Data Encryption and iOS 9" in Best Practices for iOS Apps.

How XenMobile Protects Data in Transit

Data on the move between your user's mobile devices and your internal network is referred to as data in transit. MDX app container technology provides application-specific VPN access to your internal network through NetScaler Gateway.

Consider the situation where an employee wants to access the following resources residing in the secure enterprise network from a mobile device: the corporate email server, an SSL-enabled web application hosted on the corporate intranet, and documents stored on a file server or Microsoft SharePoint. MDX enables access to all these enterprise resources from mobile devices through an application-specific micro VPN. Each device has its own dedicated micro VPN tunnel.

Micro VPN functionality does not require a device-wide VPN, which can compromise security on untrusted mobile devices. As a result, the internal network is not exposed to malware or attacks that could infect the entire corporate system. Corporate mobile apps and personal mobile apps are able to coexist on one device.

To offer even stronger levels of security, you can configure MDX-enabled apps with an Alternate NetScaler Gateway policy, used for authentication and for micro VPN sessions with an app. You can use an Alternate NetScaler Gateway with the Online session required policy to force apps to reauthenticate to the specific gateway. Such gateways would typically have different (higher assurance) authentication requirements and traffic management policies.

In addition to security features, micro VPN also offers data optimization techniques, including compression algorithms to ensure that only minimal data is transferred and that the transfer is done in the quickest time possible, thereby improving user experience, which is a key success factor in mobile project success.

You should reevaluate your device policies periodically, such as in these situations:

  • When a new version of XenMobile includes new or updated policies due to the release of device operating system updates.
  • When you add a new device type. Although many policies are common to all devices, each device has a set of policies specific to its operating system. As a result, you may find differences between iOS, Android, and Windows devices, and even between different manufacturers' devices running Android.
  • To keep XenMobile operation in sync with enterprise or industry changes, such as new corporate security policies or compliance regulations.
  • When a new version of MDX Toolkit includes new or updated policies.
  • When you add or update an app.
  • When you need to integrate new workflows for your users as a result of new apps or new requirements.

App Policies and Use Case Scenarios

Although you can choose which apps are available through Secure Hub, you might also want to define how those apps interact with XenMobile. If you want users to authenticate after a certain time period passes or you want to provide users offline access to their information, you do so through app policies. The following list includes some of the policies and discusses how you might use them. For a list of all MDX policies per platform, see MDX Policies at a Glance.

Authentication policies

Device passcode

Why use this policy: Enable the Device passcode policy to enforce that a user can access an MDX app only if the device has a device PIN enabled. This feature, for iOS 9 devices, ensures use of iOS encryption at the device level and for the MDX container.

User example: Enabling this policy means that the user must set a PIN code on their iOS device before they can access the MDX app.

App passcode

Why use this policy: Enable the App passcode policy to have Secure Hub prompt a user to authenticate to the managed app before they can open the app and access data. The user might authenticate with their Active Directory password, Citrix PIN, or iOS TouchID, depending what you configure under Client Properties in your XenMobile Server Settings. You can set an inactivity timer in Client Properties so that, with continued use, Secure Hub doesn't prompt the user to authenticate to the managed app again until the timer expires.

The app passcode differs from a device passcode in that, with a device passcode policy pushed to a device, Secure Hub prompts the user to configure a passcode or PIN, which they must unlock before they can gain access to their device when they turn on the device or when the inactivity timer expires. For more information, see Authentication in XenMobile.

User example: When opening the Citrix Secure Web application on the device, the user must enter their Citrix PIN before they can browse web sites if the inactivity period is expired.

Online session required

Why use this policy: If an application requires access to a web app (web service) to run, enable this policy so that XenMobile prompts the user to connect to the enterprise network or have an active session before using the app.

User example: When a user attempts to open an MDX app that has the Online session required policy enabled, they can't use the app until they connected to the network using a cellular or wifi service.

Maximum offline period

Why use this policy: Use this policy as an additional security option, to ensure that users can't run an app offline for long time periods without reconfirming app entitlement and refreshing policies from XenMobile.

User example: If you configure an MDX app with a Maximum offline period, the user can open and use the app offline until the offline timer period expires. At that point, the user must connect back to the network via cellular or wifi service and reauthenticate, if prompted.

Miscellaneous Access policies

App update grace period (hours)

Why use this policy: The app update grace period is the time available to the user before they must update an app that has a newer version released in the XenMobile Store. At the point of expiry, the user must update the app before they can gain access to the data in the app. When setting this value, keep in mind the needs of your mobile workforce, particularly those who might experience long periods offline when travelling internationally.

User example: You load a new version of Secure Mail in the XenMobile Store and then set an app update grace period of 6 hours. All Secure Mail users will see a message asking them to update their Secure Mail app, until the 6 hours expires. When the 6 hours expires, Secure Hub routes users to the XenMobile Store.

Active poll period (minutes)

Why use this policy: The active poll period is the interval at which XenMobile checks apps for when to perform security actions, such as App Lock and App Wipe.

User example: If you set the Active poll period policy to 60 minutes, when you send the App Lock command from XenMobile to the device, the lock occurs within 60 minutes of when the last poll took place.

Encryption policies

Why use these policies: XenMobile includes a secret vault with a strong encryption layer that Secure Hub and other XenMobile Apps use to persist their sensitive data, such as passwords and encryption keys, on the device without depending on the platform native keystores. As a result, if the device becomes compromised in any way, corporate data remains encrypted in the MDX container and XenMobile obfuscates the data before transferring it outside of the container.

User example: If the device owner did not set a device PIN or the device PIN becomes compromised, the corporate data inside the Secure Hub container remains secure.

App Interaction Policies

Why use these policies: Use App Interaction policies to control the flow of documents and data from MDX apps to other apps on the device. For example, you can prevent a user from moving data to their personal apps outside of the container or from pasting data from outside of the container into the containerized apps.

User example: You set an App interaction policy to Restricted, which means a user can copy text from Secure Mail to Secure Web but can't copy that data to their personal Safari or Chrome browser that is outside the container. In addition, a user can open an attached document from Secure Mail into ShareFile or Quick Edit but can't open the attached document in their own personal file viewing apps that are outside the container.

App Restrictions policies

Why use these policies: Use App Restriction policies to control what features users can access from an MDX app while it is open. This helps to ensure that no malicious activity can take place while the app is running. The App Restriction policies vary slightly between iOS and Android. For example, in iOS you can block access to iCloud while the MDX app is running. In Android, you can stop NFC use while the MDX app is running.

User example: If you enable the App Restriction policy to block dictation on iOS in an MDX app, the user can't use the dictate function on the iOS keyboard while the MDX app is running. Thus, data users dictate isn't passed to the unsecure third-party cloud dictation service. When the user opens their personal app outside of the container, the dictate option remains available to the user for their personal communications.

App Network Access policies

Why use these policies: Use the App Network Access policies to provide access from an MDX app in the container on the device to data sitting inside your corporate network. For the Network access policy, set the Tunneled to the internal network option to automate a micro VPN from the MDX app through the NetScaler to a back-end web service or datastore.

User example: When a user opens an MDX app, such as Secure Web, that has tunneling enabled, the browser opens and launches an intranet site without the user needing to start a VPN. The Secure Web app automatically accesses the internal site using micro VPN technology.

App Geolocation and Geofencing policies

Why use these policies: The policies that control app geolocation and geofencing include center point Longitude, center point Latitude, and Radius. Those policies contain access to the data in the MDX apps to a specific geographical area. The policies define a geographic area by a radius of latitude and longitude coordinates. If a user attempts to use an app outside of the defined radius, the app remains locked and the user cannot access the app data.

User example: A user can access merger and acquisition data while they are in their office location. When they move outside of their office location, this sensitive data becomes inaccessible.

Secure Mail App policies

Background network services

Why use this policy: Background network services in Secure Mail leverage Secure Ticket Authority (STA), which is effectively a SOCKS5 proxy to connect through NetScaler Gateway. STA supports long-lived connections and provides better battery life compared to micro VPN. Thus, STA is ideal for mail that connects constantly. Citrix recommends that you configure these settings for Secure Mail. The NetScaler for XenMobile wizard automatically sets up STA for Secure Mail.

User example: When STA isn't enabled and an Android user opens Secure Mail, they are prompted to open a VPN, which remains open on the device. When STA is enabled and the Android user opens Secure Mail, Secure Mail connects seamlessly with no VPN required.

Default sync interval

Why use this policy: This setting specifies the default days of email that synchronize to Secure Mail when the user accesses Secure Mail for the first time. Be aware that 2 weeks of email takes longer to sync than 3 days and prolongs the setup process for the user.

User example: If the default sync interval is set to 3 days when the user first sets up Secure Mail, they can see any emails in their Inbox that they received from the present to 3 days in the past. If a user wants to see emails that are older than 3 days, they can do a search. Secure Mail then shows the older emails stored on the server. After installing Secure Mail, each user can change this setting to better suit their needs.

Device Policies and Use Case Behavior

Device policies, sometimes referred to as MDM policies, determine how XenMobile works with devices. Although many policies are common to all devices, each device has a set of policies specific to its operating system. The following list includes some of the device policies and discusses how you might use them. For a list of all device policies, see the articles under Device policies.

App inventory policy

Why use this policy: Deploy the App inventory policy to a device if you need to see the apps installed by a user. If you don't deploy the App inventory policy, you can see only the apps that a user installed from the XenMobile Store and not any personally installed applications. You must use this policy if you want to blacklist certain apps from running on corporate devices.

User example: A user with an MDM-managed device cannot disable this functionality. The user's personally installed applications are visible to XenMobile administrators.

App lock policy

Why use this policy: The App Lock policy, for Android, allows you to blacklist or whitelist apps. For example, by whitelisting apps you can configure a kiosk device. Typically, you deploy the App lock policy only to corporate owned devices, because it limits the apps that users can install. You can set an override password to provide user access to blocked apps.

User example: Suppose that you deploy an App lock policy that blocks the Angry Birds app. The user can install the Angry Birds app from Google Play, yet when they open the app a message advises them that their administrator blocked the app.

Connection scheduling policy

Why use this policy: You must use the Connection scheduling policy so that Android and Windows Mobile devices can connect back to XenMobile for MDM management, app push, and policy deployment. If you do not deploy this policy and have not enabled Google Firebase Cloud Messaging (FCM), devices will not connect back to XenMobile. It is important to deploy this policy in the base package for enrolling devices. The Scheduling options are as follows:

Always - Keeps the connection alive permanently. Citrix recommends this option for optimized security. When you choose Always, also use the Connection timer policy to ensure that the connection is not draining the battery. By keeping the connection alive, you can push security commands like wipe or lock to the device on-demand. You must also select the Deployment Schedule option Deploy for always-on connection in each policy you deploy to the device.

Never -  Connects manually. Citrix does not recommend this option for production deployments because the Never option prevents you from deploying security policies to devices; thus, users never receive any new apps or policies.

Every -  Connects at the designated interval. When this option is in effect and you send a security policy, such as a lock or a wipe, XenMobile processes the policy on the device the next time the device connects.

Define schedule - When enabled, XenMobile attempts to reconnect the user's device to the XenMobile server after a network connection loss and monitors the connection by transmitting control packets at regular intervals within the timeframe you define.

User example: You want to deploy a passcode policy to enrolled devices. The scheduling policy ensures that the devices connect back to the server at a regular interval to collect the new policy.

Credentials Policy

Why use this policy: Often used in conjunction with a WiFi policy, the Credentials policy lets you deploy certificates for authentication to internal resources that require certificate authentication.

User example: You deploy a WiFi policy that configures a wireless network on the device. The WiFi network requires a certificate for authentication. The Credentials policy deploys a certificate that is then stored in the operating system keystore. The user can then select the certificate when connected to the internal resource.

Exchange policy

Why use this policy: With XenMobile, you have two options to deliver Microsoft Exchange ActiveSync email.

Secure Mail app - Deliver email by using the Secure Mail app that you distribute from the public app store or the XenMobile Store.

Native emal app - Use the Exchange policy to enable ActiveSync email for the native email client on the device. With the Exchange policy for native email, you can use macros to populate the user data from their Active Directory attributes, such as ${user.username} to populate the user name and ${user.domain} to populate the user domain.

User example: When you push the Exchange policy, you send Exchange Server details to the device. Secure Hub then prompts the user to authenticate and email begins to sync.

Location policy

Why use this policy: The Location policy lets you geolocate devices on a map, if the device has GPS enabled for Secure Hub. After you deploy this policy and then send a locate command from the XenMobile server, the device responds back with the location coordinates.

User example: When you deploy the location policy and GPS is enabled on the device, if users misplace their device, they can log on to the XenMobile Self Help Portal and choose the locate option to see the location of their device on a map. Note that the user makes the choice to allow Secure Hub to use location services. You cannot enforce the use of location services when users enroll a device themselves. Another consideration for using this policy is the effect on battery life.

Passcode policy

Why use this policy: The passcode policy allows you to enforce a PIN code or password on a managed device. This passcode policy allows you to set the complexity and time-outs for the passcode on the device.

User example: When you deploy a passcode policy to a managed device, Secure Hub prompts the user to configure a passcode or PIN, which they must unlock before they can gain access to their device when they turn on the device or when the inactivity timer expires.

Profile removal policy

Why use this policy: Suppose that you deploy a policy to a group of users and later need to remove that policy from a subset of the users. You can remove the policy for selected users by creating a Profile removal policy and using deployment rules to deploy the Profile removal policy only to specified user names.

User example: When you deploy a Profile removal policy to user devices, users might not notice the change. For example, if the Profile removal policy removes a restriction that disabled the device camera, the user won't know that camera use is now allowed. Consider letting users know when changes affect their user experience.

Restrictions policy

Why use this policy: The restriction policy gives you many options to lock down and control features and functionality on the managed device. You can enable hundreds of restriction options for supported devices, from disabling the camera or microphone on a device to enforcing roaming rules and access to third-party services like app stores.

User example: If you deploy a restriction to an iOS device, the user may not be able to access iCloud or the iTunes store.

Terms and conditions policy

Why use this policy: You might need to advise users of the legal implications of having their device managed. In addition, you may want to ensure that users are aware of the security risks when corporate data is pushed to the device. The custom Terms and Conditions document allows you to publish rules and notices before the user enrolls.

User example: A user sees the Terms and Conditions information during the enrollment process. If they decline to accept the conditions stated, the enrollment process ends and they cannot access corporate data. You can generate a report to provide to HR/Legal/Compliance teams to show who accepted or declined the terms.

VPN policy

Why use this policy: Use the VPN policy to provide access to backend systems using older VPN Gateway technology. The policy supports a number of VPN providers, including Cisco AnyConnect, Juniper, as well as Citrix VPN. It is also possible to link this policy to a CA and enabled VPN on-demand, if the VPN gateway supports this option.

User example: With the VPN policy enabled, a user's device opens a VPN connection when the user accesses an internal domain.

Webclip policy

Why use this policy: Use the Webclip policy if you want to push to devices an icon that opens directly to a website. A webclip contains a link to a website and can include a custom icon. On a device a webclip looks like an app icon.

User example: A user can click on a webclip icon to open an internet site that provides services they need to access. Using a web link is more convenient than needing to open a browser app and type a link address.

WiFi policy

Why use this policy: The WiFi policy lets you deploy WiFi network details, such as the SSID, authentication data, and configuration data, to a managed device.

User example: When you deploy the WiFi policy, the device automatically connects to the WiFi network and authenticates the user so they can gain access to the network.

XenMobile Store policy

Why use this policy: The XenMobile Store is a unified app store where administrators can publish all the corporate apps and data resources needed by their users. An administrator can add Web apps, SaaS apps, MDX wrapped apps, Citrix productivity apps, native mobile apps such as .ipa or .apk files, iTunes and Google play apps, web links, and XenApp and XenDesktop apps published using Citrix StoreFront.

User example: After a user enrolls their device into XenMobile, they access the XenMobile Store through the Citrix Secure Hub app. The user can then see all the corporate apps and services available to them. Users can click on an app to install it, access the data, rate and review the app, and download app updates from the XenMobile Store.

Back to Top