D3FEND Content Filtering (D3-CF) Implementation Guide

Most organisations run several file controls at once, such as an email gateway, a web proxy, an upload scanner and a cross-domain import, yet few can say which of them validates, which rewrites and which only holds content, or what happens when they disagree. MITRE D3FEND groups these controls under Content Filtering (D3-CF), a technique in the Isolate tactic whose 13 descendants cover validating files against policy, modifying them into a safer form, and quarantining what fails. This guide treats D3-CF as a family: what each child technique contributes, how to choose and sequence them into one pipeline, how to test that pipeline, and what to measure. It is written for security architects, email and web security owners and detection engineers. Each child technique has its own page on this site with the deeper detail; this page is about how they fit together. For D3FEND itself see the MITRE D3FEND Guide.

Key takeaways

Content Filtering is a family of three branches. In the D3FEND ontology D3-CF has three direct children: Content Validation (D3-CV), Content Modification (D3-CM) and Content Quarantine (D3-CQ), with ten further techniques beneath validation and modification.
Validate, transform, verify, then decide. The NCSC safe import pattern puts transformation before the boundary and strict verification after it, so a verifier only ever has to check one simple format.
Quarantine is the decision branch, not a dumping ground. Every validation failure and every file that cannot be safely rebuilt needs a defined route, an owner and a release rule.
D3FEND's ATT&CK links for D3-CF are broad and inferred. The D3FEND site labels them "inferred, experimental"; the realistic core is malicious attachments and files that users open.
Measure verdicts, not deployments. Track how many files were rebuilt, stripped, blocked or released, and how many verifications failed after transformation, which should be close to zero.

What D3FEND means by Content Filtering

D3FEND defines Content Filtering as techniques that aid in analysing an input file for malicious or erroneous content and outputting a sanitised version. In the ontology D3-CF is a defensive technique that enables the Isolate tactic and enforces a Content Policy, which D3FEND describes as the rules that define what content is allowed, restricted or prohibited. The technique filters files, file content blocks, file metadata and digital media, modifies files, and quarantines files and database records. Its single reference is a content disarm and reconstruction (CDR) patent from OPSWAT, which shows where the model came from: CDR products are the most complete implementations, but the family is wider than any one product category.

Two points shape implementation. First, the content policy is the real control: without a written policy for each channel (which file types, which features such as macros or embedded objects, what size and nesting limits), every child technique has nothing to enforce. Second, Content Filtering is different from malware detection. Signature and sandbox analysis decide whether a file looks bad; content filtering decides whether a file conforms to policy and, if not, changes or holds it. That is why it still works against content that no detector has seen before.

Every child technique in the family

The table lists every technique beneath D3-CF in the D3FEND ontology, with its place in the hierarchy. Each name links to the full guide for that technique.

D3FEND technique	Parent in the ontology	Purpose in one line
D3-CV Content Validation	D3-CF	Verify and validate that content complies with policy
D3-FFV File Format Verification	D3-CV	Check that a file really is the format it claims and conforms to that format
D3-FISV File Internal Structure Verification	D3-FFV	Check sections, offsets and object tables against the format specification
D3-FCDC File Content Decompression Checking	D3-FFV	Inspect compressed content and its expansion before it is trusted
D3-FMCV File Metadata Consistency Validation	D3-FFV	Check that metadata fields agree with each other and with the content
D3-FMVV File Metadata Value Verification	D3-FFV	Check that individual metadata values are valid for the format
D3-FMBV File Magic Byte Verification	D3-FMVV	Compare the leading signature bytes with the declared type
D3-CM Content Modification	D3-CF	Modify content that does not comply with policy
D3-CFC Content Format Conversion	D3-CM	Convert to another format, often normalising or flattening
D3-CNE Content Excision	D3-CM	Remove specific, potentially malicious parts such as macros or scripts
D3-CNS Content Substitution	D3-CM	Replace a non-compliant element with a safe alternative
D3-CNR Content Rebuild	D3-CM	Rebuild the file to the specification so unreferenced components are dropped
D3-CQ Content Quarantine	D3-CF	Move non-compliant content to a quarantine zone

