Windows Information Protection | WIP Learn with Joy Part #1 | Intune

0
Windows Information Protection - A deep dive to the internals

When we talk about Modern Workplace, employee experience is the priority. But there’s another aspect to this which is Information Protection – utmost importance to any organization.

Overview

Every organization tries best to keep their data protected. Sometimes, protection can be highly restrictive to the point that hampers workplace experience causing employee discontent, whereas sometimes it can be too light which leaves a lot of security loopholes. As such the IT Admins/Security Admins has to take tough decisions to balance between the two extremes, since it has a direct impact on the workplace experience of an employee.

Microsoft, being one of the top public cloud service provider, has several products/services in the space of Information Protection, each having its own area or purpose (with some overlaps in few cases), namely

  • O365 Information Protection (DLP) – helps to identify sensitive information across O365 (EXO, SPO, Teams), prevent sharing, monitor and protect sensitive information in desktop versions of Office apps.
  • Azure Information Protection (previously Azure RMS) – helps to classify and protect data by applying labels. Protection is applied directly to content and roams with the content as it moves between locations.
  • Windows Information Protection – helps to protect local data at rest on endpoint devices and manages apps to protect local data in use.
  • Microsoft Cloud App Security – a Cloud Access Security Broker (CASB) solution that allows to discover (on-prem or in-cloud) and monitor data in first-party and third-party Software-as-a-Service (SaaS) apps.
Altaro Office 365 Backup
Advertisement Altaro Office 365 Backup

In an aim to simplify the offerings, Microsoft brought all the above solutions under the unified umbrella of Microsoft Information Protection (MIP) – a complete unified solution to protect sensitive data throughout the lifecycle – inside and outside the organization.

Today however, we will not be discussing about all the different solutions which makes up MIP but instead, will focus on one of its components – Windows Information Protection (WIP) and how it helps to control data in your Windows environment.

Let’s get started.

Introduction – Windows Information Protection

WIP predominantly helps in data segregation or separation, identifying and marking corporate data from user personal data residing locally on the device. Data marked as corporate is subjected to protection. It also helps to manage apps on the device which works with those data, to prevent accidental leakage of data.

It’s an evolution of Enterprise Data Protection (EDP – predecessor to WIP) but is not a complete DLP solution in itself (which it is not meant to be as well by design).

WIP is not an impenetrable security, as a user with fair amount of knowledge about Windows registry can easily revert EDP state to stop protection. However, by design, WIP was never meant to be impenetrable. It was always meant to be an accidental data leakage prevention mechanism.

WIP has been available with Windows 10 since v1607 (Business Editions – Pro and Enterprise SKU), works in the background and does not comes in the way of user’s working habit – unless the user tries to mix and match between work and personal context.

For an example, WIP will allow users to freely copy content between business apps and documents, but it won’t allow the corporate data to be copied to an app working with personal data, unless otherwise specified by the policy.

You would either require either Intune (any MDM solution) or it’s on-prem counterpart SCCM to manage and deploy WIP policy to the Windows endpoints. WIP can work in both MDM and non-MDM (MAM only) scenarios – the protection is targeted to user identity and not device.

This is essentially where the Mobility (MDM and MAM) settings of Azure AD comes into play.

Windows Information Protection - Planning the MDM and MAM scope for with and without enrollment scenarios
Windows Information Protection – Planning the MDM and MAM scope for with and without enrollment scenarios

Same can also be accessed/comfigured from within Intune by going to Device Enrollment > Windows Enrollment > Configure Automatic Enrollment

It is to be noted that this MDM and MAM scope effects auto-enrollment of the Windows platform and as such should be planned properly.

NOTE: MAM scope takes precedence over MDM scope so for conflicting user, auto-enrollment into MDM will fail.

The MDM/MAM scope has no effect on Android/iOS management.

WIP with Enrollment is via the MDM endpoint https://enrollment.manage.microsoft.com/

Windows Information Protection - MDM management endpoint
Windows Information Protection – MDM management endpoint

WIP Without Enrollment is via the MAM endpoint https://wip.mam.manage.microsoft.com/

Windows Information Protection | WIP Learn with Joy Part #1 | Intune 1
Windows Information Protection – MAM management endpoint

During AAD Join/Registration, the response to the DRS Discovery request contains all the required endpoints that the device will connect to complete the process. This also includes the Device Management endpoint info. Based on the scope configured, either the device will get either of the above two or will not get any – in case scope is set to None for both MDM or MAM. For Hybrid AAD join (via AAD Connect), it is the SPN (AAD Connect setup provides GUI to setup SPN while configuring Hybrid AADJ) which aids the discovery of endpoints.

WIP – Understanding the concepts behind…

