Application Security Redux: It’s All about the Apps (Part 4)

by [Published on 1 June 2016 / Last Updated on 1 June 2016]

In this Part 4, we'll be delving into Microsoft’s AppLocker, which was introduced in Windows 7 and Server 2008 R2 and grew out of the previous Software Restrictions Policies feature.

If you would like to read the other parts in this article series please go to:

Introduction

In this article series, we got started in Part 1 with a broad overview of application security, and specifically the different components of an effective and comprehensive application security strategy and began to address some of the different types of application security issues, then focused on coding defects, how they occur, types of app vulnerabilities, and how to prevent or fix them. In Part 2, we started with a look at how to protect applications from tampering or access and also took a closer look at the special case of mobile applications. Then in Part 3, we started our discussion of how you can block undesirable applications and restrict what users are able to do with the apps that you do allow them to use.

The evolution of SRP to AppLocker

Windows Server 2003 and Windows XP introduced Software Restriction Policies (SRP) as a policy-based means of identifying the software applications and utilities installed on computers and giving administrators the ability to control whether individual programs are allowed to run. SRP was integrated with the operating system as a part of Windows Group Policy.

SRP was a great idea, but as implemented, many IT admins found it to be difficult to use. With four different types of policies, it could be confusing as to which one was appropriate to use in a given situation. SRP allowed you set hash policies, certificate policies, path policies, and zone policies, but even if you were able to figure out which one to use and get it configured correctly and working properly, none of these really offered a fool-proof way to control the software, and only certificate policies provided much reliability.

Because the types of SRP rules are applied in a specific order (the order in which they’re listed in the paragraph above, with default rules applied last), you might find that some of your rules override others. Troubleshooting the problem when the policies don’t work the way you expect them to – whether by restricting applications that should be or by not restricting those that should – can be an exercise in frustration.

Policy conflicts were also common with SRP, with domain settings overriding local police settings, and all too often, admins found that if they weren’t very careful in constructing the policies, users would find themselves locked out of the programs that they needed to do their work. Sometimes, when files or programs that are needed to start up the computer are inadvertently set to be disallowed by SRP, users aren’t even able to log onto the computer at all.

Thanks to all of the above, many admins who started out excited about SRP gave up on trying to make it work. Microsoft, as so often happens, had good intentions but didn’t quite get it right the first time. They do, however, tend to listen to customer feedback (eventually). After watching customers struggle with SRP in Windows XP and Vista, despite minor tweaking along the way, they decided to change the name and give the feature a real makeover. Thus Windows 7 and Server 2008 R2 sported a shiny new version with a catchier name: AppLocker.

The AppLocker Difference

So what’s different about AppLocker and does it solve the problems that plagued SRP? Certainly Microsoft made some significant improvements. You get more flexibility and more control with things like version awareness and control, with which you can set minimum versions of applications that are allowed. Instead of restricting the allowed software to just one, current version, this feature makes it possible for users to update their apps when needed, and prevents them from running old, probably unsecure versions.

Microsoft also took the time to make AppLocker more user-friendly, so that instead of having to wade through Group Policy settings, much of the rule-creation process is automated through the new utility. Further, once you have those rules in place, you can export them and then import them into another computer that’s not part of your domain, rather than having to duplicate the effort.

Most important is that AppLocker policies are not as easy for users to circumvent as SRP; however, users with local administrative privileges will be able to get around them. Of course, best practices is to give admin rights only to those who must have them. Sometimes, of course, it might not be possible to follow this guideline (as when the person who doesn't need but wants administrative control over his/her computer is the boss).

There are two very different (actually, exactly opposite) basic ways to control which applications are allowed to run:

  • Blacklisting (providing a list of applications that you don’t want to be allowed to run, with all others allowed), or
  • Whitelisting (providing a list of applications that you do want to be allowed to run, with all others blocked).

If you think about it, it’s obvious that the second method is the more restrictive, and thus the more secure of the two. For that reason, AppLocker is designed around this principle of “allow only what’s needed.” This helps to ensure that undesirable applications that you might not have thought of (or might not have even existed at the time you made the list) won’t be inadvertently allowed. Of course, it is also likely to cause more user dissatisfaction and in some cases prevent them from running apps that they actually need for their work.

What this means is that when you create rules in AppLocker that grant permission to run a particular application, AppLocker will automatically allow only the application(s) you specified, and block everything else. When you access the AppLocker console, you’ll see a warning to that effect in the “Getting Started” section. Failure to understand this can result in denying users access to apps that you never intended to block. Keep this caveat in mind when using AppLocker to control the use of applications.

As for how to do that, AppLocker is configured through the Group Policy Object Editor or the Local Security Policy console. Although AppLocker is a bit easier to deal with than SRP, there are still a few “gotchas” to be aware of. For example, before you can enforce AppLocker rules, you have to enable the Application Identity Service, which by default is not set to start up automatically. You can enable it to do so either at the local level or at the GPO level.

Once that’s done, you can use the Configure Rule Enforcement link in the AppLocker console to get to the Properties dialog box, where you can select to enforce AppLocker rules for any or all of the following:

  • Executable rules
  • Windows installer rules
  • Script rules

You can set each of these to actually be enforced, or you can set them to “audit only,” which is the safer course of action when you’re just learning about AppLocker. In this mode, the rules aren’t enforced but applications that would have been denied by the rule are logged in the AppLocker event log. This allows you to test your rules without the danger of locking yourself out of the system entirely. Note that you can also enable DLL rules, but this is an advanced function and one that you need to be very careful about. Read the Microsoft documentation thoroughly and make sure that you understand it before attempting to implement DLL rules.

AppLocker generates a set of default rules that allow the files in the Windows folder and the Programs folder to run, and you can modify these to fit your organization’s needs, and create your own custom rules. AppLocker includes a wizard that will walk you through the process of creating a new rule, or you can right click a rule and select Properties, and make changes within the dialog box. Rules contain actions (allow or deny), the user(s) or group(s) to whom the rule is to apply, and the path to the file or folder that the rule will apply (for a path-based rule), the hash of the executable file (for a hash-based rule) or for publisher rules, the digital signature that is based on the publisher, product name, file name and version. You can also create exceptions to the rules.

AppLocker can also be configured using PowerShell cmdlets. Windows 10 adds a few new features to AppLocker, including a new parameter in the New-AppLockerPolicy cmdlet, with which you can control whether executable and DLL rules collections apply to non-interactive processes. In addition, you can now manage Windows 10 mobile devices using the AppLocker CSP (Configuration Services Provider). Next time, we’ll take a look at these new Windows 10-specific features.

Summary

As we started our exploration of Windows AppLocker and how it can be used to control which apps are allowed to run, we started with the history of AppLocker and its previous incarnation as Software Restriction Policies. We then provided an overview of how AppLocker works and the different types of AppLocker rules that can be created and applied. In Part 5, we’ll delve into the use of PowerShell to configure and manage AppLocker and the new ability to control apps in Windows 10 mobile devices via the CSP that was added to AppLocker in Windows 10.

If you would like to read the other parts in this article series please go to:

See Also


The Author — Deb Shinder

Deb Shinder avatar

Debra Littlejohn Shinder, MCSE, MVP (Security) is a technology consultant, trainer and writer who has authored a number of books on computer operating systems, networking, and security.