EPISODE 1819

[INTRO]

[0:00:00] ANNOUNCER: A cryptocurrency exchange is a digital platform that allows users to buy, sell, and trade cryptocurrencies. These exchanges face unique security challenges that require specialized threat assessments and planning. Coinbase is a U.S.-based cryptocurrency exchange that was founded in 2012 and has evolved alongside cryptocurrency as a technology. Philip Martin is the Chief Security Officer at Coinbase. Prior to Coinbase, Philip built and led the Incident Response and Security Engineering teams at Palantir and was a U.S. Army Counterintelligence Agent and Arabic linguist. 

In this episode, Philip joins the podcast with Gregor Vand to talk about his career and security at Coinbase. Gregor Vand is a security-focused technologist and is the founder and CTO of Mailpass. Previously, Gregor was a CTO across cybersecurity, cyber-insurance, and general software engineering companies. He has been based in Asia Pacific for almost a decade and can be found via his profile at vand.hk.

[EPISODE]

[0:01:15] GV: Hi, Philip. Welcome to Software Engineering Daily.

[0:01:18] PM: Hi, Gregor. It's great to be here.

[0:01:19] GV: Yes. Philip, thank you so much for joining us today. You are the Chief Security Officer at Coinbase. So, we're going to be hearing all about financial security, obviously around cryptocurrencies. First of all, we're going to be hearing a bit more about what you did before Coinbase. So, what is your path to Coinbase and how did you get into this industry at all?

[0:01:39] PM: Sure. Like it was way back really. I knew I wanted to be a security practitioner when I was still in high school. I taught myself to code in my parents' proverbial basement. My parents don't have a basement, didn't have a basement, but I taught myself to code in high school. This was back in the nineties and started doing web design for local companies. I had a good time. I taught myself C, Perl, JavaScript, et cetera, and then ended up going to San Jose State for a bit for computer science, dropped out because it was incredibly boring. Joined a startup at the time that was building - it's called Cobalt Networks. It was building Linux-based appliances for small to medium-sized businesses, large work groups within larger business, things like that. Really pretty heavy at its time, but got to do some pretty cool stuff there, working on IPsec and other features of that device.

From there, we got acquired by Sun Microsystems at the time, which was a behemoth. It was - I don't even know, call up 50,000 people globally at the time, and got to do some really interesting work around the Linux Kernel, getting some of our Sun's hardware working with Linux, which at the time was unheard of, and got really bored of that quite frankly. These huge behemoth organizations, it's stereotypical going to meetings about meetings, to then hold the meeting about the issue. You're supposed to just like moving ahead and fixing something.

I left Sun and made the obvious next step of going into the military, where I focused on - and really, this was more about being a little bit burned out on computers and software engineering than anything else. But when I went in, it was like, "Okay, what do you want to do?" And I thought, "As little to do with computers as possible, that also isn't the inventory?" And they're like, "This kind of intelligence sec, you should do that. It's all about people." And that's totally true, it is all about people. It taught me a lot about how to really interact with people, how to work with other human beings who are either like or not like myself. Great experience, got to see a bunch of cool missions, do a bunch of cool things. The process really rekindled my love for security.

I left the military, and then went to work for Amazon, which like fascinating technology challenges at Amazon. For me, the mission didn't really resonate. I wasn't super excited about what we were doing in the world. So, I left Amazon, went to Palantir, where a friend of mine who I'd served with was working at the time and absolutely loved it. The mission was there, the technology challenges were there. It was a small, 300-person or so company at the time. Lots of agility and ability to sort of move outside of my defined box. Then, my boss left, and I wasn't really excited about - I didn't have like, "Oh, here's my next step within Palantir that was really exciting to me."

I had met some of the folks at Coinbase previously because they were working on some really fascinating - I'm sure some of the challenges, we'll end up talking about in this session. At the time, I didn't know much about cryptocurrency. Some of the other folks on my team at Palantir had gotten into mining really early. At the time, I told them something to the effect of, "That pretend Internet money is not really going to go anywhere." I regret that decision quite a bit obviously. I was aware of it broadly. I hadn't really ever considered the security challenges inherent in a cryptocurrency, or in running an exchange, or custodian. What a fundamental shift it was in asset and how one protects assets. But as I started to learn more and talk to the folks, I started to get really, really intrigued about both how critical security was and is to Coinbase. It truly is the one existential threat I think the company has faced since the very first day it started, as well as how much work there was to build new things in furtherance of that goal. Because we protect - I don't remember what the last quarterly report number was, but hundreds of billions of dollars in cryptocurrency.

