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.
