What is the difference between a CDS guard and a SIEM alert for cross-domain data movement?

A SIEM (Security Information and Event Management) system monitors and alerts on detected anomalies in data movement — it is a detective control. A CDS guard is a preventive control: it enforces a policy decision at the moment of transfer and physically blocks non-compliant content from crossing the domain boundary. SIEMs can be tuned to detect patterns suggesting data exfiltration attempts (large outbound transfers at unusual hours, access from unexpected accounts), but they cannot prevent a transfer that has already completed. A CDS guard stops the transfer before it happens. Defense programs require both: the guard as the primary enforcement mechanism and a SIEM receiving the guard's audit logs to detect attack patterns, repeated policy violations that may indicate probing, and guard configuration drift.

What is content-based filtering in a CDS guard and how is it implemented?

Content-based filtering means the guard inspects the actual data payload — not just headers or metadata — to enforce security policy. Implementation involves a parser specific to each supported format (XML, JSON, MIME/SMTP, PDF) that extracts structured fields. For XML-based military messages, the parser navigates the document tree to find classification marking elements (typically in a header namespace defined by the IC-ISM or UCORE schema). For SMTP, the parser processes both the envelope headers and each MIME body part separately, including recursive unpacking of nested MIME structures. The extracted marking tokens are compared against a policy rule set: a set of boolean expressions over marking token presence, absence, and value. If any rule matches a reject condition, the entire message is rejected; if sanitization rules apply, specific fields or attachments are removed and the cleaned message forwarded. The parser itself must be hardened against malformed input — a crafted malformed message that crashes the parser creates a denial-of-service vector on the cross-domain link.

Defense Data Integration

Cross-domain solution architecture for military classified networks

Q: What is a data diode and when is a unidirectional guard insufficient?

A data diode is a hardware-enforced unidirectional link: optical isolation or similar technology ensures electrons literally cannot flow in the blocked direction. It guarantees that no signal — not even a timing side-channel — can travel from low to high. Diodes are appropriate for bulk export from a classified network to an unclassified recipient when no response traffic is ever required, such as video feeds from a classified sensor displayed on an unclassified screen. They become insufficient when a protocol requires handshaking or acknowledgment, when the application needs bidirectional data exchange, or when content inspection is required before transfer. In those cases a bidirectional guard with separate high-side and low-side proxy processes — enforcing the reference monitor model — is needed.

Q: How does a CDS guard enforce NEED-TO-KNOW beyond classification level?

Classification level (UNCLASSIFIED through TOP SECRET) is only the outer boundary. Inside a classification level, additional access controls include SCI compartments (SAP accesses), NOFORN restrictions (not releasable to foreign nationals), ORCON controls (originator-controlled dissemination), REL TO markings (releasable to named countries or organizations), and eyes-only designations. A CDS guard enforces these by maintaining a policy matrix that maps each destination network's accreditation to a set of permitted marking tokens. An object marked SECRET//REL TO USA,GBR is permitted on a network that includes UK-cleared users but rejected on a network that does not carry REL TO GBR authorization. This matrix must be kept synchronized with the accreditation documentation for each connected enclave.

Q: What file formats do modern CDS guards filter, and what are the risks of unsupported formats?

Modern CDS products support inspection of XML (including UCORE, NIEM, MIL-STD-2525 schema), JSON with classification metadata fields, SMTP with MIME attachments, HTTP/HTTPS with payload inspection, PDF documents with embedded metadata, and structured message formats including MTF (Message Text Format) used in NATO systems. The risk with unsupported formats is binary pass-through or blanket rejection: if the guard cannot parse the format, it either blocks all traffic of that type (disrupting operations) or allows it through uninspected (creating a spillage vector). For any new data format introduced into a CDS-protected pipeline, explicit format support must be confirmed with the guard vendor and validated during accreditation testing. Unknown binary formats should default to reject, never to pass.

Q: How should CDS guards be integrated into a C2 pipeline that feeds both SECRET and UNCLASSIFIED consumers?

