Sieci technologii operacyjnej (OT) w systemach obronnych — płaszczyzny kontroli za radarami, instalacjami napędowymi, stanowiskami testowymi systemów uzbrojenia, obsługą magazynów, antenami stacji naziemnych — zawodzą inaczej niż IT korporacyjne. Zdarzenie ransomware na korporacyjnym fileshare jest odzyskiwalne; zdezorientowany programowalny sterownik logiczny w instalacji napędowej podczas spornego przejścia — nie. Pierwsze pytanie inżynierskie nie brzmi więc "jak patchować szybciej", ale "jak sieć jest pokrojona i co przekracza każdą granicę". To pytanie o segmentację, i przez pięćdziesiąt lat kanoniczną odpowiedzią była Purdue Enterprise Reference Architecture, nałożona na język stref i conduitów IEC 62443. Artykuł przechodzi przez model od końca do końca, a następnie nakłada kwestie specyficzne dla obronności: klauzulę, transfer międzydomenowy, monitorowanie rzekomo air-gapped stosu i papierologię akredytacyjną, którą architektura musi ostatecznie spełnić.
1. Dlaczego Purdue wciąż ma znaczenie
Purdue pierwotnie napisano dla kontroli procesów chemicznych i produkcyjnych, ale jego podstawowy wgląd — że sieć można rozłożyć na warstwy ze ściśle określonymi relacjami zaufania między nimi — przeżył każdą generację sprzętu, do której był stosowany. "Płaska OT" — sieć, gdzie stacje inżynierskie, historiany, HMI i sterowniki polowe dzielą niefiltrowaną domenę rozgłoszeniową Layer 2 — nie da się obronić. Nie ma obserwowalnej granicy, w której analityk może powiedzieć "ruch przekraczający ten punkt powinien być Modbus, nic więcej"; każdy host ufa każdemu innemu hostowi domyślnie; pojedynczy skompromitowany laptop dosięga każdego PLC przez ARP.
IEC 62443 chwyta tę samą intuicję innym słownictwem: strefa to zgrupowanie aktywów dzielących wspólne wymagania bezpieczeństwa, a conduit to kontrolowana ścieżka między strefami. Conduity, nie hosty, to miejsce, gdzie wymuszane są kontrole bezpieczeństwa. Poziomy Purdue są w istocie domyślnym szablonem stref — punktem startowym, który programy obronne adaptują, a nie wynajdują od nowa. W reszcie artykułu używamy numerów poziomów Purdue i terminów stref/conduitów IEC 62443 zamiennie; w praktyce obronnego cyberbezpieczeństwa opisują ten sam artefakt.
2. Sześć poziomów Purdue
Poziom 5 — Enterprise. IT korporacyjne: email, ERP, intranet, dostęp wykonawców. Na placówce obronnej to jawny LAN biznesowy, w którym żyją audytorzy, kadry i menedżerowie programów. Nigdy nie może bezpośrednio dotykać sprzętu procesowego.
Poziom 4 — Planowanie biznesowe i logistyka placówki. Zarządzanie konserwacją, inwentarz części, systemy zleceń. Dla morskiego systemu walki to ogon logistyczny po stronie brzegu; dla baterii obrony powietrznej — system wsparcia poziomu depot. Wciąż IT-podobny, wciąż patchowany w kadencji IT.
Poziom 3.5 — Przemysłowy DMZ. Pojedyncza najważniejsza strefa modelu. Każdy przepływ między IT korporacyjnym a operacjami przechodzi przez nią, terminowany i ponownie inicjowany przez usługi brokerujące: repliki historianów, jump hosty, staging patchów, mirrory aktualizacji antymalware. Żaden natywny protokół nie przekracza DMZ; nic na Poziomie 3 nie ustanawia sesji z czymkolwiek na Poziomie 4 czy wyżej poza przez proxy DMZ.
Poziom 3 — Operacje placówki. Systemy obejmujące całą produkcję: operacyjny historian, serwery zarządzania batchami, aplikacje inżynierskie obejmujące cały zakład, kontrolery domeny OT, serwery patchy OT. Na stanowisku testowym systemu uzbrojenia to sala kontroli poligonu — miejsce, gdzie konduktorzy testów orkiestrują przebiegi przez wiele cel.
Poziom 2 — Kontrola nadzorcza. HMI, lokalne stacje inżynierskie, serwery alarmów, SCADA w polu widzenia. Dla instalacji napędowej to konsola sterowania maszynowni; dla radaru — serwer wyświetlacza taktycznego operatora. Ludzie sterują procesem z Poziomu 2.
Poziom 1 — Kontrola podstawowa. PLC, RTU, systemy bezpieczeństwa zaprogramowane, dedykowane sterowniki. Logika utrzymująca ciśnienie pary, obracająca antenę, sekwencjonująca wyrzutnię lub wyłączająca reaktor. Czasu rzeczywistego, deterministyczna, często niezdolna tolerować nawet milisekundy jittera wprowadzonego przez źle skonfigurowany firewall.
Poziom 0 — Proces. Czujniki i siłowniki, zawory, silniki, przetworniki, fizyka systemu. Coraz bardziej cyfrowe (HART, IO-Link, Profibus-PA, FOUNDATION Fieldbus) i dlatego coraz bardziej część zakresu cyberbezpieczeństwa.
Kluczową właściwością jest, że im głębiej idziesz, tym bardziej deterministyczny, mniej patchowany i mniej zdolny do obrony jest sprzęt. Sterownik Poziomu 1 zbudowany w 2009 nie ma uwierzytelniania na swoim protokole inżynierskim. Cały sens segmentacji to kompensowanie tego kontrolami granicznymi.
3. Nakładka klauzuli na strefy Purdue
Obronność dodaje drugą oś, której Purdue nie przewidział: klauzulę. Widok logistyczny zaległości konserwacyjnej w klauzuli NATO RESTRICTED i widok taktyczny SECRET tej samej platformy mogą żyć na tym samym poziomie Purdue, ale nie mogą dzielić domeny rozgłoszeniowej. Wynik to macierz: poziom Purdue na jednej osi, klauzula na drugiej.
W praktyce macierz redukuje się do małej liczby akredytowanych kombinacji. Poziom 5 enterprise to zwykle UNCLASSIFIED lub NATO RESTRICTED. Przemysłowy DMZ może istnieć w wielu klauzulach, jeden na enklawę. Poziomy 3 do 0 — faktyczna kontrola procesu — są zwykle przypięte do najwyższej klauzuli danych, które obsługują, na zasadzie, że sterownik nie może odebrać klauzuli swojemu własnemu stanowi. Sterownik Poziomu 1 radaru obsługujący niejawną falę siedzi w enklawie SECRET, mimo że sam sterownik jest komercyjnym PLC.
Architektonicznie uczciwy ruch to narysować macierz wcześnie, oznaczyć każdą komórkę jej właścicielem akredytacji i dopuszczalnymi conduitami, i odmówić wdrożenia czegokolwiek, co nie pasuje do oznaczonej komórki. To także miejsce, gdzie zasady zero-trust spotykają klasyczną obronę w głąb: polityka świadoma tożsamości wewnątrz strefy, separacja wymuszana sprzętowo między klauzulami.
4. Cross-Domain Solutions w OT
Gdy macierz istnieje, pytanie staje się, jak dane przemieszczają się między komórkami. Dwie kategorie cross-domain solutions dominują we wdrożeniach OT.
Jednokierunkowe diody danych. Urządzenia sprzętowe (Owl, Waterfall, Fox-IT FoxDataDiode, Advenica), które fizycznie pozwalają na ruch tylko w jednym kierunku — zwykle nadajnik światłowodowy po jednej stronie i odbiornik po drugiej, bez możliwości ścieżki zwrotnej na warstwie fizycznej. Klasyczne zastosowanie OT to eksport danych historiana z Poziomu 3 do repliki Poziomu 4 lub enterprise bez wystawiania strony OT na żaden ruch zwrotny. Diody są właściwą odpowiedzią, gdy przepływ danych jest monotoniczny: telemetria na zewnątrz, nic do środka. Są złą odpowiedzią dla czegokolwiek, co wymaga potwierdzeń, patchy do środka lub zdalnego wsparcia producenta.
Transfer guards. Bramki świadome aplikacji (Forcepoint DDP, Fox-IT DataDiode w trybie guard, Everfox Trusted Gateway, Owl ReCon), które inspekcjonują i filtrują treść przekraczającą granicę klauzuli w obu kierunkach. Guard może uwolnić odkażone zlecenie konserwacji z SECRET do RESTRICTED po weryfikacji, że nie niesie niejawnych adnotacji, lub przeciągnąć zweryfikowaną aktualizację firmware PLC z niższej enklawy do wyższej. Guardy są wolniejsze, droższe i trudniejsze do akredytacji niż diody, ale są jedyną uczciwą odpowiedzią, gdy dwukierunkowy przepływ jest naprawdę wymagany.
Zasadą inżynierską jest zacząć od diody i eskalować do guarda tylko wtedy, gdy zastosowanie operacyjne udowodni, że dwukierunkowy przepływ jest nieuniknik.
5. Segmentacja wschód-zachód vs północ-południe
Purdue jest głównie modelem północ-południe: ruch porusza się w górę i w dół poziomów i jest filtrowany przy każdym conduit. Ale nowoczesne ataki są wschód-zachód — gdy przeciwnik jest na HMI Poziomu 2, następny ruch to bok do sąsiedniego HMI, nie w górę do historiana. Segmentacja wschód-zachód wewnątrz poziomu Purdue to zatem drugi front.
Mikro-segmentacja w OT jest trudniejsza niż w IT z trzech powodów. Po pierwsze, wiele legacy protokołów (Modbus/TCP, DNP3, IEC 60870-5-104, S7) nie niesie uwierzytelniania i zakłada płaską domenę L2. Po drugie, sterowniki nie mogą uruchamiać firewalli hostowych bez naruszenia swoich gwarancji czasu rzeczywistego i często gwarancji producenta. Po trzecie, deterministyczne budżety czasowe oznaczają, że źle skonfigurowany punkt wymuszania polityki może wyłączyć zakład szybciej, niż zrobiłby to napastnik.
Dwa praktyczne podejścia to projekty VLAN-plus-ACL na zarządzanych przełącznikach przemysłowych (Hirschmann, Cisco IE, Moxa) i nakładki SDN celowo zbudowane pod OT (TXOne, Claroty xDome Secure Access, Dragos z integracjami NAC). VLAN-y są znane i akredytowalne, ale gruboziarniste; SDN jest drobniej-ziarniste, ale wprowadza kontroler, którego własna dostępność staje się pojedynczym punktem awarii. Większość realnych programów kończy uruchamiając oba, z VLAN-ami jako podstawą i politykami SDN nakładanymi na wierzch dla komórek o wysokiej wartości.
6. Monitorowanie stosu air-gapped
Każdy program OT twierdzi, że jest air-gapped. Prawie żaden nie jest. Jest port USB na laptopie inżynierskim, laptop producenta przychodzący raz na kwartał, modem konserwacyjny zlikwidowany na papierze, ale wciąż z kartą SIM, instrument bezprzewodowy dodany podczas remontu. Architektura musi zakładać, że air gap przecieka, i odpowiednio instrumentować.
Platformy pasywnego monitoringu — Nozomi Networks Guardian, Claroty CTD/xDome, Dragos Platform, Tenable OT Security — siedzą na portach span wewnątrz każdej strefy i rekonstruują inwentarze aktywów, bazy protokołów i sygnały anomalii z pasywnie obserwowanego ruchu. Nigdy nie wstrzykują pakietów, co czyni je wdrażalnymi na produkcyjnym OT bez sprzeciwu producenta. W połączeniu z detekcją opartą na historianie (zapytania do historiana o niemożliwe zmiany setpointów, częstości komend powyżej zdolności człowieka, sekwencje naruszające blokady procesu) i EDR na stacji inżynierskiej tworzą obronny stos monitoringu nawet wtedy, gdy sieć jest nominalnie izolowana. To rodowód eksplorowany w naszym przewodniku forensyki ICS/OT.
Kluczowy wniosek: Traktuj każdą "air-gapped" enklawę OT jako sieć o odroczonej łączności — fizycznie izolowaną dzisiaj, statystycznie pewną zostania zmostkowaną w cyklu życia aktywa. Projektuj monitoring, tożsamość i przepływy aktualizacji pod przypadek zmostkowany, a następnie ciesz się air-gapem jako bonusem, póki trwa.
7. Tożsamość i dostęp w OT
Tożsamość w OT dominują trzy populacje: stacje inżynierskie używane przez personel placówki, sesje zdalnego dostępu producenta i konta break-glass trzymane na sytuacje kryzysowe. Każda wymaga własnej dyscypliny.
Stacje inżynierskie powinny uwierzytelniać się do katalogu po stronie OT — nigdy katalogu IT korporacyjnego — z poświadczeniami zakotwiczonymi sprzętowo i nagrywaniem sesji. Dzielenie korporacyjnego Active Directory przez Przemysłowy DMZ to pojedynczy najczęstszy błąd architektoniczny w obronnym OT; konwertuje kompromitację poświadczeń enterprise w kompromitację OT. Pomiar z sprzętowymi korzeniami zaufania na samych stacjach, by powiązać poświadczenie z urządzeniem.
Zdalny dostęp producenta to nieustanne ryzyko. Właściwy wzorzec to jump host w Przemysłowym DMZ, brokerowany dostęp z pełnym nagrywaniem sesji, autoryzacje ograniczone czasowo i model "screen-share" z operatorem w pętli, a nie autonomiczna łączność producenta. Zły wzorzec — wciąż częsty — to permanentny VPN site-to-site z biura producenta do Poziomu 3.
Procedury break-glass muszą istnieć, bo priorytety OT czasem odwracają priorytety cyber: w sytuacji kryzysowej dyżurny musi nadpisać sterownik teraz, nie po rotacji tokena. Udokumentuj poświadczenia break-glass, przechowuj fizycznie, loguj każde użycie i traktuj każde użycie jako incydent wymagający przeglądu po fakcie.
8. Dowody akredytacyjne
Nic z powyższego nie ma znaczenia, jeśli segmentacja nie przeżyje akredytacji. Pakiet Authority to Operate (ATO) dla obronnego segmentu OT zwykle zawiera: diagram stref i conduitów z etykietami klauzuli; określenie IEC 62443 Security Level Target (SL-T) per strefa, uzasadnione modelem zagrożeń; mapowania kontroli conduit po conduit (jakie filtry, jakie protokoły, jakie logowanie); dowody akredytacji cross-domain solutions (baseline NCDSMO dla USA, krajowe odpowiedniki w państwach NATO); oświadczenia o ryzyku rezydualnym dla każdej luki kontrolnej; oraz operacyjny plan ciągłego monitoringu opisujący, jak SL-T będzie ponownie dowodzony w czasie.
Określenie SL-T to miejsce, gdzie inżynieria spotyka papierologię. IEC 62443-3-2 definiuje cztery poziomy bezpieczeństwa (SL 1 do SL 4) reprezentujące zdolność przeciwnika, któremu strefa musi się oprzeć — od przypadkowego do państwa-narodu z rozległymi zasobami. Segment sterowania radarem na wysuniętej platformie to zwykle SL 3 lub SL 4. Wybrany SL napędza każde dalsze wymaganie kontrolne w IEC 62443-3-3, od polityki haseł po wybór algorytmu kryptograficznego. Wybierz SL za niski, a akredytator odrzuci pakiet; wybierz za wysoki, a nie stać cię, by go zbudować.
Wreszcie, reakredytacja to powracająca kadencja, nie jednorazowe wydarzenie. Większość reżimów obronnych wymaga pełnej ponownej oceny co trzy lata i przeglądu różnicowego przy każdej "znaczącej zmianie" — co w OT obejmuje następną aktualizację firmware producenta. Zarchitektuj segmentację tak, by dowody regenerowały się same: konfiguracja w kontroli wersji, wyniki monitoringu archiwizowane jako artefakty akredytacyjne, rekordy zmian powiązane z ponownymi ocenami ryzyka. Segmentacja, której nie da się ponownie udowodnić, to segmentacja, której już nie masz.