Sponsored: Material Security on how inboxes are targets, not just entry points
20:35 Share

Hello, this is Catalin Campano and this is a Risky Business Sponsor interview with Rajan Kapoor, VP of Customer Experience at Material Security. Welcome Rajan. Hi Catalin, it's great to be here. It's good to meet you. I think this is the first time I'm interviewing someone from Material Security. We've had sponsored interviews before, but it's been with other companies. And the first thing I do when Material Hands made upcoming sponsor is that I go look at their website.

And I went on your website and I kept reading email security company, email security company. But as I dove deep into the product and what you had to offer, it didn't look like a classic email security company. Initially, I thought, is it a workspace security company? But then you kind of realize that there's more to workspace. There can be a large number of applications that are not tied to email.

where you don't provide coverage. So I was thinking you're more like an inbox security company because lots of your...

services that you advertise on the website as material security capabilities. Don't necessarily target the email protocol and the emails coming down the wire. You don't need appliances. You're basically an app that integrates with the workspace and Microsoft 365 APIs. And then you work from there to secure not only what's coming in, in the inbox, but then spend a lot of time thinking what you could do later in the case of a compromise to secure the content of the inbox.

to secure the users, the operational security of the organization and its customers. Am I right in describing you more like an inbox security company? Yeah, so what you've picked up from our website is actually, it's accurate in that when material security launched, we launched with this view that email security has always

typically focused on stopping bad things from coming into a mailbox, you know, using the mailbox as a vector. And we're talking about, you know, classic phishing detections and protections. And then you look at the landscape, though, and you looked at some of the attacks that were happening, specifically the DNC attacks, the Democratic National Committee attacks here in 2016. But you can even go as far back to the Sony Pictures hack that happened a few years before that,

And what you see is that the mailbox is not just a vector, it's actually a target, right? That is where once someone gets access to infrastructure, those actors very quickly pivot to mailbox because the mailbox, because they know the data in there is very valuable. So we launched with email, but what we're doing right now is, you know, as we've worked with our customers, we've realized that the cloud office suite space, you know, so your Microsoft 365 and your Google workspace, they, they,

They're really hard to manage. And it's really hard to understand the data that's in there. So we are, we just launched a Google Drive product that does what we do for email. So protecting the contents at rest and helping companies understand what's in Drive and what's in email. And we are now focusing on helping our customers secure that cloud office platform that they're using. And, you know, so you're absolutely right. We started off with email and we were

protecting the contents of email at rest in the mailbox. And now we're moving to just overall helping our customers understand what's in their workspace altogether. But then there's a third component of this,

which is the configuration. Is your workspace, is your Microsoft 365 account service actually configured securely? Are you missing MFA somewhere? Is there someone forwarding all their emails out of the mailbox? Is there sensitive content in a file that's shared with a publicly available link so anyone on the internet can get to it? Things like that. And that's where we are today. We're protecting inboxes and I can dive more into that.

But we're also helping our customers kind of wrangle their cloud office suite. Or like a interface for the Azure backend, which I've heard it's quite cryptic in its wording of how secret features are described.

which is obviously enough to pay for it. I would pay for someone to translate the documentation to me. When I started at Material, I helped secure our corporate assets. At a startup, you wear a bunch of different hats. At the time, I was IT and CorpSec.

I remember trying to turn on MFA for Microsoft 365. We had it. It wasn't even like our environment. We were a Google shop, but we use Microsoft 365 for development and for, you know, just mirroring what our customers are doing. I swear I turned on MFA in like five different places and it still wasn't turned on. It was like a maze of like, where do you actually turn this thing on? Yeah.

So let's say when you start thinking about a new feature in material security, do you generally start by looking at an attack? Or are features in material security developed based on...

let's say Microsoft adds a new API function to their APIs and wonder how could you use that to secure inboxes or do you go and look at popular attack trends and use those to build your service? Because I'm generally curious how products are developed these days because some of them, you know,

practically look like they're completely separated from the threat matrix of a company these days? It's a little bit of all three. So the way we think about where to invest our resources is one,

A lot of our roadmap is guided by our customers. We have a really close relationship with the customers that we bring on and we meet with them regularly. We ask them what's working, what do they wish they had, what's not working. And our product team and our engineering team meet directly with the customers. There's not this translation layer, so they get to know each other pretty well.

The second thing we do is we do look at the landscape. We've been fortunate enough to hire a number of people who come from the security industry. For example, our product manager for phishing protection is a guy named Matt Muller who ran the SOC at Coinbase.

Our head of security is a guy named Chris Long, or Klong, as he's affectionately known, who just has an amazing background and is really well-respected in the industry. And so... And to be there, right? Exactly, right? And so we have these people that who, because they believe in what we're doing and see the direction that we're going, they come and work with us, and they're able to inform product as well. Like, hey, if I was a customer today, this is...