But underneath that, there are hundreds and hundreds of millions of private keys to be managed, and there are insane insider threat risks when you can move money digitally, in this way, irrevocably. The human element of security becomes incredibly interesting and very, very difficult to control for the amount of money adversaries are willing to spend attacking us really is just proportional to the assets we have on platform. And so, there's a very direct monetizable piece of the company at risk there. So, we see attackers who are willing to spend a lot of effort, and time, and money, and focus attacking much Coinbase really, everybody in the cryptocurrency ecosystem across the entire chain, all the way from the end user to the exchange, to the custodian, to the software infrastructure that's supporting those things. Supply software, supply chain attacks are fascinating in crypto. They actually happen outside of nation-state sponsored hacking activities.

That was just like, for me, was just catnip. I've been at Coinbase, it'll be nine years in April. Really, honestly, people ask, "How you stayed at one company that long?" Coinbase has not been the same company the entire time. It's gone through a number of evolutions as any organization like this would. But at the end of the day, for me, it's been that consistent presence of significant security engineering challenges in an environment where failure really matters, has been a recipe for something that I just cannot get enough of.

[0:07:28] GV: Yes, that's awesome. I mean, like the kind of theme, I guess, just throughout. When you did actually get bored, you kind of made a switch. I think a lot of people don't maybe do that enough. I mean, it's not to say jump around, but it is sort of - I like that you completely did a hard left when you went from technology into intelligence, and then brought them back together. And obviously, as you call it, you've been at Coinbase now nine years. Clearly, there's still an intellectual challenge there for you, which is great to see. So, you've touched on it there, but again, just in case any listeners are not aware, just a very, very brief, what is Coinbase?

[0:08:04] PM: That's a fascinating question. For the vast majority of people out there, you experience Coinbase as one of two things. You experience Coinbase as coinbase.com, which is a retail brokerage. That's what we would call that. Similar to your pickup brokerage, your Schwab account, or Fidelity, or ETrade, whatever, where we provide the access and tools to buy, sell, trade, store, transmit cryptocurrency. Now, there's more than that. There's also staking, there's a bunch of other stuff. We'll just keep it simple to start with there. So, it's either that or they're a customer of Coinbase Wallet, which is our self-custody mobile app that allows consumers to do all those same things with cryptocurrency, but without using Coinbase as an intermediary. You can go transfer, trade on things like DEXs and similar things. You can do all of that, but not having to depend on a third party to store and facilitate those transactions.

[0:09:04] GV: Got it. I don't have a huge relationship to crypto, and it probably is because I got there very early, and use a different exchange that fell over very fast, and that was the end of that. So, I think what's going to be a sort of theme throughout today is the fact that Coinbase is such a established, and I think that runs through a lot of the - if you go to coinbase.com, et cetera, it's all about, we are the most secure, the most established exchange. 

[0:09:29] PM: Yes. Now, I should note, we're way more than that. We do a bunch of stuff on the institutional side or a prime brokerage, we have a qualified custodian. We're ,into derivatives, trading. There's a bunch of other pieces to the puzzle. But for the vast majority of users, that's sort of their relationship with us.

[0:09:46] GV: Now, we sort of understand at least at a very high level what Coinbase is. You came from, I mean, ultimately, you came from tech and then sort of what we might call traditional intelligence. Then, now, into crypto security. What mental models or frameworks did you have to actually rethink when you came from, I would say, traditional intelligence into Coinbase?

[0:10:07] PM: I'm not sure if it's rethinking so much as putting the proper context. Perhaps, that's a distinction without a difference. I actually took quite a lot from how the government, for example, thinks about designing systems that protect classified information to how we think about building systems that protect cryptocurrency. From a system design perspective, there's a lot that's similar in the way that I think about those two things, because the problem space is actually almost the same. When you think about - plus the problem space for crypto as well. I have all this value that at its core is tied to a, not a short string of digits, but not a huge one either. Something that if you could memorize 20 digits at a time, you could smuggle a key out of a place if you could see and memorize it, do it piece by piece, whatever.

Not the similar from the classified data problem, of what you're actually trying to protect is something that can be in someone's brain. When we think about protecting cryptocurrency in that way, we think a lot about, not to jump around analogies here, but I will anyway. We think a lot about that, sort of like radioactive material. How do you safely manipulate radioactive material? Well, you don't. You build tools to manipulate it so it can be at arm's reach, and you can be protected from it, you're not exposed to it, or exposed as little as possible. It's a very, very similar philosophy that we would take or we do take in thinking about how we design systems that actually - those core, core systems that touch private keys is in a very, very similar way.

