STANAG 4774/4778 umsetzen: Vertraulichkeitskennzeichen in der Praxis

Datenzentrische Sicherheit – die Idee, dass der Schutz dem Datenobjekt folgt statt dem Netzwerkperimeter – ist nicht neu, aber ihre praktische Umsetzung in militärischen Koalitionssystemen war historisch schwierig. STANAG 4774 und STANAG 4778 sind die formale Antwort der NATO: zwei ineinandergreifende Standards, die definieren, wie Vertraulichkeitskennzeichen strukturiert sind, wie sie an Daten gebunden werden und wie Richtlinien-Engines sie bewerten. Dieser Artikel behandelt die praktische Entwicklung einer konformen Kennzeichnungsumsetzung: Kennzeichensyntax, den Bindungsmechanismus, das Design des Policy Enforcement Point, die Aggregationsbehandlung und die Disziplin des Kennzeichenerhalts, die darüber entscheidet, ob Ihre Architektur die Akkreditierungsprüfung übersteht. Für den Kontext der Einstufungs- und Freigaberichtlinie, der diese Entwicklungsarbeit rahmt, siehe den begleitenden Artikel über STANAG-4774/4778-Einstufung und Koalitionsfreigabe.

Das datenzentrische Sicherheitsmodell: Warum Kennzeichen mit den Daten reisen

Herkömmliche netzwerkzentrische Sicherheit stützt sich auf den Einstufungsgrad der Enklave: Sobald ein Datenstück in einem SECRET-Netz liegt, gilt jedes System in diesem Netz als vertrauenswürdig für dessen Behandlung. Dieses Modell bricht in Koalitionsumgebungen zusammen, in denen sich Daten zwischen Enklaven mit unterschiedlichen Akkreditierungsniveaus, unterschiedlichen nationalen Richtlinien und unterschiedlichen Mengen berechtigter Empfänger bewegen. Ein SECRET-Dokument in einem gemeinsamen Netz ist nicht zwangsläufig an jede Partnernation mit Zugang zu diesem Netz freigabefähig.

Datenzentrische Sicherheit löst dies, indem das Kennzeichen zu einer untrennbaren Eigenschaft des Datenobjekts wird. Jedes Objekt trägt ein maschinenlesbares Vertraulichkeitskennzeichen, das seinen Einstufungsgrad, die seine Nutzung regelnden Behandlungsvorbehalte und die Freigabemarkierungen angibt, die identifizieren, welche Organisationen zu seinem Empfang berechtigt sind. Richtlinienentscheidungen – ob ein Objekt weitergeleitet, angezeigt, gespeichert oder gedruckt wird – werden getroffen, indem das Kennzeichen des Objekts gegen die Freigabestufe des anfragenden Subjekts und das Akkreditierungsniveau des Zielsystems bewertet wird, statt darauf zu vertrauen, dass das Netz die richtige Grenze durchsetzt.

STANAG 4774 definiert die Kennzeichenstruktur. STANAG 4778 definiert den Bindungsmechanismus. Gemeinsam bilden sie das technische Substrat für Datenaustausch in Koalitionen, der die nationale Offenlegungsrichtlinie jeder Nation respektiert, ohne eine manuelle Prüfung jedes Datenaustauschs zu erfordern. Das Verständnis beider Standards als Paar – nicht isoliert – ist die Voraussetzung für eine konforme Umsetzung.

STANAG-4774-Kennzeichensyntax: Struktur und Codierung

Ein STANAG-4774-Vertraulichkeitskennzeichen ist ein XML-Dokument, das dem STANAG-4774-XML-Schema entspricht. Sein oberstes Element ist <ConfidentialityLabel>, das drei verpflichtende Kindelemente und mehrere optionale Erweiterungen trägt.

Richtlinienbezeichner. Das Element <PolicyIdentifier> enthält einen Objektbezeichner (OID), der auf das diese Kennzeichnung regelnde Kennzeichen-Richtliniendokument verweist. Die OID ist bei einer anerkannten Stelle registriert – typischerweise dem nationalen C3-Büro oder der NATO-C3-Agentur – und ist der Schlüssel, der es empfangenden Systemen erlaubt, die vollständige Richtliniendefinition nachzuschlagen und das Kennzeichen korrekt zu bewerten. Ein Kennzeichen ohne auflösbare Richtlinien-OID kann von einer konformen Richtlinien-Engine nicht bewertet werden und muss als nicht verifiziert behandelt werden.

