In Part 1 of this article on Windows Information Protection, I explained the concepts of WIP and how each setting we configure in the policy affects the end-user activity on an endpoint with WIP enabled. If you haven’t read that yet, I recommend it as well.
The entire world is fighting against the COVID-19 virus, and I really hope that everyone is safe and sound with their families and that no one gets affected anymore. Stay safe, stay isolated, and prevent the virus from spreading until we get over this pandemic.
My deepest condolences to all those who have lost someone to this pandemic, and my prayers for all those souls who lost their fight against the virus. Rest In Peace…
This article aims to take you through the internals of Windows Information Protection- a deeper insight into how it works to protect information.
Grab a cup of coffee as we dive deep into the heart of Windows Information Protection.
Table of Contents
Windows Information Protection – Getting to the core (App Level)
Concerning WIP, an app can be either enlightened or unenlightened.
Windows 10 understands if an application is WIP Enlightened by checking the App Manifest in the app package. All enlightened apps will have the “restricted capabilities” namespace and “enterpriseDataPolicy” capability declared in the manifest to self-declare that they can understand WIP policy and handle corporate and personal data simultaneously when targeted by the Windows Information Protection policy.
<?xml version="1.0" encoding="utf-8"?> <Package … xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities" IgnorableNamespaces="uap mp rescap"> … <Identity Name="package_name" Publisher="Publisher_Info" Version="x.x.x.x" /> <Capabilities> … … <rescap:Capability Name="enterpriseDataPolicy"/> </Capabilities> </Package>
As a developer, you can develop enlightened Windows UWP or C++ apps or rebuild to enlighten your existing in-house app by integrating the WIP APIs. Read the WIP developer guide here.
The Get-AppLockerFileInformation - Path <Path to executable> PS command we use to check Publisher Info for an app retrieves the info from the app manifest (<Identity/>) of the app package only.
Considering that an Enlightened app will mostly be in the Protected app list of the WIP policy, such apps work with the WIP policy and use the classes defined in Windows.Security.EnterpriseData namespace.
Windows.Security.EnterpriseData namespace contains the classes to support Windows Information Protection functions. You can consider this as the collection of WIP APIs.
The most important class of this namespace is ProtectionPolicyManager, which provides functions/methods to identify and/or set content as protected content and manage enterprise protection policy on protected content.
You can have a look at this MS documentation, which helps you understand how the classes are used using a VS project here.
I am not an app developer in any sense, but to give an insight, this is how an enlightened app will have in its source code to check if a resource is managed (protected) or not, and based on the outcome, how it handles the data operation.
Sample code for illustration purpose only:
//Initialize a new URI object containing the resource URI
Uri resourceURI = new Uri("https://joymalya.com/SampleData.xml");
//Creates and initializes a new HostName object from the Windows.Networking class using the URI object created above. This is the destination target from where data will be accessed
Windows.Networking.HostName hostName = new Windows.Networking.HostName(resourceURI.Host);
//Checks if the destination host (defined by the hostname object) has a managed identity. If false, empty string is returned.
string identity = await ProtectionPolicyManager.GetPrimaryManagedIdentityForNetworkEndpointAsync(hostName);
//If the above code does not returns an empty string , then the endpoint has a managed identity and app needs to handle the data operation in protected context. Easiest way is to create a protected thread with the context set to managed identity.
if (!string.IsNullOrEmpty(identity))
{
using (ThreadNetworkContext threadNetworkContext = ProtectionPolicyManager.CreateCurrentThreadNetworkContext(identity))
{
//code to perform data operation in protected context
}
}
else
{
//code to perform data operation in personal context
}
If your app supports multiple view windows where one window is related to the work data and the other is related to personal data, mostly as we see in the case of browsers wherein one tab you are browsing a worksite and on another a personal site, an enlightened browser can determine the context of the current tab and will show that protection is being applied on the tab in which you have a worksite open. (Depends on policy configuration to show protection icon)
How does an app determine this? It uses the classes of the same Windows Security EnterpriseData namespace.
Again though not a developer, but for illustration purposes only, an app can achieve the same by querying the Identity of the current window object and then checking if the Identity is managed.
//Querying the identity of current window object can be achieved by using the GetForCurrentView() function defined in ProtectionPolicyManager class string identity = await ProtectionPolicyManager.GetForCurrentView().Identity //If non empty string is returned, then check if the identity is a managed identity using IsIdentityManaged() from same class. ProtectionPolicyManager.IsIdentityManaged(identity))
If true, depending on policy config – Show the enterprise data protection icon is set to On (<iconsVisible: true>), then the briefcase icon will be displayed on top of the current window, else not.
Whether an app is allowed to access policy-defined cloud resources to get data or allowed to access local files protected by the policy is determined as per the policy targeting –
- Access is granted if the app is in the allowed (protected) apps or exempt apps list
- Access is denied if the app is not in the allowed (protected) apps or exempt apps list
For Unenlightened apps, as these apps do not have the Windows Information Protection APIs in their source code, when targeted by a WIP policy, any data it works with—personal or work—the OS will enforce protection and bind it to the policy-defined corporate identity. The EDP enforcement level—Blocked or Allow Override (events are logged for audit)—determines whether the user is allowed to change the protection status of such files.
Windows Information Protection – The components involved (Device-level)
Windows 10 is built from ground zero to be modern and managed via an MDM solution and the components that make this possible are the Configuration Service Providers – which expose the device settings to be remotely configurable via an MDM solution.
Let’s check how Windows Information Protection management works with Intune.
Windows Information Protection WIP Deep Dive – Modern Management
In terms of management, Windows Information Protection implementation on a Windows endpoint is based on 3 different Configuration Service Providers (CSPs), namely
- EnterpriseDataProtection CSP (facilitated via edpcsp.dll)
./Device/Vendor/MSFT/EnterpriseDataProtection/Settings (Root node for WIP config) exposes the core WIP settings to be configured by an MDM service
- AppLocker CSP (facilitated via AppLockerCSP.dll)
The purpose of AppLocker in conjunction with Windows Information Protection is not to apply app launch restrictions (this is something utilized by WDAC) but to facilitate whether an application is allowed to work with EDP-protected data or connect to a policy-defined network resource. The root node for the same is ./Device/Vendor/MSFT/AppLocker/EnterpriseDataProtection
- Policy CSP (for Network Isolation) (facilitated via policymanager.dll)
Helps to define the protected resource – Enterprise resource domains hosted in the cloud that need to be protected. Node ./Vendor/MSFT/Policy/Config/NetworkIsolation
If you have read Part 1 of this article, you would have noticed that I mentioned WIP can be managed on a Windows 10 endpoint either via
- an MDM solution like Intune (components discussed above), or
- its traditional on-prem counterpart SCCM
However, SCCM does not use CSPs to manage Windows endpoints. Then?
Windows Information Protection – Traditional Management
SCCM uses WMI—Windows Management Instrumentation, Microsoft’s Web-Based Enterprise Management (WBEM) protocol implementation. Below, I have listed the WMI classes that map to the CSPs mentioned above.
Namespace root\cimv2\mdm\dmmap (Requires Admin privilege to connect!)
- MDM_EnterpriseDataProtection
- MDM_EnterpriseDataProtection_Settings01
- MDM_AppLocker_EnterpriseDataProtection01_EXE03
- MDM_AppLocker_EnterpriseDataProtection01_StoreApps03
- MDM_Policy_Config01_NetworkIsolation02
- MDM_Policy_Config01_Search02
Notice that the provider is stated as DMWmiBridgeProv1 – this is the MDM Bridge WMI provider (implemented in DMWmiBridgeProv1.dll) which maps the CSPs used by MDM to WMI classes to be used by traditional management solutions like SCCM.
NOTE: You can also use PS (admin privileges required) to configure MDM settings locally by invoking the MDM WMI Bridge Provider. However, to configure device settings, you need to connect to the namespace in the SYSTEM context. For this purpose, you can use the PSExec tool.
Now that we understand the components involved in managing the Windows Information Protection policy on an endpoint, let’s examine how it protects corporate-identified data on the endpoint.
Windows Information Protection uses EFS to protect work-tagged data residing locally on an endpoint.
Protection of file (data) locally marked as corporate is facilitated via Encrypting File System (EFS) encryption of Windows (a feature of NTFS file system)
Where Bitlocker helps in a drive (volume) level encryption and prevents the OS from booting if the boot parameters change, thereby protecting the drive contents from unauthorized access, it cannot help protect the files stored on the drive once the OS has booted. This is where EFS comes into the picture, helping with file-level encryption—encrypting individual files on the drive.
Windows Information Protection uses this to protect the work-tagged data residing locally on the device. By default, EFS in Windows 10 uses the AES 256-bit algorithm for file encryption.
You can use the Windows inbuilt cipher cmd line tool command cipher /c <filename> to check the protection details of a WIP protected file.
EFS is recursive, so if protection is applied to a directory, all files within the directory will get encrypted automatically. This is utilized when Windows Known Folder Redirection (Desktop, Documents, Pictures redirected to OneDrive for Business) is enabled and SharePoint is a policy-defined protected resource.
In such a scenario, personal files saved or downloaded to those locations will also get WIP protected. Whether you can remove protection depends on the EDP enforcement level
- Allow Override—To remove file protection, the user can change file ownership to Personal. This action is logged in the event.
- Block – Users cannot change file ownership to Personal.
Since we now know that Windows Information Protection utilizes the EFS functionality of the NTFS filesystem of Windows to protect corporate identified files residing locally on disk, let’s have a brief overview of EFS…
Knowing Encrypting File System – The worker behind Windows Information Protection file protection
Encrypting File System, a Windows NTFS file system feature, helps in file-level encryption and protects data in files residing on the system from unauthorized access.
EFS encryption uses both symmetric and asymmetric encryption algorithms.
The file content is encrypted/protected using a symmetric key (AES 256 bits for Windows 10) generated using the crypto functionality provided by Windows. This is known as the File Encryption Key (FEK). Since it is symmetric, the same key is used for encryption and decryption. This is designed to have a faster convergence time when dealing with large file sizes, as symmetric key algorithms work faster than asymmetric key algorithms.
However, the FEK cannot be stored in plaintext and needs to be protected to ensure file protection. This is ensured by utilizing an asymmetric public/private key pair (RSA 2048 bits) – the public key is used to encrypt the FEK so it can only be decrypted by the private key, thereby ensuring that access to FEK is possible only if the caller has access to the corresponding private key.
To be Contd… Intune Windows Information Protection
So much for today. I will meet you all soon with Part 3 of this article which will be the last and concluding part of this series #LearnWIPwithJoy.
There, I will provide insight into the encryption process, deviations (if any) from the standard EFS flow, the importance of having a DRA in your WIP policy, and much other useful information that will definitely help you better understand the topic.
Till then, stay safe, stay isolated, stay at home, spend time with family, and last but not least, keep yourself engaged—read something new every day, learn something new every day, utilize the time better, and obviously stay productive while doing #WFH.
References
- Microsoft WIP documentation
- MDM Bridge WMI provider reference
We are on WhatsApp. To get the latest step-by-step guides and news updates, Join our Channel. Click here –HTMD WhatsApp.
Author
Joymalya Basu Roy is an experienced IT service professional with almost 5 years of experience working with Microsft Intune. He is currently working as a Senior Consultant – Architect with Atos India. He is an ex-MSFT where he worked as a Premiere Support Engineer for Microsoft Intune. He was also associated with Wipro and TCS in the early stages of his career. He is awarded the Microsoft MVP award for Enterprise Mobility in 2021. You can find all his latest posts on his own blog site MDM Tech Space at https://joymalya.com