Windows Information Protection done right, part 2: typical set up steps

Last time we talked about a couple of key concepts including enlightened and non-enlightened apps, and how Windows Information Protection (WIP) treats corporate data differently than personal. In short, a non-enlightened app and all of its data will be treated by WIP as personal (by default). However, if you choose to add a non-enlightened app to the protected apps list, then WIP will consider this app data as corporate.

Enlightened apps, by contrast, can handle both personal and corporate data at the same time, and distinguish between the two. Since a non-enlightened app cannot tell the difference between these worlds, it is best to be very careful in adding non-enlightened apps to protection. You should only add Line of Business apps, which deal with 100% corporate data, per Microsoft’s recommendation.

One thing I did not yet mention, but that we really should cover, is that these policies are configurable via the Microsoft 365 admin center from Devices > Policies. But DO NOT use this console to setup WIP. Ever. Never ever. Result will be a terrible user experience. Work only in the Intune / Device management portal. You have been warned.

With that point fresh in our minds, let’s setup a basic WIP policy.

Windows 10 App protection policy (with enrollment)

Remember from last time that we are really only interested in MDM-based deployments of Windows Information Protection. This is for two reasons:

1. MAM-based deployments only support enlightened apps
2. In my opinion, an unmanaged Windows device should not be accessing corporate data (in most business environments). Even non-domain, BYOD devices should be required to enroll and maintain compliance with organization policies, so that the company has adequate leverage and monitoring in place on the endpoint.

If you want more information on the differences between these deployment models, check out this article.

WIP is found under Client apps > App protection policies. Click Create policy.

Be sure to choose Windows 10 as the Platform and With enrollment. (You do not need to configure Without enrollment as long as you enforce device compliance using Conditional access; allowing open access for modern client applications not recommended except in the most open and low-security environments).

Under Protected apps, pick Add apps.

Several Recommended apps will be available for you to add, which is easily done by ticking the check boxes next to each line item.

However, if you have other apps that you want to add, or if you want to be really mindful about which apps and executables are included with protection, this can be accomplished using the Store or Desktop apps category (most likely, Desktop apps).

The most important value to input correctly is the executable name (just the filename, no file path required). Example:

• Name: Microsoft Word
• Publisher: O=Microsoft Corporation, L=Redmond, S=Washington, C=US
• Product name: *
• File: winword.exe
• Min version: *
• Max version: *
• Action: Allow

Note, you may want to be careful about using * too liberally in these fields. For instance if you do not know how to define the Publisher field, you could use a *, but that means any publisher could sign an executable with that file name, and the policy would still protect the data in that app (treat it as corporate). To find the publisher for any given app from PowerShell:

Get-AppLockerFileInformation -Path <path to exe> | fl

The Publisher field is what you’re after (just the portion up to the C=<country> is required).

As you think about the apps in your environment, just try to be thorough as you build this list. You may not want certain app data getting encrypted, for example, and in some cases you might have apps that touch both personal and corporate data, and are not enlightened–well you have a decision to make there. Protect it and potentially end up with personal data that is mis-classified as belonging to work? Or do not protect it, and block users from accessing corporate data and network locations in that application?

There is one more option, too: if you have apps that you want to exempt from WIP (which means they will be able to access corporate data and bypass the restrictions imposed by WIP), then you can do that under Exempt apps. Obviously this means there could be leakage with that app, but you have to choose your own balance of usability and security. (Note: System processes are also exempt by default).

Required settings

Next go to Required settings. If this is your first time implementing WIP, I would recommend either using the Silent or Allow Overrides option.

With the Silent option, events where data is relocated from corporate to personal locations is just logged. However, app data is still encrypted, and you can also see and validate on any workstation under this policy which apps are being treated in which contexts. Simply open Task Manager, go to the Details tab, and add the column called Enterprise context.

The Allow Overrides option is just like it sounds, instead of being blocked when relocating data, users would simply be prompted with a message similar to the following:

Additionally, users can choose to switch existing file ownership between work and personal using File explorer. Simply right-click on any file and find the File ownership option.

Whether you are using Silent or Allow overrides, there are several methods you can use to audit the events related to WIP activity. In the event viewer go to: Application and Services Logs\Microsoft\Windows and find all the logs that start with EDP-:

This article illustrates other methods including CSP and Azure Monitor.

Otherwise, if you absolutely require it, or are sure about the full Block option, you can go with that selection, and users would see a different prompt, with no option to continue.

Advanced settings (define network boundaries)

Another important consideration is your network boundary lines. WIP deals with protection on the endpoint, so saving or syncing corporate data to local storage locations on the device itself is handled seamlessly. But WIP isn’t smart enough to know on its own what are your corporate storage locations out on the local area network, or even on the Internet. Since it is very likely your users will be saving data to outside storage locations, you must also explicitly list them out when you build the policy.

Under Advanced settings, click Add network boundary. Pick Cloud resources to start.

In the above example, I am adding my tenant’s SharePoint locations, such as itpromentor.sharepoint.com and itpromentor-my.sharepoint.com (OneDrive for Business). We separate these values with a pipe | and no spaces. Also, watch for the note about adding |/*AppCompat*/ at the end of your string. If you don’t do this you will get some really funky behaviors on non-enlightened, non-protected web browsers. Like web browsing just doesn’t work.

Check out this article for a list of common locations to include for Office 365. As well, take a look at this article about OWA–which may have some special considerations since users could potentially have personal 365 accounts at Outlook.com, etc. And of course, you probably have third party cloud apps and locations to account for, as well.

Plus, you may need to specify on-premises infrastructure and storage locations if that still applies in your environment, using Network domains and IPv4 ranges.

Now this process gets really tricky because all of that data out in the corporate address space will be viewed and treated as corporate as soon as it is added to your boundary in the WIP policy. And that means that any personal apps or applications which are not included in the protected apps list will no longer be able to open data from those locations, or save data to them. So you need a really good inventory of both:

1. The corporate network locations (e.g. FQDN’s and IP ranges)
2. The “non-enlightened” apps in your environment that may require protection because they access stuff from those corporate locations

Finally you can scroll down through the other options. I generally accept the defaults, except that I like to display the briefcase icon, so we can clearly see when we are working with corporate data.

You can hover over the information icon in case you want to read the descriptions for these other settings, but like I said the defaults will probably suffice for most use cases.

Wheew…

As you can see, there are many considerations for Windows Information Protection. So my advice stands, that you should only implement this with very careful planning and only after you are sure that your requirements call for it. If your organization is concerned with data leakage, and wants some level of protection against it in place, this can be a powerful tool.

Keep in mind that some training should come with this change. Users should be prepared to understand that there is a difference between working in personal and corporate contexts, and that protecting company data is as much their responsibility as IT’s (particularly if you are allowing the override option).

And, although I’m generally down on the unmanaged device thing, it does give companies a way to pull back corporate data from unmanaged endpoints, without causing harm in the process to other apps or the device itself (only the enlightened apps are impacted).

So there may be use cases for it–but my opinion is that Windows devices should never, or with very rare exception, be excluded from management (even if they are BYOD). If you want access to corporate data on your device, and you need more than just web access, then you should enroll your device. More on workstation security to come…