Bridging Worlds: From MS-DOS Gaming to Cybersecurity Innovations

How's it going, everyone? and welcome to another security unfiltered podcast episode. So today I got a really great episode for you. It's with Orweiss from Permit IO. They're doing some really revolutionary things in the cloud and, you know, really helping revolutionize how we do IAM in the cloud. But I got a shout out. This episode would not be possible without 10kmedia. They did not sponsor the podcast or anything like that, but it definitely wouldn't be possible without them. They made this whole thing happen. So you know, if you guys want to go ahead and follow their page, hit up, you know, whatever their, their social media is and give them a shout out. So thanks, guys. Hope you enjoy the episode. How's it going, orweiss, it's great to finally have you on the podcast here. I think this thing has been in the works for a little bit now, but I'm very excited to talk to you.

And likewise the feeling is mutual. Very excited to talk with you, joe, and I'm sure it's going to be an awesome episode.

Yeah, yeah, definitely, i surely hope so. So you know why don't we start off with telling everyone how you got into IT, what made you want to go down this security path? right, and you know, i start everyone off with this primarily because you know it's helpful for my audience to hear everyone's background right, because maybe there's someone out there that's listening that is trying to make this jump in IT. They don't know if they can do this, right, they don't. They don't know, if you know, they have what it takes, and so it's always helpful, i believe, to hear someone else's story and maybe it clicks with someone. Maybe they say, oh wait, you know, maybe I do have a shot with this. So what's your story?

Happy to share it. I'm not sure if it's the best story for that particular dilemma, but still happy to share it. So I got into tech, i'd say at the age of five, basically when people ask me there what I want to be, i for some reason already told them that I want to be a software engineer. And I got exposed to tech really thanks to my sister's awesome and convinced my parents to buy a PC very early on, talking like when PCs just started and like it was like a 286 I think, and like mostly through like playing games and having to run them on MS-DOS, having to type in the commands. I both learned English, which is not my first language, and working with the command prompt and basically writing code, and from there it's kind of escalated quickly.

The most significant jump in my career was going into my military service in the IDF, was drafted into the intelligence core, into a unit called AD 200, which is the kind of the equivalent of the NSA, and there I went from like a silly script kitty that has been like building websites and games and stuff like that and maybe learning a little prologue and stuff like that in high school and went into like becoming an actual software engineer and that also really led me very quickly into cybersecurity. It's kind of in the job requirements when you're working for the intelligence core security cybersecurity both in how you write your own software and also in how you understand the enemy's software was mandatory very early on, but also very exciting and inviting very early on, so that gave me both the motivation, tools and perspective on how to do secure software development and that really led me very quickly to where I am today.

So I mean that that's maybe the most interesting way that I've heard of someone learning English right is learning learning it via MS-DOS. I mean, how does that even? how does that even work? Can you talk to me about like that learning process, because that's, that's very fascinating.

Yeah. So I'll say it's not the only input that I got for English. Also, like TVs and movies and books were there as well. But I think the most incentive was like, oh, i want to play this game, so I have to type English on the keyboard to make that happen. So initially it's just copying off, like my sister would write it on a piece of paper and I'd like copy the characters, not even knowing what they mean, from the paper to the keyboard, like to the screen, and with iteration, with the motivation of wanting to run things and wanting to play these games, i picked up the language. I think the game like that's.

A little later down the road, like not at the age of five, but like 10, 11, i think, i started to play civilization. I think it was civilization two from Sid Meyers, and there, like you have like full conversations with like the different. So it's a simulation of like running a country from like the Stone Age up to modern times and you're you have to negotiate with the AIs and it's like full on conversations. And I remember like sitting down with initially with a dictionary, a physical book, and later on with like a type in dictionary that you can like a small separate keyboard that you can type in. Does the translation for you, and I picked a significant part of my vocabulary from there and I think my vocabulary is still pretty odd, like I sometimes use higher than needed language because of that.