Einstufung. Das Element <Classification> gibt den Einstufungsgrad als Aufzählungswert an: UNCLASSIFIED, RESTRICTED, CONFIDENTIAL oder SECRET. Die Codierung unterscheidet Groß-/Kleinschreibung und muss exakt den im durch die OID referenzierten Richtliniendokument definierten Zeichenkettenwerten entsprechen. Ein Kennzeichen, das "Secret" statt "SECRET" verwendet, scheitert in einer konformen Umsetzung an der Schemavalidierung – ein häufiger Integrationsfehler beim Erzeugen von Kennzeichen aus Allzweck-XML-Bibliotheken, die die Aufzählung nicht durchsetzen.

Behandlungsvorbehalte und Freigabe. Das Element <CategoryData> trägt Behandlungsvorbehalte wie ATOMAL, CRYPTO, EYES ONLY oder von der Richtlinie definierte missionsspezifische Vorbehalte. Das Element <PermittedCountryCodes> trägt die Freigabemarkierung als Menge von ISO-3166-1-alpha-3-Ländercodes. Die Freigabemarkierung ist in multinationalen Umgebungen der operativ wichtigste Teil des Kennzeichens: Sie bestimmt, welchen Partnernationssystemen unabhängig vom Einstufungsgrad der Empfang der gekennzeichneten Daten erlaubt ist.

Kennzeichenerzeugung: Validierungsanforderungen

Jedes von einem konformen System erzeugte Kennzeichen muss gegen das STANAG-4774-XML-Schema validiert werden, bevor es an ein Datenobjekt gebunden wird. Die Schemavalidierung erkennt strukturelle Fehler – fehlerhafte OIDs, ungültige Einstufungszeichenketten, fehlende verpflichtende Elemente –, validiert aber nicht die semantische Korrektheit gegen das Richtliniendokument. Ein separater Validierungsschritt auf Richtlinienebene muss prüfen, dass jeder Vorbehalt und jede Freigabemarkierung im Kennzeichen im referenzierten Richtliniendokument definiert ist und dass die Kombination aus Einstufungsgrad und Vorbehalten von dieser Richtlinie erlaubt ist. Eine Umsetzung, die die Validierung auf Richtlinienebene überspringt, erzeugt Kennzeichen, die die Schemavalidierung bestehen, aber von nachgelagerten Richtlinien-Engines mit im Nachhinein schwer zu diagnostizierenden Fehlern abgelehnt werden. Bauen Sie den Validierungsschritt auf Richtlinienebene in den Kennzeichengenerator ein, nicht in ein separates Audit nach der Erzeugung.

STANAG-4778-Bindungsmechanismen: Assertion und Kapselung

STANAG 4778 definiert zwei Mechanismen zur Bindung eines STANAG-4774-Kennzeichens an ein Datenobjekt: Assertionsbindung und Kapselungsbindung. Sie dienen unterschiedlichen Anwendungsfällen und haben unterschiedliche Sicherheitseigenschaften, und die Wahl zwischen ihnen muss zum Zeitpunkt des Architekturentwurfs getroffen werden.

Die Assertionsbindung erzeugt eine signierte XML-Assertion, die das Kennzeichen, einen Verweis auf das Datenobjekt (typischerweise einen kryptografischen Hash der Nutzlast) und eine digitale Signatur der Kennzeichenbehörde enthält. Die Signatur wird mittels XML Digital Signature (XMLDSig) über das kanonisierte Kennzeichen-XML berechnet. Das Datenobjekt und die signierte Assertion werden zusammen übertragen – entweder in derselben Nachrichtenhülle oder als Verweis-und-Assertion-Paar. Das empfangende System verifiziert die Assertion, indem es die Signatur gegen das Zertifikat des öffentlichen Schlüssels der Kennzeichenbehörde prüft, und prüft anschließend den Hash des Datenobjekts gegen den Hash in der Assertion. Bestehen beide Prüfungen, ist das Kennzeichen als authentisch und unverändert verifiziert, und die Bindung zwischen Kennzeichen und Datenobjekt ist kryptografisch bestätigt.