I also think that, again, from that design perspective, very firmly embedded in our design process is that people shouldn't be trusted individually. We want to see systems, system design, where it really does require a conspiracy for things to go intentionally wrong, because conspiracies among humans could be fragile things. We want to introduce that additional risk into a bad actor would have to do in order to cause bad things to happen. So, lots of stuff like that, where I think are actually a huge number of parallels in how we think about secure systems design. 

[0:12:21] GV: Yes, makes a lot of sense. I mean, when you're talking about your time in the military and you were saying, you know, it was all about humans, and at the end of the day, security basically is humans.

[0:12:31] PM: Absolutely.

[0:12:31] GV: It just so happens that there's a sort of interface that we all use called a computer and Internet, et cetera. But it's ultimately humans and what can a human figure out versus another one.

[0:12:40] PM: I think that's very, very true. I think it's an element of security that you can't overemphasize. I'm not talking - when I say that, some people think, security training or whatever. Sure, fine. Educating the human about the risk is a component of good security, but more about understanding how humans are going to interact with the system. More about the understanding that the vast majority of humans that use the system that you're building don't actually care about the security or insecurity of that system. They care about getting their work done  for that day. That's their incentive.

Instead of sitting here and trying to say, "Well, no, I'm going to make them care about security." I think people should be sitting there and say, "How can I make the fastest path to that human getting what they want to get done done, the one that takes them through the most secure path? How can I make security the feature that they want in this system design?" I think we think about that a lot as we think about building security systems in Coinbase. Of course, there's something out of fiat that, "You must use this" or "You must do that." You can never get away from that entirely. But I think at the same time, we spend a lot of time and effort thinking about what roads do we need to pave for our engineers, for our whoever it is to get their work done in a way that is safe and secure. In a way that they are safe and secure because they know that if they are, they're going to be faster, and more efficient, and more able to get their actual thing done that  they care about.

You could even call it sort of some security humility. No one cares as much about system security as the security folks do. Let's just say that and be done with it, and ask ourselves, okay, great, what do they care about and how can we position ourselves that we're delivering that to them in addition to security?

[0:14:32] GV: Yes, I completely agree. I work in, it's actually email security, but I have to keep pointing out that email security, it doesn't technically matter that a bad email lands in your inbox. It matters that the human interacts with the bad email. So, to your point, it's around like how can we always ensure that people are getting what they need to get done, but gracefully avoiding the bad stuff effectively. 

[0:14:56] PM: Absolutely.

[0:14:57] GV: That kind of brings us on to, you know, because that's effectively phishing. So, just talking about the kinds of attacks we might see at Coinbase. I mean, what would you say the kind of classic question, what's the most common kind of attack, and also, just how have attack types changed over, I don't know, the last four to five years?

[0:15:15] PM: Yes. I mean, Coinbase gets attacked the way every other company on the Internet gets attacked. We see the phishing, we see the web attacks, we see all the same things that everyone else does. I'll say, a lot. People sometimes ask me, "Wow, Coinbase is seventh, the security must be so different." I'm like, "It's absolutely not." It's fundamentally, ignore a couple of things on the back end that I'll talk about in a second, but it's fundamentally web app security at a large corporate enterprise. So, you get all the same social engineering, phishing, perimeter stuff, web app stuff. We have vendors, so vendor third-party security. We have all the same attack types everyone else does. 

Now, where it gets interesting is where we get into the cryptocurrency specific stuff, because that creates a bunch of really interesting and unique security sort of threat surface for us. Everything from, hey, we're interacting with smart contracts, or actually, in some cases, we're writing smart contracts. How do we write smart contracts in a way that is safe and secure? Which is a really interesting set of problems. By occasion, it's sort of like, what if you're able to travel back in time and pick up a C programmer from 1970? Fast forward to 2025 now, and ask them to write a secure application. They couldn't possibly, because their whole classes of attacks have been invented, that they would just have been unaware of, even as a state-of-the-art practitioner.

Back then, a very, very similar problem in smart contract security is that, whole classes of attacks are getting invented on a regular basis. As people really explore the boundaries of the security of the language, of how the compiler's operate, of how the underlying network processes the bytecode, and the message types that are sent, and all of this stuff together. It's changing, it's updating at a pace that is shocking. It shouldn't be shocking not after nine years, but it still is sometimes to be shocking how quickly the space moves.

