Charlotte, NC – March 24, 2026 – NetFoundry today announces the availability of its new secure AI enclave capabilities. This extends OpenZiti, the world’s most widely used zero trust open source platform, into enterprise AI environments. New capabilities include zero trust MCP and LLM gateways to address the “AI Connectivity Conundrum” – the conflict between giving AI agents broad access to enterprise data vs. securing the expanded attack surface that their deployment creates, and delivering them at the speed of their development. The release is now available at https://openziti.ai.

NetFoundry is also announcing a limited early access program for upcoming AI capabilities in NetFoundry’s commercial cloud offering. These capabilities will simplify the deployment and ongoing operations of internal AI platforms by eliminating the headaches of network and firewall management while also providing end-to-end visibility of AI system actions.

Registration for the early-access program is available at netfoundry.io/EarlyAccessAI.

To deliver value, business-impacting AI agents must connect across clouds, VPCs, data centers, and edge environments. But exposing AI agents, MCP servers, LLMs, and enterprise data to the network increases the attack surface and adds operational drag. Without strict containment, AI agents behave less like APIs and more like autonomous, social-engineered superusers. And exposing their AI tooling on the network provides a uniquely attractive target for attackers.

NetFoundry’s new AI capabilities replace that model entirely.

“Agentic AI breaks traditional network assumptions,” said Galeal Zino, CEO and Founder of NetFoundry. “Enterprises can’t scale AI using IP-based access controls and static API keys. But with our new Identity-first AI capabilities, enterprises can secure their AI solutions while rolling them out faster and operating them more effectively because agents and MCPs do not get any network access or any API keys.”

The key to this new approach for AI – every AI agent and resource receives its own cryptographic identity. Authorization happens at the service level—not the network level. Connections are ephemeral, continuously authenticated, and fully auditable. Every connection is logged with the identity and policy which enabled it.

Core components are OpenZiti zero trust LLM and MCP Gateways–lightweight software deployed alongside AI agents, MCP servers and in front of protected resources. All connections are initiated outbound to the network overlay, and all connectivity is verified against identity and policy. Therefore all components are invisible to the public internet and internal networks alike. Inbound firewall rules remain “deny-all”—with no exceptions.

For platform teams, this means publishing services and policies just once. For application teams, it means self-service AI agent connectivity without waiting weeks for firewall or VPN changes. The guardrails are already in place – the identities and policies which govern those identities – with the controls and visibility to change policies instead of firewalls and networking.

For more information, visit netfoundry.io/ai-deployment-and-protection or openziti.ai.

About NetFoundry

NetFoundry is the leader in helping businesses simplify and secure connectivity among their widely-distributed workloads, humans, machines and AI agents. Founded by the inventors and maintainers of the world’s most-used open source zero trust software, OpenZiti, NetFoundry’s Identity-First Connectivity™ enables zero trust connectivity with no open inbound ports, no VPNs, and no firewall changes.

The post NetFoundry Extends OpenZiti with Release of First Open Source Zero Trust Enclave for AI Workloads appeared first on NetFoundry.

Velocity vs security – why can we not have both?

After working in the DevOps space for almost a decade, there are a few common traits that you’ll find among most of us:

1. We don’t actually know what we do for a living
2. We love to automate EVERYTHING
3. We wire systems together and make things work
4. We don’t like administrating systems – we build systems to administrate other systems

Over the last decade we’ve seen an explosion in technology that allows us to automate and orchestrate on a level that’s never been seen before. We develop faster, deploy faster, we innovate. But in a world that has an ever-increasing need for security, we are also the troublemakers.

In order to wire systems together, we need access to EVERYTHING. Even more than that, we can grant incredible super powers to the automation systems that we build. We create systems that are absolute goldmines for hackers to exploit. Take any of the big technology names in the DevOps space, and imagine the devastation that an exploit can bring if one of these systems becomes compromised. Salt, Kubernetes, Jenkins, Ansible, your Data Warehouse. Something they all have in common – they all have incredible access grants within systems, and they all have access to a disturbing amount of data if it falls into the wrong hands.

Since removing access to these systems is not feasible, how do we continue to build tools that allow us to move at a breakneck speed without compromising our security and creating a massive attack vector? 

Enter Ziti! 

OpenZiti (I use Ziti and OpenZiti synonymously throughout this blog) is an open-source, software-only programmable network overlay based on zero-trust principles.

As a DevOps Engineer, I like tools that act like a Swiss Army Knife. Anything that solves a variety of problems and allows me to continue to move quickly makes it into my repertoire and becomes a tool that I come back to over and over again, regardless of where I’m working. OpenZiti provides a way for you to set up access controls quickly and efficiently while raising the standard for “least permissions” at the network level. Read more about Ziti here or Ziggy, our mascot for OpenZiti and his many different outfits here.

Lock Down Your Tools

To make my life easier, I use the NetFoundry platform to provide a cloud orchestrated, programmable operation of OpenZiti – spun up and down minutes based on our needs. NetFoundry is the creator of Ziti, maintains it and can provide a SaaS option for anyone.

If you’re reading this, I probably don’t need to explain the terrifying compromises that happened in the last year with Solarwinds or TravisCI, but just in case you didn’t, you should go read those articles now and then you’ll understand perfectly why this next topic is critical. A CI/CD system is a perfect example of a “system managing a system”. It typically has elevated access and is designed to deploy and execute code in all of the places you care about. Hackers know this, they target these systems and dream about deploying and executing their own code inside of your systems.Knowing that hackers are looking for endpoints just like these would often keep me up at night. We can’t afford to leave our critical systems exposed anymore, we need to make them dark. The methodology for securing any of your sensitive resources is the same whether it’s a data warehouse, a build server, or an API. 

• Shut down your traditional ingress ports
• Place an Edge Router (cloud orchestrated software) inside of the private network space
• Grant service access to only the endpoints that need it 

Seamless Switchover

When I think about “locking things down”,this is typically synonymous to all kinds of breakage and end-user disruption. When doing this sort of work in the past it’s very difficult to validate success short of waiting for users to complain. However, NetFoundry’s console paired with Ziti makes this incredibly easy.  I could see if the project was going to be successful *before* making the cutover. Ziti’s traffic intercept will work whether a service is dark or not. Enroll your end-users, watch the traffic come into the Console, and verify everything ahead of time. After running two migrations with this method, switchover day was a non-event both times because users had already been accessing the services with Ziti for weeks.

Developer, DevOps and NetOps Access

If you’re putting on your security hat, this phrase alone should make you cringe. As nice as it would be to keep access locked down once you’re in production, sometimes things go wrong, and you need to let your developers log into instances, databases, and message brokers to solve a problem. Most companies don’t like to admit it, but too many are still using shared credentials to interact with their application dependencies, so when it comes to assigning developers secure access, this creates a security nightmare. These types of resources generally live inside of a private VPC or DC, so opening them up to a developer often means exposing the entire VPC to that user. In a “least permissions” world, this is not ideal. What Ziti allows me to do is isolate that network access and separate access by application, team, or environmenti.e. account-based access-control.

