Implementing Software Restriction Policy

This article is aims to be a comprehensive guide to creating a secure Software Restriction Policy and is quite a long read – we recommend you bookmark it now so you have it to hand when you need it.

Securing your environment is a huge deal these days. Whereas we have all for a very long time concentrated on maximizing performance – looking at how we create the best possible “user experience” – security is another big concern for consultants, architects and administrators. Ensuring that an attacker cannot move laterally through a compromised network is crucial – if penetration occurs, we need to make sure that it is as difficult as possible for the attacker to broaden the scope of their attack and gain a deeper foothold into your environment. All breaches involve some form of pivoting which generally involves running utilities which shouldn’t be allowed to run in hardened environments.

Controlling what a user can execute is a pivotal part of this approach. In an “open” environment, an attacker within your network can introduce their own executables and scripts, opening up possibilities for further compromise and move closer towards the Holy Grail of accessing all of your data and infrastructure. But if you are strictly controlling what users can execute, not only do you block the attacker from escalation, but you can also identify possible indicators of compromise simply by the very action of attempting to run these items. So not only does effective application control protect you, it adds a further layer of alerting that can spot an attack in its early stages.

Before We Begin

If you find this post useful you’re going to love our weekly newsletter. Every monday we send the best 5 Active Directory security links we’ve read each week. Stuck on something? Just search your inbox for our newsletter plus your term and you’ll usually find an answer.

Whitelisting and blacklisting

Simply put, blacklisting is where you stop users running “known bad” applications. For instance, you could blacklist executables such as PowerShell, the Registry Editor, known exploit tools like Metasploit or utilities that hackers might leverage such as the PSTools suite. But the problem with blacklisting is pretty obvious – you are reliant on knowledge of every possible executable that a hacker might use, and need to then add it to your blacklist. You become tied into a game of whack-a-mole, an arms race of constantly updating the list of threats to be kept at bay.

Whitelisting, on the other hand, removes a lot of the overhead from this by using the opposite approach. Instead of listing out the “known bad” executables, whitelisting operates by blocking *everything* except applications you specifically know that users need to execute in their day-to-day jobs – a “known good” list instead. If a new tool is identified that you want to prevent users from running, there is no update required – a whitelist blocks unknown executables by default.

There are nuances within the whitelisting approach that we will discuss. You can block by path, by certificate/publisher, by network zone, or even by file hash. Each one of these options has pros and cons attached to them. There are also differences in deployment and management that you will want to consider.

Tools for application whitelisting

There are many application whitelisting solutions out there available from third parties. However, if you are using an enterprise version of Windows and/or Active Directory, there are two options that will always be available to you at no extra cost. We will discuss later on about certain third-party tools that can extend the functionality of these core Microsoft offerings, but for now, we will concentrate specifically on these built-in tools. The older version (which shipped with Windows XP) is called Software Restriction Policies (SRPs), and its slightly newer, more updated cousin is called Application Control Policies (AppLocker). There is an even newer tool in the arsenal as well, called Microsoft Defender Application Control (MDAC).

There were two black- and whitelisting GPOs that predated SRPs, AppLocker and MDAC – Don’t run specified Windows applications and Run only specified Windows applications. Both of these sit in User Configuration | Policies | Administrative Templates | System and were the only options available for Windows 2000. However, they only apply to processes started from File Explorer directly – running programs from the command prompt, Task Manager, PowerShell or from any other already-running process allowed these GPOs to be bypassed, therefore, we will not discuss their usage here.

Note: We are using the term whitelisting and blacklisting in this post because it’s still the preferred terminology used by Microsoft. After this we will revert to using our preferred synonyms: block list and allow list.

Understanding the user environment

However, before you begin to formulate an application whitelisting policy, it is very important to understand precisely the sets of applications that your users need to use. Blocking without preparation can easily lead to chaos as line-of-business applications stop functioning, and this will have a terrible knock-on effect for your user experience. You should never implement application whitelisting without proper planning and testing!

Obviously, you need to have enterprise versions of the Windows OS on your clients and be running a version of Active Directory that supports either SRPs or AppLocker (if you are going to deploy centrally via GPOs). You can deploy SRPs and AppLocker policies without AD, but it would involve configuring local policies on each machine and therefore has a very big overhead. For the purposes of this article, we will assume that deployment is being done via AD (although the policy settings would be the same if done locally).

