Risky Business - Risky Biz Soap Box: Why AI shouldn't really change your security controls

Episode Date: June 28, 2024

This is a sponsored Soap Box edition of the Risky Business podcast. Abhishek Agrawal is the CEO and co-founder of Material Security, an email security company that locks down cloud email archives. Attackers have been raiding mailspools since hacking has existed, and with those mailspools now in the cloud with services like o365 and Google Workspace, guess where the attackers are going? Material built a product that helps you lock up your email data, to archive and redact sensitive information. The idea is to really just limit what an attacker can do with email data if they pop an account. Abhishek joined me to talk about a few things, like how non phishing resistant MFA is basically dead, how email content is very useful to security programs, and about how the gen AI won’t really change much on the defensive control side.

Hi everyone and welcome to this special Soapbox edition of the show. My name is Patrick Gray. In these Soapbox editions, we talk to sponsors about their view of things and yes, they are sponsored podcasts, which means everyone you hear in a Soapbox edition of this show paid to be here. Abhishek Agrawal is the chief executive and co-founder of Material Security, which built a product that helps you lock up your cloud email data to archive some stuff, redact other stuff. And, you know, if a user wants to unarchive or unredact, they can do step-up authentication and it's really not a problem. So the idea really is to just limit what an attacker can do with email data if they pop an account. Anyway, Abhishek Agrawal joined me for this discussion. We spoke about a few things like how non-phishing resistant MFA is just dead

and also about how the scale Gen AI will unlock for attackers won't really change all that much on the defensive control side because who cares if it's an automated attack for, you know, automated personalized attack versus a determined attacker, you know, your controls are going to be the same. But anyway, here is Abhishek Agrawal, a co-founder and chief executive of Materials Security. Enjoy. Good security controls always have been and always will be somewhat agnostic to how an attack was actually generated. You know, obviously, like we all like to talk about MFA in the security world, but like part of the reason it's such a good control is like, it almost doesn't matter how I took your like password or how I found your credential. Like it's just a good control. Like I could have

phished you with the most sophisticated campaign. I could have just asked you for your password. I could have read it off a posted note. Like the point is that the control sophisticated campaign. I could have just asked you for your password. I could have read it off a Post-it note. The point is that the control just applies. And so in email security in particular, I feel like with the Gen AI stuff, there has been a lot of attention, probably rightfully so, about, oh man, is this going to change the nature of attacks that people send? It's going to change the scale. I can personalize a lot more, a lot faster. But on the flip side, it's going to change the scale, I can personalize a lot more a lot faster. But on the flip side, it's that, well, shouldn't we have controls that don't really care whether the attack was generated by like, a very sophisticated AI or extremely determined human? Because at the end of the day, like the thing that they create, yes, it will vary in scale, because a human can't like,

do the same research or whatever at 100x the scale but they can do it once and if you can kind of detect that one thing then it shouldn't really matter if you can detect 100x of that so i think that yes it is an arms race kind of always has been but also i think it it sort of increases the need for security controls that are somewhat agnostic to how the attack was generated. Oh, look, I totally agree with you. I mean, it's interesting you mentioned MFA though, because it's actually one of the areas where I see the biggest problem in security writ large at the moment, because a lot of these, you know, phishing as a service kits are really good

at extracting and relaying, you know, one-time passwords, right? So it's like phishing kits have absolutely moved towards token theft. Yes. And the only way to fix that is, you know, FIDO2. Yeah. So you've got your, you know, your YubiKey approach and then your, you know, your Passkey approach

and Microsoft Authenticator, I believe, is supporting Passkeys now, which is useful. But then you've got, then you start bumping into reset flow problems and whatever. Code-based MFA, to me, I mean, it just seems next to useless, to be honest. Yeah, I think TOTP, code-based MFA,

I think people, there is general awareness now that that's not a good mechanism. You know, it's better than nothing, I would argue, but it's not a good mechanism. Barely. Barely. And there is also a raising awareness about trying to have push-resistant MFA. I agree with you, though. It's not nearly deployed as broadly as it should be.