The standard pattern for a C2 pipeline feeding mixed-classification consumers is a publish-subscribe topology with per-classification brokers and a CDS guard at the boundary. The SECRET broker receives all track updates, mission orders, and intelligence products from the classified network. The CDS guard subscribes to the SECRET broker, inspects each message against the configured policy, strips or redacts fields that carry compartmented markings, and re-publishes sanitized messages to the UNCLASSIFIED broker. The UNCLASSIFIED COP subscribes to the low-side broker. The guard never exposes a bidirectional connection directly between the two brokers — the high-side and low-side processes are separated with only the content-filtered output crossing the domain boundary. Latency introduced by the guard (typically 50–500 ms for text messages, longer for large attachments) must be accounted for in SLA planning.

Q: What logging requirements apply to CDS guard deployments?

CDS guards are required to produce tamper-evident audit logs of every transfer decision — approved, rejected, or flagged for human review. Each log record must include: a timestamp (GPS-synchronized UTC), the sending entity or process, the destination enclave, a hash of the message payload, the marking tokens extracted from the payload, the policy rule that triggered the decision, and the decision outcome. Logs must be stored on a system that neither the high-side nor the low-side network can write to or delete from — typically a dedicated out-of-band log server accessible only to the security administrator. Log integrity is usually enforced with an HMAC chain: each record includes the HMAC of the previous record, making insertion, deletion, or modification of any record detectable. Retention periods are set by the governing security plan, typically a minimum of three years for classified system audit logs.

By Corvus Intelligence Engineering Team · About the team →

June 24, 2026 12 min read

When a military information system needs to move data from a SECRET network to an UNCLASSIFIED one — or from a TOP SECRET compartmented environment to a coalition partner network — it cannot simply route the traffic through a standard firewall. The classification barrier is not an access-control problem solvable by network policy. It is a content-integrity problem: the information itself may carry markings, compartments, or embedded data elements that must not leave the higher-classification enclave. The mechanism designed to solve this is the cross-domain solution, and engineering one correctly requires understanding guard architecture, content filtering logic, marking standards, and a government accreditation process that typically takes longer than the application it protects.

This article explains how CDS guards work from the inside — the reference monitor model that underpins every approved product, the filter rule logic that implements CAPCO marking enforcement, the protocol-specific inspection techniques for XML and SMTP pipelines, and the NSA accreditation path that determines whether a deployment is legally authorized to operate. It is written for engineers and programme managers who need to understand the constraints before they commit to an architecture.

What is a cross-domain solution and when is it required

A cross-domain solution is a product or system that enforces a security policy when data moves between networks accredited at different classification levels or with incompatible access controls. The term covers hardware data diodes, software-based bidirectional guards, and combinations of the two. What distinguishes a CDS from an ordinary network gateway is that it operates at the content layer, not the packet layer — it inspects payloads, reads classification markings, applies structured filter rules, and makes an allow-or-reject decision for each data item individually.

A CDS is mandated whenever two conditions are both true: the source network holds information at a higher classification level than the destination network is accredited to receive, and the operational requirement is to transfer some — but not all — of that information to the lower network. If nothing should ever move from high to low, physical isolation (an air gap) is cheaper and more secure. If everything on the high side can move to the low side, the networks should be merged or the destination network should be re-accredited. It is the selective transfer case that requires a CDS.

Common scenarios that mandate a CDS in defense programs include: transferring sanitized track data from a SECRET common operational picture to an UNCLASSIFIED coalition partner display; publishing releasable intelligence products from a TS/SCI analysis environment to a SECRET dissemination network; feeding sensor data from a classified collection platform to an unclassified archive for long-term retention; and connecting a national intelligence network to a NATO-accredited combined network where the classification schemes differ. In each case, the CDS is the boundary enforcement mechanism — and its accreditation is what gives the connecting authority confidence that the boundary is being enforced correctly.

The alternative to a CDS in some limited scenarios is manual review: a human reviewer reads the document, determines it can be released, and re-types or re-drafts the content on the lower network. This is the original cross-domain "solution" and remains in use for low-volume, high-sensitivity transfers where automated filtering cannot be trusted to catch all sensitive content. Automated CDS products are appropriate only when the content is structured enough (marked XML, SMTP with classification headers, well-defined message formats) that a filter can reliably enforce the policy without human judgement for each transfer. Unstructured free-text — narrative assessments, analytical reports, commander's estimates — often still requires human review before release, even when a CDS guard is present for the technical transfer.

