In 2017, the NotPetya attack devastated Maersk, the world's largest shipping conglomerate. Within hours of the initial infection, the malware had spread to nearly every one of their 49,000 endpoints across 600 sites in 130 countries. The company's entire global operations ground to a halt. Ships couldn't dock. Terminals couldn't process containers. The estimated damage: $300 million.

The attack vector was a compromised update to Ukrainian accounting software. But the devastation wasn't primarily due to the initial compromise—it was due to the speed and ease of lateral movement across Maersk's flat network architecture. Once inside, NotPetya spread like wildfire because there were no internal barriers to slow it down.

Micro-segmentation is the architectural response to this threat. It's the practice of creating fine-grained security boundaries around individual workloads, preventing compromised systems from reaching others—even within the same network segment.

Network segmentation has existed for decades. Organizations divided their networks into zones—DMZ, development, production, HR, finance—using VLANs, firewalls, and ACLs. This was better than a completely flat network, but it created coarse-grained trust zones where everything within a segment was implicitly trusted.

The problem with traditional segmentation:

Micro-segmentation defined:

Micro-segmentation creates a security boundary around each individual workload—each container, VM, serverless function, or service instance. Access between workloads requires explicit authorization, regardless of network location.

Key characteristics:

• Workload-centric: Policies are attached to workloads, not network constructs
• Identity-based: Access decisions based on verified identity, not IP addresses
• Dynamic: Policies automatically apply as workloads scale up/down
• Application-aware: Can understand and filter based on application-level protocols
• Least privilege: Only necessary communication paths are allowed

To understand why micro-segmentation matters, we must understand how attackers move laterally within networks. Lateral movement is the phase of an attack where adversaries explore the network, escalate privileges, and reach their ultimate targets.

Common lateral movement techniques:

A typical lateral movement attack flow:

Initial Compromise            Lateral Movement Path            Ultimate Target
      │                                │                            │
      ▼                                ▼                            ▼
┌─────────────┐    Trust      ┌─────────────┐    Trust      ┌─────────────┐
│   Workload  │──────────────▶│   Workload  │──────────────▶│   Critical  │
│      A      │    Allowed    │      B      │    Allowed    │   Database  │
│  (Webserver)│               │  (App Svc)  │               │             │
└─────────────┘               └─────────────┘               └─────────────┘
   Phishing               Uses extracted                Uses app service's
   compromises            credentials to                database credentials
   webserver              reach app service             to steal data

WITHOUT MICRO-SEGMENTATION:
- Webserver can freely communicate with app service (both in "production" zone)
- App service can freely communicate with database (both "internal")
- No verification of whether these communications are legitimate
- Attacker moves freely until reaching ultimate target

The micro-segmentation difference:

WITH MICRO-SEGMENTATION:
                                                              
┌─────────────┐               ┌─────────────┐               ┌─────────────┐
│   Webserver │               │   App Svc   │               │   Database  │
│             │               │             │               │             │
│  Segment A  │               │  Segment B  │               │  Segment C  │
└──────┬──────┘               └──────┬──────┘               └──────┬──────┘
       │                             │                             │
       │  POLICY: Web → App          │  POLICY: App → DB           │
       │  IF: valid token            │  IF: service identity       │
       │  AND: request matches       │  AND: authenticated         │
       │       expected pattern      │  AND: authorized query      │
       │                             │                             │
       └─────────▶ Verified ◀────────┴────────▶ Verified ◀─────────┘

Each hop requires explicit verification:
- Stolen credentials from webserver don't grant access to app service
- Compromised app service can only make authorized database queries
- Anomalous traffic patterns trigger alerts and blocks

Micro-segmentation can be implemented through multiple architectural approaches, each with different tradeoffs:

1. Host-Based Micro-Segmentation

Policy enforcement at the host (VM or bare metal) level using host-based firewalls and agents.

How it works:

• Agent installed on each host
• Agent enforces firewall rules based on workload identity
• Central policy engine distributes policies
• Works across physical, virtual, and cloud environments

Technologies:

• Illumio Core
• Guardicore (now Akamai)
• VMware NSX Distributed Firewall
• Cisco Secure Workload (Tetration)

Pros: Broad compatibility, works in any environment, existing workloads supported Cons: Requires agents, host-level permissions, potential performance overhead

2. Network-Based Micro-Segmentation

Policy enforcement at the network infrastructure level using software-defined networking (SDN).

How it works:

• SDN controller maintains workload inventory
• Virtual network overlays isolate segments
• Distributed switches enforce policies
• Policies follow workloads as they move

Technologies:

• VMware NSX-T
• Cisco ACI
• Nuage Networks (Nokia)
• OpenStack Neutron

Pros: No host agents, network-level control, strong isolation Cons: Infrastructure dependency, may not protect within hypervisors

