Network Segmentation & Zero Trust Architecture — Definitive Reference

CIPHER Training Module | Domain: ARCHITECT / BLUE Sources: OWASP, NIST SP 800-207, Google BeyondCorp, UK NCSC ZTA, PAN-OS IronSkillet, CIS Controls v8

---

Table of Contents

1. Network Segmentation Models
2. Zone Design Patterns
3. Firewall Rule Design Methodology
4. East-West Traffic Monitoring
5. Zero Trust Architecture
6. Software-Defined Perimeter (SDP)
7. Service Mesh Security
8. Network Access Control / 802.1X
9. Cloud VPC Design
10. SD-WAN Security
11. IoT/OT Network Isolation
12. Detection & Monitoring Stack
13. Migration Playbook
14. Reference Controls Mapping

---

1. Network Segmentation Models

1.1 Flat Network (No Segmentation)

All hosts share a single broadcast domain. Any compromised host can reach every other host directly.

Risk profile: Maximum blast radius. Lateral movement is trivial (T1021, T1570). A single compromised workstation can reach databases, domain controllers, and management interfaces.

When seen: Legacy environments, small offices with no security staff, improperly configured "modern" networks where VLANs exist but inter-VLAN routing is unrestricted.

Verdict: Unacceptable for any environment processing sensitive data.

1.2 VLAN Segmentation (Traditional)

Layer 2 isolation using IEEE 802.1Q tags. Traffic between VLANs must traverse a Layer 3 device (router or firewall).

Architecture:

[VLAN 10: Users] --\
[VLAN 20: Servers] --+--> [L3 Firewall/Router] --> ACL enforcement
[VLAN 30: Mgmt]   --/

Strengths:

• Reduces broadcast domain size
• Enables ACL enforcement at VLAN boundaries
• Widely supported on all managed switches

Weaknesses:

• VLAN hopping attacks (double tagging, switch spoofing) — mitigated by disabling DTP, pruning VLANs, setting native VLAN to unused ID
• Flat trust within each VLAN — all hosts in VLAN 20 can reach each other
• ACLs on routers are stateless; firewalls add state but increase complexity
• Does not address east-west traffic within a VLAN

Hardening checklist:

• Disable DTP on all access ports (switchport nonegotiate)
• Set native VLAN to an unused VLAN ID (not VLAN 1)
• Prune VLANs from trunks — only permit VLANs that must traverse that trunk
• Enable DHCP snooping, Dynamic ARP Inspection (DAI), IP Source Guard
• Apply port security with MAC address limits

1.3 Micro-Segmentation

Per-workload or per-application segmentation enforced at the hypervisor, host firewall, or overlay network level. Every workload gets its own security policy regardless of network location.

Enforcement points:

• Hypervisor-level: VMware NSX distributed firewall, Nutanix Flow
• Host-level: iptables/nftables, Windows Firewall with Advanced Security, eBPF-based (Cilium)
• Container-level: Kubernetes NetworkPolicy, Calico, Cilium
• Cloud-native: AWS Security Groups, Azure NSGs, GCP firewall rules

Policy model: Default-deny between all workloads. Allow-list only required communication paths. Policy follows the workload, not the network segment.

┌─────────────────────────────────────────────┐
│  Physical Host / Hypervisor                 │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  │
│  │ VM-A     │  │ VM-B     │  │ VM-C     │  │
│  │ Policy:A │  │ Policy:B │  │ Policy:C │  │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘  │
│       │              │              │        │
│  ─────┴──────────────┴──────────────┴─────── │
│  Distributed Firewall (hypervisor vSwitch)   │
│  Per-flow policy enforcement                 │
└─────────────────────────────────────────────┘

Key advantage: East-west traffic between workloads on the same host is inspected and filtered. Traditional firewalls never see this traffic.

1.4 Zero Trust Segmentation

Eliminates implicit trust entirely. Every access request is authenticated, authorized, and encrypted regardless of network location. Network position grants zero privilege.

See Section 5 for full treatment.

Segmentation Model Comparison

Attribute	Flat	VLAN	Micro-Seg	Zero Trust
Blast radius	Entire network	VLAN scope	Single workload	Single session
East-west visibility	None	At VLAN boundary	Per-flow	Per-request
Policy granularity	None	Subnet/port	Workload/process	Identity+context
Lateral movement difficulty	Trivial	Moderate	High	Very high
Operational complexity	Low	Medium	High	Very high
Cloud-native fit	N/A	Poor	Good	Excellent

---

2. Zone Design Patterns

2.1 OWASP Three-Tier Architecture

Reference model from OWASP Network Segmentation Cheat Sheet [CONFIRMED]:

┌──────────────────────────────────────────────────┐
│                    INTERNET                       │
└──────────────┬───────────────────────────────────┘
               │
┌──────────────▼───────────────────────────────────┐
│  FRONTEND ZONE                                    │
│  Load balancers, WAF, reverse proxies, CDN edges  │
│  Web servers, caching layers                       │
└──────────────┬───────────────────────────────────┘
               │ (filtered: HTTP/S only)
┌──────────────▼───────────────────────────────────┐
│  MIDDLEWARE ZONE                                   │
│  Application servers, API gateways                 │
│  Authorization services, message queues            │
│  Analytics engines, stream processors              │
└──────────────┬───────────────────────────────────┘
               │ (filtered: app-specific ports only)
┌──────────────▼───────────────────────────────────┐
│  BACKEND ZONE                                      │
│  Databases (SQL, NoSQL), LDAP/AD                   │
│  HSMs, key management, file storage                │
└──────────────────────────────────────────────────┘

Critical rule: Access between FRONTEND and MIDDLEWARE segments of different information systems is prohibited. Direct database access across service boundaries is blocked. Traffic flows one way: frontend -> middleware -> backend [CONFIRMED — OWASP].

2.2 Enterprise Zone Architecture

