deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-12 13:27:23 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merge pull request #6012 from MicrosoftDocs/master

Browse Source 
Publish 11/24/2021, 10:30 AM
This commit is contained in:
Diana Hanson 2021-11-24 11:39:46 -07:00 committed by GitHub
commit 87b4db8cb2
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
21 changed files with 237 additions and 157 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
windows/client-management/mdm/policy-csp-userrights.md
View File

@ -7,7 +7,7 @@ ms.prod: w10
ms.technology: windows
author: manikadhiman
ms.localizationpriority: medium
ms.date: 11/11/2021
ms.date: 11/24/2021
ms.reviewer:
manager: dansimp
---
@ -567,6 +567,14 @@ GP Info:
<!--/Scope-->
<!--Description-->
This user right determines which users and groups can change the time and date on the internal clock of the computer. Users that are assigned this user right can affect the appearance of event logs. If the system time is changed, events that are logged will reflect this new time, not the actual time that the events occurred.
> [!CAUTION]
> Configuring user rights replaces existing users or groups previously assigned those user rights. The system requires that Local Service account (SID S-1-5-19) always has the ChangeSystemTime right. Therefore, Local Service must always be specified in addition to any other accounts being configured in this policy.
>
> Not including the Local Service account will result in failure with the following error:
>
> | Error code | Symbolic name | Error description | Header |
> |----------|----------|----------|----------|
> | 0x80070032 (Hex)|ERROR_NOT_SUPPORTED|The request is not supported.| winerror.h |
<!--/Description-->
<!--DbMapped-->

41
windows/security/threat-protection/auditing/advanced-security-audit-policy-settings.md
View File

