Windows Information Protection (WIP) in action

Windows Information Protection:

“helps to protect against this potential data leakage without otherwise interfering with the employee experience. WIP also helps to protect enterprise apps and data against accidental data leak on enterprise-owned devices and personal devices that employees bring to work without requiring changes to your environment or other apps”

It is a technology that is limited to Windows 10 desktops and is typically deployed via Intune using App Protection Policies.

To get there you’ll need to navigate to the Microsoft Intune service in the Azure portal and then select Client apps from the menu on the left.

You’ll then need to select App protection policies.

You’ll need to create a policy if one does not already exist.

For Windows 10 there are two policy options, with and without enrolment. The difference is that “with” enrolment the machine is effective using MDM (device management) and is typically directly connected to Azure AD. “Without” enrolment is typically just MAM (only application management) and is typically not directly joined to Azure AD. I’ll focus on a “with enrolment” option here but “without” is pretty much identical in the options provided.

Once the policy is in place don’t forget that you’ll also have to assign it to a group of users for it to take action. However, before you actually assign it to live set of users in your environment, you may want to take a moment to understand the ramifications of what the policy will do.

If you examine the Required settings of the policy, as seen above, you will see that you can set an option for the Windows Information Protection mode. If you are just testing things and don’t want to impact or change your environment then I recommend the Silent option. If however, you want to have the policy protections enabled but want a choice when it is applied, select Allow Overrides (recommended). If you want to be totally strict about applying the policy to your Windows 10 devices, select Block.

The domain for your tenant should appear in the Corporate identity field below. If you have any addition domains you use, ensure they are entered in this field.

If you then examine Advanced options, as shown above, you should see that an existing entry for Cloud resources already exists. When you drill into this, it should contain your Office 365 environment. I spoke about this location more in a previous post:

Intune App Protection blocking browser

and noted that you may need to make some adjustments to it to allow non Microsoft browsers on Windows 10 machines.

The interesting part is now if you also have on premises infrastructure you wish protected. So, imagine the Windows 10 devices are accessing data from Office 365 and from a local file server. By default, this local infrastructure will be considered ‘personal’ and won’t allow saving of corporate data there. In essence, Windows Information Protection (WIP) prevents corporate data being saved to personal locations. By default, your Microsoft 365 environment will be configured as a corporate data location but local fileservers will not be. Thus, if you wish to have your local infrastructure also classified as corporate data, then you need to specify your local DNS domain and IP range as I have done above as a Network Boundary. However, be warned, this has other implications that you need to consider which I’ll speak about later.

There are additional options if you scroll down further. When data that is protected by WIP is stored on a device covered by this policy, it will be protected by WIP encryption at rest. An option here in the policy allows you to revoke these encryption keys if the device is ‘unenrolled’ from Azure AD. That means, the moment the device is removed from Azure AD, any corporate data will be unable to be read since the encryption keys will be revoked for the device. You can generate and upload a recovery agent as you see above if required, however modern Windows 10 releases will actually recover the key from Azure AD if that same machine is re-joined again to Azure AD.

I have also select the option to Show the enterprise data protection icon which will appear on documents WIP considers corporate data. This is always a good way to distinguish corporate data, so my best practices is to have it there as a reminder.

You’ll also see that you can use Azure RMS (rights management) with WIP if you want. I’ll leave this disable for simplicity now, but if you want that extra protection that Azure RMS gives, then it is available if you have a license for RMS.

If those options are now saved to the policy and the policy is actually assigned to a set of users, once the policy has been fully assigned to a device you will see something like the above.

Here you will notice that all the OneDrive for Business files have been classified as corporate data as noted by the briefcase graphic in the file type icon. You will also note a new column as well – File ownership, which contains the domain you configured.

If I look at the data on a local file server I see the additional File ownership column again, with all data being owned by my domain.

Thus, all data from Office 365 and my local infrastructure is now considered corporate, not personal, data. This means that it can only be accessed using the apps I have authorised to access corporate data in the policy.

