Jak zabezpieczyć automatykę przemysłową | All for One Poland

Jak zabezpieczyć automatykę przemysłową

Jak zabezpieczyć automatykę przemysłową

Rosnąca liczba cyberataków na systemy przemysłowe pokazuje, że automatyka przemysłowa, podobnie jak infrastruktura IT, wymaga ochrony. Tej ochrony, a także przeciwdziałania skutkom awarii i błędów ludzkich domagają się także regulatorzy rynków. Wraz z nadchodzącą implementacją dyrektywy NIS2 i nowej ustawy o Krajowym Systemie Cyberbezpieczeństwa, zapewnienie bezpieczeństwa OT staje się obowiązkiem już nie tylko w przedsiębiorstwach zaliczonych do infrastruktury krytycznej, ale także w wielu gałęziach sektora produkcyjnego. Przedstawiamy sprawdzone praktyki, metody i przykłady skutecznego zarządzania bezpieczeństwem i zapewnienia ciągłości działania w środowiskach automatyki.

Rosnąca liczba cyberataków na systemy przemysłowe pokazuje, że automatyka przemysłowa, podobnie jak infrastruktura IT, wymaga ochrony. Tej ochrony, a także przeciwdziałania skutkom awarii i błędów ludzkich domagają się także regulatorzy rynków. Wraz z nadchodzącą implementacją dyrektywy NIS2 i nowej ustawy o Krajowym Systemie Cyberbezpieczeństwa, zapewnienie bezpieczeństwa OT staje się obowiązkiem już nie tylko w przedsiębiorstwach zaliczonych do infrastruktury krytycznej, ale także w wielu gałęziach sektora produkcyjnego. Przedstawiamy sprawdzone praktyki, metody i przykłady skutecznego zarządzania bezpieczeństwem i zapewnienia ciągłości działania w środowiskach automatyki.

Infrastruktura informatyczna, w tym oprogramowanie wspierające procesy biznesowe środowisk przemysłowych (np. maszyny produkcyjne, pompy, urządzenia kolejowe), określane ogólnie jako systemy OT (Operational Technology) były pierwotnie projektowane do pracy w trybie 24/7 w „odizolowanych” sieciach. Dziś są integrowane z systemami IT, zdalnym utrzymaniem, usługami chmurowymi i rozwiązaniami zewnętrznych dostawców, co diametralnie zmienia profil ryzyka.

Wypracowanie odpowiednich procedur oraz praktyczne podejście do bezpieczeństwa i ciągłości działania systemów OT w organizacji powinno stać się obszarem systemowego działania, podobnie jak to wcześniej stało się w środowiskach IT.

Ryzyko w OT: hakerzy, awarie i błędy ludzkie

Większość obaw związanych z podatnościami automatyki przemysłowej wiąże się z ryzykiem ingerencji z zewnątrz. Jednak nasze doświadczenia z projektów wdrożeń systemów cyberbezpieczeństwa w sieciach OT, także w oparciu o ustawę o Krajowym Systemie Cyberbezpieczeństwa wskazują, że znaczna część incydentów ma źródło wewnętrzne: awarie, niezamierzone zmiany, błędy konfiguracji, nieuwaga operatora. Należy założyć, że spodziewana nowelizacja ustawy o KSC będzie odzwierciedlała te obserwacje.

Już pierwsza dyrektywa NIS zaimplementowana w Polsce poprzez ustawę KSC kładła duży nacisk na analizę ryzyk i reagowania na incydenty w tym zakresie. A zatem ważne jest, by przygotowania do implementacji nowych przepisów, inwentaryzacje, analiza ryzyka, plany reagowania oraz wdrażane narzędzia monitorowania środowiska OT pozwalały równolegle zarządzać incydentami oraz wykrywać anomalie operacyjne wynikające z awarii czy błędów ludzkich (ciągłość działania).

