deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-15 06:47:21 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

removed links

Browse Source
This commit is contained in:
Justin Hall 2018-04-19 11:33:21 -07:00
parent 07a3fd16d8
commit 3d1dac17b0
3 changed files with 23 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
.openpublishing.redirection.json
View File

@ -1,6 +1,11 @@
{ {
"redirections": [ "redirections": [
{ {
"source_path": "windows/security/threat-protection/device-guard/device-guard-deployment-guide.md",
"redirect_url": "/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide",
"redirect_document_id": true
},
{
"source_path": "windows/threat-protection/windows-defender-smartscreen/windows-defender-smartscreen-available-settings.md", "source_path": "windows/threat-protection/windows-defender-smartscreen/windows-defender-smartscreen-available-settings.md",
"redirect_url": "/windows/security/threat-protection/windows-defender-smartscreen/windows-defender-smartscreen-available-settings", "redirect_url": "/windows/security/threat-protection/windows-defender-smartscreen/windows-defender-smartscreen-available-settings",
"redirect_document_id": true "redirect_document_id": true

12
windows/security/threat-protection/windows-defender-application-control/deploy-windows-defender-application-control-policies-using-group-policy.md
View File

@ -27,17 +27,15 @@ WDAC policies can easily be deployed and managed with Group Policy. A Windows De
To deploy and manage a WDAC policy with Group Policy: 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. 1. On a client computer on which RSAT is installed, open the GPMC by running **GPMC.MSC**
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. 2. Create a new GPO: right-click an OU and then click **Create a GPO in this domain, and Link it here**.
> [!NOTE] > [!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). > 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).
![Group Policy Management, create a GPO](images/dg-fig24-creategpo.png) ![Group Policy Management, create a GPO](images/dg-fig24-creategpo.png)
Figure 3. Create a GPO
3. Name the new GPO. You can choose any name. 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**. 4. Open the Group Policy Management Editor: right-click the new GPO, and then click **Edit**.
@ -46,19 +44,15 @@ To deploy and manage a WDAC policy with Group Policy:
![Edit the Group Policy for Windows Defender Application Control](images/wdac-edit-gp.png) ![Edit the Group Policy for Windows Defender Application Control](images/wdac-edit-gp.png)
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. 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. 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.
> [!NOTE] > [!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. > 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.
![Group Policy called Deploy Windows Defender Application Control](images/dg-fig26-enablecode.png) ![Group Policy called Deploy Windows Defender Application Control](images/dg-fig26-enablecode.png)
Figure 5. Enable the Windows Defender Application Control policy
> [!NOTE] > [!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. > 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.

40
windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide.md
View File

@ -15,15 +15,16 @@ ms.date: 02/27/2018
- Windows 10 - Windows 10
- Windows Server 2016 - Windows Server 2016
This topic provides a roadmap for planning and getting started on the Windows Defender Application Control (WDAC) deployment process, with links to topics that provide additional detail. Planning for WDAC deployment involves looking at both the end-user and the IT pro impact of your choices. Use the following steps to guide you. This topic provides a roadmap for planning and getting started on the Windows Defender Application Control (WDAC) deployment process, with links to topics that provide additional detail. Planning for WDAC deployment involves looking at both the end-user and the IT pro impact of your choices.
## Planning ## Planning
1. **Review requirements, especially hardware requirements for VBS**. Review the virtualization-based security (VBS) features and corresponding hardware, firmware, and software requirements. 1. Review requirements, especially hardware requirements for VBS.
2. **Group devices by degree of control needed**. [Group devices](types-of-devices.md). Do most devices fit neatly into a few categories, or are they scattered across all categories? Are users allowed to install any application or must they choose from a list? Are users allowed to use their own peripheral devices?<br>Deployment is simpler if everything is locked down in the same way, but meeting individual departments’ needs, and working with a wide variety of devices, may require a more complicated and flexible deployment. 2. Group devices by degree of control needed. Do most devices fit neatly into a few categories, or are they scattered across all categories? Are users allowed to install any application or must they choose from a list? Are users allowed to use their own peripheral devices?<br>Deployment is simpler if everything is locked down in the same way, but meeting individual departments’ needs, and working with a wide variety of devices, may require a more complicated and flexible deployment.
3. Review how much variety in software and hardware is needed by roles or departments. The following questions can help you clarify how many WDAC policies to create:
3. **Review how much variety in software and hardware is needed by roles or departments**. When several departments all use the same hardware and software, you might need to deploy only one Windows Defender Application Control (WDAC) policy for them. More variety across departments might mean you need to create and manage more WDAC policies. The following questions can help you clarify how many WDAC policies to create:
- How standardized is the hardware?<br>This can be relevant because of drivers. You could create a WDAC policy on hardware that uses a particular set of drivers, and if other drivers in your environment use the same signature, they would also be allowed to run. However, you might need to create several WDAC policies on different "reference" hardware, then merge the policies together, to ensure that the resulting policy recognizes all the drivers in your environment. - How standardized is the hardware?<br>This can be relevant because of drivers. You could create a WDAC policy on hardware that uses a particular set of drivers, and if other drivers in your environment use the same signature, they would also be allowed to run. However, you might need to create several WDAC policies on different "reference" hardware, then merge the policies together, to ensure that the resulting policy recognizes all the drivers in your environment.
- What software does each department or role need? Should they be able to install and run other departments’ software?<br>If multiple departments are allowed to run the same list of software, you might be able to merge several WDAC policies to simplify management. - What software does each department or role need? Should they be able to install and run other departments’ software?<br>If multiple departments are allowed to run the same list of software, you might be able to merge several WDAC policies to simplify management.
@ -33,42 +34,31 @@ This topic provides a roadmap for planning and getting started on the Windows De
- Is there already a list of accepted applications?<br>A list of accepted applications can be used to help create a baseline WDAC policy.<br>As of Windows 10, version 1703, it might also be useful to have a list of plug-ins, add-ins, or modules that you want to allow only in a specific app (such as a line-of-business app). Similarly, it might be useful to have a list of plug-ins, add-ins, or modules that you want to block in a specific app (such as a browser). - Is there already a list of accepted applications?<br>A list of accepted applications can be used to help create a baseline WDAC policy.<br>As of Windows 10, version 1703, it might also be useful to have a list of plug-ins, add-ins, or modules that you want to allow only in a specific app (such as a line-of-business app). Similarly, it might be useful to have a list of plug-ins, add-ins, or modules that you want to block in a specific app (such as a browser).
- As part of a threat review process, have you reviewed systems for software that can load arbitrary DLLs or run code or scripts? - As part of a threat review process, have you reviewed systems for software that can load arbitrary DLLs or run code or scripts?
In day-to-day operations, your organization’s security policy may allow certain applications, code, or scripts to run on your systems depending on their role and the context. However, if your security policy requires that you run only trusted applications, code, and scripts on your systems, you may decide to lock these systems down securely with Windows Defender Application Control policies. You can also fine-tune your control by using Windows Defender Application Control in combination with AppLocker, as described in [Windows Defender Device Guard with AppLocker](windows-defender-application-control-and-applocker.md). In day-to-day operations, your organization’s security policy may allow certain applications, code, or scripts to run on your systems depending on their role and the context. However, if your security policy requires that you run only trusted applications, code, and scripts on your systems, you may decide to lock these systems down securely with Windows Defender Application Control policies.
Legitimate applications from trusted vendors provide valid functionality. However, an attacker could also potentially use that same functionality to run malicious executable code that could bypass WDAC. Legitimate applications from trusted vendors provide valid functionality. However, an attacker could also potentially use that same functionality to run malicious executable code that could bypass WDAC.
For operational scenarios that require elevated security, certain applications with known Code Integrity bypasses may represent a security risk if you whitelist them in your WDAC policies. Other applications where older versions of the application had vulnerabilities also represent a risk. Therefore, you may want to deny or block such applications from your WDAC policies. For applications with vulnerabilities, once the vulnerabilities are fixed you can create a rule that only allows the fixed or newer versions of that application. The decision to allow or block applications depends on the context and on how the reference system is being used. For operational scenarios that require elevated security, certain applications with known Code Integrity bypasses may represent a security risk if you whitelist them in your WDAC policies. Other applications where older versions of the application had vulnerabilities also represent a risk. Therefore, you may want to deny or block such applications from your WDAC policies. For applications with vulnerabilities, once the vulnerabilities are fixed you can create a rule that only allows the fixed or newer versions of that application. The decision to allow or block applications depends on the context and on how the reference system is being used.
Security professionals collaborate with Microsoft continuously to help protect customers. With the help of their valuable reports, Microsoft has identified a list of known applications that an attacker could potentially use to bypass Windows Defender Application Control. Depending on the context, you may want to block these applications. To view this list of applications and for use case examples, such as disabling msbuild.exe, see [Microsoft recommended block rules](microsoft-recommended-block-rules.md). Security professionals collaborate with Microsoft continuously to help protect customers. With the help of their valuable reports, Microsoft has identified a list of known applications that an attacker could potentially use to bypass Windows Defender Application Control. Depending on the context, you may want to block these applications. To view this list of applications and for use case examples, such as disabling msbuild.exe, see [Microsoft recommended block rules](microsoft-recommended-block-rules.md).
4. Identify LOB applications that are currently unsigned. Although requiring signed code (through WDAC) protects against many threats, your organization might use unsigned LOB applications, for which the process of signing might be difficult. You might also have applications that are signed, but you want to add a secondary signature to them. If so, identify these applications, because you will need to create a catalog file for them.
4. **Identify LOB applications that are currently unsigned**. Although requiring signed code (through WDAC) protects against many threats, your organization might use unsigned LOB applications, for which the process of signing might be difficult. You might also have applications that are signed, but you want to add a secondary signature to them. If so, identify these applications, because you will need to create a catalog file for them. For more background information about catalog files, see [Deploy catalog files to support Windows Defender Application Control](deploy-catalog-files-to-support-windows-defender-application-control.md).
## Getting started on the deployment process ## Getting started on the deployment process
1. **Optionally, create a signing certificate for Windows Defender Application Control**. As you deploy WDAC, you might need to sign catalog files or WDAC policies internally. To do this, you will either need a publicly issued code signing certificate (that you purchase) or an internal CA. If you choose to use an internal CA, you will need to create a code signing certificate. For more information, see [Optional: Create a code signing certificate for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md). 1. Optionally, create a signing certificate for Windows Defender Application Control. As you deploy WDAC, you might need to sign catalog files or WDAC policies internally. To do this, you will either need a publicly issued code signing certificate (that you purchase) or an internal CA. If you choose to use an internal CA, you will need to [create a code signing certificate](create-code-signing-cert-for-windows-defender-application-control.md).
2. **Create WDAC policies from “golden” computers**. When you have identified departments or roles that use distinctive or partly-distinctive sets of hardware and software, you can set up “golden” computers containing that software and hardware. In this respect, creating and managing WDAC policies to align with the needs of roles or departments can be similar to managing corporate images. From each “golden” computer, you can create a WDAC policy, and decide how to manage that policy. You can merge WDAC policies to create a broader policy or a master policy, or you can manage and deploy each policy individually. For more information, see: 2. Create WDAC policies from reference computers. In this respect, creating and managing WDAC policies to align with the needs of roles or departments can be similar to managing corporate images. From each reference computer, you can create a WDAC policy, and decide how to manage that policy. You can [merge](merge-windows-defender-application-control-policies.md) WDAC policies to create a broader policy or a master policy, or you can manage and deploy each policy individually.
- [Deploy Windows Defender Application Control: policy rules and file rules](select-types-of-rules-to-create.md)
- [Merge WDAC policies](merge-windows-defender-application-control-policies.md)<br>
3. **Audit the WDAC policy and capture information about applications that are outside the policy**. We recommend that you use “audit mode” to carefully test each WDAC policy before you enforce it. With audit mode, no application is blocked—the policy just logs an event whenever an application outside the policy is started. Later, you can expand the policy to allow these applications, as needed. For more information, see [Audit Windows Defender Application Control policies](audit-windows-defender-application-control-policies.md). 3. Audit the WDAC policy and capture information about applications that are outside the policy. We recommend that you use [audit mode](audit-windows-defender-application-control-policies.md) to carefully test each WDAC policy before you enforce it. With audit mode, no application is blocked—the policy just logs an event whenever an application outside the policy is started. Later, you can expand the policy to allow these applications, as needed.
4. **Create a “catalog file” for unsigned LOB applications**. Use the Package Inspector tool to create and sign a catalog file for your unsigned LOB applications. For more information, review step 4 **Identify LOB applications that are currently unsigned**, earlier in this list, and see [Deploy catalog files to support Windows Defender Application Control](deploy-catalog-files-to-support-windows-defender-application-control.md). In later steps, you can merge the catalog file's signature into your WDAC policy, so that applications in the catalog will be allowed by the policy. 4. Create a [catalog file](deploy-catalog-files-to-support-windows-defender-application-control.md) for unsigned LOB applications. Use the Package Inspector tool to create and sign a catalog file for your unsigned LOB applications. In later steps, you can merge the catalog file's signature into your WDAC policy, so that applications in the catalog will be allowed by the policy.
6. **Capture needed policy information from the event log, and merge information into the existing policy as needed**. After a WDAC policy has been running for a time in audit mode, the event log will contain information about applications that are outside the policy. To expand the policy so that it allows for these applications, use Windows PowerShell commands to capture the needed policy information from the event log, and then merge that information into the existing policy. You can merge WDAC policies from other sources also, for flexibility in how you create your final WDAC policies. For more information, see: 6. Capture needed policy information from the event log, and merge information into the existing policy as needed. After a WDAC policy has been running for a time in audit mode, the event log will contain information about applications that are outside the policy. To expand the policy so that it allows for these applications, use Windows PowerShell commands to capture the needed policy information from the event log, and then merge that information into the existing policy. You can merge WDAC policies from other sources also, for flexibility in how you create your final WDAC policies.
- [Create a Windows Defender Application Control policy that captures audit information from the event log](windows-defender-application-control-deployment-guide.md)
- [Merge Windows Defender Application Control policies](merge-windows-defender-application-control-policies.md)<br>
7. **Deploy WDAC policies and catalog files**. After you confirm that you have completed all the preceding steps, you can begin deploying catalog files and taking WDAC policies out of auditing mode. We strongly recommend that you begin this process with a test group of users. This provides a final quality-control validation before you deploy the catalog files and WDAC policies more broadly. For more information, see: 7. Deploy WDAC policies and catalog files. After you confirm that you have completed all the preceding steps, you can begin deploying catalog files and taking WDAC policies out of auditing mode. We strongly recommend that you begin this process with a test group of users. This provides a final quality-control validation before you deploy the catalog files and WDAC policies more broadly.
- [Enforce Windows Defender Application Control policies](enforce-windows-defender-application-control-policies.md)
- [Deploy and manage Windows Defender Application Control with Group Policy](deploy-windows-defender-application-control-policies-using-group-policy.md)<br>
8. **Enable desired virtualization-based security (VBS) features**. Hardware-based security features—also called virtualization-based security (VBS) features—strengthen the protections offered by [Windows Defender Application Control](windows-defender-application-control.md). 8. Enable desired virtualization-based security (VBS) features. Hardware-based security features—also called virtualization-based security (VBS) features—strengthen the protections offered by Windows Defender Application Control.
> [!WARNING] > [!WARNING]
> Virtualization-based protection of code integrity may be incompatible with some devices and applications. We strongly recommend testing this configuration in your lab before enabling virtualization-based protection of code integrity on production systems. Failure to do so may result in unexpected failures up to and including data loss or a blue screen error (also called a stop error). > Virtualization-based protection of code integrity may be incompatible with some devices and applications. We strongly recommend testing this configuration in your lab before enabling virtualization-based protection of code integrity on production systems. Failure to do so may result in unexpected failures up to and including data loss or a blue screen error (also called a stop error).