Zero Trust Spectrum
Zero Trust Spectrum · Files CyBOK aligned NCSC aligned NIST SP-800-207 aligned

Deterministic File Assurance for Zero-Trust Programs

The Zero Trust Spectrum (ZS-1 → ZS-6) provides a CyBOK-aligned language for rating how files are inspected, sanitized, isolated, or deterministically rebuilt-complete with per-dimension scores, validation tests, and governance signals for Zero-Trust architectures.

Who this is for

CISOs, Zero-Trust program owners, security engineers, platform/product teams, delivery partners.

Use it for

Pick the minimum assurance that still satisfies risk, usability, and compliance.

Download

PDF: Rating Scale & Levels

📘Zero-Trust Spectrum (Files) Overview

The Zero-Trust Spectrum defines six progressive assurance levels (ZS-1 → ZS-6) describing how files are verified, controlled, and evidenced within zero-trust architectures. Levels advance from detection-based trust (ZS-1/2) to deterministic rebuild and independent verification (ZS-6). The framework is aligned with NIST SP-800-207, UK NCSC Zero-Trust Architecture, and CyBOK principles and published under CC BY 4.0 for open reference and adoption.

Contents

Orientation

Decide & Apply

Operate

Alignment

Resources

Mission Snapshot

Purpose

Declarative framework for deciding file-handling requirements inside Zero-Trust architectures.

Scope

Email & collab · Web/SWG/ICAP · APIs · Storage · Kiosks · Air-gapped/CDS · SDK/Embedded · File import/export

Audience

Security architects, platform teams, regulated industries, product leaders building trusted data flows.

Rating Scale & Dimensions

Every ZS level is scored 0 → 4 across six dimensions so buyers can compare like-for-like claims.

Scale (0 → 4)

  • 0 None / Heuristic

    Detection or reputation only; no structural enforcement.

  • 1 Basic

    Coarse rules or feature stripping; limited validation, best-effort only.

  • 2 Moderate

    Isolation/flattening; limited spec awareness.

  • 3 Strong

    Allow-only or spec-aware validation/repair with detailed logs.

  • 4 Deterministic

    Model-driven rebuild with reproducible outcomes for supported formats.

Dimensions

  • Mechanism rigor Strength of the control mechanism irrespective of detections.
  • Assurance evidence Quality of conformance proof, determinism, validators, provenance.
  • Usability fidelity How much editability and workflow fidelity is preserved.
  • Validation test rigor Depth of acceptance tests teams can run independently.
  • Auditability Chain-of-custody, tamper evidence, and investigative readiness.
  • Threat coverage Active content, parser exploits, nests, obfuscation, signed content, unknowns.

📊ZS-Level Definitions

LevelLabelCore MechanismDescription
ZS-1Pass-throughImplicit trustFiles accepted without verification; basic metadata checks only.
ZS-2DetectionKnown-threat identificationSignature/hash/pattern recognition detects known threats but cannot assure safety.
ZS-3Isolation / FlatteningBehavioural containmentExecutes or renders files in controlled environments to prevent direct interaction.
ZS-4SanitisationRule-based removalStrips or deactivates risky features (macros, scripts, links) within the original file.
ZS-5TransformRebuild from known-good templateParses and reconstructs files to conform to safe models; removes unsafe components.
ZS-6Deterministic RebuildClean intermediary modelFiles fully deconstructed and rebuilt from specification; no source bytes retained; output verified with audit evidence.

📄Flat-file Export / Import

Flat-file export/import is an essential control boundary. Many Zero-Trust architectures require exporting processed content to a flat, policy-governed format (XML, CSV, JSON, TXT, PDF/A) before re-ingestion or cross-domain movement.

⚙️Decision Quick Picks

Operational note: Modern ZS-6 rebuild engines routinely deliver sub-100 ms latency for mid-size documents and scale horizontally in containerized deployments.

📐Classification Criteria