Complete enterprise segmentation with dedicated security zones:

                        ┌─────────────┐
                        │  INTERNET   │
                        └──────┬──────┘
                               │
                    ┌──────────▼──────────┐
                    │   PERIMETER FW      │
                    └──────────┬──────────┘
                               │
          ┌────────────────────┼────────────────────┐
          │                    │                     │
    ┌─────▼─────┐      ┌──────▼──────┐      ┌──────▼──────┐
    │DMZ INBOUND│      │DMZ OUTBOUND │      │  VPN TERM   │
    │ Web, Mail │      │ Proxy, NTP  │      │  Remote     │
    └─────┬─────┘      └──────┬──────┘      └──────┬──────┘
          │                    │                     │
          └────────────────────┼─────────────────────┘
                               │
                    ┌──────────▼──────────┐
                    │   INTERNAL FW       │
                    └──────────┬──────────┘
                               │
     ┌──────────┬──────────┬───┴────┬──────────┬──────────┐
     │          │          │        │          │          │
  ┌──▼──┐  ┌───▼──┐  ┌────▼──┐ ┌──▼───┐  ┌──▼───┐  ┌──▼──┐
  │PROD │  │ DEV  │  │ MGMT  │ │  AD  │  │ LOGS │  │GUEST│
  │Apps │  │ Test │  │ OOBM  │ │ DNS  │  │ SIEM │  │WiFi │
  └─────┘  └──────┘  └───────┘ └──────┘  └──────┘  └─────┘

2.3 Zone Definitions and Traffic Rules

DMZ Inbound

• Purpose: Internet-facing services (web servers, mail gateways, API endpoints)
• Inbound: HTTP/S, SMTP from internet; nothing else
• Outbound: Specific ports to middleware zone only; no direct database access
• Hardening: WAF in front, IDS/IPS inline, host-based firewall on every server

DMZ Outbound

• Purpose: Internal services requiring internet access (proxy, NTP, package repos, OCSP/CRL)
• Inbound: From internal zones only, specific ports
• Outbound: Filtered internet access via explicit proxy
• Hardening: Application-layer proxy (not NAT), DNS filtering, TLS inspection

Production Zone

• Purpose: Business-critical application infrastructure
• Inbound: From DMZ inbound (frontend traffic), from middleware tier
• Outbound: To backend databases, to logging zone, to AD for auth
• Hardening: Micro-segmentation between application stacks, no inter-app lateral movement

Development / Test Zone

• Purpose: Non-production workloads, CI/CD pipelines
• Inbound: Developer access from corporate VLAN, CI/CD orchestrator
• Outbound: To package repos (via outbound DMZ proxy), to dev databases only
• Hardening: Must not have any path to production databases. Sanitized data only. Separate AD OU or identity provider.

Management Zone (Out-of-Band Management)

• Purpose: Infrastructure management — IPMI/iLO/iDRAC, switch consoles, firewall management interfaces, jump boxes
• Inbound: From authorized admin workstations only, via jump box / PAM
• Outbound: To managed devices on management interfaces only
• Hardening: Physically or logically separate network. No internet access. MFA on all access. Session recording.

PCI Cardholder Data Environment (CDE)

• Purpose: Systems that store, process, or transmit cardholder data
• Inbound: Strictly from payment application frontends
• Outbound: To payment processors only, via dedicated encrypted channels
• Hardening: PCI DSS requirements (segmentation testing per 11.3.4/11.3.4.1), quarterly ASV scans, annual penetration test must validate segmentation. Flat network within CDE is a finding.

Active Directory / Identity Zone

• Purpose: Domain controllers, ADFS, PKI, RADIUS, identity providers
• Inbound: LDAP/Kerberos/RADIUS from authorized zones
• Outbound: Replication traffic between DCs only; OCSP/CRL publishing
• Hardening: Tier 0 assets — highest protection. Admin access only from dedicated PAWs in management zone. No internet browsing from DCs.

Logging / SIEM Zone

• Purpose: Centralized log collection, SIEM, SOAR
• Inbound: Syslog/Beats/agents from all zones (append-only — sources cannot delete logs)
• Outbound: Threat intel feeds, alerting (email/webhook)
• Hardening: Immutable log storage. Separate credentials. Syslog protocol enforces append-only semantics [CONFIRMED — OWASP].

Guest / IoT Zone

• Purpose: Untrusted devices — visitor WiFi, BYOD, IoT sensors
• Inbound: DHCP, DNS, captive portal only
• Outbound: Internet only (via filtered proxy). Zero access to internal zones.
• Hardening: Client isolation enabled on wireless. MAC filtering is NOT sufficient security (trivially bypassed).

---

3. Firewall Rule Design Methodology

3.1 Core Principles

Deny-all default: Every firewall starts with an implicit deny-all. Rules are additive exceptions, not subtractive restrictions.

Least privilege: Each rule permits the minimum source, destination, port, and protocol required. No any in production rules without documented exception and compensating control.

Unidirectional flow preference: Traffic initiates from less trusted to more trusted zones through application-layer inspection. Backend zones never initiate connections to frontend zones [CONFIRMED — OWASP].

3.2 Rule Structure Template

┌──────┬────────────┬─────────────┬──────┬──────────┬────────┬────────────┐
│ Rule │ Source     │ Destination │ Port │ Protocol │ Action │ Log/Tag    │
├──────┼────────────┼─────────────┼──────┼──────────┼────────┼────────────┤
│ 0001 │ 10.1.0/24  │ 10.2.0.5    │ 443  │ TCP      │ ALLOW  │ app-to-api │
│ 0002 │ 10.2.0.5   │ 10.3.0.10   │ 5432 │ TCP      │ ALLOW  │ api-to-db  │
│ 9998 │ any        │ any         │ any  │ any      │ DENY   │ default-dn │
│ 9999 │ (cleanup)  │             │      │          │ LOG+DN │ cleanup    │
└──────┴────────────┴─────────────┴──────┴──────────┴────────┴────────────┘

3.3 Rule Review Methodology

Quarterly review cycle (minimum):

1. Usage audit: Identify rules with zero hits in 90 days — candidates for removal
2. Shadow rule detection: Rules that are fully covered by a preceding broader rule — dead weight, remove
3. Overly permissive rules: Any rule with source: any, destination: any, or port: any — must have documented business justification and compensating control
4. Temporary rules: Must have expiration dates and responsible owner. Automated cleanup via ticket integration.
5. Compliance validation: Map rules against zone policy matrix. Any rule allowing traffic contradicting zone definitions is a finding.

Rule lifecycle:

Request --> Peer Review --> Risk Assessment --> Implement --> Validate --> Monitor --> Review --> Retire

3.4 PAN-OS IronSkillet Baseline Approach

Palo Alto Networks IronSkillet provides day-one hardened configurations [CONFIRMED]:

• Security profiles on every rule: Anti-spyware, anti-virus, vulnerability protection, URL filtering, file blocking, WildFire analysis
• Zone protection profiles: Flood protection (SYN, UDP, ICMP), reconnaissance protection (port scans, host sweeps), packet-based attack protection
• Decryption policy: TLS inspection for outbound traffic with certificate management
• Log forwarding on all rules: Every rule logs to SIEM — no silent drops
• Strict application identification: App-ID enforcement rather than port-based rules where possible

