Welcome to Unsupervised Learning, a security, AI and meaning focused podcast that looks at how best to thrive as humans in a post AI world. It combines original ideas, analysis, and mental models to bring not just the news, but why it matters and how to respond. All right, Rob, welcome to Unsupervised Learning.

Welcome to Unsupervised Learning, a security, AI and meaning focused podcast that looks at how best to thrive as humans in a post AI world. It combines original ideas, analysis, and mental models to bring not just the news, but why it matters and how to respond. All right, Rob, welcome to Unsupervised Learning.

Hi, Daniel. Thank you for having me.

Hi, Daniel. Thank you for having me.

Excellent. So can we get you to give a brief intro into yourself and talk about Threatlocker and what you guys do over there?

Excellent. So can we get you to give a brief intro into yourself and talk about Threatlocker and what you guys do over there?

Sure. So I'm Rob Allen. I am chief product officer here at Threatlocker. As you can probably tell from my Midwest accent, I'm. No, I'm not from the Midwest. I'm from Ireland. And I've worked at Lockhart for about almost four years now. And Threatlocker are a zero. Zero trust cybersecurity solution. So a endpoint protection platform effectively. And we take a slightly different approach to cybersecurity, to most other tools, and fundamentally, where other things allow everything except what's known to be bad. We take the approach of block everything unless it's explicitly allowed, and a few different ways we do that, a few different aspects to it. But fundamentally it's a design by default, permit by exception approach, which is pretty much a cornerstone of zero trust.

Sure. So I'm Rob Allen. I am chief product officer here at Threatlocker. As you can probably tell from my Midwest accent, I'm. No, I'm not from the Midwest. I'm from Ireland. And I've worked at Lockhart for about almost four years now. And Threatlocker are a zero. Zero trust cybersecurity solution. So a endpoint protection platform effectively. And we take a slightly different approach to cybersecurity, to most other tools, and fundamentally, where other things allow everything except what's known to be bad. We take the approach of block everything unless it's explicitly allowed, and a few different ways we do that, a few different aspects to it. But fundamentally it's a design by default, permit by exception approach, which is pretty much a cornerstone of zero trust.

Mhm. Interesting. Yeah. That's one of my next questions is basically what is what is it that you're doing different. So that that's fascinating. Um and the reason most people can't do that, especially back in the firewall days or whatever, there was just too many things to have to poke holes through. So I imagine you've found some pretty interesting ways to, uh, to allow benign behavior. So how are you doing that?

Mhm. Interesting. Yeah. That's one of my next questions is basically what is what is it that you're doing different. So that that's fascinating. Um and the reason most people can't do that, especially back in the firewall days or whatever, there was just too many things to have to poke holes through. So I imagine you've found some pretty interesting ways to, uh, to allow benign behavior. So how are you doing that?

So there's a few parts of what we do. So first of all, the core of what we do is allow listing. So it's basically allowing what needs to run to run. I'm blocking everything else now. Anybody who's ever tried to do that probably knows that historically, that has been somewhat, even though it is kind of the gold standard in terms of cybersecurity. It is kind of a heavy lift with some of the tools that are out there. It's a lot of hard work, basically, and we do a few things differently that make it manageable. We make it attainable for even, you know, small and medium organizations. And first thing that we do differently is we basically learn everything automatically. So you deploy an agent onto your machines. It does all the hard work effectively. So it figures out everything that's required on the machine and creates policies to allow those things to continue to run once the threat has been turned on. So that's kind of the first way that we make this process much easier. The second way. And again, anybody who's ever tried to implement a listing will know that one of the biggest problems is the question of what happens when software updates. And generally speaking, What happens when software updates? Is it breaks because whatever licensing solution you're using will say, well, look, I know that file is called acrobatics, but it doesn't match my acrobatics, so I'm not going to let it run. Um, and that has always been one of the biggest hurdles with implementing this approach. So what we do to solve that problem is we have this concept of what we call built in applications, which are effectively application definitions that we maintain, we manage. We've got over 4000 common applications, everything from Acrobat to teams to zoom to office. I mean, technically, windows is kind of a built in application as well, but every time there's an update for any of those things, our applications team who are based here in Orlando working 24 over seven, 365 will run. It will capture any new files that are included in that application, and it gets pushed down to people's machines automatically. So anybody who has a definition for or a policy for teams, for example, new update comes out, they capture it. It gets pushed down to every machine that's running teams automatically. So effectively it takes a lot of the heavy lifting. It takes a lot of the hard work out of what used to be quite an involved process.

So there's a few parts of what we do. So first of all, the core of what we do is allow listing. So it's basically allowing what needs to run to run. I'm blocking everything else now. Anybody who's ever tried to do that probably knows that historically, that has been somewhat, even though it is kind of the gold standard in terms of cybersecurity. It is kind of a heavy lift with some of the tools that are out there. It's a lot of hard work, basically, and we do a few things differently that make it manageable. We make it attainable for even, you know, small and medium organizations. And first thing that we do differently is we basically learn everything automatically. So you deploy an agent onto your machines. It does all the hard work effectively. So it figures out everything that's required on the machine and creates policies to allow those things to continue to run once the threat has been turned on. So that's kind of the first way that we make this process much easier. The second way. And again, anybody who's ever tried to implement a listing will know that one of the biggest problems is the question of what happens when software updates. And generally speaking, What happens when software updates? Is it breaks because whatever licensing solution you're using will say, well, look, I know that file is called acrobatics, but it doesn't match my acrobatics, so I'm not going to let it run. Um, and that has always been one of the biggest hurdles with implementing this approach. So what we do to solve that problem is we have this concept of what we call built in applications, which are effectively application definitions that we maintain, we manage. We've got over 4000 common applications, everything from Acrobat to teams to zoom to office. I mean, technically, windows is kind of a built in application as well, but every time there's an update for any of those things, our applications team who are based here in Orlando working 24 over seven, 365 will run. It will capture any new files that are included in that application, and it gets pushed down to people's machines automatically. So anybody who has a definition for or a policy for teams, for example, new update comes out, they capture it. It gets pushed down to every machine that's running teams automatically. So effectively it takes a lot of the heavy lifting. It takes a lot of the hard work out of what used to be quite an involved process.