DimensionZS-1ZS-2ZS-3ZS-4ZS-5ZS-6
Content verificationNonePartial (signatures)Partial (behavioural)ModerateFullFull (spec-level)
Structural enforcementNoneNonePartialModerateFull (software)Full + independent verification
Policy conformanceNoneBasicContextualEnforced rulesFullFull, provable
Audit evidenceNoneMinimalLimited logsModerateComprehensiveDeterministic & tamper-evident
Fidelity / usabilityFullFullRead-onlyHighHighSpec-compliant

Evidence expectations: Classifications above ZS-4 require conformance testing, proof no source-file bytes persist, policy enforcement traceability, validation/verification steps, and reproducible audit trails.

🧱Zero Trust Spectrum Levels

ZS-1 · Baseline Pass-through / Uninspected
  • Mechanism rigor
    0 None / Heuristic

    Allow/forward or AV-only; enforcement is purely detection based.

  • Assurance evidence
    0 None / Heuristic

    No structural proof, determinism, or provenance beyond AV verdicts.

  • Usability fidelity
    4 Deterministic

    Full editability and zero latency because files are untouched.

  • Validation test rigor
    0 None / Heuristic

    Malformed or macro-laden samples still pass, revealing lack of control.

  • Auditability
    0 None / Heuristic

    Only coarse pass/fail telemetry; no tamper-evident chain of custody.

  • Threat coverage
    0 None / Heuristic

    No mitigation for macros, parser exploits, nesting, obfuscation, or unknowns.

ZS-2 · Policy Rule-based Sanitization
  • Mechanism rigor
    1 Basic

    Policy strips macros/scripts/links yet leaves underlying structure untouched.

  • Assurance evidence
    1 Basic

    Evidence is limited to policy-hit logs; little spec validation.

  • Usability fidelity
    3 Strong

    High usability apart from removed risky features.

  • Validation test rigor
    1 Basic

    Seed macros/OLE to verify removal plus reason codes.

  • Auditability
    1 Basic

    Lists of removed constructs, but minimal per-object provenance.

  • Threat coverage
    1 Basic

    Handles common active content yet struggles with parser or obfuscated attacks.

ZS-3 · Isolation Flatten / Isolate
  • Mechanism rigor
    2 Moderate

    Static rendering or remote isolation keeps active content away from endpoints.

  • Assurance evidence
    2 Moderate

    Isolation telemetry shows containment but not rebuild-grade determinism.

  • Usability fidelity
    1 Basic

    Mostly read-only or limited interactivity—great for triage, not authoring.

  • Validation test rigor
    2 Moderate

    Deliver active content and confirm flattened or isolated presentation.

  • Auditability
    2 Moderate

    Session logs and release/deny trails support investigations.

  • Threat coverage
    2 Moderate

    Neutralizes active content during viewing; downloads may still carry original bytes.

ZS-4 · Allow-only Allow-only (DDR)
  • Mechanism rigor
    3 Strong

    Positive selection copies only allow-listed structures into safe templates.

  • Assurance evidence
    3 Strong

    Template coverage and exception manifests provide repeatable assurances.

  • Usability fidelity
    3 Strong

    High usability for modelled features; coverage gaps require new templates.

  • Validation test rigor
    3 Strong

    Inject allowed/disallowed elements and observe copy/drop evidence.

  • Auditability
    3 Strong

    Template IDs, policy versions, and exception logs support traceability.

  • Threat coverage
    3 Strong

    Covers modelled embeds/nests/obfuscation but only where templates exist.

ZS-5 · Repair Deep Parsing & Repair
  • Mechanism rigor
    3 Strong

    Spec-aware parsing plus repair/sanitise routines enforce structure; outputs can be emitted in the native format or optional flat-file exports, but still reference original structure.

  • Assurance evidence
    3 Strong

    Validation/repair logs act as conformance evidence per object.

  • Usability fidelity
    4 Deterministic

    Maintains authoring fidelity while repairing defects deterministically.

  • Validation test rigor
    3 Strong

    Spec-violating samples should surface precise repair telemetry.

  • Auditability
    3 Strong

    Per-object validation traces, repair counts, and policy diffs.

  • Threat coverage
    3 Strong

    Covers macros, parser exploits, nests, and obfuscation for supported formats; optional flat-file exports aid downstream review but remain tied to sanitized source semantics.