Rozmawiając z decydentami (także na poziomie zarządu) o planowaniu bezpieczeństwa, należy podkreślać wagę obu grup źródeł zagrożeń oraz konieczność ich monitorowania i zapobiegania.

O ile coraz silniejsze jest przekonanie decydentów o konieczności wdrożenia systemów bezpieczeństwa w sieciach OT, to jednak projekty te często wzbudzają uzasadnione obawy. W wielu firmach infrastruktura OT jest przestarzała i jej integracja z nowoczesnymi systemami IT może się wiązać z dużym ryzykiem. Jest to jednak działanie coraz bardziej pożądane. Nie tylko ze względów bezpieczeństwa, ale także z powodu dążenia do coraz dalej posuniętej automatyzacji i zdalnego dostępu do systemów OT, koniecznego do obniżenia kosztów utrzymania infrastruktury.

Inna obawa wiąże się z tym, czy specjaliści IT, którzy otrzymują zadanie wsparcia kolegów automatyków w tym nowym dla nich zadaniu, rozumieją świat automatyki.

Zmiany czekają obie strony. W IT z pewnością są duże potrzeby edukacyjne i lekcja do odrobienia na temat tego, z czym zmierzą się, wchodząc do świata OT. Zespoły OT muszą być świadome konieczności dostosowania się do wymogów IT. Dodatkowo w firmach obarczonych wymogami dostosowania się do coraz większej liczby coraz bardziej restrykcyjnych regulacji na poziomie unijnym i krajowym konieczne jest jasne komunikowanie wsparcia dla zmian z poziomu zarządów.

Warto podkreślić, że środowiska OT wymagają innego rodzaju środków bezpieczeństwa, często o niższej skali złożoności w porównaniu do nowoczesnych technologii bezpieczeństwa IT. To sprawia, że zastosowanie znajdują przede wszystkim pasywne środki wykrywania incydentów, podczas gdy w IT fundamentem jest aktywna ingerencja w ruch sieciowy. Bardzo statyczny charakter architektur OT oraz bardzo powtarzalna zawartość ruchu sieciowego wpływają na prostszy charakter incydentów, które będziemy wykrywać także w bezpośredniej konsekwencji tego, jakie ryzyka zidentyfikujemy.

IT ≠ OT

Przedstawiamy kluczowe różnice pomiędzy rozwiązaniami IT i automatyką przemysłową, które determinują architekturę zabezpieczeń dla tych systemów.

  • Priorytet: IT chroni dane i dostępność usług, podczas gdy w sieciach OT ryzyka dotyczą zdrowia i życia personelu zakładu, jakości procesu wpływającego na jakość produktu, a więc często w konsekwencji na zdrowie i życie klientów;
  • Ruch sieciowy: w IT bywa chaotyczny; w OT jest stabilny i przewidywalny – w konsekwencji umożliwia detekcję anomalii (analiza statystyczna/ML);
  • Utrzymanie i przerwy: w IT okna serwisowe są planowane; w OT bywają rzadkie lub trudne do wynegocjowania;
  • Patching: IT wymaga aktualizacji; w OT często pracują stare systemy, bez możliwości patchowania (również przez zależności procesowe);
  • Środki ochrony: w IT reagujemy aktywnie (blokady, automaty), w OT stosujemy głównie monitoring pasywny i działania proceduralne;
  • Wydajność: w IT wymagana jest duża przepustowość, ale akceptowane są pewne opóźnienia; w OT przepustowość może być niższa, ale brak akceptacji dla opóźnień (praca w czasie rzeczywistym);
  • Utrzymanie: w IT można łatwo zmienić dostawcę usług utrzymania infrastruktury; w OT jest to trudne, często dostawca ma monopol, ograniczając dostęp do infrastruktury;
  • Właściciel tematu: utrzymanie i rozwój IT zazwyczaj są w gestii CFO (jako biznesowego właściciela systemu ERP) oraz CIO, automatyka przemysłowa to zwykle domena COO;
  • Żywotność: w IT okres eksploatacji infrastruktury to zwykle 3-5 lat; w OT – 10, a nawet 15 lat. Co ciekawe, w wielu zakładach nadal buduje się nowe segmenty OT w oparciu o bardzo stare, ale sprawdzone standardy sieci i protokoły.

