Security Unfiltered
Security Unfiltered
From #Boeing to #Google: Jake Moshenko's Journey with Cutting-Edge Security at Authzed
What if the smallest oversight in software could have catastrophic consequences? Join us as we uncover the remarkable journey of Jake, a visionary engineer who has made significant strides in the tech industry. From his days at the University of Michigan to influential positions at Boeing, Amazon, and Google, Jake's story is a testament to the power of curiosity and relentless problem-solving. Discover how he pioneered Quay, the first private Docker registry, and positioned himself at the cutting edge of security and containerization.
Ever wondered about the stringent processes behind aviation software? Jake takes us through his meticulous work at Boeing, where creating safety-critical software is both a science and an art. He shares the rigorous testing and standards like DO-178B and MCDC that ensure the fail-safe operation of flight systems. Jake's insights illuminate how even the smallest IT services can have profound impacts on safety, offering a rare glimpse into the interconnected world of aviation technology and its regulations born from past tragedies.
As we wrap up, we venture into the realm of high availability software and evolving security technologies. Jake draws parallels from the aviation industry to illustrate the importance of redundancy and robust planning against failures. He discusses the benefits of unified authorization services and modern models, providing practical advice for handling software downtimes and authorization challenges in today's dynamic IT environments. Finally, listeners can learn how to connect with Jake and explore his current venture, Authzed, gaining further insights into innovative security solutions. This episode promises invaluable takeaways for tech enthusiasts and professionals alike.
Follow the Podcast on Social Media!
Instagram: https://www.instagram.com/secunfpodcast/
Twitter: https://twitter.com/SecUnfPodcast
Patreon: https://www.patreon.com/SecurityUnfilteredPodcast
YouTube: https://www.youtube.com/@securityunfilteredpodcast
TikTok: Not today China! Not today
How's it going, Jake? It's great to get you on the podcast. I'm really excited for our conversation today.
Speaker 2:Yeah, it's going great. Thanks for having me.
Speaker 1:Yeah, absolutely so, jake. I start everyone off with telling their background right, how they kind of got into IT, what made them interested in security. And the reason why I start there is because there's a lot of people that could be listening, that are maybe trying to get into IT or trying to get into security for the very first time and hearing everyone's background I have felt, you know, lets people know that, hey, it's possible, right? Maybe they come from a similar background. They're saying, well, if this guy did it, maybe I can do it too. So what's that background?
Speaker 2:Yeah, I guess I probably come at it from a little bit different perspective. It's sort of like an accidental focus on security. My background, though, is that I'm an engineer by trade. I went to University of Michigan for engineering. After that I went out to Seattle and worked for Boeing. I worked for Amazon, which is where I got my start in distributed systems and service-oriented architecture, those kinds of things Then came over here to New York, worked for Google for a little while doing APIs, infrastructure, and then left Google to start a company with my co-founder second-time co-founder now, but a co-founder Joey and we left to start a company building a web IDE integrated development environment, so a tool for coding as part of that.
Speaker 2:The IDE never really took off in the way that we wanted to, but we did build a tool called Quay, a service called Quay, which was the first private Docker registry, and if you know anything about Docker, docker is kind of like a security-forward way to run lightweight processes and, as building the first Docker registry, that really kind of put us at the forefront of security and infrastructure and this whole containerization revolution that was happening at the time. So when I say we were the first private registry, we were before Docker Hub was like even a thing before you could get it from any of these other vendors that now offer registries. So all of a sudden we were both engineers but we found ourselves in this sort of cloud-native containerization space and in sort of a very security-focused way. So at the time we were doing builds like CI, builds for your containers in a way that had sort of provable bill of materials, right. So some supply chain security stuff. It's a technology for containerization, right. You don't want to be running any software that's malicious. You don't want to be running software that you don't know what it is. So that was sort of accidental.
Speaker 2:We ended up selling that company to CoreOS. Coreos was kind of like a security-focused containerization operating system. Coreos ended up getting sold to Red Hat. Red Hat got sold to IBM and we were like, hey, let's go start another company. A little bit of a wild ride there. We went from a two-person company to a 400,000-person company with sort of a direct lineage. You can actually still go and buy Quay from Red Hat, from Red Hat IBM today. So that's like still a thing that you can get.
Speaker 2:So then when we left to start this new company, we were like what's this challenge. What's a challenge that's been digging us? What's been causing us to slow down? What's been causing us problems? One of the things that we landed on was this authorization challenge. Right, so when we built Quay, we were like, all right's, just copy github's permissions. That was our authorization thesis. Let's just do what github did.
Speaker 2:And so we we copied that at first and we launched it, and then the requests started coming in. They started saying, uh, all right, that's cool, you've got these roles, but I want groups now and I want organizations and I want groups that can be a part of groups and I want uh namespaces and I want nested namespaces and I want to that can be a part of groups, and I want uh name spaces and I want nested name spaces and I want to be able to federate permissions anywhere. And it was kind of like this thing that we could never quite keep up with and it was the security sensitive code. Right, authorization code is very security sensitive. No one ever wanted to touch it, and so we're like let's go and do something in that space. Let's make that code something that you don't have to write, that you can delegate out, you can set yourself up. Uh, for success.
Speaker 1:I'm in sort of like a scalable, flexible way and that's what we're doing now at offset, and we've been kind of shipping that mission ever since well, that's really fascinating, you know, because you come from an engineering background and I I wonder if that same mentality kind of you know, propelled you through everything. Right, you're identifying a problem and you're thinking how can I solve that problem? Right, is it via methods that are already existing? Maybe it's a novel way, maybe it's, uh, you know, adjusting the, the current methods a little bit, right You're, you're going through that thought process of, um, you know, identifying the problem and then solving it. Like I talk about this sometimes, where you know my, my wife, will come to me with a problem and I have to, like, take a step back first and say do you want a solution or you want me to hear?
Speaker 2:right, you want me to just hear you out, or you want the solution, or do you want me to hear Right?
Speaker 1:Yeah, totally. Do you want me to just hear you out or do you want the solution? Right, and it's a different way of thinking, I think.
Speaker 2:Yeah, definitely, scratching our own itch is part of our DNA as entrepreneurs and as company builders. So when we built Quay, it was to address a need that we had found when building our IDE. Right, it was to address a need that we had found when building our IDE. So we needed to be able to run user-supplied, user-written code on development servers where they could sort of debug those things, and so we packaged up that code with containers and then we needed a place to put all of this proprietary code. So that's where Quay came from and we said, well, if we've got this problem, other people probably have this problem too. Let's commercialize this service. That we felt.
Speaker 2:And then sort of the same, we're using the same pattern here, which is we've struggled with authorization in the past. You know we filled up entire whiteboards with how do you build a scalable authorization service that's flexible enough to work for kind of any service, because if you take any of those parts away, it becomes sort of a tractable problem. But when you have a need for scale and flexibility and high throughput and low latency, that's what makes it really tricky and that's, you know, that's what bit us in the past and that's what we set out to solve this time around.
Speaker 1:So talk to me about that a bit, right, because I think a lot of people will say you know, get an SSO provider and that'll solve it all. Right, that's kind of the mentality of IAM almost to some extent, that kind of offset that or augment that in some way that provides additional value in ways that an SSO provider won't.
Speaker 2:Yeah, this might be a good time to jump into the difference between authentication and authorization. So an SSO provider is really going to help you understand who you're talking to right? This is authentication. Who's on the other end of the internet who you're talking to right? This is authentication. Who's on the other end of the internet who has provided evidence in the form of a certificate or username, password or whatever, who has provided evidence of who they are? And when you use AuthSense, you still need to have an authentication provider.
Speaker 2:We support all the big ones. We support OIDC and SAML and these various different ways, and then things like Auth0, where they can do username and password. So that's the authentication side of the coin. What we deal with is the authorization side of the coin. You know who you're talking to. Now what are they allowed to do? Is Joe allowed to access the balance of this bank account or initiate a transfer? I know I'm talking to Joe, but that's not enough to make a decision about what Joe is allowed to do, and so what we've done is we've built a service to help you sort of model that out for your application in a really flexible way and make those determinations in a secure way.
Speaker 1:So it's more application specific of how your users should be interacting with that application, with that data and whatnot.
Speaker 2:Totally, and usually the product manager has a really strong idea of how they want the application's permissions to work. But sometimes engineering is like well, you want groups Cool, give me a week. Oh, you want groups within other groups Cool, come back in two years, right. It's like not all the asks are equal and sometimes the nuance of how to actually make that thing perform. The reason I bring up groups within other groups is because it often requires a recursive join or recursive expression which can send a lot of traditional software into fits. So they already have an idea of how they want the application to function and what their users would find delightful. But then being able to actually build and ship that can be a challenge.
Speaker 1:That is. That's really fascinating. You know, I work with a lot of different developers and one of the last things that they ever want to, you know, discuss with me as a security professional, is that authorization, part of it right, is the, is the whole IAM side of it. They're, they're, they're always asking is there a way that you could just, you know, set something up and we'll, we'll direct the request through that, you know, and, um, it's a, it's a new approach to to, I guess, building out that core functionality? You know, cause it is so it is so arduous, it is very painful, you know, because it is so it is so arduous, it is very painful, you know, and if you do it wrong, your entire application is at extreme risk yeah.
Speaker 2:Yeah, um, totally. It's a common refrain like why can't we just set up a piece of infrastructure in between the request and the service? That will sort of make this fail safe for us, right? Just take this off our plate.
Speaker 2:I mean, the reality is that oftentimes there's existing state behind the scenes that means that you don't have enough information at request time in order to make an authorization determination, right? So let's go back to my example. Is Joe allowed to read the balance details from this bank account? Okay, he's got the account number. I know it's Joe, right? If I look at the rest request and I look at the URL parameters, it's like account number and I've got an identity baked in in the form of a jot or something. But there's an existing relationship behind the scenes. Where is Joe an owner of the account? Is Joe a spouse on the account? Is Joe the CFO of a multinational organization?
Speaker 2:There's a lot of different ways that that decision can be made and it can't all be boiled down to request time information. And it can't all be boiled down to request time information. If it could, this would be easy, right? We'd just set up some sort of policy engine in front of the application and just direct all of our requests through there, but it's just never that simple. You can get it's maybe like a 50% solution. 50% of the time you can figure out if it's allowed based on stuff that's available to you at the request layer, based on stuff that's available to you at the request layer.
Speaker 1:Yeah, that is definitely an area that's kind of almost untapped right in the security IAM space, and it's also a new way of thinking about it, so it's very interesting to me. You know, I want to take a step back. When you were at Boeing, what did you specialize in by chance?
Speaker 2:back when you were at Boeing, what did you specialize in? By chance? Yeah, boeing was my stepping stone into sort of like the tech ecosystem. But I was in the flight simulators group, so working on the 787 before it existed, right before there was a physical airplane with the number 787 on the tail. We were in there proving out the control laws and making sure that the plane was going to fly the way that the pilots would expect and in a safe fashion, and it was specifically the engineering simulators. So the flight controls group would have an idea. They'd say, hey, I wonder what would happen if and we'd model it out in the sim and we'd put a pilot and you know one of those big full motion simulators and we'd see what happened, see if the pilot liked the way it responded or found it confusing or whatever.
Speaker 2:So that was kind of my stepping stone. Amazon was really my first sort of internet focused company, sort of relevant to what I'm doing today.
Speaker 1:Well, with Boeing, though, you had to have a certain level of curiosity. You had to have a certain level of curiosity. You had to have a certain level of, you know, thinking through complex problems that could potentially be like life or death. You know, 10 or 15 years down the line, right, maybe not in the present day, but you have to think through different scenarios like, well, what if this thing goes off? What do we have for compensating controls around it that can potentially assist in some way? And so it's a very interesting way of thinking that a lot of people typically do not think about or go down that path at all. Do you see those skills that you gained there, you know, kind of prevailing through even to this day.
Speaker 2:First of all, I don't want to overstate my role at Boeing.
Speaker 2:So, there were flight control engineers who would have an idea of what they wanted to happen, and then it was up to my team, my group, to turn that into code in the simulator. Right, so it was more just verifying what they had done. Code in the simulator so it was more just verifying what they had done. There was an interesting experience I did have, though, when I was at Boeing, which is I took a DO-178B course, which is safety-critical flight software.
Speaker 2:So you get an idea of how software gets written in such a way that you know it's not going to fail in flight when people are on the line, when lives are on the line, and part of that does stick with me today.
Speaker 2:So the thesis, the fundamental crux of it, is every piece of software has to be traceable back to a low-level requirement, a high-level requirement, and there has to be a test for that requirement. That's how you write safety-critical software. And then there's another concept called MCDC, which is not only does every piece of code have to be tested, but every path through the code has to be independently exercised and tested. And so that way of thinking has really stuck with me to this day about how do you build a reliable service. How do you build a high performance, high availability service? Yeah, I would say that was sort of like the biggest takeaway outside from being just like an absolute blast of a job, right, like you know, when I would set up a new flight control, uh, I'd be like, oh well, I gotta see if it works. So I'd go in there and fly it right that was fun super fun.
Speaker 1:Yeah, that that is pretty awesome. You know, I not not like it's any comparison, right, I I got Microsoft flight sim and uh, you know, of course, like I turn it on and it's like hard as hell to fly, like I'm over here just trying to wing it and I'm like, all right, maybe I should go back to the tutorial, go to the tutorial and, like you know, it's a little bit better, but it's like man, I'd have to spend like a hundred hours before I could. You know it's a little bit better, but it's like man, I'd have to spend like a hundred hours before I could, you know, reasonably do this thing and like really pay attention to it. It's, it's remarkable, you know just the kind of, I guess, the, the different systems that are involved in a, in a, in a plane, right, flying a plane, and how they all kind of, you know, intermingled to some extent, and how they work together and that's all that.
Speaker 1:Safety critical software has always been very interesting to me, right, because I only deal with, you know, what 99% of the IT world deals with, which is like non-safety critical lives are not typically on the line or anything like that. You know that will be directly impacted by the software that you're writing or you're trying to protect or whatever it might be. That's a very interesting, that's a very interesting like scenario. You know who came up with that process and procedure of testing? Like you said, like it all has to relate back, then it has to be individually tested. Do you know, like, where that came from?
Speaker 2:potentially, I don't know who the authors of the standard were, the certification but sort of one thing in the aviation world is that all of the regulation is written in blood is what they say.
Speaker 2:So usually when something goes catastrophically wrong, then they go back and re-examine the processes and re-examine the regulations and put new things in place to make sure that that specific thing never happens again. So my guess is it came from there, right, like we put some software on a plane, and it didn't go so great. So maybe the next time we do that we should think about it a little more, a little more. Yeah, it's interesting, though, when you brought up the topic of like it not being, like lives not being on the line. Um, it's interesting how often things get commingled in a way where seemingly benign services like do put lives on the line.
Speaker 2:I think there's a lot of stories that came out of the crowd strike thing that just happened, where, like crowd strike says, you, you can't use this on systems that are, like vital for life support, right, that's fine, right, that's totally like people don't do that.
Speaker 2:But what ends up happening is that they use it to like run the like electronic charting solution at a hospital, and then that's down, and then they don't know what medicines they can give to people, and then now, all of a sudden, lives are on the line and it's through like this tangential or like this inversion of uh priorities, where things sort of like bleed. So you generally, like you want to make sure that you're building high quality, reliable software, whether you you think lives are on the line or not. Um, and the other thing is that like there should always be a plan for when it goes down, because no software is 100% None. So it's like if this thing fails, like on the airplane, our solution to that was you have three copies of the software and if one of the boxes disagrees with the other two, you shut that one off and restart it and then the plane just flies on two. So it's like nothing is ever up 100% of the time. So what's your strategy?
Speaker 1:What's your plan when it inevitably goes down the worst possible time? Yeah, that is. It's fascinating because you know that was my initial response to right was well, why are we so dependent on CrowdStrike? But then, at the same time, it's a lot more difficult to pitch two EDRs to the board or to the CIO than it is to pitch one. I mean, for a company that I worked for previously. They were a real big McAfee shop McAfee all across the globe. I'm sure that by the time we got rid of McAfee we were probably their only customer remaining.
Speaker 1:Something like that and just trying to pivot to CrowdStrike was a multi-year process. It was like they literally tried it one time in a three-year period and it failed. Like the internal buy failed and then, like a year later, they tried again and that's another three years of trial and error and everything else. Like that. Right, like it's. It's a very arduous process, but for a piece of technology that is so tightly integrated into the system itself, right, I mean, like the issue was a couple lines of code caused the computer to like infinitely blue screen. Essentially, right, that's.
Speaker 1:That's a very difficult situation. That it's like. You know, as a technology professional, you, you can account for that. You can kind of plan for it to some extent, but just thinking of how that planning goes, it's a little bit farther down the priority tree. You know like I'm more worried about like backups being corrupted or and systems going down with no backups and things like that, right before I get to crowd strike, who's a tried and true, proven technology up to that, up to that event which, of course, the one time that they have an issue is on the global stage Maybe the worst time to have an issue.
Speaker 2:You know it's like any of the other failure domains that we talk about. Right Like you don't want to have a single power provider, a single internet provider or be in a single data center. Now there's another checkbox. Right Like we're not using a single operating system vendor. We're not using a single security vendor. These things happen. Operating system vendor, we're not using a single security vendor. These things happen In the startup land. We had Silicon Valley Bank was it last summer, I think where they were struggling and all of a sudden, startups aren't allowed to have a single bank account anymore. It's very similar to the aviation regulation is written in blood. It's like now, okay, we found a new way that things can have coordinated, cascading failures, and now we have to go back and add that to our checklist of things that we worry about and think about. It's kind of interesting too, because it was affecting one operating system so totally. It was almost like what we anticipated Y2K would have been. It was just 24 years late, right.
Speaker 1:It was like one whole operating system just disappeared yeah, that's a that's an interesting way of thinking about it. I never thought about it like that is like what we thought y2k was going to be. You know, I was pretty young when y2k was coming along and like that's all that people were talking about and I'm just sitting here like I don't know, like am I going to be able to watch my cartoons? You know, like that's all that people were talking about and I'm just sitting here like I don't know, like am I going to be able to watch my cartoons? You know, like that's what I care about.
Speaker 2:I was like I thought that the whole thing was overplayed, because I'm like, did nobody think of just setting the system clock on one of these computers to 2000 and see what happens? But obviously that was like minimizing the whole situation, right, like it's more than just personal computers at play.
Speaker 1:Yeah, you know, even to this day, like I don't quite completely understand it, you know, because I'm thinking of, like, how computers are and they just count. You know, like in the background they're just counting forever. Yeah, so like, why would we think that there would be a weird situation with that? I, I don't know. Well, you know, that's just someone that wasn't old enough to go through it, I guess well, that's how they work.
Speaker 2:Now, right like that's how athletics oh, but they weren't at the time yeah, and then a lot of software was written, just assuming you'd have like a two-digit date field, and I was like, yeah, are these two numbers bigger than these other two numbers, uh, that kind of thing.
Speaker 2:God, so like zero, zero is smaller than 83 and you're like this person must be younger or older, whatever you know, like I don't know born first but yeah, it was just a just a whole thing and it's funny that the world got to kind of witness what would happen just 24 years too late right.
Speaker 1:So we talk about a lot of it's kind of like single point of failure. Right, we're going guys, land a big customer like Delta or something like that, and then your solution goes down. Now Delta's complaining about you in the news. But with your background, you know, with Boeing and the other companies that you were at, you probably have like HA built into your mindset. With whatever you're doing, it's going to be HA to some degree. What does that look like, right?
Speaker 2:Yeah. So it's definitely built into the product and you're right, right, if our product goes down, you can't answer those questions, and if you can't answer those questions, you can't make progress as a product. So HA is built in. So like, think primary and secondary load balancers, think a data store like CockroachDB or Google Cloud Spanner. That's inherently a multi-region, distributed data store. Think distributed systems, distributed caching, with multiple copies of data sprinkled everywhere, all those things.
Speaker 2:So our service is actually modeled after an internal service at Google called Zanzibar, and one of the things that drew us to that model was the fact that Zanzibar runs at. One of the things that drew us to that model was the fact that Zanzibar runs at Google with five nines of uptime. So if you're five, nines is, like you know, minutes of downtime per month or something like that. So five nines is usually sort of the gold standard for, like telephony or like high availability things that aren't airplanes. So by copying sort of that architecture and using the same mitigations for single points of failure, that's how we managed to keep a highly reliable, highly available service yeah, it's uh.
Speaker 1:when I was studying for my ccsp and they started going over like high availability and uptime and all that sort of stuff, was it like S3 is like 11, nines or something like that? It's insane availability and uptime.
Speaker 2:S3 is 11 nines for durability.
Speaker 1:I think we all know S3 has gone down in the past.
Speaker 2:It's usually for something tangentially related, like Like a misconfigured router or something, but yeah. So the goal for S3 is not to lose your data Right and to be able to survive, like asteroid strike level events.
Speaker 1:That would be really fascinating. I mean, like you know, in situations like that, like when my mind starts going down that path, it's like you know what is actually going to be left, and I guess S3 will still be around yeah, a lot of that like disaster um, like disaster recovery planning, I feel like is a little bit tongue-in-cheek, like some of the scenarios that we plan for.
Speaker 2:Like, well, what if new york city, uh, which is where the founding team for our company, gets hit by an asteroid? We're like, well, that'll be, but none of us will really care, right, we're at ground zero.
Speaker 1:Yeah, it's a weird path or, I guess, like project you know, because you kind of do it regularly in security to some extent is a disaster recovery.
Speaker 2:And you have to test it too. That's the part that people never go back and finish. It's like we put together these plans, we bought a bunch of infra, we put everything in place, but we never tested if any of it actually works.
Speaker 1:Yeah, I worked for a company where they claim oh yeah, we tested. We do this tabletop year round or yearly, and it's for a whole week and we always test it. And I just asked one question Okay, well, what domain controllers do we typically restore to a backup, because that would be the first step in getting our network back up? And they're like, we don't actually do that, we just make sure the backups are there and they're, you know, stored properly, like well, how are they stored? How?
Speaker 2:do you know?
Speaker 1:Like, oh, you know, like they're secure, and I look and they're unencrypted. I'm sitting here like guys like what are we doing? How are we passing anything right now? Yeah, I um, when we talk about disaster recovery, I kind of go back to this, this story that I heard, um, you know, in during nine 11, right, it took place during nine 11, right.
Speaker 1:But you know, a year or two before nine 11 took place, this person, working at a firm that was in one of the towers their HA site was in the other tower, oh my gosh, and they were doing disaster recovery planning and he was in a room of 20, 25 people and he was literally the only one in the conference room that said like hey, I know this is never going to happen. I know that this is crazy, you can laugh at me, that's fine. But what if both towers like have a catastrophic issue? You know power is taken, a catastrophic issue. You know power is taken out, or you know, maybe they fall down or something like that? Right, like what if something like that happens?
Speaker 1:And literally everyone said that will never happen. And he said yeah, but like can we just plan if it does? You know what? What if it does right. And so they entertained it and they developed like a big, a big like tupperware, like a big plastic container containing all the documents of how to restore the company back to its original I guess running state, good enough to run and serve its key customers and whatnot, Gave you everything of taking power of the company and everything else like that right. A couple years later, this plan is actually enacted and they hired a company to actually enact this plan right, and they had certain people that were allowed to enact this plan and the one guy that was in the room that you know pitched this idea was the one guy that was late on 9-11 to work and he had he had access to this box. He had it, like you know, locked away in a secure place and he, you know, took this box, took it over to this other company and they, they restored this company wow, I've never heard that story.
Speaker 1:Yeah, I looked it up previously. There's like one article on it. I can't even remember the company name. I'd have to look it up again. I'm sure people are probably going to say I'm lying or whatever, but I read it and going through that path and then taking part in disaster recovery planning myself, it kind of takes you down a weird place because it's you know, kind of like what that guy said. I know this is never going to happen, but like can we just talk about for five minutes if, if, what it? What if it does happen?
Speaker 2:Yeah, Forces you to really think outside of the box and and think about what failure domains might exist that nobody thought about yet.
Speaker 1:Right, yeah, like, even you know, even like when seal team six was raiding bin laden's compound, right, the youngest guy in the room was like hey, I know this is never going to happen, but what if a helicopter crashes, like in his front yard? What are we going to do? And everyone was pissed off at him because he brought that up, because he, you know, had that thought and that idea. And then everyone else was like, all right, right, well, what would we do? And they're like, okay, this isn't going to happen, but what would we do? And sure enough that one thing happens.
Speaker 2:Wow, man, we're way off the reservation now?
Speaker 1:Oh, have you not listened to any other podcast episodes? We go all over.
Speaker 2:Yeah, I'm just thinking this kind of stuff, these kind of stories, would tend to lead people down sort of like a conspiracy theory path, right?
Speaker 1:Yeah, yeah, I mean, I like to entertain, right, I like to entertain that idea because it gets your mind working in a different way. Times in security, we kind of we kind of brush off that, that tabletop exercise, or we kind of brush off, you know that, that disaster recovery plan that we have, you know like, oh, that thing that we never use, why are we even updating it? Um, it's, it's that. It's those like less than one percent situations where you know it's worth its weight in gold, that it really goes through.
Speaker 2:You know, it seems like it's always the last priority after every other thing, right, like shipping product and keeping customers happy and whatnot, but when you need it, you need it. It's like an insurance policy.
Speaker 1:Yeah, yeah yeah, there have been definitely some stressful times where I have accidentally deleted a customer's database and it's like oh, oh God, where's that backup at? You know it's a very stressful time. But with AuthZ and authorization overall and how the cloud is so rapidly, you know, growing and evolving right, where do you see this space kind of going in the near future? Right, because it seems like we're getting different permutations of IAM to some extent. Overall, that's kind of adjusting and refactoring to this new world of the cloud.
Speaker 2:Yeah, I think it's interesting to consider what if every piece of software that you brought in to your company used a service like Outset behind the scenes to store authorization.
Speaker 2:Are there any delightful, interesting experiences that you could build if you now had authorization as a separate service for all of the software? Right, could you audit things, could you see and visualize things, and could you guarantee access for things that you otherwise wouldn't be able to do if your authorization were in like a heterogeneous set of solutions? Now, obviously that's very selfish for me to bring up right, because, like in that scenario, our company does super well, but I think it's worth asking right, like are we doing things in an efficient way, or are we doing things in a way that we're building the experiences that our users are demanding? So I guess I see that as a potential interesting outcome from this new generation of authorization, which is like well, what if all of these things can start speaking each other's language for authorization? What if I can start granting access to things based on access that exists somewhere else? Kind of questions like that, and I won't claim that I have all the answers, I just think the questions themselves are kind of interesting.
Speaker 1:Yeah, it's really fascinating to see how the IT world is evolving, because we're kind of, to some extent, taking different security principles or different security responsibilities and we're offshoring it to some extent. Right Like I don't have a better term right now for it, but that's what's coming to mind we're putting we're externalizing it.
Speaker 1:Yeah, we're externalizing it or delegating it that's probably the perfect word, right. We're kind of delegating that difficult part, like you described it or maybe even I described it right where the last thing that these developers want to hear from me is I am in groups and god forbid I say a nested group to them, like they're gonna throw something at me if I say that to them, which has actually happened before. And you know like it's. It's a huge, it's a huge pain, right, and as a security professional, I don't have the expertise to build it myself. You know like, if I did have the expertise to build it myself, I wouldn't be working that nine to five. You know like, that's, that's the thing.
Speaker 1:But it's something that is a critical piece of software that needs to take place in the software to some extent. Right, it needs to be managed somehow. You can't just have it open to everyone in the world and being able to delegate that away and put that into a solution where it's like, hey, this is all that they do. If they do one thing, well, this is literally that one thing, that's a huge benefit. And we do that with every other domain, we do that with every other facet of security and even IT to basically every extent you know like you don't hear about anyone using another solution next to GitHub to store their code, right Like everyone's, just like well, why would I go anywhere else? And so we're kind of going into that place where now we're delegating different components of IAM. No-transcript.
Speaker 2:And I think we already have come to terms with delegating out the I part of it. Right, people use hosted directory providers and they use hosted identity management, things like Auth0, things like SuperTokens, whatever. So we've already come to terms with that. And it's the IAM part, because the requirements are so fluid and flexible that it's really hard to come up with something generic until we have this model of storing things as relationships and storing things as a directed graph and making our determinations that way. That's really what brings the flexibility to sort of model anything right.
Speaker 2:You can model traditional RBAC, you can model ABAC. To sort of model anything right. You can model traditional RBAC, you can model ABAC. You can model Rebat like relationship-based access control, where it's like how many edges does the graph have? So this really is, finally, the to me feels like the right layer to program at, to describe to the system how authorization works in my app in order to be able to delegate it. And before that it was all custom code and all of that code was, like you said earlier, if you get it wrong, you know you've lost the game, it's game over. But of course, again, take that with a grain of salt, right? I have to feel that way as a founder of a startup in this space, but I truly do believe it, because time is our most precious asset, so I'd like to spend my time on very worthwhile things.
Speaker 1:Oh for sure. So maybe I'm thinking from an engineering perspective of choosing a technology and then deploying it and who's going to manage it, or everything else like that, right? Do you make it easy enough for the developers to integrate it into their workflows, to where they're the ones that are kind of, I guess, deploying it, deciding on those roles and the authorization you know, infrastructure or framework that they want to use? Or is it geared more towards like a security professional, where in that situation, I would basically present some questions to that developer and say what do you want it to look like? And then I build it out in you know your solution, and then they just integrate with it. How does that look?
Speaker 2:Yeah, it's almost always engineers or people on the platform team that are bringing us in. Security's role is usually let's take a look at their development practices, let's take a look at the source code run. Some scanners make sure it passes muster, but it's usually product teams that are bringing us in and it's because we offer that flexibility they can get to revenue faster, they can ship authorization experiences that would take longer if they were to build it in-house, and we make it super easy to integrate too. So we're open core, um, we're open source. Uh, like our, our primary authorization engine is fully open source. We come from a developer tooling background as well, so we have great tooling for integrating that open source in with like your ci and with your development workflow, and you can just spin up a container and that container can run next to your app like very easily. So all of that stuff. You know we've given all of that thought in order to make sure that this thing really just does kind of like plug into your stack hmm, yeah, it's really helpful.
Speaker 1:I always. It's always a struggle to bring a new technology into an environment because it's like, all right, what complexity am I introducing in ways that I don't even think of right now, you know, and that's always a huge issue. So any solution that makes an existing process or procedure you know easier or better in any way, you know, is always something that I personally want to explore more for sure, because it's an easier sell for me, right? And as someone that is in security, that is trying to always make sure that we have, you know, the best tech, the best principles and frameworks in place and whatnot, you know, that's something that I'm always looking for. So with that, jake, I think we're actually at the end of our time here, unfortunately, but it was a fantastic conversation.
Speaker 2:It went by so quickly.
Speaker 1:Yeah, right it. You know it tends to when we started going down the rabbit holes that we explored 2K and 9-11.
Speaker 2:I didn't think we were going there today, but we did.
Speaker 1:This isn't even the craziest episode that I've had. It's always a fascinating conversation. The craziest episode that I've had, it's always a fascinating conversation. You know, when you open it up to be more free form, like it is, you know you have those possibilities of like man. Where is this going to go? You know, and it's always fascinating.
Speaker 2:Excellent. Well, I definitely enjoyed our chat and thanks for having me on.
Speaker 1:Yeah, absolutely. Well, Jake, you know, before I let you go, how about you tell my audience where they can find you if they wanted to connect and where they can find your company if they wanted to learn more?
Speaker 2:Yeah, you can learn more at our website, which is predictably at authzedcom. I'm on LinkedIn. I'm not a big user of socials I think I have like two tweets ever but you can find me on LinkedIn or you can follow us. I write a lot for our blog, so if you want to get some insight into how I think about the particular problem domain or how we're building the company or anything like that, definitely encourage you to check it out Awesome.
Speaker 1:That's great. Well, thanks everyone. I hope you enjoyed this episode.
