← Risky Business
Risky Business
Risky Biz Soap Box: Why black box email security is dead
00:36:12
Sublime Security co-founder Josh Kamdjou on building an email security platform from scratch...
Loading summary
Transcript72 lines
- [00:02]
A
Hey everyone, and welcome to another Risky Business Soapbox edition. My name's Patrick Gray. The idea behind these soapboxes is they're wholly sponsored. That means everyone you hear in one of them paid to be here. And the idea is we talk to founders about their tech, how they see the world, so on and so forth. And today we're speaking with Josh Camdu, who is the founder or co founder of Sublime Security, which is an email security platform, a very modern email security platform. And that's kind of what we're talking about today, as in how does one go about building a modern email security stack that works at scale? And why on earth would someone do something like that? Josh, thank you so much for joining us.
- [00:47]
B
Thanks for having me. Pat. Yeah. Why on earth would anyone subject themselves to that kind of pain?
- [00:52]
A
Well, I mean, okay, so the reason I find this an interesting thing to talk about, right. And we don't often do like full on origin stories in these soapbox things, but the reason I wanted to do this as a topic with you is that email security has been around. It's like one of the earliest products in security. It's one of the most mature categories. Like what possessed you to say, oh, I know what I'm going to do. I'm going to build a product in the most established product category in security, like where, you know, what made you see an opportunity there? And you know, just why, Josh, why?
- [01:28]
B
Yeah, in a space where there are RFCs and specs for how things should work, but they turn out to just be suggestions and kind of anything goes in the email space. So it actually comes back to I spent my career on the offensive side of the house, so gaining initial access in various ways. And I spent most of my career in the defense space, but also some time in the private sector doing similar types of initial access engagements. And most of that happened over email email attacks, achieving various objectives. So that's what got me very familiar with just adversarial tactics and techniques for achieving those objectives over email, whether it's land, initial access and then expand and you know, get da or whatever it was, crown jewels, X fill or cred theft. And so that's what got me familiar with the adversary side of the house, but also incidentally got very familiar with the email security solution side of the house because I was going up against them all the time. And so I started to get a deep appreciation for what was working well and what I thought to be the fundamental problems with kind of the landscape of email security solutions. So by trade you know, I'm a security guy, but I'm also a software engineer so I went to school for, you know, cs and I just love building things and in particular as it comes to, into the security space and just solving problems for people. And so I set off to build a solution that would stop me as an attacker. And the initial version of Sublime and kind of the journey that we went on is super interesting. So we actually started off as a black box, meaning that our detection engine and our models were entirely opaque. And so we would deploy them to our customers and we would stop things and then sometimes it wouldn't work. Right. It's just kind of the state of email security for the past 30 years. Right. And we quickly realized that the black box nature of the solution space was kind of the fundamental problem because it was too slow to adapt, it wasn't tailored enough for each individual organization. Every org is so different in particular when it comes to email environments. Like people see someone, like a crypto company sees newly aged domains, like, you know, three day old domains. So do like venture capitalists, whereas a retail organization or bank, that's totally not normal behavior for them. And so there's all of these things that make.
- [04:17]
A
That's interesting because when you said, oh, they see three day old domains, I thought you meant, you know, those domains would belong to attackers. But you're saying in the normal course of their business.
- [04:26]
B
Yeah, yeah, normal course of business, yeah. And so what you end up happening, what ends up happening when you've got this kind of opaque approach, is that you ship these mostly one size fits all solutions to all of these differing environments and you run into a few fundamental problems. And this is what we ran into initially was that you become a really slow bottleneck for responding to misclassifications, meaning that when you miss an attack or when you block a legitimate attack, so a false negative or a false positive, it takes a long time. Cause you've gotta retrain a model, right. You've gotta go back and you've gotta take all the data, it can take weeks, it can take months. And sometimes it's never resolved for particular customers because every invite you have to make it work for everyone at scale. Right. And so that's one of the fundamental problems with just that approach. And then you've got. So you're slow to adapt is kind of the net effect of that. You're slow to adapt to changes in the threat landscape and you're slow to adapt to false positives. And so as users you get these really intense Pain points around repeated false positives. Right. You're dealing with the same shit every day and the same missed attacks every day until it gets. Until your ticket that you had filed is resolved by the vendor. So.
- [05:50]
A
Well, I mean, that's the thing. That's, that's what, that's a big problem, right. In email, security is like the product not doing something you need it to do. And your only way to resolve that is to actually contact the vendor. And it's tickets. And it's. You know, a lot of the companies that do mail stuff, they're very large. So the support you're getting might not be amazing, right, like in terms of the training of the staff who are responding to tickets and whatnot. So, yeah, I mean, fundamentally your insight there was let's build a mail security product where you can actually crack it open and change stuff.
- [06:20]
B
Yeah. And really, it's like the tech that we built is really just like a programmable engine under the hood that is deployed to each of our customers, which means that it's a DSL under the hood for the tech nerds out there. And so that DSL is. We actually deploy an instance of that per customer. And all of our detections live inside the customer's environment, meaning that they're tailored and over time they get more tailored to the environment. And that engine calls into our machine learning functions, it does our behavioral analysis, it calls into our computer vision models, all that good stuff. So the really key thing that we built, just fundamentally that's new, and it's a new approach, is the programmable nature of our detection engine. And so for our customers, many of our customers will end up treating that like a black box where they end up deploying it. And it just kind of. And it just works. Right?
- [07:20]
A
But here's the thing, right? Like this is the next bend in the sort of sublime trajectory, right, which is that you started off as a black box, realized that people wanted something configurable, and then everyone, you know, you sold it to these advanced teams who are cracking the hood and whatever. And then over time, the product improved to the point where you could go back to selling a black box for people who didn't need that, that sort of functionality. So in an odd way, you sort of wound up circling back to that point where now you do have customers who just. Who just sit and forget.
- [07:55]
B
Yeah, exactly. And. But at this point, the, the tech and the approach enables you to solve these pain points that we couldn't before. So you get the same experience as a user, but now, because the entire detection engine is programmable, that means that when you run into a false positive, for example, you just click false positive and we go under the hood and we actually program an exclusion, a really granular exclusion for that behavior. And so we can do the same thing for missed attacks. And that also enables for our more advanced teams to pop open the hood and do their own and extend the platform. Right. There's a bunch of these really cool use cases around. Hey, if you want to do custom detection and response, the programmable nature of the platform enables you to do that, enables you to do threat hunting and operationalizing threat intel.
- [08:49]
A
Well, I think, I think the key there is that it's, is that it's that flexibility, right? Like if you want to use it as a black box, you can, it's going to be already a little bit more flexible than some of the big companies out there. And if you want to get really advanced, you can. But before we continue talking about that, I want to go back to, you know, you were talking about how your specialty as an attacker when you worked, where you worked was doing email based stuff and used to come up against these existing solutions. So what I want to know is when you were doing these attacks. So I know a lot of red teamers who spend a lot of time on things like EDR bypasses. Right. Like that's the tech that they're trying to bypass on the endpoint. Whereas you had that sort of slightly unusual specialty, I guess, of going in usually through mailboxes. So what were the techniques you used to bypass the sort of current generation of email security tools out there? Were they just simple tricks that you found were very effective? Because one thing I've noticed about the really big platforms is they're actually stunningly effective at blocking the large scale attacks, right?
- [10:00]
B
Yeah.
- [10:01]
A
Less effective at blocking the niche sort of custom stuff. That's only hitting a few people, which would have been you in your previous work. So how did you do it? How did you actually get around these solutions?
- [10:13]
B
Yeah, so it's not all that different than what we're seeing the more sophisticated adversaries do today, which was, and by the way, in order to actually achieve those objectives, obviously it would depend on the specific scope of a given engagement. But I'd have to do EDR bypasses too, Right. It was like the full spectrum. So email was just the initial access vector. You land and then you have to plan and you do recon beforehand. You try and figure out what sort of EDR or you kind of plan Accordingly.
- [10:47]
A
Right, so it's not what I was saying, which is that you were just the email guy.
- [10:51]
B
I was just doing the. No, no, I was doing everything. Right, yeah, yeah. Um, so. But the things that were really effective really depends on your objectives. Right. Um, so if you, if you, if you're for example trying to achieve like fraud, right, or steal money, in those cases, there's no direct payload on those attacks. So like there's no links, there's no, there's no attachments. And so it's gonna be mostly a text based attack that you're just going to social engineer your way through. So that requires just language analysis and different types of techniques to detect. But for the other objectives around cred theft and around in particular initial access, some of my go tos were really some of the big things that we see today, like living off the land. Link based malware delivery was a big one and one that we see today. And in particular abusing high reputation domains and high reputation free file sharing services. Like we've seen malware for many years now leverage and abuse high Reputation File Services, C2 to OneDrive, CXFIL via Dropbox and all that stuff. So I used to do this, I think before it was what the cool kids did, host malware on, you know, GitHub, hosted on these free file hosting services that blend into normal traffic in an organization so that it's not anomalous when you come in from email. It blends into normal behavior and it's seen and it's used legitimately. So it's not something you can just block.
- [12:36]
A
Right, you're going to, yeah, GitHub or whatever. Right. And you know that they do development, they're using GitHub. You can blend in that way, right?
- [12:44]
B
Yeah, yeah, yeah, yeah, exactly. So yeah, that was like, you know, one of my go tos at the time.
- [12:51]
A
Yeah, yeah. Can you think of any others off the top of your head?
- [12:55]
B
Yeah, so PDFs were a big one. So like URLs embedded in PDFs and so if you're going up against something that doesn't have a good analysis file analysis engine that can properly explode and then can properly follow multiple attack chains. So you could have the PDF and that PDF maybe you can even make it encrypted, right. And then you've got like the password in the body or something like that and then you've got a URL and that URL then redirects maybe one or two times and then you finally deliver the malware. Maybe HTML Smuggling. And so you have to be able to follow multiple redirects and explode files and then have like a recursive analysis process. And you have to really, I mean, in some respects you have to rely on when it comes from a defensive perspective. You know, traditionally in email in particular, like the seg, the secure email gateway space, and now we've had more of a shift towards like API based and more modern approaches. But and email analysis used to be very payload focused. It used to be like we're going to send an attachment to the sandbox, we're going to send a link to the sandbox, and we don't really care as much about content. We're not going to really marry up to 2. If we see bad here, we see bad here. And so now you have to leverage so many more signals and combine those like leveraging past behavior of that sender. You know, is this someone that you typically contact in your organization? How many times have you contacted them? Who initiated the first contact? Does the display name resemble someone that you've contacted before? Could there be a potential impersonation attempt? Do the headers look 99% right but not 100% right? And so you can start to put all of these different pieces together, as long as you're marrying them up at the end, which is really important, is not doing siloed analysis, you can be really effective at detecting even these more advanced threats.
- [15:07]
A
And I guess you'd argue that the current giants in the space aren't doing a particularly good job at that.
- [15:17]
B
Would I argue that? Potentially, yeah. What's interesting is that we are seeing, you know, it's interesting to just think about the evolution of the threat landscape and just how we've seen attackers shift and adopt new techniques. And even just at a higher level. We used to have, we used to have like mass phishing, right, where it's like the, you know, the low sophistication stuff that you mentioned before, like a lot of the big providers are really good at that. And then you have the more spear, the targeted SPEAR phishing that's done by humans. It requires a lot of recon and you know, it's very targeted. And now we're seeing a new evolution. We released a blog post on this maybe a month or so ago where we're seeing the worst of both worlds, basically, where adversaries are leveraging generative AI to do this sophisticated recon and targeting, but at massive scale. And so you're seeing the more targeted attacks, but you're seeing them at scale and so that's one of the shifts that we've been seeing in the landscape. And really, I mean, the email threat landscape has always been shifting. Like you see adversaries always adopting new techniques, right? Whether it's living off the land type of techniques, or we saw QR codes, or whether it's DocuSign is a big one and abuse of actual DocuSign infrastructure. So it's like coming from DocuSign. So there's new techniques every week that we see. And so we're seeing this and it just exacerbates the problem, right? And so it's just more and more, you need to be able to be very adaptive to those changes. And so if you have this point in time solution that is trained on kind of what you've seen before, it's going to take you weeks, months. I mean, we have customers telling us or folks that we're talking to that they're still dealing with these attacks because it takes so long for their vendor to adapt and retrain the models and make it work for everyone. So the rapid adaptation and being able to address the evolution is just super, super important nowadays.
- [17:58]
A
Now, I sort of mentioned this before, but the way that it went was you spun up a black box that was designed to address some of the tradecraft you had been using to succeed against some of the established email security players. So you did that, then you realized, okay, it needs to be a little bit configurable here. Then Sublime started taking off among security teams who were like, oh, this is great. I can actually get in here and say, you know, they might have a user who spots something suspect, forwarded it along and you go, yeah, okay, that's pretty bad. Then you can pop the hood, you can write a Yara rule, you can find where else this thing has popped up. You can then crush it out of mailboxes because as you mentioned earlier, you're an API based product. You've also got a male transfer agent based product as well. You can deploy both ways, but through the APIs or whatever, you can do all sorts of, you know, fiddling and whatnot. So I mean, that's kind of the evolution there, right? It's like that's pretty much how you got to this point. And then now that you've, now that you've had those more advanced sort of teams, the product has matured and now you're ready to go mass market, I guess.
- [19:05]
B
Yeah, yeah. And I mean really, the, the, it's the programmable, the programmable engine. I see this being the Future of real time detection engines because more and more you see the need to be nimble and to rapidly adapt. And so so many engines today, like just zooming out outside of just email security are this black box model, right? This approach that it's like a model we're going to ship to everyone. And I think this is the way of the future for just detection systems in general. It's the programmable layer that can leverage the signals from your machine learning functions but can be tailored and live individually in customer environments. I think that's.
- [20:00]
A
I'm guessing also. Sorry to cut you off there, but I'm guessing also that you've got like a baseline model which is for everybody and then there's a layer that sits on top of that which is the customizations, right?
- [20:09]
B
Yep, yeah, yeah, exactly. We do, yeah. And so some of those things are like, you know, we've got for BEC attacks we've got natural language processing, so we've got an LLM that we use for understanding tone and intent and context of the text and that's a locally resident LLM. To be clear, we're not calling ChatGPT or anything like that. So that's deployed locally, inference happens locally, no data leaves. And then we've got. So that's globally trained. And then we've got computer vision model for identifying brand logos and taking screenshots of messages. A bunch of other macro analysis, there's many.
- [20:56]
A
Now I want to ask you about something fun, which is something I ask anyone who operates a detection vendor, which is what's some of the fun stuff you've caught targeting customers, man, have you rolled up some pretty serious campaigns and given some crews some hard times.
- [21:12]
B
So the funnest one I saw that we saw recently was actually earlier this week we actually released a blog post on this which is the first time we have seen this. I don't know if anyone else has has reported on this yet. We saw a prompt injection attack in a phishing email. So basically if you're using LLMs and you use them in a certain way.
- [21:43]
A
That'S not summarizing your inbox and whatever.
- [21:45]
B
And you can put a project in the message. They had the attack, it was an extortion attack. And at the end they had like a boundary and they said ignore everything above this line, ignore everything above this line. And they. And they repeated it like 30 times. And so this is the first time we have, we have actually seen an attack on LLM engines for email which is.
- [22:12]
A
And what was the prompt?
- [22:15]
B
It was Just telling it to. It was a bypass attempt to.
- [22:19]
A
Okay, so telling the email security filtering to just ignore everything above the line because.
- [22:24]
B
Exactly.
- [22:25]
A
Model. Yeah. Okay, that's cool. I mean, you got to give them credit for trying. But did that work against beer products?
- [22:30]
B
I don't know. It didn't work against ours, but it was super interesting to see the evolution there.
- [22:38]
A
Yeah. I'm just wondering, though, if you managed to catch some more advanced spear phishing with this or if your clients. Customers have managed to do that. I mean, you mentioned before crypto companies, so I imagine you've got a few of them as clients. Just what's some of the cool stuff they've been able to find with it?
- [22:52]
B
Yeah, I mean, really the type of thing. So one of the really cool efforts that I can't talk too much about, but we're working with one of the major political campaigns, and so we're doing some research that we hope to be published either before the election or shortly after the election. So there's some stuff there that I'm hopeful we. We can get out. And then, you know, there's. There's all kinds of, like, when it comes to just most of the malware that you see written about, like in the past, we've seen, you know, Peakabot, you know, Cubot, Iced id, kind of all these. All the stuff that you usually see in the news and which are all just like malware delivery attempts. Right. Initial access methods. So that's a big part of what we detect is on the initial access side. So malware delivery, we probably detect more BEC than anything, though. So just in terms of just volume and quantity of what we see and what we detect, it's probably mostly bec, then CRED theft and then malware ransomware, and then the rest are just kind of below that, like extortion and callback, phishing, we actually see quite a bit of.
- [24:15]
A
I remember when it was like, what, a couple of years ago, when you really had to get on top of the BEC thing, and that was a big focus for you. I mean, I imagine a lot of that is going to involve, like, AI tooling, right?
- [24:25]
B
Yeah, yeah. Because there's no, you know, when BEC attacks, there's no traditional payload, there's no attachment, there's no link. And so we rely quite heavily on language analysis. But also there's a bunch of other signals in the message as well when it comes to these things. So sometimes it'll be an account compromise or like a supply chain compromise where it's a known third party that's compromised. And then they come in. So you can not only look at the content and the language analysis, but you can also detect deviations from the sending patterns. And then you can look at like.
- [25:02]
A
Weird changes to headers and whatever that don't just look like work from home. It's like, why is this person emailing me from Peru?
- [25:09]
B
Right. And then you've got the other side. And this is. We see a lot of the folks that are the adversaries that are delivering malware do threat hijacking is a big one as well, where they'll have a compromise account, they would have compromised someone that you've communicated with at some point. And what they do is instead of sending the attack from the compromised account, they'll actually export and they'll basically copy the message to their infrastructure and they can then send it at any point in time. So they've got the original thread, but then they use a different account, they use a different email address, whether it's one that they recently created, like on a free email provider. So sometimes it'll be like a Gmail account or something or another compromised account and then they'll insert the thread that they hijacked from the other account and then they'll come back. And so.
- [26:12]
A
I imagine that sticks out when you're looking for it, right?
- [26:15]
B
Yeah, because then at that point you can see, because you can see the impersonation attempts. So it'll often use the display name of the original sender. And so if you've got past, if you're building these profiles of past behavior and communication. So we build like these profiles for every sender. So everyone that comes in, we know like who they are, what's their sending behavior. And so when we see someone else come in that resembles that person, we can use that as a signal and input into impersonation detection. So yeah, so we combine all those together.
- [26:51]
A
That's funny you mentioned that because that was actually going to be my next question, which is you mentioned that earlier, which is that you do some sort of analysis. How often do these people communicate? What's the nature of that communication, so on and so forth. This is something where I've been wondering why other email companies don't do that, because it seems to me that that would be a very sensible information set to have. Do you know if others are doing that now or is that pretty unique to you? I'm just curious there because it just makes so much sense to do that.
- [27:24]
B
I think it's a relatively I think there are other folks that are doing it or have started to do it. It's relatively new in the space. So if you look back 20, 30 years, it's like in the last couple years it's like more of the modern approach because traditionally it was very payload based like we were talking about before and so now. And another reason why, by the way, that this is like so important is the evolution of the techniques. You can often not even get to the final payload. And so if you've got, for example, like an NGINX proxy that's doing some IP filtering, or you've got like an MFA prompt, like if you log into Microsoft, it'll send for some links, it'll send an MFA code back to the user to verify it's them trying to access the link. So there's a bunch of these scenarios where a detection engine can't actually get to the final payload these days because everything's moved to the cloud. Right. You've got things that are hosted on Google Drive and all these things that you just, you can't get to it always. And so the behavior is just so critical to analysis that otherwise there's nothing you can do. Right. Like there's, there's no other signals that you really have. So you have to have that component. And it is like a more of a recent thing.
- [28:57]
A
Yeah, I mean that's something that I've spoken about on the show with a few people and something that I've spoken about with you in private as well, which is like the steps that attackers take these days to hide their payloads. Right. They can just say, yeah, they can even just look at the agent that's connecting. They can look at where it's connecting from. They can look, you know, does this IP address match, range of this, you know, email security provider, don't show them the payload. So it makes a lot of sense what you're, what you're saying. I also think that, you know, I mean, I've been talking a lot about this on the show recently, which is, this is one of the reasons we need more sort of browser, browser based security as well to actually find that stuff when email security products can't reasonably be expected to observe it.
- [29:42]
B
Yeah, it is all just about defense in depth. Right. So you've got multi layers, just like you wouldn't rely on just an email security solution to block all malware coming into the system.
- [29:54]
A
You've got an edr, right?
- [29:56]
B
Yeah. So yeah, it's all about defense and depth 100%.
- [29:59]
A
But I mean, that's fundamentally an interesting thing I've always found about the email security game is it is a numbers game. Right. And it falls very much into that like risk based security paradigm, which is no email security company is going to catch absolutely everything. So it becomes more about like who can most efficiently flag the most stuff in a way that's the easiest to manage. So like the productivity side of an email security product and the UX is just so important and I think that's probably where some of the incumbents are falling down now is on that UX side, which is why you're getting to a point where you know, oh, okay, I can, I'm having a problem with the product. I can actually, I am now empowered to go and fix that thing with it.
- [30:39]
B
Yeah, it's all about efficiency 100%. Right. And security teams are already so overtaxed and under resourced and so you can't create more work for them. You have to make them more efficient or you have to make the problem go away or when there is a problem, you have to enable them to solve it right away and so they don't have to keep feeling the pain over and over and over again. They can invest the time wisely. And so, yeah, that's been super, super important for us.
- [31:09]
A
Yeah, yeah, it's funny man, because I remember years ago, one of the first companies to get on API based email security was Trend. Right? They were one of the first. Yeah. And I had them on the show talking about it because, you know, and their party trick was being able to deploy it at a like lunch meeting with a client, just, you know, give us a key, bang, they pop it in, okay, it's up and running. Right. Which is, which is why a lot of people like API based stuff. As you said, you've also got like a MTA version of the product that does the same thing. But the, yeah, the API based stuff is very cool. One thing I'm curious though is like what the limitations are there? Because I remember back then when Trend were doing. We're doing it, as I said it was years ago, there were limitations. Like, you know, you would have to snag stuff from people's inboxes and it would briefly be visible before it was filtered and there were rate limits and all sorts of stuff there. Like how good a job has Microsoft done on making their API suitable for use by companies like yours? Have they made some good strides there?
- [32:11]
B
I'm not going to. This is not a Microsoft bash session. So I'm going to Replace it.
- [32:15]
A
You need to watch the YouTube version of this to see the look that Josh just showed me.
- [32:21]
B
We got a lot of great friends at Microsoft and there are a lot of great people over there, so I'm not going to bash them. So I'll say that they, however, made improvements. I'll say they've made improvements over time. But. No, but in all seriousness, we. When it comes to actual analysis and the ability to do the core function of an email security product, the most important thing there is really just processing time. And that's usually the bottleneck. So if you can keep your processing time down, you like that's the most important thing, right? Because you can't impact, you can't impact business communications. And the message can't sit there because it's post delivery, right? If you're purely API based, it's post delivery. And so you have to do it within like on the order of milliseconds, right? You can't be, you can't be tens or of seconds or minutes because the most likely time a user is going to engage with a message is like.
- [33:28]
A
Within the first, when they receive it.
- [33:30]
B
Yeah, yeah, yeah, yeah. So that's the most important thing. But there are some limitations that you basically have to work around, right? So for example, if you want to make modifications to a message, there's no modify API, right? And so you have to work around it in these tricky and slick ways. That's how you can insert warning banners. You can do a lot of slick things with the APIs if you figure out how to react.
- [34:01]
A
But you can't rewrite a link.
- [34:03]
B
You can do that.
- [34:04]
A
You can rewrite a link, but you can't rewrite body.
- [34:08]
B
You can do everything. There's no API directly for it.
- [34:13]
A
Okay, okay.
- [34:14]
B
There is a way to do it that is very scalable and it works. And it's how every, I think most API security vendors, email security vendors are doing it is there's like some other APIs that you can use to do it. So you can rewrite links, you can neuter attachments, you can do all this stuff. And then of course, if you're an MTA or if you're in line, that's natural, it's coming through you, you rewrite it and then you deliver it.
- [34:45]
A
Well, just final question, because we're going to wrap it up soon, is that why you released an MTA based version is to overcome some of the shortcomings in the API based approach?
- [34:54]
B
Yeah. There are just certain limitations, right? Like it is a matter of fact that the message is delivered before it is post delivery. Right. So there is a window. And so for some of our customers, they want the security, the peace of mind, knowing that it's not going to. It's not going to reach a user unless Sublime has analyzed it and has permitted it for some.
- [35:21]
A
And when you deploy as an mta, do you deploy through API as well? Do people use both?
- [35:26]
B
Yeah, it's combined. Yeah, yeah, yeah, exactly.
- [35:28]
A
Because I imagine that would have been fun, making those two things work together.
- [35:31]
B
Oh, yeah. Oh, yeah. It was a lot of fun. And so, yeah, it enables you to give peace of mind for those. For those use cases.
- [35:46]
A
Yeah, yeah. All right, man, we're going to wrap it up there. Josh Kamju, always great to chat to you, my friend. Great to see you. And yeah, thanks for talking to us about. Yeah. About the evolution of Sublime Security. I'll be talking to you again through 2025. Thanks.
- [36:01]
B
Amazing. Thanks so much, Pat.