Tessera for Cross Domain — STANAG-Compliant Cross-Domain Solution

The Cross-Domain Challenge

Classified networks operate under security policies that define what information can be created, handled, and shared within each domain. Those policies reflect different classification ceilings, different coalition memberships, and different need-to-know requirements.

Yet operators and systems in different domains regularly need to exchange information — tasking orders, intelligence reports, situation reports. When that information crosses a domain boundary, both security policies must be satisfied simultaneously: the originating domain's policy must confirm the label is valid, and the destination domain's policy must confirm the information is releasable to that domain.

Human-enforced transfer processes are slow, error-prone, and do not scale. Manual review cannot keep pace with operational information flows, and a single oversight can expose classified material to an unauthorised domain.

          Tessera for Cross Domain automates this enforcement.
          Every information flow is evaluated against both domain security policies by a
          Guard — the only permitted path between domains. There is no human in the loop
          for the policy decision, and there is no bypass path.
        

High-Side Domain

NATO SECRET ceiling · HS SPIF

HS Users / MTA

↓

HS Proxy

Label validation
DLP scan

↓

Guard

validate HS SPIF
validate LS SPIF

ALLOW → forward

DENY → NDR

audit every decision

Low-Side Domain

NATO UNCLASSIFIED ceiling · LS SPIF

LS Users / MTA

↓

LS Proxy

Label resolution
Malware scan
CDR apply

↓

Security Model

Five principles that define the security posture of Tessera for Cross Domain.

Dual-SPIF Enforcement

Every information flow is evaluated against both domain SPIFs in a single atomic decision. The originating SPIF confirms the label is valid and properly formed; the destination SPIF confirms the information is releasable to that domain and within its ceiling. Both must agree.

Guard-Only Crossing Path

No network path exists between the High-Side and Low-Side zones except through the Guard. There is no connection that spans both zones. Every packet crossing the domain boundary transits the Guard's forward chain — there is no bypass and no exception.

Fail-Closed

Any error at any stage — SPIF loading failure, label parsing error, scanner failure, CDR failure — results in a DENY. There is no pass-through state, no "allow on timeout", and no ambiguous outcome. The Guard will not forward content it cannot fully evaluate.

Label Binding Preserved

The STANAG 4778 Binding-Data CMS SignedData in the payload is applied before the Guard Input Format (GIF) is constructed and is preserved unchanged through the pipeline. The destination proxy delivers the Guard-approved payload without modification — no rebinding or re-wrapping occurs.

Complete Audit Trail

Every Guard decision — ALLOW and DENY — is recorded with the flow direction, source and destination identity, confidentiality label, label derivation method, filter results, and timestamp. Audit records are immutable and stored in the Guard zone, isolated from both HS and LS management networks.

Three-Legged Topology

Each zone firewall has three interfaces — external (user networks), internal (zone services), and guard zone — mirroring the physical appliance topology. All inter-segment traffic transits the firewall's forward chain. The software topology is designed for direct replacement by physical hardware appliances.

Email Processing Pipeline

High-to-Low (HS→LS) and Low-to-High (LS→HS) flows follow distinct pipelines. Each stage is a policy enforcement point; failure at any stage blocks the flow.

High-to-Low (HS → LS)

Label validation STANAG 4778 Binding-Data header verified: CMS SignedData signature checked against HS label-binding CA

DLP scan Data loss prevention check on content and attachments

Malware scan All body parts and attachments are malware-scanned; scanner failure = DENY

GIF construction Guard Input Format assembled: label, flow metadata, filter results

Dual-SPIF evaluation Guard evaluates HS SPIF (label validity) and LS SPIF (releasability and ceiling)

Delivery Guard-approved payload forwarded to LS proxy then to LS MTA without modification; DENY → RFC 3464 NDR to HS sender

Low-to-High (LS → HS)

Label resolution A — Binding-Data present & valid → use binding classification
B — FLOT present, no binding → derive from First Line of Text
C — Both present → use higher; flag discrepancy if they differ
D — Neither present → reject (no security marking)

Malware scan All content is malware-scanned; scanner failure = DENY

Content Disarm & Reconstruct (CDR) Office and PDF attachments converted to pixel-safe PDF via sandboxed pipeline, eliminating active content; CDR failure = DENY

Label binding New STANAG 4778 Binding Data Object (BDO) signed with LS label-binding key and attached to CDR output

Dual-SPIF evaluation Guard evaluates LS SPIF (label validity) and HS SPIF (releasability and ceiling)

Delivery Guard-approved payload forwarded to HS proxy then to HS MTA; DENY → RFC 3464 NDR to LS sender

Security Controls

Malware scanning — all content scanned before Guard submission; scanner connection failure is treated as a detected threat and the flow is rejected.
Content Disarm & Reconstruct (CDR) — Office and PDF content is converted to pixel-safe PDF via a sandboxed pipeline, eliminating active content and embedded macros. Applied to all L2H document attachments.
Data Loss Prevention (DLP) — outbound H2L flows are checked for policy-violating content patterns before Guard submission.
mTLS everywhere — all internal connections between proxies and the Guard use mutual TLS. Client certificates are validated against the zone trust store; revocation is checked via CRL.
Four-tier PKI hierarchy — an offline root CA, an online intermediate CA, a proxy mTLS CA, and a label-binding CA. Certificate lifetime is deliberately short; CRL distribution is automated.
OIDC identity federation — operator access to management interfaces is authenticated via an OIDC identity provider with role-based access control.

Infrastructure

Zone-Segmented Deployment

Six logical network segments: HS External, HS Internal, HS Guard Zone, LS Guard Zone, LS Internal, and LS External. Each firewall spans three segments with a default-deny forward chain. No network connection spans zone boundaries.

Containerised Services

30+ services across DNS, NTP, PKI, email proxy, CDR, malware scanning, monitoring, and management — each independently deployable and health-checked. All inter-service communication is zone-local, consistent with the physical appliance topology the deployment models.

Physical Appliance Migration Path

The zone firewalls and Guard mirror the physical three-legged appliance topology. Firewall rulesets for physical appliances are included; rules are exportable from the management UI for import into hardware.

Standards Implemented

STANAG 4774

Confidentiality Labels

XML Confidentiality Label format; classification and category encoding evaluated against domain SPIFs for every flow.

STANAG 4778

Binding Data Object (BDO)

CMS SignedData validation (HS→LS) and generation (LS→HS); ADatP-4778.2 binding profiles for OOXML, XMP, and sidecar.

ACP-240

Zero Trust Data Format

ABAC policy enforcement referencing ACP-240 attribute URI conventions for classification and category assertions in GIF flows.

XMLSPIF v2.1/3.0

Security Policy

Full SPIF parsing for both domain policies; dual-SPIF evaluation for every crossing decision.

RFC 5652

CMS SignedData

Cryptographic Message Syntax for STANAG 4778 Binding Information Object signing and verification.

RFC 3464

Delivery Status Notifications

RFC-compliant Non-Delivery Reports (NDR) generated on DENY, informing the originating sender of the rejection reason.

View full standards reference →