Key hardening settings from IronSkillet:

• Block quic protocol to force TLS inspection via standard HTTPS
• Enable DNS Security subscription for DNS-layer threat prevention
• Apply vulnerability protection profile in strict mode
• Enable WildFire inline ML for zero-day detection
• Disable LLMNR/NetBIOS resolution across zone boundaries

3.5 Rule Design Anti-Patterns

Anti-Pattern	Risk	Fix
any any any allow	Complete bypass of segmentation	Remove. Decompose into specific rules.
Port-only rules (no app inspection)	Tunneling through allowed ports	Use application-layer inspection (App-ID, L7 proxy)
No logging on deny rules	Blind to attack traffic	Log all denies; feed to SIEM for threat hunting
Bidirectional rules where unidirectional suffices	Expanded attack surface	Enforce stateful inspection; allow only initiator direction
Shared service accounts in rules	No attribution	Per-application service accounts with individual rules
IP-based rules for dynamic workloads	Rule drift, stale entries	Tag-based / identity-based policies

---

4. East-West Traffic Monitoring

4.1 The Visibility Problem

Traditional perimeter firewalls see only north-south traffic (in/out of the network). In modern environments, 80%+ of traffic is east-west (server-to-server, container-to-container). This is where lateral movement lives (T1021, T1570, T1210).

4.2 Monitoring Architecture

┌─────────────────────────────────────────────────────┐
│  Network TAP / SPAN                                  │
│  Mirror east-west traffic to monitoring infrastructure│
└──────────┬──────────────────────────────────────────┘
           │
     ┌─────▼──────┐    ┌──────────────┐    ┌──────────┐
     │  Network    │    │   Flow       │    │  SIEM    │
     │  IDS/IPS    │───>│   Analytics  │───>│  (HELK,  │
     │  (Suricata, │    │   (NetFlow,  │    │  Elastic,│
     │   Zeek)     │    │   sFlow,     │    │  Splunk) │
     └────────────┘    │   IPFIX)     │    └──────────┘
                        └──────────────┘

4.3 Detection Opportunities for Lateral Movement

Network-layer indicators:

• SMB traffic between workstations (not to file servers) — T1021.002
• RDP from server to server (unexpected) — T1021.001
• WinRM/PSRemoting between non-admin hosts — T1021.006
• SSH from non-admin sources to infrastructure — T1021.004
• DNS queries to internal hosts from unexpected sources (internal recon) — T1018
• ARP scanning patterns — T1016, T1046
• ICMP sweep patterns — T1046

Application-layer indicators:

• Kerberoasting traffic patterns (high volume TGS requests) — T1558.003
• LDAP enumeration from non-DC sources — T1087.002
• DCSync replication traffic from non-DC IPs — T1003.006
• NTLM relay patterns — T1557.001
• Unusual database query patterns from application servers — T1213

Behavioral indicators:

• New communication paths between hosts that never previously communicated
• Volume anomalies on established paths
• Off-hours traffic between production systems
• Long-duration connections (C2 beaconing) — T1071

4.4 Tooling

Tool	Purpose	Deployment
Zeek (Bro)	Network protocol analysis, connection logging	TAP/SPAN, inline
Suricata	IDS/IPS with protocol detection	TAP/SPAN, inline
HELK	Hunting ELK stack with analytics	Central collection [CONFIRMED]
Flare	Network behavioral analytics framework	Central analysis [CONFIRMED]
Sigma	Generic SIEM detection rule format	Cross-platform [CONFIRMED]
Arkime (Moloch)	Full packet capture and indexed search	TAP/SPAN
RITA	Beacon detection, DNS tunneling detection	Zeek log analysis
Stenographer	High-speed packet capture to disk	TAP/SPAN

4.5 Micro-Segmentation Monitoring Integration

When micro-segmentation is deployed, the enforcement point itself becomes a monitoring source:

• VMware NSX: Flow monitoring, micro-segmentation policy hit counts, denied flow logs
• Cilium (eBPF): Hubble flow visibility, DNS-aware policy logs, per-pod network metrics
• Calico: Flow logs, DNS policy logs, network sets audit
• Cloud-native: VPC Flow Logs (AWS), NSG Flow Logs (Azure), VPC Flow Logs (GCP)

Feed all enforcement point logs to SIEM. Alert on denied flows that indicate lateral movement attempts.

---

5. Zero Trust Architecture

5.1 NIST SP 800-207 Core Tenets

[CONFIRMED — NIST SP 800-207]:

1. All data sources and computing services are considered resources — not just traditional servers
2. All communication is secured regardless of network location — internal traffic gets the same encryption as external
3. Access to individual enterprise resources is granted on a per-session basis — no persistent trust tokens
4. Access is determined by dynamic policy — including client identity, application, observable state of the requesting asset, behavioral attributes, environmental attributes
5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets — no assumed trust based on ownership
6. All resource authentication and authorization are dynamic and strictly enforced before access is allowed — continuous verification
7. 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 — continuous improvement loop

5.2 Logical Components

[CONFIRMED — NIST SP 800-207]:

┌─────────────────────────────────────────────────────────┐
│                    CONTROL PLANE                         │
│                                                          │
│  ┌──────────────┐     ┌──────────────────┐              │
│  │ Policy Engine│────>│ Policy           │              │
│  │ (PE)         │     │ Administrator    │              │
│  │              │<────│ (PA)             │              │
│  └──────────────┘     └────────┬─────────┘              │
│         ▲                      │                         │
│         │ Signal inputs:       │ Policy decisions:       │
│         │ - CDM system         │ - Grant / Deny          │
│         │ - Threat intel       │ - Session parameters    │
│         │ - Activity logs      │ - Encryption level      │
│         │ - Compliance         │                         │
│         │ - Data classification│                         │
└─────────┼──────────────────────┼─────────────────────────┘
          │                      │
┌─────────┼──────────────────────┼─────────────────────────┐
│         │       DATA PLANE     │                         │
│         │                      ▼                         │
│  ┌──────┴───────────────────────────────┐               │
│  │   Policy Enforcement Point (PEP)     │               │
│  │   - Authenticates subject            │               │
│  │   - Enforces PA decision             │               │
│  │   - Encrypts session                 │               │
│  └──────────────┬───────────────────────┘               │
│                 │                                         │
│          ┌──────▼──────┐                                 │
│          │  Resource   │                                 │
│          │  (App/Data) │                                 │
│          └─────────────┘                                 │
└─────────────────────────────────────────────────────────┘

Policy Engine (PE): The brain. Consumes signals from identity stores, device health (CDM/EDR), threat intelligence, activity logs, data classification. Produces access decisions.

Policy Administrator (PA): The executor. Takes PE decisions and configures the data plane accordingly. Manages session tokens, authentication contexts, and policy distribution.

Policy Enforcement Point (PEP): The gate. Every resource access traverses a PEP. It authenticates the subject, validates the PA decision, establishes the encrypted session, and enforces attributes (time limits, data restrictions).

5.3 Trust Algorithm Inputs

[CONFIRMED — NIST SP 800-207]:

Signal	Source	Weight
User identity + MFA status	IdP, FIDO2 attestation	High
Device health / posture	EDR, MDM, CDM	High
Device registration status	Asset inventory	Medium
Network location	IP geolocation, network zone	Low (informational)
Request context	Time, frequency, resource sensitivity	Medium
Behavioral analytics	UEBA, session patterns	Medium
Threat intelligence	External feeds, internal IOC matches	Variable
Data classification	DLP, data catalog	High for sensitive resources

5.4 Deployment Architectures

Model 1: Agent + Gateway (Device-Centric)

• Agent on endpoint communicates with gateway in front of resource
• Agent provides device health attestation
• Gateway enforces PE/PA decisions
• Best for: Managed device fleets accessing on-prem or IaaS resources

Model 2: Enclave-Based

• Resources grouped into enclaves (micro-perimeters)
• Gateway at enclave boundary
• Internal enclave traffic may have relaxed controls
• Best for: Phased migration from traditional segmentation; legacy environments

Model 3: Resource Portal

• Central portal (web-based) brokers access to all resources
• No agent required — browser-based access
• Best for: BYOD, contractor access, SaaS-first organizations

Model 4: Sandboxing

• Untrusted applications isolated in contained environments
• Resource access mediated through sandbox boundary
• Best for: High-security environments, malware analysis, untrusted code execution

5.5 ZTA Variations

[CONFIRMED — NIST SP 800-207]:

Enhanced Identity Governance: Identity is the primary control plane. Strong MFA (FIDO2), continuous authentication, PAM for privileged access, just-in-time access provisioning.

Micro-Segmentation: Network-centric zero trust. Every workload boundary is a trust boundary. See Section 1.3.

Software-Defined Perimeter (SDP): Resources are invisible until authenticated. "Dark cloud" — no DNS resolution, no port response until authorization. See Section 6.

5.6 UK NCSC Eight Principles

[CONFIRMED — UK NCSC]:

#	Principle	Implementation Requirement
1	Know your architecture	Complete asset inventory, data flow mapping, dependency graphing
2	Know your user/service/device identities	Unique cryptographic identity per entity; no shared credentials
3	Assess user behavior and service/device health	Continuous posture assessment feeding policy engine
4	Use policies to authorize requests	Central policy engine; context-aware; flexible per resource
5	Authenticate and authorize everywhere	Every connection validated; location + health + identity + risk
6	Monitor users, devices, and services	Entity-centric monitoring linked to policy validation
7	Don't trust any network, including your own	All transit encrypted; no reliance on network position for trust
8	Choose services designed for zero trust	Standards-based; native ZT support; avoid retrofitting legacy

5.7 Google BeyondCorp Model

[CONFIRMED — Google Chrome Enterprise Premium]:

Core architecture shift: Eliminate VPN. All access is through identity-aware proxies. Network location provides zero trust uplift.

Context-aware access signals:

• User identity and group membership
• Device management status (enterprise-managed, personal, mobile)
• Device posture (patch level, encryption status, screen lock)
• Third-party signals: CrowdStrike Falcon, Check Point, Lookout, Tanium, VMware
• Geographic location and IP reputation
• Time and date restrictions
• Login credential strength (MFA method quality)

Identity-Aware Proxy (IAP): Sits in front of every application. Authenticates user, evaluates access level (combination of context signals), permits or denies per-request. Application never directly exposed to network.

Key lesson: Google runs BeyondCorp across hybrid infrastructure — GCP, AWS, Azure, on-premises, and SaaS. Zero trust is not cloud-specific.

5.8 Threats to Zero Trust

[CONFIRMED — NIST SP 800-207]:

Threat	Description	Mitigation
PE/PA compromise	Attacker controls the policy brain — game over	Harden PE/PA as Tier 0 assets; multi-party approval for policy changes; immutable audit logs
Stolen credentials + device	Passes identity and posture checks	Phishing-resistant MFA (FIDO2); behavioral analytics; continuous auth
Insider threat	Legitimate access abused	UEBA; DLP; just-in-time access; session recording for sensitive resources
Visibility gaps	Policy decisions made on incomplete data	Comprehensive telemetry; fail-closed on missing signals
DoS on PE/PA	Decision plane unavailable = no access	HA deployment; cached last-known-good decisions with short TTL; fail-closed vs. fail-open is a design decision
Vendor lock-in / single point of failure	PE/PA vendor compromise	Multi-vendor strategy; open standards (OIDC, SAML, SCIM)

---

6. Software-Defined Perimeter (SDP)

6.1 Architecture

Based on Cloud Security Alliance SDP specification:

┌──────────┐         ┌──────────────┐        ┌──────────┐
│ Initiating│   1.    │  SDP         │   2.   │ Accepting│
│ Host (IH) │──auth──>│  Controller  │──auth──>│ Host (AH)│
│           │         │              │         │          │
│ Agent +   │         │ - AuthN/AuthZ│         │ Gateway  │
│ mTLS keys │         │ - Device     │         │ + hidden │
│           │         │   validation │         │ services │
│           │   3.    │ - Policy     │         │          │
│           │<──mTLS──┼──────────────┼────────>│          │
│           │  tunnel │              │         │          │
└──────────┘         └──────────────┘        └──────────┘

Sequence:

1. Initiating Host authenticates to SDP Controller (device cert + user credential + MFA)
2. Controller validates identity, device posture, and policy; instructs Accepting Host to expect connection
3. Mutual TLS tunnel established directly between IH and AH
4. Accepting Host only responds to pre-authorized connections — invisible to all other network traffic ("dark cloud")

6.2 Key Properties