Oh very interesting. So, so, um, so essentially you're watching all these core applications. It sounds like roughly 4000 or so. And then, um, any new update that comes out that immediately comes to you, you're instrument it and re push it down as part of the allow list.

Oh very interesting. So, so, um, so essentially you're watching all these core applications. It sounds like roughly 4000 or so. And then, um, any new update that comes out that immediately comes to you, you're instrument it and re push it down as part of the allow list.

So we don't push it down per se. What we do is we push down hashes. We push down new files that are allowed. So when our customer tries to run those new files, they will be allowed to do so. So yeah we update the application definitions constantly like every one of those applications, as far as I know, is checked pretty much once a day. Um, some things far more often than that. I mean, Chrome updates often and sporadically. So we might check that for argument's sake, 12 times a day. And just to make sure that we capture all those hashes as soon as possible. So by the time customers come to install them, they don't have any problems with their software being blocked. We would like this. Patch Tuesday is our busiest or our OP team's busiest day of the month. And you know, there could be five, ten, 15,000 new hashes pushed out by Microsoft as part of Patch Tuesday. So they all need to be accounted for. They all need to be allowed when our customers try and run them. So as I said, our app team our the it's kind of the secret sauce, the special sauce as to why Threadlocker is as easy to manage as it is, because we're taking a lot of that heavy lifting, a lot of that responsibility. We're taking it off customers and taking it on ourselves.

So we don't push it down per se. What we do is we push down hashes. We push down new files that are allowed. So when our customer tries to run those new files, they will be allowed to do so. So yeah we update the application definitions constantly like every one of those applications, as far as I know, is checked pretty much once a day. Um, some things far more often than that. I mean, Chrome updates often and sporadically. So we might check that for argument's sake, 12 times a day. And just to make sure that we capture all those hashes as soon as possible. So by the time customers come to install them, they don't have any problems with their software being blocked. We would like this. Patch Tuesday is our busiest or our OP team's busiest day of the month. And you know, there could be five, ten, 15,000 new hashes pushed out by Microsoft as part of Patch Tuesday. So they all need to be accounted for. They all need to be allowed when our customers try and run them. So as I said, our app team our the it's kind of the secret sauce, the special sauce as to why Threadlocker is as easy to manage as it is, because we're taking a lot of that heavy lifting, a lot of that responsibility. We're taking it off customers and taking it on ourselves.

Yeah.

Yeah.

Very interesting. Um, you mentioned the vendor putting out hashes. Is that one option for you to, um, I mean, could Microsoft actually put out a of thing. I guess it wouldn't be hashed in your particular way.

Very interesting. Um, you mentioned the vendor putting out hashes. Is that one option for you to, um, I mean, could Microsoft actually put out a of thing. I guess it wouldn't be hashed in your particular way.

Um, no. Well, if most of what we do is based on Sha 256, so technically it could. But we have relationships with lots of vendors. So they give us, you know. Access to their software before it actually gets pushed out in many cases. And I mean, in some cases, vendors don't cooperate. And we have to. Literally go out and buy their software and able to get out in order to. Get access to it as early as possible. But a lot of vendors do cooperate. I have to say, particularly cyber security solutions and cyber security. Security tools. And they're very good in giving us either access or. Early access to their software so we can make sure it doesn't get blocked. On our customer's machines.

Um, no. Well, if most of what we do is based on Sha 256, so technically it could. But we have relationships with lots of vendors. So they give us, you know. Access to their software before it actually gets pushed out in many cases. And I mean, in some cases, vendors don't cooperate. And we have to. Literally go out and buy their software and able to get out in order to. Get access to it as early as possible. But a lot of vendors do cooperate. I have to say, particularly cyber security solutions and cyber security. Security tools. And they're very good in giving us either access or. Early access to their software so we can make sure it doesn't get blocked. On our customer's machines.

Okay. That makes sense. So you don't have too many situations where um. Somebody just randomly luckily immediately got the update and they're installing it within, like whatever 30s of it coming out.

Okay. That makes sense. So you don't have too many situations where um. Somebody just randomly luckily immediately got the update and they're installing it within, like whatever 30s of it coming out.

I've been that.

I've been that.

Guy. I've been that guy. So Patch Tuesday some time ago and my machine prompted me for for an update. I didn't realize it was Tuesday. I didn't realize it was Patch Tuesday. It was like, I'll just run the update now. A few files got blocked, caused a bit of embarrassment, and I'm basically the guy that they all tag now when they say, hey, it's Patch Tuesday, don't update your machines immediately. And but it very, very, very rarely happens. I mean, people don't normally get updates that quickly or install them that immediately. And you know, a lot of obviously bigger enterprises, they'll have, you know, slower rollout for things like patching or, you know, automated patching even, you know, MSPs will have something similar and they'll have patching programs that might update things once a day or whatever the case may be. So it doesn't tend to be an issue that somebody gets to something before we do. But again, one of the other benefits to what we do is if something gets blocked, it's really easy and really fast to get it allowed. It's like a 32nd process where a user goes, hey, I need to run this thing. And an administrator goes, yeah, okay, you can run it. So even if something does get blocked, it's a really smooth, easy, fast approval process.

Guy. I've been that guy. So Patch Tuesday some time ago and my machine prompted me for for an update. I didn't realize it was Tuesday. I didn't realize it was Patch Tuesday. It was like, I'll just run the update now. A few files got blocked, caused a bit of embarrassment, and I'm basically the guy that they all tag now when they say, hey, it's Patch Tuesday, don't update your machines immediately. And but it very, very, very rarely happens. I mean, people don't normally get updates that quickly or install them that immediately. And you know, a lot of obviously bigger enterprises, they'll have, you know, slower rollout for things like patching or, you know, automated patching even, you know, MSPs will have something similar and they'll have patching programs that might update things once a day or whatever the case may be. So it doesn't tend to be an issue that somebody gets to something before we do. But again, one of the other benefits to what we do is if something gets blocked, it's really easy and really fast to get it allowed. It's like a 32nd process where a user goes, hey, I need to run this thing. And an administrator goes, yeah, okay, you can run it. So even if something does get blocked, it's a really smooth, easy, fast approval process.

