Prewencja nigdy nie jest doskonała, więc pytanie brzmi nie tylko jak powstrzymywać incydenty, lecz także jak reagować, gdy do incydentu dojdzie. W OT ta reakcja stanowi odrębną dyscyplinę, ponieważ typowe odruchy z IT, takie jak agresywna izolacja, odłączanie systemów i odbudowa, mogą być niebezpieczne lub niemożliwe, gdy trwa proces fizyczny.

Reagowanie na incydenty OT musi jednocześnie realizować dwa cele: powstrzymać incydent cybernetyczny oraz utrzymać proces fizyczny w stanie bezpiecznym i, o ile to możliwe, działającym. W tym artykule przyglądamy się temu, czym reagowanie na incydenty OT różni się od IT oraz jak łączą się w nim przygotowanie, powstrzymywanie, przywracanie działania i praktyka.

01Najważniejsze wnioski

  1. 01

    Reagowanie na incydenty OT stawia na pierwszym miejscu bezpieczeństwo i dostępność, co może kolidować ze standardowymi działaniami reagowania w IT.

  2. 02

    Często nie da się po prostu odłączyć systemów, ponieważ może to być niebezpieczne lub wstrzymać krytyczne operacje.

  3. 03

    Najważniejsze jest przygotowanie: podręczniki reagowania właściwe dla OT, role i decyzje podjęte przed incydentem, a nie w jego trakcie.

  4. 04

    Izolacja to kluczowe narzędzie powstrzymywania, a zdolność do czystego odłączenia jest cenna podczas reagowania.

  5. 05

    Przywracanie działania zależy od chronionych kopii zapasowych i przetestowanych procedur, a cały plan powinien być ćwiczony.

02Dlaczego reagowanie na incydenty OT różni się od IT

W reagowaniu na incydenty w IT izolacja dotkniętego systemu i jego odbudowa to często słuszny ruch. W OT to samo działanie może być niebezpieczne: taki system może sterować procesem fizycznym, a jego gwałtowne odłączenie lub wyłączenie mogłoby stworzyć zagrożenie bezpieczeństwa lub poważne zakłócenie.

Reagowanie w OT niesie zatem dodatkowy, nadrzędny priorytet: bezpieczeństwo. Przed każdym działaniem powstrzymującym zespół reagujący musi rozważyć jego wpływ na proces fizyczny. Zakładu nie zawsze można traktować jak coś, co da się wstrzymać na czas rozwiązywania incydentu.

W IT najgorszym scenariuszem jest zwykle utrata danych. W OT pochopna reakcja może wywołać fizyczne zdarzenie zagrażające bezpieczeństwu, dlatego sama reakcja musi być bezpieczna.

03Przygotowanie i podręczniki reagowania

Ponieważ decyzje dotyczące reagowania w OT mają wysoką stawkę i są podejmowane pod presją czasu, tam gdzie to możliwe, powinny zapadać z wyprzedzeniem. Najważniejsza praca w reagowaniu na incydenty odbywa się jeszcze przed jakimkolwiek incydentem, na etapie przygotowania.

  • Opracuj podręczniki reagowania właściwe dla OT, które uwzględniają bezpieczeństwo i wpływ na proces, a nie ogólne procedury z IT.
  • Zdefiniuj role w obszarach bezpieczeństwa, operacji, inżynierii i bezpieczeństwa procesowego, z jasno określonymi uprawnieniami decyzyjnymi.
  • Ustal z góry opcje powstrzymywania oraz to, kto może autoryzować działania wpływające na proces.
  • Ustanów ścieżki komunikacji, w tym z operatorami rozumiejącymi konsekwencje fizyczne.
  • Poznaj środowisko z wyprzedzeniem dzięki dokładnej inwentaryzacji zasobów i architekturze.

04Rola izolacji w powstrzymywaniu incydentu

Powstrzymywanie w OT oznacza zatrzymanie rozprzestrzeniania się incydentu bez destabilizacji procesu. Izolacja jest tu kluczowa, ale musi być przeprowadzona w sposób kontrolowany i przemyślany, a nie przez wyrywanie kabli.

Zdolność do czystego i celowego odłączenia segmentu jest cenna podczas reagowania. Kontrolowany wzorzec łączności AIRGAPNET, który już zarządza granicą, można wykorzystać do przecięcia ścieżki w kontrolowany sposób, izolując dotknięty lub zagrożony segment bez improwizowanej, potencjalnie niebezpiecznej interwencji. Opcje powstrzymywania zaprojektowane z wyprzedzeniem są znacznie bezpieczniejsze niż te wymyślane pod presją.

Ta sama architektura ograniczonej osiągalności, która ogranicza rozprzestrzenianie się incydentu, daje też zespołowi reagującemu czyste, zaplanowane wcześniej punkty, w których można go powstrzymać.

05Ograniczenia analizy śledczej w OT

Badanie incydentu OT jest ograniczone tymi samymi realiami, które kształtują wszystko inne. Często nie można wyłączyć sterownika, aby wykonać jego obraz, a wiele urządzeń nie generuje bogatych logów, jakich oczekują śledczy z IT.

  • Systemów pracujących na żywo może nie dać się bezpiecznie usunąć w celu pozyskania danych śledczych.
  • Urządzenia mogą mieć ograniczone logowanie lub go nie prowadzić, więc dowodów jest niewiele.
  • Pasywne dane sieciowe są często najłatwiej dostępnym źródłem dowodów.
  • Zabezpieczanie dowodów trzeba wyważyć względem przywracania bezpiecznego działania.

