Intune’s App protection policies are rules that ensure an organization’s data remains safe or contained in a managed app. These policies can be used to manage and protect your organization’s data when using a protected application on a managed or unmanaged iOS or Android devices.
If you’re curious about whether a specific app can be protected by Intune app protection policies, go check out the official list of Microsoft Intune protected apps available for public use.
When configuring App Protection Policies, there are a great many settings and options available for you to tailor app protection policies. You’ll need to tailor them to meet your organization’s data loss protection needs and within your acceptable risk-aversion comfort levels. In other words, the great flexibility that all the options, and possible combinations thereof, provide you can lead to complexity in trying to figure out what policy settings will work best for your needs.
This all boils down to one question: when there are 100 ways to do something, how do you decide on the 1 way that works for you—especially if you’re new to Intune? And [drum roll] the answer is: use the app protection policy data protection framework.
App protection policy data protection framework
The app protection policy data protection framework was created to help organizations who are asking themselves that very question–as well as give you the Microsoft recommendations for the policy settings to use. The framework provides three levels of enterprise data protection for mobile app data that you can choose from:
- Basic (Level 1). Microsoft recommends this configuration as the minimum data protection configuration for an enterprise device.
- Enhanced (Level 2). Microsoft recommends this configuration for devices where users access sensitive or confidential information. This configuration is applicable to most mobile users accessing work or school data. Some of the controls may impact user experience.
- High (Level 3). Microsoft recommends this configuration for devices run by an organization with a larger or more sophisticated security team, or for specific users or groups who are at uniquely high risk (as one example, one organization identified users who handle data whose theft would directly and seriously impact their stock price). An organization likely to be targeted by well-funded and sophisticated adversaries should aspire to this configuration.
Rather than just tell you what settings you need to configure for each app protection policy level, the framework provides .JSON files that you can download and import directly into your Intune tenant and create the required policies. Pretty cool. The team has done a great job documenting a lot of this on their GitHub repo’s read me page so I won’t try and recreate the wheel here, but continue on if you want to see what it looks like in action.
Get the app protection policy framework policies
After you’ve decided which policy level works best for you, it’s time to go get the necessary PowerShell scripts to make all this happen. Don’t worry, you don’t have to be a PowerShell guru to figure this out.
Download the ManagedAppPolicy_Import_FromJSON.ps1 script. This script lives in the repository of PowerShell sample scripts you can use to do Intune things. Useful things you can’t necessarily do using the MEM admin center portal—things like exporting and importing policies. In this case, you’ll be importing the framework example policies in .JSON format into your Intune tenant using the sample script.
Next, head over to the Intune Configuration Frameworks GitHub repo and download the policy samples in .JSON format. I generally just clone interesting GitHub repos to my local computer using Git Bash so I can keep my local files in sync with the latest from the GitHub repo, but you could also just download the .zip file and that will contain everything you need.
Either way you do it, you’ll end up with a couple of files and folders on your local system. For now, we’re only interested in the ones in the AppProtectionPolicies directory.
Import the app protection policy framework policies
Now that you have the policy import script from the GitHub Intune samples repo and the scripts that you want to import, put them all in the same directory and open a Windows PowerShell console at that location to get down to business.
Make sure you’ve met the prerequisites for using the PowerShell scripts, including the Azure AD PowerShell module (Install-Module AzureAD) and have the necessary account permissions to make the magic happen. The first time you use one of the Intune samples scripts you’ll need Azure AD Global Administrator permissions and afterwards you’ll always need Intune administrator permissions.
The hard part is over, now we just need to get the policies from GitHub into our Intune tenant so they can be assigned to the appropriate Azure AD groups. In your PowerShell console (I’m using VS Code with the PowerShell extension) just run the script we got from the Intune samples repo, ManagedAppPolicy_Import_FromJSON.ps1, and feed it the name of the policies that you want to import into your tenant. I mean, why stop at just one policy when you can import the entire framework easily right?
Level 1: enterprise basic data protection
This app protection policy ensures that apps with work or school account data are protected with a PIN, encrypted, and enables selective wipe operations. Android device attestation validation is also done for Android devices.
There are two basic data protection policies to import, one for Android and one for iOS. Let’s start with the basic enterprise data protection policy for Android (level-1-enterprise-basic-data-protection-Android.json).
When you first launch the import script, you’ll be prompted to log into your Intune tenant, use your Intune or Global Administrator credentials for that. Next, just tell it which .JSON you want to import.
Next, you’ll see PowerShell do some PowerShell’y things to import the policy into your Intune tenant. Rinse and repeat to import the basic app protection policy for iOS (level-1-enterprise-basic-data-protection-iOS.json). You should now have two shiny new app protection polices based on Microsoft’s recommendations ready to assign. It’s almost too easy.
If you execute all these import commands from your PowerShell console within 60 minutes, you shouldn’t be asked to log in again.
Level 2: enterprise enhanced data protection
This app protection policy level introduces data leakage prevention mechanisms and minimum operating system requirements. This is the configuration that is applicable to most mobile users accessing work or school data.
The process to import the enhanced level app data protection policies is the same as we’ve just done to import the basic framework policy. However, you should review the defaults set in the policy .JSON to ensure they meet your requirements before importing them. By default, the minimum operating system level required by the policy is 5.0 for Android and 12.4.6 for iOS. If you’d prefer something else, change that before importing the .JSON.
Now, just do what you know you need to do by this point and use the trusty ManagedAppPolicy_Import_FromJSON.ps1 script to do your bidding and import the enhanced data protection policy JSON files for Android and iOS (level-2-enterprise-enhanced-data-protection-Android.json and level-2-enterprise-enhanced-data-protection-iOS.json).
Now we’ve added four new polices and have just two more to go.
Level 3: enterprise high data protection
These app protection policies are for devices used by specific users or groups who are uniquely high risk (for example, users who handle highly sensitive data where unauthorized disclosure causes considerable material loss to the organization).
You know the drill by this point, but before you import the high data protection policies for Android and iOS, make sure you review the following default setting values to be sure they meet your requirements:
- Min OS Version is set to 12.4.6 for iOS and 8.0 for Android.
- Max allowed threat level is set to Secured / Block access.
- Transfer telecommunication data to is set to “replace_with_dialer_app_url_scheme” or iOS and “Any policy-managed dialer app” for Android.
- Select keyboards to approve in Android may need to be customized with the supported list of Android keyboards for your organization.
Couple more clicks and you’re done.
Review and assign the imported framework policies
All that’s left is for you to assign the policies, right? Well, maybe, but I for one would prefer to review the policy settings in the MEM admin center portal to be sure all the apps I want to protect are included and the data protection, access requirements, and conditional launch settings are configured appropriately for my organizational needs—not just according to Microsoft’s baseline recommendations.
Another thing you might want to change is the way the policies are targeted to devices. By default, all of these policies will apply to all types of devices. In other words, they will apply to devices whether they are managed or unmanaged. In general, you’ll probably want to keep policies targeting unmanaged devices a little stricter than those targeting managed devices. That because on managed devices we control the security configurations and ensure a device PIN, encryption, jailbreak/root detection etc. That being said, if the recommended policy setting work for you whether the device is managed or not, go for it. I’m a big fan of keeping things simple with as few policies floating around out there as possible.
Got the policies the way you want them? Go ahead and assign them to the appropriate user groups and let the app data protection begin!
Next steps
After you’ve deployed the app protection framework policies, you’ll need to monitor them just like any other policy you deploy with Intune.
And now that you’ve got the hang of working with the Intune PowerShell examples, you can also leverage the ManagedAppPolicy_Export.ps1 script to make a local back-up of your final policy settings. It’s a pretty easy script to figure out and use, and you should. I have faith in you.
You’ve seen my blog; want to follow me on Twitter too? @JeffGilb
