Windows Information Protection done right, part 1: education and background

A while back I mentioned that WIP policies are not something you should turn on blindly, as they can have disastrous consequences. That is true, when implemented without a plan. However, it is also a very powerful tool that is included with all Microsoft 365 subscriptions (yes, even Business). So it pays to understand when you would or should use it, and how to set it up properly so that you can provide a decent user experience as well.

Why WIP?

Windows Information Protection is Microsoft’s Endpoint DLP solution. It’s purpose is: 1) to protect corporate data (using encryption) and 2) to prevent leakage of that data outside of corporate contexts–for example by blocking copy/paste or export/save to non-corporate locations.

Here is a good, short video from Matt Soseman, a Security Architect at Microsoft, that demonstrates what the experience would look like, if you want to check that out.

Encryption is great because I know that if corporate data were to be compromised, it would be useless without the right credentials or context (an Intune-managed Windows 10 computer). It also means I can kill access to that data if the device itself were to become lost or stolen.

Being able to control the movement of corporate data is a further benefit that I enjoy as an admin, because it means that my company’s data is safe, and it will only be stored in locations and on devices that I approve, manage and control.

Note that you can take advantage of the first half of WIP (encryption) without having to implement the second part (a “hard block” against copy/paste/export). And, it is also possible to implement a “soft block” by allowing user overrides, or in fact to have it do nothing but sit there silently, logging the relocation events only.

But before we get into the various configuration options, it is important for us to cover a couple of key concepts. This background is necessary in order for you to effectively create the best policy set for your customers and end users.

Enlightened vs. Non-Enlightened apps

Microsoft publishes an API that allows developers to create “enlightened” apps. An enlightened application has the capacity to understand the difference between corporate and non-corporate data when WIP is present. For example, Outlook is an “Enlightened app” which just means that I could have a personal account at a place like gmail.com, as well as a business account through Office 365 with my employer, and Outlook would be able to segregate that data using WIP.

But what about applications that are not written to be “smart” like Outlook or the other Microsoft apps? Is it still possible to protect a non-enlightened app? What about my decades-old Line of Business app? I may need to copy/paste data from there all the time!

The answer is yes. You can protect Line of Business and other third party apps. When you add an outside application to your WIP policy that is not an “enlightened app” it means that every bit and byte within that app and exchanged by that app is considered to be corporate data. Remember–the app isn’t “smart enough” to distinguish. So Windows is going to put the entire app into the “corporate data” bucket, and treat it accordingly.

This has important implications you need to track.

Whenever you wrap a non-enlightened app with WIP, you will notice something: a small briefcase icon in appears in the title bar of the application, usually up near the buttons to minimize, expand and exit. That icon means you are working in a corporate context. But unlike the enlightened apps, it will never be able to switch itself from corporate to non-corporate depending on context.

Now for a regular Line of Business app that only ever houses corporate data, that’s perfect! But what about a third party browser, for instance–Chrome–which may be used to access both corporate and non-corporate locations?

Yes, you guessed it, WIP will assume that everything you do and interact with through that application is “corporate data.” Edge on the other hand, is indeed an enlightened app, and will respect the boundaries that are intended between personal and corporate contexts (you can also tell WIP what domains to include or not as protected locations).

As well, any files saved or downloaded from that application will also be encrypted by WIP on the local file system. In file explorer, you will notice that the files have the briefcase icon superimposed on them as well, and a new attribute or column, which describes the ownership as corporate or not.

So just be sure to keep the distinction in mind, and the full implications–when you choose to protect “non-enlightened” apps, you are turning all the app data into corporate data. This also makes it very difficult to go back on the decision to protect a non-enlightened app. In fact, Microsoft warns that you may need to uninstall and reinstall the application after removing protection.

MDM vs. MAM-based WIP management

The other key concept you need to understand is the difference between MDM and MAM-based WIP policy. Windows Information Protection can be implemented either against fully enrolled and managed devices (MDM) or against non-managed devices (MAM). But, there are a few differences in the policy options and controls available between the two.

The biggest difference: when you choose to implement MAM-based WIP (Without enrollment), it is not possible to protect non-enlightened, third-party Line of Business applications. This can only be done against a fully managed device (With enrollment) which is Intune-controlled via MDM.

This implies that for 95% of organizations that I consult with, MAM-based policy is highly limited, if not outright worthless. There are almost always some non-Microsoft / non-enlightened apps that customers will be using. Of course, over time if more developers implement the API… well… we will see. In the meantime, I am personally only recommending WIP with enrollment. (There are other reasons this is preferred–as I get more control over the device with compliance and device configurations when they are forced to enroll via conditional access).

The last important distinction to note is that MAM-based WIP does require Azure AD Premium P1, in addition to Intune. That’s not a problem for most customers who bought Intune via an Enterprise Mobility + Security subscription or a Microsoft 365 Enterprise subscription, but there is the matter of Microsoft 365 Business, which does not include a full version of Azure AD Premium P1 (rather we have a subset of the features in that SKU). Nevertheless, I have confirmed that the MDM-based WIP, at least, is indeed included across all of the Microsoft 365 SKU’s, including Business.

Other limitations

It is also going to be important for you to understand the other limitations of using WIP. You do not want to implement this and be blindsided, right? So take the time to review this article by Microsoft. The biggest points are:

• Only works in 1-1 environments (1 user per 1 device); not supported on Shared Computers
• Changing your primary corporate identity / logon name is not supported while using WIP (it would need to be disabled on all devices for that user before the change, and re-enabled/redeployed again afterward)
• Redirected folders with Client Side Caching are not supported (use OneDrive for Business instead)
• ReFS is not supported
• And more…

Until next time…

Okay, so now that we have those concepts behind us, next time we can do a walk-through of some typical configuration. Note that since every organization has their own LOB apps and network locations that you will likely want to add to protection, it would be hard to “script out” a dummy installation script for every customer (if you’re a consultant like me). But that’s okay. I’ll show you how to get started, anyway. And you can customize your deployments from there.