D3FEND Isolate Tactic: Containing Attackers With Execution and Network Barriers

Most intrusions succeed because, once an attacker has one foothold, nothing stops the next process, connection, file or permission from working too. The Isolate tactic in MITRE D3FEND collects the controls that put barriers in that path. D3FEND defines it as creating "logical or physical barriers in a system which reduces opportunities for adversaries to create further accesses." This hub lists every Isolate technique in D3FEND 1.6.0 (five families, 52 techniques, 57 entries in all), explains how the families fit together and where to start, and summarises the ATT&CK behaviours D3FEND relates to them. It is written for security architects, engineers and detection teams. For the framework itself, see the MITRE D3FEND Guide.

Key takeaways

• Isolate is about limiting reach, not spotting attackers. Its techniques decide what a process may execute, which hosts and domains a host may contact, what content may pass and what an account may touch.
• Five families cover the whole tactic. Access Mediation (16 techniques), Access Policy Administration (4), Content Filtering (13), Execution Isolation (5) and Network Isolation (14).
• Policy and enforcement are separate jobs. Access Policy Administration defines who may do what; Access Mediation is the runtime decision that enforces it. Most failures sit in the gap between them.
• Start with egress, execution and privilege. Outbound traffic filtering, DNS denylisting, executable allowlisting and account permissions remove the most attacker options for the least effort in most estates.
• ATT&CK links are inferred. D3FEND relates Isolate techniques to ATT&CK through shared digital artefacts, not through tested coverage. Treat them as a starting map and verify each barrier against the behaviour you care about.

What Isolate means in D3FEND

D3FEND groups defensive techniques into seven tactics: Model, Harden, Detect, Isolate, Deceive, Evict and Restore. Harden makes a component harder to exploit; Isolate assumes something may already be exploitable or compromised and limits what it can reach next. The ontology also defines an Isolation Event, so Isolate is both a design discipline and a containment action in incident response.

Each Isolate technique works on a digital artefact: a process, an executable file, a network flow, a DNS query, a file, a user account or a physical door. That artefact is how D3FEND links the technique to offensive behaviour. If an ATT&CK technique produces or uses the same artefact, D3FEND records an inferred relationship. The barrier types are:

• Execution barriers: which code may run and which memory, system calls and resources a running process may use (Execution Isolation, System Call Filtering).
• Network barriers: which hosts, ports, domains and directions of traffic are permitted (Network Isolation, Network Access Mediation).
• Content barriers: what files and messages may cross a boundary, and in what form (Content Filtering).
• Permission barriers: what an account, group, domain trust or file permission allows (Access Policy Administration).
• Physical barriers: who may enter a facility and which ports or operating modes a device accepts (Physical Access Mediation, IO Port Restriction, Operating Mode Restriction).

Every technique in the tactic

The table lists all 52 techniques under the five Isolate families, taken from the D3FEND 1.6.0 ontology, with each technique's direct parent. Each family row links its implementation guide; each technique links its own page.

How the families fit together

The families are layers, and an attacker who crosses one should meet another. The table shows where each is enforced.

Three relationships matter in practice. First, Access Policy Administration without Access Mediation is documentation: the rule must be enforced at a point the attacker cannot route around. Second, Network Isolation and Execution Isolation cover each other's blind spots: an allowlisted binary can still beacon out, and a blocked domain can still be reached by a process that tunnels over an allowed one. Third, Content Filtering inspects what crosses a permitted path. See the MITRE D3FEND Access Mediation Implementation Guide and the MITRE D3FEND Access Policy Administration Implementation Guide for the policy and enforcement pair in depth.

Where to start

The order below is our recommended sequence for a typical enterprise, not a D3FEND ranking. It favours barriers that remove many attacker options at once and that can be tested without breaking production.

1. Inventory what must be reachable. List the outbound destinations, inbound services, administrative paths and file types each zone genuinely needs. Every later step is an allowlist built from this list.
2. Filter outbound traffic and DNS. Apply D3-OTF Outbound Traffic Filtering to servers first, then add D3-DNSDL DNS Denylisting through a protective resolver. For servers with a short destination list, move to D3-DNSAL DNS Allowlisting. Run in log-only mode for two to four weeks (an example window) before blocking.
3. Control execution. Deploy D3-EAL Executable Allowlisting in audit mode on a pilot ring, then on servers and privileged workstations. Use D3-EDL Executable Denylisting as a stopgap where allowlisting is not yet practical. See the Application Allowlisting Guide.
4. Cut standing privilege. Review D3-UAP User Account Permissions and D3-UGPH User Group Permissions for administrative and service accounts, and restrict D3-DTP Domain Trust Policy where trusts are no longer needed.
5. Segment and mediate east-west access. Add D3-ITF Inbound Traffic Filtering between zones and D3-BDI Broadcast Domain Isolation for user and IoT segments; put administrative protocols behind D3-NAM Network Access Mediation. See the Network Segmentation Guide.
6. Filter content on delivery routes. Apply D3-EF Email Filtering, D3-FFV File Format Verification and, for high-risk inbound files, D3-CNR Content Rebuild.
7. Isolate processes on critical workloads. Use D3-KBPI Kernel-based Process Isolation and D3-SCF System Call Filtering for internet-facing services and containers.
8. Cover specialist environments. OT networks need D3-DNL Directional Network Link, D3-OVAR OT Variable Access Restriction and D3-OPR Operating Mode Restriction; sites handling sensitive hardware need the physical techniques.