3. Service Mesh Micro-Segmentation

Policy enforcement through sidecar proxies attached to each workload, typically in containerized environments.

How it works:

• Sidecar proxy (e.g., Envoy) deployed alongside each container
• All traffic routed through the proxy
• Proxy enforces mTLS and authorization policies
• Control plane manages certificates and policies

Technologies:

• Istio (with mTLS and AuthorizationPolicy)
• Linkerd (with policy)
• Consul Connect
• Cilium (eBPF-based, no sidecar)

Pros: Application-layer visibility, automatic mTLS, cloud-native Cons: Kubernetes/container focus, added complexity, latency overhead

Effective micro-segmentation requires thoughtful policy design. Poorly designed policies either create security gaps (too permissive) or break applications (too restrictive).

Policy design principles:

Discovering communication patterns:

Before writing policies, you must understand how your applications communicate. This is called application dependency mapping.

Approaches to dependency mapping:

1. Passive observation: Monitor actual traffic flows in the environment

   • Flow logs (VPC flow logs, Kubernetes network policies in audit mode)
   • Service mesh telemetry
   • Agent-based traffic analysis

2. Application documentation: Work with application teams

   • Architecture diagrams
   • API specifications
   • Service catalogs

3. Automated discovery: Use tooling to map dependencies

   • APM tools (Datadog, New Relic service maps)
   • Micro-segmentation vendor discovery features
   • Service mesh topology views

Example dependency map:

┌─────────────────────────────────────────────────────────────────────────┐
│                          E-Commerce Application                          │
└─────────────────────────────────────────────────────────────────────────┘

                    ┌──────────────────────────────┐
                    │       Load Balancer          │
                    │     (Ingress Controller)     │
                    └───────────────┬──────────────┘
                                    │ HTTPS (443)
                                    ▼
                    ┌──────────────────────────────┐
                    │      Web Frontend (BFF)      │
                    │         3 replicas           │
                    └───────────────┬──────────────┘
                                    │
              ┌─────────────────────┼─────────────────────┐
              │ gRPC (9090)         │ gRPC (9090)         │ gRPC (9090)
              ▼                     ▼                     ▼
    ┌─────────────────┐   ┌─────────────────┐   ┌─────────────────┐
    │  User Service   │   │ Catalog Service │   │  Cart Service   │
    │    2 replicas   │   │    4 replicas   │   │    2 replicas   │
    └────────┬────────┘   └────────┬────────┘   └────────┬────────┘
             │ TCP (5432)          │ TCP (5432)          │ TCP (6379)
             ▼                     ▼                     ▼
    ┌─────────────────┐   ┌─────────────────┐   ┌─────────────────┐
    │   User Database │   │ Catalog Database│   │   Redis Cache   │
    │   (PostgreSQL)  │   │   (PostgreSQL)  │   │                 │
    └─────────────────┘   └─────────────────┘   └─────────────────┘

Translating to policies:

From this map, we can derive explicit policies:

• Load Balancer → Web Frontend: HTTPS (443) only
• Web Frontend → User Service: gRPC (9090) only
• Web Frontend → Catalog Service: gRPC (9090) only
• Web Frontend → Cart Service: gRPC (9090) only
• User Service → User Database: PostgreSQL (5432) only
• Catalog Service → Catalog Database: PostgreSQL (5432) only
• Cart Service → Redis Cache: Redis (6379) only

Everything else is denied by default.

For cloud-native, containerized environments, service meshes provide the most natural micro-segmentation implementation. Let's explore how Istio—one of the most popular service meshes—implements Zero Trust micro-segmentation.

Istio's security architecture:

┌─────────────────────────────────────────────────────────────────────────┐
│                           Istio Control Plane                            │
│  ┌───────────────┐  ┌───────────────┐  ┌───────────────────────────┐    │
│  │    istiod     │  │   Citadel     │  │  Authorization Policy     │    │
│  │  (Pilot +     │  │  (Certificate │  │  Engine                   │    │
│  │   Config)     │  │   Authority)  │  │                           │    │
│  └───────────────┘  └───────────────┘  └───────────────────────────┘    │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
         Certificate distribution + Policy configuration
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                              Data Plane                                  │
│  ┌─────────────────────┐          ┌─────────────────────┐               │
│  │   Pod A             │  mTLS    │   Pod B             │               │
│  │  ┌───────┐ ┌──────┐ │◀────────▶│ ┌──────┐ ┌────────┐ │               │
│  │  │ App A │◀┤Envoy │ │          │ │Envoy ├▶│ App B  │ │               │
│  │  └───────┘ └──────┘ │          │ └──────┘ └────────┘ │               │
│  └─────────────────────┘          └─────────────────────┘               │
└─────────────────────────────────────────────────────────────────────────┘

