The Best Way To Prevent Modern Security Breaches with Jasson Casey, CTO at Beyond Identity

(Intro Narrator at 00:00:01) Today, we're talking to Jasson, CTO of Beyond Identity, about the need for multifactor authentication and the intersection of baking and software development. You're listening to the Modern CTO podcast.

(Joel Beasley at 00:00:18) Hey, buddy. How are you?

(Jasson at 00:00:19) I'm doing alright.

(Joel Beasley at 00:00:20) Man, this is great. So you just decided to add an extra S to your name. Is it still Jason, or is it Jasson?

(Jasson at 00:00:26) It's just Jasson, and I totally decided and sent it back in time, and my parents wrote it on my birth certificate.

(Joel Beasley at 00:00:34) There you go. So, typically, I like to start by just telling you a little bit about my background. So the brief story is seventeen years as a software engineer building product teams and teams of teams. And then I started sharing what I learned going from individual contributor to first time manager and so forth as blogs, and then that turned into a book, and then the book turned into the podcast, and then the podcast got fairly popular. And it ended up becoming our full time thing, and now we make this show plus fourteen other shows. It's pretty crazy. Cool. Yeah. How did you get started?

(Jasson at 00:01:10) How did I get started? I needed money to pay for college. Yeah. So I ended up going to UT Austin back in the mid-nineties. I thought it was the best way of being able to study the thing I liked, physics, while doing something I knew I could make money at, electrical engineering. I fell in love with the immediacy of software development over hardware development. And like I said, I needed some money to actually help pay for school. I already had been writing code in high school, so I was able to get a dev job for a geosciences company, and they paid me well enough to basically cover my gaps for college. And I loved the work. And companies trying to disrupt industries—i.e., startups—was always fascinating to me. I found a book. So, you know, I'm a big reader. I love going to the library and, honestly, just walking the stacks just to discover stuff. Right? The art of discovery. There was this book that looked interesting. It was called The Supermen, and it was about Seymour Cray and the founding of Cray Computer and the reasoning behind why he wanted to start it and whatnot. And so I thought that was pretty fascinating. Michael Lewis had a couple of really entertaining books out at the time, and he had just published a new one called The New New Thing. Then it was about the guy who started Netscape and Silicon Graphics. I thought it was interesting at the time because I actually worked on a Silicon Graphics machine, and I used Netscape and whatnot. And yeah. I fell into it out of a necessity. You know? I needed to pay for school. I loved the immediacy of it versus a lot of the stuff that I was going through at school. Right? When you write software, you can see the results immediately. And, yeah, it was twenty years ago.

(Joel Beasley at 00:02:47) Is that one of the reasons why you're into baking?

(Jasson at 00:02:54) Not if you do it well, it's not. So when I bake, it takes me about three days to get really what I want.

(Joel Beasley at 00:03:03) What are you baking that takes three days?

(Jasson at 00:03:04) Sourdough properly done. Well, you've got your starters. You want your starters to be mature. The maturity of a starter is highly dependent on temperature, humidity, culture time. You really want to make sure that you're taking from your starter and making a levain when the little creatures are kind of at their peak productivity. I like a more acidic flavor, which generally means you want a longer fermentation at a colder temperature. Yeah. I've always liked more of the flavor like the San Francisco sourdough, which is more of that acetic acid sort of flavor. And so that's a colder temperature. The colder the temperature, the slower they go, but the more acetic acid you build up. I like to do a twelve hour rise. I like to do a twelve to twenty-four hour on the main proof. And then once I form the bowls or the dough, I'll let it rise for another four to six hours before I bake it.

(Joel Beasley at 00:03:55) When did you pick this up? Was this all during the pandemic?

(Jasson at 00:03:59) So as you can imagine, I enjoy food. I've always enjoyed food. I've always liked cooking food. It feels like engineering to me. It really is a combination of mechanical and chemical processes that make the things that we like. The things that we really like are kind of a simultaneous impact on texture, the different flavors that we taste, the aromas that we smell, the way that we perceive it with our eyes. So there's a strong design element to it. It's just fun. It's repeatable once you actually understand the process. I've always made decent food, but I've always made trash bread. And, yeah, when the pandemic started, I decided there's nothing like repetition to figure out all the ways of not doing something correctly. And, yeah, it wasn't until four to six months into the pandemic before I finally figured out how to actually make sourdough properly. And maybe I'm just an idiot because all the YouTubes that I watched, it just seemed effortless. You know? You do this, you do this, you do this, and you finally get a result. But for me, I basically baked two loaves every day for six weeks before I started getting decent flavor and another twelve to fourteen weeks before I finally got the right structure.

