From b437b704e7a4ee4bbfd9e38f9d1393b70f2a952c Mon Sep 17 00:00:00 2001 From: Justin Hall Date: Mon, 17 Jul 2017 13:14:17 -0700 Subject: [PATCH 01/17] revised headings --- ...ent-planning-guidelines-for-device-guard.md | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md b/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md index 3a9804aa1c..8e730cae0d 100644 --- a/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md +++ b/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md @@ -45,9 +45,9 @@ The following tables provide more information about the hardware, firmware, and > • To understand the requirements in the following tables, you will need to be familiar with the main features in Device Guard: configurable code integrity policies, virtualization-based security (VBS), and Universal Extensible Firmware Interface (UEFI) Secure Boot. For information about these features, see [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).
> • Beginning with Windows 10, version 1607, Trusted Platform Module (TPM 2.0) must be enabled by default on new computers. -## Device Guard requirements for baseline protections +## Baseline protections -|Baseline Protections - requirement | Description | +|Baseline Protections | Description | |---------------------------------------------|----------------------------------------------------| | Hardware: **64-bit CPU** | A 64-bit computer is required for the Windows hypervisor to provide VBS. | | Hardware: **CPU virtualization extensions**,
plus **extended page tables** | **Requirements**: These hardware features are required for VBS:
One of the following virtualization extensions:
• VT-x (Intel) or
• AMD-V
And:
• Extended page tables, also called Second Level Address Translation (SLAT).

