5 wskazówek jak zabezpieczyć środowiska SCADA

Wirus Stuxnet uświadomił nagłą potrzebę wdrożenia do środowisk SCADA nowoczesnych technik zabezpieczających, takich jak te stosowane w sieciach dużych przedsiębiorstw.

Środowiska SCADA składają się z systemów sterowania i zarządzania przemysłowego – zazwyczaj na dużą skalę – które monitorują, zarządzają i administrują najważniejszymi infrastrukturami w różnych obszarach takich jak transport, energetyka jądrowa, przesyłanie energii elektrycznej, gazownictwo, wodociągi. W odróżnieniu od konwencjonalnych sieci IT środowisko SCADA zapewnia połączenie sprzęgające pomiędzy własnymi systemami przemysłowymi, takimi jak roboty, zawory, czujniki termiczne lub chemiczne, systemy poleceń i sterowania, a systemami HMI (Human Machine Interface), niekoniecznie PC. Pomimo tego, że SCADA pracuje głównie w dużych przedsiębiorstwach, to cieszy się coraz większym zainteresowaniem w prywatnych gospodarstwach domowych.

Systemy sterowania SCADA wykorzystują do komunikacji pomiędzy swoimi elementami dedykowany zestaw protokołów komunikacyjnych takich jak MODBUS, DNP3 i IEC 60870-5-101. Niniejsze protokoły umożliwiają zarządzanie fizycznymi sterownikami PLC, realizującymi na przykład działania zwiększające szybkość silnika, zmniejszające temperaturę itp. Z tego względu kwestią krytyczną jest spójność komunikatów sterujących SCADA przy sprawdzaniu zgodności protokołów komunikacyjnych ze standardami.

Systemy SCADA zaprojektowane do wieloletniego działania jeszcze w czasach, gdy celem cyberprzestępczości nie był sektor przemysłowy, nie uwzględniały w swoim schemacie bezpieczeństwa sieciowego. Z uwagi na wyizolowany charakter systemów przemysłowych oraz brak połączenia z siecią IP, kwestia ich bezpieczeństwa nie była początkowo uznawana za priorytetową.

Jednakże architektury SCADA ewoluowały i w tym momencie roboty, systemy pomiarowe, narzędzia poleceń i sterowania oraz zdalne systemy konserwacji zostały połączone za pośrednictwem sieci IP. Problemem nie jest samo korzystanie z IP, ale raczej to, że IP jest administrowane przez potencjalnie wrażliwe środowiska, na przykład platformy z interfejsami HMI. Są one zazwyczaj wyposażone w wersje systemu operacyjnego Windows, które nie posiadają łatek. Ponieważ systemy te zostały uznane za bardzo wrażliwe, nie stosuje się w nich łatek systemowych ani aktualizacji, które mogłyby zakłócić ich pracę. Często tego typu obawy przysłaniają prawdziwe zagrożenie związane z potencjalnymi atakami IT. Środowiska SCADA, postrzegane jako krytyczne, są tym samym paradoksalnie mniej bezpieczne i stają się potencjalnym celem cyberprzestępców. Po złamaniu zabezpieczeń haker może mieć pełną kontrolę nad systemem, jak miało to miejsce w przypadku Stuxnet, pierwszego wykrytego robaka szpiegującego i przeprogramowującego systemy przemysłowe. Robak ten wykorzystał słabości Windows Zero Day, dla których nie została jeszcze opracowana łatka i zainfekował dziesiątki tysięcy systemów IT oraz jeden zakład wzbogacania uranu.

Niestety, dopiero udany atak Stuxnet uświadomił ogrom potencjalnych szkód wynikających z cyber-zagrożeń dla sektora przemysłowego. Pomimo tego, że tradycyjne ataki komputerowe nie powodują szkód materialnych, Stuxnet niósł ze sobą zniszczenie i realną możliwość zarażenia robakami i wirusami nie tylko danych firmowych, ale również systemów gospodarki wodnej, produkcji chemikaliów oraz infrastruktur energetycznych.

W wyniku tego firmy z sektora przemysłowego przedsięwzięły kroki związane z integracją bezpieczeństwa swoich systemów. Okazuje się jednak, że jeszcze wiele jest do zrobienia zanim systemy SCADA zostaną uznane za bezpieczne. Po pierwsze, firmy korzystające ze SCADA muszą uznać je za część swojej ogólnej struktury IT, stosować te same środki i techniki bezpieczeństwa, jakie stosowane są w odniesieniu do wewnętrznej infrastruktury IT i uzyskać wsparcie kierownictwa w zakresie dodatkowego budżetu i środków na IT.

Przy braku  obowiązujących standardów firmy przemysłowe powinny stosować właściwe praktyki zalecane przez North American Electric Reliability (NERC) lub organizacje krajowe takie jak Agence Nationale de la Sécurité des Systèmes d’Information (ANSSI) we Francji. Dodatkowo należy podjąć następujące kroki, aby zapewnić bezpieczeństwo środowiska SCADA:

1. Regularne aktualizacje

Regularne stosowanie łatek systemowych w systemach operacyjnych, aplikacjach i komponentach SCADA jest kluczowym czynnikiem, aby uniknąć naruszenia bezpieczeństwa związanego ze słabymi stronami, o których dostawcy rozwiązań bezpieczeństwa już wiedzą.

Ponadto wdrożenie narzędzia do detekcji i analizy słabości, które pozwala na przechwycenie złośliwych zagrożeń internetowych zanim uderzą w sieć lub docelowy serwer, zapewnia proaktywny sposób zapobiegania atakom, unikania zakłóceń podczas pracy i szybką reakcję w czasie rzeczywistym na pojawiające się zagrożenia.

2. Partycjonowanie i izolacja sieci SCADA

Kwestią kluczową jest odizolowanie sieci SCADA od pozostałej sieci firmowej. Stosowanie stref DMZ lub bastionów w tym celu umożliwi segmentację architektury SCADA. Tym samym, sieć HMI zostanie oddzielona od robotów i urządzeń pomiarowych, systemów nadzorczych, jednostek zdalnego sterowania i infrastruktur komunikacyjnych, umożliwiając każdemu środowisku zamknięcie i zabezpieczenie przed atakami.

Krótko mówiąc, sieci SCADA wymagają zabezpieczenia przed programami typu malware i atakami w taki sam sposób jak sieci dużych przedsiębiorstw, stosując rozwiązania Intrusion Prevention Systems (IPS) oraz anti-malware, które odnoszą się nie tylko do SCADA.

3. Weryfikacja protokołu

Po wykonaniu partycjonowania i przeprowadzeniu segregacji różnych elementów architektury SCADA kolejnym logicznym etapem jest zastosowanie weryfikacji i kontroli protokołów dotyczących poszczególnych komponentów. Innymi słowy, konieczne jest skontrolowanie protokołu MODBUS, aby mieć pewność, że nie jest on wadliwie stosowany, czy też nie stał się celem ataku. Ponadto ważne jest, aby aplikacja, która generuje żądania MODBUS, była aplikacją legalną, która wygenerowana została z odpowiedniego stanowiska roboczego. Tym samym rozpoznanie aplikacji ma sens.

4. Rozdzielenie administratorów od użytkowników

Poza rozdzieleniem sieci ważne jest rozdzielenie użytkowników od administratorów i zapewnienie różnych poziomów dostępu dla tych dwóch grup. Na przykład, administrator może mieć pełny dostęp, łącznie ze zmianą konfiguracji za pośrednictwem HMI, podczas gdy użytkownik może mieć dostęp wyłącznie do odczytu.

5. Ogólny widok sieci

Znaczącą kwestią jest potrzeba korelacji i wdrożenia narzędzia do zarządzania zdarzeniami. Ważne jest, aby administrator sieci miał możliwość pełnego zrozumienia stanu bezpieczeństwa całej sieci oraz jednoczesnej kontroli stanu robota, poziomu łatki HMI i jej powiązania z danym użytkownikiem lub komponentem architektury.

Tak samo ważne jest generowanie alarmów bezpieczeństwa. Poprzez monitorowanie i analizę tego, co dzieje się w sieci, administrator uzyskuje możliwość właściwego zareagowania na zdarzenia sieciowe i podjęcia odpowiednich czynności.

Wdrożenie powyższych kroków, pomimo tego, że mogą one być czasami kłopotliwe, zapewnia wyczerpującą strategię bezpieczeństwa w sieci oraz dogłębną obronę z warstwą bezpieczeństwa na wszystkich poziomach, nawet w jednostkach programowalnych sterownikach logicznych PLC, dla precyzyjnego sterowania wymianą i komunikacją pomiędzy środowiskiem SCADA a infrastrukturą sieciową.

Ponieważ ataki stają się coraz bardziej wyrafinowane, na przykład Advanced Persistent Threats (APT), kwestią priorytetową jest budowanie świadomości w środowisku przedsiębiorców przemysłowych, że zintegrowane bezpieczeństwo środowisk SCADA jest kluczowe, aby sieci te mogły dalej funkcjonować w sposób, w jaki zostały zaprojektowane. Administratorzy powinni mieć możliwość kontroli sieci, użytkowników i aplikacji, unikać potencjalnych zagrożeń, wychodząc im naprzeciw. Powinni również wyposażyć się w specjalistyczne narzędzia, których celem jest identyfikacja potencjalnych problemów w czasie rzeczywistym i umożliwienie szybkiej reakcji w momencie, gdy zagrożenie zostanie potwierdzone.

Robert Dąbrowski,
inżynier systemowy,
FORTINET