Huh, that is. I mean, that's really fascinating. You know, like you kind of immersed yourself into the language or that world of English just because you wanted to play video games. You know, i wonder how much of my own like language and experience came from, just straight up, playing video games, right, like, how much did I learn from playing video games? because I mean, i was addicted when I was a kid. I mean, you know, i still play video games today, i just don't have enough time, right. It's like that like meme, right, where you know all you want to do when you're a kid is play video games, but you don't have the money to pay for all the games that you want to play, and then you get a job and you have all the money, but you don't have the time.

Yeah, it's one of the ironies of life.

I think, in general, there's a lot of things that we need to learn about this around western civilization, especially as we're coming into things that will really shake up the job market, like machine learning agents affecting our jobs and changes in the balances between the different echelons of society, like there's the entire wage gap.

That is still, i think, a significant thing that we haven't solved. And also retirement, like if you take your story a step further, by the time you get to retirement, where you can focus on having fun, for example, it's not only that you don't have the time, you don't have the physical capability, and that's the thing, one of the saddest things and but I'm kind of delighted, the end of the tunnel that I'm kind of looking at is uploading ourselves to the cloud. Hopefully that will solve everything or make everything worse. Will have to wait and see dilemmas or conversations on futuristic dystopias. I'm also running, in addition to permit them, running, a podcast called command shift left and which is just for engineers coming in talking about random facts for developers, and we often find ourselves talking about dystopian futures and and if we're in a simulation or not, so for people that like that the check out command shift left.

Oh, yeah, that's. It's really interesting. You know what you brought up with. You know you, a lot of people wait for retirement to kind of live their life that they wanted to live. And I always stress it to people that you know you should be, you know, enjoying your life, right, like while you can, i mean it's.

I grew up with a lot of people that would say like, oh, everything's gonna change when you're 20. You know, everything's gonna change when you're 30 and 40 and 50, right, and you know, i got told by people that, like you know, i wouldn't do certain like physical activities when I'm in my 30s because everything is gonna change. And like, to me, how my brain works is, you know, when I, when someone says I can't do something or I won't be able to do something, it's like all right, well, time to go do it. Then, you know. But it reminds me of when I was working for a large company and one of my colleagues was I think he was at that company for 30 years just same company you know at for 30 years and he was talking about, oh, i want to retire in five years.

And you know I was asking him like, oh, what are you gonna do when you retire and whatnot. And his face kind of lit up and he was talking about how he wanted to travel the world and he had a list, and you know, of all the places that he was going to go, all the food that he was going to try, and I was like you didn't, like you know, explore any of these locations, like while you were here. I mean we give vacation time, like you have more vacation time than probably anyone at the company, because it's all saved up, like you never used it really, and you know he didn't right and I'm like, well, what? like? what happens if you retire and something happens? you can't go on your trip, you know, and his, his, he had no response. It's like man, this guy spent his whole life working for this whole trip and I mean legitimately, he may not be able to go on it. Right, like you never know what's gonna happen, he may not be able to go on. It is disappointing, right.

It's disappointing and it's scary, and I think the scariest thing is how accepted and mundane these kind of patterns have become. It's like you're gonna do this one job, you're gonna do it for this significant part of your life, and then you'll wake up at the other end of the tunnel and most people don't even stop to think about it, and And, and. I think that creates a lot of frictions for society. I also think, by the way, that creates a lot of friction for security. People are just going by the lines that are defined to them, even if those lines don't actually meet the requirements of their work or The security profile that they need from the work, so that it fails twice. One says You're limited in how you perform your job because of silly security requirements that are like from ten years ago.

For, except the, my pet peeve is Requiring people to constantly change their password. Research has already proven that that's a bad idea. It causes people to pick bad passwords and It causes them to forget their passwords more often, and that just creates more chaos. So patterns like that create us, create situations where we're both Have less performance in doing our jobs and we're less secure, and in general, it creates Scenarios in our life that are just as we just touch on now. They're just sad. It's such a shame Because we don't need to live in a box. We can open our eyes, we can Investigate what we're working on, we can find the Vulnerabilities and points and change the existence. That and we can make things better if, again, if we just give it a chance.

