MITRE D3FEND Execution Isolation Implementation Guide: Choosing, Combining and Rolling Out Its Five Techniques

Most endpoint estates run some form of application control and some form of process isolation, but few teams can say which code is allowed to run, which processes can reach which memory, and how those layers fit together. MITRE D3FEND groups these controls under Execution Isolation (D3-EI), a technique in the Isolate tactic with five child techniques: two that decide whether code may run at all, and three that limit what running code can reach. This guide treats D3-EI as a programme: what the family covers, how to choose and sequence the children, how to prove the layers work, and where they fail. It is written for endpoint, platform and detection engineers. Each child technique has its own deep guide on this site, linked below; this page does not repeat them. For D3FEND itself see the MITRE D3FEND Guide.

Key takeaways

• Execution Isolation has two halves. Executable Allowlisting and Denylisting decide whether a file may start a process; hardware, kernel and application based process isolation decide what a running process can touch.
• D3FEND's definition is about resources, not files. The family exists to stop application processes reaching non-essential memory, devices or files, so allowlisting alone only delivers part of it.
• Sequence by blast radius. Start with allowlisting on servers and privileged workstations, add kernel isolation for internet-facing services, and treat hardware and application based isolation as platform and engineering choices.
• Audit mode first, always. App Control, AppLocker, fapolicyd, SELinux and seccomp all offer a log-only or permissive path; use it for at least two business cycles before enforcing.
• The ATT&CK links are inferred. D3FEND labels its offensive mappings for D3-EI "inferred, experimental", so use them to plan tests, not to claim coverage.

What D3FEND means by Execution Isolation

In the D3FEND ontology, Execution Isolation (D3-EI) is a defensive technique that enables the Isolate tactic. Its definition reads: "Execution Isolation techniques prevent application processes from accessing non-essential system resources, such as memory, devices, or files." The parent itself carries no digital artefact relations; those sit on the children, which either block executable files and filter process creation, or isolate processes and restrict what they can call.

That split matters in practice. Allowlisting and denylisting act once, at the moment a process is created. Process isolation acts for the whole life of the process. An attacker who abuses an approved binary, injects into a trusted process or exploits a memory bug in an allowed application has already passed the first gate, and only the second half of the family still applies. D3FEND also models Access Mediation separately: System Call Filtering (D3-SCF), for example, sits under Access Mediation rather than Execution Isolation, even though teams often deploy it beside kernel isolation. See the MITRE D3FEND Access Mediation Implementation Guide.

The child techniques

The table lists every child of D3-EI in the D3FEND ontology, with D3FEND's own definition paraphrased and the typical way it is delivered. Delivery examples are illustrative, not recommendations.

Choosing and combining the children

The five children answer different questions, and an estate needs a position on each. The second table summarises who owns each one, what it stops, and what it does not.

Decision guidance

• Allowlisting or denylisting: allowlisting is the stronger control, and NIST SP 800-167 covers how to plan and deploy it across its lifecycle; denylisting is a compensating layer where an allowlist is not yet feasible, and a useful addition on top of an allowlist for approved binaries you want to block for most users.
• Servers before workstations: servers run a small, stable set of software, so an allowlist is cheaper to build and maintain there. Developer and research workstations are the hardest case; D3FEND's own considerations note that organisations creating high volumes of software find allowlisting complex to manage.
• Kernel isolation for exposed services: anything that parses untrusted input, such as web servers, mail gateways and file converters, should run with its own namespaces, a mandatory access control profile and a reduced system call set.
• Hardware and application isolation are mostly bought, not built: you choose platforms and applications that use them and keep them switched on, rather than implementing them yourself. The exception is in-house software that handles untrusted content, where application based isolation is an engineering decision.
• Small organisations: start with the operating system's built-in application control features, kept in their default or evaluation modes, plus vendor defaults for browser sandboxing, rather than custom policy.
• Large and regulated organisations: run custom allowlists per server role, enforce mandatory access control on Linux fleets, and require isolation features in procurement for software that processes untrusted data.

Implementation roadmap

1. Inventory what runs. Collect process creation telemetry (Windows Security event 4688 or Sysmon event 1, Linux auditd execve records) across server roles and workstation types for at least two weeks. This becomes the baseline for D3-EAL rules and shows which binaries D3-EDL rules would hit.
2. Record current isolation state. For each server role and container platform, note whether mandatory access control is enforcing or permissive, whether containers run with a seccomp profile, and whether virtualisation based protections are enabled on Windows endpoints.
3. Deploy allowlisting in audit mode. Use signer and path rules over hash rules where the tool supports them, since hash rules break on every update. App Control, AppLocker and fapolicyd all support an audit or permissive path.
4. Tighten kernel isolation on exposed services. Move permissive MAC profiles to enforcing, apply the container runtime's default seccomp profile at minimum, and drop unneeded Linux capabilities. Note that the Linux kernel documentation states plainly that system call filtering "isn't a sandbox": it is one building block alongside namespaces and an LSM.
5. Enforce in rings. Pilot on a small group, then a business unit, then the estate. Keep a documented rollback for each ring: switch the policy back to audit, or revert to the previous policy version, with a named owner who can do it out of hours.
6. Add denylist rules last. Once the allowlist is enforced, add deny rules for approved but rarely needed system binaries that attackers abuse, scoped to users who do not need them.
7. Test. In a test environment, run benign samples of the behaviours in the next section and confirm both a block and a log line.