For the auditing aspect, you can either use the audit features provided by SRPs or AppLocker, or you can use a third-party monitoring tool. The audit features in SRPs are (practically) non-existent, but there is a proper Audit Mode in AppLocker. However, in an ideal world a central monitoring tool would be best, in order to give you full visibility of what is being run. If you are using a SIEM (Security Information Event Management) tool you can possibly parse the entries that AppLocker or SRPs produce without having to deploy a specific monitoring tool. It is up to you which approach you choose to build the initial list of “allowed” applications. For posterity, SRP produces log files, AppLocker produces event log entries, and a third-party monitoring tool should provide proper reports. If you were looking at third-party tools, then there are many out there – uberAgent, ControlUp, eG Innovations, Goliath Technologies, SCCM, Lakeside SysTrack, Nexthink are some of the ones I have worked with, but there are many, many more.

The techniques described here allow you to whitelist certain key system areas (like the Program Files folder) without needing to formulate an exhaustive list of executables that lie within them, so the process can be slightly less intimidating than it first may seem. However, it is vitally important that you capture all required executables, as some of them run from places you might not expect (such as Teams, Chrome, DropBox, Slack, etc.)

An example of a non-standard application launch being blocked

Differences between SRP and AppLocker and MDAC

MDAC is intended to eventually replace AppLocker and SRPs, but for now, it is undergoing development. For now, it is recommended to use WDAC alongside AppLocker or SRP until it develops to such a state as to fully replace them. The main drawback is that WDAC cannot currently apply policies for different users or groups on shared computers. As a best practice, you should enforce WDAC at the most restrictive level possible for your organization, and then you can use AppLocker or SRP to further fine-tune the restrictions.

MDAC shows some of its inadequacies in these situations: –

• Applying different policies for different users or groups
• Mixed Windows OS environments
• Avoiding the restriction of DLLs and drivers

However, longer-term MDAC will replace both AppLocker and SRPs. It already has some features that work above the capabilities of AppLocker and SRP, such as restricting kernel-mode drivers and preventing administrators from being able to turn off the protection.

When comparing AppLocker and SRP, they have a number of functional differences, as listed below:

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 Server 2012 , Windows 7, Windows 8, Windows 8.1, Windows 10, Server 2016 and Server 2019.
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 are allowed to run by default.   SRP can also be configured in the “allow list mode” such that the 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 “allow list 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:   – Executables – Dlls – Scripts – Windows Installers SRP cannot control each file type separately. All SRP rules are in a single rule collection.	AppLocker can control the following file types:   – Executables – Dlls – Scripts – Windows Installers – 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. Administrators can add extensions for files that should be considered executable.	AppLocker does not support this. AppLocker currently supports the following file extensions:   – Executables (.exe, .com) – Dlls (.ocx, .dll) – Scripts (.vbs, .js, .ps1, .cmd, .bat) – Windows Installers (.msi, .mst, .msp) – Packaged app installers (.appx)
Rule types	SRP supports four types of rules:   – Hash – Path – Signature – Internet zone	AppLocker supports three types of rules:   – Hash – Path – Publisher
Editing the hash value	SRP allows administrators to provide custom hash values.	AppLocker computes the hash value itself. Internally it uses the SHA1 Authenticode hash for Portable Executables (Exe and Dll) and Windows Installers and a SHA1 flat file hash for the rest.
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 which allow administrators to create rules such as “Allow everything from Windows except for Regedit.exe”.
Support for audit mode	SRP does not support audit mode. A limited logging mode can be configured (see later) but it is somewhat unreliable.	AppLocker supports audit mode which 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 the user-mode which is less secure.	Internally, AppLocker rules for Exes and DLL files are enforced in the kernel-mode which is more secure than enforcing them in the user-mode.

Software Restriction Policies

Let’s start by looking at the old-timer, Software Restriction Policies. Software Restriction Policies are not as granular as AppLocker rules, in that they cannot be applied to specific groups of users (so, for instance, allowing UserA to run an application, whereas UserB cannot, is not possible with SRPs).

Software Restriction Policies can be run in either a blacklist or a whitelist configuration. It relies on a “Default” rule setting with “Additional rules” that then override the defaults. So, if you wanted a “blacklist” configuration, you would set the default to Unrestricted and configure Additional Rules for executables you wanted to block. For a “whitelist” configuration, you set the default to Disallowed and configure Additional Rules for executables you want to run.

Let’s have a look at how we would set up a simple Software Restriction Policy in a whitelist configuration.

Firstly, create a Group Policy Object and link it to the OU containing the computer objects that you wish to apply the SRP to.