Step Up Your Visibility 

Have you ever had to determine who accessed a resource based on network traffic? Just in case you haven’t, it’s terrible. Traditional network traffic monitoring is built around IPs and Ports, and from that information you can maybe extract the “who” and the “what”. As a result, in a previous role, I once spent 3 days hunting down the fact one of our employees had gone to work from a coffee shop! NetFoundry introduces a whole new generation of network visibility, where all traffic monitoring operates around trusted identities (endpoints) and services (user-defined slices of traffic). For every byte of traffic that passes over OpenZiti, we know who initiated the traffic, what service is being accessed, and what time the traffic was passed. No additional interpretation is required.

Zero trust journey

To make our journey to zero trust DevOps as seamless and non-event as possible, we decided to go through an incremental, evolutionary series of steps. We started with our data warehouses before securing our Jenkins CI/CD pipeline. Next, we moved to ‘dark bastions’ by applying OpenZiti to them and closing inbound port 22 – auditing access became so much easier and less cumbersome. To come, we will make all internal system communications dark by applying NetFoundry to our ETL jobs and database to CI/CD connections.

I don’t know what journey you will take with OpenZiti and NetFoundry; that’s your next decision.

More info

Most of us in the security, tech and networking worlds are cynics, and for good reason.  Meanwhile, the marketeers have flocked to use and abuse the Zero Trust terms.  So here are links to enable you to quickly filter through the noise and judge for yourself if you want to learn a bit more before diving into the SaaS or open source:

• Watch me use NetFoundry to do simple, Zero Trust data collection in 10 minutes (video)
• Watch me secure my CI/CD pipeline (another 10ish minute video)
• Watch (video) Platform9 use Ziti to secure programmable Kubernetes network overlays
• Download a whitepaper to get into the gritty details
• Schedule a briefing or demo with a product expert Dive in with the open source or the SaaS (free for up to 10 endpoints)

The post Breakneck speed without breaking our necks appeared first on NetFoundry.

The post Lessons from DEF CON 33: Why Zero Trust Overlays Must Be Built In, Not Bolted On appeared first on NetFoundry.

Enterprises in the OT and IIoT sectors are increasingly adopting identity-based, secure private zero trust networking. A foundational element in this journey is the implementation of least privilege access and microsegmentation to achieve granular access control. This requires that all communicating entities—whether users, devices, or applications—be assigned unique identities. However, a significant challenge arises when dealing with machines that are unable to support the installation of software clients or tunneling agents that enforce identity-based access.

As we have engaged closely with our customers, a common need has emerged: a solution to extend zero trust access to non-identity-aware machines. These are typically legacy or specialized OT devices that cannot host identity clients yet still require secure, policy-driven communication. Addressing this need is essential to achieving comprehensive zero trust coverage across heterogeneous environments.

What is it?

Before diving into implementation details, let’s first understand the concept. In industrial environments, edge or industrial compute devices typically serve as network gateways, connecting to machines such as PLCs, sensors, actuators, and other OT assets. These gateways generally run a standard operating system and possess sufficient compute resources to host NetFoundry edge software.

In this architecture, the gateway acts as the identity-bearing entity—running the NetFoundry tunneler/router—while the connected machines communicate with cloud services, applications, and other machines through the identity of the gateway. The core objective is to implement a mechanism that controls and restricts which specific machines behind the gateway can access designated resources, even though they themselves may not have individual identities or tunneling capabilities. This enables enforcement of zero trust principles such as least privilege and segmentation, even for non-identity-aware devices.

Scenario:

The following are the communication objectives we want to achieve:

• At factory site 1,  only specific machines in Subnet A ( a /24 subnet) connected to the upstream IEC device running the NetFoundry tunneler with identity A should connect to cloud
• At factory site 1, only specifc machines in Subnet B ( a /23 subnet) connected to the upstream IEC device running the NetFoundry tunneler with identity B should connect to the DC
• From factory site 2, only spefic machines in subnet G ( a /21 subnet) connected to the upstream IEC device running the NetFoundry tunneler with identity G should connect to machines in subnet C at factory site 1

As part of the NetFoundry “Service Config”, access is restricted to a spefic port(s) and IP(s) / host name(s) and specific identities are allowed to access based on the “Service Policy Config”.  

For example, machines connected to the IEC device that runs Identity A can be allowed to access a SCADA application in the cloud through appropriate service and policy configurations. However, this identity-based model alone does not prevent unauthorized machines within Subnet A from reaching the SCADA service.

Introducing “Allowed Source Address”

To address this requirement, NetFoundry introduces the Allowed Source Address feature within the service configuration. This enhancement enables administrators to enforce access control beyond the identity level, down to the level of specific source IP addresses of individual machines behind the tunneler or a router.

With this feature:

• The NetFoundry platform inspects the originating IP address of traffic from machines behind the IEC gateway.
• Access is granted only if the source IP matches the list defined in the service configuration.
• Machines not listed—even if they route traffic through an authorized IEC device—are denied access.

This capability allows organizations to maintain the IEC gateway model, while still enforcing machine-level access policies, ensuring that only explicitly permitted devices within a subnet can access critical applications or services.

How to use the “Allowed Source Address” feature:

Let’s replicate this scenario in a lab environment. The objective is to restrict access to an “Extended Zero Trust Service”—which hosts a simple “Hello World” application on AWS—to a specific IP address: 10.0.0.5.

Once the configuration is complete, the service should only be accessible from the IP address 10.0.0.5, regardless of whether other identities are permitted by the service policy configuration. Any requests originating from other IP addresses should be denied, even if the identity is authorized by policy.

The service config with allowed source address of 10.0.0.5:

Service Policy Config that allows access to three identities, one that of a router identity and two other identities.

10.0.0.5 is a VM in Azure deployed behind the identity – ” Customer hosted edge router in Azure London”. The service should only be reachable from that VM and not reachable from our identities “………..001” and “…………002” whose IPs are not added to the allowed source address list.

Trying to access the service from the identity “NetFoundry Cloud Identity 002” ( does not match the source IP of 10.0.0.5)

The identity has access to the service as per policy but can’t access since the IP is not added to the list:

Successfull access from 10.0.0.5:

The post Extending microsegmentation to non-identity-aware devices appeared first on NetFoundry.

The post What Is Zero Trust AI appeared first on NetFoundry.

At NetFoundry, we’re revolutionizing secure networking and connectivity using a Zero Trust Architecture (ZTA), fundamentally changing how we address security challenges. One key aspect of ZTA is the Identity Pillar, which is crucial for maintaining a secure environment. This article is your comprehensive guide to understanding the role of Identity within ZTA, its benefits, and how leveraging NetFoundry can accelerate the journey toward Zero Trust maturity.

Never Trust, Always Verify

