Update planning-and-getting-started-on-the-device-guard-deployment-process.md

Fixed URLs
This commit is contained in:
jsuther1974 2017-12-28 12:44:31 -08:00 committed by GitHub
parent 1b5b9a577d
commit ea93d37521
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -33,13 +33,13 @@ 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).
- 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 organizations 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](https://technet.microsoft.com/itpro/windows/keep-secure/introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies#device-guard-with-applocker).
In day-to-day operations, your organizations 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](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md#windows-defender-device-guard-with-applocker).
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.
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 [Deploy Windows Defender Application Control: steps](https://technet.microsoft.com/itpro/windows/keep-secure/deploy-code-integrity-policies-steps).
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 [Deploy Windows Defender Application Control: steps](deploy-code-integrity-policies-steps.md).
@ -65,14 +65,14 @@ This topic provides a roadmap for planning and getting started on the Windows De
- [Merge Windows Defender Application Control policies](deploy-code-integrity-policies-steps.md#merge-windows-defender-application-control-policies)<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:
- [Enforce Windows Defender Application Control](deploy-code-integrity-policies-steps.md#enforce-windows-defender-application-control-policies)
- [Deploy and manage Windows Defender Application Control with Group Policy](deploy-code-integrity-policies-steps.md#deploy-and-manage-windows-defender-application-control-policies-with-group-policy)<br>
- [Enforce Windows Defender Application Control policies](deploy-code-integrity-policies-steps.md#enforce-windows-defender-application-control-policies)
- [Deploy and manage Windows Defender Application Control with Group Policy](deploy-code-integrity-policies-steps.md#deploy-and-manage-windows-defender-application-control-with-group-policy)<br>
8. **Enable desired hardware (VBS) security features**. Hardware-based security features—also called virtualization-based security (VBS) features—strengthen the protections offered by Windows Defender Application Control, as described in [How Windows Defender Device Guard features help protect against threats](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md#how-windows-defender-device-guard-features-help-protect-against-threats).
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, as described in [How Windows Defender Device Guard features help protect against threats](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md#how-windows-defender-device-guard-features-help-protect-against-threats).
> [!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).
For information about enabling VBS features, see [Deploy Windows Defender Device Guard: enable virtualization-based security](deploy-device-guard-enable-virtualization-based-security.md).
For information about enabling VBS features, see [Enable virtualization-based protection of code integrity](deploy-device-guard-enable-virtualization-based-security.md).
<br />