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 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 straightforward.
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.
Deployment Tips
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.
Summary
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?
Useful Resources
I’ve created an 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 get in touch with us here to learn more.
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.
