ThreatLocker is our standard security stack, with very few exceptions. We use it for all of our MSP clients, MSSP clients, and recently for IR response cases. We use ThreatLocker to control application installations and take advantage of its ring-fencing option, which prevents otherwise good applications from interacting maliciously.
Administrators can easily approve or deny requests using the log listings.
The overall visibility into software approval requests of end users is very good.
ThreatLocker and ring-fencing are two of the main ways to prevent applications from interacting with each other, outside of application control. This means that we can take two otherwise non-malicious applications and prevent them from speaking to each other. A good example is Microsoft Word and Microsoft PowerShell. We wouldn't want Word to interact with PowerShell.
From a visibility standpoint, we like Allowlisting's ability to establish trust from every access request, regardless of its origin. However, there is nothing quite like the application control feature, even in an XDR or EDR solution. We are looking for the process path, CERT, and other information to identify the application.
Allowlisting has helped reduce the number of our help desk tickets. There was an initial spike in configuring trusted applications, but it has definitely cut down on supporting applications that should not be part of an organization anyway, such as PDF readers and browsers outside of the standard. Once we add an acceptable group of applications, we no longer support any deviations from that. Allowlisting has cut down on some of the ticketing there.
Allowlisting has helped us consolidate applications and tools. For example, we have standardized on a list of allowed browsers because those are the browsers that are patched regularly. We have also standardized PDF readers and Office suites, such as LibreOffice and Microsoft Office.
We saw the benefits of Allowlisting quickly. We observed that applications, such as PowerShell, were able to run freely within an environment, and that there was a high likelihood that one of these tools could be used maliciously without any effective deterrents. None of the EDR, XDR, logging, and forwarding SOX solutions were able to stop such an attack from proceeding.
Application control, ring-fencing, and storage control are the most important features, followed closely by elevation.
More visibility in the built-ins would be nice.
The learning curve is wide because there are a lot of things to learn.
I have been using ThreatLocker Allowlisting for two years.
ThreatLocker Allowlisting has had minimal downtime, comparable to, if not exceeding, Microsoft's uptime standards.
ThreatLocker Allowlisting is easily scalable. We doubled our endpoint count in three days, and we know that we can scale.
The support team is the best we've had by far. I don't think I've ever waited more than a minute, They usually answer our call in about 30 seconds.
The initial setup was straightforward. We pushed ThreatLocker Allowlisting out from our RMM automation system. We have also pushed it out in other ways, and it is always straightforward.
Two of our people were involved in the deployment.
We used ThreatLocker's onboarding process support for the implementation.
The pricing is fair and there is no hard sell.
I would rate ThreatLocker Allowlisting ten out of ten.
The alert board for maintenance requires monitoring.
Potential users should expect to dedicate resources to ThreatLocker Allowlisting. It is not a set-and-forget solution. There is a learning curve, but Cyber Hero support is available to help users through it. Unlike some other products that onboard users and then leave them to the ticketing system, ThreatLocker provides continued support. It is important to note that ThreatLocker Allowlisting cannot be simply turned on and left alone. It requires in-house resources to properly manage at scale.