For programs that need to address not just the transfer mechanism but the broader security posture of the classified environment, the zero trust for defense software architecture provides the surrounding access control framework into which a CDS integrates.

CDS guard architectures

Four architectural patterns cover the majority of CDS deployments. Each trades security assurance, operational complexity, and capability against the others.

Hardware data diode. A physical device using optical or electrical isolation that guarantees unidirectional data flow at the hardware level. Electrons — and by extension, signals — cannot travel in the blocked direction. A diode between a classified network and an unclassified one ensures that even if the software on the low side is fully compromised, no signal from the low side can reach the high side. The limitation is strict: the application protocol must tolerate one-way flow. TCP's acknowledgment mechanism breaks over a diode; UDP streaming, syslog, and file replication over custom protocols work. Diodes are appropriate for bulk unidirectional exports — sensor streaming, log replication, video distribution — where the high side never needs confirmation of delivery.

Bidirectional guard with separated proxy processes. The most common architecture for applications requiring request-response protocols. The guard runs a high-side proxy process and a low-side proxy process with no shared address space, shared file system, or direct interprocess communication between them. The only path from high to low — and from low to high — passes through the guard kernel, which enforces the security policy for each transfer. The application on the high side connects to the high-side proxy; the application on the low side connects to the low-side proxy. From the network's perspective, each side sees only its own proxy. The guard kernel is the reference monitor — a small, formally specified, independently evaluated component whose only function is to enforce the transfer policy.

Content filter guard. A guard whose primary enforcement mechanism is content inspection — parsing the payload, extracting classification markings, matching against filter rules, and either passing, rejecting, or sanitizing the content before forwarding. Content filter guards implement the CAPCO marking vocabulary as their policy language. They are appropriate when the transferred data is structured and well-marked, and when the policy requires selective pass-through rather than wholesale blocking. Most modern bidirectional guards include a content filter as the first stage after the bidirectional separation.

Reference monitor model. The foundational security principle that all four architectures implement. A reference monitor is a component that: mediates every access request between a subject (the sender) and an object (the data item being transferred); is always invoked (no transfer bypasses it); is tamper-resistant (it cannot be modified or disabled by either side); and is small enough to be formally verified. In CDS terms, the reference monitor is the guard kernel — and its tamper resistance and complete mediation properties are what evaluators verify during the accreditation process. A CDS product that allows transfers to bypass the guard kernel under any condition — maintenance mode, high-load fallback, error state — fails the reference monitor requirement and cannot be accredited for classified network boundaries.

The following diagram shows the bidirectional guard architecture with separated proxy processes:

  ┌──────────────────────┐          ┌──────────────────────┐
  │  SECRET Network       │          │  UNCLASSIFIED Network │
  │  (High Side)          │          │  (Low Side)           │
  │                       │          │                       │
  │  ┌─────────────────┐  │          │  ┌─────────────────┐  │
  │  │  C2 Application │  │          │  │  COP Display    │  │
  │  └────────┬────────┘  │          │  └────────▲────────┘  │
  │           │            │          │           │            │
  │  ┌────────▼────────┐  │          │  ┌────────┴────────┐  │
  │  │  High-Side Proxy│  │          │  │ Low-Side Proxy  │  │
  └──┴────────┬────────┴──┘          └──┴────────▲────────┴──┘
              │                                   │
              │         ┌─────────────────┐       │
              └────────►│  Guard Kernel   ├───────┘
                        │  (Reference     │
                        │   Monitor)      │
                        │                 │
                        │  ┌───────────┐  │
                        │  │ Filter    │  │
                        │  │ Rules     │  │
                        │  │ (CAPCO)   │  │
                        │  └───────────┘  │
                        │                 │
                        │  ┌───────────┐  │
                        │  │ Audit Log │  │
                        │  │ (Signed)  │  │
                        │  └───────────┘  │
                        └─────────────────┘
                        Physical separation
                        of proxy processes
                        No shared memory/FS

Content-based filtering: what guards inspect

Content-based filtering is the mechanism that gives CDS guards their selective pass-through capability. Instead of blocking everything or passing everything, a content filter guard reads the data, extracts the security-relevant fields, applies policy rules, and makes an allow/reject/sanitize decision per message.

CAPCO marking parsing. The foundation of content filtering in U.S. classified systems is the CAPCO marking standard, which defines a controlled vocabulary of tokens that appear in classification banners, portion marks, and structured metadata fields. A guard's CAPCO parser reads the classification metadata element from each incoming message and extracts the component tokens. For a message marked SECRET//SI//REL TO USA,GBR, the parser produces: classification level = SECRET; SCI compartment = SI; dissemination control = REL TO; releasability = USA, GBR. Each token is then checked against the policy matrix for the destination network. If the destination is not accredited for SI compartment, the transfer is rejected. If the destination is accredited for REL TO GBR content, the transfer is permitted — but the filter still checks whether any other field in the message body carries a higher marking than the document-level marking claims.

Sensitive compartment enforcement. SCI compartment enforcement requires the guard to recognize the full set of compartment tokens defined in the governing classification guide. The most common compartments in U.S. systems are SI (Signals Intelligence), TK (Talent Keyhole, imagery from space), HCS (Humint Control System), and G (Gamma, a sub-compartment of SI). Each must be checked individually against the destination enclave's compartment accreditation. A destination network accredited for SI but not TK must not receive messages carrying TK marking — even if the document-level classification is within the permitted range.

Portion marking enforcement. A classified document often contains paragraphs, sections, or data elements with different sensitivity levels. CAPCO requires each portion to carry its own marking. A guard enforcing portion markings must parse not just the document-level banner but every paragraph-level (S//SI) or (U//FOUO) tag and make a separate policy decision for each. Sanitization — stripping the portions that fail the policy while forwarding the remainder — is more complex than wholesale rejection but is operationally essential for mixed-content documents.

Attachment stripping. SMTP messages and HTTP multipart payloads frequently carry attachments that the guard must inspect independently of the message body. Each attachment part is parsed separately: the MIME content-type determines the parser to use, the attachment is inspected for embedded classification metadata (PDF document properties, Word custom properties, image EXIF fields), and the policy is applied to each attachment individually. Attachments in formats the guard cannot parse — unrecognized binary formats, encrypted archives — are rejected by default, never passed through uninspected.

The interaction between CAPCO marking enforcement at the CDS layer and the underlying data model is described in detail in the article on military data fusion explained, which covers how classification propagates through a multi-source track database. For NATO environments, the binding between CAPCO-equivalent markings and the NATO confidentiality labeling standard is covered in the STANAG 4774/4778 labeling implementation reference.

Data formats and protocols supported by modern CDS products

A CDS guard is only as useful as its support for the formats your application actually uses. The guard's parser must understand the format deeply enough to extract classification fields and inspect content — surface-level header inspection is not sufficient.

Format / Protocol	Classification field location	Typical military use	Guard inspection complexity
XML (IC-ISM / UCORE)	Namespace attributes on root element and each classified portion	Track messages, intelligence products, NiemXML reports	High — full schema-aware XPath evaluation
JSON with ISM metadata	Top-level `ism:classification` field or embedded marking objects	REST API payloads, modern C2 microservices	Medium — schema-dependent, recursive inspection needed
SMTP / MIME	`X-Classification:` header + body banner + per-attachment marking	Intelligence product dissemination, SITREP distribution	High — recursive MIME parsing, attachment type detection
HTTP/HTTPS (REST)	Custom header + payload body	API calls between classified and unclassified services	Medium — TLS termination + content re-inspection required
MTF (Message Text Format)	CLASSIFICATION field in message header set	NATO/legacy military messaging, USMTF, ADatP-3	Medium — fixed-field format, well-specified parsing
PDF / Office documents	Custom document properties, XMP metadata, banner text in body	Finished intelligence products, orders, plans	Very high — embedded objects, macros, metadata stripping required
Video (RTP/RTSP)	Stream metadata headers (if present); frame-level overlay text	ISR video downlink, UAV feeds	Very high — typically requires diode + dedicated video proxy

For XML-based military messages, filter rules are expressed in XPath. A rule that rejects any message carrying a TK compartment token looks like:

<!-- Guard filter rule: reject if TK compartment is present -->
<FilterRule id="REJ-TK-001" action="REJECT">
  <Description>Reject messages carrying Talent Keyhole (TK) compartment</Description>
  <Condition>
    <XPathExpression>
      //*[contains(
        translate(
          @ism:SCIcontrols,
          'ABCDEFGHIJKLMNOPQRSTUVWXYZ',
          'abcdefghijklmnopqrstuvwxyz'
        ),
        'tk'
      )]
    </XPathExpression>
  </Condition>
  <AuditMessage>Transfer rejected: TK compartment detected in payload</AuditMessage>