Yeah, you know, you brought up the passwords and I'm still kind of blown away that in 2023, companies still don't offer their employees a password manager. You know, like, right off the bat, day one Hey, create your password. This is a secure solution. Everything is going to be stored into here and then it automatically just stores, you know, whatever passwords you enter in and it'll automatically, automatically generate, potentially even rotate, these passwords. You know, so you're not worried about learning. You know 30 different passwords. You're concerned with learning one password and the way that they salted and hash it and store it and all that sort of stuff Secures that password, even if it's, you know, password one, two, three, like one pass. You know, like, i use that for my personal self and it's it's a fantastic solution, but I I think that it's just it's Really disappointing that companies are like not getting on board with this basic, this, this basic thing.

Software is evolving quickly, but the software that we're running in our societies, our cultural software, doesn't say doesn't get service pack updates as quickly as it needs. You can also look at like if you continue that line, because let's look at like the software that is running our bodies, it's also very hard to update And that also causes a lot of problems, including that a pet peeve that I have there is backache. Evolution hasn't really tweaked us Fully on to walk on to, so our entire skeleton is kind of Head-ock patched for walking on to. So we get back pains very early in life and they stick with us, which is very annoying. And that's again all about the paces of updates of the different layers that we work with. And I don't know, i'm not sure, if there's a solution for that again, except maybe uploading yourself to the cloud. Then you have a new layer of software as a clean slate that you can maybe Upgrade and update more quickly. But I guess we'll have to wait and see.

Yeah, i couldn't imagine trying to secure something like the metaverse or Trying to put guardrails in line, you know with with a service like that. I feel like I feel like that's just an impossible task.

It is a daunting one. First of all, you you can rest assured that there are people that are working on it, so we haven't really touched on permit itself yet. But my co-founder, or soft He worked at Facebook it's meta at the time and he saw, for example, that they've invested a team of 30 people for half a decade to build a level of access control that they have. Combining that with our own experience, that really taught us that this is a huge problem. That is that exists now. I, for example, had rebuilt our access control to the product in my previous company. They work out five times Before. The company was even three years old, and so in combining those two, we realized it's a huge problem now But it's only gonna get far worse, and so the bigger companies are working on these problems, but they're coming for all of us, all over all the software engineers.

Complexity is really is At the gates and I think it's becoming very apparent. I just come back. I just came back from a A kube con in Amsterdam and I think, without exception, not even a single company presented there Didn't talk about, in a large language, model that they're embedding into their software. So and that, and thinking of that are you it's. I think it becomes really easy to see where the complexity is gonna really slap us In the face.

So if up till now, the users that we were getting access to where human users working in their pace, it's becoming more and more machine learning agents on behalf of machine learning agents, on behalf of a long cascade of those on behalf of humans interacting for software. So now it's an AI agent that is interacting with the AI agent embedding in our app and That's a lot of fuzzy logic for access control and it's and it's right around the corner. Right, we're already seeing these being embedded and the problems and security vulnerabilities that will be creating our Are are also becoming apparent. So I think we're up for exciting times and even if we can't wrap our hands around it No one's asking us it's gonna happen and, and from my perspective, what we're trying to do is provide the tools so people can Remove the cognitive load, that they'll be able to focus on building the software and they'll have something that they can pull off the shelf that will, at least I help them carry this load as they're meeting the complexity.

Hmm, well, let's talk about permit IO. You know, you guys, it sounded like you saw this issue in the industry of managing, you know, roles and permissions and whatnot, which I've done that myself And it's extremely difficult to do on-prem. It's pretty close to impossible in the cloud, especially if you allowed your developers to get into the cloud before your security team can actually, you know, look at the cloud. It creates some very unique challenges. That it's just. It turns into an impossible spider web to untangle. So what are you guys doing differently than everyone else? that is, separating permit IO apart from the rest of the crowd. Because, you know, i feel like I feel like everyone does it a little bit differently. The value in this area is identified and companies are definitely paying attention to it, but I feel like the ones that make it, that make the engineers life easier, are the ones that will stand apart.

