Budowa obronnego stacku cyberbezpieczeństwa, część 3: obrona ICS/OT, kryminalistyka cyfrowa i rozwiązania cross-domain

Części 1 i 2 zbudowały stack cyber po stronie IT. Część 3 obejmuje dyscypliny, których oprogramowanie klasy IT nie obsługuje: obronę przemysłowych systemów sterowania i technologii operacyjnej, gotowość kryminalistyki cyfrowej do analizy powłamaniowej oraz rozwiązania cross-domain, które przenoszą odpowiednie dane między enklawami niejawnymi. Każda z nich jest wyspecjalizowana, każda jest istotna dla zamówień publicznych i każda jest obszarem, w którym inżynierowie wyszkoleni w IT najczęściej popełniają błędy. Część 3 prowadzi przez nie krok po kroku.

Ramy filarowe znajdują się w artykule Kompletny przewodnik po cyberbezpieczeństwie dla obronności. Maszyneria klauzulowania po stronie fuzji, z którą łączy się ta część, jest w Budowa obronnego potoku fuzji, część 3; dyscyplina releasability w koalicji NATO jest w Wdrożenie interoperacyjności NATO, część 3.

Krok 1: Dlaczego obrona ICS/OT różni się od IT

Pierwszy błąd, jaki popełniają inżynierowie wyszkoleni w IT przy ICS/OT, to bezpośrednie zastosowanie wzorców obronnych z IT. Wzorce się przenoszą; wartości — nie. Obronę ICS/OT kształtują różnice strukturalne, które sprawiają, że dyscyplina IT jest niewystarczająca, a niekiedy aktywnie szkodliwa.

Różnice strukturalne:

• Inne protokoły. Modbus, DNP3, IEC 61850, OPC UA, BACnet — żaden z nich nie występuje w środowiskach IT. Narzędzia dekodujące protokoły IT (HTTP, TLS, SMB, DNS) nie dekodują tych. Wymagane są narzędzia specyficzne dla ICS.
• Inne cykle łatek. Sterownik ICS może przejść lata między aktualizacjami — czasem nigdy. Okna serwisowe planowane są wokół rytmów operacyjnych, nie kalendarzy bezpieczeństwa. „Po prostu załataj" rzadko jest opcją.
• Inne konsekwencje. Awaria IT kosztuje dostępność. Awaria ICS może mieć konsekwencje kinetyczne — odłączone zasilanie, zaburzony przepływ wody, wyłączony system uzbrojenia, przerwana logistyka. Promień rażenia kształtuje rachunek ryzyka.
• Inny krajobraz dostawców. Honeywell, Siemens, Schneider Electric, Rockwell, Yokogawa — każdy z własnymi konwencjami inżynierskimi, autorskimi protokołami i kontraktami wsparcia. Relacje z dostawcami IT się nie przenoszą.
• Inna kultura operatorów. Operatorzy ICS mają wykształcenie inżynierskie, nie z zakresu bezpieczeństwa IT. Rozmowa o bezpieczeństwie musi być techniczno-inżynierska, a nie security-engineering. Słownictwo jest inne.
• Inne polityki skanowania. Skanowanie podatności, które dla SOC po stronie IT jest rutyną, może wyłączyć leciwy PLC. Aktywne skanowanie jest domyślne w IT; w ICS jest złym domyślnym.

Szczegółowe ujęcie inżynierskie wzorców wykrywania włamań ICS/OT specyficznych dla sieci wojskowych jest w artykule Wykrywanie włamań ICS/OT w sieciach wojskowych.

Krok 2: Monitoring pasywny jako domyślny

Działający wzorzec obrony ICS/OT: monitoring pasywny domyślnie, reakcja aktywna tylko przy intensywnej koordynacji z operatorem.

Architektura monitoringu pasywnego:

Zbieranie z network tap lub portu SPAN. Sensor wykrywający widzi cały ruch sieciowy ICS, ale nigdy nie wstrzykuje pakietów. Sensor nie może wpłynąć na sterowany proces.

