Segmentation

Network Segmentation Review

A structured, repeatable process for evaluating network segmentation architecture against NIST SP 800-207 (Zero Trust Architecture) and CIS Controls v8 Control 12 (Network Infrastructure Management). This skill produces a segmentation maturity assessment with zone mapping, trust boundary analysis, east-west traffic control evaluation, and prioritized remediation guidance.

---

When to Use

If a target is provided via arguments, focus the review on: $ARGUMENTS

• Architecture reviews for new or modified network designs.
• Zero Trust readiness assessments.
• PCI DSS scoping exercises requiring CDE segmentation validation (PCI DSS v4.0 Requirement 1.3).
• Post-incident reviews where lateral movement was observed or suspected.
• Cloud migration planning requiring workload isolation design.
• Merger/acquisition network integration planning.

---

Context

Network segmentation is the foundational control that limits blast radius. NIST SP 800-207 Section 2 defines Zero Trust Architecture as requiring "no implicit trust granted to assets or user accounts based solely on their physical or network location." CIS Controls v8 Control 12 requires enterprises to "establish, implement, and actively manage network devices, in order to prevent attackers from exploiting vulnerable network services and access points." Effective segmentation moves beyond flat VLANs to enforce policy at the workload level, restricting east-west traffic between systems that have no legitimate communication requirement.

---

Process

Step 1: Discovery -- Locate Network Architecture Artifacts

Use Glob and Grep to locate network configuration files, diagrams-as-code, and infrastructure definitions.

Patterns to search:

# Infrastructure-as-Code
**/*.tf                  # Terraform (VPCs, subnets, route tables, security groups)
**/vpc*
**/subnet*
**/network*

# Kubernetes network policies
**/NetworkPolicy*
**/network-policy*
**/calico*
**/cilium*

# Cloud-native
**/firewall-rule*
**/security-group*
**/nsg*
**/route-table*

# Traditional
**/vlan*
**/*.acl
**/interfaces*

Catalog all discovered files by layer:

• Layer 3: VLANs, subnets, VPCs, route tables.
• Layer 4-7: Security groups, NACLs, network policies, WAF rules.
• Overlay: Service mesh policies (Istio, Linkerd), micro-segmentation (Calico, Cilium).

---

Step 2: Zone Architecture Analysis (NIST SP 800-207, Section 3)

Map the network into trust zones and evaluate the segmentation between them.

2.1 Zone Identification

Identify and document all network zones present in the configuration:

| Zone Type | NIST SP 800-207 Alignment | What to Look For | |-----------|--------------------------|------------------| | Public / DMZ | Policy Enforcement Point (PEP) at boundary | Internet-facing subnets, load balancers, reverse proxies | | Application Tier | Subject-resource segmentation | Web servers, API gateways, application subnets | | Data Tier | Resource isolation | Database subnets, storage networks, data lake VPCs | | Management Plane | Control plane isolation (Section 3.3) | Jump boxes, bastion hosts, CI/CD runners, configuration management | | PCI CDE | Explicit segmentation required by PCI DSS 1.3 | Cardholder data environment, in-scope system subnets | | User / Workstation | Subject-based segmentation | Corporate LAN, VDI subnets, remote access VPN pools | | IoT / OT | Untrusted device zones | Sensors, embedded devices, industrial control subnets |

For each zone, record:

• Subnet CIDR ranges.
• Associated security group or ACL identifiers.
• Routing relationships to other zones.

---

2.2 Trust Boundary Evaluation

For each pair of adjacent zones, evaluate the enforcement mechanism at the boundary.

NIST SP 800-207 Section 3.1 -- Policy Enforcement Points (PEP):

Every inter-zone communication path must traverse a PEP that enforces access policy. Verify:

• A firewall, security group, or network policy exists between every zone pair.
• No direct routing exists between zones that should be isolated (e.g., user workstation subnet directly routable to database subnet).
• Transit zones (shared services, hub VPCs) do not provide a bypass path around segmentation controls.

What constitutes a violation:

# BAD: Flat routing between application and data tiers
route {
  destination_cidr = "10.2.0.0/16"  # data tier
  target           = "local"         # direct route, no inspection
}

# GOOD: Traffic forced through inspection point
route {
  destination_cidr = "10.2.0.0/16"
  target           = "firewall-eni"  # routed through firewall
}

Finding classification: Missing enforcement point between zones is Critical. Bypass paths through transit zones are High.

---

2.3 VLAN Design Review (CIS Control 12.2)

CIS Control 12.2 requires establishing and maintaining a secure network architecture. Evaluate VLAN design:

• Flat network detection: Single VLAN or subnet containing mixed workload types (web servers, databases, user workstations). This is a Critical finding.
• VLAN sprawl: Excessive VLANs without clear zone mapping or naming conventions. Document count and categorization.
• Native VLAN security: Native VLAN (VLAN 1) must not carry production traffic. VLAN hopping is possible via double-tagging if native VLAN is shared.
• Inter-VLAN routing controls: Verify that inter-VLAN routing passes through a firewall or Layer 3 ACL, not unrestricted router-on-a-stick.