I definitely agree with that, and I think that's the one of the key things that also puts us apart from all the other players in the space. So most companies you'll interact with in this space they'll tell you something like you're an engineer, you like to build amazing things right. Here's building blocks, here's a policy engine like open policy agent or Cedar from AWS or there's a bunch of other languages. Here's a policy engine and here's a bunch of APIs. Go ahead and build your access control And, first of all, let's realize what is access control. So there's the decision making, there's the enforcement that you need to embed as part of the software, and there's all the interfaces and experiences around that. In the end of the day, access control is how you connect systems and people to what you've built. So it's a lot of interfaces that you've used a billion times and every time you use them, some poor schlep of a developer had to create them from scratch. So classic things like user management with the ability to assign roles, api, key management, secrets, management, audit logs So you can see what your customers did within the system. So your customers can see themselves what they did within the system for their own compliance and regulations, invites, approval flows, one user starts an action, another user approves it, permission requests, emergency access, and this list just goes on and on and on. So instead of telling people oh here's some building blocks, go ahead and build all of this. We're saying something very simple Don't. You don't have to. If you want, you can, but you don't have to. Here are all of these experiences ready off the bat. Just plug them in focus on building your core software.

So it's really about empathy. It's really about understanding what developers care about and what they don't. They care about building amazing technology, but their core amazing technology, not just run on the mill stuff that is not unique to any product, and I think that's maybe the most important thing in what we do. A key part of that is also embracing and connecting other people. So developers want to have this available, but they don't want to be fine tuning it all day long, especially when other people need to be able to participate. So you want product managers to be able to work on policies. You want security and compliance, obviously, to work on it. You want sales to and support to be able to affect this as part of a product, and the list again here continues. So it's not just about empowering the developers, it's about enabling the developers to empower everyone else and be the heroes of the story.

So, for that, one of the experiences that we've created and maybe one of our call to fame experiences, is our policy editor, which I like to say is an interface that a monkey can use, or even a product manager, if they're smart enough By the way, product managers are the ones that love the joke the most, ironically And so you get an interface that you can delegate to other people. Everyone can chime in on the conversation, but it still works with the best practices. It still generates policy as code that gets loaded into your Git repository, so you never lose control and you never lose the best practices as a developer. But you still don't have to do everything on your own and be the bottleneck for the organization Every time someone wants to add a role or make roles dynamic, or have an audit log for a certain behavior or enable people to invite other people on their own. So we get those off the shelf.

And lastly, another differentiator that we have and I think is also about developer empathy is being a policy engine agnostic.

So most companies, when you go to them, they'll tell you you got to use this policy engine.

It's the best because we built it, so it's the best right. And I think that's really weird, because when I think about developers, i think about a full arsenal of different ideas and languages and tools that people want to use, and like saying, oh, there's only one tool that you can use And that's the only one that you can, is very weird. Like different developers want different languages, different tools aligned with different tasks. So in permits, instead of saying, oh, here's another policy engine and you have to work with that one, we're saying let's just work with whichever policy engine you want, let's have interfaces that generate it in different languages, let's have generic adapters that allow you to and that's our open source project, opal that allow you to connect to different agents on the fly. So understanding what developers want and giving it to them in a way that meets the way they work, that's what differentiates us from everyone else in the space, and I think it's something that I'm very proud of and seems to be proving itself.

So is it a solution that already kind of builds out these permissions and the roles, potentially even like authentication methods for developers, of how their application will work with storing secrets securely? Is it building out these workflows automatically? you kind of go into your solution and point out like I want something that stores a secret, i want something that rotates a password or creates this authentication mechanism. Is that how it's interacting or integrating into the workflow?

So there are three key components that you mix and match. There's a microservice for authorization, what we call the policy decision point. So that's a microservice ready to be embedded. You can also consume it from our cloud, but for performance, latency, availability and security, it's best to have it as part of your app And it's based on your policy engine of choice, like Cedar or Opa. So we get that ready made for you. You just plug that in. And the other part is SDKs and plugins that create enforcement points themselves.