But I think you bring up a good point, even with MFA. But I think it sort of proves what I was saying earlier. If the only control you have is auth, well, you know, attackers are going to start figuring out how to bypass auth. And I think for a long time, people saw MFA as the silver bullet. They're like, oh, great. Like, I've got MFA. Auth is going to be really hard to bypass. Now I can just rely on that and have to not worry about kind of other issues. And I mean, you know, the history of our company and our whole philosophy

about, well, like there is no silver bullet and auth isn't one of them either. Like authentication into the account is great, but it's not going to be, it's going to be bypassable if that becomes where the sort of battleground shifts to. So you need controls that are effective even past that point. I just don't know that I, I guess the thing I push back on sometimes is, yes, the AI stuff totally changes the threat landscape in some ways, because you're going to see a scale and a level of personalization that I think would have been hard to do in the past. But on the flip side, I don't think that it really changes how to think about some of the problems in this area if you are going and thinking beyond detection. If the only thing you're thinking about is detection, then yes, you have to keep up with the arms race.

But if you're trying to build controls that are not just around the detection side, then I think you've kind of always been thinking about the problem in different terms. I mean, I think one of the things that's really interesting about all this GenII stuff is where it probably is going to be most useful to attackers is in a crime type or to a crime type, which is actually the big money spinner. And it's the most successful crime type, which is BEC, where you're not even necessarily doing a compromise. You know, you might be using lookalike accounts or whatever. And yeah, I mean, that stuff is crazy. And you're not going to fix that with auth, right? That is purely going to be a detection

play. And at that point, you know, okay, there's the compromised account side, but then there's also the lookalike domains and people slipping into, you know, existing threads and things like that. I mean, you know, this is not a, yeah, this is not a problem that's solved with auth, right? I think BEC is the slam dunk argument that you still need to be doing something with your email. Yeah, absolutely. Absolutely. And I, you know, even if you think about like specific types of BEC, there's obviously just like the traditional kind of invoice fraud, like lookalike domain spoofing, whatever, I get you to just do a financial transaction. And then there's things like, I actually take over an account, I go through the contents in that account to understand what like normal communication looks like. And I try to replicate that to carry out further attacks. Well, LLMs are going to be handy there. Yeah. You can throw an LLM at a corpus of

data and say, like, make me sound like this person. Yeah. Unless some of that data is, you know, redacted and put behind a layer of authentication, right? So yes, obviously, you know where I'm going with that. But I think that's kind of what I mean. Like, you have to invest in controls that are agnostic to the type of attack. And then you also have to invest in detection. It's just, it's just both. And, and, and that's where I feel like some of this stuff absolutely changes the game on what the defenders need to do. But in other ways, it's kind of doing the same thing you've always been doing. Now, these days, I mean, it's interesting what you just said there about the redactions and whatnot, because obviously where material started

off was offering, you know, a solution that would lock up people's mail spores, right? So that if someone does do an ATO on a 0365 account or a Google workspace account or whatever, they can only access so much, right? So you're trying to limit the damage when an account takeover happens. Yep. You know, these days you've sort of broadened the company. You're kind of competing more in the generic email security space. Yeah.

But of the people who are really going to town with the redaction stuff, what's the motivation there? Is it mostly a compliance thing? Yeah. So a couple of things. I mean, one, you sort of keep seeing large email data breaches. So, you know, like Midnight Blizzard stormed 8 last year. There's definitely more and more awareness of the fact that, hey, my mail store is a content repository, just like other content repositories

in my company. And in the same way that I try to have the right access controls or sensitive data governance on those content repositories to avoid breaches, I need something similar on my email. So that's not really a compliance thing. It's a security thing that's motivated by some of the data breaches that people are seeing. Well, that's what I wondered because, I mean, you can't really have a compliance regime that says you need to do this when there's really, beyond you, I don't really know of any other vendors that do this, right? So that's a bit hard. That's correct. The compliance and legal solution to this, which is the other motivator that I was going to get to, has always been to just delete old email, right? Like, hey, we don't want to carry the risk. And we also don't want to keep email from a discovery standpoint. So just delete things