We have a whole team, a blockchain security team that does nothing but work on the various pieces and parts of that from smart contract security, to protocol security, secure protocol design, to how we store process, private keys, the whole sort of ball of wax there. That is really the unique bit of how Coinbase sees attacks. The other unique bit, as I talked about before, is just how much is at stake for Coinbase. While we certainly see our share of spray and pray phishing that went to us and a billion of our closest friends, we also see some very, very targeted attacks that attackers clearly spent time, and effort, and money executing, which is really awesome in the perspective of a security professional. 

[0:18:03] GV: There were a couple of - one I've heard of before, but one I hadn't. When I go to coinbase.com and there's obviously a lot on there about security because educating users is of huge importance. There is a term, a trust trading scam. What is that?

[0:18:18] PM: So, I say it a lot. There are no new scams in the world. They're just sort of scams that have a different coat of paint on them. So, something like a trading scam is really sort of a confidence scam, where a bad actor is one way or another, and there are many variations of this, convincing a victim that they are going to teach them how to trade crypto or clue them in on some great investment opportunity or whatever the pitch varies quite a bit, and getting that victim to, in some way, should perform transfer money to either the attacker or attacker-controlled address, or wallet, or something of that nature. 

There are as many scams as there are scammers, probably more out there. I think the really important thing that we focus on when we talk about scams is sort of two prongs to that. The first prong is, it's about, to your point, educating customers. and potential victims out there, getting the information in front of them. What we see on our end is that, educated folks, meaning that folks who have heard about these scams before, who have some inkling of what the shape of them, and what they might sound like are much less likely to be victims to those scams than people who are encountering them for the first time. That seems intuitive, but the data backs it. That is actually true. So, we want to get in front of as many eyeballs as we can.

Now, the hard thing about that is, that scam details change. And they change not just over time, but they change in reaction to our education efforts and the different controls we put in place. So, when we talk about this stuff, what I talk about tends to be in fairly a generic term. It tends to be a - I equate it a lot to sort of what I might call real life security, or security advice people have heard growing up for ages. If it's too good to be true, it probably is. That applies just as much online as it does in
real life. If you're being pressured into making a decision, if someone is pushing you to move faster than you're comfortable with, that's the moment when you take a beat step back. Ask yourself, talk to somebody. 

The third thing is, financial decisions should not be secrets. If someone's telling you, "Hey, I need you to do this thing, but don't tell anyone about it. Don't talk to your trusted, loved one, your brother, or your mother, your father, whoever. Don't tell them about it, they're not going to understand. That should be a red flag for folks. These are very common. In fact, in most scams, we'll see some combination of one or more of these tactics, whether it be pressure, isolation, or what have you. Those should really be - and I encourage folks to talk, not just educate themselves, but talk to their loved ones about this stuff, and communicate these core concepts.

One of the most fundamental things and I talk about a lot is that, it's almost independent. So, almost anywhere I go to talk to people. People don't need to hear what I'm talking about from a consumer protection standpoint. The audience is probably like, I would bet, your audience is in at least the top quartile of educated, meaning, aware of online scams, folks out there, which is great. I'm very happy for that. But the folks that need to hear what I'm saying are not listening to Software Engineering Daily. they're not reading the Coinbase blog. They're not attending Ripple's Swell Conference in Miami.
They are watching Good Morning America. They're reading the AARP magazine. They are in other venues, consuming media differently.

So, two things. One, we do a lot of work to try to get out in those media channels too. If I can encourage your audience to do one thing walking out of this, one thing that will improve security for everybody, it is, have a conversation with one person you know who you think might be at risk for being scammed online. You know somebody, I promise you. A cousin, an aunt, an uncle, a neighbor, a friend from a social group, whatever it is. There's one person that comes to mind for almost everybody. I'd worry about that person if a scammer called them. Go talk to them. We have a bunch of resources on Coinbase's blog. We've done some animated stuff on Coinbase's YouTube channel for sort of scam awareness. There are other resources that it doesn't have to be Coinbase. It's more important to me that the information gets out there than it's a Coinbase source for it.

That is really a rallying cry. I push everywhere I can, is talk to the people in your life who might be at risk. Because you want it to be you that has that conversation with them first, not a bad guy.

[0:23:11] GV: Yes, I think it's a great call out. I have sort of aging parents, and I think they've managed to avoid most things, but they certainly have been targeted in in the past. But luckily, they do know to message me, anything that looks a bit suspicious. They just say, "What about this?" I'm like, "Yes, that's a scam as well." Even my wife got a very sophisticated phishing scam recently, and I was almost saying, "No, I think it's probably correct." Then, we did some extra checking on it. It's like, "No, that's also a scam." Yes, I think it's a great call out. Just as you call out our audience here, probably more aware of things than the average person, but we all know someone who's not. So, it's a great call out.

I want to just talk about mechanisms for a second. I mean, one thing that sort of jumped out of me here in Singapore is we have this thing called Singpass. That's sort of government digital identity. It's used to log into, if I log into my tax or just any other government kind of portal, and then, it can also be used to log into Coinbase. I'm kind of curious around what that adds to something like Coinbase, and I've just got a little anecdote here, which I'm curious if you've got sort of something that sort of resonates alongside this, which is on my apartment door. I've got this - I didn't put it on there. It's a very fancy lock. It's got fingerprint. It's got digits. It's got all these things. One day the batteries run out and we didn't actually know how to jumpstart it. There is a way, but we didn't know at the time.

So, we call the locksmith, and we expect he's going to come with some sort of special rewiring device or something. He comes with a giant metal bar. I was like, "No, no, no, it's a digital fingerprint." He's like, "Yes, yes, yes." He pops out the eye hole, and he puts his metal bar and he opens the door from the inside, which just for me, this was just like an eye-opening moment. I thought, "Geez, this is security in a nutshell. We can put all these amazing mechanisms on the front." So, just kind of going back to the things like Singpass and obviously, multi-factor, et cetera, et cetera, what kind of stands out as mechanisms that do work and again, why something like, what does Singpass, for example, bring to Coinbase?

[0:25:13] PM: As you mentioned up front, half of Coinbase's mission is to be the most secure, be most trusted, as we say. The other half is to be the easiest to use. You could think about that as being two pieces of the mission that are in tension with each other. I don't think they are in tension, or perhaps they are occasionally, but they don't have to be. Really, it is a challenge to us to say it is unquestionable that we have to be the most trusted exchange, because if we are not, then the business dies.

However, if we are so secure that no one can remember their password, no one can log into their account, then we have failed in our mission to actually be easy to use. Thus, we have failed in our larger mission of encouraging the economic freedom in the world. So, we have to balance it. Things like Singpass or the equivalent of the US would probably be closer to logging in with Google or whatever. We see that as making things a little bit easier for our customers while at the same time, in our overall security architecture design, we don't outsource 2FA, right? So, even if when you log in with your Singpass, you still have to present whatever 2FA you have configured. Hopefully, it's a UB key. If it's not, I encourage you to use a UB key. We see that that is by far the safest method of two-factor that is out there. But the - 

[0:26:32] GV: Oh, the listeners know I like passkeys. I'm curious, do you have any so leaning on passkeys versus UB key?

[0:26:38] PM: The interesting thing for me about past keys is that they're not - a passkey is not a passkey, is not a passkey from a security design perspective, right? What's backing that passkey? Where it's stored? There are implementations where that passkey, the backing private key might be on a Google Drive, right? Or it might be on a password manager with a bad password. We can't know it from Coinbase's perspective. There's no way for us to. In fact, I think that's actually a gap in the protocol that I know our team has been working with or working to address is what we would love to know is, is this passkey hardware backed or not?

[0:27:12] GV: Yes. I think that's a great call out.

[0:27:14] PM: If we could know that, then we could have a lot more faith in that. Even if, maybe there's world here where we're big advocates of using risk models in situations like this. So, this is not how it works today, but you could imagine a future world that says, "Well, hey, you're logging in using username and pass, you're using a software-backed passkey, or non-harbor-backed passkey, and your IP address is new, and maybe there's three or four more other factors. We're not going to let you log in like that." Whereas maybe if it was a hardware-backed passkey or a UB key or something, we'd say, "Okay, you physically possess a thing that is letting you make this assertion. So, we have a lot more confidence that you are you and not a bad actor who got access to some sort of digital repository where that passkey, private key was stored."

[0:28:05] GV: I think that's a really good call out. I mean, I've always appreciated passkeys from a sort of conceptual standpoint. I was working with them at least two years ago. The thing is, as things have kind of advanced, yes, okay, things have got easier for users in theory. But as you call out, it's almost become too easy in some respects that I can log into my password manager with literally just a password. Then suddenly, that's my passkey, and that I don't think was really ever supposed to be how things were. I'm noticing that my password manager is now saying they're going to start backstopping that with my email address. Of course, this is a lot of what I work on, which is sort of backstopping accounts.

