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

Back to Blog

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.

WIP in action. Same thing if I attempt to attach a WIP protected document.

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.

Cannot sync a corporate doc to Personal OneDrive

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.

Look what happens when I add Chrome to my protected apps list

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.

Comments (8)

  • Seb Reply

    Great content, as always. Thanks for sharing! There is one particular scenario I’m using with WIP – screenshot encryption. It would be great to remove the screen capturing option from Windows tray as the image is stored in system memory and encryption can be applied only after “paste” action (too late). The scenario that didn’t work for me is Adobe Acrobat Reader added to WIP apps and opening an AIP protected PDF. Fixing that would open a range of new workloads for both technologies WIP and AIP. At least AIP is now an WIP-enlightened app by default. I wish the same for the new Edge (Chromium). All in all, WIP is currently underestimated and underused technology at MSFT. My view.

    September 30, 2019 at 9:17 am
  • Carl Reply

    Great write up, very easy to understand which is to be commended 😉

    October 1, 2019 at 9:13 am
  • Sam Reply

    Hi,

    All is working as expected for me – aside from 1 missing piece. Guest users.
    Seemingly i am unable to apply WIP to Microsoft apps when access by a Guest user. We can control access via Conditional Access, and can prevent download via Sharing in SharePoint Admin Center – but can’t stop copy & paste (via WIP) for a Guest user.

    It appears that although we can control this for our corporate users and devices, a guest user invited to a Team for example, on their own BYOD device is not subject to WIP.

    Is that right? Is this a glaring loophole or am i mistaken.

    If we try to enforce device registration (to enable WIP), by using the Terms Of Business Conditional Access policy then the user faces an error (probably understandably) when trying to register their device using a Microsoft account and our MDM URL.

    Any ideas? 🙂

    November 14, 2019 at 8:34 am
    • Alex Reply

      Endpoint DLP would not apply to guests–you don’t own those endpoints, so you won’t be drawing a fence on them. If you want to share digital resources with a guest, you would use an information protection label or a sensitivity label to specify what permissions the guest is allowed, and you can choose to block export in that way. Also you can share links that block download, or as you said use Conditional access to block downloads on unmanaged devices.

      Endpoint DLP does not require data to be labeled; corporate users access a large volume of corporate data daily, potentially alongside personal apps and data. It’s just a big blanket policy that helps the user distinguish and separate corporate from personal stuff. Remember also that guest users would have their own corporate environment they are working in, so again the distinction may be in play on their own endpoint too, with respect to their own environment (corporate = their corp, not yours). But a label is much more specific, and can be attached at the file level. Any user, guest or corporate, can open numerous documents all from different orgs with different rights, and it would work just fine.

      Assume that as a guest, you open a document from another org in the Teams app. If your own org protects the Team app on your endpoint, it is considered “inside the fence” so if you downloaded data from that external team, Endpoint DLP could treat that as corporate data (in YOUR company). However, if the document were also labeled by the other corp, then it would still be protected with their preferred permissions.

      November 16, 2019 at 6:57 pm
  • Mohamed Reply

    Great content, Thank you for sharing! Actually all is working except third-party browsers. I am talking here specifically about Chrome and Firefox. it seems that they allowing to share corporate data “Copy, Paste, Sending to personal emails” although they are protected. Edge is working properly as per the policy. However, I am not able to get this done for Chrome and Firefox as well. Do you have any idea why those apps are behaving like this.

    April 13, 2020 at 7:01 am
    • Alex Reply

      Yes–When you take an application that cannot understand then difference between corp/not corp, and protect it, then that means that the app will just treat every piece of data as corporate that it encounters. So in fact you should not add Chrome or Firefox to the list of protected apps if your goal is to prevent sharing of data into non-corporate web apps/locations. Then those apps simply cannot tell the difference, and WIP will look at those browsers as outside of the corporate boundary–they will be treated as personal. As soon as you add them to the protected apps list then they are 100% corporate, regardless of which website you are visiting inside them. They are not enlightened browsers, so that’s the best you can do.

      April 13, 2020 at 12:15 pm
  • Mohamed Reply

    Thank you for your reply. I thought that once we wrap a non-enlightened app with WIP. it will act as of enlightened app. Also you took a snapshot of Chrome while copying corporate content to gmail account. What if Google Chrome isn’t a protected app then the user decided to use it to browse a cloud resource like SharePoint. What is the behavior of WIP then?

    April 13, 2020 at 5:26 pm
    • Alex Reply

      You cannot make non-enlightened behave like enlightened. It isn’t “smart” about the boundary line and so when you protect it the result is that 100% of the app goes into the corporate bucket. By default if you leave the other browsers unprotected you would be prevented from using corporate sites in third party browsers. And in fact I would recommend using the new Edge exclusively now as it is every bit as good as chrome, but supports all the MS stuff like WIP, App Guard, Conditional Access, etc. If you are REALLY serious about the DLP aspect then it is necessary to block apps that do not support the DLP controls. That would include 3rd party browsers. And you may want to consider combining WIP with Conditional Access to prevent download of data on unmanaged devices (and that includes third party browsers, even if the machines are being managed).

      April 14, 2020 at 11:48 am

Leave a Reply

Back to Blog

Helping IT Consultants Succeed in the Microsoft Cloud

Have a Question? Contact me today.