Home > News > Intune App Protection Policies – Securing Your Corporate Data
Securing your corporate data while unleashing the mobility of your workforce is one of the toughest challenges many companies face in the shift from corporate-owned devices (COD) towards a mixed of corporate and BYOD devices. Securing this data should form a core part of your data loss prevention (DLP) strategy. Microsoft Intune is a mobile device (MDM) and mobile app management (MAM) solution that provides policies enabling the management of these devices. Leveraging Intune app protection policies, you can help bolster your compliance with your DLP policies without impacting usability.
App protection policies are a set of rules that are applied to specific apps enabling additional layers of security; these app protection policies can be used to:
App protection policies should be applied in any scenario where corporate resources need to be accessed on a mobile device, these policies are not complicated but care needs to be taken before deploying them.
To utilise Intune and its app protection policies each user must be assigned one of the following licenses:
To apply Intune app protection policies, launch the Microsoft Endpoint Manager admin centre here, then on the sidebar select Apps, then App protection policies.
Create a new policy by pressing the Create Policy button; you will be given an option of iOS/iPadOS, Android, or Windows 10. In this example, we’re going to select iOS/iPadOS, this will launch the create policy modal.
Give the policy a name and description; in this example, we’ll use the name iOS/iPadOS – Demo Application Policy.
Next, select the device types and apps that will be targeted with this policy. In this example, we will be selecting Managed Devices; if you were deploying into a MAM scenario, you would choose Unmanaged. We’ll then pick a cross-section of some familiar Microsoft apps that are available. There are some additional vendors that also support app protection policies, such as, Zoom and Adobe, a complete list can be found here. You can also enable protection policies on your line of business (LOB) applications by following Microsoft’s documentation here.
Next, we’ll configure the data protection settings; this is where it gets fun. A lot of these settings are self-explanatory; however, we will go through the more relevant settings. Send org data to other apps gives us control over what data can be opened and in what applications, in this instance, we’ve selected Policy Managed Apps and we’re opted to block Save copies to org data. With these applied, users will not be able to open data from managed apps in unmanaged apps, and vice versa. For example, if a corporate email is received with an attached Word document, it can only be opened in Word. If the user attempts to share the document, it can only be shared among other managed apps.
We have also configured Allow user to save copies to selected services to allow OneDrive for Business and SharePoint; this allows our users to store and retrieve corporate data from approved cloud services and prevent storage in any unapproved cloud services. We’ve also prevented the user from saving to the local storage of the device; this prevents circumnavigation of the app protection policies.
Finally, we have restricted web content transfer with other apps to include our managed browser, which in this case is Microsoft Edge. Restricting content to Microsoft Edge means any links in emails, documents, etcetera can only be opened in Microsoft Edge under the corporate context. In this way, we can prevent SharePoint being opened in an unmanaged browser or context.
Next up, we will configure the access requirements. These settings specify what must be met to access apps in a work context. While these settings can be set using an iOS Configuration Profile for managed devices, for unmanaged devices (MAM) this ensures corporate data is protected from unauthorised access by enforcing access requirements. The exact combination of these settings will depend on the proficiency of your staff and the sensitivity of the data to which they may have access.
In the example below, I have configured a stricter set of requirements than what is normally applicable. Firstly, I have set the PIN type to passcode instead of numeric; this means the PIN must be alphanumeric. I have also blocked simple PINs which requires the user to have at least one number, letter and special character to be compliant. We have allowed Touch ID and Face ID to reduce the impact of the more complex passcode requirement. I have also required a work or school account to access managed apps.
Next up is Conditional Launch, here we can create specific app and device conditions and set an action to take if it fails. By default, the max PIN attempts, offline grace periods and Jailbroken/rooted devices are already configured, we will leave these as the defaults. We’ve added a Min SDK version of 7.1.12 as this version is the minimum supported for use when the PIN type is set to Passcode in the select minimum pin length policy we configured in the previous step. We will also apply a minimum OS version of 12.0 for iOS to prevent older iOS devices from accessing corporate data.
Finally, we will assign the policy to a group; in this example, I will select my Demo App Protection Group. Review the policy and press Create. Be careful not to lock yourself or others out from your devices, deploy first to test and pilot groups and consider using a phased approach as opposed to a “big bang” method to help ease the transition.
Once the policy has been deployed, you can check its progress by navigating to Troubleshooting + Support on the sidebar, then select Troubleshoot. From here, you have the option to choose a user, once picked scroll down until you see App Protection Status, on the right select See All to view the status of each app. If the app has not checked in/is not installed, you will get the red X, if the app has a yellow exclamation mark it has checked in but is waiting to receive the policy. Finally, if you get the green tick, the app has checked in, and the policy has been applied.
Once all the polices have applied, users will get notifications the first time they open the secured apps; they will be prompted to restart the app to protect the data. After rebooting the app, they will get notified that the data is now being protected.
If a user attempts to share corporate data, they can share the data to authorised apps only. Any app that is not a policy managed app will no longer appear in the share menu from a policy managed app.
If a user attempts to copy and paste corporate data from a managed app to an unmanaged app, it is blocked. This setting can be modified to allow a specific number of characters to be pasted, as an example, you may choose to allow a maximum of twelve characters so people can copy and paste mobile numbers, however, they would also then be able to copy any text up to twelve characters.
App protection policies are applied after a user signs in and runs the app the first time; this means it’s not much use in shared device scenarios. There is also a limited selection of published apps that currently support app protection.
Intune app protection policies for both managed and unmanaged devices are an elegant way to mitigate the risk of data loss from mobile devices. Pairing these policies with other Azure features such as conditional access, named locations, etc. you can build a powerful framework to help protect your data without compromising on usability and mobility.
If you would like to find out more you can contact us here.