(Joel Beasley at 00:05:10) Does your family appreciate it?

(Jasson at 00:05:11) So yes and no. My family treats it as an on-demand function now. Unfortunately, they don't really understand the lead times necessary to do the things that they really like. So I often get requested, "Make this type of bread or make that type of bread," the day of or the night before, and it's like, I needed to know three days ago.

(Joel Beasley at 00:05:28) Yeah. Demanding customers. How can we connect lessons learned with baking, with either leadership or what you do at Beyond Identity?

(Jasson at 00:05:39) I would split the difference and say there's a couple lessons there for just foundational software engineering, and one of it is repeatability. The same inputs need to provide—you don't have repeatability until the same inputs equal the same outputs. And that is 100% true in baking. What's hard and what people don't quite realize is there's these implicit inputs that they're not conscious of. But you could think of baking as functional programming. You just don't realize the inputs that you're actually giving it.

(Joel Beasley at 00:06:09) Do you have examples of those?

(Jasson at 00:06:11) Yeah. No. So humidity. When you're baking a loaf of bread, you're getting a mechanical rise out of the bread by steam formation. You're also getting a chemical change in the crust of the bread or the outer layer of the bread. And those two things kind of fight each other. Right? And so you typically, when you see bread, you see how there's usually breakthrough at some point. A really good loaf of bread manages to form that crust just before the loaf reaches peak volume. How do you do that? How do you delay the crust formation until you're almost at 90% peak volume? Right? And, obviously, people perfected this over thousands of years just through trial and error and just being intuitive. But, you know, we know better now. We actually understand the chemistry and the mechanics of baking. So, yeah, it's the same inputs equal the same outputs. And for bread specifically, if you keep the humidity of the loaf above, what, 60%, you'll delay crust formation. And once the humidity falls below that point, you get crust formation. So that's why commercial ovens have steam injection specifically for the beginning of a bake. It's also why, for home bakers like us, we'll put an ice cube in the cast iron or pour water in a pan underneath the stone that's actually carrying the bread. But, you know, the lesson there is repeatability—the same inputs equal the same outputs. What makes you positive that you actually understand all of the inputs? How do you—what are the hidden variables that maybe you haven't quite realized that are implicit? I find things like that, especially in design of distributed systems, to be a hard thing. Right? We take things for granted all the time. We don't quite really think of systems as pure input-output functions. But if we want repeatability, we have to think about them in that way. And, yeah, there's some connection there. I can't eat my distributed system, so maybe that's where it falls apart.

(Joel Beasley at 00:08:14) Not yet. The future is soon, my friend.

(Jasson at 00:08:18) Repeatability, discipline. Right? Maybe we're all learners, and I'm a little bit slow on that part. But if I didn't do it every day, I wouldn't have got there. And then also, this is kind of my personality type sort of thing. I need to understand how something works before I feel like I can control its results. My journey in baking bread wasn't just trial and error every day and watching a bunch of YouTubes. I think I bought about seven different books on bread making, and I even got some food chemistry books and food engineering books to try and understand what gives it the structure? How do you control the crust formation? At one point, I think I read a paper where they were using machine vision and sensors to try and plot an optimal curve of volume expansion against crust formation. I don't know if the paper was really that useful, but the point being is, how do you know you really understand something? Trial and error is necessary, but it's not enough. And this is no different in engineering. Right? For the products that I work on, the problems that I'm interested in, you need discipline, you need experience, but you also need to understand the fundamentals of computing. You need to understand the fundamentals of distributed systems. And for a lot of the security work, you have to understand the fundamentals of operating systems. And that requires reading books. That requires actually looking at source code of how operating systems work. And in a lot of cases, it requires really reversing systems.

(Joel Beasley at 00:09:42) Is that what you do at Beyond Identity?

(Jasson at 00:09:45) So Beyond Identity, we're basically a security company solving an identity and access problem. But what we mean by that is most security incidents that people experience today, especially the corporate security experience, is related to access and really related to password theft, password phishing, or site access phishing, those sorts of things. And so we look at that statistic—80-plus percent, and you can read this in Verizon's database of incident response—if 80% of incidents kind of completely bypass the access system, the access system doesn't seem to be terribly effective at providing security results. So when we got started, we rounded up a bunch of security and systems thinkers and said, "What are some of the fundamental problems of access, and can we solve them more categorically as opposed to instance-by-instance based?" Or rather than whack-a-mole, are there fundamental things that are there? So we came up with these solutions that—some of the benefits is you can remove passwords from the equation, but the real thrust of our product is to provide a simple access solution that humans can use that takes things like phishing off the table, that provides real phish resistance, that provides MFA that isn't a pain in the ass, but also isn't necessarily exploitable through all the phishing things that you see today. My role here, I'm the CTO. The definition of the job is very fluid. It's highly dependent on where the company is in its life cycle. I joined here from the beginning, so I've got to experience the different parts of the life cycle. But 50 to 60% of my time is in the field with customers, either at customer sites or at conferences or whatnot. 30% of my time is with the product and engineering team, but more on product strategy and product vision. And 20% putting out fires, which is interesting. Right? My job has evolved quite a bit to where, the size of our organization and the amount of things that we're doing, I no longer have the time to have an opinion on a lot of implementation choices. And so I have to have strong lieutenants for that. And I kind of have to spend my time focused on really product strategy and product outcomes, if that makes sense.

