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 are yet to read that, I would recommend giving it a read as well.
The entire world is fighting againts the COVID-19 virus and I do really hope that all are safe and sound with the families and no one gets affected anymore. Stay safe, stay isolated to prevent the virus spread, till 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…
The purpose of this article is to take you through the internals of WIP – 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.
Windows Information Protection – Getting to the core (App Level)
With respect to WIP – an app is 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 “restrictedcapabilities” namespace and “enterpriseDataPolicy” capability declared in the manifest to self-declare that they can understand WIP policy and can handle corporate and personal data simultaneously when being targeted by WIP 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 the fact that an Enlightened app will mostly be in the Protected app list of the WIP policy, such apps work with the WIP policy making use of the classes defined in the Windows.Security.EnterpriseData namespace.
Windows.Security.EnterpriseData namespace contains the classes to support WIP functions. You can consider this as the collection of WIP APIs.
The most important class of this namespace is ProtectionPolicyManager which is responsible for providing 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 to understand the usage of the classes using a VS project here.
I am not an app developer in any sense, but just 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 an app determines this? Well using 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 WIP APIs in their source code, as such when targeted by a WIP policy, any data it works with – personal or work, the OS will enforce protection and bound it to the policy defined corporate identity. Whether the user is allowed to change the protection status of such files is determined by the EDP enforcement level – Blocked or Allow Override (events are logged for audit).
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 WIP management works with Intune.
WIP – Modern Management
In terms of management, Windows Information Protection implementation on a Windows endpoint is on the basis of 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 WIP 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
But SCCM does not use CSPs to manage Windows endpoint. Then?
WIP – Traditional Management
SCCM uses WMI – Windows Management Instrumentation, Microsoft’s implementation of Web Based Enterprise Management (WBEM) protocol. Below I have listed the WMI classes that map to the CSPs as 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, but to configure device settings, it requires connecting to the namespace in the SYSTEM context. You can use the PSExec tool for this purpose.
With the understanding of the components involved in the management of the Windows Information Protection policy on an endpoint, let’s have a look into how it protects corporate identified data on the endpoint.
WIP 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 drive (volume) level encryption and prevents the OS from booting if the boot parameters changes, thereby protecting the drive contents from unauthorized access, it cannot help protect the files that are 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.
This is what WIP uses to protect the work tagged data residing locally on the device. EFS in Windows 10 by default 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 – The user can change file ownership to Personal to remove file protection. Action is logged in the event.
- Block – Users cannot change file ownership to Personal.
Since we now know that WIP 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 WIP file protection
Encrypting File System, a feature of the Windows NTFS file system 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 actually encrypted/protected using a symmetric key (AES 256 bits for Windows 10) generated using crypto functionality provided by Windows. This is known as the File Encryption Key (FEK). Since it is symmetric, so the same key is used for encryption and decryption purposes. This is by design to have a faster convergence time when dealing with large file sizes, as symmetric-key algorithms work faster than an asymmetric key algorithm.
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 WIP
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 be giving an insight into the encryption process, deviations (if any) from the standard EFS flow, importance of having a DRA in your WIP policy, and much other useful information which would definitely help you in having a better understanding of 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