EP41 Beyond Phishing: Email Security Isn't Solved

Security.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Tim Peacock, the product manager for threat detection here in Google Cloud, and Anton Chuvakin, a reformed, tamed, civilized former analyst and member of the cloud security team. here at Google. You can find and subscribe to this podcast wherever you get your podcasts, as well as at our website, cloud.withgoogle.com/cloudsecurity/podcast. If you like our content and want it delivered to you piping hot every Monday afternoon, please do hit that subscribe button on your podcasting app of choice. You can follow the show and argue with your hosts on Twitter as well, twitter.com/cloudsecpodcast. Anton, we've got a really fun follow-up to last week's episode. talking about email security again, but from kind of a different angle.

It's interesting how for many security professionals, email security sounds like a problem we solved because they think first spam, then they think, I don't know, malware sent through email. And somehow the reactions I get if I say, oh, such and such is innovating in email security, people look at me funny and say, oh, but isn't it solved? And of course, phishing is not solved. But I mean, to me, email security is also not solved, not for good.

It's as if people are thinking about email as a network security problem rather than an application security problem.

Or a data security problem.

Yeah. So with that, let's turn it over to Ryan. Ryan, by way of introduction, is the CEO of Material Security and has had a long career in the security industry, which he will describe as we go through the show. So Ryan, when we think about traditional email security, what comes to mind to me is, you know, an IronPort or something like that. Maybe the Gmail work on anti-phishing. You guys are well beyond that. So what are you all up to?

Email security is sort of a subset of network security in most people's mind. Messages coming and going, like just more datagrams that must be thoroughly scanned and held and whatever. But we kind of treat it more like an AppSec problem and a little bit less like a NetSec problem. So the analogies are always fun, like a TSA agent or a bouncer that can't go in front of the club or whatever, right? When you have cloud email, you have APIs. Like, the A in API is application. So you can start to think about email more as like, well, how do people use it? Like, what do they do with it? You know, what are you actually worried about? Unless like a, you know, I must defend the universe against the malicious incoming email, or I must keep the company's secrets safe because clearly everyone is always forwarding things and that's the only way that data ever gets lost, right?

The only way.

It's a lot less about data coming and going. Yeah. And a lot more about email as an application. That sounds broad. Like, you know, obviously we have lots of stuff on the website, but even things like, oh wow, yeah, like email is the identity layer of the internet. So like, if you have my email, you can go and do password resets and take over my whole life, right? Things like that. So it's like, you know, what do people do after they compromise email? That's sort of our kind of guiding philosophy. What are you actually worried about in the application itself? A little bit less like just the traditional firewall thing.

So this kind of starts from a place of assuming that access to the inbox has been achieved by an adversary. If I have good hardware 2-factor and I've got good lockout reset on all of my accounts, do I need material security at that point?

The broad way of thinking, for example, might be, what does someone do after they compromise a mailbox? But if you want to kind of go beyond firewalls and get into this zero trust nirvana, you have to ask the question of, just because X happened, Y doesn't happen. And so one of the most famous ones with emails, somebody got in my email. What do they want to do? But there's a lot of other kind of— when we're designing our product, like, assume X, what does that imply about Y?

Hmm.

So the threat model that you're talking about, where someone is literally in the mailbox, that corresponds obviously to the kind of traditional John Podesta, Sony Pictures, even honestly, SolarWinds and Hafnium are attacks against email inboxes that don't involve phishing. There's plenty of ways to break into somebody's account besides just credential stuffing their non-MFA'd account. So even things like someone's an employee and they work at the company and they have a very tall mailbox with lots and lots of stuff in it and they decide to misuse it one day, right? There's a lot of different threat models that start with the bad guy in the mailbox. There's always fun ones of like, you left your laptop open at Starbucks and you were a VIP, and that person who's watching your laptop is not really watching your laptop, or maybe they're watching it a little too closely. OAuth phishing is like a thing.

Yep.

The Google Docs worm in 2017, thankfully, it's a little bit harder to register a Google client secret these days to get, you know, restricted scopes. But the point is, there's a lot of ways to break into mailboxes. Like, I mean, you compromise an endpoint, the first thing you do as an attacker usually is like open up email, because if you have the endpoint, like the sessions are really, really, really long. You know, you see all sorts of variants of this. Browser extensions that can read the DOM, you see this, people attack email with that because Gmail is a pretty thick web client. And if you have DOM access, you can do a lot of message interception and reading.

Mm-hmm.