</FilterRule>

<!-- Sanitization rule: strip SI-marked portion elements before forwarding -->
<FilterRule id="SAN-SI-001" action="SANITIZE">
  <Description>Strip SI-marked portions from otherwise-releasable documents</Description>
  <Condition>
    <XPathExpression>//*[@ism:SCIcontrols='SI']</XPathExpression>
  </Condition>
  <SanitizeAction>REMOVE_ELEMENT</SanitizeAction>
  <AuditMessage>Sanitized: SI-marked element removed from document</AuditMessage>
</FilterRule>

NSA approval and accreditation process

A CDS guard protecting a connection between two U.S. government classified networks must be approved by NSA/CSS before it operates. There is no waiver path for operational urgency — deploying an unapproved CDS is a reportable security incident. Understanding the accreditation process and its timeline is a prerequisite for any program that includes a classified boundary.

NSA/CSS Evaluated Products List (EPL). NSA evaluates CDS products and publishes the results on the Evaluated Products List. An EPL listing certifies that a specific product version, in a specific configuration, implements the reference monitor model correctly and resists the attack classes that evaluators tested. The EPL listing specifies the exact hardware model and firmware version, software version, and configuration options that were evaluated. Deviating from the evaluated configuration — even applying an operating system patch that was not part of the evaluated baseline — requires re-evaluation or a deviation authorization. Programs must track which EPL version their deployed guard corresponds to and maintain that correspondence through the guard's operational life.

Raise the Bar (RTB) initiative. Following a series of incidents in which inadequately designed guards allowed data to pass improperly, NSA/CSS issued the Raise the Bar requirements for CDS products. RTB mandates hardware separation of high-side and low-side processing paths, formal documentation of every filter rule and its security rationale, cryptographically signed audit logs (so log tampering is detectable), independent third-party verification of guard logic, and a defined patching procedure that includes re-verification after security-relevant changes. RTB-compliant products are listed on the EPL with an explicit RTB designation. Non-RTB products may still be on older EPL lists but cannot be newly approved for U.S. government classified boundaries.

DISA Unified Capabilities Approved Products List (UC APL). For DoD programs, the DISA UC APL listing is required in addition to the NSA EPL. The UC APL evaluation focuses on interoperability with DoD network infrastructure and compliance with DoD security technical implementation guides (STIGs). A product may be on the NSA EPL but not the UC APL, or vice versa — both are required for most DoD classified network deployments. Check both lists when evaluating candidate CDS products.

Site-specific Authority to Operate (ATO). Even with an EPL/UC APL product, each deployment requires a site-specific ATO that covers: the specific hardware and software configuration deployed; the network topology and physical security of the guard installation; the filter rule set and its relationship to the classification policies of the connected networks; continuous monitoring procedures; and the patch management and configuration change process. The ATO package is reviewed by the Authorizing Official (AO) for the systems on both sides of the boundary. For connections between networks owned by different agencies, a bilateral agreement between the two AOs is required before the ATO can be granted. Timeline: 6 to 18 months for a product already on the EPL in an uncomplicated configuration.

Integration patterns for C2 and ISR pipelines

Integrating a CDS guard into an operational C2 or ISR pipeline requires thinking through both the data flow architecture and the performance constraints the guard introduces.

