When we look at security on the endpoint, there are two parts to it. One is blocking known bad things and then setting an allowlist for the things that you want to run. Defining allowlisting reduces the attack surface just to the known good applications. It also reduces the number of false positives that we need to chase when it comes to things that hit our endpoint detection or response, which is more of our known bad or behavioral-based security endpoint. So, we pair the two together. Allowlisting helps to keep the environment clean. More and more applications do not require admin rights to install. Even if you limit the ability for a user to install applications, they can still run some things on their own such as browser plugins. We know that browser plugins can be potentially very dangerous because they sit in a browser, and that is where most people do their work. They can become a problem. Allowlisting helps to put guardrails around what is allowed to run. By keeping the environment clean, the programs perform better. They are more secure, and there is less noise for us to chase when it comes to actual security events. It is easy for administrators to approve or deny requests using allowlisting. They have two ways for administrators to approve or deny requests. They can do it in a managed way, where they do it for you using Cyber Hero. We do not do it that way. We are an old customer of ThreatLocker. We have been using it before they had Cyber Hero in place. Originally, we thought it was going to be problematic because allowlisting tends to be very hard to implement. Most of the other allowlisting systems, such as Microsoft's AppLocker, are very difficult to implement and maintain, but ThreatLocker does two things. When it comes to very common applications, they work with vendors. They are always looking at the new installations and making sure they are constantly up to date, so you do not have to always approve those things. But, of course, things happen, and sometimes they happen in the middle of the night when somebody is doing something and needs help. The nice thing about it is that it is fairly easy to approve. We can approve even with a mobile app. I have had the ThreatLocker mobile app since they introduced it a year or two years ago. If one of our clients in Australia or somewhere else is doing something, I can easily approve it without having to get up from my chair. I can approve it after doing a quick review of what they are installing. If I want to do a little bit deeper check, I can do that, but most of the time, there are just basic things, and we can approve them on the fly. The portal gives us a lot of granularity in terms of not only approvals but also how to approve them. We can choose to approve something for a person, the entire company, or all of our clients. We can choose to approve only the hash or a particular version of a particular executable or any application that is signed by a company. We can define how loose or tight we want to be when it comes to certain applications. They have recently also introduced time-based approval. We can give approval for only a period of time, and then the approval goes away. If somebody needs to run something, but we do not want it to be allowed to run for a long period of time, we can implement that. In terms of access requests, we control what is allowed and what is not allowed. They have curated things on our behalf for Windows, Office, Chrome, Firefox, and a whole slew of other applications, but you do not have to add those. You can curate your own list. For example, we have an engineering company, and the applications that they use are not used by anybody else. They are very bespoke for their specific industry. We get new requests from them all the time. We check if it is something that looks nefarious. Is it on VirusTotal? Are there any other scans that show that it could be potentially malicious? If we are still not sure, ThreatLocker now has a sandboxing feature where we can watch the application execute in a secure environment and see if it is doing anything potentially bad and if it is touching files that it should not be touching. By doing that, we have some more comfort. We know that the program we are allowing is safe. We were able to see some of its benefits immediately and some were over time. We were using an EDR tool before ThreatLocker about six years ago. It was very noisy. A lot of alerts came up on that EDR. We were chasing a lot of ghosts, trying to figure out whether it was malicious or not. A lot of it was not malicious, but we still had to do all that checking. When we put ThreatLocker in place, one of the things that we immediately noticed was that it was blocking everything by default and only allowing things that we approved. It reduced the ticket noise. We mostly had things that needed investigation and more likely were malicious and needed to be reviewed. That was an immediate change. Over time, we got other benefits. We got a better grasp of what is being run on our clients' desktops. In the rare cases where because of the nature of their work, we allow them to have admin rights, we can still control what applications are being installed. Could they bypass it? Potentially and theoretically, yes, but that would be very difficult and require some technical skill. We at least have some verification of what applications are run and what applications are allowed. So, its long-term benefit was much more control over the clients' environments and the short-term or immediate benefit was a reduction in ticket noise that we were having to deal with chasing a lot of false positive alerts. Allowlisting helped us reduce our organization’s help desk tickets. We were able to reduce our security alerts by 75% to 85% after its implementation, and now, it is practically down to zero. We have very few alerts that we need to chase at this point. Allowlisting has technically helped us to free up help desk staff for other projects, but we have not quantified the savings. Because we are not having to do these other things, we are able to work on helping clients and get their work done better rather than just chasing security events. Allowlisting has not helped us consolidate applications and tools because our usage is quite narrow. We are just using allowlisting, ringfencing, and a little bit of elevation. They have other products in their mix, but we already have other products that do some of those things. I do not see us necessarily replacing all of that with other parts of ThreatLocker, so there is no tool reduction. However, it fits nicely into our workflows. In other words, it integrates into our PSA. Tickets come in there, and from there, we can go directly to ThreatLocker and do approvals. We also have the pop-ups on the mobile device.
