Microsoft has tacitly declared that the default ‘status-quo’ security model for Windows simply isn't enough. With Windows 7, Microsoft has introduced new technology, dubbed AppLocker, that further legitimizes application whitelisting as the anti-malware approach of the future. But does the technology, as delivered from Microsoft, have what it takes for IT administrators to give it true enterprise-wide adoption? This paper, written by Jeremy Moskowitz, MCSE, MCSA, Microsoft Group Policy MVP and Chief Propeller-Head for Moskowitz, Inc, helps IT Practitioners and IT Managers learn: How to implement and leverage AppLocker to perform application whitelisting, The limitations inherent within AppLocker, and How other tools — like BOUNCER by CoreTrace — can fill in the gaps that AppLocker leaves.

1. Application Whitelisting: Microsoft AppLocker and Beyond
By Jeremy Moskowitz, Group Policy MVP, GPanswers.com
Executive Summary
Microsoft has tacitly declared that the default “status-quo” security model for Windows simply isn’t enough.
With Windows 7, Microsoft has introduced new technology, dubbed AppLocker which has one main goal:
specify which software should and should not run based on IT administrator’s rules.
This technology leverages Group Policy, the de-facto method of mass-controlling Windows machines. It’s
relatively easy to configure and deploy. It has all the right ingredients to make IT shops more secure.
But does the technology, as delivered from Microsoft, have what it takes for IT administrators to give it true
enterprise-wide adoption?
This paper focuses on how IT Practitioners and IT Managers can implement and leverage AppLocker to
perform application whitelisting, but also learn the limitations inherent within AppLocker and learn how
other tools can fill in the gaps that AppLocker leaves.
Application Whitelisting: Definitions and Promises
The concept of “Application Whitelisting” is simple: if an application is not defined, expressly, to be run on
a machine — it is stopped dead in its tracks.
Fifteen or ten years ago, this idea would be absurd. Why wouldn’t you want to run applications at-will upon
machines?
But today’s threats from Internet worms, viruses, and malware make the list of evil applications truly end-
less. Indeed, there is also the constant threat of users manually downloading and running not-so-nice
“helper” applications (which express the weather, play a game, show a cute screensaver) but secretly de-
liver your company’s information to the bad guys.
Indeed, every single day, there are more bad applications trying to run themselves on your systems. There
is simply no proactive way (via traditional blacklist-based virus scanners, malware scanners, etc.) to stay
on top of it all. By the time the threat has been vetted by the anti-virus or anti-malware application vendor,
it could be too late for your company. Your machines could already be infected. The situation is even worse
for targeted threats that are never widespread enough for vendors to detect.
True prevention of application execution can only come thru application whitelisting.
Microsoft’s History of Application Execution Prevention (Software Restriction Policies)
Most people don’t know that Microsoft has had a history of application whitelisting from as long ago as
2001, when Windows XP was released.
1

2. The mechanism was (and still is) called Software Restriction Policies or SRP for short.
The Software Restriction Policies mechanism could be used to either blacklist specific applications, or, in
very rare cases, be used as a true application whitelisting technology.
Though rarely used, Software Restriction Policies worked decently for application blacklisting on Windows
XP machines. Again, almost no one performed widespread deployment of Software Restriction Policies in
whitelisting mode. That’s because, unfortunately, whitelisting does require some mechanism to create the
actual whitelist. And, since Software Restriction Policies had no built-in way to do this, most administra-
tors opted to only use it only for blacklisting specific applications — like the built-in Windows games, the
occasional 3rd party download, or other known applications they specifically wanted to prevent.
Moreover, the rules to define what “good” and “bad” applications within Software Restriction Policies are
limited. The only rule types available with Software Restriction Policies are:
• Hash: Files can be allowed or denied to run based upon the files’ specific hash.
• Path: Files can be allowed or denied based upon where they are placed in the operating system, or
by name
• Certificate: Files can be allowed or denied if they are digitally signed
• Network Zone (also known as Internet zone on pre-Vista management stations): Files can be allowed
or denied if they are .MSI files downloaded from the Internet
Most administrators, when using Software Restriction Policies used Hash and Path rules. Because of Soft-
ware Restriction Policies’ limited power to whitelist, when it was used, Software Restriction Policies was
used mostly to blacklist. And when used, administrators mostly used Hash and Path rules.
The other rule types (Certificate rule and Network Zone rules) had limited value. Most IT administrators are
not able to quickly digitally sign in-house applications with required digital certificates. And Network Zone
rule has little to no value at as designed.
On the plus side, however, Software Restriction Policies are available to be deployed via Group Policy to
either users or computers. This means that you can specify to prevent applications’ executions when users
roam from machine to machine; or, you can prevent applications’ to all users upon a specific set of machines.
You can see a simple example of a Software Restriction Policies hash rule in place in Figure 1. The result
of deploying Software Restriction Policies can be seen in Figure 2.
Note that the message inside the dialog box cannot be changed by any method. Users are simply left to
wonder what has occurred, what the organizational policy is about running appropriate software, and they
are left with nothing to click on to request help or determine why an application was prevented.
Software Restriction Policies are available from Windows XP and onward including all editions of Windows
7 (excluding Home and Starter editions).
It should also be noted that there are well-known programmatic exploits to work around XP to be found online.
2

