M1030 Network Segmentation: Segmentation Choices Mapped to Lateral Movement Techniques

On a flat network, one compromised laptop or service account can reach domain controllers, management interfaces and backup servers directly, so every later technique in an intrusion gets easier. MITRE ATT&CK M1030 Network Segmentation is the mitigation that limits what a foothold can reach. This guide reads M1030 from the ATT&CK point of view: the 38 technique and sub-technique mappings ATT&CK v20 gives it, which segmentation decision addresses each group, how to implement in a safe order, what segmentation does not stop, and how to prove it works. It is for network and cloud architects, SOC leads and detection engineers who need to justify segmentation work in terms of the techniques it removes.

Key takeaways

• ATT&CK credits segmentation well beyond lateral movement. The 38 mappings span twelve tactics, from Initial Access (T1190, T1133) through Exfiltration (T1048) and Impact (T1489, T1565).
• Six decisions cover almost all of it. A DMZ for internet-facing services, a management network, protected zones for identity systems, egress control, east-west rules for remote services, and isolation of container and AI agent workloads.
• Remote services are the lateral movement core. Blocking RDP, WinRM and DCOM between security zones addresses T1021.001, T1021.003, T1021.006, T1563 and T1210 directly.
• Identity systems need their own zone. ATT&CK's usage text for T1136, T1098 and T1482 all point to restricting network access to domain controllers and account-management systems.
• Test segmentation, do not assume it. ATT&CK's own guidance includes periodic penetration testing between segments; measure blocked versus allowed paths, not the number of VLANs.

What M1030 is

ATT&CK v20 defines Network Segmentation as "dividing a network into smaller, isolated segments to control and limit the flow of traffic between devices, systems, and applications." The mitigation text describes physical boundaries, logical separation with VLANs, and access control policies on firewalls, routers and cloud constructs. It lists seven practices: segment critical systems by function and sensitivity, host public services in a DMZ, use VPCs, subnets and security groups in the cloud, apply microsegmentation for workloads, enforce deny-by-default ACLs on both north-south and east-west traffic, monitor and audit rules and flows, and test effectiveness with periodic penetration tests.

D3FEND relates M1030 to four countermeasures: Broadcast Domain Isolation (D3-BDI), Encrypted Tunnels (D3-ET), Inbound Session Volume Analysis (D3-ISVA) and Inbound Traffic Filtering (D3-ITF). The architecture of segmentation and microsegmentation is covered in the Network Segmentation Guide; this page focuses on which ATT&CK techniques each segmentation choice addresses.

Techniques mapped to segmentation decisions

ATT&CK v20 maps M1030 to 38 current techniques and sub-techniques. The table groups them by the segmentation decision ATT&CK's usage text points to, with the count of mappings each decision addresses.

The counts sum to 38. Two lessons stand out. First, Lateral Movement is only part of the story; Persistence via account creation and Exfiltration via egress are just as strongly represented. Second, ATT&CK v20 now maps M1030 to T1698 Indirect Prompt Injection: an AI agent that reads untrusted content should not have network reach to unrelated internal services, which turns segmentation into an agent control.

Implementation priorities

The order below is an NHI Mgmt Group recommendation based on the technique coverage above and the cost of getting each step wrong.

1. Map flows before writing rules. Collect flow logs or firewall logs for at least a full business cycle, label sources and destinations by function, and identify which flows are needed. Rules written without data either break things or get written as allow-all.
2. Internet edge and remote access. Confirm nothing internal is directly reachable from the internet: RDP (TCP 3389), SSH (TCP 22), WinRM (TCP 5985 for HTTP and 5986 for HTTPS) and management interfaces sit behind a VPN, bastion or identity-aware proxy. Move public services into a DMZ or separate hosting. This addresses T1190 and T1133 first because they are entry points.
3. Tier 0 zone. Put domain controllers, identity providers, PAM vaults and certificate authorities in a zone reachable only from designated administrative hosts and the specific application flows they serve.
4. Management network. Move SNMP, device administration, hypervisor management, backup consoles and security tooling to a separate management network. ATT&CK specifically recommends running detection and response systems apart from production.
5. East-west remote service rules. Block RDP, WinRM, SMB and DCOM between user segments and between server zones except from administrative hosts. Start in log-only or monitor mode, review hits for two to four weeks, then enforce.
6. Egress per segment. Default-deny outbound for server segments; allow only named destinations and ports via proxies. Servers rarely need arbitrary internet access.
7. Workloads and agents. Apply microsegmentation for container clusters and AI agent runtimes: default-deny network policies and an explicit allow list of destinations.

Rollback: deploy each rule set with a change record listing the previous rule base, use the platform's monitor or logging mode before deny, and keep an emergency allow rule with a short expiry and an alert on use rather than reverting whole policies.

