Aufbau einer Verteidigungs-Fusionspipeline, Teil 3: Multi-INT-Fusion, Klassifizierung und Releasability

Die Teile 1 und 2 haben eine Fusionspipeline für eine einzelne Quelle aufgebaut. Die Teile 3 und 4 schließen die Lücke zur operativen Realität der Verteidigung. Reale Verteidigungsfusion verarbeitet Eingaben aus mehreren Nachrichtendisziplinen — SIGINT, IMINT, ELINT, OSINT, HUMINT, GEOINT, MASINT — jede mit eigener Semantik, Latenz, Klassifizierung und Releasability. Sie als austauschbare Beobachtungen zu behandeln ist der häufigste architektonische Fehlschlag in Verteidigungs-Fusionsprogrammen. Teil 3 behandelt das Engineering der Multi-INT-Fusion und die Klassifizierungs-Maschinerie, die nur die Verteidigung in dieser Form benötigt.

Die konzeptionelle Grundlage findet sich im Vollständigen Leitfaden zur Datenfusion in der Verteidigung; die Rahmung zum Koalitions-Datenaustausch in Herausforderungen des Koalitions-Datenaustauschs; die RBAC-Grundlagen in Rollenbasierte Zugriffskontrolle in Verteidigungs-C2-Systemen.

Schritt 1: Multi-INT-Semantik ist nicht austauschbar

Jede Nachrichtendisziplin trägt eine andere Semantik. Ein SIGINT-Kontakt mit reiner Peilung sagt Ihnen die Richtung, aber nicht die Entfernung. Eine IMINT-Beobachtung liefert eine präzise Position zu einem einzelnen Zeitpunkt, aber keine Kinematik. Ein OSINT-Bericht hat eine unsichere Attribution, aber potenziell reichen Kontext. Ein HUMINT-Bericht hat hohe Latenz und Anforderungen an den Quellenschutz. Diese in einen generischen "Beobachtungs"-Datensatz zu kollabieren, verliert die Information, die die Fusion benötigt, um vertrauenswürdige Tracks zu produzieren.

Die Felder, die Multi-INT-Beobachtungen unterscheiden:

• SIGINT — Peilungslinie, Frequenz, Modulation, Emittertyp, Abfangzeit. Position wird durch Triangulation berechnet, wenn mehrere Stationen denselben Emitter melden; andernfalls unbekannt.
• IMINT — präzise Position aus der Bildauswertung, Identität aus visueller oder automatisierter Klassifikation, Erfassungszeit. Wiederbesuchsraten gemessen in Stunden.
• ELINT — Emitter-Charakterisierung (Radarpulsparameter, Signatur). Überlappt mit SIGINT, konzentriert sich aber auf die elektronische Gefechtsordnung.
• OSINT — aus öffentlichen Quellen extrahiert, mit Attributionsunsicherheit, Quellenkonfidenz, Zitationskette. Zunehmend wichtig; behandelt in OSINT-Bedrohungsüberwachung für die Verteidigung.
• HUMINT — menschliche Quellenaufklärung, hohe Latenz, sensible Klassifizierung und Quellenschutz. Kann nicht ohne Releasability-Bereinigung an Koalitionspartner weitergegeben werden.
• GEOINT — kombiniert Bildmaterial mit Geländeanalyse, Routenvorhersage, Verhaltensmuster-Inferenz.
• MASINT — Mess- und Signaturaufklärung; umfasst akustische, infrarote, nukleare und andere spezialisierte Sensorik. Häufig domänenspezifisch (U-Boot-Abwehr, Raketenabwehr).

Das kanonische Track-Schema beherbergt diese, indem es neben den Standardfeldern Metadaten zur Quelldisziplin mitführt. Die Fusions-Engine referenziert die Disziplin bei der Berechnung der Assoziationswahrscheinlichkeiten (eine SIGINT-Beobachtung mit reiner Peilung kann einen kinematischen Track ohne Peilungsabgleichslogik nicht direkt aktualisieren; eine IMINT-Punktfixierung sollte die Position aktualisieren, aber nicht die Geschwindigkeit).

Schritt 2: Die Architektur der Multi-INT-Fusion

Das architektonische Muster für Multi-INT-Fusion, das in der Produktion funktioniert:

Adapter pro Disziplin. Jede Nachrichtendisziplin verfügt über eine eigene Familie von Adaptern mit disziplinspezifischer Logik. Die Aufgabe des Adapters besteht darin, Beobachtungen im kanonischen Schema zu erzeugen, die mit der Quelldisziplin getaggt sind — nicht darin, zwischen den Disziplinen zu interpretieren.

