Managing application control amid increasing ransomware threats while not impeding business flow remains a challenge. Organizations need a layered defense to bolster their security posture without overinvesting in overlapping tooling.
In this episode, Rob Allen, chief product officer at ThreatLocker, discusses how their deny-by-default approach to application control helps simplify this persistent challenge. Rob is joined by our panelists, Janet Heins, CISO at ChenMed, and Shaun Marion, vp, CSO at Xcel Energy.
Got feedback? Join the conversation on LinkedIn.
Huge thanks to our sponsor, ThreatLocker
Full Transcript
[Voiceover] Connecting security solutions with security leaders. Security You Should Know starts now.
[Rich Stroffolino] Welcome to Security You Should Know. Today, we’re talking with ThreatLocker and what they’re doing in application control. The problem they’re addressing, it’s a big one. Building defense in depth against ransomware attacks, something that’s always in the news when we’re on Cyber Security Headlines.
Helping us get answers to these questions are Janet Hines, CISO over at ChenMed, and Shaun Marion, VP and CSO at Xcel Energy. Janet, I’m going to start with you. Why are we still struggling with ransomware and then building that defense in depth? We know it’s the right solution, right? Why is it still a problem?
[Janet Hines] There are so many attack vectors and defense in depth is necessary. There really isn’t one solution to prevent ransomware. And so, companies need defense in depth.
[Rich Stroffolino] Shaun, I’m going to turn it to you. Why are we still struggling with this?
[Shaun Marion] I will say I’m happy to some degree. It means I’ve still got a job. When it comes to defense in depth, I think there’s a thin line between defense in depth and expense in depth. So, making sure that we’re using the tools that we have appropriately. And so, I know we talk today with Rob.
I’m sure one of the questions will be, what can we take out if we add in an additional tool, additional capability? But above all, I agree with Janet. There’s so many attack vectors, one layer, one level, that’s not going to be enough to defend ourselves against everything we need to.
[Rich Stroffolino] All right. Well, today we’re going to be talking to Rob Allen, chief product officer at ThreatLocker, about their application control solutions, just trying to solve this conundrum here. To start out, we’re answering three essential questions. So, Rob, how do I explain the value of your solution to my CEO?
What does the solution do and what does it not do? And can you give us some details about the pricing model and help us out with these preliminaries?
[Rob Allen] So, from a convincing your CEO perspective, look, there is no one solution. There is no one golden or silver bullet, rather, that’s going to stop all cyber attacks. Stopping things by default or denying things by default is a really good place to start, though. Because if nothing can run that you haven’t explicitly allowed, then bad things can’t run, ransomware can’t run, remote access tools that you don’t want to run in your environment can’t run.
And we start talking, and again, you said it is a very wide and deep problem, and you start talking about how things like PowerShell can be misused, how you can do remote shells by PowerShell or data exfiltration by PowerShell. That’s where ring fencing comes into it. So, there’s two parts of the problem, really.
There’s the what can run and what can’t run, which allow listing solves, and then there’s the what things can do when they are running, which is what ring fencing solves.
[Rich Stroffolino] We’re all set up. And that means I’m excited that we get to go to our panelists and get into the questions. I’m sure you’ve got a lot of questions. So, Shaun, I’m going to come to you first. What other questions do you have for ThreatLocker?
[Shaun Marion] Yeah, so maybe dig a bit more into this concept of ring fencing. I think we all understand kind of app whitelisting, and if you guys do something different, let me know, but I would like to know a bit more about your concept of ring fencing and how that applies to the equation here.
[Rob Allen] Absolutely. So, as I said, there’s two parts to application control from our perspective. There’s the what can run and what can’t run, which, as I said, is allow listing. It’s pretty simple. It’s a concept as old as the hills, really. But I would argue that we do it better, more manageably than anyone else.
Ring fencing is specifically about, okay, there are certain things that we know are running in our environment. Now, can we put controls and limits on what these things can do to stop them from being weaponized, stop them from being used against us? I mean, a really big problem is living off the land.
It’s using what’s already on your computer against you, whether it be PowerShell or RunDLL or cURL or any of those basically dangerous and weaponizable Windows components. Can we put restrictions on them, stop them from reaching out to the internet, for example, or does PowerShell need to access my files, or even does Office need to call PowerShell, or does Office need to call Curl?
I mean, realistically, probably not. So, if you can put controls and restrictions in place around these applications, controlling what they can do, what they can call, what data they can get out and where they can go on the internet, you’re going to minimize or restrict or reduce the possibility of them being weaponized and used against you.
[Shaun Marion] So, maybe a quick clarifier on that because a lot of the tools you mentioned, for better or worse, they’re weaponizable, but they’re also used heavily by our sysadmins. I’ll pick like PowerShell for an example.
[Rob Allen] Absolutely
[Shaun Marion] So, PowerShell is one of those things that we both love and hate. So, if my admins or whatever are going to roll out some new PowerShell, is it that they need to work with the admins of the platform to make sure that it’s whitelisted? Or am I saying that right? And how would they do that, so they don’t roll this out and it fails in production?
[Rob Allen] Broadly speaking, we’ll see most of these behaviors during what we call a learning period. So, basically at the start, when you deploy the agent, we’re going to see what things do and how they behave. I mean, in terms of something like your administrators, for example, or your techs, I mean, they don’t necessarily need the same level of restrictions that your finance department need.
So, it’s not a case of tarring everybody with the same brush. You can have different restriction levels for different groups, different people within your organization. But as I said, generally speaking, we’ll see how applications behave and we’ll be able to build these policies accordingly to allow, broadly speaking, people do what they need to do and no more.
And it’s the “and no more” is the really important bit, and that’s the bit that’s going to keep you safe.
[Janet Hines] So, following the learning mode, do you have a monitor mode, where you can see what would happen as opposed to actually make it happen?
[Rob Allen] Yeah, absolutely. So, basically when it’s in that period, nothing’s going to get blocked. We’re not going to get in the way. We’re not going to stop anything. You can then look at what we call simulated denies. So, a simulated deny is all of the things that would be blocked had ThreatLocker been turned on.
The idea being that by the end of this process, you’ll get to a point where there’s very little by way of simulated denies. So, everything will have effectively a policy or a rule set created to allow, as I said, it to continue to be able to do what it needs to do. But once you’ve satisfied yourself working with our solutions engineers, that, “Look, nothing is going to break if we turn this on,” you enable it, and then from that point forward, again, nothing that isn’t explicitly allowed will be allowed to happen.
[Janet Hines] Yeah. So, following up on that, we have some custom applications that get enhanced on a pretty regular basis that we use. So, I think ring fencing and the what they can do may require a little extra management, maybe, at our organization, just due to that fact. What does that look like?
Is that you’re able to put that in that monitor mode and then…?
[Rob Allen] Absolutely. You can put specific applications or specific policies in monitor-only state. So, basically, they’re not going to be enforced. We’re not going to enforce the controls around those things. So, absolutely. You can be, again, as specific or as general as you want. You can turn it on for everything.
You can say, “Look, I want to exclude this particular application because I know it acts a bit funny, and we want to get a better picture of what that does.” So, yeah, you can be as general or as specific as you want with these things. You can literally get down to the level of file hashes. Most of what we do is based on file hashes, but you can also build out policies.
Like one of the most common questions I get asked is what about developers? Our developers are creating new stuff all the time. We can create, again, a set of policies using paths and processes and created by processes and certificates, if needs be, to, again, allow them to do what they need to do and no more.
[Shaun Marion] You made a statement earlier I’m curious about. So, back to now go to application whitelisting, which has been around since time began, at least for security, it seems like. But you made a statement, you said that you feel like you can do it better. Elaborate on that. How do you guys do it better?
And make that make sense to me.
[Rob Allen] So, there’s two parts of it. One is that learning period I mentioned. So, we’re going to do a lot of the heavy lifting. We’re going to create the policies automatically. You don’t have to know everything that’s in use on every machine in your environment. We’re going to see all of those things during that learning period and we’re going to build policies for them.
So, that’s half of the heavy lifting of allow listing taken care of. The other half of the heavy lifting, if anyone’s ever tried to implement allow listing, they’ll know that probably the biggest question or problem is what happens when software updates. And generally, what happens with software updates is it breaks because your allow listing says, “Look, I know that file is called Acrobat.exe, but it doesn’t match my hash for Acrobat.exe, so I’m not going to let it run.”
Now, the way we’ve solved that problem is we’ve got this concept of what we call built-in applications, which are application definitions, database of 8,000-plus applications that we maintain definitions for. We’ve got an applications team, 80 strong, sitting outside the office here in Orlando, who basically their job is to download, install, and catalog software.
They do it 24-7, 365, every one of those 8,000-plus applications. They maintain definitions for it, which get pushed down automatically, which means you don’t need to worry about updates causing problems with your software.
[Shaun Marion] So, I want to build off that for a hypothetical here. First of all, I like that. The question would be, so there was another big security provider, I won’t say their name, but sometime last year, they took down most of the world due to an application update. And your environment or with your product, it theoretically could do the same thing if it blocked everything.
What is the control method in there to make sure that we don’t have a similar situation like that where you guys roll out an update or something and it just bricks our machines?
[Rob Allen] To some extent, it comes down to the nature of what we do versus the nature of what those other software companies do. I mean, number one, from an update perspective, I mean, we don’t update our software a lot. We don’t need to update our software a lot because of the nature of what we do, which is to deny by default.
We don’t have constant definitions that are going out. We don’t have to respond to new threats. We don’t have to respond to new tactics and techniques for the most part. So, it’s not a 10, 15 different update files get pushed out a day. It’s yes, the applications get updated, but that’s just hashes getting pushed down to machines.
For the most part, we don’t have to do what they do. Now, as I said, the other part of it is we are extremely careful when we do have to push out new updates and new versions that it’s done in small chunks. So, we’re not pushing updates out to many millions of machines at once. We’re pushing them out to 10, 15, 20,000 machines a day.
And if there’s a problem with that update, we’re going to find out pretty quickly and basically roll back or stop it from updating. Fun fact, and I know I’m probably going to get the unhappy thing waved at me now in a second. Can you ask me a follow-up question to that? Because I do have an interesting story about that particular event.
[Shaun Marion] Yeah, I’d be curious to know if you have a follow-up story to that particular event.
[Rob Allen] Yes, I do. We were actually able to help quite a number of mutual customers. So, one of the things that we do, and it’s not the subject of this conversation, but storage control. So, we were able to create a storage control policy that blocked CrowdStrike’s access to the problematic .sys files.
So, basically, we got loaded before CrowdStrike, we were blocking it from accessing the files that were causing it to blue screen. So, we were able to help quite a lot of our mutual customers out in avoiding the blue screens from happening to them because we were able to block CrowdStrike from accessing what caused the problem.
We also had numerous customers who just said, “Look, I want to block CrowdStrike. I just don’t want the program CrowdStrike from being able to run.” And similarly, that helped a lot of customers. Basically, okay, we don’t want this thing to run because we know it’s going to blue screen machines. Can you stop it from running?
And again, allow listing is perfect for that kind of thing. Just create a policy to block CrowdStrike from running. It wasn’t able to run, it wasn’t able to do blue screen.
[Janet Hines] So, during your learning mode, you’re building, you’re seeing what’s happening. How do you differentiate what should be allowed versus what shouldn’t be allowed?
[Rob Allen] That’s a really good question. So, first of all, one of the things that the visibility that we offer, basically the fact we log everything. We can see literally from one unified audit, everything that runs within an environment. We can see all the policies that we create. We can see all the applications that we’ve created policies for.
One big eye opener that pretty much every customer that I’ve spoken to has is there are things there that they did not know about. There are things there that they would not have otherwise wanted. So, whether it be things like remote access tools, I mean, a lot of environments have got five, six, seven different remote access tools running on their machines.
And they don’t know that. They didn’t know that prior to ThreatLocker coming along and saying, “Hey, look, we just created a policy for TeamViewer for 20 machines,” or for AnyDesk for five machines or whatever the case may be.
So, yeah, deciding is a lot easier when you know what’s there. If you don’t know what’s there, you have no mechanism or means or way of deciding what’s allowed and what’s not. So, yeah, you start with what’s there, you start with visibility, and then you can make decisions about, well, this thing doesn’t need to be allowed.
So, I’m just going to change that policy from a permit to a deny. No more AnyDesk, for example.
[Janet Hines] Yeah, so my follow up to that would be, I think you mentioned machines, is there a way to apply this to users? So, I’m just thinking like your help desk needs to log onto my machine and they want to do something that I’m not allowed to do.
[Rob Allen] Absolutely. Yeah, very much so. We can think of things like Azure AD groups, and you can create a policy for my support group to be able to do X, Y, and Z. So, yeah, absolutely, we can do it based on users as well.
[Janet Hines] Regardless of what machine they’re on, yeah.
[Rob Allen] Correct.
[Janet Hines] Great. Thank you.
[Rich Stroffolino] Well, Rob, what’s one thing we didn’t ask about that we need to know?
[Rob Allen] One thing to bear in mind is the issue of shadow IT. So, a lot of IT departments are overwhelmed and overloaded with basically cleaning up things that users have done. I’ve experienced this personally because I worked for an IT company for almost 20 years and probably, I’d say 80% of the work that I did was cleaning up stupid mistakes, stupid things that user had done, whether it be installing 15 different Chrome extensions or 4 different toolbars or 3 different antiviruses on the machine.
All of those things, basically, I ended up cleaning up. And again, if you take away users’ ability to do all of those stupid things, you’re not going to have to spend your entire IT department’s time and budget in cleaning them up.
The other thing to bear in mind, as I said, it’s just think about all those pieces of software that you use every single day that can be exploited, that can be used against you. There’s so, so many of them, whether it be browsers with vulnerabilities, or as I said, things like remote access tools that are just able to run on your machine.
It’s not because they’re good and bad. I mean, they’re going to be allowed by your EDR and your AV. I will say, and last point, is you talk about defense in depth. Defense in depth, from our perspective, is about layered defense. So, it’s about different types of defenses. It’s not about layering the same type of defense on top of each other.
So, AVs, EDRs, MDRs, all those things that end with D and R, they’re all looking for the same known bad things, okay? And very often falling over each other when they find them. So, we layer control, which is allow listing and ring fencing, with detection. So, it’s two different strategies. It’s two different types of defenses, which combined will put you in a far better place than depending on just detection.
[Rich Stroffolino] Well, that’s it for this episode of Security You Should Know. To learn more, head on over to threatlocker.com. A huge thank you to Janet Hines and Shaun Marion for helping us learn more about ThreatLocker, and thanks to Rob Allen for your time and being game to answer all of these questions.
And thank you for listening to Security You Should Know.
[Voiceover] That wraps up another episode of Security You Should Know. If you like this program, please subscribe, tell your friends, and leave us a review. All companies showcased on this program are sponsors of CISO Series. If your company would like to be spotlighted and interviewed by our security leaders, go to our contact page on CISOseries.com, or just email us at info@ciso-dev.davidspark.dcgws.com.
Thank you for listening to Security You Should Know, connecting security solutions with security leaders.