At the core of ZTA is the principle, “Never trust, always verify.” Unlike traditional security models that rely on physical perimeters to block threats, Zero Trust assumes that threats can emerge from anywhere—even from within. ZTA requires rigorous cryptographic identity verification for every access request, regardless of origin. Solutions like NetFoundry’s Zero Trust Platform are pivotal in implementing this strategy.

Identity in Zero Trust ensures that every user, device, or system is thoroughly authenticated and authorized before accessing valuable resources. It goes beyond the traditional username and password, incorporating features like multi-factor authentication (MFA), single sign-on (SSO), and privileged access management (PAM). This pillar forms the foundation of Zero Trust, ensuring that access decisions are based on who’s asking, why they’re asking, and the risks involved—principles that we at NetFoundry adhere to

The Role of Identity in A Zero Trust Architecture

1. Authentication and Authorization: Identities are crucial in ensuring that every access request is authenticated and authorized against rigorous security mechanisms – i.e., strong cryptographic identity, not weak network identifiers – before being granted. NetFoundry’s advanced solutions help implement these stringent checks.
   
   
2. Least Privilege Access: Access rights are carefully managed, providing users only with the permissions necessary for their roles and tasks. This minimizes potential security risks by limiting access to sensitive resources.
   
   
3. Dynamic Access Control: Access rights are dynamically adjusted based on various factors, such as business rules, user location, device security status, or access time. This allows for real-time management of permissions, enhancing overall security.

The Strategic Importance of the Identity Pillar In A Zero Trust Architecture

Emphasizing robust identity verification significantly enhances security and offers several key business benefits:

1. Enhanced Security Posture: Rigorous verification of every access request before connectivity can be established drastically reduces the risk of unauthorized access and potential security breaches, fortifying your organization’s defenses.
   
   
2. Regulatory Compliance: Many regulations require strict access controls and identity verifications. By prioritizing identity, organizations can more effectively meet these requirements, avoid potential fines, and enhance trust with partners and customers.
   
   
3. Improved User Experience: Implementing features such as Single Sign-On (SSO) simplifies access for legitimate users, balancing ease of use with robust security. NetFoundry’s advanced solutions further streamline this process, enhancing user satisfaction and productivity.

Advantages of NetFoundry for Accelerating Identity Pillar Implementation

NetFoundry is a comprehensive solution for organizations aiming to strengthen their Zero Trust Identity. Here’s how it helps:

1. Authenticate Before Connect: NetFoundry ensures authentication occurs before any connection can be established to the network Policy Enforcement Point (PEP), fully embodying the Zero Trust principle of “never trust, always verify” while making external network attacks redundant.
   
   
2. mTLS & E2E Encryption: NetFoundry uses mutual Transport Layer Security (mTLS) for all connections, ensuring all components verify each other’s credentials. Combined with end-to-end encryption, this secures both identity validation and data confidentiality, with no snooping anyone in between. NetFoundry uses two of the fundamental building blocks of modern authentication systems: x509 certificates and JWTs.
   
   
3. External Identity Providers (IdP): NetFoundry can integrate with external Identity Providers (IdP) and JWT systems, allowing organizations to leverage existing identity systems, streamline user management, and deliver ‘zero touch’ deployments.
   
   
4. Least Privilege Access: NetFoundry’s micro-segmentation enforces strict access control, ensuring users and devices can only access what is necessary for their roles.
   
   
5. Posture Checks: NetFoundry includes posture checks, adding an extra layer of validation and policy enforcement to ensure devices meet the network’s security standards before gaining access.
   
   
6. MFA: NetFoundry embedded identity provides inherent multi-factor authentication, with the ability to add additional TOTP MFA, making identity verification thorough and robust.

Don’t miss the chance to explore more about NetFoundry, Zero Trust concepts, and its offerings in an insightful video.

Identity and the Zero Trust Maturity Model

The Zero Trust Maturity Model from CISA suggests that implementing Zero Trust, specifically the Identity pillar, can be daunting. Organizations can significantly benefit from integrating NetFoundry’s platform to ensure strict access control and minimize unnecessary privileges while achieving advanced and optimal maturity levels more rapidly. NetFoundry enhances network security by utilizing zero-trust principles to strengthen authentication and provide precise, context-sensitive authorization. This is crucial for effectively managing identity risks for personnel and entities

Table 1 below describes NetFoundry’s benefits for each of the functions described in CISA’s zero-trust maturity model for identities, including considerations for Authentication, Identity Stores, Risk and Access Assessments, Visibility and Analytics, Automation and Orchestration, and Governance.

The post Zero Trust and Identity: A Comprehensive Guide to Secure Access appeared first on NetFoundry.

Traditional perimeter-based security models, once considered infallible, are now riddled with vulnerabilities, exposed by sophisticated cyber threats and insider attacks. The surgical precision of these attacks has revealed a shocking truth – trust can be a network’s undoing. This calls for a paradigm shift towards a security model that assumes breach and verifies every access request, regardless of origin. This leads us to Zero Trust, a model predicated on the principle, “Never trust, always verify.”

This article delves into the foundational pillars of a Zero-Trust Architecture, a model designed to withstand and thrive in the unpredictable storm of data breaches, hacks, and insider threats.

What is Zero Trust Security and Why It Matters

Zero Trust security is a cybersecurity framework that operates on the principle that nothing inside or outside the organization’s network is to be trusted implicitly. It requires strict identity verification for every person and device trying to access resources on a private network, regardless of their location. This approach minimizes the attack surface, prevents unauthorized access, and thwarts lateral movement by implementing least-privilege access, micro-segmentation, and continuous monitoring of network activity. Zero Trust ensures that only authenticated and authorized users and devices can access applications and data, thereby enhancing the organization’s overall security posture

The Five Pillars of Zero Trust

A Zero Trust Architecture reframes the conventional security model by advocating for stringent verification and constant validation across all network interactions. This holistic approach is segmented into five critical zero trust pillars:

1. Identity Verification
2. Device Trust
3. Microsegmentation
4. Least Privilege Access
5. Data Protection and Encryption

The goals of a Zero Trust architecture are to strengthen data security, improve defense against cyber threats, ensure secure access control, and reduce the risk of insider attacks by verifying everything and trusting nothing within a network.

Let’s Dive Into Each of the 5 Zero Trust Pillars