Resilience in a threat model implies Okay, like someone is actually here, like what do they want? And so that's kind of our favorite model. Our product at this point does a lot of stuff.

So that's a resounding no. That's a really resounding no to, if I have 2-factor, I don't need this. This is an answer of, there's a gajillion ways to get in, there's a gajillion threat models, and even from somebody who's legitimately signed in, that inbox still, in a good thoughtful zero trust world, we should be thoughtful about what they're doing.

Yeah, broadly speaking. I mean, there's no silver bullets in any direction in security.

Shoot, I thought we'd finally found one.

Yeah, no, I mean, that That doesn't mean you shouldn't go and get a FIDO key and get 10 of them and use them as earrings that you can take off and authenticate to your personal Gmail account with. But you definitely shouldn't assume that you're safe now because the consequences are pretty disproportionate. It's always worth it for the bad guy to get in your email because the sheer number of things that they can know and do and just the amount of money you can steal, all the eggs are in kind of one big basket in most of these organizations. And so you're never done.

You're never done. Have you seen Orza's? Titan key earrings. Oh no, yours actually, at one point when we were first getting big about the Titan keys, they're quite small, the Titan chips themselves, the ones in our data center. He had stud-style earrings made out of them.

I'm friendly with the Yubico CEO, Stina, and she's super cool. And she told me that, you know, there's a little bit of gold in all the YubiKeys. And so somebody who got married, because Yubico, I think they're pretty close, so there was a Yubico marriage, you know, between 2 employees, and they took all the defective ones that were being sent back, and they got enough of them, and they melted the gold, and they made an engagement ring out of Yubico gold.

That is shocking. So speaking of fun startups, tell me about the founding of this, because I think it's an interesting story how all this came to be for your team.

I mean, I've been doing startups for a while. My first job, you know, while I was still in grad school at Stanford, was as like a first software engineer at a math department company. Your career in this ecosystem is very path-dependent, kind of depends where you start, but I started as more or less a first employee, you know, pre-funding. Everything I've done has been in startups since then with a brief stint at Dropbox for a while. You get kind of hooked on starting companies. If it goes so well, then you're afraid of failure and you never do another one. If it goes so poorly, then you go and, you know, work at a FAANG or whatever and you never, ever, ever think about Series A, B, C, D, E, F, G ever again. Just a happy person with like work-life balance or something.

Sounds awful.

But if you're me and it goes pretty well every time, then you really kind of keep stepping up the ladder of ambition. And so with this one, I left Dropbox in '16. Kind of knew I would do another company, and then Podesta got popped and I got disturbingly into that. And it happened on like a personal Gmail account where you can't roll out IronPort or Mimecast or Proofpoint or any of these things. And so I was like, you know, if all you had was the Gmail API, how would you protect this account? And you could try and build, you know, whatever next-generation API-driven Mimecast or something if you wanted to, but you can do so much more and you can't even do that very well. So it ended up kind of being like a really solid, useful constraint. When you're a programmer, you know that constraints actually can set you free. If you're like, well, I can't share state, so what am I going to do? Like, I'll invent MapReduce. Constraints are great. And the, like, what can I do with a lowly personal OAuth grant and a personal Gmail account ended up kind of being like the germ of a lot of techniques and ideas that now we sell to the most paranoid companies in the world. And we still protect a bunch of VIPs, which is cool. We didn't forget where we came from.

That's an awesome story. I love the constraint-driven model there. That's a really interesting story.

Necessity is the mother of invention, I believe someone said at some point.

Someone did say that. I think you just said it, but somebody said it before as well. One of the other interesting things on your company blog, which is definitely going to go into the linked material in this episode, listeners, is some thinking about security vendors. And I'm a dirty security vendor. I'm a PM of security products here at Google. I started my career as a security vendor at Shape Security. You've done a lot of thinking about how I could be a less dirty security vendor, and I like to think among the security vendors I'm not particularly dirty. Uh, what's your take on how to be a less bad security vendor?

Yeah, I mean, there is not an industry that hates its vendors more than the cybersecurity industry.

Why is that?

Because the vendors deserve it, frankly, a lot of the time. So there's a really classic little like paper online called The Market for Silver Bullets, which if you haven't read, you totally should.

We'll link to that as well, listeners.

