Technologie

Bezpieczeństwo systemu SCADA – gdzie się zaczyna?

W latach 60-tych zaczęto stosować w automatyce układy regulacji wspierane przez nowoczesne teorie sterowania oraz zaprzęgnięto do tego techniki komputerowe. Przez dziesiątki lat światy automatyki (OT) oraz informatyki (IT) istniały równolegle, z tendencją przenoszenia rozwiązań informatycznych do automatyki. Świat IT od początku swego istnienia broni się przez różnego rodzaju atakami, awariami systemów czy sprzętu. W świecie automatyki, ze względu na izolację tych systemów od świata zewnętrznego – takiej potrzeby nie było. Ochrona systemów automatyki ograniczała się przede wszystkim do zapewnienia bezpiecznych fizycznych warunków eksploatacji oraz redundancji krytycznych elementów systemu. Nie stosowano mechanizmów uwierzytelniania, autoryzacji, szyfrowania itd., bo nie było takiej potrzeby.

Rys. 1. System SCADA w podziale na poziomy

Integracja systemów IT rozpoczęła się w latach osiemdziesiątych, w świecie OT ten etap przypada na ostatnie dziesięciolecie. Bezpieczeństwem systemów IT (po epoce wirusów przenoszonych na dyskietkach) na poważnie zajęto się w drugiej połowie lat dziewięćdziesiątych. Bezpieczeństwo OT to gorący temat ostatnich lat. Mamy zatem do czynienia z ok. 15-letnim opóźnieniem w zastosowaniu mechanizmów ochrony.

Czy świat OT może być dalej tak opóźniony? W procesie integracji systemów OT zostały wykorzystane istotne składowe systemów IT, wnosząc do świata OT wraz z wszystkimi dobrodziejstwami, również wszystkie zagrożenia np. zagrożenia sieciowe czy podatności systemów operacyjnych.

Co to znaczy bezpieczna SCADA?

Ochrona systemu SCADA, ze względu na jego złożoną architekturę wymaga podejścia wielowarstwowego. Przełamanie jednej warstwy nie powinno przekładać się na kontrolowany proces.

Rozwiązania stosowane do separacji sieci SCADA nie gwarantują takiego poziomu bezpieczeństwa, aby mechanizmy bezpieczeństwa na poziomie automatyki można było odłożyć na półkę. Dlatego praktycznie bezbronne dotąd sterowniki muszą umieć obronić się same. Przed czym? Ponieważ są to komputery, to przed wszystkimi zagrożeniami, jakie mogą spotkać właśnie komputery.

Podstawą w projektowaniu bezpieczeństwa komputerów jest ich architektura. Na tym etapie, w urządzeniach produkowanych przez Mikronikę, przewidziane zostały takie kwestie jak podział części funkcjonalnej sterownika od część administracyjnej, ale też zarządzanie użytkownikami, uprawnieniami, zabezpieczenie komunikacji, monitorowanie pracy urządzenia i inne mechanizmy, o których jeszcze powiemy w dalszej części.

Po co się narażać?

To pytanie retoryczne, ale przekłada się na bardzo konkretne działania. Otóż w każdym urządzeniu zainstalowane powinny być te i tylko te komponenty, które są potrzebne. Ponieważ w sterownikach RTU najczęściej wykorzystuje się systemy klasy UNIX, trzeba z nich usunąć wszystkie zbędne elementy, które powodują niepotrzebne zagrożenia związane np. z podatnościami bezpieczeństwa, które mogą zostać ujawnione w przyszłości. Cały ten proces nazywa się hardeningiem systemu.

Komunikacja