[0:28:45] PM: Then you get back down to the locksmith who pokes out the eye hole and uses the stick to unlock the door, right? Everyone is depending on a different layer to be the ultimate backing authority, and then someone comes along and says, "Well, that layer is vulnerable," and then the whole thing sort of collapses, right? I think this is really the hard part about modern secure system design. Its systems have gotten to the point that they're so complicated today. This is probably true in the past as well, but from my perspective, they're even more complicated today, that it's hard to even know that that eyehole exists in the door.

If you're designing door locks, you can make some assumptions about doors. You can think about eyeholes and hinges, and deadbolts, and deadbolt depths, and you can make some assumptions about that, and you design your deadbolt with those in mind. Trying to do that with an Internet application today is gosh, the breadth of knowledge you'd have to have, right?

[0:29:45] GV: Yes, exactly. API security just, I mean, yes, virtually impossible. I mean, there are obviously platforms and frameworks for dealing with that, but every endpoint could have some strange anomaly in it that someone figures out.

[0:29:58] PM: You inherit a constellation of assumptions that you don't necessarily even know have been made as that person operating the very top layer that imply constraints that you're not aware of, that you may or may not break because you don't know that you shouldn't. That's a very difficult problem to solve without a large and active team of people that do nothing but pay attention to this stuff. 

[0:30:21] GV: Absolutely. So, just going to move us along. I'd love to get your thoughts on a couple of topics. Obviously, one has to be AI. Let's start there. In terms of security, I think when ChatGPT kind of became a thing, and I think a lot of people all expected this to massively change, especially things like phishing. Now, what was interesting was, I believe in the last Verizon DBIR, which is a big report that's compiled every year, really well done and sort of is about the most accurate from a stats point of view sort of what's going on in the world security-wise. They actually were saying that they hadn't seen any kind of material jump in phishing or phishing sophistication yet.

Now, I mean we're due for the next report in a few months, would you say you've noticed anything materially different since AI being such an available technology? I guess, the sort of second question is, any aspects that you're using internally purely in the security part?

[0:31:20] PM: My guess is we'll see an uptick. I don't think it's going to be the sort of world-changing impact that people are predicting. I think that's for a good reason, right? There's a story, it may be apocryphal, right? But at some point, somebody had a conversation with the people that write the Nigerian Prince email, like scam emails. And ask them, "Hey guys, a Grammarly subscription is not that much money. Why don't you write these emails better, more sophisticated, with better punctuation of grammar, or whatever?" And the answer was because if someone responds to the email as poorly as it's put together, they're already in our target zone. They're more likely to believe us when we engage in the scam, than if we had written a perfect email that was very difficult to tell apart, now we're getting people who are going to be skeptical.

So, people talk about a sales funnel a lot. They are sort of scam funnel then becomes much more difficult for the parts to do. They're spending more human time. My guess is something like that is at play in the phishing world that, number one, phishing has always worked really well. So, why try harder than you have to in order to get the outcome that you want from a bulk phishing perspective? Number two, maybe it serves as that same kind of first-step filter for these bad actors in a way that they don't have to do as much effort farther down in the pipeline. I'm speculating there, of course, but that's one of my guesses.

I think that there's probably been more impact on the higher end. There's certainly been more impact on things like the use of chatbots in scams targeting consumers. That's a real thing that's absolutely happening today in a way that it just couldn't have historically.

[0:33:16] GV: Yes, when you say using chatbots in scams, how does that look, I guess? So, an example here could be you've probably gotten, or maybe not, I don't know if it works the same for scams in Singapore, but you've probably gotten a text message at some point that it was just like a, "Hi," or "Hey, Kathy, looking forward to golf tomorrow," or whatever it is. What's supposed to happen there in sort of the scammers' happy path is you reply back and say like, "I'm not Kathy," and they then kick off a conversation.

Well, historically, that was a human on the back of that. Now, frequently, very tragically, that was frequently a human-traffic human sitting somewhere in Southeast Asia in what amounts to a scam or sweat camp. There had been a number of really heartbreaking stories. 60 Minutes Australia did one. I think it was maybe three or six months back on this, but historically, it had been actual human doing that stuff or moving into a world where it can be a chatbot. So, what that means is that the volume goes way up and the quality becomes more consistent. I think that's the kind of place where I think AI technologies are more likely to show up in the average potential victim's day-to-day life than in phishing emails.