(Joel Beasley at 00:12:03) Yeah. No. 100%. I'm at the small business level of fifteen people. I know you guys are much bigger. Right? How many people are at Beyond Identity today?

(Jasson at 00:12:13) We're just shy of 200 people.

(Joel Beasley at 00:12:16) And were you one of the founders?

(Jasson at 00:12:18) So the company got started officially in February 2019. And at that time, it was Jim Clark, TJ, or Tom Jermoluk, Nelson Melo, and Mike Clark. I met the team in the summer of 2019. And it's kind of a funny story. I was leaving my previous company. I was the CTO at a company called SecurityScorecard from 2016 through the, I guess, fall of 2019, early fall of '19. I wanted to branch out, and I was thinking about just kind of starting my own company. You know, I wanted to maybe do it myself. And I got an email out of the blue, and it said it was from someone helping Jim Clark with his new company. And my initial response was, you know, there's no way I can get an email from anything related to Jim. And earlier, when I was talking the story of how I got into all this, the two books that I read—or two of the books that I read in college—kind of really made me attracted to startups. One of them was that Michael Lewis book, The New New Thing. It was about Jim Clark. So I've always known who he was and kind of the history of some of the companies he did. So I get this email in the summer of 2019, and I think I just ignored the first one because I thought it was just—you know, you all get trash emails all the time. Right? Yeah. So I get another one a couple days later, and there's a little bit more background in it. It's like, "Hey. Jim lives in New York, and he's been on the East Coast for a while now. He's really interested in this security company idea. He's got a couple folks together that have built this proof of concept of what it could be, and he's looking for a New York-based security leader who can help him get started." Yeah. So I spent time with the team over the course of two or three weeks, and that was kind of funny. Jim hadn't even made me an offer to join the company yet. And I got a call from one of the guys saying, "Hey. We're going to meet our first prospective customer, and what time should we pick you up?" So it all just happened pretty fast in the summer of 2019. It took us four to five months to ramp to about 20 total people, 15 engineers, and release the first version of our product. We got our first sale, I think, inside of twelve months. Our first major deployments, obviously, in that time frame. We're 200 people today. Hundred or so of them are engineers. Yeah. Blowing and going.

(Joel Beasley at 00:14:38) Nice. So what is it exactly that you do? Do you build a suite of tools that help you with different things? You have a tool chest? Are you consultants?

(Jasson at 00:14:48) Yeah. No. So we build a SaaS service. It's an authentication and identity service. So if you're a company that uses Google Workspace or if you're a company that uses Okta or Azure AD, Azure authentication system, you can plug us into the back of that system. And we then distribute—we call it a platform authenticator, and that's actually a term of art that came out of the W3C specification called WebAuthn. You think of it like a wallet. Think of it like a digital wallet that holds a couple of credentials or IDs. When a user has that, that will interact with our cloud service and your identity service to authenticate you to whatever you're trying to access or log in to. So kind of talking about the product from a high level, we can authenticate you through possession.

(Jason at 00:15:34) Right? You possessing a thing, we can authenticate you with a biometric. You are a thing. We can authenticate you with a PIN code, kind of like Windows Hello for Business, a thing you know. The difference with the PIN code is the PIN is actually a guard to a key that's locked in a secure enclave that's specific to your device.

(Jason at 00:15:51) So it's very much like when you access an iPhone, you have a couple tries before your phone locks. And what that PIN is doing really is just providing access to a credential that's in this tamper-resistant security processor that's on that machine. And it's really that key that's authenticating you and providing proof of other properties to our cloud service. But, yeah, we build an authentication system. We dub it as a zero trust access solution.

(Jason at 00:16:15) We plug into the back. We don't displace SSOs. We plug into the back of the existing SSO. But we do displace your MFA solution. So a lot of our customers typically replace their Duo instance with our product.