• Single Packet Authorization (SPA): AH drops all packets unless preceded by a valid SPA packet. Port scanning reveals nothing.
• Pre-authentication before connection: Network access only after identity + device + policy validation
• Mutual TLS: Both sides authenticate — prevents MitM
• No visible attack surface: Resources have no DNS entries, no open ports until authorized

6.3 SDP vs. VPN

Attribute	Traditional VPN	SDP
Network access	Full subnet after connect	Single resource per session
Visibility	VPN concentrator visible, attackable	Nothing visible until SPA
Lateral movement	Possible within VPN subnet	Impossible — no network access beyond authorized resource
Device posture	Rarely checked post-connect	Continuously evaluated
Scalability	Concentrator bottleneck	Distributed enforcement

---

7. Service Mesh Security

7.1 Why Service Mesh Matters for Segmentation

In Kubernetes and microservice architectures, traditional network segmentation is insufficient. Services are ephemeral, IP addresses change constantly, and east-west traffic volume is massive. Service mesh provides L7 segmentation at the application layer.

7.2 Istio Security Architecture

┌─────────────────────────────────────────────────┐
│  CONTROL PLANE (istiod)                          │
│  ┌─────────┐  ┌──────────────┐  ┌────────────┐ │
│  │  Pilot   │  │ Citadel (CA) │  │  Galley    │ │
│  │ (config) │  │ (mTLS certs) │  │ (policy)   │ │
│  └─────────┘  └──────────────┘  └────────────┘ │
└────────────────────┬────────────────────────────┘
                     │ cert provisioning + policy push
     ┌───────────────┼───────────────────┐
     │               │                   │
┌────▼────┐    ┌─────▼────┐    ┌────────▼──┐
│ Envoy   │    │  Envoy   │    │  Envoy    │
│ Sidecar │◄──►│  Sidecar │◄──►│  Sidecar  │
│ (Svc A) │mTLS│  (Svc B) │mTLS│  (Svc C)  │
└─────────┘    └──────────┘    └───────────┘

mTLS everywhere: Citadel (now integrated into istiod) provisions short-lived certificates to every sidecar proxy. All service-to-service communication is mutually authenticated and encrypted. No plaintext east-west traffic.

Authorization policies:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-frontend-to-api
  namespace: production
spec:
  selector:
    matchLabels:
      app: api-server
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/production/sa/frontend"]
    to:
    - operation:
        methods: ["GET", "POST"]
        paths: ["/api/v1/*"]

PEER authentication (mTLS mode):

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: strict-mtls
  namespace: production
spec:
  mtls:
    mode: STRICT  # No plaintext allowed

7.3 Linkerd Security Model

• Automatic mTLS: Enabled by default for all meshed services (unlike Istio which requires configuration)
• Identity: Uses Kubernetes ServiceAccounts as identity basis; issues short-lived TLS certificates
• Authorization policy: Server and ServerAuthorization resources control which identities can reach which services
• Advantages over Istio for segmentation: Simpler operational model, lower resource overhead, mTLS-by-default reduces misconfiguration risk

7.4 Service Mesh Segmentation Patterns

Pattern	Implementation	Use Case
Namespace isolation	Default-deny AuthorizationPolicy per namespace	Multi-tenant clusters
Service-to-service allow-list	Explicit principal-based rules	Micro-segmentation at L7
Path-based access control	Operation rules on HTTP paths/methods	API-level segmentation
External traffic control	Egress gateways with policy	Controlling outbound from mesh
Multi-cluster segmentation	Federated mesh with trust domains	Cross-cluster zero trust

---

8. Network Access Control / 802.1X

8.1 Architecture

┌──────────┐   EAP   ┌──────────────┐  RADIUS  ┌──────────┐
│ Supplicant│──────>│ Authenticator  │────────>│  Auth     │
│ (endpoint)│       │ (switch/AP)    │         │  Server   │
│           │       │                │         │ (RADIUS)  │
│ 802.1X    │       │ Port-based     │         │ + CA      │
│ client    │       │ access control │         │ + Policy  │
└──────────┘       └──────────────┘         └──────────┘

8.2 EAP Methods (Strongest to Weakest)

Method	Security	Credential	Use Case
EAP-TLS	Strongest — mutual certificate auth	Client + server certs	Managed devices with PKI
EAP-TEAP	Strong — tunnel + cert/password	Server cert + client cert or password	Transition to cert-based
PEAP (EAP-MSCHAPv2)	Moderate — server cert only	Server cert + username/password	Legacy AD environments
EAP-TTLS	Moderate — similar to PEAP	Server cert + inner method	Non-Windows environments
MAB (MAC bypass)	Weak — MAC only	MAC address	IoT, printers, phones (with compensating controls)

8.3 Dynamic VLAN Assignment

RADIUS returns VLAN assignment attributes based on authentication result:

# RADIUS response attributes for dynamic VLAN
Tunnel-Type = VLAN
Tunnel-Medium-Type = IEEE-802
Tunnel-Private-Group-ID = 20    # VLAN 20 for authenticated corporate devices

Policy matrix:

• Corporate device + valid cert → Production VLAN
• Corporate device + failed posture → Remediation VLAN
• BYOD + valid user auth → BYOD VLAN (internet only)
• Unknown device + MAB → IoT VLAN (heavily restricted)
• Failed auth → Blackhole VLAN (no access)

8.4 Posture Assessment Integration

NAC systems (Cisco ISE, Aruba ClearPass, ForeScout, PacketFence) can evaluate endpoint health before granting access:

• OS patch level current?
• EDR agent installed and reporting?
• Disk encryption enabled?
• Host firewall active?
• Not on IOC blocklist?

Failed posture → quarantine VLAN with access only to remediation servers (WSUS, patch repo, EDR installer).

---

9. Cloud VPC Design

9.1 AWS VPC Architecture