[0:34:30] GV: Yes, makes a lot of sense. So, moving on from AI, we're doing a few episodes covering different aspects this but post-quantum cryptography. How are you guys thinking about that? And just our listeners might not have heard of any of the other episodes. So, we're talking about things like store now, decrypt later, i.e. when people get access to data that's encrypted today with a certain protocol and knowing full well that maybe in four or five years, there's going to be increased computing power to be able to decrypt that and then use it at that stage. I mean, I can imagine this very sort of something that you guys are thinking about a lot.

[0:35:05] PM: I mean, yes and no, it's definitely something that's on our mind. I think the store now, decrypt later, that sort of world of things, it's fascinating, but it's also not really our problem to solve. That would be solved by the browser makers who are already doing a good job and really the critical designers who are already good at doing a good job figuring out how to layer quantum resistant or what we believe to be quantum resistant algorithms. I think it's important to acknowledge that we actually have no idea, really. We have strong beliefs but no hard data because we can't test our assumptions against an actual loss of computer that doesn't exist.

Doing the best job to layer protections in such that when that does happen, it reduces the vulnerability window because we've layered in some whatever, some lattice-based encryption mechanism that turns out to be hard for computers to break. I think that will get solved. It's already in the process of being solved. It'll absolutely get solved. I think the more interesting problem for us is that basically all of cryptocurrency depends on private keys, asymmetric private keys. Now, I think there's a bunch of smart people thinking about this as to how we could update protocols to become more resistant. The obvious answer is, "Oh, why don't you just change the signing algorithm to use a quantum-resistant protocol?" 

Well, okay. So, every single person that has the private key is going to have to regenerate the private key. What about people who have lost a private key or forgotten one? Is that not up for grabs now? What about people who don't know how to regenerate a private key? There's a bunch of interesting corner cases around that kind of migration that makes it more difficult than someone just casually thinking about it realizes.

That said, my belief, and I could turn out to be spectacularly wrong here, so let me just be clear here. I don't believe I have any particular expertise over anybody else in this space, but my belief here is this quantum is something we will see coming from a long way of way. We're already seeing it coming, right? The improvements in not just QBIT count, but much more importantly, error correction in these quantum computers and in quantum networking. It's happening right in front of us every single day. Every single day, it's improving the computational power for lack of a better quantum work, the computational power of these quantum computers. But it's happening in a way that we can see it. We can say, "Okay, they're getting closer. We're taking one step at a time." We're still well away from an algorithm that could effectively break a reasonable-length modern asymmetric key pair.

But I think what is going to happen here is we will see it coming from far enough off that at some point here, we will see a 512-bit key get broken. And that I think will wake up a lot of you. At that point, we're still, we're still what, depending on - or early for Bitcoin drive 256, we'll see 128-bit key get broken at some point here, right? And that will really encourage folks to think hard about how are we migrating this stuff? But it's not we're not going to jump from one to the other in the space of a week or a year, I think it'll be a long slog.

[0:38:25] GV: Yes, we did an episode recently with Meta. So, the work that they've been doing on this, and actually internally, they've been using what they call like a hybrid approach, basically, where - so some of it's done on a sort of regular protocol, and then some is on a post-quantum protocol. Yes, there's various sort of reasons around that and I encourage anyone to go listen to that episode to get into the so nuts and bolts of that.

But I think what you call out is absolutely right that this isn't a tomorrow problem, but it is a 5, maybe 10-year problem. And yes, we'll start to see some signals at some stage, not quite yet, but it's good that people are thinking about it. Just sort of moving on, obviously, conscious of time and just like to hear a little bit around the team, maybe that you've built up at Coinbase and like, what do you think about when you're hiring people into your team? I think it's often a bit of a, at any company, the security side is always almost a bit of a - sometimes to outsiders feels a bit of a club or secretive. So, what do you look for when you're hiring for your team? And I'm also like curious about sort of some of the initiatives that you maybe do things like bug bounty programs, this kind of thing, how does that all look?

[0:39:34] PM: Sure. So, we obviously look for different things across different teams from a specific skill set point of view, right? But I back that up into, generically, what are the characteristics I hope to see of any person in the security org or the Coinbase, number one, is curiosity, right? I think in the world of security and especially in the world of cryptocurrency security, Coinbase dogmatic answers just don't work. It's not this way because it's this way. It's this way for a reason. Let's figure out what that reason is and let's figure out that reason applies to our use case, right?

