Windows Defender Application Control management with Configuration Manager

Applies to: Configuration Manager (current branch)

Introduction

Windows Defender Application Control is designed to protect PCs against malware and other untrusted software. It prevents malicious code from running by ensuring that only approved code, that you know, can be run.

Windows Defender Application Control is a software-based security layer that enforces an explicit list of software that is allowed to run on a PC. On its own, Application Control does not have any hardware or firmware prerequisites. Application Control policies deployed with Configuration Manager enable a policy on PCs in targeted collections that meet the minimum Windows version and SKU requirements outlined in this article. Optionally, hypervisor-based protection of Application Control policies deployed through Configuration Manager can be enabled through Group Policy on capable hardware.

To learn more about Windows Defender Application Control, read the Windows Defender Application Control deployment guide.

• Beginning with Windows 10, version 1709, configurable code integrity policies are known as Windows Defender Application Control.
• Beginning in Configuration Manager version 1710, Device Guard policies have been renamed to Windows Defender Application Control policies.

Using Windows Defender Application Control with Configuration Manager

You can use Configuration Manager to deploy a Windows Defender Application Control policy. This policy lets you configure the mode in which Windows Defender Application Control runs on PCs in a collection.

You can configure one of the following modes:

1. Enforcement enabled — Only trusted executables are allowed to run.
2. Audit only — Allow all executables to run, but log untrusted executables that run in the local client event log.

This feature was first introduced in version 1702 as a pre-release feature. Beginning with version 1906, it’s no longer a pre-release feature.

What can run when you deploy a Windows Defender Application Control policy?

Windows Defender Application Control lets you strongly control what can run on PCs you manage. This feature can be useful for PCs in high-security departments, where it’s vital that unwanted software cannot run.

When you deploy a policy, typically, the following executables can run:

• Windows operating system components
• Hardware Dev Center drivers (that have Windows Hardware Quality Labs signatures)
• Windows Store apps
• The Configuration Manager client
• All software deployed through Configuration Manager that PCs install after the Windows Defender Application Control policy is processed.
• Updates to windows components from:
  • Windows Update
  • Windows Update for Business
  • Windows Server Update Services
  • Configuration Manager
  • Optionally, software with a good reputation as determined by the Microsoft Intelligent Security Graph (ISG). The ISG includes Windows Defender SmartScreen and other Microsoft services. The device must be running Windows Defender SmartScreen and Windows 10 version 1709 or later for this software to be trusted.

These items do not include any software that is not built-into Windows that automatically updates from the internet or third-party software updates whether they are installed via any of the update mechanisms mentioned previously, or from the internet. Only software changes that are deployed though the Configuration Manager client can run.

Supported operating systems

To use Windows Defender Application Control with Configuration Manager, devices you manage must be running:

• Windows 10 Enterprise version 1703, or later.
• Windows Server 2019, or later (Introduced in version 2010)

Create new policies to target Windows Server operating systems after installation of Configuration Manager 2010 and installing the updated client. Existing Windows Defender Application Control polices created prior to installing 2010 won’t work with Windows Server operating systems.

Before you start

Before you configure or deploy Windows Defender Application Control policies, read the following information:

• Once a policy is successfully processed on a client PC, Configuration Manager is configured as a Managed Installer on that client. Software deployed through it, after the policy processes, is automatically trusted. Software installed by Configuration Manager before the Windows Defender Application Control policy processes is not automatically trusted.
• The default compliance evaluation schedule for Application Control policies, configurable during deployment, is every one day. If issues in policy processing are observed, it may be beneficial to configure the compliance evaluation schedule to be shorter, for example every hour. This schedule dictates how often clients reattempt to process a Windows Defender Application Control policy if a failure occurs.
• Regardless of the enforcement mode you select, when you deploy a Windows Defender Application Control policy, client PCs cannot run HTML applications with the extension .hta.
• Create new policies to target Windows Server operating systems after installation of Configuration Manager 2010 and installing the updated client. Existing Windows Defender Application Control polices created prior to installing 2010 won’t work with Windows Server operating systems.

How to create a Windows Defender Application Control policy

