If you would like to read the other parts in this article series please go to:
- Managing AppLocker in Windows Server 2012 and Windows 8/8.1 (Part 2)
- Managing AppLocker in Windows Server 2012 and Windows 8/8.1 (Part 3)
Introduction
AppLocker is a powerful but often overlooked tool for increasing security by restricting user access to applications and other executable files, scripts, Windows Installer files and Dynamic Link Libraries (DLLs). AppLocker was first introduced in Windows Server 2008 R2 and Windows 7; it’s an outgrowth of the old Software Restriction Policies that was included in Windows Server 2003/2008 and Windows XP and Vista. AppLocker is similar to a superset of SRP, with expanded capabilities. In this multi-part article, we’ll discuss the evolution and features of AppLocker in Windows Server 2012 and how to deploy and manage policies, including the use of PowerShell, which is fast becoming the management tool of choice for many Windows administrators.
We’ll begin here in part 1 with an overview of AppLocker, how it differs from SRP, system requirements, and how to get started configuring it.
AppLocker vs. SRP
SRP was a great idea, but it ended up not being used much because it was difficult to configure and could also be circumvented fairly easily by savvy users. If you made a mistake in creating the policies, it could create a nightmare situation that kept users from being able to get their work done and thus negatively impacted productivity. In addition, if you used hash rules to control software, you had to create new rules every time you installed a software update, or you would find your users blocked from using the updated programs. Many network admins threw up their hands in frustration and stopped trying to make it work.
To their credit, Microsoft listened to customers’ complaints and made some big changes when it was time to “re-imagine” the technology for Windows 2008 R2 and Windows 7. To reflect that this wasn’t your father’s SRP, they changed the name to something catchier: AppLocker. One of the major improvements was in version awareness and control. What this means is that you can impose controls to ensure that users can only run specific versions of a particular application. However, this doesn’t mean they won’t be able to update when a new version comes out, as you can specify, for example, version 10 and above. A welcome change for admins was the wizard-based rule creation that made it much easier to create the policies you want.
AppLocker got some improvements in Windows Server 2012, adding the ability to manage policies for packaged apps and packaged app installers. Packaged applications are, as the name implies, a package that contains the functional application along with scripts and other resources to streamline software configuration and deployment. AppLocker can control all the different components of a packaged app with just one rule, in contrast to unpackaged applications and the different components they use (such as .DLL files and installers).
The Windows Server 2012 version of AppLocker adds two more file formats to the types of files that you can control with policies: .mst (files used by Windows to customize installation settings for Windows Installer applications) and .appx (Windows Store app packages, which are a type of code-signed zipped file that contains the application code, script, markup and so forth that comprises modern UI-style Windows 8/8.1 apps).
You might be wondering whether you can migrate your previous Software Restriction Policies to AppLocker. Unfortunately, the two are different technologies so the short answer is “no.” You can, however, use both SRP and AppLocker together in the same domain. That is, you can use SRP for computers running Windows Vista (or XP, if you still run such machines despite the discontinuation of support and security updates – which I strongly recommend against) and at the same time use AppLocker for those machines that are running Windows 7 and Windows 8/8.1. For more information on doing so, see the TechNet article Use AppLocker and Software Restriction Policies in the Same Domain.
Overview
There are many AppLocker usage scenarios, depending on your organization’s specific needs. A good security strategy is based on the principle of least privilege, which involves limiting user access to those resources, files and programs that are necessary for getting the job done, and no more. Software restriction is an extension of that concept, based on the premise that users should be able to run only those applications and other executables that they need in order to do their jobs.
When a user runs an executable, the process will typically run with the same level of access that the user’s account has. If the program that the user runs is malicious, damage can be done to critical data or it can be stolen (sent back to the attacker’s “mothership” by the malware). This is a growing concern in today’s business world, where a data breach can cost millions in lost customers, damage to reputation, civil liability and (if your organization belongs to a government- or industry-regulated field) fines and other penalties.
There are many preventative measures that can be taken to protect against such a data breach. One step is to restrict users from running software that isn’t approved by the organization, which could be malware or old versions of legitimate programs that are less secure than their up-to-date versions. That’s where AppLocker comes in.
AppLocker can be used to prevent users from running outdated software, software that isn’t licensed, software that uses an excessive amount of network bandwidth, or particular applications that either pose a security risk or can waste time and reduce productivity. You can either blacklist specific applications or you can whitelist applications that you do want users to be able to run and block all others. These restrictions can be applied organization-wide or just to a specific individual or a group of users.
AppLocker doesn’t care where the executable file is located, so it will block unauthorized applications from running, whether they’re being run from the local drive, a network drive, a USB drive, etc. Note that you can create DLL rules but you must explicitly enable DLL rule collection; it is disabled by default because you really need to know what you’re doing since DDL rules, if not implemented correctly, can cause trouble with application compatibility. Also be aware that if you do enable DLL rules, this may cause a very large number of events to be recorded in the event log because AppLocker will check every time a DLL attempts to run, to determine whether it is allowed.
Because it’s still possible to create rules with “unintended consequences” when you aren’t experienced with AppLocker (or even if you are), it’s a good idea to test the rules before you actually start enforcing them. You can do this by selecting AppLocker’s Audit only enforcement mode. When you’re in this mode, instead of blocking an application that the rule would normally prohibit from running, it will still run but a warning event will display in the AppLocker logs.
Getting started
AppLocker is based on Group Policy. You can access it through the Group Policy Editor for the domain policy or local computer policy, but it’s pretty well hidden. In the Windows Settings node of Computer Configuration, open Security Settings, then Application Control Policies, and click on AppLocker, as shown in the screenshot in Figure 1.
Figure 1
It’s likely that the first thing that will catch your eye in the right pane is the big yellow triangle with an exclamation point, which is the standard “warning” icon. It’s telling you that the Application Identity Service has to be running on a computer in order for your AppLocker rules to be enforced. You can enable the service via Group Policy for all computers or you change the setting manually on an individual computer through the Services console in Administrative Tools, as shown in Figure 2.
Set the service to run automatically; if the service is disabled or not started, AppLocker won’t be able to enforce policies. This is also a quick way to temporarily suspend enforcement of AppLocker policies if you should need to do so.
Figure 2
Note that you can only use AppLocker with Windows 7 Ultimate or Enterprise editions or with Windows 8 or 8.1 Enterprise. The rules can be created on any edition of Windows Server 2008 R2, Server 2012 or 2012 R2.
Note that there has been a change in that you could create rules (but not enforce them) on Windows 7 Pro computers. This is not the case with Windows 8; you can neither create nor enforce AppLocker rules on the Pro edition. Misleadingly, though, the AppLocker interface is there and it appears to allow you to create rules and select to enforce them, but when you do, they don’t work.
Also note that you can’t create AppLocker rules with computers running Windows Server 2003 or 2008. However, that doesn’t mean you must upgrade your domain controllers because those operating systems can still host AppLocker rules.
Summary
In this, part 1 of a multi-part series, we introduced you to AppLocker in Windows Server 2012/2012 R2 and Windows 8/8.1. In subsequent installments, we’ll take you through the process of planning your AppLocker policies and creating and applying AppLocker rules.
UPDATE: Further experimentation has shown that my statement above, that AppLocker won’t enforce policies if the service is not started, is incorrect. AppLocker will continue to apply the previously applied enforcement policy. To return to default Windows behavior (running applications previously blocked by AppLocker policy), you can apply the default rules or create an enforcement rule to allow what was previously blocked. After applying that, disable the Application Identity services to block newer updates or don’t apply the previous policy to the OU where the computer for which you want to disable the policy resides.
If you would like to read the other parts in this article series please go to:
