Części 1 i 2 zbudowały jednoźródłowy pipeline fuzji. Części 3 i 4 zamykają lukę dzielącą go od operacyjnej rzeczywistości obronnej. Realna fuzja obronna przyjmuje wejścia z wielu dyscyplin wywiadowczych — SIGINT, IMINT, ELINT, OSINT, HUMINT, GEOINT, MASINT — z których każda ma własną semantykę, latencję, klasyfikację i releasability. Traktowanie ich jako wymiennych obserwacji to pojedyncza, najczęstsza porażka architektoniczna w programach fuzji obronnej. Część 3 opisuje inżynierię fuzji multi-INT oraz mechanikę klasyfikacji, której obronność wymaga w sposób unikalny.

Podstawa konceptualna znajduje się w Kompletnym przewodniku po fuzji danych obronnych; ramy współdzielenia danych koalicyjnych w Wyzwaniach współdzielenia danych koalicyjnych; fundamenty RBAC w Kontroli dostępu opartej na rolach w obronnych systemach C2.

Krok 1: Semantyka multi-INT nie jest wymienna

Każda dyscyplina wywiadowcza niesie inną semantykę. Kontakt SIGINT z samym namiarem mówi ci kierunek, ale nie odległość. Obserwacja IMINT daje precyzyjną pozycję w pojedynczym punkcie w czasie, ale bez kinematyki. Raport OSINT ma niepewną atrybucję, ale potencjalnie bogaty kontekst. Raport HUMINT ma wysoką latencję i wymagania ochrony źródła. Spłaszczenie tego do generycznego rekordu „obserwacji" gubi informację, której fuzja potrzebuje do wyprodukowania godnych zaufania śladów.

Pola odróżniające obserwacje multi-INT:

  • SIGINT — linia namiaru, częstotliwość, modulacja, typ emitera, czas przechwytu. Pozycja obliczana przez triangulację, jeśli wiele stacji raportuje tego samego emitera; w przeciwnym razie nieznana.
  • IMINT — precyzyjna pozycja z eksploatacji obrazów, tożsamość z wizualnej lub automatycznej klasyfikacji, czas zbiórki. Tempa rewizyt mierzone w godzinach.
  • ELINT — charakteryzacja emitera (parametry impulsu radarowego, sygnatura). Pokrywa się z SIGINT, ale koncentruje się na elektronicznym porządku bojowym.
  • OSINT — wydobywany ze źródeł publicznych, z niepewnością atrybucji, pewnością źródła, łańcuchem cytowań. Coraz ważniejszy; omówiony w Monitorowaniu zagrożeń OSINT dla obronności.
  • HUMINT — wywiad osobowy, wysoka latencja, wrażliwość klasyfikacji i ochrony źródła. Nie może być propagowany do partnerów koalicyjnych bez procedury releasability scrubbing.
  • GEOINT — łączy obrazowanie z analizą terenu, predykcją tras, wnioskowaniem o wzorcach aktywności.
  • MASINT — wywiad pomiarowo-sygnaturowy; obejmuje sensorykę akustyczną, podczerwoną, nuklearną i inne wyspecjalizowane. Często domenowo-specyficzny (zwalczanie okrętów podwodnych, obrona przeciwrakietowa).

Kanoniczny schemat śladu obsługuje to, niosąc metadane dyscypliny źródłowej obok standardowych pól. Silnik fuzji odwołuje się do dyscypliny przy wyliczaniu prawdopodobieństw asocjacji (obserwacja SIGINT z samym namiarem nie może bezpośrednio aktualizować śladu kinematycznego bez logiki dopasowania namiaru; punktowa fiksacja IMINT powinna aktualizować pozycję, ale nie prędkość).

Krok 2: Architektura fuzji multi-INT

Wzorzec architektoniczny dla fuzji multi-INT, który sprawdza się w produkcji:

Adaptery na dyscyplinę. Każda dyscyplina wywiadowcza ma własną rodzinę adapterów z logiką specyficzną dla dyscypliny. Zadaniem adaptera jest produkcja obserwacji w schemacie kanonicznym, otagowanych dyscypliną źródłową, a nie interpretacja między dyscyplinami.

