S1: Welcome to Unsupervised Learning, a security, AI and meaning focused
S1: podcast that looks at how best to thrive as humans
S1: in a post AI world. It combines original ideas, analysis,
S1: and mental models to bring not just the news, but
S1: why it matters and how to respond. All right, Rob,
S1: welcome to Unsupervised Learning.
S2: Hi, Daniel. Thank you for having me.
S1: Excellent. So can we get you to give a brief
S1: intro into yourself and talk about Threatlocker and what you
S1: guys do over there?
S2: Sure. So I'm Rob Allen. I am chief product officer
S2: here at Threatlocker. As you can probably tell from my
S2: Midwest accent, I'm. No, I'm not from the Midwest. I'm
S2: from Ireland. And I've worked at Lockhart for about almost
S2: four years now. And Threatlocker are a zero. Zero trust
S2: cybersecurity solution. So a endpoint protection platform effectively. And we
S2: take a slightly different approach to cybersecurity, to most other tools,
S2: and fundamentally, where other things allow everything except what's known
S2: to be bad. We take the approach of block everything
S2: unless it's explicitly allowed, and a few different ways we
S2: do that, a few different aspects to it. But fundamentally
S2: it's a design by default, permit by exception approach, which
S2: is pretty much a cornerstone of zero trust.
S1: Mhm. Interesting. Yeah. That's one of my next questions is
S1: basically what is what is it that you're doing different.
S1: So that that's fascinating. Um and the reason most people
S1: can't do that, especially back in the firewall days or whatever,
S1: there was just too many things to have to poke
S1: holes through. So I imagine you've found some pretty interesting
S1: ways to, uh, to allow benign behavior. So how are
S1: you doing that?
S2: So there's a few parts of what we do. So
S2: first of all, the core of what we do is
S2: allow listing. So it's basically allowing what needs to run
S2: to run. I'm blocking everything else now. Anybody who's ever
S2: tried to do that probably knows that historically, that has
S2: been somewhat, even though it is kind of the gold
S2: standard in terms of cybersecurity. It is kind of a
S2: heavy lift with some of the tools that are out there.
S2: It's a lot of hard work, basically, and we do
S2: a few things differently that make it manageable. We make
S2: it attainable for even, you know, small and medium organizations.
S2: And first thing that we do differently is we basically
S2: learn everything automatically. So you deploy an agent onto your machines.
S2: It does all the hard work effectively. So it figures
S2: out everything that's required on the machine and creates policies
S2: to allow those things to continue to run once the
S2: threat has been turned on. So that's kind of the
S2: first way that we make this process much easier. The
S2: second way. And again, anybody who's ever tried to implement
S2: a listing will know that one of the biggest problems
S2: is the question of what happens when software updates. And
S2: generally speaking, What happens when software updates? Is it breaks
S2: because whatever licensing solution you're using will say, well, look,
S2: I know that file is called acrobatics, but it doesn't
S2: match my acrobatics, so I'm not going to let it run. Um,
S2: and that has always been one of the biggest hurdles
S2: with implementing this approach. So what we do to solve
S2: that problem is we have this concept of what we
S2: call built in applications, which are effectively application definitions that
S2: we maintain, we manage. We've got over 4000 common applications,
S2: everything from Acrobat to teams to zoom to office. I mean, technically,
S2: windows is kind of a built in application as well,
S2: but every time there's an update for any of those things,
S2: our applications team who are based here in Orlando working
S2: 24 over seven, 365 will run. It will capture any
S2: new files that are included in that application, and it
S2: gets pushed down to people's machines automatically. So anybody who
S2: has a definition for or a policy for teams, for example,
S2: new update comes out, they capture it. It gets pushed
S2: down to every machine that's running teams automatically. So effectively
S2: it takes a lot of the heavy lifting. It takes
S2: a lot of the hard work out of what used
S2: to be quite an involved process.
S1: Oh very interesting. So, so, um, so essentially you're watching
S1: all these core applications. It sounds like roughly 4000 or so.
S1: And then, um, any new update that comes out that
S1: immediately comes to you, you're instrument it and re push
S1: it down as part of the allow list.
S2: So we don't push it down per se. What we
S2: do is we push down hashes. We push down new
S2: files that are allowed. So when our customer tries to
S2: run those new files, they will be allowed to do so.
S2: So yeah we update the application definitions constantly like every
S2: one of those applications, as far as I know, is
S2: checked pretty much once a day. Um, some things far
S2: more often than that. I mean, Chrome updates often and sporadically.
S2: So we might check that for argument's sake, 12 times
S2: a day. And just to make sure that we capture
S2: all those hashes as soon as possible. So by the
S2: time customers come to install them, they don't have any
S2: problems with their software being blocked. We would like this.
S2: Patch Tuesday is our busiest or our OP team's busiest
S2: day of the month. And you know, there could be five, ten,
S2: 15,000 new hashes pushed out by Microsoft as part of
S2: Patch Tuesday. So they all need to be accounted for.
S2: They all need to be allowed when our customers try
S2: and run them. So as I said, our app team
S2: our the it's kind of the secret sauce, the special
S2: sauce as to why Threadlocker is as easy to manage
S2: as it is, because we're taking a lot of that
S2: heavy lifting, a lot of that responsibility. We're taking it
S2: off customers and taking it on ourselves.
S3: Yeah.
S1: Very interesting. Um, you mentioned the vendor putting out hashes.
S1: Is that one option for you to, um, I mean,
S1: could Microsoft actually put out a of thing. I guess
S1: it wouldn't be hashed in your particular way.
S2: Um, no. Well, if most of what we do is
S2: based on Sha 256, so technically it could. But we
S2: have relationships with lots of vendors. So they give us,
S2: you know. Access to their software before it actually gets
S2: pushed out in many cases. And I mean, in some cases,
S2: vendors don't cooperate. And we have to. Literally go out
S2: and buy their software and able to get out in
S2: order to. Get access to it as early as possible.
S2: But a lot of vendors do cooperate. I have to say,
S2: particularly cyber security solutions and cyber security. Security tools. And
S2: they're very good in giving us either access or. Early
S2: access to their software so we can make sure it
S2: doesn't get blocked. On our customer's machines.
S1: Okay. That makes sense. So you don't have too many
S1: situations where um. Somebody just randomly luckily immediately got the
S1: update and they're installing it within, like whatever 30s of
S1: it coming out.
S3: I've been that.
S2: Guy. I've been that guy. So Patch Tuesday some time
S2: ago and my machine prompted me for for an update.
S2: I didn't realize it was Tuesday. I didn't realize it
S2: was Patch Tuesday. It was like, I'll just run the
S2: update now. A few files got blocked, caused a bit
S2: of embarrassment, and I'm basically the guy that they all
S2: tag now when they say, hey, it's Patch Tuesday, don't
S2: update your machines immediately. And but it very, very, very
S2: rarely happens. I mean, people don't normally get updates that
S2: quickly or install them that immediately. And you know, a
S2: lot of obviously bigger enterprises, they'll have, you know, slower
S2: rollout for things like patching or, you know, automated patching even,
S2: you know, MSPs will have something similar and they'll have
S2: patching programs that might update things once a day or
S2: whatever the case may be. So it doesn't tend to
S2: be an issue that somebody gets to something before we do.
S2: But again, one of the other benefits to what we
S2: do is if something gets blocked, it's really easy and
S2: really fast to get it allowed. It's like a 32nd
S2: process where a user goes, hey, I need to run
S2: this thing. And an administrator goes, yeah, okay, you can
S2: run it. So even if something does get blocked, it's
S2: a really smooth, easy, fast approval process.
S3: Yeah.
S1: And like you said, usually we have the opposite problem, right.
S1: People not applying patches, not applying them too quickly.
S2: Well it's actually it's a really interesting point because the
S2: problem I mean, it's obviously a huge problem from a
S2: cybersecurity perspective and vulnerable software and or vulnerabilities in software.
S2: I mean, there's so many different examples. There's a Veeam
S2: one at the moment that allows remote remote code execution.
S2: There's I mean, what I tend to say to people is, look,
S2: just assume the software, even if you patch your stuff
S2: absolutely on the button every time, I'd say assume the
S2: software that you're using, even though patched, is still full
S2: of holes, because it probably is. I mean, again, look
S2: at an average Patch Tuesday. Look at the serious issues
S2: that Microsoft fix every time they release an update for windows,
S2: so assume that those things are there even if your
S2: system is patched. And act accordingly. And it's effectively it's
S2: one of the tenets of zero trust is assume breach,
S2: assume issues, assume vulnerabilities. Assume you know the bad guys
S2: are already in for all intents and purposes. But if
S2: you take that approach, then everything that we do makes sense,
S2: which is okay, they're in now, what can they do?
S2: Can they run things? No. Can they exfiltrate data? No.
S2: Can they run ransomware? No. So again, everything we do
S2: and there is a lot more to it than just
S2: the listing. But everything else that we do just makes
S2: sense when you operate from that assumed breach perspective.
S1: Yeah, I like that a lot. So what are some
S1: other ways that you're you're implementing this zero trust philosophy?
S1: I looked at the site before getting on. I saw
S1: something called ring fencing. Um, is that the same or.
S3: Um, the.
S2: Ring fencing is awesome, if I may say so myself. Yeah.
S1: Go ahead.
S2: So basically what it is, is it takes the principle
S2: of deny by default, permit by exception, and it expands
S2: on it. So it's not so much about it's the
S2: other part of what we call application control, or what
S2: we consider to be application control as to what can
S2: run and what can't run. And then there's what things
S2: can do when they're running. So it's things like application interaction.
S2: So what applications can call what other applications. So like
S2: you may need to run office on your machines. You
S2: may need to run PowerShell on your machines. Does office
S2: need to call PowerShell.
S1: Oh okay.
S2: Absolutely not. So we can control those application interactions to
S2: stop things. You know that lateral movement between applications. But
S2: we can also control for example, what data an application
S2: has access to it. So again PowerShell is a great example.
S2: Does PowerShell need to access all my files, my documents,
S2: my spreadsheets, my network shares my UNC paths? Answer in
S2: most cases is no, but obviously out of the box
S2: it can, which is why it's so often misused. And
S2: so if you can limit what data things like PowerShell
S2: have access to, you're going to minimize the potential for
S2: data exfiltration, you know, and realistically the potential for damage
S2: if something bad does get into an environment. But we
S2: can also control where applications can connect to on the internet.
S2: So again PowerShell, brilliant example. Does PowerShell need to talk
S2: to the entire internet? Absolutely not. By default. Absolutely. Which
S2: is why it's used for data exfiltration or running remote code.
S2: And I mean I'll give you an example. We did
S2: a webinar recently with a guy called Jacobi. And guy
S2: is an absolute genius. I mean, he knows he he's.
S1: A friend of mine, I.
S3: Know him. Oh really? Yeah.
S2: So Jacobi does this really cool thing and you've probably
S2: seen this and he's got this, um, an API that
S2: he set up that basically delivers polymorphic and PowerShell reverse
S2: shell code. So every time it goes out to the API,
S2: it gets a different piece of code back, and it's
S2: not picked up or stopped or blocked by any traditional
S2: tool because again, it's different every time. It's not known bad.
S2: So how does that depends on knowing what's good or bad.
S2: Ever stop it. And but he has done he's done
S2: a couple of webinars now. The first one he kind
S2: of mentioned was he said I've come across this thing
S2: threatlocker and it's awesome. It blocks me every time from
S2: doing this. You know, they're using some amazing behavioral analysis or,
S2: you know, it's it I don't know, somehow knows what
S2: we're doing. And but we did another call with him
S2: last week. I don't think it's been released yet, but
S2: I was able to say to him, look, just to explain, Jacoby,
S2: we're not detecting what you're doing as being bad. We're
S2: not recognizing it as malicious. What we're doing instead is
S2: we're just saying, look, PowerShell can't access the internet. Stopped everything.
S2: He was in his tracks because he was dependent, or
S2: that the hacks that he was doing was dependent on
S2: PowerShell being able to access, in this case his API
S2: to get that polymorphic code, which then reached out to
S2: another reverse shell server. So by, as I said, controlling
S2: what applications can do is almost as important as what
S2: can run and what can't run.
S1: Okay I really love this. Okay. So so the overall
S1: theme is zero trust. But now we've got what can run,
S1: what can't run, what can invoke. Next to it. What
S1: can reach the internet. What are some other sort of,
S1: um zero trust concepts that you're applying.
S2: So we have a we've got a storage control component
S2: as well. Um, and I can I can give you
S2: an example of where storage control is very relevant, but
S2: storage control basically allows you to control which programs have
S2: access to what data. So now what users have access
S2: to what data, but which programs, which individual application can
S2: access what data. So there's a million different examples. I mean,
S2: if you think about it logically, like why would anything
S2: other than Hyper-V need to access a FD or VHDL file?
S2: Why would anything other than SQL server X need to
S2: access a SQL server's database? But again, out of the box.
S2: And it's one of the reasons why ransomware and data
S2: exfiltration are as prevalent as they are. It's because everything
S2: that can run on a system, or everything that you
S2: run on a system has access to everything that you
S2: have access to. So if you've got access to a
S2: management chair, everything you run, whether it be good bad, malware, ransomware,
S2: Angry Birds, they all have access to that data as
S2: well because they're running as you. So what we we
S2: augment or combine your traditional user based controls and add
S2: to that program based controls. So if you have a
S2: folder on the server, if that folder only needs to
S2: be accessed by Office and Acrobat and Teams and Zoom,
S2: why would you let any of the other 500 applications
S2: that are running in your computer, access that location. So again,
S2: it's denied by default permit by exception. But for programs
S2: and data we also have and again same principle with
S2: the same principle for networking. So we've got a firewall
S2: built into the same agent. So it's effectively a default
S2: denies permit by exception. And it's kind of smarter than
S2: your average firewall though. And I mean it's a huge problem.
S2: I mean people are taking, you know, work computers home.
S2: They're taking them to, you know, Starbucks or at events
S2: or in hotels or everywhere. So the time when we
S2: could all kind of hide behind the perimeter firewall and
S2: feel safe is very much gone. But because our firewall
S2: is centrally managed, you can see everything that's happening on
S2: all of your machines from one place, but you can
S2: also control everything. And but when I say it's smarter
S2: than your average firewall, we can use what we call
S2: dynamic ACLs. So I can create a policy that says, look,
S2: only allow machines in my IT group connect to an
S2: RDP port on a server or only allow machines in
S2: my workstations. Group connect to, you know, SQL 1433 on
S2: this server. But what that means is whether a port
S2: is open or not depends on what's connecting to it.
S2: If it's a device that you've explicitly said can access
S2: this resource on the server, it's going to be allowed
S2: to connect. If it's not, it won't. So it's effectively
S2: it's akin to network segmentation, but it's done at the
S2: endpoint level. It's not done with expensive or expensive switches
S2: and hardware and everything else. You're basically saying, look, only
S2: these devices can connect to this port. Now that stops
S2: so many ransomware attacks in their tracks just by blocking
S2: by default network connections. Because again, most of these ransomware
S2: attacks will need some sort of connection to take place.
S2: And in a lot of cases, I mean, the whole
S2: issue with RDP still being open, I mean, we've I've
S2: seen so many instances of RDP being open to the
S2: internet I mean, I'm going to put in or insert
S2: my usual RDP standing for Ransomware delivery protocol joke, but
S2: it's called that for a reason. I mean, it's close
S2: to 20%. Ransomware attacks still include RDP, and it's basically
S2: just servers hanging out with that port available on the internet.
S3: I mean, you're talking about three.
S1: Three, eight, nine like actual.
S3: Yeah.
S2: Um, and so if anybody's bored, um, do try this on.
S2: So go to shodan. So obviously, I'm sure you know
S2: what shodan is. It's effectively a search engine for the
S2: internet of things. Go to Shodan and you can search
S2: in Shodan for a specific port in an area. So
S2: you can look for port colon 3389 city colon Orlando
S2: for example. I did that some time ago for Orlando
S2: and it showed over 900 devices, over 900 servers, machines,
S2: you name it. With that port open to the internet
S2: and those machines, those organizations, those environments are literally a
S2: brute force password away from being the next victims of
S2: a ransomware attack and.
S3: Or.
S1: Being unpatched like RDP.
S2: Yeah, absolutely. Absolutely. And but it really is scary. And
S2: in some cases, I mean, you can literally see the
S2: name of the organization because they've got like the, you know,
S2: domain name header.
S3: Yeah.
S2: They show the user who's logged in. So it's not
S2: as if they have to even guess what the username is.
S2: They can say, oh this machine, the username is Rob.
S2: So I just need to run my, you know, password
S2: attack against the user Rob rather than to try a
S2: million different users. It's terrifying. But again, the point about
S2: network control is you could theoretically and hypothetically you could
S2: open port three, three, eight, nine to the internet. But
S2: you can say you can. Only these machines can connect.
S2: So when the internet tries to connect it, it can't
S2: because that port is closed. But if you're just the devices,
S2: the ones that you want to connect want to connect,
S2: they can't. So again, it's just it's taking that same
S2: principle of deny by default, permit by exception, but applying
S2: it to networking?
S3: Yeah.
S1: Really interesting. So I got a question for you. Have
S1: have you thought about or are you already doing um,
S1: gathering of context from an organization? So what if you
S1: could take an organization and just be like, okay, based
S1: on slack conversations based on internal wikis or whatever? This
S1: is the general flow of how things normally work, right?
S1: And then you could basically build a bunch of allow
S1: list rules across all the different facets, not just like
S1: can an application run, but these, these, uh, applications normally
S1: talk to these, uh, these servers over here should be
S1: accessed by these finance servers or whatever, and then intelligently
S1: build like this profile of different allows and disallows.
S2: To kind of do that already. So the learning mode
S2: and allow listing is effectively doing that. We learn quite
S2: a bit of ring fencing as well. So if applications
S2: need to go into particular locations or access particular internet locations,
S2: we learn that stuff already. I mean, it is your
S2: allow list is effectively that we also and I should
S2: have mentioned this, but we do also have what we
S2: call the unified audit, whereas which is visibility over everything
S2: that's happening on machines. So everything that runs, everything that
S2: can't run, everything that's allowed, everything that's denied network traffic
S2: in and out. So we have complete visibility over what
S2: is happening and also what's not happening in the environments
S2: that that are managed with Docker. And one thing I
S2: should mention, and a lot of what we've spoken about
S2: thus far has been effectively controlled. So as we take
S2: a different approach, we're not about detecting, we're not well, sorry,
S2: we're not primarily about detecting. We are primarily about controls
S2: or about environment effectively as unfriendly as possible to an
S2: attacker while allowing users to do what they need to do.
S2: So users and you know, you have to think or
S2: you have to consider that probably 98% of users do
S2: the same things with the same software every single day. Yep.
S2: I mean, they use office. They use Acrobat. They use
S2: video conferencing team zoom browsers. Obviously, you know, windows operating system, etc.
S2: maybe a line of business application or two. But fundamentally
S2: what we're doing is we're just setting guardrails around that.
S2: We're saying, look, operate within these guardrails and you're not
S2: even going to know we're here. Okay. So it's not
S2: going to affect or get in the way of the vast,
S2: vast majority of users. But back to what you mentioned
S2: a second ago. The other thing that we do as
S2: well as control. So we for many years a lot
S2: of organizations would run us beside some sort of detection. Okay.
S2: So they might run Threadlocker alongside an EDR for example.
S2: Basically Threadlocker offering the control and the EDR as effectively
S2: as a fallback as a okay, you know, somebody allowed
S2: something wrong they shouldn't have done. Now the EDR steps
S2: in and goes, okay, I'm going to detect that and
S2: hopefully clean it up. So what we've added more recently
S2: is what we call Threadlocker detect, which is a EDR
S2: that is attached to Threadlocker. I mean, it's effectively it's
S2: the same agent, it's the same portal, it's the same
S2: everything that you're using. But the beauty about Threadlocker is
S2: detection platform, which is, as I said, detect. And we
S2: also have MDR is we see not only everything that
S2: we have allowed, but we also see everything that we've denied.
S2: Because the problem is, if you're running Threadlocker alongside another
S2: tool like an EDR, we're blocking most of its source.
S2: We're stopping, you know, remote access tools from running. We're
S2: stopping everything from running at source and very often the
S2: editor that's running alongside us won't even know that happened.
S2: You know what I mean? So yes. Yeah, but Angus
S2: has been blocked from running, so it has nothing to detect.
S2: It has nothing to respond to. So the beauty about
S2: us is we see both sides. We see everything that's
S2: been allowed. We also see everything that's been denied. And
S2: we can alert, detect and respond accordingly. Because the thing
S2: is what the layers of control we mentioned are going
S2: to do is they're going to buy you time, okay.
S2: In the event of a cyber attack, having time where
S2: you know, they're in, but they can't do anything because
S2: they keep on banging their heads against the wall. That
S2: is threatlocker that's going to buy you time, but you
S2: still want to know if something's going on.
S1: Yeah, because they might switch tactics to something else that
S1: that you can't block. And you get all that time
S1: if you're seeing it beforehand.
S2: This is exactly the point. So basically if you know
S2: there's a deep connection coming in or if an event
S2: log gets cleared on a server, if there's any other of,
S2: you know, hundreds of indicators of compromise. We see them
S2: and with our detection platform and our EDR sorry, on
S2: our end or basically which is human beings sitting outside
S2: the office here basically looking at these alerts or customers,
S2: but basically they will say or it will tell you
S2: something is happening, whether or not some other EDR might
S2: even know it's going on, which very often they won't.
S2: But look, the point is we see detection as being
S2: complementary to those other layers of protection I mentioned. We
S2: don't see it like for us, detection is not the
S2: entire game for.
S1: Yeah, I've always said I mean probably maybe it's NIST
S1: or something, but I've always said, um, prevent detect respond
S1: in that order. Right. So if you're zero trust prevent
S1: is the number one. But you also want to have
S1: that visibility. So it's nice you have that that that function.
S1: What about respond. Is there any anything you have there
S1: about I guess firing off an alert would be one.
S2: Well, absolutely. We can do a lot of different things
S2: So we can we make people aware, I suppose is
S2: the first thing. So, you know, log a ticket, send
S2: an email, pick up the phone, which is what our
S2: entire team will do depending on a customer's defined playbook
S2: or runbook. And we can take automatic remediating actions. So
S2: like if we see something happening on a machine we
S2: can not only. And I know a lot of solutions
S2: allow you to isolate machines from network. And isolation is
S2: all very well and good and we offer isolation as well.
S2: But the problem is if you isolate a server that's
S2: running ransomware, you're going to do nothing other than allow
S2: that ransomware to continue to run and also have server
S2: isolated from anything it needs to talk to. So we
S2: have what we call lockdown mode. And lockdown mode is
S2: like isolation on steroids basically. So it both blocks everything
S2: from running. And when I say everything, I mean everything
S2: large parts of windows as well. It blocks even, you know,
S2: otherwise good applications, things like Chrome, Internet Explorer, they're all
S2: going to get blocked from running. You can't run office,
S2: you can't run PowerShell, you can't run command prompt effectively.
S2: You can't run anything on the machine, but it also
S2: locks on blocks down access to storage. So any protected
S2: storage location, we say okay. Block all reads and writes
S2: to that. So your your ransomware may be running, but
S2: it's not going to be able to encrypt my data.
S2: But it also and the third thing we do on
S2: top of that is we also isolate from the network.
S2: So if there's incoming outgoing connections, we're going to kill
S2: those connections. That machine is going to stay isolated. So
S2: as I said, lockdown mode is like a much more
S2: extreme version of isolation, but it's one that will actually
S2: stop ransomware in its tracks, whereas isolation is just going
S2: to allow it to continue on its own. And but
S2: we do also have remediation facilities. So basically you can
S2: if a customer wants, we have a separate service called Remediator,
S2: which effectively is a PowerShell access to the machine, which
S2: we can get in and stop things, delete things, do
S2: whatever the customer wants. Again, it's all very much based
S2: on the customer's requirements.
S3: Okay, so.
S1: You mentioned the people out there watching. Um, so is
S1: the MSP service. Is that part of the endpoint product
S1: or is like, is that an add on like that
S1: monitoring piece? How tied into it the product is that?
S2: Oh, it's completely integrated. But we've got we've effectively on
S2: top of the the products as in the software as
S2: a service that you pay for. We do have a
S2: couple of additional services. One is what we call cyber
S2: hero approvals, which is if you don't want the hassle
S2: of dealing with your users, sending requests through and saying
S2: they want to run this thing and they want to
S2: run that thing, you can effectively outsource that to us,
S2: where we'll basically approve or deny applications requests according to
S2: your specific instructions. So you might say look them remote
S2: access tools. Bad. Don't allow them video conferencing video conferencing tools. Yes.
S2: And but you know that's a set of instructions effectively
S2: for us to follow. And we will follow them to
S2: the letter. So somebody tries to run a remote access tool,
S2: we're going to block it if somebody tries to run
S2: a video conferencing tool will permit it for you or
S2: on your behalf. So that's the cyber hero approvals. We
S2: also have eMDR, which is again tied to the ADR,
S2: tied to the detection, which is human beings sitting outside
S2: here watching alerts, investigating when something is going on and
S2: if needs be, alerting customers or as I said, taking
S2: remediating action.
S3: Yeah.
S1: Fantastic. Well, this is this is super interesting. I actually
S1: have an idea I want to ask you about, but
S1: I think it might, uh, take us into a whole
S1: separate episode. I'm actually curious about if we were to
S1: break down the different portions of a ransomware attack, like. So.
S1: It's got to get in. It's got to do the following.
S1: It wants to spread. I would like to match that
S1: with the different blocking functionality and the detection functionality of
S1: the tool. So it's like this particular portion gets blocked
S1: by this portion. If it gets through there, which it wouldn't,
S1: but if it somehow did, it would get stopped here
S1: and then stopped at the internet. So it's like, here's
S1: three different ways or here's five different ways. It would
S1: be stopped.
S3: Yeah.
S2: Absolutely. And look, there's so many different examples of that.
S2: I mean, you know, we stop very often the initial
S2: access because we're going to stop the network connection coming in.
S2: Even if a network connection comes in, we're going to
S2: probably detect a brute force happening because we can, you know,
S2: detect or fail logons. So even if they do get
S2: that far in, then they're probably going to try and
S2: give themselves persistent access. So they're going to run something
S2: like Anydesk. Well, we're going to block that by default
S2: because blocking things is what we do. Or they might
S2: try and run a reverse shell in PowerShell. Again we're
S2: going to block that because blocking PowerShell from accessing the
S2: internet there's probably about in your average ransomware attack, there's
S2: probably about ten different stages that we would basically step
S2: in and block things. Um, To embody it would be
S2: an interesting exercise and to undertake, but I would suggest
S2: in most attacks there's a lot of different ways that
S2: we we would get in their way.
S3: Yeah.
S1: Interesting. Any new stuff coming out? You should let us
S1: know about.
S2: Um, so the detection eMDR was released this year. We
S2: have recently added Cloud Detect as well. So effectively the
S2: same or similar capabilities as Threatlocker detect but for cloud environments.
S2: So first one we've done is office 365 with the
S2: likes of G suite and others coming soon as well.
S2: So same principle looking for anomalous behavior. I mean, a
S2: lot of the problems are whether you're managing one office
S2: 365 environment or 100 office 365 environments, actually finding somewhere
S2: with all of the information you need and all the
S2: alerts that you want to look at is not always easy. Um,
S2: less Microsoft. but again, allow people to alert themselves on,
S2: you know, suspicious travel and anomalous behavior, forwarding rules being
S2: set up, all those kind of things. Again, in one place,
S2: rather than having to go into 50 different office, 365
S2: tendencies to see what's going on. So Cloud Detect is
S2: probably the newest thing that we've we've added recently, and
S2: it's something that's gaining a lot of interest and a
S2: lot of traction.
S1: Awesome. And where can people learn more about you?
S2: Threatlocker. Com is a good place to start. We are
S2: on all the things we're on, um, Facebook. We're on Twitter.
S2: I refuse to call it X and we're on YouTube.
S2: And if anybody is interested, we do webinars on YouTube
S2: quite often, maybe once or twice a month, and often
S2: entertaining and somewhat or sometimes educational. So have a look
S2: at them as well. We sort of take deep dives into,
S2: you know, different attack vectors. We did, you know, things
S2: about drones and Wi-Fi? Pineapples at one stage that may
S2: have been, may or may not have crashed a drone
S2: into a building here. And but yes, at the risk
S2: of sounding like every YouTuber, my children watch and smash
S2: that subscribe button and check us out.
S3: Awesome.
S1: Well, thanks for your time today. I enjoyed it.
S2: You're very welcome. Daniel, thank you very much.
S3: All right.
S1: Take care.
S3: Bye bye.
S1: Unsupervised learning is produced and edited by Daniel Miessler on
S1: a Neumann U87 AI microphone using Hindenburg. Intro and outro
S1: music is by zombie with a Y. And to get
S1: the text and links from this episode, sign up for
S1: the newsletter version of the show at Daniel miessler.com/newsletter. We'll
S1: see you next time.