Głęboka inspekcja pakietów świadoma protokołów. Sensor dekoduje Modbus, DNP3, IEC 61850, OPC UA, identyfikuje wykonywane operacje i wykrywa anomalie (nieoczekiwane polecenia, zniekształcone pakiety, nietypowe pary źródło-cel).

Wykrywanie aktywów z pasywnej obserwacji. Sensor identyfikuje aktywa ICS na podstawie ich zachowania w sieci — dostawca, model, wersja firmware, rola — bez aktywnego sondowania. Inwentarz aktywów z Części 1 jest wzbogacany o te odkrycia.

Behawioralne ustalanie baseline. Przez tygodnie obserwacji sensor buduje baseline normalnego zachowania ICS. Odchylenia (polecenia o nieoczekiwanej porze, sekwencje spoza baseline, ruch do aktywów, które nie powinny się komunikować) stają się alertami.

Reakcja kierowana przez operatora. Gdy sensor wykryje anomalię, odpowiedzią jest powiadomienie zespołu operacyjnego, a nie podjęcie zautomatyzowanej akcji. Operatorzy ICS mają kontekst, by ocenić, czy anomalia jest złośliwa, czy operacyjna.

Produkty dostawców realizujące ten wzorzec: Dragos Platform, Claroty xDome, Nozomi Vantage, Tenable OT Security. Każdy ma własne mocne strony w dekodowaniu protokołów; zamówienia obronne oceniają je pod kątem konkretnego środowiska OT.

Krok 3: Wywiad o zagrożeniach specyficzny dla ICS/OT

Wywiad o zagrożeniach ICS/OT to osobna dyscyplina. Ogólne kanały CTI dla IT (omówione w Części 1) pomijają TTP specyficzne dla ICS: techniki z rodziny Stuxnet, warianty Industroyer, TRITON, PIPEDREAM. Dedykowane źródła CTI dla ICS:

Dragos WorldView. Wiodący w branży wywiad o zagrożeniach ICS. Obejmuje państwowych aktorów ICS (ELECTRUM, XENOTIME, ALLANITE i innych) wraz z TTP i treścią detekcji.

Doradcze CISA ICS-CERT. Publiczne doradcze ICS z amerykańskiej Cybersecurity and Infrastructure Security Agency. Darmowe, dobrze opracowane.

CSIRT-y NATO i krajowe. Doradcze istotne dla ICS z NCIRC, BSI, ANSSI i odpowiedników — szczególnie w okresach podwyższonego zagrożenia.

Doradcze bezpieczeństwa dostawców. Każdy dostawca ICS publikuje własne. Subskrybować; zintegrować z potokiem CTI; śledzić zobowiązania łatkowe.

CTI dla ICS trafia do warstwy detekcji specyficznej dla OT oddzielnie od CTI dla IT. Mieszanie ich rozcieńcza sygnał — większość CTI dla IT jest nieistotna dla OT, a środowiska OT nie są w stanie wchłonąć wolumenu IT.

Krok 4: Gotowość kryminalistyki cyfrowej

Detekcja bez analizy powłamaniowej to połowa zdolności. Programy cyberbezpieczeństwa obronnego potrzebują gotowości kryminalistyki cyfrowej — inwestycji inżynierskich, które umożliwiają rekonstrukcję tego, co się wydarzyło po kompromitacji.

Komponenty gotowości kryminalistycznej:

Agregacja logów z długą retencją. Kampanie podmiotów państwowych trwają miesiącami. SOC z retencją 30 dni nie jest w stanie zrekonstruować 18-miesięcznej kampanii. Budżet retencji wspiera ramy czasowe dochodzenia; storage warstwowy zarządza kosztem. Architektura potoku z Części 2 musi to uwzględniać.

Głębokie przechwytywanie pakietów tam, gdzie uzasadnia to threat-warrant. Selektywne pełne przechwytywanie pakietów dla segmentów wysokiego ryzyka. Wymagania storage są znaczące; wartość jest niezastąpiona, gdy kompromitacja wymaga rekonstrukcji na poziomie sieci.