that are older than X period of time. Well, that can get you into other forms of trouble. But anyway, yeah, yeah. I mean, obviously, ideally, you're not deleting things that are under legal hold. But my point is, like people implement a retention policy, and they say, any email older than five years or six years or whatever, we're going to delete, which obviously people bypass in awkward ways. Like they start sending things to themselves on their personal accounts or they abuse like a keep label or they fight about how long the retention period should be. And so I think that another motivating use case to your original question is, you know, folks will be thinking about a retention policy and they're trying to find a Goldilocks zone

where they're enabling their users and business to still access old mail because that is useful sometimes. We all hoard mail for a reason without having to go the full draconian route of just straight up deleting it, but also don't want to carry all the risk. So with Midnight Blizzard,

Microsoft's own executives' email accounts getting compromised definitely doesn't help. people feel very secure about this so uh we have you know some very large customers where uh it's almost a board level concern like hey how does this recent event affect our strategy um so what is that what is unique about because this is a tiny slice of the market right as you said like big customers there's some big orgs that are interested in this. I imagine you probably had some interesting calls with the State Department after this, for example, right? That's right.

And so, I mean, the question becomes like, what is unique about the sorts of companies that, you know, what do they have in common, the sorts of orgs that actually do this? Yeah. So, you know, early on, I think kind of the usual suspects would be industries that are heavily regulated. So financial services, healthcare, the basically where your email system gathers a lot of data that is in any other content repository would be heavily regulated. There's a lot of compliance, right? Like, for example, like, if I said, Oh, yeah, there's companies just keeping patient records in their, I don't know, OneDrive, you'd be like, Oh, that probably sounds like a compliance violation. Like, are they supposed to have that?

But if I said it's an email, you'd be like, yeah, that probably happens all the time. And like, companies don't even know. So I think early days, yeah, financial services, healthcare, heavily regulated industries where they collect a lot of this sensitive data and worry about it. But something interesting has happened over time, which is that as there's been kind of more awareness around this problem, and as we have been talking to folks about kind of a holistic email security solution where it's not just the inbound email detection, it's also worrying about what does happen in the case of an account takeover or what does happen with an insider. Actually, we're seeing a lot of interest even in the mid-market with our email data protection product because what happens is, truthfully, folks are thinking, if I'm going to spend a single dollar on email security

that is supplementing my Microsoft or Google built-in email security, then am I going to spend it on just an additional layer that is trying to block two more emails that would have gotten through or 10 more emails? Or should I also be thinking about some of these data risks or identity risks that we help with related to email? Not instead of the inbound email security, but in addition to. No, no, I'm with you, right? Because I've always said about the inbound email security, but in addition to. I'm with you, right? Because I've always said about the big email security companies, one of which I do business with, right, is that they don't turn the raw sewage of crap that comes through their gateways into drinkable water.

They turn it more into water that you can shower with, but maybe not drink, right? So I 100% get what you mean. Like, you know, it's never going to be a replacement, an email security gateway, or even an API based product. It's never going to be a substitute for having compensating controls on the end point for when things get through. Right. Like you're not going to ditch CrowdStrike because you're using a major email security platform. So I kind of understand the rationale there where it's like, well, why don't we do this different feature? Seeing as we're already getting at least some level of protection from the- Yeah. And specifically what I was trying to highlight

is that I initially thought kind of like what you implied earlier, where there's going to be a unique segment of the market where some of the sensitive data in mail that collects in the archives is of particular urgent interest, and that's where people are really going to focus. What we've seen recently is that even in the mid-market, even in smaller companies, if they're selecting an email security solution broadly, either because they skipped the whole gateway generation or because they are trying to enhance or supplement the gateway they have, What they're saying to themselves is, well, inbound email security and blocking attacks is one part of the problem.

But account takeovers and thinking about what someone would do if they did compromise a mailbox, some of these use cases are popping up as well. And so they're interested in picking kind of a holistic solution. That's what we've been observing. Well, and there's been this big shift in email security, right? Where until a few years ago, everybody was operating this as a pass-through like, you know, MTA, right? It was a mail transfer agent. Yep. Then funnily enough, one of the companies that really innovated there was Trend Micro. They had one of the first like early Microsoft 365 API based mail security products. Right, right.

