All posts

Zero Trust Architecture

by Robert Broeckelmann

Zero Trust Architecture (ZT or ZTA) is a security model / framework based on one simple idea: Never trust, always verify. From NIST, we have, the “… ZT approach is primarily focused on data and service protection but can and should be expanded to include all enterprise assets (devices, infrastructure components, applications, virtual and cloud components) and subjects (end users, applications and other non-human entities that request information from resources)”. Furthermore, “A zero trust architecture (ZTA) is an enterprise cybersecurity architecture that is based on zero trust principles and designed to prevent data breaches and limit internal lateral movement.” ZTA is a system / security architecture design philosophy. ZTA operates using end-to-end encryption, access control mechanisms, network monitoring capabilities, and in the interest of buzzword-compliance, AI to analyze the data collected.

In traditional networks, anything inside the network perimeter was considered trusted. Once an attacker got inside (phishing, compromised laptop, VPN breach), they could often move around freely — ie, lateral movement.

Zero Trust flips that model.

Instead of trusting the network, every request must be authenticated, authorized, and verified continuously regardless of where it originates. This concept was formalized by the National Institute of Standards and Technology (NIST) in NIST SP 800–207.

From the same NIST paper, we have “ZT is not a single architecture but a set of guiding principles for workflow, system design and operations that can be used to improve the security posture of any classification or sensitivity level.” This means that it isn’t a particular product or vendor. It’s a set of capabilities and design principles.

If you take away nothing else from this discussion, please, remember, “There is no such thing as a trusted network.”

Why ZTA?

Traditional “castle-and-moat” security fails because:

  • Perimeters are gone. Modern environments include: cloud infrastructure, SaaS, mobile devices, remote work. There is no single secure network boundary anymore.
  • Attackers move laterally. Once attackers compromise a device, they try to: access internal APIs, enumerate services, escalate privileges. ZTA limits lateral movement.
  • Insider threats. Not all threats come from outside. Zero Trust assumes: Any user or device could be compromised.

Core Tenants

Most implementations follow three fundamental rules.

  • Verify explicitly (this is my favorite, authentication at every level).
  • Use the Principal of Least Privilege (use the PoLP, just as Luke used the force).
  • Assume a breach has already occurred (the enemy is within the gates).

Additionally, the NIST paper specifies:

  • All data sources and computing services are considered resources
  • All communication is secured regardless of network location
  • Access to individual enterprise resources is granted on a per-session basis
  • Access to resources is determined by dynamic policy — including the observable state of client identity, application/service, and the requesting asset — and may include other behavioral and environmental attributes.
  • The enterprise monitors and measures the integrity and security posture of all owned and associated assets.
  • All resource authentication and authorization are dynamic and strictly enforced before access is allowed.
  • The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture.

You may also see:

  • Endpoint Security
  • Data Security
  • SIEM
  • AI capabilities

Discussed in ZTA descriptions.

All of this comes together to re-enforce Defense in Depth.

Assume Nothing; Verify Explicitly

Every request must be verified using multiple signals:

Authentication technologies often include:

  • OAuth 2.0
  • OpenID Connect
  • Mutual TLS

Apply the Principle of Least Privilege

Apply the Principal of least Privilege to every access control and design decision. Users and services should only get access to exactly what they need.

Access is limited by:

  • Role
  • Device state
  • Session context
  • Time limits

Common models for access control include:

  • Role-Based Access Control
  • Attribute-Based Access Control

Assume a Breach Has Occurred Already (or Will Soon)

ZT assumes that the attacker is already inside your network.

So the system focuses on:

  • Containment: It should be extremely difficult for an attacker to move from a compromised internal system to the next (hopefully, uncompromised) hop in the processing path (or anywhere else on the network).
  • Segmentation: Macro and Micro Segmentation concepts should be deployed throughout the network.
  • Monitoring: There should be broad and deep monitoring of the entire network.
  • Anomaly detection: Anomaly detection can come from traditional IDS / IPS systems monitoring the network, host-based IDS / IPS systems, traditional firewalls, the identity provider, network equipment with detection agents, and other network nodes.

Doing this limits lateral movements of an attacker. Just because the first layer of components has been compromised doesn’t mean the attacker automatically has free-reign to the entire internal network.

ZTA Benefits