I have always stated that configuring a policy is not the real work of an IT Admin, but it is knowing the internals or behind the scenes mechanisms – what is the effect of configuring a particular settings in a policy, how it gets implemented on an endpoint and how it is supposed to work.

With the same aim of getting to know the internals, let us understand the primary action points. Windows Information Protection can roughly be related to the following functions

  • File and buffer protection,
  • Clipboard protection,
  • Data protection under lock, and
  • Protected access to network resources

With this information, let us see how the settings in the WIP policy configuration that we configure has an effect to the end user experience on an endpoint.

The most important part of the policy is to set the protection mode and define the identity.

Windows Information Protection - Protection Mode and defining the Identity
Windows Information Protection – Protection Mode and defining the Identity

Corporate Identity

WIP protected data is tagged to the identity as defined here (in general the default domain). This also helps to identify the context in which an app is running.

You will see a WIP protected file always tagged to the corporate Identity as defined in the policy. Right click and open the Properties > Advanced > Details and you can see the Enterprise Domain and the Protection status in details.

Windows Information Protection - Work file is tagged to Corporate Identity
Windows Information Protection – Work file is tagged to Corporate Identity

The tagging happens when

  • Creator decides to create data with corporate tagging
Windows Information Protection - Creator can decide to tag file to Corp Identity
Windows Information Protection – Creator can decide to tag file to Corp Identity
  • Data downloaded to the device from any policy defined Cloud Resource

For environments where Known Folder Redirection is configured and SharePoint is defined as a Cloud Resource in the WIP policy, data saved to such locations are automatically WIP protected and tagged to corp identity as essentially those locations are redirected to OneDrive for Business instead of local storage.

This identity is also tagged to applications (Enlightened/Unenlightened) to determine app execution context (if the application is being targeted by EDP) and can be checked from the Task Manager (need to enable the column for Enterprise Context)

Windows Information Protection - Enterprise Context of an App identifies if it is being targeted by EDP
Windows Information Protection – Enterprise Context of an App identifies if it is being targeted by EDP

Protection mode and the corresponding behavior

This setting decides the response to the event when user tries to take data from a policy defined app to an unknown app. This is EDP enforcement level on an endpoint which decides if actions like

  • changing file ownership from work tagged to personal
  • copying data from work app to personal app

is allowed or not.

WIP EDP mode – Blocked

The actions highlighted above are not allowed and will be blocked.

Windows Information Protection - Cannot change ownership of Work file when EDP is set to Blocked mode
Windows Information Protection – Cannot change ownership of Work file when EDP is set to Blocked mode

When EDP set to Blocked mode, you can change file ownership of a personal file to work protected but the reverse is not possible. In the above, you can see that for a work file, the File ownership options are greyed out.

Windows Information Protection - EDP Blocked mode - Copy/Paste action is not allowed from work file to personal file
Windows Information Protection – EDP Blocked mode – Copy/Paste action is not allowed from work file to personal file

WIP will block user actions which involves clipboard actions like copying data from a work file or app in work context to a personal file or app running in personal context.

WIP EDP mode – Allow Override

The actions as highlighted are allowed but end user is notified that the action involves work content.

Windows Information Protection - EDP Allow Override mode - Copy/Paste action is allowed from work space to personal space with an alert prompt
Windows Information Protection – EDP Allow Override mode – Copy/Paste action is allowed from work space to personal space with an alert prompt

In this mode, you can also change file ownership of work file to personal to remove WIP protection from the content. However, the actions are audited!

Windows Information Protection - When EDP set to Allow Override, user can change ownership of work file to personal and remove EDP protection. Action is audited!
Windows Information Protection – When EDP set to Allow Override, user can change ownership of work file to personal and remove EDP protection. Action is audited!

WIP EDP mode – Silent

If you are planning to deploy WIP in your modern managed Windows environment for the first time, it is always recommended to deploy the policy with EDP enforcement set to Silent (or Allow Override).

In this mode, no restrictions are implied as such users won’t even notice the presence of WIP on an endpoint. However, it continues to work silently in the background, auditing user activities and habits – applications the user uses to connect to corporate resources – essentially known as WIP Learning.

If in your environment, you have a standard set of applications that are used in the workplace devices, you can prepare a test system and check the EDP events to get an idea of how you should plan to target the applications.

Windows Information Protection - App learning report for WIP gives you an insight to the applications that are not part of WIP policy but are used to access work tagged data.
Windows Information Protection – App learning report for WIP gives you an insight to the applications that are not part of WIP policy but are used to access work tagged data.

WIP Learning generates two report sets

  • App Learning – tracks apps, not in policy, that attempt to access work data.
  • Website Learning – shows website URLs that are accessed by WIP-enabled apps so you can decide which ones are corporate location or personal.

