mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-14 22:37:22 +00:00
Merge pull request #1396 from MicrosoftDocs/FromPrivateRepo
From private repo
This commit is contained in:
huypub
GitHub
commit
516ebf1deb
@ -1,14 +1,14 @@
|
||||
{
|
||||
"redirections": [
|
||||
{
|
||||
"source_path": "windows/deployment/update/waas-windows-insider-for-business-aad.md",
|
||||
"redirect_url": "https://docs.microsoft.com/en-us/windows-insider/at-work-pro/wip-4-biz-add",
|
||||
"redirect_document_id": true
|
||||
},
|
||||
"source_path": "windows/deployment/update/waas-windows-insider-for-business-aad.md",
|
||||
"redirect_url": "https://docs.microsoft.com/en-us/windows-insider/at-work-pro/wip-4-biz-add",
|
||||
"redirect_document_id": true
|
||||
},
|
||||
{
|
||||
"source_path": "windows/deployment/update/waas-windows-insider-for-business-faq.md",
|
||||
"redirect_url": "https://docs.microsoft.com/en-us/windows-insider/at-work-pro/wip-4-biz-get-started",
|
||||
"redirect_document_id": true
|
||||
"source_path": "windows/deployment/update/waas-windows-insider-for-business-faq.md",
|
||||
"redirect_url": "https://docs.microsoft.com/en-us/windows-insider/at-work-pro/wip-4-biz-get-started",
|
||||
"redirect_document_id": true
|
||||
},
|
||||
{
|
||||
"source_path": "windows/deployment/update/waas-windows-insider-for-business.md",
|
||||
@ -16,6 +16,11 @@
|
||||
"redirect_document_id": true
|
||||
},
|
||||
{
|
||||
"source_path": "windows/security/hardware-protection/how-hardware-based-containers-help-protect-windows.md",
|
||||
"redirect_url": "/windows/security/identity-protection/how-hardware-based-containers-help-protect-windows",
|
||||
"redirect_document_id": true
|
||||
},
|
||||
{
|
||||
"source_path": "windows/security/threat-protection/applocker/add-rules-for-packaged-apps-to-existing-applocker-rule-set.md",
|
||||
"redirect_url": "/windows/security/threat-protection/windows-defender-application-control/applocker/add-rules-for-packaged-apps-to-existing-applocker-rule-set",
|
||||
"redirect_document_id": true
|
||||
|
||||
@ -2915,6 +2915,9 @@ The following diagram shows the Policy configuration service provider in tree fo
|
||||
<dd>
|
||||
<a href="./policy-csp-security.md#security-preventautomaticdeviceencryptionforazureadjoineddevices" id="security-preventautomaticdeviceencryptionforazureadjoineddevices">Security/PreventAutomaticDeviceEncryptionForAzureADJoinedDevices</a>
|
||||
</dd>
|
||||
<dd>
|
||||
<a href="./policy-csp-security.md#security-recoveryenvironmentauthentication" id="security-recoveryenvironmentauthentication">Security/RecoveryEnvironmentAuthentication</a>
|
||||
</dd>
|
||||
<dd>
|
||||
<a href="./policy-csp-security.md#security-requiredeviceencryption" id="security-requiredeviceencryption">Security/RequireDeviceEncryption</a>
|
||||
</dd>
|
||||
|
||||
@ -11,6 +11,8 @@ ms.date: 07/30/2018
|
||||
|
||||
# Policy CSP - Security
|
||||
|
||||
> [!WARNING]
|
||||
> Some information relates to prereleased product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
|
||||
|
||||
|
||||
<hr/>
|
||||
@ -43,6 +45,9 @@ ms.date: 07/30/2018
|
||||
<dd>
|
||||
<a href="#security-preventautomaticdeviceencryptionforazureadjoineddevices">Security/PreventAutomaticDeviceEncryptionForAzureADJoinedDevices</a>
|
||||
</dd>
|
||||
<dd>
|
||||
<a href="#security-recoveryenvironmentauthentication">Security/RecoveryEnvironmentAuthentication</a>
|
||||
</dd>
|
||||
<dd>
|
||||
<a href="#security-requiredeviceencryption">Security/RequireDeviceEncryption</a>
|
||||
</dd>
|
||||
@ -488,6 +493,87 @@ The following list shows the supported values:
|
||||
|
||||
<hr/>
|
||||
|
||||
<!--Policy-->
|
||||
<a href="" id="security-recoveryenvironmentauthentication"></a>**Security/RecoveryEnvironmentAuthentication**
|
||||
|
||||
<!--SupportedSKUs-->
|
||||
<table>
|
||||
<tr>
|
||||
<th>Home</th>
|
||||
<th>Pro</th>
|
||||
<th>Business</th>
|
||||
<th>Enterprise</th>
|
||||
<th>Education</th>
|
||||
<th>Mobile</th>
|
||||
<th>Mobile Enterprise</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><img src="images/crossmark.png" alt="cross mark" /></td>
|
||||
<td><img src="images/checkmark.png" alt="check mark" /><sup>5</sup></td>
|
||||
<td><img src="images/checkmark.png" alt="check mark" /><sup>5</sup></td>
|
||||
<td><img src="images/checkmark.png" alt="check mark" /><sup>5</sup></td>
|
||||
<td><img src="images/checkmark.png" alt="check mark" /><sup>5</sup></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<!--/SupportedSKUs-->
|
||||
<!--Scope-->
|
||||
[Scope](./policy-configuration-service-provider.md#policy-scope):
|
||||
|
||||
> [!div class = "checklist"]
|
||||
> * User
|
||||
> * Device
|
||||
|
||||
<hr/>
|
||||
|
||||
<!--/Scope-->
|
||||
<!--Description-->
|
||||
Added in Windows 10, next major version. This policy controls the Admin Authentication requirement in RecoveryEnvironment.
|
||||
|
||||
Supported values:
|
||||
- 0 - Default: Keep using default(current) behavior
|
||||
- 1 - RequireAuthentication: Admin Authentication is always required for components in RecoveryEnvironment
|
||||
- 2 - NoRequireAuthentication: Admin Authentication is not required for components in RecoveryEnvironment
|
||||
|
||||
<!--/Description-->
|
||||
<!--SupportedValues-->
|
||||
|
||||
<!--/SupportedValues-->
|
||||
<!--Example-->
|
||||
|
||||
<!--/Example-->
|
||||
<!--Validation-->
|
||||
**Validation procedure**
|
||||
|
||||
The validation requires a check whether Refresh ("Keep my files") and Reset ("Remove everything") requires admin authentication in WinRE.
|
||||
The process of starting Push Button Reset (PBR) in WinRE:
|
||||
|
||||
1. Open a cmd as Administrator, run command "reagentc /boottore" and restart the OS to boot to WinRE.
|
||||
1. OS should boot to the blue screen of WinRE UI, go through TroubleShoot -> Reset this PC, it should show two options: "Keep my files" and "Remove everything".
|
||||
|
||||
If the MDM policy is set to "Default" (0) or does not exist, the admin authentication flow should work as default behavior:
|
||||
|
||||
1. Start PBR in WinRE, choose "Keep my files", it should pop up admin authentication.
|
||||
1. Click "<-" (right arrow) button and choose "Remove everything", it should not pop up admin authentication and just go to PBR options.
|
||||
|
||||
If the MDM policy is set to "RequireAuthentication" (1)
|
||||
|
||||
1. Start PBR in WinRE, choose "Keep my files", it should pop up admin authentication.
|
||||
1. Click "<-" (right arrow) button and choose "Remove everything", it should also pop up admin authentication.
|
||||
|
||||
If the MDM policy is set to "NoRequireAuthentication" (2)
|
||||
|
||||
1. Start PBR in WinRE, choose "Keep my files", it should not pop up admin authentication.
|
||||
1. Go through PBR options and click "cancel" at final confirmation page, wait unit the UI is back.
|
||||
1. Click "TroubleShoot" -> "Reset this PC" again, choose "Remove everything", it should not pop up admin authentication neither.
|
||||
|
||||
<!--/Validation-->
|
||||
<!--/Policy-->
|
||||
|
||||
<hr/>
|
||||
|
||||
<!--Policy-->
|
||||
<a href="" id="security-requiredeviceencryption"></a>**Security/RequireDeviceEncryption**
|
||||
|
||||
@ -661,6 +747,7 @@ Footnote:
|
||||
- 2 - Added in Windows 10, version 1703.
|
||||
- 3 - Added in Windows 10, version 1709.
|
||||
- 4 - Added in Windows 10, version 1803.
|
||||
- 5 - Added in the next major release of Windows 10.
|
||||
|
||||
<!--/Policies-->
|
||||
|
||||
|
||||
@ -1,51 +0,0 @@
|
||||
---
|
||||
title: How hardware-based containers help protect Windows 10 (Windows 10)
|
||||
description: Windows 10 uses containers to isolate sensitive system services and data, enabling them to remain secure even when the operating system has been compromised.
|
||||
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: justinha
|
||||
ms.date: 06/29/2017
|
||||
---
|
||||
|
||||
# How hardware-based containers help protect Windows 10
|
||||
|
||||
Windows 10 uses containers to isolate sensitive system services and data, enabling them to remain secure even when the operating system has been compromised.
|
||||
Windows 10 protects critical resources, such as the Windows authentication stack, single sign-on tokens, Windows Hello biometric stack, and Virtual Trusted Platform Module, by using a container type called Windows Defender System Guard.
|
||||
|
||||
Windows Defender System Guard reorganizes the existing Windows 10 system integrity features under one roof and sets up the next set of investments in Windows security. It's designed to make the these security guarantees:
|
||||
|
||||
- Protect and maintain the integrity of the system as it starts up
|
||||
- Protect and maintain the integrity of the system after it's running
|
||||
- Validate that system integrity has truly been maintained through local and remote attestation
|
||||
|
||||
## Maintaining the integrity of the system as it starts
|
||||
|
||||
With Windows 7, one of the means attackers would use to persist and evade detection was to install what is often referred to as a bootkit or rootkit on the system. This malicious software would start before Windows started, or during the boot process itself, enabling it to start with the highest level of privilege.
|
||||
|
||||
With Windows 10 running on modern hardware (that is, Windows 8-certified or greater) we have a hardware-based root of trust that helps us ensure that no unauthorized firmware or software (such as a bootkit) can start before the Windows bootloader. This hardware-based root of trust comes from the device’s [Secure Boot feature](https://docs.microsoft.com/previous-versions/windows/it-pro/windows-8.1-and-8/hh824987), which is part of the Unified Extensible Firmware Interface (UEFI).
|
||||
|
||||
After successful verification and startup of the device’s firmware and Windows bootloader, the next opportunity for attackers to tamper with the system’s integrity is while the rest of the Windows operating system and defenses are starting. As an attacker, embedding your malicious code using a rootkit within the boot process enables you to gain the maximum level of privilege and gives you the ability to more easily persist and evade detection.
|
||||
|
||||
This is where Windows Defender System Guard protection begins with its ability to ensure that only properly signed and secure Windows files and drivers, including third party, can start on the device. At the end of the Windows boot process, System Guard will start the system’s antimalware solution, which scans all third party drivers, at which point the system boot process is completed. In the end, Windows Defender System Guard helps ensure that the system securely boots with integrity and that it hasn’t been compromised before the remainder of your system defenses start.
|
||||
|
||||
|
||||
|
||||
## Maintaining integrity of the system after it’s running (run time)
|
||||
|
||||
Prior to Windows 10, if an attacker exploited the system and gained SYSTEM level privilege or they compromised the kernel itself, it was game over. The level of control that an attacker would acquire in this condition would enable them to tamper with and bypass many, if not all, of your system defenses. While we have a number of development practices and technologies (such as Windows Defender Exploit Guard) that have made it difficult to gain this level of privilege in Windows 10, the reality is that we needed a way to maintain the integrity of the most sensitive Windows services and data, even when the highest level of privilege has been secured by an adversary.
|
||||
|
||||
With Windows 10, we introduced the concept of virtualization-based security (VBS), which enables us to contain the most sensitive Windows services and data in hardware-based isolation, which is the Windows Defender System Guard container. This secure environment provides us with the hardware-based security boundary we need to be able to secure and maintain the integrity of critical system services at run time like Credential Guard, Device Guard, Virtual TPM and parts of Windows Defender Exploit Guard, just to name a few.
|
||||
|
||||
|
||||
|
||||
## Validating platform integrity after Windows is running (run time)
|
||||
|
||||
While Windows Defender System Guard provides advanced protection that will help protect and maintain the integrity of the platform during boot and at run time, the reality is that we must apply an "assume breach" mentality to even our most sophisticated security technologies. We should be able to trust that the technologies are successfully doing their jobs, but we also need the ability to verify that they were successful in achieving their goals. When it comes to platform integrity, we can’t just trust the platform, which potentially could be compromised, to self-attest to its security state. So Windows Defender System Guard includes a series of technologies that enable remote analysis of the device’s integrity.
|
||||
|
||||
As Windows 10 boots, a series of integrity measurements are taken by Windows Defender System Guard using the device’s Trusted Platform Module 2.0 (TPM 2.0). This process and data are hardware-isolated away from Windows to help ensure that the measurement data is not subject to the type of tampering that could happen if the platform was compromised. From here, the measurements can be used to determine the integrity of the device’s firmware, hardware configuration state, and Windows boot-related components, just to name a few. After the system boots, Windows Defender System Guard signs and seals these measurements using the TPM. Upon request, a management system like Intune or System Center Configuration Manager can acquire them for remote analysis. If Windows Defender System Guard indicates that the device lacks integrity, the management system can take a series of actions, such as denying the device access to resources.
|
||||
|
||||
|
||||
|
||||
@ -17,7 +17,7 @@
|
||||
|
||||
## [Install digital certificates on Windows 10 Mobile](installing-digital-certificates-on-windows-10-mobile.md)
|
||||
|
||||
## [How hardware-based containers help protect Windows 10](how-hardware-based-containers-help-protect-windows.md)
|
||||
## [Windows Defender System Guard](how-hardware-based-containers-help-protect-windows.md)
|
||||
|
||||
## [Protect derived domain credentials with Credential Guard](credential-guard/credential-guard.md)
|
||||
### [How Credential Guard works](credential-guard/credential-guard-how-it-works.md)
|
||||
|
||||
@ -7,54 +7,45 @@ ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: justinha
|
||||
ms.date: 06/29/2017
|
||||
ms.date: 07/31/2018
|
||||
---
|
||||
|
||||
# How hardware-based containers help protect Windows 10
|
||||
# Windows Defender System Guard: How hardware-based containers help protect Windows 10
|
||||
|
||||
Windows 10 uses containers to isolate sensitive system services and data, enabling them to remain secure even when the operating system has been compromised.
|
||||
Windows 10 protects critical resources, such as the Windows authentication stack, single sign-on tokens, Windows Hello biometric stack, and Virtual Trusted Platform Module, by using a container type called Windows Defender System Guard.
|
||||
|
||||
Protecting system services and data with Windows Defender System Guard is an important first step, but is just the beginning of what we need to do as it doesn’t protect the rest of the operating system, information on the device, other apps, or the network.
|
||||
Since systems are generally compromised through the application layer, and often though browsers, Windows 10 includes Windows Defender Application Guard to isolate Microsoft Edge from the operating system, information on the device, and the network.
|
||||
With this, Windows can start to protect the broader range of resources.
|
||||
Windows Defender System Guard reorganizes the existing Windows 10 system integrity features under one roof and sets up the next set of investments in Windows security. It's designed to make the these security guarantees:
|
||||
|
||||
The following diagram shows Windows Defender System Guard and Windows Defender Application Guard in relation to the Windows 10 operating system.
|
||||
- Protect and maintain the integrity of the system as it starts up
|
||||
- Protect and maintain the integrity of the system after it's running
|
||||
- Validate that system integrity has truly been maintained through local and remote attestation
|
||||
|
||||
|
||||
## Maintaining the integrity of the system as it starts
|
||||
|
||||
## What security threats do containers protect against
|
||||
With Windows 7, one of the means attackers would use to persist and evade detection was to install what is often referred to as a bootkit or rootkit on the system. This malicious software would start before Windows started, or during the boot process itself, enabling it to start with the highest level of privilege.
|
||||
|
||||
Exploiting zero days and vulnerabilities are an increasing threat that attackers are attempting to take advantage of.
|
||||
The following diagram shows the traditional Windows software stack: a kernel with an app platform, and an app running on top of it.
|
||||
Let’s look at how an attacker might elevate privileges and move down the stack.
|
||||
With Windows 10 running on modern hardware (that is, Windows 8-certified or greater) we have a hardware-based root of trust that helps us ensure that no unauthorized firmware or software (such as a bootkit) can start before the Windows bootloader. This hardware-based root of trust comes from the device’s [Secure Boot feature](https://docs.microsoft.com/previous-versions/windows/it-pro/windows-8.1-and-8/hh824987), which is part of the Unified Extensible Firmware Interface (UEFI).
|
||||
|
||||
|
||||
After successful verification and startup of the device’s firmware and Windows bootloader, the next opportunity for attackers to tamper with the system’s integrity is while the rest of the Windows operating system and defenses are starting. As an attacker, embedding your malicious code using a rootkit within the boot process enables you to gain the maximum level of privilege and gives you the ability to more easily persist and evade detection.
|
||||
|
||||
In desktop operating systems, those apps typically run under the context of the user’s privileges.
|
||||
If the app was malicious, it would have access to all the files in the file system, all the settings that you as a user Standard user have access to, and so on.
|
||||
This is where Windows Defender System Guard protection begins with its ability to ensure that only properly signed and secure Windows files and drivers, including third party, can start on the device. At the end of the Windows boot process, System Guard will start the system’s antimalware solution, which scans all third party drivers, at which point the system boot process is completed. In the end, Windows Defender System Guard helps ensure that the system securely boots with integrity and that it hasn’t been compromised before the remainder of your system defenses start.
|
||||
|
||||
A different type of app may run under the context of an Administrator.
|
||||
If attackers exploit a vulnerability in that app, they could gain Administrator privileges.
|
||||
Then they can start turning off defenses.
|
||||
|
||||
|
||||
They can poke down a little bit lower in the stack and maybe elevate to System, which is greater than Administrator.
|
||||
Or if they can exploit the kernel mode, they can turn on and turn off all defenses, while at the same time making the computer look healthy.
|
||||
SecOps tools could report the computer as healthy when in fact it’s completely under the control of someone else.
|
||||
## Maintaining integrity of the system after it’s running (run time)
|
||||
|
||||
One way to address this threat is to use a sandbox, as smartphones do.
|
||||
That puts a layer between the app layer and the Windows platform services.
|
||||
Universal Windows Platform (UWP) applications work this way.
|
||||
But what if a vulnerability in the sandbox exists?
|
||||
The attacker can escape and take control of the system.
|
||||
Prior to Windows 10, if an attacker exploited the system and gained SYSTEM level privilege or they compromised the kernel itself, it was game over. The level of control that an attacker would acquire in this condition would enable them to tamper with and bypass many, if not all, of your system defenses. While we have a number of development practices and technologies (such as Windows Defender Exploit Guard) that have made it difficult to gain this level of privilege in Windows 10, the reality is that we needed a way to maintain the integrity of the most sensitive Windows services and data, even when the highest level of privilege has been secured by an adversary.
|
||||
|
||||
## How containers help protect Windows 10
|
||||
With Windows 10, we introduced the concept of virtualization-based security (VBS), which enables us to contain the most sensitive Windows services and data in hardware-based isolation, which is the Windows Defender System Guard container. This secure environment provides us with the hardware-based security boundary we need to be able to secure and maintain the integrity of critical system services at run time like Credential Guard, Device Guard, Virtual TPM and parts of Windows Defender Exploit Guard, just to name a few.
|
||||
|
||||
Windows 10 addresses this by using virtualization based security to isolate more and more components out of Windows (left side) over time and moving those components into a separate, isolated hardware container.
|
||||
The container helps prevent zero days and vulnerabilities from allowing an attacker to take control of a device.
|
||||
|
||||
|
||||
Anything that's running in that container on the right side will be safe, even from Windows, even if the kernel's compromised.
|
||||
Anything that's running in that container will also be secure against a compromised app.
|
||||
Initially, Windows Defender System Guard will protect things like authentication and other system services and data that needs to resist malware, and more things will be protected over time.
|
||||
## Validating platform integrity after Windows is running (run time)
|
||||
|
||||
While Windows Defender System Guard provides advanced protection that will help protect and maintain the integrity of the platform during boot and at run time, the reality is that we must apply an "assume breach" mentality to even our most sophisticated security technologies. We should be able to trust that the technologies are successfully doing their jobs, but we also need the ability to verify that they were successful in achieving their goals. When it comes to platform integrity, we can’t just trust the platform, which potentially could be compromised, to self-attest to its security state. So Windows Defender System Guard includes a series of technologies that enable remote analysis of the device’s integrity.
|
||||
|
||||
As Windows 10 boots, a series of integrity measurements are taken by Windows Defender System Guard using the device’s Trusted Platform Module 2.0 (TPM 2.0). This process and data are hardware-isolated away from Windows to help ensure that the measurement data is not subject to the type of tampering that could happen if the platform was compromised. From here, the measurements can be used to determine the integrity of the device’s firmware, hardware configuration state, and Windows boot-related components, just to name a few. After the system boots, Windows Defender System Guard signs and seals these measurements using the TPM. Upon request, a management system like Intune or System Center Configuration Manager can acquire them for remote analysis. If Windows Defender System Guard indicates that the device lacks integrity, the management system can take a series of actions, such as denying the device access to resources.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -387,10 +387,10 @@
|
||||
###### [Audit process tracking](auditing/basic-audit-process-tracking.md)
|
||||
###### [Audit system events](auditing/basic-audit-system-events.md)
|
||||
|
||||
##### [Advanced security audit policies](auditing/advanced-security-auditing.md)
|
||||
###### [Planning and deploying advanced security audit policies](auditing/planning-and-deploying-advanced-security-audit-policies.md)
|
||||
###### [Advanced security auditing FAQ](auditing/advanced-security-auditing-faq.md)
|
||||
####### [Which editions of Windows support advanced audit policy configuration](auditing/which-editions-of-windows-support-advanced-audit-policy-configuration.md)
|
||||
#### [Advanced security audit policies](auditing/advanced-security-auditing.md)
|
||||
##### [Planning and deploying advanced security audit policies](auditing/planning-and-deploying-advanced-security-audit-policies.md)
|
||||
##### [Advanced security auditing FAQ](auditing/advanced-security-auditing-faq.md)
|
||||
###### [Which editions of Windows support advanced audit policy configuration](auditing/which-editions-of-windows-support-advanced-audit-policy-configuration.md)
|
||||
|
||||
###### [Using advanced security auditing options to monitor dynamic access control objects](auditing/using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md)
|
||||
####### [Monitor the central access policies that apply on a file server](auditing/monitor-the-central-access-policies-that-apply-on-a-file-server.md)
|
||||
@ -731,7 +731,7 @@
|
||||
|
||||
|
||||
|
||||
#### [Security policy settings](security-policy-settings/security-policy-settings.md)
|
||||
### [Security policy settings](security-policy-settings/security-policy-settings.md)
|
||||
#### [Administer security policy settings](security-policy-settings/administer-security-policy-settings.md)
|
||||
##### [Network List Manager policies](security-policy-settings/network-list-manager-policies.md)
|
||||
#### [Configure security policy settings](security-policy-settings/how-to-configure-security-policy-settings.md)
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user