The D3FEND website lists the same 13 techniques but shows them flat under D3-CF; this guide follows the hierarchy in the D3FEND ontology file, where for example File Magic Byte Verification sits under File Metadata Value Verification.

How the branches fit together

The three branches answer three different questions. Validation asks "does this file conform?". Modification asks "can I make it conform without losing what the business needs?". Quarantine asks "who decides about the files that are left?". A working pipeline uses all three, in that order, and adds one more validation pass after modification.

The NCSC pattern for safely importing data gives the clearest reference design. It runs transformation, a protocol break with flow control, and verification in series, and assumes any component, including the transformation engine, could be compromised. NCSC's reasoning for the order is that transformation should be a low side activity because parsing untrusted content is inherently risky, and that once content is transformed into a format you control, the verification engine may only need to verify content in just one simple format. It also advises that any verification failure after transformation suggests the transformer has malfunctioned or been compromised, so it should raise an alert rather than simply drop the file.

A reference sequence

Type and structure checks (D3-FMBV, D3-FMVV, D3-FFV, D3-FISV): reject files whose magic bytes, extension and declared MIME type disagree, and files that do not parse cleanly.
Archive handling (D3-FCDC): unpack with limits on nesting depth, file count and expansion ratio; password-protected archives go to quarantine by default.
Policy decision (D3-CV): compare the file and its features with the content policy for that channel.
Modification (D3-CNE, D3-CNS, D3-CNR, D3-CFC): strip or replace active content, rebuild to specification, or flatten to a simpler format where fidelity allows.
Re-verification (D3-CV again): confirm the output conforms and that no active content remains; alert on any failure.
Quarantine (D3-CQ): anything that fails, cannot be rebuilt or is out of policy goes to a held store with an owner, a retention period and a release workflow.

Choosing the right child for each channel

Not every channel needs every technique. The choice depends on what the receiver must be able to do with the file and how much fidelity loss users will accept. The table is our guidance at NHI Mgmt Group, not part of D3FEND.

Channel	Typical content	Lead techniques	Trade-off to decide
Inbound email attachments	Office documents, PDFs, archives	D3-FFV, D3-CNE, D3-CNR, D3-CQ	Whether users can request the original from quarantine, and who approves
Web downloads through a proxy	Installers, documents, archives	D3-FMBV, D3-FCDC, D3-CQ	Executables are usually blocked or held rather than modified
Customer and partner uploads to an application	Images, PDFs, CSV	D3-FMBV, D3-FISV, D3-CFC	Re-encoding images or flattening PDFs removes features the business may want
Cross-domain or OT imports	Reports, configuration, data files	D3-CFC, D3-CV after the boundary	Converting to a simple format such as plain text or CSV gives the strongest verification
Collaboration and file sharing	Shared documents	D3-FFV, D3-CNE	Rewriting files in place can break version history; scan on upload instead

Decision guidance

Validation only versus modification: validation alone suits structured, low-variety inputs such as a CSV import with a schema. Rich documents need modification, because a well-formed Office file can still carry a macro.
Excision versus rebuild versus conversion: excision keeps the most fidelity but only removes what the engine recognises; rebuild drops anything not referenced by the specification; conversion to a flat format removes the most risk and the most function. Choose the strongest option users can accept per channel.
Small organisations: use the content controls built into the email and web services you already run, set macro and archive policies, and define a quarantine release process. A dedicated CDR product is rarely the first purchase.
Large and regulated organisations: centralise the content policy so the same rules apply across email, web, upload and cross-domain channels, and log every verdict to the SIEM. See the Content Disarm and Reconstruction buyer's guide.

ATT&CK techniques D3FEND relates to Content Filtering

D3FEND links D3-CF to offensive techniques through the digital artefacts both act on, and states that these mappings are "inferred, experimental, and will improve as the knowledge graph grows". For D3-CF the list is very wide, spanning Discovery, Persistence, Privilege Escalation, Credential Access, Collection, Command and Control, Exfiltration, Initial Access, Lateral Movement and Impact, because files are an artefact in almost every technique. The rows below are the subset from that list where filtering content in transit is a realistic control, with ATT&CK v20 IDs.

