@ -71,193 +71,11 @@ After you complete these steps, the WDAC binary file (DeviceGuardPolicy.bin) and
We recommend that every WDAC policy be run in audit mode before being enforced. Doing so allows administrators to discover any issues with the policy without receiving error message dialog boxes. For information about how to audit a WDAC policy, see the next section, [Audit Windows Defender Application Control policies](#audit-windows-defender-application-control-policies).
## Audit Windows Defender Application Control policies
When WDAC policies are run in audit mode, it allows administrators to discover any applications that were missed during an initial policy scan and to identify any new applications that have been installed and run since the original policy was created. While a WDAC policy is running in audit mode, any binary that runs and would have been denied had the policy been enforced is logged in the **Applications and Services Logs\\Microsoft\\Windows\\CodeIntegrity\\Operational** event log. When these logged binaries have been validated, they can easily be added to a new WDAC policy. When the new exception policy is created, you can merge it with your existing WDAC policies.
> [!Note]
> Before you begin this process, you need to create a WDAC policy binary file. If you have not already done so, see [Create a Windows Defender Application Control policy from a reference computer](#create-a-windows-defender-application-control-policy-from-a-reference-computer), earlier in this topic, for a step-by-step walkthrough of the process to create a WDAC policy and convert it to binary format.
**To audit a Windows Defender Application Control policy with local policy:**
1. Find a *.bin policy file that you have created, for example, the DeviceGuardPolicy.bin file that resulted from the steps in the earlier section, [Create a Windows Defender Application Control policy from a reference computer](#create-a-windows-defender-application-control-policy-from-a-reference-computer). Copy the file to C:\\Windows\\System32\\CodeIntegrity.
2. On the computer you want to run in audit mode, open the Local Group Policy Editor by running **GPEdit.msc**.
> [!Note]
> - The computer that you will run in audit mode must be clean of viruses or malware. Otherwise, in the process that you follow after auditing the system, you might unintentionally merge in a policy that allows viruses or malware to run.
> - An alternative method to test a policy is to rename the test file to SIPolicy.p7b and drop it into C:\\Windows\\System32\\CodeIntegrity, rather than deploy it by using the Local Group Policy Editor.
3. Navigate to **Computer Configuration\\Administrative Templates\\System\\Windows Defender Device Guard**, and then select **Deploy Windows Defender Application Control**. Enable this setting by using the appropriate file path, for example, C:\\Windows\\System32\\CodeIntegrity\\DeviceGuardPolicy.bin, as shown in Figure 1.
> [!Note]
> - The illustration shows the example file name *DeviceGuardPolicy.bin* because this name was used earlier in this topic, in [Create a Windows Defender Application Control policy from a reference computer](#create-a-windows-defender-application-control-policy-from-a-reference-computer). Also, this policy file does not need to be copied to every system. You can instead copy the WDAC policies to a file share to which all computer accounts have access.
> - Any policy you select here is converted to SIPolicy.p7b when it is deployed to the individual computers.
> - You might have noticed that the GPO setting references a .p7b file and this policy uses a .bin file. Regardless of the type of policy you deploy (.bin, .p7b, or .p7), they are all converted to SIPolicy.p7b when dropped onto the computers running Windows 10. We recommend that you make your WDAC policy names friendly and allow the system to convert the policy names for you. By doing this, it ensures that the policies are easily distinguishable when viewed in a share or any other central repository.
Figure 1. Deploy your Windows Defender Application Control policy
4. Restart the reference system for the WDAC policy to take effect.
5. Use the system as you normally would, and monitor code integrity events in the event log. While in audit mode, any exception to the deployed WDAC policy will be logged in the **Applications and Services Logs\\Microsoft\\Windows\\CodeIntegrity\\Operational** event log, as shown in Figure 2.
Figure 2. Exceptions to the deployed WDAC policy
You will be reviewing the exceptions that appear in the event log, and making a list of any applications that should be allowed to run in your environment.
6. If you want to create a catalog file to simplify the process of including unsigned LOB applications in your WDAC policy, this is a good time to create it. For information, see [Deploy catalog files to support Windows Defender Application Control](deploy-catalog-files-to-support-windows-defender-application-control.md).
Now that you have a WDAC policy deployed in audit mode, you can capture any audit information that appears in the event log. This is described in the next section.
## Create a Windows Defender Application Control policy that captures audit information from the event log
Use the following procedure after you have been running a computer with a WDAC policy in audit mode for a period of time. When you are ready to capture the needed policy information from the event log (so that you can later merge that information into the original WDAC policy), complete the following steps.
<!-- Watch the phrase "later step in this procedure" in step 1, in case the organization of the procedures changes. -->
1. Review the audit information in the event log. From the WDAC policy exceptions that you see, make a list of any applications that should be allowed to run in your environment, and decide on the file rule level that should be used to trust these applications.
Although the Hash file rule level will catch all of these exceptions, it may not be the best way to trust all of them. For information about file rule levels, see [Windows Defender Application Control file rule levels](deploy-windows-defender-application-control-policy-rules-and-file-rules.md#windows-defender-application-control-file-rule-levels) in "Deploy Windows Defender Application Control: policy rules and file rules."
Your event log might also contain exceptions for applications that you eventually want your WDAC policy to block. If these appear, make a list of these also, for a later step in this procedure.
2. In an elevated Windows PowerShell session, initialize the variables that will be used. The example filename shown here is **DeviceGuardAuditPolicy.xml**:
3. Use [New-CIPolicy](https://technet.microsoft.com/library/mt634473.aspx) to generate a new WDAC policy from logged audit events. This example uses a file rule level of **Hash** and includes `3> CIPolicylog.txt`, which redirects warning messages to a text file, **CIPolicylog.txt**.
> When you create policies from audit events, you should carefully consider the file rule level that you select to trust. The preceding example uses the **Hash** rule level, which is the most specific. Any change to the file (such as replacing the file with a newer version of the same file) will change the Hash value, and require an update to the policy.
4. Find and review the WDAC audit policy .xml file that you created. If you used the example variables as shown, the filename will be **DeviceGuardAuditPolicy.xml**, and it will be on your desktop. Look for the following:
- Any applications that were caught as exceptions, but should be allowed to run in your environment. These are applications that should be in the .xml file. Leave these as-is in the file.
- Any applications that actually should not be allowed to run in your environment. Edit these out of the .xml file. If they remain in the .xml file, and the information in the file is merged into your existing WDAC policy, the policy will treat the applications as trusted, and allow them to run.
You can now use this file to update the existing WDAC policy that you ran in audit mode by merging the two policies. For instructions on how to merge this audit policy with the existing WDAC policy, see the next section, [Merge Windows Defender Application Control policies](#merge-windows-defender-application-control-policies).
> [!Note]
> You may have noticed that you did not generate a binary version of this policy as you did in [Create a Windows Defender Application Control policy from a reference computer](#create-a-windows-defender-application-control-policy-from-a-reference-computer). This is because WDAC policies created from an audit log are not intended to run as stand-alone policies but rather to update existing WDAC policies.
## Use a Windows Defender Application Control policy to control specific plug-ins, add-ins, and modules
As of Windows 10, version 1703, you can use WDAC policies not only to control applications, but also to control whether specific plug-ins, add-ins, and modules can run from specific apps (such as a line-of-business application or a browser):
| Approach (as of Windows 10, version 1703) | Guideline |
|---|---|
| You can work from a list of plug-ins, add-ins, or modules that you want only a specific application to be able to run. Other applications would be blocked from running them. | Use `New-CIPolicyRule` with the `-AppID` option. |
| In addition, you can work from a list of plug-ins, add-ins, or modules that you want to block in a specific application. Other applications would be allowed to run them. | Use `New-CIPolicyRule` with the `-AppID` and `-Deny` options. |
To work with these options, the typical method is to create a policy that only affects plug-ins, add-ins, and modules, then merge it into your ‘master’ policy (merging is described in the next section).
For example, to create a WDAC policy that allows **addin1.dll** and **addin2.dll** to run in **ERP1.exe**, your organization’s enterprise resource planning (ERP) application, but blocks those add-ins in other applications, run the following commands. Note that in the second command, **+=** is used to add a second rule to the **$rule** variable:
As another example, to create a WDAC policy that blocks **addin3.dll** from running in Microsoft Word, run the following command. You must include the `-Deny` option to block the specified add-ins in the specifed application:
## Merge Windows Defender Application Control policies
When you develop WDAC policies, you will occasionally need to merge two policies. A common example is when a WDAC policy is initially created and audited. Another example is when you create a single master policy by using multiple policies previously created from reference computers. Because each computer running Windows 10 can have only one WDAC policy, it is important to properly maintain these policies. In this example, audit events have been saved into a secondary WDAC policy that you then merge with the initial WDAC policy.
> [!Note]
> The following example uses several of the WDAC policy .xml files that you created in earlier sections in this topic. You can follow this process, however, with any two WDAC policies you would like to combine.
To merge two WDAC policies, complete the following steps in an elevated Windows PowerShell session:
> The variables in this section specifically expect to find an initial policy on your desktop called **InitialScan.xml** and an audit WDAC policy called **DeviceGuardAuditPolicy.xml**. If you want to merge other WDAC policies, update the variables accordingly.
2. Use [Merge-CIPolicy](https://technet.microsoft.com/library/mt634485.aspx) to merge two policies and create a new WDAC policy:
Now that you have created a new WDAC policy (for example, called **NewDeviceGuardPolicy.bin**), you can deploy the policy binary to systems manually or by using Group Policy or Microsoft client management solutions. For information about how to deploy this new policy with Group Policy, see the [Deploy and manage Windows Defender Application Control with Group Policy](#deploy-and-manage-windows-defender-application-control-with-group-policy) section.
## Enforce Windows Defender Application Control policies
Every WDAC policy is created with audit mode enabled. After you have successfully deployed and tested a WDAC policy in audit mode and are ready to test the policy in enforced mode, complete the following steps in an elevated Windows PowerShell session:
> [!Note]
> Every WDAC policy should be tested in audit mode first. For information about how to audit WDAC policies, see [Audit Windows Defender Application Control policies](#audit-windows-defender-application-control-policies), earlier in this topic.
> The initial WDAC policy that this section refers to was created in the [Create a Windows Defender Application Control policy from a reference computer](#create-a-windows-defender-application-control-policy-from-a-reference-computer) section. If you are using a different WDAC policy, update the **CIPolicyPath** and **InitialCIPolicy** variables.
2. Ensure that rule options 9 (“Advanced Boot Options Menu”) and 10 (“Boot Audit on Failure”) are set the way that you intend for this policy. We strongly recommend that you enable these rule options before you run any enforced policy for the first time. Enabling these options provides administrators with a pre-boot command prompt, and allows Windows to start even if the WDAC policy blocks a kernel-mode driver from running. When ready for enterprise deployment, you can remove these options.
To ensure that these options are enabled in a policy, use [Set-RuleOption](https://technet.microsoft.com/library/mt634483.aspx) as shown in the following commands. You can run these commands even if you're not sure whether options 9 and 10 are already enabled—if so, the commands have no effect.
Now that this policy is in enforced mode, you can deploy it to your test computers. Rename the policy to SIPolicy.p7b and copy it to C:\\Windows\\System32\\CodeIntegrity for testing, or deploy the policy through Group Policy by following the instructions in [Deploy and manage Windows Defender Application Control with Group Policy](#deploy-and-manage-windows-defender-application-control-with-group-policy). You can also use other client management software to deploy and manage the policy.
## Signing Windows Defender Application Control policies with SignTool.exe
@ -388,57 +206,9 @@ There may be a time when signed WDAC policies cause a boot failure. Because WDAC
## Deploy and manage Windows Defender Application Control with Group Policy
WDAC policies can easily be deployed and managed with Group Policy. A Windows Defender Device Guard administrative template will be available in Windows Server 2016 that allows you to simplify deployment of Windows Defender Device Guard hardware-based security features and Windows Defender Application Control policies. The following procedure walks you through how to deploy a WDAC policy called **DeviceGuardPolicy.bin** to a test OU called *DG Enabled PCs* by using a GPO called **Contoso GPO Test**.
> [!Note]
> This walkthrough requires that you have previously created a WDAC policy and have a computer running Windows 10 on which to test a Group Policy deployment. For more information about how to create a WDAC policy, see [Create a Windows Defender Application Control policy from a reference computer](#create-a-windows-defender-application-control-policy-from-a-reference-computer), earlier in this topic.
> [!Note]
> Signed WDAC policies can cause boot failures when deployed. We recommend that signed WDAC policies be thoroughly tested on each hardware platform before enterprise deployment.
To deploy and manage a WDAC policy with Group Policy:
1. On a domain controller on a client computer on which RSAT is installed, open the GPMC by running **GPMC.MSC** or searching for “Group Policy Management” in Windows Search.
2. Create a new GPO: right-click an OU and then click **Create a GPO in this domain, and Link it here**, as shown in Figure 3.
> **Note** You can use any OU name. Also, security group filtering is an option when you consider different ways of combining WDAC policies (or keeping them separate), as discussed in [Planning and getting started on the Windows Defender Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md).
Figure 3. Create a GPO
3. Name the new GPO. You can choose any name.
4. Open the Group Policy Management Editor: right-click the new GPO, and then click **Edit**.
5. In the selected GPO, navigate to Computer Configuration\\Administrative Templates\\System\\Device Guard. Right-click **Deploy Windows Defender Application Control** and then click **Edit**.
Figure 4. Edit the Group Policy for Windows Defender Application Control
6. In the **Deploy Windows Defender Application Control** dialog box, select the **Enabled** option, and then specify the code integrity policy deployment path.
In this policy setting, you specify either the local path in which the policy will exist on the client computer or a Universal Naming Convention (UNC) path that the client computers will look to retrieve the latest version of the policy. For example, with DeviceGuardPolicy.bin on the test computer, the example file path would be C:\\Windows\\System32\\CodeIntegrity\\DeviceGuardPolicy.bin, as shown in Figure 5.
> [!Note]
> The illustration shows the example file name *DeviceGuardPolicy.bin* because this name was used earlier in this topic, in [Create a Windows Defender Application Control policy from a reference computer](#create-a-windows-defender-application-control-policy-from-a-reference-computer). Also, this policy file does not need to be copied to every computer. You can instead copy the WDAC policies to a file share to which all computer accounts have access. Any policy selected here is converted to SIPolicy.p7b when it is deployed to the individual client computers.
Figure 5. Enable the Windows Defender Application Control policy
> [!Note]
> You may have noticed that the GPO setting references a .p7b file and this example uses a .bin file for the policy. Regardless of the type of policy you deploy (.bin, .p7b, or .p7), they are all converted to SIPolicy.p7b when dropped on the client computer running Windows 10. Make your WDAC policies friendly and allow the system to convert the policy names for you to ensure that the policies are easily distinguishable when viewed in a share or any other central repository.
7. Close the Group Policy Management Editor, and then restart the Windows 10 test computer. Restarting the computer updates the WDAC policy. For information about how to audit WDAC policies, see the [Audit Windows Defender Application Control policies](#audit-windows-defender-application-control-policies) section.
## Related topics
[Introduction to Windows Defender Device Guard: virtualization-based security and Windows Defender Application Control](introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md)
WDAC policies can easily be deployed and managed with Group Policy. A Windows Defender Device Guard administrative template will be available in Windows Server 2016 that allows you to simplify deployment of Windows Defender Device Guard hardware-based security features and Windows Defender Application Control policies. The following procedure walks you through how to deploy a WDAC policy called **DeviceGuardPolicy.bin** to a test OU called *DG Enabled PCs* by using a GPO called **Contoso GPO Test**.
> [!Note]
> This walkthrough requires that you have previously created a WDAC policy and have a computer running Windows 10 on which to test a Group Policy deployment. For more information about how to create a WDAC policy, see [Create a Windows Defender Application Control policy from a reference computer](create-initial-default-policy.md), earlier in this topic.
> [!Note]
> Signed WDAC policies can cause boot failures when deployed. We recommend that signed WDAC policies be thoroughly tested on each hardware platform before enterprise deployment.
To deploy and manage a WDAC policy with Group Policy:
1. On a domain controller on a client computer on which RSAT is installed, open the GPMC by running **GPMC.MSC** or searching for “Group Policy Management” in Windows Search.
2. Create a new GPO: right-click an OU and then click **Create a GPO in this domain, and Link it here**, as shown in Figure 3.
> **Note** You can use any OU name. Also, security group filtering is an option when you consider different ways of combining WDAC policies (or keeping them separate), as discussed in [Plan for Windows Defender Application Control policy management](plan-windows-defender-application-control-management.md).
Figure 3. Create a GPO
3. Name the new GPO. You can choose any name.
4. Open the Group Policy Management Editor: right-click the new GPO, and then click **Edit**.
5. In the selected GPO, navigate to Computer Configuration\\Administrative Templates\\System\\Device Guard. Right-click **Deploy Windows Defender Application Control** and then click **Edit**.
Figure 4. Edit the Group Policy for Windows Defender Application Control
6. In the **Deploy Windows Defender Application Control** dialog box, select the **Enabled** option, and then specify the code integrity policy deployment path.
In this policy setting, you specify either the local path in which the policy will exist on the client computer or a Universal Naming Convention (UNC) path that the client computers will look to retrieve the latest version of the policy. For example, with DeviceGuardPolicy.bin on the test computer, the example file path would be C:\\Windows\\System32\\CodeIntegrity\\DeviceGuardPolicy.bin, as shown in Figure 5.
> [!Note]
> This policy file does not need to be copied to every computer. You can instead copy the WDAC policies to a file share to which all computer accounts have access. Any policy selected here is converted to SIPolicy.p7b when it is deployed to the individual client computers.
Figure 5. Enable the Windows Defender Application Control policy
> [!Note]
> You may have noticed that the GPO setting references a .p7b file and this example uses a .bin file for the policy. Regardless of the type of policy you deploy (.bin, .p7b, or .p7), they are all converted to SIPolicy.p7b when dropped on the client computer running Windows 10. Make your WDAC policies friendly and allow the system to convert the policy names for you to ensure that the policies are easily distinguishable when viewed in a share or any other central repository.
7. Close the Group Policy Management Editor, and then restart the Windows 10 test computer. Restarting the computer updates the WDAC policy. For information about how to audit WDAC policies, see [Audit Windows Defender Application Control policies](audit-windows-defender-application-control-policies.md).
Every WDAC policy is created with audit mode enabled. After you have successfully deployed and tested a WDAC policy in audit mode and are ready to test the policy in enforced mode, complete the following steps in an elevated Windows PowerShell session:
> [!Note]
> Every WDAC policy should be tested in audit mode first. For information about how to audit WDAC policies, see [Audit Windows Defender Application Control policies](audit-windows-defender-application-control-policies.md), earlier in this topic.
> The initial WDAC policy that this section refers to was created in the [Create a Windows Defender Application Control policy from a reference computer](create-initial-default-policy.md) section. If you are using a different WDAC policy, update the **CIPolicyPath** and **InitialCIPolicy** variables.
2. Ensure that rule options 9 (“Advanced Boot Options Menu”) and 10 (“Boot Audit on Failure”) are set the way that you intend for this policy. We strongly recommend that you enable these rule options before you run any enforced policy for the first time. Enabling these options provides administrators with a pre-boot command prompt, and allows Windows to start even if the WDAC policy blocks a kernel-mode driver from running. When ready for enterprise deployment, you can remove these options.
To ensure that these options are enabled in a policy, use [Set-RuleOption](https://docs.microsoft.com/powershell/module/configci/set-ruleoption) as shown in the following commands. You can run these commands even if you're not sure whether options 9 and 10 are already enabled—if so, the commands have no effect.
> To enforce a WDAC policy, you delete option 3, the **Audit Mode Enabled** option. There is no “enforced” option that can be placed in a WDAC policy.
5. Use [ConvertFrom-CIPolicy](https://docs.microsoft.com/powershell/module/configci/convertfrom-cipolicy) to convert the new WDAC policy to binary format:
Now that this policy is in enforced mode, you can deploy it to your test computers. Rename the policy to SIPolicy.p7b and copy it to C:\\Windows\\System32\\CodeIntegrity for testing, or deploy the policy through Group Policy by following the instructions in [Deploy and manage Windows Defender Application Control with Group Policy](deploy-windows-defender-application-control-policies-using-group-policy.md). You can also use other client management software to deploy and manage the policy.
When you develop WDAC policies, you will occasionally need to merge two policies. A common example is when a WDAC policy is initially created and audited. Another example is when you create a single master policy by using multiple policies previously created from reference computers. Because each computer running Windows 10 can have only one WDAC policy, it is important to properly maintain these policies. In this example, audit events have been saved into a secondary WDAC policy that you then merge with the initial WDAC policy.
> [!Note]
> The following example uses several of the WDAC policy .xml files that you created in earlier sections in this topic. You can follow this process, however, with any two WDAC policies you would like to combine.
To merge two WDAC policies, complete the following steps in an elevated Windows PowerShell session:
> The variables in this section specifically expect to find an initial policy on your desktop called **InitialScan.xml** and an audit WDAC policy called **DeviceGuardAuditPolicy.xml**. If you want to merge other WDAC policies, update the variables accordingly.
2. Use [Merge-CIPolicy](https://docs.microsoft.com/powershell/module/configci/merge-cipolicy) to merge two policies and create a new WDAC policy:
3. Use [ConvertFrom-CIPolicy](https://docs.microsoft.com/powershell/module/configci/convertfrom-cipolicy) to convert the merged WDAC policy to binary format:
Now that you have created a new WDAC policy, you can deploy the policy binary to systems manually or by using Group Policy or Microsoft client management solutions. For information about how to deploy this new policy with Group Policy, see [Deploy and manage Windows Defender Application Control with Group Policy](deploy-windows-defender-application-control-policies-using-group-policy).
# Use a Windows Defender Application Control policy to control specific plug-ins, add-ins, and modules
As of Windows 10, version 1703, you can use WDAC policies not only to control applications, but also to control whether specific plug-ins, add-ins, and modules can run from specific apps (such as a line-of-business application or a browser):
| Approach (as of Windows 10, version 1703) | Guideline |
|---|---|
| You can work from a list of plug-ins, add-ins, or modules that you want only a specific application to be able to run. Other applications would be blocked from running them. | Use `New-CIPolicyRule` with the `-AppID` option. |
| In addition, you can work from a list of plug-ins, add-ins, or modules that you want to block in a specific application. Other applications would be allowed to run them. | Use `New-CIPolicyRule` with the `-AppID` and `-Deny` options. |
To work with these options, the typical method is to create a policy that only affects plug-ins, add-ins, and modules, then merge it into your ‘master’ policy (merging is described in the next section).
For example, to create a WDAC policy that allows **addin1.dll** and **addin2.dll** to run in **ERP1.exe**, your organization’s enterprise resource planning (ERP) application, but blocks those add-ins in other applications, run the following commands. Note that in the second command, **+=** is used to add a second rule to the **$rule** variable:
As another example, to create a WDAC policy that blocks **addin3.dll** from running in Microsoft Word, run the following command. You must include the `-Deny` option to block the specified add-ins in the specifed application:
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Justin Hall