Content Disarm and Reconstruction¶
Sanitization tool — instantiates Transitive Trust Boundary Hardening
Rebuilds an incoming file into a known-clean equivalent instead of trying to detect what is wrong with it, so a hidden payload is dropped in reconstruction whether or not it was ever recognized.
Detection asks "is this file bad?" and fails on anything it has not seen. Content Disarm and Reconstruction (CDR) refuses to ask the question at all. It assumes an incoming file may be hostile and neutralizes it by rebuilding rather than judging: extract the legitimate content, discard everything active or structural that could carry a payload — macros, embedded scripts, embedded objects, malformed structures — and regenerate a fresh, clean file. Its defining move is being threat-agnostic: because it drops active content by construction rather than by recognizing a signature, it works on unknown and zero-day payloads it could never have detected. It is the admission boundary that neutralizes content instead of verifying it.
Example¶
A bank's claims department receives thousands of customer documents a day — PDFs and Office files — from senders it cannot vet. Even a document from a verified, known sender can carry a malicious macro or a crafted-PDF exploit: trust in the sender does not make the file safe, and the sender's own machine may be compromised. Rather than scanning for known-bad, the ingestion pipeline runs each file through CDR inside an isolated staging zone. A PDF is parsed down to its visible content and re-rendered to a new PDF with no embedded JavaScript; a DOCX is stripped of macros and rebuilt. The reconstructed file crosses into the internal systems; the original never does. An exploit hidden in a font table or an auto-open macro is simply not carried across — no one had to know it was there.
How it works¶
Treat the file as untrusted data, not as something to authenticate: extract only the intended content, discard everything active or structural that could smuggle a payload, and regenerate a clean artifact in a controlled staging zone. The original is never admitted — only the reconstruction crosses the boundary. Security comes from reconstruction, not recognition, which is exactly why it does not depend on knowing the threat and does not attempt to verify origin.
Tuning parameters¶
- Fidelity versus safety — how much rich content and formatting to preserve versus strip. Aggressive stripping is safer but can break legitimate active content; this is the core dial and the one attackers hope you loosen.
- File types and depth — which formats are handled and how deep (nested archives, embedded objects). Unhandled or deeply-nested content is a gap.
- Rebuild target — reconstruct to the same format or flatten to a simpler, safer one (e.g., render to an image-only PDF).
- Staging isolation — how strongly the disarm environment is sandboxed, so processing a hostile file cannot compromise the processor itself.
- Original-handling policy — quarantine the source for recovery versus destroy it; retained originals must never be a path back in.
When it helps, and when it misleads¶
Its strength is neutralizing unknown, file-borne payloads at the moment of admission, with no reliance on detection — precisely the case where a trusted sender lulls a consumer into accepting a dangerous file.
Its failure mode is collateral: reconstruction can strip legitimate functionality — a needed macro, an interactive form, a digital signature on the document — causing false-positive damage to content, and it cannot preserve what it does not understand.[1] It defends the file channel only; it says nothing about a malicious credential, instruction, or live protocol. The classic misuse is relaxing the fidelity settings until active content is passed through "so things stop breaking," which quietly reopens the hole the tool was closing. The discipline: keep reconstruction threat-agnostic and default-strip, and keep any retained original in quarantine for recovery — never as an admission path.
How it implements the components¶
payload_admission_boundary— CDR is the admission boundary for file content: nothing crosses except a freshly-reconstructed, payload-free equivalent, so the untrusted original never enters.quarantine_and_staging_zone— the disarm-and-rebuild happens inside an isolated staging zone where the untrusted original is processed and held (or destroyed), contained away from the systems it is destined for.
It does not verify origin or signatures (Artifact Signature Verification) — it assumes it cannot; it does not detect threats by executing them and observing behavior (compromise_assumption_model, Sandboxed Payload Execution); and it does not bound a payload's blast radius after admission (blast_radius_boundary, Canary Rollout with Kill Switch).
Related¶
- Instantiates: Transitive Trust Boundary Hardening — hardens the file-admission boundary so a trusted sender no longer implies a safe file.
- Sibling mechanisms: Sandboxed Payload Execution · Canary Rollout with Kill Switch · Artifact Signature Verification · Quarantine Release Workflow
Notes¶
CDR and detonation-style sandboxing are complementary opposites. CDR neutralizes without knowing the threat by rebuilding the file; a sandbox tries to observe the threat by executing it and watching. CDR's honest trade is that it buys threat-agnostic safety at the cost of some fidelity — it can quietly remove something legitimate — whereas a sandbox preserves the file but can be evaded by payloads that stay dormant under observation.
References¶
[1] CDR applies a zero trust stance to content: the file is treated as untrusted no matter who sent it, so it is rebuilt rather than believed. The trade is inherent — distrusting every file's active content means occasionally discarding active content that was legitimate. ↩