---

Step 3: East-West Traffic Controls (NIST SP 800-207, Section 2.1)

NIST SP 800-207 Tenet 4: "Access to individual enterprise resources is granted on a per-session basis." This means east-west (lateral) traffic within a zone must also be controlled.

3.1 Intra-Zone Policy Evaluation

• Within application tier: Can any application server communicate with any other application server? If yes, micro-segmentation is absent.
• Within data tier: Can Database A communicate with Database B? Unrestricted intra-tier communication enables lateral movement after initial compromise.
• Within management plane: Can a compromised jump box reach all other management endpoints?

Patterns to check:

# Kubernetes NetworkPolicy -- default deny within namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
spec:
  podSelector: {}        # applies to all pods in namespace
  policyTypes:
    - Ingress
    - Egress

# Calico -- global default deny
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: default-deny
spec:
  selector: all()
  types:
    - Ingress
    - Egress

Finding classification: No intra-zone controls (flat east-west within zones) is High. Absence of Kubernetes default-deny NetworkPolicy in production namespaces is High.

---

3.2 Micro-Segmentation Readiness Assessment

Evaluate the environment's readiness for workload-level segmentation:

| Criterion | Ready | Partially Ready | Not Ready | |-----------|-------|-----------------|-----------| | Workload identity | Every workload has a unique identity (service account, SPIFFE ID) | Some workloads identified | No workload identity scheme | | Communication mapping | Flow logs or service mesh telemetry documenting all east-west flows | Partial flow visibility | No east-west flow data | | Policy engine | Calico, Cilium, Istio, or cloud-native network policy deployed | Policy engine deployed but not enforcing | No policy engine | | Enforcement mode | Policies enforcing (deny unauthorized) | Policies in audit/monitor mode | No policies defined | | Automation | Policy changes via GitOps/IaC | Some manual policy management | Fully manual |

---

Step 4: DMZ Architecture Review (NIST SP 800-41, Section 4.1; CIS Control 12.2)

If a DMZ is present, evaluate its architectural soundness:

• Dual-firewall DMZ: Preferred architecture with separate external and internal firewalls (different vendors or rule sets). Single-firewall DMZ with three interfaces is acceptable but less resilient.
• DMZ-to-internal restrictions: DMZ systems must initiate connections only to specific internal hosts on specific ports. Unrestricted DMZ-to-internal access is a Critical finding.
• No direct external-to-internal path: External traffic must terminate in the DMZ. Any rule permitting direct external-to-internal-zone traffic bypasses the DMZ purpose entirely.
• DMZ management access: Management access to DMZ systems should originate from the management zone, not from the internet or user zone.

---

Step 5: PCI CDE Segmentation Validation (PCI DSS v4.0 Requirement 1.3)

If PCI scope is identified, verify CDE segmentation meets PCI DSS requirements:

• CDE is isolated in dedicated subnets or VLANs with explicit boundary controls.
• All traffic entering and leaving the CDE traverses a firewall or equivalent PEP.
• Connected-to systems are identified and documented.
• Out-of-scope systems cannot route directly to CDE systems.
• Segmentation testing methodology exists and is executed at least annually (PCI DSS 11.4.5).

Finding classification: CDE not segmented from general corporate network is Critical. Missing segmentation testing is High.

---

Step 6: Segmentation Testing Methodology

Document or verify the existence of a segmentation testing process:

1. From each zone, attempt to reach every other zone on unauthorized ports. Expected result: connection refused or timed out.
2. From outside the CDE, attempt to reach CDE systems on all ports. Expected result: no connectivity.
3. From the DMZ, attempt to reach internal zones on unauthorized ports. Expected result: blocked.
4. Test VLAN hopping via double-tagging from user VLANs. Expected result: traffic dropped.
5. Validate that segmentation controls survive failover (HA firewall failover should not open transit paths).

---

Findings Classification

| Severity | Definition | |----------|-----------| | Critical | Flat network with no segmentation; missing enforcement points between security zones; CDE not isolated; direct external-to-internal routing. | | High | No east-west controls within zones; bypass paths through transit networks; unrestricted DMZ-to-internal access; missing segmentation testing; native VLAN carrying production traffic. | | Medium | Micro-segmentation policies in audit mode only; partial flow visibility; management plane accessible from user zone without MFA/jump box; VLAN sprawl without documentation. | | Low | Suboptimal zone naming conventions; missing network diagrams; segmentation documentation out of date. |

---

Output Format

## Network Segmentation Assessment Report

### Scope
- Environment: 
- Configuration files analyzed: 
- Date: 
- Frameworks applied: NIST SP 800-207, CIS Controls v8 (12)

### Zone Map