(Jason at 00:16:26) And usually, the catalyst for doing it is they need phish-resistant authentication. If they're going to do that, they'd like to maybe remove the password for their end users to give them a little better life experience. And they kind of want to get more visibility and control into access. And so, one of the things that's unique about our architecture, because we're a platform authenticator, right? That concept of the wallet, because it lives on the machine that you're trying to do something from as opposed to a secondary device, we have an ability to actually comment on and observe the security controls on that device at the time of access. Right? So a typical access architecture, you think of it as these vertical stovepipes that don't really know anything about each other. Right? So you have an MFA system, and you have an SSO system that does password management. You have an MDM system that's pushing out operating system configuration on the machine. And then you have an EDR system, right, that's looking out for malware and whatnot. And all of these systems kind of pump events into a SIEM. And then you have these teams that are writing queries against that SIEM to try and understand the big picture. Right? What's going on in your environment from a security and access perspective? So we have all of these what seem to be independent events that we're trying to correlate, but are they really independent? Right? We're talking about a machine. We're talking about the security controls on that machine. We're saying we don't only want to put these controls on the machine. We want to verify they're there and use that verification as part of allowing someone to move forward. So a pithy line we typically give is a security tool is not a security control. So MDM, for instance. Right? Whether we're talking about Jamf, Intune, AirWatch, or whatnot. You use MDMs to establish security controls on machines, but the MDM is the security tool. Right? So you might define this profile that says, alright, I want to put these rules in the firewall of my target machine to prevent brute-forcing of an RDP password. I want to make sure, obviously, the firewall is on. I want to make sure the disks are encrypted. I want to make sure there's an idle screen lock timeout on the machine. I want to make sure its value is three minutes. Right? So then you apply that profile to a set of target machines. And, again, this is all in the MDM. Right? That is your intention. That's what you set out to do. It turns out those security controls don't get deployed to 100% of your targets. Right? People mess up. People make mistakes. The system can give you back a green light saying we've deployed this profile. How do you know you deployed that profile to the right machines? How do you know the way you're classing those machines into the profile is actually what you intended? So with our system, we give you a way of almost like unit testing or almost like verifying that your security design and intent has been achieved. But rather than just answering that question in the general sense, it's really part of every authentication. So an authentication in our system is very much a proof. So I want you to prove that you can use the key that's glued to the physical machine, right, that I—right? That proof of possession. I want you to prove that you can use that key where the key unlock is a biometric and a PIN. Right? So I get my knowledge and inherence. I want you to prove that that machine's firewall is enabled. I want you to prove the OS version. I want you to prove the RDP protection rule is in place. And I want you to prove that your idle screen lock is at least or no more than 180 seconds. Right? And then and only then would I classify you as high trust. And then and only then would I allow you to access our banking software or make transfers or whatnot. So there are a couple ideas in there. The first couple are really around secure authentication that has phish resistance. But the final one is more of the zero trust concepts, which is we've gotten ourselves into a ton of trouble in the security landscape by treating security as transitive relations. Right? Because you're in a place of privilege, you must be authorized to be there. Therefore, don't worry. Right? Because you're in the VPN, I shouldn't worry. Because you're in the office, I shouldn't worry. Right? So why is it—and so then zero trust was this movement around, we really have to have this minimal set of assumptions. And from there, we use just standard logic to deduce all of our other properties. We actually prove it. So why is it acceptable to then say, well, I can see a security tool on your machine? That's just another variation of perimeter-based security or transitive-based security. Just because you have MDM on your device doesn't mean it's the right policy. It doesn't mean it's established the right security controls. What you really care about is are the security controls you expect present on the device prior to letting someone do something from that device. So ask the direct question and answer it in real time relative to the authentication.

(Joel Beasley at 00:21:17) That's pretty sweet. So then you have to have your software will be on the computer that's trying to connect.