Browse to Computer Configuration | Policies | Windows Settings | Security Settings | Software Restriction Policies. Right-click the node and choose New Software Restriction Policies

This will then create the rules for you underneath the main node.

Global options

In the right-hand pane, you will see a number of options you can configure at a global level

Security Levels and Additional Rules we know about and will come to in a moment. Firstly, though, right-click on Enforcement and choose Properties, and you will see this dialog

The first option should generally be set to “All software files except libraries”. If you start applying application controls to DLL files, you may find problems as you will need to list all libraries used by a program. Now if you have the “additional rules” correctly configured, then that doesn’t include DLL files from the Program Files or Windows\System* directories, but even so, it can be a lot of overhead and potentially problematic. I would only turn on DLL-level checking in high-security environments where you have total control over every file in use.

The second option, Apply to all users or all users except local administrators, is up to you to decide. If you are in an environment where administrators routinely log on to and perform troubleshooting on client devices, then make them exempt from the SRP rules. However, if you are in an environment where all troubleshooting is done remotely via a privileged-access station (which, ideally, it should be), then you can apply the restrictions to administrators as well. Alternatively, you can whitelist all of the administrator tools as well, but bear in mind that because SRPs are not flexible by user this will allow ordinary users to run these tools also. One thing to bear in mind here is that if you select “all users except local administrators” this means that installations, for instance, can be triggered by right-clicking and choosing Run As Administrator. Choose the option that makes the most sense for your environment.

The final option is whether to enforce certificate rules. If, in the Additional Rules section, you are using certificate-based checking, then you will need to enforce them here. The caveat about performance refers to the need to check a certificate revocation list (CRL) every time a program is run. It also means that the CRL (usually held online) needs to be accessible from the client, so environments with internet access blocked may struggle if this option is enforced. Choose the option that matches your requirements.

Next, right-click on Designated File Types and choose Properties.

This dialog shows you what file extensions are considered to be “executable code” by the SRP. Notice that .exe, .dll and .vbs are considered executable by default and cannot be removed. All of the others in the list can be removed, or added to.

There are a couple of notes worth calling out. Firstly, that .ps1 is not listed as an executable file, so you may want to add that (PowerShell script – for the record PS modules are not listed either). Also, .lnk is listed as an executable type, so even if you have an executable that is allowed, the actual shortcut (because that’s what .lnk files are, shortcuts) will not be allowed to run that points to the executable. I normally remove .lnk from the list and add other modern filetypes that I feel are necessary to manage.

The final option is for management of Trusted Publishers. This can allow or disallow whether users or administrators can manage adding trusted publishers (for instance, if they were to download an application from a publisher’s site). It also, optionally, allows you to enforce a CRL on the trusted certificates. Again, choose the options which are relevant to how you wish to manage the environment.

Security levels

Next, browse into the Security Levels folder and you will see three settings.

The default is set to Unrestricted, which is a “blacklist” model. Right-click on Disallowed and choose “Set as default”. You will get a warning – just click on Yes.

“Basic User” is a setting which does not work any more, so do not use it. In modern Windows environments “Basic User” simply functions the same as “Disallowed” does.

This now means that everything will be blocked, subject to a) the options configured under your global rules, and b) any Additional Rules configured with a security level of Unrestricted.

Additional Rules

In a whitelist situation, you configure Additional Rules with a Security Level of Unrestricted to allow executables to run.

When you create a new SRP, the following two paths are listed as Additional Rules:-

These odd-looking Registry/variable Path Rules are meant to allow any executables from the SYSTEMROOT or PROGRAMFILES variables. However, these paths predate the arrival of x64 computing and often will mean anything in the x86 Program Files folder will be blocked. I delete the default Path Rules and replace them with those shown below:-

This ensures that files in the system areas can execute without needing to provide an exhaustive list prior to deployment. Make sure that the “Security Level” is set to Unrestricted – this is how you configure a whitelist. Using “Disallowed” is for a blacklist approach and if you inadvertently combine this with a global “Disallowed” policy you will break the devices it applies to!

Population of the Additional Rules section is where your understanding of execution areas will become paramount. For instance, in our image we use App-V applications. These applications do not execute from Program Files or the SystemRoot areas – they have their own cached location. If we try to launch one, we see the standard SRP block screen (below)

If you then check in the Event Viewer under Application log and look for an event ID 865, it will tell you the path of the executable which was prevented from running