The main flow is a function called permitcheck. You're basically saying this is what's happening now. This identity is trying to perform this action on this resource. So your application code can just describe what it's doing, without going into the policy, without going into the decision making. So you can pepper your code with those very simple code. You can do that for decorators, for the middleware, for whatever suits your flavor of development, obviously, and that would connect to that microservice for authorization. And, lastly, you have the control plane and the interfaces. So you have the policy editor, so that on the fly you can say, oh, i want this role and I want these resources, and I want to say that these roles can perform these actions on these resources and I want these conditions for attribute-based access control, or I want these relationships for relationship-based access control. And you just create it quickly, either in code or on the UI for less technical people or for just technical people that don't want to dive into this because it's boring And it generates the code for you and loads it on the fly to the decision points in the application So it immediately updates. So you have the ability it's many moments in time to work through GitOps. You're creating code, pushing it to Git And from there it's automatically deployed via Opal to the live agents within the software And that's basically it.

And maybe the last thing is the experiences on top, because there's this foundation, event-driven foundation of decoupling policy and code and creating clear structures, resources and actions On top of it. You can now apply interfaces on top, so you can apply the user management. So, oh, i have the concept of a role, so I can just assign it to users. I have the concept of a tenant. I can put resources in that box and some users in that box, and now I can say, oh, only you can, only these users and resources can interact together. So, yeah, and these will just work with the user management, and with the tenant management, and with the approval flows and with the audit logs. Everything just emerges from the baseline that you embedded into your software. So, and you don't have to think about that, because the abstraction just builds it out for you. So that's the way it works. You have an SDK, you have a microservice and you have a control plane that gives you the experiences to embed into your software.

Hmm, that's interesting. You know it kind of, in a way, it seems like it's working with the developers rather than the developers working with the solution, in terms of you know it's there to really you know, immediately provide answers and solutions. You know automatically within the application and really limits you know the interaction right that the developers have to go and create. You know this authentication mechanism and we need to point it to this IDP and things like that right, like that doesn't, that doesn't exist with the solution. So that's very interesting and it and it works across all languages. I assume, like it doesn't matter what the developer is trying to work with it, it'll just work with whatever.

So we have, first of all, it's Swagger and OpenAPI base so you can always work with the API directly. We have SDKs for basically every language, from Python to Go, net, rust, java, elixir, even the esoteric ones. We have SDKs ready. It's easy to create more. Yeah, you can then bake this into your software in the way that's suitable for you. In general, the balance that I love to adhere to when building developer tools, there's this balance between how simple the tool is and how powerful it is. Obviously, the more opinionated and more simplified it is, it's easier to use, but it takes away the power. The balance that I like to strike is to have the power always accessible. You can choose, you can always dive into code. You can always use the API directly. You can always create interfaces, ui interfaces on your own, but there's an opinionated layer that would simplify it for you in 80 percent of the cases. In 80 percent of the cases, you just throw it in and it works. But for the other cases that you want, you're never limited. You can always dive deeper and use the direct raw power as a developer. I think that's very important. I think that's maybe what you were hinted at that this works with the developers.

The developers are the ones that are going to decide what this application is going to look like, how it's going to behave, what are the policies and however people are going to connect it. That shouldn't change. That's how software should be built by people that understand it, but it doesn't mean that they have to build every new concranny for every little thing in the software, or at least not at once. They should always have the option, but they should also have the option to focus on the things that are actually important at that point in time. Let's face it when you're building an application, there's a mountain of stuff to do and there's always the buy versus build dilemma. So you should be able to choose the right balance point for you at each point in time.

That's why we also provide the solution, first of all, with a very extensive free tier, but with usage-based pricing on top. You decide how much you use as part of this. This would grow with you and we're not like forcing you to make all of the decisions that they want, because we understand that as you build out software, requirements come in gradually and the requirements change. Your policy is going to change. You're going to start with R back, and then you want to have A back and you want to have Reback and you want to have ACLs and you want to have a bunch of stuff. But at the current moment in time you want something specific and you should be able to tap into that specifically without having to wreck your brain or wreck your budget just to get started.

Yeah, it's interesting. Where do you see this solution going and growing into over the next couple of years? Obviously, you have the authentication mechanisms and whatnot taken care of with the developers, But I feel like there's a whole other side where it could potentially be used to even audit current permissions within the environment and say, hey, you don't use this for the last I don't know two years, or something like that.

Let's clean it up.

Yeah, being able to maintain a healthy environment in IAM as much as you can Do. you also see where it's going, or is this something that you're exploring and whatnot?