• Identity Verification: This pillar represents the cornerstone of Zero Trust Identity, advocating for rigorous identity verification and continuous authentication. Understanding and implementing the Identity pillar involves navigating through initiatives like centralized identity management systems, phishing-resistant Multi-Factor Authentication (MFA), and dynamic user authorization mechanisms—each aimed at ensuring secure and appropriate access in a zero-trust environment. Wondering about more? Immerse yourself in our full-pledged Guide about the role of Identity in a zero-trust architecture.
  
  
• Device Trust: Before granting access, devices are assessed to ensure they meet the organization’s security standards. This can include checking for up-to-date security patches and not being jailbroken or rooted. In the context of Zero Trust, we are talking about somewhat intelligent devices connected to the internet. This includes simple home devices to sophisticated industrial equipment, sometimes referred to as the Industrial Internet of Things (IIoT). To implement this pillar, organizations must participate in CISA’s Continuous Diagnostics and Mitigation (CDM) program for reliable asset inventories and better monitoring. They must also ensure Endpoint Detection and Response (EDR) tools meet CISA’s technical requirements, are widely deployed, and enable proactive detection of cybersecurity incidents.
  
  
• Microsegmentation: To minimize lateral movement post-breach, Zero Trust advocates network segmentation and microsegmentation. The network is divided into secure zones to control user access and reduce the attack surface. This pillar ensures secure communication and reduces reliance on perimeter-based defenses by isolating systems and applications from each other.
  
  
• Least Privilege Access: Users are granted the minimum levels of access—or permissions—needed to perform their job functions, limiting the potential damage from a breach. This pillar includes embedding security into applications from the ground up, leveraging strategies like Kubernetes Zero Trust in containerized environments or OpenZiti zero trust networking embedded in applications. These robust security measures offer foolproof protection against potential security breaches and help maintain the integrity of your applications.
  
  
• Data Protection and Encryption: The final pillar emphasizes encrypting and safeguarding data, ensuring only authorized access to data at rest and in transit. In the context of Zero Trust, end-to-end encryption (E2EE) is a critical security measure that ensures data transmitted across a network is encrypted from the source (sender) to the destination (receiver), with no ability for intermediaries to decrypt it. This practice aligns with Zero Trust principles by securing data integrity and confidentiality, ensuring that even if a network is compromised, the data remains protected from unauthorized access. E2EE helps enforce data privacy and security policies by limiting data access to only the communicating users, thus supporting the Zero Trust mandate of never trusting and always verifying every access request.
  
  

Zero Trust Benefits and Impact

Implementing the five pillars of a Zero Trust architecture brings several key benefits:

• Enhanced Security: By verifying every access request, regardless of where it originates, Zero Trust minimizes the attack surface and reduces the risk of both external attacks and insider threats.
  
  
• Improved Compliance: Zero Trust helps organizations meet stringent regulatory requirements for data protection by implementing strict access controls and data security measures.
  
  
• Reduced Data Breach Impact: By segmenting the network and applying least-privilege access controls, Zero Trust limits how much damage a potential breach can cause, as attackers can’t easily move laterally across the network.
  
  
• Greater Visibility and Control: Continuous monitoring and logging of all network and user activities enhance visibility into network traffic and user behavior, enabling more effective detection and response to anomalies.
  
  
• Scalability and Flexibility: Zero Trust architectures are adaptable to varying network environments, including cloud and hybrid systems, making them suitable for modern, dynamic IT ecosystems.
  
  
• Increased Trust in IT Environment: With robust security measures in place, stakeholders can have greater confidence in the IT environment’s ability to protect sensitive data and systems.
  

Overall, Zero Trust provides a comprehensive framework for protecting an organization’s data and resources in an increasingly complex and threat-prone digital landscape.

Considerations and Zero Trust Best Practice

Embarking on a Zero Trust journey requires thoughtful planning and execution. Organizations should conduct thorough risk assessments and adopt a phased implementation approach. Embracing change management, educating stakeholders, and choosing the right technology partners are paramount to success.

Implementing a Zero Trust solution effectively involves several best practices to ensure the architecture aligns with the organization’s specific security needs and operational requirements. Here are some of the key best practices:

• Define the Protect Surface: Identify critical data, assets, applications, and services that need protection. Understanding what you need to protect is the first step in applying Zero Trust principles effectively.
  
  
• Map the Transaction Flows: Understand how traffic moves within your environment. This helps you design a network that aligns with the principle of least privilege and creates effective microsegments.
  
  
• Architect from the Inside Out: Start with securing the most valuable or sensitive resources and expand outward. This approach prioritizes protection where it is most needed.
  
  
• Establish Strict Access Controls and Authentication: Implement multi-factor authentication (MFA) and least privilege access controls. Every access request should be authenticated, authorized, and encrypted.
  
  
• Utilize Microsegmentation: Divide the network into smaller, manageable segments to control access and movement within the network, thus reducing the attack surface.
  
  
• Employ Endpoint Security Measures: Ensure all devices are secure before granting access. This includes maintaining device health checks, implementing security patches, and managing device configurations.
  
  
• Enhance Monitoring and Analytics: Deploy security technologies that provide visibility into all network and data access activities. Use advanced analytics to detect anomalies and potential threats.
  
  
• Automate Security Processes: Use security Orchestration, Automation, and Response (SOAR) tools to increase efficiency in detecting, responding to, and mitigating incidents.
  
  
• Conduct Regular Audits and Simulations: Regularly test and validate the effectiveness of your Zero Trust architecture through audits and penetration testing to identify and address vulnerabilities.
  
  
• Educate and Train Employees: Continuously educate employees about cybersecurity risks and Zero Trust policies to ensure they understand how to operate securely within a Zero Trust environment.
  
  

Zero Trust Framework Example: OpenZiti

OpenZiti is an open-source framework for building secure, Zero Trust, software-defined network access solutions across the internet.

Incorporating OpenZiti can significantly streamline the process of adopting Zero Trust security and networking in an organization. OpenZiti facilitates the uncomplicated embedding of Zero Trust Networking and SDN/SDWAN principles into anything from devices to clouds. It offers authenticate-before-connect capabilities, end-to-end encryption, and micro-segmentation, among others, without the need for traditional VPNs or inbound firewall ports. With OpenZiti, organizations can leapfrog to a ubiquitous high-level Zero Trust Architecture, underscoring security, flexibility, and simplicity.

NetFoundry and OpenZiti

NetFoundry is a software company focused on providing Zero Trust Internet-overlay networking as a service (NaaS). The company is the original creator of OpenZiti and is still the most significant contributor to the OpenZiti project. Netfoundry uses this open-source software framework to provide secure, programmable networking solutions and services, implementing principles such as Zero Trust and secure access. It is designed to facilitate the creation of applications that securely transmit data over the internet, without the need for traditional VPNs or custom hardware.

NetFoundry leverages the OpenZiti framework to build its commercial products, providing its customers with enhanced security and performance features. By contributing to OpenZiti, NetFoundry supports the development of a robust open-source tool that aligns with their business interests in secure network connectivity, promoting an ecosystem where security and networking are accessible and scalable. This relationship helps NetFoundry maintain a leading edge in technology while fostering a community around secure, open-source networking solutions.

Applying the Five Pillars of Zero Trust to Key Industries

The Five Pillars of Zero Trust—Identity Verification, Device Trust, Microsegmentation, Least Privilege Access, and Data Protection and Encryption—are essential for fortifying security across various sectors. Here’s how these pillars apply to NetFoundry’s three primary industries: Software Providers, IIoT and B2B Product Providers, and Service Providers.

