Risky Business - Risky Biz Soap Box: Why black box email security is dead

Episode Date: November 11, 2024

In this edition of the Risky Business Soap Box we’re talking all about email security with Sublime Security co-founder Josh Kamdjou. Email security is one of the oldest product categories in security, but as you’ll hear, Josh thinks the incumbents are just doing it wrong. He joins Risky Business host Patrick Gray for this interview about Sublime’s origin story and its new approach to email security.

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 Kamju, 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. Thanks for having me, Pat. Yeah. Why on earth would anyone subject themselves to that kind of pain? 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, just why Josh, why? 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, in, in the email space. Um, so it actually comes back to, I spent my career on the offensive side of the house. So I'm getting initial access in various ways. And I spent most of my career in the defense space, but also some, 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, you know, land, you know, initial access and then expand and, you know, get DA or whatever it was, crown jewels, exfil or cred theft. And so that's what got me familiar with the adversary

side of the house. But also, incidentally, I 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, I'm a security guy, but I'm also a software engineer. So I went to school for CS and I just love building things. And in particular, as it comes 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, you know, 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 an email environment unique. 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. Yeah, Yeah. And that's normal course of business. Yeah. Yeah. And so what you end up happening, what ends up happening when you've got this kind of opaque, you know, um, approach is that you, you ship these like 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 because you've got to retrain a model, right? You've got to go back

and you've got to 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 you, 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 that was one of the things 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 its 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. Yeah. And, and, and really it's like the, 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. that we built just fundamentally that's 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 um and it just kind of and it just works right well so here's the thing right like this is the next bend uh in the 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 were 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 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 set and forget. Yeah, exactly. But at this point, 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. Well, I think the key there 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 you used to come up against these existing solutions so what i want to know is when you were doing these attacks so 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,

where they're 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? Yeah. 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, you know, how did you do it? How did you actually get around these solutions? Yeah. So it's not all that different than what we're seeing.

We're seeing the more sophisticated adversaries do today, which was like, and by the way, in order to actually like achieve those objectives, obviously it would depend on the specific, you know, 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 know, you do recon beforehand. You try and figure out what sort of EDR or you kind of plan accordingly, right? So it's not, it's not what I was saying, which is that you were just the email guy.

I was just doing the, no, I was doing everything, right? So yeah, yeah. So, but the things that were really effective really depends on your objectives, right? So if you, if you're, if you're, for example, trying to achieve fraud or steal money, in those cases, there's no direct payload on those attacks. So there's no links. There's no attachments. And so it's going to 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, you know, many years now leverage and abuse, you know, like high-reputation file sharing services. Yeah, well, like OneDrive. Like XFIL, C2 to One2 to one drives yeah xville via dropbox and all that stuff right so we i used to do this i think uh before it was before what the cool kids

did um you know 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, from email, it's, it blends into normal behavior and it's seen and it's used legitimately. So it's not something that you can just block, right? You're going to, you're going to hinder. Yeah. GitHub or whatever. Right. And you know that they do development, they're using GitHub. You can blend in that way right yeah yeah yeah exactly um so yeah that was like yes one of my one of my go-tos at at the time yeah yeah what can you think of any others off the top of your head um yeah so pdfs were a big one so like um urls embedded in in pdfs

and so if you're going up against something that doesn't have a good file analysis engine that can properly explode and then can properly follow multiple attack chains, so you could have the PDF in that PDF. You can even make it encrypted, right? And then you've got 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, you know, now we've had more of a shift towards like API based and more modern approaches but an 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 two if we 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. And I guess you'd argue that the current giants in the space aren't doing a particularly good job at that. You know, 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 um attackers shift and adopt new techniques and and even it just at a higher level we used to have we used to have like mass fishing right um where it's like the you know the low sophistication stuff that you mentioned before like a lot of the big providers are uh really good at that and then you have the more spear the targeted spearfishing that's done by humans, it requires a lot of recon and,

um, you know, it's very targeted and now we're seeing a new evolution. We, we released a blog post on this, um, maybe a month or so ago where we're seeing the, the,

the worst of both worlds basically, um, where adversaries are, are leveraging, um, generative AI to do this sophisticated recon and targeting, but at a 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 some of the tradecraft you had been using yeah to to succeed against um you know 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 are 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 a API based product. You've also got a mail 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 had those more advanced sort of teams, the product has matured. And now you're ready to go mass market, I guess. Yeah, yeah. And I mean, really, it's 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 many engines today, 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'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? 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 chat GBT or anything like that. So that's deployed locally.