Disziplin-bewusste Korrelation. Die Korrelationslogik der Fusions-Engine referenziert die Metadaten der Quelldisziplin. Regelbasiertes Gating umfasst Disziplin-Kompatibilitätsregeln ("ein HUMINT-Bericht über ein Schiff kann einen IMINT-bestätigten Schiffs-Track nur dann aktualisieren, wenn die Identität mit hoher Konfidenz übereinstimmt"). Probabilistische Assoziation verwendet disziplinspezifische Priors.

Fusion als Anreicherung, nicht als Ersatz. Wenn Multi-INT-Beobachtungen übereinstimmen, verstärken sie die Konfidenz. Wenn sie sich widersprechen, bringt die Fusions-Engine die Diskrepanz beim Operator zur Anzeige, statt eine davon auszuwählen. Ein Track mit zwei konfidenzstarken, aber widersprüchlichen Identitätsberichten ist nicht "falsch" — er ist genuin mehrdeutig, und der Operator muss das wissen.

Disziplinübergreifende Analytik als separate Dienste. Analytik höherer Ordnung, die mehrere Disziplinen umspannt — Verhaltensmustererkennung (Verhaltensmusteranalyse), Anomalieerkennung im Verhalten, Netzwerkanalyse — läuft als separater Dienst, der den fusionierten Track-Stream konsumiert. Diese Dienste produzieren angereicherte Annotationen auf bestehenden Tracks, nicht neue Tracks, die mit der Fusions-Engine konkurrieren.

Schritt 3: Klassifizierungs-Labelling nach STANAG 4774/4778

Jedes Datenobjekt, das die Plattform produziert, trägt ein Vertraulichkeits-Label. STANAG 4774 definiert das Label-Format; STANAG 4778 definiert die kryptografische Bindung, die das Ablösen von Labels von den von ihnen gekennzeichneten Daten verhindert. Zusammen bilden sie die Grundlage jeglichen Koalitions-Datenaustauschs im NATO-Kontext.

Die Engineering-Integration:

Quellklassifizierung wird von jedem Adapter mitgeführt. Jeder Adapter kennt die Klassifizierung seiner Quelle (konfiguriert im Quellenkatalog aus Teil 1) und taggt jede Beobachtung damit. Der Adapter ist die maßgebliche Quelle für die Klassifizierung seiner Beobachtungen.

Labels sind strukturiert, nicht Zeichenketten. Ein Klassifizierungs-Label ist nicht "SECRET"; es ist ein strukturiertes Objekt mit Klassifizierungsstufe, Kompartimenten, Releasability-Tags und Bindungssignatur. Die Label-Bibliothek implementiert STANAG-4774-Serialisierung und STANAG-4778-Bindung; jede Beobachtung passiert sie.

Labels werden propagiert, nicht neu erzeugt. Wenn die Fusions-Engine einen Track aktualisiert, wird die effektive Klassifizierung des Tracks aus der Quellenmenge berechnet, nicht unabhängig zugewiesen. Ein Track, der aus einer SECRET-Radarrückkehr und einer UNCLASSIFIED-AIS-Nachricht abgeleitet ist, ist SECRET. Die Propagationsdisziplin ist mechanisch; sie falsch zu handhaben ist ein Akkreditierungsversagen.

Bindung überlebt die Serialisierung. Wenn Tracks auf die Platte, auf den Message Bus oder über die Leitung serialisiert werden, bleibt die STANAG-4778-Bindung erhalten. Die Bindung zur "Bequemlichkeit" zu entfernen ist genau die Art von Abkürzung, nach der Akkreditierungsprüfer gezielt suchen.

Schritt 4: Klassifikationspropagation durch die Fusion

Die Fusions-Engine erzeugt abgeleitete Daten. Ein Track ist eine Ableitung aus mehreren Quellbeobachtungen; seine Klassifizierung muss aus deren Klassifizierungen berechnet werden. Die Propagationsregeln:

Die Klassifizierungsstufe ist das Maximum über die Quellenmenge. Ein Track, abgeleitet aus SECRET- und UNCLASSIFIED-Quellen, ist SECRET. Die High-Water-Mark-Regel ist unerbittlich, aber gut verstanden.

Kompartimente sind die Vereinigung über die Quellenmenge. Ein Track, abgeleitet aus einer Quelle im Kompartiment HIGH-VALUE-TARGET und einer Quelle im Kompartiment HUMAN-INTELLIGENCE, trägt beide Kompartimente. Der Zugriff erfordert Freigabe in beiden.