Based on the WIP learnings, you can fine tune your WIP policy before switching over the protection mode to Blocked. Benefit to this is, it won’t affect the end user experience all of a sudden and disrupt the workflow for BAU activities, as you get to know the different applications that your end users are using to connect to corporate resources.

Application Targeting – Protected vs Exempt Apps

Windows Information Protection - Planning Application Targeting for EDP - Protected vs Exempt Apps
Windows Information Protection – Planning Application Targeting for EDP – Protected vs Exempt Apps

The decision of adding an application to either of the categories (or not adding the application at all?) directly impacts how the app is going to behave. This is the time during policy configuration where you choose the applications that will be targeted by the policy.

When we talk about WIP, an application can be either

Enlightened (WIP aware) Apps

The application can differentiate between personal and corporate data and apply the protection as enforced by the policy only on the corporate data. These are mainly Microsoft applications which are developed integrating the WIP APIs and the current list of apps are here.

All the Enlightened Apps gets pre-generated as Recommended apps in the Protected Apps section when you create a WIP policy.

If you know an application is WIP Enlightened, you can simply add it to your WIP policy as Protected App as you can be sure that the app will only apply protection as enforced when the data in context is identified as corporate.

Unenlightened (WIP Unaware) Apps

The application cannot differentiate between personal and corporate data as they are not aware of the WIP APIs (not integrated in source code) and if targeted by WIP policy, the OS will enforce the application to treat all data being used as corporate and apply the protection on it. LOB applications and most desktop applications by 3rd party vendors fall in these category.

For an Unenlightened App (3rd party apps and LOB apps), the decision to add it to Protected Apps or Exempt Apps is a bit tricky!

If you are sure that an Unenlightened app works only with corporate data, you can add it to the Protected Apps section on the policy. This will cause the app to enforce protection to every data that it will access or work with.

Scenario Example # Teams desktop client (Teams.exe) is an Unenlightened App but you can still add it to Protected Apps section of your WIP policy to enforce protection on the app as a User will be using Teams for corporate communication purpose only and the data involved will also be corporate.

If however an Unenlightened app may work with both personal and corporate data, in such scenario, if the app is added to Protected Apps section of your WIP policy, either the app functionality might get affected or you will hamper user experience. In such cases it is advisable to add such apps to the Exempt Apps section instead, so that the app can continue to work with both personal and corporate data. In this scenario, you essentially trade-off security for user experience.

Scenario Example # Adobe Acrobat Reader is an Unenlighteed application which helps viewing PDF files. A user can use it to view personal PDF files as well as corporate PDF files. If you add this Unenlightened application to the Protected Apps section of your WIP policy, the application will enforce protection (encrypt file) even when user opens a personal PDF file, which is undesirable. As such you should be adding this kind of apps to the Exempt Apps section instead.

What happens to the application on an endpoint with WIP enabled which is not in any of the policy app lists (Protected or Exempt)?

The application works fine till it is confined to working with personal data, but if it tries to access a corporate file or a corporate network resource as defined in the WIP policy, it will return an access denied error (or may give other errors based on the error handling of the app)

Let’s consider Python as an example. I have two scripts – one is personal and the other is WIP protected tagged to corporate identity.

Windows Information Protection - Protected vs Exempt App behavior for Unenlightened applications
Windows Information Protection – Protected vs Exempt App behavior for Unenlightened applications

Python is not added to either Protected App or Exempt App list of the enforced WIP policy – the context of Python instance when executed is Personal.

Windows Information Protection - App running in Personal context - Will it be able to access work protected file?
Windows Information Protection – App running in Personal context – Will it be able to access work protected file?

As such when I try execute the scripts, it will be able to execute script1.py which is personal but will get an error when executing script2.py which is WIP protected as it will be unable to open the file.

Windows Information Protection - App running in Personal context cannot access work protected data
Windows Information Protection – App running in Personal context cannot access work protected data

Whitelist applications from the policy – Publisher Info or AppLocker XML

Whitelisting of applications in WIP is to basically allow the application to work with requested content (local data or network resource) that is being protected by the enforced WIP policy.

This mostly comes down to LOB and Unenlightened applications which gets blocked or gives error when WIP is enforced on an endpoint and the application is not listed in either Protected or Exempt app list of the policy.

Again as I mentioned earlier, the decision to whitelist an app – add to either Protected or Exempt app list of the policy entirely depends on the fact how the application is intended for use. If the app usage is restricted to work purpose only, you can add it to Protected app list, protection will be enforced to all app data. However if the app usage is for both personal and workspace, you need to add it to Exempt app list so as to avoid enforcing protection on personal files.