Die Assertionsbindung ist für Daten verpflichtend, die Einstufungsgrenzen über eine Cross-Domain-Solution (CDS) überschreiten. Der Akkreditierer muss verifizieren, dass die CDS Kennzeichen korrekt durchsetzt, und die signierte Assertion liefert die für diese Verifikation erforderlichen Audit-Nachweise. Ohne Assertionsbindung an der CDS-Grenze kann der Akkreditierer nicht bestätigen, dass die dem System der niedrigen Seite präsentierten Kennzeichen authentische Repräsentationen der Entscheidung der Kennzeichenbehörde der hohen Seite sind – und die CDS wird nicht akkreditiert.

Die Kapselungsbindung bettet das Kennzeichen direkt in die Struktur des Datenobjekts ein – in einen Nachrichtenheader, einen Metadatenblock oder ein definiertes Erweiterungsfeld. Es gibt keine separate kryptografische Signatur; die Bindung beruht auf der Integrität des Transportkanals. Die Kapselungsbindung ist einfacher umzusetzen und wird weithin für Daten verwendet, die innerhalb einer einzelnen Sicherheitsdomäne verbleiben. Für ein C2-System, das vollständig innerhalb einer SECRET-Enklave arbeitet, ist die Kapselungsbindung im Nachrichtenschema ausreichend und vermeidet den PKI-Aufwand der Assertionsbindung für jede interne Nachricht.

Das Mischen von Bindungsmechanismen innerhalb desselben Systems – Kapselungsbindung für interne Nachrichten und Assertionsbindung nur an der CDS-Grenze – ist korrekt und üblich, aber die Grenze muss in der Umsetzung klar definiert und durchgesetzt sein. Mehrdeutigkeit darüber, welcher Bindungsmechanismus an welcher Systemgrenze gilt, ist eine Quelle von Akkreditierungsbefunden.

Design des Policy Enforcement Point

Ein Policy Enforcement Point (PEP) ist die Softwarekomponente, die Datenzugriffs- und Austauschanfragen abfängt und das Kennzeichen des angeforderten Objekts gegen die Freigabestufe des anfragenden Subjekts und das Akkreditierungsniveau des anfragenden Systems bewertet. In einer STANAG-4774/4778-konformen Architektur ist der PEP nicht optional: Er ist der Mechanismus, durch den das Kennzeichen tatsächliche Zugriffskontrolle erzeugt, statt lediglich eine niemals bewertete Metadaten-Anmerkung zu sein.

Der PEP-Bewertungsalgorithmus muss die Dominanz korrekt umsetzen. Ein Subjekt kann genau dann auf ein Objekt zugreifen, wenn die Freigabestufe des Subjekts das Kennzeichen des Objekts dominiert: Der Einstufungsgrad des Subjekts ist mindestens so hoch wie der des Objekts, das Subjekt hält alle von den Behandlungsmarkierungen des Objekts geforderten Vorbehalte, und die berechtigte Freigabemenge des Subjekts deckt alle Freigabemarkierungen des Objekts ab. Jede dieser drei Bedingungen muss unabhängig bewertet werden; das Bestehen von zwei von drei ist ein Richtlinienverstoß, keine teilweise Zugriffsgewährung.

Die am häufigsten falsch umgesetzte Bedingung ist die Freigabe. Ein korrekter Freigabevergleich prüft, dass die berechtigte Freigabemenge des empfangenden Systems eine Obermenge der Freigabemarkierung des Objekts ist. Ein für REL TO DEU GBR USA berechtigtes System kann ein mit REL TO DEU GBR markiertes Objekt empfangen, weil die berechtigte Menge alle markierten Nationen enthält. Ein für REL TO GBR USA berechtigtes System kann ein mit REL TO DEU GBR markiertes Objekt nicht empfangen, obwohl GBR in beiden Mengen erscheint, weil DEU nicht in der berechtigten Menge des empfangenden Systems ist. Die Umsetzung einer Obermengenprüfung statt einer Schnittmengenprüfung ist die korrekte Logik; die Schnittmengenprüfung ist der häufige Fehler und erzeugt ein System, das Zugriff auf Objekte gewährt, zu deren Empfang es nicht berechtigt ist.

Aggregation und Kennzeicheneskalation

Aggregation – das Kombinieren von zwei oder mehr gekennzeichneten Objekten zu einem abgeleiteten Produkt – ist das schwierigste Problem in einer praktischen STANAG-4774/4778-Umsetzung. Das abgeleitete Produkt muss ein Kennzeichen tragen, das mindestens so restriktiv ist wie die restriktivste Eingabe, über alle drei Kennzeichenkomponenten hinweg: Einstufungsgrad, Behandlungsvorbehalte und Freigabe.