(Jason at 00:21:22) Absolutely. And that is the concept of a platform authenticator. A platform authenticator is on the machine that someone is actually running the connection from. By being on the machine that someone's able to make the connection from, you are actually able to bring a huge benefit to the end user and the security of the company as well, and only by being on the machine. And so this has to do with phish resistance. So I'm sure you and the folks listening to this have read the headlines over the last six months. They've only kind of increased around MFA bypass and credential harvesting and whatnot. Right? All of these big breaches that we read about, the initial access or the lateral movement involves stolen credentials, phished credentials, and MFA bypass. When you study that problem holistically, it turns out you can think about that problem as really a problem class, because there's a bunch of demonstrations of how to run those exploits, but they're really all exploiting the same couple premise concepts. By being on the platform, you're able to do a couple things. Right? So by moving from a password to an asymmetric key pair where you're using a private key essentially to sign, you're now making it possible to where the password doesn't have to move or that key doesn't have to move. Right? In the old world, if we go passwords, I have to know it, you have to know it. Right? And it's like, oh, there's salts. Well, technically, a salt is between the web service and the database. Right? It's not between myself and the web service and all of the application load balancers between me and the web service. Right? The CDN, the application load balancer, my entry point into a Kubernetes cluster. So passwords end up in a lot of machines. Those machines aren't all controlled by you or your company. Those processes—the memory those processes are using can swap. Those processes can crash. Those passwords can end up in the file system through that action. A password is just almost indefensible. Right? So by moving to an asymmetric key pair, right, I don't have to move that private key around. I don't have a guarantee yet. Right? So step two is, what if I only created those key pairs in secure enclaves? Turns out half of those secure enclaves can give me structural proofs that the key, in fact, will not move. The key will only ever exist in that secure memory in that tiny little security processor that's off the CPU. And you don't ask for the key. You send a little piece of data to the processor and say, sign this. And you can create keys with no policy. So a no-policy key is useful for device things. Right? Like, prove you're on the right device. And so you send the thing down, it'll sign it, but it's kind of like Ron Burgundy. Right? It's going to sign anything you send to it. You can create keys with policies that are based on PINs. Right? So PINs kind of sounds like a password, but it's a little bit different. You run an HVAC protocol with the PIN. And if the PIN is correct, the processor will use that private key to then sign whatever piece of data you sent down and use that in the authentication process. So now I have a knowledge proof and a possession proof. The PIN was never shared. The PIN was just local to the system. It's susceptible to online attacks, but it's not susceptible to offline attacks. Right? There's nothing to export. That key was never in memory. I can't run crackers against it. I can run online attacks. I can do brute-forcing. Right? But those processors then have these things called anti-hammering. I'm sure you've experienced it where you fumble your phone PIN and it just locks for some period of time.

(Joel Beasley at 00:24:33) Yeah.

(Jason at 00:24:34) You can create bio guards on those keys. Right? So step one is you've got to move to asymmetric keys so you're doing signatures for authentication. Right? That makes it possible where you don't have to spray the world with your secret. By doing it in an enclave, you now have a guarantee that that's not happening, but that's not enough. The third step is you have to have a platform authenticator run the client side of the authentication process. A high-level way of kind of understanding the intuition here is, today, our organizations think that they can train their employees out of the phishing problem. But the phishing problem in training feels a lot like quantum mechanics in some way. And the way I got there is I can train people to be 99.999% effective. Right? But if they're doing a thousand operations a week and I have 10,000 employees, then 99.99% effectiveness rate multiplied by that really, really big number is still a significant number of incidents that I'm having to deal with. Right? So I can't train the problem away. Right? But why am I asking a human to solve a computer's problem in the first place? Right? Why am I asking a human to answer the question of, is this domain right? Are these characters not a homomorphic attack against something that you think you recognize? From an authentication's perspective, the server is fixed. The code base of the client is fixed. If you have a platform authenticator, make it verify the origin as part of authentication. Don't even sign the challenge if the origin is not correct. So that's kind of where the platform authenticator plays in. Right? And it's not exactly as simple as I'm representing it. Technically, you need the origin of the transport and you need the origin of the challenge. So it's kind of like, you think old-school OSI model. You need to verify not just that you're talking to a valid server, but that the challenge coming over that server is part of a package from an origin that you trust. Because remember, we deal with CDNs through CloudFlare, through CloudFront. There's all sorts of third parties that get involved that technically could be insider threat-style man-in-the-middles. Right? So are those two origins that come across, right, the layer seven and the layer four origin, are they the same, and are they what you expect? And only if you're doing those things—only if you're doing those three checks and those three steps are you really providing phish resistance. Right? And so if you dig into the FIDO specification, you'll discover inside of both WebAuthn and CTAP, but just focus on WebAuthn because it's a little more accessible. There is a concept of a challenge origin and a challenge response. It's very, very clear. You're not supposed to sign—the software doesn't sign things that—doesn't sign with keys that don't match the challenge origin unless you allow that as a policy. Turns out we learn stuff from the world of web servers, and we translated it to authentication. When I say we, I mean the world, not us. Right? WebAuthn came out of W3C. We're just taking the good bits and using it where we went. And the fourth thing of what we do is all of that provides authentication that's phish-resistant. But if you're going to do all that work, take the zero trust step as well. Ask the questions you care about about security controls and roll it into authentication. Sorry. I just put a lot out there. But—