So for sure. First of all, i'd like to think that I know where this is going. I'm no profit, so take everything as saying with a grain of salt, but I can tell you what I'm seeing and how I'm perceiving it at least. So, first of all, we're seeing that the complexity for software is constantly rising and with it the complexity for the authorization for that software. So the software itself is becoming the most critical thing that's already happened is the breakdown into the cloud and into microservices. Everything has become distributed. So instead of having one big, huge chunk of software now, we have a lot of small bits of software that we need to get specific access to separately. So that's one of the key things that we had to solve off the bat. So that's where those decision points come in, and the granularity of both embedding it and enforcing it is very, very important early on. So that's something that's happening, already happened, and we're in the midst of. Next. What's coming is complexity in the policy itself and how dynamic it is. So, as we're building more complex solutions of software, what they do is becoming more dynamic. So if in the past you had policies like just simple roles like this user can do that, that user can do that and that's it. Now a lot of applications have dynamic things like only users that have paid for a feature can use it, only users that are currently now in Europe can you do this action or work against this server, only users that have this quota left can do this action. And these kind of dynamic behaviors that are to some degree stateful, or at least have a stateful component that is changing at the authorization layer. That's becoming more and more commonplace because of the requirements for compliance, because of the features that we're building into the software and just because of the speed of software that we're creating. So that's really immediate next step and that's why we've created OPL Open Policy Administration Layer as an event-driven channel, because that's the only way you can meet those challenges if your authorization layer by itself is event-driven.

Next, what's coming and I've kind of already touched on it is the complexity and speed of the components using the software. So machine learning agents, automated agents, people using the software with APIs themselves, like more and more people, are becoming code savvy. Even if they're not using code directly, they're using low code interfaces. If they're using generative AI to drive things automated for them, they're using things like Zapier, that's becoming very, very commonplace as well. It's really around the corner, especially with the machine learning agents themselves, and so the speed in which your software is being used and the speed in which you need to check permissions for is going to explode in the next year and a half. So that's something that's happening and with it is also how you just reason around software. So if before you had policies that were thinking about how humans behave, now we need policies that are thinking about how machine learning agents are behaving, and then you get into that. Okay. So I've basically a policy that to some degree, especially if I'm gating another machine learning agent component that can be basically almost undeterministic or with having significant random, pseudo random factors built into it. So now I need my policy to also not be to be as flexible, to be as undeterministic or as able to take in the randomness or chaos on the other side. So we'll be seeing machine learning agents becoming part of the authorization layer.

By the way, in Facebook and Meta, which we have some visibility into through my co-founder, they have this already today. So, a lot of times, because of the complexity of the different elements of software and the different people interacting with it. There's an AI agent making decisions on who can do what. So, for example, it might this and they're in it's applying complex conditions and complex organizational flows to make the decisions. So, for example, it will look at behavior and analytics. Oh, you've been consuming more data than you usually do, or you've been accessing data that usually don't. This raises a flag And now, instead of just blocking you, it can decide to throttle you, or it can decide to ask your team lead if what you're doing makes sense, or to get another approval by another element of software that exists. So these are things that will also They're coming for everyone, also sooner than what we perceive as later.

Lastly, is well, i think what do you touch down with the behavioral analytics?

As this picture becomes more and more complex, as the audit logs are becoming more vague, as the vulnerabilities, the surface of attack the attack surface, sorry is growing, it will also need more intelligent, more automated solutions to recognize where things are going off beat, recognizing when users go rogue, when machine learning agents go rogue, when machine learning agents are being defrauded or being malused, all of these things are very imminent As I see it.

I think they're a clear part of the upcoming future, and that's basically just the tip of the iceberg. By the way, what I think the very classic question is okay, what are we going to do about this? I think what we need to do about this is, first of all, just cover our basics, because we haven't done that yet. That's what we're trying to do with Parinaio, and to provide interfaces that would make it approachable for everyone to work on this problem. By doing that, we can start to ramp up the conversation, but we should start with crawling or walking before we're running, and we need to get through to crawling and walking soon, because we'll need to be in running pace very soon. That's how I'm thinking about the future.