Rozpatrując aspekt zabezpieczenia komunikacji na linii RTU – SCADA trzeba wziąć pod uwagę wszystkie trzy atrybuty bezpieczeństwa informacji zdefiniowane w standardzie ISO 27001. Poufność, która w ochronie tajemnicy jest najbardziej istotna, w systemach SCADA wydaje się mieć mniejsze znaczenie od dostępności i integralności, ponieważ ujawnienie treści komunikacji ma zwykle mniej poważne skutki niż zmiana treści komunikatów lub zatrzymanie transmisji. Dla zabezpieczenia integralności i poufności komunikacji wykorzystywane są mechanizmy szyfrujące oparte o infrastrukturę klucza publicznego (PKI). Komunikacja jest zabezpieczana zgodnie z taktyką „defence in depth”. Kanał zabezpieczony jednym mechanizmem może być wewnątrz zabezpieczany kolejnym. Ilustrację tej taktyki można zobaczyć na rysunku.

Rys 2. Wielowarstwowa struktura bezpieczeństwa (Defence in Depth)

Warto dodać, że dobór protokołów, algorytmów i długości kluczy oparty został o rekomendacje ENISA, która na podstawie badań wzrostu mocy obliczeniowych i siły algorytmów przewiduje czas, w którym mogą one przestać być bezpieczne. W ramach PKI zaimplementowane zostały również wszystkie mechanizmy dotyczące weryfikacji statusu certyfikatów w oparciu o OCSP.

Gdzie to schować?

Urządzenia obsługujące obiekty lokalizowane w terenie narażone są na kradzież czy manipulację przez niepowołane osoby. Dlatego trzeba zadbać o to, aby wrażliwe dane przechowywane w urządzeniu były bezpieczne nawet w sytuacji ewentualnej kradzieży.

Dlatego, do przechowywania wrażliwych danych (klucze, certyfikaty, dane konfiguracyjne), sterownik zastał wyposażony w specjalną partycję, która nie tylko jest szyfrowana, ale dostęp do zapisanych na niej informacji wymaga spełnienia określonych procedur bezpieczeństwa.

Kto i co może?

Na zawsze żegnamy czasy, w których jeden użytkownik z uprawnieniami administratora jest używany do wszystkiego i wszystkie procesy są uruchamiane w jego kontekście. Podział użytkowników wynika ściśle z zadań jakie są do nich przypisane. Inne uprawnienia ma operator, inne obserwator, inne inżynier automatyki odpowiedzialny za konfigurację, a jeszcze inne administrator logów. Takie podejście nazywane jest Role Based Access Control i zalecane jest przez standard IEC 62351-8.

Zastanówmy się jednak nad jeszcze jedną kwestią – jak zarządzać użytkownikami, hasłami, uprawnieniami w sytuacji, gdy mamy w sieci kilkaset lub kilka tysięcy urządzeń. Jak obsłużyć przypadek, gdy pracownik mający dostęp do tych urządzeń odchodzi z pracy lub ujawnione zostało jego hasło. Aby rozwiązać ten problem zaimplementowane zostały mechanizmy centralnego uwierzytelniania oparte o serwer RADIUS lub TACACS.

Ślad w systemie

Logowanie zdarzeń w systemie umożliwia nie tylko analizę powłamaniową czy po wystąpieniu awarii. Sterownik ma też możliwość eksportu logów w protokole syslog, na zewnętrzny serwer gdzie te dane mogą być poddawane dalszej obróbce. Jeśli chodzi o rejestrowane zdarzenia, to oprócz działań użytkowników, logowane mogą być zmiana wartości lub stanów, zmiana konfiguracji, zmiana daty i czasu, wykonane sterowanie, alarmy – czyli praktycznie wszystkie zdarzenia jakie mogą wystąpić na sterowniku.Kto jest kto?