The SECRET-to-UNCLASSIFIED COP pattern. The most common integration is a publish-subscribe pipeline where a SECRET broker feeds classified track updates, and a CDS guard subscribes to the SECRET broker, inspects each update, and re-publishes sanitized updates to an UNCLASSIFIED broker that coalition partners or lower-side consumers subscribe to. The guard in this architecture acts as a filtering subscriber on the high side and a publishing producer on the low side — never as a pass-through router. This ensures no direct connection exists between the two brokers.

SECRET Network                     UNCLASSIFIED Network
─────────────                      ────────────────────

┌─────────────┐   track updates   ┌─────────────────────────────┐
│ SECRET      │ ─────────────────►│     CDS Guard               │
│ Message     │                   │                             │
│ Broker      │                   │  High-Side     Low-Side     │
│             │                   │  Subscriber    Publisher    │
│             │                   │      │              │       │
│             │                   │      ▼              │       │
│             │                   │  CAPCO Filter       │       │
│             │                   │  SI/TK/HCS check    │       │
│             │                   │  Sanitize/Reject     │       │
│             │                   │      │              │       │
│             │                   │      └──────────────►       │
└─────────────┘                   └─────────────────────────────┘
                                               │
                                               ▼ sanitized updates
                                   ┌───────────────────┐
                                   │ UNCLASSIFIED      │
                                   │ Message Broker    │
                                   └─────────┬─────────┘
                                             │
                                             ▼
                                   ┌───────────────────┐
                                   │ Coalition COP /   │
                                   │ UNCLASSIFIED      │
                                   │ Display           │
                                   └───────────────────┘

Latency planning. A CDS guard introduces processing latency for every message it inspects. For small XML track-update messages (under 4 KB), commercial guards typically add 50 to 200 milliseconds of inspection latency. For large messages carrying binary attachments or requiring sanitization of multiple portions, latency can reach 500 milliseconds to 2 seconds. For PDF documents or complex MIME messages, processing can take several seconds. This must be factored into the COP refresh rate and the SLA for intelligence product dissemination. Guard throughput ratings are published in EPL documentation — verify that the rated throughput at the message size and complexity of your application is sufficient before committing to a product.

ISR sensor data paths. For ISR sensors operating at the classified level that must feed data to lower-classification consumers, the data path typically involves a classified processing stage that produces sanitized derivative products, which then cross the CDS boundary. Raw sensor data (full-fidelity imagery, raw SIGINT intercepts) should never be designed to flow through a CDS guard — the classification of raw ISR is typically far above what the low side can receive, and content filtering of raw sensor data is unreliable. The design pattern is: process at the classification level of the data, produce derivative products stripped of the sensitive source indicators, and transfer only the derivative products through the guard.

Operational security for CDS deployments

A CDS guard is a high-value target precisely because compromising it is equivalent to eliminating the classified boundary. The operational security controls around a deployed guard must be proportionate to that risk.

Physical security. The guard hardware must be installed in a physically secure location — a locked equipment room with access-controlled entry and visitor logging. Both the high-side network connection and the guard hardware must be within the physical security perimeter of the higher-classification network. Guard tampering — inserting a covert channel device on the network connection, replacing firmware — is a real threat that physical controls address.

Out-of-band management. The guard's management interface must be on a dedicated physical network separate from both the operational high-side and low-side networks. Management traffic — configuration changes, software updates, log retrieval — that transits either operational network creates a covert channel vector. Management workstations should be located inside the higher-classification security perimeter and accredited accordingly.

Log integrity and tamper detection. CDS audit logs are the primary evidence that the boundary was correctly enforced. Logs must be cryptographically protected — each log record includes an HMAC over the record content and the hash of the previous record (a hash chain). This makes insertion, deletion, or modification of any record detectable when the chain is verified. Logs must be written to a system that neither the high-side nor the low-side network can write to or delete from — a dedicated log server accessible only to the security administrator through the out-of-band management network. Log review must be an active, daily activity: rejection anomalies, unusual message volumes, or repeated policy violations by the same sender are indicators of probing or attack.