3. Figure 1: Software Restriction Policies deployed using Group Policy have a limited set of rule types
Figure 2: User’s interactions with Software Restriction Policies
Inside AppLocker: Blacklisting and Whitelisting
Internally to the operating system, AppLocker is labeled as SRPv2. This expresses the evolutionary nature
of Software Restriction Policies into AppLocker.
AppLocker strives to bring more to the table. However, many organizations’ use of AppLocker will sadly be
out of reach. Specifically, AppLocker is only available in the following versions of Windows 7:
• Windows 7 Enterprise (available only with a Microsoft SA agreement)
• Windows 7 Ultimate
3

4. It is not present in the most popular edition, Windows 7 Professional, nor is it going to be back-ported to
Windows Vista or Windows XP.
For those fortunate organizations to be able to leverage the “correct” versions of Windows 7, only then
does AppLocker provide a modernized, more automated way to whitelist applications.
AppLocker is designed, up front, to be more “whitelist friendly.” To that end, AppLocker has three un-
changeable Laws which are executed in the following order:
• Law #1: Explicit deny: A specific rule which denies an action.
• Law #2: Explicit allow: A specific rule which allows an action.
• Law #3: Implicit deny: All files that are not specifically named by an Allow rule are automatically blocked.
In this way, once fully engaged, AppLocker’s goal is to immediately start denying access to just about every
application executed. To that end, there is a prompt for the administrator to expressly whitelist Windows’
own directories, lest the operating system itself become unstartable and inoperable.
Note that there are three discrete steps that must be performed for AppLocker to be working at all on the
client machine. We’ll see in the next section how to configure AppLocker’s rules, and turn on the required
client pieces such that AppLocker is actually enforcing administrators desired rules.
AppLocker takes some evolutionary steps which correct the main shortcomings of Software Restriction
Policies. Specifically, with AppLocker, administrators can now declare certain application Publishers ac-
ceptable or unacceptable, and make exceptions within those rules. For instance, an administrator might
“Only allow software from XYZ Corp, specifically App1, when it’s greater than version 4.5.” The other main
benefit AppLocker has over Software Restriction Policies is the ability to auto-generate a whitelist from a
“template machine.” The goal of this feature is to take a representative machine which has the collection
of “acceptable” software and generate rules based from it.
We’ll learn more about that feature in the next section.
AppLocker: Setup, Blacklisting and Whitelisting
AppLocker takes three main steps to be turned on and activated upon clients. Those steps are:
• Setting up the AppLocker rules
• Turning on Auditing or Enforcement
• Enabling the AppLocker “AppID” service on the Windows 7 client machine
To set up AppLocker rules, you can use the flexible Group Policy infrastructure. The scope of Group Policy
best-practices and implementation is beyond the scope of this paper. For more formalized information and
training on Group Policy, please visit GPanswers.com and inspect the book and hands-on training options.
AppLocker Rules
In general, AppLocker administrators will want to set Group Policy Objects (GPOs) to affect a particular OU
containing computer accounts. Note that AppLocker does not permit administrators from targeting OUs
4

