S1: All right, Abhishek, welcome to unsupervised Learning.
S2: Yeah, thanks for having me. Excited to be here.
S1: Yeah. Awesome. So, uh, you are Abhishek Agarwal and co-founder
S1: and CEO at Material Security. Is that correct?
S2: That's right.
S1: Awesome. Well, tell me about your background and, uh, the
S1: product and just, uh, get us started here.
S2: Yeah, sure. Happy to. Um, yeah. So I'm Abhishek, um,
S2: one of the co-founders of material. Um, before this company,
S2: I was an early PM at Dropbox, uh, where I
S2: spent time on the data infrastructure side and the cert side, um,
S2: when the company was fairly early. So around 250 people.
S2: I was, uh, an early PM there, like I said.
S2: And then before that, uh, got my start on the
S2: Microsoft at Microsoft Research on the engineering side. So my
S2: background before this company was actually more in like the
S2: productivity and sort of large data sets, side and data
S2: data infrastructure. Um, with this company obviously kind of first
S2: foray into security, although at Dropbox, the security team would
S2: use our data infrastructure quite a bit. So I had
S2: some interaction with them. Um, and yeah, material. You know,
S2: we started a while ago, we're kind of in the
S2: email security space, uh, where we're now broadening a little
S2: bit more to the productivity suite more broadly, more generally. But, uh,
S2: the kind of key insight that led to the company,
S2: which actually got started after the 2016 election cycle, where
S2: there were a couple high profile email attacks. Uh, the
S2: key insight was everybody's really obsessed with trying to stop
S2: someone from getting into email. But but we had this
S2: idea which was like, if someone does get into an
S2: email account, there's all these downstream things that they can do.
S2: What if we could contain that blast radius? Uh, so
S2: that was the original insight that led to the company
S2: and a lot of what we still do today. And
S2: then we also do a kind of more of the
S2: traditional email security of trying to, you know, stop attacks
S2: that that are still bypassing, um, uh, sort of gateways and,
S2: and the like.
S1: Yeah. Interesting. The the front page says, uh, secure email
S1: from every angle, which is pretty interesting. I thought that
S1: was that was a good tagline.
S3: Thank you.
S1: Yeah. So I looked at your background as well. So
S1: I'm surprised we haven't run into each other more. Uh,
S1: you're also in the Bay area as well?
S2: I am, yeah. So I moved out here for Dropbox
S2: and then, uh, has been kind of bouncing around the
S2: Bay area, uh, for the last decade now, so. Yeah.
S1: Nice. Yeah. We should get coffee at some point. Let's
S1: do it for sure. I'm just in Newark, so.
S2: Oh. No way. Okay, I'm really close to you. I'm
S2: in Walnut Creek, so, uh. Oh. Nice. Not not not
S2: just in the Bay area, but nearby. Yeah.
S1: Awesome. Yeah. So, uh, why do product managers make such
S1: good CEOs and co-founders? Because I know you started in engineering,
S1: but you did a decent amount of time as a
S1: product manager. Yeah. What do you think they're so good at? Like,
S1: starting and building and pushing products.
S2: Yeah. It's a great question. Um. First of all. I mean,
S2: I think that like, you know, I'm a big believer
S2: there's like multiple paths to God. So like, you know,
S2: there is no kind of one template, like a lot
S2: of different profiles, uh, folks, uh, can start companies and
S2: make great, uh, founders or CEOs. I think the reason
S2: you see product managers kind of maybe overrepresented there is
S2: that by definition, product management is kind of a, um,
S2: generalist function. You know, like you're at this intersection of engineering, uh,
S2: design business. Uh, that's kind of your job as a
S2: product manager. And so if you take that kind of
S2: elevate that, like, that's kind of what you're doing as
S2: a founder, you know, you're like thinking about what to build.
S2: You're thinking about how you're going to sell it, take
S2: it to market. You're thinking about, um, how it's going
S2: to work, but also how you're going to message it.
S2: And so a lot of these kind of activities are
S2: what PMS are doing inside companies for their products. You're
S2: kind of doing that for your whole company as a
S2: founder when you're when you're, uh, CEO or founder. So
S2: I think that's maybe why PMS are attracted to it. Um,
S2: in my case personally, you know, I just kind of
S2: when I was an engineer, I would really be kind
S2: of missing having an input into what the product should
S2: be and how it should work and who the customer
S2: should be. Then when I became a PM, I was
S2: really missing, like writing code. So I was kind of like,
S2: never really happy in one role or the other. Uh,
S2: and that also makes for a great trait for founders
S2: that are just kind of not satisfied with being in
S2: any one specific role. They just kind of want to like, uh,
S2: be a little bit of jack of all trades. Uh,
S2: so yeah, I think that's why. But I'm not sure.
S1: Yeah, I think that sounds right. I mean, I actually
S1: think with all this AI stuff happening, a lot of
S1: product managers are going to be like, you know what,
S1: screw this. And they're just going to break off and
S1: like build their own companies. Yeah. And have a little
S1: bit of dev support. But even be able to do
S1: like MVP's themselves if they're technical. Yeah. And then be
S1: able to do a lot of the marketing themselves, a
S1: lot of the user stories and like. It's like a
S1: one person company, essentially.
S2: Yeah, I think that's actually one of the most exciting
S2: things about all of this stuff. And I know several
S2: folks have kind of written about this, but the whole like,
S2: when will we see the first, like, you know, billion
S2: dollar company that's just got one employee? That's a very,
S2: very intriguing idea. And I think that is you're totally right. Um,
S2: that and again, I don't think it has to be
S2: just product managers like anyone that can kind of like
S2: complement whatever skill set they have with, with a lot
S2: of that other stuff is going to be in a
S2: position to really get pretty far with, without, maybe not
S2: with literally just one person, but with a pretty small team. Um.
S1: Yeah. And I think it goes back to what you said,
S1: which is, uh, being able to link these different things.
S1: It's like it's almost like the opposite of Google. And
S1: I know some people at Google, so I don't want
S1: to be too mean here. But like Google in general
S1: is almost like engineering focused. Where as opposed to product
S1: or problem focused. Hmm. Yeah. And so they they have
S1: all this tech that they build, they come out with
S1: the attention is all you need paper. Yeah, yeah. And
S1: people just throw random things at the wall. And there's
S1: not a product management led thing of like, problem solution,
S1: really good marketing that makes it clear and then make
S1: and then also product management making it easy to use.
S2: Totally.
S1: It's like so hard to use like Google stuff like, um,
S1: Google Eye Studio compared to Claude or one of these
S1: other products. It's like impenetrable.
S2: Yeah. Um, no, I agree, I, you know, my favorite
S2: kind of recent example of this is that they, they
S2: launched a thing recently for Google Drive in the workspace setting,
S2: where they will use an LLM to auto classify sensitive
S2: content in your drive, which is pretty cool. Uh, to
S2: like auto label it. Um, but but the way you
S2: have to set it up is like, you literally have
S2: to go as a workspace admin and like basically train
S2: a model yourself. And I was like, oh my God. Like,
S2: you know, like most of these security folks or IT
S2: admins be talked to like they're they're not going to
S2: have time to go do that and like back test
S2: it and make sure the precision and stuff is good. Like,
S2: you know, you would expect that to be more kind
S2: of one, one, one click. But yeah, I think um,
S2: I think the other thing is that we talk a
S2: lot about product management in the Valley. But for me personally,
S2: and I've talked about this before, uh, on another podcast, like,
S2: especially as a founder early on, I think learning about
S2: product marketing is very, very important because, yes, because half
S2: of what you were just saying is, um, it is
S2: part of a product managers kind of responsibility, but it's
S2: honestly it's product marketing. It's like, well, like, what is
S2: this going to thing going to be like, what features
S2: is it going to have? Uh, how are they going
S2: to compare to alternatives like how are we even going
S2: to describe them? Like, you know, are they going to
S2: be bundled this way or that way? These are critical
S2: decisions you're making at the beginning of a company, or
S2: even if inside a inside a large org that have
S2: such a big impact. And I think people often are
S2: thinking about them as an afterthought. I know I certainly
S2: was guilty of this, like when I was dropped at
S2: a Dropbox. Like product marketing would often be like, you've
S2: built the whole product, and now someone needs to write
S2: the launch blog post, and that's where product marketing comes in.
S2: But honestly, like, I think the right way to do
S2: it is invest in product marketing way earlier. Like make
S2: your website landing page first and figure out force yourself
S2: to understand how you're going to describe it, you know,
S2: before writing a line of code.
S1: I think you're exactly right. I think this is the
S1: whole thing is like. Have the story, the problem be
S1: like in the very front. The problem is everything. Yeah.
S1: Then you have the story and the wrapper around it.
S1: Then you have your landing page, and then it's kind
S1: of like the Amazon flow, which I used a lot
S1: at Apple as well. You you ship the PR, you
S1: release the PR and it's like, here's what the website
S1: looks like. Here's what the marketing looks like. How excited
S1: are we about this? Yes. And if you pass this
S1: around the table for this senior meeting and people aren't excited. Yeah.
S1: What are you doing?
S2: What is it all for? Yeah. What's the point?
S1: Yeah, yeah, yeah. And if you are no.
S2: Worse feeling than being in like, a company where you've
S2: built the product, you've invested all this time engineering, and
S2: then you're realizing that there's no worse feeling than that
S2: because you're just like, oh God, what have we just do,
S2: you know? So yeah, the more you can do it
S2: up front, the better.
S1: Yeah, definitely. So. So what do you, uh. There yourself
S1: or the company in general believe about email security that
S1: other people don't?
S2: Yeah. Um, this is something that, you know, we have
S2: been kind of saying from the hilltops for a while, but.
S2: The fundamental idea that led to this company was email
S2: is seen in the security context as a really, really
S2: good way to deliver an attack to you, right? Like,
S2: you know, we are all familiar with sort of malware and, uh,
S2: phishing and like BCC and and that's true. Like it
S2: is an open protocol. Anybody on the internet can send
S2: anybody else an email. That's part of what makes it great.
S2: But in a security context, that's what makes it really terrible.
S2: And there's been just years and years and years of
S2: focus on email as a way to deliver an attack.
S2: What's happened, though, at the same time, especially over the
S2: last decade, is we all got like cloud email. And
S2: that meant that we basically got infinite storage and we
S2: started hoarding all of our email. And that means that
S2: it becomes this, like representation of your entire life. Uh,
S2: on the personal front, it's like literally like everything in
S2: your life, like whether it's like your finances, taxes, your
S2: kids stuff, your house mortgage, it ends up in your email,
S2: in the corporate setting, obviously, it's like all of the
S2: company's IP, like the system of record. Right. And so
S2: what that does is it makes it a really big
S2: target as well. So it's not just the delivery method
S2: of a bad attack. It's actually the thing that someone
S2: wants to steal now because it has all this content
S2: inside it. Interesting. The thing that we believe about email
S2: security that no one else does is that blocking phishing
S2: and stuff is important. Uh, it really is, because it's
S2: still a really great entry point. But you also have
S2: to think about email as a content repository that needs
S2: to be secured, the same way that security has been
S2: securing other content repositories for a long time. Uh, so
S2: a lot of what we do at material tries to
S2: block inbound emails that are bad, but it also tries
S2: to go, you know, have a plan. If someone does
S2: get into a mail account and, you know, today, like
S2: they would be able to steal all the content inside
S2: it or they would be able to go like reset
S2: my Dropbox password and take over Dropbox. We try to
S2: mitigate those things and limit the blast radius of a
S2: bad of a, of a of a breach. Basically, if
S2: someone does get into an account, how can we stop
S2: them from not doing as much harm as they would
S2: normally have done? That's a thing where complementing traditional email
S2: security with.
S1: No, that's interesting. And what are the detection mechanisms for that?
S1: So let's say someone has a credential. Yeah. Um like what?
S1: How are you detecting if you move around, you do
S1: something dangerous inside the account.
S2: Yeah. So the first thing I'd say is, like, it
S2: actually doesn't have to be about detection at all. So
S2: let me give you an example. So let's say like
S2: we take a, the uh, the analogy of a car.
S2: So a seatbelt is something you just put on when
S2: you drive a car. It doesn't like detect the accident
S2: and like go into like motion right before the accident
S2: is going to happen. Like it's just there. It does
S2: its job. Yeah. Um, so similarly, you know, we're not
S2: necessarily detecting the presence of an attacker and then trying
S2: to respond. We're just saying there are certain controls you
S2: should just have all the time. So for example, um,
S2: if you, uh, one of our products is called, uh,
S2: data protection for email. And what it does is it
S2: goes through your archive and via APIs, it looks for
S2: anything that it thinks is really sensitive, like really juicy
S2: stuff that's in your archives. And if it's like older
S2: than some specified period of time, let's say a year
S2: or six months, it it can actually redact it inside
S2: your mailbox and make you do a side channel challenge,
S2: like an MFA or a, you know, touch ID or
S2: an octopus or whatever before you can get it back
S2: in your mailbox. And, um, that's like a simple control
S2: that is not it's not going into place when we
S2: detect an attacker. It's just there all the time. Because,
S2: you know, in the same way that, uh, for other
S2: content repos, you wouldn't want it to be the case
S2: that if I get in once, I just get everything.
S2: You would want to have additional checks. We're just trying
S2: to do that for email as well. Now, what's cool
S2: about that, though, is that it opens up detection capabilities,
S2: because now let's say someone was in my account and
S2: they're going to try to like retrieve these messages that
S2: have been redacted. Well, yeah. If they like try and
S2: they keep failing requests. Now it acts as a canary
S2: and it tells us, okay, there might be someone in
S2: this mailbox, um, which is actually, you know, funny story. Like,
S2: recently there was this big attack, uh, by the Chinese
S2: called storm. Uh, uh, it was a storm eight breach.
S2: It's a group that attacked the Department of Justice and
S2: a State Department and a couple other, uh, federal agencies,
S2: and they basically were after email correspondence. That's why they
S2: did it. They went after the content of these mailboxes.
S2: And one of the agencies that actually discovered this attack
S2: the way they did that is because they were looking
S2: at a log of every time an email message inside
S2: a mailbox is accessed. It's a very verbose log. Um,
S2: most people don't use it or don't, uh, operationalize it,
S2: but they were. And it's how they figured out, oh, man.
S2: Like someone is reading all these emails from like, three
S2: years ago, and they're doing it at a very high
S2: volume versus what the normal usage of the mailbox is.
S2: So you do want canaries that can tell you about.
S2: The attacker. But more importantly, you want to just like
S2: limit what the attacker can do in the first place
S2: because it's not just all about detection.
S1: Yeah, I love that because that that kind of takes
S1: the realm away from like an email security. Yeah. Vibe,
S1: which is very, I don't know, 20 years ago or
S1: whatever and moves it into more of like a data
S1: security or like an app security.
S2: That's right. That's exactly right. And, and, um, this is
S2: one of those situations where like, like the terminology is
S2: actually hurting us as an industry because it's like, okay,
S2: so email security means what you just said, right? For
S2: 20 years it's blocked bad emails.
S1: Yeah. SMTP related settings, whatever. Yeah.
S2: Or like I'm going to send you like the, you know, like, uh,
S2: sasser werm over email like 20 years ago, but like, uh,
S2: or more than 20 years ago. Man, it's been a while. Um, yeah. But, uh,
S2: but I think then what do you call the thing
S2: that tries to go protect the sensitive content in your email?
S2: I mean, technically, it's security for your email messages. So
S2: is it email security? I mean, maybe, but like, yeah,
S2: to your point, it's more like data security or app security. Um,
S2: you know, it gets even more like, uh, tricky, like. So,
S2: for example, I mentioned that I was at Dropbox before
S2: this company. One of the biggest ways we would see
S2: Dropbox accounts get hacked is an email account would get hacked,
S2: and then the adversary would just reset a password to
S2: Dropbox because, um, back then and I think this is
S2: still the case, like, even if you had MFA on
S2: your Dropbox account, if you requested a password reset email,
S2: Dropbox would let you reset the password without triggering MFA
S2: because it assumed that if you had lost your first factor,
S2: you would have also lost your second factor. Um, but
S2: that means, like if I get access to an email
S2: account now, all of a sudden every service that is
S2: connected to that email account, I can just move it to, um,
S2: this happened, you know, with like, uh, McDonald's. They had
S2: their Twitter account taken over because someone broke into, like
S2: a marketing person's email account and then reset the Twitter
S2: password and they could just post anything they wanted as McDonald's.
S2: So you kind of see this thing where, like, email
S2: is really more than just a bad way to deliver something, uh, or, sorry,
S2: a way to deliver something bad. It is like all
S2: of these other things open up from an email account
S2: if you, if you, um, if you get it access once.
S1: Yeah. I love this idea. It's it's almost like you
S1: can make a total list of all the bad things
S1: that can happen around email. Yeah. And then not even
S1: think about email security. Not even think about any type
S1: of security. Just make a list of, like, abuse cases. Yeah, yeah.
S1: And then be like, okay, so where are the different
S1: layers of control that we could put on this. Is
S1: this a. And then you could assign the labels afterwards
S1: and be like this is kind of a data security thing.
S1: We kind of think of this as appsec or whatever. Yeah.
S1: And then just be like, look there's like 13 of
S1: these and they're really important. I mean, what are some
S1: of the other ones that are kind of like a
S1: more traditional appsec type control that, that you.
S2: Um, I think there's so, you know, there's going after data, uh,
S2: then there's using lateral movement, uh, like I said, with
S2: the password reset type of stuff. So trying to figure
S2: out where else I can get from this. So is
S2: a vector for further attack. Um, the other kind of
S2: thing that is very common is if I'm in control
S2: of a mailbox now, I can send email from it, obviously,
S2: and like impersonate the person who I've just taken over.
S2: So this is one of the most common ways that like, uh,
S2: business email compromise happens where, uh, let's say you're a
S2: big company, you have a vendor that sends you invoices
S2: every month. Someone takes over the vendor's account, uh, sends
S2: an email from the vendor that's like, hey, we need
S2: to change the payment terms of our invoice. And you're like, okay, cool.
S2: It's coming from the valid email. And now all of
S2: a sudden, you've wired money to the wrong place, right? So, uh,
S2: that's another abuse case of taking over a mailbox. Um,
S2: and but but honestly, there aren't that many. And this
S2: is kind of like, I, I like your point of, like,
S2: making that list. Uh, when we started this company, me
S2: and my, one of my co-founders. Big. We're big into analogies.
S2: So I'll give you another analogy, right? Like, okay, if
S2: you're thinking about, like, protecting your house and you have
S2: to make a list of every single way I could
S2: break into your house, like, how do I get in? Yep.
S2: And so that's one list. And now you make another
S2: list of, like, every single thing. I would actually want
S2: a value in your house that you really care about. Yes.
S2: Like which list is shorter? I would argue that second
S2: list is way shorter, right? It's like okay, like there's
S2: a few things that like are your crown jewels, uh,
S2: and you want to protect. So if you take that
S2: same idea to email security, if you think about every
S2: single way an email account can be compromised, it is
S2: like a long list, like I can I can do
S2: a malicious OAuth application, I can bypass MFA. Maybe I
S2: get a malicious browser extension, I might steal a personal
S2: device like client side malware list goes on. And I mean,
S2: in the case of like some of these state actor attacks,
S2: it's like literally zero days or, you know, a forged
S2: token at the Microsoft level. There's like just a long,
S2: long list. But then what do I actually want? Once
S2: I get into an email account, it's like 2 or
S2: 3 things like, you know, I want the data that's
S2: inside the. Mailbox already. I want to move laterally to
S2: some other services. I want to send outbound email to
S2: a specific people. So it's just a much, much shorter list.
S2: And to your point, you can kind of iterate through
S2: each of those abuse cases and say, what controls can
S2: I put into place and actually really take a solid
S2: dent on, like the harm that you can do from
S2: a compromised mailbox? Um, so I like that way of
S2: thinking a lot.
S1: Yeah. Yeah, I think it's really interesting. I love that
S1: you're thinking in less the same way. I, I very
S1: much think that way. I think of a risk register
S1: that way. I think of threat scenarios, uh, attack scenarios
S1: like defenses. And you kind of just match them up. Yeah. Um,
S1: I hate to say the a word, but, um, one
S1: one thing, uh, that I think about a lot is,
S1: is like, okay, if one of those things is convincing
S1: somebody to do something. Yes. Like, hey, it's time to go, uh,
S1: go send this money. I need it urgently. Yeah. You
S1: can ask, uh, an LLM or AI or whatever. Like
S1: is is someone applying pressure of urgency here? Yes. Yes. Um,
S1: and is that sense of urgency tied to a thing
S1: that matters a lot, like sending money? Yes.
S3: Right. Yeah.
S1: So you could just build this, you know, very large
S1: list of like, all the different bad things. And like
S1: you said, it's, um, there could be API keys, there
S1: could be, um, uh, one of the big things a
S1: lot of foreign actors do, as you know, more than me,
S1: is like, go after sources and look for, like, with
S1: reporters and stuff like that. Yes. So if you just
S1: had this giant grid of like all these different situations
S1: and be like, oh, this one, we could do LLM
S1: to detect that this one is just a setting inside
S1: the platform to do that one. Yes. I love that
S1: comprehensive approach.
S2: 100% agree with you. Um, and in fact, the thing
S2: that you just pointed out, we literally use LMS for
S2: on the detection side because.
S3: Sometimes.
S2: Because sometimes, um, you know, to be honest, like a
S2: lot of the kind of NLU stuff of like detecting
S2: things like urgency and stuff like that that's been around
S2: for a while, but then like there's and it didn't
S2: require LMS, you know, you can train like a traditional
S2: machine learning model. But what is cool about LMS is
S2: that the speed of iteration is very fast. So like
S2: you can very quickly put things in. You don't have
S2: to worry about things like, you know, multi-language support because
S2: that's handled by the LM. And then also where it
S2: really becomes handy is for things that are even more complicated. So,
S2: you know, I'll give you an example, like if I'm
S2: a company and I'm trying to protect sensitive email, some
S2: of it is going to be kind of like the
S2: classic like Social Security numbers, credit card numbers, whatever. But
S2: some of it is going to be like, is there
S2: a negotiation happening in this email thread?
S3: Yes.
S2: It's like, how the hell do you how do you
S2: like write a detection for that? You know, like you write,
S2: it's really hard. Uh, or like, oh, it's like is
S2: a executive abusing power in this email thread, uh, where
S2: like if it got if it leaked like it would like,
S2: have a reputational damage. Um, that's the kind of stuff
S2: that is very difficult or like, you know, you see,
S2: kind of like examples of, like extortion or like blackmail. Um,
S2: so for those types of things, LMS are fantastic detection
S2: tools because, I mean, their job is to understand language literally. Right?
S2: So like, they're very, very good at that. Um, I
S2: think a lot of the email security discussion with LMS
S2: has actually been pretty like pessimistic because people's heads immediately
S2: go to, oh my God, like, this thing can generate text,
S2: which means it can generate phishing emails. And so like
S2: now all of a sudden any bad guy can write
S2: emails and like send them. And, you know, there there
S2: is an element of truth to that for sure. Because like,
S2: you can kind of scale up any kind of like phishing, um, uh,
S2: campaign just by like, you know, doing research via the
S2: LMS and having it customized. So 100% is a valid
S2: it's a valid fear. But my kind of answer to
S2: that has always been like, well, shouldn't your good security
S2: controls be sort of, um, agnostic to how an attack
S2: is generated? Like, who cares if it's like a person
S2: writing the email themselves after hours of research, or they
S2: just automated it with like an LLM? At the end
S2: of the day, if you have a good control in place,
S2: like it shouldn't matter. And so and by the way,
S2: like a lot of these AI tools like LMS are
S2: a fantastic on the defensive side too. So I would
S2: personally like to see a little bit more optimism there. Uh,
S2: because like so far, a lot of the fear mongering
S2: around LMS has been, oh God, they're going to write
S2: ten more phishing emails. And it's like, yes, but like
S2: your control should work anyway. Good ones at least. And secondly,
S2: you can also use them on the defensive side. So
S2: there's there's a lot to be optimistic about.
S1: Yeah I love that. The way I've been framing that
S1: is um. Uh, Red is going to have like this
S1: massive advantage in the beginning because they could just like
S1: they don't have to experiment and be careful. Yeah. They
S1: could just like so the spearfishing like, starts the day
S1: after an LM comes out. Yes.
S2: Yeah. Exactly.
S3: Yeah.
S1: But um, blue should actually get better with those same
S1: AI tools.
S3: Yeah.
S1: So ideally it would be something like oh we have a,
S1: we have a Sea team member who is like just
S1: so ego driven. And if you compliment them in any
S1: way and like say, hey, I want you to lead
S1: this new foundation or something like they're going to click
S1: that email.
S3: Yeah.
S1: So you flagged that or something.
S3: Yeah.
S1: This goes back to what I think so cool about.
S3: That would be funny.
S2: It's like this email is complimenting you. You don't ever
S2: get compliments. This especially.
S3: Right.
S1: That's right. And you click on 94 of them 94%
S1: of them when you do get to compliment. So this
S1: is dangerous. Um, yeah. Yeah. So it's like. The other
S1: thing that's really powerful about this is, um, you can
S1: have additional context customized for your particular company. Yeah. So
S1: it's like, um, we're doing this thing with France or something.
S1: It's really sensitive. Yes. And, uh, so anything around that is,
S1: you know, notch that up two levels.
S3: Totally.
S2: Totally. Yeah, yeah. And so, yeah, we've been talking about
S2: kind of like suspicious or malicious emails, but LMS like
S2: I think you just alluded to also very helpful for
S2: the sensitive emails because like yes. Yeah. To your point,
S2: like maybe today you want to say something like anything
S2: about this project or we're about to we're prepping to
S2: go to IPO. Uh, not material, but as a hypothetical.
S3: Right. Exactly.
S2: Like it's like, uh. How any conversation around like IPO
S2: prep is pretty sensitive. Like, but how do you how
S2: do you declare that as a general sensitive content category,
S2: it's pretty hard without something like an LLM. So leveraging
S2: them for those custom detection categories or context specific detection
S2: categories is very exciting. Um, and I and I think
S2: that that is the way the, the sort of like, uh,
S2: security controls are headed.
S1: Yeah, absolutely. The other use case I thought about for
S1: a long time about that is like, um, legal companies
S1: were being attacked.
S3: Um, law.
S1: Firms. Yeah. And they have very little IT staff, very
S1: little security knowledge. Yes. And what they have is this
S1: list of connections, people interacting with different people. Yeah. Uh,
S1: suing different people. And it's like, that's the mapping that
S1: that attacker might want, want to use.
S3: Yes. Yeah.
S2: Totally. Well, and that's another I mean, that brings up
S2: one other point about email that is hard, is that
S2: the way email works is when when a message is
S2: sent to multiple people, uh, everyone gets a copy, obviously. Right.
S2: So there's no like pointer relationship with email. Like you
S2: each get a copy, which means that one of the
S2: downsides is that is like you could be doing a
S2: great job with your own email security and like, you
S2: could have minimized the impact of a compromised account or whatever.
S2: But then like the person who was CC'd, like, you know,
S2: they might have terrible, you know, when when we started
S2: the company, like I mentioned, it was after the 2016
S2: election cycle, and one of the attacks that happened then
S2: was John Podesta, who was Hillary's campaign chairman. He had
S2: his personal Gmail account compromised, and all of his emails
S2: were put on Wikileaks, like literally like years and years
S2: of his personal Gmail. And and there were things in
S2: there that he was just seized on. He had literally
S2: no reason to even be on the message. He was
S2: just CC. And because of that, all this communication that
S2: was about like the election or about like prepping for
S2: something that like, frankly, he just was being an FYI on. Yeah.
S2: You know, um, so I think the, the fact that
S2: everybody gets a copy is hard. And what that means
S2: is you kind of have to think about who you're
S2: like trusted parties are that are outside of your control
S2: and make sure they have good practices, you know, which
S2: which becomes a it's kind of like, uh, similar to
S2: a supply chain security problem, right? Where you're like on
S2: the software side, you're thinking about all the dependencies your
S2: software has on the kind of email side, you might
S2: have to think about all the different, um, associates of
S2: your company that have, you know, your email as well.
S1: Yeah. Or like, uh, PCI where the scope is contagious. Yeah.
S1: It like slightly brushes up against it. Now that's in scope.
S1: It's like yeah, yeah, yeah. Interesting. Um, so so what
S1: does it look like to basically onboard the tech. Like
S1: what does the integration look like. What's the experience like
S1: how fast can somebody get up and running.
S2: Yeah. So it's incredibly fast. And the reason for that
S2: is everything we do uh works with cloud mailboxes which
S2: have APIs. So our whole integration point, um, is API based.
S2: It's just an OAuth grant where we are getting access
S2: to email via API. Uh, which is a big difference
S2: from like, uh, you know, legacy email security products that
S2: some folks might.
S3: Be away or something. Yeah.
S2: Where you're like changing your DNS and like routing email
S2: through the appliance, like you're not doing any of that. Um,
S2: as a result, the integration is very quick. But also
S2: it means that you don't take some dependency on this
S2: API based thing going down and like, you know, shutting
S2: off your email, like, for example, like if material were
S2: to go down, it's not like email stops flowing. You're
S2: still you're still doing email as usual. Of course, some
S2: of the detections material does or some of the mitigations
S2: it does would be would not be active. But we're
S2: not in your email flow. Um, so it's pretty quick.
S2: The other benefit of APIs is you can be very
S2: selective in how you deploy that, deploy the protection inside
S2: your company. So for example, with gateways, it's a kind
S2: of an all or nothing you like do a cutover. Um,
S2: but with API based email security products, you can say, hey,
S2: for my executives do X, but for my other team Y,
S2: you know, you can kind of have different settings, different
S2: kind of configurations or policies. So that is something that
S2: a lot of our customers also take advantage of.
S1: Yeah, that's really cool. And what does it look like
S1: to know that it's working. Like what is the interface
S1: look like. Um, if there's nothing wrong, do you just
S1: not see it? And then does it sort of move
S1: up the level in priority if it sees something?
S3: Yeah.
S2: Well, we have a few different products. So depending on
S2: the product we're talking about, you know, what you would
S2: see is slightly different. So one of our products that
S2: we've been talking about a little bit so far is uh,
S2: we go and redact sensitive messages that are older than
S2: some specified time frame. And uh, and then an end
S2: user has to pass like an Okta challenge or some
S2: sort of secondary challenge. Uh, it can be really any
S2: IDP or so. If they pass that, then we restore
S2: the message right back into the mailbox. It's really seamless.
S2: And then after some amount of time, once the user
S2: is kind of done with it, we will redact. Did again.
S2: So for that product, what you see as an IT
S2: or security admin is really not much on a day
S2: to day basis, because it's kind of like just in
S2: the background doing its thing. Uh, you do get an
S2: access request log. So every time someone is accessing one
S2: of these sensitive messages and having to do the retrieval,
S2: now there's a paper trail of that, obviously you could
S2: you could pipe that into like a SIM or something
S2: and say, okay, like if I'm seeing a lot of
S2: these from someone at the same time, that's that's indicative
S2: of something bad. Or if I'm getting a lot of
S2: denials in a row, obviously, that that ends up being
S2: something bad, but really there's nothing to like, detect or
S2: show on a daily basis because people are just doing
S2: a self-serve, secure workflow for accessing sensitive content. Um, on
S2: the other hand, we do have a product that is
S2: a much more in the kind of traditional look for
S2: sophisticated attacks that bypass like Google or Microsoft or Proofpoint
S2: or whatever. Um, and there you have like a, you know,
S2: an incidence or cases list where you're seeing kind of
S2: what material actually detected. Some companies set us up where
S2: we're just auto remediating those. And again, you don't really
S2: have to log into the console. There's nothing to see.
S2: We're just handling them. Other teams are much more hands
S2: on where they might auto remediate, but then they want
S2: to still like triage the things that we actually caught
S2: make sure they're not false positives. Um, you know, communicate
S2: to end users about it, have their sort of, um,
S2: SoC watch. That kind of really depends on how much, um,
S2: how hands on a company wants to be. But that's
S2: what they would see in the console.
S1: Okay, cool. And then what is, um, the threat intelligence
S1: story look like in terms of like, hey, there's this
S1: new campaign happening, this new vulnerability or whatever. Yeah. And
S1: it's like it's being blasted all over the internet. Yeah. Like,
S1: what does that turnaround gap look like for you in
S1: terms of like, uh, finding out about it and getting
S1: into the product and rolling it out?
S2: Yeah, it's a great question. Um, yeah. So email is
S2: super dynamic. There's like always new kinds of campaigns. And
S2: people are, uh, you know, trying out new tactics to
S2: bypass kind of a lot of the traditional defenses. So
S2: like one of the, one of the more recent things
S2: is like QR codes, right? Like for a while, like
S2: a lot of detection engines weren't exploding QR codes or
S2: following the links. So that meant that like QR codes
S2: were a really great way to deliver attacks. Um, we
S2: have a couple different mechanisms. So first of all, one
S2: of the things our product does is it also ingests
S2: any user reporting that is happening inside a company. So
S2: one of the best practices that every security team tries
S2: to implement is they say, hey, uh, if you see something,
S2: say something, right? Like, uh, and with email security, what
S2: that normally looks like in most companies is, hey, we
S2: have this like phishing mailing list, or we have like a,
S2: like a, like a report phishing button or something where
S2: please report it to us if you see something. So
S2: we have a product that automates the response to those
S2: user reports. So it ingests them. It auto classifies and
S2: triages them, uh, looks for similar messages that the user
S2: may not have reported, and then even responds back to
S2: the user saying, hey, thanks for this report. Uh, it
S2: was fine. Or actually that was a true positive. That
S2: was bad. Anyway, so that ends up being a great
S2: signal because across all customers, if they are users that
S2: are reporting things that then we know are actually malicious,
S2: that's a you know, we think of that as like
S2: a oh, well, why didn't material just flag that in
S2: the first place. And so it becomes this feedback loop. Um,
S2: so the more customers we have, the more signal we
S2: have from users reporting things. And we can quickly like
S2: build it back into the product. The other thing is
S2: we do have an in-house threat research team. You know,
S2: their whole job is like focused on looking for these
S2: active campaigns that are happening, looking for what some of
S2: our more sophisticated customers are telling us that they're seeing,
S2: and then quickly kind of iterating on our detection engine
S2: to handle them. And then the the sort of like
S2: last piece of this is, um, just investing in a
S2: system that has a lot of flexibility. So in in
S2: email security, there's kind of this interesting not like really
S2: a debate, but there's this interesting kind of, uh, trend
S2: emerging where there's a couple different approaches to the email
S2: security problem. Like on the one hand, there's kind of
S2: like the black box approach, which is like, hey, like AI,
S2: machine learning, we're going to try to detect what we
S2: can and like there aren't really knobs and tuning and
S2: all that, but like this model is going to be
S2: way better than trying to like handwrite a lot of rules.
S2: Which makes sense because, you know, a lot of times
S2: you have like never before seen attacks or you have
S2: like things that are like, you know, there's no signature
S2: that you can kind of rely on. And also, like,
S2: no one wants to maintain this big list of rules
S2: and things like that. So that's kind of one extreme.
S2: The other extreme is, uh, you know, you're kind of
S2: seeing like the detection as code, um, philosophy coming to
S2: email security as well. And people are like, hey, we
S2: have this list of detections we maintain we're going to
S2: back test them. We're going to make sure they have
S2: like a good precision rate. Um, and it gives a
S2: lot of control, but it means you're doing a lot yourself.
S2: You're hand tuning a lot of things. And there are
S2: products that kind of help you and make that easier.
S2: There are products that help you maintain that, you know,
S2: we have customers that. Maintain like GitHub repositories of like
S2: detections they've written, but it is kind of like very manual.
S2: And then there's kind of somewhere in the middle where
S2: you're like, hey, I don't want to be full black
S2: box because they are going to be things that you miss.
S2: And in those moments, like, you don't want to be like, oh,
S2: I guess I'll just wait for the black box to
S2: update and catch this. But on the other hand, you
S2: really don't want to live in a world where most
S2: of your time as a security team is spent on
S2: like tuning or creating these, like, detections. Um, and so
S2: what we're trying to do is like out of the box.
S2: It's like, you know, going to be perfectly fine, have
S2: a lot of coverage, pretty high precision, but then still
S2: give you tools in the product where if you notice something,
S2: if like you're aware of an active campaign that we're not,
S2: you can quickly like express a detection in our product
S2: or express a rule or a search query that will say, hey,
S2: please treat this as malicious. Like, I know your whole
S2: product hasn't updated yet, but like I know this is bad,
S2: I just want to express it in your platform. I
S2: should be able to. Um, so it's kind of a
S2: product design philosophy, right? Which is like have the kind
S2: of flexibility so that when you need it, it's available.
S2: But treat that as almost an anti metric. Like if
S2: people are having to create those flexible leverage that flexibility
S2: a lot. It means you're kind of doing something wrong, right.
S2: Like you really should have done it out of the box.
S3: I absolutely.
S1: Love that. I don't know if, um, you ever watch
S1: Star Trek The Next Generation, but I was obsessed with
S1: I was obsessed with the fact that the first time
S1: they hit a Borg with the phaser. Yeah, like it
S1: would fall over dead. And like, the third time the
S1: entire Borg across the entire universe was updated. Yeah. And like,
S1: that frequency would not work anymore. And I was just like, yeah,
S1: that is, you know, I mean, security maybe.
S3: Yeah.
S2: I've never thought about it that way, but so true.
S3: Yeah, yeah.
S1: So that signal that they create that would obviously apply
S1: to their local environment. But is that is that also
S1: a signal to the, uh, the T team to be like, hey,
S1: maybe we should put this in.
S2: Yes, absolutely. And, um, one thing that we are very
S2: conscious of is like, obviously we're getting access to a
S2: companies like email. It's very, very sensitive. So, so the
S2: whole material deployment and architecture, uh, model is that every
S2: single customer has a single tenant environment that is actually
S2: in their control. So they, they don't just get access
S2: to our admin console like other SaaS, they actually can
S2: log in to the underlying infrastructure that is hosting our
S2: application because it's all single tenant. And so we get
S2: to make some pretty cool guarantees, like of isolation and
S2: making sure that there's no data sharing happening and that like,
S2: data isn't leaving that instance unless it's permitted by a customer.
S2: Having said that, though, a lot of our customers are
S2: okay with a threat research team extracting the signal of, okay, what,
S2: you know, what custom detections did you make or what
S2: did your user reports? So where we have permission, which
S2: tends to be in most cases, we are able to
S2: look for those signals. But I do want to point
S2: out that there are some customers who are like, nope, sorry.
S2: Like this is too sensitive. Like we don't want your
S2: team or anyone in material to have any access to
S2: what we're doing. You can you can configure and deploy
S2: us that way as well. And you know, there's kind
S2: of like you can probably guess the types of organizations
S2: that want to deploy us in that model.
S1: No, that's a great point. And it goes to your
S1: earlier point about flexibility. It's like you could be that
S1: like three letter agency type group. That's like all closed doors.
S1: Or it could be like, yeah, sharing with the Borg
S1: or whatever.
S3: Yeah.
S2: Yeah. Exactly. And you know, and like the nice thing
S2: here is like obviously like for these attacks and stuff
S2: for the most part, like even just like getting like
S2: anonymized data in terms of like, like it doesn't really matter.
S2: Like which tenant or which customer it's targeting. It's just
S2: a fact that like, it got missed. It's something you
S2: can tweak so you kind of don't have to reveal
S2: anything to other customers by participating in this. But having
S2: said that, yeah, some some companies are just a lot
S2: more closed and a lot more strict. And and that's okay. Uh,
S2: we also have the other extreme where there's companies that
S2: are like, dude, I just want to use this as SaaS. Like,
S2: I don't care about the infrastructure. Like, I don't have
S2: teams that like, want to, like, log into that and like,
S2: I'm busy. Just just give me an admin console. That's
S2: fine too, you know, like, uh, so we kind of
S2: have support all of those models.
S1: Okay. And what are the main products? I think we've
S1: talked about 2 or 3 already, but like what what
S1: are the main core products.
S2: Yeah. So we have four main products. So the first
S2: that we've been talking about is data protection. And that's
S2: really focused on giving you visibility. And then the redaction
S2: of sensitive messages that are in email. And again not
S2: like outbound emails, not things I'm now sending, but really
S2: focused on what's sitting in your archives that's going to
S2: get you in trouble if a, if a mailbox was compromised,
S2: or if an insider was trying to walk with a
S2: lot of email on their last day or something. So
S2: that's one. The second product is, uh, phishing protection. So
S2: that is kind of the traditional email security where we're
S2: looking for inbound attacks that may have been missed by
S2: like a Google or a Microsoft or whatever other traditional
S2: defenses you have in place. The third is a product
S2: we call identity. Protection, where it's really focused on that
S2: Dropbox example of like, hey, if you get into my
S2: email account, can you now go reset Dropbox because you
S2: just request a password reset? Or can you go to
S2: slack and say, hey, can you send me one of
S2: those magic sign in links? And then I can just
S2: get into a slack workspace, even if slack is behind
S2: so or MFA or whatever. Yeah. You literally click these
S2: magic sign in links bypass link.
S3: Yeah.
S2: Um, so what we do there is something again, very simple.
S2: It's another seat belt where we intercept those kinds of
S2: messages and we make the end user prove that they
S2: were the ones who actually requested them before delivering them.
S2: So it's very simple. Like you go request a Dropbox
S2: password reset. Now you first get an email from material
S2: that says, hey, are you trying to reset your Dropbox password?
S2: If you say yes, the Dropbox password reset email comes
S2: in as usual. You go about your merry way. If
S2: you say no, though, it means like I can't be
S2: in your mailbox and then go get access to these
S2: lateral things. And in a in a typical enterprise organization,
S2: which is what we normally kind of sell to, um,
S2: you will see hundreds of apps that are still doing
S2: password resets or sign up verifications over email, even though
S2: they're supposed to be under SSL. So like a common
S2: culprit is like Salesforce, uh, or, you know, workday where
S2: like you think they're behind. So or ADP is another
S2: one where you think you've kind of handled them, but
S2: there's some backdoor happening over email that you like, forgot
S2: about or you misconfigured. And then there's all these like
S2: consumer apps that are like not never going to support
S2: SFO but are still valid in the corporate settings. So
S2: like Twitter I gave as an example. Right. Like obviously
S2: your marketing team has a Twitter account, but Twitter is
S2: not going to support any type of identity thing. Um,
S2: and then our fourth product is basically what we call
S2: posture management. And it really is about helping you understand
S2: what's even going on with your email environment, uh, and
S2: broadly your Google Workspace or M365 environment. So for example, um,
S2: when I was at Dropbox, if I walked into our
S2: company and created a auto forward of all of my
S2: corporate mail to my personal Gmail, literally no one would
S2: know and no one would come and do anything about it.
S2: And the reason is because, um, just getting that kind
S2: of information out of like some of these productivity suites
S2: can be very hard. And a lot of times people
S2: haven't really built like detection or response playbooks around them,
S2: and they can't outright block this kind of behavior from
S2: happening because sometimes they are legitimate use cases for auto forwards,
S2: for example. So you can't just like block it at
S2: the tenant level. So we look for all sorts of
S2: behavior or settings or misconfigurations in M365 or Google Workspace,
S2: and we just surfaced them with recommendations of how to
S2: reduce that kind of risk. And that's part of the
S2: posture management product. So yeah, those are the four.
S1: Yeah. Those are those are great. That is they all
S1: do definitely complement each other. I really like the last one,
S1: especially because I feel like that is so much of
S1: the game is like just not knowing. It's like leaving
S1: open S3 buckets. It's like you're spending all this money
S1: on security and then you've got this thing dangling. Yeah.
S1: And uh, yeah, there's so many settings as well. So
S1: it's hard for me.
S2: I actually think that, you know, it's a funny story
S2: about that. When we first started the company, it was
S2: just the data protection, uh, feature, the redaction one. That's
S2: really what led us to start this company in the
S2: first place. When we went and talked to CISOs or
S2: security teams about that, the first question we would obviously
S2: get is like, hey, cool. Like you have this awesome
S2: control for sensitive content in the mailbox. What sensitive content
S2: do I even have in mailboxes? Like, right. Like, do
S2: I even need this? Like, I have no idea. Like,
S2: it's like, I suspect that I probably need this, but like,
S2: I have no idea. And so we were like, oh shit. Like,
S2: obviously like step one is to give you visibility and
S2: help you understand what even is there. And so, like, selfishly,
S2: for us, it kind of helped us tell the story
S2: of why you need some of the controls that we're
S2: talking about, but also for, for security teams, it's often
S2: step one anyway, which is just like, okay, like now
S2: I have a lay of the land. The other thing
S2: is you kind of mentioned the S3 bucket. And that
S2: I think is a really great point. Like it is
S2: a very well understood in cloud security that like, you know,
S2: Cspm is like cnaps all this stuff like are very,
S2: you know, well understood category. People understand why they need
S2: them because there's all this stuff happening in your cloud environment.
S2: There's different teams, uh, creating like software, uh, all these
S2: settings to think about. And so you need a platform
S2: that's like looking at behavior, looking at vulnerabilities and kind
S2: of like showcasing the top, riskiest ones and helping you
S2: address them literally, word for word. Everything I just said
S2: applies to the productivity suite, right? Like M365 and Google Workspace.
S2: And yet there isn't really a cspm equivalent for just
S2: those products. There's there are SPM tools where they're like, oh, well,
S2: we cover 50 apps and M365 is one of them.
S2: And because they cover 50. The apps. It's hard for
S2: them to go deep on the productivity suite. Um, and
S2: so they'll give a some surface level detections, but the
S2: sort of like depth of a cspm that is entirely
S2: focused on cloud security does not exist for the productivity suite.
S2: And it's an area that we're at material like, very
S2: excited about pursuing, because I don't really see a good
S2: reason that there isn't an equivalent.
S1: Yeah, especially when the implications of a setting being one
S1: way versus another are so huge. Yeah, right. And there's
S1: also a lot of opportunity there to be like, look
S1: you are this type of risk posture of a company.
S1: You really care about these relationships or whatever. So out
S1: of the 312 settings available in this platform, we recommend
S1: the following settings three.
S2: Yeah, totally. Um, and it's kind of similar to what
S2: you were saying earlier, right? Like if you make a
S2: register of the like most common attacks anyway, and you
S2: just start with that, like here, here, like the 10
S2: or 15 things that like are almost always the culprits
S2: like and again, Cspm learned that a while ago and
S2: I think they're like, okay. Yeah. Like we keep leaving
S2: buckets open, like, let's stop doing this. You know, I
S2: think that there are equivalents, uh, in, for example, like
S2: we have a product, we have a fifth product that
S2: I actually forgot to mention that is very new, and
S2: it focuses on Google Drive. So a lot of the
S2: same stuff that we had heard over the years with
S2: sensitive content in email, people were like, our customers were like, hey,
S2: I have a lot of these problems with Google Drive,
S2: like just the files. And, um, and that product is
S2: all about detecting kind of oversharing, because a lot of
S2: times what happens is it literally equivalent to the S3 bucket?
S2: You might have some file that was shared at one
S2: point with anyone with the link permissions, uh, even though
S2: like it didn't need to be and it's got sensitive content.
S2: And now it's been two years since anyone has ever
S2: looked at it. But, you know, it's mentioned in some
S2: email that might be part of a breach. And now
S2: all of a sudden it's accessible. So how do you
S2: go clean that up? Like you're not going to have
S2: a security team that's sitting around like auditing their Google Drive,
S2: which has like millions of files. So you can automate that.
S2: You can do things like, hey, if it has sensitive
S2: content and it also has these permissions like revoke them
S2: in this way and notify the owner so you can
S2: build workflows and kind of get the end users involved.
S2: Because that's the only way to have like a tenable
S2: solution there. Otherwise you're just going to have a security
S2: team that is trying to like, go through a giant
S2: backlog of these and will never prioritize it. And it's
S2: just one of those, like, active risks just sitting there.
S3: Um, yeah, absolutely.
S1: Any new research or new new exciting stuff coming out soon?
S2: Yeah. The thing that I'm very excited about is kind
S2: of what I was alluding to. So maybe I'll describe
S2: it in a little bit more detail. But basically we
S2: think that, um, there is an opportunity to do more
S2: than just email. Email is just one part of this
S2: suite of products, obviously, uh, which includes like files and
S2: chat and all the posture and settings that come with
S2: the productivity suites. And we kind of want to broaden
S2: and cover more and more of that. Uh, and so
S2: the really new thing for us is broadening beyond email.
S2: We did that with Google Drive. Um, we plan to
S2: do something similar on the Microsoft side in the future. Um,
S2: and then, uh, where it gets really interesting though, is
S2: you now unlock kind of new types of correlations. You
S2: can do if you have access to content, uh, settings
S2: and logs, you can really correlate these things together. So
S2: like let me give you a simple example. Um, let's
S2: say that I have a Google group that allows external
S2: people to post to it. That is a very common
S2: thing that exists in basically every company because you have
S2: like support at or you have like, you know, help
S2: at or whatever. But now let's say that that Google
S2: Group also has weak moderation settings, spam moderation settings, which,
S2: by the way, is their default for Google groups. Don't
S2: ask me why, but that's the default. Okay, so that's
S2: a little worse because now I can like, use this
S2: Google group to send you, uh, malicious emails that may
S2: bypass your like, existing controls because the spam moderation settings
S2: are lower. So that's those two things are a little
S2: bit worse. And now let's say that that same Google
S2: group is actually the one that like your CEO is
S2: a member of, or you're like, finance guy is a
S2: member of. Now it's like even worse because it's like, okay, well,
S2: if I want to like do like a high profile attack,
S2: I have now a path into a VIP. So in
S2: Google Workspace today to get each of these three signals
S2: are different API calls. Um, and you have to kind
S2: of correlate them together and write your own detection in
S2: the future. What we want to do with material is
S2: like basically have our threat research team come up with
S2: a lot of these common scenarios that we see express
S2: them as detections that just come out of the box
S2: and help you really attack these and, and leverage the
S2: fact that we have the content access, but we also
S2: have the, uh, settings and log data access, because when
S2: you can put those three things together, that's where like
S2: you can build some really high signal detections. One big
S2: problem with Cspm, since we were talking about them in
S2: the past, is a long time, uh, ago, like people
S2: kind of almost gave up on them because they used
S2: to have so much noise. Right? It's like it was untenable.
S2: It's like you go in, it's like million issues detected
S2: and you're like, great, I'm never going to do anything
S2: about this. What I think the modern Cspm did a
S2: really good job with, you know, like, I'm like, thinking of, like,
S2: The Wiz or Orca's of the world. Is. He said, well,
S2: actually we are going to have a million issues, but
S2: out of those million, there's probably 40 that you really, really,
S2: really need to address. And those are like these, uh,
S2: those are those like attack paths, the ones that like,
S2: correlate 3 or 4 different things together, and they raise
S2: the severity of that detection. Um, I think it's a
S2: really smart model. And I think it's kind of what
S2: we want to do on the, on the, uh, workspace side.
S1: Yeah, I love that. I feel like everything is going
S1: eventually towards this, uh, inevitable place, which is gather all
S1: the context and point intelligence at it.
S3: Yeah. Right.
S1: And so I love the fact that you're bringing together
S1: all that different context, the state of the configuration of
S1: the platform.
S3: Yes.
S1: The things you're concerned about, actual logs plus threat intelligence.
S1: Now you've got a real picture.
S2: Exactly. And this was kind of the promise of XDR
S2: or whatever. But I think that the, the challenge is
S2: that like if you try to do it for all
S2: security across all platforms, it really does feel like a
S2: gnarly kind of untenable problem. So where I think people
S2: have done a good job is where they've kind of
S2: carved a boundary so that they can focus and kind
S2: of go deep. Uh, the thing that I think hasn't
S2: worked is when you kind of create like a very
S2: horizontal products that are a mile wide and an inch
S2: deep because they just can't really get to the to
S2: the true insights, and they end up just spamming you
S2: with something that's like, yes, it's a risk, but is
S2: it really your top priority? And you just, you know,
S2: I've talked to some CISOs who talk about those products, uh,
S2: as like kind of report card products where it's like,
S2: let's just make you feel bad, you know, and it's like, yeah, yeah,
S2: like much to do. I think what, what we are
S2: interested in is trying to find the balance between, yeah,
S2: broadened beyond email, but kind of still focus really on
S2: this productivity suite so that you can still go deep
S2: and not get overextended. Um, and it's a it's a
S2: tricky balance, but I think like that kind of going
S2: into the full XDR thing is probably a little too broad. Yeah.
S3: Well, cool.
S1: Where can people learn more about material?
S2: Yeah. Head over to material Dot security. We try to,
S2: you know, explain what we do in really simple terms.
S2: There's like videos and stuff that show how the product works.
S2: So that's the best way to learn about material and
S2: reach out if you'd like to learn more.
S1: Awesome. Well, I love the approach. I love the way
S1: you're thinking about this. It's exactly the way that I
S1: would approach this. Awesome. So I really, really great to
S1: hear it. And, uh, I enjoyed the conversation.
S2: Yeah. Me too. Thank you so much.
S1: All right. Take care. See you.