Yeah.

Yeah.

And like you said, usually we have the opposite problem, right. People not applying patches, not applying them too quickly.

And like you said, usually we have the opposite problem, right. People not applying patches, not applying them too quickly.

Well it's actually it's a really interesting point because the problem I mean, it's obviously a huge problem from a cybersecurity perspective and vulnerable software and or vulnerabilities in software. I mean, there's so many different examples. There's a Veeam one at the moment that allows remote remote code execution. There's I mean, what I tend to say to people is, look, just assume the software, even if you patch your stuff absolutely on the button every time, I'd say assume the software that you're using, even though patched, is still full of holes, because it probably is. I mean, again, look at an average Patch Tuesday. Look at the serious issues that Microsoft fix every time they release an update for windows, so assume that those things are there even if your system is patched. And act accordingly. And it's effectively it's one of the tenets of zero trust is assume breach, assume issues, assume vulnerabilities. Assume you know the bad guys are already in for all intents and purposes. But if you take that approach, then everything that we do makes sense, which is okay, they're in now, what can they do? Can they run things? No. Can they exfiltrate data? No. Can they run ransomware? No. So again, everything we do and there is a lot more to it than just the listing. But everything else that we do just makes sense when you operate from that assumed breach perspective.

Well it's actually it's a really interesting point because the problem I mean, it's obviously a huge problem from a cybersecurity perspective and vulnerable software and or vulnerabilities in software. I mean, there's so many different examples. There's a Veeam one at the moment that allows remote remote code execution. There's I mean, what I tend to say to people is, look, just assume the software, even if you patch your stuff absolutely on the button every time, I'd say assume the software that you're using, even though patched, is still full of holes, because it probably is. I mean, again, look at an average Patch Tuesday. Look at the serious issues that Microsoft fix every time they release an update for windows, so assume that those things are there even if your system is patched. And act accordingly. And it's effectively it's one of the tenets of zero trust is assume breach, assume issues, assume vulnerabilities. Assume you know the bad guys are already in for all intents and purposes. But if you take that approach, then everything that we do makes sense, which is okay, they're in now, what can they do? Can they run things? No. Can they exfiltrate data? No. Can they run ransomware? No. So again, everything we do and there is a lot more to it than just the listing. But everything else that we do just makes sense when you operate from that assumed breach perspective.

Yeah, I like that a lot. So what are some other ways that you're you're implementing this zero trust philosophy? I looked at the site before getting on. I saw something called ring fencing. Um, is that the same or.

Yeah, I like that a lot. So what are some other ways that you're you're implementing this zero trust philosophy? I looked at the site before getting on. I saw something called ring fencing. Um, is that the same or.

Um, the.

Um, the.

Ring fencing is awesome, if I may say so myself. Yeah.

Ring fencing is awesome, if I may say so myself. Yeah.

Go ahead.

Go ahead.

So basically what it is, is it takes the principle of deny by default, permit by exception, and it expands on it. So it's not so much about it's the other part of what we call application control, or what we consider to be application control as to what can run and what can't run. And then there's what things can do when they're running. So it's things like application interaction. So what applications can call what other applications. So like you may need to run office on your machines. You may need to run PowerShell on your machines. Does office need to call PowerShell.

So basically what it is, is it takes the principle of deny by default, permit by exception, and it expands on it. So it's not so much about it's the other part of what we call application control, or what we consider to be application control as to what can run and what can't run. And then there's what things can do when they're running. So it's things like application interaction. So what applications can call what other applications. So like you may need to run office on your machines. You may need to run PowerShell on your machines. Does office need to call PowerShell.

Oh okay.

Oh okay.

Absolutely not. So we can control those application interactions to stop things. You know that lateral movement between applications. But we can also control for example, what data an application has access to it. So again PowerShell is a great example. Does PowerShell need to access all my files, my documents, my spreadsheets, my network shares my UNC paths? Answer in most cases is no, but obviously out of the box it can, which is why it's so often misused. And so if you can limit what data things like PowerShell have access to, you're going to minimize the potential for data exfiltration, you know, and realistically the potential for damage if something bad does get into an environment. But we can also control where applications can connect to on the internet. So again PowerShell, brilliant example. Does PowerShell need to talk to the entire internet? Absolutely not. By default. Absolutely. Which is why it's used for data exfiltration or running remote code. And I mean I'll give you an example. We did a webinar recently with a guy called Jacobi. And guy is an absolute genius. I mean, he knows he he's.

Absolutely not. So we can control those application interactions to stop things. You know that lateral movement between applications. But we can also control for example, what data an application has access to it. So again PowerShell is a great example. Does PowerShell need to access all my files, my documents, my spreadsheets, my network shares my UNC paths? Answer in most cases is no, but obviously out of the box it can, which is why it's so often misused. And so if you can limit what data things like PowerShell have access to, you're going to minimize the potential for data exfiltration, you know, and realistically the potential for damage if something bad does get into an environment. But we can also control where applications can connect to on the internet. So again PowerShell, brilliant example. Does PowerShell need to talk to the entire internet? Absolutely not. By default. Absolutely. Which is why it's used for data exfiltration or running remote code. And I mean I'll give you an example. We did a webinar recently with a guy called Jacobi. And guy is an absolute genius. I mean, he knows he he's.

A friend of mine, I.

A friend of mine, I.

Know him. Oh really? Yeah.

Know him. Oh really? Yeah.