Testing and rollback: Keep each change in a log-only or audit state first, roll out by ring (pilot, then servers, then the wider estate), keep the previous policy version deployable, and define in advance who can grant an emergency exception and how long it lasts. Small organisations can get most of the value from steps 2 to 4 using built-in operating system and resolver features; large estates usually need central policy management and a change process per zone.

ATT&CK techniques D3FEND relates to Isolate

D3FEND relates each Isolate technique to ATT&CK techniques that act on the same or a related digital artefact. These are inferred relationships, not proof that a control blocks a technique. The table shows our count of how many of the 52 Isolate technique pages on this site list each ATT&CK technique (or one of its sub-techniques) in their inferred tables, which indicates where the tactic's barriers concentrate. Technique names and tactics are as in ATT&CK v20.

The "barrier that typically applies" column is our engineering view, not a D3FEND mapping. Some ATT&CK techniques that D3FEND still references have been revoked or reorganised in ATT&CK v20 (for example Impair Defenses, whose successors include T1685 Disable or Modify Tools); the technique pages show the v20 successor. For the attacker side of these behaviours, see the ATT&CK Command and Control Tactic and ATT&CK Lateral Movement Tactic hubs.

Where identity fits

Several Isolate techniques are identity controls under another name. D3-UAP User Account Permissions and D3-UGPH User Group Permissions apply equally to service accounts, workload identities and API clients, which often hold broader standing rights than any person. D3-CTS Credential Transmission Scoping is the principle behind audience-restricted tokens and sender-constrained credentials: a credential that can only be presented to one relying party is worth less when stolen. Network barriers also apply to machine identities: a service account that can only authenticate from its own host and only reach its own database is contained even if its secret leaks. See the Least Privilege Techniques Guide and the Cloud Workload Identity Guide.

Detection and measurement

Once policy is tuned, a blocked action is an anomaly by definition, so Isolate controls produce high-value detection data.

• Log every deny: firewall and resolver blocks, application control blocks, system call filter violations, quarantine actions and access mediation refusals.
• Alert on repeated denies from one source: a host that keeps hitting blocked domains or blocked binaries is either misconfigured or compromised.
• Watch for policy changes: changes to firewall rules, application control policy, group membership and domain trusts are high-value events and map to the Defense Impairment behaviours above.

Targets are examples, not standards.

Framework mapping

This mapping is our alignment by control intent; D3FEND itself does not publish it. Monitoring of the deny events described above aligns with CSF DE.CM-01.

Common failure patterns

• Allowlists that never leave audit mode. Application control and DNS allowlisting projects often stall after the pilot because nobody owns the exception process. Set an enforcement date before the pilot starts.
• Inbound filtering only. Perimeter rules that block inbound traffic but allow any outbound connection leave command and control and exfiltration open.
• Permitted paths that carry anything. Allowing HTTPS or DNS to the internet without content or destination controls lets an attacker tunnel through the one path that is open.
• Policy defined, not enforced. Group design and permission reviews that are not backed by an enforcement point, or that a local administrator can override, give a false sense of containment.
• Exceptions without expiry. Temporary firewall rules and application control exceptions become permanent and accumulate into a flat network.
• Isolation that cannot be triggered fast. If isolating a compromised host requires a change ticket, the response action fails when it is needed most.

Practitioner checklist

• Map current controls to the five Isolate families and record which of the 52 techniques you run, partially run or do not run.
• Default-deny outbound traffic for servers, with a protective DNS resolver for all hosts.
• Application control in enforce mode on servers and privileged workstations.
• Standing administrative rights reviewed for people and for service accounts, with owners recorded.
• Inbound filtering between zones, not just at the perimeter.
• Mail and web routes inspect file format and rebuild high-risk content.
• Every deny event logged centrally, and policy changes alerted.
• A tested, rapid host isolation procedure for incident response.
• Exception process with named approvers and automatic expiry.

Standards and references

• MITRE D3FEND: Isolate Tactic
• MITRE D3FEND: Execution Isolation
• MITRE D3FEND: Network Isolation
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-41 Rev. 1 Guidelines on Firewalls and Firewall Policy
• NIST: SP 800-167 Guide to Application Whitelisting
• MITRE ATT&CK

Related NHI Mgmt Group resources: MITRE D3FEND Guide · MITRE D3FEND Network Isolation Implementation Guide · MITRE D3FEND Execution Isolation Implementation Guide · Protective DNS Guide · Network Segmentation Guide