Nie czekaj na ustawę

Regulacje unijne, krajowe czy branżowe (NIS2, KSC, normy ISO 27001/22301, TISAX) zwiększą presję na realizację projektu zarządzania ryzykami oraz reagowania na incydenty w środowisku OT. Z perspektywy doświadczeń praktycznych możemy powiedzieć, że największe, często trudne do oszacowania potencjalne opóźnienia mogą wyniknąć z barier formalnych i kontraktowych (np. monopol serwisowy utrzymania, brak zgody dostawcy na dodatkowy monitoring) oraz technicznych (oryginalna architektura sieci OT uniemożliwia monitoring).

Oczekiwanie na wejście w życie kolejnych regulacji przy jednoczesnym braku planowania działań dostosowawczych jest nieracjonalne także ze względu na to, że część z nich wymaga długiego czasu na wykonanie zmian. Warto już wcześniej zabrać się za usuwanie przeszkód i wykonanie tych dostosowań, które i tak będą konieczne, a często okazują się nie generować znaczących kosztów. Warto zaznaczyć, że niezależnie od szczegółów nowej polskiej ustawy o KSC można założyć, iż fundamenty zobowiązań nakładanych na nową grupę przedsiębiorstw były już obecne w dotychczas obowiązujących inne branże przepisach: konieczność wykonania inwentaryzacji zasobów, analizy podatności i ryzyk, przygotowanie planu reagowania na incydenty.

Praktyczne doświadczenia z podobnych projektów pozwalają sformułować wnioski i zalecenia.

Wnioski organizacyjne

  • Uzyskaj sponsoring na poziomie dyrektorów zakładu/produkcji, zarządu przedsiębiorstwa (z uwzględnieniem tego, kto czuje się właścicielem konkretnej grupy ryzyk);
  • Renegocjuj umowy utrzymaniowe: wymagaj prawa dostępu do infrastruktury, wykonywania kopii ruchu, użycia sond sieciowych;
  • Przygotuj się na obsługę incydentów. Rozdziel odpowiedzialność: ciągłość działania po stronie automatyków, cyberzagrożenia – zespół IT/bezpieczeństwa lub wsparcie zewnętrzne (outtasking np. dla analiz typu forensics).

Najczęstsze przeszkody na starcie

Na etapie przygotowań do projektu zabezpieczenia automatyki przemysłowej zwykle napotykamy na podobne przeszkody, niezależnie od branż czy wielkości firm. Najważniejsze z nich to:

  • Niezarządzalne switche bez wolnych portów – brak możliwości wykonania kopii ruchu czy raportowania zawartości MIB, netflow;
  • Brak dokumentacji lub nieaktualna dokumentacja topologii i modyfikacji protokołów;
  • Ograniczenia kontraktowe dostawców automatyki i usługi jej utrzymania (np. brak możliwości realizacji projektu przez firmy trzecie);
  • Niechęć do ingerencji – obawa wśród automatyków, że monitoring zakłóci produkcję (stąd wymóg pełnej pasywności i galwanicznej separacji środków monitoringu).

Przykład z projektu: dokumentacja od OT nie odzwierciedla rzeczywistej architektury sieci, urządzeń w niej obecnych – urządzeń w kopii ruchu (pcap) widać więcej niż „na papierze”. Wniosek: zawsze weryfikuj dokumentację poprzez wykonanie analizy ruchu sieciowego.

Metodyka projektu OT security/continuity

Na podstawie naszych doświadczeń przygotowaliśmy metodykę prowadzenia tego typu projektów, w której na etapie budowania fundamentów przyszłej zgodności z nowymi przepisami można wydzielić następujące kroki.