To Add applications to your WIP policy, either under Protected Apps or Exempt Apps section, you get 3 options to choose from

  • Recommended Apps – Apps which are Enlightened and/or which MS recommends with all the information already available with Intune.
  • Store Apps – Apps which are available from the Microsoft Store and the procedure to add store apps is well documented by Microsoft here.
  • Desktop Apps – These will be mostly your .EXE or .MSI applications which covers the in-house LOB apps as well.

You can add a Desktop App to your WIP policy by using the Publisher information if the application is signed. You can get Publisher info of a signed application using PS command Get-AppLockerFileInformation

Windows Information Protection - Get-AppLockerFileInformation cmdlet to retrieve Publisher info of an app package
Windows Information Protection – Get-AppLockerFileInformation cmdlet to retrieve Publisher info of an app package

However, in cases of LOB applications and many other 3rd party applications as well, you would not get the Publisher information from the app package. Notice in the snap below the Publisher space is blank.

Windows Information Protection - What if you do not get Publisher information from the app package? Create an AppLocker executable rule based on File Hash instead.
Windows Information Protection – What if you do not get Publisher information from the app package? Create an AppLocker executable rule based on File Hash instead.

The recommended way to add such application would be to create an AppLocker executable rule for the application using the File Hash method.

Windows Information Protection - Create AppLocker Exectuable rule for unsigned application using File Hash
Windows Information Protection – Create AppLocker Exectuable rule for unsigned application using File Hash

You can export the created rule as an XML file and import it to your WIP policy in Intune.

When you are creating an AppLocker executable rule for an application based on File Hash, be sure to add all the dependent .exe files that the application depends on for proper app functionality.

Downside to using AppLocker executable rule based on File Hash is that, if the app gets updated, its HASH will change which will require re-whitelisting. This is not the case with whitelist based on Publisher Info.

When whitelisting an app for WIP, a good rule is to check the Install location of the application to see if there is a single executable or multiple executables.

For multiple executables, it depends on how you create the app entry in WIP.

Windows Information Protection - Should you fill all the entries or some and leave the rest on wildcards?
Windows Information Protection – Should you fill all the entries or some and leave the rest on wildcards?

If Publisher Info is available, I recommend whitelisting such app by filling up only the Publisher Information and leave the rest to “*wildcard which makes all the executables from the same Publisher trusted.

If you have created the entry with Publisher and Product name, you would need to create individual entries for each individual dependent executable.

Sometimes, you might find that Publisher Info is not available for all the dependent executables.

In such case, use a combination of both Publisher Info to whitelist the majority of executables for which it is common, and for those where Publisher Info is not available, create an AppLocker XML File Hash rule.

Points to consider while you create an AppLocker executable rule for an unsigned application

  • An AppLocker executable rule based on Path is not recommended as it poses a security concern – any application placed in that path will also come under consideration.
  • Remember not to create default rules while you create an AppLocker executable rule for an unsigned app.
Windows Information Protection - Do not create default rules if creating AppLocker executable rule for unsigned applications
Windows Information Protection – Do not create default rules if creating AppLocker executable rule for unsigned applications
  • Delete the created rule post exporting it as an XML and before closing the Local Security Policy console. If you forget to delete the created rule and closed the secpol console, your system will be good for nothing and will require a re-image.

Advanced Settings section

This is where you define/configure the following settings

  • Creating/Defining the Cloud Resources
  • Creating/Defining additional Protected Domains
  • Creating/Defining the Network Boundaries
  • Uploading a DRA certificate for recovery of encrypted data
  • Configure to Revoke encryption on unenrollment
  • Show the enterprise data protection icon
  • Configuring Azure RMS (for integrating WIP with AIP)
  • Allow Windows Search indexer to index protected files

I will not go and describe all these as you can find all the information required for the above in the Microsoft documentation here.

However, it is important that when you create any Cloud Resource, do not forget to add the /*AppCompat*/ entry.

Else any application which is not defined in the application list of the policy will be cut off from internet connection, even though the endpoint has a perfectly working active internet.

Windows Information Protection - Cloud Resource must have entry for  /*AppCompat*/ or else personal apps will be cut off from accessing Internet
Windows Information Protection – Cloud Resource must have entry for /*AppCompat*/ or else personal apps will be cut off from accessing Internet

To be contd. in #part 2

Till this, I hope you now have a pretty good understanding of the functionality of each settings in the policy.

In the next post #part 2 of this arcticle, I will be giving you a deeper insight into the internal working of WIP – both App level and Device level. So stay tuned as it will be followed with this article very soon.

If you liked reading this, there is a good chance you will like my other artciles published here so give them a read if the topic matches your interest. You will find them listed under my profile here.

Till then, as I say, keep reading and learning!

Resources

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.