What Good L3/L4 Policy Can Actually Do

In 2019 I published a short article about MITRE ATT&CK and segmentation.

The point was simple: when ATT&CK maps adversary techniques to mitigations, network segmentation shows up in more places than many people expect. It is not only a perimeter control. It appears across the attack lifecycle because attackers need reach.

That old point still holds.

But it deserves a 2026 reassessment.

The original post was written in a world where many segmentation conversations still meant VLANs, firewall zones, and large network boundaries. Today the conversation is broader. We have cloud security groups, Kubernetes network policies, host firewalls, software-defined segmentation, identity-aware access paths, workload labels, service maps, and microsegmentation platforms.

At the same time, the basics have not changed.

Most attacks still need communication paths:

a path from an exposed service to something more valuable
a path from one workload to another
a path to identity systems
a path to management tools
a path to file shares
a path to backup infrastructure
a path to exfiltrate data
a path to command-and-control infrastructure

Good L3/L4 policy works because it changes those paths.

The ATT&CK Layer Is A Useful Reality Check

MITRE ATT&CK currently describes Network Segmentation as mitigation M1030. The definition is practical: divide networks into smaller, isolated segments, control traffic between systems and applications, reduce attack surface, restrict lateral movement, and protect critical assets from compromise.

That sounds basic.

It is also powerful.

The updated Navigator layer on this site currently maps MITRE’s M1030 mitigation to 44 Enterprise ATT&CK technique and tactic entries, covering 37 unique technique IDs. The concentration is exactly where you would expect: lateral movement, persistence, credential access, discovery, exfiltration, initial access, command and control, and impact.

That does not mean segmentation magically prevents all 37 techniques.

It means those techniques often depend on network reach, and reducing that reach changes the attacker’s options.

That distinction matters.

Segmentation is not a magic “technique disabled” button. It is a control that removes unnecessary routes, limits who can talk to whom, constrains management paths, and makes certain attack chains harder, noisier, slower, or impossible in a specific environment.

That is exactly the kind of control defenders need.

L3/L4 Policy Is Not Primitive If It Is Done Well

There is a lazy version of the segmentation debate that treats L3/L4 controls as outdated because they do not understand application intent.

That is too simplistic.

Ports and protocols are not the whole truth, but they are still a very important part of the truth.

Attackers do not move laterally through vibes. They use actual connectivity. RDP. SMB. WinRM. SSH. SQL. LDAP. Kerberos. HTTPS. Remote management tools. Admin consoles. Backup ports. Database listeners. Object storage APIs. Package registries. CI/CD endpoints. Cloud metadata paths. Egress channels.

If those paths are unnecessary, L3/L4 policy can remove them.

If those paths are necessary only between specific systems, L3/L4 policy can constrain them.

If those paths are sensitive, L3/L4 policy can make them visible, reviewable, logged, and exceptional rather than ambient.

That is not old-fashioned. That is operational discipline.

The mistake is not using L3/L4 policy.

The mistake is using it too broadly, too statically, and too far away from the workload reality.

What Good L3/L4 Policy Can Do

Good L3/L4 policy can reduce lateral movement.

Remote services should not be broadly reachable because two systems happen to be in the same internal network. RDP, SSH, WinRM, SMB, DCOM, database ports, and admin APIs should have explicit sources and destinations. If a compromised workload cannot reach those services, many common movement patterns break early.

Good L3/L4 policy can protect management planes.

Domain controllers, backup servers, EDR consoles, virtualization managers, firewall managers, CI/CD systems, Kubernetes APIs, cloud control paths, and monitoring platforms should not be reachable from ordinary application or user zones. They are high-trust systems. Their network access should look like high-trust access.

Good L3/L4 policy can reduce discovery value.

Attackers rely on enumeration. Broad network visibility makes discovery cheap. Constrained reach makes scanning less useful and more suspicious. A server that can only reach five required services is harder to use as a general-purpose reconnaissance platform.

Good L3/L4 policy can limit exfiltration paths.

Many environments still allow too much outbound traffic. A workload that only needs to talk to a small set of internal services and approved external endpoints should not be able to initiate arbitrary outbound sessions. Egress control is segmentation, too.