Telemetria endpointów o wystarczającej głębokości. Sysmon, agent EDR dostawcy, audyt linii poleceń, przechwytywanie drzewa procesów. Telemetria powierzchniowa jest niewystarczająca dla dochodzenia w sprawie podmiotu państwowego; głębokość ma znaczenie.

Łańcuch dowodowy od momentu zbierania. Dowody kryminalistyczne muszą wspierać przegląd prawny i akredytacyjny. Procedury zbierania, weryfikacja hashy przy każdym transferze, dokumentacja łańcucha dowodowego. Dowody zebrane bez łańcucha dowodowego są operacyjnie ciekawe, ale prawnie bezużyteczne.

Środowisko analizy kryminalistycznej. Izolowana sieć analityczna, zweryfikowane narzędzia (Volatility, Autopsy, pakiet SANS DFIR), wyszkoleni analitycy. Środowisko jest przygotowywane z wyprzedzeniem, nie stawiane podczas incydentu.

Odtwarzalne potoki analityczne. Powtarzalne analizy (kryminalistyka pamięci, sandbox dla malware, ekstrakcja wskaźników) są skryptowane i kontrolowane wersją. Analizy ręczne nie skalują się i nie przetrwają rotacji analityków.

Szczegółowe ujęcie kryminalistyki cyber w obronności znajduje się w artykule Kryminalistyka cyfrowa dla cyber w obronności.

Krok 5: Rozwiązania cross-domain

Sieci obronne nie są pojedynczymi enklawami. Dane legalnie przemieszczają się między poziomami klauzul — kanał wywiadu o zagrożeniach jawny do SOC SECRET, podsumowanie incydentu po scrubbingu releasability w dół do partnera koalicyjnego, OSINT zebrany w sieci low-side trafiający do analityków high-side. Te przepływy odbywają się przez rozwiązania cross-domain (CDS).

Krajobraz CDS:

Diody danych jednokierunkowe. Połączenia jednokierunkowe egzekwowane sprzętowo. Dane płyną wyłącznie w zatwierdzonym kierunku (typowo high-to-low dla produktów do udostępnienia, low-to-high dla pozyskiwania informacji publicznych). Owl Cyber Defense, Forcepoint, Garrison to typowi dostawcy.

Strażnicy transferu cross-domain. Rozwiązania sprzętowo-programowe, które inspekcjonują, sanityzują i przekazują dane między poziomami klauzul. Bardziej elastyczne niż diody (możliwa dwukierunkowość), ale z większym obciążeniem akredytacyjnym.

Przepływy przeglądu ręcznego. Tam, gdzie automat nie może bezpiecznie zdecydować, recenzenci-ludzie zatwierdzają konkretne przemieszczenia danych. Platforma wyświetla kandydata, rejestruje decyzję człowieka z atrybucją i propaguje zatwierdzony transfer z audytem.

Integracja inżynierska:

• Stack cyber integruje się z infrastrukturą CDS, nigdy jej nie zastępuje. CDS są dostarczane przez akredytowanych dostawców z aprobatą organu bezpieczeństwa narodowego; budowanie własnego in-house rzadko jest uzasadnione.
• Logowanie audytowe per transfer. Każdy transfer cross-domain jest logowany z atrybucją, uzasadnieniem i referencją treści. Log audytowy jest dowodem akredytacyjnym.
• Weryfikacja klauzulowania na granicy. Dane wchodzące do CDS są weryfikowane pod kątem odpowiednich etykiet (STANAG 4774 zgodnie z Częścią 3 serii interop NATO); dane wychodzące są re-weryfikowane.
• Oczekiwania co do pasma i latencji. CDS dodaje latencję. Przepływy operacyjne dostosowują się do latencji, zamiast z nią walczyć.

Krok 6: Segmentacja sieci między IT a OT

Model Purdue jest kanonicznym odniesieniem dla segmentacji sieci IT-OT. Środowiska obronne często rozszerzają go o segmentację świadomą klauzulowania. Działający wzorzec:

Poziom 0-1 (Proces i sensoryka). Faktyczna kontrola fizyczna — PLC, RTU, sensory, aktuatory. Izolowane od IT. Brak bezpośredniej łączności po stronie IT.

Poziom 2 (Nadzór i sterowanie). Lokalne HMI i stacje robocze inżynierskie. Połączone z Poziomem 0-1; minimalnie połączone w górę.

Poziom 3 (Operacje obiektu). Bazy danych operacji, zarządzanie partiami, serwery sterowania. Tam, gdzie żyją systemy poziomu ICS.

Poziom 3.5 (DMZ). Punkt przejścia między OT a IT. Cała komunikacja IT-OT przechodzi tędy, z jawnymi politykami przepływu danych i detekcją.

Poziom 4-5 (IT korporacyjne). Standardowe środowisko IT. Tam głównie działa SIEM/SOAR z Części 2.

Rozszerzenia obronne dodają segmentację na poziomie klauzul ortogonalną do poziomów Purdue: jawna sieć OT dla infrastruktury obiektowej, sieć OT NATO-RESTRICTED dla infrastruktury ćwiczeń koalicyjnych, krajowa sieć OT klauzulowana dla OT platform uzbrojenia. Każda jest własnym segmentowanym środowiskiem z własnymi rozwiązaniami cross-domain tam, gdzie dane muszą płynąć.

Krok 7: Koordynacja reakcji na incydenty ICS/OT

Gdy dochodzi do incydentu ICS, reakcja jest wielostronna. Reakcja na incydenty po stronie IT obsługuje komponenty IT; operatorzy OT obsługują komponenty operacyjne; inżynierowie bezpieczeństwa zajmują się ryzykiem procesu fizycznego; prawnicy obsługują raportowanie regulacyjne (które w niektórych jurysdykcjach ma konkretne terminy dla ICS); kierownictwo koordynuje komunikację publiczną.

Inwestycje inżynierskie wspierające tę koordynację:

Wcześniej ustalone playbooki. Specyficzne dla ICS playbooki incydentowe, okresowo ćwiczone, nazywające role i ścieżki komunikacji. Playbook jest w repozytorium, kontrolowany wersją, przeglądany raz w roku.

Ćwiczenia tabletop. Roczne lub półroczne ćwiczenia przechodzące przez scenariusze incydentów ICS. Ujawniają luki w playbookach, ścieżkach komunikacji, zdolnościach technicznych. Szczegółowa dyscyplina testowania C2, która wpływa na tę praktykę, jest w artykule Testowanie systemów C2 krytycznych dla misji.

Szkolenia międzyzespołowe. Analitycy SOC IT, którzy nigdy nie widzą środowisk OT, nie mogą skutecznie reagować na incydenty OT. Szkolenia krzyżowe, zaznajamianie ze środowiskiem OT, wspólne ćwiczenia.

Ścieżki eskalacji do dostawców. Wcześniej ustanowione relacje wsparcia z dostawcami ICS. Czas incydentu to nie jest moment na odkrywanie, że relacja wsparcia jest tylko kontraktowa.

Co dalej

Część 3 omówiła wyspecjalizowane warstwy. Obrona ICS/OT z monitoringiem pasywnym jako domyślnym, dedykowany wywiad o zagrożeniach OT, gotowość kryminalistyki cyfrowej z długą retencją i łańcuchem dowodowym, rozwiązania cross-domain dla przepływów między enklawami, segmentacja sieci według modelu Purdue, koordynacja reakcji na incydenty ICS.

Część 4 zamyka serię dyscyplinami potoku inżynierskiego i architektonicznymi: DevSecOps generujący dowody akredytacyjne jako efekt uboczny, zero-trust w sieciach wojskowych, SBOM i integralność łańcucha dostaw, dostosowanie do ISO 27001 i AQAP-2110 oraz postawa ciągłej zgodności, która utrzymuje stack cyber akredytowany przez 15-20 lat cyklu operacyjnego.