Traffic flow:
1. App A sends request to App B
2. Request goes to local Envoy sidecar
3. Envoy encrypts request using mutual TLS with App B's identity
4. App B's Envoy receives request, verifies identity
5. Envoy checks AuthorizationPolicy: Is App A allowed to call this endpoint?
6. If authorized, request passes to App B; otherwise, denied

Istio AuthorizationPolicy example:

# Policy: Only allow frontend service to call the user service
# and only for specific paths with specific methods
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: user-service-policy
  namespace: production
spec:
  selector:
    matchLabels:
      app: user-service
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - "cluster.local/ns/production/sa/frontend-service"
    to:
    - operation:
        methods: ["GET", "POST"]
        paths: ["/api/users/*", "/api/auth/validate"]
  - from:
    - source:
        principals:
        - "cluster.local/ns/production/sa/admin-service"
    to:
    - operation:
        methods: ["GET", "POST", "PUT", "DELETE"]
        paths: ["/api/users/*", "/api/admin/*"]

This policy specifies:

• Who can access: Only frontend-service and admin-service identities
• What they can access: Specific paths and methods
• Everything else: Implicitly denied

Not all workloads require the same level of segmentation. Strategic segmentation focuses the most controls on the most sensitive assets while maintaining manageable complexity.

Segmentation by sensitivity:

Domain-driven segmentation:

Align micro-segmentation boundaries with business domain boundaries (bounded contexts from Domain-Driven Design):

┌─────────────────────────────────────────────────────────────────────────┐
│                         Domain Boundary Segmentation                     │
└─────────────────────────────────────────────────────────────────────────┘

  ┌──────────────────────┐  ┌──────────────────────┐  ┌─────────────────┐
  │   Payments Domain    │  │   Inventory Domain   │  │  Users Domain   │
  │  ┌────────────────┐  │  │  ┌────────────────┐  │  │  ┌───────────┐  │
  │  │Payment Service │  │  │  │Inventory Svc   │  │  │  │User Svc   │  │
  │  └───────┬────────┘  │  │  └───────┬────────┘  │  │  └─────┬─────┘  │
  │          │           │  │          │           │  │        │        │
  │  ┌───────▼────────┐  │  │  ┌───────▼────────┐  │  │  ┌─────▼─────┐  │
  │  │Payment DB      │  │  │  │Inventory DB    │  │  │  │User DB    │  │
  │  └────────────────┘  │  │  └────────────────┘  │  │  └───────────┘  │
  │                      │  │                      │  │                 │
  │  ┌────────────────┐  │  │  ┌────────────────┐  │  │  ┌───────────┐  │
  │  │Fraud Detection │  │  │  │Warehouse Svc   │  │  │  │Auth Svc   │  │
  │  └────────────────┘  │  │  └────────────────┘  │  │  └───────────┘  │
  └──────────────────────┘  └──────────────────────┘  └─────────────────┘
          │                          │                        │
          └──────────────────────────┼────────────────────────┘
                                     │
                          Cross-domain communication
                          requires explicit APIs and
                          strong authentication

Benefits of domain-aligned segmentation:

• Services within a domain share context and can be more permissive
• Cross-domain communication is strictly controlled through well-defined APIs
• Aligns with team ownership—each team manages their domain's policies
• Reduces policy complexity—fewer cross-domain dependencies to model

Micro-segmentation adds security but also adds complexity. Successful implementations require careful operational planning.

Best practices for operations:

1. Policy-as-code with CI/CD

policies/
├── base/
│   └── default-deny.yaml
├── domains/
│   ├── users/
│   │   └── user-service-policy.yaml
│   ├── payments/
│   │   └── payment-service-policy.yaml
│   └── catalog/
│       └── catalog-service-policy.yaml
└── kustomization.yaml

Treat policies like application code:

• Version control all policies
• Require code review for policy changes
• Test policies in staging before production
• Automate deployment through GitOps

2. Observability for security

Implement comprehensive observability:

• Access logs for every request
• Policy decision logs
• Service topology visualization
• Anomaly detection on traffic patterns

3. Gradual rollout strategy

1. Discover: Map all communication patterns
2. Define: Write policies based on discovered patterns
3. Monitor: Deploy in audit mode, validate no legitimate breakage
4. Enforce: Enable enforcement, start with least critical services
5. Expand: Gradually cover all services
6. Maintain: Continuously update policies as applications evolve

Let's consolidate the key concepts of micro-segmentation for Zero Trust:

What's next:

With micro-segmentation establishing boundaries around workloads, we need to ensure that access within those boundaries is correctly controlled. The next page explores identity-based access—how to implement authentication and authorization based on verified identities rather than network location, including service-to-service identity using SPIFFE/SPIRE and workload identity in cloud-native environments.