(Joel Beasley at 00:27:51) No, no. Luckily, I have years of experience in this. Not in security specifically, but there were very few things that you said that I didn't fully understand. One of them that I didn't understand, I've never worked at an enterprise or built a company that was an enterprise-level thing. So I personally haven't gotten to the platform authentication tools. I've never—I haven't used them before. You said that it sits on a security chip off the CPU. Can you explain more about what that is?

(Jason at 00:28:22) So we use the term secure enclave. It's kind of a categorical term. But generally, what we mean at the abstract level is a specialized processor that really only has a couple of instructions: create key pair, delete key pair, sign with key handle X. There's a few more things it does, but you can kind of generalize in that way. This processor has its own NVRAM. Right? So when you create a key pair, you can create a key pair with certain properties that says, this private key must be stored in the local secure NVRAM of the chip itself and is never allowed to be copied out.

(Joel Beasley at 00:28:57) So wait, are you providing a physical device along with the computer that this thing is in?

(Jason at 00:29:02) It turns out that it's almost impossible for you to buy a computer that doesn't already have this concept already baked into it.

(Joel Beasley at 00:29:08) Really?

(Jason at 00:29:08) Really. So secure enclave is the category. The specific instances that you've probably heard about is called the TPM. Right? So TPM is the Trusted Computing Group. They wrote the spec called a TPM, and the gold standard is TPM 2.0. And it's this tiny little processor. And so, obviously, implementations can vary. Some manufacturers will actually lay the TPM processor in the same die that they have in the main CPU in. Some of them will actually have the processor as a discrete component on the PCB. There's a couple different implementations, but in all implementations, the TPM is discreetly different. It is its own processor. So the way the TPM actually gets integrated with the main system is you kind of treat it like this remote CPU, and you just send it commands. So you send it commands saying, create key, use key, delete key, that sort of thing. It carries a small amount of its own memory, right, that you can store keys in. That memory is tamper-proof, and it's called secure memory. There's a couple similarities between this and actual CPU and physical systems from operating systems. So, you know, the operating system problem. Right? I have a finite amount of RAM, and I have all these applications competing.

(Jason at 00:30:23) Right? And so then, well, virtual RAM came out of it. It's like, I'm going to give every application its own kind of infinite memory space, and then I'm going to hide how I actually map that to memory under the hood. Turns out you can do the exact same thing with TPMs, right?

(Jason at 00:30:37) So TPMs may only have 15 slots or 14 slots for creating keys, right? Little memory slots. But I have all sorts of applications that might want to create keys in this custom processor. Well, you can kind of do a virtual memory sort of thing. You can create, think of it as an anchor key or a root key, with a policy that basically says this key is never allowed to leave the TPM. And then every time someone creates another key, you can say, well, this key needs to be part of this hierarchy, and it's only allowed to leave the TPM if it's ciphertext and has been encrypted by the key that's not allowed to leave the TPM. So you get this kind of virtual infinite number of slots by basically letting the key leave, but the key can't leave unless it's encrypted. And it can only be encrypted by something that is not allowed to leave or by something that has the same property of itself.

(Jason at 00:31:24) So it kind of creates this recursive definition, if you will. So you might only have 15 physical slots to store keys in, but you could have an unlimited number of keys, really, if you're basically just running that process I described. So TPM is the one you most likely heard of, but there's a lot of other technologies that exist as well that have similar sorts of component building blocks. Apple had this chipset called T2. In the M1, they've revamped it a bit, and I'm actually a little bit behind on reading the doc they just published that kind of explains the new architecture.

(Jason at 00:32:00) But I imagine, based on some things I ran into a couple weeks ago, it seems like they're evolving a lot closer to the TPM than they have before. ARM has this thing called TrustZone. There are CPU-style instructions that have been around for a while where you can kind of emulate these sorts of things, right? Create a memory jail, create a processor jail, drop a TPM emulator inside that jail, and then essentially treat it as a system with a certain level of trust.

(Jason at 00:32:26) And the really cool thing—I could talk about TPMs forever—the really, really cool thing about the TPM is it can produce an evidence trail that is a proof that you can validate. A third party can validate that certain things are true. So for instance, there's this thing in a TPM called an EK, an endorsement key. An endorsement key is unique in each TPM, and an endorsement key ties back to an actual manufacturer, right?

(Jason at 00:32:54) So I can use that endorsement key—think of that endorsement key as a private key, and the manufacturer has the public key for it. So I can use that public key to basically encrypt little pieces of data and send it to that device. And that device can only really respond to me if it can decrypt that data properly and the computation happens to be inside of the challenge that was actually issued down. So you can kind of use that to establish, am I talking to the...

(Joel Beasley at 00:33:21) Right manufacturer.

