Advanced Security #zero-trust #ZTNA #BeyondCorp #micro-segmentation

Zero Trust Design Language

5 exercises — master zero trust design vocabulary: the "never trust, always verify" principle, micro-segmentation and lateral movement prevention, ZTNA vs VPN access model comparison, BeyondCorp reference architecture components, and policy engine continuous evaluation dimensions.

0 / 5 completed

Zero trust quick reference

"Never trust, always verify" — network location is not a trust signal; every request requires explicit identity + device + context verification regardless of source.
Three tenets (NIST SP 800-207) — (1) Verify explicitly, (2) Use least privilege, (3) Assume breach.
Micro-segmentation — fine-grained east-west traffic policy; each workload is its own segment; lateral movement requires explicit policy permit.
ZTNA vs VPN — VPN grants network-level access; ZTNA grants application-level access. ZTNA is continuously re-evaluated; VPN is verified only at connection time.
BeyondCorp — Google's reference ZT model: Device Inventory + Access Proxy + Access Control Engine. Users connect to the proxy, never to the network directly.
Policy engine inputs — Subject (identity/role) + Device (health/posture) + Environment (location/time/risk) + Resource (sensitivity/tier). Evaluated on every request.
Continuous evaluation — policy re-applied per request; mid-session revocation or step-up if context risk changes.

1 / 5

A security architect explains the company's new strategy: "We're moving away from a perimeter-based model. From now on, our core principle is 'never trust, always verify' — regardless of whether the request originates inside or outside our network."

What does this zero trust principle mean in practice?

Zero trust reframes the security boundary from the network edge to the identity/device/context layer. The key insight: network location is not a security signal.

Traditional perimeter vs. zero trust:

Dimension	Perimeter (castle-and-moat)	Zero Trust
Trust basis	Network location (inside firewall = trusted)	Identity + device posture + context-based policy
Lateral movement risk	High — once inside, attacker moves freely	Low — every resource requires re-verification
Remote work fit	Poor — requires VPN to "be inside"	Native — location-agnostic by design
Breach impact	High — attacker has broad internal access	Limited — blast radius contained by micro-segmentation and least privilege

Three NIST zero trust tenets (SP 800-207):
1. Verify explicitly — authenticate and authorise based on all available data: identity, location, device health, service or workload, data classification, anomalies
2. Use least privilege access — limit user access with Just-In-Time and Just-Enough-Access (JIT/JEA), risk-based adaptive policies, and data protection
3. Assume breach — minimise blast radius, segment access, encrypt end-to-end, use analytics to get visibility, drive threat detection and improve defences

Key vocabulary:
• Zero trust — security model that eliminates implicit trust based on network location; requires explicit verification for every access request regardless of source
• "Never trust, always verify" — zero trust tagline; means every request is evaluated against policy using identity + device + context, not network address
• Assume breach — design principle that treats the network perimeter as already compromised; minimise lateral movement and blast radius
• Blast radius — the scope of damage an attacker can cause if a given credential, segment, or component is compromised

2 / 5

During a zero trust architecture review, an engineer says: "We need to implement micro-segmentation to limit lateral movement. Right now, once an attacker gets into a pod in our cluster, they can reach any other service."

What is micro-segmentation and how does it prevent lateral movement?

Micro-segmentation controls east-west (lateral) traffic inside the network, not just north-south traffic at the perimeter. Most breaches succeed through lateral movement after initial entry.

Implementation layers:

Layer	Technology	How micro-segmentation works
Cloud VPC	AWS Security Groups / Azure NSG	Restrict traffic per service; deny by default; explicit inbound rules
Kubernetes	NetworkPolicy + service mesh (Istio, Linkerd, Cilium)	Pod-to-pod policy; namespace isolation; mTLS between services
Physical / VM	VLAN + ACL; VMware NSX; host-based firewall	Zone-to-zone rules; host firewall rules per workload
Application-layer	mTLS, internal service accounts, OAuth scopes	Mutual authentication at layer 7; not just network-layer allow/deny

Micro-segmentation vs. traditional network segmentation:
• Traditional segmentation — divides into coarse zones (DMZ, internal, management). Still flat within a zone; an attacker inside "internal" can reach all internal services.
• Micro-segmentation — each workload or application is its own segment; policy is per-workload, not per-zone. Granularity scales with the environment.

Key vocabulary:
• Micro-segmentation — dividing a network into fine-grained segments where traffic between segments requires explicit policy authorization; limits lateral movement blast radius
• Lateral movement — an attacker's technique of using an initial compromise to access other systems or services within the same network
• East-west traffic — service-to-service traffic inside the network or cluster; contrast with north-south (external to internal)
• mTLS (mutual TLS) — both sides of a connection authenticate with certificates, not just the server; prevents impersonation between services

3 / 5

A team evaluates replacing their corporate VPN with ZTNA (Zero Trust Network Access). A manager asks: "What's the difference? VPN gets our employees in already."

How would you explain ZTNA vs VPN to a non-technical stakeholder?