this is what we should be doing. And so how a feature or how a piece, a part of the product comes to life can be informed by a bunch of different things. And the hardest thing, the hardest thing is prioritizing. And so what we look for is where can we have the biggest impact in closing gaps in a customer's security posture? I'll go back to Google Drive again.

Understanding the contents of what is in your files that are in Drive is super, super, super hard for our customers. And we would talk to customers who had built

their own tooling internally and sometimes had up to like two or three FTEs dedicated to this. And it's kind of like, well, why? Why do you have to build this and manage it yourself? Why isn't there something that can do this for you? And so we went and met with those customers, you know, went through their journey, understood what they were looking for, understood what they wish they had. And then we released our drive product and those customers signed up and it made their lives much easier.

You say you have these meetings with customers, obviously many of them probably use ESGs, email security gateways. Do you think that the feedback they provide to you is something they wouldn't provide to a company like someone who provides ESGs? What I'm trying to ask is, do you get this feeling that they're viewing you as a way to protect post-compromise? Like, okay, we're relying on ESGs to detect incoming and relying on you to minimize the impact.

Some of our customers do. They look at us to complement or fill the gap of protecting the data at rest in the mailbox, and I can talk more about that. But some of our customers, they leverage Microsoft Defender as their gateway, right? And then they leverage us to kind of be that backstop to detect and remediate information

anything that Defender didn't catch. And then some of our customers will have a secure email gateway in place and also use us because no email gateway is 100% bulletproof. And they'll rely on our detections and our ability to take in user reports and then go triage and look for similar emails. So the reason they come to us, though, like looking inside the mailbox is...

it's a hard thing to do, right? And a lot of email, secure email gateway services out there, they just deal with data in transit. And some of them are trying to look at the mailbox, but they're not, they're really not doing a great job of it. And so you look at email, it's in transit, you have like milliseconds as a service to make a decision on whether to deliver that email or not. And then you have no way of going back and like,

fixing a mistake, right? If a true positive gets through, the email gateway is not going to be able to go and pull that email back out of the mailbox or mailboxes. And so that's, you know, that's the value of us is being that backstop. But then also, say a user reports something to us that wasn't detected by their email gateway, right?

we can go and look for that email or similar emails across all of the mailboxes and pull it out, right? Or modify it so the payload isn't there anymore. But that's all focused on pre-reach protections, right? That's stopping the email being used as a vector for attack. What no one else is really doing is thinking about the mailbox as a target for an attack.

And that's where our post-breach protections come in, where we can do a couple of things. We can, number one, give customers visibility into the mailbox, help them understand what's even in there. We can classify the emails, let you know, hey, there's social security numbers here, there's PII, there's source code, and let them know where that information sits, right? You have to understand your risk, and to understand your risk, you need to have visibility into something.

And then once we help the customers identify their risk and what's in the mailbox, we help them protect those emails. And this is where using an API gives us magic powers, superhuman powers. We can reach into the mailbox and actually remove the emails that have the sensitive content in them and replace them with a stub that says, hey, this email has sensitive content in it. If you want to look at it, you have to MFA. You have to go through the

So you're using Okta. You have to go through an Okta verify prompt, and then we'll put that email right back into the mailbox if it's successful. If not, if it's not successful, you've got really good signal that maybe something's going on in that mailbox. If MFA challenges start failing as someone's trying to access emails, then maybe that's something you want to look at as a security team and understand what's happening. So really...

trying to get the industry to move to thinking not just about pre-breach protections through these email gateways or through phishing protection,

But also, you know, considering how they're going to protect their data post-breach, the data at rest in the mailbox that these email gateways just can't get to. Do you usually see thread actors focusing on the content of the email inbox regularly? Or do you see thread actors gain access to your email inbox and then using it for phishing? I'm just curious, what would be a percentage of what you see?

For sure. We see both. And more often we see the attackers are, the first thing they want to do is get the contents of the mailbox because you can do so much with that, right? Email is still the number one collaboration tool in the world. Even if they don't use it right away, they just still want to have it. Exactly. Because it's such a content-rich repository and it's unmanaged, right? Like I said, no protections in place to stop them from doing that.

And we saw this, actually, we saw this at the end of last year with the Microsoft breaches that occurred. You know, they got, there was two breaches they announced pretty close together. The first was Chinese actors in the storm attacks went, you know, directly for State Department emails once they got access to State Departments at Microsoft 365 tenant. And in the second case, Midnight Blizzard went directly for Microsoft Corp's emails, like their own, you know, emails that they had on their own Microsoft 365 tenant, right?

And the attackers, again, they went right for email, right? And it's because the attackers know that they are going to find a lot in there that once they exfiltrate it, they can take their time, they can go through it, and they can find other attack vectors. Or they can find sensitive content that's in there and start to leverage that or sell that data immediately.