(Jason at 00:33:22) Yeah. Oh, 100%. You verify the manufacturer. So one of the ways that zero trust kind of went off the rails is, technically, it's not zero trust. It really is minimal assumptions, right? So you still have to assume trust in the manufacturer. But if you assume trust in the manufacturer's TPM line, you can track it all the way back to that. And then at that point, the evidence trail of the authentication tells you—you can basically have an actual proof saying, this machine with proof of this key that was guarded by a biometric, linked to this identity, with this level of integrity on the system that's actually running. And not every device has a TPM, but the absence of evidence is actually pretty useful as well.

(Jason at 00:34:04) So we built this big policy engine where TPM 2.0 is kind of the gold standard. When we don't get back, you can have medium trust, low trust. And the way you get medium trust, low trust is you just don't have that. You have claims—a semi-validated, unvalidated piece of data. And so, yeah.

(Jason at 00:34:21) No, it's great, right? You get keys. The keys are never in memory. If they're never in memory, they can't be in the file system. The attacks against these types of devices are destructive, so it costs a lot of money. Successful attack only basically yields an ability against one person and on one device. So the blast radius of an attack against old-style credentials is drastically reduced.

(Jason at 00:34:44) Yeah. No. It's fascinating. It's fun. It's not exactly new. A lot of the stuff's been around since the late nineties. It's just we haven't quite cared about security, and the original intended usage of these chips was actually DRM.

(Joel Beasley at 00:34:59) Really?

(Jason at 00:35:00) Yeah. The big media companies wanted to—basically, they wanted rip prevention.

(Joel Beasley at 00:35:06) I just got a message yesterday from the CTO of Napster. He messaged me on LinkedIn. He goes, hey, what's up? I'm the CTO of Napster. And then you put in brackets, yes, we still exist.

(Jason at 00:35:18) I learned something. I didn't know they still existed.

(Joel Beasley at 00:35:20) Neither did I. But, yeah, they drove the need for those DRM-type systems, right?

(Jason at 00:35:27) Yep. Yeah. The original driver really was around DRM. There was this big backlash, I think originally from the Linux community or the FreeBSD community and the EFF, around, we don't want your DRM. You're going to break computing, blah, blah, blah. And so it caused people to just not really do much with it for a decade or so.

(Joel Beasley at 00:35:46) Luckily, you guys have that technology to come tap into to make sweet authentication systems.

(Jason at 00:35:52) Well, that's just it. I think the cost of poor security and authentication is now far outweighing, you know, the counter concerns in some of the other areas. Like I said, it's almost impossible to buy a consumer electronics device that doesn't have...

(Joel Beasley at 00:36:08) So my iPhone has it. Is my iPhone having it so that it's not just there for third party, right?

(Jason at 00:36:13) So when you log in to your iPhone or your macOS, you are providing—let's talk macOS. When you log in to your macOS, you're providing a password that macOS is going to use to essentially unlock the usage of a key that's in that specialized processor. And that specialized processor is then going to—that key that you just unlocked is then going to unlock your file system, so to speak, right?

(Joel Beasley at 00:36:43) Got it.

(Jason at 00:36:43) So that you can actually access your file system. And it's going to unlock your keychain, right? So no difference with your iPhone, right? When you're putting your PIN or you're doing your biometric, you're supplying an unlock. You're basically just kind of—I think they call them keybags now. You're unlocking a successive keybag that is a security zone around just private data that's used for encryption, signatures, that sort of thing. So it's been available for a while. Apple's doing a better job now of showing more capabilities.

(Jason at 00:37:12) Traditionally, they really just let you do create key, delete key. Sometimes that key wouldn't really end up where you wanted it to. But yeah. No. You can't—it's difficult to buy a computing device today that does not have this capability.

(Joel Beasley at 00:37:26) Now you guys are growing fast. Why do people buy it from a high level? You got CTOs listening, VPs of engineering, all types of tech leaders. What pain are they experiencing that you guys relieve?

(Jason at 00:37:38) So we provide phish-resistant MFA, right? If you're running anything that involves passwords, push notification, or TOTP-based authentication, you are vulnerable. And it's not a theoretical attack. It's actually happening. And if you don't believe it, go to GitHub, download EvilGinx, and have your security team point it at your own infrastructure. Everyone needs to move to phish-resistant MFA, whether it's with us or not. That's the only thing that's really going to protect you. The U.S. federal government is mandating all of their federal agencies get off that style of MFA by the end of 2024, I think. So, you know, you have a real problem you must address, whether you solve it with us or not.