I think the second thing I hope to see in anyone that works in my work is humility. No, one is always right, and we're not here to be always right. We're here to solve a problem together with the business and I think it's so easy to get pulled into a us versus them mindset in security. They won't listen. They don't care about security. They don't want to do the right thing. They're lazy, whatever the excuse is, right? When someone that has the humility to step back and say, "I'm not landing my message correctly with this audience. What am I missing here? How can I help them better grasp the concepts that I'm trying to communicate? And how can I really listen to them and what they're trying to tell me so that we can get to common ground and solve a problem?"

I think there's no more important place for that than in security, because without that humility and that
ability to take a step back and say, "We're on the same team trying to solve the same problem." It's like, let's not fight. Let's work together. Without that quality, you end up being a security team that is consulted less and less and less or bypassed more and more and more because your customers are going to think, "Well, if I go there, I know what answer I'm going to hear. So, let's avoid going there." Let's say, "Oh, no, this isn't a major change. It's a minor change. No security view needed."

This system isn't security-critical for whatever reason. They'll seek reasons to avoid you. So, that humility, so, so, so important. I think I want people who are good communicators I think that quality is inconsistently valued in technology circles in my opinion. But I think it doesn't matter how smart you are if no one understands what you're trying to communicate to them. That's a generalization, right? A single smart person can get a lot of things done. But even more than that, a single smart person who can communicate their ideas and help other people come along with them will get exponentially more done over the long term. I want people who can speak simply, directly, clearly. I want people who can cut through all the security whiz-bang words we threw around out there, all the Gartner abbreviations, all that stuff. And using sentences that an eighth grader could understand and could
explain a problem. You might not explain all of it when you explain it like that. You might not explain every single nuance, but you can definitely communicate the shape of it. Then you can invite people to come along with you for the rest of that journey into the details of it. That, again, that's an inconsistently valued skill, but I think it is absolutely critical to executing effectively the mission of a security org at a technology company.

There's a bunch more. I could probably go on for hours on this question, right? But maybe boil it down to a reasonable human being who cares about the mission, who cares about other people, and who cares about doing the right thing.

[0:43:35] GV: I think that's obviously a great call out. It's almost this full circle here where security is humans at the end of the day. If humans, especially within security, can't communicate with each other, then that's usually where things start to break down. I think a lot of unintentional failures of security has arisen from that. I can certainly remember a couple of episodes where basically a breakdown in communication has probably led to something not going so well and I can certainly reflect on that. So, I think that's a really, really great call out.

Just looking at the kind of, I guess sort of external side, if you want to call it that, or community effectively, do you run bug bounty programs? Or like, how do you interface with sort of open source or anything like that?

[0:44:18] PM: Yes, so we do both. We run a large and active bug bounty program. We have for really as long as Coinbase has been around. So, call it whatever that is now 13, 14 years. We have a very active community of researchers out there who are helping us find things that slip through the cracks. We also do a bunch of open-source engagement. We open source a number of our technologies in half for a long time, and we do it for a bunch of reasons. But from my perspective, because a lot of the problems we solve are unique in some way, but I think what we tend, it's less, I think our problems that is less unique and no one else will ever have and more unique in we have it today and it'll be a lot of other places in 10 years.

If we think in that direction, the stuff that we're building today will really be the vanguard of future stuff. Not saying we have the right answers here because, again, I think being humble about this stuff is incredibly important. I think we have good answers, but I think open-sourcing some of the stuff enables other people to build even better answers.

[0:45:30] GV: Yes, absolutely. I mean, we see this more and more security products, products or frameworks, but being open source makes a ton of sense. If everyone can see and analyze that code, then you're always going to get someone who can point out the problems, which is helpful for everybody. So, just as we kind of come to wrap up, I tend to ask this question to most guests now, which is a pretty simple question, but it gets in different answers. Knowing what you know now, what would you tell yourself at the start of your career? Just something that you now know, but you could have in theory then told yourself at the beginning of things.

[0:46:04] PM: I think I would have told myself that really what I just said to you, that it doesn't matter if you're the smartest person in the room, if you cannot make your case to the other people in the room. So, spend more time on rhetoric and philosophy and public speaking, right? Really hone that craft in addition to your technical craft.

[0:46:28] GV: That's awesome. I really like that. We've not had that answer before. So, that's a great place to leave it. Philip, thank you so much for coming on. You've imparted, I think, a lot of wisdom today. You're obviously a great communicator yourself.

[0:46:39] PM: Well, it's been a pleasure, Gregor.

[0:46:42] GV: Thank you so much and I hope we get to catch up in the future.

[0:46:44] PM: Me too.

[END]