Listen on
Data breaches often stem not just from weak authentication but from an outdated network security model. Even with robust single sign-on (SSO) in place, misconfigured cloud access or leaked session tokens can expose critical data assets. Traditional Virtual Private Networks (VPNs), designed for perimeter security, contribute to this risk by granting broad network access once a user is authenticated, making lateral movement possible and access control complex.
This episode features Jamil Bou Kheir, Founder & CEO at Firezone, who offers a clear perspective on moving beyond legacy VPNs. Jamil shares how Zero Trust Network Access (ZTNA) fundamentally shifts the security paradigm from network perimeters to individual resources. The discussion covers the inherent vulnerabilities of traditional VPNs, the principles behind ZTNA, and how Firezone implements a granular, identity-aware approach to secure access for remote workforces and third parties—from internal applications to sensitive cloud data platforms like Snowflake.
Data leaders and executives will find concrete examples of how ZTNA addresses the ‘ACL hell’ of complex access rules, strengthens security-in-depth for cloud applications through IP allow-listing, and makes internal resources invisible to unauthorized users. Jamil explains how these measures prevent data exposure, reduce audit complexity, and help organizations meet compliance requirements in a distributed work environment.
Key Takeaways
Traditional VPNs create broad network exposure; Zero Trust isolates access to specific resources.
A VPN effectively places a remote user inside the corporate network, giving them potential access to anything on that network, whether they need it or not. Zero Trust Network Access (ZTNA) changes this by creating encrypted tunnels directly to the specific applications or services a user requires, significantly limiting lateral movement and making resources invisible to those without explicit permission.
SSO is not enough; IP allow-listing adds critical defense for cloud data platforms.
Even with strong SSO, compromised session tokens or credentials can lead to breaches in cloud services like Snowflake. ZTNA platforms enable organizations to route all traffic to specific cloud applications through a static, whitelisted public IP. This creates an essential second layer of defense, ensuring that only trusted sources can connect, even if other authentication methods are temporarily bypassed.
Granular access control does not require ‘ACL hell’; modern ZTNA simplifies policy management.
Historically, achieving fine-grained access meant managing thousands of complex Access Control Lists (ACLs)—a cumbersome and error-prone process. ZTNA solutions like Firezone simplify this by using DNS-based resources and role-based policies, allowing administrators to define access for individual applications or databases without exposing their underlying network details or creating unmanageable rule sets.
Micro-segmentation makes data assets invisible to unauthorized users, securing them by design.
Zero Trust inherently supports micro-segmentation by moving the security perimeter to the individual resource. This means that data assets, whether an internal database or a web application, remain undiscoverable and inaccessible to anyone without authenticated and authorized access. This ‘dark network’ approach drastically reduces the attack surface compared to traditional perimeter-based models.
Related: CorrDyn provides expert guidance in data reliability and data engineering. We also offer data assessment services and specialize in helping biotech manufacturers unlock data value through secure and effective data strategies. Jamil returns in Episode 20: Supply Chain Security to discuss how AI is changing the attack economics.
Full Transcript
Jason: Welcome to Data BS, a show dedicated to tackling the big questions impacting the worlds of data and ML AI without any of the BS. My name is James Winegar. Each week I sit down with guests from across the data ecosystem to unpack how they’re shaping their businesses, or the businesses of others, through the real-world application of data engineering, ML AI, infrastructure, analytics, and more. No fluff, unfiltered, but slightly edited to remove noise. This is Data BS, let’s get into it.
James Winegar: All right, Jamil. Tell me who you are, where you work, and what you do.
Jamil Bou Kheir: I’m Jamil Bou Kheir. I work at Firezone. Spend a lot of my time on GitHub trying to build a security product. We’re building Firezone, it helps companies secure their data and networks.
James Winegar: What exactly is Firezone, if you had to define it?
Jamil Bou Kheir: Firezone is a zero-trust access product. It’s similar to a VPN, but it’s a little bit different, which we’ll get into later. And yeah, zero trust. It’s a thing.
James Winegar: It’s a thing, yeah.
Jamil Bou Kheir: It’s a thing.
James Winegar: So zero-trust access control. It’s pretty complicated as compared to a traditional VPN. So let’s start off with, what’s a traditional VPN? Describe that.
Jamil Bou Kheir: What it does is it wraps your data, basically encapsulates all of your network traffic into another network. What that does is it allows you to essentially appear or pretend you’re within that network. Companies have used this for some time, for example, if they’ve got an office, or if they’ve got a branch office, a physical office, they’ve got employees there, when the employee is remote or is working from home, they’ll typically VPN into that office. And what that does is it makes it appear that the employee is physically in the office.
James Winegar: We saw a big boost in business for VPN providers and things like that when COVID started, or what was going on with that?
Jamil Bou Kheir: Oh yeah. That was interesting. We all had to start working remotely, pretty much, all around the world. A lot of companies had what’s known as a perimeter-based access model that’s tied to the physical location of their office. Employees come to the office, and they have servers, or maybe even the office has a static IP, for example, they’ve configured all of their cloud apps to grant access to just that IP. Suddenly, people have to work from home and they’re struggling to cope with that change. I was at Cisco at the time, and I was already working remotely, Cisco had a hybrid workforce, or still has a hybrid workforce, and I remember everyone had to start working from home, so we had to start VPNing, is that a word, authenticating to the VPN concentrators. Obviously we’re using Cisco’s gear, we’re using Cisco AnyConnect, and I just remember them struggling to keep up with the demand, which was a little surprising to me. Cisco traditionally was a perimeter-based model, and the whole industry was, so you had to VPN into the intranet to get anything done, to check your email, to use the GitHub instance, and so forth. That was a little shocking to me. They got it fixed after two or three days. I’m sure there was a lot of fires that folks were putting out. That was just one example of the company I was working at, Cisco. But there’s many others.
James Winegar: Let’s talk a little about Firezone and what Firezone actually is as a zero-trust access management tool, and then how it’s differentiated across other VPN solutions or zero-trust platforms.
Jamil Bou Kheir: We talked a little bit about VPNs and what they do, how they work, and the problem they solve in regards to physical or perimeter-based security. The issue with that model is anyone in the network, if I’m in the office I could just plug in a laptop, if there’s no other further protections, and I have lateral access across the whole network. If I VPN into the office, I have that same access, because I’m now on the network. There’s been a big push towards what’s known as a zero-trust access model, and there’s a NIST standard on this and I’d recommend folks check that out if they’re interested in reading more about it. Essentially the whole idea behind that is instead of opening one tunnel into a network and having the same access as if you were physically on the network itself, you instead have these little encrypted tunnels, whether it’s TLS or WireGuard, to the services and the applications directly that you want to access. The access control is a lot more granular, so there’s no lateral movement. For example, if you have access to a web application within the intranet, it doesn’t necessarily imply that you can access the database directly behind it, or another web application, even if it’s on the same host. Firezone, we actually moved from, it was more of a VPN, I would say, the early MVP, and we experimented with that, we built on that, we collected a lot of feedback. As we started building though, we realized the industry is definitely moving in this zero-trust access direction, and any large organization looking to adopt a remote access strategy, they’re going to be moving in that zero-trust access direction as well. We re-architected Firezone about a year ago, and turned it into this zero-trust access product. What does that mean? Firezone is now a cloud-delivered product, where the control plane is running in the cloud, and the data plane you host and manage yourself, and you install our client applications onto your workforce’s machines, and they get access to each individual service that you configure for them. It’s similar to a traditional VPN in terms of how it works, the underlying encryption and the tunnels and things like that, but it’s different from a VPN in that the end user is only able to access the individual applications and services that you configure for them.
James Winegar: One way to think about it is it’s a VPN plus. You take a VPN, add some role-based access control or ACLs, access control list, to that VPN, so that it manages different tunnels for different end locations. Do you have a separate tunnel for each resource that you connect to, or is it an aggregated tunnel and then there’s some handoff that manages that?
Jamil Bou Kheir: The way Firezone works, you run a gateway. It’s what we call the other side of the VPN connection that terminates the tunnel on the other side. One side of the tunnel’s the employee’s laptop, the other side would be the gateway. You take the gateway, you deploy it on a VM, you can put it in a Docker image, you can put it in Kubernetes, just wherever you need access. They’re little Linux binaries, we build them in Rust. The gateway’s built in Rust. It’s statically linked, so there’s no dependencies, and it just needs an environment variable to run. In other words, it’s designed to be very portable and lightweight, you can put them anywhere. A common way that our customers are deploying it is into the same network, you just drop them into the same network as the resources that you want to protect. A resource could be the network itself, it could be an IP address, it could be a web application that you define by its DNS address. What’ll happen is when the end user tries to access that service, they open the browser, for example, and they put in gitlab.company.com, the Firezone client will see that request, and in real time it will punch a hole in the firewall, we call that NAT traversal, into wherever that gateway’s deployed, so you don’t need to reconfigure your firewall to deploy the gateways, and it’ll set up a secure tunnel to that gateway so that the employee or end user can access the resource behind it. That one tunnel will be used to multiplex all access to that resource and any other resources you have in that site. What’s a site? A site is just a shared connectivity context. It could be a VPC, it could be a LAN, but the idea is that all of the gateways you put into a site have access or can talk to all of the resources in that site. That’s what we use to power our high availability features for the gateway as well. All of the gateways in a site, they’ll fail over for each other, they’ll load balance for each other in a round-robin fashion. That’s a little bit more detail about how Firezone works.
James Winegar: You have high availability because there’s multiple gateways that you could deploy within a given network or area or site as we’re calling it. These gateways handle all of the distribution of the traffic and things like that. Also because you manage and deploy it, if it’s on-prem you have whatever fixed resources like we’re talking about with the Cisco situation, or if you’re in a cloud environment you can dynamically scale them up with auto-scaling groups or something like that in AWS or Google or Azure. So really portable to any environment. And customers could manage multiple sites as well. If you’ve got a co-location or you got your own data center or you have your AWS account, etc. Based off of the type of employee and their roles or group memberships and things like that, it’ll manage their access control across different sets of resources. So you’ve moved away from perimeter security and you’re really securing the individual resource object at that point.
Jamil Bou Kheir: That’s right. You’re getting into Firezone’s access model, a little bit about how it’s different. The existential issue with zero trust is by opening the door to this granular access model, it creates a combinatorial explosion in the number of rules you need to manage. Because now you’ve got this web of, this employee can access this thing but not that thing. One of our customers put it to us as ACL hell. It’s just hundreds or thousands of rules and they each have different Boolean modifiers and this complex syntax. We knew when we were re-architecting Firezone into a zero trust access product, that was something that was going to be really important to solve.
James Winegar: For us, we have a few different use cases. We have some GPU servers in a co-location, that’s our on-prem network effectively that we allow access to internal resources. Because we’re a services company, we have a bunch of different customers that we need to connect to. They don’t want us connecting from one of my analyst’s home computer and network. They want us to make sure we have good security policies in place. We have an egress or proxy site as well, which is forcing all of our traffic to be encrypted and things like that over a NAT IP in Google Cloud, which allows us to basically say, hey, we’re coming from this IP address, and so we can secure the access to our customers’ environments if they whitelist our IP. On our side, because Firezone allows for two-factor authentication or is connected to the identity provider, which we have two-factor authentication on, we have good security controls to ensure that if you are presenting as this IP address then you are authenticated appropriately and you have role-based access control or group membership in Google Workspace to say, okay, Bob has access to connect to customer A’s environment, or anybody who’s connecting to Snowflake has to go over this, everything to these data warehouse systems we force the traffic over that for everybody regardless. You have a pretty hierarchical structure on your side and then the structure on the customer’s identity provider side as well for managing access. We have our sites as the top level, which set of network resources am I going to deploy these high-available gateways into to manage access, then that site is going to have a set of resources attached to it, and then we will have policies that manage access into individual resources. Those resources can be as wide as we want it to be. In your traditional VPN example it would be like 10.0.0.0 slash 8 or whatever. Hey, this is the whole network. Or pick your RFC 1918 addresses.
Jamil Bou Kheir: Just to be clear, we try not to encourage that. If you’re going to adopt a zero-trust product, you want to be moving in the direction of more and more granular access controls.
James Winegar: But Firezone can enable that and so you could say, as some example, you’re in an admin group and somebody’s lazy and they do that. Don’t do that. But it’s actually a really common stepping stone. In large organizations they go, hey, we need to replace Palo Alto GlobalProtect. This is a common thing that we’ve seen. And we want to just mimic exactly what we have with that with Firezone, and then we’ll take baby steps towards incremental…
Jamil Bou Kheir: Yeah.
James Winegar: You have these policies that you then attach to the individual resource, which could be, hey, you’re a member of this group. And now ta-da, you have access to those resources. One thing that’s worth talking about is the set of use cases that Firezone enables. We’ve danced around ’em but let’s be more prescriptive about what use cases exist for Firezone.
Jamil Bou Kheir: Sure. We’ve already talked about the traditional VPN use case. The way that you would set that up in Firezone is you’d create what we call a CIDR resource, or a cider resource. You give it the actual cider address that you want to manage access for, and that’s basically it. Make sure you have gateways deployed in the network and that’s it. That use case, from what we’ve seen, is most applicable to companies and organizations looking for a stepping stone towards zero trust. That’s the cider resource access. Another one is what James mentioned earlier, which we see becoming more and more popular, which is third-party app or third-party cloud app access lockdown. Access security. It could be Snowflake, it could be HubSpot, could be GitHub, could be Slack. Essentially any cloud app that supports IP-based whitelisting, you can use Firezone to funnel or tunnel your team’s traffic through a particular site where you have maybe two or three or four or five gateways running, egress that through a static public IP, and then from the cloud application standpoint all of your team’s traffic is coming from that single IP. It’s a way to create a static IP, mimic this, okay, we’re all in an office, the office has a static IP, we’re going to a cloud service. It’s a way to mimic that but with remote employees. There’s some high-profile breaches recently, and I think those were due to misconfigured Snowflake instances. Even if you have your authentication locked down, let’s say you’ve set up SSO to Snowflake, great, your workforce needs to authenticate with your SSO provider, with your identity provider to get into Snowflake. What happens when that process is compromised somehow or a session token gets stolen? That’s where Firezone can come in to add another layer of security with this IP allowlisting use case.
James Winegar: Security in depth.
Jamil Bou Kheir: Onion model of security, whatever we want to call it.
James Winegar: Many layers. More protection you have, the better it is. All right, was that two use cases or…?
Jamil Bou Kheir: I would say that’s two. Then you can use it for the way Firezone routes traffic. Maybe we should talk about that a little bit. There’s two main ways we can tell what you’re trying to access. One is by IP and one is by DNS name. This implements the use cases I mentioned before. There’s another one, we talked about accessing a network, a cider range, accessing a publicly hosted or third-party cloud service. The other one is just accessing a private web app or database in your VPC or in an on-prem network. To do that, we encourage users to use the DNS-based resource. How does that work? You give it the DNS name, you define a resource in Firezone, and its address is the DNS name of the thing you’re trying to access. When the Firezone client on an end user’s device makes a query for that app or service, Firezone will intercept that query, and it’ll generate a dummy IP in a private range that we use and then it’ll return that to the application. This happens within a split second, and the application will then use that IP to start trying to communicate with the service. At that point we set up a connection and it behaves like an IP-based system. But the cool thing about DNS resources is that it provides even more granularity. Because we generate this dummy IP that’s not the actual IP, what that means is the clients never actually see the real IP. Another layer of security, there’s no way to do DNS enumeration now for your DNS resources. Also because that IP is generated on the fly, you can manage access to one service, let’s say a web app, but not another service, or another web app, even if it’s using the same protocol and port running on the same IP address or same host. It’s a way to have even more granular control.
James Winegar: That’s my point. We got three use cases, traditional VPN, basically. You can cut it up a little bit better than that, but traditional VPN idea, proxying traffic through a public IP, and then being more restrictive than we were with our traditional VPN type of use case. Actually moving towards the zero trust model, additional security controls that are being enabled by Firezone when you’re not just cutting up by IPs and things like that. Don’t give people access to the databases except for the people who need access to the databases. There’s no reason for your end users to connect to underlying databases, they only need the web server and things like that. You don’t want to publicly host this web server and just do security groups in AWS, because that could still theoretically expose to the world. What happens if somebody messes up a security group? Letting Firezone say, hey, you don’t have anything open at all to the world, they have to authenticate through their identity provider, okay now you can connect to these resources and they’re hosted in our VPC or in our on-prem, whatever. So we got rid of that perimeter almost.
Jamil Bou Kheir: In a sense. We’re taking the perimeter, we’re moving it as close as we can to the actual thing we want to protect. That means there’s a lot more of them. Essentially your resources are just invisible to the users that don’t have access to them. Physically the packets will not flow, there’s no chance, keep your firewall ports closed. End of story. This is a technique, you could say, called microsegmentation. Segmenting the network up into smaller and smaller pieces. It’s one way to do zero trust access.
James Winegar: Jamil, we’ve hinted around security of databases and things like that, Snowflake instance, and how do we secure access to our data as this is a data podcast, gotta bring it back into that instead of just the networking. How does Firezone or zero-trust network access tooling help us protect our data assets? What is the fundamental idea that it’s helping solve for us?
Jamil Bou Kheir: Back in the old days, all the core applications and services that a company needed typically ran on-prem, your email would be on-prem, etc. Obviously things are moving to the cloud. How do you manage access? The way that everyone’s already implemented and using today is SSO. You’ve got SSO set up to that application or service and only the users who have access can reach it. As I touched on before, what if that is not set up properly or a session token gets leaked, and now you got an issue. This is a downside that you wouldn’t have if that application was running on-prem. It’s not just open for the public in the whole world to access and hammer. What you can do, if that application supports IP allowlisting, which more and more are, is to configure your traffic in some way to egress through a static IP or multiple IPs in order to reach that application. I believe that would’ve prevented the recent Snowflake-based breaches. Why aren’t more companies doing that and using that? I think it’s due to complexity. The product that you’re using to manage access or secure access is too complicated or it impacts business too much or creates too much inconvenience. If you’re stopping business or preventing people from doing their work, then nine times out of ten it ends up just getting turned off, or holes get punched through. Oh, I’ll just open this or I’ll disable this rule just for an hour or two so I can access it from my personal laptop or from my hotspot, my Wi-Fi is not working. Whatever it is. Then you forget to enable it and you’re back to where you started.
James Winegar: I think Snowflake’s actually a really good example here, because Snowflake has protections that you could use for basically all the stuff you talked about. For example, you can disable a rule for an hour and then it’ll automatically turn itself back on. But what’s likely going to happen? Somebody’s doing that type of change, they’re probably going to go into the network access list and just remove the rule from there and be like, oh yeah, I’ll add it back later. Or add their hotspot IP, which hotspot IP is going to change all the time. You return the IP and then some other person at Starbucks next to you is going to get that IP. It’s dynamically allocated to whoever. I was thinking more from a product complexity standpoint going back to ACL hell. Looking at a set of ACLs for a Cisco ASA firewall, how can you quickly determine if someone has access to the company GitLab instance? No, you can’t. You can’t audit that or evaluate that easily because everything’s in the same construct. Then there’s hierarchy to the rules and so the security model has evolved, but it’s based off a different security model that it was designed for, which was perimeter security. And it’s these giant text files that get pushed down to the devices and who knows how they’re managed, if it’s even in version control. One would hope that they’re pushing it with Ansible or something and they have it in Git, but we both know better. One of the reasons why we asked you to be on, Jamil, is because security products as part of protecting data is a big part of the discussion that needs to be around anything involving data. If you don’t have secure access to data, if your data’s exposed to the world, your risk of being in the news or your cybersecurity insurance or your GDPR compliance or your CCPA compliance or your PCI compliance or all these other things where really the crux of it all is protect the data for the most part, and then protecting the network is an aspect of protecting the data. From that viewpoint, let’s talk about Firezone as a business, you’re YC-backed, it’s been around for how many years, where are you planning to go?
Jamil Bou Kheir: I think we did mention, you asked about the first commit, building into 2021, we had an early what I call the MVP, got accepted into YC 2021, started in the winter 22 batch. A little over a couple of years ago now and added on to that MVP. Probably a little too long after that, but paused on that and started building our zero trust product, or what we’re calling Firezone 1.0, our paid product, commercial product, in April of last year. We went GA and released 1.0 in April of this year and it’s just been growing ever since. We had a long wait list, we were taking our customers and beta testing with them for a few months and then when we opened Firezone up to the general public, we had a long wait list of people wanting to try it and use it. We had some load to scale up to meet some demand, but things have been pretty much smooth sailing since then. Since you mentioned data and compliance, there’s a term I used to use when I was working at Cisco, that security doesn’t sell, but compliance sells. Compliance requires security. I think that’s still true today. I do think security as a requirement is only going to grow and grow. We’re not moving into a world where there’s fewer compliance requirements, we’re moving into a world where there’s more and more complicated ones and probably more standardization, but it’s going to become more important to require certain compliance requirements of your vendors and employees and whatnot. Firezone’s very much building in that space. It’s a product that we are definitely gearing for businesses and organizations to use more and more. Right now our average customer size is probably in the hundreds, so you could say SMBs. We’re a small team, we are a startup. I’m not going to pretend we’re this big, decade-old company, but we’re growing into larger and larger organizations month by month. The way we’re doing that is by more product maturity, operational maturity, more product features, and scaling up from there.
James Winegar: All right, awesome. So what are some of those features that you recently worked on?
Jamil Bou Kheir: Two notable ones. One is the REST API. We put that together and we have an OpenAPI spec for it, so you can download the spec, you can generate clients in Ruby, Python, JavaScript to interact with the Firezone API. That’s all about automation. If you’re a larger organization, you’re probably going to have a lot more resources and policies and gateways than a smaller company, so you’re going to need ways to automate, maybe version control your configuration, automate setting that up in Firezone. The other one is what we call the Internet Resource. This is full-route tunneling. Before this, Firezone was strictly split-route. It would only route the traffic that you’ve defined resources for from the client to those resources, and all other traffic, let’s say that employee checking their personal email or going to google.com to search something, would just go directly out to the internet, not protected by Firezone. That works great for the majority of the time and is usually what you want because you don’t want all of your workforce’s data going through your gateway running in AWS and now you have a $2,000 AWS bill you gotta pay. But in some cases maybe you have a gateway running in a cheaper network to operate and you want to provide the opportunity for certain employees to be able to protect that first hop. Let’s say they’re in a public café, Wi-Fi’s not encrypted, and you want to make sure that all of the communication leaving that laptop is at least encrypted with WireGuard. You can enable the Internet Resource for that employee and all of their network traffic will go to the gateway that you’ve defined for the site you’ve designated and egress out from there.
James Winegar: What’s next for Firezone? What are you thinking about from a business viewpoint, or is your ideal customer still this smaller business or is it more mid-market, like thousand-employee type? Where do you see Firezone playing?
Jamil Bou Kheir: Very quickly we are moving into that mid-market size. The goal for a cybersecurity product is to move into enterprise as quickly as possible. It’s a space where these aren’t new problems. We’re solving them in somewhat new ways. There’s other competing products out there, so there’s competition. When you put all of those together and then sprinkle the enterprise security requirement over all of that, it creates a very high bar. It’s not the type of company, and I’ve come to learn this and understand this much more clearly now after starting Firezone, where you just raise a little bit of money, put out some really bare-bones product that just solves the problem and then it’s off to the races. You’ve got to have a great product, it’s got to be very secure, and that creates a challenge. It’s been a fun one to try to solve. We look to be growing, we want to grow up into the 1,000, 2,000, 3,000 company range over the next few months and then scale up further from there.
James Winegar: Awesome. Where can people learn more about Jamil and Firezone?
Jamil Bou Kheir: You can find Firezone at our website. We’re at firezone.dev, D-E-V. You can also find us on GitHub. github.com/firezone is our main product repo. We welcome anyone to go and explore the code, open issues there if you’d like to see features or if you have a bug to report. You can find me personally on LinkedIn, just my first and last name, and I do read every DM. I don’t always get around to responding to them, so apologies if I’m not super responsive.
James Winegar: Awesome. Thanks for joining us, Jamil.
Jamil Bou Kheir: Thanks for having me. This was fun.
Jason: That’s it for this episode of Data BS. If you enjoyed this episode, make sure you subscribe wherever you listen to your podcasts and not miss the next one. This episode was sponsored by CorrDyn, a data consultancy that helps organizations unlock the power of their data. If you have a data challenge, we can help. Visit corrdyn.com, C-O-R-R-D-Y-N dot com, to learn more. See you next time.