(Jason at 00:38:22) Now we think you should solve it with us because we have a principled solution that's a very easy end user experience, right? Security companies that don't consider usability and UX are kind of creating their next vulnerabilities. So we spend a lot of time making it easier on your end users. But also, you know, we have a pretty strong fine-grained policy engine that we built from the ground up as well that really helps you define your risk profile, right, your unique risk profile in a super fine-grained way. So we have customers that write policies that say things like, I want to check certain registry key values that exist. I want to check the idle screen lockout time is there, right? They're verifying all of these controls, mapping into a high-trust device, and then letting that proceed to high-risk applications, low-trust devices, and whatnot. And there's a lot of authentication solutions on the market. There's very few that have the architecture that we have, and there's no one that's done it as principally as we have.

(Joel Beasley at 00:39:25) Do you think the companies like Mimecast and KnowBe4—my exposure to them has been primarily phishing training, right, for employees at scale. Do you think those types of companies are going to pivot into this identity space?

(Jason at 00:39:41) So it's kind of a couple questions in there that, honestly, I don't have the answer to because it required a bit of privilege on their part. So first, KnowBe4 is a great partner of ours. We work with them a lot. So when I was saying earlier, you can't train the problem away—that's true, and that needs to be the goal, but it's also going to take you time to get to the goal. So in the meantime, you do need to train your employees.

(Jason at 00:40:02) With that said, I do fundamentally believe that part of the problem with phishing and the root cause of phishing is that we're expecting people to solve what's fundamentally a computer's problem, right?

(Joel Beasley at 00:40:14) Yeah. I liked when you said that. That really clicked with me. For me, not having experience in this space but being a technologist, when you said that, I was like, oh, that's good. I bet you say it a lot, right? You have to talk a lot to different prospective customers and stuff, but it really comes off well the first time you hear it.

(Jason at 00:40:29) Yeah. When you pitch a lot, you've got to find a small set of statements that resonate. If someone really wants you to dig in, then you can kind of dig in and geek out.

(Joel Beasley at 00:40:39) The Ron Burgundy one was my favorite, though.

(Jason at 00:40:43) You know, that's the thing. The technical term is confused deputy. If you actually look at security research, the problems that they look for in certain protocols is, is it vulnerable to a confused deputy and whatnot. But I think you can make a strong argument that Ron Burgundy, fundamentally an anchorman—his teleprompter protocol is susceptible to a confused deputy. Yeah. It's fun.

(Joel Beasley at 00:41:05) I love it. So people want to learn more? They want to try it out? They want to just explore this world? Where do they go?

(Jason at 00:41:13) BeyondIdentity.com. There's a sign-up page to try it out. You know, I've mostly been talking about our workforce product, which is kind of—it's an IT product that your IT or security team would install for your workers and contractors. We have a dev kit version of the product. So if you wanted to build this experience into your applications for your end customers, you could. And you can get to that on our website as well. We also have what we call an SDO, a Secure DevOps flavor of our product, which is pretty cool. And what it does is—so everyone listening to this probably writes code or has written a lot of code. You all use Git. Your Git repo may be backed by a different company, but, fundamentally, you're all using Git.

(Jason at 00:41:52) You all manage SSH keys, right, to authenticate your database syncs, right, your repo syncs. And we all kind of probably know this, but we overlook it pretty commonly. That SSH key doesn't have anything to do with the authenticity or authorship of each individual commit, right? Whatever your configuration setting is and your setup is going to show up in that git commit, right? You can do --author=Donald Duck on a commit, and it will gladly take it, right?

(Jason at 00:42:22) Another Ron Burgundy problem. So how often as an engineering leader or even as a security person doing incident response, have you looked at a Git log and tried to figure out exactly who did this commit come from, right? And even if all the names are actually there, how do you know it's actually true? So no one signs their commits. SDLC integrity is now starting to become a big issue, right? The most well-known integrity incident was with SolarWinds a year or so ago, which was fascinating. If you really care about the integrity of your software development process, you need to worry about four things: source code integrity, build integrity, distribution integrity, and third-party bill of materials integrity. The SLSA organization is a great place to go look to learn more about those four areas.

(Jason at 00:43:12) But our SDO product is basically a seamless source code integrity product. So when you're running our platform authenticator, in addition to helping you log in to all of your corporate services, we will set up a signing agent, and we will update your Git config file on your targeted repos. So the next time you type git commit, the commit itself is signed with a key that's cryptographically linked both to your corporate identity and the security controls present on your device at the time of the commit. So, yeah. Go to our website, got a couple tools, and we're always happy to talk more if anyone's interested.

(Joel Beasley at 00:43:46) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you'd like to hear discussed on the podcast, either add me on LinkedIn or send me an email: [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.