Cross-Domain-Solution-Architektur für klassifizierte Militärnetzwerke

Von Corvus Intelligence Engineering Team · Über das Team →

24. Juni 2026 12 Min. Lesezeit

Wenn ein militärisches Informationssystem Daten von einem SECRET-Netzwerk in ein UNCLASSIFIED-Netzwerk übertragen muss — oder aus einer TOP SECRET-kompartimentierten Umgebung in ein Koalitionspartnernetzwerk — kann es den Datenverkehr nicht einfach über eine Standard-Firewall routen. Die Klassifizierungsbarriere ist kein Zugriffskontrollproblem, das durch Netzwerkrichtlinien gelöst werden kann. Es ist ein Inhaltsintegritätsproblem: Die Information selbst kann Kennzeichnungen, Kompartimente oder eingebettete Datenelemente enthalten, die die höher klassifizierte Enklave nicht verlassen dürfen. Der Mechanismus, der zur Lösung dieses Problems entwickelt wurde, ist die Cross-Domain Solution, und ihre korrekte Implementierung erfordert ein Verständnis von Guard-Architektur, Inhaltsfilterlogik, Kennzeichnungsstandards und einem staatlichen Akkreditierungsprozess, der typischerweise länger dauert als die Anwendung, die er schützt.

Dieser Artikel erklärt, wie CDS-Guards von innen funktionieren — das Referenzmonitormodell, das allen genehmigten Produkten zugrunde liegt, die Filterregellogik, die die CAPCO-Kennzeichnungsdurchsetzung implementiert, die protokollspezifischen Inspektionstechniken für XML- und SMTP-Pipelines und den NSA-Akkreditierungsweg, der bestimmt, ob ein Deployment rechtlich zum Betrieb autorisiert ist. Er richtet sich an Ingenieure und Programmmanager, die die Einschränkungen verstehen müssen, bevor sie sich auf eine Architektur festlegen.

Was ist eine Cross-Domain Solution und wann wird sie benötigt

Eine Cross-Domain Solution ist ein Produkt oder System, das eine Sicherheitsrichtlinie durchsetzt, wenn Daten zwischen Netzwerken mit unterschiedlichen Klassifizierungsstufen oder inkompatiblen Zugriffskontrollen übertragen werden. Der Begriff umfasst Hardware-Datendioden, softwarebasierte bidirektionale Guards und Kombinationen beider. Was eine CDS von einem gewöhnlichen Netzwerk-Gateway unterscheidet, ist, dass sie auf der Inhaltsebene und nicht auf der Paketebene arbeitet — sie prüft Nutzdaten, liest Klassifizierungskennzeichnungen, wendet strukturierte Filterregeln an und trifft für jedes Datenelement einzeln eine Zulassungs- oder Ablehnungsentscheidung.

Eine CDS ist zwingend vorgeschrieben, wenn zwei Bedingungen gleichzeitig zutreffen: Das Quellnetzwerk enthält Informationen auf einer höheren Klassifizierungsstufe, als das Zielnetzwerk akkreditiert ist zu empfangen, und die operative Anforderung besteht darin, einige — aber nicht alle — dieser Informationen in das niedrigere Netzwerk zu übertragen. Wenn nie etwas von hoch nach niedrig übertragen werden soll, ist physische Isolation (ein Air Gap) günstiger und sicherer. Wenn alles auf der höheren Seite auf die niedrigere Seite übertragen werden kann, sollten die Netzwerke zusammengeführt oder das Zielnetzwerk neu akkreditiert werden. Es ist der selektive Übertragungsfall, der eine CDS erfordert.

Häufige Szenarien, die in Verteidigungsprogrammen eine CDS vorschreiben, sind: Übertragung bereinigter Lageinformationen von einem SECRET-Lagebildsystem auf ein UNCLASSIFIED-Koalitionspartnerdisplay; Veröffentlichung freigebbarer Nachrichtendienstprodukte aus einer TS/SCI-Analyseumgebung in ein SECRET-Verbreitungsnetzwerk; Einspeisung von Sensordaten einer klassifizierten Erfassungsplattform in ein nicht klassifiziertes Archiv zur Langzeitaufbewahrung; und Verbindung eines nationalen Nachrichtendienstnetzes mit einem NATO-akkreditierten Verbundnetz, in dem die Klassifizierungsschemata unterschiedlich sind. In jedem Fall ist die CDS der Grenzdurchsetzungsmechanismus — und ihre Akkreditierung gibt der verbindenden Behörde die Gewissheit, dass die Grenze korrekt eingehalten wird.

Die Alternative zu einer CDS in einigen begrenzten Szenarien ist die manuelle Überprüfung: Ein menschlicher Prüfer liest das Dokument, stellt fest, dass es freigegeben werden kann, und tippt oder fasst den Inhalt im niedrigeren Netzwerk neu. Dies ist die ursprüngliche Cross-Domain-„Lösung" und wird nach wie vor für kleine, hochsensible Übertragungen eingesetzt, bei denen der automatisierten Filterung nicht vertraut werden kann, alle sensiblen Inhalte zu erfassen. Automatisierte CDS-Produkte sind nur geeignet, wenn der Inhalt ausreichend strukturiert ist (gekennzeichnetes XML, SMTP mit Klassifizierungs-Headern, klar definierte Nachrichtenformate), sodass ein Filter die Richtlinie zuverlässig ohne menschliches Urteil für jede Übertragung durchsetzen kann. Unstrukturierter Freitext — narrative Einschätzungen, analytische Berichte, Lageurteile des Kommandeurs — erfordert oft noch menschliche Überprüfung vor der Freigabe, auch wenn ein CDS-Guard für die technische Übertragung vorhanden ist.