Configuration change control. Every change to the filter rule set — adding a rule, modifying a condition, removing a rule — must go through a documented change process that includes: a written change request with security rationale; independent review by a second security officer; test execution against the representative traffic sample; and post-change audit of the first 24 hours of production decisions to verify the rule behaves as intended. Changes that have not been through this process must not be applied to production guard configurations. A standing change freeze should apply during high-tempo operational periods when a guard misconfiguration would be most damaging.

Patch management. Security patches for the guard operating system and application require careful handling. Applying a patch that is not part of the evaluated configuration may invalidate the ATO — and not applying security patches creates exploitable vulnerabilities. The procedure is: receive and assess the patch; determine whether it affects the evaluated configuration baseline; if it does, consult with the EPL vendor and obtain an evaluation deviation authorization or schedule a re-evaluation; test the patch in an isolated guard environment that mirrors production; apply to production during a scheduled maintenance window with brief service interruption; verify that filter rule behavior is unchanged after patching.

Red-team testing. Annual penetration testing of the CDS installation should be a requirement in the security plan. The test scope should include: attempted extraction of classified content via the low-side interface using format injection and encoding attacks; attempted covert channel exploitation via timing, storage, and protocol-level channels; attempted guard management interface access from operational networks; and attempted physical tampering scenarios. Findings from red-team testing feed directly into the continuous monitoring report and may trigger configuration changes or re-evaluation.

Key insight: The most common operational failure mode in CDS deployments is not a filter rule gap — it is configuration drift. A guard deployed and accredited in a defined configuration gradually diverges from that configuration through unauthorized patches, ad-hoc rule changes, and hardware component substitutions. After 18 months of operation without a formal configuration audit, most guards are running in a configuration that was never evaluated. Build configuration audits into the operational schedule from the start.

Discuss Your Project

We design data integration architectures for defense programs operating across classified and unclassified network boundaries, including CDS integration, CAPCO-aware data pipelines, and multi-domain C2 connectivity.

Data Integration Services → Book a Briefing

This analysis was prepared by Corvus Intelligence engineers who build mission-critical software for defense and government organizations. Learn about our team →

Frequently Asked Questions

What is the difference between a cross-domain solution and a firewall?

A firewall enforces access control at the network layer — it allows or denies connections between hosts based on IP addresses, ports, and protocols. A cross-domain solution (CDS) operates at the content layer: it inspects the payload of each message, verifies that classification markings are present and correct, applies filter rules to the content itself, and sanitizes or rejects the transfer before it crosses to the lower-classification network. A firewall cannot read CAPCO markings embedded in XML or strip classified attachments from SMTP messages; a CDS is purpose-built for these tasks. CDS products are also subject to formal government accreditation (NSA/CSS EPL, DISA UC APL) that ordinary firewalls do not undergo.

What does CAPCO stand for and why is it used in CDS filter rules?

CAPCO stands for Controlled Access Program Coordination Office. CAPCO standards define the controlled vocabulary for U.S. classification markings — the structured strings that appear in banners, portion marks, and XML metadata fields. Examples include TOP SECRET//SI//REL TO USA,FVEY and SECRET//NOFORN. CDS guard filter rules are written against these structured markings because they encode the precise classification level, dissemination controls, and releasability. A guard parsing a CAPCO marking extracts the classification level, the SCI compartments (SI, TK, HCS), and the handling caveats (NOFORN, ORCON, REL TO). If any of those tokens exceed what the destination network is authorized to receive, the transfer is rejected before the payload leaves the source enclave.

What is a data diode and when is a unidirectional guard insufficient?

A data diode is a hardware-enforced unidirectional link using optical isolation or similar technology that ensures no signal can travel in the blocked direction. Diodes are appropriate for bulk export from a classified network when no response traffic is ever required, such as video feeds or log replication. They become insufficient when a protocol requires handshaking or acknowledgment, when the application needs bidirectional data exchange, or when content inspection is required before transfer. In those cases a bidirectional guard with separate high-side and low-side proxy processes — enforcing the reference monitor model — is needed instead.

How does a CDS guard enforce NEED-TO-KNOW beyond classification level?

