diff --git a/windows/device-security/device-guard/3. Proc/3a. Docs/Branching_and_pull_requests.docx b/windows/device-security/device-guard/3. Proc/3a. Docs/Branching_and_pull_requests.docx new file mode 100644 index 0000000000..ec63c21835 Binary files /dev/null and b/windows/device-security/device-guard/3. Proc/3a. Docs/Branching_and_pull_requests.docx differ diff --git a/windows/device-security/device-guard/3. Proc/3a. Docs/Git_command_workflow.docx b/windows/device-security/device-guard/3. Proc/3a. Docs/Git_command_workflow.docx new file mode 100644 index 0000000000..7d481eab92 Binary files /dev/null and b/windows/device-security/device-guard/3. Proc/3a. Docs/Git_command_workflow.docx differ diff --git a/windows/device-security/device-guard/3. Proc/3a. Docs/Git_questions.docx b/windows/device-security/device-guard/3. Proc/3a. Docs/Git_questions.docx new file mode 100644 index 0000000000..775c13a02a Binary files /dev/null and b/windows/device-security/device-guard/3. Proc/3a. Docs/Git_questions.docx differ diff --git a/windows/device-security/device-guard/3. Proc/3a. Docs/Git_questions2.docx b/windows/device-security/device-guard/3. Proc/3a. Docs/Git_questions2.docx new file mode 100644 index 0000000000..312c9f44ab Binary files /dev/null and b/windows/device-security/device-guard/3. Proc/3a. Docs/Git_questions2.docx differ diff --git a/windows/device-security/device-guard/3. Proc/3a. Docs/Git_questions_justin_responses.docx b/windows/device-security/device-guard/3. Proc/3a. Docs/Git_questions_justin_responses.docx new file mode 100644 index 0000000000..7806727093 Binary files /dev/null and b/windows/device-security/device-guard/3. Proc/3a. Docs/Git_questions_justin_responses.docx differ diff --git a/windows/device-security/device-guard/3. Proc/3a. Docs/LCA_stuff_trademarking/Third-party_trademarks.docx b/windows/device-security/device-guard/3. Proc/3a. Docs/LCA_stuff_trademarking/Third-party_trademarks.docx new file mode 100644 index 0000000000..4cd0675123 Binary files /dev/null and b/windows/device-security/device-guard/3. Proc/3a. Docs/LCA_stuff_trademarking/Third-party_trademarks.docx differ diff --git a/windows/device-security/device-guard/3. Proc/3a. Docs/Outlook-set-reminders-for-other-people.docx b/windows/device-security/device-guard/3. Proc/3a. Docs/Outlook-set-reminders-for-other-people.docx new file mode 100644 index 0000000000..0a8cb52e54 Binary files /dev/null and b/windows/device-security/device-guard/3. Proc/3a. Docs/Outlook-set-reminders-for-other-people.docx differ diff --git a/windows/device-security/device-guard/3. Proc/3a. Docs/Permissions_to_apps.docx b/windows/device-security/device-guard/3. Proc/3a. Docs/Permissions_to_apps.docx new file mode 100644 index 0000000000..2f0621f2d7 Binary files /dev/null and b/windows/device-security/device-guard/3. Proc/3a. Docs/Permissions_to_apps.docx differ diff --git a/windows/device-security/device-guard/3. Proc/3a. Docs/Publishing_documents_procedure.docx b/windows/device-security/device-guard/3. Proc/3a. Docs/Publishing_documents_procedure.docx new file mode 100644 index 0000000000..68541b893b Binary files /dev/null and b/windows/device-security/device-guard/3. Proc/3a. Docs/Publishing_documents_procedure.docx differ diff --git a/windows/device-security/device-guard/3. Proc/3a. Docs/Writing_sub-steps.docx b/windows/device-security/device-guard/3. Proc/3a. Docs/Writing_sub-steps.docx new file mode 100644 index 0000000000..3c3d308341 Binary files /dev/null and b/windows/device-security/device-guard/3. Proc/3a. Docs/Writing_sub-steps.docx differ diff --git a/windows/device-security/device-guard/3. Proc/3a. Docs/mstp.chm b/windows/device-security/device-guard/3. Proc/3a. Docs/mstp.chm new file mode 100644 index 0000000000..db3bdd69ff Binary files /dev/null and b/windows/device-security/device-guard/3. Proc/3a. Docs/mstp.chm differ diff --git a/windows/device-security/device-guard/3. Proc/3a. Docs/mstp.chw b/windows/device-security/device-guard/3. Proc/3a. Docs/mstp.chw new file mode 100644 index 0000000000..3f8b903934 Binary files /dev/null and b/windows/device-security/device-guard/3. Proc/3a. Docs/mstp.chw differ diff --git a/windows/device-security/device-guard/3. Proc/3a. Docs/~$anching_and_pull_requests.docx b/windows/device-security/device-guard/3. Proc/3a. Docs/~$anching_and_pull_requests.docx new file mode 100644 index 0000000000..0b22025225 Binary files /dev/null and b/windows/device-security/device-guard/3. Proc/3a. Docs/~$anching_and_pull_requests.docx differ diff --git a/windows/device-security/device-guard/3. Proc/3a. Docs/~$t_command_workflow.docx b/windows/device-security/device-guard/3. Proc/3a. Docs/~$t_command_workflow.docx new file mode 100644 index 0000000000..cb3d6cadbe Binary files /dev/null and b/windows/device-security/device-guard/3. Proc/3a. Docs/~$t_command_workflow.docx differ diff --git a/windows/device-security/device-guard/3. Proc/3a. Docs/~$t_questions.docx b/windows/device-security/device-guard/3. Proc/3a. Docs/~$t_questions.docx new file mode 100644 index 0000000000..0b22025225 Binary files /dev/null and b/windows/device-security/device-guard/3. Proc/3a. Docs/~$t_questions.docx differ diff --git a/windows/device-security/device-guard/3. Proc/3a. Docs/~$t_questions_justin_responses.docx b/windows/device-security/device-guard/3. Proc/3a. Docs/~$t_questions_justin_responses.docx new file mode 100644 index 0000000000..7364974570 Binary files /dev/null and b/windows/device-security/device-guard/3. Proc/3a. Docs/~$t_questions_justin_responses.docx differ diff --git a/windows/device-security/device-guard/3. Proc/3a. Docs/~$tlook-set-reminders-for-other-people.docx b/windows/device-security/device-guard/3. Proc/3a. Docs/~$tlook-set-reminders-for-other-people.docx new file mode 100644 index 0000000000..549e6d80a8 Binary files /dev/null and b/windows/device-security/device-guard/3. Proc/3a. Docs/~$tlook-set-reminders-for-other-people.docx differ diff --git a/windows/device-security/device-guard/3. Proc/3a. Docs/~WRL1871.tmp b/windows/device-security/device-guard/3. Proc/3a. Docs/~WRL1871.tmp new file mode 100644 index 0000000000..65b397f586 Binary files /dev/null and b/windows/device-security/device-guard/3. Proc/3a. Docs/~WRL1871.tmp differ diff --git a/windows/device-security/device-guard/3. Proc/3a. Docs/~WRL2707.tmp b/windows/device-security/device-guard/3. Proc/3a. Docs/~WRL2707.tmp new file mode 100644 index 0000000000..5f5cfc78f9 Binary files /dev/null and b/windows/device-security/device-guard/3. Proc/3a. Docs/~WRL2707.tmp differ diff --git a/windows/device-security/device-guard/deploy-code-integrity-policies-steps.md b/windows/device-security/device-guard/deploy-code-integrity-policies-steps.md index d13224f45d..8a6acb16d6 100644 --- a/windows/device-security/device-guard/deploy-code-integrity-policies-steps.md +++ b/windows/device-security/device-guard/deploy-code-integrity-policies-steps.md @@ -20,7 +20,424 @@ For an overview of the process described in the following procedures, see [Deplo The process for creating a golden code integrity policy from a reference system is straightforward. This section outlines the process that is required to successfully create a code integrity policy with Windows PowerShell. First, for this example, you must initiate variables to be used during the creation process. Rather than using variables, you can simply use the full file paths in the command. Next, you create the code integrity policy by scanning the system for installed applications. When created, the policy file is converted to binary format so that Windows can consume its contents. -> **Note**  Before you begin this procedure, ensure that the reference PC is clean of viruses or malware. Each piece of installed software should be validated as trustworthy before you create this policy. Also, be sure that any software that you would like to be scanned is installed on the system before you create the code integrity policy. +> **Note**  Before you begin this procedure, make sure that the reference PC is virus and malware-free,and that any software you want to be scanned is installed on the system before creating the code integrity policy. + +### Scripting and applications + +Each installed software application should be validated as trustworthy before you create a policy. We recommend that you review the reference PC for software that can load arbitrary DLLs and run code or scripts that could render the PC more vulnerable. Examples include software aimed at development or scripting such as msbuild.exe (part of Visual Studio and the .NET Framework) which can be removed, and Windows Script Host (WSH), which can be manually disabled if you do not want it to run scripts. +You can remove or disable such software on reference PCs used to create code integrity policies. You can also fine-tune your control by using Device Guard in combination with AppLocker, as described in [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). + +Members of the security community* continuously collaborate with Microsoft to help protect customers. With the help of their valuable reports, Microsoft has identified a list of valid applications that an attacker could also potentially use to bypass Device Guard code integrity policies. + +In certain circumstances, if the use case is appropriate, for example if your operational scenario requires elevated security, you may want to block these applications. For example, if you have a code integrity policy that trusts all Microsoft-signed applications, we recommend that you block the following applications (optional in the case of cscript.exe and wscript.exe) from running on your systems: + +- bash.exe +- bginfo.exe +- cdb.exe +- cscript.exe1 +- csi.exe +- dnx.exe +- fsi.exe +- kd.exe +- lxssmanager.dll +- msbuild.exe2 +- mshta.exe +- ntsd.exe +- rcsi.exe +- windbg.exe +- wscript.exe1 + +1 Microsoft Windows Script Host (WSH) is an automation technology for Microsoft Windows operating systems that allows scripts to load and run. It comprises two files, wscript.exe and cscript.exe. When WSH is enabled, scripts are allowed. However, when Device Guard is enabled, the functionality of WSH scripts is restricted by default. + +2 If you are using your reference system in a development context and use msbuild.exe to build managed applications, we recommend that you whitelist msbuild.exe in your code integrity policies. However, if your reference system is an end user device that is not being used in a development context, we recommend that you block msbuild.exe. + +* Microsoft recognizes the efforts of those in the security community who help us protect customers through responsible vulnerability disclosure, and extends thanks to the following people: + +|Name|Twitter| +|---|---| +|Casey Smith |@subTee| +|Matt Graeber | @mattifestation| +|Matt Nelson | @enigma0x3| +|Oddvar Moe |@Oddvarmoe| + +
+ +>!Note +>This application list is fluid and will be updated with the latest vendor information as application vulnerabilities are resolved and new issues are discovered. + +When an application version is upgraded, you may want to add deny rules to your code integrity policies for that application’s previous, less secure versions, especially to fix a vulnerability or potential Device Guard bypass. Certain vendors may or may not intend to update their software to work with Device Guard. + +To block the listed applications, you can merge this policy into your existing policy by adding the following deny rules using the Powershell Merge-CIPolicy cmdlet: + +``` + + + 10.0.0.0 + {A244370E-44C9-4C06-B551-F6016E563076} + {2E07F7E4-194C-4D20-B7C9-6F44A6C5A234} + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 0 + + +``` + +### Disable Windows Script Host + +If you are using Device Guard code integrity policies, the policies place constraints on Powershell and WSH scripts. When Device Guard is enabled, by default, PowerShell scripts execute in “ConstrainedLanguage” language mode, in which neither wscript.exe and cscript.exe can invoke untrusted Active X controls or COM objects. However, signed PowerShell scripts are permitted to execute in “FullLanguage” language mode, and trusted or signed wscript or cscript scripts can invoke Active X controls or COM objects. For further information on Powershell language modes, see [Language Modes](https://msdn.microsoft.com/en-us/powershell/reference/4.0/microsoft.powershell.core/about/about_language_modes). + +Alternatively, though script hosts are safer with Device Guard enabled, if your reference PC does not require any scripting, you may want to completely disable WSH. Disabling WSH prevents all users from running any scripts, including VBScript and JScript scripts. Note that some applications may require WSH to be enabled. You can disable WSH by configuring Device Guard code integrity policies. + +### Disable Windows Script Host using code integrity policies + +To disable Windows Script Hosting, you can simply create further deny rules to add the script hosts (wscript.exe and cscript.exe) to the list of blocked applications in your code integrity policy as follows: +``` + + + 1.0.0.0 + {A244370E-44C9-4C06-B551-F6016E563076} + {2E07F7E4-194C-4D20-B7C9-6F44A6C5A234} + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +``` + +
+ +The June 2017 Windows updates resolve a vulnerability in Powershell that allowed an attacker to bypass Device Guard code integrity policies. Powershell cmdlets cannot be blocked by name or version, and therefore must be blocked by their corresponding hashes. We recommend that you block the following Powershell cmdlets and merge this policy into your existing policy by adding the following deny rules using the Merge-CIPolicy cmdlet: + +``` + + + 10.0.0.0 + {A244370E-44C9-4C06-B551-F6016E563076} + {2E07F7E4-194C-4D20-B7C9-6F44A6C5A234} + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 0 + + +``` +
To create a code integrity policy, copy each of the following commands into an elevated Windows PowerShell session, in order: diff --git a/windows/device-security/device-guard/planning-and-getting-started-on-the-device-guard-deployment-process - Copy.md b/windows/device-security/device-guard/planning-and-getting-started-on-the-device-guard-deployment-process - Copy.md new file mode 100644 index 0000000000..3e922b1c6b --- /dev/null +++ b/windows/device-security/device-guard/planning-and-getting-started-on-the-device-guard-deployment-process - Copy.md @@ -0,0 +1,61 @@ +--- +title: Planning and getting started on the Device Guard deployment process (Windows 10) +description: To help you plan and begin the initial test stages of a deployment of Microsoft Device Guard, this article outlines how to gather information, create a plan, and begin to create and test initial code integrity policies. +keywords: virtualization, security, malware +ms.prod: w10 +ms.mktglfcycl: deploy +localizationpriority: high +author: brianlic-msft +--- + +# Planning and getting started on the Device Guard deployment process + +**Applies to** +- Windows 10 +- Windows Server 2016 + +This topic provides a roadmap for planning and getting started on the Device Guard deployment process, with links to topics that provide additional detail. Planning for Device Guard deployment involves looking at both the end-user and the IT pro impact of your choices. Use the following steps to guide you. + +## Planning + +1. **Review requirements, especially hardware requirements for VBS**. Review the virtualization-based security (VBS) features described in [How Device Guard features help protect against threats](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md#how-device-guard-features-help-protect-against-threats). Then you can assess your end-user systems to see how many support the VBS features you are interested in, as described in [Hardware, firmware, and software requirements for Device Guard](requirements-and-deployment-planning-guidelines-for-device-guard.md#hardware-firmware-and-software-requirements-for-device-guard). + +2. **Group devices by degree of control needed**. Group devices according to the table in [Device Guard deployment in different scenarios: types of devices](requirements-and-deployment-planning-guidelines-for-device-guard.md#device-guard-deployment-in-different-scenarios-types-of-devices). 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?
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**. When several departments all use the same hardware and software, you might need to deploy only one code integrity policy for them. More variety across departments might mean you need to create and manage more code integrity policies. The following questions can help you clarify how many code integrity policies to create: + - How standardized is the hardware?
This can be relevant because of drivers. You could create a code integrity 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 code integrity policies on different "reference" hardware, then merge the policies together, to ensure that the resulting policy recognizes all the drivers in your environment. + + - Is there already a list of accepted applications?
A list of accepted applications can be used to help create a baseline code integrity policy.
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). + + - What software does each department or role need? Should they be able to install and run other departments’ software?
If multiple departments are allowed to run the same list of software, you might be able to merge several code integrity policies to simplify management. + + - Are there departments or roles where unique, restricted software is used?
If one department needs to run an application that no other department is allowed, it might require a separate code integrity policy. Similarly, if only one department must run an old version of an application (while other departments allow only the newer version), it might require a separate code integrity policy. + +4. **Identify LOB applications that are currently unsigned**. Although requiring signed code (through code integrity policies) 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 a basic description of catalog files, see the table in [Introduction to Device Guard: virtualization-based security and code integrity policies](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md). For more background information about catalog files, see [Reviewing your applications: application signing and catalog files](requirements-and-deployment-planning-guidelines-for-device-guard.md#reviewing-your-applications-application-signing-and-catalog-files). + +## Getting started on the deployment process + +1. **Optionally, create a signing certificate for code integrity policies**. As you deploy code integrity policies, you might need to sign catalog files or code integrity 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 code integrity policies](optional-create-a-code-signing-certificate-for-code-integrity-policies.md). + +2. **Create code integrity 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 code integrity 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 code integrity policy, and decide how to manage that policy. You can merge code integrity policies to create a broader policy or a master policy, or you can manage and deploy each policy individually. For more information, see: + - [Deploy code integrity policies: policy rules and file rules](deploy-code-integrity-policies-policy-rules-and-file-rules.md) + - [Deploy code integrity policies: steps](deploy-code-integrity-policies-steps.md)
+ +3. **Audit the code integrity policy and capture information about applications that are outside the policy**. We recommend that you use “audit mode” to carefully test each code integrity 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 code integrity policies](deploy-code-integrity-policies-steps.md#audit-code-integrity-policies). + +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 code integrity policies](deploy-catalog-files-to-support-code-integrity-policies.md). In later steps, you can merge the catalog file's signature into your code integrity 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 code integrity 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 code integrity policies from other sources also, for flexibility in how you create your final code integrity policies. For more information, see: + - [Create a code integrity policy that captures audit information from the event log](deploy-code-integrity-policies-steps.md#create-a-code-integrity-policy-that-captures-audit-information-from-the-event-log) + - [Merge code integrity policies](deploy-code-integrity-policies-steps.md#merge-code-integrity-policies)
+ +7. **Deploy code integrity policies and catalog files**. After you confirm that you have completed all the preceding steps, you can begin deploying catalog files and taking code integrity 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 code integrity policies more broadly. For more information, see: + - [Enforce code integrity policies](deploy-code-integrity-policies-steps.md#enforce-code-integrity-policies) + - [Deploy and manage code integrity policies with Group Policy](deploy-code-integrity-policies-steps.md#deploy-and-manage-code-integrity-policies-with-group-policy)
+ +8. **Enable desired hardware (VBS) security features**. Hardware-based security features—also called virtualization-based security (VBS) features—strengthen the protections offered by code integrity policies, as described in [How Device Guard features help protect against threats](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md#how-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 Device Guard: enable virtualization-based security](deploy-device-guard-enable-virtualization-based-security.md). diff --git a/windows/device-security/device-guard/planning-and-getting-started-on-the-device-guard-deployment-process.md b/windows/device-security/device-guard/planning-and-getting-started-on-the-device-guard-deployment-process.md index 3e922b1c6b..deeccdbaf3 100644 --- a/windows/device-security/device-guard/planning-and-getting-started-on-the-device-guard-deployment-process.md +++ b/windows/device-security/device-guard/planning-and-getting-started-on-the-device-guard-deployment-process.md @@ -25,12 +25,21 @@ This topic provides a roadmap for planning and getting started on the Device Gua 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 code integrity policy for them. More variety across departments might mean you need to create and manage more code integrity policies. The following questions can help you clarify how many code integrity policies to create: - How standardized is the hardware?
This can be relevant because of drivers. You could create a code integrity 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 code integrity policies on different "reference" hardware, then merge the policies together, to ensure that the resulting policy recognizes all the drivers in your environment. - - Is there already a list of accepted applications?
A list of accepted applications can be used to help create a baseline code integrity policy.
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). - - What software does each department or role need? Should they be able to install and run other departments’ software?
If multiple departments are allowed to run the same list of software, you might be able to merge several code integrity policies to simplify management. - Are there departments or roles where unique, restricted software is used?
If one department needs to run an application that no other department is allowed, it might require a separate code integrity policy. Similarly, if only one department must run an old version of an application (while other departments allow only the newer version), it might require a separate code integrity policy. + - Is there already a list of accepted applications?
A list of accepted applications can be used to help create a baseline code integrity policy.
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 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 Device Guard code integrity policies. + You can also fine-tune your control by using Device Guard in combination with AppLocker, as described in [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). + + 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 code integrity policies. 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 code integrity policies. Other applications whose older versions have vulnerabilities also represent a risk. Therefore, you may want to deny or block such applications from your code integrity policies. Once applications with vulnerabilities are fixed, you can create a rule that only allows the fixed version 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 Device Guard code integrity policies. + Depending on the context, you may want to block these applications. To see the list of applications, and for use case examples such as disabling Windows Script Host (WSH) or disabling msbuild.exe, See [Deploy code integrity policies: steps](https://technet.microsoft.com/itpro/windows/keep-secure/deploy-code-integrity-policies-steps)). + 4. **Identify LOB applications that are currently unsigned**. Although requiring signed code (through code integrity policies) 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 a basic description of catalog files, see the table in [Introduction to Device Guard: virtualization-based security and code integrity policies](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md). For more background information about catalog files, see [Reviewing your applications: application signing and catalog files](requirements-and-deployment-planning-guidelines-for-device-guard.md#reviewing-your-applications-application-signing-and-catalog-files). ## Getting started on the deployment process