| Setting | -Supported on | -Description | -
|---|---|---|
| Windows 10, version 2004: Administrative Templates\Windows Components\Windows Defender SmartScreen\Explorer\Configure Windows Defender SmartScreen - | Windows 10, version 1703: Administrative Templates\Windows Components\Windows Defender SmartScreen\Explorer\Configure Windows Defender SmartScreen Windows 10, Version 1607 and earlier: |
-This policy setting turns on Microsoft Defender SmartScreen. If you enable this setting, it turns on Microsoft Defender SmartScreen and your employees are unable to turn it off. Additionally, when enabling this feature, you must also pick whether Microsoft Defender SmartScreen should Warn your employees or Warn and prevent bypassing the message (effectively blocking the employee from the site). If you disable this setting, it turns off Microsoft Defender SmartScreen and your employees are unable to turn it on. If you don't configure this setting, your employees can decide whether to use Microsoft Defender SmartScreen. |
-
| Windows 10, version 2004: Administrative Templates\Windows Components\Windows Defender SmartScreen\Explorer\Configure App Install Control |
-Windows 10, version 1703: Administrative Templates\Windows Components\Windows Defender SmartScreen\Explorer\Configure App Install Control |
-This policy setting is intended to prevent malicious content from affecting your user's devices when downloading executable content from the internet. This setting does not protect against malicious content from USB devices, network shares, or other non-internet sources. Important: Using a trustworthy browser helps ensure that these protections work as expected. |
-
| Windows 10, version 2004: Administrative Templates\Windows Components\Windows Defender SmartScreen\Microsoft Edge\Configure Windows Defender SmartScreen (Microsoft Edge version 45 and earlier) Administrative Templates\Microsoft Edge\SmartScreen settings\Configure Microsoft Defender SmartScreen (Microsoft Edge version 77 or later) Windows 10, version 1703: Administrative Templates\Microsoft Edge\SmartScreen settings\Configure Microsoft Defender SmartScreen (Microsoft Edge version 77 or later) Windows 10, Version 1607 and earlier: |
-Microsoft Edge on Windows 10 or Windows 11 | -This policy setting turns on Microsoft Defender SmartScreen. If you enable this setting, it turns on Microsoft Defender SmartScreen and your employees are unable to turn it off. If you disable this setting, it turns off Microsoft Defender SmartScreen and your employees are unable to turn it on. If you don't configure this setting, your employees can decide whether to use Microsoft Defender SmartScreen. |
-
| Windows 10, version 2004: Administrative Templates\Windows Components\Windows Defender SmartScreen\Microsoft Edge\Prevent bypassing Windows Defender SmartScreen prompts for files (Microsoft Edge version 45 and earlier) Administrative Templates\Microsoft Edge\SmartScreen settings\Prevent bypassing of Microsoft Defender SmartScreen warnings about downloads (Microsoft Edge version 77 or later) Windows 10, version 1703: Administrative Templates\Microsoft Edge\SmartScreen settings\Prevent bypassing of Microsoft Defender SmartScreen warnings about downloads (Microsoft Edge version 77 or later) Windows 10, Version 1511 and 1607: |
-Microsoft Edge on Windows 10, version 1511 or later | -This policy setting stops employees from bypassing the Microsoft Defender SmartScreen warnings about potentially malicious files. If you enable this setting, it stops employees from bypassing the warning, stopping the file download. If you disable or don't configure this setting, your employees can bypass the warnings and continue to download potentially malicious files. |
-
| Windows 10, version 2004: Administrative Templates\Windows Components\Windows Defender SmartScreen\Microsoft Edge\Prevent bypassing Windows Defender SmartScreen prompts for sites (Microsoft Edge version 45 and earlier) Administrative Templates\Microsoft Edge\SmartScreen settings\Prevent bypassing Microsoft Defender SmartScreen prompts for sites (Microsoft Edge version 77 or later) Windows 10, version 1703: Administrative Templates\Microsoft Edge\SmartScreen settings\Prevent bypassing Microsoft Defender SmartScreen prompts for sites (Microsoft Edge version 77 or later) Windows 10, Version 1511 and 1607: |
-Microsoft Edge on Windows 10, version 1511 or later | -This policy setting stops employees from bypassing the Microsoft Defender SmartScreen warnings about potentially malicious sites. If you enable this setting, it stops employees from bypassing the warning, stopping them from going to the site. If you disable or don't configure this setting, your employees can bypass the warnings and continue to visit a potentially malicious site. |
-
| Administrative Templates\Windows Components\Internet Explorer\Prevent managing SmartScreen Filter | -Internet Explorer 9 or later | -This policy setting prevents the employee from managing Microsoft Defender SmartScreen. If you enable this policy setting, the employee isn't prompted to turn on Microsoft Defender SmartScreen. All website addresses that are not on the filter's allow list are sent automatically to Microsoft without prompting the employee. If you disable or don't configure this policy setting, the employee is prompted to decide whether to turn on Microsoft Defender SmartScreen during the first-run experience. |
-
| Administrative Templates\Windows Components\Internet Explorer\Prevent bypassing SmartScreen Filter warnings | -Internet Explorer 8 or later | -This policy setting determines whether an employee can bypass warnings from Microsoft Defender SmartScreen. If you enable this policy setting, Microsoft Defender SmartScreen warnings block the employee. If you disable or don't configure this policy setting, the employee can bypass Microsoft Defender SmartScreen warnings. |
-
| Administrative Templates\Windows Components\Internet Explorer\Prevent bypassing SmartScreen Filter warnings about files that are not commonly downloaded from the Internet | -Internet Explorer 9 or later | -This policy setting determines whether the employee can bypass warnings from Microsoft Defender SmartScreen. Microsoft Defender SmartScreen warns the employee about executable files that Internet Explorer users do not commonly download from the Internet. If you enable this policy setting, Microsoft Defender SmartScreen warnings block the employee. If you disable or don't configure this policy setting, the employee can bypass Microsoft Defender SmartScreen warnings. |
-
| Setting | -Supported versions | -Details | -
|---|---|---|
| AllowSmartScreen | -Windows 10 | -
-
|
-
| EnableAppInstallControl | -Windows 10, version 1703 | -
-
|
-
| EnableSmartScreenInShell | -Windows 10, version 1703 | -
-
|
-
| PreventOverrideForFilesInShell | -Windows 10, version 1703 | -
-
|
-
| PreventSmartScreenPromptOverride | -Windows 10, Version 1511 and Windows 11 | -
-
|
-
| PreventSmartScreenPromptOverrideForFiles | -Windows 10, Version 1511 and Windows 11 | -
-
|
-
| Group Policy setting | -Recommendation | -
|---|---|
| Administrative Templates\Windows Components\Microsoft Edge\Configure Windows Defender SmartScreen (Microsoft Edge version 45 and earlier) Administrative Templates\Microsoft Edge\SmartScreen settings\Configure Microsoft Defender SmartScreen (Microsoft Edge version 77 or later) |
-Enable. Turns on Microsoft Defender SmartScreen. | -
| Administrative Templates\Windows Components\Microsoft Edge\Prevent bypassing Windows Defender SmartScreen prompts for sites (Microsoft Edge version 45 and earlier) Administrative Templates\Microsoft Edge\SmartScreen settings\Prevent bypassing Windows Defender SmartScreen prompts for sites (Microsoft Edge version 77 or later) |
-Enable. Stops employees from ignoring warning messages and continuing to a potentially malicious website. | -
| Administrative Templates\Windows Components\Microsoft Edge\Prevent bypassing Windows Defender SmartScreen prompts for files (Microsoft Edge version 45 and earlier) Administrative Templates\Microsoft Edge\SmartScreen settings\Prevent bypassing of Microsoft Defender SmartScreen warnings about downloads (Microsoft Edge version 77 or later) |
-Enable. Stops employees from ignoring warning messages and continuing to download potentially malicious files. | -
| Administrative Templates\Windows Components\File Explorer\Configure Windows Defender SmartScreen | -Enable with the Warn and prevent bypass option. Stops employees from ignoring warning messages about malicious files downloaded from the Internet. | -
-
| MDM setting | -Recommendation | -
|---|---|
| Browser/AllowSmartScreen | -1. Turns on Microsoft Defender SmartScreen. | -
| Browser/PreventSmartScreenPromptOverride | -1. Stops employees from ignoring warning messages and continuing to a potentially malicious website. | -
| Browser/PreventSmartScreenPromptOverrideForFiles | -1. Stops employees from ignoring warning messages and continuing to download potentially malicious files. | -
| SmartScreen/EnableSmartScreenInShell | -1. Turns on Microsoft Defender SmartScreen in Windows. Requires at least Windows 10, version 1703. |
-
| SmartScreen/PreventOverrideForFilesInShell | -1. Stops employees from ignoring warning messages about malicious files downloaded from the Internet. Requires at least Windows 10, version 1703. |
-
STOP: C0000244 {Audit Failed} -An attempt to generate a security audit failed. |
-
| Threat | -Windows 10 Mobile mitigation | -
|---|---|
Firmware bootkits replace the firmware with malware. |
-All certified devices include Unified Extensible Firmware (UEFI) with Secure Boot, which requires signed firmware for updates to UEFI and Option ROMs. |
-
Bootkits start malware before Windows starts. |
-UEFI with Secure Boot verifies Windows bootloader integrity to help ensure that no malicious operating system can start before Windows. |
-
System or driver rootkits (typically malicious software that hides from the operating system) start kernel- level malware while Windows is starting, before antimalware solutions can start. |
-Windows Trusted Boot verifies Windows boot components, including Microsoft drivers. Measured Boot runs in parallel with Trusted Boot and can provide information to a remote server that verifies the boot state of the device to help ensure that Trusted Boot and other boot components successfully checked the system. |
-
An app infects other apps or the operating system with malware. |
-All Windows 10 Mobile apps run inside an AppContainer that isolates them from all other processes and sensitive operating system components. Apps cannot access any resources outside their AppContainer. |
-
An unauthorized app or malware attempts to start on the device. |
-All Windows 10 Mobile apps must come from Microsoft Store or Microsoft Store for Business. Device Guard enforces administrative policies to select exactly which apps are allowed to run. |
-
User-level malware exploits a vulnerability in the system or an application and owns the device. |
-Improvements to address space layout randomization (ASLR), Data Execution Prevention (DEP), the heap architecture, and memory-management algorithms reduce the likelihood that vulnerabilities can enable successful exploits. -Protected Processes isolates non-trusted processes from each other and from sensitive operating system components. |
-
Users access a dangerous website without knowledge of the risk. |
-The Windows Defender SmartScreen URL Reputation feature prevents users from going to a malicious website that may try to exploit the browser and take control of the device. |
-
Malware exploits a vulnerability in a browser add-on. |
-Microsoft Edge is an app built on the Universal Windows Platform (UWP) that does not run legacy binary extensions, including Microsoft ActiveX and browser helper objects frequently used for toolbars, which eliminates these risks. |
-
A website that includes malicious code exploits a vulnerability in the web browser to run malware on the client device. |
-Microsoft Edge includes Enhanced Protected Mode, which uses AppContainer-based sandboxing to help protect the system against vulnerabilities that at attacker may discover in the extensions running in the browser (for example, Adobe Flash, Java) or the browser itself. |
-
Protected Processes isolates non-trusted processes from each other and from sensitive operating system components.| +|Users access a dangerous website without knowledge of the risk.|The Windows Defender SmartScreen URL Reputation feature prevents users from going to a malicious website that may try to exploit the browser and take control of the device.| +|Malware exploits a vulnerability in a browser add-on.|Microsoft Edge is an app built on the Universal Windows Platform (UWP) that does not run legacy binary extensions, including Microsoft ActiveX and browser helper objects frequently used for toolbars, which eliminates these risks.| +|A website that includes malicious code exploits a vulnerability in the web browser to run malware on the client device.|Microsoft Edge includes Enhanced Protected Mode, which uses AppContainer-based sandboxing to help protect the system against vulnerabilities that at attacker may discover in the extensions running in the browser (for example, Adobe Flash, Java) or the browser itself.| ->**Note:** The Windows 10 Mobile devices use a System on a Chip (SoC) design provided by SoC vendors such as Qualcomm. With this architecture, the SoC vendor and device manufacturers provide the pre-UEFI bootloaders and the UEFI environment. The UEFI environment implements the UEFI Secure Boot standard described in section 27 of the UEFI specification, which can be found at [www.uefi.org/specs]( http://www.uefi.org/specs). This standard describes the process by which all UEFI drivers and applications are validated against keys provisioned into a UEFI-based device before they are executed. + +> [!NOTE] +> The Windows 10 Mobile devices use a System on a Chip (SoC) design provided by SoC vendors such as Qualcomm. With this architecture, the SoC vendor and device manufacturers provide the pre-UEFI bootloaders and the UEFI environment. The UEFI environment implements the UEFI Secure Boot standard described in section 27 of the UEFI specification, which can be found at [www.uefi.org/specs]( http://www.uefi.org/specs). This standard describes the process by which all UEFI drivers and applications are validated against keys provisioned into a UEFI-based device before they are executed. ### UEFI with Secure Boot @@ -237,7 +201,8 @@ Windows 10 Mobile supports TPM implementations that comply with the 2.0 standard Many assume that original equipment manufacturers (OEMs) must implant a TPM in hardware on a motherboard as a discrete module, but TPM can also be effective when implemented in firmware. Windows 10 Mobile supports only firmware TPM that complies with the 2.0 standard. Windows does not differentiate between discrete and firmware-based solutions because both must meet the same implementation and security requirements. Therefore, any Windows 10 feature that can take advantage of TPM can be used with Windows 10 Mobile. ->Microsoft requires TPM 2.0 on devices running any version of Windows 10 Mobile. For more information, see [minimum hardware requirements](/windows-hardware/design/minimum/minimum-hardware-requirements-overview) +> [!NOTE] +> Microsoft requires TPM 2.0 on devices running any version of Windows 10 Mobile. For more information, see [minimum hardware requirements](/windows-hardware/design/minimum/minimum-hardware-requirements-overview) Several Windows 10 Mobile security features require TPM: - Virtual smart cards diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/create-a-rule-for-packaged-apps.md b/windows/security/threat-protection/windows-defender-application-control/applocker/create-a-rule-for-packaged-apps.md index f983e81eba..1c676d9236 100644 --- a/windows/security/threat-protection/windows-defender-application-control/applocker/create-a-rule-for-packaged-apps.md +++ b/windows/security/threat-protection/windows-defender-application-control/applocker/create-a-rule-for-packaged-apps.md @@ -50,77 +50,22 @@ You can perform this task by using the Group Policy Management Console for an Ap 3. On the **Before You Begin** page, select **Next**. 4. On the **Permissions** page, select the action (allow or deny) and the user or group that the rule should apply to, and then select **Next**. 5. On the **Publisher** page, you can select a specific reference for the packaged app rule and set the scope for the rule. The following table describes the reference options. -
| Selection | -Description | -Example | -
|---|---|---|
Use an installed packaged app as a reference |
- If selected, AppLocker requires you to choose an app that is already installed on which to base your new rule. AppLocker uses the publisher, package name and package version to define the rule. |
- You want the Sales group only to use the app named Microsoft.BingMaps for its outside sales calls. The Microsoft.BingMaps app is already installed on the device where you are creating the rule, so you choose this option, and select the app from the list of apps installed on the computer and create the rule using this app as a reference. |
-
Use a packaged app installer as a reference |
- If selected, AppLocker requires you to choose an app installer on which to base your new rule. A packaged app installer has the .appx extension. AppLocker uses the publisher, package name, and package version of the installer to define the rule. |
- Your company has developed many internal line-of-business packaged apps. The app installers are stored on a common file share. Employees can install the required apps from that file share. You want to allow all your employees to install the Payroll app from this share. So you choose this option from the wizard, browse to the file share, and choose the installer for the Payroll app as a reference to create your rule. |
-
| Selection | -Description | -Example | -
|---|---|---|
Applies to Any publisher |
- This is the least restrictive scope condition for an Allow rule. It permits every packaged app to run or install. -Conversely, if this is a Deny rule, then this option is the most restrictive because it denies all apps from installing or running. |
- You want the Sales group to use any packaged app from any signed publisher. You set the permissions to allow the Sales group to be able to run any app. |
-
Applies to a specific Publisher |
- This scopes the rule to all apps published by a particular publisher. |
- You want to allow all your users to install apps published by the publisher of Microsoft.BingMaps. You could select Microsoft.BingMaps as a reference and choose this rule scope. |
-
Applies to a Package name |
- This scopes the rule to all packages that share the publisher name and package name as the reference file. |
- You want to allow your Sales group to install any version of the Microsoft.BingMaps app. You could select the Microsoft.BingMaps app as a reference and choose this rule scope. |
-
Applies to a Package version |
- This scopes the rule to a particular version of the package. |
- You want to be very selective in what you allow. You do not want to implicitly trust all future updates of the Microsoft.BingMaps app. You can limit the scope of your rule to the version of the app currently installed on your reference computer. |
-
Applying custom values to the rule |
- Selecting the Use custom values check box allows you to adjust the scope fields for your particular circumstance. |
- You want to allow users to install all Microsoft.Bing* applications, which include Microsoft.BingMaps, Microsoft.BingWeather, Microsoft.BingMoney. You can choose the Microsoft.BingMaps as a reference, select the Use custom values check box and edit the package name field by adding “Microsoft.Bing*” as the Package name. |
-
| Application control function | -SRP | -AppLocker | -
|---|---|---|
Scope |
-SRP policies can be applied to all Windows operating systems beginning with Windows XP and Windows Server 2003. |
-AppLocker policies apply only to the support versions of Windows listed in Requirements to use AppLocker. |
-
Policy creation |
-SRP policies are maintained through Group Policy and only the administrator of the GPO can update the SRP policy. The administrator on the local computer can modify the SRP policies defined in the local GPO. |
-AppLocker policies are maintained through Group Policy and only the administrator of the GPO can update the policy. The administrator on the local computer can modify the AppLocker policies defined in the local GPO. -AppLocker permits customization of error messages to direct users to a Web page for help. |
-
Policy maintenance |
-SRP policies must be updated by using the Local Security Policy snap-in (if the policies are created locally) or the Group Policy Management Console (GPMC). |
-AppLocker policies can be updated by using the Local Security Policy snap-in, if the policies are created locally, or the GPMC, or the Windows PowerShell AppLocker cmdlets. |
-
Policy application |
-SRP policies are distributed through Group Policy. |
-AppLocker policies are distributed through Group Policy. |
-
Enforcement mode |
-SRP works in the “deny list mode” where administrators can create rules for files that they don't want to allow in this Enterprise, but the rest of the files are allowed to run by default. -SRP can also be configured in the “allow list mode” such that by default all files are blocked and administrators need to create allow rules for files that they want to allow. |
-By default, AppLocker works in allow list mode. Only those files are allowed to run for which there's a matching allow rule. |
-
File types that can be controlled |
-SRP can control the following file types: -
SRP cannot control each file type separately. All SRP rules are in a single rule collection. |
-AppLocker can control the following file types: -
AppLocker maintains a separate rule collection for each of the five file types. |
-
Designated file types |
-SRP supports an extensible list of file types that are considered executable. You can add extensions for files that should be considered executable. |
-AppLocker doesn't support this. AppLocker currently supports the following file extensions: -
|
-
Rule types |
-SRP supports four types of rules: -
|
-AppLocker supports three types of rules: -
|
-
Editing the hash value |
-SRP allows you to select a file to hash. |
-AppLocker computes the hash value itself. Internally it uses the SHA2 Authenticode hash for Portable Executables (exe and DLL) and Windows Installers and an SHA2 flat file hash for the rest. |
-
Support for different security levels |
-With SRP, you can specify the permissions with which an app can run. Then configure a rule such that Notepad always runs with restricted permissions and never with administrative privileges. -SRP on Windows Vista and earlier supported multiple security levels. On Windows 7, that list was restricted to just two levels: Disallowed and Unrestricted (Basic User translates to Disallowed). |
-AppLocker does not support security levels. |
-
Manage Packaged apps and Packaged app installers. |
-Unable |
-.appx is a valid file type which AppLocker can manage. |
-
Targeting a rule to a user or a group of users |
-SRP rules apply to all users on a particular computer. |
-AppLocker rules can be targeted to a specific user or a group of users. |
-
Support for rule exceptions |
-SRP does not support rule exceptions |
-AppLocker rules can have exceptions that allow administrators to create rules such as “Allow everything from Windows except for Regedit.exe”. |
-
Support for audit mode |
-SRP doesn't support audit mode. The only way to test SRP policies is to set up a test environment and run a few experiments. |
-AppLocker supports audit mode that allows administrators to test the effect of their policy in the real production environment without impacting the user experience. Once you are satisfied with the results, you can start enforcing the policy. |
-
Support for exporting and importing policies |
-SRP does not support policy import/export. |
-AppLocker supports the importing and exporting of policies. This allows you to create AppLocker policy on a sample computer, test it out and then export that policy and import it back into the desired GPO. |
-
Rule enforcement |
-Internally, SRP rules enforcement happens in user-mode, which is less secure. |
-Internally, AppLocker rules for exes and dlls are enforced in kernel-mode, which is more secure than enforcing them in the user-mode. |
-
| Business group | -Organizational unit | -Implement AppLocker? | -Apps | -Installation path | -Use default rule or define new rule condition | -Allow or deny | -GPO name | -
|---|---|---|---|---|---|---|---|
Bank Tellers |
-Teller-East and Teller-West |
-Yes |
-Teller Software |
-C:\Program Files\Woodgrove\Teller.exe |
-File is signed; create a publisher condition |
-Allow |
-Tellers-AppLockerTellerRules |
-
| - | - | - | Windows files |
-C:\Windows |
-Create a path exception to the default rule to exclude \Windows\Temp |
-Allow |
-- |
Human Resources |
-HR-All |
-Yes |
-Check Payout |
-C:\Program Files\Woodgrove\HR\Checkcut.exe |
-File is signed; create a publisher condition |
-Allow |
-HR-AppLockerHRRules |
-
| - | - | - | Time Sheet Organizer - |
-C:\Program Files\Woodgrove\HR\Timesheet.exe - |
-File is not signed; create a file hash condition - |
-Allow |
-- |
| - | - | - | Internet Explorer 7 |
-C:\Program Files\Internet Explorer</p> |
-File is signed; create a publisher condition |
-Deny |
-- |
| - | - | - | Windows files |
-C:\Windows |
-Use a default rule for the Windows path |
-Allow |
-- |
| Business group | -Organizational unit | -Implement AppLocker? | -Apps | -Installation path | -
|---|---|---|---|---|
Bank Tellers |
-Teller-East and Teller-West |
-Yes |
-Teller Software |
-C:\Program Files\Woodgrove\Teller.exe |
-
| - | - | - | Windows files |
-C:\Windows |
-
Human Resources |
-HR-All |
-Yes |
-Check Payout |
-C:\Program Files\Woodgrove\HR\Checkcut.exe |
-
| - | - | - | Time Sheet Organizer |
-C:\Program Files\Woodgrove\HR\Timesheet.exe |
-
| - | - | - | Internet Explorer 7 |
-C:\Program Files\Internet Explorer</p> |
-
| - | - | - | Windows files |
-C:\Windows |
-
| Business group | -Organizational unit | -Implement AppLocker? | -Applications | -Installation path | -Use default rule or define new rule condition | -Allow or deny | -
|---|---|---|---|---|---|---|
Bank Tellers |
-Teller-East and Teller-West |
-Yes |
-Teller Software |
-C:\Program Files\Woodgrove\Teller.exe |
-File is signed; create a publisher condition |
-- |
| - | - | - | Windows files |
-C:\Windows |
-Create a path exception to the default rule to exclude \Windows\Temp |
-- |
Human Resources |
-HR-All |
-Yes |
-Check Payout |
-C:\Program Files\Woodgrove\HR\Checkcut.exe |
-File is signed; create a publisher condition |
-- |
| - | - | - | Time Sheet Organizer |
-C:\Program Files\Woodgrove\HR\Timesheet.exe |
-File is not signed; create a file hash condition |
-- |
| - | - | - | Internet Explorer 7 |
-C:\Program Files\Internet Explorer</p> |
-File is signed; create a publisher condition |
-- |
| - | - | - | Windows files |
-C:\Windows |
-Use the default rule for the Windows path |
-- |
| Business group | -Organizational unit | -Implement AppLocker? | -Apps | -Installation path | -Use default rule or define new rule condition | -Allow or deny | -GPO name | -Support policy | -
|---|---|---|---|---|---|---|---|---|
Bank Tellers |
-Teller-East and Teller-West |
-Yes |
-Teller Software |
-C:\Program Files\Woodgrove\Teller.exe |
-File is signed; create a publisher condition |
-Allow |
-Tellers-AppLockerTellerRules |
-Web help |
-
| - | - | - | Windows files - |
-C:\Windows |
-Create a path exception to the default rule to exclude \Windows\Temp |
-Allow |
-- | Help desk |
-
Human Resources |
-HR-All |
-Yes |
-Check Payout |
-C:\Program Files\Woodgrove\HR\Checkcut.exe |
-File is signed; create a publisher condition |
-Allow |
-HR-AppLockerHRRules |
-Web help |
-
| - | - | - | Time Sheet Organizer |
-C:\Program Files\Woodgrove\HR\Timesheet.exe |
-File is not signed; create a file hash condition |
-Allow |
-- | Web help |
-
| - | - | - | Internet Explorer 7 |
-C:\Program Files\Internet Explorer</p> |
-File is signed; create a publisher condition |
-Deny |
-- | Web help - |
-
| - | - | - | Windows files |
-C:\Windows |
-Use the default rule for the Windows path |
-Allow |
-- | Help desk |
-
| Business group | -AppLocker event collection location | -Archival policy | -Analyzed? | -Security policy | -
|---|---|---|---|---|
Bank Tellers |
-Forwarded to: AppLocker Event Repository on srvBT093 |
-Standard |
-None |
-Standard |
-
Human Resources |
-DO NOT FORWARD. srvHR004 |
-60 months |
-Yes, summary reports monthly to managers |
-Standard |
-
| Business group | -Rule update policy | -Application decommission policy | -Application version policy | -Application deployment policy | -
|---|---|---|---|---|
Bank Tellers |
-Planned: Monthly through business office triage -Emergency: Request through help desk |
-Through business office triage -30-day notice required |
-General policy: Keep past versions for 12 months -List policies for each application |
-Coordinated through business office -30-day notice required |
-
Human Resources |
-Planned: Monthly through HR triage -Emergency: Request through help desk |
-Through HR triage -30-day notice required |
-General policy: Keep past versions for 60 months -List policies for each application |
-Coordinated through HR -30-day notice required |
-
Emergency: Request through help desk|Through business office triage
30-day notice required|General policy: Keep past versions for 12 months
List policies for each application|Coordinated through business office
30-day notice required| +|Human Resources|Planned: Monthly through HR triage
Emergency: Request through help desk|Through HR triage
30-day notice required|General policy: Keep past versions for 60 months
List policies for each application|Coordinated through HR
30-day notice required| + diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/requirements-for-deploying-applocker-policies.md b/windows/security/threat-protection/windows-defender-application-control/applocker/requirements-for-deploying-applocker-policies.md index 85f6eb11a3..4b22f44415 100644 --- a/windows/security/threat-protection/windows-defender-application-control/applocker/requirements-for-deploying-applocker-policies.md +++ b/windows/security/threat-protection/windows-defender-application-control/applocker/requirements-for-deploying-applocker-policies.md @@ -41,181 +41,28 @@ The following requirements must be met or addressed before you deploy your AppLo An AppLocker policy deployment plan is the result of investigating which applications are required and necessary in your organization, which apps are optional, and which apps are forbidden. To develop this plan, see [AppLocker Design Guide](applocker-policies-design-guide.md). The following table is an example of the data you need to collect and the decisions you need to make to successfully deploy AppLocker policies on the supported operating systems (as listed in [Requirements to use AppLocker](requirements-to-use-applocker.md)). -
| Business group | -Organizational unit | -Implement AppLocker? | -Apps | -Installation path | -Use default rule or define new rule condition | -Allow or deny | -GPO name | -Support policy | -
|---|---|---|---|---|---|---|---|---|
Bank Tellers |
-Teller-East and Teller-West |
-Yes |
-Teller software |
-C:\Program Files\Woodgrove\Teller.exe |
-File is signed; create a publisher condition |
-Allow |
-Tellers |
-Web help |
-
| - | - | - | Windows files - |
-C:\Windows |
-Create a path exception to the default rule to exclude \Windows\Temp |
-Allow |
-- | Help Desk |
-
| - | - | - | Time Sheet Organizer |
-C:\Program Files\Woodgrove\HR\Timesheet.exe |
-File is not signed; create a file hash condition |
-Allow |
-- | Web help |
-
Human Resources |
-HR-All |
-Yes |
-Check Payout |
-C:\Program Files\Woodgrove\HR\Checkcut.exe |
-File is signed; create a publisher condition |
-Allow |
-HR |
-Web help |
-
| - | - | - | Internet Explorer 7 |
-C:\Program Files\Internet Explorer</p> |
-File is signed; create a publisher condition |
-Deny |
-- | Help Desk |
-
| - | - | - | Windows files |
-C:\Windows |
-Use the default rule for the Windows path |
-Allow |
-- | Help Desk |
-
| Business group | -AppLocker event collection location | -Archival policy | -Analyzed? | -Security policy | -
|---|---|---|---|---|
Bank Tellers |
-Forwarded to: srvBT093 |
-Standard |
-None |
-Standard |
-
Human Resources |
-Do not forward - |
-60 months |
-Yes; summary reports monthly to managers |
-Standard |
-
| Business group | -Rule update policy | -App decommission policy | -App version policy | -App deployment policy | -
|---|---|---|---|---|
Bank Tellers |
-Planned: Monthly through business office triage -Emergency: Request through Help Desk |
-Through business office triage; 30-day notice required |
-General policy: Keep past versions for 12 months -List policies for each application |
-Coordinated through business office; 30-day notice required |
-
Human Resources |
-Planned: Through HR triage -Emergency: Request through Help Desk |
-Through HR triage; 30-day notice required - |
-General policy: Keep past versions for 60 months -List policies for each application |
-Coordinated through HR; 30-day notice required |
-
Emergency: Request through Help Desk|Through business office triage; 30-day notice required|General policy: Keep past versions for 12 months
List policies for each application|Coordinated through business office; 30-day notice required| +|Human Resources|Planned: Through HR triage
Emergency: Request through Help Desk|Through HR triage; 30-day notice required|General policy: Keep past versions for 60 months
List policies for each application|Coordinated through HR; 30-day notice required| ### Supported operating systems diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/understand-applocker-policy-design-decisions.md b/windows/security/threat-protection/windows-defender-application-control/applocker/understand-applocker-policy-design-decisions.md index 2d5fca2ebb..c14abfaefc 100644 --- a/windows/security/threat-protection/windows-defender-application-control/applocker/understand-applocker-policy-design-decisions.md +++ b/windows/security/threat-protection/windows-defender-application-control/applocker/understand-applocker-policy-design-decisions.md @@ -57,7 +57,8 @@ You might need to control a limited number of apps because they access sensitive | Control apps by computer, not user | AppLocker is a computer-based policy implementation. If your domain or site organizational structure is not based on a logical user structure, such as an OU, you might want to set up that structure before you begin your AppLocker planning. Otherwise, you will have to identify users, their computers, and their app access requirements.| |Understand app usage, but there is no need to control any apps yet | AppLocker policies can be set to audit app usage to help you track which apps are used in your organization. You can then use the AppLocker event log to create AppLocker policies.| ->**Important:** The following list contains files or types of files that cannot be managed by AppLocker: +> [!IMPORTANT] +> The following list contains files or types of files that cannot be managed by AppLocker: - AppLocker does not protect against running 16-bit DOS binaries in an NT Virtual DOS Machine (NTVDM). This technology allows running legacy DOS and 16-bit Windows programs on computers that are using Intel 80386 or higher when there is already another operating system running and controlling the hardware. The result is that 16-bit binaries can still run on Windows Server 2008 R2 and Windows 7 when AppLocker is configured to otherwise block binaries and libraries. If it is a requirement to prevent 16-bit applications from running, you must configure the Deny rule in the Executable rule collection for NTVDM.exe. @@ -65,7 +66,8 @@ You might need to control a limited number of apps because they access sensitive - AppLocker can only control VBScript, JScript, .bat files, .cmd files and Windows PowerShell scripts. It does not control all interpreted code that runs within a host process, for example Perl scripts and macros. Interpreted code is a form of executable code that runs within a host process. For example, Windows batch files (\*.bat) run within the context of the Windows Command Host (cmd.exe). To use AppLocker to control interpreted code, the host process must call AppLocker before it runs the interpreted code, and then enforce the decision that is returned by AppLocker. Not all host processes call into AppLocker. Therefore, AppLocker cannot control every kind of interpreted code, for example Microsoft Office macros. - >**Important:** You should configure the appropriate security settings of these host processes if you must allow them to run. For example, configure the security settings in Microsoft Office to ensure that only signed and trusted macros are loaded. + > [!IMPORTANT] + > You should configure the appropriate security settings of these host processes if you must allow them to run. For example, configure the security settings in Microsoft Office to ensure that only signed and trusted macros are loaded. - AppLocker rules allow or prevent an app from launching. AppLocker does not control the behavior of apps after they are launched. Applications could contain flags that are passed to functions that signal AppLocker to circumvent the rules and allow another .exe or .dll file to be loaded. In practice, an app that is allowed by AppLocker could use these flags to bypass AppLocker rules and launch child processes. You must follow a process that best suits your needs to thoroughly vet each app before allowing them to run using AppLocker rules. @@ -98,57 +100,11 @@ Most organizations have evolved app control policies and methods over time. With ### Which Windows desktop and server operating systems are running in your organization? If your organization supports multiple Windows operating systems, app control policy planning becomes more complex. Your initial design decisions should consider the security and management priorities of applications that are installed on each version of the operating system. -
| Possible answers | -Design considerations | -
|---|---|
Your organization's computers are running a combination of the following operating systems: -
|
-AppLocker rules are only applied to computers running the supported versions of Windows, but SRP rules can be applied to all versions of Windows beginning with Windows XP and Windows Server 2003. For specific operating system version requirements, see Requirements to use AppLocker. -
-Note
-If you are using the Basic User security level as assigned in SRP, those privileges are not supported on computers running that support AppLocker. -
-
-AppLocker policies as applied through a GPO take precedence over SRP policies in the same or linked GPO. SRP policies can be created and maintained the same way. |
-
Your organization's computers are running only the following operating systems: -
|
-Use AppLocker to create your application control policies. |
-
| Path condition advantages | -Path condition disadvantages | -
|---|---|
|
-
|
-
| Publisher condition advantages | -Publisher condition disadvantages | -
|---|---|
|
-
|
-
| Application control function | -SRP | -AppLocker | -
|---|---|---|
Scope |
-SRP policies can be applied to all Windows operating systems beginning with Windows XP and Windows Server 2003. |
-AppLocker policies apply only to Windows Server 2008 R2, Windows 7, and later. |
-
Policy creation |
-SRP policies are maintained through Group Policy and only the administrator of the GPO can update the SRP policy. The administrator on the local computer can modify the SRP policies defined in the local GPO. |
-AppLocker policies are maintained through Group Policy and only the administrator of the GPO can update the policy. The administrator on the local computer can modify the AppLocker policies defined in the local GPO. -AppLocker permits customization of error messages to direct users to a Web page for help. |
-
Policy maintenance |
-SRP policies must be updated by using the Local Security Policy snap-in (if the policies are created locally) or the Group Policy Management Console (GPMC). |
-AppLocker policies can be updated by using the Local Security Policy snap-in (if the policies are created locally), or the GPMC, or the Windows PowerShell AppLocker cmdlets. |
-
Policy application |
-SRP policies are distributed through Group Policy. |
-AppLocker policies are distributed through Group Policy. |
-
Enforcement mode |
-SRP works in the “deny list mode” where administrators can create rules for files that they do not want to allow in this Enterprise whereas the rest of the file is allowed to run by default. -SRP can also be configured in the “allowlist mode” so that by default all files are blocked and administrators need to create allow rules for files that they want to allow. |
-AppLocker by default works in the “allowlist mode” where only those files are allowed to run for which there is a matching allow rule. |
-
File types that can be controlled |
-SRP can control the following file types: -
SRP cannot control each file type separately. All SRP rules are in a single rule collection. |
-AppLocker can control the following file types: -
AppLocker maintains a separate rule collection for each of the five file types. |
-
Designated file types |
-SRP supports an extensible list of file types that are considered executable. Administrators can add extensions for files that should be considered executable. |
-AppLocker currently supports the following file extensions: -
|
-
Rule types |
-SRP supports four types of rules: -
|
-AppLocker supports three types of rules: -
|
-
Editing the hash value |
-In Windows XP, you could use SRP to provide custom hash values. -Beginning with Windows 7 and Windows Server 2008 R2, you can only select the file to hash, not provide the hash value. |
-AppLocker computes the hash value itself. Internally, it uses the SHA2 Authenticode hash for Portable Executables (exe and dll) and Windows Installers and an SHA2 flat file hash for the rest. |
-
Support for different security levels |
-With SRP, you can specify the permissions with which an app can run. So, you can configure a rule such that Notepad always runs with restricted permissions and never with administrative privileges. -SRP on Windows Vista and earlier supported multiple security levels. On Windows 7, that list was restricted to just two levels: Disallowed and Unrestricted (Basic User translates to Disallowed). |
-AppLocker does not support security levels. |
-
Manage Packaged apps and Packaged app installers. |
-Not supported |
-.appx is a valid file type which AppLocker can manage. |
-
Targeting a rule to a user or a group of users |
-SRP rules apply to all users on a particular computer. |
-AppLocker rules can be targeted to a specific user or a group of users. |
-
Support for rule exceptions |
-SRP does not support rule exceptions. |
-AppLocker rules can have exceptions, which allow you to create rules such as “Allow everything from Windows except for regedit.exe”. |
-
Support for audit mode |
-SRP does not support audit mode. The only way to test SRP policies is to set up a test environment and run a few experiments. |
-AppLocker supports audit mode, which allows you to test the effect of their policy in the real production environment without impacting the user experience. Once you are satisfied with the results, you can start enforcing the policy. |
-
Support for exporting and importing policies |
-SRP does not support policy import/export. |
-AppLocker supports the importing and exporting of policies. This allows you to create AppLocker policy on a sample device, test it out and then export that policy and import it back into the desired GPO. |
-
Rule enforcement |
-Internally, SRP rules enforcement happens in the user-mode, which is less secure. |
-Internally, AppLocker rules for .exe and .dll files are enforced in the kernel-mode, which is more secure than enforcing them in the user-mode. |
-
| Feature | -Software Restriction Policies | -AppLocker | -
|---|---|---|
Rule scope |
-All users |
-Specific user or group |
-
Rule conditions provided |
-File hash, path, certificate, registry path, and Internet zone |
-File hash, path, and publisher |
-
Rule types provided |
-Defined by the security levels: -
|
-Allow and deny |
-
Default rule action |
-Unrestricted |
-Implicit deny |
-
Audit-only mode |
-No |
-Yes |
-
Wizard to create multiple rules at one time |
-No |
-Yes |
-
Policy import or export |
-No |
-Yes |
-
Rule collection |
-No |
-Yes |
-
Windows PowerShell support |
-No |
-Yes |
-
Custom error messages |
-No |
-Yes |
-
| Application control function | -SRP | -AppLocker | -
|---|---|---|
Operating system scope |
-SRP policies can be applied to all Windows operating systems beginning with Windows XP and Windows Server 2003. |
-AppLocker policies apply only to those supported operating system versions and editions listed in Requirements to use AppLocker. But these systems can also use SRP. -
-Note
-Use different GPOs for SRP and AppLocker rules. -
- |
-
User support |
-SRP allows users to install applications as an administrator. |
-AppLocker policies are maintained through Group Policy, and only the administrator of the device can update an AppLocker policy. -AppLocker permits customization of error messages to direct users to a Web page for help. |
-
Policy maintenance |
-SRP policies are updated by using the Local Security Policy snap-in or the Group Policy Management Console (GPMC). |
-AppLocker policies are updated by using the Local Security Policy snap-in or the GPMC. -AppLocker supports a small set of PowerShell cmdlets to aid in administration and maintenance. |
-
Policy management infrastructure |
-To manage SRP policies, SRP uses Group Policy within a domain and the Local Security Policy snap-in for a local computer. |
-To manage AppLocker policies, AppLocker uses Group Policy within a domain and the Local Security Policy snap-in for a local computer. |
-
Block malicious scripts |
-Rules for blocking malicious scripts prevents all scripts associated with the Windows Script Host from running, except those that are digitally signed by your organization. |
-AppLocker rules can control the following file formats: .ps1, .bat, .cmd, .vbs, and .js. In addition, you can set exceptions to allow specific files to run. |
-
Manage software installation |
-SRP can prevent all Windows Installer packages from installing. It allows .msi files that are digitally signed by your organization to be installed. |
-The Windows Installer rule collection is a set of rules created for Windows Installer file types (.mst, .msi and .msp) to allow you to control the installation of files on client computers and servers. |
-
Manage all software on the computer |
-All software is managed in one rule set. By default, the policy for managing all software on a device disallows all software on the user's device, except software that is installed in the Windows folder, Program Files folder, or subfolders. |
-Unlike SRP, each AppLocker rule collection functions as an allowed list of files. Only the files that are listed within the rule collection will be allowed to run. This configuration makes it easier for administrators to determine what will occur when an AppLocker rule is applied. |
-
Different policies for different users |
-Rules are applied uniformly to all users on a particular device. |
-On a device that is shared by multiple users, an administrator can specify the groups of users who can access the installed software. Using AppLocker, an administrator can specify the user to whom a specific rule should apply. |
-
AppLocker permits customization of error messages to direct users to a Web page for help.| +|Policy maintenance|SRP policies are updated by using the Local Security Policy snap-in or the Group Policy Management Console (GPMC).|AppLocker policies are updated by using the Local Security Policy snap-in or the GPMC.
AppLocker supports a small set of PowerShell cmdlets to aid in administration and maintenance.| +|Policy management infrastructure|To manage SRP policies, SRP uses Group Policy within a domain and the Local Security Policy snap-in for a local computer.|To manage AppLocker policies, AppLocker uses Group Policy within a domain and the Local Security Policy snap-in for a local computer.| +|Block malicious scripts|Rules for blocking malicious scripts prevents all scripts associated with the Windows Script Host from running, except those that are digitally signed by your organization.|AppLocker rules can control the following file formats: .ps1, .bat, .cmd, .vbs, and .js. In addition, you can set exceptions to allow specific files to run.| +|Manage software installation|SRP can prevent all Windows Installer packages from installing. It allows .msi files that are digitally signed by your organization to be installed.|The Windows Installer rule collection is a set of rules created for Windows Installer file types (.mst, .msi and .msp) to allow you to control the installation of files on client computers and servers.| +|Manage all software on the computer|All software is managed in one rule set. By default, the policy for managing all software on a device disallows all software on the user's device, except software that is installed in the Windows folder, Program Files folder, or subfolders.|Unlike SRP, each AppLocker rule collection functions as an allowed list of files. Only the files that are listed within the rule collection will be allowed to run. This configuration makes it easier for administrators to determine what will occur when an AppLocker rule is applied.| +|Different policies for different users|Rules are applied uniformly to all users on a particular device.|On a device that is shared by multiple users, an administrator can specify the groups of users who can access the installed software. Using AppLocker, an administrator can specify the user to whom a specific rule should apply.| ## Related topics