CSA Zero Trust Microsegmentation Guidance – formalizes topology-defined vs. connection-defined segmentation models

Disclosure: I led this workstream at the Cloud Security Alliance. CSA published new guidance on Zero Trust Microsegmentation. Sharing here because the framing is more precise than most vendor material on this topic, and I think the model split is useful even if you disagree with parts of the paper. Core definition used throughout: a communication is “segmented” only if it’s explicitly permitted, enforceable, observable, and governable over time – not just blocked by default or isolated by network position. Two models, formally separated: Topology-defined segmentation: enforcement based on network position: zones, routes, VLANs, security groups, firewalls, gateways. Controls where traffic is allowed to flow. Connection-defined segmentation: enforcement based on session establishment: identity, device posture, entitlement, and context gate whether a session to a service can be created at all. Controls who/what can talk to a service, independent of network location. The paper’s position is that these are complementary, not competing – connection-defined controls reduce the attack surface before a session exists (relevant for credential theft, insider threat, lateral movement from an already-authenticated foothold), while topology-defined controls provide containment if a session, credential, or system is compromised despite that. Relying on only one leaves a gap the other closes. Scope beyond the usual east-west/data-center framing: IT, OT, IoT, cloud, edge, and agentic AI workloads macro/micro/nano-segmentation as distinct granularities, not synonyms enforcement plane choices (host, hypervisor, network, identity/proxy) governed egress (not just ingress/lateral) control-plane resilience (what happens when the policy engine or PDP is unreachable) policy drift detection and exception lifecycle management Operational model it lays out: visibility → derive policy from observed legitimate dependencies → simulate/canary → enforce → monitor for drift → retire stale exceptions. Framed explicitly as continuous, not a deployment milestone. There’s a separate direction I’m developing – Identity-Defined Reachability, treating reachability as a governed policy outcome rather than something inherited from network topology – but that’s out of scope for this paper; the guidance here is the groundwork (segmentation models, enforcement plane tradeoffs, operational practice) rather than that architecture itself. Happy to get into specifics on enforcement plane tradeoffs or policy-drift detection approaches if useful. submitted by /u/PhilipLGriffiths88 [link] [comments]Technical Information Security Content & DiscussionRead More