5. containing user accounts — only computer accounts. That is, AppLocker rules must be targeted by com-
puter, then, if desired, filtered by users upon those computers within the rules. This can potentially make for
an incongruous experience: users are locked out of some applications on some computers, but not others.
Where Software Restriction Policies had four main rules, AppLocker has three rules, with several sub-rules:
• Executable Rules: Allow or Prevent specific EXEs, .COMs, DLLs or .OCXs to run. Within Executable
Rules are three sub-rule types: Publisher, Path and File hash.
• Windows Installer Rules: Allow or Prevent specific .MSI (Windows Installer) and .MSP (Windows
Patching) setup files to run
• Script Rules: Allow or Prevent scripts to run. Limited to .PS1, .BAT, .CMD, .VBS, and .JS files only.
You can see how to create a rule in Figure 3.
Figure 3: Creating a new AppLocker rule within the Group Policy editor
5

6. Space limits us from going into every possible configuration option for AppLocker. However, let’s examine
one common example and see how administrators might utilize AppLocker.
In Figure 3 you can see the main choices when creating rules:
• Create New Rule
• Automatically Generate Rules
• Create Default Rules
Let’s examine these rules, a little out of the order displayed in the user-interface.
Create Default Rules: This is recommended when using AppLocker because AppLocker’s Law #3 will deny
access everywhere unless items are specifically whitelisted.
The Default rules, however, could be a little misleading and too promiscuous. As seen in Figure 4, the
default rules enable all AppLocker enabled computers to continue to run anything already installed in the
Program Files folder. Additionally, AppLocker’s defaults allow any local administrator to continue to run any
application as desired.
Again, these are the default rules, and may be fine in some circumstances, but are not recommended to
be used blindly by all organizations.
Figure 4: The default AppLocker Executable rules, which must be put in place by the administrator
Note that there are also default rules which should be set up for the other two types of AppLocker rules:
Windows Installer Rules and Script Rules. Administrators must also generate then tune those default rules,
similarly to the default Executable rules if they want to have successful whitelisting in all three areas.
Create New Rule: Allows administrators to create a manual Allow or Deny rule. Again, since AppLocker’s
Law #3 will deny anything not expressly opened up with an “Allow rule” administrators must create rules
which allow applications to run.
In this example, we’re creating an Executable rule based upon Publisher. (Again, the other options, not
shown here, are File hash or Path rule.)
6

7. Figure 5: Manually creating an AppLocker Publisher rule
The Publisher rule type can only work if the application is fully signed, end-to-end, across all .EXEs the ap-
plication uses. Additionally, an AppLocker administrator has the ability to also lock out .DLLs and .OCX files
(described and shown later.) If that option is turned on, administrators must make very certain that all .DLLs
and .OCX files that make up an application are also digitally signed, and digitally signed in the same manner
such that rule doesn’t block application execution. It’s not uncommon for major applications to have only
pieces of the application (the main executable) digitally signed, but not other pieces of the same application.
A rule to Deny an application can be seen in Figure 6.
Figure 6: A Deny rule will override an Allow rule
Deny rules are only really required if applications are already installed within the spaces defined in the pre-de-
fined rules. But this situation is quite common. Machines are often rolled out with “core applications” already
embedded inside the image; then, some time later, they need to be restricted due to a variety of circumstances.
Automatically Generate Rules: This action will allow administrators to take a representative sample ma-
chine, and auto-generate rules based on a starting file location, like c: or c:program files. Note that on
64-bit machines, the action will need to usually be run twice, making sure to include the C:Program Files
(x86) folder as well, where the majority of application installations are performed.
The default rule-creation actions can be seen in Figure 7, which is to create Publisher rules for digitally
signed files, and file hash rules for those applications which are not digitally signed.
7

8. Figure 7: Options for creating auto-generated Executable rules
When done, a machine could have hundreds of rules automatically generated as seen in Figure 8 and 9.
Figure 8: Automatic rule creation
8