Krok 1. Inwentaryzacja zasobów (platformy IT i elementy sieci: sterowniki PLC, falowniki, panele operatorskie, czujniki, aplikacje serwerowe, urządzenia diagnostyczne i monitorujące), wykonywana na podstawie zapisu ruchu (PCAP/flow).

Krok 2. Identyfikacja podatności i ograniczeń (bez skanerów). Korzystaj z dokumentacji producentów i wiedzy domenowej. Rzadziej (a najlepiej w warunkach laboratoryjnych) aktywne skanowanie podatności.

Krok 3. Mapowanie infrastruktury na procesy i ocena poziomu ich krytyczności – niezbędne do oceny ryzyka.

Krok 4. Analiza ryzyka, plan reagowania na incydenty (wraz z wyborem incydentów, które chcemy wykrywać). To determinuje dobór narzędzi (czasem wystarczy open-source; do wykrywania anomalii w protokołach OT potrzebne sondy rozumiejące te protokoły).

Krok 5. Projekt architektury monitorowania i jej wdrożenie (wybór metod monitorowania w konsekwencji wyboru incydentów).

Krok 6. Obsługa incydentów. Wdrożenie podstawowego monitoringu infrastruktury wraz z planem reagowania na incydenty. Ustalenie adresatów incydentów do obsłużenia: alerty ciągłości działania (OT), incydenty cybersecurity (IT/SOC/zewnętrzny partner).

Krok 7. Edukacja. Wgląd w infrastrukturę i incydenty pozwala zespołom budować nowe wymagania, poszerzać zakres monitorowania, przygotować firmę na nowe przepisy, ale też szukać korzyści w innych obszarach – np. predictive maintenance.

Od prostych sygnałów po anomalie rejestrów

Wcześniej pisaliśmy, że wdrożenie monitoringu infrastruktury OT często nie wymaga dużych budżetów. Dobrym tego przykładem jest związek pomiędzy poszukiwanym incydentem a metodą wykrycia zdarzeń.

Do wykrywania prostych zdarzeń typu:

  • pojawiło się nowe urządzenie w segmencie OT,
  • zainicjowano nową niespotykaną wcześniej sesję pomiędzy endpointami,
  • zanik ruchu pomiędzy urządzeniami,

często wystarczą kolektory netflow na bazie rozwiązań open source.

Złożone zdarzenia, takie jak:

  • anomalie w protokołach przemysłowych (np. niestandardowe polecenia, nietypowa częstotliwość),
  • zmiany w rejestrach PLC (wykryte poprzez pasywny monitoring – w kopii ruchu),
  • profile ruchu odbiegające od „stabilnego” baseline’u,

wymagają zastosowania bardziej zaawansowanych narzędzi (typu komercyjna sonda OT z mechanizmami uczenia maszynowego).

Już w trakcie realizacji pierwszego kroku wymienionego powyżej, czyli inwentaryzując urządzenia i zaglądając do kopii ruchu, można odkryć błędy architektoniczne, których analiza skutkuje rekomendacją wykonania niezwłocznej zmiany.

Przykład z projektu: w segmencie OT wykryto rejestrator CCTV zestawiający zaszyfrowaną sesję do Chin. Rekomendacja: korekta reguł na firewallu (blokada niepożądanych połączeń wychodzących).