So yes, we absolutely see the attackers considering the mailbox as their primary target and going right to it. It's basically a file server for them, just exactly like Moveit. That's correct. That's right. They'll download it, look for it later, see who can extort and move on. That's right, because they're worried about losing persistent access. And the funny thing is,

Because of GDPR, Google has to give you a really easy way to get stuff out of a mailbox, right? And so they'll just leverage, in some cases, the very tools that were built to help consumers migrate their data. Is there a way how material can protect, like block that access function with an MFA? Yeah, so it's less about stopping access to the function and more about like,

If the data is not even there to begin with, if we pulled all the sensitive emails out of the mailbox and the attacker can't get to it, then, you know, because because let's say we block like access to that function, they will find other ways to exfiltrate this data. Right. And at the end of the day, if you if you just protect the data, you know, at rest, however they get in, whatever they try and do, they will not get access to this data. When you say you pull the data from the email inbox, where do you put it?

It's a great question, and that's a question that comes up frequently. I'd imagine someone working in government wouldn't like that being put in your cloud server, maybe their local server, something like that. We took an approach here that made a ton of sense, in my opinion, which is material is not like a multi-tenant SaaS service where we co-mingle all of our customers' data into one service. Instead, what we do is

stand up a single tenant Google Cloud project for every one of our customers. So we're basically giving them their own Google Cloud project

And then we give them owner access to that project if they want it, which means they can actually log in to the infrastructure that Material is running on. And they can get direct access to the tables that our application is running on. They can run their own queries. But even more important, they can configure that Google Cloud project to have the same tooling and the same visibility that they have

for other infrastructure that they're running. You can put like a wiz on there. They can attach the Google logs to their own SIM or their own SOAR. And they don't have to rely on what's in our product to get signal on is something bad happening here or who's logging into this instance and what are they doing. And it's kind of like, it is like on-prem. It's like the new on-prem, right? Because back in the days when I started working in IT, which is

longer ago than I'd like to admit, we had our own data centers and we would buy a server from Dell. We would put the software that we had bought on there and our team would be responsible for managing that infrastructure and keeping it healthy. What's different this time though is customers have access to that infrastructure and we can operate in one of three models.

The first is customers can use this as if we were just a SaaS product, just working in our UI, never really going into the infrastructure. And we carry the pager. If something goes wrong with the infrastructure, our engineers are being woken up and working on it to resolve it.

The second is what we call a mixed mode where we do give the customers owner access to that Google Cloud project because they want it and they put in their own tooling and signaling. But we're still responsible for keeping the infrastructure healthy. We're still carrying that pager. And then the third model is, and a handful of our customers do this, we get them set up and they kick us out completely.

And now their team carries the pager for that infrastructure. They're responsible for installing our updates and they're responsible for keeping that GCP instance healthy. And so you mentioned the old days of on-prem, right? It is exactly like that. That's how you can think of it. And we've unlocked a lot of objections by having this model.

Are you FedRAMP compliant? We are working towards becoming FedRAMP compliant now. We expect to have it, I think, middle of next year. It's a big investment. So we wanted to take a little bit of time here and make sure it was the right investment to make. And it turned out it was. We have a lot of excitement in government sector, both

both private and the government itself. Yeah, because the way you describe it, fixing data management basically deals with most of the FedRAMP compliance issues. That's right. And so since we have the single tenant instance, it was much easier than if we had a multi-tenant SaaS service that we then had to figure out how to make FedRAMP compliant. So...

There's another issue I want to ask you. How does material deal with this? So there's this scene of SimSwapper that uses it to gain access to your email and then use the email inbox to...

reset your passwords and gain access to other accounts to pivot to other online identities. Is there, let's say, any kind of alert in material where it can detect password reset spikes? Yeah, so this is exactly what we do with our identity protection product. Basically, we talked about how attackers get into the mailbox and the first thing they'll do is exfiltrate all the data in case they lose persistence.

very quickly after that, they will start to go and try and pivot to other services by triggering a password reset because your email address and your mailbox unfortunately is your identity on the internet a lot of times, right?

And so what we do is we look for those password reset emails coming in, and instead of delivering the password reset email, we'll put a stub in place again that requires MFA in order to unlock that password email, that password reset email. So you still have to go... And in a way, it's like applying...

you know, your single sign-on service to a non-single sign-on, like, enabled or protected application, right? You have to go through your identity provider in order to get that password reset email. All right. Thank you very much.

This was a very interesting conversation. Email is slowly becoming your new computer. Like the way you looked at protecting, like installing several layers of antivirus software on your personal PCs to keep it secure. Email is becoming that these days, right? And

And seeing a variation in email security services beyond detecting real-time wire traffic is the way you hope you see the industry evolve. So thank you very much for the talk today. Thanks, Adeline. It's great to be here.