So Jacobi does this really cool thing and you've probably seen this and he's got this, um, an API that he set up that basically delivers polymorphic and PowerShell reverse shell code. So every time it goes out to the API, it gets a different piece of code back, and it's not picked up or stopped or blocked by any traditional tool because again, it's different every time. It's not known bad. So how does that depends on knowing what's good or bad. Ever stop it. And but he has done he's done a couple of webinars now. The first one he kind of mentioned was he said I've come across this thing threatlocker and it's awesome. It blocks me every time from doing this. You know, they're using some amazing behavioral analysis or, you know, it's it I don't know, somehow knows what we're doing. And but we did another call with him last week. I don't think it's been released yet, but I was able to say to him, look, just to explain, Jacoby, we're not detecting what you're doing as being bad. We're not recognizing it as malicious. What we're doing instead is we're just saying, look, PowerShell can't access the internet. Stopped everything. He was in his tracks because he was dependent, or that the hacks that he was doing was dependent on PowerShell being able to access, in this case his API to get that polymorphic code, which then reached out to another reverse shell server. So by, as I said, controlling what applications can do is almost as important as what can run and what can't run.

So Jacobi does this really cool thing and you've probably seen this and he's got this, um, an API that he set up that basically delivers polymorphic and PowerShell reverse shell code. So every time it goes out to the API, it gets a different piece of code back, and it's not picked up or stopped or blocked by any traditional tool because again, it's different every time. It's not known bad. So how does that depends on knowing what's good or bad. Ever stop it. And but he has done he's done a couple of webinars now. The first one he kind of mentioned was he said I've come across this thing threatlocker and it's awesome. It blocks me every time from doing this. You know, they're using some amazing behavioral analysis or, you know, it's it I don't know, somehow knows what we're doing. And but we did another call with him last week. I don't think it's been released yet, but I was able to say to him, look, just to explain, Jacoby, we're not detecting what you're doing as being bad. We're not recognizing it as malicious. What we're doing instead is we're just saying, look, PowerShell can't access the internet. Stopped everything. He was in his tracks because he was dependent, or that the hacks that he was doing was dependent on PowerShell being able to access, in this case his API to get that polymorphic code, which then reached out to another reverse shell server. So by, as I said, controlling what applications can do is almost as important as what can run and what can't run.

Okay I really love this. Okay. So so the overall theme is zero trust. But now we've got what can run, what can't run, what can invoke. Next to it. What can reach the internet. What are some other sort of, um zero trust concepts that you're applying.

Okay I really love this. Okay. So so the overall theme is zero trust. But now we've got what can run, what can't run, what can invoke. Next to it. What can reach the internet. What are some other sort of, um zero trust concepts that you're applying.

So we have a we've got a storage control component as well. Um, and I can I can give you an example of where storage control is very relevant, but storage control basically allows you to control which programs have access to what data. So now what users have access to what data, but which programs, which individual application can access what data. So there's a million different examples. I mean, if you think about it logically, like why would anything other than Hyper-V need to access a FD or VHDL file? Why would anything other than SQL server X need to access a SQL server's database? But again, out of the box. And it's one of the reasons why ransomware and data exfiltration are as prevalent as they are. It's because everything that can run on a system, or everything that you run on a system has access to everything that you have access to. So if you've got access to a management chair, everything you run, whether it be good bad, malware, ransomware, Angry Birds, they all have access to that data as well because they're running as you. So what we we augment or combine your traditional user based controls and add to that program based controls. So if you have a folder on the server, if that folder only needs to be accessed by Office and Acrobat and Teams and Zoom, why would you let any of the other 500 applications that are running in your computer, access that location. So again, it's denied by default permit by exception. But for programs and data we also have and again same principle with the same principle for networking. So we've got a firewall built into the same agent. So it's effectively a default denies permit by exception. And it's kind of smarter than your average firewall though. And I mean it's a huge problem. I mean people are taking, you know, work computers home. They're taking them to, you know, Starbucks or at events or in hotels or everywhere. So the time when we could all kind of hide behind the perimeter firewall and feel safe is very much gone. But because our firewall is centrally managed, you can see everything that's happening on all of your machines from one place, but you can also control everything. And but when I say it's smarter than your average firewall, we can use what we call dynamic ACLs. So I can create a policy that says, look, only allow machines in my IT group connect to an RDP port on a server or only allow machines in my workstations. Group connect to, you know, SQL 1433 on this server. But what that means is whether a port is open or not depends on what's connecting to it. If it's a device that you've explicitly said can access this resource on the server, it's going to be allowed to connect. If it's not, it won't. So it's effectively it's akin to network segmentation, but it's done at the endpoint level. It's not done with expensive or expensive switches and hardware and everything else. You're basically saying, look, only these devices can connect to this port. Now that stops so many ransomware attacks in their tracks just by blocking by default network connections. Because again, most of these ransomware attacks will need some sort of connection to take place. And in a lot of cases, I mean, the whole issue with RDP still being open, I mean, we've I've seen so many instances of RDP being open to the internet I mean, I'm going to put in or insert my usual RDP standing for Ransomware delivery protocol joke, but it's called that for a reason. I mean, it's close to 20%. Ransomware attacks still include RDP, and it's basically just servers hanging out with that port available on the internet.