ZS-6 · Rebuild True Rebuild (Safe Blueprint)
  • Mechanism rigor
    4 Deterministic

    Model-driven rebuild outputs new spec-compliant files with no unsafe bytes and can natively export/import neutral flat files (XML/JSON/CSV/PDF-A) for air-gap or analytic flows.

  • Assurance evidence
    4 Deterministic

    Validators plus provenance prove deterministic results per file.

  • Usability fidelity
    4 Deterministic

    Full fidelity for supported formats while eliminating risky source bytes.

  • Validation test rigor
    4 Deterministic

    Diff input/output, review validator logs, and confirm provenance packages.

  • Auditability
    4 Deterministic

    Signed manifests, hashes, policy IDs, and tamper-evident logs per submission.

  • Threat coverage
    4 Deterministic

    Mitigates macros, parser exploits, nests, obfuscation—flat-file export/import provides a clean break for cross-domain transfer; fallbacks defined for unsupported formats.

Each tier defines how the control handles encrypted payloads, nested archives, macros, scripts, active content, media, metadata, and unsupported formats. Advance maturity when operational risk or regulatory posture demands it.

Summary: ZS-1 pass-through · ZS-2 policy sanitize · ZS-3 flatten/isolate · ZS-4 positive selection · ZS-5 deep parsing & repair · ZS-6 deterministic rebuild.

🔍Evaluation Cues

📋Evaluation Criteria

Functional

  • Mechanism type and visibility (pass, sanitise, rebuild).
  • Encrypted/password-protected handling.
  • Nested/archived content support.
  • Export/import to flat structured formats (CSV, XML, JSON, TXT, PDF/A).
  • Ability to rebuild directly from validated flat data for deterministic ZS-6 workflows.
  • Policy configuration depth per format/feature.

Governance & Interop

  • Policy versioning, audit trails, and tamper-evident logs.
  • DLP/SOAR/SIEM integration and open telemetry (API/syslog).
  • Export sanitised/rebuilt outputs to safe zones; store or transmit clean flat files as audit artifacts and cross-domain handoffs.
  • Open standards, schema alignment, and reproducible SLO reporting.

🧩Integration Patterns

Core processing flows

  • Email / Collaboration (inline or API): M365, Google Workspace, SEG, SMTP relay, API ingestion.
  • Web / SWG / Proxy (ICAP / reverse-proxy / WAF): upload & download enforcement with identity-aware policies.
  • Storage / Archive (on-ingest + scheduled): S3, NAS, SharePoint, Azure Blob with retention/governance hooks.
  • Application / SDK / API (sync / async): deep embedding into custom apps, brokers, or zero-trust gateways.

Operational & isolated environments

  • Kiosk / Air-gap / Cross-domain (CDS): export/import via neutral flat files; deterministic rebuild between networks.
  • OT / Industrial / Classified networks: deterministic enforcement at transfer guard boundaries with policy directionality.

Automation & ecosystem integration

  • SOAR / DLP / SIEM / UEBA: event forwarding, orchestration hooks, automated remediation.
  • EDR / XDR / Email Security / CASB: complementary enforcement via shared telemetry and policy alignment.
  • Data Governance / Compliance / Audit: policy reports, per-file assurance logs, retention labeling, regulatory evidence.

Developer & operational enablement

  • CLI / Container / K8s operators: scalable cluster processing with declarative pipelines.
  • API Gateway / ESB / Workflow engines: inline validation for automated data exchange.
  • Flat-file export / import: deterministic output/input for analytics, ETL, SIEM/DLP, or cross-domain transfer.

📁File Coverage Reality Check

Breadth ≠ depth. Build a file-coverage register and rate each format by mechanism and fallback.

