MITRE D3FEND Network Isolation Implementation Guide: Combining Filtering, DNS Controls and Tunnels

Most networks still let a compromised host reach far more than it needs: any internal subnet, any external domain, any port. MITRE D3FEND groups the controls that close those paths under Network Isolation (D3-NI), a technique in the Isolate tactic defined as preventing network hosts from accessing non-essential system network resources. Its children span traffic filtering, DNS allowlisting and denylisting, broadcast domain isolation, one-way links and encrypted tunnels. This guide treats D3-NI as one programme: what each child does, how to choose and sequence them, how to verify they work, and where they are bypassed. It is written for network, cloud and security architecture teams. Each child has its own page on this site; for the tactic see the D3FEND Isolate Tactic guide.

Key takeaways

• Network Isolation is about non-essential access. D3FEND's definition makes the test simple: if a host does not need a network resource, it should not be able to reach it.
• The family has 14 numbered techniques in four groups. Traffic filtering, DNS controls, layer 2 and physical isolation, and encrypted tunnels.
• Outbound control is where most estates are weakest. Inbound filtering is near universal; outbound filtering and DNS allowlisting, which constrain command and control and exfiltration, are much rarer.
• D3FEND's ATT&CK links are inferred. The site lists command and control, credential access, lateral movement, exfiltration and denial of service techniques for D3-NI, labelled inferred and experimental.
• Isolation needs identity to stay precise. Rules keyed only to IP addresses drift as workloads move; rules keyed to workload or service identity stay accurate.

What D3FEND means by Network Isolation

D3FEND defines Network Isolation as techniques that prevent network hosts from accessing non-essential system network resources. It enables the Isolate tactic, has no external references of its own, and relies on its children for mechanism. The D3FEND page describes the related actions as blocking DNS lookups and responses, filtering email, network, OT protocol and local area network traffic, isolating intranet networks, using physical data diodes and restricting physical links.

D3-NI sits beside Access Mediation in the same tactic. The difference is practical: Access Mediation grants or denies a specific request by a subject, while Network Isolation removes whole paths so the request never arrives. The MITRE D3FEND Access Mediation Implementation Guide covers the request-level side. For segmentation design patterns see the Network Segmentation Guide.

The child techniques

The table lists every numbered technique under D3-NI in the D3FEND ontology. Nesting is shown in the parent column.

How to choose and combine the children

Allowlist or denylist

• Choose DNS allowlisting (D3-DNSAL) and default-deny outbound filtering for servers, OT, build systems and other hosts with a known, stable set of destinations. The list is short and changes are reviewable.
• Choose denylisting (D3-DNSDL family) and category-based outbound control for user devices, where destinations are unpredictable. A protective DNS service is the usual delivery; the NCSC's Protective DNS service for UK public sector bodies is one example, and blocks resolution of domains known to be malicious.
• Use both where you can: allowlists for server zones, denylists plus logging for user zones.

Combinations that work

• Outbound filtering plus DNS control: blocking a domain is weak if the host can connect straight to an IP address, and blocking IPs is weak if the attacker rotates infrastructure. Force all DNS through the controlled resolver and block direct outbound DNS, DNS over HTTPS to unapproved resolvers, and direct internet access from server zones.
• Broadcast domain isolation plus host firewalls: private VLANs or host firewall rules that block peer-to-peer traffic between workstations remove much of the lateral movement and local name resolution poisoning surface.
• Encrypted tunnels plus filtering at the tunnel end: a tunnel protects traffic in transit but extends the network; filter what comes out of it as strictly as any other untrusted ingress.
• One-way links for the highest-consequence zones: where an OT or classified network only needs to send data out, a directional link removes the return path entirely. See the Data Diodes and Unidirectional Gateways Guide.

Small and large organisations

• Small organisations: a protective DNS service, a default-deny inbound firewall, email filtering, and blocking of workstation-to-workstation traffic deliver most of the value with managed services.
• Large and regulated organisations: add default-deny outbound for server and cloud zones through egress proxies, DNS allowlisting for critical servers, segmentation by zone with reviewed rule sets, and encrypted tunnels for all site and partner links.
• OT operators: zones and conduits, protocol-aware filtering and directional links. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.

Implementation sequence

The order is an NHI Mgmt Group recommendation: it starts with controls that give visibility and quick risk reduction, then moves to default-deny where breakage risk is higher.