Releasability ist die Schnittmenge über die Quellenmenge. Ein Track, abgeleitet aus FVEY-only- und NATO-only-Quellen, ist nur an die Schnittmenge freigebbar (FVEY-und-NATO, was in der Praxis die vier FVEY-Nationen bedeutet, die auch NATO-Mitglieder sind). Die Schnittmengenregel ist operativ am folgenreichsten und die in ad hoc Implementierungen am häufigsten fehlerhafte.

Klassifizierung pro Attribut, wo es darauf ankommt. Die Position eines Tracks kann breit freigebbar sein, während seine Identität stärker eingeschränkt ist. Das Schema unterstützt Klassifizierung pro Attribut; die Policy Engine bewertet den Zugriff pro Attribut zur Abfragezeit.

Schritt 5: Die Releasability-Policy-Engine

Klassifizierungs-Labels auf Daten sind notwendig, aber nicht hinreichend. Zugriffsentscheidungen erfordern eine Policy Engine, die Freigabe, Staatsbürgerschaft, Rolle des Nutzers sowie Klassifizierung, Kompartimente und Releasability der angeforderten Daten kennt. Jede Abfrage gegen den Track-Speicher passiert diese Engine.

Das Engineering-Muster:

Policy as Code. Releasability-Regeln werden in einer versionierten Policy-Sprache ausgedrückt — das Rego von Open Policy Agent (OPA) ist der vertretbare Standard. Policy-Änderungen durchlaufen Code Review, nicht Konfigurationsänderungen. Die Historie der Policy-Entscheidungen ist aus der Versionskontrolle heraus prüfbar.

Entscheidungsbewertung an der Abfragegrenze. Wenn ein Konsument den Track-Speicher abfragt, bewertet die Policy Engine, welche Tracks sichtbar sind und welche Attribute pro Track sichtbar sind. Das Ergebnis ist eine gefilterte Sicht, nicht die vollständigen Daten mit einer UI-Maske. Reine UI-Filterung ist ein Verstoß gegen Common Criteria und ein Akkreditierungs-Showstopper.

Audit-Log pro Entscheidung. Jede Zugriffsentscheidung — welcher Nutzer, welche Daten, welche Klassifizierung, welches Ergebnis — wird unveränderbar protokolliert. Das Audit-Log ist die Evidenzbasis für Akkreditierungsprüfungen und operative forensische Analysen.

Performance-Budgets. Die Policy Engine sitzt auf dem kritischen Pfad des COP; ihre Auswertungslatenz muss pro Entscheidung im Submillisekundenbereich liegen. Caching-Strategien, vorkompilierte Policy-Bundles und Per-User-Policy-Fingerprints sind allesamt relevant. Eine naive Policy Engine ist die häufigste Ursache für COP-Verlangsamungen in klassifizierten Deployments.

Die ausführliche Behandlung des Policy-Engine-Musters, der Implikationen für den Koalitions-Datenaustausch und der zu vermeidenden operativen Antipattern findet sich in Herausforderungen des Koalitions-Datenaustauschs.

Schritt 6: Enklavenübergreifende Datenflüsse

Verteidigungsnetze sind keine Einzelenklaven. Eine Plattform, die über NATO RESTRICTED, NATO SECRET und national klassifizierte Netze hinweg operiert, muss angemessene Daten zwischen ihnen bewegen und gleichzeitig unangemessene Datenflüsse verhindern. Das Architekturmuster:

Fusionsinstanzen pro Enklave. Jede klassifizierte Enklave betreibt ihre eigene Fusionsinstanz mit eigener Quellenmenge, eigenem Track-Speicher und eigener Policy Engine. Die Instanzen sind physisch getrennt; die Plattform geht nicht davon aus, dass sie Zustände teilen.

Cross-Domain-Brücken. Wo Daten legitim zwischen Enklaven bewegt werden — zum Beispiel ein unklassifizierter AIS-Feed, der in eine SECRET-Enklave hochfließt, oder ein releasability-bereinigtes Produkt, das in eine Koalitions-Enklave hinunterfließt — verläuft die Bewegung über eine akkreditierte Cross-Domain-Brücke, nicht über eine direkte Verbindung. Die Brücke erzwingt die Klassifizierungsregeln an der Grenze.

Einweg-Dioden, wo die Physik die Richtung erzwingt. Für die Datenbewegung von High-Side zu Low-Side (die selten und operativ sensibel ist) erzwingen Einweg-Datendioden die Richtung auf der Netzwerkebene. Die Fusionsplattform integriert sich in die Dioden-Infrastruktur, anstatt eine eigene zu implementieren.

