The Zero Trust Landscape

From when it was first coined in 2009 by Forrester to when it was featured in a special publication in 2020 by NIST, zero trust has come a long way. However, zero trust is an often misunderstood and overused term by the vendor community. Due to the confusion caused by the inappropriate use of the word, people tend to misinterpret it, and even dismiss its relevance. It is necessary to clarify its true meaning, given that it is a fundamental paradigm shift in how cybersecurity should be practiced.

Before trying to understand the zero trust landscape, we must first define it clearly. Zero trust stands for “always verify, never trust.” But verify what? Verify privileges. However, to get to privileges, you first need an identity since privileges are awarded to identities.

Historically, privileges were given to networks, and those can have a huge boundary (the perimeter). We continue to expand the perimeter flexibly (now as SDP - software-defined perimeter). However, for zero-trust, both the grains of identity and privilege should tend to zero - the least granular identity boundary and the least amount of privileges needed by the identity to get the job done.

When Forrester coined the term, it was more in the context of deperimeterization. However, that is not what actually took place. Instead, the perimeter was merely diminished and corporate users and devices were removed to be outside of that trusted perimeter. The main theme was to ditch the VPN, consolidate and secure user access to services, and protect services directly in a mobile-first world. In contrast, applications were mostly static and rigid - sitting behind often painstakingly programmed firewall protection.

Many companies have played a pivotal role in the zero trust journey so far:

  • Palo Alto Networks created NGFW technology around userId and appId. This could potentially be used to manage user privilege for apps by placing a powerful PANW firewall appliance between users and your data center.

  • Google showed the world that this was doable and workable purely in software in a way that was also friendly to a mobile and untethered workforce. They even published the now-famous BeyondCorp paper based on their experience and execution.

  • Identity providers like Okta/Duo/Ping Identity helped with MFA, SSO, and user authentication. Okta now offers adaptive MFA which goes into the realm of CARTA (continuous zero trust beyond the initial user authentication)

  • Zscaler/Netscope/Cato/Cloudflare did the plumbing to create a software-defined perimeter (ZTNA, SASE) integrating with the identity providers to obtain user identity to then enforce privilege on the software-defined perimeter.

How about the apps and resources within the (ever-growing) perimeter that still remains? Over time, they have gotten harder to tame - being ephemeral, deployed in an agile manner, auto-scaled, and dynamically placed. AWS (and similarly other cloud providers) created IAM roles assigned to resources that could be used to access cloud services offered by them on the basis of identity. Unfortunately, the rest of the world is mostly still assigning privileges to IPs and subnets - whether it is AWS VPC, AWS security groups, CNI, or k8s/Istio.

Araali Networks seeks to change that by creating an identity-based perimeter-free world of applications having privileges that are least permissive. We deliver deperimeterization as it was originally envisioned at the speed of DevOps.