Für Programme, die nicht nur den Übertragungsmechanismus, sondern auch die breitere Sicherheitslage der klassifizierten Umgebung berücksichtigen müssen, bietet die Zero-Trust-Architektur für Verteidigungssoftware den umgebenden Zugangskontrollrahmen, in den eine CDS integriert wird.

CDS-Guard-Architekturen

Vier Architekturmuster decken die Mehrheit der CDS-Deployments ab. Jedes schlägt Sicherheitsgewissheit, operationale Komplexität und Leistungsfähigkeit gegen die anderen aus.

Hardware-Datendiode. Ein physisches Gerät, das optische oder elektrische Isolation nutzt, um unidirektionalen Datenfluss auf Hardwareebene zu gewährleisten. Elektronen — und damit Signale — können nicht in die gesperrte Richtung fließen. Eine Diode zwischen einem klassifizierten und einem nicht klassifizierten Netzwerk stellt sicher, dass selbst wenn die Software auf der niedrigen Seite vollständig kompromittiert ist, kein Signal von der niedrigen auf die hohe Seite gelangen kann. Die Einschränkung ist strikt: Das Anwendungsprotokoll muss einseitigen Fluss tolerieren. Der Bestätigungsmechanismus von TCP funktioniert über eine Diode nicht; UDP-Streaming, Syslog und Dateireplikation über benutzerdefinierte Protokolle funktionieren. Dioden sind geeignet für massenhaften unidirektionalen Export — Sensor-Streaming, Protokollreplikation, Videoverteilung — wo die höhere Seite nie eine Zustellbestätigung benötigt.

Bidirektionaler Guard mit getrennten Proxy-Prozessen. Die häufigste Architektur für Anwendungen, die Anfrage-Antwort-Protokolle benötigen. Der Guard betreibt einen High-Side-Proxy-Prozess und einen Low-Side-Proxy-Prozess ohne gemeinsamen Adressraum, gemeinsames Dateisystem oder direkte Interprozesskommunikation zwischen ihnen. Der einzige Weg von hoch nach niedrig — und von niedrig nach hoch — führt durch den Guard-Kernel, der für jede Übertragung die Sicherheitsrichtlinie durchsetzt. Die Anwendung auf der hohen Seite verbindet sich mit dem High-Side-Proxy; die Anwendung auf der niedrigen Seite verbindet sich mit dem Low-Side-Proxy. Aus Netzwerksicht sieht jede Seite nur ihren eigenen Proxy. Der Guard-Kernel ist der Referenzmonitor — eine kleine, formal spezifizierte, unabhängig bewertete Komponente, deren einzige Funktion die Durchsetzung der Übertragungsrichtlinie ist.

Inhaltsfilter-Guard. Ein Guard, dessen primärer Durchsetzungsmechanismus die Inhaltsinspektion ist — Parsing der Nutzdaten, Extraktion von Klassifizierungskennzeichnungen, Abgleich mit Filterregeln und entweder Weiterleitung, Ablehnung oder Bereinigung des Inhalts vor der Weiterleitung. Inhaltsfilter-Guards implementieren das CAPCO-Kennzeichnungsvokabular als Richtliniensprache. Sie sind geeignet, wenn die übertragenen Daten strukturiert und gut gekennzeichnet sind und wenn die Richtlinie selektiven Durchlass anstelle von vollständiger Sperrung erfordert. Die meisten modernen bidirektionalen Guards enthalten einen Inhaltsfilter als erste Stufe nach der bidirektionalen Trennung.

Referenzmonitormodell. Das grundlegende Sicherheitsprinzip, das alle vier Architekturen implementieren. Ein Referenzmonitor ist eine Komponente, die: jede Zugriffsanfrage zwischen einem Subjekt (dem Sender) und einem Objekt (dem zu übertragenden Datenelement) vermittelt; immer aufgerufen wird (keine Übertragung umgeht ihn); manipulationssicher ist (er kann von keiner Seite modifiziert oder deaktiviert werden); und klein genug ist, um formal verifiziert zu werden. In CDS-Begriffen ist der Referenzmonitor der Guard-Kernel — und seine Manipulationssicherheit und vollständige Vermittlungseigenschaften sind das, was Evaluatoren während des Akkreditierungsprozesses verifizieren. Ein CDS-Produkt, das unter irgendeiner Bedingung — Wartungsmodus, Hochlast-Fallback, Fehlerzustand — Übertragungen den Guard-Kernel umgehen lässt, erfüllt die Referenzmonitorbedingung nicht und kann nicht für klassifizierte Netzwerkgrenzen akkreditiert werden.

Das folgende Diagramm zeigt die bidirektionale Guard-Architektur mit getrennten Proxy-Prozessen:

  ┌──────────────────────┐          ┌──────────────────────┐
  │  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

Inhaltsbasierte Filterung: was Guards prüfen

