Unauthorized site access remains a significant security concern for organizations. But why does this issue persist, and how can it be effectively addressed?
In this episode, Rob Allen, chief product officer at ThreatLocker, discusses the core functionality of ThreatLocker’s Web Control solution: blocking access to unauthorized sites without meddling with DNS servers—a common pitfall among other tools. Rob explains that the simplicity of defining where employees can and cannot access is pivotal. This approach not only helps keep users away from malicious sites but also steers them clear of non-productive ones, thereby enhancing resource allocation. Rob is joined by our panelists, TC Niedzialkowski, Head of IT & Security at Opendoor, and Sasha Pereira, CISO, WASH.
Got feedback? Join the conversation on LinkedIn.
A 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 web controls. Now, the problem they’re addressing here is users going to unauthorized sites. It doesn’t matter if it’s phishing or they’re just curious. We want to know how to solve this and helping us get answers to this is TC Niedzialkowski, former CISO over at Nextdoor and Thumbtack, as well as Sasha Pereira, CISO at Wash.
TC, I’m going to start with you. Why are we still struggling with controlling access to these unauthorized sites?
[TC Niedzialkowski] I think one of the challenges is that a lot of the attacks, if you think about phishing, right, or if you think about data loss prevention or malicious websites, it’s coming through the users, through the employees’ browsers, and I think the idea is if we can make their browsing safe, we can avoid where these attackers are trying to meet their victims.
[Rich Stroffolino] Sasha, I’m going to turn this to you. Why are we still struggling with controlling this access?
[Sasha Pereira] The biggest one for me is part of what TC just said as well is all phishing emails that don’t have active payloads in them need a browser. They effectively need you to click on a link, which translates into a browser, and that’s where the problems start, is that link that they click on.
And if you look at it, 75% of ransomware that is emailed, a majority of that 75% is links that people click and put in credentials. So, again, it comes down to the browser, like where are people putting credentials in, into a browser?
[Rich Stroffolino] Well, today we’re thrilled to be talking with Rob Allen, chief product officer at ThreatLocker, about their web control solution and what they’re doing to solve this problem. To start out though, Rob, we need you to answer three essential questions. First off, how do I explain the value of web control to my CEO?
What does it do and what does it not do, its limitations, and what is the pricing model? Can you help us out with these preliminaries?
[Rob Allen] Sure, explaining the value to your CEO, I mean, just point at Doris in the corner and say, “See the way she’s on Facebook all day? Do you want to do something about that, or do you want to let her just keep doing that?” Obviously, that’s being slightly facetious, but controlling where people can go on the internet and more specifically where people can’t go on the internet is a pretty fundamental part of any security strategy.
I mean, as the guy said, malicious websites is one thing, but also unproductive websites are another thing. And again, that’s a huge thing in resources. So, your CEO, yeah, we’re going to control all this stuff. We’re going to stop all the bad stuff or block all the bad stuff. We’re also going to stop all the unproductive stuff as well.
And I have forgotten the second question again.
[Rich Stroffolino] What does the solution do and what does it not do?
[Rob Allen] It blocks access to places you don’t want people to be able to access on the internet. And what does it not do? It doesn’t muck around with your DNS servers on your computers, which is what a lot of other tools like this do, and they cause all sorts of problems and issues and machines going offline.
So, we don’t touch DNS on the machines.
[Rich Stroffolino] All right, CISOs, we’ve gotten a taste for web control, but I’m sure you have a lot of questions. Sasha, I’m going to start with you. What other questions do you have for Rob?
[Sasha Pereira] So, I have a lot of tools in place to sort of help prevent things, right? Ranging from umbrella, it used to be called open DNS, right? Preventing and trying to find those threats. How does ThreatLocker stay ahead of the game in terms of finding those zero-day vulnerabilities?
[Rob Allen] Well, there’s a couple of ways. I mean, obviously, we get information through a lot of different sources. We also have our own insights data. So, we can basically see where people pretty much everywhere are going on the internet, etc. One of the cool things you can actually do with this, I have constant discussions with our CEO, Danny, and he doesn’t think this is a cool thing you can do, but I very much do, which is we can actually set up a default-deny policy for web control.
So, we can say, “I want people to be able to go to these locations. I want them to go to business tools. I want them to go to social media. I want them to go to X, Y, and Z websites. If it doesn’t match any of those categories, block it.” So, that basically stops everything that you haven’t explicitly allowed.
So, that is one way you can use it. I mean, you can use it obviously just to block specifically stuff that you don’t want, but you can also block by default, which is pretty cool because it basically just takes away all of the doubt. If it’s not on the list, if it’s not explicitly allowed, it’s going to get denied.
Now, again, it’s not a core function. It’s just something pretty cool you can actually do with it as well.
[Rich Stroffolino] And TC, what questions do you have for Rob about web control?
[TC Niedzialkowski] Yeah, so when it comes to implementing web control across a fleet, across an employee base, what type of coverage do you have in terms of Mac, Windows, Linux, potentially mobile, and then not just, I guess, major browsers, right? CLI or other thick clients that can make web requests.
What type of coverage do you have across those and how are you able to get beyond just covering, for example, the standard browsers?
[Rob Allen] Sure. Well, I mean, from a pure web control perspective, it is fundamentally about browsers. There are other things that you mentioned, so things like CLIs and stuff like that. We have another solution, which is called ring fencing, which can control where they can and can’t go. So, again, same principles, deny by default, permit by exception.
So, I want PowerShell not to be able to access the entire internet, but to access these locations. So, we have a solution for pretty much everything. You can ring fence anything you want. So, whether it be a SolarWinds agent or a PowerShell or a cURL, stop it reaching out to the internet, we can do all of that with ring fencing.
From a web control perspective, we’ve got Windows obviously covered, we’ve got Mac covered as well. We also have a solution which is effectively DNS, which we’re not crazy keen on, but it is something that is required for those unprotected devices. So, things that ThreatLocker is not running on, I want to point my Wi-Fi networks DNS to ThreatLocker.
So, basically the same policies, the same controls that we can put in place via the agent, we can also do via DNS requests as well. So, we pretty much have full coverage of both things that we run on and also things that we don’t run on too.
[Rich Stroffolino] The floor is open.
[Sasha Pereira] Yeah, so I know you mentioned about connecting like your Wi-Fi or things to ThreatLocker. Does this work in tandem with an existing DNS sort of protector or does it work solely as the one in the… Because for me, I’m thinking, can I eliminate a tool in my stack or does it need to exist, coexist?
[Rob Allen] Technically both, but I mean, absolutely. There is certainly an argument that it could replace some other DNS protection or again, I don’t want to be too specific about it, but yeah, absolutely.
[Sasha Pereira] Okay.
[Rob Allen] Again, the beauty about it is from our perspective, and one thing that we’ve been really big on with this is user experience. So, we actually have a method whereby if I get blocked from accessing a gambling site, for example, we have a mechanism whereby we use extensions and Chrome and Edge, which will actually pop up and go, rather than giving a SSLR message and just, “You can’t access this,” we can actually tell them it’s been blocked because you’ve got a policy in place to block access to gambling sites.
If you’d like to request this, you can. So, they can actually request exceptions to the block for specific reasons. So, I like to gamble, send that request off, administrator approves it within 60 seconds, the user is able to access their gambling website. So, the user experience is really important as part of this.
It’s not just that it gets blocked and users get frustrated. It gets blocked. They get a reason why it’s got blocked and they have the ability to request an exception to the block as well, which is pretty cool.
[Sasha Pereira] Does the request for unlock go like through like a separate ThreatLocker system in an email or is it something that can be integrated into an existing service desk ticketing system?
[Rob Allen] Oh, it’s exactly the same as the rest of ThreatLocker fundamentally. So, whether it be ServiceNow or an RMM for an MSP, I mean, we’ve got lots of different ways, a multitude of different ways to get requests to the administrators. But whatever they might be for everything else, it’s the same portal, it’s the same agent that’s controlling this.
This is the beauty about it. It’s not like you have to have two, three, four, five different agents for controls and for MDR and for web filtering. It’s one agent, it’s low impact. As I said, it’s basically the same product that people know and trust. It’s just we’ve added this additional layer of protection which is web filtering or web control.
[Sasha Pereira] Is there anything you do from, in terms of protecting, like known malicious websites? I had seen this with Umbrella and I’m not familiar with how it works with ThreatLocker. They would, if there’s a certain IP address range that was found to be malicious, it would look for nearby IP address ranges and potentially mark them as could be unsafe because typically threat actors tend to be at a certain ISP and then kind of move around the ISPs when certain IPs get blocked.
Is that something that ThreatLocker does?
[Rob Allen] Interesting. No is the short answer. So, we have our databases of known malicious and categories and everything else. I mean, I think the known malicious is one of the biggest, if… Actually no, sorry, I lied. It’s the second biggest behind adult content. Now, obviously they’re updated pretty constantly but as I said to you before, we could equally just do a block all unknown websites if needs be.
So, you don’t need to worry about blocking specific malicious websites if you’re blocking all websites that aren’t explicitly allowed by default.
[TC Niedzialkowski] Okay, that makes sense. I have a question around when it comes to these targeted phishing attacks or business email compromise, the website or the domain itself might be explicitly allowed, right? Like it’s a Google Forms website or it’s hosted on Salesforce, or it’s hosted on AWS, and so that domain might be allowed but essentially an attacker is using that to capture the victim’s, the target’s information.
Does WebLocker have the ability to detect those types of attacks that occur in the browser and prevent those? And how does that work?
[Rob Allen] So, there’s a few different parts to that. So, that’s a really deep question. I mean, we, again, we’ve got a fairly expansive platform. So, the first part that I should mention is we’ve got, again, ring fencing. So, we can ring fence browsers. So, we can stop a browser from calling something else.
So, say a PowerShell, for example, or whatever the case may be. So, we can stop that at that level. And again, this is probably a conversation for another day, but we also have a cloud control component which basically updates Azure’s, for example, name locations and conditional access policies. So, basically you can do the same thing as you can do with network control, which is deny by default, permit by exception.
So, I’m only going to allow IP addresses for an app that we’ve got running on the phone or people’s computers that are running ThreatLocker to connect to my Azure portal. So, it doesn’t matter if your credentials get phished fundamentally because even if somebody has your credentials or a token or anything else, they’re not going to be able to get access because they’re not going to match those conditional access policies.
So, there’s three or four different layers to this. As I said, it’s a fairly expansive platform but that we have a number of different things that we can do. Plus, also we’ve got – and we spoke about MDR a moment ago – we’ve also got detection and response for cloud as well. So, if something unusual happens or somebody tries to log in from an IP address in God knows where, you’re going to get an alert as well.
So, there’s three or four different layers to that.
[TC Niedzialkowski] When it comes to preventing access, blocking access to malicious websites, how does it work for ThreatLocker when this particular campaign has an N of one? What I mean by that is there’s some domain, there’s some infrastructure, some IP address that the attacker is using, and this is the first time they’re using that domain or IP.
So, I’m assuming it’s not already in your known bad list. How does ThreatLocker proactively prevent that type of malicious access?
[Rob Allen] Deny by default. So, the very last policy in your web control policies list can just be a block everything. So, it doesn’t matter what the IP is. It doesn’t matter if it was created today, yesterday, known bad, not known bad. It really doesn’t make any difference. It’s the beauty of deny by default in everything that we do, whether it be application control or what stuff can do or network control or everything else.
If your fall back, if your last option is to deny by default, then it really doesn’t matter. You don’t have to depend on knowing everything to be bad because realistically nobody knows everything that is bad.
[TC Niedzialkowski] What percentage of your customers are able to implement that deny-by-default policy?
[Rob Allen] From a web control perspective?
[TC Niedzialkowski] Yeah.
[Rob Allen] Again, most people don’t do that many different things on the internet in an average day. I mean, realistically, if you think about how many different websites… Well, again, I could be talking to two internet addicts here, [Laughter] I don’t know, but you don’t look like internet addicts.
But I mean, realistically, I know in my own circumstance, I mean, there’s probably about 10 or 15 different websites I’d access on a given day. In fact, it’s probably 10 or 15 different websites I’d access in a given week or a given month because I don’t actually tend to do that much out of the ordinary that different.
You know what I mean? I’ve got my computers, and I’ve got SquadCast and 5 or 10 other different things. So, most users are quite similar to that. Now, as I said, there’s always going to be exceptions. You know what I mean? There’s always going to be the exception to that rule, which is somebody who literally spends all day on a million different websites.
But that is very much the exception rather than the rule. Most users just do the same things with their computers in the same way every single day. And realistically, just set boundaries around that, guardrails around that and say, “Look, off you go.” But obviously, from allow listing perspective, it’s a much different question and basically, everybody who uses ThreatLocker uses default deny in that context.
[Rich Stroffolino] And Rob, what’s one thing we didn’t ask about that we need to know?
[Rob Allen] We may have mentioned it briefly, but with this, user experience is really important. You don’t want users to be getting, when something is blocked, to get an SSL error and not understand what that SSL error means. You don’t want somebody to be blocked from accessing something and not know why.
You don’t want somebody to be blocked from something and not have any mechanism or means where they can say, “Hey, I need access to this now, and I can’t wait for two days or three days or four days for somebody to recategorize it. I need to access the site that I need to access now. Can I have access to it, please?” So, being able to do that, as I said, within seconds and having it evaluated and approved within 60 seconds is a real game changer for this kind of approach and solution.
[Rich Stroffolino] Well, that’s just about it for this episode of Security You Should Know. To learn more, head on over to threatlocker.com. A huge thank you to TC Niedzialkowski and Sasha Pereira for helping us learn more about ThreatLocker, and a big thanks to Rob Allen from ThreatLocker for your time and being game to answer all of these questions and get into the details.
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@CISOseries.com.
Thank you for listening to Security You Should Know, connecting security solutions with security leaders.