Standardize 'applies to' section

This commit is contained in:
brbrahm 2020-04-15 17:10:55 -07:00
parent 7d4890a4c4
commit 7328a258f7
9 changed files with 52 additions and 51 deletions

View File

@ -1,6 +1,6 @@
# [Application Control for Windows](windows-defender-application-control.md)
## [WDAC and AppLocker Overview](plan-windows-defender-application-control-management.md)
## [WDAC and AppLocker Feature Availability](understand-windows-defender-application-control-policy-design-decisions.md)
### [WDAC and AppLocker Feature Availability](understand-windows-defender-application-control-policy-design-decisions.md)
## [WDAC design guide](windows-defender-application-control-design-guide.md)

View File

@ -21,8 +21,8 @@ ms.date: 05/03/2018
**Applies to:**
- Windows 10
- Windows Server 2016 and above
- Windows 10
- Windows Server 2016 and above
This section outlines the process to create a WDAC policy for fixed-workload devices within an organization. Fixed-workload devices tend to be dedicated to a specific functional purpose and share common configuration attributes with other devices servicing the same functional role. Examples of fixed-workload devices may include Active Directory Domain Controllers, Secure Admin Workstations, pharmaceutical drug-mixing equipment, manufacturing devices, cash registers, ATMs, etc...

View File

@ -22,8 +22,8 @@ ms.date: 11/20/2019
**Applies to:**
- Windows 10
- Windows Server 2016 and above
- Windows 10
- Windows Server 2016 and above
This section outlines the process to create a WDAC policy for **fully-managed devices** within an organization. The key difference between this scenario and [lightly-managed devices](create-wdac-policy-for-lightly-managed-devices.md) is that all software deployed to a fully-managed device is managed by IT and users of the device cannot install arbitrary apps. Ideally, all apps are deployed using a software distribution solution, such as Microsoft Endpoint Manager (MEM). Additionally, users on fully-managed devices should ideally run as standard user and only authorized IT pros have administrative access.

View File

@ -22,8 +22,8 @@ ms.date: 11/15/2019
**Applies to:**
- Windows 10
- Windows Server 2016 and above
- Windows 10
- Windows Server 2016 and above
This section outlines the process to create a WDAC policy for **lightly-managed devices** within an organization. Typically, organizations that are new to application control will be most successful if they start with a permissive policy like the one described in this topic. Organizations can choose to harden the policy over time to achieve a stronger overall security posture on their WDAC managed devices as described in later topics.

View File

@ -21,8 +21,8 @@ ms.date: 04/15/2020
**Applies to:**
- Windows 10
- Windows Server 2016
- Windows 10
- Windows Server 2016
The restriction of only having a single code integrity policy active on a system at any given time has felt limiting for customers in situations where multiple policies with different intents would be useful. Beginning with Windows 10 version 1903, WDAC supports multiple simultaneous code integrity policies for one device in order to enable the following scenarios:
@ -69,6 +69,7 @@ Add-SignerRule -FilePath <string> -CertificatePath <string> [-Kernel] [-User] [-
### Supplemental policy creation
In order to create a supplemental policy, begin by creating a new policy in the Multiple Policy Format as shown above. From there, use Set-CIPolicyIdInfo to convert it to a supplemental policy and specify which base policy it expands. You can use either SupplementsBasePolicyID or BasePolicyToSupplementPath to specify the base policy.
- "SupplementsBasePolicyID": GUID of base policy that the supplemental policy applies to
- "BasePolicyToSupplementPath": path to base policy file that the supplemental policy applies to

View File

@ -20,9 +20,10 @@ ms.date: 11/15/2019
# Windows Defender Application Control example base policies
**Applies to**
- Windows 10
- Windows Server 2016 and above
**Applies to:**
- Windows 10
- Windows Server 2016 and above
When creating policies for use with Windows Defender Application Control (WDAC), it is recommended to start from an existing base policy and then add or remove rules to build your own custom policy XML files. Windows includes several example policies which can be used, or organizations which use the Device Guard Signing Service can download a starter policy from that service.

View File

@ -19,10 +19,10 @@ ms.date: 04/09/2019
# Microsoft recommended block rules
**Applies to**
- Windows 10
- Windows Server 2016
- Windows Server 2019
**Applies to:**
- Windows 10
- Windows Server 2016 and above
Members of the security community<sup>\*</sup> continuously collaborate with Microsoft to help protect customers. With the help of their valuable reports, Microsoft has identified a list of valid applications that an attacker could also potentially use to bypass Windows Defender Application Control.

View File

@ -21,8 +21,8 @@ ms.date: 03/10/2020
**Applies to:**
- Windows 10
- Windows Server 2016 and above
- Windows 10
- Windows Server 2016 and above
Application execution control can be difficult to implement in enterprises that do not have processes to effectively control the deployment of applications centrally through an IT managed system. In such environments, users are empowered to acquire the applications they need for work, making accounting for all the applications that would need to be authorized for execution control a daunting task.

View File

@ -21,9 +21,8 @@ ms.date: 06/13/2018
**Applies to:**
- Windows 10
- Windows Server 2016 and above
- Windows 10
- Windows Server 2016 and above
Creating and maintaining application execution control policies has always been challenging, and finding ways to address this issue has been a frequently-cited request for customers of AppLocker and Windows Defender Application Control (WDAC).
This is especially true for enterprises with large, ever changing software catalogs.
@ -144,6 +143,7 @@ An example of the managed installer option being set in policy is shown below.
</Rule>
</Rules>
```
## Set the AppLocker filter driver to autostart
To enable the managed installer, you need to set the AppLocker filter driver to autostart and start it.
@ -155,7 +155,6 @@ appidtel.exe start [-mionly]
Specify `-mionly` if you will not use the Intelligent Security Graph (ISG).
## Security considerations with managed installer
Since managed installer is a heuristic-based mechanism, it does not provide the same security guarantees that explicit allow or deny rules do.