So we have a we've got a storage control component as well. Um, and I can I can give you an example of where storage control is very relevant, but storage control basically allows you to control which programs have access to what data. So now what users have access to what data, but which programs, which individual application can access what data. So there's a million different examples. I mean, if you think about it logically, like why would anything other than Hyper-V need to access a FD or VHDL file? Why would anything other than SQL server X need to access a SQL server's database? But again, out of the box. And it's one of the reasons why ransomware and data exfiltration are as prevalent as they are. It's because everything that can run on a system, or everything that you run on a system has access to everything that you have access to. So if you've got access to a management chair, everything you run, whether it be good bad, malware, ransomware, Angry Birds, they all have access to that data as well because they're running as you. So what we we augment or combine your traditional user based controls and add to that program based controls. So if you have a folder on the server, if that folder only needs to be accessed by Office and Acrobat and Teams and Zoom, why would you let any of the other 500 applications that are running in your computer, access that location. So again, it's denied by default permit by exception. But for programs and data we also have and again same principle with the same principle for networking. So we've got a firewall built into the same agent. So it's effectively a default denies permit by exception. And it's kind of smarter than your average firewall though. And I mean it's a huge problem. I mean people are taking, you know, work computers home. They're taking them to, you know, Starbucks or at events or in hotels or everywhere. So the time when we could all kind of hide behind the perimeter firewall and feel safe is very much gone. But because our firewall is centrally managed, you can see everything that's happening on all of your machines from one place, but you can also control everything. And but when I say it's smarter than your average firewall, we can use what we call dynamic ACLs. So I can create a policy that says, look, only allow machines in my IT group connect to an RDP port on a server or only allow machines in my workstations. Group connect to, you know, SQL 1433 on this server. But what that means is whether a port is open or not depends on what's connecting to it. If it's a device that you've explicitly said can access this resource on the server, it's going to be allowed to connect. If it's not, it won't. So it's effectively it's akin to network segmentation, but it's done at the endpoint level. It's not done with expensive or expensive switches and hardware and everything else. You're basically saying, look, only these devices can connect to this port. Now that stops so many ransomware attacks in their tracks just by blocking by default network connections. Because again, most of these ransomware attacks will need some sort of connection to take place. And in a lot of cases, I mean, the whole issue with RDP still being open, I mean, we've I've seen so many instances of RDP being open to the internet I mean, I'm going to put in or insert my usual RDP standing for Ransomware delivery protocol joke, but it's called that for a reason. I mean, it's close to 20%. Ransomware attacks still include RDP, and it's basically just servers hanging out with that port available on the internet.

I mean, you're talking about three.

I mean, you're talking about three.

Three, eight, nine like actual.

Three, eight, nine like actual.

Yeah.

Yeah.

Um, and so if anybody's bored, um, do try this on. So go to shodan. So obviously, I'm sure you know what shodan is. It's effectively a search engine for the internet of things. Go to Shodan and you can search in Shodan for a specific port in an area. So you can look for port colon 3389 city colon Orlando for example. I did that some time ago for Orlando and it showed over 900 devices, over 900 servers, machines, you name it. With that port open to the internet and those machines, those organizations, those environments are literally a brute force password away from being the next victims of a ransomware attack and.

Um, and so if anybody's bored, um, do try this on. So go to shodan. So obviously, I'm sure you know what shodan is. It's effectively a search engine for the internet of things. Go to Shodan and you can search in Shodan for a specific port in an area. So you can look for port colon 3389 city colon Orlando for example. I did that some time ago for Orlando and it showed over 900 devices, over 900 servers, machines, you name it. With that port open to the internet and those machines, those organizations, those environments are literally a brute force password away from being the next victims of a ransomware attack and.

Or.

Or.

Being unpatched like RDP.

Being unpatched like RDP.

Yeah, absolutely. Absolutely. And but it really is scary. And in some cases, I mean, you can literally see the name of the organization because they've got like the, you know, domain name header.

Yeah, absolutely. Absolutely. And but it really is scary. And in some cases, I mean, you can literally see the name of the organization because they've got like the, you know, domain name header.

Yeah.

Yeah.

They show the user who's logged in. So it's not as if they have to even guess what the username is. They can say, oh this machine, the username is Rob. So I just need to run my, you know, password attack against the user Rob rather than to try a million different users. It's terrifying. But again, the point about network control is you could theoretically and hypothetically you could open port three, three, eight, nine to the internet. But you can say you can. Only these machines can connect. So when the internet tries to connect it, it can't because that port is closed. But if you're just the devices, the ones that you want to connect want to connect, they can't. So again, it's just it's taking that same principle of deny by default, permit by exception, but applying it to networking?

They show the user who's logged in. So it's not as if they have to even guess what the username is. They can say, oh this machine, the username is Rob. So I just need to run my, you know, password attack against the user Rob rather than to try a million different users. It's terrifying. But again, the point about network control is you could theoretically and hypothetically you could open port three, three, eight, nine to the internet. But you can say you can. Only these machines can connect. So when the internet tries to connect it, it can't because that port is closed. But if you're just the devices, the ones that you want to connect want to connect, they can't. So again, it's just it's taking that same principle of deny by default, permit by exception, but applying it to networking?

Yeah.

Yeah.

Really interesting. So I got a question for you. Have have you thought about or are you already doing um, gathering of context from an organization? So what if you could take an organization and just be like, okay, based on slack conversations based on internal wikis or whatever? This is the general flow of how things normally work, right? And then you could basically build a bunch of allow list rules across all the different facets, not just like can an application run, but these, these, uh, applications normally talk to these, uh, these servers over here should be accessed by these finance servers or whatever, and then intelligently build like this profile of different allows and disallows.

Really interesting. So I got a question for you. Have have you thought about or are you already doing um, gathering of context from an organization? So what if you could take an organization and just be like, okay, based on slack conversations based on internal wikis or whatever? This is the general flow of how things normally work, right? And then you could basically build a bunch of allow list rules across all the different facets, not just like can an application run, but these, these, uh, applications normally talk to these, uh, these servers over here should be accessed by these finance servers or whatever, and then intelligently build like this profile of different allows and disallows.