1. Software Providers
   
   Identity Verification: Software providers must ensure that only authenticated users can access development environments and production systems. By implementing strong identity verification processes, such as multi-factor authentication (MFA), they can protect their intellectual property and customer data from unauthorized access.
   
   Device Trust: Software providers often use various devices to access development environments and cloud services. Ensuring that these devices meet security standards before granting access helps prevent breaches caused by compromised devices. Tools like Endpoint Detection and Response (EDR) can help maintain device integrity.
   
   Microsegmentation: Microsegmentation allows software providers to isolate different environments (development, testing, production) from each other. This prevents lateral movement of threats within the network and limits the potential damage of a breach to a single environment.
   
   Least Privilege Access: By applying least privilege access, software providers ensure that users have only the necessary permissions to perform their tasks. This minimizes the risk of insider threats and unauthorized access to sensitive information.
   
   Data Protection and Encryption: Encrypting data both at rest and in transit ensures that even if data is intercepted, it remains unreadable to unauthorized parties. This is particularly important for protecting sensitive customer information and proprietary code.
   
   Example: A software company integrates NetFoundry to secure its cloud-based ERP and CRM platforms when deployed on-premise at its customers’ sites. By implementing microsegmentation, each customer’s data is isolated, ensuring that a breach in one account doesn’t affect others. Policy-based access controls grant customer support agents limited access based on their role, and enhanced identity governance ensures robust user authentication.
   
   
2. IIoT and B2B Product Providers
   
   Identity Verification: IIoT and B2B product providers manage a wide array of connected devices. Enhanced identity governance ensures that each device has a unique, verifiable identity, preventing unauthorized devices from accessing the network.
   
   Device Trust: Ensuring device trust is crucial for IIoT environments where devices often operate in remote or harsh conditions. Regular health checks and security patches help maintain device integrity and secure communication channels.
   
   Microsegmentation: Microsegmentation allows IIoT providers to create secure zones for different operational functions. Separating manufacturing processes from administrative functions, for example, helps protect sensitive data and reduces the attack surface.
   
   Least Privilege Access: Implementing least privilege access ensures that operators and technicians can access only the systems they need to perform their duties. This limits the potential impact of any compromised credentials.
   
   Data Protection and Encryption: Encrypting data transmitted between IIoT devices and central systems ensures that sensitive operational data remains secure. This is essential for maintaining the integrity and confidentiality of industrial processes.
   
   Example: An industrial equipment manufacturer uses NetFoundry to secure remote access to its machinery. Enhanced identity governance ensures that only authorized service technicians can access the control systems, and microsegmentation isolates each machine’s network segment. Software-defined perimeters make the control systems invisible to external threats, while the hardware root of trust ensures device integrity.
   
   
3. Service Providers
   
   Identity Verification: Service providers handle sensitive client data and systems, making strong identity verification essential. Multi-factor authentication (MFA) ensures that only authorized personnel can access client environments.
   
   Device Trust: Service providers often use multiple devices to manage client systems. Ensuring that these devices meet security standards before granting access helps prevent breaches caused by compromised devices.
   
   Microsegmentation: Microsegmentation allows service providers to isolate different client networks from each other. This prevents a breach in one client’s environment from affecting others, ensuring each client’s data remains secure.
   
   Least Privilege Access: By applying least privilege access, service providers ensure that their technicians have only the necessary permissions to perform their tasks. This reduces the risk of insider threats and unauthorized access to client data.
   
   Data Protection and Encryption: Encrypting data at rest and in transit ensures that sensitive client information is protected from interception and unauthorized access. This is critical for maintaining client trust and meeting regulatory requirements.
   
   Example: An MSSP leverages NetFoundry to provide its clients secure, remote management services. Each client’s network is segmented using microsegmentation, and policy-based access controls ensure that support staff can only access the systems they are responsible for. Enhanced identity governance verifies the identities of support staff, and software-defined perimeters protect client systems from external threats.
   

Implement the Five Pillars of Zero Trust

In conclusion, the seismic shifts in the cybersecurity landscape underscore the urgent need for a robust and adaptive security model. Zero Trust architecture, with its core principles of “never trust, always verify,” provides a comprehensive framework to protect an organization’s sensitive data and critical systems. The detailed exploration of its five pillars—Identity Verification, Device Trust, Microsegmentation, Least Privilege Access, and Data Protection and Encryption—illustrates how Zero Trust secures corporate environments by preventing unauthorized access and minimizing the impact of breaches.

Implementing these practices not only bolsters security but also enhances compliance, reduces operational risks, and improves network visibility. As cybersecurity threats continue to evolve, adopting Zero Trust and integrating solutions like OpenZiti will be crucial for organizations aiming to fortify their defenses and ensure data integrity in a progressively interconnected world. The synergy between NetFoundry and OpenZiti demonstrates a forward-thinking approach, leveraging open-source innovation to advance network security and resilience, which is vital for thriving in today’s digital ecosystem.

The post The Five Pillars of Zero Trust Security appeared first on NetFoundry.

“Zero trust” is often a long, tough journey.  But it doesn’t need to be.  And the answer is actually simple once we separate reality from the marketing fluff from many zero trust vendors. Everyone claims to have a zero trust solution including the top security vendors like Cisco, Palo Alto Networks, Zscaler, CrowdStrike, and Okta. This article is an overview of zero trust and an example from a major new player in secure networking and the leading open source zero trust platform provider NetFoundry.

Zero Trust Overview

Let’s start with the problem.  There are two main reasons why “zero trust” is difficult:

1. Most “zero trust” solutions are not zero trust. Ironically, they trust the Internet! Trusting the Internet causes complexity and other problems.
   
   
2. Most “zero trust” solutions are too broad and disruptive. They impact entire user groups or sites, backhaul everything, cause performance problems, and disrupt the WAN and firewalls. They are too broad to be effective for specific use cases such as private data center-hosted apps, third-party access, multi-cloud, IoT, APIs, and remote management.

NetFoundry’s Ziti  platform helps businesses simplify the journey by taking the opposite approach of the industry’s “zero trust solutions”:

1. NetFoundry does not trust the Internet.  No open inbound ports.  No firewall hole punching.  No reliance on IP addresses or public DNS.  You can choose to use federated IDPS and MFA, but you are not forced to – you use it when you decide it is appropriate.  You don’t even need to trust NetFoundry itself – it is built on open source OpenZiti – you don’t need to trust the label on the tin, or hope the black box does what it says it does.
   
   
2. NetFoundry enables you to choose your path and makes it so your paths are not disruptive.  Move at any level, even individual apps, such that business priorities determine the journey.  Every app is routed independently – no performance-impacting backhaul tunnels.  Add use cases without disrupting existing networks or firewalls.  And, because NetFoundry covers use cases like APIs, remote management, IoT, private DC apps, and 3rd party access, you don’t need to cobble together an assortment of different solutions.

Let’s take a more detailed look at how NetFoundry differs from the top zero trust vendors:

NetFoundry principle #1:
Don’t trust the Internet = simpler secure networking