Good L3/L4 policy can make response faster.

During an incident, the team should not have to invent containment from scratch. If application dependencies are already understood and enforced, responders can tighten, isolate, or switch to emergency policy with far less guesswork.

Good L3/L4 policy can create useful telemetry.

Denied traffic is a signal. Unexpected east-west attempts are a signal. A workload trying to reach unrelated management systems, file shares, backup repositories, or developer infrastructure is a signal. Segmentation does not only block. It tells you when reality diverges from the intended architecture.

What L3/L4 Policy Cannot Do

This is where the reassessment needs to stay honest.

L3/L4 policy cannot decide whether a valid HTTPS request is malicious.

If an attacker compromises a workload and abuses an allowed application path, a port-based policy may not see the difference. You still need identity, application controls, secrets hygiene, logging, detection, endpoint security, vulnerability management, and application-layer protection.

L3/L4 policy cannot fix overprivileged identities.

If a service account can access too much through an allowed path, the network policy may only reveal the blast radius. It cannot correct the identity model by itself.

L3/L4 policy cannot replace patching.

If a vulnerable service must be reachable, segmentation reduces exposure but does not remove the vulnerability. Patch the system. Harden the service. Remove the feature if it is unnecessary.

L3/L4 policy cannot compensate for bad scope.

If the segment is “all production,” the policy is probably too coarse. If every workload in the same environment can talk to every other workload, the control exists on paper but not in the attack path.

That is why microsegmentation matters.

Microsegmentation Makes L3/L4 Policy Operational

Microsegmentation is not valuable because it abandons L3/L4.

It is valuable because it makes least-privilege L3/L4 policy practical at workload level.

The useful version is not “more firewall rules.” The useful version is:

discover actual application dependencies
label workloads by role, environment, owner, and sensitivity
define policies around required flows
enforce close to the workload
adapt when workloads move
separate steady-state policy from emergency containment
keep policy understandable enough that humans can operate it

That is the difference between old segmentation and modern microsegmentation.

Old segmentation often tried to solve the problem with topology.

Modern microsegmentation solves it with intent, workload context, and enforced communication boundaries.

The enforcement may still be L3/L4 for many flows. That is fine. Most environments need that. The question is whether the policy is precise, complete, maintainable, and close enough to the systems it protects.

The Practical Test

A useful way to assess segmentation maturity is to ask a few uncomfortable questions:

Can an ordinary server reach domain controllers on more ports than it needs?
Can a compromised user endpoint reach server admin ports?
Can application servers initiate arbitrary outbound internet traffic?
Can production workloads reach development systems?
Can backup, monitoring, or deployment tools be reached from broad internal networks?
Can one application tier talk to unrelated application tiers?
Can a compromised public-facing service reach internal systems directly?
Can responders isolate a single application without breaking the entire environment?

If the answer to most of those questions is “yes” or “we do not know,” the segmentation program is not mature enough.

That does not mean the organization needs to boil the ocean.

Start where ATT&CK and incident history both point:

Remote administration paths.
Identity and directory infrastructure.
Backup and recovery systems.
Management planes.
Public-facing application paths.
East-west application dependencies.
Egress paths.

Those are the places where good policy changes real attack options.

The Bottom Line

Good L3/L4 policy is not a relic.

Bad L3/L4 policy is a relic.

Flat networks, broad internal trust, “any-any” exceptions, oversized zones, and unmanaged egress are architectural debt. Attackers monetize that debt every time one compromised system becomes a path to the next one.

Microsegmentation does not promise perfect prevention.

It promises better failure boundaries.

That is the right way to read the ATT&CK segmentation mapping. Network segmentation shows up across many techniques because reach is a dependency inside many attack chains. Remove unnecessary reach, and the attack graph changes.

Sometimes the attacker is blocked.

Sometimes the attacker is slowed down.

Sometimes the attacker is forced into a noisier path.

Sometimes the incident stays local instead of becoming enterprise-wide.

That is not a small win.

That is the point.

microsegment.io