Gdzie zaczyna się bezpieczeństwo systemu SCADA?

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 to konieczne.

Integracja systemów IT rozpoczęła się w latach 80. zeszłego wieku, zaś 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 około 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 przemysłu wraz ze wszystkimi dobrodziejstwami również zagrożenia – np. sieciowe czy też związane z 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, 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 rozdział 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ścią na zagrożenia, które mogą zostać ujawnione w przyszłości. Cały ten proces nazywa się hardeningiem systemu.

KOMUNIKACJA

 

Rys. 2 - Wielowarstwowa struktura bezpieczeństwa (defence in depth)

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. Do zabezpieczenia integralności i poufności komunikacji wykorzystywane są mechanizmy szyfrujące oparte na infrastrukturze klucza publicznego (PKI). Komunikacja jest zabezpieczana zgodnie z taktyką "defence in depth". Kanał zabezpieczony jednym mechanizmem może być wewnątrz zabezpieczany kolejnym (patrz rysunek 2).

Warto dodać, że dobór protokołów, algorytmów i długości kluczy oparty został na rekomendacjach 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 na 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.

Z tych powodów 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 na serwerze 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 KIM?

Urządzenia, które nawiązują komunikację w sieci, muszą mieć pewność, że „rozmawiają” z innymi uprawnionymi urządzeniami. Takie sytuacje występują w przypadku wysyłania wyników pomiarów, wymiany komunikatów sterujących, ale też rekonfiguracji sterownika czy wymiany firmware’u. Dlatego każdy sterownik opuszczający mury Mikroniki ma wgrany w bezpieczne miejsce klucz publiczny Mikroniki, adresy serwerów, z którymi wymienia dane, oraz własne klucze prywatne. Pozwala to na jednoznaczną identyfikację stron uczestniczących w komunikacji, a także zapewnia szyfrowanie komunikacji oraz gwarantuje 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.

 

Rys. 1 - System SCADA w podziale na poziomy

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’m 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’U

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 mieć możliwość obrony przed cyberzagrożeniami, to nie można go pozostawić z oprogramowaniem mają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.

Tomasz Szała
Ekspert ds. bezpieczeństwa w Mikronice

Mikronika
www.mikronika.pl