It just kind of describes like from a pure like econ, almost like game theory perspective, the way that the cybersecurity market works. There's a lot of unknown with regards to efficacy. Buyers don't have perfect information, sellers don't have perfect information. There's an attacker in the picture who has imperfect information, but more than the defender or the dev vendor. So it's just challenging. Vendors have a huge incentive to overpromise. Buyers have a huge incentive to believe things that aren't true because I just want to be able to sleep at night for 5 minutes. And then on top of it, the economics of the market, where funding comes from, how companies work, because things are changing so fast in technology and security is the most change-heavy part because the emergent properties of every other change in tech blend together and end up kind of compounding. So if tech changes, like, N changes per year, and then you have M changes in a different vertical, emergent properties are either N times M or N to the M, however you want to deal with it.

Yeah.

Security, there's a lot going on. And so the big vendors that have distribution— I'm not going to name names, but you know who we're talking about.

No, no.

Like, they have, you know, a sales force and they have a book of business that lasts a long time, but they don't really know what to fill it with. And so they end up being incredibly acquisitive, and they buy all these little, like, base hits of things that seem to catch on. And it kind of just becomes like, turn the crank, shovel the security products into the security product boiler. and just sort of hope that the buyers are getting a portfolio of stuff. But then the other really hateable thing that enterprise software does in general is the tip of the spear in the organization is the sales team and the solutions architects, and then the customer success is kind of an afterthought.

Mm-hmm.

That's sort of some leftover from when we did perpetual software licensing, and you could just— shelfware was just as profitable as software that was being used. So as a result, people end up buying a lot of stuff, and then are they getting the most out of it? Does anybody even care? It's a crank that is turned, and then you don't even look at the sausage at the other end because that's customer success's job. So I just feel bad, frankly, for much of this ecosystem because it's more important than ever.

Mm-hmm.

I don't think cybersecurity is getting less important over time. It ends up being kind of the lens through which we're even analyzing the future of open societies at this point. I think Bob McMillan had a story in the Journal as we record this today about the Russians are back. SolarWinds 2, son of SolarWinds, it's here. So there's a culture problem in the cybersecurity industry. There's a market problem. We kind of need to fix both because it's all fun and games to whine about vendors and to try and evangelize your product by just sending people like AirPods in the mail to take like, you know, a meeting with you. But like these things, they do hurt the entire society that we live in, this behavior in the market.

So that sounds like sort of 4 problems here. There's just the market dynamics of security as an industry are different. We have adversaries involved and we have quality problems that go well beyond, say, a market for lemons. really is, and I've read that paper, it's an excellent paper, Market for Silver Bullets. We have the emergent complexity of securing systems that we're not responsible for, where those systems intersect in ways that are multiplicative in their complexity. We have the economics of acquisition that have emerged in our industry with dominant players snapping up up-and-comers. And then we have finally bad organizational design choices, not prioritizing customer success, which is in part driven again by economics. That's really interesting to me that sort of 4 independent threads in that answer Really, none of which are technology itself. Security is not hard because of technology. Security is hard because of economics.

Technology will do whatever you want it to. That's like the beauty and the sadness of it, right?

The horror of it.

You can kind of strangle a piece of technology and make it dance for you if you need to, but most problems in technology are human problems. Technology is largely amoral and the bits will go where we ask them to go. Yes.

Actually, I was talking to a data scientist the other day about torturing bits. On that topic, I want to click in a little bit on the marketing piece and on communicating to users about value of things. We've got a gajillion vendors out there, and if you walk around RSA, it feels like 2 gajillion. How do we, as a vendor, expect to cut through the noise and actually get a message to land? Like, how do you guys do that? How should anybody think about doing that?

People use the term like, where is their alpha? You know, like, where is their value as a strategy, right? It's a capital markets pricing theory, you know, word. So I tend to use it. Had a couple impressionable years hanging out with hedge funds, but—

I'm so sorry.