┌─────────────────────────────────────────────────────────┐
│  AWS Account (Production)                                │
│                                                          │
│  ┌─────────────────────────────────────────────────┐    │
│  │  VPC: 10.0.0.0/16                                │    │
│  │                                                   │    │
│  │  ┌──────────────┐  ┌──────────────┐              │    │
│  │  │Public Subnet │  │Public Subnet │  AZ-a, AZ-b  │    │
│  │  │10.0.1.0/24   │  │10.0.2.0/24   │              │    │
│  │  │ ALB, NAT GW  │  │ ALB, NAT GW  │              │    │
│  │  └──────┬───────┘  └──────┬───────┘              │    │
│  │         │                  │                       │    │
│  │  ┌──────▼───────┐  ┌──────▼───────┐              │    │
│  │  │Private Sub   │  │Private Sub   │  App Tier     │    │
│  │  │10.0.10.0/24  │  │10.0.11.0/24  │              │    │
│  │  │ EC2/ECS/EKS  │  │ EC2/ECS/EKS  │              │    │
│  │  └──────┬───────┘  └──────┬───────┘              │    │
│  │         │                  │                       │    │
│  │  ┌──────▼───────┐  ┌──────▼───────┐              │    │
│  │  │Isolated Sub  │  │Isolated Sub  │  Data Tier    │    │
│  │  │10.0.20.0/24  │  │10.0.21.0/24  │              │    │
│  │  │ RDS, ElastiC │  │ RDS, ElastiC │              │    │
│  │  └──────────────┘  └──────────────┘              │    │
│  └─────────────────────────────────────────────────┘    │
│                                                          │
│  Security Groups (stateful, per-ENI):                    │
│  - ALB SG: 443 from 0.0.0.0/0                           │
│  - App SG: 8080 from ALB SG only                        │
│  - DB SG:  5432 from App SG only                        │
│                                                          │
│  NACLs (stateless, per-subnet):                          │
│  - Additional subnet-level filtering                     │
│  - Deny rules for known-bad ranges                       │
└─────────────────────────────────────────────────────────┘

Key AWS segmentation controls:

• Security Groups: Stateful, reference other SGs by ID (not IP) — self-healing when IPs change
• NACLs: Stateless, subnet-level, numbered rules with explicit deny capability
• VPC Flow Logs: Enable on all VPCs, all ENIs; send to S3 + CloudWatch for analysis
• Transit Gateway: Hub-spoke for multi-VPC; attach route tables for inter-VPC segmentation
• PrivateLink: Access AWS services without traversing internet or VPC peering
• AWS Network Firewall: Stateful inspection for VPC traffic with Suricata-compatible rules

Multi-account strategy (AWS Organizations):

• Separate accounts per environment (prod, staging, dev)
• Separate accounts per workload domain
• Networking account owns Transit Gateway
• Security account owns GuardDuty, SecurityHub, centralized logging
• SCPs enforce guardrails across all accounts

9.2 Azure VNet Architecture

Key Azure segmentation controls:

• NSGs: Applied to subnets or NICs; stateful; priority-ordered rules
• ASGs (Application Security Groups): Group VMs by application role; reference in NSG rules instead of IPs
• Azure Firewall: Central managed firewall with FQDN filtering, threat intelligence, TLS inspection
• Azure Private Link: Private endpoint for PaaS services within VNet
• VNet peering: Non-transitive by default — explicit route control
• NSG Flow Logs: Enable on all NSGs; send to Log Analytics workspace
• Azure DDoS Protection: Standard tier for all production VNets

Hub-spoke topology:

         ┌──────────┐
         │  Hub VNet │
         │ Azure FW  │
         │ VPN GW    │
         │ Bastion   │
         └─────┬─────┘
    ┌──────────┼──────────┐
    │          │          │
┌───▼──┐  ┌───▼──┐  ┌───▼──┐
│Spoke1│  │Spoke2│  │Spoke3│
│ Prod │  │ Dev  │  │ Mgmt │
└──────┘  └──────┘  └──────┘

9.3 GCP VPC Architecture

Key GCP segmentation controls:

• VPC is global: Subnets are regional but VPC spans regions — different mental model from AWS/Azure
• Firewall rules: Applied at VPC level; priority-ordered; target by service account or network tag
• Hierarchical firewall policies: Organization → Folder → Project → VPC — inherited enforcement
• Private Google Access: Access Google APIs without external IP
• Shared VPC: Central networking project; service projects attach — clean separation of duties
• VPC Service Controls: Creates security perimeters around GCP services to prevent data exfiltration
• VPC Flow Logs: Per-subnet; configurable sampling rate

9.4 Cloud Segmentation Anti-Patterns

Anti-Pattern	Risk	Fix
Single VPC for all environments	Blast radius = everything	Separate VPC/VNet per environment; use peering with explicit routes
Security group 0.0.0.0/0 on non-ALB resources	Internet exposure	Reference SGs/ASGs instead; no direct internet access for app/data tier
Disabled flow logs	No visibility into lateral movement	Enable flow logs on all VPCs/VNets; send to SIEM
VPC peering without route filtering	Transitive trust	Use Transit Gateway/Azure Firewall for controlled inter-VPC routing
PaaS services on public endpoints	Data exfiltration risk	PrivateLink/Private Endpoint for all data services
Single account/subscription	No blast radius containment	Multi-account/subscription strategy with centralized governance

---

10. SD-WAN Security

10.1 Architecture

SD-WAN replaces traditional MPLS with encrypted overlays across commodity internet and LTE/5G links. Security implications are significant.

┌──────────┐    IPsec/WireGuard    ┌──────────┐
│ Branch    │◄────────────────────►│ Hub /    │
│ SD-WAN   │    over internet      │ Data Ctr │
│ Edge      │                      │ SD-WAN   │
│           │    IPsec/WireGuard    │ Edge     │
│           │◄────────────────────►│          │
│           │    over LTE/5G       │          │
└──────────┘                      └──────────┘
     │                                  │
     │  Local breakout                  │  Central breakout
     │  (direct-to-cloud)               │  (backhauled)
     ▼                                  ▼
  ┌──────┐                         ┌──────────┐
  │ SaaS │                         │ Security │
  │ Apps │                         │ Stack    │
  └──────┘                         └──────────┘

10.2 Security Considerations

Overlay encryption:

• All SD-WAN tunnels must use strong encryption (AES-256-GCM minimum)
• Perfect Forward Secrecy (PFS) enabled
• Certificate-based authentication between edges (not PSK at scale)
• Regular key rotation (< 24 hours)

Local internet breakout risks:

• Branch traffic to SaaS bypasses central security stack
• Requires NGFW or SASE at branch, or cloud-based security (Zscaler, Netskope, Palo Alto Prisma)
• DNS filtering, TLS inspection, and threat prevention must follow the traffic

Segmentation within SD-WAN:

• VRF-lite or VPN segmentation between zones (guest, corporate, PCI, IoT)
• End-to-end segmentation from branch to data center
• Each segment gets independent routing table and encryption context
• Application-aware routing must not bypass security inspection

Zero trust integration:

• SD-WAN transport is untrusted by default
• SASE (Secure Access Service Edge) = SD-WAN + zero trust network access + CASB + SWG
• Identity-based policy at the SD-WAN edge
• Continuous posture assessment for branch devices