But it was limited in what you could do because the APIs weren't actually that good. But I remember talking to them about it and, you know, their greatest party trick was doing a demo install with the customer like over lunch. Where they'd just be like, I just need this sort of key and you know, it's used temporarily to provision and then we nuke the key and then like, there you go. It's installed. Right. Yeah. And that was always the, that was always the advantage of those API based products. And now what I've noticed is everybody's kind of doing both. Right. A lot of people are doing both,

but also that the efficacy of the API based products has kind of caught up to the, to the MTA based products. Right. And some are doing both, but also that the efficacy of the API-based products has kind of caught up to the MTA-based products, right? And some are doing both. Like, what's your view on that? I mean, obviously with the sort of stuff that you're doing, you're always going to have that API component, but are you also doing an MTA-based, like an actual ESG-based product as well, or you're just all on API? No, we are fully API based. And the reason for that is that we think it's fundamentally a better architecture to supplement the security

that you're already getting with Microsoft or Google for your email security. So you're like, okay, they've got that MTA piece. Yes. We don't need to duplicate that. Like sure, we can maybe be a bit more effective, but what we can really do is add value with the API based stuff. That's correct. And the, you know, you mentioned a fast integration, like, you know, back then with Trend Micro was over a lunch break. Now would be like, you know, literally minutes to get an integration with the OAuth grant. Well, that's what they meant. Like this is during the sales meeting at lunch. They'd just be like, give me your phone. And here we go. So that sort of like small integration lift is awesome. The fact that you can be very targeted with the user population that you deploy on is great. So there's all these advantages to the

API based approach. But probably the biggest one is that I think that the types of remediations you can do are really, really granular. If I have a gateway, historically in the past, it would have like a few seconds to examine a message, make a determination if it's good or bad. It doesn't want to add too much latency to your email system, so it can't hold on to it for too long. If it decides that it doesn't want to let it through, that's it. That's all it can do. It just kind of black holes it, right? We've seen them rewriting URLs as well, right? Like some of them do that. Yeah. And they would rewrite certain URLs or all URLs and then kind of be trying to like do an additional pass on the URL at runtime. I think that one of the key innovations with the API stuff

was that not only do you have more time post-delivery to make these assessments, but you can change your mind on the assessment several times as you learn more information. And then you can remediate in a dynamic way, depending on your confidence or severity of the message. No, I get what you mean. Like you see one, you let it through and then you see 500 and you realize that it's something bad and then you can retrospectively go into those mailboxes and remove the messages. Yeah. or like, for example, if you have lower confidence in a message, maybe you leave it in the mailbox,

but put a banner on it or rewrite the link to have a speed bump. But if you have very high confidence that it's malicious, you actually go and move it to quarantine or spam or whatever. So just the fact that you can be pretty dynamic in your remediation, vary it based on severity, and do it post delivery and change your mind if you learn more. It just is an architecture that I think enables a lot more flexibility. Yeah. Now, one thing we've got to discuss that's here in our

notes is you say that analysts and vendors have been promoting human-centric security in the email space, largely looking at additional communications channels that could be compromised and where data could be exfiltrated. But you're saying this is all just talk and there's little evidence that Slack or Zoom comms are like high value targets. I'm going to push back a little bit on you with the Slack one, right? Because we've seen so many times that attackers have been able to get Slack access and then pivot because people dump creds into Slack. Like one of my team members did that recently. And I just said to him, like, what the are you doing? Like, please let's delete that and reset it because it was a,

it was a cred for, for, for an app that we use. And yeah, I mean, I just sort of think that stuff is important too. You disagree? No, I, I, you No, let me clarify it. So first of all, I think the kind of emphasis on the human element or whatever the sort of latest terminology is, I mean, it makes sense. Like, you know, you have an application that every single person in your enterprise is using day in and day out that is an open protocol that anybody on the internet can send them a message with. It is obviously a really big surface to worry about. And I think this kind of narrative around, hey, well, people are using this, they're going to make mistakes. That's not new. That's been just kind of remarketed over and over, in my opinion. I think what we mean specifically when