ATT&CK techniques D3FEND relates to D3-EI

D3FEND links defensive and offensive techniques through the digital artefacts both act on, and labels these offensive mappings for Execution Isolation "inferred, experimental". The parent page lists techniques across Privilege Escalation, Stealth, Discovery, Execution, Persistence, Impact, Credential Access, Lateral Movement and Defense Impairment. The table groups a representative selection by tactic, using ATT&CK v20 IDs. Where D3FEND still lists a retired Impair Defenses sub-technique, the v20 successor is shown instead.

The "child most likely to act" column is NHI Mgmt Group's reading of where each behaviour meets the family, not a D3FEND mapping. See the T1055 Process Injection Defensive Guide, T1218 System Binary Proxy Execution Defensive Guide and T1574 Hijack Execution Flow Defensive Guide for those behaviours in depth.

Where identity fits

Allowlisting and isolation decisions are increasingly tied to the identity of code and of the service account it runs as. Signer rules trust a code signing identity, so the security of D3-EAL depends on how well your own signing keys and certificates are protected. Service accounts that run isolated processes should hold only the rights the isolation profile assumes; a tightly confined process running as a domain administrator still carries that credential. See the Least Privilege Techniques Guide.

Detection and measurement

Each child produces evidence. Allowlisting tools log blocked and audited executions (on Windows, App Control events appear in the CodeIntegrity Operational log). Mandatory access control produces SELinux AVC denials or AppArmor DENIED records. The seccomp LOG action records filtered calls when "log" is present in the actions_logged sysctl. Useful detections include an audited or blocked execution on a server, an AVC denial from an internet-facing service, and a new parent and child process pair that has never appeared in the baseline.

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

1. Allowlist coverage: percentage of servers and workstations with an enforced allowlist, by role.
2. Enforcement ratio: percentage of allowlist and MAC policies in enforce rather than audit mode.
3. Exposed service confinement: percentage of internet-facing services running with an enforcing MAC profile and a seccomp profile.
4. Exception debt: number of open allowlist exceptions and their median age.
5. Emulation pass rate: percentage of tested ATT&CK behaviours that produced both a block and an alert.

Framework mapping

See M1038 Execution Prevention and M1048 Application Isolation and Sandboxing.

Common failure patterns

• Allowlisting treated as the whole family. Approved binaries and in-memory techniques pass the gate; without process isolation nothing limits them afterwards.
• Audit mode as the end state. Policies left in audit or permissive mode for years look like coverage on a dashboard and stop nothing.
• Broad path rules. Allowing whole user-writable directories, such as a downloads or temp folder, turns the allowlist into a denylist with extra steps.
• Containers without a profile. Running containers unconfined or privileged removes the kernel isolation the platform would otherwise provide. See the Container Runtime Security Guide.
• Hash-only rules. Every update breaks them, which creates pressure to switch the policy off.
• Treating inferred mappings as coverage. A D3FEND link from D3-EI to an ATT&CK technique is a test idea, not evidence.

Practitioner checklist

• Record, per server role and workstation type, the state of each of the five D3-EI children.
• Baseline process creation for two weeks before writing allowlist rules.
• Prefer signer and path rules; avoid user-writable allowed paths.
• Run allowlisting and MAC policies in audit mode for two business cycles, then enforce in rings with a rollback owner.
• Confine every internet-facing service with namespaces, an enforcing MAC profile and a seccomp profile.
• Keep platform hardware and virtualisation based protections enabled, and require application sandboxing in procurement where software handles untrusted content.
• Add deny rules for abused system binaries after the allowlist is enforced.
• Emulate the mapped ATT&CK behaviours and confirm both a block and an alert.

Standards and references

• MITRE D3FEND: Execution Isolation
• MITRE D3FEND: Executable Allowlisting
• MITRE D3FEND: Kernel-based Process Isolation
• NIST: SP 800-167 Guide to Application Whitelisting
• Microsoft Learn: App Control for Business
• Linux kernel documentation: Seccomp BPF
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: MITRE D3FEND Guide · Application Allowlisting Guide · App Control for Business (WDAC) · Linux Namespaces and cgroups Security Guide · MITRE D3FEND Access Mediation Implementation Guide