1. In the Configuration Manager console, click Assets and Compliance.
2. In the Assets and Compliance workspace, expand Endpoint Protection, and then click Windows Defender Application Control.
3. On the Home tab, in the Create group, click Create Application Control policy.
4. On the General page of the Create Application Control policy Wizard, specify the following settings:
   • Name — Enter a unique name for this Windows Defender Application Control policy.
   • Description — Optionally, enter a description for the policy that helps you identify it in the Configuration Manager console.
   • Enforce a restart of devices so that this policy can be enforced for all processes — After the policy is processed on a client PC, a restart is scheduled on the client according to the Client Settings for Computer Restart.
     • Devices running Windows 10 version 1703 or earlier will always be automatically restarted.
     • Starting with Windows 10 version 1709, applications currently running on the device will not have the new Application Control policy applied to them until after a restart. However, applications launched after the policy applies will honor the new Application Control policy.
   • Enforcement Mode — Choose one of the following enforcement methods for Windows Defender Application Control on the client PC.
     • Enforcement Enabled — Only allow trusted executables are allowed to run.
     • Audit Only — Allow all executables to run, but log untrusted executables that run in the local client event log.
5. On the Inclusions tab of the Create Application Control policy Wizard, choose if you want to Authorize software that is trusted by the Intelligent Security Graph.
6. Click Add if you want to add trust for specific files or folders on PCs. In the Add Trusted File or Folder dialog box, you can specify a local file or a folder path to trust. You can also specify a file or folder path on a remote device on which you have permission to connect. When you add trust for specific files or folders in a Windows Defender Application Control policy, you can:
   • Overcome issues with managed installer behaviors
   • Trust line-of-business apps that cannot be deployed with Configuration Manager
   • Trust apps that are included in an operating system deployment image.
7. Click Next, to complete the wizard.

The inclusion of trusted files or folders is only supported on client PCs running version 1706 or later of the Configuration Manager client. If any inclusion rules are included in a Windows Defender Application Control policy and the policy is then deployed to a client PC running an earlier version on the Configuration Manager client, the policy will fail to be applied. Upgrading these older clients will resolve this issue. Policies that do not include any inclusion rules may still be applied on older versions of the Configuration Manager client.

How to deploy a Windows Defender Application Control policy

1. In the Configuration Manager console, click Assets and Compliance.
2. In the Assets and Compliance workspace, expand Endpoint Protection, and then click Windows Defender Application Control.
3. From the list of policies, select the one you want to deploy, and then, on the Home tab, in the Deployment group, click Deploy Application Control Policy.
4. In the Deploy Application Control policy dialog box, select the collection to which you want to deploy the policy. Then, configure a schedule for when clients evaluate the policy. Finally, select whether the client can evaluate the policy outside of any configured maintenance windows.
5. When you are finished, click OK to deploy the policy.

How to monitor a Windows Defender Application Control policy

Use the information in the Monitor compliance settings article to help you monitor that the deployed policy has been applied to all PCs correctly.

To monitor the processing of a Windows Defender Application Control policy, use the following log file on client PCs:

%WINDIR%\CCM\Logs\DeviceGuardHandler.log

To verify the specific software being blocked or audited, see the following local client event logs:

1. For blocking and auditing of executable files, use Applications and Services Logs >Microsoft >Windows >Code Integrity >Operational.
2. For blocking and auditing of Windows Installer and script files, use Applications and Services Logs >Microsoft >Windows >AppLocker >MSI and Script.

Determine your application control objectives

Applies to

This article helps with decisions you need to make to determine what applications to control and how to control them by comparing Software Restriction Policies (SRP) and AppLocker.

AppLocker is effective for organizations with app restriction requirements whose environments have a simple topography and whose application control policy goals are straightforward. For example, AppLocker can benefit an environment where non-employees have access to computers connected to the organizational network, such as a school or library. Large organizations also benefit from AppLocker policy deployment when the goal is a detailed level of control on the PCs they manage for a relatively small number of apps.

There are management and maintenance costs associated with a list of allowed apps. In addition, the purpose of application control policies is to allow or prevent employees from using apps that might actually be productivity tools. Keeping employees or users productive while implementing the policies can cost time and effort. Lastly, creating user support processes and network support processes to keep the organization productive are also concerns.

Use the following table to develop your own objectives and determine which application control feature best addresses those objectives.

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.

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.

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.

SRP policies are distributed through Group Policy.

AppLocker policies are distributed through Group Policy.

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:

Packaged apps and installers

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:

Executables (.exe, .com)

Scripts (.vbs, .js, .ps1, .cmd, .bat)

Windows Installers (.msi, .mst, .msp)

Packaged app installers (.appx)

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.

.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.

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.

Вам также может понравиться

Windows или Linux: Что лучше выбрать?

Есть много причин выбирать между Windows и Linux, но

Файл владелец изменить linux

Команда Chown в Linux Chown Command in Linux (File

Установка шлюза по умолчанию linux

Настройка сети вручную Содержание Краткое описание

Чем разбить диск для linux

ИТ База знаний Курс по Asterisk Полезно — Узнать IP —