WEBVTT - A Conversation with Rob Allen from ThreatLocker 0:00:01.280 --> 0:00:04.609 Welcome to Unsupervised Learning, a security, AI and meaning focused 0:00:04.610 --> 0:00:07.490 podcast that looks at how best to thrive as humans 0:00:07.490 --> 0:00:11.719 in a post AI world. It combines original ideas, analysis, 0:00:11.720 --> 0:00:14.930 and mental models to bring not just the news, but 0:00:14.930 --> 0:00:18.440 why it matters and how to respond. All right, Rob, 0:00:18.440 --> 0:00:20.150 welcome to Unsupervised Learning. 0:00:21.020 --> 0:00:22.430 Hi, Daniel. Thank you for having me. 0:00:23.600 --> 0:00:26.210 Excellent. So can we get you to give a brief 0:00:26.210 --> 0:00:29.990 intro into yourself and talk about Threatlocker and what you 0:00:29.990 --> 0:00:30.980 guys do over there? 0:00:31.400 --> 0:00:35.510 Sure. So I'm Rob Allen. I am chief product officer 0:00:35.510 --> 0:00:38.720 here at Threatlocker. As you can probably tell from my 0:00:39.530 --> 0:00:43.580 Midwest accent, I'm. No, I'm not from the Midwest. I'm 0:00:43.580 --> 0:00:47.059 from Ireland. And I've worked at Lockhart for about almost 0:00:47.060 --> 0:00:51.620 four years now. And Threatlocker are a zero. Zero trust 0:00:51.620 --> 0:00:57.350 cybersecurity solution. So a endpoint protection platform effectively. And we 0:00:57.350 --> 0:01:01.830 take a slightly different approach to cybersecurity, to most other tools, 0:01:01.980 --> 0:01:08.399 and fundamentally, where other things allow everything except what's known 0:01:08.400 --> 0:01:12.179 to be bad. We take the approach of block everything 0:01:12.209 --> 0:01:15.870 unless it's explicitly allowed, and a few different ways we 0:01:15.870 --> 0:01:18.300 do that, a few different aspects to it. But fundamentally 0:01:18.300 --> 0:01:21.149 it's a design by default, permit by exception approach, which 0:01:21.150 --> 0:01:23.850 is pretty much a cornerstone of zero trust. 0:01:25.140 --> 0:01:28.230 Mhm. Interesting. Yeah. That's one of my next questions is 0:01:28.230 --> 0:01:31.650 basically what is what is it that you're doing different. 0:01:31.650 --> 0:01:35.610 So that that's fascinating. Um and the reason most people 0:01:35.610 --> 0:01:39.030 can't do that, especially back in the firewall days or whatever, 0:01:39.060 --> 0:01:42.030 there was just too many things to have to poke 0:01:42.030 --> 0:01:45.600 holes through. So I imagine you've found some pretty interesting 0:01:45.600 --> 0:01:48.900 ways to, uh, to allow benign behavior. So how are 0:01:48.900 --> 0:01:49.710 you doing that? 0:01:49.830 --> 0:01:52.350 So there's a few parts of what we do. So 0:01:52.350 --> 0:01:53.790 first of all, the core of what we do is 0:01:53.790 --> 0:01:57.960 allow listing. So it's basically allowing what needs to run 0:01:57.960 --> 0:02:02.410 to run. I'm blocking everything else now. Anybody who's ever 0:02:02.410 --> 0:02:06.160 tried to do that probably knows that historically, that has 0:02:06.160 --> 0:02:08.050 been somewhat, even though it is kind of the gold 0:02:08.050 --> 0:02:11.470 standard in terms of cybersecurity. It is kind of a 0:02:11.470 --> 0:02:13.660 heavy lift with some of the tools that are out there. 0:02:13.660 --> 0:02:16.330 It's a lot of hard work, basically, and we do 0:02:16.330 --> 0:02:20.140 a few things differently that make it manageable. We make 0:02:20.139 --> 0:02:23.679 it attainable for even, you know, small and medium organizations. 0:02:23.919 --> 0:02:26.950 And first thing that we do differently is we basically 0:02:26.950 --> 0:02:30.490 learn everything automatically. So you deploy an agent onto your machines. 0:02:30.490 --> 0:02:33.339 It does all the hard work effectively. So it figures 0:02:33.340 --> 0:02:35.829 out everything that's required on the machine and creates policies 0:02:35.830 --> 0:02:38.860 to allow those things to continue to run once the 0:02:38.860 --> 0:02:41.470 threat has been turned on. So that's kind of the 0:02:41.470 --> 0:02:45.070 first way that we make this process much easier. The 0:02:45.070 --> 0:02:48.639 second way. And again, anybody who's ever tried to implement 0:02:48.669 --> 0:02:51.190 a listing will know that one of the biggest problems 0:02:51.220 --> 0:02:55.900 is the question of what happens when software updates. And 0:02:55.900 --> 0:02:59.760 generally speaking, What happens when software updates? Is it breaks 0:02:59.760 --> 0:03:03.090 because whatever licensing solution you're using will say, well, look, 0:03:03.120 --> 0:03:05.820 I know that file is called acrobatics, but it doesn't 0:03:05.820 --> 0:03:09.839 match my acrobatics, so I'm not going to let it run. Um, 0:03:09.870 --> 0:03:13.919 and that has always been one of the biggest hurdles 0:03:13.919 --> 0:03:17.400 with implementing this approach. So what we do to solve 0:03:17.400 --> 0:03:19.440 that problem is we have this concept of what we 0:03:19.440 --> 0:03:23.820 call built in applications, which are effectively application definitions that 0:03:23.820 --> 0:03:28.560 we maintain, we manage. We've got over 4000 common applications, 0:03:28.560 --> 0:03:33.419 everything from Acrobat to teams to zoom to office. I mean, technically, 0:03:33.419 --> 0:03:36.000 windows is kind of a built in application as well, 0:03:36.030 --> 0:03:39.600 but every time there's an update for any of those things, 0:03:39.630 --> 0:03:42.690 our applications team who are based here in Orlando working 0:03:42.720 --> 0:03:46.830 24 over seven, 365 will run. It will capture any 0:03:46.830 --> 0:03:49.890 new files that are included in that application, and it 0:03:49.890 --> 0:03:52.950 gets pushed down to people's machines automatically. So anybody who 0:03:52.950 --> 0:03:56.470 has a definition for or a policy for teams, for example, 0:03:56.500 --> 0:03:59.770 new update comes out, they capture it. It gets pushed 0:03:59.770 --> 0:04:03.580 down to every machine that's running teams automatically. So effectively 0:04:03.580 --> 0:04:05.350 it takes a lot of the heavy lifting. It takes 0:04:05.350 --> 0:04:07.840 a lot of the hard work out of what used 0:04:07.840 --> 0:04:10.420 to be quite an involved process. 0:04:11.440 --> 0:04:18.040 Oh very interesting. So, so, um, so essentially you're watching 0:04:18.040 --> 0:04:22.089 all these core applications. It sounds like roughly 4000 or so. 0:04:22.089 --> 0:04:24.789 And then, um, any new update that comes out that 0:04:24.790 --> 0:04:28.419 immediately comes to you, you're instrument it and re push 0:04:28.420 --> 0:04:30.280 it down as part of the allow list. 0:04:30.310 --> 0:04:32.169 So we don't push it down per se. What we 0:04:32.170 --> 0:04:34.660 do is we push down hashes. We push down new 0:04:34.660 --> 0:04:37.179 files that are allowed. So when our customer tries to 0:04:37.180 --> 0:04:40.030 run those new files, they will be allowed to do so. 0:04:40.029 --> 0:04:43.989 So yeah we update the application definitions constantly like every 0:04:43.990 --> 0:04:45.640 one of those applications, as far as I know, is 0:04:45.640 --> 0:04:49.120 checked pretty much once a day. Um, some things far 0:04:49.120 --> 0:04:53.140 more often than that. I mean, Chrome updates often and sporadically. 0:04:53.140 --> 0:04:56.000 So we might check that for argument's sake, 12 times 0:04:56.000 --> 0:04:58.190 a day. And just to make sure that we capture 0:04:58.220 --> 0:05:01.159 all those hashes as soon as possible. So by the 0:05:01.160 --> 0:05:04.250 time customers come to install them, they don't have any 0:05:04.250 --> 0:05:07.850 problems with their software being blocked. We would like this. 0:05:08.300 --> 0:05:11.240 Patch Tuesday is our busiest or our OP team's busiest 0:05:11.240 --> 0:05:14.659 day of the month. And you know, there could be five, ten, 0:05:14.660 --> 0:05:18.920 15,000 new hashes pushed out by Microsoft as part of 0:05:18.950 --> 0:05:21.170 Patch Tuesday. So they all need to be accounted for. 0:05:21.200 --> 0:05:24.140 They all need to be allowed when our customers try 0:05:24.140 --> 0:05:26.330 and run them. So as I said, our app team 0:05:26.360 --> 0:05:30.260 our the it's kind of the secret sauce, the special 0:05:30.260 --> 0:05:32.870 sauce as to why Threadlocker is as easy to manage 0:05:32.870 --> 0:05:34.730 as it is, because we're taking a lot of that 0:05:34.730 --> 0:05:37.760 heavy lifting, a lot of that responsibility. We're taking it 0:05:37.760 --> 0:05:39.830 off customers and taking it on ourselves. 0:05:40.820 --> 0:05:41.180 Yeah. 0:05:41.210 --> 0:05:46.370 Very interesting. Um, you mentioned the vendor putting out hashes. 0:05:47.150 --> 0:05:50.090 Is that one option for you to, um, I mean, 0:05:50.120 --> 0:05:53.610 could Microsoft actually put out a of thing. I guess 0:05:53.610 --> 0:05:56.400 it wouldn't be hashed in your particular way. 0:05:56.520 --> 0:05:58.919 Um, no. Well, if most of what we do is 0:05:58.920 --> 0:06:03.000 based on Sha 256, so technically it could. But we 0:06:03.000 --> 0:06:07.080 have relationships with lots of vendors. So they give us, 0:06:07.110 --> 0:06:10.860 you know. Access to their software before it actually gets 0:06:10.860 --> 0:06:14.100 pushed out in many cases. And I mean, in some cases, 0:06:14.130 --> 0:06:16.560 vendors don't cooperate. And we have to. Literally go out 0:06:16.560 --> 0:06:18.870 and buy their software and able to get out in 0:06:18.870 --> 0:06:20.910 order to. Get access to it as early as possible. 0:06:20.970 --> 0:06:24.570 But a lot of vendors do cooperate. I have to say, 0:06:24.600 --> 0:06:28.950 particularly cyber security solutions and cyber security. Security tools. And 0:06:28.980 --> 0:06:32.490 they're very good in giving us either access or. Early 0:06:32.490 --> 0:06:35.340 access to their software so we can make sure it 0:06:35.339 --> 0:06:37.530 doesn't get blocked. On our customer's machines. 0:06:38.550 --> 0:06:41.340 Okay. That makes sense. So you don't have too many 0:06:41.339 --> 0:06:49.020 situations where um. Somebody just randomly luckily immediately got the 0:06:49.020 --> 0:06:52.300 update and they're installing it within, like whatever 30s of 0:06:52.300 --> 0:06:53.170 it coming out. 0:06:53.320 --> 0:06:53.979 I've been that. 0:06:53.980 --> 0:06:57.760 Guy. I've been that guy. So Patch Tuesday some time 0:06:57.760 --> 0:07:01.180 ago and my machine prompted me for for an update. 0:07:01.180 --> 0:07:03.580 I didn't realize it was Tuesday. I didn't realize it 0:07:03.580 --> 0:07:05.620 was Patch Tuesday. It was like, I'll just run the 0:07:05.620 --> 0:07:08.830 update now. A few files got blocked, caused a bit 0:07:08.830 --> 0:07:12.070 of embarrassment, and I'm basically the guy that they all 0:07:12.070 --> 0:07:14.530 tag now when they say, hey, it's Patch Tuesday, don't 0:07:14.560 --> 0:07:19.030 update your machines immediately. And but it very, very, very 0:07:19.030 --> 0:07:22.600 rarely happens. I mean, people don't normally get updates that 0:07:22.600 --> 0:07:26.590 quickly or install them that immediately. And you know, a 0:07:26.620 --> 0:07:29.380 lot of obviously bigger enterprises, they'll have, you know, slower 0:07:29.380 --> 0:07:32.560 rollout for things like patching or, you know, automated patching even, 0:07:32.590 --> 0:07:35.680 you know, MSPs will have something similar and they'll have 0:07:35.680 --> 0:07:38.140 patching programs that might update things once a day or 0:07:38.140 --> 0:07:40.270 whatever the case may be. So it doesn't tend to 0:07:40.270 --> 0:07:42.700 be an issue that somebody gets to something before we do. 0:07:42.700 --> 0:07:45.880 But again, one of the other benefits to what we 0:07:45.880 --> 0:07:49.120 do is if something gets blocked, it's really easy and 0:07:49.120 --> 0:07:52.250 really fast to get it allowed. It's like a 32nd 0:07:52.250 --> 0:07:54.860 process where a user goes, hey, I need to run 0:07:54.860 --> 0:07:58.100 this thing. And an administrator goes, yeah, okay, you can 0:07:58.100 --> 0:08:00.200 run it. So even if something does get blocked, it's 0:08:00.200 --> 0:08:03.770 a really smooth, easy, fast approval process. 0:08:04.310 --> 0:08:04.580 Yeah. 0:08:04.610 --> 0:08:06.800 And like you said, usually we have the opposite problem, right. 0:08:06.830 --> 0:08:10.010 People not applying patches, not applying them too quickly. 0:08:10.040 --> 0:08:13.760 Well it's actually it's a really interesting point because the 0:08:13.760 --> 0:08:16.940 problem I mean, it's obviously a huge problem from a 0:08:16.940 --> 0:08:22.070 cybersecurity perspective and vulnerable software and or vulnerabilities in software. 0:08:22.100 --> 0:08:24.680 I mean, there's so many different examples. There's a Veeam 0:08:24.680 --> 0:08:28.460 one at the moment that allows remote remote code execution. 0:08:28.490 --> 0:08:31.070 There's I mean, what I tend to say to people is, look, 0:08:31.100 --> 0:08:34.220 just assume the software, even if you patch your stuff 0:08:34.280 --> 0:08:37.760 absolutely on the button every time, I'd say assume the 0:08:37.760 --> 0:08:40.370 software that you're using, even though patched, is still full 0:08:40.370 --> 0:08:42.890 of holes, because it probably is. I mean, again, look 0:08:42.920 --> 0:08:46.490 at an average Patch Tuesday. Look at the serious issues 0:08:46.490 --> 0:08:49.720 that Microsoft fix every time they release an update for windows, 0:08:49.720 --> 0:08:52.330 so assume that those things are there even if your 0:08:52.330 --> 0:08:56.350 system is patched. And act accordingly. And it's effectively it's 0:08:56.380 --> 0:09:00.340 one of the tenets of zero trust is assume breach, 0:09:00.370 --> 0:09:05.950 assume issues, assume vulnerabilities. Assume you know the bad guys 0:09:05.950 --> 0:09:09.100 are already in for all intents and purposes. But if 0:09:09.100 --> 0:09:12.580 you take that approach, then everything that we do makes sense, 0:09:12.580 --> 0:09:14.530 which is okay, they're in now, what can they do? 0:09:14.559 --> 0:09:18.160 Can they run things? No. Can they exfiltrate data? No. 0:09:18.160 --> 0:09:22.210 Can they run ransomware? No. So again, everything we do 0:09:22.240 --> 0:09:23.740 and there is a lot more to it than just 0:09:23.830 --> 0:09:26.800 the listing. But everything else that we do just makes 0:09:26.800 --> 0:09:29.950 sense when you operate from that assumed breach perspective. 0:09:30.580 --> 0:09:33.280 Yeah, I like that a lot. So what are some 0:09:33.280 --> 0:09:37.150 other ways that you're you're implementing this zero trust philosophy? 0:09:37.179 --> 0:09:40.089 I looked at the site before getting on. I saw 0:09:40.090 --> 0:09:44.500 something called ring fencing. Um, is that the same or. 0:09:44.500 --> 0:09:45.310 Um, the. 0:09:45.610 --> 0:09:48.530 Ring fencing is awesome, if I may say so myself. Yeah. 0:09:48.559 --> 0:09:49.189 Go ahead. 0:09:49.940 --> 0:09:52.670 So basically what it is, is it takes the principle 0:09:52.670 --> 0:09:56.270 of deny by default, permit by exception, and it expands 0:09:56.270 --> 0:09:58.790 on it. So it's not so much about it's the 0:09:58.790 --> 0:10:00.920 other part of what we call application control, or what 0:10:00.920 --> 0:10:03.349 we consider to be application control as to what can 0:10:03.350 --> 0:10:06.320 run and what can't run. And then there's what things 0:10:06.320 --> 0:10:10.849 can do when they're running. So it's things like application interaction. 0:10:10.850 --> 0:10:14.030 So what applications can call what other applications. So like 0:10:14.059 --> 0:10:16.520 you may need to run office on your machines. You 0:10:16.520 --> 0:10:19.430 may need to run PowerShell on your machines. Does office 0:10:19.429 --> 0:10:20.990 need to call PowerShell. 0:10:21.290 --> 0:10:22.160 Oh okay. 0:10:22.190 --> 0:10:25.580 Absolutely not. So we can control those application interactions to 0:10:25.610 --> 0:10:29.390 stop things. You know that lateral movement between applications. But 0:10:29.390 --> 0:10:32.630 we can also control for example, what data an application 0:10:32.630 --> 0:10:35.240 has access to it. So again PowerShell is a great example. 0:10:35.270 --> 0:10:38.990 Does PowerShell need to access all my files, my documents, 0:10:38.990 --> 0:10:42.679 my spreadsheets, my network shares my UNC paths? Answer in 0:10:42.679 --> 0:10:45.680 most cases is no, but obviously out of the box 0:10:45.679 --> 0:10:49.860 it can, which is why it's so often misused. And 0:10:49.860 --> 0:10:52.890 so if you can limit what data things like PowerShell 0:10:52.920 --> 0:10:55.770 have access to, you're going to minimize the potential for 0:10:55.770 --> 0:10:59.490 data exfiltration, you know, and realistically the potential for damage 0:10:59.520 --> 0:11:01.860 if something bad does get into an environment. But we 0:11:01.860 --> 0:11:06.689 can also control where applications can connect to on the internet. 0:11:06.690 --> 0:11:11.040 So again PowerShell, brilliant example. Does PowerShell need to talk 0:11:11.040 --> 0:11:17.729 to the entire internet? Absolutely not. By default. Absolutely. Which 0:11:17.730 --> 0:11:21.660 is why it's used for data exfiltration or running remote code. 0:11:21.780 --> 0:11:23.730 And I mean I'll give you an example. We did 0:11:23.760 --> 0:11:28.410 a webinar recently with a guy called Jacobi. And guy 0:11:28.410 --> 0:11:32.489 is an absolute genius. I mean, he knows he he's. 0:11:32.490 --> 0:11:33.270 A friend of mine, I. 0:11:33.270 --> 0:11:34.500 Know him. Oh really? Yeah. 0:11:34.530 --> 0:11:37.199 So Jacobi does this really cool thing and you've probably 0:11:37.200 --> 0:11:40.530 seen this and he's got this, um, an API that 0:11:40.530 --> 0:11:45.580 he set up that basically delivers polymorphic and PowerShell reverse 0:11:45.580 --> 0:11:48.550 shell code. So every time it goes out to the API, 0:11:48.580 --> 0:11:50.380 it gets a different piece of code back, and it's 0:11:50.380 --> 0:11:53.410 not picked up or stopped or blocked by any traditional 0:11:53.440 --> 0:11:56.800 tool because again, it's different every time. It's not known bad. 0:11:56.830 --> 0:12:00.160 So how does that depends on knowing what's good or bad. 0:12:00.160 --> 0:12:04.060 Ever stop it. And but he has done he's done 0:12:04.059 --> 0:12:05.620 a couple of webinars now. The first one he kind 0:12:05.650 --> 0:12:07.449 of mentioned was he said I've come across this thing 0:12:07.480 --> 0:12:09.760 threatlocker and it's awesome. It blocks me every time from 0:12:09.760 --> 0:12:14.260 doing this. You know, they're using some amazing behavioral analysis or, 0:12:14.290 --> 0:12:17.530 you know, it's it I don't know, somehow knows what 0:12:17.530 --> 0:12:20.200 we're doing. And but we did another call with him 0:12:20.200 --> 0:12:22.210 last week. I don't think it's been released yet, but 0:12:22.210 --> 0:12:24.910 I was able to say to him, look, just to explain, Jacoby, 0:12:24.940 --> 0:12:28.090 we're not detecting what you're doing as being bad. We're 0:12:28.090 --> 0:12:31.780 not recognizing it as malicious. What we're doing instead is 0:12:31.809 --> 0:12:37.689 we're just saying, look, PowerShell can't access the internet. Stopped everything. 0:12:37.690 --> 0:12:40.929 He was in his tracks because he was dependent, or 0:12:40.929 --> 0:12:42.820 that the hacks that he was doing was dependent on 0:12:42.820 --> 0:12:46.260 PowerShell being able to access, in this case his API 0:12:46.290 --> 0:12:48.870 to get that polymorphic code, which then reached out to 0:12:48.990 --> 0:12:53.010 another reverse shell server. So by, as I said, controlling 0:12:53.010 --> 0:12:56.939 what applications can do is almost as important as what 0:12:56.940 --> 0:12:58.410 can run and what can't run. 0:12:59.100 --> 0:13:02.699 Okay I really love this. Okay. So so the overall 0:13:02.700 --> 0:13:05.729 theme is zero trust. But now we've got what can run, 0:13:05.730 --> 0:13:10.800 what can't run, what can invoke. Next to it. What 0:13:10.800 --> 0:13:13.770 can reach the internet. What are some other sort of, 0:13:13.770 --> 0:13:17.310 um zero trust concepts that you're applying. 0:13:17.340 --> 0:13:21.480 So we have a we've got a storage control component 0:13:21.480 --> 0:13:24.000 as well. Um, and I can I can give you 0:13:24.000 --> 0:13:27.090 an example of where storage control is very relevant, but 0:13:27.090 --> 0:13:30.390 storage control basically allows you to control which programs have 0:13:30.390 --> 0:13:33.900 access to what data. So now what users have access 0:13:33.900 --> 0:13:37.109 to what data, but which programs, which individual application can 0:13:37.110 --> 0:13:40.920 access what data. So there's a million different examples. I mean, 0:13:40.920 --> 0:13:43.089 if you think about it logically, like why would anything 0:13:43.120 --> 0:13:47.440 other than Hyper-V need to access a FD or VHDL file? 0:13:47.740 --> 0:13:51.040 Why would anything other than SQL server X need to 0:13:51.070 --> 0:13:54.820 access a SQL server's database? But again, out of the box. 0:13:54.850 --> 0:13:57.520 And it's one of the reasons why ransomware and data 0:13:57.520 --> 0:14:00.490 exfiltration are as prevalent as they are. It's because everything 0:14:00.490 --> 0:14:02.860 that can run on a system, or everything that you 0:14:02.860 --> 0:14:06.130 run on a system has access to everything that you 0:14:06.130 --> 0:14:08.530 have access to. So if you've got access to a 0:14:08.530 --> 0:14:13.240 management chair, everything you run, whether it be good bad, malware, ransomware, 0:14:13.270 --> 0:14:16.420 Angry Birds, they all have access to that data as 0:14:16.420 --> 0:14:20.290 well because they're running as you. So what we we 0:14:20.470 --> 0:14:26.350 augment or combine your traditional user based controls and add 0:14:26.350 --> 0:14:30.160 to that program based controls. So if you have a 0:14:30.160 --> 0:14:32.830 folder on the server, if that folder only needs to 0:14:32.830 --> 0:14:36.430 be accessed by Office and Acrobat and Teams and Zoom, 0:14:36.430 --> 0:14:39.970 why would you let any of the other 500 applications 0:14:39.970 --> 0:14:42.560 that are running in your computer, access that location. So again, 0:14:42.560 --> 0:14:46.190 it's denied by default permit by exception. But for programs 0:14:46.190 --> 0:14:51.590 and data we also have and again same principle with 0:14:51.590 --> 0:14:54.440 the same principle for networking. So we've got a firewall 0:14:54.470 --> 0:14:57.440 built into the same agent. So it's effectively a default 0:14:57.440 --> 0:15:01.370 denies permit by exception. And it's kind of smarter than 0:15:01.370 --> 0:15:04.880 your average firewall though. And I mean it's a huge problem. 0:15:04.910 --> 0:15:08.210 I mean people are taking, you know, work computers home. 0:15:08.210 --> 0:15:10.850 They're taking them to, you know, Starbucks or at events 0:15:10.850 --> 0:15:14.690 or in hotels or everywhere. So the time when we 0:15:14.690 --> 0:15:17.480 could all kind of hide behind the perimeter firewall and 0:15:17.480 --> 0:15:21.440 feel safe is very much gone. But because our firewall 0:15:21.440 --> 0:15:23.690 is centrally managed, you can see everything that's happening on 0:15:23.690 --> 0:15:25.760 all of your machines from one place, but you can 0:15:25.760 --> 0:15:29.060 also control everything. And but when I say it's smarter 0:15:29.060 --> 0:15:31.700 than your average firewall, we can use what we call 0:15:31.700 --> 0:15:35.390 dynamic ACLs. So I can create a policy that says, look, 0:15:35.420 --> 0:15:40.320 only allow machines in my IT group connect to an 0:15:40.320 --> 0:15:43.620 RDP port on a server or only allow machines in 0:15:43.620 --> 0:15:47.550 my workstations. Group connect to, you know, SQL 1433 on 0:15:47.550 --> 0:15:51.120 this server. But what that means is whether a port 0:15:51.120 --> 0:15:54.510 is open or not depends on what's connecting to it. 0:15:54.510 --> 0:15:58.260 If it's a device that you've explicitly said can access 0:15:58.290 --> 0:16:00.120 this resource on the server, it's going to be allowed 0:16:00.120 --> 0:16:04.530 to connect. If it's not, it won't. So it's effectively 0:16:04.560 --> 0:16:07.350 it's akin to network segmentation, but it's done at the 0:16:07.350 --> 0:16:11.010 endpoint level. It's not done with expensive or expensive switches 0:16:11.010 --> 0:16:13.710 and hardware and everything else. You're basically saying, look, only 0:16:13.710 --> 0:16:17.610 these devices can connect to this port. Now that stops 0:16:17.610 --> 0:16:22.020 so many ransomware attacks in their tracks just by blocking 0:16:22.020 --> 0:16:25.590 by default network connections. Because again, most of these ransomware 0:16:25.590 --> 0:16:29.880 attacks will need some sort of connection to take place. 0:16:29.880 --> 0:16:32.130 And in a lot of cases, I mean, the whole 0:16:32.130 --> 0:16:35.370 issue with RDP still being open, I mean, we've I've 0:16:35.370 --> 0:16:37.560 seen so many instances of RDP being open to the 0:16:37.560 --> 0:16:41.620 internet I mean, I'm going to put in or insert 0:16:41.620 --> 0:16:47.290 my usual RDP standing for Ransomware delivery protocol joke, but 0:16:47.290 --> 0:16:49.930 it's called that for a reason. I mean, it's close 0:16:49.930 --> 0:16:54.400 to 20%. Ransomware attacks still include RDP, and it's basically 0:16:54.400 --> 0:16:58.600 just servers hanging out with that port available on the internet. 0:16:58.630 --> 0:16:59.440 I mean, you're talking about three. 0:16:59.470 --> 0:17:01.090 Three, eight, nine like actual. 0:17:01.180 --> 0:17:01.510 Yeah. 0:17:02.260 --> 0:17:07.120 Um, and so if anybody's bored, um, do try this on. 0:17:07.119 --> 0:17:09.790 So go to shodan. So obviously, I'm sure you know 0:17:09.790 --> 0:17:11.770 what shodan is. It's effectively a search engine for the 0:17:11.770 --> 0:17:14.770 internet of things. Go to Shodan and you can search 0:17:14.770 --> 0:17:18.850 in Shodan for a specific port in an area. So 0:17:18.850 --> 0:17:22.810 you can look for port colon 3389 city colon Orlando 0:17:22.810 --> 0:17:25.720 for example. I did that some time ago for Orlando 0:17:25.720 --> 0:17:32.169 and it showed over 900 devices, over 900 servers, machines, 0:17:32.170 --> 0:17:35.920 you name it. With that port open to the internet 0:17:35.950 --> 0:17:39.470 and those machines, those organizations, those environments are literally a 0:17:39.470 --> 0:17:42.859 brute force password away from being the next victims of 0:17:42.859 --> 0:17:44.570 a ransomware attack and. 0:17:44.930 --> 0:17:45.230 Or. 0:17:45.230 --> 0:17:47.060 Being unpatched like RDP. 0:17:47.420 --> 0:17:51.199 Yeah, absolutely. Absolutely. And but it really is scary. And 0:17:51.200 --> 0:17:52.669 in some cases, I mean, you can literally see the 0:17:52.670 --> 0:17:55.040 name of the organization because they've got like the, you know, 0:17:55.070 --> 0:17:56.120 domain name header. 0:17:56.150 --> 0:17:56.480 Yeah. 0:17:56.930 --> 0:17:59.360 They show the user who's logged in. So it's not 0:17:59.359 --> 0:18:02.119 as if they have to even guess what the username is. 0:18:02.150 --> 0:18:04.820 They can say, oh this machine, the username is Rob. 0:18:04.820 --> 0:18:07.580 So I just need to run my, you know, password 0:18:07.580 --> 0:18:10.229 attack against the user Rob rather than to try a 0:18:10.230 --> 0:18:13.910 million different users. It's terrifying. But again, the point about 0:18:13.940 --> 0:18:18.440 network control is you could theoretically and hypothetically you could 0:18:18.680 --> 0:18:21.440 open port three, three, eight, nine to the internet. But 0:18:21.440 --> 0:18:25.130 you can say you can. Only these machines can connect. 0:18:25.130 --> 0:18:28.220 So when the internet tries to connect it, it can't 0:18:28.220 --> 0:18:31.070 because that port is closed. But if you're just the devices, 0:18:31.070 --> 0:18:32.780 the ones that you want to connect want to connect, 0:18:32.869 --> 0:18:35.730 they can't. So again, it's just it's taking that same 0:18:35.730 --> 0:18:38.879 principle of deny by default, permit by exception, but applying 0:18:38.880 --> 0:18:40.470 it to networking? 0:18:41.400 --> 0:18:42.330 Yeah. 0:18:43.530 --> 0:18:47.370 Really interesting. So I got a question for you. Have 0:18:47.400 --> 0:18:51.840 have you thought about or are you already doing um, 0:18:52.560 --> 0:18:56.699 gathering of context from an organization? So what if you 0:18:56.700 --> 0:19:00.210 could take an organization and just be like, okay, based 0:19:00.210 --> 0:19:04.800 on slack conversations based on internal wikis or whatever? This 0:19:04.800 --> 0:19:08.790 is the general flow of how things normally work, right? 0:19:08.790 --> 0:19:11.580 And then you could basically build a bunch of allow 0:19:11.609 --> 0:19:15.510 list rules across all the different facets, not just like 0:19:15.540 --> 0:19:20.880 can an application run, but these, these, uh, applications normally 0:19:20.880 --> 0:19:24.270 talk to these, uh, these servers over here should be 0:19:24.270 --> 0:19:28.290 accessed by these finance servers or whatever, and then intelligently 0:19:28.290 --> 0:19:34.200 build like this profile of different allows and disallows. 0:19:35.390 --> 0:19:39.560 To kind of do that already. So the learning mode 0:19:39.560 --> 0:19:42.410 and allow listing is effectively doing that. We learn quite 0:19:42.410 --> 0:19:44.750 a bit of ring fencing as well. So if applications 0:19:44.780 --> 0:19:49.220 need to go into particular locations or access particular internet locations, 0:19:49.220 --> 0:19:52.639 we learn that stuff already. I mean, it is your 0:19:52.640 --> 0:19:55.879 allow list is effectively that we also and I should 0:19:55.910 --> 0:19:57.590 have mentioned this, but we do also have what we 0:19:57.590 --> 0:20:01.850 call the unified audit, whereas which is visibility over everything 0:20:01.850 --> 0:20:04.580 that's happening on machines. So everything that runs, everything that 0:20:04.580 --> 0:20:07.940 can't run, everything that's allowed, everything that's denied network traffic 0:20:07.940 --> 0:20:11.870 in and out. So we have complete visibility over what 0:20:11.869 --> 0:20:15.980 is happening and also what's not happening in the environments 0:20:15.980 --> 0:20:20.030 that that are managed with Docker. And one thing I 0:20:20.030 --> 0:20:23.300 should mention, and a lot of what we've spoken about 0:20:23.330 --> 0:20:27.830 thus far has been effectively controlled. So as we take 0:20:27.830 --> 0:20:31.280 a different approach, we're not about detecting, we're not well, sorry, 0:20:31.310 --> 0:20:35.490 we're not primarily about detecting. We are primarily about controls 0:20:35.490 --> 0:20:39.780 or about environment effectively as unfriendly as possible to an 0:20:39.780 --> 0:20:44.250 attacker while allowing users to do what they need to do. 0:20:44.460 --> 0:20:46.949 So users and you know, you have to think or 0:20:46.950 --> 0:20:50.490 you have to consider that probably 98% of users do 0:20:50.490 --> 0:20:55.200 the same things with the same software every single day. Yep. 0:20:55.260 --> 0:20:57.690 I mean, they use office. They use Acrobat. They use 0:20:57.690 --> 0:21:02.820 video conferencing team zoom browsers. Obviously, you know, windows operating system, etc. 0:21:02.850 --> 0:21:06.600 maybe a line of business application or two. But fundamentally 0:21:06.600 --> 0:21:09.030 what we're doing is we're just setting guardrails around that. 0:21:09.060 --> 0:21:11.970 We're saying, look, operate within these guardrails and you're not 0:21:11.970 --> 0:21:14.400 even going to know we're here. Okay. So it's not 0:21:14.400 --> 0:21:16.800 going to affect or get in the way of the vast, 0:21:16.800 --> 0:21:20.790 vast majority of users. But back to what you mentioned 0:21:20.850 --> 0:21:23.520 a second ago. The other thing that we do as 0:21:23.520 --> 0:21:28.260 well as control. So we for many years a lot 0:21:28.290 --> 0:21:32.379 of organizations would run us beside some sort of detection. Okay. 0:21:32.410 --> 0:21:35.650 So they might run Threadlocker alongside an EDR for example. 0:21:35.680 --> 0:21:40.210 Basically Threadlocker offering the control and the EDR as effectively 0:21:40.210 --> 0:21:43.600 as a fallback as a okay, you know, somebody allowed 0:21:43.600 --> 0:21:46.150 something wrong they shouldn't have done. Now the EDR steps 0:21:46.150 --> 0:21:48.040 in and goes, okay, I'm going to detect that and 0:21:48.040 --> 0:21:52.030 hopefully clean it up. So what we've added more recently 0:21:52.030 --> 0:21:55.690 is what we call Threadlocker detect, which is a EDR 0:21:55.720 --> 0:21:59.109 that is attached to Threadlocker. I mean, it's effectively it's 0:21:59.109 --> 0:22:01.960 the same agent, it's the same portal, it's the same 0:22:02.080 --> 0:22:05.859 everything that you're using. But the beauty about Threadlocker is 0:22:05.859 --> 0:22:08.890 detection platform, which is, as I said, detect. And we 0:22:08.890 --> 0:22:13.600 also have MDR is we see not only everything that 0:22:13.600 --> 0:22:17.620 we have allowed, but we also see everything that we've denied. 0:22:17.619 --> 0:22:20.740 Because the problem is, if you're running Threadlocker alongside another 0:22:20.740 --> 0:22:24.520 tool like an EDR, we're blocking most of its source. 0:22:24.520 --> 0:22:27.820 We're stopping, you know, remote access tools from running. We're 0:22:27.820 --> 0:22:31.370 stopping everything from running at source and very often the 0:22:31.369 --> 0:22:34.369 editor that's running alongside us won't even know that happened. 0:22:34.460 --> 0:22:37.340 You know what I mean? So yes. Yeah, but Angus 0:22:37.340 --> 0:22:39.560 has been blocked from running, so it has nothing to detect. 0:22:39.560 --> 0:22:42.050 It has nothing to respond to. So the beauty about 0:22:42.050 --> 0:22:44.900 us is we see both sides. We see everything that's 0:22:44.900 --> 0:22:47.990 been allowed. We also see everything that's been denied. And 0:22:47.990 --> 0:22:52.550 we can alert, detect and respond accordingly. Because the thing 0:22:52.550 --> 0:22:55.670 is what the layers of control we mentioned are going 0:22:55.670 --> 0:22:58.130 to do is they're going to buy you time, okay. 0:22:58.160 --> 0:23:01.370 In the event of a cyber attack, having time where 0:23:01.400 --> 0:23:03.770 you know, they're in, but they can't do anything because 0:23:03.770 --> 0:23:06.140 they keep on banging their heads against the wall. That 0:23:06.140 --> 0:23:09.350 is threatlocker that's going to buy you time, but you 0:23:09.350 --> 0:23:11.660 still want to know if something's going on. 0:23:11.660 --> 0:23:14.570 Yeah, because they might switch tactics to something else that 0:23:14.600 --> 0:23:17.090 that you can't block. And you get all that time 0:23:17.090 --> 0:23:18.500 if you're seeing it beforehand. 0:23:18.590 --> 0:23:21.440 This is exactly the point. So basically if you know 0:23:21.470 --> 0:23:23.900 there's a deep connection coming in or if an event 0:23:23.930 --> 0:23:26.660 log gets cleared on a server, if there's any other of, 0:23:26.690 --> 0:23:30.600 you know, hundreds of indicators of compromise. We see them 0:23:30.600 --> 0:23:33.479 and with our detection platform and our EDR sorry, on 0:23:33.480 --> 0:23:36.810 our end or basically which is human beings sitting outside 0:23:36.810 --> 0:23:39.510 the office here basically looking at these alerts or customers, 0:23:39.510 --> 0:23:42.630 but basically they will say or it will tell you 0:23:42.630 --> 0:23:46.920 something is happening, whether or not some other EDR might 0:23:46.920 --> 0:23:49.830 even know it's going on, which very often they won't. 0:23:49.830 --> 0:23:53.970 But look, the point is we see detection as being 0:23:53.970 --> 0:23:58.199 complementary to those other layers of protection I mentioned. We 0:23:58.200 --> 0:24:00.719 don't see it like for us, detection is not the 0:24:00.720 --> 0:24:02.669 entire game for. 0:24:02.700 --> 0:24:06.240 Yeah, I've always said I mean probably maybe it's NIST 0:24:06.240 --> 0:24:09.510 or something, but I've always said, um, prevent detect respond 0:24:09.510 --> 0:24:13.230 in that order. Right. So if you're zero trust prevent 0:24:13.260 --> 0:24:16.350 is the number one. But you also want to have 0:24:16.350 --> 0:24:19.619 that visibility. So it's nice you have that that that function. 0:24:20.190 --> 0:24:22.800 What about respond. Is there any anything you have there 0:24:22.800 --> 0:24:25.560 about I guess firing off an alert would be one. 0:24:25.590 --> 0:24:27.480 Well, absolutely. We can do a lot of different things 0:24:27.500 --> 0:24:30.500 So we can we make people aware, I suppose is 0:24:30.500 --> 0:24:32.359 the first thing. So, you know, log a ticket, send 0:24:32.359 --> 0:24:34.429 an email, pick up the phone, which is what our 0:24:34.430 --> 0:24:38.090 entire team will do depending on a customer's defined playbook 0:24:38.119 --> 0:24:41.810 or runbook. And we can take automatic remediating actions. So 0:24:41.840 --> 0:24:44.750 like if we see something happening on a machine we 0:24:44.750 --> 0:24:47.360 can not only. And I know a lot of solutions 0:24:47.359 --> 0:24:50.750 allow you to isolate machines from network. And isolation is 0:24:50.750 --> 0:24:53.480 all very well and good and we offer isolation as well. 0:24:53.480 --> 0:24:55.610 But the problem is if you isolate a server that's 0:24:55.609 --> 0:24:58.370 running ransomware, you're going to do nothing other than allow 0:24:58.369 --> 0:25:01.460 that ransomware to continue to run and also have server 0:25:01.460 --> 0:25:03.800 isolated from anything it needs to talk to. So we 0:25:03.800 --> 0:25:06.410 have what we call lockdown mode. And lockdown mode is 0:25:06.410 --> 0:25:11.600 like isolation on steroids basically. So it both blocks everything 0:25:11.600 --> 0:25:14.060 from running. And when I say everything, I mean everything 0:25:14.090 --> 0:25:17.540 large parts of windows as well. It blocks even, you know, 0:25:17.570 --> 0:25:20.480 otherwise good applications, things like Chrome, Internet Explorer, they're all 0:25:20.510 --> 0:25:22.310 going to get blocked from running. You can't run office, 0:25:22.340 --> 0:25:25.010 you can't run PowerShell, you can't run command prompt effectively. 0:25:25.010 --> 0:25:28.139 You can't run anything on the machine, but it also 0:25:28.170 --> 0:25:31.290 locks on blocks down access to storage. So any protected 0:25:31.290 --> 0:25:33.750 storage location, we say okay. Block all reads and writes 0:25:33.750 --> 0:25:36.689 to that. So your your ransomware may be running, but 0:25:36.690 --> 0:25:38.670 it's not going to be able to encrypt my data. 0:25:38.670 --> 0:25:40.950 But it also and the third thing we do on 0:25:40.950 --> 0:25:42.990 top of that is we also isolate from the network. 0:25:42.990 --> 0:25:45.240 So if there's incoming outgoing connections, we're going to kill 0:25:45.240 --> 0:25:48.420 those connections. That machine is going to stay isolated. So 0:25:48.450 --> 0:25:51.629 as I said, lockdown mode is like a much more 0:25:51.630 --> 0:25:55.439 extreme version of isolation, but it's one that will actually 0:25:55.440 --> 0:25:58.770 stop ransomware in its tracks, whereas isolation is just going 0:25:58.800 --> 0:26:01.020 to allow it to continue on its own. And but 0:26:01.020 --> 0:26:04.920 we do also have remediation facilities. So basically you can 0:26:05.310 --> 0:26:09.389 if a customer wants, we have a separate service called Remediator, 0:26:09.390 --> 0:26:12.390 which effectively is a PowerShell access to the machine, which 0:26:12.390 --> 0:26:14.970 we can get in and stop things, delete things, do 0:26:14.970 --> 0:26:18.060 whatever the customer wants. Again, it's all very much based 0:26:18.060 --> 0:26:19.470 on the customer's requirements. 0:26:19.800 --> 0:26:20.310 Okay, so. 0:26:20.310 --> 0:26:23.550 You mentioned the people out there watching. Um, so is 0:26:23.550 --> 0:26:28.960 the MSP service. Is that part of the endpoint product 0:26:28.960 --> 0:26:31.930 or is like, is that an add on like that 0:26:31.930 --> 0:26:36.159 monitoring piece? How tied into it the product is that? 0:26:36.250 --> 0:26:38.770 Oh, it's completely integrated. But we've got we've effectively on 0:26:38.770 --> 0:26:42.940 top of the the products as in the software as 0:26:42.940 --> 0:26:45.399 a service that you pay for. We do have a 0:26:45.400 --> 0:26:48.100 couple of additional services. One is what we call cyber 0:26:48.130 --> 0:26:51.670 hero approvals, which is if you don't want the hassle 0:26:51.670 --> 0:26:56.169 of dealing with your users, sending requests through and saying 0:26:56.170 --> 0:26:57.639 they want to run this thing and they want to 0:26:57.640 --> 0:27:00.490 run that thing, you can effectively outsource that to us, 0:27:00.490 --> 0:27:05.379 where we'll basically approve or deny applications requests according to 0:27:05.410 --> 0:27:09.820 your specific instructions. So you might say look them remote 0:27:09.820 --> 0:27:14.920 access tools. Bad. Don't allow them video conferencing video conferencing tools. Yes. 0:27:14.950 --> 0:27:17.980 And but you know that's a set of instructions effectively 0:27:17.980 --> 0:27:19.570 for us to follow. And we will follow them to 0:27:19.600 --> 0:27:21.580 the letter. So somebody tries to run a remote access tool, 0:27:21.609 --> 0:27:22.899 we're going to block it if somebody tries to run 0:27:22.900 --> 0:27:26.300 a video conferencing tool will permit it for you or 0:27:26.300 --> 0:27:29.330 on your behalf. So that's the cyber hero approvals. We 0:27:29.330 --> 0:27:33.290 also have eMDR, which is again tied to the ADR, 0:27:33.320 --> 0:27:36.890 tied to the detection, which is human beings sitting outside 0:27:36.890 --> 0:27:40.700 here watching alerts, investigating when something is going on and 0:27:40.700 --> 0:27:43.910 if needs be, alerting customers or as I said, taking 0:27:43.910 --> 0:27:45.290 remediating action. 0:27:46.609 --> 0:27:47.060 Yeah. 0:27:47.090 --> 0:27:51.109 Fantastic. Well, this is this is super interesting. I actually 0:27:51.109 --> 0:27:53.570 have an idea I want to ask you about, but 0:27:53.570 --> 0:27:56.690 I think it might, uh, take us into a whole 0:27:56.690 --> 0:28:01.639 separate episode. I'm actually curious about if we were to 0:28:01.670 --> 0:28:08.090 break down the different portions of a ransomware attack, like. So. 0:28:08.090 --> 0:28:10.369 It's got to get in. It's got to do the following. 0:28:10.400 --> 0:28:13.430 It wants to spread. I would like to match that 0:28:13.430 --> 0:28:18.200 with the different blocking functionality and the detection functionality of 0:28:18.200 --> 0:28:21.500 the tool. So it's like this particular portion gets blocked 0:28:21.500 --> 0:28:24.790 by this portion. If it gets through there, which it wouldn't, 0:28:24.790 --> 0:28:27.940 but if it somehow did, it would get stopped here 0:28:27.940 --> 0:28:30.639 and then stopped at the internet. So it's like, here's 0:28:30.640 --> 0:28:32.860 three different ways or here's five different ways. It would 0:28:32.859 --> 0:28:33.670 be stopped. 0:28:33.700 --> 0:28:34.150 Yeah. 0:28:34.600 --> 0:28:38.500 Absolutely. And look, there's so many different examples of that. 0:28:38.530 --> 0:28:43.120 I mean, you know, we stop very often the initial 0:28:43.120 --> 0:28:45.610 access because we're going to stop the network connection coming in. 0:28:45.640 --> 0:28:48.190 Even if a network connection comes in, we're going to 0:28:48.220 --> 0:28:51.460 probably detect a brute force happening because we can, you know, 0:28:51.490 --> 0:28:55.030 detect or fail logons. So even if they do get 0:28:55.030 --> 0:28:57.070 that far in, then they're probably going to try and 0:28:57.070 --> 0:28:59.440 give themselves persistent access. So they're going to run something 0:28:59.440 --> 0:29:01.360 like Anydesk. Well, we're going to block that by default 0:29:01.360 --> 0:29:03.730 because blocking things is what we do. Or they might 0:29:03.760 --> 0:29:07.360 try and run a reverse shell in PowerShell. Again we're 0:29:07.390 --> 0:29:10.840 going to block that because blocking PowerShell from accessing the 0:29:10.840 --> 0:29:15.010 internet there's probably about in your average ransomware attack, there's 0:29:15.010 --> 0:29:17.980 probably about ten different stages that we would basically step 0:29:17.980 --> 0:29:22.300 in and block things. Um, To embody it would be 0:29:22.300 --> 0:29:27.400 an interesting exercise and to undertake, but I would suggest 0:29:27.400 --> 0:29:30.280 in most attacks there's a lot of different ways that 0:29:30.280 --> 0:29:33.010 we we would get in their way. 0:29:34.000 --> 0:29:34.300 Yeah. 0:29:34.330 --> 0:29:37.479 Interesting. Any new stuff coming out? You should let us 0:29:37.480 --> 0:29:38.230 know about. 0:29:38.890 --> 0:29:42.520 Um, so the detection eMDR was released this year. We 0:29:42.520 --> 0:29:46.959 have recently added Cloud Detect as well. So effectively the 0:29:46.960 --> 0:29:51.490 same or similar capabilities as Threatlocker detect but for cloud environments. 0:29:51.490 --> 0:29:54.550 So first one we've done is office 365 with the 0:29:54.550 --> 0:29:57.190 likes of G suite and others coming soon as well. 0:29:57.190 --> 0:30:01.930 So same principle looking for anomalous behavior. I mean, a 0:30:01.960 --> 0:30:06.580 lot of the problems are whether you're managing one office 0:30:06.580 --> 0:30:12.490 365 environment or 100 office 365 environments, actually finding somewhere 0:30:12.490 --> 0:30:14.680 with all of the information you need and all the 0:30:14.680 --> 0:30:17.920 alerts that you want to look at is not always easy. Um, 0:30:17.950 --> 0:30:22.890 less Microsoft. but again, allow people to alert themselves on, 0:30:22.920 --> 0:30:27.570 you know, suspicious travel and anomalous behavior, forwarding rules being 0:30:27.570 --> 0:30:30.930 set up, all those kind of things. Again, in one place, 0:30:30.930 --> 0:30:33.900 rather than having to go into 50 different office, 365 0:30:33.930 --> 0:30:36.780 tendencies to see what's going on. So Cloud Detect is 0:30:36.780 --> 0:30:39.479 probably the newest thing that we've we've added recently, and 0:30:39.480 --> 0:30:41.790 it's something that's gaining a lot of interest and a 0:30:41.790 --> 0:30:42.720 lot of traction. 0:30:43.530 --> 0:30:46.350 Awesome. And where can people learn more about you? 0:30:47.760 --> 0:30:51.450 Threatlocker. Com is a good place to start. We are 0:30:51.450 --> 0:30:56.280 on all the things we're on, um, Facebook. We're on Twitter. 0:30:56.310 --> 0:31:00.030 I refuse to call it X and we're on YouTube. 0:31:00.030 --> 0:31:04.560 And if anybody is interested, we do webinars on YouTube 0:31:04.560 --> 0:31:08.670 quite often, maybe once or twice a month, and often 0:31:08.670 --> 0:31:12.510 entertaining and somewhat or sometimes educational. So have a look 0:31:12.540 --> 0:31:15.060 at them as well. We sort of take deep dives into, 0:31:15.090 --> 0:31:18.400 you know, different attack vectors. We did, you know, things 0:31:18.400 --> 0:31:22.930 about drones and Wi-Fi? Pineapples at one stage that may 0:31:22.930 --> 0:31:25.870 have been, may or may not have crashed a drone 0:31:25.870 --> 0:31:28.870 into a building here. And but yes, at the risk 0:31:28.870 --> 0:31:31.990 of sounding like every YouTuber, my children watch and smash 0:31:31.990 --> 0:31:33.820 that subscribe button and check us out. 0:31:34.840 --> 0:31:35.560 Awesome. 0:31:35.590 --> 0:31:37.600 Well, thanks for your time today. I enjoyed it. 0:31:37.630 --> 0:31:39.550 You're very welcome. Daniel, thank you very much. 0:31:39.580 --> 0:31:39.910 All right. 0:31:39.940 --> 0:31:40.540 Take care. 0:31:40.900 --> 0:31:41.410 Bye bye. 0:31:44.350 --> 0:31:47.530 Unsupervised learning is produced and edited by Daniel Miessler on 0:31:47.530 --> 0:31:52.120 a Neumann U87 AI microphone using Hindenburg. Intro and outro 0:31:52.150 --> 0:31:55.480 music is by zombie with a Y. And to get 0:31:55.480 --> 0:31:57.550 the text and links from this episode, sign up for 0:31:57.550 --> 0:32:03.190 the newsletter version of the show at Daniel miessler.com/newsletter. We'll 0:32:03.190 --> 0:32:04.060 see you next time.