Good practice, Part 3: Application control on Windows clients

In Part 2 of this series, I wrote about local admin rights. But users are able to install some software without admin rights, and malware take advantage of that. In this article I’ll discuss how you should mitigate that problem and strengthen application control for your Windows Enterprise clients.

Some background info.

Have you ever wondered why some software can install without asking for or getting admin permission? Google Chrome and Spotify are examples of that. It is important to understand why you sometime get the admin permission prompt in the first place. If you try to change something that require admin rights, you must be authorized to execute the change. The folders “Program Files” and “Windows” are both protected in the sense that any change requires admin rights. And since most software wants to put something into at least on of those folders, you must be admin to allow it.

But folders in your user directory do not require admin rights in order to change or add anything. So, some software developers make their software install in your user directory to avoid any issues regarding admin rights. I don’t think this is a good approach to software design, but i can understand that some do it, since it will will increase the adoption rate among their customers.

The problem.

Since software can be installed and run from a users directory, you can not be sure that users comply with your software policy. This on its own is a problem, but not the biggest one. It’s a bigger problem that malware creators also create software that will be installed and executed from within the users directory. This can lead to infected computers, without the end user having admin rights.

How to mitigate the problem? Meet AppLocker.

In order to give customers better application control, Microsoft created a white and blacklisting technology called AppLocker, introduced with Windows 7. In order to get AppLocker to work, you must have an Enterprise, Ultimate or Education edition of Windows 7, 8 or 10.

How it works.

Without AppLocker, you can open any executable you have access to, and it will run. With AppLocker you open an executable, and then the operating system asks AppLcoker for approval to run that executable. If everything is OK, the application will start immediately as you are used to.

The above is a very simple explanation on how AppLocker works, but it covers the basic idea. AppLocker also manages msi files, appx and scripts. What AppLocker does not handle, are programs in other formats. Office macros are not handled either. So even if AppLocker helps out a lot in application control, it isn’t bullet proof.

How to implement.

Implementation in a corporation is done via Group Policy (GP). First, ensure that the “Application Identity” service is running on your clients for them to obey your AppLocker rules, via a Group Policy Object (GPO). Then create a base GPO that contain your AppLocker rules. You should also make sure that your rule set is configured as “Audit only”, by right clicking “AppLocker” as seen in the image below, and select “Properties”. Else, I can almost guarantee that your rule set will break someones productivity the day you push the GPO.

Next, make sure you add the default rules that allow everything in “Windows” and “Program Files” to run, and that admins can run everything. I have broken one Windows installation because those default rules were not there. To put it simply – the computer would not boot, and I had to reinstall it. I’m just glad that did not affect all computers in the office. That would be really bad.

The observant reader will notice that i have added an exception to one of my default rules. This is because I do not want users to be able to run PowerShell, since malware can exploit PowerShell, and I don’t want users to be able to edit the registry since that can lead to many issues as well.

Once you have added your default rules, and made sure AppLocker is only in audit mode, you should go ahead and enable the GPO, targeting only a test computer. On the test computer you can now see that everything work, and try to open different applications. You can see what AppLocker does in the background by having a look at the Event Viewer, as shown below.

Adding your own rules. Conditions.

When you want to open up for software to run, you must choose how AppLocker should identify the approved software. Publisher is the best alternative if you can use that. It is based on digital signatures, and can let you allow all software from one developer. This is great since you don’t have to update your rule set each time there is a software update, like another alternative on the list – File hash.

With File hash, you can tell AppLocker to approve a file with a unique fingerprint. This is great since you know exactly what file you are allowing to run, but bad since you must manually update the hash list for each software update. Last, you have Path. Path allows everything in that path and below to run. This should be your last resort, since users then could add any software into that path and be able to run it. You can of course catch such activities in the system logs, but either way, File path exceptions should be kept to a minimum.

When you have added software you want to your rule set, and all is good on the test computer, you should be able to point the GPO to other computers as well. You can collect the AppLocker logs from all computers via PowerShell to see what applications you should allow in your rule set (that you forgot about).

You will probably find that some departments require unique software, only used by them. In that case, you should create another GPO targeting their clients – including the default rules – and add their software in that rule set.

When you have had your rule set in audit only on all computers in your network, and you no longer find any programs that should be allowed to run in your rule set, you can move to from audit to enforce.

Going into production.

I would recommend that you clone your audit AppLocker rule set GPO(s), and change those to enforce. But only target some test computers, and roll out to more and more computers as you see that everything work. You do not want to mess up a lot of computers. AppLocker is a powerful tool. Remember that.