So how does this all work in practice? As an example, I created a new data file on the local Windows 10 device subject to the App Protection policy. This file is currently considered a personal file because it doesn’t have the briefcase graphic in the file icon.

I can change the file from personal to corporate by right mouse clicking, selecting File ownership and then picking the option that I want. Here’s I’d choose Work (ciaops.com) to swap that file to being considered corporate data.

Once I make the option to categorise it as corporate data, you’ll see the logo changes immediately to indicate the file is now managed. The file has also now been encrypted by WIP on the local device for protection. The user doesn’t see this as the WIP encryption/decryption is handled seamlessly behind the scenes on the device.

Now that this data is a corporate file, only apps that I have defined as corporate apps can open that file. You’ll see above that Notepad will work on both types of files, corporate and personal, but what happens if you try and open this corporate file with a non corporate app like Wordpad, which, as you can see, says it will only open personal files?

What happens, is that the corporate file cannot be opened by the non corporate app as shown above and I get an denied message.

You’ll see that I get a similar result if I try and copy data from a corporate app and attempt to paste to a personal app. Because I set the option earlier in my policy to Allow Overrides, I see the options shown above indicating that I can proceed pasting corporate data into a non corporate app but the actions may be tracked.

The way that I can tell whether the data in the file is being protected and considered corporate is with a small briefcase icon in the upper right as shown above.

If I select this icon I get further information that the app is being managed by my domain as shown.

This means in summary, that you can use WIP applied via Intune App Protection policies to ensure that defined corporate data does not end up in non corporate locations. WIP corporate data while stored on a Windows 10 device is protected at rest by encryption.

Also, remember that not all Windows 10 devices will be enrolled into your Azure AD. Some may just be associated (typically BYOD). By implementing a Windows 10 App Protection policy Without Enrolment you can protect the corporate data that is on these device as well. A good scenario here is to imagine a user’s personal Windows 10 Home machine that they use to access corporate data after hours to work on while not on their corporate joined devices. This means you can protect data even on Windows 10 Home editions machines (via a  non enrolled App Protection policy).

There are some issues to be aware of here, especially when you start mixing WIP with on premises locations. The best way to explain this is via an example I’d suggest. I set up WIP to include my local server and when the policy applied, all the data on that server was considered corporate. The apps that I used are mainly those that were set up in the Intune policy such as Word, Excel, etc as well as some custom apps like Adobe Acrobat Reader which I have detailed how to do here:

Adding Acrobat Reader as an Allowed app

Where things came unstuck a tad was when I wanted to use a not so common app like Keypass. The Keypass app lived on my Windows 10 machine but that data lived in the on premises server. Thus, the Keypass app could only open ‘personal’ data but all the data on the local file server, including the Keypass data file, was now ‘considered’ corporate data thanks to the Network Boundary settings in the policy. In short, I couldn’t open the data when I needed to. Moving the data file to other locations didn’t help either as it was still considered corporate data and the Keypass app could only open personal data. Annoying to say the least.

In the above scenario, with a small number of custom apps required to open data, you could add these custom apps to allowed list of apps in the policy so they are permitted to work with corporate data. If that becomes to hard then you probably need to evaluate whether you want your on premises infrastructure classified as ‘corporate’ data. However, failing to do that means you can’t copy from locations defined as corporate, such as Office 365, to these.

As you can see from the above, when I attempt to copy from my OneDrive for Business (corporate location) to a location that is considered non-corporate (local server) I get the above. Because I specified the ability to override I do get a bypass option but you’ll see when I do that, the data I copy will have it’s corporate protection removed and reverted to a personal data.

The key message is therefore that implementing WIP is something you need to think about carefully and plan prior to implementing. If you get it wrong then it will be a huge source of frustration for users, However, implemented correctly it is yet another way to protect your corporate data on both managed and unmanaged Windows 10 devices.