9. Auto-generating rules toward a whitelist is big-step forward from Microsoft for AppLocker as compared to
Software Restriction Policies. It makes quick work getting the initial rules from a particular machine into a
Group Policy to then be deployed to other machines.
The potential issue, however, is that administrators will need to find representative example machines from
each user population, such as, Sales, Marketing, Doctors, Nurses, Engineers, Human Resources, and so
on. That means administrators may “get it right” the first time by finding a perfect example system, or, more
likely, after the rules are auto-generated, they will have to manually add or subtract rules. Moreover, there
is no automated way to keep this list auto-updated in the case of an exception or a wider rollout. Auto-
generating rules appears to be designed as a “one time, kickstart” action to help create the rule set — not
keep it maintained.
When complete and adjusted as needed, AppLocker still will not start enforcing rules upon client ma-
chines. There are two more steps involved.
The next step is to choose to Enforce rules or simply run in Audit only mode on the client.
Figure 9-A and 9-B: Enforcing or Auditing for AppLocker rules
Unfortunately, Audit rules only go to the local machine’s audit logs. There is no automatic collection, cen-
tralized database, or detailed analysis across multiple systems. While there are some available Windows’
facilities for rounding up events on disparate machines and forwarding them to a “collector machine”, that
is an extra step and infrastructure disparate from AppLocker and, thus must be set up separately. More-
over, should those rules be collected and somehow centralized, it is still then a manual process to decide
which logs have “good” information such that rules inside the policy should be modified.
9

10. The last step for AppLocker to begin enforcement is to turn on the AppIDSvc service on your Windows 7
machines as seen in Figure 10.
Figure 10: The AppIDSvc must be turned on for AppLocker to begin enforcement
Note that turning on the AppIDSvc is relatively easy to do, en-mass using Group Policy controls. However,
if AppLocker rules are set up to Enforce Rules, users can see immediate consequences.
It should also be noted that anyone with local administrative rights can simply stop the AppIDSvc, thus
working around AppLocker policies. It is a noted best-practice not to have regular users as local adminis-
trators, specifically to avoid attacks just like this.
User’s Interaction with AppLocker
Applications which pass your rules are able to run. Applications which fail the rules are stopped as seen
in Figure 11 (see next page).
Note, that there is a way to change the message to what’s seen in Figure 12 (see next page), with a simple
Group Policy change. The “More Information” link can redirect users to your company’s internal web page
describing your corporate position on what software is acceptable to run or other information.
10

11. Figure 11: The standard Group Policy message when an AppLocker rule is tripped
Figure 12: You can change the alert message to include a More Information link
From CoreTrace and Moskowitz, inc.
AppLocker is a decent evolutionary step from Software Restriction Policies which was built in 2001. The
advances in creating auto-generated whitelist from a sample computer are good, but there is simply no
allowance for dynamic list creation when the software set at a company grows.
There could be many times that a default, static set of rules is placed upon computers could be detrimen-
tal. There is simply no automatic way users can request for exceptions, nor can rules automatically be re-
jiggered based upon extreme criteria. The rule must manually be adjusted back at the Group Policy source
and re-applied to a machine.
Once auto-generated rules are in place, administrators need to think about the consequences each and
every time they want to roll out new software or upgrade existing software. Here are some issues using
only the auto-generated rule list:
• After using the auto-generated rule list, administrators will need to keep on top of, and know about
every new application for every user in their organization needed to do their jobs. Only after gathering
that information, a manual additional rule must be set to enable the applications or suffer user backlash.
• Administrators could be forced to hunt and peck on various machines to locate software and manu-
ally generate rules to specifically allow or disallow applications based on the existing auto-generated
whitelist. They could need to manually find the differences between the auto-generated whitelist and
the newly required applications.
11