we push back on the Slack and Zoom is that obviously those like Slack is a fantastic target. But when we talk about communication channels that are actually being used to deliver attacks, what we haven't seen personally in the while too much is, you know, Zoom chat or Slack messages being used to actually deliver a payload. Is it a target? Absolutely. And as you know, one of the things that we do is try to stop folks that have taken over an email account from pivoting into something like Slack via password reset. We try to stop that from happening. That's a really nice feature that you have actually is to be able to say, put some speed bumps on password resets.

Yeah. Just because I have access to an email account, should I have access to every account attached to that email account? Like probably not. Yeah, so for listeners who might not be aware, like if you are a Material customer and you've got this set up, if one of your users receives, like they get their account popped and you haven't detected it, they get a password reset.

In order to like decloak the URL to to complete the reset uh material can force an mfa um you know an mfa prompt basically so that would cause some trouble for an attacker and i think you can instrument like questions via slack and whatever like did you mean to do this and yeah that's exactly right yeah yeah yeah but my point is that so the recognition that slack is a target no pushback whatsoever there. I completely agree. I mean, in the same way that emails. But you're just saying they're not going to start their attacks there. Yeah.

Like I haven't heard of someone being like, I got phished because like someone sent me a phishing link over Slack like that. I mean, I have heard it. I have heard of it happening via LinkedIn though. And I think Teams maybe. Yeah. Yeah. I think, you know, LinkedIn for sure.

Again, because there's a lot of external kind of inbound, you know, similarly, in Slack and Teams, in theory, you know, if you have an external guest, that external gets account gets popped, they can then use be used for further attacks. We're just not seeing that at anywhere near the volume of like email. That's not to say it never happens. It's just, I think, I think that's, in my opinion, the wrong interpretation of the human element. I think if you're talking about, hey, there's a productivity suite that people spend all day in, and email security is just one aspect of that productivity suite. And you need security coverage on that in the same way that you have coverage on the endpoint or you have coverage in the cloud workloads. Of course, we completely agree. And actually, that's a lot of what like materials future direction is focused on, specifically other aspects of Google Workspace or M365 that are beyond email.

But as a delivery mechanism, as a, you know, pure like threat detection play, probably not the areas that I would focus on first. What proportion of your customers would you say are actually using that email archiving and step up auth protection and stuff? Is it a big percentage or 50-50? No, I would say it's actually greater than 50%. So it's definitely not as small.

It's actually the majority of our customers are using the data protection products because again, as I was mentioning earlier, even smaller customers, even kind of mid-market companies are really embracing the need for that kind of control. Obviously, inbound email security and some of the things that we do around abuse mailbox automation, things like that are very popular as well. So we do have a large number of customers that are only using things like on the inbound email security side, but the data protection stuff is definitely not some niche minority. It is, you know, a majority of our customers are using it in some fashion. If not to do the exact redaction, then definitely to at least do the sensitive content classification, get visibility, get kind of like alerting and telemetry around how sensitive data is being used.

That looks like a social security number. Might just redact that one. Yeah, yeah, yeah, exactly. That kind of thing. Yeah. Yeah. Or like, hey, why is this user sending messages with sensitive data to a personal account? Or they have an auto forward setup that last month, you know, sent like tons of company confidential data to a personal account that's have an auto forward setup that last month, you know, sent like tons of company confidential data to a personal account that's not supposed to happen. So just the telemetry on it ends up being pretty important, but yeah, you'd be surprised. The data protection

stuff is pretty widely adopted. Now, I know this doesn't necessarily connect one-to-one with the stuff you do, but I'm curious to get your thoughts on what you think the role of like, because we're seeing this emerging category now of like ITDR. And I don't think anyone really has a clear definition of what an identity threat detection and response product looks like or what it should do. But I think it's at least good that people are thinking about this whole concept of identity as the new perimeter and whatever. So, I mean, what you've got is a product which is like, well, we can limit the damage when an identity is compromised, right? Yes, yes.

But where are you seeing people doing cool stuff around identity protection in the first place? Because I'm just curious, right? Because you would have some thoughts there, I'm sure. You know, I think it's really interesting because my sort of, and like you said, the meaning of ITDR is probably still evolving. Yeah. It's like two people who offer completely different products that do completely different things. And they're like, I'm an ITDR.

