<!-- Copyright (c) 2026 defconxt. All rights reserved. -->
<!-- Licensed under AGPL-3.0 — see LICENSE file for details. -->
<!-- NERF is a trademark of defconxt. -->

# Network Segmentation & Zero Trust Architecture — Definitive Reference

> NERF 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](#1-network-segmentation-models)
2. [Zone Design Patterns](#2-zone-design-patterns)
3. [Firewall Rule Design Methodology](#3-firewall-rule-design-methodology)
4. [East-West Traffic Monitoring](#4-east-west-traffic-monitoring)
5. [Zero Trust Architecture](#5-zero-trust-architecture)
6. [Software-Defined Perimeter (SDP)](#6-software-defined-perimeter-sdp)
7. [Service Mesh Security](#7-service-mesh-security)
8. [Network Access Control / 802.1X](#8-network-access-control--8021x)
9. [Cloud VPC Design](#9-cloud-vpc-design)
10. [SD-WAN Security](#10-sd-wan-security)
11. [IoT/OT Network Isolation](#11-iotot-network-isolation)
12. [Detection & Monitoring Stack](#12-detection--monitoring-stack)
13. [Migration Playbook](#13-migration-playbook)
14. [Reference Controls Mapping](#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](#5-zero-trust-architecture) 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](#13-micro-segmentation).

**Software-Defined Perimeter (SDP)**: Resources are invisible until authenticated. "Dark cloud" — no DNS resolution, no port response until authorization. See [Section 6](#6-software-defined-perimeter-sdp).

### 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**:
```yaml
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):
```yaml
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**:
```yaml
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**:
```yaml
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 |

---

*NERF 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*
