How to make your users hate ThreatLocker less

ThreatLocker blocks every program not explicitly allowed, which makes it a powerful security tool. However, users can view this as getting in the way of their work.

Some users expect to install whatever program they want.

Or a hash or file path in a permitted application changes, so it gets blocked again.

This results in frustrated calls to your help desk, which makes both users and technicians ask "Can we get rid of ThreatLocker".

Below are some quick tips to make your users and help desk hate ThreatLocker less.

Speed of Response

TLDR: Set up a notification channel (Teams, Slack, Email, etc.) that pushes a notification to you when a ThreatLocker approval request is sent in.

One method of doing this is by logging into the ThreatLocker admin portal, going to Users, clicking on your user, then selecting "Notify on application request" (select the other features as well if you use them) and selecting Email or SMS. YouTube video on this: https://www.youtube.com/watch?v=8zLVrkwqWxE.

Once you receive a notification, you should either approve the app or call the customer explaining why you denied it within a few minutes.

By responding to approval requests in minutes rather than hours, your help desk will receive fewer angry tickets.

Constant Denies

TLDR: If an application is constantly denied, build allow rules with wildcards by asking the question "How can I permit this program every time it updates, and make it near impossible for a hacker to exploit?".

Throwing a PC that keeps having the same app denied into learning mode will not help.

As an example, programs typically use "C:\Program Files\application\appupgrade.exe" to update. So, you approve this path along with the program's certificate, and you are good to go.

The programs that typically cause problems might have a random string that changes in the file path. For example: "C:\Program Files\annoyingapplication\jlfdanxlfkxndlanxkfd\upgrade.exe".

In the application definition permit "C:\Program Files\annoyingapplication\*\upgrade.exe" and either the process or certificate along with it.

This way, future updates are allowed. Learning mode would just permit "C:\Program Files\annoyingapplication\jlfdanxlfkxndlanxkfd\upgrade.exe" and its hashes. If you just use learning mode without making wildcards, next time there is an update, your client is going to call in upset, asking for ThreatLocker to be uninstalled.

This is because the update used different hashes and file paths then what learning mode picked up.

One of the worse things you can do for your clients security is uninstall ThreatLocker (without another zero trust tool deployed) or put it into learning mode forever.

Better to be a little bit more flexible with your application definitions than abandon zero trust.

Ownership

TLDR: Make one or two people your "ThreatLocker guy". This should be someone with security knowledge and who is quick to respond.

I also recommend that they go through ThreatLocker university: https://www.threatlocker.com/resources/threatlocker-university

When ThreatLocker is "everyone's" responsibility, no one wants to deal with it due to how much work it can be. This results in everyone feeling resentment towards what can be a powerful security tool.

"Joe is our ThreatLocker guy" rather than "The escalations team is in charge of ThreatLocker" gets better results.

Whoever is put in charge of ThreatLocker should be allowed to give it priority over other projects.

About Me

I founded Lean Cybersecurity to help MSPs fix security gaps that would have led to real incidents.

From my experience, most MSPs are so busy they don't have time to security harden and fix the tools that are frustrating their users and help desk.

Currently offering a pilot program, 20 hours of free security reviews for 5 MSPs.

If you have any questions about these tips or us, reach out at contact@leancybersec.com