Office & Productivity PDF & Print Streams CAD / BIM Media & Imagery Archives & Containers Custom / Legacy Formats

Active content

Macros, scripts, JS, OLE, XFA, plug-ins.

Parser exploits

Memory corruption, malformed structures, decompression abuse.

Embedded & nested

Linked objects, nested archives, container recursion.

Obfuscation

Polyglots, malformed metadata, stego tricks.

Signed content

Trusted-but-malicious or expired signatures; re-signing expectations.

Unknown / 0-day

Unsupported formats or feature abuse—define default fallbacks.

🧪Validation Tests & Signals

Dataset essentials: macros/OLE, PDF JS & launch actions, nested archives (depth > 5), polyglots (PDF/ZIP), malformed EXIF/media metadata, passworded samples, malformed containers.

Expectations:

Signals to emit: outcome code, reason, elements copied/removed/repaired, validator findings, archive tree, input/output hashes, policy version, latency/error stats.

🛡️Guardrails & Defaults

Encrypted / Passworded

  • Block or decrypt inside a trusted zone before processing.
  • Never emit original bytes; log crypto metadata and avoid storing plaintext.

Archives & Nesting

  • Recurse with safe depth/size limits.
  • Apply the target ZS level to each extracted item and rebuild deterministically.
  • Detect polyglots and MIME/type mismatches.

Unknown / Unsupported

  • Default to block or ZS-3 isolate.
  • Time-bound exceptions with precise telemetry.

Signed Content

  • Validate before processing.
  • Preserve provenance metadata; re-sign outputs in a trusted zone when signatures must persist.

🧠Implementation Moments that Matter

Integration Surface

ICAP, REST, event-driven, inline or asynchronous flows, SDK kits for embedded OEM or on-device use (M365 Graph, SharePoint, Google Drive APIs, etc.).

Assurance Proof

Signed manifests, replayable logs, policy versioning, attestation packages per submission.

Human Factors

UI/UX for releases, exception handling, succinct user messaging, governance dashboards.

PoV & SLO discipline

Measure p95/p99 latency and sustained throughput per format/level on intended infrastructure, track fidelity and error handling, publish SLOs by flow (email/web/storage/API) with the chosen ZS per format.

📚CyBOK Alignment Signals

🛡️NCSC Alignment Signals

🏛️NIST SP 800-207 Alignment Signals

❓FAQ

How are ZS levels used?

Each level maps to a measurable assurance state. Assign targets per workflow based on usability, risk, and compliance signals.

Do higher levels replace lower ones?

No—you often blend tiers. Critical ingress/egress runs ZS-6 while productivity paths stay on ZS-5/4.

Does ZS-6 eliminate all threats?

ZS-6 minimizes dependence on detection by rebuilding structure, but you still monitor residuals like unsupported formats or policy drift.

What should I measure?

Track throughput, P50/95/99 latency, error & bypass rates, unsupported-format counts, and policy drift alerts.

ℹ️Glossary

Key terms referenced across ZS levels and evaluation criteria.

Content Disarm & Reconstruction (CDR)

Deterministic extraction and rebuild of file content. See reference.

Positive Selection / DDR

Copy only known-good elements into safe templates (ZS-4). Unknown items are removed by policy design.

Flat-file export/import

Neutral CSV/XML/JSON/TXT/PDF-A outputs used for cross-domain transfer, archival, or deterministic re-ingestion.

Policy Enforcement Point (PEP)

A control plane described in NIST SP 800-207; here it is the file-processing tier mediating untrusted inputs.

Deterministic rebuild

ZS-6 capability to create a clean intermediary model and emit a fresh spec-compliant file with provenance.

Validation test harness

Repeatable dataset + telemetry capture used to verify claims (sometimes called “buyer tests”).

🔗References

  1. NIST SP 800-207 – Zero Trust Architecture (Dec 2020)
  2. NCSC Zero-Trust Architecture Collection
  3. CyBOK – Cyber Security Body of Knowledge
  4. Creative Commons BY 4.0 License