Plan wdrożenia interoperacyjności NATO, część 3: STANAG 4774/4778 — klasyfikacja i releasability koalicyjne

Łącza danych z części 2 przenoszą komunikaty. Maszyneria klasyfikacji i releasability decyduje, które komunikaty trafiają do kogo. STANAG 4774 definiuje format etykiet poufności; STANAG 4778 definiuje wiązanie kryptograficzne, które uniemożliwia odłączenie etykiet od oznaczonych nimi danych. Razem stanowią techniczny fundament całej koalicyjnej wymiany danych NATO. Platforma, która robi to dobrze, wdraża się w sieciach klasyfikowanych; platforma, która traktuje je jak maskę UI, nie przechodzi akredytacji w pierwszym cyklu przeglądu. Część 3 opisuje dyscyplinę wdrożeniową.

Ramy filarowe znajdują się w Kompletnym przewodniku po interoperacyjności NATO; szersze wzorce wymiany koalicyjnej w Wyzwaniach wymiany danych w koalicji; podstawy RBAC w Kontroli dostępu opartej na rolach w systemach C2; propagację po stronie fuzji w Budowie potoku fuzji obronnej, część 3.

Krok 1: Etykiety są danymi strukturalnymi, nie ciągami znaków

Najczęstszym błędem wdrożeniowym jest traktowanie klasyfikacji jako pola tekstowego — „SECRET”, „NATO RESTRICTED” — dołączonego do rekordów danych. Model STANAG 4774 jest bogatszy i strukturalnie odmienny.

Etykieta poufności STANAG 4774 to ustrukturyzowany obiekt zawierający:

• Identyfikator polityki. Polityka klasyfikacyjna, w ramach której nadano etykietę (NATO, krajowa, FVEY, UE). Polityka definiuje dopuszczalne poziomy klasyfikacji i kompartmenty.
• Poziom klasyfikacji. Wartość uporządkowana w ramach polityki — dla NATO: UNCLASSIFIED, RESTRICTED, CONFIDENTIAL, SECRET, COSMIC TOP SECRET.
• Kompartmenty. Nazwane zastrzeżenia ograniczające dostęp — operacyjnie istotne, charakterystyczne dla programu, często same w sobie klasyfikowane.
• Znaczniki releasability. Które państwa lub organizacje mogą otrzymać oznaczone dane — FVEY, REL TO NATO, REL TO konkretnym państwom.
• Zastrzeżenia. Dodatkowe ograniczenia (NOFORN, ORCON, inne zależne od polityki).
• Wytwórca. Podmiot produkujący, dla audytu i odpowiedzialności.
• Znacznik czasu utworzenia. Kiedy etykieta została nadana.

Wdrażaj je jako ustrukturyzowane typy z walidacją. Ciąg „SECRET REL FVEY” parsowany w czasie wykonania przez dopasowanie tekstu to wzorzec inżynierski, który nie zdaje akredytacji. Ustrukturyzowane typy, walidowane schematem na każdej granicy, to wzorzec, który zdaje.

Krok 2: Wiązanie kryptograficzne STANAG 4778

STANAG 4778 definiuje wiązanie kryptograficzne, które zapewnia, że etykieta nie może zostać odłączona od oznaczonych nią danych. Wiązanie jest obliczane przez wytwórcę i weryfikowane przez każdego konsumenta; bez weryfikacji etykieta może zostać usunięta, podmieniona lub zmodyfikowana.

Wzorzec wdrożeniowy:

Oblicz wiązanie w usłudze wytwarzającej. Gdy adapter, usługa fuzji lub inny komponent wytwarza dane, oblicza wiązanie nad krotką (etykieta, dane) za pomocą swojego klucza podpisującego. Klucz zakotwiczony jest w sprzętowo ugruntowanym magazynie zaufania; operacja podpisywania jest logowana.

Weryfikuj przy każdym odczycie. Konsumenci (COP, dalsza analityka, zewnętrzne bramy API) weryfikują wiązanie przed propagacją danych. Niepowodzenia weryfikacji są głośno logowane, a dane odrzucane — nie po cichu obniżane klasyfikacyjnie.

Zachowuj wiązanie przy serializacjach. Gdy dane trafiają na szynę komunikatów, do bazy danych, przez sieć do partnera koalicyjnego, wiązanie wędruje z nimi. Formaty magazynowania uwzględniają wiązanie; protokoły komunikacyjne je przenoszą. Pomijanie dla „wygody” to skrót, którego oceniający akredytację konkretnie szukają.

Wiązanie per-atrybut tam, gdzie wymagane. Niektóre obiekty danych mają atrybuty o różnych klasyfikacjach. Trasa może mieć pozycję UNCLASSIFIED, ale tożsamość SECRET. STANAG 4778 dopuszcza wiązanie per-atrybut; platforma wdraża je tam, gdzie wymaga tego model klasyfikacji.