Incorporating ZTA into your application / system architecture provides the following benfits:

  • Support remote and hybrid work.
  • Minimize risk.
  • Ease / address regulatory compliance
  • Robust cloud migration strategy.
  • Strengthen overall security posture.

Components of ZTA

A real ZTA environment includes several layers.

Components of a ZTA

It’s difficult to create a reference architecture for a ZTA in more detail than this without making assumptions about application architecture, the technology stack, and specific vendor products. That’s not what I’m trying to do here.

Identity Provider (IdP)

Centralized identity management verifies users and services.

For example:

  • Okta
  • Auth0
  • Microsoft Entra ID
  • Ping Federate
  • KeyCloak

Some of these have more capabilities than others that tie into anomaly detection and ZTA. I’m not attempting to do a compare and contract here of specific products.

The IdP handles:

Policy Decision Point (PDP)

This component decides: Should this request be allowed?

Decisions are based on:

  • identity
  • device posture
  • access policies attached to the resource being accessed

I continue to be a fan of XACML / ALFA-based systems for authorization policy authoring and management. These standards put structure around PDPs and PEPs. That can be the focus of a future blog post.

The PDP tends to be a library or plugin provided by a vendor solution that integrates with various IdPs. As an example, the Balana Opensource Project provides a XACML compliant runtime for PDP / PEP as defined by the XACML spec.

Policy Enforcement Point (PEP)

This is where policy is actually enforced

Examples of this include:

  • API gateway
  • reverse proxy
  • application firewall

An authorization policy engine vendor product would provide a component (library or plugin) that can integrate with these layers.

These systems intercept requests and enforce access rules.

Micro-Segmentation

Instead of one large internal network, resources are segmented into small zones.

Each segment requires authentication.

Tools often used include:

  • Istio (Service Mesh for Kubernetes-based)
  • Linkerd (lightweight Service Mesh for Kubernetes-based)
  • Cisco Application Centric Infrastructure (not Kubernetes-based)
  • Cisco Secure Workload (formerly, Tetration, not Kubernetes-based)
  • Many other products.

You could accomplish something similar with firewalld and traditional IP firewalls, but it would be complicated.

Your network will very likely have a Macro-Segmentation deployed as well.

Resource

The important thing (application, API, file, database, etc) that is being protected and someone or something is attempting to access.

This definition works at the macro-level and micro-level as you decompose appliations into each more granular components. Something is always trying to access something else.

Continuous Monitoring

Zero Trust requires ongoing monitoring and analytics.

This includes:

  • Security logs / SIEM
  • Behavior analytics
  • Anomaly detection

Platforms often used include:

  • Splunk
  • LogRhythm

Typical Zero Trust Access Flow

A simplified request flow might look like the following:

Typical ZTA Access Flow

At each step, the system checks:

  • Who the user is
  • Device health
  • Policy compliance
  • Session risk

Typically, once at the application layer, you are dealing with a distributed (microservices, maybe) architecture that should have these same principals applied at each layer.

Common Misconceptions

As with so many good ideas in our industry, ZTA has its misconceptions, including:

  • Zero Trust is a product: It is not a product. It’s an architecture strategy. Vendors selling “Zero Trust in a box” are mostly selling marketing nonsense.
  • It replaces all security: Nope. ZT adds identity-based controls but still relies on: firewalls, endpoint security, monitoring, encryption, etc.
  • It’s only for big companies: Actually, cloud-native startups often implement it more easily than large legacy enterprises.

Where Zero Trust Is Most Useful

Zero Trust shines in environments with:

  • remote workers
  • cloud infrastructure
  • microservices
  • SaaS-heavy environments

However, a traditional on-prem data center could utilize ZTA as well. Though, notable changes in assumptions, attitudes, and approach is needed.

Industries that are heavily adopting it include:

  • finance
  • government
  • healthcare
  • technology companies

We invite everyone else to join us in the light.

Summary

Many organizations claim they have ZTA, but what they really have is a VPN and MFA, which is about 5% of a real ZTA. ZTA should be combined with Defense In Depth and other security patterns to develop your organizations security architecture.

Notes

  • AI / GenAI / ChatGPT / etc were not used to generate the text of this article.
  • I used em dashes in my writing before the current GenAI wave was a thing. Not planning on changing now.
  • Names have been changed to protect the guilty.
  • None of the hostnames or users used in examples actually exist.
  • Feel free to post any comments or suggestions below.

Originally published on Medium.

More articles