We can see here that all of our App-V apps run from C:\ProgramData\Microsoft\AppV\Client. So we need to add a new Additional Rule that allows this path. Notice we have substituted the environment variable ALLUSERSPROFILE for the c:\ProgramData path

Once this is saved into the GPO SRP and a group policy refresh takes place, we should find we can now execute the App-V apps. One thing worth noting with SRPs, though, is that often the user has to log out and back in before the updated policy will take effect.

So now only executables residing in our specified paths can be run. For instance, I can run regedit.exe without issue, because it is in the %SYSTEMROOT% folder…

…but if I then copy regedit.exe to the %USERPROFILE% path and try to run it, it now fails

Path Rules versus Certificate versus Network Zone versus Hash

Simply allowing Paths is the most basic way to allow executables to run. However, this can potentially be subverted by an attacker creating files within the allowed Paths, even with the same name as expected executables, if you have restricted by exact name.

You can further tighten the security by restricting by other methods. Certificate rules allowing you to allow executables to run only if they are signed with an allowed publisher’s certificate.

Network Zone rules allow you to specify particular internet or intranet locations that MSI files can be executed from. This rule is quite niche and I would not generally recommend its usage.

The most useful from a security perspective is the Hash rule. This actually takes a hash generated from a specific executable and ensures that this hash is matched before an executable is allowed to run. This is very useful in high-security environments where you may be interested in also stopping compromised administrator accounts from executing untrusted code. However, there are caveats. The list of hashes must be updated every time an application is patched – so, if you allow Teams.exe to run via a Hash rule, and then a new version of Teams is downloaded, the hash value will need to be updated before it can run.

I generally use SRPs with a combination of Path and Hash/Certificate rules. Path rules are allowed for the installation and system directories, as the only people who can modify files in these locations belong to the Administrators group. If you have executables that need to run from outside these locations (maybe a piece of software that executes from the USERPROFILE location, as far too many do these days), then use a Hash rule to allow it (or use a Certificate rule if the executable is regularly changed, or downloaded afresh at each launch). Don’t forget, if SRP rules conflict, Hash rules take priority over all others.

However, if you are in a high-security environment where Administrators also need to be subject to the rules, then creating Hash rules for every executable would be the way to proceed. This is a high-maintenance approach but it ensures that a compromised admin account cannot circumvent the rules – only the users who can add new Hash rules into Active Directory would be able to achieve this.

Loopholes in system folders

Sometimes Windows allows users Write access to system folders. This means that potentially, a user could drop out an executable into one of these folders and execute it, bypassing the rules because of the default allow configured for the system folders. There are multiple layers of defence that may protect you from this – antivirus, Windows file blocking, SmartScreen, etc. – but given that our job is to anticipate attacks that sometimes bypass these layers, it is an avenue worth testing.

Examples of these folders (on Windows 10) include

• C:\Windows\tracing
• C:\Windows\Registration\CRMLog
• C:\Windows\System32\Microsoft\Crypto\RSA\MachineKeys
• C:\Windows\System32\spool\drivers\color
• C:\Windows\SysWOW64\Microsoft\Crypto\RSA\MachineKeys
• C:\Program Files (x86)\Google\Chrome\Application\SetupMetrics
• C:\Windows\Tasks
• C:\Windows\System32\Tasks

You can use the SysInternals tool accesschk to identify folders that users have write access into.

If it is found that users can move executables to these folders and run them, then you would need to create new Path rules with “Disallowed” set as the security level to override the Unrestricted rules. An example is shown below

This will then enforce the blocking of any executable content from the folders that users can place files within.

SRP discovery mode

As mentioned before, SRPs really don’t have a “discovery” or “audit” mode that can help with the initial view of what executables your users access. What you can do is turn on a Registry key that performs SRP logging. Create a GPO Preferences Registry Item that adds the following value:-

• Action – Replace
• Hive – HKLM
• Key Path – SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers
• Value Name – LogFileName
• Value Type – REG_SZ
• Value data – path to the log file (local to the machine, preferably)

Then, switch the Security Level back to Unrestricted and delete all of the Additional Rules. Be very careful here – if you delete the Additional Rules and leave the Security Level as Disallowed, you will effectively have broken your machine. You will be unable to even run a gpupdate to reverse the settings, so make sure you have a backup or snapshot before doing this!

This will then log out to the specified file as rules are allowed to run but be warned – this process seems a little hit and miss.

Software Restriction Policies in action

For an example of the SRP in action, we will get a user to try to execute MimiKatz (a well-known Windows exploit tool).