Krok 3: Propagacja klasyfikacji przez fuzję i wyprowadzanie

Platformy obronne produkują dane pochodne. Trasa jest wyprowadzana z wielu obserwacji źródłowych; produkt fuzji wyprowadzany jest z wielu raportów wywiadowczych. Klasyfikacja danych pochodnych jest obliczana z klasyfikacji źródeł — nie nadawana niezależnie.

Reguły propagacji (powtórka z serii o fuzji i z artykułu filarowego):

• Poziom klasyfikacji: maksimum. Wyprowadzenie ze źródeł SECRET i UNCLASSIFIED ma poziom SECRET.
• Kompartmenty: suma. Wyprowadzenie ze źródeł kompartmentu A i kompartmentu B niesie oba kompartmenty.
• Releasability: przecięcie. Wyprowadzenie ze źródeł tylko-FVEY i tylko-NATO jest udostępnialne wyłącznie ich przecięciu.
• Zastrzeżenia: najbardziej restrykcyjne. NOFORN na dowolnym źródle czyni wyprowadzenie NOFORN.

Reguły są mechaniczne. Wdróż je jako bibliotekę, którą wywołuje każda usługa fuzji, adapter i punkt wyprowadzania. Ręcznie pisana propagacja w każdej usłudze osobno rozjeżdża się i produkuje niespójności, które wyłapują oceniający akredytację. Wspólna, generowana z kodu biblioteka, używana przez każdy komponent, to dyscyplina, która skaluje się.

Krok 4: Silnik polityk

Etykiety na danych są konieczne, ale niewystarczające. Decyzje dostępowe wymagają silnika polityk, który zna poświadczenie użytkownika, obywatelstwo, rolę oraz klasyfikację, kompartmenty i releasability żądanych danych. Każde zapytanie do platformy przechodzi przez ten silnik.

Wzorzec wdrożeniowy:

Polityka jako kod. Reguły releasability wyrażone w wersjonowanym języku polityk. Rego z Open Policy Agent to obronny domyślny wybór; alternatywy takie jak Cedar lub ręcznie pisane DSL-e istnieją, ale wprowadzają narzut utrzymania. Zmiany polityk przechodzą przez code review, a nie zmiany konfiguracji.

Ewaluacja decyzji na granicy zapytania. Gdy konsument odpytuje platformę, silnik polityk ewaluuje, które rekordy są widoczne i które atrybuty są widoczne w każdym rekordzie. Wynikiem jest przefiltrowany widok, obliczony w czasie zapytania. Filtrowanie tylko po stronie UI — wysyłanie pełnych danych do klienta i ukrywanie ich CSS-em lub JavaScriptem — to naruszenie Common Criteria i natychmiastowa porażka akredytacji.

Log audytu per-decyzja. Każda decyzja dostępowa — użytkownik, żądane dane, klasyfikacja, wynik — jest logowana w sposób niezmienialny. Log audytu to baza dowodów dla przeglądu po działaniu, analizy kryminalistycznej i okresowego przeglądu akredytacyjnego.

Budżety wydajnościowe. Silnik polityk leży na ścieżce krytycznej COP. Opóźnienie decyzji musi być subsekundowe — poniżej milisekundy. Strategie cache, prekompilowane pakiety polityk, odciski palca polityk per-użytkownik — wszystko ma znaczenie. Naiwny silnik polityk to najczęstsza przyczyna spowolnienia COP w wdrożeniach klasyfikowanych.

Decyzje per-atrybut tam, gdzie wymagane. Silnik ewaluuje nie tylko, czy rekord jest widoczny, ale które jego atrybuty. Trasa może być widoczna dla użytkownika koalicyjnego z udostępnioną pozycją, ale ukrytą tożsamością.

Krok 5: Przepływy danych między enklawami

Sieci obronne nie są pojedynczymi enklawami. Platforma działająca między sieciami NATO RESTRICTED, NATO SECRET i krajowo-klasyfikowanymi musi przenosić odpowiednie dane między nimi, jednocześnie zapobiegając przepływom nieodpowiednim.

Wzorce:

Instancje platformy per-enklawa. Każda klasyfikowana enklawa uruchamia własną instancję platformy z własnym magazynem danych, silnikiem polityk i logiem audytu. Instancje są fizycznie odseparowane; platforma nie zakłada, że dzielą stan.

Mosty międzydomenowe. Tam, gdzie dane legalnie przemieszczają się między enklawami — UNCLASSIFIED AIS płynący do enklawy SECRET, produkt z oczyszczoną releasability płynący w dół do enklawy koalicyjnej — przemieszczanie przechodzi przez akredytowane rozwiązanie międzydomenowe. Most egzekwuje reguły klasyfikacji na granicy.

