Merge remote-tracking branch 'refs/remotes/origin/master' into atp-FEB

This commit is contained in:
jcaparas
2017-02-21 15:53:22 -08:00
37 changed files with 282 additions and 543 deletions

View File

@ -115,7 +115,11 @@ Windows 10 uses Trusted Boot on any hardware platform: It requires neither UEFI
Because UEFI-based Secure Boot has protected the bootloader and Trusted Boot has protected the Windows kernel or other Windows startup components, the next opportunity for malware to start is by infecting a non-Microsoft boot-related driver. Traditional antimalware apps dont start until after the boot-related drivers have been loaded, giving a rootkit disguised as a driver the opportunity to work.
The purpose of ELAM is to load an antimalware driver before drivers that are flagged as boot-start can be executed. This approach provides the ability for an antimalware driver to register as a trusted boot-critical driver. It is launched during the Trusted Boot process, and with that, Windows ensures that it is loaded before any other non-Microsoft software.
Early Launch Antimalware (ELAM) is designed to enable the antimalware solution to start before all non-Microsoft drivers and apps. ELAM checks the integrity of non-Microsoft drivers to determine whether the drivers are trustworthy. Because Windows needs to start as fast as possible, ELAM cannot be a complicated process of checking the driver files against known malware signatures. Instead, ELAM has the simple task of examining every boot driver and determining whether it is on the list of trusted drivers. If malware modifies a boot-related driver, ELAM will detect the change, and Windows will prevent the driver from starting, thus blocking driver-based rootkits. ELAM also allows the registered antimalware provider to scan drivers that are loaded after the boot process is complete.
Windows Defender in Windows 10 supports ELAM, as do Microsoft System Center 2012 Endpoint Protection and non-Microsoft antimalware apps.
To do this, ELAM loads an antimalware driver before drivers that are flagged as boot-start can be executed. This approach provides the ability for an antimalware driver to register as a trusted boot-critical driver. It is launched during the Trusted Boot process, and with that, Windows ensures that it is loaded before any other non-Microsoft software.
With this solution in place, boot drivers are initialized based on the classification that the ELAM driver returns according to an initialization policy. IT pros have the ability to change this policy through Group Policy.
ELAM classifies drivers as follows:

View File