So where is the alpha? I changed my ways when I came back to California. If tech is what I love, then tech should be the product. Whenever someone's like, should I go work at a hedge fund? I'm like, do you love money or do you love technology? It's actually quite clear. And so they're like, well, money. I'm like, okay, then I'll miss you. Goodbye. Please get out of my ecosystem. The point is, when you're trying to think about where do you allocate your marketing budget as a vendor is one way to ask this question. And if you have a couple of million dollars burning a hole in your pocket because it's VC bonanza right now and anything with a pulse can raise God's own seed round or whatever, Basically, if everyone else is doing it, everybody else has millions of dollars too. I guess I'll like buy some ads and I'll start my own podcast or something, you know? That's a good idea. We'll do content marketing. We'll get the best content marketing ever. You know, like there's a playbook and everybody else is kind of running that playbook. So like marketing is the art of like standing out. But honestly, the one thing that has worked well for us and that's like fairly timeless is like work your butt off for your customers and then help them make referrals after you do. And then just be an awesome partner. 'Cause when you go and talk to buyers, buyers, like, they like to hear about things from their peers. So it's just like, do your best to earn someone's business, and then they'll want to tell their friends about you. And that's where people want to hear about stuff anyway. So like, I'll go on podcasts that are interesting, and you have a fantastic podcast, and you have deep conversations. Thank you. The point is, like, your customers are your best evangelists. So like, you can have the booth at RSA or whatever, right? But like, what's more important is like, you know, if your customers are in town, like, thank them to their face for the opportunity to serve them. And then, you know, if they have a friend with them, like, ask them to bring a friend, you know, that's like not that hard. So you can get a chain reaction with customers. If your product is good enough for customers to tell their friends, well, like customers beget customers beget customers, right? Customers as neutrons in the reactor of your business is like kind of how it should be.

Hmm.

Thermal customers.

Exactly. Yeah, I love it. So the thermodynamics approach to marketing, you heard it here first.

This is going to end up as a very wide-ranging episode, but I love that answer because when I was at Shape, one of our goals was not just to have happy customers, but was to get our buyers promoted. And we found that in cases where we're really knocking it out of the park, really solving the problem for the user, not only was the company happy, but the individual who ended up purchasing us and who was our champion, if they got promoted, they were our champion not just internally, but externally as well.

I don't think this is even cynical, but it's like enterprise software exists to get the person that bought it promoted.

Yeah.

Obviously, modular organizational incentives and whatever, whatever, but in an ideal world, that For me feels like honest work. Like enterprise software can be honest work. It's like a thing you have to explain to people.

We're getting close to time and I want to touch on 2 more things. One of the challenges that customers face when buying a new technology is it takes time to ramp up on it and get value out of it. And we still, even in a world of consumption pricing, end up with shelfware. What can we do to help people get value out of their security investments faster?

I think part of this is, you know, it's on the sell side. It's also on the buy side. Like, I think time to value is like the metric that you have to optimize for no matter who you are. If you're selling software, like, for example, our software, you press the button, you auth us wherever you want us to auth, and by the next meeting, we've ingested a huge chunk of the company's data, and we're telling you useful, valuable things even in advance of the fancier, more complex parts of our product. So by the second meeting of our eval process, you've got something that you can screenshot and put in an audit committee deck or show to the business side or whatever, right? So just try and help people. as fast as you possibly can if you're designing software. Like one of many silver linings of all of this, like, you know, SaaS stuff is that it's easier than ever to connect and integrate with things.

Mm-hmm.

And whenever someone's like giving me the grand master plan for their company, I'm like, how can you deploy it faster? How can you show value faster? Right? You know, when you're performance profiling a page, you have time to interactivity, right? You have TTI. If you're performance profiling your sales strategy, like you really want to have a lot of value quickly. Like don't make them wait for 6 months to see the value. Like how about next Tuesday? Right? Or instantaneous. Whatever you can.

Mm-hmm.

You just want to have a very clearly, crisply valuable wedge for your product. And then obviously some parts are more complicated, some parts, you know, require to read the manual or something, right? But like, make it as easy as you can. Like Google and Microsoft have done a great job of, you know, making these like really solid platforms that you can build on top of. And they've lowered the bar for integration to the extent that you can just make the customers glad that they're working with you faster than anybody else. As a buyer, demand this. You're like, I need to see value quickly. Like when you're dealing with vendors, That makes it a lot easier. Like, a lot of these things are very momentum-driven. Once you get into a rhythm of providing value to the customer, like, it's hard to stop and everyone's very glad.

That makes a lot of sense. So one more question and kind of related on the time-to aspect. A lot of security products require a lot of time to get value out of them. How do we fix that?

I mean, a part of it's how they're designed, right? Like the prototypical security product, you turn it on and it's an empty thing and it says, press here to create something you would like to alert on or whatever. Yeah, right. And every time you press that button, you're just, you know, ruining your life a little bit more. So it's a lot of it's how they're designed. My co-founder Abhishek is a very smart guy, and one of the blog posts on our site is a reprint of something that got printed, I think, in Fortune, where he's just like, how to design security products that don't require like tremendous amounts of babysitting and by proxy setup. It's part of honestly why the talent shortage is so bad in security, because it's a supply and demand thing. The supply of people is, you know, challenging, and the demands of the security products, not just the teams and management, right, but the demands of like Hi, if you want to use this, you need to stare at it and like configure it and spoon-feed it and tweak it constantly. The products are needy. Uh, so the same like kind of consumerization of IT, like, I don't want to think about it. Let me turn the DMARC button on.