Die inhaltsbasierte Filterung ist der Mechanismus, der CDS-Guards ihre selektive Durchlassfähigkeit verleiht. Anstatt alles zu sperren oder alles durchzulassen, liest ein Inhaltsfilter-Guard die Daten, extrahiert die sicherheitsrelevanten Felder, wendet Richtlinienregeln an und trifft eine Zulassungs-/Ablehnungs-/Bereinigungsentscheidung pro Nachricht.

CAPCO-Kennzeichnungs-Parsing. Das Fundament der Inhaltsfilterung in US-klassifizierten Systemen ist der CAPCO-Kennzeichnungsstandard, der ein kontrolliertes Vokabular von Token definiert, die in Klassifizierungsbannern, Abschnittsmarkierungen und strukturierten Metadatenfeldern erscheinen. Der CAPCO-Parser eines Guards liest das Klassifizierungsmetadatenelement aus jeder eingehenden Nachricht und extrahiert die Komponenten-Token. Für eine Nachricht, die mit SECRET//SI//REL TO USA,GBR gekennzeichnet ist, erzeugt der Parser: Klassifizierungsstufe = SECRET; SCI-Kompartiment = SI; Verbreitungskontrolle = REL TO; Freigabefähigkeit = USA, GBR. Jeder Token wird dann gegen die Richtlinienmatrix für das Zielnetzwerk geprüft. Wenn das Ziel nicht für das SI-Kompartiment akkreditiert ist, wird die Übertragung abgelehnt. Wenn das Ziel für REL TO GBR-Inhalte akkreditiert ist, ist die Übertragung erlaubt — aber der Filter prüft weiterhin, ob ein anderes Feld im Nachrichtentext eine höhere Kennzeichnung trägt, als die Kennzeichnung auf Dokumentebene behauptet.

Durchsetzung sensibler Kompartimente. Die SCI-Kompartimentdurchsetzung erfordert, dass der Guard den vollständigen Satz von Kompartiment-Token erkennt, die in der maßgeblichen Klassifizierungsanleitung definiert sind. Die häufigsten Kompartimente in US-Systemen sind SI (Signals Intelligence), TK (Talent Keyhole, Bilder aus dem Weltraum), HCS (Humint Control System) und G (Gamma, ein Unterkompartiment von SI). Jedes muss einzeln gegen die Kompartimentakkreditierung der Zielenklave geprüft werden. Ein Zielnetzwerk, das für SI, aber nicht für TK akkreditiert ist, darf keine Nachrichten mit TK-Kennzeichnung empfangen — auch wenn die Klassifizierungsstufe auf Dokumentebene im erlaubten Bereich liegt.