Cloud segmentation primitives

Platforms are listed alphabetically. Each row describes the provider's own construct and its documented behaviour.

Where identity fits

Segmentation and identity controls fail together in a predictable way: a network rule allows a path, and a reusable credential walks it. Two points matter for non-human identities. First, service accounts, automation hosts and deployment systems are often given broad network reach "because they need to talk to everything"; ATT&CK's T1072 usage text calls for isolating deployment systems with firewalls precisely because they do. Scope their network paths to the targets they manage. Second, cloud firewall targeting by service account is an identity decision: Google Cloud documents service account targets as stricter than network tags because they cannot be changed on a running instance. The Colonial Pipeline ransomware attack in May 2021 began with an unused VPN account without MFA; the company then shut down pipeline operations as a precaution while it contained ransomware on the IT side. How far an intrusion can spread from an IT foothold, and how confidently operations can continue, depends on segmentation between business IT and operational systems.

What M1030 does not stop

• Allowed paths. If the business needs a flow, an attacker can use it. Segmentation narrows the paths; identity, authentication and detection protect the ones that remain.
• Control plane access. Cloud API calls and SaaS administration do not cross your segments. T1098.001 Additional Cloud Credentials is mitigated by segmentation only where access to the systems that manage accounts is network-restricted; API access from the internet needs conditional access and M1032 Multi-factor Authentication.
• Tunnelled and encrypted traffic over allowed ports. Command and control over HTTPS through an allowed proxy passes egress rules; that is the job of M1031 Network Intrusion Prevention and M1037 Filter Network Traffic.
• Compromise inside the segment. Hosts in the same zone still reach each other unless microsegmentation or host firewalls add controls within the zone.
• Rule erosion. Temporary allow rules that become permanent slowly rebuild a flat network.

Detection and measurement

Segment boundaries are high-value sensor points. Log denied and allowed flows at each boundary, alert on denied attempts from user segments to tier 0 and management zones, and alert on any new allow rule touching those zones. D3FEND's Inbound Session Volume Analysis fits here: unusual connection volume into a protected zone is an early lateral movement signal.

Testing: run scheduled reachability checks from a probe in each user and server segment to the protected zones, and include segmentation testing in penetration test scope as ATT&CK recommends.

Common failure patterns

• VLANs without filtering. Separate subnets with routing between them and no ACLs give the appearance of segmentation and none of the effect.
• Management interfaces on the user network. Hypervisor, backup and network device consoles reachable from desktops undo every other zone.
• Egress left open on servers. Cloud defaults that allow all outbound traffic leave the exfiltration and command and control mappings unaddressed.
• Automation granted flat reach. Deployment and configuration management servers allowed to everything become the lateral movement path.
• Cloud tags used as security boundaries without control over who edits them. Where targets depend on editable labels, the right to edit the instance becomes the right to change the firewall.
• No re-test after change. Segmentation verified at project close and never again drifts silently.

Framework mapping

Related mitigations

• M1037 Filter Network Traffic: the rule content that enforces each boundary.
• M1035 Limit Access to Resource Over Network: restricts access to specific services and shares.
• M1031 Network Intrusion Prevention: inspects traffic on the paths segmentation leaves open.
• M1028 Operating System Configuration: host-level remote access settings that complement network rules.

Practitioner checklist

• Collect flow data for a full business cycle before writing segmentation rules.
• Confirm RDP, SSH, WinRM and management interfaces are not reachable from the internet.
• Create a tier 0 zone for domain controllers, identity providers, PAM and certificate authorities with named administrative sources only.
• Move SNMP, device, hypervisor, backup and security tool management to a separate management network.
• Block RDP, WinRM, SMB and DCOM between zones except from administrative hosts, after a monitor-mode period.
• Apply default-deny egress to server segments and route allowed traffic through proxies.
• Restrict deployment and automation servers to the targets they manage.
• Apply default-deny network policies to container clusters and AI agent runtimes.
• Run scheduled reachability tests between zones and include segmentation in penetration test scope.
• Give every temporary allow rule an owner and an expiry, and alert on rules touching protected zones.

Standards and references

• MITRE ATT&CK: M1030 Network Segmentation
• MITRE D3FEND: Inbound Traffic Filtering
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NSA: Advancing Zero Trust Maturity Throughout the Network and Environment Pillar
• AWS: Control traffic to your AWS resources using security groups
• Google Cloud: VPC firewall rules
• Kubernetes: Network Policies
• Microsoft Learn: Network security groups

Related NHI Mgmt Group resources: Network Segmentation Guide · T1021 Remote Services · T1133 External Remote Services Defensive Guide · M1029 Remote Data Storage