Korelacja świadoma dyscypliny. Logika korelacji silnika fuzji odwołuje się do metadanych dyscypliny źródłowej. Bramkowanie oparte na regułach obejmuje reguły kompatybilności dyscyplin („raport HUMINT o jednostce pływającej może aktualizować ślad jednostki potwierdzony IMINT tylko wtedy, gdy tożsamość pasuje z wysoką pewnością"). Asocjacja probabilistyczna używa priorów specyficznych dla dyscypliny.

Fuzja wzbogaca, nie zastępuje. Gdy obserwacje multi-INT zgadzają się, wzmacniają pewność. Gdy nie zgadzają się, silnik fuzji eksponuje rozbieżność operatorowi, zamiast wybierać jedną. Ślad z dwoma pewnymi-lecz-sprzecznymi raportami tożsamości nie jest „błędny" — jest genuinely dwuznaczny, a operator musi o tym wiedzieć.

Analityka cross-dyscyplinarna jako osobne usługi. Analityka wyższego rzędu obejmująca dyscypliny — wykrywanie wzorców aktywności (Analiza wzorców aktywności), wykrywanie anomalii behawioralnych, analiza sieci — działa jako osobne usługi, które konsumują strumień zfuzowanych śladów. Produkują wzbogacone adnotacje na istniejących śladach, a nie nowe ślady konkurujące z silnikiem fuzji.

Krok 3: Etykietowanie klasyfikacji wg STANAG 4774/4778

Każdy obiekt danych, który platforma produkuje, niesie etykietę poufności. STANAG 4774 definiuje format etykietowania; STANAG 4778 definiuje wiązanie kryptograficzne, które uniemożliwia odłączenie etykiet od danych, które oznaczają. Razem stanowią fundament wszelkiego współdzielenia danych koalicyjnych w kontekstach NATO.

Inżynierska integracja:

Klasyfikacja źródła jest niesiona przez każdy adapter. Każdy adapter zna klasyfikację swojego źródła (skonfigurowaną w katalogu źródeł z Części 1) i taguje nią każdą obserwację. Adapter jest źródłem prawdy dla klasyfikacji swoich obserwacji.

Etykiety są strukturalne, nie tekstowe. Etykieta klasyfikacji nie jest ciągiem „SECRET"; jest strukturalnym obiektem z poziomem klasyfikacji, kompartmentami, tagami releasability i podpisem wiążącym. Biblioteka etykiet implementuje serializację STANAG 4774 i wiązanie STANAG 4778; każda obserwacja przez nią przechodzi.

Etykiety są propagowane, nie regenerowane. Gdy silnik fuzji aktualizuje ślad, efektywna klasyfikacja śladu jest obliczana z zestawu źródeł, a nie przypisywana niezależnie. Ślad pochodzący ze zwrotu radarowego SECRET i wiadomości AIS UNCLASSIFIED jest SECRET. Dyscyplina propagacji jest mechaniczna; pomylenie jej jest porażką akredytacji.

Wiązanie przetrwa serializację. Gdy ślady są serializowane na dysk, na szynę wiadomości lub przez sieć, wiązanie STANAG 4778 pozostaje dołączone. Zdejmowanie wiązania „dla wygody" to typ skrótu, którego recenzenci akredytacyjni szukają w sposób ukierunkowany.

Krok 4: Propagacja klasyfikacji przez fuzję

Silnik fuzji tworzy dane pochodne. Ślad jest derywatem z wielu obserwacji źródłowych; jego klasyfikacja musi być obliczona z ich. Reguły propagacji:

Poziom klasyfikacji to maksimum w zestawie źródeł. Ślad pochodzący ze źródeł SECRET i UNCLASSIFIED jest SECRET. Reguła high-water-mark jest bezlitosna, ale dobrze rozumiana.

Kompartmenty są sumą w zestawie źródeł. Ślad pochodzący ze źródła w kompartmencie HIGH-VALUE-TARGET i źródła w kompartmencie HUMAN-INTELLIGENCE niesie oba kompartmenty. Dostęp wymaga uprawnień w obu.

Releasability to przecięcie w zestawie źródeł. Ślad pochodzący ze źródeł tylko-FVEY i tylko-NATO jest dopuszczony do udostępnienia tylko przecięciu (FVEY-i-NATO, co w praktyce oznacza cztery państwa FVEY, które są również członkami NATO). Reguła przecięcia jest najbardziej operacyjnie konsekwentna i tą najczęściej źle implementowaną w ad-hoc wdrożeniach.

Klasyfikacja per-atrybut tam, gdzie to istotne. Pozycja śladu może być dopuszczona do udostępnienia szeroko, podczas gdy jego tożsamość jest bardziej ograniczona. Schemat wspiera klasyfikację per-atrybut; silnik polityki ewaluuje dostęp per-atrybut w czasie zapytania.

Kluczowy wniosek: Propagacji klasyfikacji nie da się dorobić retrospektywnie. Platforma fuzji, która zignorowała klasyfikację w początkowym developmencie i próbowała ją dodać później, zafundowała sobie wieloletnie refaktoryzacje i dostarczyła z opóźnieniem. Buduj mechanikę propagacji równolegle z silnikiem fuzji od pierwszego sprintu; akta operacyjne i tak jej zażądają, a wcześniej jest dramatycznie taniej niż później.

Krok 5: Silnik polityki releasability

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

Wzorzec inżynierski:

Polityka jako kod. Reguły releasability wyrażone w wersjonowanym języku polityki — Rego z Open Policy Agent jest defensywnym wyborem domyślnym. Zmiany polityki przechodzą przez code review, nie zmiany konfiguracji. Historia decyzji polityki jest audytowalna z systemu kontroli wersji.

Ewaluacja decyzji na granicy zapytania. Gdy konsument odpytuje magazyn śladów, silnik polityki ewaluuje, które ślady są widoczne i które atrybuty są widoczne per-ślad. Wynikiem jest przefiltrowany widok, a nie pełne dane z maską w UI. Filtrowanie tylko w UI jest naruszeniem Common Criteria i akredytacyjnym deal-breakerem.

Log audytu per-decyzja. Każda decyzja dostępu — jaki użytkownik, jakie dane, jaka klasyfikacja, jaki rezultat — jest logowana niemutowalnie. Log audytu jest bazą dowodową dla przeglądu akredytacyjnego i operacyjnej analizy kryminalistycznej.

Budżety wydajności. Silnik polityki siedzi na ścieżce krytycznej COP; jego latencja ewaluacji musi być sub-milisekundowa per-decyzja. Strategie cache'owania, prekompilowane paczki polityki i odciski palców polityki per-użytkownik — wszystko ma znaczenie. Naiwny silnik polityki jest najczęstszą przyczyną spowolnień COP w klasyfikowanych wdrożeniach.

Szczegółowe potraktowanie wzorca silnika polityki, implikacji współdzielenia danych koalicyjnych i operacyjnych antywzorców, których trzeba unikać, znajduje się w Wyzwaniach współdzielenia danych koalicyjnych.

Krok 6: Przepływy danych między enklawami

Sieci obronne nie są pojedynczymi enklawami. Platforma operująca w sieciach NATO RESTRICTED, NATO SECRET i krajowo-klasyfikowanych musi przenosić odpowiednie dane między nimi, jednocześnie zapobiegając nieodpowiednim przepływom danych. Wzorzec architektoniczny:

Instancje fuzji per-enklawa. Każda klasyfikowana enklawa uruchamia własną instancję fuzji z własnym zestawem źródeł, magazynem śladów i silnikiem polityki. Instancje są fizycznie oddzielone; platforma nie zakłada, że dzielą stan.

Mosty cross-domain. Tam, gdzie dane legalnie przemieszczają się między enklawami — na przykład niesklasyfikowany kanał AIS płynący w górę do enklawy SECRET lub produkt po releasability scrubbingu płynący w dół do enklawy koalicyjnej — ruch przechodzi przez akredytowany most cross-domain, a nie bezpośrednie połączenie. Most egzekwuje reguły klasyfikacji na granicy.

Diody jednokierunkowe tam, gdzie fizyka wymusza kierunek. Dla ruchu danych z high-side na low-side (który jest rzadki i operacyjnie wrażliwy) jednokierunkowe diody danych wymuszają kierunek na warstwie sieciowej. Platforma fuzji integruje się z infrastrukturą diod, a nie implementuje własnej.

Manualne udostępnienie tam, gdzie automatyzacja zawodzi. Niektóre decyzje klasyfikacyjne nie mogą być bezpiecznie zautomatyzowane. Decyzje o wydaniu per-produkt dla HUMINT lub danych skompartmentalizowanych mogą wymagać akceptacji człowieka. Platforma musi obsłużyć workflow — wyeksponować kandydata do wydania, uchwycić decyzję człowieka, propagować zatwierdzone wydanie.

Krok 7: Rozważania operacyjne

Fuzja multi-INT w eksploatacji ujawnia wyzwania niewidoczne w developmencie. Dyscypliny, które odróżniają platformy operacyjne od demonstracyjnych:

Atrybucja źródła przetrwa propagację. Gdy ślad jest odpytywany, odpowiedź zawiera zestaw źródeł, który się na niego złożył. Operatorzy muszą wiedzieć, czy pozycja pochodzi z radaru (wysoka pewność kinematyczna, niepewna tożsamość), czy z HUMINT (niska precyzja przestrzenna, bogaty kontekst tożsamości). Atrybucja źródła czyni to przejrzystym.

Rozbieżność jest zachowana, nie spłaszczona. Gdy dwie dyscypliny źródłowe nie zgadzają się co do tożsamości śladu, silnik fuzji zachowuje obie alternatywy z pewnościami. Operator decyduje; platforma eksponuje.

Fan-out kompartmentów jest ograniczony. Ślad z wieloma kompartmentami ma wiele odrębnych potencjalnych odbiorców. System musi efektywnie obliczać releasability nawet gdy zbiór kompartmentów jest duży.

Audyt obejmuje każdą decyzję o udostępnieniu. Każdy transfer cross-domain, każdy rezultat filtra per-zapytanie, każda eskalacja kompartmentu jest logowana. Log audytu wspiera operacyjny przegląd kryminalistyczny, dowody akredytacyjne i analizę po działaniu. Szczegółowy wzorzec znajduje się w Event Sourcing dla śladów audytu obronnego.

Obserwacje cyber jako multi-INT

Coraz częściej obserwacje cyber wpływają do tego samego pipeline'u fuzji co obserwacje z domeny fizycznej. Potwierdzone włamanie sieciowe, wyciekły zestaw poświadczeń, lead atrybucyjny wywiedziony z OSINT — każdy może stać się obserwacją w strumieniu fuzji multi-INT. Dopasowanie architektoniczne jest realne, ale wymaga ostrożności: dane cyber mają inną latencję, pewność i semantykę klasyfikacji niż dane z domeny fizycznej. Wzorzec jest omówiony w Platformach CTI dla obronności, a szersze ujęcie cyber-jako-dyscypliny-fuzji w Kompletnym przewodniku po cyberbezpieczeństwie obronnym.

Decyzja inżynierska: zbuduj adaptery specyficzne dla cyber, które produkują obserwacje w schemacie kanonicznym, otagowane dyscypliną „cyber", zachowując jednocześnie metadane specyficzne dla cyber (wskaźniki kompromitacji, atrybucja aktora zagrożeń, faza kill-chain). Silnik fuzji traktuje obserwacje cyber jak inne wejścia multi-INT; tooling specyficzny dla cyber (platformy CTI, SIEM/SOAR) konsumuje ten sam strumień śladów dla własnych celów.

Co dalej

Część 3 objęła mechanikę multi-INT i klasyfikacji. Platforma teraz koreluje obserwacje między dyscyplinami wywiadowczymi, zachowując ich różnice semantyczne, propaguje klasyfikację przez fuzję poprawnie, egzekwuje releasability poprzez silnik polityki i operuje przez granice klasyfikowanych enklaw.

Część 4 zamyka serię operacjonalizacją: monitoringiem driftu w algorytmach fuzji, pipeline'em audytu wspierającym akredytację, wzorcami wdrożenia produkcyjnego (cloud-to-air-gapped) i długoogonową dyscypliną utrzymania, która utrzymuje platformę operacyjnie sprawną przez 20-letni cykl życia.