To kind of do that already. So the learning mode and allow listing is effectively doing that. We learn quite a bit of ring fencing as well. So if applications need to go into particular locations or access particular internet locations, we learn that stuff already. I mean, it is your allow list is effectively that we also and I should have mentioned this, but we do also have what we call the unified audit, whereas which is visibility over everything that's happening on machines. So everything that runs, everything that can't run, everything that's allowed, everything that's denied network traffic in and out. So we have complete visibility over what is happening and also what's not happening in the environments that that are managed with Docker. And one thing I should mention, and a lot of what we've spoken about thus far has been effectively controlled. So as we take a different approach, we're not about detecting, we're not well, sorry, we're not primarily about detecting. We are primarily about controls or about environment effectively as unfriendly as possible to an attacker while allowing users to do what they need to do. So users and you know, you have to think or you have to consider that probably 98% of users do the same things with the same software every single day. Yep. I mean, they use office. They use Acrobat. They use video conferencing team zoom browsers. Obviously, you know, windows operating system, etc. maybe a line of business application or two. But fundamentally what we're doing is we're just setting guardrails around that. We're saying, look, operate within these guardrails and you're not even going to know we're here. Okay. So it's not going to affect or get in the way of the vast, vast majority of users. But back to what you mentioned a second ago. The other thing that we do as well as control. So we for many years a lot of organizations would run us beside some sort of detection. Okay. So they might run Threadlocker alongside an EDR for example. Basically Threadlocker offering the control and the EDR as effectively as a fallback as a okay, you know, somebody allowed something wrong they shouldn't have done. Now the EDR steps in and goes, okay, I'm going to detect that and hopefully clean it up. So what we've added more recently is what we call Threadlocker detect, which is a EDR that is attached to Threadlocker. I mean, it's effectively it's the same agent, it's the same portal, it's the same everything that you're using. But the beauty about Threadlocker is detection platform, which is, as I said, detect. And we also have MDR is we see not only everything that we have allowed, but we also see everything that we've denied. Because the problem is, if you're running Threadlocker alongside another tool like an EDR, we're blocking most of its source. We're stopping, you know, remote access tools from running. We're stopping everything from running at source and very often the editor that's running alongside us won't even know that happened. You know what I mean? So yes. Yeah, but Angus has been blocked from running, so it has nothing to detect. It has nothing to respond to. So the beauty about us is we see both sides. We see everything that's been allowed. We also see everything that's been denied. And we can alert, detect and respond accordingly. Because the thing is what the layers of control we mentioned are going to do is they're going to buy you time, okay. In the event of a cyber attack, having time where you know, they're in, but they can't do anything because they keep on banging their heads against the wall. That is threatlocker that's going to buy you time, but you still want to know if something's going on.

To kind of do that already. So the learning mode and allow listing is effectively doing that. We learn quite a bit of ring fencing as well. So if applications need to go into particular locations or access particular internet locations, we learn that stuff already. I mean, it is your allow list is effectively that we also and I should have mentioned this, but we do also have what we call the unified audit, whereas which is visibility over everything that's happening on machines. So everything that runs, everything that can't run, everything that's allowed, everything that's denied network traffic in and out. So we have complete visibility over what is happening and also what's not happening in the environments that that are managed with Docker. And one thing I should mention, and a lot of what we've spoken about thus far has been effectively controlled. So as we take a different approach, we're not about detecting, we're not well, sorry, we're not primarily about detecting. We are primarily about controls or about environment effectively as unfriendly as possible to an attacker while allowing users to do what they need to do. So users and you know, you have to think or you have to consider that probably 98% of users do the same things with the same software every single day. Yep. I mean, they use office. They use Acrobat. They use video conferencing team zoom browsers. Obviously, you know, windows operating system, etc. maybe a line of business application or two. But fundamentally what we're doing is we're just setting guardrails around that. We're saying, look, operate within these guardrails and you're not even going to know we're here. Okay. So it's not going to affect or get in the way of the vast, vast majority of users. But back to what you mentioned a second ago. The other thing that we do as well as control. So we for many years a lot of organizations would run us beside some sort of detection. Okay. So they might run Threadlocker alongside an EDR for example. Basically Threadlocker offering the control and the EDR as effectively as a fallback as a okay, you know, somebody allowed something wrong they shouldn't have done. Now the EDR steps in and goes, okay, I'm going to detect that and hopefully clean it up. So what we've added more recently is what we call Threadlocker detect, which is a EDR that is attached to Threadlocker. I mean, it's effectively it's the same agent, it's the same portal, it's the same everything that you're using. But the beauty about Threadlocker is detection platform, which is, as I said, detect. And we also have MDR is we see not only everything that we have allowed, but we also see everything that we've denied. Because the problem is, if you're running Threadlocker alongside another tool like an EDR, we're blocking most of its source. We're stopping, you know, remote access tools from running. We're stopping everything from running at source and very often the editor that's running alongside us won't even know that happened. You know what I mean? So yes. Yeah, but Angus has been blocked from running, so it has nothing to detect. It has nothing to respond to. So the beauty about us is we see both sides. We see everything that's been allowed. We also see everything that's been denied. And we can alert, detect and respond accordingly. Because the thing is what the layers of control we mentioned are going to do is they're going to buy you time, okay. In the event of a cyber attack, having time where you know, they're in, but they can't do anything because they keep on banging their heads against the wall. That is threatlocker that's going to buy you time, but you still want to know if something's going on.

Yeah, because they might switch tactics to something else that that you can't block. And you get all that time if you're seeing it beforehand.

Yeah, because they might switch tactics to something else that that you can't block. And you get all that time if you're seeing it beforehand.

This is exactly the point. So basically if you know there's a deep connection coming in or if an event log gets cleared on a server, if there's any other of, you know, hundreds of indicators of compromise. We see them and with our detection platform and our EDR sorry, on our end or basically which is human beings sitting outside the office here basically looking at these alerts or customers, but basically they will say or it will tell you something is happening, whether or not some other EDR might even know it's going on, which very often they won't. But look, the point is we see detection as being complementary to those other layers of protection I mentioned. We don't see it like for us, detection is not the entire game for.

This is exactly the point. So basically if you know there's a deep connection coming in or if an event log gets cleared on a server, if there's any other of, you know, hundreds of indicators of compromise. We see them and with our detection platform and our EDR sorry, on our end or basically which is human beings sitting outside the office here basically looking at these alerts or customers, but basically they will say or it will tell you something is happening, whether or not some other EDR might even know it's going on, which very often they won't. But look, the point is we see detection as being complementary to those other layers of protection I mentioned. We don't see it like for us, detection is not the entire game for.

Yeah, I've always said I mean probably maybe it's NIST or something, but I've always said, um, prevent detect respond in that order. Right. So if you're zero trust prevent is the number one. But you also want to have that visibility. So it's nice you have that that that function. What about respond. Is there any anything you have there about I guess firing off an alert would be one.

