Zero Trust Network Segmentation: Microsegmentation and Palo Alto Policy Design

March 10, 2026·9 min read

Overview

Zero Trust is not a product — it is an architecture principle: never trust, always verify. Every user, device, and workload must prove its identity and be authorized before accessing any resource, regardless of whether the request originates inside or outside the traditional perimeter. In practice, implementing Zero Trust means replacing flat, implicit-trust networks with explicitly segmented zones, identity-aware policy enforcement, continuous session inspection, and comprehensive logging. This guide covers how to design and implement Zero Trust segmentation using Palo Alto NGFW as the enforcement point.

// Zero Trust Zone Segmentation — Explicit Allow, Implicit Deny

Part 1 — Zero Trust Principles

The Five Core Principles

Zero Trust is built on five verifiable assertions for every access request:

Verify explicitly — Authenticate and authorize based on all available data: identity, location, device health, service, workload, and data classification.
Use least-privilege access — Limit user and workload access with just-in-time and just-enough-access policies.
Assume breach — Minimize blast radius, segment access, and verify end-to-end encryption. Use analytics to detect anomalies.
Inspect all traffic — TLS inspection, application identification, and threat prevention on every flow — including east-west traffic.
Log everything — Every allow and deny decision must be logged with enough context to reconstruct what happened.

What Zero Trust is NOT

It is not just multi-factor authentication
It is not "buy a ZTNA product"
It is not achievable with a flat network, even with a perimeter firewall

Part 2 — Zone Design

Start with a zone model. Every segment of your network belongs to a zone, and traffic between zones is inspected by the NGFW with an explicit policy. There is no implicit trust between zones — even internal zones.

Zone	Contents	Trust Level	Key Policy
UNTRUST	Internet, remote users pre-VPN	None	Allow only HTTPS inbound to DMZ, deny all else
DMZ	Web servers, reverse proxies, email gateways	Low	Allow only specific ports to TRUST; no direct access to DB
TRUST	Internal users, workstations	Medium	Allow outbound with App-ID inspection; no lateral movement
SERVERS	Application servers, APIs	Medium	Allow only app-specific ports from TRUST; log all access
DB	Databases, data warehouses	High	Allow only from SERVERS zone on specific DB ports; deny all else
MGMT	Jump hosts, NMS, SIEM	High	Allow only from defined admin IPs; MFA required
OT / IoT	Industrial, building systems, IoT devices	Isolated	No access to TRUST or SERVERS; outbound NTP/syslog only

Part 3 — Palo Alto Policy Design

Security Policy Best Practices

# Policy design rules (Panorama / CLI equivalent):
#
# 1. Use App-ID, not port-based rules
#    BAD:  from TRUST to SERVERS  any → port 443  allow
#    GOOD: from TRUST to SERVERS  ssl,web-browsing → allow
#
# 2. Use User-ID groups, not IP addresses
#    BAD:  source 10.1.0.0/24  → allow
#    GOOD: source user: finance-team@corp.com → allow
#
# 3. Attach Security Profiles to every allow rule
#    Every allow rule needs: AV + Anti-Spyware + Vulnerability + URL Filter
#    Use Security Profile Groups to keep this consistent
#
# 4. Log at session end on ALL rules including deny
#    Denied traffic logs are critical for forensics

Panorama Policy Rule Structure

# Pre-rules (pushed from Panorama — apply to all devices):
# Rule 1: Block known-bad — apply Threat Prevention, block C2 destinations
# Rule 2: Block high-risk applications — bittorent, tor, anonymizers
# Rule 3: Allow MGMT zone → all zones on mgmt-specific apps only

# Device-local rules (per-firewall policy):
# Rule 10: UNTRUST → DMZ  |  ssl, web-browsing  |  Profile: strict  |  Log: yes
# Rule 20: DMZ → SERVERS  |  specific app only  |  Profile: strict  |  Log: yes
# Rule 30: TRUST → SERVERS  |  User-ID group  |  Profile: strict  |  Log: yes
# Rule 40: TRUST → UNTRUST  |  ssl + allowed-SaaS  |  URL Filter  |  Log: yes
# Rule 50: OT → UNTRUST  |  ntp, syslog  |  Profile: strict  |  Log: yes
# Rule 99: Catch-all deny  |  any → any  |  Log: yes  |  (explicit, for logging)

SSL/TLS Inspection

# SSL Inspection is mandatory for Zero Trust
# Without it, you cannot see what's in encrypted traffic
#
# SSL Forward Proxy — for outbound user traffic (TRUST → UNTRUST)
# SSL Inbound Inspection — for inbound traffic to DMZ servers
#
# Exemptions (no-decrypt list) — required for:
#   - Financial / banking sites (certificate pinning)
#   - Medical record systems (HIPAA concerns)
#   - Software update servers
#   - Always document why each exemption exists

Part 4 — User-ID and Device Identity

Zero Trust requires that every policy decision knows who the user is and what device they are using — not just what IP address sent the packet.

# User-ID agent sources:
#   - Windows Security Event Log (domain login events)
#   - Captive portal (for non-domain devices)
#   - GlobalProtect (VPN/ZTNA — strongest identity signal)
#   - Syslog from RADIUS/LDAP

# HIP (Host Information Profile) — device posture checks
# HIP allows or blocks based on endpoint state:
#   - Is AV installed and up to date?
#   - Is disk encryption enabled?
#   - Is the OS patch level current?
#   - Is the device corporate-managed?

# Policy example using HIP:
# from UNTRUST to DMZ
# source user: any
# HIP profile: corporate-compliant
# application: ssl
# action: allow
# Unmanaged/non-compliant devices hit the catch-all deny

Part 5 — Microsegmentation for East-West Traffic

The majority of breach-related damage happens via east-west lateral movement after an initial compromise. Microsegmentation addresses this.

# East-west segmentation options:
#
# Option 1: Inter-VLAN routing through NGFW (most common)
#   All inter-VLAN traffic routed through firewall
#   High visibility, lower throughput on large flat networks
#
# Option 2: VM-Series on hypervisor (VMware NSX / Nutanix)
#   Firewall runs inside the hypervisor, inspects VM-to-VM traffic
#   Best for data center east-west control
#
# Option 3: Prisma Access (cloud-delivered) + ZTNA
#   Users connect to cloud enforcement point
#   Application access is per-app, not network-wide

# Minimum effective east-west segmentation:
#   Separate VLANs/subnets for: users, servers, DB, OT, management
#   Route inter-VLAN traffic through NGFW (not L3 switch)
#   Deny VLAN-to-VLAN by default — allow only specific, inspected flows

Zero Trust Implementation Checklist

Network is divided into explicit zones — no flat /16 subnets with full internal trust
All inter-zone traffic routes through NGFW — no L3 switches bypassing inspection
Security policies use App-ID and User-ID — no port-based or IP-only rules
Every allow rule has a Security Profile Group attached (AV, Anti-Spyware, Vuln, URL)
SSL/TLS inspection is enabled for outbound and inbound traffic with documented exemptions
All rules log at session end — including the implicit deny
HIP profiles enforce device posture before granting network access
Database zone is not directly reachable from TRUST or UNTRUST — only from SERVERS zone
OT/IoT devices are in an isolated zone with no inbound access from any internal zone
SIEM receives logs from all firewall zones — alerts on lateral movement patterns