**Security benefits**: VBS provides isolation of the secure kernel from the normal operating system. Vulnerabilities and zero-days in the normal operating system cannot be exploited because of this isolation. | @@ -56,25 +56,24 @@ The following tables provide more information about the hardware, firmware, and | Software: **HVCI compatible drivers** | **Requirements**: See the Windows Hardware Compatibility Program requirements under [Filter.Driver.DeviceGuard.DriverCompatibility](https://msdn.microsoft.com/library/windows/hardware/mt589732(v=vs.85).aspx).

**Security benefits**: [HVCI Compatible](https://blogs.msdn.microsoft.com/windows_hardware_certification/2015/05/22/driver-compatibility-with-device-guard-in-windows-10/) drivers help ensure that VBS can maintain appropriate memory permissions. This increases resistance to bypassing vulnerable kernel drivers and helps ensure that malware cannot run in kernel. Only code verified through code integrity can run in kernel mode. | | Software: Qualified **Windows operating system** | **Requirement**: Windows 10 Enterprise, Windows 10 Education, Windows Server 2016, or Windows 10 IoT Enterprise

Important:
Windows Server 2016 running as a domain controller does not support Credential Guard. Only Device Guard is supported in this configuration.


**Security benefits**: Support for VBS and for management features that simplify configuration of Device Guard. | -> **Important**  The preceding table lists requirements for baseline protections. The following tables list requirements for improved security. You can use Device Guard with hardware, firmware, and software that support baseline protections, even if they do not support protections for improved security. However, we strongly recommend meeting the requirements for improved security, to significantly strengthen the level of security that Device Guard can provide. +> **Important**  The following tables list additional qualifications for improved security. You can use Device Guard with hardware, firmware, and software that support baseline protections, even if they do not support protections for improved security. However, we strongly recommend meeting these additional qualifications to significantly strengthen the level of security that Device Guard can provide. -## Device Guard requirements for improved security +## Additional qualifications for improved security -The following tables describes additional hardware and firmware requirements, and the improved security that is available when those requirements are met. +The following tables describe additional hardware and firmware qualifications, and the improved security that is available when these qualifications are met. ### Additional security qualifications starting with Windows 10, version 1507, and Windows Server 2016, Technical Preview 4 -| Protections for Improved Security - requirement | Description | +| Protections for Improved Security | Description | |---------------------------------------------|----------------------------------------------------| | Firmware: **Securing Boot Configuration and Management** | **Requirements**:
• BIOS password or stronger authentication must be supported.
• In the BIOS configuration, BIOS authentication must be set.
• There must be support for protected BIOS option to configure list of permitted boot devices (for example, “Boot only from internal hard drive”) and boot device order, overriding BOOTORDER modification made by operating system.
• In the BIOS configuration, BIOS options related to security and boot options (list of permitted boot devices, boot order) must be secured to prevent other operating systems from starting and to prevent changes to the BIOS settings.

**Security benefits**:
• BIOS password or stronger authentication helps ensure that only authenticated Platform BIOS administrators can change BIOS settings. This helps protect against a physically present user with BIOS access.
• Boot order when locked provides protection against the computer being booted into WinRE or another operating system on bootable media. |
-### Additional Qualification Requirements starting with Windows 10, version 1607, and Windows Server 2016 +### Additional security qualifications starting with Windows 10, version 1607, and Windows Server 2016 -> **Important**  The following tables list requirements for improved security, beyond the level of protection described in the preceding tables. You can use Device Guard with hardware, firmware, and software that do not support the following protections for improved security. As your systems meet more requirements, more protections become available to them. | Protections for Improved Security - requirement | Description | |---------------------------------------------|----------------------------------------------------| @@ -84,9 +83,8 @@ The following tables describes additional hardware and firmware requirements, an
-### Additional Qualification Requirements starting with Windows 10, version 1703 +### Additional security qualifications starting with Windows 10, version 1703 -The following table lists requirements for Windows 10, version 1703, which are in addition to all preceding requirements. | Protection for Improved Security | Description | |---------------------------------------------|----------------------------------------------------| From f647f11682d243c914b5c5e2163cb2ff02fdd883 Mon Sep 17 00:00:00 2001 From: Justin Hall Date: Mon, 17 Jul 2017 13:23:21 -0700 Subject: [PATCH 02/17] revised headings --- ...-deployment-planning-guidelines-for-device-guard.md | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md b/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md index 8e730cae0d..b43f8011f0 100644 --- a/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md +++ b/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md @@ -14,16 +14,6 @@ author: brianlic-msft - Windows 10 - Windows Server 2016 -This article describes the following: - -- [Hardware, firmware, and software requirements for Device Guard](#hardware-firmware-and-software-requirements-for-device-guard) - - [Device Guard requirements for baseline protections](#device-guard-requirements-for-baseline-protections) - - [Device Guard requirements for improved security](#device-guard-requirements-for-improved-security) -- [Device Guard deployment in different scenarios: types of devices](#device-guard-deployment-in-different-scenarios-types-of-devices) -- [Device Guard deployment in virtual machines](#device-guard-deployment-in-virtual-machines) -- [Reviewing your applications: application signing and catalog files](#reviewing-your-applications-application-signing-and-catalog-files) -- [Code integrity policy formats and signing](#code-integrity-policy-formats-and-signing) - The information in this article is intended for IT professionals, and provides a foundation for [Planning and getting started on the Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md). >**Note**  If you are an OEM, see the requirements information at [PC OEM requirements for Device Guard and Credential Guard](https://msdn.microsoft.com/library/windows/hardware/mt767514.aspx). From 4b915f616febebd25cdd32e3ec12cd854ddc2d72 Mon Sep 17 00:00:00 2001 From: Brian Lich Date: Mon, 17 Jul 2017 21:30:14 +0000 Subject: [PATCH 03/17] added contributors back --- .openpublishing.publish.config.json | 1 + 1 file changed, 1 insertion(+) diff --git a/.openpublishing.publish.config.json b/.openpublishing.publish.config.json index 6b4c0ed9c4..7a91d505ae 100644 --- a/.openpublishing.publish.config.json +++ b/.openpublishing.publish.config.json @@ -484,6 +484,7 @@ ] }, "need_generate_pdf_url_template": true, + "resolve_user_profile_using_github": true, "Targets": { "Pdf": { "template_folder": "_themes.pdf" From 83520a785d4007ef5e9fd067601aabed4e0abc41 Mon Sep 17 00:00:00 2001 From: Justin Hall Date: Mon, 17 Jul 2017 14:30:41 -0700 Subject: [PATCH 04/17] revised tables --- ...nt-planning-guidelines-for-device-guard.md | 30 +++++++++---------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md b/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md index b43f8011f0..dc11c9dc4d 100644 --- a/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md +++ b/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md @@ -37,14 +37,14 @@ The following tables provide more information about the hardware, firmware, and ## Baseline protections -|Baseline Protections | Description | +|Baseline Protections | Description | Security benefits | |---------------------------------------------|----------------------------------------------------| | Hardware: **64-bit CPU** | A 64-bit computer is required for the Windows hypervisor to provide VBS. | -| Hardware: **CPU virtualization extensions**,
plus **extended page tables** | **Requirements**: These hardware features are required for VBS:
One of the following virtualization extensions:
• VT-x (Intel) or
• AMD-V
And:
• Extended page tables, also called Second Level Address Translation (SLAT).

**Security benefits**: VBS provides isolation of the secure kernel from the normal operating system. Vulnerabilities and zero-days in the normal operating system cannot be exploited because of this isolation. | -| Firmware: **UEFI firmware version 2.3.1.c or higher with UEFI Secure Boot** | **Requirements**: See the following Windows Hardware Compatibility Program requirement: [System.Fundamentals.Firmware.UEFISecureBoot](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot)

**Security benefits**: UEFI Secure Boot helps ensure that the device boots only authorized code. This can prevent boot kits and root kits from installing and persisting across reboots. | -| Firmware: **Secure firmware update process** | **Requirements**: UEFI firmware must support secure firmware update found under the following Windows Hardware Compatibility Program requirement: [System.Fundamentals.Firmware.UEFISecureBoot](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot).

**Security benefits**: UEFI firmware just like software can have security vulnerabilities that, when found, need to be patched through firmware updates. Patching helps prevent root kits from getting installed. | -| Software: **HVCI compatible drivers** | **Requirements**: See the Windows Hardware Compatibility Program requirements under [Filter.Driver.DeviceGuard.DriverCompatibility](https://msdn.microsoft.com/library/windows/hardware/mt589732(v=vs.85).aspx).

**Security benefits**: [HVCI Compatible](https://blogs.msdn.microsoft.com/windows_hardware_certification/2015/05/22/driver-compatibility-with-device-guard-in-windows-10/) drivers help ensure that VBS can maintain appropriate memory permissions. This increases resistance to bypassing vulnerable kernel drivers and helps ensure that malware cannot run in kernel. Only code verified through code integrity can run in kernel mode. | -| Software: Qualified **Windows operating system** | **Requirement**: Windows 10 Enterprise, Windows 10 Education, Windows Server 2016, or Windows 10 IoT Enterprise

Important:
Windows Server 2016 running as a domain controller does not support Credential Guard. Only Device Guard is supported in this configuration.


**Security benefits**: Support for VBS and for management features that simplify configuration of Device Guard. | +| Hardware: **CPU virtualization extensions**,
plus **extended page tables** | These hardware features are required for VBS:
One of the following virtualization extensions:
• VT-x (Intel) or
• AMD-V
And:
• Extended page tables, also called Second Level Address Translation (SLAT). | VBS provides isolation of the secure kernel from the normal operating system. Vulnerabilities and zero-days in the normal operating system cannot be exploited because of this isolation. | +| Firmware: **UEFI firmware version 2.3.1.c or higher with UEFI Secure Boot** | See the following Windows Hardware Compatibility Program requirement: [System.Fundamentals.Firmware.UEFISecureBoot](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot) | UEFI Secure Boot helps ensure that the device boots only authorized code. This can prevent boot kits and root kits from installing and persisting across reboots. | +| Firmware: **Secure firmware update process** | UEFI firmware must support secure firmware update found under the following Windows Hardware Compatibility Program requirement: [System.Fundamentals.Firmware.UEFISecureBoot](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot). | UEFI firmware just like software can have security vulnerabilities that, when found, need to be patched through firmware updates. Patching helps prevent root kits from getting installed. | +| Software: **HVCI compatible drivers** | See the Windows Hardware Compatibility Program requirements under [Filter.Driver.DeviceGuard.DriverCompatibility](https://msdn.microsoft.com/library/windows/hardware/mt589732(v=vs.85).aspx).| [HVCI Compatible](https://blogs.msdn.microsoft.com/windows_hardware_certification/2015/05/22/driver-compatibility-with-device-guard-in-windows-10/) drivers help ensure that VBS can maintain appropriate memory permissions. This increases resistance to bypassing vulnerable kernel drivers and helps ensure that malware cannot run in kernel. Only code verified through code integrity can run in kernel mode. | +| Software: Qualified **Windows operating system** | Windows 10 Enterprise, Windows 10 Education, Windows Server 2016, or Windows 10 IoT Enterprise

Important:
Windows Server 2016 running as a domain controller does not support Credential Guard. Only Device Guard is supported in this configuration.

| Support for VBS and for management features that simplify configuration of Device Guard. | > **Important**  The following tables list additional qualifications for improved security. You can use Device Guard with hardware, firmware, and software that support baseline protections, even if they do not support protections for improved security. However, we strongly recommend meeting these additional qualifications to significantly strengthen the level of security that Device Guard can provide. @@ -56,30 +56,30 @@ The following tables describe additional hardware and firmware qualifications, a ### Additional security qualifications starting with Windows 10, version 1507, and Windows Server 2016, Technical Preview 4 -| Protections for Improved Security | Description | +| Protections for Improved Security | Description | Security benefits | |---------------------------------------------|----------------------------------------------------| -| Firmware: **Securing Boot Configuration and Management** | **Requirements**:
• BIOS password or stronger authentication must be supported.
• In the BIOS configuration, BIOS authentication must be set.
• There must be support for protected BIOS option to configure list of permitted boot devices (for example, “Boot only from internal hard drive”) and boot device order, overriding BOOTORDER modification made by operating system.
• In the BIOS configuration, BIOS options related to security and boot options (list of permitted boot devices, boot order) must be secured to prevent other operating systems from starting and to prevent changes to the BIOS settings.

**Security benefits**:
• BIOS password or stronger authentication helps ensure that only authenticated Platform BIOS administrators can change BIOS settings. This helps protect against a physically present user with BIOS access.
• Boot order when locked provides protection against the computer being booted into WinRE or another operating system on bootable media. | +| Firmware: **Securing Boot Configuration and Management** |
• BIOS password or stronger authentication must be supported.
• In the BIOS configuration, BIOS authentication must be set.
• There must be support for protected BIOS option to configure list of permitted boot devices (for example, “Boot only from internal hard drive”) and boot device order, overriding BOOTORDER modification made by operating system.
• In the BIOS configuration, BIOS options related to security and boot options (list of permitted boot devices, boot order) must be secured to prevent other operating systems from starting and to prevent changes to the BIOS settings. |

**Security benefits**:
• BIOS password or stronger authentication helps ensure that only authenticated Platform BIOS administrators can change BIOS settings. This helps protect against a physically present user with BIOS access.
• Boot order when locked provides protection against the computer being booted into WinRE or another operating system on bootable media. |
### Additional security qualifications starting with Windows 10, version 1607, and Windows Server 2016 -| Protections for Improved Security - requirement | Description | +| Protections for Improved Security | Description | Security benefits | |---------------------------------------------|----------------------------------------------------| -| Firmware: **Hardware Rooted Trust Platform Secure Boot** | **Requirements**:
Boot Integrity (Platform Secure Boot) must be supported. See the Windows Hardware Compatibility Program requirements under [System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby](https://msdn.microsoft.com/library/windows/hardware/dn932807(v=vs.85).aspx#system_fundamentals_firmware_cs_uefisecureboot_connectedstandby)
• The Hardware Security Test Interface (HSTI) 1.1.a must be implemented. See [Hardware Security Testability Specification](https://msdn.microsoft.com/en-us/library/windows/hardware/mt712332.aspx).

**Security benefits**:
• Boot Integrity (Platform Secure Boot) from Power-On provides protections against physically present attackers, and defense-in-depth against malware.
• HSTI 1.1.a provides additional security assurance for correctly secured silicon and platform. | -| Firmware: **Firmware Update through Windows Update** | **Requirements**: Firmware must support field updates through Windows Update and UEFI encapsulation update.

**Security benefits**: Helps ensure that firmware updates are fast, secure, and reliable. | -| Firmware: **Securing Boot Configuration and Management** | **Requirements**:
• Required BIOS capabilities: Ability of OEM to add ISV, OEM, or Enterprise Certificate in Secure Boot DB at manufacturing time.
• Required configurations: Microsoft UEFI CA must be removed from Secure Boot DB. Support for 3rd-party UEFI modules is permitted but should leverage ISV-provided certificates or OEM certificate for the specific UEFI software.

**Security benefits**:
• Enterprises can choose to allow proprietary EFI drivers/applications to run.
• Removing Microsoft UEFI CA from Secure Boot DB provides full control to enterprises over software that runs before the operating system boots. | +| Firmware: **Hardware Rooted Trust Platform Secure Boot** | Boot Integrity (Platform Secure Boot) must be supported. See the Windows Hardware Compatibility Program requirements under [System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby](https://msdn.microsoft.com/library/windows/hardware/dn932807(v=vs.85).aspx#system_fundamentals_firmware_cs_uefisecureboot_connectedstandby)
• The Hardware Security Test Interface (HSTI) 1.1.a must be implemented. See [Hardware Security Testability Specification](https://msdn.microsoft.com/en-us/library/windows/hardware/mt712332.aspx). |
• Boot Integrity (Platform Secure Boot) from Power-On provides protections against physically present attackers, and defense-in-depth against malware.
• HSTI 1.1.a provides additional security assurance for correctly secured silicon and platform. | +| Firmware: **Firmware Update through Windows Update** | Firmware must support field updates through Windows Update and UEFI encapsulation update. | Helps ensure that firmware updates are fast, secure, and reliable. | +| Firmware: **Securing Boot Configuration and Management** |
• Required BIOS capabilities: Ability of OEM to add ISV, OEM, or Enterprise Certificate in Secure Boot DB at manufacturing time.
• Required configurations: Microsoft UEFI CA must be removed from Secure Boot DB. Support for 3rd-party UEFI modules is permitted but should leverage ISV-provided certificates or OEM certificate for the specific UEFI software.|
• Enterprises can choose to allow proprietary EFI drivers/applications to run.
• Removing Microsoft UEFI CA from Secure Boot DB provides full control to enterprises over software that runs before the operating system boots. |
### Additional security qualifications starting with Windows 10, version 1703 -| Protection for Improved Security | Description | +| Protection for Improved Security | Description | Security benefits | |---------------------------------------------|----------------------------------------------------| -| Firmware: **VBS enablement of NX protection for UEFI runtime services** | **Requirements**:
• VBS will enable No-Execute (NX) protection on UEFI runtime service code and data memory regions. UEFI runtime service code must support read-only page protections, and UEFI runtime service data must not be exceutable.
• UEFI runtime service must meet these requirements:
    • Implement UEFI 2.6 EFI_MEMORY_ATTRIBUTES_TABLE. All UEFI runtime service memory (code and data) must be described by this table.
    • PE sections need to be page-aligned in memory (not required for in non-volitile storage).
    • The Memory Attributes Table needs to correctly mark code and data as RO/NX for configuration by the OS:
        • All entries must include attributes EFI_MEMORY_RO, EFI_MEMORY_XP, or both
        • No entries may be left with neither of the above attributes, indicating memory that is both exceutable and writable. Memory must be either readable and executable or writeable and non-executable.

Notes:
• This only applies to UEFI runtime service memory, and not UEFI boot service memory.
• This protection is applied by VBS on OS page tables.


Please also note the following:
• Do not use sections that are both writeable and exceutable
• Do not attempt to directly modify executable system memory
• Do not use dynamic code

**Security benefits**:
• Vulnerabilities in UEFI runtime, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)
• Reduces the attack surface to VBS from system firmware. | -| Firmware: **Firmware support for SMM protection** | **Requirements**: The [Windows SMM Security Mitigations Table (WSMT) specification](http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx) contains details of an Advanced Configuration and Power Interface (ACPI) table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features.

**Security benefits**:
• Protects against potential vulnerabilities in UEFI runtime services, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)
• Reduces the attack surface to VBS from system firmware.
• Blocks additional security attacks against SMM. | +| Firmware: **VBS enablement of NX protection for UEFI runtime services** |
• VBS will enable No-Execute (NX) protection on UEFI runtime service code and data memory regions. UEFI runtime service code must support read-only page protections, and UEFI runtime service data must not be exceutable.
• UEFI runtime service must meet these requirements:
    • Implement UEFI 2.6 EFI_MEMORY_ATTRIBUTES_TABLE. All UEFI runtime service memory (code and data) must be described by this table.
    • PE sections need to be page-aligned in memory (not required for in non-volitile storage).
    • The Memory Attributes Table needs to correctly mark code and data as RO/NX for configuration by the OS:
        • All entries must include attributes EFI_MEMORY_RO, EFI_MEMORY_XP, or both
        • No entries may be left with neither of the above attributes, indicating memory that is both exceutable and writable. Memory must be either readable and executable or writeable and non-executable.

Notes:
• This only applies to UEFI runtime service memory, and not UEFI boot service memory.
• This protection is applied by VBS on OS page tables.


Please also note the following:
• Do not use sections that are both writeable and exceutable
• Do not attempt to directly modify executable system memory
• Do not use dynamic code |
• Vulnerabilities in UEFI runtime, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)
• Reduces the attack surface to VBS from system firmware. | +| Firmware: **Firmware support for SMM protection** | The [Windows SMM Security Mitigations Table (WSMT) specification](http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx) contains details of an Advanced Configuration and Power Interface (ACPI) table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features.|


• Protects against potential vulnerabilities in UEFI runtime services, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)
• Reduces the attack surface to VBS from system firmware.
• Blocks additional security attacks against SMM. | ## Device Guard deployment in different scenarios: types of devices From 717fa8ca01a57691b9c018e3502c08bc8d467442 Mon Sep 17 00:00:00 2001 From: Justin Hall Date: Mon, 17 Jul 2017 14:41:45 -0700 Subject: [PATCH 05/17] added link in BitLocker topic --- .../bitlocker-device-encryption-overview-windows-10.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/windows/device-security/bitlocker/bitlocker-device-encryption-overview-windows-10.md b/windows/device-security/bitlocker/bitlocker-device-encryption-overview-windows-10.md index f08b02baf6..882e1249fb 100644 --- a/windows/device-security/bitlocker/bitlocker-device-encryption-overview-windows-10.md +++ b/windows/device-security/bitlocker/bitlocker-device-encryption-overview-windows-10.md @@ -13,7 +13,9 @@ author: Justinha **Applies to** - Windows 10 -This topic provides an overview of the ways that BitLocker and device encryption can help protect data on devices running Windows 10. For a general overview and list of topics about BitLocker, see [BitLocker](bitlocker-overview.md). +This topic explains how BitLocker and device encryption can help protect data on devices running Windows 10. +For an architectural overview abot how device encryption works with Secure Boot, see [Secure boot and device encryption overview](https://docs.microsoft.com/windows-hardware/drivers/bringup/secure-boot-and-device-encryption-overview). +For a general overview and list of topics about BitLocker, see [BitLocker](bitlocker-overview.md). When users travel, their organization’s confidential data goes with them. Wherever confidential data is stored, it must be protected against unauthorized access. Windows has a long history of providing at-rest data-protection solutions that guard against nefarious attackers, beginning with the Encrypting File System in the Windows 2000 operating system. More recently, BitLocker has provided encryption for full drives and portable drives; in Windows 10, BitLocker will even protect individual files, with data loss prevention capabilities. Windows consistently improves data protection by improving existing options and by providing new strategies. From 0fe65352722d42ef05e8b65952a0877c2a69f686 Mon Sep 17 00:00:00 2001 From: Justin Hall Date: Mon, 17 Jul 2017 14:45:54 -0700 Subject: [PATCH 06/17] fixed tables --- ...and-deployment-planning-guidelines-for-device-guard.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md b/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md index dc11c9dc4d..b49276c3cc 100644 --- a/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md +++ b/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md @@ -38,7 +38,7 @@ The following tables provide more information about the hardware, firmware, and ## Baseline protections |Baseline Protections | Description | Security benefits | -|---------------------------------------------|----------------------------------------------------| +|---------------------------------------------|----------------------------------------------------|----| | Hardware: **64-bit CPU** | A 64-bit computer is required for the Windows hypervisor to provide VBS. | | Hardware: **CPU virtualization extensions**,
plus **extended page tables** | These hardware features are required for VBS:
One of the following virtualization extensions:
• VT-x (Intel) or
• AMD-V
And:
• Extended page tables, also called Second Level Address Translation (SLAT). | VBS provides isolation of the secure kernel from the normal operating system. Vulnerabilities and zero-days in the normal operating system cannot be exploited because of this isolation. | | Firmware: **UEFI firmware version 2.3.1.c or higher with UEFI Secure Boot** | See the following Windows Hardware Compatibility Program requirement: [System.Fundamentals.Firmware.UEFISecureBoot](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot) | UEFI Secure Boot helps ensure that the device boots only authorized code. This can prevent boot kits and root kits from installing and persisting across reboots. | @@ -57,7 +57,7 @@ The following tables describe additional hardware and firmware qualifications, a | Protections for Improved Security | Description | Security benefits | -|---------------------------------------------|----------------------------------------------------| +|---------------------------------------------|----------------------------------------------------|------| | Firmware: **Securing Boot Configuration and Management** |
• BIOS password or stronger authentication must be supported.
• In the BIOS configuration, BIOS authentication must be set.
• There must be support for protected BIOS option to configure list of permitted boot devices (for example, “Boot only from internal hard drive”) and boot device order, overriding BOOTORDER modification made by operating system.
• In the BIOS configuration, BIOS options related to security and boot options (list of permitted boot devices, boot order) must be secured to prevent other operating systems from starting and to prevent changes to the BIOS settings. |

**Security benefits**:
• BIOS password or stronger authentication helps ensure that only authenticated Platform BIOS administrators can change BIOS settings. This helps protect against a physically present user with BIOS access.
• Boot order when locked provides protection against the computer being booted into WinRE or another operating system on bootable media. |
@@ -66,7 +66,7 @@ The following tables describe additional hardware and firmware qualifications, a | Protections for Improved Security | Description | Security benefits | -|---------------------------------------------|----------------------------------------------------| +|---------------------------------------------|----------------------------------------------------|-----| | Firmware: **Hardware Rooted Trust Platform Secure Boot** | Boot Integrity (Platform Secure Boot) must be supported. See the Windows Hardware Compatibility Program requirements under [System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby](https://msdn.microsoft.com/library/windows/hardware/dn932807(v=vs.85).aspx#system_fundamentals_firmware_cs_uefisecureboot_connectedstandby)
• The Hardware Security Test Interface (HSTI) 1.1.a must be implemented. See [Hardware Security Testability Specification](https://msdn.microsoft.com/en-us/library/windows/hardware/mt712332.aspx). |
• Boot Integrity (Platform Secure Boot) from Power-On provides protections against physically present attackers, and defense-in-depth against malware.
• HSTI 1.1.a provides additional security assurance for correctly secured silicon and platform. | | Firmware: **Firmware Update through Windows Update** | Firmware must support field updates through Windows Update and UEFI encapsulation update. | Helps ensure that firmware updates are fast, secure, and reliable. | | Firmware: **Securing Boot Configuration and Management** |
• Required BIOS capabilities: Ability of OEM to add ISV, OEM, or Enterprise Certificate in Secure Boot DB at manufacturing time.
• Required configurations: Microsoft UEFI CA must be removed from Secure Boot DB. Support for 3rd-party UEFI modules is permitted but should leverage ISV-provided certificates or OEM certificate for the specific UEFI software.|
• Enterprises can choose to allow proprietary EFI drivers/applications to run.
• Removing Microsoft UEFI CA from Secure Boot DB provides full control to enterprises over software that runs before the operating system boots. | @@ -77,7 +77,7 @@ The following tables describe additional hardware and firmware qualifications, a | Protection for Improved Security | Description | Security benefits | -|---------------------------------------------|----------------------------------------------------| +|---------------------------------------------|----------------------------------------------------|------| | Firmware: **VBS enablement of NX protection for UEFI runtime services** |
• VBS will enable No-Execute (NX) protection on UEFI runtime service code and data memory regions. UEFI runtime service code must support read-only page protections, and UEFI runtime service data must not be exceutable.
• UEFI runtime service must meet these requirements:
    • Implement UEFI 2.6 EFI_MEMORY_ATTRIBUTES_TABLE. All UEFI runtime service memory (code and data) must be described by this table.
    • PE sections need to be page-aligned in memory (not required for in non-volitile storage).
    • The Memory Attributes Table needs to correctly mark code and data as RO/NX for configuration by the OS:
        • All entries must include attributes EFI_MEMORY_RO, EFI_MEMORY_XP, or both
        • No entries may be left with neither of the above attributes, indicating memory that is both exceutable and writable. Memory must be either readable and executable or writeable and non-executable.

Notes:
• This only applies to UEFI runtime service memory, and not UEFI boot service memory.
• This protection is applied by VBS on OS page tables.


Please also note the following:
• Do not use sections that are both writeable and exceutable
• Do not attempt to directly modify executable system memory
• Do not use dynamic code |
• Vulnerabilities in UEFI runtime, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)
• Reduces the attack surface to VBS from system firmware. | | Firmware: **Firmware support for SMM protection** | The [Windows SMM Security Mitigations Table (WSMT) specification](http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx) contains details of an Advanced Configuration and Power Interface (ACPI) table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features.|


• Protects against potential vulnerabilities in UEFI runtime services, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)
• Reduces the attack surface to VBS from system firmware.
• Blocks additional security attacks against SMM. | From 3604dd6f27addbe9a23c2bbe8d8d1a4af2ec90f3 Mon Sep 17 00:00:00 2001 From: Justin Hall Date: Mon, 17 Jul 2017 15:00:18 -0700 Subject: [PATCH 07/17] fixed tables --- ...-deployment-planning-guidelines-for-device-guard.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md b/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md index b49276c3cc..5c320db82c 100644 --- a/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md +++ b/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md @@ -38,8 +38,8 @@ The following tables provide more information about the hardware, firmware, and ## Baseline protections |Baseline Protections | Description | Security benefits | -|---------------------------------------------|----------------------------------------------------|----| -| Hardware: **64-bit CPU** | A 64-bit computer is required for the Windows hypervisor to provide VBS. | +|--------------------------------|----------------------------------------------------|-------------------| +| Hardware: **64-bit CPU** | A 64-bit computer is required for the Windows hypervisor to provide VBS. | | | Hardware: **CPU virtualization extensions**,
plus **extended page tables** | These hardware features are required for VBS:
One of the following virtualization extensions:
• VT-x (Intel) or
• AMD-V
And:
• Extended page tables, also called Second Level Address Translation (SLAT). | VBS provides isolation of the secure kernel from the normal operating system. Vulnerabilities and zero-days in the normal operating system cannot be exploited because of this isolation. | | Firmware: **UEFI firmware version 2.3.1.c or higher with UEFI Secure Boot** | See the following Windows Hardware Compatibility Program requirement: [System.Fundamentals.Firmware.UEFISecureBoot](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot) | UEFI Secure Boot helps ensure that the device boots only authorized code. This can prevent boot kits and root kits from installing and persisting across reboots. | | Firmware: **Secure firmware update process** | UEFI firmware must support secure firmware update found under the following Windows Hardware Compatibility Program requirement: [System.Fundamentals.Firmware.UEFISecureBoot](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot). | UEFI firmware just like software can have security vulnerabilities that, when found, need to be patched through firmware updates. Patching helps prevent root kits from getting installed. | @@ -55,10 +55,14 @@ The following tables describe additional hardware and firmware qualifications, a ### Additional security qualifications starting with Windows 10, version 1507, and Windows Server 2016, Technical Preview 4 +| Protections for Improved Security | Description | Security benefits | +|---------------------------------------------|----------------------------------------------------|------| +| Text | Text | Text | + | Protections for Improved Security | Description | Security benefits | |---------------------------------------------|----------------------------------------------------|------| -| Firmware: **Securing Boot Configuration and Management** |
• BIOS password or stronger authentication must be supported.
• In the BIOS configuration, BIOS authentication must be set.
• There must be support for protected BIOS option to configure list of permitted boot devices (for example, “Boot only from internal hard drive”) and boot device order, overriding BOOTORDER modification made by operating system.
• In the BIOS configuration, BIOS options related to security and boot options (list of permitted boot devices, boot order) must be secured to prevent other operating systems from starting and to prevent changes to the BIOS settings. |

**Security benefits**:
• BIOS password or stronger authentication helps ensure that only authenticated Platform BIOS administrators can change BIOS settings. This helps protect against a physically present user with BIOS access.
• Boot order when locked provides protection against the computer being booted into WinRE or another operating system on bootable media. | +| Firmware: **Securing Boot Configuration and Management** |
• BIOS password or stronger authentication must be supported.
• In the BIOS configuration, BIOS authentication must be set.
• There must be support for protected BIOS option to configure list of permitted boot devices (for example, “Boot only from internal hard drive”) and boot device order, overriding BOOTORDER modification made by operating system.
• In the BIOS configuration, BIOS options related to security and boot options (list of permitted boot devices, boot order) must be secured to prevent other operating systems from starting and to prevent changes to the BIOS settings. |
• BIOS password or stronger authentication helps ensure that only authenticated Platform BIOS administrators can change BIOS settings. This helps protect against a physically present user with BIOS access.
• Boot order when locked provides protection against the computer being booted into WinRE or another operating system on bootable media. |
From 21425663d76a0f193ca39ce48c3d19959da30fdd Mon Sep 17 00:00:00 2001 From: Justin Hall Date: Mon, 17 Jul 2017 15:09:46 -0700 Subject: [PATCH 08/17] fixed tables --- ...oyment-planning-guidelines-for-device-guard.md | 15 +++++---------- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md b/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md index 5c320db82c..5b2545753c 100644 --- a/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md +++ b/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md @@ -57,12 +57,7 @@ The following tables describe additional hardware and firmware qualifications, a | Protections for Improved Security | Description | Security benefits | |---------------------------------------------|----------------------------------------------------|------| -| Text | Text | Text | - - -| Protections for Improved Security | Description | Security benefits | -|---------------------------------------------|----------------------------------------------------|------| -| Firmware: **Securing Boot Configuration and Management** |
• BIOS password or stronger authentication must be supported.
• In the BIOS configuration, BIOS authentication must be set.
• There must be support for protected BIOS option to configure list of permitted boot devices (for example, “Boot only from internal hard drive”) and boot device order, overriding BOOTORDER modification made by operating system.
• In the BIOS configuration, BIOS options related to security and boot options (list of permitted boot devices, boot order) must be secured to prevent other operating systems from starting and to prevent changes to the BIOS settings. |
• BIOS password or stronger authentication helps ensure that only authenticated Platform BIOS administrators can change BIOS settings. This helps protect against a physically present user with BIOS access.
• Boot order when locked provides protection against the computer being booted into WinRE or another operating system on bootable media. | +| Firmware: **Securing Boot Configuration and Management** | • BIOS password or stronger authentication must be supported.
• In the BIOS configuration, BIOS authentication must be set.
• There must be support for protected BIOS option to configure list of permitted boot devices (for example, “Boot only from internal hard drive”) and boot device order, overriding BOOTORDER modification made by operating system.
• In the BIOS configuration, BIOS options related to security and boot options (list of permitted boot devices, boot order) must be secured to prevent other operating systems from starting and to prevent changes to the BIOS settings. | • BIOS password or stronger authentication helps ensure that only authenticated Platform BIOS administrators can change BIOS settings. This helps protect against a physically present user with BIOS access.
• Boot order when locked provides protection against the computer being booted into WinRE or another operating system on bootable media. |
@@ -71,9 +66,9 @@ The following tables describe additional hardware and firmware qualifications, a | Protections for Improved Security | Description | Security benefits | |---------------------------------------------|----------------------------------------------------|-----| -| Firmware: **Hardware Rooted Trust Platform Secure Boot** | Boot Integrity (Platform Secure Boot) must be supported. See the Windows Hardware Compatibility Program requirements under [System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby](https://msdn.microsoft.com/library/windows/hardware/dn932807(v=vs.85).aspx#system_fundamentals_firmware_cs_uefisecureboot_connectedstandby)
• The Hardware Security Test Interface (HSTI) 1.1.a must be implemented. See [Hardware Security Testability Specification](https://msdn.microsoft.com/en-us/library/windows/hardware/mt712332.aspx). |
• Boot Integrity (Platform Secure Boot) from Power-On provides protections against physically present attackers, and defense-in-depth against malware.
• HSTI 1.1.a provides additional security assurance for correctly secured silicon and platform. | +| Firmware: **Hardware Rooted Trust Platform Secure Boot** | Boot Integrity (Platform Secure Boot) must be supported. See the Windows Hardware Compatibility Program requirements under [System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby](https://msdn.microsoft.com/library/windows/hardware/dn932807(v=vs.85).aspx#system_fundamentals_firmware_cs_uefisecureboot_connectedstandby)
• The Hardware Security Test Interface (HSTI) 1.1.a must be implemented. See [Hardware Security Testability Specification](https://msdn.microsoft.com/en-us/library/windows/hardware/mt712332.aspx). | • Boot Integrity (Platform Secure Boot) from Power-On provides protections against physically present attackers, and defense-in-depth against malware.
• HSTI 1.1.a provides additional security assurance for correctly secured silicon and platform. | | Firmware: **Firmware Update through Windows Update** | Firmware must support field updates through Windows Update and UEFI encapsulation update. | Helps ensure that firmware updates are fast, secure, and reliable. | -| Firmware: **Securing Boot Configuration and Management** |
• Required BIOS capabilities: Ability of OEM to add ISV, OEM, or Enterprise Certificate in Secure Boot DB at manufacturing time.
• Required configurations: Microsoft UEFI CA must be removed from Secure Boot DB. Support for 3rd-party UEFI modules is permitted but should leverage ISV-provided certificates or OEM certificate for the specific UEFI software.|
• Enterprises can choose to allow proprietary EFI drivers/applications to run.
• Removing Microsoft UEFI CA from Secure Boot DB provides full control to enterprises over software that runs before the operating system boots. | +| Firmware: **Securing Boot Configuration and Management** | • Required BIOS capabilities: Ability of OEM to add ISV, OEM, or Enterprise Certificate in Secure Boot DB at manufacturing time.
• Required configurations: Microsoft UEFI CA must be removed from Secure Boot DB. Support for 3rd-party UEFI modules is permitted but should leverage ISV-provided certificates or OEM certificate for the specific UEFI software.| • Enterprises can choose to allow proprietary EFI drivers/applications to run.
• Removing Microsoft UEFI CA from Secure Boot DB provides full control to enterprises over software that runs before the operating system boots. |
@@ -82,8 +77,8 @@ The following tables describe additional hardware and firmware qualifications, a | Protection for Improved Security | Description | Security benefits | |---------------------------------------------|----------------------------------------------------|------| -| Firmware: **VBS enablement of NX protection for UEFI runtime services** |
• VBS will enable No-Execute (NX) protection on UEFI runtime service code and data memory regions. UEFI runtime service code must support read-only page protections, and UEFI runtime service data must not be exceutable.
• UEFI runtime service must meet these requirements:
    • Implement UEFI 2.6 EFI_MEMORY_ATTRIBUTES_TABLE. All UEFI runtime service memory (code and data) must be described by this table.
    • PE sections need to be page-aligned in memory (not required for in non-volitile storage).
    • The Memory Attributes Table needs to correctly mark code and data as RO/NX for configuration by the OS:
        • All entries must include attributes EFI_MEMORY_RO, EFI_MEMORY_XP, or both
        • No entries may be left with neither of the above attributes, indicating memory that is both exceutable and writable. Memory must be either readable and executable or writeable and non-executable.

Notes:
• This only applies to UEFI runtime service memory, and not UEFI boot service memory.
• This protection is applied by VBS on OS page tables.


Please also note the following:
• Do not use sections that are both writeable and exceutable
• Do not attempt to directly modify executable system memory
• Do not use dynamic code |
• Vulnerabilities in UEFI runtime, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)
• Reduces the attack surface to VBS from system firmware. | -| Firmware: **Firmware support for SMM protection** | The [Windows SMM Security Mitigations Table (WSMT) specification](http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx) contains details of an Advanced Configuration and Power Interface (ACPI) table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features.|


• Protects against potential vulnerabilities in UEFI runtime services, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)
• Reduces the attack surface to VBS from system firmware.
• Blocks additional security attacks against SMM. | +| Firmware: **VBS enablement of NX protection for UEFI runtime services** | • VBS will enable No-Execute (NX) protection on UEFI runtime service code and data memory regions. UEFI runtime service code must support read-only page protections, and UEFI runtime service data must not be exceutable.
• UEFI runtime service must meet these requirements:
    • Implement UEFI 2.6 EFI_MEMORY_ATTRIBUTES_TABLE. All UEFI runtime service memory (code and data) must be described by this table.
    • PE sections need to be page-aligned in memory (not required for in non-volitile storage).
    • The Memory Attributes Table needs to correctly mark code and data as RO/NX for configuration by the OS:
        • All entries must include attributes EFI_MEMORY_RO, EFI_MEMORY_XP, or both
        • No entries may be left with neither of the above attributes, indicating memory that is both exceutable and writable. Memory must be either readable and executable or writeable and non-executable.

Notes:
• This only applies to UEFI runtime service memory, and not UEFI boot service memory.
• This protection is applied by VBS on OS page tables.


Please also note the following:
• Do not use sections that are both writeable and exceutable
• Do not attempt to directly modify executable system memory
• Do not use dynamic code | • Vulnerabilities in UEFI runtime, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)
• Reduces the attack surface to VBS from system firmware. | +| Firmware: **Firmware support for SMM protection** | The [Windows SMM Security Mitigations Table (WSMT) specification](http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx) contains details of an Advanced Configuration and Power Interface (ACPI) table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features.| • Protects against potential vulnerabilities in UEFI runtime services, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)
• Reduces the attack surface to VBS from system firmware.
• Blocks additional security attacks against SMM. | ## Device Guard deployment in different scenarios: types of devices From 828d5a348b08dc5bed5fe7787308e3bc68014242 Mon Sep 17 00:00:00 2001 From: Bill McIlhargey Date: Mon, 17 Jul 2017 18:28:55 -0400 Subject: [PATCH 09/17] Update tpm-recommendations.md Modified Device Guard line to match https://docs.microsoft.com/en-us/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard --- windows/device-security/tpm/tpm-recommendations.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/windows/device-security/tpm/tpm-recommendations.md b/windows/device-security/tpm/tpm-recommendations.md index d0283a1020..a328d7e773 100644 --- a/windows/device-security/tpm/tpm-recommendations.md +++ b/windows/device-security/tpm/tpm-recommendations.md @@ -105,10 +105,10 @@ The following table defines which Windows features require TPM support. | Passport: Domain AADJ Join | Required | Required | Supports both versions of TPM, but requires TPM with HMAC and EK certificate for key attestation support. | | Passport: MSA or Local Account | Required | Required | TPM 2.0 is required with HMAC and EK certificate for key attestation support. | | Device Encryption | Not Applicable | Required | TPM 2.0 is required for all InstantGo devices. | -| Device Guard / Configurable Code Integrity | See next column | Recommended | | +| Device Guard / Configurable Code Integrity | Not Applicable | Required | Beginning with Windows 10, version 1607, Trusted Platform Module (TPM 2.0) must be enabled by default on new computers. | | Credential Guard | Required | Required | For Windows 10, version 1511, TPM 1.2 or 2.0 is highly recommended. If you don't have a TPM installed, Credential Guard will still be enabled, but the keys used to encrypt Credential Guard will not be protected by the TPM. | | Device Health Attestation | Required | Required | | -| Windows Hello | Not Required | Recommended | | +| Windows Hello | Not Required | Recommended | Whenever possible, Microsoft recommends the use of TPM hardware. The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. [How keys are protected](https://docs.microsoft.com/en-us/windows/access-protection/hello-for-business/hello-how-it-works#how-keys-are-protected) | | UEFI Secure Boot | Not Required | Recommended | | | Platform Key Storage provider | Required | Required | | | Virtual Smart Card | Required | Required | | From 9f8a106fe2fbec2d849f8842f216cf8dcc892054 Mon Sep 17 00:00:00 2001 From: Bill McIlhargey Date: Mon, 17 Jul 2017 18:33:15 -0400 Subject: [PATCH 10/17] Update tpm-recommendations.md added windows hello for business to clearly state both items --- windows/device-security/tpm/tpm-recommendations.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/device-security/tpm/tpm-recommendations.md b/windows/device-security/tpm/tpm-recommendations.md index a328d7e773..69f5838087 100644 --- a/windows/device-security/tpm/tpm-recommendations.md +++ b/windows/device-security/tpm/tpm-recommendations.md @@ -108,7 +108,7 @@ The following table defines which Windows features require TPM support. | Device Guard / Configurable Code Integrity | Not Applicable | Required | Beginning with Windows 10, version 1607, Trusted Platform Module (TPM 2.0) must be enabled by default on new computers. | | Credential Guard | Required | Required | For Windows 10, version 1511, TPM 1.2 or 2.0 is highly recommended. If you don't have a TPM installed, Credential Guard will still be enabled, but the keys used to encrypt Credential Guard will not be protected by the TPM. | | Device Health Attestation | Required | Required | | -| Windows Hello | Not Required | Recommended | Whenever possible, Microsoft recommends the use of TPM hardware. The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. [How keys are protected](https://docs.microsoft.com/en-us/windows/access-protection/hello-for-business/hello-how-it-works#how-keys-are-protected) | +| Windows Hello / Windows Hello for Business | Not Required | Recommended | Whenever possible, Microsoft recommends the use of TPM hardware. The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. [How keys are protected](https://docs.microsoft.com/en-us/windows/access-protection/hello-for-business/hello-how-it-works#how-keys-are-protected) | | UEFI Secure Boot | Not Required | Recommended | | | Platform Key Storage provider | Required | Required | | | Virtual Smart Card | Required | Required | | From ad6693114ad57f418ce8d91e3321bfda63b2dfa1 Mon Sep 17 00:00:00 2001 From: Bill McIlhargey Date: Mon, 17 Jul 2017 18:54:46 -0400 Subject: [PATCH 11/17] Update stop-employees-from-using-the-windows-store.md Windows 10 1511 is no longer needed to be specified. As of 1511 Pro is no longer supported but Enterprise and Education continue to be supported Updated the blurb to specify this as well and link to the KB for additional information --- .../stop-employees-from-using-the-windows-store.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/windows/configuration/stop-employees-from-using-the-windows-store.md b/windows/configuration/stop-employees-from-using-the-windows-store.md index 43f1bbb647..9674b6bb66 100644 --- a/windows/configuration/stop-employees-from-using-the-windows-store.md +++ b/windows/configuration/stop-employees-from-using-the-windows-store.md @@ -59,10 +59,10 @@ For more information on AppLocker, see [What is AppLocker?](/windows/device-secu ## Block Microsoft Store using Group Policy -Applies to: Windows 10 Enterprise, version 1511, Windows 10 Education +Applies to: Windows 10 Enterprise, Windows 10 Education > [!Note] -> Not supported on Windows 10 Pro. +> Not supported on Windows 10 Pro, starting with version 1511. For more info, see [Knowledge Base article #3135657](https://support.microsoft.com/kb/3135657). You can also use Group Policy to manage access to Microsoft Store. From 16456849ffade6a30be74d58cd4042071c907396 Mon Sep 17 00:00:00 2001 From: Justin Hall Date: Mon, 17 Jul 2017 16:01:32 -0700 Subject: [PATCH 12/17] fixed tables --- ...ments-and-deployment-planning-guidelines-for-device-guard.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md b/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md index 5b2545753c..46527eb217 100644 --- a/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md +++ b/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md @@ -66,7 +66,7 @@ The following tables describe additional hardware and firmware qualifications, a | Protections for Improved Security | Description | Security benefits | |---------------------------------------------|----------------------------------------------------|-----| -| Firmware: **Hardware Rooted Trust Platform Secure Boot** | Boot Integrity (Platform Secure Boot) must be supported. See the Windows Hardware Compatibility Program requirements under [System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby](https://msdn.microsoft.com/library/windows/hardware/dn932807(v=vs.85).aspx#system_fundamentals_firmware_cs_uefisecureboot_connectedstandby)
• The Hardware Security Test Interface (HSTI) 1.1.a must be implemented. See [Hardware Security Testability Specification](https://msdn.microsoft.com/en-us/library/windows/hardware/mt712332.aspx). | • Boot Integrity (Platform Secure Boot) from Power-On provides protections against physically present attackers, and defense-in-depth against malware.
• HSTI 1.1.a provides additional security assurance for correctly secured silicon and platform. | +| Firmware: **Hardware Rooted Trust Platform Secure Boot** | • Boot Integrity (Platform Secure Boot) must be supported. See the Windows Hardware Compatibility Program requirements under [System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby](https://msdn.microsoft.com/library/windows/hardware/dn932807(v=vs.85).aspx#system_fundamentals_firmware_cs_uefisecureboot_connectedstandby)
• The Hardware Security Test Interface (HSTI) 1.1.a must be implemented. See [Hardware Security Testability Specification](https://msdn.microsoft.com/en-us/library/windows/hardware/mt712332.aspx). | • Boot Integrity (Platform Secure Boot) from Power-On provides protections against physically present attackers, and defense-in-depth against malware.
• HSTI 1.1.a provides additional security assurance for correctly secured silicon and platform. | | Firmware: **Firmware Update through Windows Update** | Firmware must support field updates through Windows Update and UEFI encapsulation update. | Helps ensure that firmware updates are fast, secure, and reliable. | | Firmware: **Securing Boot Configuration and Management** | • Required BIOS capabilities: Ability of OEM to add ISV, OEM, or Enterprise Certificate in Secure Boot DB at manufacturing time.
• Required configurations: Microsoft UEFI CA must be removed from Secure Boot DB. Support for 3rd-party UEFI modules is permitted but should leverage ISV-provided certificates or OEM certificate for the specific UEFI software.| • Enterprises can choose to allow proprietary EFI drivers/applications to run.
• Removing Microsoft UEFI CA from Secure Boot DB provides full control to enterprises over software that runs before the operating system boots. | From 0ab48ecf6bb575a6877711e8e59661a2cfafaf99 Mon Sep 17 00:00:00 2001 From: Justin Hall Date: Mon, 17 Jul 2017 16:10:02 -0700 Subject: [PATCH 13/17] fixed tables --- ...ments-and-deployment-planning-guidelines-for-device-guard.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md b/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md index 46527eb217..0e79244bb9 100644 --- a/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md +++ b/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md @@ -75,7 +75,7 @@ The following tables describe additional hardware and firmware qualifications, a ### Additional security qualifications starting with Windows 10, version 1703 -| Protection for Improved Security | Description | Security benefits | +| Protections for Improved Security | Description | Security benefits | |---------------------------------------------|----------------------------------------------------|------| | Firmware: **VBS enablement of NX protection for UEFI runtime services** | • VBS will enable No-Execute (NX) protection on UEFI runtime service code and data memory regions. UEFI runtime service code must support read-only page protections, and UEFI runtime service data must not be exceutable.
• UEFI runtime service must meet these requirements:
    • Implement UEFI 2.6 EFI_MEMORY_ATTRIBUTES_TABLE. All UEFI runtime service memory (code and data) must be described by this table.
    • PE sections need to be page-aligned in memory (not required for in non-volitile storage).
    • The Memory Attributes Table needs to correctly mark code and data as RO/NX for configuration by the OS:
        • All entries must include attributes EFI_MEMORY_RO, EFI_MEMORY_XP, or both
        • No entries may be left with neither of the above attributes, indicating memory that is both exceutable and writable. Memory must be either readable and executable or writeable and non-executable.

Notes:
• This only applies to UEFI runtime service memory, and not UEFI boot service memory.
• This protection is applied by VBS on OS page tables.


Please also note the following:
• Do not use sections that are both writeable and exceutable
• Do not attempt to directly modify executable system memory
• Do not use dynamic code | • Vulnerabilities in UEFI runtime, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)
• Reduces the attack surface to VBS from system firmware. | | Firmware: **Firmware support for SMM protection** | The [Windows SMM Security Mitigations Table (WSMT) specification](http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx) contains details of an Advanced Configuration and Power Interface (ACPI) table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features.| • Protects against potential vulnerabilities in UEFI runtime services, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)
• Reduces the attack surface to VBS from system firmware.
• Blocks additional security attacks against SMM. | From 4ab53c5f054e571dc2be5ca60564128db3109c5b Mon Sep 17 00:00:00 2001 From: Sven Aelterman Date: Tue, 18 Jul 2017 08:48:00 -0500 Subject: [PATCH 14/17] Fix missing heading formatting --- ...figuration-manager-integration-topology.md | 31 +++++++++---------- 1 file changed, 14 insertions(+), 17 deletions(-) diff --git a/mdop/mbam-v25/high-level-architecture-of-mbam-25-with-configuration-manager-integration-topology.md b/mdop/mbam-v25/high-level-architecture-of-mbam-25-with-configuration-manager-integration-topology.md index 78d2526dde..bb53d965cc 100644 --- a/mdop/mbam-v25/high-level-architecture-of-mbam-25-with-configuration-manager-integration-topology.md +++ b/mdop/mbam-v25/high-level-architecture-of-mbam-25-with-configuration-manager-integration-topology.md @@ -69,30 +69,27 @@ The following diagram and table describe the recommended high-level architecture ![mbam2\-5](images/mbam2-5-cmserver.png) -Server -Features to configure on this server -Description -Database Server +### Database Server -Recovery Database +#### Recovery Database This feature is configured on a computer running Windows Server and supported SQL Server instance. The **Recovery Database** stores recovery data that is collected from MBAM Client computers. -Audit Database +#### Audit Database This feature is configured on a computer running Windows Server and supported SQL Server instance. The **Audit Database** stores audit activity data that is collected from client computers that have accessed recovery data. -Reports +#### Reports This feature is configured on a computer running Windows Server and supported SQL Server instance. The **Reports** provide recovery audit data for the client computers in your enterprise. You can view reports from the Configuration Manager console or directly from SQL Server Reporting Services. -Configuration Manager Primary Site Server +### Configuration Manager Primary Site Server System Center Configuration Manager Integration feature @@ -104,9 +101,9 @@ System Center Configuration Manager Integration feature - The **Configuration Manager console** must be installed on the same computer on which you install the MBAM Server software. -Administration and Monitoring Server +### Administration and Monitoring Server -Administration and Monitoring Website +#### Administration and Monitoring Website This feature is configured on a computer running Windows Server. @@ -116,13 +113,13 @@ The **Administration and Monitoring Website** is used to: - View the Recovery Audit Report, which shows recovery activity for client computers. Other reports are viewed from the Configuration Manager console. -Self-Service Portal +#### Self-Service Portal This feature is configured on a computer running Windows Server. The **Self-Service Portal** is a website that enables end users on client computers to independently log on to a website to get a recovery key if they lose or forget their BitLocker password. -Monitoring web services for this website +#### Monitoring web services for this website This feature is installed on a computer running Windows Server. @@ -133,9 +130,9 @@ The Monitoring Web Service is no longer available in Microsoft BitLocker Adminis   -Management Workstation +### Management Workstation -MBAM Group Policy Templates +#### MBAM Group Policy Templates - The **MBAM Group Policy Templates** are Group Policy settings that define implementation settings for MBAM, which enable you to manage BitLocker drive encryption. @@ -146,9 +143,9 @@ MBAM Group Policy Templates   -MBAM Client and Configuration Manager Client computer +### MBAM Client and Configuration Manager Client computer -MBAM Client software +#### MBAM Client software The **MBAM Client**: @@ -158,7 +155,7 @@ The **MBAM Client**: - Collects recovery information and computer information about the client computers. -Configuration Manager Client +#### Configuration Manager Client The **Configuration Manager Client** enables Configuration Manager to collect hardware compatibility data about the client computers and report compliance information. From 7e65eae98a6e41f8abdef046d3e1cbcf9a4cf600 Mon Sep 17 00:00:00 2001 From: Justin Hall Date: Tue, 18 Jul 2017 08:47:12 -0700 Subject: [PATCH 15/17] fixed typo --- .../bitlocker-device-encryption-overview-windows-10.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/device-security/bitlocker/bitlocker-device-encryption-overview-windows-10.md b/windows/device-security/bitlocker/bitlocker-device-encryption-overview-windows-10.md index 882e1249fb..db72ab90ec 100644 --- a/windows/device-security/bitlocker/bitlocker-device-encryption-overview-windows-10.md +++ b/windows/device-security/bitlocker/bitlocker-device-encryption-overview-windows-10.md @@ -14,7 +14,7 @@ author: Justinha - Windows 10 This topic explains how BitLocker and device encryption can help protect data on devices running Windows 10. -For an architectural overview abot how device encryption works with Secure Boot, see [Secure boot and device encryption overview](https://docs.microsoft.com/windows-hardware/drivers/bringup/secure-boot-and-device-encryption-overview). +For an architectural overview about how device encryption works with Secure Boot, see [Secure boot and device encryption overview](https://docs.microsoft.com/windows-hardware/drivers/bringup/secure-boot-and-device-encryption-overview). For a general overview and list of topics about BitLocker, see [BitLocker](bitlocker-overview.md). When users travel, their organization’s confidential data goes with them. Wherever confidential data is stored, it must be protected against unauthorized access. Windows has a long history of providing at-rest data-protection solutions that guard against nefarious attackers, beginning with the Encrypting File System in the Windows 2000 operating system. More recently, BitLocker has provided encryption for full drives and portable drives; in Windows 10, BitLocker will even protect individual files, with data loss prevention capabilities. Windows consistently improves data protection by improving existing options and by providing new strategies. From 0bcf51264ab01e4f109199a1527d841704df6b56 Mon Sep 17 00:00:00 2001 From: Elizabeth Ross Date: Tue, 18 Jul 2017 17:42:19 +0000 Subject: [PATCH 16/17] Merged PR 2284: Removed mobile support from clearbrowsingdataonexit MDM setting --- browsers/edge/available-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/browsers/edge/available-policies.md b/browsers/edge/available-policies.md index c62e0d7b6a..9c908fe294 100644 --- a/browsers/edge/available-policies.md +++ b/browsers/edge/available-policies.md @@ -656,7 +656,7 @@ All devices must be enrolled with Intune if you want to use the Windows Custom U ### ClearBrowsingDataOnExit - **Supported versions:** Windows 10, version 1703 -- **Supported devices:** Both +- **Supported devices:** Desktop - **Details:** From 442aa65aac3462b5920124c4899733c1ee6ce500 Mon Sep 17 00:00:00 2001 From: Greg Lindsay Date: Tue, 18 Jul 2017 18:31:19 +0000 Subject: [PATCH 17/17] Merged PR 2288: Replace two incorrect links on index page Replace two incorrect links on index page --- windows/deployment/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/windows/deployment/index.md b/windows/deployment/index.md index 1705124e4a..5e0c465fb2 100644 --- a/windows/deployment/index.md +++ b/windows/deployment/index.md @@ -17,8 +17,8 @@ Learn about deployment in Windows 10 for IT professionals. This includes deploy |------|------------| |[What's new in Windows 10 deployment](deploy-whats-new.md) |See this topic for a summary of new features and some recent changes related to deploying Windows 10 in your organization. | |[Windows 10 deployment scenarios](windows-10-deployment-scenarios.md) |To successfully deploy the Windows 10 operating system in your organization, it is important to understand the different ways that it can be deployed, especially now that there are new scenarios to consider. Choosing among these scenarios, and understanding the key capabilities and limitations of each, is a key task. | -|[Windows 10 Enterprise E3 in CSP overview](deploy-whats-new.md) |Windows 10 Enterprise E3 in CSP is a new offering that delivers, by subscription, exclusive features reserved for Windows 10 Enterprise edition. | -|[Resolve Windows 10 upgrade errors](windows-10-enterprise-e3-overview.md) |This topic provides a brief introduction to Windows 10 installation processes, and provides resolution procedures that IT administrators can use to resolve issues with Windows 10 upgrade. | +|[Windows 10 Enterprise E3 in CSP overview](windows-10-enterprise-e3-overview.md) |Windows 10 Enterprise E3 in CSP is a new offering that delivers, by subscription, exclusive features reserved for Windows 10 Enterprise edition. | +|[Resolve Windows 10 upgrade errors](upgrade/resolve-windows-10-upgrade-errors.md) |This topic provides a brief introduction to Windows 10 installation processes, and provides resolution procedures that IT administrators can use to resolve issues with Windows 10 upgrade. | ## Deploy Windows 10