Yeah, right.

You know, like things like that that used to be really, really hard that have been abstracted away and are made easy. Don't forget the designer and don't forget the PM when you're designing a security product. Use the data that you have access to. I'm a big fan of every security product should be at least a third, if not a half, an analytics product. There's no a security product should be empty on day one. Like, there's really great commodity infrastructure for analyzing data. You might as well, like, make the product feel full and have suggestions of how to use it out the box. And, like, this problem will get better. And don't just, like, send more alerts to people. Like, if you're blocking things, then you're probably sending alerts. You know, if you're not blocking things, you're sending alerts anyway. Like, the default security product is a damn beeper.

Yeah, yeah.

And, like, now we're shocked that we have a talent shortage and we hate all the products. It's because, like, the PM boxes The affordances that our PMs are bringing to these situations are remarkably the same. Just another thing that will yell at you and send you an email with a red exclamation mark on it. Like, so there are other ways to design security products. I swear to God.

It turns out that's true. When I was at Shape, we thought we had made it when one of our users posted a job description saying, must have 5 years experience with Shape Security. And they were, you know, they were looking for somebody to run the thing. We did think it was funny when we read that said 5 years, we were founded 3 years ago.

The new grad dilemma.

It is the new grad dilemma. Also contributing to the talent shortage in our industry, by the way. I want to wrap up with our traditional closing questions here on the podcast. First, one weird tip to improve email security, and then 2, beyond all of the great stuff we've mentioned, including for sure market for silver bullets, do you have a recommended reading for the audience?

So in terms of, I mean, how to be better at email, I would go and double-check all the account reset flows that you have, just because remember, once somebody gets in your email, they're going to spread. Most apps, shockingly, don't give you a non-email-oriented way to reset them. But if you can, like, go and double-check those because, like, people think, like, oh cool, I've got my SMS two-factor blah blah blah blah blah blah blah. But then email is still a single point of compromise for you. And if someone goes and password resets everything, you know, Twitter doesn't support SAML. Anyone Twitter is listening, it's my like standard canard of just please roll out SAML. I don't care how, I'll pay for it at the company level. You know, like, like, you know, presidents and stuff are on there. Like, just Just do it. It's okay. Just do it. But I think Twitter, for example, has a non-email password reset flow that you can turn on. Go and look at that. And if it doesn't, we have a part of our product that helps with this and whatever. It's just little things that you might not think about after you've rolled out a password manager and gotten FIDO keys for everything and whatever, whatever. So in terms of reading, most of my long-form reading tends to be more fundamentals. That's okay.

Those are great.

If you're thinking about doing a company, Crossing the Chasm is a good book, but pretty standard recommendation. It's not just for the thesis of the chasm. in the adoption lifecycle. It's just an introduction to how to think about different kinds of people and why they buy and sell things and whatever. Like, if you've ever used the term early adopter but you have no idea what like the Rogers Curve is and the bell curve, and you don't know what a late majority customer is or whatever, go and read a book about it. You'll start using the buzzwords a little more intelligently. It's, it's like highly worth it. Apart from that, I read a lot of history.

Hmm.

So if you have, you know, 20 years to spend, I highly recommend, you know, Will Durant's like Story of Civilization books. Like, they're old, but they're timeless, and it's just like beautiful Writing on the human condition. So I either take a very short view of things or I take a very long view of things.

Well, that's a fantastic answer. Ryan, thank you so much for joining us today. This was a super enjoyable conversation.

Yeah, thanks for having me on.

And now we are at time. Thank you very much for listening and, of course, for subscribing. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever else you get your podcasts. Also, you can find us at our website, cloud.withgoogle.com/podcast. cloudsecurity/podcast. Please subscribe so that you don't miss episodes that come out every Monday. You can follow us on Twitter, twitter.com/cloudsecpodcast. Your hosts are also on Twitter at twitter.com/cloudsecpodcast. Your hosts are also on Twitter, Anton_Chuvakin and _TimPeacock. Tweet at us, email us, argue with us, and if we like or hate what we hear, we can invite you to the next episode. See you on the next Cloud Security Podcast episode.