A Quick Overview
One of your company’s biggest cybersecurity risks lies in the one of the most common
employee activities: running applications. More specifically, I am talking about users running
executables or accessing files which could theoretically contain malicious code that could
compromise their device, your network or even your business.
This is where AppLocker comes in. It can help you determine which files and applications
users can run. This may include executables, Windows Installer files, packaged app
installers/packaged apps, dynamic-link libraries (DLLs), and scripts—to name but a few.
Unified Extensible Firmware Interface (UEFI) isn’t a new technology, it has been around for many years. On the other hand, attacks at the BIOS level have not only happened this century, but this decade. Rootkits that try to alter boot process are still in the wild, and anybody on an outdated and legacy technology are at a huge risk.
What Can AppLocker Do?
AppLocker allows you to bring your apps under control by helping you to understand which
applications are being used, by whom, how often, and when.
Once you know this, you can then control which applications can be run, and who can run
them, through the use of rules. If a user attempts to run an unapproved application, the
attempt will fail because it is blocked. This can help you enforce standardization. For
example, a user can only run the most recent version of Office and is prevented from
running older versions. It can also help you limit usage to only the number of licenses you
have paid for.
How Much Is This Going to Cost?
Probably one of the first questions you are going to have to answer from management is
how much is all of this going to cost? Well, like most IT-related projects there are both
material and resource-related costs when it comes to implementing AppLocker.
From the material side, any machines on which you want to be able to configure and
enforce AppLocker need to be running a supported operating system. This includes some
versions of Windows 7 and later Windows releases (see the link Operating system
requirements link in the Useful Resources table below).
You may have heard a lot about Unified Extensible Firmware Interface (UEFI) and how
various features of Windows 10 can use this. If you are worried about using AppLocker as it
is dependent on UEFI or has specific hardware requirements, don’t be. AppLocker does not
have any specific hardware requirements or rely on UEFI.
From the resource side, you need to determine which rules should apply to which
applications/users/groups. These rules will need to be created, tested (and amended
accordingly), and documented.
Then of course there is the ongoing costs associated with creating new rules, maintaining
existing ones, and deleting those no longer used. You also need to make sure you have
processes in place to cover common scenarios. Common cases are users moving between
groups, changing jobs, requiring access to new applications, and being removed if they no
longer require access.
The Devil Is in the Details
Of course, implementing any new technology has some degree of risk. In the case of
AppLocker, the biggest thing you can do to reduce this risk is to create a matrix identifying
which policies need to be created and to whom they should apply.
In order to do this, you are going to need an up-to- date inventory or your organization’s
operating system versions and applications. Microsoft System Center Configuration
Manager (ConfigMgr/SCCM) can provide this.
If you don’t have a tool such as ConfigMgr, you can learn and refine as you go. If you
configure your rules in audit-only mode, every time an application is accessed on a machine,
an event is written to the event log. These events can later be analyzed to build a picture of
usage of that application in your company.
But this is of course only half the story as you will also need a breakdown of the various
business groups in your organization.
In order to achieve your desired result, you may need to use a mix of AppLocker and
Software Restriction Policies (SRPs). (See the What features are different between Software
Restriction Policies and AppLocker? link in the Useful Resources table below for more
information on each and the differences between them).
Just bear in mind that each have their own requirements/limitations. If you implement both
types of policy in the same domain, the AppLocker policy takes precedence over those
generated by SRPs which may cause some unwanted results.
Gently Does It
As well as ensuring all of the all of machines on which you want to use AppLocker are
running a supported operating system, consider a phased approach similar to that below
when implementing AppLocker.
First off identify the easy/quick wins you can make such as applications that are used the
most through your organization such as Microsoft Office. You may have critical and highly
specialized apps, such as a CAD application which are expensive and to which only certain
users should have access.
Next, you probably have users or groups within your company that run a limited/standard
set of applications. Creating and applying a standard policy for these should be relatively
Leave those applications that are used by specific groups/business areas until last as these
can take longer to get working correctly, especially if such groups are physically spread.
As with most things in life, it’s usually better to learn from someone who has already done
something and hopefully learned from their mistakes, rather than going into the unknown
and hoping for the best.
Deploying AppLocker is no exception.
First off, don’t be afraid to use a mix of AppLocker and Software Restriction Policies (SRPs) if
that is what is best for your situation.
Next, if in doubt, when you create a new policy configure it in audit-only mode. This is safer
than just creating, deploying and enforcing a policy that upsets those targeted by it who
can’t now use the software you’ve just blocked. This might happen due to something you
were not aware of, or because of a difference between your live and test environments.
Configuring your policies in audit-only mode allows you to see the impact of the policy
before enforcing it.
Also look at creating exceptions to rules where applicable to simplify the creation, testing
and on-going management of rules. You might for example, allow all Windows processes to
run on a machine with the exception of those you would rather you didn’t your users have
access to, such as Regedit.
Finally, you need to make sure you document your rules in terms of which ones you have,
what they apply to, and to whom they apply. If you don’t do this from the beginning it is
only going to get a bigger headache the longer you leave it and the more rules you add.
As we’ve already identified, one of the biggest potential risks to your users, their devices,
your network, and ultimately your organization is the risk of users running executables or
accessing files which could theoretically contain malicious code leading to a compromise.
Why take this risk when you have AppLocker in your corner to help identify and eradicate
this risk leaving you to get in with the primary functions of your business?
I’ve created in-depth material on AppLocker and other Windows 10 Security Features for Adaptiva as part of a new program. The Adaptiva Windows 10 Accelerator Program is an end-to-end ecosystem which assembles the products, tools, and training you need to speed zero-touch Windows 10 deployments at scale. You can learn more about it here:
Microsoft has a number of documents and other useful AppLocker links, which I’ve listed here:
About Cliff Hobbs
The author of this blog is Cliff Hobbs, a 14-time Microsoft MVP in Enterprise Mobility (SCCM + Intune), and founder of FAQShop.