Inference happens locally. No data leaves. And then, you know, we've got, so that's globally trained. And then we've got computer vision model for identifying like brand logos and, you know, taking screenshots of messages, a bunch of other macro analysis. There's like, there's many. Now I want to ask you about something fun, which is something I ask anyone who operates a, you know, detection vendor, which is what's some of the fun stuff you've caught? Oh man.

Targeting your customers. Man, have you rolled up some pretty serious campaigns and given some crews some hard times? So the funnest one 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 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 that's not- To summarize your inbox and whatever and you can put a summary yeah yeah or yeah yeah so in the message they had 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 actually seen an attack on LLM engines for email, which is- And what was the prompt? It was just telling it to, it was a bypass attempt to-

Okay, so it was telling the email security filtering to just ignore everything above the line because you're using an ML model. Yeah, okay, that's cool. Yeah, yeah that's yeah yeah i mean you've got to give them credit for trying but did that work against you do products i don't know it didn't work against it didn't work against ours but uh it was it was super interesting to see the the evolution there yeah i'm just wondering though if you managed to catch some more advanced spearfishing with this or if your clients so you know customers have managed to do that i mean mean, you know, you mentioned before crypto companies, so I imagine you've got a few of them as clients. You know, just what's some of the cool stuff they've been able to find with it?

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 can get out. And then, you know, 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, Peekabot, you know, Qbot, 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. 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? Yeah, yeah. Because there's no, you know, on BC 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 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? Right. And then you've got, um, the other side, and this is, we see a lot of, um, uh, a lot of the folks that are,

um, the adversaries that are delivering malware, um, do threat hijacking is, is a big one as well, um, where they'll have a compromised 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'll then 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 um or another compromised account and then they'll insert the thread that they hijacked from from the other um account and then they'll insert the thread that they hijacked from the other account, and then they'll come back and so... Well, I imagine that sticks out when you're looking for it, right? 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. 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. 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 another reason why, by the way, that this is 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 know, 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 no other signals that you really have.

So you have to have that component. And it is like a more of a recent thing. 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 a 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-based security as well, to actually find that stuff when email security products can't reasonably be expected to observe it. Yeah, it is all just about defense in depth, right? So you've got multi, 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. You've got an EDR, right? Yeah. So, so yeah, it's, it's all about defense in depth. A hundred percent. I mean, that's fundamentally an interesting thing I've always found about the email security game is it, is it as 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 in 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 actually, I am now empowered to go and fix that thing with it. Yeah.

It's all about efficiency, a hundred percent. Right. 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. 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 a key bang they pop it in okay it's up and running right which is which is why a lot of people like uh api based stuff as you said you've also got like a mta uh version of the product that does the same thing but the yeah the 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 now as i said it was years ago there very cool. One thing I'm curious though, is like what the limitations are there? Because I remember

back then when trend we're doing, we're doing it now, 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? This is not a Microsoft bash session. So I'm going to refrain from... You need to watch the YouTube version of this to see the look that Josh just showed me there.

We've 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 have made improvements. I'll say they've made improvements over time. But in all seriousness, 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, 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 10s or seconds or minutes, because the most likely time a user is going to engage with a message is like within the first... It's when they receive it, 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. And so you have to kind of work around it in these tricky and slick ways. And so 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 do it.

But you can't rewrite a link. You can do that. You can rewrite a link. So you can write a link, but you can't rewrite a link you can do that you can you can okay so you can write a link but you can't rewrite body you can do everything uh if you there's no api directly for okay okay there is a there is a way to do it um that is very scalable and it works and it's it's it's how every i think uh most of the most api security vendors, email security vendors are doing it. 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 inline, that's natural. It's coming through you, you rewrite it and then you deliver it. 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? Yeah, there are just certain limitations, right?

Like it is a matter of fact that the message is delivered, it is post-delivery, right? So there is a window. And so for some of our customers, they want the, they want the security, the peace of mind knowing that it's not going to, it's not going to reach a user unless,

unless Sublime has, has analyzed it and has, and has permitted it for some. And when you deploy as an MTA, do you deploy through API as well? Do people use both? Yeah, it's combined yeah yeah exactly because i imagine that would have been fun making those two things work together oh yeah oh yeah uh it was a lot of fun and so um so yeah it it enables you to um to to give peace of mind um for for for those for those use cases. 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. Amazing. Thanks so much, Pat.