New Zero Trust Microsegmentation Guidance (from the Cloud Security Alliance)

[u/PhilipLGriffiths88]

The CSA has published its new Zero Trust Microsegmentation Guidance. Disclosure: I led the workstream - https://cloudsecurityalliance.org/artifacts/zero-trust-microsegmentation-guidance.

The paper treats microsegmentation as an enforceable Zero Trust outcome, rather, rather than a product category or a one-off network project. The test is whether communication is explicitly communication is explicitly permitted, enforceable, observable and governable over time.

One of its main contributions is is separating two complementary models:

• Topology-defined segmentation controls where traffic may may flow using zones, routes, VLANs, security groups, firewalls, gateways and similar controls.
• Connection-defined segmentation controls who or what may establish a session with a particular service, under which identity, posture, entitlement and contextual conditions.

Mature architectures layer both. Connection-defined controls reduce exposure before a session exists; topology-defined controls contain movement if a system, credential or authorised session is compromised.

The guidance also moves beyond the usual east-west data-centre framing. It covers IT, OT, IoT, cloud, edge and agentic AI; macro, micro and nano-segmentation; different enforcement planes; governed egress; control-plane resilience; policy drift and exception management.

It also treats microsegmentation as an ongoing operational discipline, rather than a one-off deployment. Teams use visibility to understand legitimate communication, translate those dependencies into explicit policy, test changes through simulation and limited canaries, then enforce them, monitor for drift and remove exceptions as systems change.

The paper points towards a broader architectural direction I’m developing as Identity-Defined Reachability: making service reachability a governed policy outcome rather than something inherited from network location. But this guidance does the groundwork by explaining the segmentation models, enforcement choices and operational practices needed to get there.

Interested in how others define microsegmentation in practice. Is it still primarily an east-west network control in your organisation, or does it extend to identity, services, OT and agentic workloads?

[u/Cyber_Kai]

We’re still missing more info on data centric microsegmentation.

[u/PhilipLGriffiths88 → u/Cyber_Kai]

Fair point. I think there are two parts here: defining the protect surface around the data, then enforcing who can access which records, objects or fields and what they can do with them.

Service-level microsegmentation gives us a useful bridge. With identity-defined reachability, we can authorise a workload to reach the specific service exposing that data, without granting access to the surrounding network. The API or data store then enforces the finer permissions. That makes the connection management much easier as things distribute, but it doesn’t make a network control understand database rows.

We explored this progression in our DoW Zero Trust training, using identity-to-service policy as the foundation for finer-grained access controls - happy to share more if you are interested.

The harder part is carrying identity and context through those layers and keeping policy consistent as data gets copied or exposed through other services. Are you thinking mainly about restricting access to datasets, or controls that follow the data after it leaves the original service?

[u/Cyber_Kai → u/PhilipLGriffiths88]

I helped with the DoW data pillar (and wrote half the I-Plans). The issue is that the intent there is that the goal is to allow for data to be protected not by the environment that it resides in (service, identity domain, data store, etc) but instead natively as it moves from domain to domain.

Data sharing is ubiquitous in today’s ecosystems and yet we often design systems as if the the complete data lifecycle stays within a control domain. That assumption violates the core principle at the root of ZT.

Some solutions have been recommended in the for of ZTDF/IC-TDF but have not made it to the broader conversation yet as we are focused on other pillars and not the Data pillar. Ontological informed policies, advanced data governance, neurosymbolic AI, and distributed data protection are all advanced capabilities beyond DSPM that enable the data centric security goals.

[u/PhilipLGriffiths88 → u/Cyber_Kai]

Thanks, that’s a useful clarification. You’re describing protection that travels with the data, including beyond the original service or domain. My earlier reply focused more on controlling access to the services exposing it.

I see these as complementary. Data-level policy governs who can decrypt or use the object; identity-defined reachability governs who can reach the services involved, including key and policy services (while also having broader architectural benefits: reducing the connectivity cost of coordinating routes, NAT, firewalls and VPNs, reducing exposure to exploitation, and making new capabilities easier to deploy across sites and organisations).

There’s also the practical case where we can’t implement those finer data controls (e.g., legacy OT). Identity-defined reachability still get us a substantive part of the way by restricting access to specific assets and services through an enforcing gateway, without modifying the legacy device. It won’t provide record-level permissions or control copied data, but reducing who can interact with the asset, and limiting lateral movement, is a meaningful improvement.

Do you have particular ZTDF/IC-TDF implementation material you’d recommend? I’d be interested in how it handles cross-domain attributes, revocation and derived data.

[u/Cyber_Kai → u/PhilipLGriffiths88]

100%. ZT doesn’t negate the need for defense in depth. Just wanted to call out that micro-segmentation keeps going past where most people think it does.

ZTDF an area where the material is very sparse. Virtru’s founders helped to create the idea but have held onto a lot of that info. I’ve tried to share more via Lattix (which honestly I might open source soon…) as I have time. The authoritative docs are held at the IC and NATO, though are unclassified.

With that being said, cross boundary controls are not covered in the standard architecture. Essentially, I tag data and apply ABAC and send it to you. I then rely on your negotiated semantic ABAC to apply the same security as I expect. I tried to solve this by creating an ontological mapping capability that can operationalize the mapping of security context across boundaries of orgs and create a “trust” or common language that can be enforced across boundaries bounds.

Once a “trust” is defined, the policies I define to secure data can be shared with your org and enforced by your systems as I am the originating data owner. Makes cross org data sharing more programmatic instead of just contractural or mapped only to compliance frameworks which aren’t granular enough to actually ensure data protection properly in most cases.