So like that's a heavy caveat on like the space itself, like obviously is evolving and like my understanding is minimal there. But like I would say that from my perspective, it sounds like the very first kind of natural use case for ITDR was, you know, when you didn't have IDPs, let's say like you just take Microsoft as an example. You sign in using a username and password. Well, they offered a product security alert back in the day that was like, hey, you know, you have a suspicious sign in because things like impossible travel or like, you know, the bad IP or whatever. I mean, this is like not a new thing. This is very old. But then you kind of shift to using an IDP. And now all of a sudden it's not just a Microsoft application. You have all these

applications that are behind a single identity provider. But that's fine, right? Because they all give you really, really high quality logs. Oh, wait. Well, exactly. So that's my point. Not only do you now not have the telemetry on that, but even if you do have the telemetry, who writes detections against that telemetry? And I would argue it should be the identity provider. But because they have it for whatever reason, now we have a space called ITDR, which is like products that are like, you know what? I'll ingest the telemetry and I'll write the detections on that for you. But in my opinion, it's really something that is, I mean, how can you be an identity provider and not be telling me if something that may have abused my identity? I got a bit of sympathy for the IDPs here. Like I had the chief architect of

Okta on the show a while ago, and he basically turned up to beg app developers to start integrating some of these features, right? So that they could provide telemetry and enable things like, you know, universal logout, which isn't supported by most applications, but it is by the IDP. And I think that's one of the issues here is it's so, it's so fractured. And he, you know, his whole thing when he was on the show is like begging CISOs to start putting this into their procurement documents where you have to support these features to try to get app developers to do it. But I mean, I guess that's interesting. That's still the R part of ITDR, right? Like they could still do I, T, and D. Yeah, yeah, yeah.

So I think like, yeah, it's fair that like you can't do the response entirely yourself because you need the developers to integrate those features. But I think, you know, basically companies like Okta, I also sympathize with them, but they did a fantastic job of convincing a lot of folks that, hey, you can outsource the problem of identity to me. And that has a lot of benefits. And I buy that pitch. I agree with that pitch. Well, that's why everybody uses it, right? Yes.

Yes. But then I think they're sort of implicitly saying that we also take responsibility for securing that identity. And I don't think they would disagree with that. And I think they will have an ITDR play and already do. But my point is that ITDR, in my opinion, the simplest kind of explanation of it is like, yes, you have these identity providers. We all kind of centralized on them. They have telemetry or not. But even if they have the telemetry, they're not doing detections on top of that telemetry. And that created this market for ITDR.

Personally, I feel like that should just be part of the identity platform, but call me old school. Yeah, no, no. I'm with you. But I mean, I guess the reason I asked about that is because surely if you've got decent identity protections in place, like the need to redact data out of mail spools is somewhat reduced. But I guess my point raising it is like we're nowhere near the point where that is something you can rely on yet. But it's just, you know, it's a burgeoning field. I just wanted to get your thoughts on it. No, no. I, yeah, I get your point. But I think

even that, right? Compromising identity is not the only way to compromise the content of a mail store. For example, if I have some malware on a personal device where email is being accessed from, I don't need to compromise your identity. I didn't need to like compromise authentication into the mail account. I can just access the content in another way because I have, you know, malware on the device. Or if I have a malicious browser extension, I didn't really compromise identity. I just, you know, was able to read the contents of your mailbox in another way. if you know i was able to forge a token with the you know uh native email provider just hypothetically just hypothetically speaking not like not like this actually happened and resulted in a csrb report that is causing microsoft all

sorts of drama right now yeah yeah i didn't there's no identity compromise there's just like i just figured out a way to like literally an identity token. Well, there was an identity issue there, which is identity compromise. And the identity that was compromised was all of them. Yeah, that's maybe what I mean. The provider's identity maybe was compromised. I would argue that an ITDR product probably would not have detected that identity compromise. Yeah, exactly. So, so I, I, I actually disagree that it, um, identity controls alone would reduce the need for these kinds of, um, content controls. Uh, but you're right. I mean,