1. Map flows. Collect firewall, flow and DNS resolver logs for at least two business cycles. Build a list of which zones talk to which, and which external destinations each server zone uses.
2. Centralise DNS (D3-DNSDL). Point every host at controlled resolvers, enable protective DNS denylisting, and block outbound port 53 and unapproved encrypted DNS from everywhere else. Log every query.
3. Isolate peers (D3-BDI). Block workstation-to-workstation traffic and unneeded broadcast protocols, starting with a pilot site.
4. Restrict outbound from servers (D3-OTF). Use the flow map to write allow rules, run them in log-only mode, then enforce zone by zone. Send remaining internet access through an egress proxy. For cloud, see Cloud Egress Filtering.
5. Move critical servers to DNS allowlisting (D3-DNSAL). Start with domain controllers, build servers and OT gateways.
6. Tighten inbound and internal filtering (D3-ITF, D3-NTF). Review rule sets for any-any rules, unused rules and broad management access. The Firewall Rule Review Checklist helps here.
7. Encrypt links that cross untrusted networks (D3-ET) and add directional links (D3-DNL) where only one-way flow is needed.

Testing and rollback

• Log-only first: every new deny rule and allowlist should run in log or monitor mode until the hit list is reviewed with system owners.
• Ring rollout: one zone or site at a time, with a named owner who can revert the rule set out of hours.
• Keep a break-glass path: out-of-band management access that does not depend on the rules being changed.

Where identity fits

A large share of the flows that isolation rules must allow belong to non-human identities: service accounts calling APIs, backup agents, CI runners pulling packages, monitoring collectors. Write rules that name the workload or service identity, not only an address range, and give each service account only the destinations it needs. In cloud and Kubernetes, security groups and network policies keyed to workload labels or service accounts stay accurate as addresses change. Encrypted tunnels and mutual TLS also rely on machine credentials that need rotation and ownership. See the mTLS Guide and the Zero Trust Identity Guide.

ATT&CK behaviours D3FEND relates to Network Isolation

D3FEND links D3-NI to offensive techniques through shared network artefacts and labels the mappings inferred and experimental. The table is a selection for testing, grouped by tactic, with ATT&CK v20 IDs. The child column is our reading, not a D3FEND statement.

Detection and measurement

Isolation controls generate the evidence of their own value. Watch for denied outbound connections from servers (especially to newly registered or uncategorised domains), DNS queries that bypass the controlled resolver, high-entropy or very long DNS query names, denied peer-to-peer traffic between workstations, and spikes in denies after a change, which usually signal a broken rule rather than an attack. The VPN and Firewall Log Detection Guide covers the log sources.

Metrics we suggest at NHI Mgmt Group (targets are examples, not standards):

1. Default-deny outbound coverage: percentage of server and cloud zones with enforced outbound allow rules.
2. DNS control coverage: percentage of hosts whose queries all pass through the controlled resolver (example target 100 percent of managed hosts).
3. Peer isolation: percentage of workstation segments blocking workstation-to-workstation traffic.
4. Rule hygiene: count of any-any rules and rules with no hits in 90 days.
5. Emulation pass rate: percentage of tested command and control and exfiltration behaviours blocked and alerted.

Framework mapping

Common failure patterns

• Inbound only. Strong perimeter filtering with open outbound lets any foothold call home and exfiltrate.
• DNS controls that can be bypassed. Protective DNS is configured, but hosts can still use public resolvers or encrypted DNS directly.
• Flat user networks. Workstations can reach each other on SMB, RDP and broadcast name resolution, so one compromised laptop reaches many.
• Tunnels treated as trusted. VPN and partner tunnels land on broad internal ranges with little filtering.
• IP-based rules for moving workloads. Cloud and container addresses are reused, so rules allow more than intended over time.
• Allowlists without owners. Exceptions accumulate with no review date until the allowlist is effectively open.

Practitioner checklist

• Map all 14 D3-NI techniques to a control, owner and coverage figure.
• Force all DNS through controlled resolvers and log every query.
• Block workstation-to-workstation traffic and unneeded broadcast protocols.
• Enforce default-deny outbound for server, build and OT zones.
• Put critical servers on DNS allowlists.
• Filter traffic leaving VPN and partner tunnels like any untrusted ingress.
• Key cloud and container rules to workload or service identity where the platform supports it.
• Run new rules in log-only mode, then enforce by zone with a rollback owner.
• Review any-any and unused rules quarterly.

Standards and references

• MITRE D3FEND: Network Isolation
• NIST: SP 800-41 Rev. 1 Guidelines on Firewalls and Firewall Policy
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• NCSC: Protective DNS (PDNS)
• MITRE ATT&CK: Application Layer Protocol: DNS
• MITRE ATT&CK: Name Resolution Poisoning and SMB Relay

Related NHI Mgmt Group resources: MITRE D3FEND Guide · D3FEND Isolate Tactic · MITRE D3FEND Access Mediation Implementation Guide · Protective DNS Guide · Network Segmentation Guide