Technologie: co działa w OT i dlaczego

  • Kolektory netflow: najprostsza i najtańsza w realizacji metoda ciągłej inwentaryzacji sieci i wykrywania incydentów (np. nieznane urządzenie, nieznana sesja, zanik ruchu sieciowego itp.);
  • System nadzoru: często również oparty na open source monitoring zawartości rejestrów MIB oraz kolektor trapów SNMP; możliwość wykrywania awarii infrastruktury, a także bardziej szczegółowej inwentaryzacji (LLDP czy SNMP daje np. możliwość rejestrowania wersji oprogramowania urządzeń);
  • Pasywne sondy/IDS dla OT. Monitoring przy zachowaniu galwanicznej separacji od monitorowanej sieci; obsługa starych interfejsów fizycznych, modyfikowanych protokołów; możliwość śledzenia stanów rejestrów;
  • Nagrywarka ruchu sieciowego: tu również można zastosować open source. Umożliwia bardzo szczegółową inwentaryzację sieci i ruchu, a także możliwość analizy postzdarzeniowej z kopią ruchu. Nagrywanie sesji RDP i SSH umożliwia śledzenie działalności administratorów;
  • Firewalle, separacja, DMZ. Analiza kopii ruchu sieciowego często kończy się rekomendacją zmiany konfiguracji firewalli;
  • Switche: zarządzalne switche umożliwiają wykonywanie kopii ruchu, kolekcjonują dane w rejestrach MIB, przesyłają raporty netlow itp. Wymiana starych switchy na zarządzalne to jedna z najbardziej efektywnych kosztowo inwestycji w ramach realizacji projektów monitoringu sieci OT.

Praktyka projektowa podpowiada, że decyzję, jakie środki z listy przedstawionej powyżej wdrożyć, najlepiej poprzedzić analizą ruchu sieciowego, inwentaryzacją infrastruktury i wyborem incydentów, które chcemy wykrywać. To pomaga znacznie zmniejszyć koszty inwestycji poprzez unikanie wydawania pieniędzy na środki techniczne, które nie będą właściwie wykorzystane.

Monitoruj i reaguj

Warto zwrócić uwagę na to, że te same rozwiązania techniczne, które służą nam do wykrywania incydentów cyberbezpieczeństwa w sieciach OT, używane są w procesie zarządzania ciągłością działania: identyfikujemy zdarzenia poprzedzone błędem ludzkim lub awarią. Projekt monitoringu automatyki przemysłowej warto więc uzasadniać nie tylko koniecznością zapewnienia zgodności z przepisami, a samo usuwanie przeszkód technicznych i formalnych, mimo że czasami czasochłonne, nie niesie ze sobą dużych wydatków inwestycyjnych.

Dobrze przygotowana inwentaryzacja pozwoli obniżyć koszty. Wybór rodzaju incydentów, którymi chcemy zarządzać, determinuje wybór narzędzi. Pasywny monitoring nie stwarza ryzyk dla infrastruktury automatyki przemysłowej. Warto też pamiętać, że wykrytymi incydentami należy zarządzać, a więc konieczne jest opracowanie strategii reagowania na zdarzenia.

Dobre praktyki cyberbezpieczeństwa w OT

  • Nie skanuj aktywnie sieci OT narzędziami IT, używaj środków pasywnych
  • Zaczynaj od danych: PCAP, netflow, zawartość MIB
  • Rewiduj kontrakty utrzymaniowe (zgoda na dostęp do kopii ruchu)
  • Zacznij budowę planu reagowania przed inwestycją – oszczędzisz na inwestycji i przygotujesz zespół na dodatkowe obowiązki
  • Buduj kompetencje obustronnie: IT uczy się ograniczeń OT; OT poznaje narzędzia detekcji i ich wartość w praktyce utrzymania
Napisz do nas Zadzwoń Wyślij email






    Informacje na temat przetwarzania danych osobowych znajdują się w Polityce Prywatności. Wysłanie wiadomości jest równoznaczne z zapoznaniem się z polityką prywatności All for One Poland Sp. z o. o.

    61 827 70 00

    Biuro jest czynne
    od poniedziałku do piątku
    w godz. 8:00 – 16:00 (CET)

    Kontakt ogólny do firmy
    office.pl@all-for-one.com

    Pytania o produkty i usługi
    info.pl@all-for-one.com

    Pytania na temat pracy i staży
    kariera@all-for-one.com

    This site is registered on wpml.org as a development site. Switch to a production site key to remove this banner.