W sieci urządzenia które nawiązują komunikację muszą mieć pewność, że rozmawiają z innym uprawnionym urządzeniem. Takie sytuacje występują w przypadku wysyłania pomiarów, wymiany komunikatów sterujących, ale też rekonfiguracji sterownika czy wymiany firmware. Dlatego każdy sterownik opuszczający mury Mikroniki posiada wgrany w bezpieczne miejsce klucz publiczny Mikroniki, serwerów, z którymi wymienia dane oraz własne klucze prywatne. To pozwala na jednoznaczną identyfikację stron uczestniczących w komunikacji, ale zapewnia również szyfrowanie komunikacji oraz jej niezaprzeczalność. Oczywiście dla celów bezpiecznej wymiany danych każdy klient może wgrać swoje klucze.

Wdrożenie i eksploatacja

Tak przygotowany bezpieczny sterownik trafia do klienta. Konfiguracja wdrożeniowa przebiega w dwóch podstawowych płaszczyznach – interfejsu sieciowego oraz logiki pracy urządzenia.

Ze względu na specyfikę pracy służb technicznych oraz rozległość geograficzną obiektów, sterownik może współpracować z serwerem konfiguracji. Serwer konfiguracji doskonale sprawdza się jeżeli musimy zarządzać więcej niż kilkoma urządzeniami. Serwer konfiguracji pozwala na dwie podstawowe rzeczy – inicjowanie sterownika – tzw. bootstrap oraz zarządzanie konfiguracją. Pierwsza z tych funkcji pozwala przygotować konfigurację sterownika bez fizycznego dysponowania urządzeniem. Druga funkcja serwera DM pozwala na zdalne równoległe zarządzanie konfiguracją i firmware urządzeń RTU. Dzięki temu możemy zaplanować aktualizację na określony czas – najbardziej dogodny z punktu widzenia prowadzenia ruchu i wykonać równoległą aktualizację na dowolnej liczbie urządzeń.

Aktualizacje firmware

Jedną z istotnych właściwości nowych sterowników jest możliwość szybkiego ale przy tym bezpiecznego wprowadzenia aktualizacji oprogramowania. Dotychczas firmware sterownika wymieniany był maksymalnie kilka razy w całym cyklu jego życia, a często taka operacja nie była wykonywana wcale. Jeżeli jednak sterownik ma umieć się obronić przed cyberzagrożeniami, to nie można go pozostawić z oprogramowaniem posiadającym ujawnione słabości. Dlatego w Mikronice pracuje specjalny zespół, który stale monitoruje bezpieczeństwo produkowanych urządzeń. Każda słabość, która zostanie zakwalifikowana jako krytyczna, uruchamia proces komunikacji z klientem oraz równolegle przygotowaniem poprawki bezpieczeństwa.

Każdy pakiet oprogramowania jest podpisywany kluczem Mikroniki. W ten sposób serwer DM ma pewność, że pakiet jest kompletny, niezmieniony i pochodzi z zaufanego źródła. Każda próba ingerencji w pakiet spowoduje jego odrzucenie. Także sterownik jest w stanie wykryć każdą próbę ingerencji w taki pakiet i go odrzucić. Użycie PKI wyklucza również wczytanie do sterownika, konfiguracji przeznaczonej dla innego sterownika, co dotychczas niejednokrotnie powodowało problemy a nawet awarie.

Podsumowanie

Zapewnienie bezpieczeństwa i ciągłości funkcjonowania procesów sterowanych urządzeniami automatyki stanowi krytyczny element dla funkcjonowania wielu przedsiębiorstw. W tym zakresie, na operatorach infrastruktury ciąży ogromna odpowiedzialność za ewentualne skutki błędów i uchybień, które mogą tą ciągłość zakłócić.

Dlatego system automatyki, od którego zależy bezpieczeństwo i ciągłość procesów, musi być bezpieczny w każdym swoim punkcie. Sterownik opisywany w tym artykule przeszedł szereg audytów i testów bezpieczeństwa przeprowadzonych m.in. przez firmy takie jak Blue Energy, ENCS czy Applied Risk.

Autor artykułu: Tomasz Szała, Ekspert ds. bezpieczeństwa w Mikronice

Click to comment

Leave a Reply

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

To Top