When we talk about Modern Workplace, employee experience is the priority. But there’s another aspect to this which is Information Protection – of utmost importance to any organization.
Every organization tries its best to keep its 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 have 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 providers, has several products/services in the space of Information Protection, each having its own area or purpose (with some overlaps in a 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.
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 all the different solutions which make 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 work with those data, to prevent accidental leakage of data.
It’s an evolution of Enterprise Data Protection (EDP – the 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 impenetrable security, as a user with a fair amount of knowledge about the Windows registry can easily revert the 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 the user’s working habit – unless the user tries to mix and match between work and personal context.
For 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 its 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 the device.
This is essentially where the Mobility (MDM and MAM) settings of Azure AD come into play.
The same can also be accessed/configured from within Intune by going to Device Enrollment > Windows Enrollment > Configure Automatic Enrollment
It is to be noted that this MDM and MAM scope affects auto-enrollment of the Windows platform and as such should be planned properly.
NOTE: MAM scope takes precedence over MDM scope so for the conflicting users, 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/
WIP Without Enrollment is via the MAM endpoint https://wip.mam.manage.microsoft.com/
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 the 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 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 have an effect on the end-user experience on an endpoint.
The most important part of the policy is to set the protection mode and define the 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 detail.
The tagging happens when
- Creator decides to create data with corporate tagging
- 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)
Protection mode and the corresponding behavior
This setting decides the response to the event when a user tries to take data from a policy-defined app to an unknown app. This is the EDP enforcement level on an endpoint that decides if actions like
- changing file ownership from work tagged to personal
- copying data from a working app to a personal app
are allowed or not.
WIP EDP mode – Blocked
The actions highlighted above are not allowed and will be blocked.
When EDP is 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.
WIP will block user actions that involve clipboard actions like copying data from a work file or app in a work context to a personal file or app running in a personal context.
WIP EDP mode – Allow Override
The actions as highlighted are allowed but the end-user is notified that the action involves work content.
In this mode, you can also change file ownership of work files to personal to remove WIP protection from the content. However, the actions are 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.
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 finetune your WIP policy before switching over the protection mode to Blocked. The benefit to this is, that 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
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 when 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 for the protection as enforced by the policy only on the corporate data. These are mainly Microsoft applications that are developed by integrating the WIP APIs and the current list of apps are here.
All the Enlightened Apps get 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 a Protected App as you can be sure that the app will only apply for 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 into source code) and if targeted by WIP policy, the OS will enforce the application to treat all data being used as corporate and apply for the protection on it. LOB applications and most desktop applications by 3rd party vendors fall in this 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 the Protected Apps section of your WIP policy to enforce protection on the app as a User will be using Teams for corporate communication purposes only and the data involved will also be corporate.
If however, an Unenlightened app may work with both personal and corporate data, in such a scenario, if the app is added to the Protected Apps section of your WIP policy, either the app functionality might get affected or you will hamper the 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 Unenlightened application that helps to view 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 a user opens a personal PDF file, which is undesirable. As such you should be adding this kind of app 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.
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.
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.
Whitelist applications from the policy – Publisher Info or AppLocker XML
Whitelisting of applications in WIP basically allows 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 get blocked or give errors when WIP is enforced on an endpoint and the application is not listed in either the Protected or Exempt app list of the policy.
Again as I mentioned earlier, the decision to whitelist an app – add it to either the 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 purposes only, you can add it to the Protected app list, protection will be enforced on all app data. However, if the app usage is for both personal and workspace, you need to add it to the Exempt app list so as to avoid enforcing protection on personal files.
To add applications to your WIP policy, either under the Protected Apps or Exempt Apps section, you get 3 options to choose from
- Recommended Apps – Apps that are Enlightened and/or which MS recommends with all the information already available with Intune.
- Store Apps – Apps that 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 cover 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 the PS command
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 that the Publisher space is blank.
The recommended way to add such an application would be to create an AppLocker executable rule for the application using the File Hash method.
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.
If Publisher Info is available, I recommend whitelisting such an app by filling up only the Publisher Information and leaving 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.
- 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
- Creating/Defining additional
- Creating/Defining the
- Uploading a
DRA certificatefor recovery of encrypted data
- Configure to
Revoke encryptionon unenrollment
- Show the enterprise data protection icon
Azure RMS(for integrating WIP with AIP)
Windows Searchindexer 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.
To be contd. in #part 2
To this, I hope you now have a pretty good understanding of the functionality of each set in the policy.
In the next post #part 2 of this article, 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 articles 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!
- How Windows Information Protection (WIP) protects a file that has a sensitivity label
- Protect your enterprise data using Windows Information Protection (WIP)