Yeah, I've always said I mean probably maybe it's NIST or something, but I've always said, um, prevent detect respond in that order. Right. So if you're zero trust prevent is the number one. But you also want to have that visibility. So it's nice you have that that that function. What about respond. Is there any anything you have there about I guess firing off an alert would be one.

Well, absolutely. We can do a lot of different things So we can we make people aware, I suppose is the first thing. So, you know, log a ticket, send an email, pick up the phone, which is what our entire team will do depending on a customer's defined playbook or runbook. And we can take automatic remediating actions. So like if we see something happening on a machine we can not only. And I know a lot of solutions allow you to isolate machines from network. And isolation is all very well and good and we offer isolation as well. But the problem is if you isolate a server that's running ransomware, you're going to do nothing other than allow that ransomware to continue to run and also have server isolated from anything it needs to talk to. So we have what we call lockdown mode. And lockdown mode is like isolation on steroids basically. So it both blocks everything from running. And when I say everything, I mean everything large parts of windows as well. It blocks even, you know, otherwise good applications, things like Chrome, Internet Explorer, they're all going to get blocked from running. You can't run office, you can't run PowerShell, you can't run command prompt effectively. You can't run anything on the machine, but it also locks on blocks down access to storage. So any protected storage location, we say okay. Block all reads and writes to that. So your your ransomware may be running, but it's not going to be able to encrypt my data. But it also and the third thing we do on top of that is we also isolate from the network. So if there's incoming outgoing connections, we're going to kill those connections. That machine is going to stay isolated. So as I said, lockdown mode is like a much more extreme version of isolation, but it's one that will actually stop ransomware in its tracks, whereas isolation is just going to allow it to continue on its own. And but we do also have remediation facilities. So basically you can if a customer wants, we have a separate service called Remediator, which effectively is a PowerShell access to the machine, which we can get in and stop things, delete things, do whatever the customer wants. Again, it's all very much based on the customer's requirements.

Well, absolutely. We can do a lot of different things So we can we make people aware, I suppose is the first thing. So, you know, log a ticket, send an email, pick up the phone, which is what our entire team will do depending on a customer's defined playbook or runbook. And we can take automatic remediating actions. So like if we see something happening on a machine we can not only. And I know a lot of solutions allow you to isolate machines from network. And isolation is all very well and good and we offer isolation as well. But the problem is if you isolate a server that's running ransomware, you're going to do nothing other than allow that ransomware to continue to run and also have server isolated from anything it needs to talk to. So we have what we call lockdown mode. And lockdown mode is like isolation on steroids basically. So it both blocks everything from running. And when I say everything, I mean everything large parts of windows as well. It blocks even, you know, otherwise good applications, things like Chrome, Internet Explorer, they're all going to get blocked from running. You can't run office, you can't run PowerShell, you can't run command prompt effectively. You can't run anything on the machine, but it also locks on blocks down access to storage. So any protected storage location, we say okay. Block all reads and writes to that. So your your ransomware may be running, but it's not going to be able to encrypt my data. But it also and the third thing we do on top of that is we also isolate from the network. So if there's incoming outgoing connections, we're going to kill those connections. That machine is going to stay isolated. So as I said, lockdown mode is like a much more extreme version of isolation, but it's one that will actually stop ransomware in its tracks, whereas isolation is just going to allow it to continue on its own. And but we do also have remediation facilities. So basically you can if a customer wants, we have a separate service called Remediator, which effectively is a PowerShell access to the machine, which we can get in and stop things, delete things, do whatever the customer wants. Again, it's all very much based on the customer's requirements.

Okay, so.

Okay, so.

You mentioned the people out there watching. Um, so is the MSP service. Is that part of the endpoint product or is like, is that an add on like that monitoring piece? How tied into it the product is that?

You mentioned the people out there watching. Um, so is the MSP service. Is that part of the endpoint product or is like, is that an add on like that monitoring piece? How tied into it the product is that?

Oh, it's completely integrated. But we've got we've effectively on top of the the products as in the software as a service that you pay for. We do have a couple of additional services. One is what we call cyber hero approvals, which is if you don't want the hassle of dealing with your users, sending requests through and saying they want to run this thing and they want to run that thing, you can effectively outsource that to us, where we'll basically approve or deny applications requests according to your specific instructions. So you might say look them remote access tools. Bad. Don't allow them video conferencing video conferencing tools. Yes. And but you know that's a set of instructions effectively for us to follow. And we will follow them to the letter. So somebody tries to run a remote access tool, we're going to block it if somebody tries to run a video conferencing tool will permit it for you or on your behalf. So that's the cyber hero approvals. We also have eMDR, which is again tied to the ADR, tied to the detection, which is human beings sitting outside here watching alerts, investigating when something is going on and if needs be, alerting customers or as I said, taking remediating action.

Oh, it's completely integrated. But we've got we've effectively on top of the the products as in the software as a service that you pay for. We do have a couple of additional services. One is what we call cyber hero approvals, which is if you don't want the hassle of dealing with your users, sending requests through and saying they want to run this thing and they want to run that thing, you can effectively outsource that to us, where we'll basically approve or deny applications requests according to your specific instructions. So you might say look them remote access tools. Bad. Don't allow them video conferencing video conferencing tools. Yes. And but you know that's a set of instructions effectively for us to follow. And we will follow them to the letter. So somebody tries to run a remote access tool, we're going to block it if somebody tries to run a video conferencing tool will permit it for you or on your behalf. So that's the cyber hero approvals. We also have eMDR, which is again tied to the ADR, tied to the detection, which is human beings sitting outside here watching alerts, investigating when something is going on and if needs be, alerting customers or as I said, taking remediating action.

Yeah.

Yeah.

Fantastic. Well, this is this is super interesting. I actually have an idea I want to ask you about, but I think it might, uh, take us into a whole separate episode. I'm actually curious about if we were to break down the different portions of a ransomware attack, like. So. It's got to get in. It's got to do the following. It wants to spread. I would like to match that with the different blocking functionality and the detection functionality of the tool. So it's like this particular portion gets blocked by this portion. If it gets through there, which it wouldn't, but if it somehow did, it would get stopped here and then stopped at the internet. So it's like, here's three different ways or here's five different ways. It would be stopped.