10.3 SD-WAN Hardening Checklist

• Disable management interface on WAN-facing ports
• Certificate-based edge authentication (not PSK)
• AES-256-GCM + PFS for all tunnels
• Segmented VRFs for different security zones
• NGFW or SASE inspection for local breakout traffic
• Centralized logging of all SD-WAN events to SIEM
• Firmware patching cadence (SD-WAN edge appliances are high-value targets)
• DDoS mitigation on internet circuits
• Mutual authentication on orchestrator API (prevent rogue edge enrollment)

---

11. IoT/OT Network Isolation

11.1 The Problem

IoT and OT devices typically:

• Run outdated/unpatachable firmware
• Do not support 802.1X or modern authentication
• Use insecure protocols (Telnet, HTTP, Modbus, BACnet, DNP3)
• Cannot run endpoint agents
• Have long lifespans (10-20 years for OT)
• Are physically accessible (cameras, sensors, PLCs)

11.2 Purdue Model for OT (IEC 62443)

┌─────────────────────────────────────────┐
│ Level 5: Enterprise Network             │
│ (ERP, email, internet)                  │
├─────────── DMZ ─────────────────────────┤
│ Level 4: Site Business Planning          │
│ (Historian mirror, IT/OT data exchange) │
├─────────── FIREWALL ────────────────────┤
│ Level 3: Site Operations                 │
│ (Historian, SCADA server, AV server)    │
├─────────────────────────────────────────┤
│ Level 2: Area Supervisory Control       │
│ (HMI, engineering workstations)         │
├─────────────────────────────────────────┤
│ Level 1: Basic Control                   │
│ (PLCs, RTUs, controllers)               │
├─────────────────────────────────────────┤
│ Level 0: Physical Process               │
│ (Sensors, actuators, field devices)     │
└─────────────────────────────────────────┘

Critical rules:

• Traffic flows ONLY between adjacent levels
• IT/OT boundary (Level 4/3) has a dedicated DMZ — no direct IT-to-OT connectivity
• Level 0-2 has NO internet access — ever
• Jump box in OT DMZ for remote administration (recorded, MFA, time-limited)
• One-way data diode for historian data from OT → IT where possible

11.3 IoT Isolation Patterns

Pattern 1: Dedicated IoT VLAN with MAB

IoT Device → Switch Port (MAB) → RADIUS → IoT VLAN
IoT VLAN rules:
  - Permit: IoT device → IoT management server (specific ports)
  - Permit: IoT device → cloud endpoint (specific FQDN via DNS proxy)
  - Deny: IoT VLAN → all internal VLANs
  - Deny: all internal VLANs → IoT VLAN (except management)

Pattern 2: IoT Gateway / Broker

IoT Devices → [Isolated VLAN] → IoT Gateway/Broker → [Production VLAN]
                                 (protocol translation,
                                  authentication,
                                  data validation)

Pattern 3: Micro-Segmentation per Device Type

Camera VLAN:    cameras → NVR only
HVAC VLAN:      BMS controllers → BMS server only
Badge VLAN:     access control → access control server only
Medical VLAN:   devices → clinical system only (HIPAA)

11.4 IoT/OT Monitoring

• Network behavior analysis: Baseline normal communication patterns; alert on deviations (new destinations, new protocols, volume changes)
• Passive OT protocol inspection: Zeek with OT protocol parsers (Modbus, DNP3, S7comm, EtherNet/IP)
• Asset discovery: Passive fingerprinting (avoid active scanning in OT — can crash PLCs)
• Dedicated OT SIEM: Dragos, Claroty, Nozomi Networks for OT-specific detection
• Network TAP, not SPAN: Use hardware TAPs in OT networks — SPAN can introduce jitter

---

12. Detection & Monitoring Stack

12.1 Comprehensive Monitoring Architecture

┌─────────────────────────────────────────────────────────────┐
│                    DATA SOURCES                              │
│                                                              │
│  Firewall Logs ─┐                                           │
│  Flow Logs     ─┤                                           │
│  DNS Logs      ─┤    ┌──────────────┐    ┌──────────────┐  │
│  Proxy Logs    ─┼───>│  Log         │───>│  SIEM        │  │
│  IDS/IPS       ─┤    │  Pipeline    │    │  (Elastic,   │  │
│  Auth Logs     ─┤    │  (Logstash,  │    │   Splunk,    │  │
│  EDR Telemetry ─┤    │   Cribl,     │    │   Sentinel)  │  │
│  Cloud Logs    ─┤    │   Fluentd)   │    │              │  │
│  Service Mesh  ─┤    └──────────────┘    └──────┬───────┘  │
│  NAC/RADIUS    ─┘                                │          │
│                                            ┌─────▼──────┐   │
│                                            │  SOAR      │   │
│                                            │  Playbooks │   │
│                                            └────────────┘   │
└─────────────────────────────────────────────────────────────┘

12.2 Sigma Rules for Segmentation Monitoring

Detect cross-zone lateral movement:

title: Cross-Zone SMB Connection from Non-Admin Source
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
status: experimental
description: Detects SMB connections originating from non-administrative
  network zones targeting servers in production or management zones
logsource:
  category: network_connection
  product: firewall
detection:
  selection:
    dst_port:
      - 445
      - 139
    src_zone:
      - 'user_workstation'
      - 'guest'
      - 'iot'
    dst_zone:
      - 'production'
      - 'management'
      - 'ad_services'
  condition: selection
falsepositives:
  - Authorized IT admin from workstation VLAN using designated jump box
    (should be excluded by src_ip allowlist)
level: high
tags:
  - attack.t1021.002
  - attack.lateral_movement

Detect firewall rule bypass attempts:

title: High Volume Firewall Denies from Single Source
id: b2c3d4e5-f6a7-8901-bcde-f12345678901
status: experimental
description: Detects a single source generating excessive denied connections,
  indicating network reconnaissance or misconfigured lateral movement tool
logsource:
  category: network_connection
  product: firewall
detection:
  selection:
    action: 'denied'
  condition: selection | count(src_ip) by src_ip > 100
  timeframe: 5m
falsepositives:
  - Misconfigured monitoring system scanning across zones
  - Vulnerability scanner without proper source allowlisting
level: medium
tags:
  - attack.t1046
  - attack.discovery

12.3 MITRE ATT&CK Coverage for Segmented Networks