certainly if you don't have good identity controls, that's like leaving the door open. So you should, but, um, I don't think it's really the only way that people, uh, access these content stores. And real quick, uh, just, you know, because we're getting towards the end of this now, what's next for you? You know, what's on the roadmap? What can we expect to see out of the material? Because, you know, you've always got some left of field ideas. So let's hear it. You know, the thing that we are really obsessed with, I briefly talked about it on the show before, is we are still very interested in Google Workspace and Microsoft 365. We talk a lot about those two applications in particular because they are so ubiquitous. We talk about them as a stable duopoly, right? There's only two options and every company uses one of them.

And we got our start in email security, but I mean, email is just one application that is part of that suite. And we haven't really seen anybody try to go focus on that suite without going and now trying to cover 50 different apps in a kind of an SSPM type of play. So we're really interested in seeing if we can broaden out of email, but stay focused on the productivity suite defined by M35 and Google Workspace, which means, you know, thinking about files. It means thinking about the posture of those environments in general, giving you telemetry. Telling you when a tenant is insanely configured, that sort of thing. Yeah, that kind of thing, because these two apps are just, they're so important. And they represent so much for a company. You know, they are, I like to say it's like the first app you get when you join a company and it's the last one that's taken away from you when you leave.

And it's pretty much the only app, maybe except a few others that everybody in the organization has a license to. So it's this very broad, very universally accessed thing that, ironically, there's no security platform other than the native providers, obviously, that are trying to focus on it. What are you doing with OneDrive and GDrive? So we launched a product around Google Drive earlier this year. Yeah, because I remember that. That's why I asked, right? Yeah. So what we're doing is really tackling the problem of excessive sharing that happens in these systems. So, you know, we heard from our customers where, companies that have a breach around that. But I mean, a Google doc with all your sensitive data open to the internet is kind of the same thing. Well, I mean, you know, people forget that it's

like if you're sharing with a non G drive user, right? Like that is just a URL that anyone can access. That's exactly right. So, you know, very, very simple things like first classify the sensitive content that's actually in these stores. So we are very good at that. We've noticed that a lot of the built-in capabilities for that are pretty poor. So we are really good at high precision classifying the content. Second, letting you very quickly say things like a file with this type of sensitive content, if it lives in a shared drive and it also is older than months, and it's been shared with a personal Gmail address, please revoke the personal Gmail address automatically. Just defining that kind of automatic response is actually pretty hard.

So that's what we're doing there. But I think the thing that I'm more excited about more broadly is if you think about Google Workspace or M365, there's kind of three interesting data sets from a security standpoint. One is the content of things that people create in there, so file content, email content, et cetera. The second is all of the security logs that the provider gives you. And then the third is a snapshot of the settings data, how the tenant is configured, what account settings are on or off. If you have these three data sets and are willing to correlate them together, you can really write some pretty cool detections. You can look for pretty interesting types of attack tweets. People talk about identity is the new perimeter or whatever. I think these productivity suites are the new endpoint. Oh, 100%. Yeah, like you're doing all your work.

100%. I mean, I've actually said on the show a few times that an OAuth grant is the new RCE, right? Yeah, yeah. And 100% is. So if CrowdStrike is, you know, for the endpoints, then who is the CrowdStrike for these new endpoints that are the productivity suite?

That's the question. And I think that today that's sort of, you glue together a few different vendors to try to attack different parts of the problem. I don't think anyone has really tried to stitch those use cases together. Then come on, mate. Get your shit together.

Come on. Let's see it. Let's see it. All right, Abhishek Agrawal, great to talk to you. Great to see you. And right, Abhishek Agrawal, great to talk to you. Great to see you. And hopefully, you know, we can talk again soon and you can tell us about what you've been able to piece together in that space.

Always great to catch up with you. And yeah, talk to you soon. Yeah, likewise. Thanks for having me. That was Abhishek Agrawal there from Material Security. Big thanks to him for that. And big thanks to Material Security for being a risky business sponsor. You can find them at material.security.

And that is it from me today. I do hope you enjoyed it. I'll be back next week with more security news and analysis. But until then, I've been Patrick Gray. Thanks for listening.