Współczesny przemysł opiera się na systemach komputerowych. Ten fakt jest niezaprzeczalny. Mnogość takich stanowisk w przeciętnym zakładzie przemysłowym jest ogromna choćby ze względu na „końcówki” systemu SCADA. I właśnie systemy nadzoru i kontroli nad procesem technologicznym stanowią ogromne wyzwanie w procesie wdrażania cyberbezpieczeństwa w sieciach OT.
Przemysłowe stacje komputerowe to cel dla potencjalnych atakujących, ponieważ zawierają informacje na temat całego procesu oraz ze względu na swoją charakterystykę, mogą komunikować się z największą liczbą podsieci. Zatem poza informacjami procesowymi stacja ta może stanowić platformę do rozsiania ataku po całej infrastrukturze, tak jak to było np. w przypadku ataku BlackEnergy. W tym wypadku z poziomu paneli stacji operatorskich hakerzy uzyskali dostęp do urządzeń sieciowych w infrastrukturze OT. To, w wielkim skrócie, doprowadziło do otworzenia wyłączników i przerwy w dostawie prądu.
Jak można zabezpieczyć się przed takimi atakami?
Pierwszą myślą jest oczywiście oprogramowanie antywirusowe. Jednak w przypadku klasycznych systemów EDR (Endpoint Detection and Response) istnieje obawa, że ich bieżąca praca zakłóci działanie aplikacji procesowych. Co więcej – jest to obawa uzasadniona. Jeżeli spojrzymy na zasoby wymagane przez takie oprogramowanie może się okazać, że bieżące skanowanie pracy aplikacji procesowej w czasie rzeczywistym pochłonie zasoby (np. CPU lub RAM) przeznaczone do realizacji zadań priorytetowych.
Czy zatem rozwiązania agentowe skazane są na porażkę w środowisku produkcyjnym?
Otóż nie. Pod warunkiem, że wykorzystywać będziemy rozwiązania dostosowane do pracy w takim środowisku.
Poszukując zatem rozwiązania agentowego możemy posłużyć się listą pytań, które są dość pomocne w doborze rozwiązania:
- Czy jego bieżąca praca będzie wpływała na proces?
- Jak wygląda alokacja zasobów?
- Czy ochrona antywirusowa musi być włączona w trybie ciągłym czy możemy ją zaplanować?
- Czy istnieje możliwość tworzenia wykluczeń od skanowania?
- Jakie systemy operacyjne są wspierane?
- Czy wszystkie systemy, które posiadam w stacjach po stronie OT są obsługiwane?
- Czy agent wymaga stałego dostępu do Internetu by aktualizować sygnatury bezpieczeństwa?
- Czy prace aktualizacyjne wymagają restartu stacji?
- W jaki sposób zarządzamy politykami bezpieczeństwa i przeprowadzamy aktualizację oprogramowania oraz sygnatur?
- Czy agent może pracować jako SA czy wymaga komunikacji z konsolą?
- Jak odbywa się komunikacja z konsolą – kto inicjuje kontakt i w jaki sposób?
- Czy agent zapewnia inne rodzaje ochrony aniżeli ochrona antywirusowa?
Przejdźmy zatem przez główne założenia tej listy. Jest ułożona tak, by sukcesywnie odhaczać kluczowe dla ochrony stacji OT punkty.
Ciągłość procesu
Z perspektywy automatyki to punkt najważniejszy. Musimy pamiętać, że agent instalowany będzie na maszynie, która przeznaczona jest do pracy w trybie ciągłym i jest to maszyna zadaniowa. Warto więc zweryfikować z dostawcą oprogramowania, jakie są minimalne wymagania i w jaki sposób praca agenta wpływa na bieżącą pracę systemów.
Należy wiedzieć jak mocno obciąża ona CPU i jaka jest maksymalna alokacja pamięci RAM przy uruchomionych wszystkich usługach ochrony. To szczególnie ważne zwłaszcza przy starszych stacjach, które nie są już najwydajniejsze i mogą mieć problem z obsługą skomplikowanych procesów.
Warto upewnić się, że producent oprogramowania przewidział współpracę z takimi maszynami i wspiera starsze systemy operacyjne. Zwłaszcza te już niewspierane jak choćby Windows XP czy 7, które w dalszym ciągu są bardzo popularne w środowisku przemysłowym.
Dotyczy to również systemów takich jak Windows 10, którego wsparcie również niedługo się zakończy, a który nadal będzie używany w środowisku produkcyjnym.
Ochrona antywirusowa
Mówiąc o zabezpieczeniu stacji komputerowych od razu przychodzi nam na myśl ochrona antywirusowa. Proces ten jest jednak tym najbardziej obciążającym system. W związku z tym do rozważenia mamy dwa scenariusze:
- możliwość cyklicznego skanowania systemu z wyłączoną ochroną Real-Time,
- tworzenie wykluczeń od skanowania (np. dla dedykowanej zaufanej aplikacji np. SCADA).
Naturalnie opcja Real-Time to najwyższy poziom ochrony, musimy jednak pamiętać o tym, że stacja może być znacznie mniej wydajna i taka praca będzie dla niej dużym obciążeniem. Jeżeli ochrona Real-Time nie wchodzi w grę, należy sprawdzić jakie inne systemy ochronne zapewnia nam aplikacja i co dodatkowo możemy uruchomić.
Aktualizacje
Środowisko OT powinno być całkowicie odizolowane od dostępu do Internetu a aktualizacje sygnatur agenta możliwe do przeprowadzenia bez podłączenia do sieci. Dlatego dobierając rozwiązanie agentowe zweryfikujmy z naszym dostawcą, w jaki sposób przeprowadzane są wspomniane aktualizacje sygnatur oraz patchowanie samego agenta. Powinniśmy mieć możliwość stworzenia całkowicie odizolowanego środowiska, które wszelkie aktualizacje pobiera np. z serwera plików w strefie DMZ. Inny sposób to możliwość pracy w trybie standalone i manualne wgrywanie plików aktualizacji.
W tym miejscu warto również poruszyć kwestie samej instalacji. Ze względu na charakterystykę pracy maszyny warto zwrócić uwagę, aby przeprowadzane przez nas aktualizacje nie wymagały restartów urządzenia.
Przypominam – ciągłość procesu jest tu czynnikiem nadrzędnym.
Zarządzanie agentami
W średniej wielkości przedsiębiorstwie dysponować będziemy 40-60 stacjami komputerowymi. Manualne zarządzanie nimi jest możliwe, jednak najczęściej wymaga stworzenia dodatkowego etatu wyłącznie do obsługi skanowań (jeżeli wykonywane by były z wykorzystaniem zewnętrznego nośnika). Z pomocą przyjdzie tu zatem centralizacja.
Warto zwrócić uwagę w jaki sposób możemy zarządzać agentami. Ważne jest to, czy producent dostarcza konsolę centralną. Jeśli tak -czy ma ona możliwość gradacji uprawnień i tworzenia indywidualnych polityk dla poszczególnych lokalizacji lub nawet maszyn. W przypadku zakładów rozporoszonych może to być szczególnie użyteczne, ponieważ zyskujemy możliwość centralizacji części polityk bezpieczeństwa oraz nadania uprawnień poszczególnym lokalnym administratorom.
Tutaj jednak pojawiają się dwa pytania, na które warto zwrócić uwagę:
- Czy konsola zarządzająca musi mieć dostęp do Internetu by pobrać aktualizacje dla agentów?
- W jaki sposób konsola komunikuje się z agentami?
Powinniśmy mieć możliwość stworzenia środowiska całkowicie odizolowanego, który aktualizacje pobiera np. z serwera plików w przygotowanej do tego strefie DMZ.
Jeżeli zaś chodzi o drugi aspekt, to tutaj nie ma jednoznacznej odpowiedzi. Dobre praktyki mówią, że strefa o mniejszym poziomie zaufania nigdy nie inicjuje komunikacji. W związku z tym komunikacja powinna pochodzić ze strony agenta do konsoli, czyli klasyczna komunikacja klient-serwer. Niemniej jednak, powinno to być również zgodne z naszymi wewnętrznymi politykami. Może pojawić się podatność, którą chcemy szybko załatać i puścić natychmiastowy deploy do wszystkich agentów. Wówczas komunikacja serwer-klient będzie bardzo użyteczna. Nie możemy zatem całkowicie zamykać się na ten typ komunikacji. Warto jednak zwrócić uwagę dostawcy, by wyjaśnił, jak wygląda komunikacja ze strony serwera i czy jest ona konieczna do poprawnej pracy systemu.
Co do zasady, powinniśmy mieć możliwość stworzenia elastycznego środowiska, które w zależności od poziomu krytyczności odpowiednio dostosujemy pod nasze procedury cyberbezpieczeństwa. W tym wypadku część agentów będzie usieciowiona, zarządzana centralnie, a częścią pracująca stand alone. Oczywiście, przy założeniu, że nasze wewnętrzne procedury nie pozwalają na włączenie do sieci danej stacji np. ze względu na zainstalowany na niej Windows XP.
Ochrona, ale nie tylko antywirusowa
Wróćmy na chwilę do ataku BlackEnergy, który był spreparowanym malware’em na potrzeby ataku na Ukraińską Infrastrukturę Energetyczną. W jaki sposób mogliśmy się zabezpieczyć, aby malware nie wykonał się na Stacji Operatorskiej?
Otóż, jeżeli malware nie był wcześniej znany i opisany sygnaturą, to antywirus niewiele by nam pomógł. Pomocne jednak będą inne rozwiązanie jak np. tzw. whitelista dopuszczonych aplikacji oraz natywna ochrona aplikacji OT.
W przypadku ataku BlackEnergy gdyby atakujący, tak jak to miało miejsce, pokonałby wszystkie pozostałe zabezpieczenia i zdołał wgrać na nią wykonywalny plik malware, to plik ten nie zostałby uruchomiony, ze względu na jego brak na whiteliście. Jest ona bardzo wygodnym i nieobciążającym narzędziem. Nawet w przypadku przedostania się do stacji podejrzanego pliku, uniemożliwia mu wykonania nieautoryzowanych działań.
Wato również zwrócić uwagę czy dostawca oprogramowania natywnie wspiera ochronę wiodących aplikacji automatyki przed usunięciem lub podmianą plików wykonywalnych np. WinCC. Jest to o tyle użyteczne, że z automatu wiemy, że pliki naszego systemu SCADA są chronione i możemy skupić się na innych kwestiach.
Funkcje, o których tutaj mowa dają nam również możliwość balansowania ochroną antywirusową korzystając z niej np. zgodnie z harmonogramem lub tworząc wyjątki. Takim wyjątkiem będzie np. pominięcie procesów realizowanych przez system SCADA, którego pliki wykonywalne nie mogą ulec zmianie ze względu na ich dwupłaszczyznową ochronę opisanymi wcześniej systemami).
W przypadku tych dodatkowych funkcjonalności rodzi się pytanie: czy producent przewidział tryb, w którym mamy możliwość aktualizacji białej listy w sposób bezpieczny, bo np. będziemy podnosili wersję SCADA do najnowszej wersji?
To kolejny element, który warto zweryfikować z naszym dostawcą i ustalić, jak jest on adresowany w przypadku oferowanego oprogramowania.
Podsumowując: nie taki agent straszny jak go malują
Całkowicie rozumiem obawy stosowania rozwiązań agentowych w środowisku produkcyjnym. Ich wpływ na systemy może być dyskusyjny i implementacja takiego rozwiązania wymaga wcześniejszej analizy zespołów IT/OT Security oraz Utrzymania Ruchu.
Niemniej, istnieją rozwiązania specjalnie zaprojektowane do pracy z systemami OT jak np. Stellar Protect od TXOne Networks. To lekkie rozwiązanie, które stanowi tło dla pracy kluczowych aplikacji i jedynie je wspomaga w bieżącej pracy. Maksymalizować bezpieczeństwo a minimalizując wpływ na pracę.
Tak jak jednak wcześniej wspomniałem implementacja takiego oprogramowania wymaga jednak odpowiedniego, wcześniejszego przygotowania. Cyberbezpieczeństwo w OT rządzi się nieco innymi prawami i wymaga pewnej elastyczności w podejściu, którego w klasycznym IT Security nie uświadczymy. Nie zmienia to jednego.
W związku z nadchodzącą nowelizacją przepisów Ustawy o Krajowym Systemie Cyberbezpieczeństwa, pewne kroki podjąć będziemy musieli, jeżeli chodzi o systemy informatyczne po stronie OT i wdrożenie EDR może być jednym z istotnych elementów ochrony przydatnych do spełnienia warunków legislacyjnych ustawy.
Mam świadomość, że temat bezpieczeństwa na styku OT i IT jest trudny i zawiera wiele niuansów. W razie jakichkolwiek pytań, chętnie pomogę.
Michał Łęcki
Menadżer ds Cyberbezpieczenstwa OT
Elmark Automatyka S.A.
601-868-636
michal.lecki@elmark.com.pl