To jeden z powodów, dla których wykrywanie zagrożeń w sieciach OT różni się od standardowego monitoringu bezpieczeństwa IT. W sieci biurowej nowy endpoint agent, vulnerability scanner lub narzędzie do aktywnego wykrywania urządzeń może być traktowane jako normalny element security stacku. W środowisku OT takie samo podejście może wprowadzać ryzyko operacyjne. Podatny na zakłócenia sterownik, legacy engineering workstation lub niezarządzane urządzenie przemysłowe może nie tolerować niespodziewanego ruchu, zmian w oprogramowaniu ani agresywnego skanowania.
Jednocześnie środowiska przemysłowe nie mogą już polegać na izolacji jako swojej głównej linii obrony. Konwergencja IT/OT rozszerzyła powierzchnię ataku. Remote access jest obecnie powszechny. Industrial Ethernet jest szeroko wykorzystywany. Systemy SCADA wymieniają dane z aplikacjami biznesowymi. Zespoły utrzymania, dostawcy i integratorzy potrzebują kontrolowanego dostępu do systemów, które kiedyś były traktowane jako odseparowane od sieci firmowej.
Tworzy to trudne wymaganie: organizacje przemysłowe potrzebują lepszej widoczności OT i skuteczniejszego wykrywania zagrożeń, ale muszą osiągnąć je bez zakłócania procesów, które próbują chronić.
Flow-based detection stanowi praktyczną odpowiedź na to wymaganie. Analizując metadane komunikacji zamiast aktywnie skanować urządzenia lub instalować software agents na podatnych na zakłócenia assetach, zespoły bezpieczeństwa i sieciowe mogą wykrywać anomalie, monitorować segmentację, identyfikować nieoczekiwane ścieżki komunikacji i analizować podejrzane zachowania przy minimalnej ingerencji w środowisko produkcyjne.
Table of Contents
Dlaczego sieci OT są niewidoczne z założenia
Wiele sieci OT nie pozostaje niewidocznych dlatego, że nikomu nie zależy na widoczności. Są niewidoczne, ponieważ środowisko zostało zaprojektowane z myślą o innych priorytetach.
Systemy przemysłowe często mają bardzo długi oczekiwany cykl życia. PLC, HMI, RTU, safety controller lub engineering workstation mogą pozostawać w środowisku produkcyjnym przez 10, 15, a nawet 20 lat. Hardware i software wymienia się wyłącznie wtedy, gdy istnieje ku temu silny powód operacyjny, ponieważ każda zmiana wymaga planowania, testów, zatwierdzeń i maintenance windows. W wielu zakładach obowiązuje prosta, nieoficjalna zasada: jeżeli linia działa, nie należy jej dotykać.
Prowadzi to do powstawania luk w widoczności, które rzadko występują w nowoczesnych środowiskach IT. Inwentaryzacje assetów mogą być niekompletne. Diagramy sieciowe mogą nie odzwierciedlać lat niewielkich zmian operacyjnych. Niektóre urządzenia mogą korzystać z nieaktualnego firmware’u lub niewspieranych systemów operacyjnych. Systemy zarządzane przez dostawców mogą być traktowane jak black boxy. Ścieżki remote access mogą istnieć na potrzeby prac serwisowych, ale pozostawać słabo monitorowane. Protokoły przemysłowe mogą komunikować się jawnym tekstem i z założenia nie obsługiwać silnego uwierzytelniania ani szyfrowania.
Komunikacja OT zachowuje się również inaczej niż typowy ruch w sieci firmowej. W wielu przypadkach ruch przemysłowy jest powtarzalny i deterministyczny. To samo HMI komunikuje się z tymi samymi PLC. Ta sama stacja inżynierska łączy się z niewielką liczbą sterowników. Ten sam historian zbiera dane procesowe w oczekiwanych odstępach czasu. Ten sam serwer SCADA wymienia ruch ze znanymi urządzeniami terenowymi.
Ta przewidywalność jest zaletą z perspektywy detekcji, ale tylko wtedy, gdy komunikacja jest rzeczywiście monitorowana. Bez widoczności sieci nieprawidłowe zachowanie może pozostać ukryte wśród rutynowych operacji. Nowy host komunikujący się ze sterownikiem, workstation przechodząca do innej strefy, nieoczekiwane połączenie Modbus lub nagły wzrost ruchu między segmentami sterowania mogą być widoczne w sieci, ale niewidoczne dla zespołu bezpieczeństwa.
Brak widoczności OT nie jest więc wyłącznie problemem inwentaryzacji assetów. Jest problemem komunikacji. Organizacje muszą rozumieć nie tylko, jakie urządzenia istnieją, ale również które systemy się komunikują, jakich protokołów używają, przez które strefy przechodzą i czy te wzorce są oczekiwane z perspektywy procesu przemysłowego.
Dlaczego IT security playbook nie sprawdza się w OT
Bezpośrednie przeniesienie praktyk bezpieczeństwa IT do OT może przynieść więcej ryzyka niż wartości. Różnica nie jest wyłącznie techniczna. Ma charakter operacyjny. Bezpieczeństwo IT często optymalizuje działania pod kątem poufności, szybkiego patchowania i szerokiej kontroli endpointów. Bezpieczeństwo OT musi uwzględniać bezpieczeństwo fizyczne, uptime, certyfikację dostawców, integralność procesów oraz fizyczne konsekwencje zakłóceń.
Dlaczego nie można instalować agentów na urządzeniach OT
Endpoint agents są centralną częścią wielu programów bezpieczeństwa IT. Zapewniają widoczność procesów, wykrywanie malware’u, behavioral analytics i możliwości reagowania. W OT zastosowanie modelu opartego na agentach jest znacznie trudniejsze.
Wiele urządzeń przemysłowych w ogóle nie może obsługiwać agentów. PLC, RTU, sensory, napędy i safety controllers nie są platformami obliczeniowymi ogólnego przeznaczenia. Nawet tam, gdzie wykorzystywane są systemy Windows lub Linux — na przykład na engineering workstations, operator stations lub historianach — instalacja dodatkowego oprogramowania może wymagać zgody dostawcy, testów walidacyjnych i dokładnej koordynacji z zespołami produkcyjnymi.
Najważniejsze obawy mają charakter praktyczny:
- obciążenie systemów dysponujących ograniczonymi zasobami;
- problemy z kompatybilnością z legacy software;
- ograniczenia wsparcia ze strony dostawców;
- nieplanowane restarty lub przerwy w działaniu usług;
- trudność w utrzymywaniu agentów w odizolowanych sieciach;
- opór operacyjny przed wprowadzaniem zmian w stabilnych assetach produkcyjnych;
- brak obsługi agentów na urządzeniach proprietary lub embedded.
Dlatego agentless OT security jest czymś więcej niż wygodą. W wielu środowiskach przemysłowych jest koniecznością. Monitoring bezpieczeństwa musi obserwować środowisko bez modyfikowania urządzeń sterujących produkcją.
Dlaczego aktywne skanowanie może destabilizować systemy przemysłowe
Aktywne skanowanie jest kolejną praktyką bezpieczeństwa IT, która wymaga ostrożności w OT. Vulnerability scanners, port scanners i narzędzia discovery generują ruch skierowany do urządzeń docelowych. W środowisku firmowego IT jest to zwykle akceptowalne, jeśli skanowanie zostało odpowiednio zaplanowane i skonfigurowane. W środowiskach przemysłowych nieoczekiwane pakiety mogą powodować problemy w podatnych na zakłócenia urządzeniach, legacy protocol stacks lub urządzeniach z ograniczoną mocą obliczeniową.
Problem nie polega na tym, że każde skanowanie doprowadzi do awarii PLC. Problemem jest to, że operatorzy środowisk przemysłowych nie mogą zaakceptować niepotrzebnej niepewności dotyczącej systemów produkcyjnych. Sterownik zachowujący się nieprzewidywalnie podczas skanowania, HMI tracące komunikację lub urządzenie wymagające ręcznej interwencji mogą wywołać konsekwencje operacyjne i związane z bezpieczeństwem, które znacznie wykraczają poza typowy incydent IT.
Z tego powodu passive OT monitoring stał się powszechnie stosowany. Zamiast bezpośrednio odpytywać urządzenia, monitoring pasywny obserwuje komunikację już obecną w sieci. Ogranicza to ryzyko zakłócenia procesu i zapewnia zespołom bezpieczeństwa widoczność rzeczywistych wzorców komunikacji.
Aktywne testowanie nadal może mieć swoje miejsce w bezpieczeństwie OT, ale powinno być prowadzone w kontrolowanych warunkach: środowiskach laboratoryjnych, maintenance windows, zatwierdzonych segmentach i w ramach precyzyjnie określonych assessmentów. Nie powinno stanowić domyślnej metody zapewniania codziennej widoczności w działających sieciach produkcyjnych.
Problem konwergencji IT/OT
Tradycyjne postrzeganie OT jako środowiska odizolowanego od IT nie odzwierciedla już rzeczywistości wielu organizacji przemysłowych. Środowiska produkcyjne coraz częściej zależą od wymiany danych z systemami biznesowymi, scentralizowanego zarządzania, remote support, analityki chmurowej i integracji z rozwiązaniami podmiotów trzecich.
Konwergencja tworzy nowe ścieżki prowadzące do OT:
- remote access wykorzystywany przez dostawców i zespoły utrzymania;
- engineering laptops przemieszczające się pomiędzy sieciami IT i OT;
- historiany wymieniające dane z aplikacjami firmowymi;
- industrial DMZ łączące systemy produkcyjne z systemami biznesowymi;
- urządzenia bezprzewodowe i IIoT dodawane do legacy environments;
- współdzielona infrastruktura identity, backupu lub monitoringu;
- platformy połączone z chmurą i narzędzia predictive maintenance.
Każde połączenie może być uzasadnione i konieczne z perspektywy operacyjnej. Każde może również stać się ścieżką ataku, jeżeli nie jest monitorowane i kontrolowane. Wyzwanie związane z bezpieczeństwem nie ogranicza się już do ochrony granicy między IT i OT. Zespoły muszą również wykrywać podejrzane przemieszczanie się pomiędzy strefami, conduits i segmentami wewnętrznymi.
Monitoring pasywny, aktywny… i trzecia droga — flow-based detection
Monitoring OT często przedstawia się jako wybór pomiędzy podejściem pasywnym i aktywnym. Monitoring pasywny obserwuje ruch bez ingerowania w urządzenia. Monitoring aktywny odpytuje, skanuje lub testuje systemy w celu wykrywania assetów i podatności. To rozróżnienie jest przydatne, ale nie wyjaśnia w pełni opcji architektonicznych dostępnych dla zespołów bezpieczeństwa przemysłowego.
Flow-based detection można traktować jako trzecią warstwę operacyjną w ramach passive OT monitoring. Nie wymaga endpoint agents. Nie skanuje aktywnie sterowników. Nie musi przechowywać payloadu każdego pakietu, aby wykrywać wiele istotnych anomalii. Zamiast tego wykorzystuje metadane flow pochodzące z urządzeń sieciowych, sond lub eksporterów, aby analizować wzorce komunikacji w całym środowisku OT.
Flow-based detection koncentruje się na takich pytaniach, jak:
- które systemy komunikują się pomiędzy strefami OT;
- które hosty korzystają z protokołów przemysłowych;
- które ścieżki komunikacji naruszają zasady segmentacji;
- które urządzenia zaczęły komunikować się po raz pierwszy;
- które wewnętrzne hosty generują nietypowy east-west traffic;
- które assety OT komunikują się z IT, internetem lub sieciami dostawców;
- czy wolumen, czas lub kierunek ruchu zmieniły się względem baseline’u.
Podejście to jest szczególnie wartościowe w sieciach przemysłowych, ponieważ ruch OT jest często stabilny. Gdy zostanie określony baseline normalnej komunikacji, odstępstwa zaczynają mieć znaczenie. Nowy host komunikujący się z PLC, sterownik komunikujący się poza swoją strefą, workstation korzystająca z Modbus po raz pierwszy lub nieoczekiwane połączenie z IT do Level 2 mogą zostać wykryte jako zmiana zachowania komunikacyjnego.
Flow a deep packet inspection w OT
Deep packet inspection i monitoring oparty na flow są użyteczne, ale działają na różnych poziomach szczegółowości. DPI analizuje zawartość pakietów i semantykę protokołów. Monitoring oparty na flow analizuje metadane komunikacji, takie jak źródło, cel, porty, protokoły, czas, wolumen i kierunek.
| Podejście | Co widzi | Mocna strona w OT | Główne ograniczenie |
|---|---|---|---|
| Deep packet inspection | Payload pakietu, komendy protokołu, function codes, szczegółowy kontekst aplikacyjny | Zaawansowana analiza na poziomie protokołu, przydatna w przypadku konkretnych komend przemysłowych i detekcji uwzględniającej proces | Większe wymagania dotyczące storage’u i przetwarzania; może wymagać dostępu do pakietów i parserów protokołów |
| Flow-based detection | Metadane dotyczące komunikacji pomiędzy systemami | Skalowalna widoczność, długa retencja, monitoring segmentacji, wykrywanie anomalii, niski wpływ operacyjny | Nie pokazuje payloadu ani pełnych szczegółów na poziomie komend |
| Active scanning | Odpowiedzi od odpytywanych urządzeń | Asset discovery i vulnerability assessment w kontrolowanych warunkach | Może wprowadzać ryzyko operacyjne w działających środowiskach OT |
| Endpoint agents | Aktywność na poziomie procesów, plików i systemu na obsługiwanych hostach | Zaawansowana widoczność na engineering workstations i serwerach | Często niemożliwe lub niewskazane na urządzeniach przemysłowych |
DPI jest wartościowe, gdy analityk musi zrozumieć konkretne komendy przemysłowe, takie jak operacje odczytu i zapisu, function codes lub zachowanie charakterystyczne dla określonego protokołu. Monitoring oparty na flow jest wartościowy, gdy organizacja potrzebuje szerokiej, skalowalnej i niewymagającej dużej ingerencji widoczności obejmującej strefy i conduits.
W praktyce oba podejścia mogą się uzupełniać. Dane flow mogą wskazać, gdzie komunikacja jest nieprawidłowa, który segment wymaga głębszej inspekcji i jaki przedział czasowy należy przeanalizować. DPI może następnie dostarczyć dodatkowe szczegóły na poziomie protokołu tam, gdzie dostępna jest widoczność pakietów i gdzie jest ona odpowiednia z perspektywy operacyjnej.
Jak monitoring oparty na flow mapuje się na Purdue Model
Purdue Model pozostaje użytecznym sposobem opisywania architektury sieci przemysłowych, nawet jeśli współczesne środowiska są często bardziej złożone niż pierwotny model warstwowy. Monitoring oparty na flow naturalnie wpisuje się w tę strukturę, ponieważ koncentruje się na komunikacji pomiędzy poziomami, strefami i conduits.
Uproszczony model monitoringu może wyglądać następująco:
| Poziom Purdue | Typowe systemy | Obszar monitoringu opartego na flow |
|---|---|---|
| Level 5 | Systemy Enterprise IT | Połączenia prowadzące do industrial DMZ, remote access i aplikacji biznesowych |
| Level 4 | Planowanie biznesowe i logistyka zakładu | Wymiana danych z historianami, systemami raportowymi i aplikacjami produkcyjnymi |
| Level 3.5 | Industrial DMZ | Kontrolowane conduits pomiędzy IT i OT, jump servers, patch repositories, remote access brokers |
| Level 3 | Zarządzanie operacjami | Serwery SCADA, historiany, engineering workstations, systemy zarządzania OT |
| Level 2 | Sterowanie nadrzędne | HMI, operator stations, systemy sterowni |
| Level 1 | Sterowanie podstawowe | PLC, RTU, sterowniki, protection relays |
| Level 0 | Proces fizyczny | Sensory, aktuatory, urządzenia terenowe |
Monitoring oparty na flow można umieścić w kluczowych punktach granicznych: na styku IT/OT, w industrial DMZ, w rdzeniu sieci sterowania, na firewallach pomiędzy strefami, na łączach data center, w punktach remote access i w wybranych punktach agregacji wewnątrz sieci OT. Celem jest obserwowanie komunikacji przebiegającej przez conduits, a nie ingerowanie w urządzenia.
Prosty diagram koncepcyjny:
Enterprise IT
|
| monitorowany conduit
v
Industrial DMZ
|
| monitorowany conduit
v
Operations / SCADA / Historian
|
| monitorowany conduit
v
HMI / Engineering / Control Network
|
| monitorowany conduit
v
Segmenty PLC / RTU / sterownikówZ perspektywy detekcji najważniejsze pytanie brzmi: czy komunikacja przebiega zgodnie z oczekiwaną architekturą? Jeżeli systemy Level 4 mogą uzyskiwać bezpośredni dostęp do sterowników, vendor VPN omija DMZ, workstation w jednej komórce produkcyjnej komunikuje się z inną komórką albo sterownik inicjuje komunikację outbound w kierunku IT, dane flow mogą ujawnić takie naruszenia.
Ustanawianie baseline’u w deterministycznej sieci
OT anomaly detection działa najlepiej, gdy baseline odzwierciedla rzeczywisty proces. Sieci przemysłowe często charakteryzują się stabilnymi wzorcami komunikacji, ponieważ systemy produkcyjne wykonują powtarzalne zadania. Dzięki temu flow-based detection dobrze nadaje się do identyfikowania odstępstw.
Przydatny baseline OT powinien obejmować:
- normalną komunikację host-to-host;
- oczekiwane protokoły dla każdej strefy;
- zatwierdzone conduits pomiędzy poziomami;
- typowy czas i częstotliwość komunikacji;
- normalny wolumen ruchu dla poszczególnych systemów i segmentów;
- znane zachowanie engineering workstations;
- zatwierdzone ścieżki remote access;
- oczekiwaną komunikację z historianami, serwerami SCADA i HMI;
- wyjątki obowiązujące podczas maintenance windows.
Po ustanowieniu takiego baseline’u logika detekcji staje się bardziej wartościowa. Celem nie jest oznaczanie każdego nieznanego pakietu jako krytycznego incydentu. Celem jest identyfikowanie zmian, które mają znaczenie w kontekście przemysłowym: nowego talkera, nowego protokołu, nowej ścieżki pomiędzy strefami, nieoczekiwanego wzrostu ruchu lub komunikacji pochodzącej z hosta, który powinien pozostawać odizolowany.
Podejście to pomaga również ograniczyć false positives. Zamiast stosować ogólne reguły IT w środowisku przemysłowym, detekcja opiera się na tym, co jest normalne dla konkretnego zakładu, linii, komórki, strefy lub procesu.
Jak atak wygląda w danych flow OT
Ataki na OT nie zawsze rozpoczynają się od gwałtownego zakłócenia procesu. Często zaczynają się od reconnaissance, nieautoryzowanego dostępu, cichego przemieszczania się pomiędzy strefami lub niewłaściwego użycia legalnych protokołów. Dane flow mogą ujawnić te wczesne etapy, zanim atakujący osiągnie punkt, w którym może manipulować procesem.
Reconnaissance i nieoczekiwani talkers
Reconnaissance w OT może objawiać się jako host próbujący komunikować się z wieloma urządzeniami, portami lub segmentami, do których normalnie nie uzyskuje dostępu. Źródłem może być przejęta engineering workstation, serwer remote access, laptop dostawcy, host IT lub system znajdujący się w industrial DMZ.
Wskaźniki oparte na flow obejmują:
- jeden host komunikujący się z wieloma assetami OT w krótkim czasie;
- połączenia z wieloma portami protokołów przemysłowych;
- próby komunikacji obejmujące kilka komórek produkcyjnych;
- nowy ruch z sieci IT w kierunku systemów OT;
- powtarzające się nieudane lub krótkotrwałe sesje;
- nowe urządzenia pojawiające się w segmentach sterowników lub HMI.
W deterministycznym środowisku nieoczekiwani talkers są często ważniejsi niż sam wolumen ruchu. Niewielka liczba połączeń pochodzących z niewłaściwego hosta i skierowanych do niewłaściwego sterownika może mieć większe znaczenie niż duża ilość rutynowego ruchu historianów.
Cross-zone i east-west traffic naruszający segmentację
Segmentacja stanowi jeden z fundamentów bezpieczeństwa OT. Strefy i conduits definiują, które systemy powinny się komunikować i na jakich warunkach. Dane flow pomagają zweryfikować, czy sieć rzeczywiście zachowuje się zgodnie z tym projektem.
Podejrzane wzorce obejmują:
- bezpośrednią komunikację z Enterprise IT do systemów sterowania;
- ruch omijający industrial DMZ;
- komunikację pomiędzy komórkami produkcyjnymi, które powinny być odizolowane;
- ścieżki remote access umożliwiające bezpośredni dostęp do sterowników;
- nowy east-west traffic pomiędzy engineering workstations i HMI;
- ruch z jednego segmentu zarządzanego przez dostawcę do innego;
- komunikację sterownika poza jego oczekiwaną strefą.
Wzorce te mają znaczenie, ponieważ wiele ataków na OT wymaga przemieszczania się przez systemy pośrednie. Atakujący mogą najpierw przejąć host IT, a następnie wykonać lateral movement do jump servera, historiana, engineering workstation lub HMI, zanim dotrą do sterowników. Monitoring oparty na flow może ujawnić tę ścieżkę jeszcze przed końcowym etapem ataku.
Nieautoryzowane użycie protokołów przemysłowych
Protokoły przemysłowe, takie jak Modbus, DNP3, S7, OPC UA, EtherNet/IP i IEC 60870-5-104, są normalnym elementem środowisk OT. Sama ich obecność nie jest podejrzana. Istotne pytanie brzmi: czy właściwe systemy korzystają z właściwych protokołów, we właściwym kierunku i we właściwym czasie?
Przykłady podejrzanych wzorców flow obejmują:
| Wzorzec | Dlaczego ma znaczenie |
|---|---|
| Nowy host używający Modbus w kierunku segmentu PLC | Może wskazywać na nieautoryzowane działania inżynierskie lub reconnaissance. |
| Ruch DNP3 z nieoczekiwanego źródła | Może sugerować użycie protokołu poza zatwierdzonymi ścieżkami. |
| Komunikacja S7 z workstation znajdującej się poza strefą inżynierską | Może wskazywać na nieautoryzowany dostęp do sterowników Siemens. |
| Ruch OPC UA omijający DMZ | Może naruszać zatwierdzoną architekturę i narażać dane procesowe. |
| Ruch protokołów przemysłowych poza maintenance windows | Może wskazywać na podejrzaną aktywność lub nieautoryzowane próby wprowadzania zmian. |
Dane flow nie pokażą pełnej semantyki komend w taki sposób jak DPI. Mogą jednak wykazać, że dany protokół pojawił się w nieoczekiwanym miejscu, pochodził z nieoczekiwanego źródła lub przechodził przez conduit, w którym nie powinien występować. Taki sygnał często wystarcza, aby rozpocząć dokładniejszą analizę.
Wnioski z rzeczywistych ataków na OT
Rzeczywiste incydenty przemysłowe pokazują, dlaczego widoczność wewnątrz OT ma znaczenie.
TRITON, znany również jako TRISIS, był wymierzony w systemy bezpieczeństwa przemysłowego Schneider Electric Triconex. Jego znaczenie wynikało nie tylko z tego, że malware dotarł do środowiska przemysłowego, ale również z faktu, że zaatakował systemy zaprojektowane w celu ochrony procesów fizycznych. Dla zespołów odpowiedzialnych za ochronę wniosek jest jasny: monitoring nie powinien kończyć się na granicy IT/OT. Ścieżki prowadzące do systemów bezpieczeństwa, sterowania i inżynierskich również wymagają widoczności.
Industroyer, znany także jako CrashOverride, został zaprojektowany w celu wpływania na działanie sieci energetycznych i wykorzystany podczas ataku na ukraińską sieć elektroenergetyczną w 2016 roku. Industroyer2 pokazał później, że możliwości specyficzne dla ICS nadal odgrywały istotną rolę w kolejnych atakach na ukraińską infrastrukturę energetyczną. Przypadki te podkreślają znaczenie monitorowania użycia protokołów, komunikacji systemów sterowania oraz aktywności wokół podstacji, systemów SCADA i środowisk inżynierskich.
PIPEDREAM, znany również jako INCONTROLLER, pokazał jeszcze jedną ważną rzecz: zaawansowane narzędzia do atakowania OT mogą być projektowane tak, aby bezpośrednio komunikować się z urządzeniami przemysłowymi i systemami automatyki. Gdy atakujący uzyska dostęp do sieci OT, możliwość wykrywania sterowników, komunikowania się z nimi i manipulowania nimi staje się poważnym zagrożeniem.
Wspólny wniosek dotyczący detekcji we wszystkich tych przypadkach nie polega na tym, że każda organizacja będzie musiała zmierzyć się z tym samym malware’em. Atakujący potrzebują ścieżek komunikacji. Muszą dotrzeć do systemów inżynierskich, sterowników, systemów bezpieczeństwa, punktów remote access, serwerów przemysłowych lub gateways protokołów. Monitoring oparty na flow pomaga ujawniać te ścieżki, szczególnie gdy ruch przekracza granicę strefy lub odbiega od normalnego zachowania procesu.
Mapowanie detekcji do MITRE ATT&CK for ICS
MITRE ATT&CK for ICS zapewnia użyteczny framework do opisywania zachowań adversary w środowiskach przemysłowych. Dowody oparte na flow mogą wspierać to mapowanie na poziomie komunikacji i zachowania.
| Obserwacja oparta na flow | Możliwe mapowanie ATT&CK for ICS | Wartość detekcyjna |
|---|---|---|
| Jeden host łączący się z wieloma assetami lub portami OT | Discovery | Wskazuje na reconnaissance lub enumerację assetów |
| Nowa komunikacja pomiędzy strefami IT i OT | Initial Access / Lateral Movement | Pokazuje potencjalną ścieżkę z systemów firmowych do środowiska produkcyjnego |
| Korzystanie z remote services pomiędzy segmentami OT | Lateral Movement | Pomaga wykrywać przemieszczanie się przez systemy inżynierskie lub nadzorcze |
| Nowy lub nieautoryzowany ruch protokołu przemysłowego | Command and Control / Impair Process Control, zależnie od kontekstu | Wskazuje na użycie protokołu naruszające oczekiwany wzorzec zachowania |
| Komunikacja ze sterownikami poza maintenance windows | Execution / Impair Process Control, zależnie od dostępnych dowodów | Może wskazywać na nieautoryzowaną interakcję z urządzeniami procesowymi |
| Duży lub nietypowy transfer danych z systemów OT | Collection / Exfiltration | Wspiera analizę transferu danych lub kradzieży informacji procesowych |
| Ruch do znanej złośliwej lub podejrzanej infrastruktury | Command and Control | Wskazuje na potencjalną komunikację z zewnętrznym atakującym |
Mapowanie powinno pozostać precyzyjne. Dane flow mogą potwierdzać określone ustalenie, ale nie dowodzą automatycznie wystąpienia całej techniki. Nowe połączenie Modbus z engineering workstation może być uzasadnione w trakcie maintenance window, a jednocześnie podejrzane o godzinie 2:00 w nocy, jeśli pochodzi z nieznanego laptopa. Kontekst decyduje o ostatecznym wniosku.
Dobry raport z detekcji OT powinien zatem łączyć trzy elementy:
- zaobserwowane dowody flow;
- kontekst przemysłowy, taki jak strefa, rola assetu i harmonogram prac serwisowych;
- mapowanie ATT&CK for ICS tam, gdzie zachowanie odpowiada znanej taktyce lub technice.
Zapewnia to zespołowi bezpieczeństwa wspólny język raportowania bez utraty niuansów operacyjnych.
Compliance — jak monitoring oparty na flow wspiera IEC 62443, NERC CIP i NIS2
Monitoring oparty na flow sam w sobie nie jest narzędziem compliance, ale wspiera kilka zdolności, których rozwijania oczekują od organizacji frameworki i regulacje dotyczące bezpieczeństwa przemysłowego.
IEC 62443 kładzie nacisk na opartą na ryzyku segmentację, zones and conduits, integralność systemów i defense-in-depth. Dane flow pomagają zweryfikować, czy zones and conduits rzeczywiście działają zgodnie z założeniami. Mogą pokazać, czy komunikacja przebiega według zatwierdzonej architektury, czy istnieją nieoczekiwane ścieżki oraz czy w obszarach wrażliwych pojawiają się nowe urządzenia lub protokoły.
NERC CIP, mający zastosowanie do North American Bulk Electric System, obejmuje wymagania dotyczące elektronicznych granic bezpieczeństwa, kontroli dostępu, incident response i ochrony krytycznych systemów cybernetycznych. Monitoring oparty na flow może wspierać dostarczanie dowodów na kontrolowanie ścieżek komunikacji, wykrywanie prób nieautoryzowanego dostępu, przegląd aktywności sieciowej i analizę incydentów.
NIS2 zwiększa oczekiwania dotyczące zarządzania ryzykiem cyberbezpieczeństwa, obsługi incydentów, ciągłości działania i raportowania dla podmiotów kluczowych i ważnych w UE. W przypadku organizacji przemysłowych objętych dyrektywą widoczność oparta na flow wspiera zdolność wykrywania podejrzanej aktywności, rekonstruowania incydentów, oceny wpływu oraz dostarczania dowodów na potrzeby raportowania i działań naprawczych.
We wszystkich tych frameworkach powtarza się podobna potrzeba operacyjna: organizacje muszą rozumieć swoje ścieżki komunikacji, wykrywać odstępstwa, dokumentować incydenty i udowadniać, że mechanizmy bezpieczeństwa działają zgodnie z założeniami. Dane flow zapewniają praktyczną warstwę dowodową wspierającą te działania.
Monitoring OT oparty na flow w praktyce z Sycope
W środowisku OT Sycope może wspierać pasywny monitoring oparty na flow poprzez zbieranie i analizowanie NetFlow, IPFIX, sFlow lub powiązanej telemetrii flow pochodzącej z infrastruktury sieciowej, sond lub kluczowych punktów granicznych. Podejście to nie wymaga instalowania agentów na PLC, sterownikach ani innych podatnych na zakłócenia urządzeniach przemysłowych i nie zależy od aktywnego skanowania jako podstawowego źródła widoczności.
Praktyczny workflow monitoringu OT oparty na Sycope może obejmować:
- zbieranie danych flow ze styku IT/OT, industrial DMZ, core switches, routerów, firewalli lub wybranych punktów agregacji OT;
- mapowanie komunikacji pomiędzy strefami, conduits, komórkami produkcyjnymi i systemami krytycznymi;
- ustanowienie baseline’u normalnej komunikacji OT według hosta, protokołu, portu, czasu i wolumenu ruchu;
- wykrywanie nowych talkers, nieautoryzowanych protokołów i komunikacji cross-zone naruszającej segmentację;
- monitorowanie ścieżek remote access, engineering workstations, historianów, serwerów SCADA i kluczowych segmentów systemów sterowania;
- alertowanie o nietypowych wzorcach komunikacji, takich jak nowy east-west traffic, podejrzane zewnętrzne destynacje lub nieoczekiwane użycie protokołów;
- wspieranie analiz za pomocą historycznych danych flow i filtrowania według hosta, portu, protokołu, przedziału czasowego lub konwersacji;
- dokumentowanie ustaleń na timeline, który może wspierać incident response, audyt i działania compliance.
Podejście to jest szczególnie przydatne, gdy zespoły przemysłowe potrzebują widoczności bez zakłócania operacji. Flow-based detection nie zastępuje DPI uwzględniającego specyfikę protokołów ani specjalistycznych mechanizmów bezpieczeństwa OT, ale zapewnia skalowalną warstwę widoczności, która pomaga zespołom zrozumieć, co dzieje się w całej sieci.
Dla OT security managers wartością jest ograniczenie blind spotów i dostęp do lepszych dowodów. Dla zespołów NetOps w środowiskach przemysłowych — czytelniejsze mapowanie komunikacji i szybszy troubleshooting. Dla zespołów SOC — wcześniejsze wykrywanie movement, misuse i naruszeń polityk w środowiskach, w których telemetria endpointów jest ograniczona.
Praktycznym rezultatem jest łatwiejszy do obrony model monitoringu OT: z założenia pasywny, skoncentrowany na zachowaniu komunikacji, zgodny z segmentacją i odpowiedni dla środowisk, w których stabilność produkcji stanowi najwyższy priorytet.
FAQ
Czy można monitorować sieć OT bez instalowania agentów?
Tak. Sieci OT można monitorować bez instalowania agentów, wykorzystując passive network monitoring i flow-based detection. Zamiast wdrażać oprogramowanie na sterownikach, PLC lub innych urządzeniach przemysłowych, system monitorujący analizuje metadane ruchu zbierane z infrastruktury sieciowej, sond lub eksporterów telemetrii.
Podejście to jest szczególnie istotne w środowiskach OT, w których urządzenia mogą być legacy, zarządzane przez dostawców, posiadać ograniczone zasoby lub być zbyt wrażliwe, aby modyfikować je bez przeprowadzenia rozbudowanych testów.
Czy monitoring sieci może zakłócić procesy przemysłowe?
Monitoring pasywny i flow-based detection zostały zaprojektowane tak, aby minimalizować zakłócenia, ponieważ obserwują istniejącą komunikację, zamiast aktywnie odpytywać urządzenia. Jeżeli są prawidłowo wdrożone, nie generują ruchu skanującego skierowanego do PLC, HMI ani sterowników.
Aktywne skanowanie i testowanie podatności wymagają większej ostrożności. Powinny być dokładnie zaplanowane, zatwierdzone i przetestowane, szczególnie w działających środowiskach produkcyjnych, ponieważ niektóre systemy przemysłowe mogą reagować nieprzewidywalnie na nieoczekiwany ruch.
Jaka jest różnica pomiędzy pasywnym i aktywnym monitoringiem OT?
Pasywny monitoring OT obserwuje ruch, który już istnieje w sieci. Jest powszechnie stosowany do zapewniania ciągłej widoczności, wykrywania anomalii i mapowania komunikacji, ponieważ ogranicza ryzyko ingerencji w procesy przemysłowe.
Aktywny monitoring OT wysyła do urządzeń zapytania, probes lub ruch skanujący. Może dostarczyć przydatnych informacji o assetach i podatnościach, ale wprowadza większe ryzyko operacyjne i powinien być stosowany ostrożnie, szczególnie w przypadku podatnych na zakłócenia lub legacy systems.
Flow-based detection jest podejściem pasywnym skoncentrowanym na metadanych: źródle, celu, protokole, portach, czasie, wolumenie i kierunku.
Jakich protokołów używają sieci OT?
Do popularnych protokołów OT i ICS należą Modbus, DNP3, OPC UA, Siemens S7, EtherNet/IP, PROFINET, IEC 60870-5-104, IEC 61850 oraz protokoły specyficzne dla poszczególnych dostawców. Dokładny zestaw protokołów zależy od branży, dostawców sprzętu, architektury i wieku środowiska.
Z perspektywy detekcji ważne jest nie tylko to, jakie protokoły występują, ale również czy korzystają z nich oczekiwane systemy, czy są używane przez zatwierdzone ścieżki i czy komunikacja odbywa się w normalnych oknach operacyjnych.
Jak flow-based detection mapuje się na Purdue Model i IEC 62443?
Flow-based detection dobrze mapuje się na Purdue Model, ponieważ może monitorować komunikację pomiędzy poziomami, takimi jak Enterprise IT, industrial DMZ, zarządzanie operacjami, sterowanie nadrzędne i segmenty sterowników. Pomaga ustalić, czy ruch przebiega oczekiwanymi ścieżkami, czy omija zatwierdzone conduits.
Wspiera również koncepcje IEC 62443, takie jak zones and conduits. Analizując dane flow, zespoły mogą sprawdzić, czy komunikacja pomiędzy strefami odpowiada założonemu projektowi segmentacji, oraz wykrywać ruch naruszający przyjęte założenia bezpieczeństwa.