Unlike “zero trust” approaches, NetFoundry’s NetFoundry service enables you to not trust the Internet, at all (read the “great zero trust lie” appendix to see how solutions marketed as “zero trust” actually trust the Internet).  What does it mean to not trust the Internet?

• No open inbound firewall ports in front of your servers.  Not 443.  Not 80.  No ACLs or hole-punching schemes.  No pseudo-random ports.  Nothing.
  
  
• Your servers are no longer exposed to the Internet, but your users consume your service from the Internet or whatever network they are on.
  
  
• With NetFoundry, each app session is authorized before it is allowed to connect on the overlay network – the ‘firewall’ moves to the origin of the app session.
  
  
• Authorization is based on strong identities (cryptographically verified certificates), rather than IP addresses, and attribute-based access.
  

This distrust of the Internet is enabled by the private Ziti overlay network fabrics (self-hosted in the OpenZiti open source option, or hosted by NetFoundry or NetFoundry partners in the NetFoundry option).  Authorized endpoints open outbound sessions to the private overlay network fabric; the fabric merges the sessions.

NetFoundry principle #2:
The app is the new edge = simpler secure networking

NetFoundry endpoints treat the app as the new edge.  What in the world does that mean?

• Direct routing.  Each app is routed independently and directly, from its source.  For example, a user may be using some apps or APIs in which the servers are in a nearby private data center or edge site.  Rather than first backhauling those apps or APIs to somewhere else, the NetFoundry endpoints will route those sessions directly.  Meanwhile, other apps and APIs are also routed directly to other sites, according to your policies (such as latency minimization, geofencing, and interface costs).
  
  
• Your policies are in control. Not all apps need to be routed over NetFoundry. If your policy states that Netflix or YouTube should go directly to your Internet gateway, proxy, or CASB, then the NetFoundry endpoint will follow that policy.
  
  
• Your business priorities determine your path. You have full control of your zero trust path. For example, start with one app, a certain user group, specific sites, a time-sensitive use case…or some combination. It is up to you, and the rest of your users or apps will be unaffected.
  
  
• No network disruption. NetFoundry forms app-specific, microsegmented zero trust overlays. This means you run it over any WAN or Internet, without disruption. NetFoundry has endpoints in each major cloud marketplace. Spin them up in minutes using your existing DevOps and cloud orchestration tools.
  
  
• No firewall disruption. Since NetFoundry doesn’t require any open inbound ports, your firewalls are also not disrupted.
  
  
• Every use case. NetFoundry endpoints go anywhere – even inside your apps or APIs, as code (agentless). You can also use host-based agents and virtualized/containerized gateways. NetFoundry endpoints serve every use case including APIs, IoT, multi-cloud, remote management, and 3rd party access. This means you avoid piling up different solutions for different use cases.
   
• Combine cybersecurity and network. NetFoundry covers both sides, like an SD-WAN that is natively secure or a cybersecurity solution with an embedded overlay network.

Comparing the Top Zero Trust Vendors

The primary differences between Cisco, Palo Alto Networks, Zscaler, CrowdStrike, Okta, and NetFoundry lie in their core focuses and approaches:

1. Cisco: Focuses on comprehensive security solutions for network, endpoint, and cloud security, emphasizing advanced threat protection and scalability​​​​.
   
   
2. Palo Alto Networks: Known for its next-generation firewall technology and cloud security solutions, with a strong emphasis on real-time threat detection and a user-friendly interface​.
   
   
3. Zscaler: Specializes in cloud-native Zero Trust Network Access (ZTNA) solutions, providing secure web gateways and replacing traditional VPNs with a least-privileged access model​​.
   
   
4. CrowdStrike: Renowned for its endpoint security expertise, leveraging a cloud-native architecture and behavioral analytics for real-time threat detection​​.
   
   
5. Okta: Focuses on identity-centric security, offering Single Sign-On (SSO) and adaptive authentication to streamline user access management​​.
   
   
6. NetFoundry: Distinctly emphasizes Zero Trust Networking through its platform, which avoids trusting the internet by eliminating open inbound ports, using cryptographically verified identities, and providing flexible, app-specific microsegmentation without disrupting existing networks or firewalls​​. It also is the only vendor that enables companies to embed zero trust networking in their applications, eliminating the need to rely on perimeter security.
   
   

In summary, while Cisco, Palo Alto Networks, Zscaler, CrowdStrike, and Okta provide comprehensive and specialized security solutions across different aspects of network and cloud security.  NetFoundry uniquely focuses on Zero Trust Networking with a strong emphasis on flexibility, software-defined overlays, embedding, and the management of secure connectivity.

Appendix: the great “zero trust” lie

Most “zero trust” implementations authorize everyone, even if they appear to be on a certain LAN or WAN. This is sensible—very sensible. IDPS, MFA, biometrics, certificates, and hardware root of trust help.

But the problem is not just the robustness of the authorization step.  The problem is when the authorization takes place.  In most “zero trust”, the auth still takes place after the network connection (layer 3) – the ports in front of the server are still open.
This also serves as an excellent litmus test to cut through vendor hype: if your team can’t use a deny-all inbound policy on your firewalls, without any ACL exceptions, then the vendor’s “zero trust” solution actually trusts the Internet.

So, ironically, despite the “zero trust” moniker, the web or app server is still initially allowing (trusting) the layer 3 Internet connection, and then trying to weed out the unauthorized users.  Of course, silly marketing terms aside, we do need to trust something.  But in “zero trust”, we are implicitly trusting the layer 3 connection from the Internet!  The result is these “zero trust” approaches are akin to letting 200,000 fans into a stadium for a World Cup soccer match, and then trying to figure out who has tickets.  Except it is billions of fans (users, attackers, bots).  And it is a stadium (your network) with virtually unlimited seats.  And the “fans” move at the speed of light, literally.

Despite the dangers of that authorize-after-connect model, the attacker will most likely be denied once it fails to authorize – the initial connection will be torn down.  Unfortunately, bugs, business logic gaps, misconfigurations, and vulnerabilities enable attackers to essentially bypass this public auth gate.  This means anyone or anything on the Internet can be an attacker since everyone is allowed to connect before they are made to authorize.  And that’s why the improvements that most “zero trust” solutions make on authorization are helpful but not sufficient – the authorization takes place after the initial network connection is made – too late in some cases.  Hence, global cyber attack damage is now over $1 trillion per year.  Hence why “zero trust” solutions are often incredibly complex and difficult to implement – you still need other solutions to fill the holes – giving you a new problem of figuring out how to patch everything together.

The post Zero Trust Overview: Comparing NetFoundry to the Top Zero Trust Vendors appeared first on NetFoundry.

Two approaches gaining traction in reducing attack surface visibility are the Metrics Manifesto, a framework proposed by Richard Seiersen, and the implementation of zero trust networking (ZTN). Not all ZTN is born equal, so we will specifically focus on ZTN, which allows us to make our attack surface ‘Invisible’ to the internet, including no inbound firewall ports. Using the Metrics Manifesto’s principles and Invisible ZTN, we will see how to reduce the attack surface massively and breach risk while increasing business value.