Classification level is only the outer boundary. Inside a classification level, additional access controls include SCI compartments (SI, TK, HCS), NOFORN restrictions, ORCON controls, REL TO markings, and eyes-only designations. A CDS guard enforces these by maintaining a policy matrix that maps each destination network's accreditation to a set of permitted marking tokens. An object marked SECRET//REL TO USA,GBR is permitted on a network that includes UK-cleared users but rejected on one that does not carry REL TO GBR authorization. This matrix must be kept synchronized with the accreditation documentation for each connected enclave.

What is the NSA Raise the Bar initiative and how does it affect CDS procurement?

Raise the Bar (RTB) is an NSA/CSS initiative that established more rigorous evaluation standards for CDS products following incidents where inadequate guards allowed data spillage. RTB-compliant products must demonstrate hardware separation between high-side and low-side processing paths, formal security policy documentation, cryptographic log integrity, independent verification of guard logic, and a defined patching and re-evaluation process. Products meeting RTB requirements are listed on the NSA/CSS EPL with an explicit RTB designation. Procuring a non-RTB-compliant CDS for classified network boundaries is prohibited under current policy.

What file formats do modern CDS guards filter, and what are the risks of unsupported formats?

Modern CDS products support XML (IC-ISM, UCORE, NIEM schema), JSON with classification metadata fields, SMTP with MIME attachments, HTTP/HTTPS with payload inspection, PDF documents with embedded metadata, and MTF message formats. The risk with unsupported formats is binary pass-through or blanket rejection: if the guard cannot parse the format, it either blocks all traffic of that type (disrupting operations) or allows it through uninspected (creating a spillage vector). Unknown binary formats must default to reject, never to pass. Any new data format introduced into a CDS-protected pipeline requires explicit format support validation during accreditation testing.

How should CDS guards be integrated into a C2 pipeline that feeds both SECRET and UNCLASSIFIED consumers?

The standard pattern is a publish-subscribe topology with per-classification brokers and a CDS guard at the boundary. The SECRET broker receives all track updates and intelligence products. The CDS guard subscribes to the SECRET broker, inspects each message against the configured policy, strips fields carrying compartmented markings, and re-publishes sanitized messages to the UNCLASSIFIED broker. The guard never exposes a bidirectional connection directly between the two brokers. Latency introduced by the guard (typically 50–500 ms for text messages) must be accounted for in SLA planning for the COP update rate.

What logging requirements apply to CDS guard deployments?

CDS guards must produce tamper-evident audit logs of every transfer decision. Each log record must include a GPS-synchronized timestamp, the sending entity, the destination enclave, a hash of the message payload, the marking tokens extracted, the policy rule triggered, and the decision outcome. Logs must be stored on a system that neither the high-side nor the low-side network can write to or delete from. Log integrity is enforced with an HMAC chain — each record includes the HMAC of the previous record, making any modification detectable. Retention is typically a minimum of three years for classified system audit logs.

Can a CDS guard handle real-time streaming data such as video or track feeds?

Yes, but the architecture differs from message-based transfer. For video, a unidirectional data diode combined with a video transcoding proxy is standard: the classified stream enters the proxy on the high side, which re-encodes to a clean bitstream stripping all metadata, and the cleaned stream exits through the diode to the low-side display. For real-time track feeds, a content-aware guard proxies each track-update message, inspecting classification fields before forwarding. CDS products rated for high-throughput streaming exist on the EPL but must be specifically evaluated for the message rates of the intended deployment — a feed updating 10,000 objects per second at 200 bytes per message generates 2 MB/s requiring real-time parsing.

How long does NSA/DISA accreditation of a new CDS deployment typically take?

A CDS deployment using a product already on the NSA/CSS EPL and DISA UC APL typically requires 6 to 18 months for site-specific ATO processing, assuming the Security Plan is complete and the configuration matches the evaluated baseline. Deployments using custom-developed guard components require a full government-sponsored evaluation typically taking 18 to 36 months. Programs that deploy before accreditation is complete typically encounter forced shutdown orders when inspectors identify the gap. Building the ATO process into the programme schedule from the start, with realistic timelines, is essential for any CDS-dependent program.