Diody jednokierunkowe tam, gdzie wymagane. Dla przemieszczania danych z wysokiej klasyfikacji do niskiej, jednokierunkowe diody danych egzekwują kierunek na warstwie sieciowej. Platforma integruje się z infrastrukturą diody, zamiast wdrażać własną.

Ręczne zwolnienie tam, gdzie automatyzacja nie dotrze. Niektórych decyzji klasyfikacyjnych nie da się bezpiecznie zautomatyzować. Zwolnienie per-produkt HUMINT lub danych kompartmentowanych może wymagać akceptacji człowieka. Platforma uwypukla kandydata, rejestruje decyzję człowieka z atrybucją i propaguje zatwierdzone zwolnienie z audytem.

Szczegółowe inżynierskie omówienie wymiany danych w koalicji znajduje się w Wyzwaniach wymiany danych w koalicji.

Krok 6: Releasability specyficzne dla koalicji

Różne koalicje mają różne reguły releasability. Platforma, która chce być wdrażana w wielu kontekstach koalicyjnych, musi uwzględniać:

Releasability NATO. Standardowy zestaw poziomów klasyfikacji NATO i oznaczenie REL TO NATO. Większość platform operacyjnych celuje w tę bazową linię najpierw.

Tylko-FVEY. Porozumienie wywiadowcze Five Eyes (AUS, CAN, NZ, UK, US) używa polityk klasyfikacyjnych, które nie mapują się czysto na poziomy NATO. Platforma celująca w konteksty FVEY wdraża politykę FVEY obok NATO.

Porozumienia dwustronne. Wiele platform ma dwustronne porozumienia o wymianie danych z konkretnymi partnerami. Ukraina, Izrael, Korea, Japonia — wszystkie mają porozumienia specyficzne dla programu. Silnik releasability uwzględnia je jako konkretne oznaczenia REL TO plus dostęp do kompartmentów specyficznych dla partnera.

Releasability UE. Programy finansowane przez UE mają własną politykę klasyfikacyjną (EU CONFIDENTIAL, EU SECRET), która nie zwija się do poziomów NATO. Platformy finansowane z EDF muszą uwzględniać zarówno klasyfikację NATO, jak i UE.

Dyscyplina: wdróż wielopolitykowy silnik klasyfikacji, nie pojedynczo-polityczny. Silnik zna NATO, FVEY, UE i polityki dwustronne jako nazwane byty; dane niosą politykę, pod którą zostały sklasyfikowane; silnik polityk ewaluuje dostęp wobec poświadczenia użytkownika w ramach każdej obowiązującej polityki.

Krok 7: Generowanie dowodów akredytacyjnych

Oceniający akredytację nie uwierzą platformie na słowo w żadnej z tych kwestii. Poproszą o dowody. Dowody są generowane jako efekt uboczny poprawnie zaprojektowanej maszynerii klasyfikacyjnej.

Dowody, które oceniający akredytację uznają za wiarygodne:

• Odniesienia w kodzie pokazujące, gdzie wdrożone są reguły propagacji klasyfikacji, ze śledzeniem od polityki do kodu.
• Próbki logu audytu demonstrujące logowanie per-decyzja w spektrum scenariuszy dostępu.
• Wyniki testów z zautomatyzowanego pakietu testów platformy obejmujące propagację klasyfikacji, filtrowanie releasability i weryfikację wiązania pod adversarialnym wejściem.
• Dowody wdrożenia operacyjnego — miesiące lub lata pracy produkcyjnej z udokumentowaną reakcją na incydenty, zapobieganiem wyciekowi klasyfikacji i zaliczonymi okresowymi przeglądami akredytacyjnymi.
• Logi transferów międzydomenowych pokazujące, że przemieszczanie między enklawami było uzasadnione, zatwierdzone i odnotowane.
• Raporty testów penetracyjnych z ćwiczeń red-team konkretnie celujących w maszynerię klasyfikacyjną.

Dyscyplina DevSecOps, która automatycznie generuje te dowody, omówiona jest w DevSecOps dla potoków obronnych. Wspierające ramy akredytacyjne (ISO 27001, AQAP-2110, NIST) omówione są w ISO 27001 w oprogramowaniu obronnym i NATO AQAP-2110 dla dostawców oprogramowania.

Co dalej

Część 3 wdrożyła maszynerię klasyfikacyjną. Etykiety STANAG 4774 jako dane strukturalne, wiązanie STANAG 4778 weryfikowane na każdej granicy, propagacja przez fuzję i wyprowadzanie, silnik polityk egzekwujący releasability w czasie zapytania, uwzględnione przepływy między enklawami, wspierane wielokoalicyjne releasability, wbudowane generowanie dowodów.

Część 4 zamyka serię dyscyplinami walidacyjnymi i akwizycyjnymi: testy konformancji, przygotowanie do CWIX, ścieżka akredytacyjna i długoogonowa dyscyplina utrzymaniowa, która utrzymuje platformę wdrażalną przez wieloletnie cykle operacyjne.