ThreatLocker Zero Trust Platform Reviews

Users submit applications for installation, and I typically review them, granting or denying access as needed. While the volume isn't high, ThreatLocker Protect provides significant peace of mind knowing users aren't installing unauthorized or malicious software. Our biggest challenge has been user errors causing support requests. To address this, I've implemented rules for applications frequently used in daily operations. It's had a learning curve, but the effectiveness has been noticeable.

Making approval or denial decisions on requests is pretty straightforward for me. I haven't encountered any problems. However, I can see how it might be a bit confusing for less technical users. Things like allowing hashes and understanding all the terminology could be stumbling blocks. Still, I believe anyone with a few months to a year of IT experience would find it manageable. And of course, I was able to grasp it myself.

While allowlisting can help verify specific access requests, it doesn't guarantee overall trust as requests can still originate from compromised sources. In my experience, the zero trust model has proven the most effective approach. Its principle of "never trust, always verify" minimizes risk by scrutinizing every access, regardless of origin. We haven't encountered any security breaches with clients who implemented it, suggesting its efficacy. While antivirus remains a valuable layer of defense, I believe the zero trust framework, particularly in conjunction with ThreatLocker, offers the most robust security posture we've encountered. Thankfully, we haven't experienced any issues with this combination so far.

ThreatLocker Protect provides us with peace of mind. It's a game-changer. With it in place, we can be confident that employees are only using authorized applications, minimizing surprises and freeing up our time for other aspects of our work. We used to spend significant time dealing with malware, but that burden has been greatly reduced. Peace of mind is truly the main benefit.

Allowlisting has significantly reduced the number of tickets we receive from compromised accounts. It's eliminated them. However, we still get tickets from users who are confused about the new process, need things approved, or are feeling impatient. While the volume has decreased, these legitimate tickets related to access limitations are still present. Ultimately, we believe this trade-off is worth it for the sake of enhanced security. This is what we communicated to the team.

Implementing an allowlist has not only freed up our help desk staff for other projects but also aligns with my preference for approved application lists on both mobile devices and computers. This approach ensures smooth operation with minimal complications, and a positive outcome overall.

We utilize allowlisting alongside other security measures, with ThreatLocker as an additional layer. This choice stems from the absence of other comprehensive endpoint protection solutions, ensuring ThreatLocker doesn't overlap with existing safeguards. Therefore, it complements our antivirus for all users.

It initially took a couple of months for us to fully appreciate the benefits of ThreatLocker. While we put our people in learning mode for approximately a week to understand normal system processes, it wasn't until the lack of suspicious activity became evident that we truly recognized the impact. This doesn't diminish the importance of our existing security measures, including sound user guidance, phishing training, and other protocols that discourage risky behavior and minimize software installation needs. In essence, it took some time for the benefits of ThreatLocker to become fully apparent due to the effectiveness of our pre-existing security practices.

When new files arrive and people mention they've been tested twice in the virtual environment, I like to double-check for potential malware by scanning them on VirusTotal and other antivirus platforms. This adds an extra layer of security, which is especially helpful when I'm unsure about approving a file and research doesn't provide clear answers. The sandbox functionality is fantastic. It bolsters my confidence considerably, as it can reveal suspicious behavior like registry modifications even if initial scans are inconclusive. Overall, these features have been game-changers for me.

The current process for viewing software approval requests from end users has room for improvement. While it's generally functional, some users find it confusing. This can be due to either unfamiliarity with the process, unexpected appearance of the request window, or lack of clear instructions. Additionally, the notification box might not be sufficiently noticeable, as some users have reported missing it entirely.

Adding applications to the allowlist can sometimes feel overwhelming. The numerous fields, coupled with navigating the unfamiliar portal, can be daunting, especially on our first attempt. Even with explanations, recalling the necessary information and understanding the required actions for file inclusion can be tricky. I believe the initial learning curve for allowlisting is relatively steep. However, once mastered, it proves to be a valuable tool. My main concern lies with the initial learning hurdle.

I have been using ThreatLocker Protect for around four months.

ThreatLocker Protect has been mostly stable over the past six months. We did experience a single outage that lasted a day, which was disruptive due to pending approvals. However, this has been the only major incident in that timeframe, suggesting overall good stability.

ThreatLocker scales well and has been successfully deployed on all our required devices. We offer it as part of a premium package, but due to its higher cost, adoption among our clients is currently limited. Nevertheless, it meets our scalability needs effectively.

The implementation was relatively straightforward. We developed components or scripts for deployment to devices, avoiding major complications. Furthermore, we have a remote management tool in place for efficient installation.

Installing on everyone's machines is a fairly quick process, typically taking an hour with online devices. While it doesn't require much time, we recently spent two hours on calls with someone to guide us through it. This was because our previous setup, done by someone else in the company, had some errors. We've rectified them now, but it meant changing a few things. Overall, deployment should be smooth and swift, requiring two people and around an hour if all the devices are online.

The implementation was completed internally by our team. Given our extensive experience deploying vulnerability scanners for assessments, this process was relatively straightforward.

I would rate ThreatLocker Protect a seven out of ten. The learning curve is quite steep, especially for those without extensive IT experience. I found it challenging to master and had to rely on my team for guidance on several occasions. Even my manager isn't completely comfortable with it yet. However, once we overcome the initial hurdle, it truly shines.

ThreatLocker requires minimal maintenance, except for one recent instance where we reviewed its configuration. While it's designed to automatically update on user machines, I noticed some devices hadn't yet received the latest version. I manually initiated the update for these devices. The cause of the delay is unclear, though the devices are online, so it might be a network issue.

Ensure all future ThreatLocker users are thoroughly briefed on its functionality. We've encountered surprises among some users regarding the approval requirement for new activities. To avoid such issues, we recommend comprehensive pre-deployment communication, outlining ThreatLocker's purpose, features, and approval process.

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.

Positive

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.