Manuelle Freigabe, wo Automatisierung versagt. Einige Klassifizierungsentscheidungen lassen sich nicht sicher automatisieren. Freigabeentscheidungen pro Produkt für HUMINT oder kompartimentierte Daten können menschliche Genehmigung erfordern. Die Plattform muss den Workflow abbilden — den Freigabekandidaten anzeigen, die menschliche Entscheidung erfassen, die genehmigte Freigabe propagieren.

Schritt 7: Operative Erwägungen

Multi-INT-Fusion im Betrieb bringt Herausforderungen zum Vorschein, die in der Entwicklung nicht sichtbar sind. Die Disziplinen, die operative Plattformen von Demo-Plattformen unterscheiden:

Quellenattribution überlebt die Propagation. Wenn ein Track abgefragt wird, enthält die Antwort die Quellenmenge, die zu ihm beigetragen hat. Operatoren müssen wissen, ob eine Position aus Radar (hohe kinematische Konfidenz, Identität unsicher) oder HUMINT (geringe räumliche Präzision, kontextreiche Identität) stammt. Quellenattribution macht das transparent.

Widerspruch wird bewahrt, nicht kollabiert. Wenn zwei Quelldisziplinen über die Identität eines Tracks uneins sind, bewahrt die Fusions-Engine beide Alternativen mit Konfidenzen. Der Operator entscheidet; die Plattform bringt zur Anzeige.

Kompartiment-Fan-out ist begrenzt. Ein Track mit vielen Kompartimenten hat viele unterschiedliche potenzielle Adressaten. Das System muss Releasability effizient berechnen, auch wenn die Kompartimentmenge groß ist.

Audit deckt jede Freigabeentscheidung ab. Jeder Cross-Domain-Transfer, jedes Filterergebnis pro Abfrage, jede Kompartiment-Eskalation wird protokolliert. Das Audit-Log unterstützt operative forensische Prüfungen, Akkreditierungsnachweise und After-Action-Analysen. Das detaillierte Muster ist in Event Sourcing für Verteidigungs-Audit-Trails behandelt.

Cyber-Beobachtungen als Multi-INT

Zunehmend fließen Cyber-Beobachtungen in dieselbe Fusionspipeline wie Beobachtungen aus der physischen Domäne. Ein bestätigter Netzwerkeinbruch, ein geleakter Anmeldedatensatz, ein OSINT-abgeleiteter Attributionshinweis — jeder kann zu einer Beobachtung im Multi-INT-Fusionsstrom werden. Die architektonische Eignung ist real, erfordert aber Sorgfalt: Cyber-Daten haben andere Latenz-, Konfidenz- und Klassifizierungs-Semantik als Daten der physischen Domäne. Das Muster wird in CTI-Plattformen für die Verteidigung behandelt und die breitere Sicht auf Cyber als Fusionsdisziplin in Der vollständige Leitfaden zur Cybersicherheit in der Verteidigung.

Die Engineering-Entscheidung: Bauen Sie cyberspezifische Adapter, die Beobachtungen im kanonischen Schema mit der Disziplin "Cyber" erzeugen, während die cyberspezifischen Metadaten (Indicators of Compromise, Bedrohungsakteur-Attribution, Kill-Chain-Phase) erhalten bleiben. Die Fusions-Engine behandelt Cyber-Beobachtungen wie andere Multi-INT-Eingaben; das cyberspezifische Tooling (CTI-Plattformen, SIEM/SOAR) konsumiert denselben Track-Stream für seine eigenen Zwecke.

Wie es weitergeht

Teil 3 hat die Maschinerie für Multi-INT und Klassifizierung behandelt. Die Plattform korreliert nun Beobachtungen über Nachrichtendisziplinen hinweg unter Erhaltung ihrer semantischen Unterschiede, propagiert die Klassifizierung korrekt durch die Fusion, erzwingt Releasability über eine Policy Engine und operiert über Grenzen klassifizierter Enklaven hinweg.

Teil 4 schließt die Serie mit der Operationalisierung ab: Drift-Monitoring auf den Fusionsalgorithmen, die Audit-Pipeline, die die Akkreditierung unterstützt, die Produktions-Deployment-Muster (Cloud bis Air-Gapped) und die Long-Tail-Wartungsdisziplin, die die Plattform über einen 20-Jahre-Lebenszyklus betriebsbereit hält.