The critical ZTNA vs. VPN difference: network-level vs. application-level access. ZTNA enforces "access to one app" not "access to the network".

Comparison table:

Dimension	VPN	ZTNA
Access granted	Network segment	Specific applications only
Routing	Private IP assigned; client can route to any internal subnet	Proxied access; client never gets network routing
Verification	At connection time only	Continuous; re-evaluated per request
Device check	Certificate or password at auth	Device posture check on every request (patch level, endpoint security status)
Breach impact	Attacker gets internal network access	Attacker gets access to one application (if posture passes)
Scalability	VPN concentrators = bottleneck; expensive at scale	Cloud-distributed; scales to hybrid and multinational workforce natively

Key vocabulary:
• ZTNA (Zero Trust Network Access) — access model that grants users access to specific applications only, not the underlying network; uses identity + device + context per request
• VPN (Virtual Private Network) — tunnels traffic to create network connectivity; grants network-level access, not just application access
• Access proxy — the ZTNA component that brokers connections selectively; users connect to the proxy, which forwards only authorised requests
• Device posture — the security health of a device at time of access: patch level, EDR status, disk encryption status, certificate validity

4 / 5

A senior architect references the BeyondCorp model during a migration planning session: "Google's BeyondCorp is the reference implementation of zero trust at scale — our architecture should mirror its access proxy pattern."

What is BeyondCorp and what are its key components?

BeyondCorp is the reference zero trust architecture that practically every enterprise zero trust implementation is descended from. Understanding its components clarifies the generic zero trust pattern.

BeyondCorp components:

Component	Role	Modern equivalent
Device Inventory	Database of all managed devices, their certificates, patch level, and health status	MDM/EDR + device certificate authority
Access Proxy	Single entry point for all internal applications; users never touch internal network directly	Cloudflare Access, Zscaler, Google IAP
Access Control Engine	Policy evaluation engine: user + device + request context → allow/deny	Identity provider + policy engine (OPA, Cedar)
Trust Tier	Device trust level classification: corp-managed, corp-provisioned, unmanaged	Device compliance policy in MDM (Intune, Jamf)

BeyondCorp access flow:
1. User requests docs.corp.google.com
2. Access Proxy intercepts and queries Access Control Engine
3. Engine checks: valid device certificate in inventory? Device health (patch level, endpoint security)? User has policy permission for this service?
4. Engine decision: ALLOW → proxy forwards request to internal service; DENY → 401 response
5. Internal service never sees the external network; request appears internal from the access proxy

Key vocabulary:
• BeyondCorp — Google's reference zero trust architecture; moved access control from the network to the device + identity + context layer; eliminated VPN for internal services
• Context-aware access — access decisions that incorporate runtime context (device health, location risk, time, user behaviour) beyond just identity
• Access proxy — the zero trust enforcement point that brokers application access; users connect to the proxy rather than directly to applications
• Trust tier / device trust level — classification of a device's trustworthiness based on management status, certificate validity, and health metrics

5 / 5

In a zero trust design discussion, the team debates the policy engine component. An architect says: "The policy engine needs to evaluate the subject, the device, the environment context, and the requested resource — every time, not just at login."

What are these policy input dimensions, and what does "continuous evaluation" mean in practice?

A zero trust policy engine must evaluate all dimensions on every request. Session-level trust is insufficient — context changes between requests (device health can degrade, anomalies can emerge).

NIST SP 800-207 zero trust policy engine inputs:

Input dimension	Examples	Risk signals
Subject (identity)	User identity, role, group, auth method (MFA vs password), risk score	High-risk role accessing sensitive data; failed auth attempts
Device	Managed vs. unmanaged, OS patch level, EDR status, disk encryption, certificate validity	Unmanaged device; missing patches; EDR quarantine flag
Environment / context	Network (office vs. home vs. Tor exit node), geolocation, time of day, impossible travel	Login from London then New York in 2 hours; Tor exit node IP
Resource / target	Data sensitivity, application risk tier, required access level	PII database access from unmanaged device; production access from high-risk context

Continuous evaluation in practice:
• Session-level tokens — short-lived tokens (15 minutes); if policy changes, old tokens expire before they can be used for long
• Mid-session step-up — if context risk increases during a session (new IP, suspicious query pattern), the policy engine demands additional auth (e.g., MFA re-prompt or manager approval)
• Mid-session revocation — if a device registers a threat (EDR alert), access proxy immediately revokes the session token for that device; user is logged out
• Risk-based adaptive access — low-risk context + low-risk resource → silent allow; high-risk context → step-up challenge; very high risk → deny

Key vocabulary:
• Policy engine — the zero trust decision point; evaluates subject + device + context + resource dimensions to produce an allow/deny/step-up decision
• Policy enforcement point (PEP) — the component that enforces the policy engine's decision; typically the access proxy or an API gateway
• Continuous evaluation — reassessing access rights on every request, not just at session start; allows real-time revocation when risk context changes
• Step-up authentication — requiring additional authentication factors mid-session when access risk increases above a threshold; avoids full re-login while maintaining security