In today’s Ask the Admin, I will share my strategy for using AppLocker to block untrusted apps.
Application Control, along with removing administrative privileges from users, is an essential part of your defense-in-depth strategy. Users with local administrative privileges can always find ways to bypass AppLocker and other Group Policy settings. If you are serious about controlling what users can install, the first and most important step is to remove users from the local Administrators group.
Removing users from the Administrators group is not enough to block portable applications. The Google Chrome installer offers users who do not have administrative privileges the option to install the browser for the logged-in user only.
Fortunately, it is enough to enable AppLocker with the default rules to block the Chrome installer. The default AppLocker rules only permit executables to run from trusted locations, such as the Windows directory. Standard users, those that are not members of the local Administrators group, do not have write access to trusted locations.
Google offers Chrome as a Windows Installer (.msi) download for enterprise distribution. The default AppLocker rules allow .msi files to run from publishers trusted by Windows. Google signs the MSI, so it runs. However, unlike the consumer version of the Chrome installer, it will not install Chrome without administrator privileges.
For many organizations, the default AppLocker rules combined with standard user accounts can provide a fair amount of additional protection against malware. AppLocker can be configured to be more restrictive but that can make endpoints harder to manage. How you decide to configure AppLocker depends on what your goal is:
In my experience, AppLocker is buggy. It does not always do what is written on the tin. It does not provide enough flexibility to really lock down an environment while providing users the scope they need to get work done.
The default rules for AppLocker are sufficient to act as additional protection against malware, with the exception of Windows Installer Rules. It allows all trusted .msi files to run. The problem with this is that it might allow a user, in theory at least, to install a web browser from a trusted publisher. From here, any number of vulnerabilities could be exploited.
I prefer to create a series of Windows Installer rules that allow users to install applications from trusted publishers. Rather than use the default Windows Installer rule that allows all signed files to run, I modify the default rule. I only allow files signed by Microsoft, instead of all digitally signed Windows Installer files. I also add additional rules for publishers that I trust, such as Google and Dell.
If needed, I add publisher Executable rules, which allows users to install portable applications from publishers I trust. For example, I could allow users to install Google Chrome but block all other portable apps. You might also want to add Microsoft as a trusted publisher in Executable rules. It is best to avoid creating deny rules, as they always take precedence. If needed, it is possible to create exceptions to allow rules.
For more information on configuring AppLocker, see Setting Application Control Policies with Microsoft’s AppLocker on Petri.