HOW TO: Deploy Windows Defender Application Guard with Endpoint Manager
In part 2 of the series, I will be taking a closer look at Windows Defender Application Guard (WDAG), specifically for Edge. Not to confused with Windows Defender Application Control (WDAC). Essentially WDAG runs application in a virtualized environment on your Windows 10 device. This way the operating system is protected from any applications that try to interfere with the system.
For Edge, WDAG helps to isolate untrusted websites. By isolating browsers users can safely browse the web without having to worry that they accidently end up on a site that they are not supposed to be on. This isolation happens within a Hyper-V-enabled container. This container is separate from the host operating system. Meaning that if a website turns out to be malicious the host device is protected, and the attacker cannot get the data.
Today this article is about Edge, more specifically the new Chromium version, but these same settings also work for the older Edge and even Internet Explorer. This level of isolation is also available for Microsoft Office, but this will not be covered today.
A physical test client (64-bit, Virtualization options, minimum of 8GB), joined and enrolled in Endpoint Manager
Windows 10 Enterprise currently supported version
Microsoft subscription with Endpoint Manager
Enable Windows Defender Application Guard
To enable WDAG go to endpoint.microsoft.com, select Devices > Configuration Profiles > New Profile and select Windows 10 and later. For profile select Endpoint Protection.
Fill out the basic information and continue to the next step. Select Microsoft Defender Application Guard to reveal the options. I have applied the following settings, tailor them to your need if needed. In the link you can find the explication of all these settings. If you want to provide a nice experience for your users make sure to enable retain user generated browser data. This way cookies and preferences are saved. Finally apply the policy to a group.
Network boundaries
The next question is how to control what sites are blocked and what site are considered as trusted. The documentation of Microsoft is not particularly clear on this point, but is hidden way in one of the lines of text. Within Endpoint manager you have the options to create a Configuration Profile specifically for network boundaries.
To create a profile go to Devices > Configuration Profiles > New Profile and select Windows 10 and later. For profile select Network boundary. Depending on what you want to whitelist there are special rules and formats you need to apply by. Also take into account if you want to use wildcards or specific domains. See the explication of Microsoft how to whitelist certain domains. See the explination on how to whitelist domains:
Value
Numbers of dots to the left
Meaning
contoso.com
0
Trust only the literal value of contoso.com.
www.contoso.com
0
Trust only the literal value of www.contoso.com.
.contoso.com
1
Trust any domain that ends with the text contoso.com. Matching sites include spearphishingcontoso.com, contoso.com, and www.contoso.com.
..contoso.com
2
Trust all levels of the domain hierarchy that are to the left of the dot. Matching sites include shop.contoso.com, us.shop.contoso.com, www.us.shop.contoso.com, but NOT contoso.com itself.
Here are some boundaries that I have added for this article. Most of the resources are Microsoft cloud services, but of course I also added my own website as a safe website.
So now you configured WDAG, but what is happening on the background? By enabling WDAG the Windows Defender Application Guard feature is installed on the client. This installation requires a restart so the next time a user turns off its device the feature will be installed. After the feature is live users can start their browser and at first nothing is different then what they are used to. If they immediately start their browser, they might see an initialization popup meaning that the container is being provisioned.
They can go to any trusted site or cloud resources that have been defined as trusted in the boundary policy. However as soon as they try to go to an untrusted website a secure isolated browser is started. See the example below when we browse to google.com.
HOW TO: Deploy Windows Defender Application Control with Microsoft Endpoint Manager
Windows 10 has a variety of security features build in. These features are not enabled by default, but if configured correctly they can significantly increase the security of the devices. The main advantage of Windows 10 Enterprise are the security features. These security features ‘harden’ the operating system. By hardening your OS, you protect yourself and the Enterprise against viruses, ransomware, and possible hackers. This blog series explains the different “Defender” functionalities that are available in Windows 10 Enterprise and how to configure them by using Microsofts Endpoint Manager (Intune).
Microsoft always likes to rebrand their functionalities, and the name defender is now used generally for all the security features, not only covering Windows 10. You can think of Defender for Endpoint, Defender for Azure etc. This is also true for the functionalities of this blog series. Windows Defender Application Control is the new name for services which were once called Application Control Guard, or even Configurable Code Integrity (CCI).
Simply stated: Windows Defender Application Control (WDAC) controls whether an application may or may not run on a Windows 10 device. If the application is trusted the application can run, otherwise the application is blocked. There is a lot more to it of course but in essence this is what is does. Some may remember AppLocker which was introduced in Windows 7 and it allowed organization to control which applications could run on a device. If stated like this the functionalities of AppLocker and WDAC are very alike, but WDAC takes it a lot further. Not only does WDAC now has the capability to also control drivers, it can also make use of Microsoft’s Intelligent Security Graph. By using the Intelligent Security Graph, you do not have to whitelist applications individually, but you automatically trust the application is Microsoft trusts the application. This will save you a lot of time maintaining the WDAC policies. Furthermore, you have the option to automatically approve applications that have been deployed by using software distribution solutions, such as Microsoft Endpoint Manger.
Securing your environment by building and maintaining WDAC policies or any other security solution will take time. The policies you create will change over time since applications and other software change. You should understand that this is not a one-time configuration, and this should be evaluated on a regular basis. Before you start implementing WDAC I would recommend to start by reading and understanding the documentation of Microsoft. Make sure that the requirements of your business needs are clear.
There are so many variables that go into designing this solution that it is impossible to cover all the steps. This series of articles should give you a basic understanding on how to use these security features to your advantage. What are the high level steps in this article:
In this article we create a policy for a fully managed device. You can also create policies for lightly managed devices. The difference between the two is that with fully managed devices all the software installed on the device is managed by IT and users cannot install any applications. On lightly managed devices users can install applications. If you are planning to start with WDAC it is recommended to start by treating your devices as if they are lightly managed. After that slowly build up the security around the device until they are “fully managed”.
1. Create a baseline policy
You start with a baseline. Creating a baseline policy depends on what type of device you are using. Each type of device has its own drivers and specifications, depending on the manufacturer of the device. So, it is important to capture baseline policies for each type of device. If you have multiple types of devices you can use each baseline for the specific device type, or you can merge the baseline into one baseline policy which you can then use for all of them. Microsoft has provided some example policies in C:\Windows\schemas\CodeIntegrity\ExamplePolicies. For this article we start from scratch.
Take a Windows 10 device which is as clean as possible to start the inventorying phase. To start use the following PowerShell command. This command will scan the entire device and creates a baseline XML. This will take some time to complete.
Option 13 is used so that applications installed by a software distribution solution are automatically allowed.
Option 14 enables the use of the Microsoft Intelligent Security Graph so that well known applications are automatically approved.
Option 16, so no reboot is required when applying WDAC policies.
Option 17, so you can combine policies.
Activating Hardware Virtualized Code Integrity and set it to enabled. To be used with care, some applications and drivers are incompatible with HVCI and can cause software malfunction and blue screens.
When your XML has finished building you can convert the XML to a CIP file. First open the XML file and copy the <PolicyID> , this can be found at the bottom of the XML file and looks something like {DF4B2E6F-F05F-4D3C-AE70-000F6CCD445C}. The name of the CIP file must match the Policy GUID. To create a CIP file run:
The CIP file is now ready to be tested. Copy the CIP file to C:\Windows\System32\CodeIntegrity\CIPolicies\Active and reboot the machine.
The WDAC policy was created in audit mode, meaning that no applications will be blocked. However, the event log will show if an application would have been blocked if the policy were being enforced. In the Event Viewer under Applications and Services Logs > Microsoft > Windows > Code Integrity > Operational you will see all the warnings. Make sure to run different application and check the event viewer for warnings and errors.
4. Deploy WDAC policy – pilot
Before this section explains how to deploy WDAC policies with Endpoint Manager, a little side step. I was preparing this blog by reading documentation and trying to the deploy the WDAC policy in my lab. I’ve followed the documentation from Microsoft Deploy Windows Defender Application Control (WDAC) policies by using Microsoft Intune (Windows 10) – Windows security | Microsoft Docs. Everything went fine until I was not able to upload the bin file that was created. Every time I tried to create the policy I received the error: Unable to save due to invalid data. Update your data then try again: Exception has been thrown by the target of an invocation. After a while I found this article stating that OMA-URI policies with payload over 350k bytes were no longer supported Support Tip: Custom OMA-URI’s not always applying to Windows 10 Devices – Microsoft Tech Community . Well the payload for a WDAC policy is way bigger then 350k bytes so that would explain why I wasn’t able to add the policy. Even by stripping a WDAC policy to its bear minimum it would still be bigger than 350k bytes… I’m hoping this will be resolved in the future, so I will leave the original procedure in place, but also provide an alternative method to deploy the WDAC policy.
Original method
You have created a baseline policy and tested the policy on a device. Ideally you want to test the policy on multiple devices which are being used by multiple people within your organization. Running a pilot will better determine if your baseline policy fits the business needs. So, its time to deploy the policy to several devices by using Configuration Manager.
To deploy the policy with Endpoint manager the policy first must be converted to a bin file.
In Endpoint Manager go to Configuration Profiles and add a new policy. For platform select Windows 10 and later for profile select Custom.
Give your policy a name, and go to the next step
In configuration settings Add a new OMA-URI setting
Provide a clear name
OMA-URI is ./Vendor/MSFT/ApplicationControl/Policies/<POLICYID> /Policy. Here you replace <POLICYID> with the value of the policy ID without the brackets
For Data type select Base64 (file) and upload the bin file
Assign the deployment to a group with test devices / users
Alternative Method
For the alternative distribution method, we are going to use the IntuneWinAppUtil.exe utility from Microsoft. The goal is to copy the CIP file to C:\Windows\System32\CodeIntegrity\CIPolicies\Active folder. However this brings on a new problem, because in order to copy something in that directory you need administrative permissions. Even though the account installing the application should have this permissions, it is not permitted to copy files to that location. Or I haven’t found a good way of doing this, if you know the solution please let me know because I haven’t found a better way. I did however found one way of completing this and it seems a little bit devious, but if it works it works. It involves creating a scheduled task which then copies the files to the right location.. In order to make it work all the necessary information is wrapped into a Win32 Intune package to deploy it to the device. The tool for doing this will also be used for the monitoring agent later on in this blog. To learn and read more about this packaging method check out my previous blog.
To start create a folder containing the following:
-Your CIP file – A Powershell script to Deploy the CIPolicy (Deploy-CIP.ps1 Adjust the script to match your CIPolicy id.)
To deploy the application use endpoint.microsoft.com:
Add and new Windows app (Win32)
Fill in the app information
For the install command use powershell.exe -ExecutionPolicy Bypass .\Deploy-CIP.ps1
For the uninstall use powershell.exe -ExecutionPolicy Bypass .\Remove-CIP.ps1
Run as system
Specify your requirements
For Detection rules make use of a File manually detection rule. Here you can use C:\Windows\system32\CodeIntegrity\CiPolicies\Active and for File use {DF4B2E6F-F05F-4C3D-AE70-000F6CCD445C}.cip (change the name to your CIP policy), detection method File or folder exists
5. Monitor your WDAC Policy
As mentioned previously in this blog you can view the Event Viewer to check if applications are blocked. In larger deployments this is not really practical to check each individually device for events. Ideally you want to have a central location for all the Event logs. For this you can use a Log Analytics Workspace.
After you have a Workspace enable logging in endpoint.microsoft.com by going to Reports and selecting Diagnostics settings. Select Add diagnostic setting. Select all the different log types and for destination details select Send to Log Analytics Workspace and select your subscription and Workspace.
Go back to the Analytics Workspace and now go to Agents Management. Here you can download the log agent and make sure to note the Workspace ID and the Primary key.
The downloaded Analytics agents needs to be repackaged using the IntuneWinAppUtil.exe. Check out my previous blog for more in-depth information. The first step is to extract the contents of the AnalyticsAgent.exe.
Place the downloaded MMASetup-AMD64.exe into a folder
Run .\ MMASetup-AMD64.exe /c and specify a folder location on where to put the extracted data.
Run the IntuneWinAppUtil.exe and specify:
The source folder location
The setup file, which is setup.exe
Output folder
You do not need a catalog folder
You now have the monitoring app packaged into the Intune format
To deploy the application use endpoint.microsoft.com:
Add and new Windows app (Win32)
Fill in the app information
For the install command use setup.exe /qn NOAPM=0 ADD_OPINSIGHTS_WORKSPACE=1 OPINSIGHTS_WORKSPACE_ID=”<WORKSPACEID>” OPINSIGHTS_WORKSPACE_KEY=”<PRIMARYKEY>” OPINSIGHTS_WORKSPACE_AZURE_CLOUD_TYPE=0 AcceptEndUserLicenseAgreement=1″ You need the Workspace ID and the Primary key from your workspace. View the reference in the docs Install Log Analytics agent on Windows computers – Azure Monitor | Microsoft Docs
SPecify your requirements
For Detection rules make use of a Registry manually detection rule. Here you can use Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HealthService\Parameters\Management Groups\AOI-<WORKSPACEID> where you change WORKSPACEID to your Workspace ID
Assign your application to a group
After the deployment is finished the Monitor Agent starts uploading Event logs to the Workspace. To view the Event Logs open the Workspace and select Logs. Here you can enter Query based on Kusto Query Language to search the Event Viewer logs. For example you can use the following query to display all the logs with a Warning or Error in the Code Integrity Events category.
Event
| where Source == "Microsoft-Windows-CodeIntegrity"
| where EventLevelName == "Warning" or EventLevelName == "Error"
| project TimeGenerated, Computer, RenderedDescription
| sort by TimeGenerated desc
6. No more testing, time for enforced mode
When your done with testing and you have validated everything to work as expected it is time to turn on the enforced mode. To enforce the policy option 3 is removed from the XML which is the configuration for audit mode.