We can see the user trying to run the executable from the network, from a local location, and then show the event logs that indicate the executable was blocked by SRP

There is also the capability for a savvy attacker to try and load the mimikatz library from an allowed executable, such as regedit.exe. If the attacker could copy the dll into the system, and then add it to the Security Support Provider list by editing the Registry (which would require admin privileges), it would be possible to leverage the functionality of tools like mimikatz in a way that would bypass the “standard” SRP. Below, we can see the loaded library compromising a Windows domain admin password after being loaded.

If this attack vector is feasible, then the “block libraries” function from the global options would be the way to protect against it.

Once we have applied the “block libraries” option at the global level, the mimikatz dll can no longer be loaded and therefore passwords are not intercepted.

We know this is effective because the kiwissp.log file which holds the output from the dll is no longer present on the system. However, an annoying feature of SRPs is that when a library is blocked, no data is written to the event logs. You may get application errors within the user interface as below, but no logging is maintained as to what has been blocked from loading.

AppLocker

AppLocker is, as already stated, a slightly more granular approach to application whitelisting. AppLocker is configured in the same way, by using Group Policy Objects.

AppLocker setup

As a pre-requisite for any AppLocker deployment, the Application Identity service must be started on the target devices. This can be done within the image or alternatively via GPO.

The actual GPOs themselves to initiate AppLocker are located in Computer Configuration | Policies | Windows Settings | Security Settings | Application Control Policies | AppLocker

Similar to SRPs, you begin by configuring the level of “rule enforcement”. You can “enforce” for standard executables, Windows Installer files, Scripts, or “Packaged Apps” (which refers to Universal Windows Platform apps). The main difference from SRPs is that you have the option to configure “Audit only” rather than the blanket “Enforce rules” option. It is recommended to always run in “Audit only” mode for a period of time so that you can identify what is being run, what needs to be blocked and what may need to be allowed.

Like SRPs, the base rules also have a “DLL rules” option similar to SRPs. This allows you to control libraries as well as standard executable content.

Beneath the base AppLocker node where you configure the enforcement level, you have separate nodes for Executable, Windows Installer, Script or Packaged App Rules. This operates the same way as SRPs – you can configure Allow or Deny Rules here to override those configured at the base level.

You can also create Automatically Generated Rules (so, for instance, you can point at a particular folder and the AppLocker rules will be generated for all content in that folder). Like SRPs, you can either use Path or Hash for the generated rules.

You can also create “Default Rules”, again, much the same as SRPs in that it will automatically generate rules for common areas like Program Files and the Windows folder

Now, AppLocker is a bit cleverer than SRPs in that both the x86 and x64 Program Files directories are allowed by the “Program Files” default rule. However, folders such as the App-V programs folder, are not within the Default Rules and would need to be added.

The added granularity of AppLocker starts to show here though – as well as creating rules here, and applying them as Publisher, Path or Hash, you can also apply the rules only to specific users or groups of users, or you can configure exceptions to the rule as well.

Exceptions allow you to allow specific content that would normally be caught by the rule

You can see right away that the flexibility of AppLocker makes it infinitely more preferable to a standard SRP. You can get very granular with what you allow or deny, and configure settings targeted to specific users without having to get into any GP-level targeting. It can allow you to configure a very flexible approach.

In the same way, you also need to be very careful with the auditing and testing to ensure that you don’t block any content that users will need. Running with the “Audit only” feature turned on over a period of time will allow you to build lists of what users are using and what you need to block. This will also drive the selection of Path, Publisher or Hash rules to see what is appropriate for your environment.

If you run in Audit Mode it is very important to regularly collect and review the AppLocker event logs to see what is being restricted. You will find these at Windows Logs | Applications and Services Logs | Microsoft | Windows | AppLocker. Look for 8002 (allowed execution) events and 8003 (which would have been a disallowed execution, but was allowed because of Audit Mode). If you are deploying at scale, collecting and collating these events centrally is a very good idea.

Once you’ve identified what you need to allow to run, then you can create your rules and switch to Enforced.

A word of warning – don’t get tempted to block all “Packaged apps”. Whilst nobody cares much for UWP apps, blocking them through AppLocker can have side-effects. UWP apps includes Cortana, Settings, and the Start Menu! So if you want to block Packaged Apps – make sure you configure the Default Rules!

Once you’ve switched to Enforced you should see hard blocks appearing for things outside of your configured execution scopes.

With regard to AppLocker, many of the principles discussed in the SRPs section apply – we have just added the capacity for a proper audit mode and much more targeted granularity of the settings.