Yeah, the AI agent or the machine learning component of it, i find to be very fascinating. I remember working with someone and I got on the call with them for the very first time. While we were troubleshooting an issue with some random server in the environment, some calendar alert came up and said log into whatever servers. I'm on the security team, this guy's on the infrastructure team. I'm like what was that? Because that looked really weird. He said oh, we have this software in the environment where if you do something out of your norm, it locks you out of the system and it won't allow you to access it. And I want to prevent that from stopping me to resolve issues on these servers if something were to go down on the weekend or whatever. I don't want to wait for someone else's permission.

I was very in the middle on this, because what he's doing is it wrong? Sure, it's going against the security tools, security policy, probably even. But is he wrong for doing it? He has good intentions behind it, but that also opens the organization up to a greater insider threat situation where this AI, this ML, whatever it might be, is learning like hey, he logs into this critical server in the environment often. Well, if he gets laid off or fired or whatever it might be, and he just decides to go in there, that agent that was meant to protect that sort of login is now allowing it when it normally wouldn't. It creates a difficult situation, i think, for everyone in the organization, because security just wants what's best. These other guys, they just want to do their job and they want to be able to do it when they need to do it. Yeah, it's like what do you do? Where do you go from here?

I think you've basically brought us full circle, back to the mini conversation we had about passwords. If you're creating security culture that people can't work with or can't relate with or can't understand, that's bad security culture. Even if you're covering all of your bases, you'd fail in your job, because people will always adhere to norms and not laws. People will always find a way to make things work for them. By making it harder and missing the point, which is enabling the organization to work, you basically shoot yourself in the foot. I don't think anyone should be blamed here. I'm not blaming that engineer and I'm not blaming the app sec people that created that situation But we need to recognize such, basically vulnerability points in our security culture and build the tools the right way that provide both the security and the enablement to work that the organization needs. There's actually another classic story that I have from my Ministry of Defense days. Without going into the raw details, there was an air gap network, a very highly secure air gap network that was created for a very important project. In order for that network to work with other solutions, they created a data loading solution. There was basically stations where you can bring in whatever you need from external sources and it will go through protocols and scans and all the right things that you need to load the data in a secure fashion. On the surface, this looks great. We have a fully air gap network. We have specific nodes where we control data entry and we can limit things with our policies and with our scanning and our security tools.

Problem was that those work nodes, those stations to upload the data they were great, they were top of the line, but they were slow. They covered all of the bases for security, but they were super annoying to work with because you load in the data and you'd have to wait hours to get the result. On the other side, people being people, some of them said this is just like a small thing that I need here. It's like a small text file. There's no reason to wait hours now to go forward.

They found a loophole and they plug it in in a separate way. I can tell you there was a matter of time until really dangerous malware was exposed to the network itself and infecting critical spots of it. Again, people doing it, they didn't have bad intentions and they weren't aware of the risk of what they're doing, and so I really think the problem there is not just people circumventing things, it's around creating situations where people don't need to circumnavigate things. And, yeah, i think it's like the cultural aspect, or the human aspect, is probably the most challenging part of doing security.

Yeah, that is, that's for sure. You know, and I feel like one of the things that can separate you and your career is actually your soft skills of how how you handle those difficult situations. How you handle, you know, interacting with people, regardless of their team, their status within the organization, and you know all those things matter. It reminds me of a time when I was working for a company that you know did a very similar thing. They tried to air gap, basically, their critical servers and their security, you know, servers like the control consoles, right from everything else. The only issue was that they did it in such a way that made it extremely arduous, very difficult for even authorized users to log into that environment, to even just deploy patches. It was a very difficult task, and so when I took it on, we were two years behind on patches and people were still telling me that it was secure because no one can access it.

I'm like, yeah, well, you think one. You think that no one can access it from the outside because people have trouble accessing it from internally, but that's not a reason not to patch, you know, and doing some deeper digging, of course, the teams that were tasked with actually patching it, you know they didn't want to work with it. They literally told me they're like. You know, we have a change window and within that change window we have to be logged in, patched and done and the server needs to be rebooted. Well, we don't even have enough time to literally deploy the patches before we have to re-log in and do this whole process again.