Durchsetzung von Abschnittsmarkierungen. Ein klassifiziertes Dokument enthält oft Absätze, Abschnitte oder Datenelemente mit unterschiedlichen Empfindlichkeitsstufen. CAPCO erfordert, dass jeder Abschnitt seine eigene Kennzeichnung trägt. Ein Guard, der Abschnittsmarkierungen durchsetzt, muss nicht nur das Banner auf Dokumentebene, sondern auch jedes (S//SI) oder (U//FOUO)-Tag auf Absatzebene parsen und für jeden eine separate Richtlinienentscheidung treffen. Bereinigung — Entfernung der Abschnitte, die die Richtlinie nicht erfüllen, während der Rest weitergeleitet wird — ist komplexer als vollständige Ablehnung, aber operativ unerlässlich für Dokumente mit gemischten Inhalten.

Anlagenbereinigung. SMTP-Nachrichten und HTTP-Multipart-Nutzdaten enthalten häufig Anhänge, die der Guard unabhängig vom Nachrichtentext prüfen muss. Jedes Anhangsteil wird separat geparst: Der MIME-Content-Type bestimmt den zu verwendenden Parser, der Anhang wird auf eingebettete Klassifizierungsmetadaten geprüft (PDF-Dokumenteigenschaften, Word-Benutzereigenschaften, EXIF-Felder in Bildern), und die Richtlinie wird auf jeden Anhang einzeln angewendet. Anhänge in Formaten, die der Guard nicht parsen kann — nicht erkannte Binärformate, verschlüsselte Archive — werden standardmäßig abgelehnt, niemals ungeprüft durchgelassen.

Die Wechselwirkung zwischen der CAPCO-Kennzeichnungsdurchsetzung auf CDS-Ebene und dem zugrunde liegenden Datenmodell wird ausführlich im Artikel über militärische Datenfusion erklärt beschrieben, der behandelt, wie Klassifizierungen sich durch eine Mehrquellen-Lagedatenbank fortpflanzen. Für NATO-Umgebungen wird die Bindung zwischen CAPCO-äquivalenten Kennzeichnungen und dem NATO-Standard für Vertraulichkeitskennzeichnungen in der Referenz zu STANAG 4774/4778-Kennzeichnungsimplementierung behandelt.

Datenformate und Protokolle moderner CDS-Produkte

Ein CDS-Guard ist nur so nützlich wie seine Unterstützung für die Formate, die Ihre Anwendung tatsächlich verwendet. Der Parser des Guards muss das Format tief genug verstehen, um Klassifizierungsfelder zu extrahieren und Inhalte zu prüfen — eine oberflächliche Header-Inspektion reicht nicht aus.

Format / Protokoll	Speicherort des Klassifizierungsfelds	Typische militärische Verwendung	Komplexität der Guard-Inspektion
XML (IC-ISM / UCORE)	Namespace-Attribute auf Root-Element und jedem klassifizierten Abschnitt	Lagemeldungen, Nachrichtendienstprodukte, NiemXML-Berichte	Hoch — vollständige schemabewusste XPath-Auswertung
JSON mit ISM-Metadaten	Oberste Ebene `ism:classification`-Feld oder eingebettete Kennzeichnungsobjekte	REST-API-Nutzdaten, moderne C2-Microservices	Mittel — schemabhängig, rekursive Inspektion erforderlich
SMTP / MIME	`X-Classification:`-Header + Body-Banner + Kennzeichnung pro Anhang	Verbreitung von Nachrichtendienstprodukten, SITREP-Verteilung	Hoch — rekursives MIME-Parsing, Erkennung des Anhangstyps
HTTP/HTTPS (REST)	Benutzerdefinierter Header + Nutzdaten-Body	API-Aufrufe zwischen klassifizierten und nicht klassifizierten Diensten	Mittel — TLS-Terminierung + erneute Inhaltsinspektion erforderlich
MTF (Message Text Format)	CLASSIFICATION-Feld im Nachrichten-Header-Satz	NATO-/Legacy-Militärnachrichten, USMTF, ADatP-3	Mittel — Festfeldformat, gut spezifiziertes Parsing
PDF / Office-Dokumente	Benutzerdefinierte Dokumenteigenschaften, XMP-Metadaten, Bannertext im Body	Fertige Nachrichtendienstprodukte, Befehle, Pläne	Sehr hoch — eingebettete Objekte, Makros, Metadaten-Bereinigung erforderlich
Video (RTP/RTSP)	Stream-Metadaten-Header (falls vorhanden); Overlay-Text auf Frame-Ebene	ISR-Video-Downlink, UAV-Feeds	Sehr hoch — typischerweise Diode + dedizierter Video-Proxy erforderlich

Für XML-basierte Militärnachrichten werden Filterregeln in XPath ausgedrückt. Eine Regel, die jede Nachricht mit einem TK-Kompartiment-Token ablehnt, sieht folgendermaßen aus:

<!-- 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-Genehmigung und Akkreditierungsprozess

Ein CDS-Guard, der eine Verbindung zwischen zwei klassifizierten US-Regierungsnetzwerken schützt, muss vor dem Betrieb von NSA/CSS genehmigt werden. Es gibt keinen Ausnahmeweg für operative Dringlichkeit — der Betrieb einer nicht genehmigten CDS ist ein meldepflichtiger Sicherheitsvorfall. Das Verständnis des Akkreditierungsprozesses und seiner Zeitplanung ist eine Voraussetzung für jedes Programm, das eine klassifizierte Grenze umfasst.

NSA/CSS Evaluated Products List (EPL). NSA bewertet CDS-Produkte und veröffentlicht die Ergebnisse auf der Evaluated Products List. Eine EPL-Listung zertifiziert, dass eine bestimmte Produktversion in einer bestimmten Konfiguration das Referenzmonitormodell korrekt implementiert und den Angriffsklassen standhält, die Evaluatoren getestet haben. Die EPL-Listung spezifiziert das genaue Hardware-Modell und die Firmware-Version, Softwareversion und Konfigurationsoptionen, die bewertet wurden. Eine Abweichung von der bewerteten Konfiguration — auch das Einspielen eines Betriebssystem-Patches, der nicht Teil der bewerteten Grundlage war — erfordert eine erneute Bewertung oder eine Abweichungsgenehmigung. Programme müssen verfolgen, welcher EPL-Version ihr eingesetzter Guard entspricht, und diese Entsprechung während der gesamten Betriebszeit des Guards aufrechterhalten.

Raise the Bar (RTB)-Initiative. Nach einer Reihe von Vorfällen, bei denen unzureichend konzipierte Guards Daten unkorrekt passieren ließen, erließ NSA/CSS die Raise the Bar-Anforderungen für CDS-Produkte. RTB schreibt vor: Hardware-Trennung von High-Side- und Low-Side-Verarbeitungspfaden, formale Dokumentation jeder Filterregel und ihrer Sicherheitsbegründung, kryptographisch signierte Audit-Protokolle (damit Protokollmanipulationen erkennbar sind), unabhängige Drittpartei-Verifikation der Guard-Logik und ein definiertes Patch-Verfahren, das Re-Verifikation nach sicherheitsrelevanten Änderungen umfasst. RTB-konforme Produkte sind auf der EPL mit einer expliziten RTB-Bezeichnung aufgeführt. Nicht-RTB-Produkte können sich noch auf älteren EPL-Listen befinden, können aber nicht neu für US-Regierungs-klassifizierte Grenzen zugelassen werden.

DISA Unified Capabilities Approved Products List (UC APL). Für DoD-Programme ist die DISA UC APL-Listung zusätzlich zur NSA EPL erforderlich. Die UC APL-Bewertung konzentriert sich auf die Interoperabilität mit DoD-Netzwerkinfrastruktur und die Einhaltung der DoD Security Technical Implementation Guides (STIGs). Ein Produkt kann auf der NSA EPL, aber nicht auf der UC APL sein, oder umgekehrt — für die meisten DoD-klassifizierten Netzwerk-Deployments sind beide erforderlich. Prüfen Sie beide Listen bei der Bewertung von CDS-Kandidatenprodukten.

Standortspezifische Authority to Operate (ATO). Selbst mit einem EPL/UC APL-Produkt erfordert jedes Deployment eine standortspezifische ATO, die abdeckt: die spezifische eingesetzte Hardware- und Softwarekonfiguration; die Netzwerktopologie und physische Sicherheit der Guard-Installation; den Filterregelsatz und seine Beziehung zu den Klassifizierungsrichtlinien der verbundenen Netzwerke; Verfahren zur kontinuierlichen Überwachung; und den Patch-Management- und Konfigurationsänderungsprozess. Das ATO-Paket wird vom Authorizing Official (AO) für die Systeme auf beiden Seiten der Grenze überprüft. Für Verbindungen zwischen Netzwerken verschiedener Behörden ist ein bilaterales Abkommen zwischen den beiden AOs erforderlich, bevor die ATO erteilt werden kann. Zeitplan: 6 bis 18 Monate für ein Produkt, das bereits auf der EPL in einer unkomplizierten Konfiguration aufgeführt ist.

Integrationsmuster für C2- und ISR-Pipelines

Die Integration eines CDS-Guards in eine operative C2- oder ISR-Pipeline erfordert die Durchdenkung sowohl der Datenflusarchitektur als auch der Leistungseinschränkungen, die der Guard einführt.

Das SECRET-zu-UNCLASSIFIED-COP-Muster. Die häufigste Integration ist eine Publish-Subscribe-Pipeline, bei der ein SECRET-Broker klassifizierte Lageaktualisierungen einspeist, und ein CDS-Guard den SECRET-Broker abonniert, jede Aktualisierung prüft und bereinigte Aktualisierungen an einen UNCLASSIFIED-Broker weiterveröffentlicht, den Koalitionspartner oder Low-Side-Verbraucher abonnieren. Der Guard in dieser Architektur fungiert als filternder Abonnent auf der hohen Seite und als veröffentlichender Produzent auf der niedrigen Seite — niemals als Durchgangs-Router. Dadurch wird sichergestellt, dass keine direkte Verbindung zwischen den beiden Brokern besteht.

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           │
                                   └───────────────────┘

Latenzplanung. Ein CDS-Guard führt Verarbeitungslatenz für jede Nachricht ein, die er prüft. Für kleine XML-Lageaktualisierungsnachrichten (unter 4 KB) fügen kommerzielle Guards typischerweise 50 bis 200 Millisekunden Inspektionslatenz hinzu. Für große Nachrichten mit binären Anhängen oder solche, die eine Bereinigung mehrerer Abschnitte erfordern, kann die Latenz 500 Millisekunden bis 2 Sekunden erreichen. Für PDF-Dokumente oder komplexe MIME-Nachrichten kann die Verarbeitung mehrere Sekunden dauern. Dies muss bei der COP-Aktualisierungsrate und dem SLA für die Verbreitung von Nachrichtendienstprodukten berücksichtigt werden. Guard-Durchsatzbewertungen werden in EPL-Dokumentation veröffentlicht — überprüfen Sie, ob der bewertete Durchsatz bei der Nachrichtengröße und -komplexität Ihrer Anwendung ausreichend ist, bevor Sie sich für ein Produkt entscheiden.

ISR-Sensordatenpfade. Für ISR-Sensoren, die auf klassifiziertem Niveau operieren und Daten an niedriger klassifizierte Verbraucher liefern müssen, umfasst der Datenpfad typischerweise eine klassifizierte Verarbeitungsstufe, die bereinigte abgeleitete Produkte erzeugt, die dann die CDS-Grenze überschreiten. Rohe Sensordaten (hochauflösende Bilder, rohe SIGINT-Abfangmaterialien) sollten nie so konzipiert werden, dass sie durch einen CDS-Guard fließen — die Klassifizierung von rohen ISR-Daten liegt typischerweise weit über dem, was die niedrigere Seite empfangen kann, und die Inhaltsfilterung roher Sensordaten ist unzuverlässig. Das Entwurfsmuster lautet: Verarbeitung auf der Klassifizierungsebene der Daten, Erzeugung von abgeleiteten Produkten ohne die sensiblen Quellenindikatoren und Übertragung nur der abgeleiteten Produkte durch den Guard.

Betriebssicherheit für CDS-Deployments

Ein CDS-Guard ist ein hochrangiges Angriffsziel, weil seine Kompromittierung der Eliminierung der klassifizierten Grenze gleichkommt. Die Betriebssicherheitskontrollen rund um einen eingesetzten Guard müssen diesem Risiko angemessen sein.

Physische Sicherheit. Die Guard-Hardware muss an einem physisch sicheren Ort installiert sein — einem abgesperrten Geräteraum mit zugangskontrolliertem Eingang und Besucherprotokollierung. Sowohl die High-Side-Netzwerkverbindung als auch die Guard-Hardware müssen sich innerhalb des physischen Sicherheitsperimeters des höher klassifizierten Netzwerks befinden. Guard-Manipulation — Einsetzen eines verdeckten Kanalgeräts an der Netzwerkverbindung, Firmware-Austausch — ist eine reale Bedrohung, die physische Kontrollen adressieren.

Out-of-Band-Management. Die Management-Schnittstelle des Guards muss sich auf einem dedizierten physischen Netzwerk befinden, das von beiden operativen High-Side- und Low-Side-Netzwerken getrennt ist. Management-Datenverkehr — Konfigurationsänderungen, Software-Updates, Protokollabruf — der über eines der operativen Netzwerke läuft, schafft einen verdeckten Kanalvektor. Management-Workstations sollten sich innerhalb des höher klassifizierten Sicherheitsperimeters befinden und entsprechend akkreditiert sein.

Protokollintegrität und Manipulationserkennung. CDS-Audit-Protokolle sind der primäre Nachweis, dass die Grenze korrekt eingehalten wurde. Protokolle müssen kryptographisch geschützt sein — jeder Protokolleintrag enthält einen HMAC über den Eintragsinhalt und den Hash des vorherigen Eintrags (eine Hash-Kette). Dies macht das Einfügen, Löschen oder Ändern eines Eintrags erkennbar, wenn die Kette verifiziert wird. Protokolle müssen auf ein System geschrieben werden, auf das weder das High-Side- noch das Low-Side-Netzwerk schreiben oder von dem es löschen kann — ein dedizierter Protokollserver, der nur dem Sicherheitsadministrator über das Out-of-Band-Management-Netzwerk zugänglich ist. Die Protokollüberprüfung muss eine aktive, tägliche Aktivität sein: Ablehnungsanomalien, ungewöhnliche Nachrichtenvolumina oder wiederholte Richtlinienverstöße desselben Absenders sind Indikatoren für Sondierungen oder Angriffe.

Konfigurationsänderungskontrolle. Jede Änderung am Filterregelsatz — Hinzufügen einer Regel, Ändern einer Bedingung, Entfernen einer Regel — muss einen dokumentierten Änderungsprozess durchlaufen, der umfasst: eine schriftliche Änderungsanforderung mit Sicherheitsbegründung; unabhängige Überprüfung durch einen zweiten Sicherheitsoffizier; Testdurchführung an der repräsentativen Verkehrsstichprobe; und Post-Änderungs-Audit der ersten 24 Stunden von Produktionsentscheidungen zur Überprüfung, ob sich die Regel wie beabsichtigt verhält. Änderungen, die diesen Prozess nicht durchlaufen haben, dürfen nicht auf Guard-Produktionskonfigurationen angewendet werden. Während hochtemporärer operativer Phasen, in denen eine Guard-Fehlkonfiguration am schädlichsten wäre, sollte ein Änderungsstopp gelten.

Patch-Management. Sicherheits-Patches für das Guard-Betriebssystem und die Anwendung erfordern sorgfältige Handhabung. Das Einspielen eines Patches, der nicht Teil der bewerteten Konfiguration ist, kann die ATO ungültig machen — und das Nicht-Einspielen von Sicherheits-Patches schafft ausnutzbare Schwachstellen. Das Verfahren lautet: Patch empfangen und bewerten; bestimmen, ob er die bewertete Konfigurationsgrundlage betrifft; wenn ja, mit dem EPL-Anbieter konsultieren und eine Bewertungsabweichungsgenehmigung einholen oder eine erneute Bewertung planen; den Patch in einer isolierten Guard-Umgebung testen, die die Produktion spiegelt; während eines geplanten Wartungsfensters mit kurzer Dienstunterbrechung auf die Produktion anwenden; nach dem Patchen überprüfen, dass das Filterregelverhalten unverändert ist.

Red-Team-Tests. Jährliche Penetrationstests der CDS-Installation sollten eine Anforderung im Sicherheitsplan sein. Der Testumfang sollte umfassen: versuchte Extraktion von klassifizierten Inhalten über die Low-Side-Schnittstelle mit Format-Injection- und Encoding-Angriffen; versuchte verdeckte Kanal-Ausnutzung über Timing-, Speicher- und Protokollebenenkanäle; versuchter Zugriff auf die Guard-Management-Schnittstelle von operativen Netzwerken; und versuchte physische Manipulationsszenarien. Ergebnisse aus Red-Team-Tests fließen direkt in den kontinuierlichen Überwachungsbericht ein und können Konfigurationsänderungen oder eine erneute Bewertung auslösen.

Zentrale Erkenntnis: Der häufigste operative Ausfallmodus bei CDS-Deployments ist kein Filterregeldefizit — es ist Konfigurationsdrift. Ein Guard, der in einer definierten Konfiguration eingesetzt und akkreditiert wurde, weicht durch unbefugte Patches, Ad-hoc-Regeländerungen und Hardware-Komponentenersatz schrittweise von dieser Konfiguration ab. Nach 18 Monaten Betrieb ohne formalen Konfigurationsaudit laufen die meisten Guards in einer Konfiguration, die nie bewertet wurde. Konfigurationsaudits von Anfang an in den Betriebsplan einbauen.

Ihr Projekt besprechen

Wir entwerfen Datenintegrationsarchitekturen für Verteidigungsprogramme, die über klassifizierte und nicht klassifizierte Netzwerkgrenzen hinweg operieren, einschließlich CDS-Integration, CAPCO-bewusster Datenpipelines und C2-Konnektivität für mehrere Domänen.

Datenintegrationsleistungen → Briefing buchen

Diese Analyse wurde von Corvus Intelligence-Ingenieuren erstellt, die missionskritische Software für Verteidigungs- und Regierungsorganisationen entwickeln. Mehr über unser Team →

Häufig gestellte Fragen

Was ist der Unterschied zwischen einer Cross-Domain Solution und einer Firewall?

Eine Firewall erzwingt Zugangskontrolle auf der Netzwerkebene — sie erlaubt oder verweigert Verbindungen zwischen Hosts basierend auf IP-Adressen, Ports und Protokollen. Eine Cross-Domain Solution (CDS) arbeitet auf der Inhaltsebene: sie prüft die Nutzdaten jeder Nachricht, verifiziert, dass Klassifizierungskennzeichnungen vorhanden und korrekt sind, wendet Filterregeln auf den Inhalt selbst an und bereinigt oder lehnt die Übertragung ab, bevor sie die niedrigere Klassifizierungsebene erreicht. Eine Firewall kann keine CAPCO-Kennzeichnungen in XML lesen oder klassifizierte Anhänge aus SMTP-Nachrichten entfernen; eine CDS ist speziell für diese Aufgaben konzipiert. CDS-Produkte unterliegen auch einer formalen staatlichen Akkreditierung (NSA/CSS EPL, DISA UC APL), der normale Firewalls nicht unterliegen.

Wofür steht CAPCO und warum wird es in CDS-Filterregeln verwendet?

CAPCO steht für Controlled Access Program Coordination Office. CAPCO-Standards definieren das kontrollierte Vokabular für US-Klassifizierungskennzeichnungen — die strukturierten Zeichenketten, die in Bannern, Abschnittsmarkierungen und XML-Metadatenfeldern erscheinen. Beispiele sind TOP SECRET//SI//REL TO USA,FVEY und SECRET//NOFORN. CDS-Guard-Filterregeln werden gegen diese strukturierten Kennzeichnungen geschrieben, weil sie die genaue Klassifizierungsstufe, Verbreitungskontrollen und Freigabefähigkeit codieren. Ein Guard, der eine CAPCO-Kennzeichnung parst, extrahiert die Klassifizierungsstufe, die SCI-Kompartimente (SI, TK, HCS) und die Handhabungsvorbehalte (NOFORN, ORCON, REL TO). Wenn eines dieser Token das überschreitet, was das Zielnetzwerk zu empfangen autorisiert ist, wird die Übertragung abgelehnt, bevor die Nutzdaten die Quellenklave verlassen.

Was ist eine Datendiode und wann ist ein unidirektionaler Guard unzureichend?

Eine Datendiode ist eine hardwareerzwungene unidirektionale Verbindung, die optische Isolation oder ähnliche Technologie verwendet, die sicherstellt, dass kein Signal in die gesperrte Richtung reisen kann. Dioden sind geeignet für massenhaften Export aus einem klassifizierten Netzwerk, wenn kein Rückverkehr je benötigt wird, wie Video-Feeds oder Log-Replikation. Sie werden unzureichend, wenn ein Protokoll Handshaking oder Bestätigung erfordert, wenn die Anwendung bidirektionalen Datenaustausch benötigt oder wenn eine Inhaltsinspektion vor der Übertragung erforderlich ist. In diesen Fällen wird stattdessen ein bidirektionaler Guard mit separaten High-Side- und Low-Side-Proxy-Prozessen — der das Referenzmonitormodell durchsetzt — benötigt.

Wie setzt ein CDS-Guard NEED-TO-KNOW über die Klassifizierungsstufe hinaus durch?

Die Klassifizierungsstufe ist nur die äußere Grenze. Innerhalb einer Klassifizierungsstufe umfassen zusätzliche Zugriffskontrollen SCI-Kompartimente (SI, TK, HCS), NOFORN-Einschränkungen, ORCON-Kontrollen, REL TO-Kennzeichnungen und Nur-Augen-Bezeichnungen. Ein CDS-Guard setzt diese durch, indem er eine Richtlinienmatrix pflegt, die die Akkreditierung jedes Zielnetzwerks einem Satz erlaubter Kennzeichnungs-Token zuordnet. Ein Objekt mit SECRET//REL TO USA,GBR ist auf einem Netzwerk erlaubt, das UK-zertifizierte Benutzer einschließt, wird aber auf einem abgelehnt, das keine REL TO GBR-Genehmigung trägt. Diese Matrix muss mit der Akkreditierungsdokumentation für jede verbundene Enklave synchron gehalten werden.

Was ist die NSA Raise the Bar-Initiative und wie wirkt sie sich auf die CDS-Beschaffung aus?

Raise the Bar (RTB) ist eine NSA/CSS-Initiative, die nach Vorfällen, bei denen unzureichende Guards Daten unkorrekt passieren ließen, strengere Bewertungsstandards für CDS-Produkte etablierte. RTB-konforme Produkte müssen nachweisen: Hardware-Trennung zwischen High-Side- und Low-Side-Verarbeitungspfaden, formale Sicherheitsrichtliniendokumentation, kryptographische Protokollintegrität, unabhängige Verifikation der Guard-Logik und ein definiertes Patch- und Re-Evaluierungs-Verfahren. Produkte, die RTB-Anforderungen erfüllen, sind auf der NSA/CSS EPL mit einer expliziten RTB-Bezeichnung aufgeführt. Die Beschaffung einer nicht RTB-konformen CDS für klassifizierte Netzwerkgrenzen ist nach aktueller Richtlinie verboten.

Welche Dateiformate filtern moderne CDS-Guards und welche Risiken bestehen bei nicht unterstützten Formaten?

Moderne CDS-Produkte unterstützen XML (IC-ISM, UCORE, NIEM-Schema), JSON mit Klassifizierungsmetadatenfeldern, SMTP mit MIME-Anhängen, HTTP/HTTPS mit Nutzdateninspektion, PDF-Dokumente mit eingebetteten Metadaten und MTF-Nachrichtenformate. Das Risiko bei nicht unterstützten Formaten ist binärer Durchlass oder vollständige Ablehnung: Wenn der Guard das Format nicht parsen kann, blockiert er entweder allen Datenverkehr dieses Typs (störend für den Betrieb) oder lässt ihn ungeprüft durch (schafft einen Datenleck-Vektor). Unbekannte Binärformate müssen standardmäßig abgelehnt werden, niemals durchgelassen. Jedes neue Datenformat, das in eine CDS-geschützte Pipeline eingeführt wird, erfordert eine explizite Format-Unterstützungsvalidierung während der Akkreditierungstests.

Wie sollten CDS-Guards in eine C2-Pipeline integriert werden, die sowohl SECRET- als auch UNCLASSIFIED-Verbraucher bedient?

Das Standardmuster ist eine Publish-Subscribe-Topologie mit Brokern je Klassifizierung und einem CDS-Guard an der Grenze. Der SECRET-Broker empfängt alle Lageaktualisierungen und Nachrichtendienstprodukte. Der CDS-Guard abonniert den SECRET-Broker, prüft jede Nachricht gegen die konfigurierte Richtlinie, entfernt Felder mit kompartimentierten Kennzeichnungen und veröffentlicht bereinigte Nachrichten erneut an den UNCLASSIFIED-Broker. Der Guard stellt nie eine bidirektionale Verbindung direkt zwischen den beiden Brokern bereit. Durch den Guard eingeführte Latenz (typischerweise 50–500 ms für Textnachrichten) muss bei der SLA-Planung für die COP-Aktualisierungsrate berücksichtigt werden.

Welche Protokollierungsanforderungen gelten für CDS-Guard-Deployments?

CDS-Guards müssen manipulationssichere Audit-Protokolle jeder Übertragungsentscheidung erstellen. Jeder Protokolleintrag muss enthalten: einen GPS-synchronisierten Zeitstempel, die sendende Entität, die Zielenklave, einen Hash der Nachrichtennutzdaten, die extrahierten Kennzeichnungs-Token, die ausgelöste Richtlinienregel und das Entscheidungsergebnis. Protokolle müssen auf einem System gespeichert werden, auf das weder das High-Side- noch das Low-Side-Netzwerk schreiben oder von dem es löschen kann. Protokollintegrität wird mit einer HMAC-Kette durchgesetzt — jeder Eintrag enthält den HMAC des vorherigen Eintrags, sodass jede Änderung erkennbar ist. Die Aufbewahrung beträgt typischerweise mindestens drei Jahre für Audit-Protokolle klassifizierter Systeme.

Kann ein CDS-Guard Echtzeit-Streaming-Daten wie Video oder Lage-Feeds verarbeiten?

Ja, aber die Architektur unterscheidet sich von der nachrichtenbasierten Übertragung. Für Video ist eine unidirektionale Datendiode in Kombination mit einem Video-Transcodierungs-Proxy der Standardansatz: Der klassifizierte Stream tritt auf der hohen Seite in den Proxy ein, der Proxy kodiert ihn in einen sauberen Bitstrom um und entfernt alle Metadaten, und der bereinigte Stream verlässt die Diode zur Low-Side-Anzeige. Für Echtzeit-Lage-Feeds proxiest ein inhaltsbewusster Guard jede Lageaktualisierungsnachricht und prüft Klassifizierungsfelder vor der Weiterleitung. CDS-Produkte, die für Hochdurchsatz-Streaming bewertet wurden, gibt es auf der EPL, müssen aber speziell für die Nachrichtenraten des beabsichtigten Deployments bewertet werden.

Wie lange dauert die NSA/DISA-Akkreditierung eines neuen CDS-Deployments typischerweise?

Ein CDS-Deployment mit einem Produkt, das bereits auf der NSA/CSS EPL und der DISA UC APL aufgeführt ist, erfordert typischerweise 6 bis 18 Monate für die standortspezifische ATO-Bearbeitung, vorausgesetzt, der Sicherheitsplan ist vollständig und die Konfiguration entspricht der bewerteten Grundlage. Deployments mit benutzerdefinierten Guard-Komponenten erfordern eine vollständige staatlich geförderte Bewertung, die typischerweise 18 bis 36 Monate dauert. Programme, die vor Abschluss der Akkreditierung einsetzen, stoßen typischerweise auf erzwungene Abschaltbefehle, wenn Inspektoren die Lücke identifizieren. Den ATO-Prozess von Anfang an mit realistischen Zeitplänen in den Programmzeitplan einzubauen ist für jedes CDS-abhängige Programm unerlässlich.