ATT&CK technique	Tactic	What content filtering changes
T1566.001 Spearphishing Attachment	Initial Access	Attachments are validated, disarmed or held before delivery
T1566.002 Spearphishing Link	Initial Access	Files fetched from links through a filtering proxy get the same treatment
T1204.002 Malicious File	Execution	The file a user opens no longer contains the active content
T1137 Office Application Startup	Persistence	Macros and templates are removed from documents before they reach users
T1027 Obfuscated Files or Information	Stealth	Rebuild and conversion discard hidden or padded content regardless of how it is encoded

Treat this as a test list, not proof of coverage. For the behaviours in depth see MITRE ATT&CK T1566 Phishing and T1204 User Execution.

Implementation roadmap

Write the content policy per channel. Allowed types, blocked features (macros, embedded objects, scripts in PDFs, external template references), size, nesting and archive limits, and what happens to password-protected files.
Inventory where content enters. Email, web, uploads, file transfer, removable media imports and cross-domain links. Record which child techniques each entry point already performs and whether it logs verdicts.
Run in monitor mode first. Log what would be stripped, rebuilt or quarantined for at least two business cycles, and review which business processes depend on features you plan to remove.
Enforce in rings. Start with one channel and one group, then widen. Keep a documented rollback per ring (return to monitor mode or a previous policy version) and a named owner for quarantine release.
Add re-verification and alerting. Verify modified output and alert on any failure, following the NCSC pattern.
Test regularly. Send benign test files that carry the features your policy blocks (a macro-enabled document, a nested archive, a type mismatch) through each channel and confirm both the action and the log entry.

Detection and measurement

Every filtering decision is a signal. Useful detections include the same sender or uploader hitting repeated quarantine verdicts, type mismatches where the magic bytes contradict the extension, archives that exceed nesting or expansion limits, and post-transformation verification failures, which deserve high-severity handling. Quarantine release requests are also worth reviewing: a burst of release requests for one file is a common sign of a targeted lure.

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

Channel coverage: percentage of content entry points with a written policy and logged verdicts.
Verdict mix per channel: delivered clean, modified, quarantined, blocked.
Re-verification failures: count per month, each investigated (expected near zero).
Quarantine release time and release rate, with the share released without approval.
User fidelity complaints per thousand files modified, to tune policy without silent exceptions.
Test file pass rate: percentage of scheduled test files that triggered the expected action and log line.

Framework mapping

Framework	Reference	Link to D3-CF
NIST SP 800-53 Rev. 5	SI-3 Malicious Code Protection	Protection mechanisms at entry and exit points
NIST SP 800-53 Rev. 5	SI-10 Information Input Validation	The validation branch for application inputs
NIST SP 800-53 Rev. 5	SC-18 Mobile Code, SC-44 Detonation Chambers	Policy for active content; holding content for analysis
NIST SP 800-53 Rev. 5	SC-7 Boundary Protection	Where filtering sits in the architecture
NIST CSF 2.0	DE.CM-09, DE.AE-02	Monitoring content and analysing adverse events
NCSC	Pattern: safely importing data	Transformation, protocol break and verification in series

Common failure patterns

No written content policy. Products run on defaults, so each channel enforces different rules and nobody can say why a file was allowed.
Password-protected archives allowed through. The filter cannot open them, so they bypass every child technique; hold them by default.
Quarantine without ownership. Users or helpdesk staff release held files on request with no review, which turns D3-CQ into a delay rather than a control.
No re-verification. A transformation engine that silently fails or is bypassed is never noticed.
Silent exceptions. Whole departments exempted from macro stripping after a complaint, never revisited.
Uploads outside the pipeline. Application upload paths and file transfer services built by product teams often skip the filtering used for email and web.

Practitioner checklist

Write a content policy for each entry channel, including archive and password-protected file rules.
Map each of the 13 D3-CF techniques to the entry points that perform it.
Sequence validation, modification, re-verification and quarantine in that order.
Run new policies in monitor mode for two business cycles, then enforce in rings with a rollback plan.
Give quarantine a named owner, retention period and approval rule for release.
Alert on any verification failure after transformation.
Send scheduled test files through every channel and check the action and the log.
Report verdict mix, re-verification failures and release metrics quarterly.

MITRE D3FEND Content Filtering Implementation Guide: Choosing, Combining and Measuring File Sanitisation Controls