06Przywracanie działania i odtwarzanie z chronionych kopii zapasowych

Przywracanie działania w OT oznacza powrót do bezpiecznej, normalnej pracy, co jest bardziej złożone niż odtworzenie danych. Może wymagać odbudowy systemów sterowania, odtworzenia konfiguracji i logiki oraz ostrożnego ponownego uruchomienia procesu fizycznego.

Zależy to od posiadania kopii zapasowych, do których incydent nie mógł sięgnąć i o których wiadomo, że działają, w tym offline'owych kopii konfiguracji i logiki sterowników. Gotowość do przywracania działania, czyli chronione i przetestowane kopie zapasowe oraz udokumentowane procedury ponownego uruchomienia, jest tym, co zamienia potencjalną katastrofę w możliwe do opanowania, choć trudne, przywrócenie działania.

07Ćwiczenia sztabowe (tabletop)

Plan, który nigdy nie został przetestowany, jest jedynie hipotezą. Ćwiczenia sztabowe (tabletop) prowadzą zespół przez realistyczne scenariusze OT, ujawniając luki w decyzjach, rolach i założeniach, zanim zrobi to prawdziwy incydent.

Ćwiczenie reagowania na incydenty OT jest szczególnie ważne, ponieważ zbiera przy jednym stole bezpieczeństwo, operacje, inżynierię i bezpieczeństwo procesowe, by z wyprzedzeniem przećwiczyć trudne kompromisy. Chodzi o to, aby w chwili prawdziwego incydentu trudne decyzje były już przemyślane.

08Myśl na koniec

Reagowanie na incydenty OT to nie reagowanie na incydenty IT pod inną nazwą. Kształtuje je twarde ograniczenie, że sama reakcja musi być bezpieczna, które wyklucza wiele standardowych ruchów i wymaga starannych, wcześniej zaplanowanych alternatyw.

Przygotuj podręczniki reagowania, zaprojektuj czyste punkty powstrzymywania, chroń środki umożliwiające przywrócenie działania i ćwicz. Gdy prewencja zawiedzie, a w końcu tak się stanie, to plan zbudowany pod realia OT sprawia, że incydent nie staje się katastrofą.

FAQNajczęściej zadawane pytania

Czym reagowanie na incydenty OT różni się od IT?

Reagowanie w OT musi stawiać na pierwszym miejscu bezpieczeństwo i dostępność. Standardowe działania z IT, takie jak agresywna izolacja lub wyłączenie systemu, mogą być niebezpieczne, gdy taki system steruje procesem fizycznym, dlatego zespół reagujący musi rozważać wpływ każdego działania na sam proces.

Dlaczego nie można po prostu odłączyć systemów OT podczas incydentu?

System OT może sterować działającym procesem fizycznym, a jego gwałtowne odłączenie lub wyłączenie mogłoby stworzyć zagrożenie bezpieczeństwa lub wstrzymać krytyczne operacje. Powstrzymywanie w OT musi być kontrolowane i przemyślane, a nie improwizowanym wyrwaniem kabla.

Co jest najważniejsze w reagowaniu na incydenty OT?

Przygotowanie. Ponieważ decyzje dotyczące reagowania w OT mają wysoką stawkę i są podejmowane pod presją czasu, powinny zapadać z wyprzedzeniem poprzez podręczniki reagowania właściwe dla OT, jasno zdefiniowane role w obszarach bezpieczeństwa, operacji, inżynierii i bezpieczeństwa procesowego oraz ustalone z góry opcje powstrzymywania.

Jak izolacja pomaga powstrzymać incydent OT?

Izolacja zatrzymuje rozprzestrzenianie się incydentu bez destabilizacji procesu, ale musi być przeprowadzona czysto. Granica już zarządzana przez kontrolowaną łączność daje zespołowi reagującemu zaplanowane wcześniej punkty, w których można bezpiecznie przeciąć ścieżkę, zamiast improwizować pod presją.

Czego wymaga przywracanie działania w OT?

Powrotu do bezpiecznej pracy, co może oznaczać odbudowę systemów sterowania, odtworzenie konfiguracji i logiki oraz ostrożne ponowne uruchomienie procesu. Zależy to od chronionych kopii zapasowych, do których incydent nie mógł sięgnąć, w tym offline'owych kopii logiki sterowników, oraz od udokumentowanych procedur ponownego uruchomienia.

SRCŹródła referencyjne

Zaplanuj reakcję, zanim będzie potrzebna

Zaprojektuj czyste punkty powstrzymywania z wyprzedzeniem.

Granica już zarządzana przez kontrolowaną łączność pozwala zespołowi reagującemu bezpiecznie i celowo odizolować dotknięty segment, zamiast improwizować ryzykowne odłączenie pod presją.

Powiązany artykuł

Kontynuuj wątek Ransomware in OT: How Industrial Attacks Unfold and How to Contain Them