@ -18,24 +18,33 @@ ms.date: 09/06/2021
ms.technology: windows-sec
---
# Advanced security audit policy settings
# Advanced security audit policy settings (Windows 10)
This reference for IT professionals provides information about the advanced audit policy settings that are available in Windows and the audit events that they generate.
This reference for IT professionals provides information about:
- The advanced audit policy settings available in Windows
- The audit events that these settings generate.
The security audit policy settings under **Security Settings\\Advanced Audit Policy Configuration** can help your organization audit compliance with important business-related and security-related rules by tracking precisely defined activities, such as:
- A group administrator has modified settings or data on servers that contain finance information.
- An employee within a defined group has accessed an important file.
- The correct system access control list (SACL) is applied to every file and folder or registry key on a computer or file share as a verifiable safeguard against undetected access.
- The correct system access control list (SACL) - as a verifiable safeguard against undetected access - is applied to either of the following:
- every file and folder
- registry key on a computer
- file share.
You can access these audit policy settings through the Local Security Policy snap-in (secpol.msc) on the local computer or by using Group Policy.
These advanced audit policy settings allow you to select only the behaviors that you want to monitor. You can exclude audit results for behaviors that are of little or no concern to you, or behaviors that create an excessive number of log entries. In addition, because security audit policies can be applied by using domain Group Policy Objects, audit policy settings can be modified, tested, and deployed to selected users and groups with relative simplicity.
These advanced audit policy settings allow you to select only the behaviors that you want to monitor. You can exclude audit results for the following types of behaviors:
- That are of little or no concern to you
- That create an excessive number of log entries.
In addition, because security audit policies can be applied by using domain Group Policy Objects, audit policy settings can be modified, tested, and deployed to selected users and groups with relative simplicity.
Audit policy settings under **Security Settings\\Advanced Audit Policy Configuration** are available in the following categories:
## Account Logon
Configuring policy settings in this category can help you document attempts to authenticate account data on a domain controller or on a local Security Accounts Manager (SAM). Unlike Logon and Logoff policy settings and events, which track attempts to access a particular computer, settings and events in this category focus on the account database that is used. This category includes the following subcategories:
Configuring policy settings in this category can help you document attempts to authenticate account data on a domain controller or on a local Security Accounts Manager (SAM). Unlike Logon and Logoff policy settings and events, Account Logon settings and events focus on the account database that is used. This category includes the following subcategories:
- [Audit Credential Validation](audit-credential-validation.md)
- [Audit Kerberos Authentication Service](audit-kerberos-authentication-service.md)
@ -55,7 +64,11 @@ The security audit policy settings in this category can be used to monitor chang
## Detailed Tracking
Detailed Tracking security policy settings and audit events can be used to monitor the activities of individual applications and users on that computer, and to understand how a computer is being used. This category includes the following subcategories:
Detailed Tracking security policy settings and audit events can be used for the following purposes:
- To monitor the activities of individual applications and users on that computer
- To understand how a computer is being used.
This category includes the following subcategories:
- [Audit DPAPI Activity](audit-dpapi-activity.md)
- [Audit PNP activity](audit-pnp-activity.md)
@ -91,7 +104,7 @@ Logon/Logoff security policy settings and audit events allow you to track attemp
## Object Access
Object Access policy settings and audit events allow you to track attempts to access specific objects or types of objects on a network or computer. To audit attempts to access a file, directory, registry key, or any other object, you must enable the appropriate Object Access auditing subcategory for success and/or failure events. For example, the file system subcategory needs to be enabled to audit file operations, and the Registry subcategory needs to be enabled to audit registry accesses.
Object Access policy settings and audit events allow you to track attempts to access specific objects or types of objects on a network or computer. To audit attempts to access a file, directory, registry key, or any other object, enable the appropriate Object Access auditing subcategory for success and/or failure events. For example, the file system subcategory needs to be enabled to audit file operations; the Registry subcategory needs to be enabled to audit registry accesses.
Proving that these audit policies are in effect to an external auditor is more difficult. There is no easy way to verify that the proper SACLs are set on all inherited objects. To address this issue, see [Global Object Access Auditing](#global-object-access-auditing).
@ -114,7 +127,7 @@ This category includes the following subcategories:
## Policy Change
Policy Change audit events allow you to track changes to important security policies on a local system or network. Because policies are typically established by administrators to help secure network resources, monitoring changes or attempts to change these policies can be an important aspect of security management for a network. This category includes the following subcategories:
Policy Change audit events allow you to track changes to important security policies on a local system or network. Because policies are typically established by administrators to help secure network resources, tracking changes (or its attempts) to these policies is an important aspect of security management for a network. This category includes the following subcategories:
- [Audit Audit Policy Change](audit-audit-policy-change.md)
- [Audit Authentication Policy Change](audit-authentication-policy-change.md)
@ -133,7 +146,11 @@ Permissions on a network are granted for users or computers to complete defined
## System
System security policy settings and audit events allow you to track system-level changes to a computer that are not included in other categories and that have potential security implications. This category includes the following subcategories:
System security policy settings and audit events allow you to track the following types of system-level changes to a computer:
- Not included in other categories
- Have potential security implications.
This category includes the following subcategories:
- [Audit IPsec Driver](audit-ipsec-driver.md)
- [Audit Other System Events](audit-other-system-events.md)
@ -144,9 +161,11 @@ System security policy settings and audit events allow you to track system-level
## Global Object Access Auditing
Global Object Access Auditing policy settings allow administrators to define computer system access control lists (SACLs) per object type for the file system or for the registry. The specified SACL is then automatically applied to every object of that type.
Auditors will be able to prove that every resource in the system is protected by an audit policy by viewing the contents of the Global Object Access Auditing policy settings. For example, if auditors see a policy setting called "Track all changes made by group administrators," they know that this policy is in effect.
Auditors can prove that every resource in the system is protected by an audit policy. They can do this task by viewing the contents of the Global Object Access Auditing policy settings. For example, if auditors see a policy setting called "Track all changes made by group administrators," they know that this policy is in effect.
Resource SACLs are also useful for diagnostic scenarios. For example, setting the Global Object Access Auditing policy to log all the activity for a specific user and enabling the policy to track "Access denied" events for the file system or registry can help administrators quickly identify which object in a system is denying a user access.
Resource SACLs are also useful for diagnostic scenarios. For example, administrators quickly identify which object in a system is denying a user access by:
- Setting the Global Object Access Auditing policy to log all the activities for a specific user
- Enabling the policy to track "Access denied" events for the file system or registry can help
> [!NOTE]
> If a file or folder SACL and a Global Object Access Auditing policy setting (or a single registry setting SACL and a Global Object Access Auditing policy setting) are configured on a computer, the effective SACL is derived from combining the file or folder SACL and the Global Object Access Auditing policy. This means that an audit event is generated if an activity matches the file or folder SACL or the Global Object Access Auditing policy.

24
windows/security/threat-protection/auditing/advanced-security-auditing-faq.yml
View File

@ -41,7 +41,7 @@ summary: This topic for the IT professional lists questions and answers about un
- [How can I set an audit policy that affects all objects on a computer?](#how-can-i-set-an-audit-policy-that-affects-all-objects-on-a-computer-)
- [How do I figure out why someone was able to access a resource?](#how-do-i-figure-out-why-someone-was-able-to-access-a-resource-)
- [How do I ascertain the purpose for accessing a resource?](#how-do-i-figure-out-why-someone-was-able-to-access-a-resource-)
- [How do I know when changes are made to access control settings, by whom, and what the changes were?](#how-do-i-know-when-changes-are-made-to-access-control-settings--by-whom--and-what-the-changes-were-)
@ -64,7 +64,7 @@ sections:
- question: |
What is Windows security auditing and why might I want to use it?
answer: |
Security auditing is a methodical examination and review of activities that may affect the security of a system. In the Windows operating systems, security auditing is more narrowly defined as the features and services that enable an administrator to log and review events for specified security-related activities.
Security auditing is a methodical examination and review of activities that may affect the security of a system. In the Windows operating systems, security auditing is the features and services for an administrator to log and review events for specified security-related activities.
Hundreds of events occur as the Windows operating system and the applications that run on it perform their tasks. Monitoring these events can provide valuable information to help administrators troubleshoot and investigate security-related activities.
@ -91,16 +91,16 @@ sections:
> **Important**  Whether you apply advanced audit policies by using Group Policy or by using logon scripts, do not use both the basic audit policy settings under **Local Policies\\Audit Policy** and the advanced settings under **Security Settings\\Advanced Audit Policy Configuration**. Using both advanced and basic audit policy settings can cause unexpected results in audit reporting.
If you use Advanced Audit Policy Configuration settings or use logon scripts to apply advanced audit policies, be sure to enable the **Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings** policy setting under **Local Policies\\Security Options**. This will prevent conflicts between similar settings by forcing basic security auditing to be ignored.
If you use Advanced Audit Policy Configuration settings or use logon scripts to apply advanced audit policies, be sure to enable the **Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings** policy setting under **Local Policies\\Security Options**. This setting prevents conflicts between similar settings by forcing basic security auditing to be ignored.
 
- question: |
How are audit settings merged by Group Policy?
answer: |
By default, policy options that are set in GPOs and linked to higher levels of Active Directory sites, domains, and OUs are inherited by all OUs at lower levels. However, an inherited policy can be overridden by a GPO that is linked at a lower level.
For example, you might use a domain GPO to assign an organization-wide group of audit settings, but want a certain OU to get a defined group of additional settings. To accomplish this, you can link a second GPO to that specific lower-level OU. Therefore, a logon audit setting that is applied at the OU level will override a conflicting logon audit setting that is applied at the domain level (unless you have taken special steps to apply Group Policy loopback processing).
For example, you might use a domain GPO to assign an organization-wide group of audit settings, but want a certain OU to get a defined group of extra settings. To accomplish this customization, you can link a second GPO to that specific lower-level OU. Therefore, a logon audit setting that is applied at the OU level will override a conflicting logon audit setting that is applied at the domain level (unless you have taken special steps to apply Group Policy loopback processing).
The rules that govern how Group Policy settings are applied propagate to the subcategory level of audit policy settings. This means that audit policy settings configured in different GPOs will be merged if no policy settings configured at a lower level exist. The following table illustrates this behavior.
The rules that govern how Group Policy settings are applied propagate to the subcategory level of audit policy settings. This coverage means that audit policy settings configured in different GPOs will be merged if no policy settings configured at a lower level exist. The following table illustrates this behavior.
| Auditing subcategory | Setting configured in an OU GPO (higher priority) | Setting configured in a domain GPO (lower priority) | Resulting policy for the target computer |
@ -119,7 +119,7 @@ sections:
The access control model that is used in Windows is administered at the object level by setting different levels of access, or permissions, to objects. If permissions are configured for an object, its security descriptor contains a DACL with security identifiers (SIDs) for the users and groups that are allowed or denied access.
If auditing is configured for the object, its security descriptor also contains a SACL that controls how the security subsystem audits attempts to access the object. However, auditing is not completely configured unless a SACL has been configured for an object and a corresponding **Object Access** audit policy setting has been configured and applied.
If auditing is configured for the object, its security descriptor also contains a SACL that controls how the security subsystem audits attempts to access the object. However, auditing is not configured entirely unless a SACL has been configured for an object and a corresponding **Object Access** audit policy setting has been configured and applied.
- question: |
Why are audit policies applied on a per-computer basis rather than per user?
@ -128,7 +128,7 @@ sections:
In addition, because audit policy capabilities can vary between computers running different versions of Windows, the best way to ensure that the audit policy is applied correctly is to base these settings on the computer instead of the user.
However, in cases where you want audit settings to apply only to specified groups of users, you can accomplish this by configuring SACLs on the relevant objects to enable auditing for a security group that contains only the users you specify. For example, you can configure a SACL for a folder called Payroll Data on Accounting Server 1. This can audit attempts by members of the Payroll Processors OU to delete objects from this folder. The **Object Access\\Audit File System** audit policy setting applies to Accounting Server 1, but because it requires a corresponding resource SACL, only actions by members of the Payroll Processors OU on the Payroll Data folder generates audit events.
However, when you want audit settings to apply only to specified groups of users, you can accomplish this customization by configuring SACLs on the relevant objects to enable auditing for a security group that contains only the users you specify. For example, you can configure a SACL for a folder called Payroll Data on Accounting Server 1. This configuration results in an audit of attempts by members of the Payroll Processors OU to delete objects from this folder. The **Object Access\\Audit File System** audit policy setting applies to Accounting Server 1, but because it requires a corresponding resource SACL, only actions by members of the Payroll Processors OU on the Payroll Data folder generates audit events.
- question: |
What are the differences in auditing functionality between versions of Windows?
@ -147,13 +147,13 @@ sections:
A failure audit event is triggered when a defined action, such as a user logon, is not completed successfully.
The appearance of failure audit events in the event log does not necessarily mean that something is wrong with your system. For example, if you configure Audit Logon events, a failure event may simply mean that a user mistyped his or her password.
The appearance of failure audit events in the event log does not necessarily mean that something is wrong with your system. For example, if you configure Audit Logon events, a failure event may mean that a user mistyped the password.
- question: |
How can I set an audit policy that affects all objects on a computer?
answer: |
System administrators and auditors increasingly want to verify that an auditing policy is applied to all objects on a system. This has been difficult to accomplish because the system access control lists (SACLs) that govern auditing are applied on a per-object basis. Thus, to verify that an audit policy has been applied to all objects, you would have to check every object to be sure that no changes have been made—even temporarily to a single SACL.
Introduced in Windows Server 2008 R2 and Windows 7, security auditing allows administrators to define global object access auditing policies for the entire file system or for the registry on a computer. The specified SACL is then automatically applied to every object of that type. This can be useful for verifying that all critical files, folders, and registry settings on a computer are protected, and for identifying when an issue with a system resource occurs. If a file or folder SACL and a global object access auditing policy (or a single registry setting SACL and a global object access auditing policy) are configured on a computer, the effective SACL is derived from combining the file or folder SACL and the global object access auditing policy. This means that an audit event is generated if an activity matches either the file or folder SACL or the global object access auditing policy.
System administrators and auditors increasingly want to verify that an auditing policy is applied to all objects on a system. This requirement has been difficult to accomplish because the system access control lists (SACLs) that govern auditing are applied on a per-object basis. Thus, to verify that an audit policy has been applied to all objects, you would have to check every object to be sure that no changes have been made—even temporarily to a single SACL.
Introduced in Windows Server 2008 R2 and Windows 7, security auditing allows administrators to define global object access auditing policies for the entire file system or for the registry on a computer. The specified SACL is then automatically applied to every object of that type. This application of SACL can be useful for verifying that all critical files, folders, and registry settings on a computer are protected, and for identifying when an issue with a system resource occurs. If a file or folder SACL and a global object access auditing policy (or a single registry setting SACL and a global object access auditing policy) are configured on a computer, the effective SACL is derived from combining the file or folder SACL and the global object access auditing policy. This resultant SACL from the combination means that an audit event is generated if an activity matches either the file or folder SACL or the global object access auditing policy.
- question: |
How do I figure out why someone was able to access a resource?
@ -173,7 +173,7 @@ sections:
- question: |
How can I roll back security audit policies from the advanced audit policy to the basic audit policy?
answer: |
Applying advanced audit policy settings replaces any comparable basic security audit policy settings. If you subsequently change the advanced audit policy setting to **Not configured**, you need to complete the following steps to restore the original basic security audit policy settings:
Applying advanced audit policy settings replaces any comparable basic security audit policy settings. If you later change the advanced audit policy setting to **Not configured**, you need to complete the following steps to restore the original basic security audit policy settings:
1. Set all Advanced Audit Policy subcategories to **Not configured**.
2. Delete all audit.csv files from the %SYSVOL% folder on the domain controller.
@ -203,7 +203,7 @@ sections:
What are the best tools to model and manage audit policies?
answer: |
The integration of advanced audit policy settings with domain Group Policy, introduced in Windows 7 and Windows Server 2008 R2, is designed to simplify the management and implementation of security audit policies in an organization's network. As such, tools used to plan and deploy Group Policy Objects for a domain can also be used to plan and deploy security audit policies.
On an individual computer, the Auditpol command-line tool can be used to complete a number of important audit policy–related management tasks.
On an individual computer, the Auditpol command-line tool can be used to complete many important audit policy–related management tasks.
In addition, there are a number of computer management products, such as the Audit Collection Services in the Microsoft System Center Operations Manager products, which can be used to collect and filter event data.

2
windows/security/threat-protection/auditing/appendix-a-security-monitoring-recommendations-for-many-audit-events.md
View File

@ -24,7 +24,7 @@ This document, the [Advanced security audit policy settings](advanced-security-a
| **High-value accounts**: You might have high-value domain or local accounts for which you need to monitor each action.<br>Examples of high-value accounts are database administrators, built-in local administrator account, domain administrators, service accounts, domain controller accounts and so on. | Monitor relevant events for the **“Subject\\Security ID”** that corresponds to the high-value account or accounts. |
| **Anomalies or malicious actions**: You might have specific requirements for detecting anomalies or monitoring potential malicious actions. For example, you might need to monitor for use of an account outside of working hours. | When you monitor for anomalies or malicious actions, use the **“Subject\\Security ID”** (with other information) to monitor how or when a particular account is being used. |
| **Non-active accounts**: You might have non-active, disabled, or guest accounts, or other accounts that should never be used. | Monitor relevant events for the **“Subject\\Security ID”** that corresponds to the accounts that should never be used. |
| **Account allow list**: You might have a specific allow list of accounts that are the only ones allowed to perform actions corresponding to particular events. | Monitor the relevant events for **“Subject\\Security ID”** accounts that are outside the allow list of accounts. |
| **Account allowlist**: You might have a specific allowlist of accounts that are the only ones allowed to perform actions corresponding to particular events. | Monitor the relevant events for **“Subject\\Security ID”** accounts that are outside the allowlist of accounts. |
| **Accounts of different types**: You might want to ensure that certain actions are performed only by certain account types, for example, local or domain account, machine or user account, vendor or employee account, and so on. | Identify events that correspond to the actions you want to monitor, and for those events, review the **“Subject\\Security ID”** to see whether the account type is as expected. |
| **External accounts**: You might be monitoring accounts from another domain, or “external” accounts that are not allowed to perform certain actions (represented by certain specific events). | Monitor the specific events for the **“Subject\\Account Domain”** corresponding to accounts from another domain or “external” accounts. |
| **Restricted-use computers or devices**: You might have certain computers, machines, or devices on which certain people (accounts) should not typically perform any actions. | Monitor the target **Computer:** (or other target device) for actions performed by the **“Subject\\Security ID”** that you are concerned about. |

8
windows/security/threat-protection/auditing/apply-a-basic-audit-policy-on-a-file-or-folder.md
View File

@ -29,7 +29,7 @@ To complete this procedure, you must be signed in as a member of the built-in Ad
1. Select and hold (or right-click) the file or folder that you want to audit, select **Properties**, and then select the **Security** tab.
2. Select **Advanced**.
3. In the **Advanced Security Settings** dialog box, select the **Auditing** tab, and then select **Continue**.
4. Do one of the following:
4. Do one of the following tasks:
- To set up auditing for a new user or group, select **Add**. Select **Select a principal**, type the name of the user or group that you want, and then select **OK**.
- To remove auditing for an existing group or user, select the group or user name, select **Remove**, select **OK**, and then skip the rest of this procedure.
- To view or change auditing for an existing group or user, select its name, and then select **Edit.**
@ -40,7 +40,7 @@ To complete this procedure, you must be signed in as a member of the built-in Ad
6. In the **Applies to** box, select the object(s) to which the audit of events will apply. These include:
6. In the **Applies to** box, select the object(s) to which the audit of events will apply. These objects include:
- **This folder only**
- **This folder, subfolders and files**
@ -62,9 +62,9 @@ To complete this procedure, you must be signed in as a member of the built-in Ad
> [!IMPORTANT]
> Before you set up auditing for files and folders, you must enable [object access auditing](basic-audit-object-access.md). To do this, define auditing policy settings for the object access event category. If you don't enable object access auditing, you'll receive an error message when you set up auditing for files and folders, and no files or folders will be audited.
 
## Additional considerations
## More considerations
- After you turn on object access auditing, view the security log in Event Viewer to review the results of your changes.
- After you turn on object access auditing, view the security login Event Viewer to review the results of your changes.
- You can set up file and folder auditing only on NTFS drives.
- Because the security log is limited in size, carefully select the files and folders to be audited. Also, consider the amount of disk space that you want to devote to the security log. The maximum size for the security log is defined in Event Viewer.
 

6
windows/security/threat-protection/auditing/audit-account-lockout.md
View File

@ -29,9 +29,9 @@ This subcategory failure logon attempts, when account was already locked out.
| Computer Type | General Success | General Failure | Stronger Success | Stronger Failure | Comments |
|-------------------|-----------------|-----------------|------------------|------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Domain Controller | No | Yes | No | Yes | We recommend tracking account lockouts, especially for high value domain or local accounts (database administrators, built-in local administrator account, domain administrators, service accounts, domain controller accounts, and so on).<br>This subcategory doesn’t have Success events, so there is no recommendation to enable Success auditing for this subcategory. |
| Member Server | No | Yes | No | Yes | We recommend tracking account lockouts, especially for high value domain or local accounts (database administrators, built-in local administrator account, domain administrators, service accounts, domain controller accounts, and so on).<br>This subcategory doesn’t have Success events, so there is no recommendation to enable Success auditing for this subcategory. |
| Workstation | No | Yes | No | Yes | We recommend tracking account lockouts, especially for high value domain or local accounts (database administrators, built-in local administrator account, domain administrators, service accounts, domain controller accounts, and so on).<br>This subcategory doesn’t have Success events, so there is no recommendation to enable Success auditing for this subcategory. |
| Domain Controller | No | Yes | No | Yes | We recommend tracking account lockouts, especially for high value domain or for local accounts (database administrators, built-in local administrator account, domain administrators, service accounts, domain controller accounts, and so on).<br>This subcategory doesn’t have Success events, so there is no recommendation to enable Success auditing for this subcategory. |
| Member Server | No | Yes | No | Yes | We recommend tracking account lockouts, especially for high value domain or for local accounts (database administrators, built-in local administrator account, domain administrators, service accounts, domain controller accounts, and so on).<br>This subcategory doesn’t have Success events, so there is no recommendation to enable Success auditing for this subcategory. |
| Workstation | No | Yes | No | Yes | We recommend tracking account lockouts, especially for high value domain or for local accounts (database administrators, built-in local administrator account, domain administrators, service accounts, domain controller accounts, and so on).<br>This subcategory doesn’t have Success events, so there is no recommendation to enable Success auditing for this subcategory. |
**Events List:**

2
windows/security/threat-protection/get-support-for-security-baselines.md
View File

@ -16,7 +16,7 @@ ms.reviewer:
ms.technology: windows-sec
---
# Get Support
# Get Support for Windows baselines
**What is the Microsoft Security Compliance Manager (SCM)?**

74
windows/security/threat-protection/overview-of-threat-mitigations-in-windows-10.md
View File

@ -59,26 +59,26 @@ Windows 10 mitigations that you can configure are listed in the following two ta
|---|---|
| **Windows Defender SmartScreen**<br> helps prevent<br>malicious applications<br>from being downloaded | Windows Defender SmartScreen can check the reputation of a downloaded application by using a service that Microsoft maintains. The first time a user runs an app that originates from the Internet (even if the user copied it from another PC), SmartScreen checks to see if the app lacks a reputation or is known to be malicious, and responds accordingly.<br><br>**More information**: [Windows Defender SmartScreen](#windows-defender-smartscreen), later in this topic |
| **Credential Guard**<br> helps keep attackers<br>from gaining access through<br>Pass-the-Hash or<br>Pass-the-Ticket attacks | Credential Guard uses virtualization-based security to isolate secrets, such as NTLM password hashes and Kerberos Ticket Granting Tickets, so that only privileged system software can access them.<br>Credential Guard is included in Windows 10 Enterprise and Windows Server 2016.<br><br>**More information**: [Protect derived domain credentials with Credential Guard](/windows/access-protection/credential-guard/credential-guard) |
| **Enterprise certificate pinning**<br> helps prevent <br>man-in-the-middle attacks<br>that leverage PKI | Enterprise certificate pinning enables you to protect your internal domain names from chaining to unwanted certificates or to fraudulently issued certificates. With enterprise certificate pinning, you can "pin" (associate) an X.509 certificate and its public key to its Certification Authority, either root or leaf. <br><br>**More information**: [Enterprise Certificate Pinning](/windows/access-protection/enterprise-certificate-pinning) |
| **Device Guard**<br> helps keep a device<br>from running malware or<br>other untrusted apps | Device Guard includes a Code Integrity policy that you create; an allowlist of trusted apps—the only apps allowed to run in your organization. Device Guard also includes a powerful system mitigation called hypervisor-protected code integrity (HVCI), which leverages virtualization-based security (VBS) to protect Windows' kernel-mode code integrity validation process. HVCI has specific hardware requirements, and works with Code Integrity policies to help stop attacks even if they gain access to the kernel.<br>Device Guard is included in Windows 10 Enterprise and Windows Server 2016.<br><br>**More information**: [Introduction to Device Guard](/windows/device-security/device-guard/introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies) |
| **Microsoft Defender Antivirus**,<br>which helps keep devices<br>free of viruses and other<br>malware | Windows 10 includes Microsoft Defender Antivirus, a robust inbox antimalware solution. Microsoft Defender Antivirus has been significantly improved since it was introduced in Windows 8.<br><br>**More information**: [Microsoft Defender Antivirus](#microsoft-defender-antivirus), later in this topic |
| **Enterprise certificate pinning**<br> helps prevent <br>man-in-the-middle attacks<br>that use PKI | Enterprise certificate pinning enables you to protect your internal domain names from chaining to unwanted certificates or to fraudulently issued certificates. With enterprise certificate pinning, you can "pin" (associate) an X.509 certificate and its public key to its Certification Authority, either root or leaf. <br><br>**More information**: [Enterprise Certificate Pinning](/windows/access-protection/enterprise-certificate-pinning) |
| **Device Guard**<br> helps keep a device<br>from running malware or<br>other untrusted apps | Device Guard includes a Code Integrity policy that you create; an allowlist of trusted apps—the only apps allowed to run in your organization. Device Guard also includes a powerful system mitigation called hypervisor-protected code integrity (HVCI), which uses virtualization-based security (VBS) to protect Windows' kernel-mode code integrity validation process. HVCI has specific hardware requirements, and works with Code Integrity policies to help stop attacks even if they gain access to the kernel.<br>Device Guard is included in Windows 10 Enterprise and Windows Server 2016.<br><br>**More information**: [Introduction to Device Guard](/windows/device-security/device-guard/introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies) |
| **Microsoft Defender Antivirus**,<br>which helps keep devices<br>free of viruses and other<br>malware | Windows 10 includes Microsoft Defender Antivirus, a robust inbox anti-malware solution. Microsoft Defender Antivirus has been improved to a considerable extent since it was introduced in Windows 8.<br><br>**More information**: [Microsoft Defender Antivirus](#microsoft-defender-antivirus), later in this topic |
| **Blocking of untrusted fonts**<br> helps prevent fonts<br>from being used in<br>elevation-of-privilege attacks | Block Untrusted Fonts is a setting that allows you to prevent users from loading fonts that are "untrusted" onto your network, which can mitigate elevation-of-privilege attacks associated with the parsing of font files. However, as of Windows 10, version 1703, this mitigation is less important, because font parsing is isolated in an [AppContainer sandbox](/windows/win32/secauthz/appcontainer-isolation) (for a list describing this and other kernel pool protections, see [Kernel pool protections](#kernel-pool-protections), later in this topic).<br><br>**More information**: [Block untrusted fonts in an enterprise](/windows/threat-protection/block-untrusted-fonts-in-enterprise) |
| **Memory protections**<br> help prevent malware<br>from using memory manipulation<br>techniques such as buffer<br>overruns | These mitigations, listed in [Table 2](#table-2), help to protect against memory-based attacks, where malware or other code manipulates memory to gain control of a system (for example, malware that attempts to use buffer overruns to inject malicious executable code into memory. Note:<br>A subset of apps will not be able to run if some of these mitigations are set to their most restrictive settings. Testing can help you maximize protection while still allowing these apps to run.<br><br>**More information**: [Table 2](#table-2), later in this topic |
| **UEFI Secure Boot**<br> helps protect<br>the platform from<br>boot kits and rootkits | Unified Extensible Firmware Interface (UEFI) Secure Boot is a security standard for firmware built in to PCs by manufacturers beginning with Windows 8. It helps to protect the boot process and firmware against tampering, such as from a physically present attacker or from forms of malware that run early in the boot process or in kernel after startup.<br><br>**More information**: [UEFI and Secure Boot](/windows/device-security/bitlocker/bitlocker-countermeasures#uefi-and-secure-boot)</a> |
| **Early Launch Antimalware (ELAM)**<br> helps protect<br>the platform from<br>rootkits disguised as drivers | Early Launch Antimalware (ELAM) is designed to enable the antimalware solution to start before all non-Microsoft drivers and apps. 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.<br><br>**More information**: [Early Launch Antimalware](/windows/device-security/bitlocker/bitlocker-countermeasures#protection-during-startup) |
| **Early Launch Antimalware (ELAM)**<br> helps protect<br>the platform from<br>rootkits disguised as drivers | Early Launch Antimalware (ELAM) is designed to enable the anti-malware solution to start before all non-Microsoft drivers and apps. 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.<br><br>**More information**: [Early Launch Antimalware](/windows/device-security/bitlocker/bitlocker-countermeasures#protection-during-startup) |
| **Device Health Attestation**<br> helps prevent<br>compromised devices from<br>accessing an organization's<br>assets | Device Health Attestation (DHA) provides a way to confirm that devices attempting to connect to an organization's network are in a healthy state, not compromised with malware. When DHA has been configured, a device's actual boot data measurements can be checked against the expected "healthy" boot data. If the check indicates a device is unhealthy, the device can be prevented from accessing the network.<br><br>**More information**: [Control the health of Windows 10-based devices](/windows/device-security/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices) and [Device Health Attestation](/windows-server/security/device-health-attestation) |
Configurable Windows 10 mitigations designed to help protect against memory manipulation require in-depth understanding of these threats and mitigations and knowledge about how the operating system and applications handle memory. The standard process for maximizing these types of mitigations is to work in a test lab to discover whether a given setting interferes with any applications that you use so that you can deploy settings that maximize protection while still allowing apps to run correctly.
As an IT professional, you can ask application developers and software vendors to deliver applications that include an additional protection called Control Flow Guard (CFG). No configuration is needed in the operating system—the protection is compiled into applications. More information can be found in [Control Flow Guard](#control-flow-guard).
As an IT professional, you can ask application developers and software vendors to deliver applications that include an extra protection called Control Flow Guard (CFG). No configuration is needed in the operating system—the protection is compiled into applications. More information can be found in [Control Flow Guard](#control-flow-guard).
### <span id="table-2" class="anchor"></span>Table 2&nbsp;&nbsp;Configurable Windows 10 mitigations designed to help protect against memory exploits
| Mitigation and corresponding threat | Description |
|---|---|
| **Data Execution Prevention (DEP)**<br> helps prevent<br>exploitation of buffer overruns | **Data Execution Prevention (DEP)** is a system-level memory protection feature available in Windows operating systems. DEP enables the operating system to mark one or more pages of memory as non-executable, which prevents code from being run from that region of memory, to help prevent exploitation of buffer overruns.<br>DEP helps prevent code from being run from data pages such as the default heap, stacks, and memory pools. Although some applications have compatibility problems with DEP, the vast majority of applications do not.<br>**More information**: [Data Execution Prevention](#data-execution-prevention), later in this topic.<br><br>**Group Policy settings**: DEP is on by default for 64-bit applications, but you can configure additional DEP protections by using the Group Policy settings described in [Override Process Mitigation Options to help enforce app-related security policies](override-mitigation-options-for-app-related-security-policies.md). |
| **SEHOP**<br> helps prevent<br>overwrites of the<br>Structured Exception Handler | **Structured Exception Handling Overwrite Protection (SEHOP)** is designed to help block exploits that use the Structured Exception Handler (SEH) overwrite technique. Because this protection mechanism is provided at run-time, it helps to protect apps regardless of whether they have been compiled with the latest improvements. A few applications have compatibility problems with SEHOP, so be sure to test for your environment.<br>**More information**: [Structured Exception Handling Overwrite Protection](#structured-exception-handling-overwrite-protection), later in this topic.<br><br>**Group Policy setting**: SEHOP is on by default for 64-bit applications, but you can configure additional SEHOP protections by using the Group Policy setting described in [Override Process Mitigation Options to help enforce app-related security policies](override-mitigation-options-for-app-related-security-policies.md). |
| **ASLR**<br> helps mitigate malware<br>attacks based on<br>expected memory locations | **Address Space Layout Randomization (ASLR)** loads DLLs into random memory addresses at boot time. This helps mitigate malware that's designed to attack specific memory locations, where specific DLLs are expected to be loaded.<br>**More information**: [Address Space Layout Randomization](#address-space-layout-randomization), later in this topic.<br><br>**Group Policy settings**: ASLR is on by default for 64-bit applications, but you can configure additional ASLR protections by using the Group Policy settings described in [Override Process Mitigation Options to help enforce app-related security policies](override-mitigation-options-for-app-related-security-policies.md). |
| **Data Execution Prevention (DEP)**<br> helps prevent<br>exploitation of buffer overruns | **Data Execution Prevention (DEP)** is a system-level memory protection feature available in Windows operating systems. DEP enables the operating system to mark one or more pages of memory as non-executable, which prevents code from being run from that region of memory, to help prevent exploitation of buffer overruns.<br>DEP helps prevent code from being run from data pages such as the default heap, stacks, and memory pools. Although some applications have compatibility problems with DEP, most applications do not.<br>**More information**: [Data Execution Prevention](#data-execution-prevention), later in this topic.<br><br>**Group Policy settings**: DEP is on by default for 64-bit applications, but you can configure more DEP protections by using the Group Policy settings described in [Override Process Mitigation Options to help enforce app-related security policies](override-mitigation-options-for-app-related-security-policies.md). |
| **SEHOP**<br> helps prevent<br>overwrites of the<br>Structured Exception Handler | **Structured Exception Handling Overwrite Protection (SEHOP)** is designed to help block exploits that use the Structured Exception Handler (SEH) overwrite technique. Because this protection mechanism is provided at run-time, it helps to protect apps regardless of whether they have been compiled with the latest improvements. A few applications have compatibility problems with SEHOP, so be sure to test for your environment.<br>**More information**: [Structured Exception Handling Overwrite Protection](#structured-exception-handling-overwrite-protection), later in this topic.<br><br>**Group Policy setting**: SEHOP is on by default for 64-bit applications, but you can configure more SEHOP protections by using the Group Policy setting described in [Override Process Mitigation Options to help enforce app-related security policies](override-mitigation-options-for-app-related-security-policies.md). |
| **ASLR**<br> helps mitigate malware<br>attacks based on<br>expected memory locations | **Address Space Layout Randomization (ASLR)** loads DLLs into random memory addresses at boot time. This loading - of specific DLLs -helps mitigate malware that's designed to attack specific memory locations.<br>**More information**: [Address Space Layout Randomization](#address-space-layout-randomization), later in this topic.<br><br>**Group Policy settings**: ASLR is on by default for 64-bit applications, but you can configure more ASLR protections by using the Group Policy settings described in [Override Process Mitigation Options to help enforce app-related security policies](override-mitigation-options-for-app-related-security-policies.md). |
### Windows Defender SmartScreen
@ -90,17 +90,17 @@ For more information, see [Microsoft Defender SmartScreen overview](microsoft-de
### Microsoft Defender Antivirus
Microsoft Defender Antivirus in Windows 10 uses a multi-pronged approach to improve antimalware:
Microsoft Defender Antivirus in Windows 10 uses a multi-pronged approach to improve anti-malware:
- **Cloud-delivered protection** helps detect and block new malware within seconds, even if the malware has never been seen before. The service, available as of Windows 10, version 1703, uses distributed resources and machine learning to deliver protection to endpoints at a rate that is far faster than traditional signature updates.
- **Rich local context** improves how malware is identified. Windows 10 informs Microsoft Defender Antivirus not only about content like files and processes but also where the content came from, where it has been stored, and more. The information about source and history enables Microsoft Defender Antivirus to apply different levels of scrutiny to different content.
- **Extensive global sensors** help keep Microsoft Defender Antivirus current and aware of even the newest malware. This is accomplished in two ways: by collecting the rich local context data from end points and by centrally analyzing that data.
- **Extensive global sensors** help keep Microsoft Defender Antivirus current and aware of even the newest malware. This up-to-date status is accomplished in two ways: by collecting the rich local context data from end points and by centrally analyzing that data.
- **Tamper proofing** helps guard Microsoft Defender Antivirus itself against malware attacks. For example, Microsoft Defender Antivirus uses Protected Processes, which prevents untrusted processes from attempting to tamper with Microsoft Defender Antivirus components, its registry keys, and so on. ([Protected Processes](#protected-processes) is described later in this topic.)
- **Enterprise-level features** give IT pros the tools and configuration options necessary to make Microsoft Defender Antivirus an enterprise-class antimalware solution.
- **Enterprise-level features** give IT pros the tools and configuration options necessary to make Microsoft Defender Antivirus an enterprise-class anti-malware solution.
<!-- Watch the link text for the following links - try to keep it in sync with the actual topic. -->
@ -112,7 +112,7 @@ For information about Microsoft Defender for Endpoint, a service that helps ente
Malware depends on its ability to insert a malicious payload into memory with the hope that it will be executed later. Wouldn't it be great if you could prevent malware from running if it wrote to an area that has been allocated solely for the storage of information?
Data Execution Prevention (DEP) does exactly that, by substantially reducing the range of memory that malicious code can use for its benefit. DEP uses the No eXecute bit on modern CPUs to mark blocks of memory as read-only so that those blocks can't be used to execute malicious code that may be inserted by means of a vulnerability exploit.
Data Execution Prevention (DEP) does exactly that, by substantially reducing the range of memory that malicious code can use for its benefit. DEP uses the No eXecute bit on modern CPUs to mark blocks of memory as read-only so that those blocks can't be used to execute malicious code that may be inserted through a vulnerability exploit.
**To use Task Manager to see apps that use DEP**
@ -164,7 +164,7 @@ You can use the Group Policy setting called **Process Mitigation Options** to co
### Address Space Layout Randomization
One of the most common techniques used to gain access to a system is to find a vulnerability in a privileged process that is already running, guess or find a location in memory where important system code and data have been placed, and then overwrite that information with a malicious payload. Any malware that could write directly to the system memory could simply overwrite it in well-known and predictable locations.
One of the most common techniques used to gain access to a system is to find a vulnerability in a privileged process that is already running, guess or find a location in memory where important system code and data have been placed, and then overwrite that information with a malicious payload. Any malware that could write directly to the system memory could overwrite it in well-known and predictable locations.
Address Space Layout Randomization (ASLR) makes that type of attack much more difficult because it randomizes how and where important data is stored in memory. With ASLR, it is more difficult for malware to find the specific location it needs to attack. Figure 3 illustrates how ASLR works by showing how the locations of different critical Windows components can change in memory between restarts.
@ -180,23 +180,23 @@ You can use the Group Policy setting called **Process Mitigation Options** to co
Windows 10 provides many threat mitigations to protect against exploits that are built into the operating system and need no configuration within the operating system. The table that follows describes some of these mitigations.
Control Flow Guard (CFG) is a mitigation that does not need configuration within the operating system, but does require that an application developer configure the mitigation into the application when it's compiled. CFG is built into Microsoft Edge, IE11, and other areas in Windows 10, and can be built into many other applications when they are compiled.
Control Flow Guard (CFG) is a mitigation that does not need configuration within the operating system, but does require an application developer to configure the mitigation into the application when it's compiled. CFG is built into Microsoft Edge, IE11, and other areas in Windows 10, and can be built into many other applications when they are compiled.
### Table 3   Windows 10 mitigations to protect against memory exploits – no configuration needed
| Mitigation and corresponding threat | Description |
|---|---|
| **SMB hardening for SYSVOL and NETLOGON shares**<br>helps mitigate<br>man-in-the-middle attacks | Client connections to the Active Directory Domain Services default SYSVOL and NETLOGON shares on domain controllers now require SMB signing and mutual authentication (such as Kerberos).<br><br>**More information**: [SMB hardening improvements for SYSVOL and NETLOGON shares](#smb-hardening-improvements-for-sysvol-and-netlogon-shares), later in this topic. |
| **Protected Processes**<br>help prevent one process<br>from tampering with another<br>process | With the Protected Processes feature, Windows 10 prevents untrusted processes from interacting or tampering with those that have been specially signed.<br><br>**More information**: [Protected Processes](#protected-processes), later in this topic. |
| **Protected Processes**<br>help prevent one process<br>from tampering with another<br>process | With the Protected Processes feature, Windows 10 prevents untrusted processes from interacting or tampering with those processes that have been specially signed.<br><br>**More information**: [Protected Processes](#protected-processes), later in this topic. |
| **Universal Windows apps protections**<br>screen downloadable<br>apps and run them in<br>an AppContainer sandbox | Universal Windows apps are carefully screened before being made available, and they run in an AppContainer sandbox with limited privileges and capabilities.<br><br>**More information**: [Universal Windows apps protections](#universal-windows-apps-protections), later in this topic. |
| **Heap protections**<br>help prevent<br>exploitation of the heap | Windows 10 includes protections for the heap, such as the use of internal data structures which help protect against corruption of memory used by the heap.<br><br>**More information**: [Windows heap protections](#windows-heap-protections), later in this topic. |
| **Heap protections**<br>help prevent<br>exploitation of the heap | Windows 10 includes protections for the heap, such as the use of internal data structures that help protect against corruption of memory used by the heap.<br><br>**More information**: [Windows heap protections](#windows-heap-protections), later in this topic. |
| **Kernel pool protections**<br>help prevent<br>exploitation of pool memory<br>used by the kernel | Windows 10 includes protections for the pool of memory used by the kernel. For example, safe unlinking protects against pool overruns that are combined with unlinking operations that can be used to create an attack.<br><br>**More information**: [Kernel pool protections](#kernel-pool-protections), later in this topic. |
| **Control Flow Guard**<br>helps mitigate exploits<br>that are based on<br>flow between code locations<br>in memory | Control Flow Guard (CFG) is a mitigation that requires no configuration within the operating system, but instead is built into software when it's compiled. It is built into Microsoft Edge, IE11, and other areas in Windows 10. CFG can be built into applications written in C or C++, or applications compiled using Visual Studio 2015.<br>For such an application, CFG can detect an attacker's attempt to change the intended flow of code. If this occurs, CFG terminates the application. You can request software vendors to deliver Windows applications compiled with CFG enabled.<br><br>**More information**: [Control Flow Guard](#control-flow-guard), later in this topic. |
| **Control Flow Guard**<br>helps mitigate exploits<br>based on<br>flow between code locations<br>in memory | Control Flow Guard (CFG) is a mitigation that requires no configuration within the operating system, but instead is built into software when it's compiled. It is built into Microsoft Edge, IE11, and other areas in Windows 10. CFG can be built into applications written in C or C++, or applications compiled using Visual Studio 2015.<br>For such an application, CFG can detect an attacker's attempt to change the intended flow of code. If this attempt occurs, CFG terminates the application. You can request software vendors to deliver Windows applications compiled with CFG enabled.<br><br>**More information**: [Control Flow Guard](#control-flow-guard), later in this topic. |
| **Protections built into Microsoft Edge** (the browser)<br>helps mitigate multiple<br>threats | Windows 10 includes an entirely new browser, Microsoft Edge, designed with multiple security improvements.<br><br>**More information**: [Microsoft Edge and Internet Explorer 11](#microsoft-edge-and-internet-explorer11), later in this topic. |
### SMB hardening improvements for SYSVOL and NETLOGON shares
In Windows 10 and Windows Server 2016, client connections to the Active Directory Domain Services default SYSVOL and NETLOGON shares on domain controllers require Server Message Block (SMB) signing and mutual authentication (such as Kerberos). This reduces the likelihood of man-in-the-middle attacks. If SMB signing and mutual authentication are unavailable, a computer running Windows 10 or Windows Server 2016 won't process domain-based Group Policy and scripts.
In Windows 10 and Windows Server 2016, client connections to the Active Directory Domain Services default SYSVOL and NETLOGON shares on domain controllers require Server Message Block (SMB) signing and mutual authentication (such as Kerberos). This requirement reduces the likelihood of man-in-the-middle attacks. If SMB signing and mutual authentication are unavailable, a computer running Windows 10 or Windows Server 2016 won't process domain-based Group Policy and scripts.
> [!NOTE]
> The registry values for these settings aren't present by default, but the hardening rules still apply until overridden by Group Policy or other registry values. For more information on these security improvements, (also referred to as UNC hardening), see [Microsoft Knowledge Base article 3000483](https://support.microsoft.com/help/3000483/ms15-011-vulnerability-in-group-policy-could-allow-remote-code-execution-february-10,-2015) and [MS15-011 & MS15-014: Hardening Group Policy](https://msrc-blog.microsoft.com/2015/02/10/ms15-011-ms15-014-hardening-group-policy/).
@ -205,7 +205,7 @@ In Windows 10 and Windows Server 2016, client connections to the Active Director
Most security controls are designed to prevent the initial infection point. However, despite all the best preventative controls, malware might eventually find a way to infect the system. So, some protections are built to place limits on malware that gets on the device. Protected Processes creates limits of this type.
With Protected Processes, Windows 10 prevents untrusted processes from interacting or tampering with those that have been specially signed. Protected Processes defines levels of trust for processes. Less trusted processes are prevented from interacting with and therefore attacking more trusted processes. Windows 10 uses Protected Processes more broadly across the operating system, and as in Windows 8.1, implements them in a way that can be used by 3rd party anti-malware vendors, as described in [Protecting Anti-Malware Services](/windows/win32/services/protecting-anti-malware-services-). This helps make the system and antimalware solutions less susceptible to tampering by malware that does manage to get on the system.
With Protected Processes, Windows 10 prevents untrusted processes from interacting or tampering with those processes that have been specially signed. Protected Processes defines levels of trust for processes. Less trusted processes are prevented from interacting with and therefore attacking more trusted processes. Windows 10 uses Protected Processes more broadly across the operating system, and, as in Windows 8.1, implements them in a way that can be used by third-party anti-malware vendors, as described in [Protecting Anti-Malware Services](/windows/win32/services/protecting-anti-malware-services-). This ease in use helps make the system and anti-malware solutions less susceptible to tampering by malware that does manage to get on the system.
### Universal Windows apps protections
@ -223,13 +223,13 @@ Windows 10 has several important improvements to the security of the heap:
- **Heap metadata hardening** for internal data structures that the heap uses, to improve protections against memory corruption.
- **Heap allocation randomization**, that is, the use of randomized locations and sizes for heap memory allocations, which makes it more difficult for an attacker to predict the location of critical memory to overwrite. Specifically, Windows 10 adds a random offset to the address of a newly allocated heap, which makes the allocation much less predictable.
- **Heap allocation randomization**, that is, the use of randomized locations and sizes for heap memory allocations, making it more difficult for an attacker to predict the location of critical memory to overwrite. Specifically, Windows 10 adds a random offset to the address of a newly allocated heap, which makes the allocation much less predictable.
- **Heap guard pages** before and after blocks of memory, which work as trip wires. If an attacker attempts to write past a block of memory (a common technique known as a buffer overflow), the attacker will have to overwrite a guard page. Any attempt to modify a guard page is considered a memory corruption, and Windows 10 responds by instantly terminating the app.
### Kernel pool protections
The operating system kernel in Windows sets aside two pools of memory, one which remains in physical memory ("nonpaged pool") and one which can be paged in and out of physical memory ("paged pool"). There are many mitigations that have been added over time, such as process quota pointer encoding; lookaside, delay free, and pool page cookies; and PoolIndex bounds checks. Windows 10 adds multiple "pool hardening" protections, such as integrity checks, that help protect the kernel pool against more advanced attacks.
The operating system kernel in Windows sets aside two pools of memory, one which remains in physical memory ("nonpaged pool") and one that can be paged in and out of physical memory ("paged pool"). There are many mitigations that have been added over time, such as process quota pointer encoding; lookaside, delay free, and pool page cookies; and PoolIndex bounds checks. Windows 10 adds multiple "pool hardening" protections, such as integrity checks, that help protect the kernel pool against more advanced attacks.
In addition to pool hardening, Windows 10 includes other kernel hardening features:
@ -239,27 +239,27 @@ In addition to pool hardening, Windows 10 includes other kernel hardening featur
- **Disabling of NT Virtual DOS Machine (NTVDM)**: The old NTVDM kernel module (for running 16-bit applications) is disabled by default, which neutralizes the associated vulnerabilities. (Enabling NTVDM decreases protection against Null dereference and other exploits.)
- **Supervisor Mode Execution Prevention (SMEP)**: Helps prevent the kernel (the "supervisor") from executing code in user pages, a common technique used by attackers for local kernel elevation of privilege (EOP). This requires processor support found in Intel Ivy Bridge or later processors, or ARM with PXN support.
- **Supervisor Mode Execution Prevention (SMEP)**: Helps prevent the kernel (the "supervisor") from executing code in user pages, a common technique used by attackers for local kernel elevation of privilege (EOP). This configuration requires processor support found in Intel Ivy Bridge or later processors, or ARM with PXN support.
- **Safe unlinking:** Helps protect against pool overruns that are combined with unlinking operations to create an attack. Windows 10 includes global safe unlinking, which extends heap and kernel pool safe unlinking to all usage of LIST\_ENTRY and includes the "FastFail" mechanism to enable rapid and safe process termination.
- **Memory reservations**: The lowest 64 KB of process memory is reserved for the system. Apps are not allowed to allocate that portion of the memory. This makes it more difficult for malware to use techniques such as "NULL dereference" to overwrite critical system data structures in memory.
- **Memory reservations**: The lowest 64 KB of process memory is reserved for the system. Apps are not allowed to allocate that portion of the memory. This allocation for the system makes it more difficult for malware to use techniques such as "NULL dereference" to overwrite critical system data structures in memory.
### Control Flow Guard
When applications are loaded into memory, they are allocated space based on the size of the code, requested memory, and other factors. When an application begins to execute code, it calls additional code located in other memory addresses. The relationships between the code locations are well known—they are written in the code itself—but previous to Windows 10, the flow between these locations was not enforced, which gave attackers the opportunity to change the flow to meet their needs.
When applications are loaded into memory, they are allocated space based on the size of the code, requested memory, and other factors. When an application begins to execute code, it calls the other code located in other memory addresses. The relationships between the code locations are well known—they are written in the code itself—but previous to Windows 10, the flow between these locations was not enforced, which gave attackers the opportunity to change the flow to meet their needs.
This kind of threat is mitigated in Windows 10 through the Control Flow Guard (CFG) feature. When a trusted application that was compiled to use CFG calls code, CFG verifies that the code location called is trusted for execution. If the location is not trusted, the application is immediately terminated as a potential security risk.
An administrator cannot configure CFG; rather, an application developer can take advantage of CFG by configuring it when the application is compiled. Consider asking application developers and software vendors to deliver trustworthy Windows applications compiled with CFG enabled. For example, it can be enabled for applications written in C or C++, or applications compiled using Visual Studio 2015. For information about enabling CFG for a Visual Studio 2015 project, see [Control Flow Guard](/windows/win32/secbp/control-flow-guard).
Of course, browsers are a key entry point for attacks, so Microsoft Edge, IE, and other Windows features take full advantage of CFG.
Browsers are a key entry point for attacks, so Microsoft Edge, IE, and other Windows features take full advantage of CFG.
### Microsoft Edge and Internet Explorer 11
Browser security is a critical component of any security strategy, and for good reason: the browser is the user's interface to the Internet, an environment with many malicious sites and content waiting to attack. Most users cannot perform at least part of their job without a browser, and many users are completely reliant on one. This reality has made the browser the common pathway from which malicious hackers initiate their attacks.
Browser security is a critical component of any security strategy, and for good reason: the browser is the user's interface to the Internet, an environment with many malicious sites and content waiting to attack. Most users cannot perform at least part of their job without a browser, and many users are reliant on one. This reality has made the browser the common pathway from which malicious hackers initiate their attacks.
All browsers enable some amount of extensibility to do things beyond the original scope of the browser. Two common examples of this are Flash and Java extensions that enable their respective applications to run inside a browser. Keeping Windows 10 secure for web browsing and applications, especially for these two content types, is a priority.
All browsers enable some amount of extensibility to do things beyond the original scope of the browser. Two common examples are Flash and Java extensions that enable their respective applications to run inside a browser. Keeping Windows 10 secure for web browsing and applications, especially for these two content types, is a priority.
Windows 10 includes an entirely new browser, Microsoft Edge. Microsoft Edge is more secure in multiple ways, especially:
@ -267,15 +267,15 @@ Windows 10 includes an entirely new browser, Microsoft Edge. Microsoft Edge is m
- **Runs 64-bit processes.** A 64-bit PC running an older version of Windows often runs in 32-bit compatibility mode to support older and less secure extensions. When Microsoft Edge runs on a 64-bit PC, it runs only 64-bit processes, which are much more secure against exploits.
- **Includes Memory Garbage Collection (MemGC)**. This helps protect against use-after-free (UAF) issues.
- **Includes Memory Garbage Collection (MemGC)**. This feature helps protect against use-after-free (UAF) issues.
- **Designed as a Universal Windows app.** Microsoft Edge is inherently compartmentalized and runs in an AppContainer that sandboxes the browser from the system, data, and other apps. IE11 on Windows 10 can also take advantage of the same AppContainer technology through Enhanced Protect Mode. However, because IE11 can run ActiveX and BHOs, the browser and sandbox are susceptible to a much broader range of attacks than Microsoft Edge.
- **Simplifies security configuration tasks.** Because Microsoft Edge uses a simplified application structure and a single sandbox configuration, there are fewer required security settings. In addition, Microsoft Edge default settings align with security best practices, which makes it more secure by default.
- **Simplifies security configuration tasks.** Because Microsoft Edge uses a simplified application structure and a single sandbox configuration, there are fewer required security settings. In addition, Microsoft Edge default settings align with security best practices, making it more secure by default.
In addition to Microsoft Edge, Microsoft includes IE11 in Windows 10, primarily for backwards-compatibility with websites and with binary extensions that do not work with Microsoft Edge. It should not be configured as the primary browser but rather as an optional or automatic switchover. We recommend using Microsoft Edge as the primary web browser because it provides compatibility with the modern web and the best possible security.
In addition to Microsoft Edge, Microsoft includes IE11 in Windows 10, primarily for backwards-compatibility with websites and with binary extensions that do not work with Microsoft Edge. You cannot configure it as the primary browser but rather as an optional or automatic switchover. We recommend using Microsoft Edge as the primary web browser because it provides compatibility with the modern web and the best possible security.
For sites that require IE11 compatibility, including those that require binary extensions and plug-ins, enable Enterprise mode and use the Enterprise Mode Site List to define which sites have the dependency. With this configuration, when Microsoft Edge identifies a site that requires IE11, users will automatically be switched to IE11.
For sites that require IE11 compatibility, including those sites that require binary extensions and plug-ins, enable Enterprise mode and use the Enterprise Mode Site List to define which sites have the dependency. With this configuration, when Microsoft Edge identifies a site that requires IE11, users will automatically be switched to IE11.
### Functions that software vendors can use to build mitigations into apps
@ -293,16 +293,16 @@ Some of the protections available in Windows 10 are provided through functions t
| Child Process Restriction to restrict the ability to create child processes | [UpdateProcThreadAttribute function](/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute)<br>\[PROC\_THREAD\_ATTRIBUTE\_CHILD\_PROCESS\_POLICY\] |
| Code Integrity Restriction to restrict image loading | [SetProcessMitigationPolicy function](/windows/win32/api/processthreadsapi/nf-processthreadsapi-setprocessmitigationpolicy)<br>\[ProcessSignaturePolicy\] |
| Win32k System Call Disable Restriction to restrict ability to use NTUser and GDI | [SetProcessMitigationPolicy function](/windows/win32/api/processthreadsapi/nf-processthreadsapi-setprocessmitigationpolicy)<br>\[ProcessSystemCallDisablePolicy\] |
| High Entropy ASLR for up to 1TB of variance in memory allocations | [UpdateProcThreadAttribute function](/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute)<br>\[PROCESS\_CREATION\_MITIGATION\_POLICY\_HIGH\_ENTROPY\_ASLR\_ALWAYS\_ON\] |
| High Entropy ASLR for up to 1 TB of variance in memory allocations | [UpdateProcThreadAttribute function](/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute)<br>\[PROCESS\_CREATION\_MITIGATION\_POLICY\_HIGH\_ENTROPY\_ASLR\_ALWAYS\_ON\] |
| Strict handle checks to raise immediate exception upon bad handle reference | [UpdateProcThreadAttribute function](/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute)<br>\[PROCESS\_CREATION\_MITIGATION\_POLICY\_STRICT\_HANDLE\_CHECKS\_ALWAYS\_ON\] |
| Extension point disable to block the use of certain third-party extension points | [UpdateProcThreadAttribute function](/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute)<br>\[PROCESS\_CREATION\_MITIGATION\_POLICY\_EXTENSION\_POINT\_DISABLE\_ALWAYS\_ON\] |
| Heap terminate on corruption to protect the system against a corrupted heap | [UpdateProcThreadAttribute function](/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute)<br>\[PROCESS\_CREATION\_MITIGATION\_POLICY\_HEAP\_TERMINATE\_ALWAYS\_ON\] |
## Understanding Windows 10 in relation to the Enhanced Mitigation Experience Toolkit
You might already be familiar with the [Enhanced Mitigation Experience Toolkit (EMET)](https://support.microsoft.com/kb/2458544), which has since 2009 offered a variety of exploit mitigations, and an interface for configuring those mitigations. You can use this section to understand how EMET mitigations relate to those in Windows 10. Many of EMET's mitigations have been built into Windows 10, some with additional improvements. However, some EMET mitigations carry high performance cost, or appear to be relatively ineffective against modern threats, and therefore have not been brought into Windows 10.
You might already be familiar with the [Enhanced Mitigation Experience Toolkit (EMET)](https://support.microsoft.com/kb/2458544), which has since 2009 offered various exploit mitigations, and an interface for configuring those mitigations. You can use this section to understand how EMET mitigations relate to those mitigations in Windows 10. Many of EMET's mitigations have been built into Windows 10, some with extra improvements. However, some EMET mitigations carry high-performance cost, or appear to be relatively ineffective against modern threats, and therefore have not been brought into Windows 10.
Because many of EMET's mitigations and security mechanisms already exist in Windows 10 and have been improved, particularly those assessed to have high effectiveness at mitigating known bypasses, version 5.5*x* has been announced as the final major version release for EMET (see [Enhanced Mitigation Experience Toolkit](https://web.archive.org/web/20170928073955/https://technet.microsoft.com/en-US/security/jj653751)).
Because many of EMET's mitigations and security mechanisms already exist in Windows 10 and have been improved, particularly the ones assessed to have high effectiveness at mitigating known bypasses, version 5.5*x* has been announced as the final major version release for EMET (see [Enhanced Mitigation Experience Toolkit](https://web.archive.org/web/20170928073955/https://technet.microsoft.com/en-US/security/jj653751)).
The following table lists EMET features in relation to Windows 10 features.
@ -323,7 +323,7 @@ to Windows 10 features</th>
<li><p>SEHOP</p></li>
<li><p>ASLR (Force ASLR, Bottom-up ASLR)</p></li>
</ul></td>
<td><p>DEP, SEHOP and ASLR are included in Windows 10 as configurable features. See <a href="#table-2">Table 2</a>, earlier in this topic.</p>
<td><p>DEP, SEHOP, and ASLR are included in Windows 10 as configurable features. See <a href="#table-2">Table 2</a>, earlier in this topic.</p>
<p>You can install the ProcessMitigations PowerShell module to convert your EMET settings for these features into policies that you can apply to Windows 10.</p></td>
</tr>
<tr class="even">
@ -429,13 +429,13 @@ Examples:
ConvertTo-ProcessMitigationPolicy -EMETFilePath policy.xml -OutputFilePath result.xml
```
- **Audit and modify the converted settings (the output file)**: Additional cmdlets let you apply, enumerate, enable, disable, and save settings in the output file. For example, this cmdlet enables SEHOP and disables MandatoryASLR and DEPATL registry settings for Notepad:
- **Audit and modify the converted settings (the output file)**: More cmdlets let you apply, enumerate, enable, disable, and save settings in the output file. For example, this cmdlet enables SEHOP and disables MandatoryASLR and DEPATL registry settings for Notepad:
```powershell
Set-ProcessMitigation -Name notepad.exe -Enable SEHOP -Disable MandatoryASLR,DEPATL
```
- **Convert Attack surface reduction (ASR) settings to a Code Integrity policy file**: If the input file contains any settings for EMET's Attack surface reduction (ASR) mitigation, the converter will also create a Code Integrity policy file. In this case, you can complete the merging, auditing, and deployment process for the Code Integrity policy, as described in [Deploy Device Guard: deploy code integrity policies](/windows/device-security/device-guard/deploy-windows-defender-application-control). This will enable protections on Windows 10 equivalent to EMET's ASR protections.
- **Convert Attack surface reduction (ASR) settings to a Code Integrity policy file**: If the input file contains any settings for EMET's Attack surface reduction (ASR) mitigation, the converter will also create a Code Integrity policy file. In this case, you can complete the merging, auditing, and deployment process for the Code Integrity policy, as described in [Deploy Device Guard: deploy code integrity policies](/windows/device-security/device-guard/deploy-windows-defender-application-control). This completion will enable protections on Windows 10 equivalent to EMET's ASR protections.
- **Convert Certificate Trust settings to enterprise certificate pinning rules**: If you have an EMET "Certificate Trust" XML file (pinning rules file), you can also use ConvertTo-ProcessMitigationPolicy to convert the pinning rules file into an enterprise certificate pinning rules file. Then you can finish enabling that file as described in [Enterprise Certificate Pinning](/windows/access-protection/enterprise-certificate-pinning). For example:

24
windows/security/threat-protection/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md
View File

@ -80,13 +80,13 @@ An MDM solution evaluates the health assertions and, depending on the health rul
Access to content is then authorized to the appropriate level of trust for whatever the health status and other conditional elements indicate.
Depending on the requirements and the sensitivity of the managed asset, device health status can be combined with user identity information when processing an access request. Access to content is then authorized to the appropriate level of trust. The Conditional Access engine may be structured to allow additional verification as needed by the sensitivity of the managed asset. For example, if access to high-value data is requested, additional security authentication may need to be established by querying the user to answer a phone call before access is granted.
Depending on the requirements and the sensitivity of the managed asset, device health status can be combined with user identity information when processing an access request. Access to content is then authorized to the appropriate level of trust. The Conditional Access engine may be structured to allow more verification as needed by the sensitivity of the managed asset. For example, if access to high-value data is requested, further security authentication may need to be established by querying the user to answer a phone call before access is granted.
### <a href="" id="microsoft-s-security-investments-in-windows-10"></a>Microsoft’s security investments in Windows 10
In Windows 10, there are three pillars of investments:
- **Secure identities.** Microsoft is part of the FIDO Alliance which aims to provide an interoperable method of secure authentication by moving away from the use of passwords for authentication, both on the local system as well as for services like on-premises resources and cloud resources.
- **Secure identities.** Microsoft is part of the FIDO Alliance that aims to provide an interoperable method of secure authentication by moving away from the use of passwords for authentication, both on the local system and for services like on-premises resources and cloud resources.
- **Information protection.** Microsoft is making investments to allow organizations to have better control over who has access to important data and what they can do with that data. With Windows 10, organizations can take advantage of policies that specify which applications are considered to be corporate applications and can be trusted to access secure data.
- **Threat resistance.** Microsoft is helping organizations to better secure enterprise assets against the threats of malware and attacks by using security defenses relying on hardware.
@ -99,7 +99,7 @@ This section is an overview that describes different parts of the end-to-end sec
| Number | Part of the solution | Description |
| - | - | - |
| **1** | Windows 10-based device | The first time a Windows 10-based device is powered on, the out-of-box experience (OOBE) screen is displayed. During setup, the device can be automatically registered into Azure Active Directory (AD) and enrolled in MDM.<br/>A Windows 10-based device with TPM can report health status at any time by using the Health Attestation Service available with all editions of Windows 10.|
| **2** | Identity provider | Azure AD contains users, registered devices, and registered application of organization’s tenant. A device always belongs to a user and a user can have multiple devices. A device is represented as an object with different attributes like the compliance status of the device. A trusted MDM can update the compliance status.<br/>Azure AD is more than a repository. Azure AD is able to authenticate users and devices and can also authorize access to managed resources. Azure AD has a conditional access control engine that leverages the identity of the user, the location of the device and also the compliance status of the device when making a trusted access decision.|
| **2** | Identity provider | Azure AD contains users, registered devices, and registered application of organization’s tenant. A device always belongs to a user and a user can have multiple devices. A device is represented as an object with different attributes like the compliance status of the device. A trusted MDM can update the compliance status.<br/>Azure AD is more than a repository. Azure AD is able to authenticate users and devices and can also authorize access to managed resources. Azure AD has a conditional access control engine that uses the identity of the user, the location of the device and also the compliance status of the device when making a trusted access decision.|
| **3**|Mobile device management| Windows 10 has MDM support that enables the device to be managed out-of-box without deploying any agent.<br/>MDM can be Microsoft Intune or any third-party MDM solution that is compatible with Windows 10.|
| **4** | Remote health attestation | The Health Attestation Service is a trusted cloud service operated by Microsoft that performs a series of health checks and reports to MDM what Windows 10 security features are enabled on the device.<br/>Security verification includes boot state (WinPE, Safe Mode, Debug/test modes) and components that manage security and integrity of runtime operations (BitLocker, Device Guard).|
| **5** | Enterprise managed asset | Enterprise managed asset is the resource to protect.<br/>For example, the asset can be Office 365, other cloud apps, on-premises web resources published by Azure AD, or even VPN access.|
@ -121,7 +121,7 @@ Windows 10 supports features to help prevent sophisticated low-level malware lik
- **Trusted Platform Module.** A Trusted Platform Module (TPM) is a hardware component that provides unique security features.
Windows 10 leverages security characteristics of a TPM for measuring boot integrity sequence (and based on that, unlocking automatically BitLocker protected drives), for protecting credentials or for health attestation.
Windows 10 uses security characteristics of a TPM for measuring boot integrity sequence (and based on that, unlocking automatically BitLocker protected drives), for protecting credentials or for health attestation.
A TPM implements controls that meet the specification described by the Trusted Computing Group (TCG). At the time of this writing, there are two versions of TPM specification produced by TCG that are not compatible with each other:
@ -161,7 +161,7 @@ Windows 10 supports features to help prevent sophisticated low-level malware lik
- **Secure Boot configuration policy.** Extends Secure Boot functionality to critical Windows 10 configuration.
Examples of protected configuration information include protecting Disable Execute bit (NX option) or ensuring that the test signing policy (code integrity) cannot be enabled. This ensures that the binaries and configuration of the computer can be trusted after the boot process has completed.
Examples of protected configuration information include protecting Disable Execute bit (NX option) or ensuring that the test signing policy (code integrity) cannot be enabled. This protective action ensures that the binaries and configuration of the computer can be trusted after the boot process has completed.
Secure Boot configuration policy does this with UEFI policy. These signatures for these policies are signed in the same way that operating system binaries are signed for use with Secure Boot.
The Secure Boot configuration policy must be signed by a private key that corresponds to one of the public keys stored in the Key Exchange Key (KEK) list. The Microsoft Certificate Authority (CA) will be present in the KEK list of all Windows certified Secure Boot systems. By default, a policy signed by the Microsoft KEK shall be work on all Secure Boot systems. BootMgr must verify the signature against the KEK list before applying a signed policy. With Windows 10, the default Secure Boot configuration policy is embedded in bootmgr.
@ -188,7 +188,7 @@ Windows 10 supports features to help prevent sophisticated low-level malware lik
When enabled and configured, Windows 10 can start the Hyper-V virtualization-based security services. HVCI helps protect the system core (kernel), privileged drivers, and system defenses, like antimalware solutions, by preventing malware from running early in the boot process, or after startup.
HVCI uses virtualization-based security to isolate Code Integrity, the only way kernel memory can become executable is through a Code Integrity verification. This means that kernel memory pages can never be Writable and Executable (W+X) and executable code cannot be directly modified.
HVCI uses virtualization-based security to isolate Code Integrity, the only way kernel memory can become executable is through a Code Integrity verification. This dependency on verification means that kernel memory pages can never be Writable and Executable (W+X) and executable code cannot be directly modified.
> [!NOTE]
> Device Guard devices that run Kernel Mode Code Integrity with virtualization-based security must have compatible drivers. For additional information, please read the [Driver compatibility with Device Guard in Windows 10](https://go.microsoft.com/fwlink/p/?LinkId=691612) blog post.
@ -200,7 +200,7 @@ Windows 10 supports features to help prevent sophisticated low-level malware lik
In Windows 10, Credential Guard aims to protect domain corporate credentials from theft and reuse by malware. With Credential Guard, Windows 10 implemented an architectural change that fundamentally prevents the current forms of the pass-the-hash (PtH) attack.
This is accomplished by leveraging Hyper-V and the new virtualization-based security feature to create a protected container where trusted code and secrets are isolated from the Windows kernel. That means that even if the Windows kernel is compromised an attacker has no way to read and extract the data required to initiate a PtH attack. Credential Guard prevents this because the memory where secrets are stored is no longer accessible from the regular OS, even in kernel mode - the hypervisor controls who can access the memory.
This attack-free state is accomplished by using Hyper-V and the new virtualization-based security feature to create a protected container where trusted code and secrets are isolated from the Windows kernel. This accomplishment means that even if the Windows kernel is compromised, an attacker has no way to read and extract the data required to initiate a PtH attack. Credential Guard prevents this unauthorized access because the memory where secrets are stored is no longer accessible from the regular OS, even in kernel mode - the hypervisor controls who can access the memory.
- **Health attestation.** The device’s firmware logs the boot process, and Windows 10 can send it to a trusted server that can check and assess the device’s health.
@ -208,15 +208,15 @@ Windows 10 supports features to help prevent sophisticated low-level malware lik
For more information, see [Secured Boot and Measured Boot: Hardening Early Boot Components Against Malware](/previous-versions/windows/hardware/design/dn653311(v=vs.85)).
During each subsequent boot, the same components are measured, which allows comparison of the measurements against an expected baseline. For additional security, the values measured by the TPM can be signed and transmitted to a remote server, which can then perform the comparison. This process, called *remote device health attestation*, allows the server to verify health status of the Windows device.
During each subsequent boot, the same components are measured, which allows comparison of the measurements against an expected baseline. For more security, the values measured by the TPM can be signed and transmitted to a remote server, which can then perform the comparison. This process, called *remote device health attestation*, allows the server to verify health status of the Windows device.
Although Secure Boot is a proactive form of protection, health attestation is a reactive form of boot protection. Health attestation ships disabled in Windows and is enabled by an antimalware or an MDM vendor. Unlike Secure Boot, health attestation will not stop the boot process and enter remediation when a measurement does not work. But with conditional access control, health attestation will help to prevent access to high-value assets.
### <a href="" id="virtual"></a>Virtualization-based security
Virtualization-based security provides a new trust boundary for Windows 10. leverages Hyper-V hypervisor technology to enhance platform security. Virtualization-based security provides a secure execution environment to run specific Windows trusted code (trustlet) and to protect sensitive data.
Virtualization-based security provides a new trust boundary for Windows 10 and uses Hyper-V hypervisor technology to enhance platform security. Virtualization-based security provides a secure execution environment to run specific Windows trusted code (trustlet) and to protect sensitive data.
Virtualization-based security helps to protect against a compromised kernel or a malicious user with Administrator privileges. Note that virtualization-based security is not trying to protect against a physical attacker.
Virtualization-based security helps to protect against a compromised kernel or a malicious user with Administrator privileges. Virtualization-based security is not trying to protect against a physical attacker.
The following Windows 10 services are protected with virtualization-based security:
@ -234,14 +234,14 @@ The schema below is a high-level view of Windows 10 with virtualization-based se
### Credential Guard
In Windows 10, when Credential Guard is enabled, Local Security Authority Subsystem Service (lsass.exe) runs sensitive code in an Isolated user mode to help protect data from malware that may be running in the normal user mode. This helps ensure that protected data is not stolen and reused on
In Windows 10, when Credential Guard is enabled, Local Security Authority Subsystem Service (lsass.exe) runs a sensitive code in an Isolated user mode to help protect data from malware that may be running in the normal user mode. This code execution helps ensure that protected data is not stolen and reused on
remote machines, which mitigates many PtH-style attacks.
Credential Guard helps protect credentials by encrypting them with either a per-boot or persistent key:
- **The per-boot key** is used for any in-memory credentials that do not require persistence. An example of such a credential would be a ticket-granting ticket (TGT) session key. This key is negotiated with a Key Distribution Center (KDC) every time authentication occurs and is protected with a per-boot key.
- **The persistent key**, or some derivative, is used to help protect items that are stored and reloaded after a reboot. Such protection is intended for long-term storage, and must be protected with a consistent key.
Credential Guard is activated by a registry key and then enabled by using an UEFI variable. This is done to protect against remote modifications of the configuration. The use of a UEFI variable implies that physical access is required to change the configuration. When lsass.exe detects that
Credential Guard is activated by a registry key and then enabled by using a UEFI variable. This activation is done to protect against remote modifications of the configuration. The use of a UEFI variable implies that physical access is required to change the configuration. When lsass.exe detects that
credential isolation is enabled, it then spawns LsaIso.exe as an isolated process, which ensures that it runs within isolated user mode. The startup of LsaIso.exe is performed before initialization of a security support provider, which ensures that the secure mode support routines are ready before any authentication begins.
### Device Guard

4
windows/security/threat-protection/security-compliance-toolkit-10.md
View File

@ -1,6 +1,6 @@
---
title: Microsoft Security Compliance Toolkit 1.0
description: This article describes how to use the Security Compliance Toolkit in your organization
description: This article describes how to use the Microsoft Security Compliance Toolkit in your organization
keywords: virtualization, security, malware
ms.prod: m365-security
ms.mktglfcycl: deploy
@ -16,7 +16,7 @@ ms.reviewer:
ms.technology: windows-sec
---
# Microsoft Security Compliance Toolkit 1.0
# Microsoft Security Compliance Toolkit 1.0 - Usage
## What is the Security Compliance Toolkit (SCT)?

2
windows/security/threat-protection/security-policy-settings/secpol-advanced-security-audit-policy-settings.md
View File

@ -18,7 +18,7 @@ ms.date: 04/19/2017
ms.technology: windows-sec
---
# Advanced security audit policy settings
# Advanced security audit policy settings for Windows 10
**Applies to**
- Windows 10

34
windows/security/threat-protection/use-windows-event-forwarding-to-assist-in-intrusion-detection.md
View File

@ -25,7 +25,7 @@ Learn about an approach to collect events from devices in your organization. Thi
Windows Event Forwarding (WEF) reads any operational or administrative event log on a device in your organization and forwards the events you choose to a Windows Event Collector (WEC) server.
To accomplish this, there are two different subscriptions published to client devices - the Baseline subscription and the suspect subscription. The Baseline subscription enrolls all devices in your organization, and a Suspect subscription only includes devices that have been added by you. The Suspect subscription collects additional events to help build context for system activity and can quickly be updated to accommodate new events and/or scenarios as needed without impacting baseline operations.
To accomplish this functionality, there are two different subscriptions published to client devices - the Baseline subscription and the suspect subscription. The Baseline subscription enrolls all devices in your organization, and a Suspect subscription only includes devices that have been added by you. The Suspect subscription collects more events to help build context for system activity and can quickly be updated to accommodate new events and/or scenarios as needed without impacting baseline operations.
This implementation helps differentiate where events are ultimately stored. Baseline events can be sent to devices with online analytical capability, such as Security Event Manager (SEM), while also sending events to a MapReduce system, such as HDInsight or Hadoop, for long-term storage and deeper analysis. Events from the Suspect subscription are sent directly to a MapReduce system due to volume and lower signal/noise ratio, they are largely used for host forensic analysis.
@ -41,7 +41,7 @@ Here's an approximate scaling guide for WEF events:
| 5,000 - 50,000 | SEM |
| 50,000+ | Hadoop/HDInsight/Data Lake |
Event generation on a device must be enabled either separately or as part of the GPO for the baseline WEF implementation, including enabling of disabled event logs and setting channel permissions. For more info, see [Appendix C - Event channel settings (enable and channel access) methods](#bkmk-appendixc). This is because WEF is a passive system regarding the event log. It cannot change the size of event log files, enable disabled event channels, change channel permissions, or adjust a security audit policy. WEF only queries event channels for existing events. Additionally, having event generation already occurring on a device allows for more complete event collection building a complete history of system activity. Otherwise, you'll be limited to the speed of GPO and WEF subscription refresh cycles to make changes to what is being generated on the device. On modern devices, enabling additional event channels and expanding the size of event log files has not resulted in noticeable performance differences.
Event generation on a device must be enabled either separately or as part of the GPO for the baseline WEF implementation, including enabling of disabled event logs and setting channel permissions. For more info, see [Appendix C - Event channel settings (enable and channel access) methods](#bkmk-appendixc). This condition is because WEF is a passive system regarding the event log. It cannot change the size of event log files, enable disabled event channels, change channel permissions, or adjust a security audit policy. WEF only queries event channels for existing events. Additionally, having event generation already occurring on a device allows for more complete event collection building a complete history of system activity. Otherwise, you'll be limited to the speed of GPO and WEF subscription refresh cycles to make changes to what is being generated on the device. On modern devices, enabling more event channels and expanding the size of event log files has not resulted in noticeable performance differences.
For the minimum recommended audit policy and registry system ACL settings, see [Appendix A - Minimum recommended minimum audit policy](#bkmk-appendixa) and [Appendix B - Recommended minimum registry system ACL policy](#bkmk-appendixb).
@ -49,14 +49,14 @@ For the minimum recommended audit policy and registry system ACL settings, see [
From a WEF subscription management perspective, the event queries provided should be used in two separate subscriptions for ease of maintenance; only machines meeting specific criteria would be allowed access to the targeted subscription, this access would be determined by an algorithm or an analysts’ direction. All devices should have access to the Baseline subscription.
This means you would create two base subscriptions:
This system of dual subscription means you would create two base subscriptions:
- **Baseline WEF subscription**. Events collected from all hosts, this includes some role-specific events, which will only be emitted by those machines.
- **Baseline WEF subscription**. Events collected from all hosts; these events include some role-specific events, which will only be emitted by those machines.
- **Targeted WEF subscription**. Events collected from a limited set of hosts due to unusual activity and/or heightened awareness for those systems.
Each using the respective event query below. Note that for the Targeted subscription enabling the “read existing events” option should be set to true to allow collection of existing events from systems. By default, WEF subscriptions will only forward events generated after the WEF subscription was received by the client.
Each using the respective event query below. For the Targeted subscription enabling the “read existing events” option should be set to true to allow collection of existing events from systems. By default, WEF subscriptions will only forward events generated after the WEF subscription was received by the client.
In [Appendix E – Annotated Baseline Subscription Event Query](#bkmk-appendixe) and [Appendix F – Annotated Suspect Subscription Event Query](#bkmk-appendixf), the event query XML is included when creating WEF subscriptions. These are annotated for query purpose and clarity. Individual &lt;Query&gt; element can be removed or edited without affecting the rest of the query.
In [Appendix E – Annotated Baseline Subscription Event Query](#bkmk-appendixe) and [Appendix F – Annotated Suspect Subscription Event Query](#bkmk-appendixf), the event query XML is included when creating WEF subscriptions. These subscriptions are annotated for query purpose and clarity. Individual &lt;Query&gt; element can be removed or edited without affecting the rest of the query.
### Common WEF questions
@ -70,7 +70,7 @@ The longer answer is: The **Eventlog-forwardingPlugin/Operational** event channe
### Is WEF Push or Pull?
A WEF subscription can be configured to be push or pull, but not both. The simplest, most flexible IT deployment with the greatest scalability can be achieved by using a push, or source initiated, subscription. WEF clients are configured by using a GPO and the built-in forwarding client is activated. For pull, collector initiated, the subscription on the WEC server is pre-configured with the names of the WEF Client devices from which events are to be selected. Those clients also have to be configured ahead of time to allow the credentials used in the subscription to access their event logs remotely (normally by adding the credential to the **Event Log Readers** built-in local security group.) A useful scenario: closely monitoring a specific set of machines.
A WEF subscription can be configured to be push or pull, but not both. The simplest, most flexible IT deployment with the greatest scalability can be achieved by using a push, or source initiated, subscription. WEF clients are configured by using a GPO and the built-in forwarding client is activated. For pull, collector initiated, the subscription on the WEC server is pre-configured with the names of the WEF Client devices from which events are to be selected. Those clients are to be configured ahead of time to allow the credentials used in the subscription to access their event logs remotely (normally by adding the credential to the **Event Log Readers** built-in local security group.) A useful scenario: closely monitoring a specific set of machines.
### Will WEF work over VPN or RAS?
@ -78,7 +78,7 @@ WEF handles VPN, RAS, and DirectAccess scenarios well and will reconnect and sen
### How is client progress tracked?
The WEC server maintains in its registry the bookmark information and last heartbeat time for each event source for each WEF subscription. When an event source re-connects to a WEC server, the last bookmark position is sent to the device to use as a starting point to resume forwarding events. If a
The WEC server maintains in its registry the bookmark information and last heartbeat time for each event source for each WEF subscription. When an event source reconnects to a WEC server, the last bookmark position is sent to the device to use as a starting point to resume forwarding events. If a
WEF client has no events to send, the WEF client will connect periodically to send a Heartbeat to the WEC server to indicate it is active. This heartbeat value can be individually configured for each subscription.
### Will WEF work in an IPv4, IPv6, or mixed IPv4/IPv6 environment?
@ -188,7 +188,7 @@ The annotated event query can be found in the following. For more info, see [App
- Registry modification events. For more info, see [Appendix B – Recommended minimum Registry System ACL Policy](#bkmk-appendixb).
- OS startup and shutdown
- Startup event include operating system version, service pack level, QFE version, and boot mode.
- Startup events include operating system version, service pack level, QFE version, and boot mode.
- Service install
@ -216,13 +216,13 @@ The annotated event query can be found in the following. For more info, see [App
- Find out what initiated the restart of a device.
- User initiated interactive logoff event
- Remote Desktop Services session connect, reconnect, or disconnect.
- Remote Desktop Services sessions connect, reconnect, or disconnect.
- EMET events, if EMET is installed.
- Event forwarding plugin events
- For monitoring WEF subscription operations, particularly Partial Success events. This is useful for diagnosing deployment issues.
- Network share create and delete
- Network share creation and deletion
- Enables detection of unauthorized share creation.
>**Note:** All shares are re-created when the device starts.
@ -232,7 +232,7 @@ The annotated event query can be found in the following. For more info, see [App
- Logon success for interactive (local and Remote Interactive/Remote Desktop)
- Logon success for services for non-built-in accounts, such as LocalSystem, LocalNetwork, and so on.
- Logon success for batch sessions
- Logon session close, which are logoff events for non-network sessions.
- Logon session close, which is logoff events for non-network sessions.
- Windows Error Reporting (Application crash events only)
@ -244,7 +244,7 @@ The annotated event query can be found in the following. For more info, see [App
- Event log cleared (including the Security Event Log)
- This could indicate an intruder that are covering their tracks.
- This could indicate an intruder that is covering their tracks.
- Special privileges assigned to new logon
@ -271,7 +271,7 @@ The annotated event query can be found in the following. For more info, see [App
- Logon with explicit credentials
- Detect credential use changes by intruders to access additional resources.
- Detect credential use changes by intruders to access more resources.
- Smartcard card holder verification events
@ -296,7 +296,7 @@ This adds some possible intruder-related activity to help analyst further refine
- Groups assigned to local logon
- Gives visibility to groups which enable account wide access
- Gives visibility to groups which enable account-wide access
- Allows better planning for remediation efforts
- Excludes well known, built-in system accounts.
@ -337,7 +337,7 @@ This adds some possible intruder-related activity to help analyst further refine
## <a href="" id="bkmk-appendixa"></a>Appendix A - Minimum recommended minimum audit policy
If your organizational audit policy enables additional auditing to meet its needs, that is fine. The policy below is the minimum audit policy settings needed to enable events collected by both baseline and targeted subscriptions.
If your organizational audit policy enables more auditing to meet its needs, that is fine. The policy below is the minimum audit policy settings needed to enable events collected by both baseline and targeted subscriptions.
| Category | Subcategory | Audit settings |
|--------------------|---------------------------------|---------------------|
@ -388,7 +388,7 @@ Use the following figures to see how you can configure those registry keys.
Some channels are disabled by default and have to be enabled. Others, such as Microsoft-Windows-CAPI2/Operational must have the channel access modified to allow the Event Log Readers built-in security group to read from it.
The recommended and most effective way to do this is to configure the baseline GPO to run a scheduled task to configure the event channels (enable, set maximum size, and adjust channel access.) This will take effect at the next GPO refresh cycle and has minimal impact on the client device.
The recommended and most effective way to do this is configuring the baseline GPO to run a scheduled task to configure the event channels (enable, set maximum size, and adjust channel access.) This will take effect at the next GPO refresh cycle and has minimal impact on the client device.
The following GPO snippet performs the following:

2
windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer.md
View File

@ -29,7 +29,7 @@ ms.technology: windows-sec
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
With Windows Defender Application Control (WDAC), you can automatically allow applications installed by a software distribution solution, such as Microsoft Endpoint Configuration Manager, using a feature called _managed installer_. Managed installer can help you better balance security and manageability when enforcing application control policies.
Windows 10 (version 1703) introduced a new option for Windows Defender Application Control (WDAC), called _managed installer_, that helps balance security and manageability when enforcing application control policies. This option lets you automatically allow applications installed by a designated software distribution solution such as Microsoft Endpoint Configuration Manager.
## How does a managed installer work?

3
windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules.md
View File

@ -89,6 +89,7 @@ Unless your use scenarios explicitly require them, Microsoft recommends that you
| `Brock Mammen`| |
| `Casey Smith` | `@subTee` |
| `Jimmy Bayne` | `@bohops` |
| `Kim Oppalfens` | `@thewmiguy` |
| `Lasse Trolle Borup` | `Langkjaer Cyber Defence` |
| `Lee Christensen` | `@tifkin_` |
| `Matt Graeber` | `@mattifestation` |
@ -164,6 +165,7 @@ Select the correct version of each .dll for the Windows release you plan to supp
<Deny ID="ID_DENY_KILL" FriendlyName="kill.exe" FileName="kill.exe" MinimumFileVersion="65535.65535.65535.65535" />
<Deny ID="ID_DENY_LXRUN" FriendlyName="lxrun.exe" FileName="lxrun.exe" MinimumFileVersion="65535.65535.65535.65535"/>
<Deny ID="ID_DENY_LXSS" FriendlyName="LxssManager.dll" FileName="LxssManager.dll" MinimumFileVersion="65535.65535.65535.65535"/>
<Deny ID="ID_DENY_INTUNE_AGENT" FriendlyName="IntuneWindowsAgent.exe" FileName="Microsoft.Management.Services.IntuneWindowsAgent.exe" MinimumFileVersion="1.46.204.0"/>
<Deny ID="ID_DENY_MFC40" FriendlyName="mfc40.dll" FileName="mfc40.dll" MinimumFileVersion="65535.65535.65535.65535"/>
<Deny ID="ID_DENY_MS_BUILD" FriendlyName="Microsoft.Build.dll" FileName="Microsoft.Build.dll" MinimumFileVersion="65535.65535.65535.65535" />
<Deny ID="ID_DENY_MS_BUILD_FMWK" FriendlyName="Microsoft.Build.Framework.dll" FileName="Microsoft.Build.Framework.dll" MinimumFileVersion="65535.65535.65535.65535" />
@ -905,6 +907,7 @@ Select the correct version of each .dll for the Windows release you plan to supp
<FileRuleRef RuleID="ID_DENY_KILL"/>
<FileRuleRef RuleID="ID_DENY_LXSS"/>
<FileRuleRef RuleID="ID_DENY_LXRUN"/>
<FileRuleRef RuleID="ID_DENY_INTUNE_AGENT"/>
<FileRuleRef RuleID="ID_DENY_MFC40"/>
<FileRuleRef RuleID="ID_DENY_MS_BUILD" />
<FileRuleRef RuleID="ID_DENY_MS_BUILD_FMWK" />

71
windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules.md
View File

@ -46,14 +46,14 @@ Microsoft recommends enabling [HVCI](/windows/security/threat-protection/device-
```xml
<?xml version="1.0" encoding="utf-8"?>
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy">
<VersionEx>10.0.19565.0</VersionEx>
<VersionEx>10.0.22493.0</VersionEx>
<PolicyTypeID>{D2BDA982-CCF6-4344-AC5B-0B44427B6816}</PolicyTypeID>
<PlatformID>{2E07F7E4-194C-4D20-B7C9-6F44A6C5A234}</PlatformID>
<Rules>
<Rule>
<Option>Enabled:Unsigned System Integrity Policy</Option>
</Rule>
<Rule>
<Rule>
<Option>Enabled:Audit Mode</Option>
</Rule>
<Rule>
@ -173,6 +173,10 @@ Microsoft recommends enabling [HVCI](/windows/security/threat-protection/device-
<Deny ID="ID_DENY_SEMAV6MSR64_SHA256" FriendlyName="semav6msr64.sys Hash Sha256" Hash="EB71A8ECEF692E74AE356E8CB734029B233185EE5C2CCB6CC87CC6B36BEA65CF" />
<Deny ID="ID_DENY_SEMAV6MSR64_SHA1_PAGE" FriendlyName="semav6msr64.sys Hash Page Sha1" Hash="F3821EC0AEF270F749DF9F44FBA91AFA5C8C38E8" />
<Deny ID="ID_DENY_SEMAV6MSR64_SHA256_PAGE" FriendlyName="semav6msr64.sys Hash Page Sha256" Hash="4F12EE563E7496E7105D67BF64AF6B436902BE4332033AF0B5A242B206372CB7" />
<Deny ID="ID_DENY_WINRING0_SHA1" FriendlyName="WinRing0.sys Hash Sha1" Hash="12EB825418A932B1E4C6697DC7647E89AE52CF3F" />
<Deny ID="ID_DENY_WINRING0_SHA256" FriendlyName="WinRing0.sys Hash Sha256" Hash="4582ADB2E67EEBAFF755AE740C1F24BC3AF78E0F28E8E8DECB99F86BF155AB23" />
<Deny ID="ID_DENY_WINRING0_SHA1_PAGE" FriendlyName="WinRing0.sys Hash Page Sha1" Hash="497AFEB0D5B97D4B863704A2F77FFEF31220402D" />
<Deny ID="ID_DENY_WINRING0_SHA256_PAGE" FriendlyName="WinRing0.sys Hash Page Sha256" Hash="8D8A5696BDF11D2427016F91F9726AFF4F0C80FADBC3E6033662FA11C8B282BD" />
<Deny ID="ID_DENY_RETLIFTEN_SHA1_1" FriendlyName="80.sys Hash Sha1" Hash="BC2F3850C7B858340D7ED27B90E63B036881FD6C"/>
<Deny ID="ID_DENY_RETLIFTEN_SHA1_2" FriendlyName="netfilterdrv.sys Hash Sha1" Hash="E74B6DDA8BC53BC687FC21218BD34062A78D8467"/>
<Deny ID="ID_DENY_RETLIFTEN_SHA1_3" FriendlyName="netfilterdrv.sys Hash Sha1" Hash="2C27ABBBBCF10DFB75AD79557E30ACE5ED314DF8"/>
@ -242,6 +246,9 @@ Microsoft recommends enabling [HVCI](/windows/security/threat-protection/device-
<Deny ID="ID_DENY_RETLIFTEN_SHA1_67" FriendlyName="c.sys Hash Sha1" Hash="3C20BB896FD16B5C698185FB176E820A448997B3"/>
<Deny ID="ID_DENY_RETLIFTEN_SHA1_68" FriendlyName="gameink.sys Hash Sha1" Hash="6A784D45517142C11D5CCA3FF9956B2ED6EAF4C9"/>
<Deny ID="ID_DENY_RETLIFTEN_SHA1_69" FriendlyName="gameink.sys Hash Sha1" Hash="4E5E719362CD48BB323803C1D00AFDE11D4B9D4C"/>
<Deny ID="ID_DENY_RETLIFTEN_SHA1_70" FriendlyName="b.sys Hash Sha1" Hash="FD8A340CD071BC98E6EEAC9BBD4AC8A78688BC17"/>
<Deny ID="ID_DENY_RETLIFTEN_SHA1_71" FriendlyName="nt4.sys Hash Sha1" Hash="EC7947AD1919C8F60BC973B96DA4132A1EA396E0"/>
<Deny ID="ID_DENY_RETLIFTEN_SHA1_72" FriendlyName="d3.sys Hash Sha1" Hash="560D8869D48A71E59601B76240E9A6CFFB068C9C"/>
<Deny ID="ID_DENY_RETLIFTEN_SHA256_1" FriendlyName="80.sys Hash Sha256" Hash="F08EBDDC11AEFCB46082C239F8D97CEEA247D846E22C4BCDD72AF75C1CBC6B0B"/>
<Deny ID="ID_DENY_RETLIFTEN_SHA256_2" FriendlyName="netfilterdrv.sys Hash Sha256" Hash="12A636449A491EF3DC8688C5D25BE9EBF785874F9C4573667EEFD42139201AA4"/>
<Deny ID="ID_DENY_RETLIFTEN_SHA256_3" FriendlyName="netfilterdrv.sys Hash Sha256" Hash="7F1772BDF7DD81CB00D30159D19D4EB9160B54D7609B36F781D08CA3AFBD29A7"/>
@ -311,10 +318,16 @@ Microsoft recommends enabling [HVCI](/windows/security/threat-protection/device-
<Deny ID="ID_DENY_RETLIFTEN_SHA256_67" FriendlyName="c.sys Hash Sha256" Hash="CC383AD11E9D06047A1558ED343F389492DA3AC2B84B71462AEE502A2FA616C8"/>
<Deny ID="ID_DENY_RETLIFTEN_SHA256_68" FriendlyName="gameink.sys Hash Sha256" Hash="E94E8A87459DB56837D1C58F9854794AA99F36566A9DED9B398BE9D4D3A2C2AF"/>
<Deny ID="ID_DENY_RETLIFTEN_SHA256_69" FriendlyName="gameink.sys Hash Sha256" Hash="44A0599DEFEA351314663582DBC61069B3A095A4DDAD571BB17DD0D8B21E7FF2"/>
<Deny ID="ID_DENY_RETLIFTEN_SHA256_70" FriendlyName="b.sys Hash Sha256" Hash="84DF20B1D9D87E305C92E5FFAE21B10B325609D59D835A954DBD8750EF5DABF4"/>
<Deny ID="ID_DENY_RETLIFTEN_SHA256_71" FriendlyName="nt4.sys Hash Sha256" Hash="D7BC7306CB489FE4C285BBEDDC6D1A09E814EF55CF30BD5B8DAF87A52396F102"/>
<Deny ID="ID_DENY_RETLIFTEN_SHA256_72" FriendlyName="d3.sys Hash Sha256" Hash="36875562E747136313EC5DB58174E5FAB870997A054CA8D3987D181599C7DB6A"/>
<Deny ID="ID_DENY_PROCESSHACKER" FriendlyName="kprocesshacker.sys FileRule" FileName="kprocesshacker.sys" />
<Deny ID="ID_DENY_AMP" FriendlyName="System Mechanic CVE-2018-5701" FileName="amp.sys" MinimumFileVersion="0.0.0.0" MaximumFileVersion="5.4.11.1" />
<Deny ID="ID_DENY_ASMMAP" FriendlyName="Asus Memory Mapping Driver" FileName="asmmap.sys" MinimumFileVersion="0.0.0.0" MaximumFileVersion="65535.65535.65535.65535" />
<Deny ID="ID_DENY_ASMMAP_64" FriendlyName="Asus Memory Mapping Driver" FileName="asmmap64.sys" MinimumFileVersion="0.0.0.0" MaximumFileVersion="65535.65535.65535.65535" />
<Deny ID="ID_DENY_PHYMEMX_64" FriendlyName="Phymemx64 Memory Mapping Driver" FileName="phymemx64.sys" MinimumFileVersion="0.0.0.0" MaximumFileVersion="65535.65535.65535.65535" />
<Deny ID="ID_DENY_DBK_32" FriendlyName="Cheat Engine Driver" FileName="dbk32.sys" MinimumFileVersion="0.0.0.0" MaximumFileVersion="65535.65535.65535.65535" />
<Deny ID="ID_DENY_DBK_64" FriendlyName="Cheat Engine Driver" FileName="dbk64.sys" MinimumFileVersion="0.0.0.0" MaximumFileVersion="65535.65535.65535.65535" />
<FileAttrib ID="ID_FILEATTRIB_CPUZ_DRIVER" FriendlyName="" FileName="cpuz.sys" MinimumFileVersion="0.0.0.0" MaximumFileVersion="1.0.4.3" />
<FileAttrib ID="ID_FILEATTRIB_ELBY_DRIVER" FriendlyName="" FileName="ElbyCDIO.sys" MinimumFileVersion="0.0.0.0" MaximumFileVersion="6.0.3.2" />
<FileAttrib ID="ID_FILEATTRIB_LIBNICM_DRIVER" FriendlyName="" FileName="libnicm.sys" MinimumFileVersion="0.0.0.0" MaximumFileVersion="3.1.12.0" />
@ -335,15 +348,20 @@ Microsoft recommends enabling [HVCI](/windows/security/threat-protection/device-
<FileAttrib ID="ID_FILEATTRIB_TREND_MICRO" FriendlyName="TmComm.sys" FileName="TmComm.sys" MinimumFileVersion="0.0.0.0" MaximumFileVersion="8.0.0.0" />
<FileAttrib ID="ID_FILEATTRIB_VIRAGT" FriendlyName="viragt.sys 32-bit" FileName="viragt.sys" MinimumFileVersion="0.0.0.0" MaximumFileVersion="1.80.0.0" />
<FileAttrib ID="ID_FILEATTRIB_VIRAGT64" FriendlyName="viragt64.sys" FileName="viragt64.sys" MinimumFileVersion="0.0.0.0" MaximumFileVersion="1.0.0.11" />
<FileAttrib ID="ID_FILEATTRIB_HPPORTIOX64" FriendlyName="HpPortIox64.sys" FileName="HpPortIox64.sys" MinimumFileVersion="0.0.0.0" MaximumFileVersion="1.2.0.9" />
<FileAttrib ID="ID_FILEATTRIB_WINRING0" FriendlyName="WinRing0.sys" FileName="WinRing0.sys" MinimumFileVersion="0.0.0.0" MaximumFileVersion="2.0.0.0" />
</FileRules>
<!--Signers-->
<Signers>
<Signer ID="ID_SIGNER_F_1" Name="VeriSign Class 3 Code Signing 2010 CA">
<Signer ID="ID_SIGNER_VERISIGN_2010" Name="VeriSign Class 3 Code Signing 2010 CA">
<CertRoot Type="TBS" Value="4843A82ED3B1F2BFBEE9671960E1940C942F688D" />
<CertPublisher Value="CPUID" />
<FileAttribRef RuleID="ID_FILEATTRIB_CPUZ_DRIVER" />
<FileAttribRef RuleID="ID_FILEATTRIB_TREND_MICRO" />
</Signer>
<Signer ID="ID_SIGNER_CHEAT_ENGINE" Name="Microsoft Windows Third Party Component CA 2014 Cheat Engine OPUS">
<CertRoot Type="TBS" Value="D8BE9E4D9074088EF818BC6F6FB64955E90378B2754155126FEEBBBD969CF0AE" />
<CertOemID Value="Cheat Engine"/>
</Signer>
<Signer ID="ID_SIGNER_CPUZ" Name="DigiCert EV Code Signing CA (SHA2)">
<CertRoot Type="TBS" Value="EEC58131DC11CD7F512501B15FDBC6074C603B68CA91F7162D5A042054EDB0CF" />
<CertPublisher Value="CPUID" />
@ -405,6 +423,8 @@ Microsoft recommends enabling [HVCI](/windows/security/threat-protection/device-
<CertPublisher Value="Microsoft Windows Hardware Compatibility Publisher" />
<FileAttribRef RuleID="ID_FILEATTRIB_AMD_RYZEN" />
<FileAttribRef RuleID="ID_FILEATTRIB_TREND_MICRO" />
<FileAttribRef RuleID="ID_FILEATTRIB_HPPORTIOX64" />
<FileAttribRef RuleID="ID_FILEATTRIB_WINRING0" />
</Signer>
<Signer ID="ID_SIGNER_WINDOWS_3RD_PARTY_2014" Name="Microsoft Windows Third Party Component CA 2014">
<CertRoot Type="TBS" Value="D8BE9E4D9074088EF818BC6F6FB64955E90378B2754155126FEEBBBD969CF0AE" />
@ -415,6 +435,12 @@ Microsoft recommends enabling [HVCI](/windows/security/threat-protection/device-
<FileAttribRef RuleID="ID_FILEATTRIB_VIRAGT" />
<FileAttribRef RuleID="ID_FILEATTRIB_VIRAGT64" />
</Signer>
<Signer ID="ID_SIGNER_WINDOWS_3RD_PARTY_2010" Name="Microsoft Third Party Component Windows PCA 2010">
<CertRoot Type="TBS" Value="90C9669670E75989159E6EEF69625EB6AD17CBA6209ED56F5665D55450A05212" />
<CertPublisher Value="Microsoft Windows Hardware Compatibility Publisher" />
<FileAttribRef RuleID="ID_FILEATTRIB_HPPORTIOX64" />
<FileAttribRef RuleID="ID_FILEATTRIB_WINRING0" />
</Signer>
<Signer ID="ID_SIGNER_VERISIGN_2004" Name="VeriSign Class 3 Code Signing 2004 CA">
<CertRoot Type="TBS" Value="C7FC1727F5B75A6421A1F95C73BBDB23580C48E5" />
<CertPublisher Value="Mitac Technology Corporation" />
@ -452,7 +478,6 @@ Microsoft recommends enabling [HVCI](/windows/security/threat-protection/device-
</Signer>
<Signer ID="ID_SIGNER_SYMANTEC_CLASS_3" Name="Symantec Class 3 SHA256 Code Signing CA">
<CertRoot Type="TBS" Value="A08E79C386083D875014C409C13D144E0A24386132980DF11FF59737C8489EB1" />
<CertPublisher Value="Advanced Micro Devices INC." />
<FileAttribRef RuleID="ID_FILEATTRIB_AMD_RYZEN" />
<FileAttribRef RuleID="ID_FILEATTRIB_TREND_MICRO" />
</Signer>
@ -468,6 +493,12 @@ Microsoft recommends enabling [HVCI](/windows/security/threat-protection/device-
<FileAttribRef RuleID="ID_FILEATTRIB_VIRAGT" />
<FileAttribRef RuleID="ID_FILEATTRIB_VIRAGT64" />
</Signer>
<Signer ID="ID_SIGNER_HP" Name="DigiCert SHA2 Assured ID Code Signing CA">
<CertRoot Type="TBS" Value="E767799478F64A34B3F53FF3BB9057FE1768F4AB178041B0DCC0FF1E210CBA65" />
<CertPublisher Value="HP Inc." />
<FileAttribRef RuleID="ID_FILEATTRIB_HPPORTIOX64" />
<FileAttribRef RuleID="ID_FILEATTRIB_WINRING0" />
</Signer>
<Signer ID="ID_SIGNER_GEOTRUST_SRL_2009" Name="HT Srl Digital ID Class 3 - Microsoft Software Validation v2">
<CertRoot Type="TBS" Value="d70edfa009a76bd8250d74e9ee92eb9ead7d4cb3" />
</Signer>
@ -485,6 +516,9 @@ Microsoft recommends enabling [HVCI](/windows/security/threat-protection/device-
</Signer>
<Signer ID="ID_SIGNER_JEROMIN_CODY_ERIC" Name="Jeromin Cody Eric">
<CertRoot Type="TBS" Value="dfa6171201b51a2ec174310e8fb9f4c0fde2d365235e589ded0213c5279bea6e" />
</Signer>
<Signer ID="ID_SIGNER_SAASAME" Name="SaaSaMe Ltd.">
<CertRoot Type="TBS" Value="A86DE66D8198E4272859881476A6F9936034A482" />
</Signer>
</Signers>
<!--Driver Signing Scenarios-->
@ -501,10 +535,12 @@ Microsoft recommends enabling [HVCI](/windows/security/threat-protection/device-
<DeniedSigner SignerId="ID_SIGNER_VBOX" />
<DeniedSigner SignerId="ID_SIGNER_CPUZ" />
<DeniedSigner SignerId="ID_SIGNER_ELBY" />
<DeniedSigner SignerId="ID_SIGNER_F_1" />
<DeniedSigner SignerId="ID_SIGNER_VERISIGN_2010" />
<DeniedSigner SignerId="ID_SIGNER_HP" />
<DeniedSigner SignerId="ID_SIGNER_REALTEK" />
<DeniedSigner SignerId="ID_SIGNER_REALTEK_2" />
<DeniedSigner SignerId="ID_SIGNER_VERISIGN_2004" />
<DeniedSigner SignerId="ID_SIGNER_WINDOWS_3RD_PARTY_2010" />
<DeniedSigner SignerId="ID_SIGNER_WINDOWS_3RD_PARTY_2012" />
<DeniedSigner SignerId="ID_SIGNER_WINDOWS_3RD_PARTY_2014" />
<DeniedSigner SignerId="ID_SIGNER_VERISIGN_2009" />
@ -522,8 +558,10 @@ Microsoft recommends enabling [HVCI](/windows/security/threat-protection/device-
<DeniedSigner SignerId="ID_SIGNER_NANJING" />
<DeniedSigner SignerId="ID_SIGNER_TRUST_ASIA" />
<DeniedSigner SignerId="ID_SIGNER_JEROMIN_CODY_ERIC" />
<DeniedSigner SignerId="ID_SIGNER_CHEAT_ENGINE" />
<DeniedSigner SignerId="ID_SIGNER_SAASAME" />
</DeniedSigners>
<FileRulesRef>
<FileRulesRef>
<FileRuleRef RuleID="ID_DENY_ASIO_32_SHA1" />
<FileRuleRef RuleID="ID_DENY_ASIO_32_SHA256" />
<FileRuleRef RuleID="ID_DENY_ASIO_32_SHA1_PAGE" />
@ -633,6 +671,10 @@ Microsoft recommends enabling [HVCI](/windows/security/threat-protection/device-
<FileRuleRef RuleID="ID_DENY_SEMAV6MSR64_SHA256" />
<FileRuleRef RuleID="ID_DENY_SEMAV6MSR64_SHA1_PAGE" />
<FileRuleRef RuleID="ID_DENY_SEMAV6MSR64_SHA256_PAGE" />
<FileRuleRef RuleID="ID_DENY_WINRING0_SHA1" />
<FileRuleRef RuleID="ID_DENY_WINRING0_SHA256" />
<FileRuleRef RuleID="ID_DENY_WINRING0_SHA1_PAGE" />
<FileRuleRef RuleID="ID_DENY_WINRING0_SHA256_PAGE" />
<FileRuleRef RuleID="ID_DENY_RETLIFTEN_SHA1_1" />
<FileRuleRef RuleID="ID_DENY_RETLIFTEN_SHA1_2" />
<FileRuleRef RuleID="ID_DENY_RETLIFTEN_SHA1_3" />
@ -702,6 +744,9 @@ Microsoft recommends enabling [HVCI](/windows/security/threat-protection/device-
<FileRuleRef RuleID="ID_DENY_RETLIFTEN_SHA1_67"/>
<FileRuleRef RuleID="ID_DENY_RETLIFTEN_SHA1_68"/>
<FileRuleRef RuleID="ID_DENY_RETLIFTEN_SHA1_69"/>
<FileRuleRef RuleID="ID_DENY_RETLIFTEN_SHA1_70"/>
<FileRuleRef RuleID="ID_DENY_RETLIFTEN_SHA1_71"/>
<FileRuleRef RuleID="ID_DENY_RETLIFTEN_SHA1_72"/>
<FileRuleRef RuleID="ID_DENY_RETLIFTEN_SHA256_1" />
<FileRuleRef RuleID="ID_DENY_RETLIFTEN_SHA256_2" />
<FileRuleRef RuleID="ID_DENY_RETLIFTEN_SHA256_3" />
@ -771,11 +816,17 @@ Microsoft recommends enabling [HVCI](/windows/security/threat-protection/device-
<FileRuleRef RuleID="ID_DENY_RETLIFTEN_SHA256_67"/>
<FileRuleRef RuleID="ID_DENY_RETLIFTEN_SHA256_68"/>
<FileRuleRef RuleID="ID_DENY_RETLIFTEN_SHA256_69"/>
<FileRuleRef RuleID="ID_DENY_RETLIFTEN_SHA256_70"/>
<FileRuleRef RuleID="ID_DENY_RETLIFTEN_SHA256_71"/>
<FileRuleRef RuleID="ID_DENY_RETLIFTEN_SHA256_72"/>
<FileRuleRef RuleID="ID_DENY_PROCESSHACKER"/>
<FileRuleRef RuleID="ID_DENY_AMP"/>
<FileRuleRef RuleID="ID_DENY_ASMMAP"/>
<FileRuleRef RuleID="ID_DENY_ASMMAP_64"/>
</FileRulesRef>
<FileRuleRef RuleID="ID_DENY_ASMMAP_64"/>
<FileRuleRef RuleID="ID_DENY_PHYMEMX_64"/>
<FileRuleRef RuleID="ID_DENY_DBK_32"/>
<FileRuleRef RuleID="ID_DENY_DBK_64"/>
</FileRulesRef>
</ProductSigners>
</SigningScenario>
<SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_WINDOWS" FriendlyName="">
@ -794,7 +845,7 @@ Microsoft recommends enabling [HVCI](/windows/security/threat-protection/device-
</Setting>
<Setting Provider="PolicyInfo" Key="Information" ValueName="Id">
<Value>
<String>10.0.22417.0</String>
<String>10.0.22493.0</String>
</Value>
</Setting>
</Settings>

2
windows/security/threat-protection/windows-defender-application-control/plan-windows-defender-application-control-management.md
View File

@ -33,7 +33,7 @@ This topic describes the decisions you need to make to establish the processes f
## Policy XML lifecycle management
The first step in implementing application control is to consider how your policies will be managed and maintained over time. Developing a process for managing WDAC policies helps assure that WDAC continues to effectively control how applications are allowed to run in your organization.
The first step in implementing application control is to consider how your policies will be managed and maintained over time. Developing a process for managing WDAC policies helps ensure that WDAC continues to effectively control how applications are allowed to run in your organization.
Most WDAC policies will evolve over time and proceed through a set of identifiable phases during their lifetime. Typically, these phases include:

50
windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md
View File

@ -29,23 +29,23 @@ ms.technology: windows-sec
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
Windows Defender Application Control (WDAC) can control what runs on Windows 10 and Windows 11 by setting policies that specify whether a driver or application is trusted. A policy includes *policy rules* that control options such as audit mode, and *file rules* (or *file rule levels*) that specify how applications are identified and trusted.
Windows Defender Application Control (WDAC) can control what runs on Windows 10 and Windows 11, by setting policies that specify whether a driver or application is trusted. A policy includes *policy rules* that control options such as audit mode, and *file rules* (or *file rule levels*) that specify how applications are identified and trusted.
## Windows Defender Application Control policy rules
To modify the policy rule options of an existing WDAC policy XML, use [Set-RuleOption](/powershell/module/configci/set-ruleoption). The following examples show how to use this cmdlet to add and remove a rule option on an existing WDAC policy:
- To ensure that UMCI is enabled for a WDAC policy that was created with the `-UserPEs` (user mode) option, add rule option 0 to an existing policy by running the following command:
- To ensure that UMCI is enabled for a WDAC 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 XML> -Option 0`
A policy created without the `-UserPEs` option has no rules for user mode code. If you enable UMCI (Option 0) for such a policy, WDAC will block all applications and even critical Windows user session code. In audit mode, WDAC simply logs an event, but when enforced, all user mode code will be blocked. To create a policy that includes user mode executables (applications), run `New-CIPolicy` with the `-UserPEs` option.
A policy created without the `-UserPEs` option has no rules for user mode code. If you enable UMCI (Option 0) for such a policy, WDAC will block all applications, and even critical Windows user session code. In audit mode, WDAC simply logs an event, but when enforced, all user mode code will be blocked. To create a policy that includes user mode executables (applications), run `New-CIPolicy` with the `-UserPEs` option.
- To disable UMCI on an existing WDAC policy, delete rule option 0 by running the following command:
`Set-RuleOption -FilePath <Path to policy XML> -Option 0 -Delete`
You can set several rule options within a WDAC policy. Table 1 describes each rule option and whether they have supplemental policies. However, option 5 is not implemented as it is reserved for future work, and option 7 is not supported.
You can set several rule options within a WDAC policy. Table 1 describes each rule option, and whether they have supplemental policies. However, option 5 is not implemented as it is reserved for future work, and option 7 is not supported.
> [!NOTE]
> We recommend that you use **Enabled:Audit Mode** initially because it allows you to test new WDAC policies before you enforce them. With audit mode, no application is blocked—instead the policy logs an event whenever an application outside the policy is started. To allow these applications, you can capture the policy information from the event log, and then merge that information into the existing policy. When the **Enabled:Audit Mode** is deleted, the policy runs in enforced mode.
@ -57,28 +57,28 @@ You can set several rule options within a WDAC policy. Table 1 describes each ru
| **0 Enabled:UMCI** | WDAC policies restrict both kernel-mode and user-mode binaries. By default, only kernel-mode binaries are restricted. Enabling this rule option validates user mode executables and scripts. | No |
| **1 Enabled:Boot Menu Protection** | This option is not currently supported. | No |
| **2 Required:WHQL** | By default, legacy drivers that are not Windows Hardware Quality Labs (WHQL) signed are allowed to execute. Enabling this rule requires that every executed driver is WHQL signed and removes legacy driver support. Kernel drivers built for Windows 10 should be WHQL certified. | No |
| **3 Enabled:Audit Mode (Default)** | Instructs WDAC to log information about applications, binaries, and scripts that would have been blocked if the policy was enforced. You can use this option to identify the potential impact of your WDAC policy, and use the audit events to refine the policy before enforcement. To enforce a WDAC policy, delete this option. | No |
| **3 Enabled:Audit Mode (Default)** | Instructs WDAC to log information about applications, binaries, and scripts that would have been blocked, if the policy was enforced. You can use this option to identify the potential impact of your WDAC policy, and use the audit events to refine the policy before enforcement. To enforce a WDAC policy, delete this option. | No |
| **4 Disabled:Flight Signing** | If enabled, WDAC policies will not trust flightroot-signed binaries. This option would be used by organizations that only want to run released binaries, not pre-release Windows builds. | No |
| **5 Enabled:Inherit Default Policy** | This option is reserved for future use and currently has no effect. | Yes |
| **6 Enabled:Unsigned System Integrity Policy (Default)** | Allows the policy to remain unsigned. When this option is removed, the policy must be signed and the certificates that are trusted for future policy updates must be identified in the UpdatePolicySigners section. | Yes |
| **6 Enabled:Unsigned System Integrity Policy (Default)** | Allows the policy to remain unsigned. When this option is removed, the policy must be signed. The certificates that are trusted for future policy updates must be identified in the UpdatePolicySigners section. | Yes |
| **7 Allowed:Debug Policy Augmented** | This option is not currently supported. | Yes |
| **8 Required:EV Signers** | This rule requires that drivers must be WHQL signed and have been submitted by a partner with an Extended Verification (EV) certificate. All Windows 10 and Windows 11 drivers will meet this requirement. | No |
| **8 Required:EV Signers** | This rule requires that drivers must be WHQL signed, and have been submitted by a partner with an Extended Verification (EV) certificate. All Windows 10 and Windows 11 drivers will meet this requirement. | No |
| **9 Enabled:Advanced Boot Options Menu** | The F8 preboot menu is disabled by default for all WDAC policies. Setting this rule option allows the F8 menu to appear to physically present users. | No |
| **10 Enabled:Boot Audit on Failure** | Used when the WDAC policy is in enforcement mode. When a driver fails during startup, the WDAC policy will be placed in audit mode so that Windows will load. Administrators can validate the reason for the failure in the CodeIntegrity event log. | No |
| **11 Disabled:Script Enforcement** | This option disables script enforcement options. Unsigned PowerShell scripts and interactive PowerShell are no longer restricted to [Constrained Language Mode](/powershell/module/microsoft.powershell.core/about/about_language_modes). NOTE: This option is required to run HTA files, and is supported on 1709, 1803, and 1809 builds with the 2019 10C LCU or higher, and on devices with the Windows 10 May 2019 Update (1903) and higher. Using it on versions of Windows without the proper update may have unintended results. | No |
| **11 Disabled:Script Enforcement** | This option disables script enforcement options. Unsigned PowerShell scripts and interactive PowerShell are no longer restricted to [Constrained Language Mode](/powershell/module/microsoft.powershell.core/about/about_language_modes).<br/> NOTE: This option is required to run HTA files, and is supported on 1709, 1803, and 1809 builds with the 2019 10C LCU or higher, and on devices with the Windows 10 May 2019 Update (1903) and higher. Using it on versions of Windows without the proper update may have unintended results. | No |
| **12 Required:Enforce Store Applications** | If this rule option is enabled, WDAC policies will also apply to Universal Windows applications. | No |
| **13 Enabled:Managed Installer** | Use this option to automatically allow applications installed by a managed installer. For more information, see [Authorize apps deployed with a WDAC managed installer](configure-authorized-apps-deployed-with-a-managed-installer.md) | Yes |
| **14 Enabled:Intelligent Security Graph Authorization** | Use this option to automatically allow applications with "known good" reputation as defined by Microsoft’s Intelligent Security Graph (ISG). | Yes |
| **15 Enabled:Invalidate EAs on Reboot** | When the Intelligent Security Graph option (14) is used, WDAC sets an extended file attribute that indicates that the file was authorized to run. This option will cause WDAC to periodically revalidate the reputation for files that were authorized by the ISG.| No |
| **16 Enabled:Update Policy No Reboot** | Use this option to allow future WDAC policy updates to apply without requiring a system reboot. NOTE: This option is only supported on Windows 10, version 1709, and above.| No |
| **17 Enabled:Allow Supplemental Policies** | Use this option on a base policy to allow supplemental policies to expand it. NOTE: This option is only supported on Windows 10, version 1903, and above. | No |
| **18 Disabled:Runtime FilePath Rule Protection** | This option disables the default runtime check that only allows FilePath rules for paths that are only writable by an administrator. NOTE: This option is only supported on Windows 10, version 1903, and above. | Yes |
| **19 Enabled:Dynamic Code Security** | Enables policy enforcement for .NET applications and dynamically loaded libraries. NOTE: This option is only supported on Windows 10, version 1803, and above. | No |
| **20 Enabled:Revoked Expired As Unsigned** | Use this option to treat binaries signed with expired and/or revoked certificates as "Unsigned binaries" for user-mode process/components under enterprise signing scenarios. | No |
| **16 Enabled:Update Policy No Reboot** | Use this option to allow future WDAC policy updates to apply without requiring a system reboot.<br/> NOTE: This option is only supported on Windows 10, version 1709 and above.| No |
| **17 Enabled:Allow Supplemental Policies** | Use this option on a base policy to allow supplemental policies to expand it.<br/> NOTE: This option is only supported on Windows 10, version 1903 and above. | No |
| **18 Disabled:Runtime FilePath Rule Protection** | This option disables the default runtime check that only allows FilePath rules for paths that are only writable by an administrator.<br/> NOTE: This option is only supported on Windows 10, version 1903 and above. | Yes |
| **19 Enabled:Dynamic Code Security** | Enables policy enforcement for .NET applications and dynamically loaded libraries.<br/> NOTE: This option is only supported on Windows 10, version 1803 and above. | No |
| **20 Enabled:Revoked Expired As Unsigned** | Use this option to treat binaries signed with expired and/or revoked certificates as "Unsigned binaries" for user-mode process/components, under enterprise signing scenarios. | No |
## Windows Defender Application Control file rule levels
File rule levels allow administrators to specify the level at which they want to trust their applications. This level of trust could be as granular as the hash of each binary or as general as a CA certificate. You specify file rule levels when using WDAC PowerShell cmdlets to create and modify policies.
File rule levels allow administrators to specify the level at which they want to trust their applications. This level of trust could be as granular as the hash of each binary, or as general as a CA certificate. You specify file rule levels when using WDAC PowerShell cmdlets to create and modify policies.
Each file rule level has its benefit and disadvantage. Use Table 2 to select the appropriate protection level for your available administrative resources and Windows Defender Application Control deployment scenario.
@ -86,21 +86,21 @@ Each file rule level has its benefit and disadvantage. Use Table 2 to select the
| Rule level | Description |
|----------- | ----------- |
| **Hash** | Specifies individual hash values for each discovered binary. This is the most specific level and requires additional effort to maintain the current product versions’ hash values. Each time a binary is updated, the hash value changes, therefore requiring a policy update. |
| **FileName** | Specifies the original filename for each binary. Although the hash values for an application are modified when updated, the file names are typically not. This level offers less specific security than the hash level but does not typically require a policy update when any binary is modified. |
| **Hash** | Specifies individual hash values for each discovered binary. This is the most specific level, and requires additional effort to maintain the current product versions’ hash values. Each time a binary is updated, the hash value changes, therefore requiring a policy update. |
| **FileName** | Specifies the original filename for each binary. Although the hash values for an application are modified when updated, the file names are typically not. This level offers less specific security than the hash level, but it does not typically require a policy update when any binary is modified. |
| **FilePath** | Beginning with Windows 10 version 1903, this level allows binaries to run from specific file path locations. Additional information about FilePath level rules can be found below. |
| **SignedVersion** | This level combines the publisher rule with a version number and allows anything to run from the specified publisher with a version at or above the specified version number. |
| **SignedVersion** | This level combines the publisher rule with a version number. It allows anything to run from the specified publisher with a version at or above the specified version number. |
| **Publisher** | This level combines the PcaCertificate level (typically one certificate below the root) and the common name (CN) of the leaf certificate. You can use this rule level to trust a certificate issued by a particular CA and issued to a specific company you trust (such as Intel, for device drivers). |
| **FilePublisher** | This level combines the “FileName” attribute of the signed file, plus “Publisher” (PCA certificate with CN of leaf), plus a minimum version number. This option trusts specific files from the specified publisher, with a version at or above the specified version number. |
| **LeafCertificate** | Adds trusted signers at the individual signing certificate level. The benefit of using this level versus the individual hash level is that new versions of the product will have different hash values but typically the same signing certificate. Using this level, no policy update would be needed to run the new version of the application. However, leaf certificates have much shorter validity periods than other certificate levels, so the WDAC policy must be updated whenever these certificates change. |
| **PcaCertificate** | Adds the highest available certificate in the provided certificate chain to signers. This level is typically one certificate below the root certificate, because the scan does not validate anything beyond the certificates included in the provided signature (it does not go online or check local root stores). |
| **PcaCertificate** | Adds the highest available certificate in the provided certificate chain to signers. This level is typically one certificate below the root certificate because the scan does not validate anything beyond the certificates included in the provided signature (it does not go online or check local root stores). |
| **RootCertificate** | Currently unsupported. |
| **WHQL** | Trusts binaries if they have been validated and signed by WHQL. This level is primarily for kernel binaries. |
| **WHQLPublisher** | This level combines the WHQL level and the CN on the leaf certificate and is primarily for kernel binaries. |
| **WHQLPublisher** | This level combines the WHQL level and the CN on the leaf certificate, and is primarily for kernel binaries. |
| **WHQLFilePublisher** | Specifies that the binaries are validated and signed by WHQL, with a specific publisher (WHQLPublisher), and that the binary is the specified version or newer. This level is primarily for kernel binaries. |
> [!NOTE]
> When you create WDAC policies with [New-CIPolicy](/powershell/module/configci/new-cipolicy), you can specify a primary file rule level by including the **-Level** parameter. For discovered binaries that cannot be trusted based on the primary file rule criteria, use the **-Fallback** parameter. For example, if the primary file rule level is PCACertificate but you would like to trust the unsigned applications as well, using the Hash rule level as a fallback adds the hash values of binaries that did not have a signing certificate.
> When you create WDAC policies with [New-CIPolicy](/powershell/module/configci/new-cipolicy), you can specify a primary file rule level, by including the **-Level** parameter. For discovered binaries that cannot be trusted based on the primary file rule criteria, use the **-Fallback** parameter. For example, if the primary file rule level is PCACertificate, but you would like to trust the unsigned applications as well, using the Hash rule level as a fallback adds the hash values of binaries that did not have a signing certificate.
> [!NOTE]
> - WDAC only supports signer rules for RSA certificate signing keys with a maximum of 4096 bits.
@ -120,17 +120,17 @@ WDAC has a built-in file rule conflict logic that translates to precedence order
## More information about filepath rules
Filepath rules do not provide the same security guarantees that explicit signer rules do, as they are based on mutable access permissions. Filepath rules are best suited for environments where most users are running as standard rather than admin. Path rules are best suited to allow paths that you expect will remain admin-writeable only. You may want to avoid path rules for directories where standard users can modify ACLs on the folder.
Filepath rules do not provide the same security guarantees that explicit signer rules do, since they are based on mutable access permissions. Filepath rules are best suited for environments where most users are running as standard rather than admin. Path rules are best suited to allow paths that you expect will remain admin-writeable only. You may want to avoid path rules for directories where standard users can modify ACLs on the folder.
By default, WDAC performs a user-writeability check at runtime that ensures that the current permissions on the specified filepath and its parent directories (recursively) do not allow standard users write access.
There is a defined list of SIDs which WDAC recognizes as admins. If a filepath allows write permissions for any SID not in this list, the filepath is considered to be user-writeable even if the SID is associated to a custom admin user. To handle these special cases, you can override WDAC's runtime admin-writeable check with the **Disabled:Runtime FilePath Rule Protection** option described above.
There is a defined list of SIDs that WDAC recognizes as admins. If a filepath allows write permissions for any SID not in this list, the filepath is considered to be user-writeable, even if the SID is associated to a custom admin user. To handle these special cases, you can override WDAC's runtime admin-writeable check with the **Disabled:Runtime FilePath Rule Protection** option described above.
WDAC's list of well-known admin SIDs are:
S-1-3-0; S-1-5-18; S-1-5-19; S-1-5-20; S-1-5-32-544; S-1-5-32-549; S-1-5-32-550; S-1-5-32-551; S-1-5-32-577; S-1-5-32-559; S-1-5-32-568; S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394; S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523.
When generating filepath rules using [New-CIPolicy](/powershell/module/configci/new-cipolicy), a unique, fully qualified path rule is generated for every file discovered in the scanned path(s). To create rules that instead allow all files under a specified folder path, use [New-CIPolicyRule](/powershell/module/configci/new-cipolicyrule) to define rules containing wildcards using the [-FilePathRules](/powershell/module/configci/new-cipolicyrule#parameters) switch.
When generating filepath rules using [New-CIPolicy](/powershell/module/configci/new-cipolicy), a unique, fully qualified path rule is generated for every file discovered in the scanned path(s). To create rules that instead allow all files under a specified folder path, use [New-CIPolicyRule](/powershell/module/configci/new-cipolicyrule) to define rules containing wildcards, using the [-FilePathRules](/powershell/module/configci/new-cipolicyrule#parameters) switch.
Wildcards can be used at the beginning or end of a path rule; only one wildcard is allowed per path rule. Wildcards placed at the end of a path authorize all files in that path and its subdirectories recursively (ex. `C:\*` would include `C:\foo\*` ). Wildcards placed at the beginning of a path will allow the exact specified filename under any path (ex. `*\bar.exe` would allow `C:\bar.exe` and `C:\foo\bar.exe`). Wildcards in the middle of a path are not supported (ex. `C:\*\foo.exe`). Without a wildcard, the rule will allow only a specific file (ex. `C:\foo\bar.exe`).
@ -144,13 +144,13 @@ You can also use the following macros when the exact volume may vary: `%OSDRIVE%
### Why does scan create four hash rules per XML file?
The PowerShell cmdlet will produce an Authenticode Sha1 Hash, Sha256 Hash, Sha1 Page Hash, Sha256 Page Hash.
During validation CI will choose which hashes to calculate depending on how the file is signed. For example, if the file is page-hash signed the entire file would not get paged in to do a full sha256 authenticode and we would just match using the first page hash.
During validation CI will choose which hashes to calculate, depending on how the file is signed. For example, if the file is page-hash signed the entire file would not get paged in to do a full sha256 authenticode, and we would just match using the first page hash.
In the cmdlets, rather than try to predict which hash CI will use, we pre-calculate and use the four hashes (sha1/sha2 authenticode, and sha1/sha2 of first page). This is also resilient, if the signing status of the file changes and necessary for deny rules to ensure that changing/stripping the signature doesn’t result in a different hash than what was in the policy being used by CI.
### Why does scan create eight hash rules for certain XML files?
Separate rules are created for UMCI and KMCI. In some cases, files which are purely user-mode or purely kernel-mode may still generate both sets, as CI cannot always precisely determine what is purely user vs. kernel mode and errs on the side of caution.
Separate rules are created for UMCI and KMCI. In some cases, files that are purely user-mode or purely kernel-mode may still generate both sets, since CI cannot always precisely determine what is purely user vs. kernel mode, and errs on the side of caution.
## Windows Defender Application Control filename rules

10
windows/security/threat-protection/windows-defender-application-control/understand-windows-defender-application-control-policy-design-decisions.md
View File

@ -29,7 +29,7 @@ ms.technology: windows-sec
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
This topic is for the IT professional and lists the design questions, possible answers, and ramifications of the decisions when you plan a deployment of application control policies by using Windows Defender Application Control (WDAC) within a Windows operating system environment.
This topic is for the IT professional. It lists the design questions, possible answers, and ramifications for decisions made, when planning application control policies deployment using Windows Defender Application Control (WDAC), within a Windows operating system environment.
When you begin the design and planning process, you should consider the ramifications of your design choices. The resulting decisions will affect your policy deployment scheme and subsequent application control policy maintenance.
@ -46,24 +46,24 @@ You should consider using WDAC as part of your organization's application contro
Beginning with Windows 10, version 1903, WDAC allows [multiple simultaneous policies](deploy-multiple-windows-defender-application-control-policies.md) to be applied to each device. This opens up many new use cases for organizations, but your policy management can easily become unwieldy without a well-thought-out plan for the number and types of policies to create.
The first step is to define the desired "circle-of-trust" for your WDAC policies. By "circle-of-trust", we mean a description of the business intent of the policy expressed in natural language. This "circle-of-trust" definition will guide you as you create the actual policy rules for your policy XML.
The first step is to define the desired "circle-of-trust" for your WDAC policies. By "circle-of-trust," we mean a description of the business intent of the policy expressed in natural language. This "circle-of-trust" definition will guide you as you create the actual policy rules for your policy XML.
For example, the DefaultWindows policy, which can be found under %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies, establishes a "circle-of-trust" that allows Windows, 3rd-party hardware and software kernel drivers, and applications from the Microsoft Store.
Microsoft Endpoint Configuration Manager, previously known as System Center Configuration Manager, uses the DefaultWindows policy as the basis for its policy but then modifies the policy rules to allow Configuration Manager and its dependencies, sets the managed installer policy rule, and additionally configures Configuration Manager as a managed installer. It also can optionally authorize apps with positive reputation and perform a one-time scan of folder paths specified by the Configuration Manager administrator, which adds rules for any apps found in the specified paths on the managed endpoint. This establishes the "circle-of-trust" for Configuration Manager's native WDAC integration.
The following questions can help you plan your WDAC deployment and determine the right "circle-of-trust" for your policies. They are not in priority or sequential order and are not meant to be an exhaustive set of design considerations.
The following questions can help you plan your WDAC deployment and determine the right "circle-of-trust" for your policies. They are not in priority or sequential order, and are not meant to be an exhaustive set of design considerations.
## WDAC design considerations
### How are apps managed and deployed in your organization?
Organizations with well-defined, centrally managed app management and deployment processes can create more restrictive, more secure policies. Other organizations may be able to deploy WDAC with more relaxed rules or may choose to deploy WDAC in audit mode to gain better visibility to the apps being used in their organization.
Organizations with well-defined, centrally managed app management and deployment processes can create more restrictive, more secure policies. Other organizations may be able to deploy WDAC with more relaxed rules, or may choose to deploy WDAC in audit mode to gain better visibility to the apps being used in their organization.
| Possible answers | Design considerations|
| - | - |
| All apps are centrally managed and deployed using endpoint management tools like [Microsoft Endpoint Manager](https://www.microsoft.com/microsoft-365/microsoft-endpoint-manager). | Organizations that centrally manage all apps are best-suited for application control. WDAC options like [managed installer](configure-authorized-apps-deployed-with-a-managed-installer.md) can make it easy to authorize apps that are deployed by the organization's app distribution management solution. |
| Some apps are centrally managed and deployed, but teams can install other apps for their members. | [Supplemental policies](deploy-multiple-windows-defender-application-control-policies.md) can be used to allow team-specific exceptions to your core organization-wide WDAC policy. Alternatively, teams can use managed installers to install their team-specific apps or admin-only file path rules can be used to allow apps installed by admin users. |
| Some apps are centrally managed and deployed, but teams can install other apps for their members. | [Supplemental policies](deploy-multiple-windows-defender-application-control-policies.md) can be used to allow team-specific exceptions to your core organization-wide WDAC policy. Alternatively, teams can use managed installers to install their team-specific apps, or admin-only file path rules can be used to allow apps installed by admin users. |
| Users and teams are free to download and install apps but the organization wants to restrict that right to prevalent and reputable apps only. | WDAC can integrate with Microsoft's [Intelligent Security Graph](use-windows-defender-application-control-with-intelligent-security-graph.md) (the same source of intelligence that powers Microsoft Defender Antivirus and Windows Defender SmartScreen) to allow only apps and binaries that have positive reputation. |
| Users and teams are free to download and install apps without restriction. | WDAC policies can be deployed in audit mode to gain insight into the apps and binaries running in your organization without impacting user and team productivity.|

11
windows/security/threat-protection/windows-defender-application-control/use-signed-policies-to-protect-windows-defender-application-control-against-tampering.md
View File

@ -29,14 +29,14 @@ ms.technology: windows-sec
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
Signed WDAC policies give organizations the highest level of malware protection available in Windows. In addition to their enforced policy rules, signed policies cannot be modified or deleted by a user or administrator on the computer. These policies are designed to prevent administrative tampering and kernel mode exploit access. With this in mind, it is much more difficult to remove signed WDAC policies. Note that SecureBoot must be enabled in order to restrict users from updating or removing signed WDAC policies.
Signed WDAC policies give organizations the highest level of malware protection available in Windows—must be signed with [PKCS #7](https://datatracker.ietf.org/doc/html/rfc5652). In addition to their enforced policy rules, signed policies cannot be modified or deleted by a user or administrator on the computer. These policies are designed to prevent administrative tampering and kernel mode exploit access. With this in mind, it is much more difficult to remove signed WDAC policies. Note that SecureBoot must be enabled in order to restrict users from updating or removing signed WDAC policies.
Before you sign and deploy a signed WDAC policy, we recommend that you [audit the policy](audit-windows-defender-application-control-policies.md) to discover any blocked applications that should be allowed to run.
Before you sign with PKCS #7 and deploy a signed WDAC policy, we recommend that you [audit the policy](audit-windows-defender-application-control-policies.md) to discover any blocked applications that should be allowed to run.
Signing WDAC policies by using an on-premises CA-generated certificate or a purchased code signing certificate is straightforward.
If you do not currently have a code signing certificate exported in .pfx format (containing private keys, extensions, and root certificates), see [Optional: Create a code signing certificate for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md) to create one with your on-premises CA.
Before signing WDAC policies for the first time, be sure to enable rule options 9 (“Advanced Boot Options Menu”) and 10 (“Boot Audit on Failure”) to leave troubleshooting options available to administrators. To ensure that a rule option is enabled, you can run a command such as `Set-RuleOption -FilePath <PathAndFilename> -Option 9` even if you're not sure whether the option is already enabled—if so, the command has no effect. When validated and ready for enterprise deployment, you can remove these options. For more information about rule options, see [Windows Defender Application Control policy rules](select-types-of-rules-to-create.md).
Before PKCS #7-signing WDAC policies for the first time, be sure to enable rule options 9 (“Advanced Boot Options Menu”) and 10 (“Boot Audit on Failure”) to leave troubleshooting options available to administrators. To ensure that a rule option is enabled, you can run a command such as `Set-RuleOption -FilePath <PathAndFilename> -Option 9`, even if you're not sure whether the option is already enabled. If so, the command has no effect. When validated and ready for enterprise deployment, you can remove these options. For more information about rule options, see [Windows Defender Application Control policy rules](select-types-of-rules-to-create.md).
To sign a WDAC policy with SignTool.exe, you need the following components:
@ -96,17 +96,16 @@ If you do not have a code signing certificate, see [Optional: Create a code sign
ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin
```
8. Sign the WDAC policy by using SignTool.exe:
8. Sign ([PKCS #7](https://datatracker.ietf.org/doc/html/rfc5652)) the WDAC policy by using SignTool.exe:
```powershell
<Path to signtool.exe> sign -v /n "ContosoDGSigningCert" -p7 . -p7co 1.3.6.1.4.1.311.79.1 -fd sha256 $CIPolicyBin
```
> [!NOTE]
> The *&lt;Path to signtool.exe&gt;* variable should be the full path to the SignTool.exe utility. **ContosoDGSigningCert** is the subject name of the certificate that will be used to sign the WDAC policy. You should import this certificate to your personal certificate store on the computer you use to sign the policy.
9. Validate the signed file. When complete, the commands should output a signed policy file called {PolicyID}.cip to your desktop. You can deploy this file the same way you deploy an enforced or non-enforced policy. For information about how to deploy WDAC policies, see [Deploy and manage Windows Defender Application Control with Group Policy](deploy-windows-defender-application-control-policies-using-group-policy.md).
> [!NOTE]
> The device with the signed policy must be rebooted one time with Secure Boot enabled for the UEFI lock to be set.

10
windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-design-guide.md
View File

@ -34,10 +34,10 @@ This guide covers design and planning for Windows Defender Application Control (
## Plan for success
A common refrain you may hear about application control is that it is "too hard". While it is true that application control is not as simple as flipping a switch, organizations can be successful if they take a methodical approach and carefully plan their approach. In reality, the issues that lead to failure with application control often arise from business issues rather than technology challenges. Organizations that have successfully deployed application control have ensured the following before starting their planning:
A common refrain you may hear about application control is that it is "too hard." While it is true that application control is not as simple as flipping a switch, organizations can be successful, if they're methodical when carefully planning their approach. In reality, the issues that lead to failure with application control often arise from business issues rather than technology challenges. Organizations that have successfully deployed application control have ensured the following before starting their planning:
- Executive sponsorship and organizational buy-in is in place.
- There is a clear **business** objective for using application control and it is not being planned as a purely technical problem from IT.
- There is a clear **business** objective for using application control, and it is not being planned as a purely technical problem from IT.
- The organization has a plan to handle potential helpdesk support requests for users who are blocked from running some apps.
- The organization has considered where application control can be most useful (for example, securing sensitive workloads or business functions) and also where it may be difficult to achieve (for example, developer workstations).
@ -48,9 +48,9 @@ Once these business factors are in place, you are ready to begin planning your W
| Topic | Description |
| - | - |
| [Plan for WDAC policy management](plan-windows-defender-application-control-management.md) | This topic describes the decisions you need to make to establish the processes for managing and maintaining WDAC policies. |
| [Understand WDAC policy design decisions](understand-windows-defender-application-control-policy-design-decisions.md) | This topic lists the design questions, possible answers, and ramifications of the decisions when you plan a deployment of application control policies. |
| [Understand WDAC policy design decisions](understand-windows-defender-application-control-policy-design-decisions.md) | This topic lists the design questions, possible answers, and ramifications of the decisions, when you plan a deployment of application control policies. |
| [Understand WDAC policy rules and file rules](select-types-of-rules-to-create.md) | This topic lists resources you can use when selecting your application control policy rules by using WDAC. |
| [Policy creation for common WDAC usage scenarios](types-of-devices.md) | This set of topics outlines common use case scenarios and helps you begin to develop a plan for deploying WDAC in your organization. |
| [Policy creation for common WDAC usage scenarios](types-of-devices.md) | This set of topics outlines common use case scenarios, and helps you begin to develop a plan for deploying WDAC in your organization. |
| [Policy creation using the WDAC Wizard tool](wdac-wizard.md) | This set of topics describes how to use the WDAC Wizard desktop app to easily create, edit, and merge WDAC policies. |
After planning is complete, the next step is to deploy WDAC. The [Windows Defender Application Control Deployment Guide](windows-defender-application-control-deployment-guide.md) covers the creation and testing of policies, deploying the enforcement setting, and managing and maintaining the policies.
After planning is complete, the next step is to deploy WDAC. The [Windows Defender Application Control Deployment Guide](windows-defender-application-control-deployment-guide.md) covers creating and testing policies, deploying the enforcement setting, and managing and maintaining policies.

4
windows/security/threat-protection/windows-security-configuration-framework/security-compliance-toolkit-10.md
View File

@ -1,6 +1,6 @@
---
title: Microsoft Security Compliance Toolkit 1.0 Guide
description: This article describes how to use the Security Compliance Toolkit in your organization
description: This article describes how to use Security Compliance Toolkit 1.0 in your organization
keywords: virtualization, security, malware
ms.prod: m365-security
ms.mktglfcycl: deploy
@ -16,7 +16,7 @@ ms.reviewer:
ms.technology: windows-sec
---
# Microsoft Security Compliance Toolkit 1.0
# Microsoft Security Compliance Toolkit 1.0 - How to use
## What is the Security Compliance Toolkit (SCT)?