AppLocker in Action

Again, let’s show a user trying to copy mimikatz.exe down to their local profile and executing it.

This time you will generate an 8004 error in the event log indicating a hard block.

As we did in the SRPs section, the same “advanced” attack vector (loading the mimikatz dll with local admin access) can be used to try and harvest passwords. Again, the resolution is to turn on dll execution blocking to prevent the library from being loaded.

With AppLocker, when you turn on dll execution, you get a fifth section available for use:

And if you configure this correctly, you can then stop the unsanctioned library from loading. Unlike SRPs, though, AppLocker successfully logs both allowed and disallowed library loading in the event log under the relevant IDs.

Extending AppLocker functionality with third-party products

There are many products out there that either leverage or extend the AppLocker functionality.

Citrix Workspace Environment Management (WEM) replicates most of the AppLocker power but allows you to target it in a more granular fashion, therefore applying AppLocker rules based around more specific conditions than is available natively in Group Policy. Citrix WEM is available as an on-premises or cloud service as part of specific Citrix license entitlements.

PolicyPak Least Privilege Manager allows you more options around controlling execution, by allowing you to whitelist apps for certain users in certain situations where execution may be desirable (or even allowing them to elevate their access to complete certain tasks). PolicyPak is a licensed extension for Group Policy.

Ivanti User Workspace Manager Application Control (formerly AppSense AM) combines the advanced targeting you get in WEM with the execution control you get in PolicyPak. Whilst this does not leverage the AppLocker engine directly and instead uses its own filter driver, the concept of stopping execution is the same. The UWM suite is a user environment management family of products and Application Control is available as part of this or on its own. Application Control is a pretty advanced product that allows much more finely-tuned control and features.

Microsoft Defender Application Control

Microsoft Defender Application Control (formerly Windows Defender Application Control) is an evolution of AppLocker designed to avoid the most glaring issue with AppLocker – that system processes and device driver execution cannot be controlled. MDAC was one of the features that was formerly known as “Device Guard” in Windows 10. It currently runs on Windows 10 or Server 2016 and higher (although the 1903+ version of Windows 10 is recommended for full features).

MDAC policies apply to the device as a whole rather than users but introduce some cutting-edge new features for application whitelisting:-

• Using attributes of the codesigning certificates to allow or disallow execution
• Using advanced features of the executable, such as filename, version, hash or metadata
• The application’s actual reputation, sourced from an online security repository
• The parent process that launched the application

Whilst it does not yet offer the flexibility that AppLocker does, it seems certain that MDAC will evolve to supersede AppLocker in the coming years. For now, if you have devices that can support MDAC, it is recommended to use MDAC as the baseline and AppLocker to fine-tune the requirements. Eventually, MDAC will become the standard that AppLocker is now.

Currently, though, bear in mind that it is pretty new and there will be bumps in the road. I’ve heard tales of it breaking InTune app deployments and some minor issues with Office add-ins.

Summary

So, what’s my advice around application whitelisting?

Firstly – do it! Whitelisting gives you so much more protection, even if you can only do rudimentary path-based whitelisting. ANYTHING that puts obstacles in the way of an attacker increases your security posture. The more hoops they have to jump through, the more chance you have of spotting them before they can move laterally and do damage.

Obviously, plan carefully. There’s nothing guaranteed to put users off a solution faster than making their lives as misery with it. Audit your environment carefully and make sure you have at least 80-90% of the applications covered before you go live.

SRPs are really long in the tooth these days, so generally I wouldn’t recommend using them. Especially with even AppLocker looking like it will eventually be replaced, leaning on SRPs, dated as they are, is not recommended. The lack of proper auditing should be enough to put anyone off.

AppLocker is pretty much the tech of the moment – it is granular, well-documented, reliable, and flexible. Whether on its own or used alongside something like WEM or PolicyPak or even replaced entirely by a product like Ivanti Application Control, it is not to be sniffed at. In a traditional environment where you have a blend of operating system types, AppLocker is probably the right choice for you.

However, if you’re pretty up-to-date, then a blend of MDAC and AppLocker will do better. The advanced security features of MDAC will eventually replace AppLocker and adopting these sooner rather than later will be good. MDAC has not reached maturity yet, but when it does, expect it to subsume AppLocker pretty rapidly. Be ready for that switch moment!

Try pwncheck. our password audit tool, it’s completely free to download and run. Provides you with the number of pwned users in just a few seconds.