It took them 20, 30 minutes sometimes to log in to the right place and just start the work And then at times out after a certain amount of time, and they didn't want to deal with that. And I don't blame them, i don't want to deal with that either. So, you know, it kind of became like my personal mission at that company to kind of dismantle this thing. But it was an interesting challenge because the person that created it was retiring and I don't know what it was like 90 days or something like that And so it was like, okay, i kind of have to maybe design this for 90 days because I don't want to, you know, completely destroy like his life's work at this company, at least not in front of him, right, like?

by the way, my general opinion is that air gap is a pointless effort, especially as the speed of technology accelerates, like the speed in which we're discovering vulnerabilities is constantly increasing, and so your ability to catch up when you're disconnected is gradually becoming irrelevant. And by becoming so, by air gaping, you're basically making yourself more vulnerable as opposed to being more, as opposed to being less, vulnerable. So I really think that air gap networks are pointless, aside from like very specific situations or very like when you can completely connect it, like seal it in concrete, lock it out from the outside world, like it's like a bunker that needs to run on its own for a while. Those are maybe the exception, and even there I'm not that sure. Other than that, you're using air gap solutions. You're mostly doing your security at this service.

That's my opinion, and I think what really makes it apparent is when you think about the cost effectiveness of your defense versus the attackers or offenders. For most, not that significant attackers like your just, let's say, corporate espionage or just run in the mill, rent somewhere, stuff like that they're not gonna waste their energy anyways on targets that have high security profiles, that have the ability to build significant modes and protect their networks. It's a waste of time And for them they have easier targets. So you already have the capabilities and budget. If you're building an air gap network, you already have the capabilities to fend these off rather easily, or at least contain them if the things go all right.

The folks that you are trying to protect yourself are basically the nation state attackers. Those are the ones that usually you're trying to use an air gap network to protect yourself And for them it's meaningless. Like we can look at the things like they're in our public, like Stuxnet and Olympic Games, It's really easy for an actor like that to. It's super simple. It's literally getting something across the smaller gap. It's literally how they think about it, and so it's basically pointless against the only kind of attacker that this might be relevant for. So there doesn't exist a cost-effectiveness point, an equilibrium point, where it would make sense. I think that's the best argument that I can put on the table against dismantling air gaps.

Yeah, with all of the different developments that have been happening, air gaps are kind of they're laughable, right. They're kind of more for show than anything else at this point, because when you say that you're airgapping a system, you make it sound like nothing else can access it, like it's just gonna run forever right, there's gonna be no issues that ever occur, because software runs perfectly every time, right. But as soon as you start diving into the architecture of the air gap, they're like it would always come back to oh well, windows updates, it has to have access to Windows updates, it has to have access to Rapid7 or whatever it is right, and all of those things are in the cloud And it only communicates one way, allegedly right. But that's not how it works. It communicates two ways, right, and you start diving into it.

And even if you manage to put all that behind an air gap and it was actually secure, there's always the insider threat. There's always the guy that is making minimum wage, that has access to this room that he probably shouldn't have access to, and all they want him to do is plug in a USB into a random server for $10 million, like now. We're talking Well, or I really appreciate you coming on. I think that we are just about out of time here and I'm trying to be very cognizant of your time. So before I let you go, how about you tell my audience where they could find you if they wanted to reach out and where they could find permit?

IO.

Yeah so, for starters, finding permit IO is as easy as typing permit IO into your address bar And when you get there, on the top right there's a Slack icon. So if you go there, that brings you into our large open source and SaaS community and you can DM me there directly. My name is Orwais O-R-W-E-I-S And with those characters you'll also find me on LinkedIn and Twitter and GitHub, And I encourage you to reach out. I always love talking to fellow engineers and security practitioners. Come talk to me about what you're building, about your security challenges, about your startup. I always enjoy that And I don't think I've ever not enjoyed or not welcomed someone reaching out. So please do that. And, yeah, I'd love to talk to all you folks. Awesome.

Well, thanks for coming out, or? I really enjoyed our conversation. I wish it could have gone longer, but you know, all good things must come to an end, or something like that, right? Well, thanks everyone. I hope you enjoyed this episode.