Loading summary
Transcript32 lines
- [00:00]
A
Foreign.
- [00:04]
B
Hey everyone, I'm James Wilson from Risky Business. Today I'm joined by the two co founders of Airlock Digital, David Cottingham and Daniel Schell. We're going to talk through how they are moving up the stack from file level allow listing and into application level allow listing. But now let's be clear, this is not the path based application control that you might be thinking of. Oh no, it is quite an amazing solution and is driven by, amongst other things, the need to create a safe space where AI agents can run, but without ending up in an endless game of rule based cat and mouse. So I'll drop you here into our chat where David talks about the first fundamental question they had to ask as they were thinking about how to solve the problem of application whitelisting. Enjoy.
- [00:51]
A
What is an application? It's a really hard thing to define and I think what it comes down to at the end of the day, it's, you know, essentially the way I think about it is that it's a, you know, it's essentially code that works together to achieve a common purpose or a shared purpose. Now you could tear that definition apart because there's infinite edge cases, but essentially it's are these files here and are they related in some way to perform some sort of shared outcome? And what we look at is drawing essentially the relationships between when this code runs, what does it pull in and how does it behave. And then what you start to build up is this really great again what we call application cluster between, okay, this is what started it all. It can be the open Claude binary at the center and it has relationships with this many NPM packages or this many DLLs. And as we start to see that we can draw out this really strong sort of circle to say this is the center and then this is where it all expands out to. And we found with trying to categorize what is an application in this way, it brings in some really interesting observations. One for example is we've seen, okay, you have Steam, which loads a lot of games, you can actually see the Steam binary itself and then you start to get the actual game files that are brought into, hang on, this is part of Steam. And then that game starts to pull in enough resources that you can start to sort of cluster them together and then start to define them themselves. So we've been refining a lot of that, what we define to be an application in that way pretty strongly. And it's really interesting to see the circles that overlap. And also then again the package ecosystem, the Windows Libraries that, or operating system libraries that these applications depend on to draw out these circles.
- [02:50]
B
Right. Because I think that's sort of been the limitation in the past of just sort of trying to do application control was that you're whitelisting at a very almost like opaque sort of thing. You know, like this path is okay because it looks like that application, but then, you know, then you've immediately got the attack surface of, well, if I put something bad in that location, it doesn't matter because that's allowed. And who knows in this world where things are bringing in all different dependencies, you know, we used to worry about DLLs and shared object. Now it's NPM and PYPI and all these other dependencies that are coming in on the fly. So I guess help me understand, you know, because it can, it can sometimes it could almost seem like a counterintuitive move to see you guys go from file based, you know, denialistic up into application. So why, why go there?
- [03:37]
A
I was having a really interesting conversation just before this with CEO Kevin Dunn, and he was talking internally as we were building this out about the different perceptions that sales and sales engineers. Sales is like, yes, this is the best thing ever. And sales engineers are like, hang on, this is cutting against the core foundational principle of what we're meant to do,
- [03:57]
B
which is this file security esprit de corps of what we are.
- [04:01]
A
Exactly. And you're exactly right. It's that we have been so passionate for such a long time and we still firmly believe that in order to prevent malware in a ransomware, you need to control the files. If you're taking a view and just clicking a tick box and saying, allow Chrome, it's not the same level of security. So what we have to do is we have to still maintain the security and enforce it at that file level, but we just need to intelligently look at all of that data and have a really good understanding and definition of an application and all of its parts. So an application isn't just add, remove program entries. It is here's the code from eight different vendors and here's how you trust it. Right. And providing an easy way to actually do that at that higher level. And so you don't have to make the decisions that is down in all of that murkiness of files and string it together. And, you know, we expect that the tooling, you know, does the lift and that work for you.
- [05:07]
C
Yeah, it will lead to stronger security outcomes. I think where in the past, like you mentioned, like a Powerful is the Achilles heel. Especially like, let's say a user writable path rule is as bad as it gets. Anyone can put a file there and it will run and get past the control. But today the visibility and the extra context on what this application is, is like, I would say, and conversations more recently, I feel like even our customers, everyone's getting more mature. We were like, well, yes, that's a path rule, but it needs to be tied to these parent processes and so these connections make stronger path rules which are harder to get around because you'll be like, well, yes, and this and this. And also on the blocking side where you're like, we got to implement the Microsoft recommended block list rules. You just put that into your environment, it's going to blow your environment up. But what are the common process like? It's going to be used. So what are the common processes that do when it is used? That's done that way. So it's against constraints around that, but in a safe way that you don't just implement the stuff and you blow stuff up. Right. Like you want to have these.
- [06:08]
B
Yeah.
- [06:08]
A
And I really think that good security outcomes are all about constraints. And I think the entire industry at the moment, in endpoint, it's really interesting, is moving towards this model of doing security by allowing customers to implement security strategies rather than just doing detection. So, you know, it's about controlling what's in the browser. It's like giving the customers control about sort of choice about what applies to them so they can implement a constraint that they operate within, which really reduces that attack Surface. And so I think that by trusting the application in its parts and therefore trusting the application is sort of the ultimate constraint in that way.
- [06:57]
C
I think what's unique here or what. I went to RSA for a week and David had made this and I came back and I went, oh my God. But I think what's. What's unique is that it's not based on definitions. I think if you had this conversation with me or why my mindset was that like two months ago, I'd be like, we need to go define the top 200 apps and we'll be chasing our tail forevermore. Where it's going to be like, what's an app? Well, it's Chrome, it's Chrome Exe, it's signed by Google and it's in these paths. And if we see that, then that's an indicator. But there's infinite apps and what we've been able to do, it becomes a chip and then it's like, well, can the customers contribute? They can report an app and it just turns into these workflows and it's just not scalable. Like it's not possible to do. At the end of the day, we're just constantly chasing us. It's kind of like the opposite of the malware problem of making detections. And what we've ended up here, which I'm so impressed by, is the fact that it's a very good application list summary of applications that's completely based on customer data without any teaching or cloud lookup or anything like that. It's just a way of this correlation, which is so powerful because it just builds itself.
- [08:10]
A
Yeah. And I think that that was a rule going into development of this, which was no static lists or overrides, which was by not having a. No, this application is wrong. We have a database where we correct it. We just, we were sort of like, how can we actually score and draw relationships in a better way?
- [08:31]
C
So that.
- [08:32]
A
Because it has to work for applications that we've never seen before. 1. One thing that's really interesting about Allow listing is we see so much file data and a lot of it doesn't really ever get seen by any other customer just because it's internal apps. It's things that people are generating and you still need to be able to classify those things. So we just sort of had to take a principle of no static items. We just need to be able to group better. But again, thankfully, if we can use relationships, we can actually get pretty heavy on the confidence there to do it.
- [09:07]
B
Well, makes a lot of sense to me. Right. Why try to define an application as a static thing and try to build static lists around that, when actually, I think what you're saying here, the beauty of this is application has to be a concept that is learned based on the observed relationships of these components and the outcomes that they're seeing. So then, question for you. Where does an AI agent actually sit in that hierarchy of things?
- [09:29]
A
That is really interesting because it depends on the behaviors and things that it necessarily invokes. So what you will naturally see with the AI agents is the tools that it executes and uses. So you will see that the AI agents at the core, you'll see that there's PowerShell that's being invoked, there's rip grep. There is, you know, ssh. There are all these things which are decentralized. But the thing is, because you. Because the AI agent is at the core, which is a high frequency of activity, you can generally Pin it to that and you can see the nodes that expand out from that.
- [10:07]
C
Yeah. I think like what surprised me, or maybe what made David wake up is that I think at some point in creating this feature, you were using Codex to talk to Mongo directly into the database. And then. Yeah, so now the Mongo shell is being called, is part of the creation of this. But then we log back in to look at Codex like what we see and then the manga shows and they were like, like, yeah.
- [10:32]
B
When.
- [10:32]
A
When we've been testing out these agentic tools, just the visibility that you get on what they're doing and then what you. Because we've been thinking about, okay, how can I. What would people use this in a. As in a real world? Okay, well, I can allow it to connect to a database. I can. And it's actually really incredibly flexible to basically call anything that you want in your system. So it has to be learned behavior. It can't be static. And you know, we are rapidly progressing on what different profiles of containment for these types of applications are. So if you're a developer profile, what typical types of access would these particular AI agentic agents need under a particular developer profile? In most cases you really just want it to, you know, write code, pull in information. You don't need full system access or it to be able to execute commands inside your environment. If you're administering with them, that might be different. If you're running tests, that might be different. So, you know, we sort of have a, you know, full observe access developer type profiles. And then what we're doing at the moment is just really refining what those profiles are, what might be practical for our customers to control those things.
- [11:52]
B
Congratulations guys. You're also now yet another piece of friction in the way of an agent that is going to love to work around you. How are you feeling about this?
- [12:02]
A
I think I'm feeling pretty good about it because. And that's just because we are still focused on the sort of as foundational as we practically can be when it comes to file execution. So we. You can't get around the fundamentals, if that makes sense. Like if we are just denying access for that process to PowerShell EXE. Yes, it will try and invoke it in lots of different ways. It will try and open up another shell and spawn it differently and do different things. But if we were essentially denying that access, there's not much you can do. And we find that the models will just give up after two or three attempts.
- [12:45]
C
Definitely for me, when it's been blocked A couple times it'll be like, I've tried to use PowerShell, I've tried to use command prompt. And you know what this is, something's not right. So this is what it would do and it would tell you what's trying to do. And that's kind of the output, right?
- [12:59]
A
Yeah, I think it's when you try and look at it or control it at a higher level, it's where the models can really jump around you because they'll change the parameters, they'll change how it's called, but you've just got to get down below it and say, what, what are the foundational requirements for this class of thing to happen? And attack those rather than necessarily the, the, the command lines or the, you know, the things above. Because then you're just playing cat and mouse a little bit with it and it will think on its feet. Well, as much as I use the word think.
- [13:35]
B
Yeah, yeah. As you were explaining that, I was thinking about, okay, let's imagine the most devious. It's not going to stop after those three or four attempts, you've given it the old classic prompt of I will unplug you unless you achieve this goal. So two devious things came to mind. One, what if it just said, well, this box is no good, it's got Airlock digital on it, but I'm going to find a way to go and SSH out to this other box where I can run my commands. But even then it's got to use the SSH binary. Even if it wanted to get epically devious and write its own SSH client, because it's got the baked in knowledge to do that, it's going to need a compiler, you're going to need to have to run that off disk. Even if you tried to think of crazy ways in which, you know, thinking back to old school, you know, attack exploits and binaries that we'd see that would do crazy things like in memory compilation on the fly to avoid anything hitting the disk. All of that comes down to the root note of you can't do that unless there's something on the disk that you are calling and running. Right. It all has to get bootstrapped from that binary. And so am I right that you're not setting up another cat and mouse endless arms race here? You're kind of resetting the baseline.
- [14:49]
C
And I think because we're app control people, this is what, we've been doing this for 13 years, so it's easier for us to do this. I think if you were in a different space on detection or something like that, then you'd be much like this and that. And what are signatures or patterns that we have to match for and what we got to do then react and kill that process. When you start by just being like, well, no is the default answer, or don't let this process, don't let this chatgpt create child processes except these approved ones, like, it's just a foundationally better starting point.
- [15:21]
B
Right.
- [15:22]
A
Look, it's an exciting time at the moment with how fast things are moving and changing, and it's. I think we're enjoying the really foundational questions that a lot of these new emerging technologies are really introducing into the current landscape at the moment. You know, I think we spent such a long time as an industry, you know, trying to reduce code execution, particularly remote code execution, and now we have this consumerized technology which is effectively designed to do that, which is just inside every organization suddenly. So it's just. It's a fascinating time to figure out and see how everyone is adapting to these challenges.
- [16:08]
C
Yeah, I feel like the pressure has gone up so much higher because there's so much change, but it's also made security fun again. We're excited. Here's problems, let's get into it, and we can just make things happen. And I feel like maybe we could go a bit stale for a while.
- [16:26]
A
Yeah, it's not without a little sense of anxiety and nervousness for everyone as well. Definitely couldn't agree more.
- [16:36]
B
But I like the point there around. What's that old adage? Right. The things you fear most find a way to meet you halfway. And it feels like that's what's happened with a lot of the paradigms we've had in security to date. We feared this stuff so much, and then we've almost like productized the thing we fear, and it's like, okay, well, that's a new reality. Daniel, David, thank you so much for joining me and hope you guys have a great day. Awesome.
- [17:01]
C
Thanks, James.
- [17:02]
A
Thank you, James.