Technique	Detection in Segmented Network
T1046 Network Service Scanning	Firewall deny logs at zone boundaries; IDS signature
T1021 Remote Services	Cross-zone connection logs; unexpected protocol use
T1570 Lateral Tool Transfer	File transfer protocols crossing zone boundaries
T1071 Application Layer Protocol	DNS/HTTP anomalies at zone egress; beaconing detection (RITA)
T1557 ARP/LLMNR Poisoning	Contained to VLAN; detected by DAI / DHCP snooping
T1210 Exploitation of Remote Services	IDS/IPS at zone boundary; vulnerability protection profiles
T1558 Steal or Forge Kerberos Tickets	Kerberos traffic from non-DC sources crossing AD zone boundary
T1003.006 DCSync	Replication traffic from non-DC IP addresses

---

13. Migration Playbook

13.1 From Flat to Segmented (Phased)

Phase 1: Visibility (Weeks 1-4)

• Deploy network TAPs / SPAN at critical points
• Enable flow logging (NetFlow/sFlow/IPFIX)
• Map all communication paths — build dependency matrix
• Identify crown jewels (databases, AD, key management)

Phase 2: Quick Wins (Weeks 5-8)

• Isolate management plane (IPMI, switch consoles, firewall mgmt)
• Segment guest/IoT from corporate
• Deploy 802.1X for wired access (start with monitor mode, not enforcement)
• Enable VPC Flow Logs / NSG Flow Logs in cloud

Phase 3: Zone Boundaries (Weeks 9-16)

• Implement VLAN segmentation per zone design
• Deploy internal firewalls between zones
• Default-deny between zones; allow-list discovered legitimate flows
• Parallel-run: log violations but do not block (learning mode)

Phase 4: Enforcement (Weeks 17-24)

• Switch from learning mode to enforcement
• Harden firewall rules — remove overly permissive rules
• Deploy IDS/IPS at zone boundaries
• Implement micro-segmentation for high-value assets

Phase 5: Zero Trust Overlay (Ongoing)

• Deploy identity-aware access for applications
• Implement continuous posture assessment
• Add behavioral analytics (UEBA)
• Replace VPN with SDP/ZTNA

13.2 Key Risk: Breaking Production

The number one reason segmentation projects fail is breaking application connectivity.

Mitigation:

• Always deploy in monitor/learning mode first
• Build application dependency maps before enforcement
• Use application owners as approvers for zone policies
• Have rollback procedures for every enforcement change
• Test in dev/staging environment first (if segmentation mirrors production)

---

14. Reference Controls Mapping

CIS Controls v8 — Network Segmentation

Control	Safeguard	Description	IG
3.12	Segment Data Processing and Storage	Isolate processing based on data sensitivity	IG2+
4.1	Establish Secure Configuration Process	Standard firewall configurations	IG1+
4.2	Establish Secure Configuration for Network Infra	Hardened switch/router/FW configs	IG1+
4.4	Implement and Manage a Firewall on Servers	Host-based firewall on all servers	IG1+
4.5	Implement and Manage a Firewall on End-User Devices	Host-based firewall on endpoints	IG1+
9.2	Use DNS Filtering Services	Block known malicious domains	IG1+
9.3	Maintain and Enforce Network-Based URL Filtering	Proxy-based URL filtering	IG2+
12.2	Establish and Maintain a Secure Network Architecture	Documented network segmentation	IG2+
12.3	Securely Manage Network Infrastructure	ACLs, change management	IG2+
12.4	Establish and Maintain Architecture Diagrams	Current network diagrams	IG2+
12.5	Centralize Network Authentication, Authorization, and Auditing	RADIUS/TACACS+ for network devices	IG2+
12.6	Use of Secure Network Management and Communication Protocols	SSH, HTTPS, SNMPv3 for management	IG2+
12.7	Ensure Remote Devices Utilize a VPN and are Connecting to Enterprise AAA	Remote access controls	IG2+
12.8	Establish and Maintain Dedicated Computing Resources for Admin Work	PAWs, jump boxes	IG3
13.1	Centralize Security Event Alerting	SIEM for all zones	IG1+
13.3	Deploy a Network Intrusion Detection Solution	IDS at zone boundaries	IG2+
13.4	Perform Traffic Filtering Between Network Segments	ACLs/firewalls between segments	IG2+

NIST 800-53 Mapping

Control	Description	Relevance
SC-7	Boundary Protection	Firewall rules, zone design
SC-7(5)	Deny by Default / Allow by Exception	Default-deny rule methodology
AC-4	Information Flow Enforcement	Cross-zone traffic filtering
AC-4(21)	Physical/Logical Separation of Information Flows	OT/IT separation
SI-4	System Monitoring	East-west traffic monitoring
CA-3	Information Exchange	Inter-zone communication agreements
SC-8	Transmission Confidentiality and Integrity	mTLS, VPN encryption

PCI DSS 4.0 Mapping

Requirement	Description	Segmentation Relevance
1.2	Network Security Controls	Firewall between CDE and all other zones
1.3	Network Access to/from CDE is Restricted	Explicit allow-list only
1.4	Network Connections Between Trusted and Untrusted Networks Controlled	DMZ architecture
11.4.1	Penetration Testing — Segmentation Verification	Must validate segmentation controls annually
11.4.5	Segmentation Controls Tested Every Six Months	For service providers

---

Quick Reference: Decision Matrix

"What segmentation model should I use?"

Scenario	Recommended Model	Rationale
Small office, < 50 hosts	VLAN + host firewall	Low complexity, meaningful risk reduction
Traditional data center	VLAN + internal NGFW	Zone-based with L7 inspection
Virtualized data center	Micro-segmentation (NSX/Calico)	Per-workload policy, east-west visibility
Kubernetes / microservices	Service mesh (Istio/Linkerd) + NetworkPolicy	L7 identity-based, ephemeral workloads
Cloud-native (AWS/Azure/GCP)	VPC per env + SG/NSG per tier + PrivateLink	Cloud-native controls, multi-account
Remote workforce	ZTNA / SDP	Identity-based, no VPN, device posture
IoT / OT	Dedicated VLANs + Purdue model + data diodes	Physical isolation where possible
Regulated (PCI/HIPAA)	All of the above + validated segmentation	Compliance requires proof of segmentation

---

CIPHER Training Reference — Network Segmentation & Zero Trust Architecture Sources: OWASP Cheat Sheet Series, NIST SP 800-207, Google BeyondCorp, UK NCSC ZTA Principles, PAN-OS IronSkillet, MITRE ATT&CK, CIS Controls v8