What is Windows Information Protection
We have focused on the detailed description of Windows Information Protection (WIP) in one of our earlier posts, so I would like to link to it here and not to discuss the basics further.
Deployment in Intune - MDM vs MAM
When creating a WIP policy, we have a choice of whether it will be applied to devices managed through the MDM channel (typically corporate devices) or through the MAM channel (typically BYOD devices). If we use both MDM and MAM management types then we need to set two policies.
At the same time, it is necessary to think about how we enroll devices into management. A common configuration today is a hybrid AD with automatic MDM enrollment - which means an on-premise domain controller and synchronization of objects, attributes, and devices with the cloud via Azure AD Connect. Windows 10 devices are then managed through Group Policy and MDM simultaneously. All we need to do is to create an MDM Windows Information Protection policy in Intune and we are good to go.
However, if we allow employees to use personal devices, the situation becomes a bit more complicated. We cannot guarantee that a user voluntarily enrolls his personal device into MAM - for example in Outlook, he can add a corporate email account but after successful login not approve the use of the account elsewhere on the device (which means he does not approve enrollment of the device into Azure AD). If the user does this then his BYOD device will have access to work resources but will not be registered in Azure AD.
Thus, we guarantee that BYOD devices will also be managed via Intune. It should be noted that the above procedure requires Azure AD Premium license due to conditional access and subsequent automatic enrollment to device management.
Windows Information Protection can be configured in four different modes:
- Off: Windows Information Protection is turned off. If WIP has been turned on in the past, switching to this setting decrypts locally stored work files.
- Silent: In this mode, WIP is running but does not block copying information between applications, these actions are only logged. However, unauthorized application access to work files is still blocked.
- Allow Overrides: Both copying between applications and access to work files are prevented. When attempting to copy, the user is informed that he is trying to paste the data into the unmanaged space and is allowed to confirm this and copy the data.
- Block: Both copying between applications and access to work files are prevented, but unlike Allow Overrides, this cannot be bypassed.
From our experience we can say that we always deploy WIP in Allow Overrides mode. In practice, complete blocking is quite restrictive and leads, for example, to a complete prevention of copying to USB drives or to the insertion of data into all unmanaged websites. Certainly it is possible to successfully use WIP in this mode, but it increases administration costs.
Domains and cloud resources
In the WIP policy setting, we specify corporate domains and cloud locations, which are then recognized as work resources in Windows 10. Microsoft publishes a list of recommended cloud domains that you can find here.
However, be aware that this Microsoft-managed list is incomplete and you will have to fill it in on your own. It lacks many O365 domains, such as tasks.office.com, to-do.office.com, or web.powerapps.com. In addition, of course, you must add all custom domains running internal applications.
At the end of the cloud resources list, we can add the /*AppCompat*/ switch to determine how Windows 10 should look at IP addresses. If we do not add this switch to the list, all IPs will be automatically considered as work resources which means communication will be blocked for all non-whitelisted applications. By typing in the /*AppCompat*/ switch, IP addresses will be viewed as personal, allowing many applications that would otherwise be blocked (such as third-party browsers) to function. We therefore recommend not adding /*AppCompat*/ into the rules.
Microsoft also recommends adding neutral services, which are domains that both personal and business applications can communicate with (the login.microsoftonline.com and login.windows.net authentication endpoints).
Local network and exceptions
For the policy, we also specify the DNS suffixes of our corporate domains and the range of IP addresses. Windows 10 devices will then treat all resources on this network as work resources. However, it is important to understand that this logic works from the perspective of a particular device, that is, when it is in this network, everything that it sees around it will be perceived as work resources. However, if the devices connects to the network from elsewhere (VPN, devices behind NAT, etc.) then the reources are not treated as work resources. For this reason, we recommend that you also include FQDNs of network storages (for example dataserver.corp.contoso.com) into cloud domains.
A useful tip from practice is that if you need to exempt some network storages from WIP, you can set them as Proxy servers in the policy settings. WIP rules do not apply to communicatin with such resources.
You set allowed applications based on digital signatures of exe files. Be prepared that identifying all the applications used is a long-term task and that not all applications are digitally signed. In such cases, you will need to whitelist applications based on their placement in folders via the Applocker xml rule.
Some installers do not work correctly when WIP policy is applied. It is therefore appropriate to exclude those frequently used from WIP policy. It is helpful to know that application exceptions take precedence over allowed applications. For example, in case of a non-working Adobe Reader installer, you set an exception to the specific installation file (by the product name - in this case "Adobe download manager") and WIP will not be applied to this file. At the same time, a general rule for exe files signed with Adobe certificates will ensure that Adobe Reader as such is protected.
All blocked actions are logged and we can summarize them in Intune via App learning report, where we find can easily find out what application rules need to be added to WIP policy. Previously, we had the ability to filter actions by specific devices in Windows Analytics, but unfortunately this option was deprecated by switching to Dekstop Analytics, where this report is not available and it does not currently seem to come be backing back in the future.
Windows Information Protection uses EFS to encrypt locally stored work files. When setting up a policy, we upload a private key to the cloud, which can then be used to decrypt the data - so it is essential to save it for future use.
Azure Rights Management Services can be used for encrpytion when copying data to external USB storage. We even have the option to choose a specific RMS template, which will be used for the encryption. For example such that the data copied over to a USB device can only open by people in a specific department.
You can also enable or disable indexing of locally stored encrypted files. Searching in Outlook does not work correctly without allowing this, so we recommend enabling the setting.
In this article, we looked at some specific Windows Information Protection settings and mentioned some pitfalls that we might encounter when deploying WIP and setting it up.
Finally, remember that protectiong data with WIP is not bulletproof and is promoted by Microsoft as a feature that prevents unintentional leakage of corporate information. It is therefore a suitable addition to other data protection technologies.