Network Microsegmentation

The 2013 Target breach started with a compromised HVAC contractor and pivoted across a flat corporate network to point-of-sale systems. NotPetya in 2017 hopped freely across global enterprise networks because once inside the perimeter everything was reachable. Both are textbook examples of why network microsegmentation matters.

The Goal

Microsegmentation limits east-west traffic — the traffic between internal systems — to only what is necessary. Each segment (often a single workload) has its own ingress and egress policy. A breach in one workload can talk to a handful of intentionally allowed peers; everything else is blocked.

The blast radius shrinks from "everything reachable from anywhere inside the perimeter" to "this one application plus the database it owns plus the auth service."

Three Architectural Approaches

Mature deployments mix all three. Service mesh handles Kubernetes east-west; NSX or cloud security groups handle hypervisor / VPC level; an agent platform covers heterogeneous on-prem.

Microsegmentation in the Cloud

Each hyperscaler ships a built-in segmentation primitive:

• AWS — Security Groups (stateful), Network ACLs (stateless), VPC endpoints, AWS Network Firewall, Verified Access
• Azure — Network Security Groups, Application Security Groups, Azure Firewall, Private Link, Service Endpoints
• GCP — VPC firewall rules with tags / service accounts, Hierarchical firewall policies, Cloud NGFW

Best-practice patterns:

• Default-deny VPC. The default route to the internet is removed; egress traverses a managed firewall.
• Per-service security groups. Web tier SG allows ingress from the load balancer SG. App tier SG allows ingress from the web SG. Database SG allows ingress only from the app SG. No CIDR-based rules.
• Private endpoints. Replace public S3 / Storage Account / Cloud SQL endpoints with VPC private endpoints. Public access blocked at the resource level too.
• Egress filtering. Outbound traffic to the internet allow-listed by FQDN (e.g., only *.cloudflare.com, *.aws.com, your CDN). Prevents data exfiltration and C2 callbacks.

Microsegmentation in Kubernetes

Pods talk to each other freely by default. Two layers fix this:

NetworkPolicy

A Kubernetes object that declares which pods may talk to which, based on labels and namespaces. Enforced by the CNI plugin (Calico, Cilium, Antrea).

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow-from-frontend
  namespace: prod
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes: [Ingress]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              env: prod
          podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

Pattern: a default-deny NetworkPolicy in every namespace, then targeted "allow X from Y" policies layered on top. Cilium's eBPF-based implementation is the modern standard and adds Layer 7 (HTTP / gRPC / Kafka) policy.

Service Mesh

NetworkPolicy works at IP / port level. A service mesh adds identity-based mTLS — every pod gets a cryptographic identity (a SPIFFE SVID), every call is encrypted, every call is authorised on workload identity.

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

If an attacker compromises a pod in billing and tries to call the api service, the call fails not because of IP rules but because the attacker's workload identity is not frontend.

The three production-grade meshes are Istio (most features), Linkerd (simplest), and Cilium Service Mesh (eBPF, no sidecar). All three implement mTLS by default, which is itself a Zero Trust win independent of policy.

Observability Comes First

You cannot write segmentation policy for traffic you cannot see. The first project is always:

1. Deploy a flow-visualisation tool (VPC Flow Logs + Athena, NSX Intelligence, Illumio's app dependency map, Cilium Hubble for Kubernetes).
2. Capture 30-90 days of east-west flows in audit mode.
3. Group flows by application; produce an "intended traffic" matrix per app.
4. Convert intended flows into allow rules; everything else default-deny.
5. Roll out per environment: dev → staging → prod.

Skipping this step is how segmentation projects break critical applications and stall.

Microsegmentation vs ZTNA

Both are network controls; they target different traffic:

Both are needed. We will look at ZTNA later in the policy-engines lesson.

The Minimum Bar

1. VPC / vNet design with subnets per tier and security groups per service.
2. Private endpoints for managed services. Public access disabled at the resource.
3. Egress through a controlled gateway with FQDN allow-listing.
4. NetworkPolicy default-deny in every Kubernetes namespace.
5. Service mesh (Istio / Linkerd / Cilium) for mTLS and identity-based policy.
6. Flow logging and visualisation to evolve policy without breakage.

With identity, device, and network pillars in place, three out of five CISA pillars are covered. The remaining two — applications/workloads and data — are where the rubber meets the business value, covered next.