Application whitelisting: Software Restriction Policies vs. AppLocker vs. Window...

Blocking unauthorized programs is one of the most effective measures for defending against malware. To this end, Windows contains three mechanisms for app whitelisting, each with its own strengths and weaknesses.

The spread of malware almost always requires that it can store code locally and then execute it in the context of the logged-on user. This applies to infections via mail attachments and malicious Office macros as well as drive-by attacks when visiting infected websites. It is obvious that consistent whitelisting of legitimate applications will put a stop to this.

Complex maintenance of rules

Although Software Restriction Policies (SRP or SAFER) have been in Windows since XP, the use of app whitelisting is not very widespread.

The most important reason for this is likely that many companies shy away from the effort to create and maintain the required set of rules. If you are not careful enough, you will either have to face numerous calls to the helpdesk to unblock legitimate applications or deal with loopholes for malicious code.

Preventing programs starting from the user profile

Often IT pros think you must explicitly approve all valid applications. However, for solid, basic protection, it is enough to allow applications only from the program and Windows directories and prevent code execution where users have write access.

This blocks all programs the user (unknowingly) downloads from the internet or wants to start from a USB stick. On the other hand, everything the administrator or a software distribution tool has installed on the computer will still run. This ensures that a careless click on a mail attachment does not lead to nasty consequences.

Standard user as a target group

The whitelisting functions cannot fulfill all expectations. Thus, it is almost impossible to prevent local administrators from executing unauthorized software because they can break the lock by stopping services, changing the registry, or using other bypassing strategies.

Thus, effective whitelisting requires that companies follow the principle of least privilege and do not grant administrative rights to normal users. Conversely, reduced permissions alone are not enough to protect against malware because it can cause considerable damage even in the context of standard users, for example, by encrypting their data.

Windows directory with loopholes

But even basic protection is not achievable easily. Thus, just unlocking C:\Windows and all of its subdirectories falls short because there are also folders in which standard users have write access. In addition, attackers can abuse programs normal users do not need, such as cipher.exe .

On the other hand, legitimate applications may need to start from the user's profile, typically a result of poor programming. Microsoft itself provides an example of this with Windows Defender Antimalware .

Rule types based on various criteria

As these examples show, several rules are necessary to allow execution of applications from program and system directories while at the same time preventing users from starting code stored in their profiles. The whitelisting mechanisms provide different rule types for this purpose.

For example, they allow starting applications depending on the manufacturer, the path of the program file, or the hash code for the executable file. In an ideal world, you would just allow signed applications from selected suppliers. But since not all applications will be signed in the foreseeable future, you also have to resort to other means.

For example, you can unlock a trusted, unsigned application in a user directory by generating a hash code from it. But as soon as the file changes even slightly due to an update, you have to update the corresponding rule as well.

Testing rules in audit mode

To avoid complications caused by inadvertently blocked software, most app whitelisting tools offer an audit mode. It logs all events where rules affect applications.

In this way, the administrator gets an overview of which programs are running and which programs whitelisting would block in enforcement mode.

Software Restriction Policies

The SRP (or SAFER) is the oldest Windows mechanism for whitelisting applications. Only this one is included in all versions and editions of the operating system (including Server). Since Windows 7, SRPs only provide for two levels of security, namely Not Allowed and Not Restricted ("Running as a basic user" is no longer applicable).

In addition to rules based on certificates, hashes, and paths, SRP also supports those based on internet zones. The feature does not include a set of pre-existing rules that would already provide basic protection. Rather, it is up to the admin to develop the entire set of rules. However, an audit mode is lacking, with which one could first observe the effect of restrictions.

Another limitation of SRPs is that they cannot block the (relatively safe) Store apps (.appx files). In addition, you cannot define rules separately by file types, such as .exe, batch files, or scripts. They always apply to all types of code.

Finally, you cannot export or import rules. Rather, they are created by default in the Group Policy Object (GPO) editor and saved in a .pol file from where they are transferred to the registry.

Stefan Kanthak's set of rules , available as an .inf file for the different versions of Windows, removes many of the mentioned disadvantages of SRPs. There's detailed annotation for the entries, which you can adapt as needed. It writes the intended values ​​directly into the registry database during installation. Overall, they ensure standard users can only execute programs from places where they cannot save these programs themselves.

For additional reading, I recommend this National Security Agency (NSA) whitepaper .

Windows 7 and Server 2008 introduced AppLocker as the next generation of the SRP. The feature is limited to the Enterprise Edition and therefore is not available to smaller companies if they use the Pro Edition.

Like SRP, AppLocker is managed by group policies. As an improvement over older technology, it comes with a set of standard rules that enable non-administrative users to run programs from %PROGRAMFILES%\* and all directories under %SYSTEMROOT% (but this is not enough considering the problems described above).

Unlike with SRPs, you can define separate rules for different types of executable files: scripts, program files, .appx files, and installers. With the exception of internet zones, AppLocker has the same rule types as SAFER.

Another advantage of AppLocker over SRPs is the ability to assign a rule to specific users and groups. In addition, the feature offers an audit mode in which you can test all rules before you go live. Finally, you can import and export rules in XML format.

What Stefan Kanthak's .inf files are to SRPs is what AaronLocker is to AppLocker. However, the tool takes a different approach with a combination of PowerShell scripts and XML files. The admin creates a ruleset in XML format and imports it into the GPO editor. AaronLocker also has numerous policies that close the gaps in standard rules and prevent bypasses.

Windows Defender Application Control

This is the latest mechanism for whitelisting applications. Up until Windows 10 1709 and Server 2016, Microsoft marketed it under the name Device Guard together with Virtualization Based Security (VBS).

Since then, Microsoft has renamed the VBS part Exploit Guard , and whitelisting is now Windows Defender Application Control (WDAC). However, you can use the latter independently of VBS but at the cost of lower security. WDAC can block code not only in user mode but also at the kernel level (e.g., drivers).

In contrast to the two older technologies, WDAC is more oriented to Microsoft's concept of the Modern Desktop. You can generate policies via PowerShell and deploy them via mobile device management, for example, via the cloud service Intune (although distribution via GPOs is equally possible). This also makes it independent of Active Directory Domain Services.

According to the official system requirements , you need Windows 10 Pro, Enterprise, or Server version 2016 or higher to create rules, and you can apply these rules to all editions. In practice, however, you can neither create nor apply rules on the Pro Edition.

There is no graphical tool for defining custom rules, only PowerShell cmdlets. They allow whitelisting in a concise sense, in which you have to allow every application explicitly. For example, there are no path rules unlike with the two other features.

Also limited is rule targeting, which you can only apply to computers and not to users. If you need user-specific restrictions, Microsoft recommends the parallel use of AppLocker .

Like AppLocker, WDAC supports an audit mode that is active by default when creating a new policy. It stores it in an XML file, which you must first convert to a binary format before deploying it to the target computers.

The script CIDeployment.ps1 by Matthew Graeber provides an introduction to the configuration and also a first impression of the complexity of this task.

Microsoft offers an alternative option to defining your own rules with theintegration of the Intelligent Security Graph. This is especially useful for smaller companies that cannot afford this effort to maintain complex rule sets. WDAC then only runs applications listed as trusted in this Microsoft database.

Are you an IT pro? Apply for membership!