Understanding the Metrics Manifesto & Frameworks

The Metrics Manifesto (MM), devised by Richard Seiersen, outlines principles to improve an organization’s security posture by leveraging metrics and data-driven decision-making. The manifesto emphasizes the importance of quantifying security risks and implementing actionable metrics to gain insights into an organization’s security posture – it makes me think of Six Sigma (6σ) for Security (6σ as an application of engineering principles to improve business processes by reducing defects and errors, minimizing variation, and increasing quality and efficiency). By adopting this approach, organizations can better understand and address vulnerabilities, allocate resources effectively, and continually improve security defenses. To understand more, I recommend watching his 2019 RSA presentation, The Metrics Manifesto.

The MM incorporates frameworks, including the NIST Cybersecurity Framework (CSF), to map the ‘Control State’ and ‘Exposure State’. In the YouTube video, Richard discusses applying zero trust controls to ‘Protect’ as part of the ‘Control State’ (see diagram) but not making the Attack Surface ‘Invisible’.

Earlier in the presentation, Richard does set out the key observations and beliefs of the Metrics Manifesto, including:

“We believe shrinking the attack surface, while not slowing value exposure, is the new job #1 for security”

This is part of Richard’s observation: “Most metrics count, the best ones confront”. The metric I believe is most important, which confronts our whole view of cyber security, is:

“How many open inbound firewall ports do you have”?

What’s wrong with holes in our firewall?

A firewall is a fire-resistant barrier used to prevent the spread of fire. We took the idea of firewalls (FW) and applied them to computing in the 1980s. We place them between two networks and monitor incoming and outgoing traffic based on predetermined security rules. To do this, we ‘punch holes’ through them, and large enterprises have thousands to 100s of thousands of firewall rules.  For example, to the left is a diagram from a security vendor with recommended open FW holes (red circles). While these open inbound ports allow users and systems to connect, attackers can see them too. Tools like Shodan and Censys scan the internet to provide a ‘Search Engine of Everything for Internet-connected devices’. This allows attackers to see bugs, misconfigurations, business logic gaps, and similar vulnerabilities. While FWs try to differentiate between legitimate use and attackers and terminate unauthorized connections, this is too late. The 2023 IBM Security X-Force Threat Intelligence Index identified the back door systems access these firewall holes provide as ransomware’s #1 attack vector (i.e., exploiting outbound FW ports). The #2 attack vector is exploiting public-facing apps (i.e., using inbound FW ports). We suffer trillions of dollars of cyberattack damage yearly, as it’s impossible to win a race against the entire Internet. 

What if, instead of having open FW ports, we could make everything ‘Invisible’ to the internet? Threat actors can’t attack what they can’t see, so having no inbound FW ports would be a metric that confronts. This requires a new approach called ‘Zero Trust’.

Zero Trust Networking: An Introduction

The term ‘zero trust’ was born in 2010 when John Kindervag popularized it while working for Forrester Research when he presented the idea that an organization should not extend trust to anything inside or outside its perimeters. I was first introduced to Zero Trust ideas when I joined NetFoundry. In my first year, massively improved my knowledge of Zero Trust when I read Zero Trust Networks, O’Reilly, which included the idea that:

“all hosts be treated as if they’re internet-facing. The networks they reside in must be considered compromised and hostile.”

This idea was also incorporated into NIST 800-207, the Special Publication on Zero Trust Architecture. We can see this maps nicely to the Metrics Manifesto. If our resources are publicly facing, they are more exposed. If we do not introduce extra controls, our attack surface and risk of breach increases. The naughty little secret is that many control systems (VPNs, Firewalls, Zero Trust solutions, etc.) have inbound ports that listen for internet connections. They can be (and are frequently) compromised through vulnerability or misconfiguration. At the same time, these extra controls to increase security reduce agility and value to the business – it’s an age-old security balancing act.

What if we could close all inbound ports and effectively change ‘Public Proximity’ from public to private? This would massively reduce our attack surface and breach risk. No inbound ports would mean no access to any applications unless on a private, physical network… this would slow value exposure and business opportunities.

Magical Zero Trust Networking: Ziti Invisibility

Returning to the questions, What is your attack surface visibility” and “How many open inbound firewall ports do you have?”, we must understand that not all Zero Trust Networking solutions are equal. Some allow us to close all inbound ports on our firewall while using the public internet – i..e, making it Invisible and invisible to external malicious actors. This utilizes the concept of Software-Defined-Perimeters, popularised by the Cloud Security Alliance, specifically ABC, Authenticate/Authorise-Before-Connect, using cryptographic identity and outbound-only connections. I wrote a blog last year exploring this by comparing zero trust networking solutions using analogies from Harry Potter (hint, it’s like making your app magical with an ‘invisibility cloak’ and a ‘port key’).

Even better, ZTN with ABC is available as an open-source solution called OpenZiti. NetFoundry, the company I work for, maintains OpenZiti and provides a SaaS version called NetFoundry Cloud. You can try it out for free today.

Ziti also introduces a radical possibility called embedded zero-trust networking with ABC. This makes your application ‘Invisible’ to all hostile and compromised networks, including WAN, LAN, and host OS. It is the logical conclusion of zero trust, assuming all networks are compromised and hostile. It is for all these reasons that many have said:

“Ziti provides the best NIST 800-207 adherence across all architectures”. 

The Metrics Manifesto & Ziti:

By utilizing Ziti and ZTN with ABC, we make our attack surface Invisible and massively reduce our risk of breach. Further, as we are replacing bolt-on security and networking solutions with built-in, using software and APIs, we can increase business velocity and innovation to drive more business opportunities. We have created a high-level (an area for more quantified research) overview of these reductions in risk according to deployment type:

• ZTN with ABC at the Network Level (ZTNA):
  • Close all inbound FW ports – this will stop all external network attacks, including brute force, CVE, port scans, DDoS, etc. – for a massive reduction in the attack surface. 
  • Optionally close all outbound ports, except to ZTN – stopping connections to C&C or data exfiltration – for another order of magnitude reduction risk by breaking the breach chain.
    
    
• ZTN with ABC at the Host Level (ZTHA): This extends zero trust to the host. Even if the network is compromised, the hosts cannot be for another order of magnitude reduction in attack surface.
  
  
• ZTN with ABC at the App Level (ZTAA): Extends zero trust to the app. Even malicious SW on a host cannot easily break into the app and its ZTN for another order of magnitude reduction in the attack surface.

The Holy Grail of Security: Zero Trust Invisibility

The Metrics Manifesto and zero trust networking with authenticate-before-connect present compelling strategies for shrinking the attack surface while not slowing value exposure. By implementing Ziti or comparable technology, organizations can close all inbound firewall ports and potentially more to deliver the best adherence to NIST 800-207 and treat all networks as compromised and hostile. 