12. • When file hash rules are used, watch out for self-updating applications. In these cases, a self-updat-
ing application will generate new file hashes and simply self-excludes itself from the rule list! Users
will instantly be denied access to their application.
• In the case of Publisher rules, many application manufacturers are still not signing all of their ap-
plications. Or, if they are signing their applications, they are sometimes missing signing all parts of
their applications.
• For home grown applications, applications are rarely digitally signed, which precludes the use of
Publisher rules. Additionally, home grown applications are often updated, which precludes the use
of hash rules. This can be a major problem for ongoing maintenance.
• AppLocker rules must be independently updated. They are segmented into three completely unique
areas which must be addressed, one at a time: Executables Rules, Windows Installer Rules and Script
Rules. There is no master “Auto-Generate Rules for all three rule types” functionality within AppLocker.
Microsoft has raised the awareness and need for application whitelisting as a required technology. By in-
cluding AppLocker in their Windows 7 product, they are expressing that the need for true lockdown using
application execution prevention is a must.
Again, however, only select enterprise customers will be within reach of AppLocker. Only Windows 7 En-
terprise and Ultimate editions (but all editions of Windows Server 2008 / R2) have the AppLocker AppID-
Service service, and, hence will embrace AppLocker rules.
Let’s examine if AppLocker or if BOUNCER by CoreTrace is right for your environment. Here are some
questions for you and the IT organization to consider:
AppLocker seems to require a lot of ongoing tuning and is highly likely to have issues associated with
conflicting or improperly created rules. How is BOUNCER different?
Initially, BOUNCER auto-generates a custom whitelist of all executables on any given computer. There is
no tuning other than explicitly preventing the execution of certain applications, if desired. Subsequently,
as new applications or upgrades are installed via BOUNCER’s Trusted Change feature, the same auto-
generation capabilities create a customized whitelist which is appended to the existing whitelist for that
computer. This prevents accidental conflicts between manually crafted rules, and reduces the manage-
ment burden significantly.
What if I want to perform application whitelisting to Windows XP clients? Or Windows 7 professional
clients?
Unfortunately, AppLocker is only available for Windows 7 Ultimate and Enterprise SKUs. The older Soft-
ware Restriction Policies technology is still built in from Windows XP and onward. While it is possible to use
Software Restriction Policies in a whitelisting mode it is not a recommended configuration from Microsoft
due to its supportability difficulties. Additionally, the unfortunate truth is that there are known exploits to
work around existing Software Restriction Policies on the web. Conversely, BOUNCER was designed from
the beginning to be an enterprise-wide, cross-platform solution. Currently, BOUNCER secures clients from
Windows NT 4, through Windows 2000 and XP, and up to and including all modern products such as Win-
12

13. dows Server 2008 and Windows 7. Additionally, BOUNCER secures systems on non-Microsoft operating
systems including Solaris 7, 8, 9, and 10.
How can I avoid having to manually auto-generate the whitelist when existing applications are updated
or new ones are added?
Having a system which auto-generates the whitelist is great. But the ongoing maintenance after that is
where the headache begins. BOUNCER automatically modifies
whitelists through its patent-pending “Trusted Change” technology. Trusted Change allows IT profession-
als to predefine multiple sources from which applications can be installed or upgraded. Then those up-
dates are quietly added to the whitelist. Once your IT organization has established where trusted updates
can come from, say, a Microsoft WSUS update server, the work is performed automatically. A BOUNCER
Trusted Update can be a wide array of sources including trusted self-updating applications, trusted digital
certificates, trusted paths and network shares, or trusted users. Once set up, these updates are auto-
mated, and don’t require manual IT interaction.
What if I want to block other types of executables and script types?
AppLocker’s Executable rules limit.EXE, .COM, .DLL or .OCX files to run. AppLocker’s Windows Installer
rules can limit .MSP (Windows Patching) and .MSI files to run. And with AppLocker’s Script Rules, you can
prevent .PS1, .BAT, .CMD, .VBS, and .JS files.
BOUNCER, however, identifies executables as .EXE, .DLL, .COM, .OCX and continues onward to include
.BAT, .SYS, .CMD, .DRV, .CPL, .DEV, and .MANIFEST files.
Additionally, BOUNCER controls installers such as .MSI, .MSU, .MST, .MSP and all other installable files.
BOUNCER goes even further by opening up unknown files and inspecting it to determine what type of file it
is to ensure it is not an executable in disguise. Many third party Windows software vendors use executable
libraries with an extension other than .DLL or .OCX. Adobe Acrobat is a one such example of this practice
and one that BOUNCER protects you against.
To protect even further, the following types of files are added regardless of the file extension: Older MS-
DOS executables, Windows PE binaries (executables, libraries, and kernel drivers), True Type fonts and
font collections and Open Type fonts.
What is the impact if I want to whitelist DLLs and OCX files?
Microsoft admits in its official TechNet documentation (http://technet.microsoft.com/en-us/library/
dd759068.aspx) that “When DLL rules are used, AppLocker must check each DLL that an application loads.
Therefore, users may experience a reduction in performance if DLL rules are used.” In contrast, there is no
discernable performance decay when BOUNCER is utilized for DLL monitoring and protection.
What if the application itself has a vulnerability? Can AppLocker help protect me there?
AppLocker has a simple job. If it’s on the list, the application runs. If if’s not on the list, it’s prevented. If the
application itself has a fatal flaw or exploit inside it, then AppLocker has no provisions to control how the
13