| Zone | Subnet(s) | Enforcement Mechanism | Trust Level |
|------|-----------|----------------------|-------------|
| DMZ  | 10.1.0.0/24 | External FW + SG | Low |
| App  | 10.2.0.0/16 | Internal FW + NP | Medium |
| Data | 10.3.0.0/16 | Internal FW + NP | High |
| Mgmt | 10.4.0.0/24 | Bastion + SG | High |

### Trust Boundary Matrix

| Source Zone | Dest Zone | Enforcement | Status | Finding |
|-------------|-----------|-------------|--------|---------|
| DMZ         | App       | Firewall    | Restricted | Pass |
| App         | Data      | SG only     | Overly permissive | F-002 |
| User        | Data      | None        | No control | F-001 |

### Findings

#### [F-001] 
- **Severity:** Critical / High / Medium / Low
- **Control Reference:** NIST SP 800-207 Section X / CIS 12.X
- **File:** 
- **Description:** 
- **Remediation:** 

### Micro-Segmentation Readiness Score
- Workload Identity: 
- Communication Mapping: 
- Policy Engine: 
- Enforcement Mode: 
- Automation: 
- **Overall Readiness:** 

### Prioritized Remediation Plan
1. **[Critical]** 
2. **[High]** 
3. ...

---

Framework Reference

NIST SP 800-207 (Zero Trust Architecture)

| Section | Topic | Key Requirements | |---------|-------|-----------------| | 2.1 | Tenets of Zero Trust | No implicit trust based on network location; per-session access; dynamic policy | | 3.1 | Policy Enforcement Point (PEP) | Every resource access must traverse a PEP | | 3.2 | Policy Decision Point (PDP) | Centralized policy engine evaluates access requests | | 3.3 | Control Plane / Data Plane Separation | Management traffic isolated from production data flows | | 4.1 | Deployment Models | Agent/gateway, enclave-based, resource-portal models |

CIS Controls v8

| Control | Title | Relevance | |---------|-------|-----------| | 12.1 | Ensure Network Infrastructure is Up-to-Date | Patched network devices prevent segmentation bypass | | 12.2 | Establish and Maintain a Secure Network Architecture | Zone design, VLAN segmentation, DMZ architecture | | 12.3 | Securely Manage Network Infrastructure | Management plane isolation, encrypted management protocols | | 12.4 | Establish and Maintain Architecture Diagram(s) | Documented zone maps and data flow diagrams | | 12.8 | Establish and Maintain Dedicated Computing Resources for All Administrative Work | Privileged access workstations, jump boxes |

---

Common Pitfalls

1. Equating VLANs with segmentation. VLANs provide Layer 2 isolation but do not enforce access policy. Without Layer 3/4 ACLs or firewall rules between VLANs, a VLAN is a broadcast domain boundary, not a security boundary. Always verify that inter-VLAN traffic is filtered.

1. Ignoring east-west traffic in cloud environments. Cloud security groups often focus on north-south (internet to VPC) traffic. Within a VPC, instances in the same security group can typically communicate freely. This creates a flat network inside the "secure" perimeter.

1. Treating hub-and-spoke VPC peering as segmented. Transit gateways and VPC peering create routable paths between spoke VPCs. Without explicit route table restrictions and security group rules, a compromised workload in one spoke can reach resources in all peered spokes.

1. Overlooking service mesh bypass paths. Istio and Linkerd enforce policy on mesh-enrolled workloads only. Pods that bypass the sidecar proxy (hostNetwork: true, or init container misconfiguration) are not subject to mesh policy. Verify sidecar injection is enforced.

1. Assuming Kubernetes namespaces provide network isolation. Namespaces are a logical organizational boundary. Without a NetworkPolicy or CNI-level enforcement (Calico, Cilium), all pods across all namespaces can communicate freely by default.

---

Limitations

• Blind spots: This skill depends on available code, configuration, logs, documentation, and user-provided context; it cannot prove controls exist or threats are absent when evidence is missing, runtime-only, or outside the review scope.
• False-positive risks: Treat findings as hypotheses until validated against asset criticality, compensating controls, environment intent, and recent authorized changes.
• Required evidence: Support each finding with concrete artifacts such as file paths and line numbers, policy snippets, scanner output, logs, screenshots, control records, or reproducible steps.
• Normalized JSON: When machine-readable output is requested, findings MUST be available as JSON that validates against [schemas/finding.schema.json](../../../schemas/finding.schema.json).
• Escalation rules: Escalate immediately for suspected active compromise, exposed secrets, regulated-data exposure, critical exploitable vulnerabilities, privileged-access abuse, or when evidence is insufficient to safely disposition a high-impact risk.

---

Prompt Injection Safety Notice

This skill processes network configurations that may contain user-supplied comments, resource names, or tag values. When reading configura

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: UnitOneAI
• Source: UnitOneAI/SecuritySkills
• License: MIT
• Homepage: https://www.unitone.ai

Install and usage instructions live in the source repository linked above.