Für den Einstufungsgrad ist die Regel einfach: Die Ausgabeeinstufung ist das Maximum der Eingabeeinstufungen. Ein aus RESTRICTED- und CONFIDENTIAL-Eingaben abgeleitetes Produkt ist CONFIDENTIAL. Für Behandlungsvorbehalte muss die Ausgabe die Vereinigung aller Eingabevorbehalte enthalten: Trägt eine Eingabe ATOMAL und eine andere CRYPTO, muss die Ausgabe beide tragen. Für die Freigabe muss die Ausgabe die Schnittmenge der Eingabe-Freigabemengen tragen: Ist eine Eingabe an DEU GBR USA freigabefähig und eine andere an GBR FRA, ist die Ausgabe nur an GBR freigabefähig, weil nur GBR für beide Eingaben berechtigt ist.

Diese Aggregationslogik muss in jeder Komponente umgesetzt werden, die abgeleitete Daten erzeugt: Fusions-Engines, Berichtsgeneratoren, Zusammenfassungsdienste und jede Analysepipeline, die Eingaben aus mehreren Quellen kombiniert. Die Kennzeichenaggregationsberechnung muss erfolgen, bevor das Ausgabeobjekt in einen Puffer oder eine Warteschlange geschrieben wird, nicht als Nachverarbeitungsschritt. Eine Ausgabe, die auch nur kurz ohne korrektes Kennzeichen existiert – bevor ein Nachverarbeitungsschritt auslöst –, stellt ein Fenster der Richtlinien-Nichtkonformität dar, das ein Akkreditierer während der Entwurfsprüfung identifizieren wird.

Kennzeichenerhalt im Koalitionsaustausch

Kennzeichenerhalt ist die Disziplin sicherzustellen, dass ein STANAG-4774-Kennzeichen und seine STANAG-4778-Bindung den vollständigen Transitpfad vom Ursprungssystem zu jedem berechtigten Empfänger überstehen, einschließlich durch Middleware, Nachrichtenbroker, Föderationsgateways und Formatumwandlungskomponenten, die möglicherweise nicht kennzeichenbewusst sind.

In einer Federated-Mission-Network-(FMN-)konformen Austauschinfrastruktur ist der Kennzeichenerhalt in das Profil eingebaut: Die FMN-Dienstschicht ist verpflichtet, STANAG-4774-Kennzeichen in Nachrichtenhüllen zu tragen und Bindungen beim Einlesen zu verifizieren. In der Praxis enthalten viele eingesetzte Systeme Komponenten, die der FMN-Konformität vorausgehen oder ohne Kennzeichenbewusstsein integriert wurden – veraltete Nachrichtenrelais, nicht konforme CoT-Router, Datenbank-Middleware, die Metadaten beim Einfügen entfernt. Jede solche Komponente stellt einen potenziellen Kennzeichenverlustpunkt dar, der im Systementwurf identifiziert und gemildert werden muss.

Die Standardabhilfe gegen das Kennzeichenverlustrisiko besteht darin, für Daten, die nicht vertrauenswürdige Infrastruktur durchqueren, eine Assertionsbindung statt einer Kapselungsbindung zu verwenden. Da die Assertion Teil des Nutzlastkörpers und kein Transportheader ist, übersteht sie den Transit durch Komponenten, die Nachrichtenheader entfernen oder umschreiben. Am empfangenden Ende bestätigt die Verifikation der Assertionsbindung, dass das Kennzeichen authentisch und intakt ist, selbst wenn die Transport-Metadaten im Transit verändert wurden.

Für Systeme, die sich umfassender an NATO-Interoperabilitätsstandards ausrichten müssen, sollte das Testen des Kennzeichenerhalts als erstklassiges Testziel in den CWIX-Interoperabilitätstestplan integriert werden, nicht als spät hinzugefügter Zusatz. Ein System, das alle funktionalen Interoperabilitätstests besteht, aber Kennzeichen im Transit stillschweigend entfernt, scheitert an der Sicherheitsakkreditierungsprüfung, selbst wenn es nie einen einzigen funktionalen Test nicht besteht. Die Testsuite für den Kennzeichenerhalt muss Objekte mit bekannten Kennzeichen an jedem Eingangspunkt injizieren, Objekte an jedem Ausgangspunkt erfassen und prüfen und verifizieren, dass sowohl Kennzeicheninhalt als auch Bindungssignatur zwischen Injektion und Empfang identisch sind.