@ -45,14 +45,14 @@ You can use System Center Configuration Managers existing functionality to cr
2. Extract the contents of the .zip file to a shared, read-only location that can be accessed by the network administrators who will deploy the package. You should have a file named *WindowsDefenderATPOnboardingScript.cmd*.
3. Import the configuration package by following the steps in the [How to Create Packages and Programs in Configuration Manager](https://technet.microsoft.com/library/gg682112.aspx#BKMK_Import) topic.
3. Onboard your devices using SCCM by following the steps in the [Onboard devices to Windows Defender ATP](https://docs.microsoft.com/en-us/sccm/protect/deploy-use/windows-defender-advanced-threat-protection#onboard-devices-for-windows-defender-atp) topic.
4. Deploy the package by following the steps in the [How to Deploy Packages and Programs in Configuration Manager](https://technet.microsoft.com/library/gg682178.aspx) topic.
a. Choose a predefined device collection to deploy the package to.
> [!NOTE]
> Onboarding couldn't be completed during Out-Of-Box Experience (OOBE). Make sure users pass OOBE after running Windows installation or upgrading.
> Windows Defender ATP doesn't support onboarding during the [Out-Of-Box Experience (OOBE)](https://answers.microsoft.com/en-us/windows/wiki/windows_10/how-to-complete-the-windows-10-out-of-box/47e3f943-f000-45e3-8c5c-9d85a1a0cf87) phase. Make sure users complete OOBE after running Windows installation or upgrading.
### Configure sample collection settings

View File

@ -178,11 +178,11 @@ You can do this by using either the Control Panel or the Deployment Image Servic
1. Open an elevated command prompt.
2. Add the Hyper-V Hypervisor by running the following command:
``` syntax
```
dism /image:<WIM file name> /Enable-Feature /FeatureName:Microsoft-Hyper-V-Hypervisor /all
```
3. Add the Isolated User Mode feature by running the following command:
``` syntax
```
dism /image:<WIM file name> /Enable-Feature /FeatureName:IsolatedUserMode
```

View File

@ -14,7 +14,7 @@ author: brianlic-msft
- Windows 10
- Windows Server 2016
Code integrity policies maintain the standards by which a computer running Windows 10 determines whether an application is trustworthy and can be run. For an overview of code integrity, see:
Code integrity policies provide control over a computer running Windows 10 by specifying whether a driver or application is trusted and can be run. For an overview of code integrity, 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) in "Introduction to Device Guard: virtualization-based security and code integrity policies."
- [Code integrity policy formats and signing](requirements-and-deployment-planning-guidelines-for-device-guard.md#code-integrity-policy-formats-and-signing) in "Requirements and deployment planning guidelines for Device Guard."
@ -23,7 +23,7 @@ If you already understand the basics of code integrity policy and want procedure
This topic includes the following sections:
- [Overview of the process of creating code integrity policies](#overview-of-the-process-of-creating-code-integrity-policies): Helps familiarize you with the process described in this and related topics.
- [Code integrity policy rules](#code-integrity-policy-rules): Describes one key element you specify in a policy, the *policy rules*, which control options such as audit mode or whether UMCI is enabled in a code integrity policy.
- [Code integrity policy rules](#code-integrity-policy-rules): Describes one key element you specify in a policy, the *policy rules*, which control options such as audit mode or whether user mode code integrity (UMCI) is enabled in a code integrity policy.
- [Code integrity file rule levels](#code-integrity-file-rule-levels): Describes the other key element you specify in a policy, the *file rules* (or *file rule levels*), which specify the level at which applications will be identified and trusted.
- [Example of file rule levels in use](#example-of-file-rule-levels-in-use): Gives an example of how file rule levels can be applied.
@ -31,7 +31,7 @@ This topic includes the following sections:
A common system imaging practice in todays IT organization is to establish a “golden” image as a reference for what an ideal system should look like, and then use that image to clone additional company assets. Code integrity policies follow a similar methodology, that begins with the establishment of a golden computer. As with imaging, you can have multiple golden computers based on model, department, application set, and so on. Although the thought process around the creation of code integrity policies is similar to imaging, these policies should be maintained independently. Assess the necessity of additional code integrity policies based on what should be allowed to be installed and run and for whom. For more details on doing this assessment, see the planning steps in [Planning and getting started on the Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md).
> **Note**&nbsp;&nbsp;Each computer can have only **one** code integrity policy at a time. Whichever way you deploy this policy, it is renamed to SIPolicy.p7b and copied to C:\\Windows\\System32\\CodeIntegrity. Keep this in mind when you create your code integrity policies.
> **Note**&nbsp;&nbsp;Each computer can have only **one** code integrity policy at a time. Whichever way you deploy this policy, it is renamed to SIPolicy.p7b and copied to **C:\\Windows\\System32\\CodeIntegrity** and, for UEFI computers, **&lt;EFI System Partition&gt;\\Microsoft\\Boot**. Keep this in mind when you create your code integrity policies.
Optionally, code integrity policies can align with your software catalog as well as any IT departmentapproved applications. One straightforward method to implement code integrity policies is to use existing images to create one master code integrity policy. You do so by creating a code integrity policy from each image, and then by merging the policies. This way, what is installed on all of those images will be allowed to run, if the applications are installed on a computer based on a different image. Alternatively, you may choose to create a base applications policy and add policies based on the computers role or department. Organizations have a choice of how their policies are created, merged or serviced, and managed.
@ -43,10 +43,12 @@ Code integrity policies include *policy rules*, which control options such as au
To modify the policy rule options of an existing code integrity policy, use the [Set-RuleOption](https://technet.microsoft.com/library/mt634483.aspx) Windows PowerShell cmdlet. Note the following examples of how to use this cmdlet to add and remove a rule option on an existing code integrity policy:
- To enable UMCI, add rule option 0 to an existing policy by running the following command:
- To ensure that UMCI is enabled for a code integrity policy that was created with the `-UserPEs` (user mode) option, add rule option 0 to an existing policy by running the following command:
` Set-RuleOption -FilePath <Path to policy> -Option 0`
Note that a policy that was created without the `-UserPEs` option is empty of user mode executables, that is, applications. If you enable UMCI (Option 0) for such a policy and then attempt to run an application, Device Guard will see that the application is not on its list (which is empty of applications), and respond. In audit mode, the response is logging an event, and in enforced mode, the response is blocking the application. To create a policy that includes user mode executables (applications), when you run `New-CIPolicy`, include the `-UserPEs` option.
- To disable UMCI on an existing code integrity policy, delete rule option 0 by running the following command:
` Set-RuleOption -FilePath <Path to policy> -Option 0 -Delete`

View File

@ -38,11 +38,11 @@ To create a code integrity policy, copy each of the following commands into an e
> **Notes**
> - By specifying the *UserPEs* parameter, rule option **0 Enabled:UMCI** is automatically added to the code integrity policy. If you do not specify this parameter, to enable UMCI, use [Set-RuleOption](https://technet.microsoft.com/library/mt634483.aspx) as shown in the following command:<br>**Set-RuleOption -FilePath $InitialCIPolicy -Option 0**
> - When you specify the **-UserPEs** parameter (to include user mode executables in the scan), rule option **0 Enabled:UMCI** is automatically added to the code integrity policy. In contrast, if you do not specify **-UserPEs**, the policy will be empty of user mode executables and will only have rules for kernel mode binaries like drivers, in other words, the whitelist will not include applications. If you create such a policy and later add rule option **0 Enabled:UMCI**, all attempts to start applications will cause a response from Device Guard. In audit mode, the response is logging an event, and in enforced mode, the response is blocking the application.
> - You can add the **-Fallback** parameter to catch any applications not discovered using the primary file rule level specified by the **-Level** parameter. For more information about file rule level options, see [Code integrity file rule levels](deploy-code-integrity-policies-policy-rules-and-file-rules.md#code-integrity-file-rule-levels) in “Deploy code integrity policies: policy rules and file rules.”
> - You can add the *Fallback* parameter to catch any applications not discovered using the primary file rule level specified by the *Level* parameter. For more information about file rule level options, see [Code integrity file rule levels](deploy-code-integrity-policies-policy-rules-and-file-rules.md#code-integrity-file-rule-levels) in “Deploy code integrity policies: policy rules and file rules.”
> - To specify that the code integrity policy scan only a specific drive, include the *ScanPath* parameter followed by a path. Without this parameter, the entire system is scanned.
> - To specify that the code integrity policy scan only a specific drive, include the **-ScanPath** parameter followed by a path. Without this parameter, the entire system is scanned.
> - The preceding example includes `3> CIPolicylog.txt`, which redirects warning messages to a text file, **CIPolicylog.txt**.

View File

@ -22,9 +22,9 @@ This policy setting determines whether the Lightweight Directory Access Protocol
Unsigned network traffic is susceptible to man-in-the-middle attacks, where an intruder captures packets between the server and the client device and modifies them before forwarding them to the client device. In the case of an LDAP server, this means that a malicious user can cause a client device to make decisions based on false records from the LDAP directory. You can lower the risk of a malicious user accomplishing this in a corporate network by implementing strong physical security measures to protect the network infrastructure. Furthermore, implementing Internet Protocol security (IPsec) Authentication Header mode, which provides mutual authentication and packet integrity for IP traffic, can make all types of man-in-the-middle attacks extremely difficult.
This setting does not have any impact on LDAP simple bind or LDAP simple bind through SSL.
This setting does not have any impact on LDAP simple bind through SSL (LDAP TCP/636).
If signing is required, then LDAP simple bind and LDAP simple bind through SSL requests are rejected.
If signing is required, then LDAP simple binds not using SSL are rejected (LDAP TCP/389).
>**Caution:**  If you set the server to Require signature, you must also set the client device. Not setting the client device results in loss of connection with the server.