“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 marketing fluff.

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.  They backhaul everything, causing performance problems.  They disrupt the WAN and firewalls. They are too broad to be effective for specific use cases such ass private data center hosted apps, 3rd party access, multicloud, IoT, APIs and remote management.  

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

  1. CloudZiti 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 CloudZiti 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. CloudZiti 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 CloudZiti 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:

CloudZiti principle #1: don’t trust the Internet = simpler secure networking

Unlike “zero trust” approaches, NetFoundry’s CloudZiti 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 CloudZiti, 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 CloudZiti option).  Authorized endpoints open outbound sessions to the private overlay network fabric; the fabric merges the sessions.

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

CloudZiti 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 CloudZiti 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 CloudZiti. If your policy states that Netflix or Youtube should go directly to your Internet gateway, proxy or CASB, then the CloudZiti 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, or a certain user group, or specific sites, or 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. CloudZiti forms app-specific, microsegmented zero trust overlays. This means you run it over any WAN or Internet, without disruption. CloudZiti has endpoints in each major cloud marketplace. Spin them up in minutes using your existing DevOps and cloud orchestration tools.
  • No firewall disruption. Since CloudZiti doesn’t require any open inbound ports, your firewalls are also not disrupted.
  • Every use case. CloudZiti endpoints go anywhere – even inside your apps or APIs, as code (agentless). You can also use host-based agents and virtualized/containerized gateways.  CloudZiti endpoints serve every use case including APIs, IoT, multicloud, remote management and 3rd party access. This means you avoid piling up different solutions for different use cases.  
  • Combine cybersecurity and network. CloudZiti covers the network side and the cybersecurity side. Like an SD-WAN which is natively secure. Or a cybersecurity solution with an embedded overlay network.

Appendix: the great “zero trust” lie

Most “zero trust” implementations authorize everyone, even if they appear to be on a certain LAN or WAN.  Sensible.  Very sensible.  And IdPs, MFA, biometrics, certs, and hardware root of trust helps.  

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, most of the time the attacker will 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 which 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.  And 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.

Discuss On: