AppLocker whitelisting vs. blacklisting

• Author
• Recent Posts

Sami Laiho

Sami Laiho has been a Microsoft Most Valuable Professional (MVP) since 2011 and one of the world's leading IT experts for Windows and security. He has been teaching OS troubleshooting, management, and security since 1996. In 2019 TiVi-magazine chose Sami as one of the top 100 influencers in IT in Finland. For more info, go to https://samilaiho.com.

Latest posts by Sami Laiho (see all)

• Hardening AppLocker - Thu, Jun 25 2020
• AppLocker Audit vs. Enforced mode - Tue, Jun 23 2020
• Creating AppLocker rules from the Windows event log - Wed, Jun 17 2020

Let's start with some myths to bust!

Myth #1: People think AppLocker is difficult—BUSTED

AppLocker whitelisting can be done in many ways. When I enter a project meeting for the first time, my customers often say, "But Sami, we have, like, a thousand different apps to list." I always reply, "But how many folders do you run them from?" When I started the project with a capital city, their list was 8,000 lines, and when I was done, it was down to 72 lines—with the same end result. So trust me, you can do AppLocker in many very different ways.

Myth #2: People think AppLocker adds so much more work that they need to hire more people—BUSTED

One of the first questions in a project I usually get is, "Sami, can you verify that it's OK if we hire two new people to take care of AppLocker?" I always reply, "You don't need to hire new people, but you might have to fire a few."

If you ask me, AppLocker is the tool for the lazy admin. AppLocker frees so many resources from working with reactive incident handling that you will not be working more—you'll be working less. Think of it like this: with whitelisting, you need to add a few rules for GOOD software every month, while the traditional anti-malware needs to add a million lines for BAD software per day (the amount of new malware samples found per day in 2019).

Now let's move from myth busting to some principles I always adhere to.

Some of the most important principles to follow for any whitelisting solution are:

1. Only whitelisting is a security barrier. Blacklisting is not.
2. Effective whitelisting works only when combined with the principle of least privilege (no admin rights for end users).
3. Stick to containers, not items.

Let's look at these in more detail, one by one.

Number 1—Security barrier or not? When I talk to my customers about AppLocker, most say that they have AppLocker but they started with blacklisting. That's not the way to secure your environment. I always say that blacklisting works:

1. Against kids—I use it at home to limit the browsers my kids can use.
2. To extinguish fires—You can use it to block malware123.exe running around your environment.
3. To enforce compliance—You can use it to block app versions that you don't support.

But for actually protecting an environment, it's useless. To protect against malware, you would have to list a million new things per day—just like traditional anti-malware tries to do.

Blacklisting is not a security barrier, but is only good for compliance and extinguishing fires

Number 2—Whitelisting requires the principle of least privilege. The 1993 user guide of NT 3.1 said, "In Windows there is no security if you are using admin rights." Removal of admin rights has been the most recommended (or second most recommended) security principal by security companies for years. Also, Group Policy documentation says that GPOs can be used to enforce settings for limited users only.

So just keep in mind that the security subsystem of the NT operating systems has not been built to operate with admin rights. When it comes to AppLocker, an admin can bypass the whitelist in multiple ways. One of them is disconnecting the computer from the network and then disable the whitelist by deleting the content of C:\Windows\System32\AppLocker and. To be fair, that might be an important troubleshooting step sometimes.

The most important reason for this is to limit the number of rules. Let's say you have 800 apps in C:\Program Files\. If you don't have admin rights, you can just add one rule to allow everything from C:\Program Files\ as limited users can't add anything there (many apps break this but we'll deal with this later). If you had admin rights, you would require hundreds of rules.

You can safely allow everything from Program Files to run as long as the user doesn't have admin rights

Number 3—Stick to containers, not items. Always aim to add a trusted location or provider instead of a single binary. Just keep the list short and easier to manage. Trust me—you and your end users will love whitelisting a lot more this way. When whitelisting first started to become a widespread security feature in ~2005, it failed because everyone said that you would have to list every binary with a hash rule that would have to be changed with every patch-Tuesday or other update. These days, we don't do whitelisting like that. We trust Microsoft instead of Notepad, and we trust C:\Program Files\ instead of every app in it.

The old way of whitelisting would require 190+ rules for just the Program Files folder. Today, we just list the folder and prevent users from changing its content.

I think it is clear that AppLocker whitelisting is a better choice than blacklisting. In my next post, I will outline the steps to follow for a successful AppLocker deployment.