Fantastic. Well, this is this is super interesting. I actually have an idea I want to ask you about, but I think it might, uh, take us into a whole separate episode. I'm actually curious about if we were to break down the different portions of a ransomware attack, like. So. It's got to get in. It's got to do the following. It wants to spread. I would like to match that with the different blocking functionality and the detection functionality of the tool. So it's like this particular portion gets blocked by this portion. If it gets through there, which it wouldn't, but if it somehow did, it would get stopped here and then stopped at the internet. So it's like, here's three different ways or here's five different ways. It would be stopped.

Yeah.

Yeah.

Absolutely. And look, there's so many different examples of that. I mean, you know, we stop very often the initial access because we're going to stop the network connection coming in. Even if a network connection comes in, we're going to probably detect a brute force happening because we can, you know, detect or fail logons. So even if they do get that far in, then they're probably going to try and give themselves persistent access. So they're going to run something like Anydesk. Well, we're going to block that by default because blocking things is what we do. Or they might try and run a reverse shell in PowerShell. Again we're going to block that because blocking PowerShell from accessing the internet there's probably about in your average ransomware attack, there's probably about ten different stages that we would basically step in and block things. Um, To embody it would be an interesting exercise and to undertake, but I would suggest in most attacks there's a lot of different ways that we we would get in their way.

Absolutely. And look, there's so many different examples of that. I mean, you know, we stop very often the initial access because we're going to stop the network connection coming in. Even if a network connection comes in, we're going to probably detect a brute force happening because we can, you know, detect or fail logons. So even if they do get that far in, then they're probably going to try and give themselves persistent access. So they're going to run something like Anydesk. Well, we're going to block that by default because blocking things is what we do. Or they might try and run a reverse shell in PowerShell. Again we're going to block that because blocking PowerShell from accessing the internet there's probably about in your average ransomware attack, there's probably about ten different stages that we would basically step in and block things. Um, To embody it would be an interesting exercise and to undertake, but I would suggest in most attacks there's a lot of different ways that we we would get in their way.

Yeah.

Yeah.

Interesting. Any new stuff coming out? You should let us know about.

Interesting. Any new stuff coming out? You should let us know about.

Um, so the detection eMDR was released this year. We have recently added Cloud Detect as well. So effectively the same or similar capabilities as Threatlocker detect but for cloud environments. So first one we've done is office 365 with the likes of G suite and others coming soon as well. So same principle looking for anomalous behavior. I mean, a lot of the problems are whether you're managing one office 365 environment or 100 office 365 environments, actually finding somewhere with all of the information you need and all the alerts that you want to look at is not always easy. Um, less Microsoft. but again, allow people to alert themselves on, you know, suspicious travel and anomalous behavior, forwarding rules being set up, all those kind of things. Again, in one place, rather than having to go into 50 different office, 365 tendencies to see what's going on. So Cloud Detect is probably the newest thing that we've we've added recently, and it's something that's gaining a lot of interest and a lot of traction.

Um, so the detection eMDR was released this year. We have recently added Cloud Detect as well. So effectively the same or similar capabilities as Threatlocker detect but for cloud environments. So first one we've done is office 365 with the likes of G suite and others coming soon as well. So same principle looking for anomalous behavior. I mean, a lot of the problems are whether you're managing one office 365 environment or 100 office 365 environments, actually finding somewhere with all of the information you need and all the alerts that you want to look at is not always easy. Um, less Microsoft. but again, allow people to alert themselves on, you know, suspicious travel and anomalous behavior, forwarding rules being set up, all those kind of things. Again, in one place, rather than having to go into 50 different office, 365 tendencies to see what's going on. So Cloud Detect is probably the newest thing that we've we've added recently, and it's something that's gaining a lot of interest and a lot of traction.

Awesome. And where can people learn more about you?

Awesome. And where can people learn more about you?

Threatlocker. Com is a good place to start. We are on all the things we're on, um, Facebook. We're on Twitter. I refuse to call it X and we're on YouTube. And if anybody is interested, we do webinars on YouTube quite often, maybe once or twice a month, and often entertaining and somewhat or sometimes educational. So have a look at them as well. We sort of take deep dives into, you know, different attack vectors. We did, you know, things about drones and Wi-Fi? Pineapples at one stage that may have been, may or may not have crashed a drone into a building here. And but yes, at the risk of sounding like every YouTuber, my children watch and smash that subscribe button and check us out.

Threatlocker. Com is a good place to start. We are on all the things we're on, um, Facebook. We're on Twitter. I refuse to call it X and we're on YouTube. And if anybody is interested, we do webinars on YouTube quite often, maybe once or twice a month, and often entertaining and somewhat or sometimes educational. So have a look at them as well. We sort of take deep dives into, you know, different attack vectors. We did, you know, things about drones and Wi-Fi? Pineapples at one stage that may have been, may or may not have crashed a drone into a building here. And but yes, at the risk of sounding like every YouTuber, my children watch and smash that subscribe button and check us out.

Awesome.

Awesome.

Well, thanks for your time today. I enjoyed it.

Well, thanks for your time today. I enjoyed it.

You're very welcome. Daniel, thank you very much.

You're very welcome. Daniel, thank you very much.

All right.

All right.

Take care.

Take care.

Bye bye.

Bye bye.

Unsupervised learning is produced and edited by Daniel Miessler on a Neumann U87 AI microphone using Hindenburg. Intro and outro music is by zombie with a Y. And to get the text and links from this episode, sign up for the newsletter version of the show at Daniel miessler.com/newsletter. We'll see you next time.

Unsupervised learning is produced and edited by Daniel Miessler on a Neumann U87 AI microphone using Hindenburg. Intro and outro music is by zombie with a Y. And to get the text and links from this episode, sign up for the newsletter version of the show at Daniel miessler.com/newsletter. We'll see you next time.