MM and ZTN with ABC help us reduce breach risk by orders of magnitude and drive greater business opportunities. In the spirit of Richard and his wonderful metrics-based approach, we need to develop a more quantified analysis of how much ZTN with ABC can reduce risk, with careful analysis of different implementations across ZTNA, ZTHA, and ZTAA.

Organizations that embrace the Metrics Manifesto and adopt ZTN with ABC gain a comprehensive security approach beyond traditional perimeter-based defenses. By leveraging data-driven decision-making and ‘magical zero trust’, organizations can proactively protect their valuable assets, safeguard sensitive data, and stay one step ahead of the ever-evolving threat landscape.

The post The Metrics Manifesto: Attack Surface Visibility vs ‘Invisibility’ appeared first on NetFoundry.

Welcome to Part 2 of our Zero Trust Journey! This article focuses on applying the principle of zero trust to our existing platform infrastructure. By the end, production databases and SSH servers will only be accessible through the OpenZiti Network, effectively eliminating network exposure to both public and private anonymous clients.

In case you missed Part 1, we began with a common defensive strategy: using a bastion host as an SSH jump box and proxy to shield a private zone from direct internet exposure. By implementing OpenZiti, we transformed the SSH bastion host into a “dark” asset on all networks while maintaining normal functionality—a concept we call Bastion Dark Mode.

In this discussion, we’ll continue the bastion pattern: a host with special network access depicted in the diagrams as being behind the firewall. We’ll remove the dark SSH bastion from our OpenZiti overlay and use an OpenZiti Router that is logically transparent to the client. 

Dark bastions are great, but transparent bastions are even more flexible and much more convenient. Dark bastions allowed us to continue using our existing SSH proxy configurations without interrupting business as usual. This was important for the transition to dark bastions. After making our bastions dark, we realized the security provided by those SSH proxies would be made entirely redundant if we were to apply OpenZiti to the connection! So that’s what we set out to do. 

Transparent bastions allow us to connect to our protected resources without a client proxy configuration: no more SSH jump box. Additionally, there are certain problems that dark bastions never solved. For example, How can we send GitHub webhooks to our private Jenkins server? It just didn’t make sense to send the webhooks over SSH through a dark SSH bastion, so we used a GitHub Action built with OpenZiti’s NodeJS SDK to send the webhooks to Jenkins. You can read about how that works here.

Using the Transparent Bastion

From my perspective as a user, I don’t need to know anything about the transparent bastion to use it effectively. To start using the transparent bastion seamlessly I just need to stop using the opaque SSH bastion! 

Let’s say I’m using the laptop device shown on the left side of the diagram. In the episode 1 configuration, I used an SSH jump box configuration to reach our resources. An example configuration for a resource that is an SQL server is to save the SSH bastion’s domain name and my proxy username and private key file path into my SQL client application.

My OpenZiti badge there represents my tunneler which is the OpenZiti agent on my computer. I’ve been issued an identity for that tunneler which I have loaded. With that one step completed any application on my computer has access to the resources shown on the right side of the diagram. I no longer need an SSH jump box or proxy of any kind. The bastion is shown in the diagram below, but I don’t see it as a user because it’s part of the OpenZiti overlay which is transparent from one edge to the other.

Setting up OpenZiti Services

A prerequisite for a direct, transparent connection is an OpenZiti service that specifies the destination. For now, we will be creating the few services we have manually. We plan to use the NetFoundry API to automate setting up these services in the future when we have a less static set of resources. 

Fortunately, it’s a one-time cost for each destination. When I want to SSH to a particular host or connect to a particular SQL server then I need to take a one-time administrative step in the NetFoundry web console to specify that connection. Here’s one example of specifying a production database server as a Ziti service.

1. Apply some hashtag role attributes so that my new service aligns with the existing service policy for production databases.
2. Define a domain name and port pair that clients will use to connect to this service. This could be a fictitious name or the real name of the server.
3. Select the bastion host that has access to the application server we’re specifying.
4. Define the real domain name and port of the application server from the perspective of the bastion host where ziti-router is running.

Reference: Support Hub article about creating services and role attributes. 

The post A Zero Trust Journey: Transparent Bastions appeared first on NetFoundry.

Gracefully Going Dark

Our build systems, support engineers, admins, and developers use the SSH infrastructure daily. We realized that we would have to step this forward without too much disruption. Our fortress walls comprised a fleet of Linux hosts, each running an OpenSSH server. According to best practices, they were locked down tight but were still listening on the open internet. Going “dark” would mean the internet access we were using to reach the bastion hosts would no longer be available as soon as the firewall exceptions are removed, disallowing inbound 22/TCP.

Enter the Dark Bastions

We treated our bastions like any other app and applied OpenZiti to control the network-level access to the servers’ listening ports. On the SSH server host, we installed an OpenZiti tunneler as a system daemon. Any tunneler can be configured to provide server or client functionality. For the sake of clarity, I’ll refer to “server tunneler” or “client tunneler”. In our case, the server tunneler was bound to a single OpenZiti service for SSH that shovels packets between the OpenZiti network and localhost:22, the device’s host-only loopback interface. This is a simple thing to set up and works for any services you want to expose securely, on any OS, any device.

We continued using the familiar “ssh” (OpenSSH client) on the admin workstations in tandem with a client tunneler. This means we didn’t have to change our OpenSSH client configuration, the domain names we were using, or the “ssh” command-line arguments and options! The global DNS records for the bastions were still in place to allow for a seamless transition.

A neat feature of an OpenZiti tunneling app is its ability to discover OpenZiti services with its built-in DNS. Our workstations then preferred the built-in OpenZiti DNS above global DNS for name queries that match an authorized OpenZiti service. This was powerful because it enabled a seamless transition! Each workstation gained the ability to jump on and off the OpenZiti solution by merely toggling its client tunneler. We retained the global records to support our transition, but nothing stops us from deleting them entirely.

The final result is that the bastions are invisible to the attacker viewing them from the internet or the subnet behind the wall. Our authorized workstations continue to use them normally after installing OpenZiti as signified in the drawing by the ultraviolet “Z” badge. This has been a painless change and is an enormous improvement in the overall security posture and immediate visibility of how the bastions are being used, and by whom! Every time we gain a new admin or support engineer we add them to the system with these steps:

1. Ask for their SSH pubkey to add to the Jenkins job for bastion configs which uses an OpenZiti tunneler to access the dark bastions in the same way as the workstations
2. Have them install a tunneler on their workstation
3. Add the appropriate attributes to their identity in the NetFoundry console to authorize bastion access.

There’s still one not-so-zero-trust feature of the dark bastions diagram: the SQL server. It is still visible to its local network and therefore vulnerable if a malicious actor can get behind the wall. We’ll take a swing at that remaining vulnerability in a future episode.

The post A Zero Trust Journey: Bastion Security “Dark Mode” appeared first on NetFoundry.