14. application is run. Other parts of the operating system, like DEP (http://en.wikipedia.org/wiki/Data_Execu-
tion_Prevention) may or may not help with “runaway applications” like this.
BOUNCER is similar in that it does not prevent or patch vulnerabilities, and it does prevent the execution
of deposited payloads. However, BOUNCER can prevent major types of memory exploits directly, such
as .DLL injections and attempts to write directly to kernel-memory. When BOUNCER catches rogue code
running where it shouldn’t, it runs a hash on the kernel mode drivers in the memory and checks it against
the kernel module list. If the process does not come from the approved list, it does not run. BOUNCER’s
job is to ensure system integrity at multiple levels.
How can I know which applications are most frequently blocked or allowed using AppLocker? How is
this different with BOUNCER?
AppLocker does log every success and failure to the local event logs. In that way, you can individually
assess what one particular machine is doing. But, there is no AppLocker-based mechanism to centrally
analyze what is being prevented or allowed across multiple machines.
BOUNCER is designed to provide a centralized, enterprise-wide view of controlled systems. BOUNCER al-
lows IT teams to see which applications are running, or are attempting to run, on each protected endpoint.
This information helps the IT team identify fast-propagating malware like worms, diagnose performance
and reliability problems and assist in internal, licensing, and compliance audits.
What if I have custom and home-grown apps?
As noted with AppLocker, home-grown applications could mean many ongoing manual updates.
BOUNCER’s design philosophy is driven by two fundamental beliefs:
• No two computers are alike, and
• It is impossible to have a complete list of all known applications in advance.
BOUNCER auto-generates custom-tailored whitelists from and for each protected endpoint quickly and
efficiently. Since different computers have different applications and processes installed, this is the only
way to get the job done.
This capability facilitates the automated implementation across any number of computers in a network in
matter of minutes and automatically accounts for custom and home-grown applications.
About the Author
Jeremy Moskowitz, MCSE, MCSA and Group Policy MVP is the Chief Propeller-Head for Moskowitz, Inc.
and an independent consultant and trainer for Windows technologies. He runs www.GPanswers.com, a
community forum for people to get their toughest Group Policy questions answered.
Mr. Moskowitz can be found speaking at IT conferences and inside corporations all over the world, and has
authored or co-authored many books, including his latest two, “Group Policy: Management, Troubleshoot-
14

15. ing, and Security” (Sybex), and the new “Creating the Secure Managed Desktop: Group Policy, SoftGrid,
Microsoft Deployment Toolkit, and Management Tools”, both with content available as eBook downloads
from GPanswers.com/books.
Since becoming one of the world’s first MCSEs, he has performed Active Directory, Group Policy, and Win-
dows infrastructure planning and implementation for some of the nation’s largest organizations. Jeremy
frequently contributes to Windows IT Pro Magazine, Redmond Magazine, and Microsoft TechNet Maga-
zine.
Jeremy teaches Group Policy intensive training and workshop classes recommended by Microsoft.
Learn more at www.GPanswers.com/workshop.
About CoreTrace
CoreTrace ® is the pioneer of client-based application whitelisting. The company’s award-winning and pat-
ented high-security, easy-change BOUNCER solution is at the forefront of the movement in next-generation
endpoint control and security solutions. Unlike other application whitelisting solutions that are simply lock-
down technologies, BOUNCER’s “Trusted Change” capability enables IT professionals to predefine multiple
sources from which users can safely install applications and have them automatically added to the whitelist
— all with minimal IT involvement. The result: full prevention of unauthorized applications, improved overall
security, and lower total cost of ownership compared to alternative whitelisting and traditional blacklisting
antivirus solutions. CoreTrace’s customers include organizations in a wide variety of industries, such as
energy, oil and gas, financial services, telecommunications, as well as government agencies.
CoreTrace is headquartered in Austin, Texas. For more information, please visit: www.CoreTrace.com. Our
blog can be found at http://www.coretraceblogs.com/.
15