Bezpieczeństwo SCADA o wymaganiach, ryzyku i świadomych wyborach

Bezpieczeństwo SCADA o wymaganiach, ryzyku i świadomych wyborach Poczucie bezpieczeństwa to jedna z elementarnych potrzeb człowieka. Stanowi fundament warunków egzystencji i rozwoju cywilizacyjnego. Rozwój technologii sterowania szeroko rozumianymi procesami poszedł już tak daleko, że trzeba sobie jasno powiedzieć, że dziś żadna nowoczesna infrastruktura nie jest w stanie na dłuższą metę pracować w trybie awaryjnym (bez wsparcia ze strony systemów sterujących). Dotyczy to w zasadzie wszystkich gałęzi gospodarki od elektrowni zaczynając na paczkomatach kończąc. To uzależnienie daje nam podstawy do dalszego rozwoju cywilizacyjnego. Tak się działo od zawsze. Nowe rozwiązania stanowiły podwalinę pod kolejne. Rewolucja przemysłowa zapoczątkowana w XIX wieku doprowadziła do powstania komputerów, które ktoś kiedyś z dużym sukcesem postanowił wykorzystać do wspierania procesów technologicznych. Często same procesy nie mogłyby zaistnieć bez narzędzi informatycznych. Mamy więc do czynienia z jednej strony z kroczącą rewolucją, a z drugiej z koniecznością zapewnienia bezpieczeństwa. Ale zastanówmy się chwilę o jakie bezpieczeństwo tu chodzi. Wiele się mówi o cyberbezpieczeństwie, bezpieczeństwie IT/OT, zagrożeniach, atakach, hakerach. Jednak w świecie zdominowanym przez systemy informatyczne trzeba cofnąć się do źródła i zastanowić nad tym co my właściwie powinniśmy chronić. Wbrew pozorom odpowiedzi nie powinniśmy szukać w świecie informatyki czy automatyki. To co powinniśmy chronić to procesy, które ta informatyka/ automatyka wspiera czy realizuje. Oczywiście procesy same się nie dzieją i wykorzystują określone zasoby, ale to właśnie procesy definiują nam wymagania dla bezpieczeństwa zasobów w szczególności systemów IT/OT. Zatem jakie są te wymagania? Wymagania możemy podzielić na regulacyjne i biznesowe. Wymagania regulacyjne są nam narzucone i cokolwiek byśmy o nich nie myśleli musimy je stosować, niezależnie od kosztów z tym związanych. W zakresie bezpieczeństwa systemów SCADA niektóre branże (jak np. górnictwo) wypracowały własne regulacje dotyczące bezpieczeństwa systemów krytycznych. Innym źródłem regulacji są np. przepisy dotyczące ochrony infrastruktury krytycznej. Wymagania biznesowe mają tą właściwość, że w zasadzie każda firma może je kształtować w dowolnie wybrany przez siebie sposób, korzystając przy tym z takich narzędzi jak zarządzanie ryzykiem, o którym za chwilę. Systemy SCADA są powszechnie wykorzystywane w sterowaniu pracą instalacji strategicznych dla bezpieczeństwa państwa i obywateli. Takie systemy znajdziemy w górnictwie, elektrowniach, rafineriach, magazynach surowców energetycznych, przedsiębiorstwach zajmujących się przesyłem i dystrybucją paliw i energii elektrycznej, przedsiębiorstwach wodociągowych, oczyszczalniach, fabrykach leków, żywności i pewnie wielu innych miejscach istotnych dla zapewnienia poczucia bezpieczeństwa ludności. Oczywiście każda branża ma swoją specyfikę i inny profil zależności od systemów SCADA. Mikronika ma to szczęście, że działa głównie w branży, w której mając kontrolę nad systemem SCADA można bezpośrednio doprowadzić do destabilizacji pracy systemu elektroenergetycznego, a to z kolei w bardzo krótkim czasie może przełożyć się na destabilizację bezpieczeństwa społecznego. W bardzo obrazowy sposób opisał to Marc Elsberg w swojej książce

Blackout. Warto też przypomnieć sobie przypadki wstrzymania dostaw energii na okres powyżej kilkunastu godzin i reakcje jakie one przynosiły. Rys. 1. Domeny potencjalnych zagrożeń dla infrastruktury krytycznej państwa. Źródło: Jerzy Dereń, Anna Rabiak, NATO a aspekty bezpieczeństwa w cyberprzestrzeni. Obszar bezpieczeństwa cyberprzestrzeni jest też wyraźnie dostrzegany w sektorze militarnym. Obecnie traktowany na równi z powietrzem, morzem, lądem czy przestrzenią kosmiczną. Przestrzeń cybernetyczna jest z wielu względów bardzo atrakcyjnym obszarem do prowadzenia działań rozpoznawczych czy wywiadowczych. Zrozumiałe są zatem wymagania dotyczące ochrony tego obszaru. Mamy też w końcu szereg norm ogólnych i szczegółowych, wydawanych przez różne organizacje. Dla przykładu przytoczę tu normy serii ISO/IEC 27000 określające zasady zarządzania bezpieczeństwem informacji, czy też branżowy standard IEC 62351 definiujący bezpieczeństwo dla protokołów komunikacyjnych, rozwinięty dalej w dokumentach IEC 60870-x. Z amerykańskiego rynku możemy skorzystać z publikacji NIST polecam dokumenty NIST SP 800-82 i NIST SP 800-53 zawierające wiele cennych wskazówek do budowy zabezpieczeń systemów SCADA. Systemy SCADA budowane są na lata. O ile systemy HMI są rozwijane w zasadzie w sposób ciągły, to urządzenia klasy (sterowniki obiektowe) projektowane są na okres 8-12 lat pracy. W tym czasie zmienia się wiele. Pojawiają się nowe zagrożenia, rosną wymagania w zakresie siły mechanizmów kryptograficznych. Zamawiając bezpieczne urządzenia na dziś musimy pamiętać o tym, aby urządzenia miały odpowiedni zapas pamięci i mocy obliczeniowej, aby w założonej perspektywie mogły bezpiecznie pracować. To zagadnienie również powinniśmy potraktować jako wymaganie. Prognozy w tym zakresie publikuje np. ENISA. ZAGROŻENIA Analiza zagrożeń to dość żmudna praca, która w dużym uproszczeniu polega na wymyślaniu zdarzeń, które mogą się zdarzyć i które spowodują jakieś niekorzystne skutki. W tym zakresie warto skorzystać

z dostępnych katalogów zagrożeń zarówno technicznych jak i organizacyjnych np. wspomniany wyżej NIST SP 800-82 czy ISO/IEC 27005. Największy problem z zagrożeniami polega na tym, że trudno oszacować prawdopodobieństwo zaistnienia sytuacji, która dane zagrożenie wykorzystuje. Jest to tym trudniejsze, im rzadziej się taka sytuacja wydarza. RYZYKO Moda na zarządzanie ryzykiem już nieco przygasła, jednak warto skorzystać z tego narzędzia do właściwego ustawienia poziomu poprzeczki. A o co chodzi z tym poziomem poprzeczki? Otóż sprawa jest dość prosta. Nie ma systemów bezpiecznych i niebezpiecznych. Są natomiast systemy bardziej bezpieczne i mniej bezpieczne. W przypadku oceny mechanizmów bezpieczeństwa świat nie jest zerojedynkowy. Zawsze da się podnieść poziom bezpieczeństwa i zawsze też można ten poziom obniżyć. Pamiętajmy też, że bezpieczeństwo kosztuje. Nie tylko czas i pieniądze wydane na wdrożenie. Równie istotne są koszty związane z utrzymaniem i eksploatacją mechanizmów bezpieczeństwa i to nie tylko od strony zarządzania nimi, ale przede wszystkim od strony użytkownika. Wracając do poprzeczki niech ona symbolizuje poziom bezpieczeństwa. Zanim zabierzemy się za zabezpieczanie systemów, trzeba sobie odpowiedzieć jaki jest docelowy poziom naszej poprzeczki. I tu właśnie z pomocą przychodzi nam zarządzanie ryzykiem. Żeby zarządzać ryzykiem, trzeba umieć odpowiedzieć na trzy pytania: 1. Co jest dla nas ważne? Musimy zdefiniować sobie co musimy, chcemy lub powinniśmy chronić i dlaczego. Możemy to zrobić z perspektywy potencjalnych skutków naruszenia bezpieczeństwa. Z takiej prostej analizy powinniśmy otrzymać zbiór aktywów (procesów, systemów, elementów infrastruktury IT/OT itd.), podzielony na podzbiory istotności. Każdy ze zdefiniowanymi wymaganiami. 2. Gdzie dziś jesteśmy? W tym kroku trzeba zrobić swoisty rachunek sumienia. Czyli spojrzeć na nasze systemy, ich otoczenie, sposób zarządzania nimi i odpowiedzieć, czy każde z wymagań określonych w poprzednim kroku jest skutecznie zrealizowane. 3. Dokąd zmierzamy? Dokąd zmierzamy to inaczej właśnie jak wysoko powinna zostać zawieszona nasza poprzeczka. A wisieć powinna tym wyżej, im ważniejsze jest dla nas to, co ma chronić. Żeby domknąć proces zarządzania ryzykiem, musimy jeszcze zidentyfikować wszystkie sytuacje, w których określone wymaganie nie jest dziś spełnione i określić co z tym robimy czyli definiujemy postępowanie z ryzykiem. Takie cykle można a w zasadzie należy robić okresowo z taką częstością, jaka wynika z dynamiki zmian we wspomnianych wyżej elementach. Jakie zastosować podejście do bezpieczeństwa? Spróbujmy więc zastosować wyżej opisane zarządzanie ryzykiem. Po pierwsze co jest dla nas ważne? Nie będziemy tu szczegółowo opisywać potencjalnych skutków naruszenia bezpieczeństwa SCADA, bo z jednej strony to jest sprawa dość indywidualna dla każdego systemu, ale możemy też przyjąć, że zajmujemy się systemami krytycznymi czyli upraszczając takimi, których naruszenie bezpieczeństwa może doprowadzić do bardzo istotnych konsekwencji społecznych, gospodarczych do naruszenia porządku publicznego włącznie.

Postawmy zatem drugie pytanie gdzie dzisiaj jesteśmy? Rozwiązania ze świata informatyki z dość dużym poślizgiem czasowym trafiały do świata automatyki. W automatyce liczą się nieco inne aspekty. Sprzęt nie musi być najnowszy, najbardziej wydajny. Ma być pewny i sprawdzony. Jednak w momencie, kiedy rozwiązania IT na tyle zdominowały świat, że korzystanie z nich stało się oczywistą oczywistością, świat automatyki nie mógł się temu oprzeć. Największą rewolucją w tym zakresie jest masowe udostępnienie taniej bezprzewodowej transmisji danych opartych głównie o sieci komórkowe. Po prostu nie można było z tego nie skorzystać, pomimo tego, że ani te sieci, ani protokoły w nich wykorzystywane nie zostały zaprojektowane do zastosowań w systemach SCADA. Podobna sytuacja jest z systemami operacyjnymi, systemami baz danych itd. Zatem osobne do niedawna światy automatyki i informatyki zaczęły się przenikać, przy czym zaawansowanie rozwiązań informatycznych wyprzedza o ok. 15-20 lat to, co dzieje się w świecie OT. Niezależne odseparowane systemy Służby automatyki Niezależne odseparowane systemy Integracja ze światem zewnętrznym Gwałtowny transfer zagrożeń i problemów z IT do OT 1980 1990 2000 2010 2020 Służby IT Niezależne odseparowane systemy Standaryzacja Systemy centralne ERP / CRM Wirtualizacja, Centra usług wspólnych Cloud computing Rys. 2. Historia OT i IT. I nie było by w tym większego problemu, gdyby nie nagłe zderzenie tych światów, które w ostatnich latach się zwyczajnie połączyły pod względem stosowanych narzędzi informatycznych przez szerokie zastosowanie w automatyce. Trzeba jednak pamiętać, że z każdym elementem przyjmujemy z dobrodziejstwem inwentarza wszystkie związane z nim zagrożenia i podatności. Dodatkowo bardzo proste stało się łączenie systemów i wymiana danych. To z jednej strony jest podstawą rozwoju, ale z drugiej spowodowało, że zniesione zostały bariery, które zabezpieczały proces technologiczny. Bezpieczeństwo środowiska SCADA trzeba zapewnić tu i teraz, zatem nie można czekać kolejnych lat aż świat OT dogoni informatykę w stosowaniu zabezpieczeń. Dlatego w Mikronice postanowiliśmy na nowo zdefiniować bezpieczeństwo środowiska OT. Na początek kilka założeń, jakie zostały przyjęte w tym projekcie opracowania bezpiecznej architektury systemu SCADA. Model powinien być:

wygodny w użytkowaniu, w zarządzaniu, we wsparciu biznesu, racjonalny umożliwiać właściwe rozłożenie priorytetów, wykonalny, możliwy do adaptacji (w zakresie zastosowania, skali, uwarunkowań technologicznych, finansowych, innych), osadzony we współcześnie stosowanych mechanizmach bezpieczeństwa, perspektywiczny dający się utrzymać w najbliższej przyszłości (perspektywa czasu pracy urządzeń / systemów). Cały model podzielony został na cztery poziomy, zaprezentowane na rysunku 3. W dalszej części omówione zostaną kolejne poziomy czytając model od dołu. Poziom systemów zewnętrznych Inne systemy korporacyjne Internet Poziom prezentacji i zarządzania Syndis RV z modułami DB Poziom komunikacji Sieć prywatna Sieć publiczna (VPN, APN, Poziom automatyki pomiarowosterującej Rys. 3. Model systemu SCADA. Poziom automatyki pomiarowo-sterującej. To zagadnienie szczegółowo zostało opisane w czasopiśmie Control Engineering 09/10 2016 w artykule zatytułowanym Bezpieczeństwo systemu SCADA gdzie się zaczyna? Projektując bezpieczeństwo w warstwie sterowników obiektowych przyjęliśmy założenie, że sterownik może pracować w sieci, która nie jest siecią bezpieczną, dlatego musi umieć się sam obronić. Dlatego sam sterownik został wyposażony w szereg nakładających się na siebie mechanizmów bezpieczeństwa, które zgodnie z koncepcją wielowarstwowej struktury bezpieczeństwa (defence in depth) daje

niespotykany dotąd w tej klasie urządzeń poziom bezpieczeństwa. Po szczegóły odsyłam do przytoczonego wyżej artykułu. Poziom komunikacji, poziom systemów zewnętrznych Jak już wyżej wspomniano, zmiany technologiczne na poziomie komunikacji są najważniejszą przyczyną całego zamieszania. Skoro więc sieć IP wyparła inne stosowane do tej pory media komunikacyjne, to trzeba się skupić na zabezpieczeniu sieci IP. Tutaj na szczęście mamy bardzo wiele dostępnych rozwiązań, od dawna stosowanych w świecie informatyki. Obecne tendencje są takie, że operatorzy infrastruktury rozproszonej budują własne sieci techniczne, oparte o łącza własne, dedykowane łącza dzierżawione czy wręcz posadowione na infrastrukturze operatorów publicznych. Zwykle z redundancją w postaci transmisji bezprzewodowej. Większość komunikacji oparta jest o sieć IP, jako taki został stworzony do transmisji na duże odległości, a dodatkowo zapewnia skalowalność, wydajność, wysoką odporność na awarie dynamiczny routing, niezawodną transmisja danych i uniwersalność. Jednak to, co jest zaletą w jednym zastosowaniu, w innym może być wadą. Przykładem mogą być zakłócenia spowodowane dynamicznymi protokołami routingu, z którymi systemy SDADA nie zawsze dobrze sobie radzą. W niektórych zastosowaniach wykorzystuje się sieć TETRA. Bezpieczeństwo sieci SCADA. Czym ono w zasadzie różnie się od sieci domowej czy biurowej? Przede wszystkim tym, że do minimum musimy tu ograniczyć możliwość wykonania operacji na sterowanym przez system SCADA procesie technologicznym. Sama kradzież danych ma tu zwykle znacznie bardziej łagodne skutki niż potencjalna ingerencja w proces. To powoduje, że musimy trochę inaczej rozłożyć akcenty w mechanizmach obronnych. Przy definiowaniu bezpiecznej komunikacji trzeba wziąć pod uwagę następujące elementy: urządzenia końcowe z obsługą wielowarstwowych mechanizmów bezpieczeństwa, architektura serwerowa z obsługą komplementarnych do zastosowanych w urządzeniach wielowarstwowych mechanizmach bezpieczeństwa, zabezpieczenie infrastruktury dostępowej, polityki separacji i filtrowania ruchu, zabezpieczenie i konfiguracja protokołów routingu, mechanizmy szyfrowania danych, aktywne monitorowanie infrastruktury. Oczywiście każda sieć jest inna, każde środowiska SCADA jest inne, dlatego nie ma jednego najlepszego modelu referencyjnego, który dałoby się po drobnych przeskalowaniach zwyczajnie kopiować. Jak zabezpieczyć sieć SCADA? Przede wszystkim trzeba się zastanowić nad podziałem sieci na mniejsze części funkcjonalne, obsługujące coraz szersze obszary funkcjonalne. Rysunek 4 przedstawia model ochrony systemu SCADA opracowany na potrzeby energetyki jądrowej, zgodny z koncepcją defense in depth. Idea jest stosunkowo prosta. W centrum osadzamy tylko te elementy (systemy / infrastruktura / użytkownicy / usługi), które są niezbędne dla zapewnienia popranej pracy sterowanego procesu. Im dalej od lewej stronnym tym więcej elementów nam przybywa. Oczywiście na granicach stref instalowane są urządzenia zapewniające wymuszenie polityki ruchu, zgodnie z przyjętymi regułami.

Zaletą takiej architektury jest możliwość stosunkowo łatwego odcięcia poszczególnych warstw od krytycznego w tym przypadku Level 4, w sytuacji, gdyby doszło do jakiegoś incydentu w którejkolwiek z zewnętrznych stref. Rys. 4. Architektura obrony cyberbezpieczeństwa. Źródło: U.S. Nuclear Regulatory Commission Regulatory Guide 5.71 Level 4 reprezentuje sieć systemu sterowania i systemu zabezpieczeń Level 3 to sieć akwizycji danych Level 2 to sieć obiektowa / zakładowa Level 1 reprezentuje sieć korporacyjną Level 0 to sieć publiczna / Internet Na rynku dostępne są urządzenia, służące zabezpieczeniu sieci, które z powodzeniem można zastosować do ochrony sieci SCADA. Podstawowym i najczęściej stosowanym urządzeniem jest firewall. Jeżeli do separacji poszczególnych poziomów stosujemy firewalle, dobrą praktyką jest, jeżeli pochodzą one od różnych dostawców/producentów. Dobrze też, jeżeli firewall może pracować w kontekście konkretnego użytkownika oraz rozumie co filtruje tzn. potrafi filtrować ruch na poziomie protokołów w warstwie aplikacji. Firewalle mogą być też wyposażone w dedykowane moduły IPS/IDS. W razie konieczności inspekcji szyfrowanych połączeń możemy wykorzystać SSL PROXY, który ma możliwość inspekcji np. zaszyfrowanej transmisji http. Inną klasą urządzeń służących do separacji sieci jest dioda danych. Urządzenia złożone z dwóch komputerów połączonych jednokierunkowym światłowodowym kanałem nadawczo-odbiorczym zapewnia separację sieci na poziomie separacji galwanicznej. Komputer nadawczy w diodzie danych wyposażony jest wyłącznie w nadajnik, a komputer odbiorczy w odbiornik sygnałów świetlnych. Nie ma wiec fizycznej możliwości wykonania transmisji zwrotnej, nawet, gdyby udało się komuś przejąć pełną kontrolę nad komputerem odbiorczym. Stosowanie wyżej wymienionych urządzeń ma sens wtedy, jeżeli łączymy ze sobą segmenty sieci. Przy infrastrukturze mocno rozproszonej geograficznie, zwykle lepiej jest zastosować sterownik wyposażony w zaawansowane mechanizmy bezpieczeństwa. Poziom prezentacji i zarządzania W klasycznym systemie SCADA sprzed kilkunastu lat mieliśmy klika serwerów systemu, pracujących w odseparowanej sieci, z komunikacją po dedykowanych łączach z obiektami telemechaniki. Serwery najczęściej zdublowane dla zapewnienia redundancji. Do tego kilka stanowisk dyspozytorskich i na tym system się kończył. Obecnie, przez rozwój możliwości komunikacji oraz integrację systemów SCADA np. z system IVR, ERP, GIS, a także koniecznością wykonywania wielu analiz, które nie są już realizowane przez dyspozytorów tylko pracowników biurowych, trzeba było udostępnić szereg usług i danych na zewnątrz.

Na rysunku 5 z przedstawiona została przykładowa architektura bezpieczeństwa systemu SCADA. Warstwa sterowania Wymiana danych z Operatorem Systemu Przesyłowego Strefa Obiekty sieć techniczna Strefa Obiekty sieć publiczna Strefa SCADA Oddział Wymiana z systemami wewn. obiekt stacja Syndis Warstwa pośrednicząca obiekt stacja Strefa DMZ integracja GIS IVR ERP obiekt DNP3 / IEC 104 DNP3 / IEC 104 Serwer pośredniczący Warstwa użytkownika Zdalny dostęp - Mikronika Strefa DMZ serwis Sieć techniczna Strefa pracowników telemechaniki (administratorzy Syndis) Strefa SCADA zapasowa Strefa SCADA Serwer dostępowy Strefa DMZ usługi dostępowe Strefa planistów Syndis RV, EMS Syndis RV OMS, EMS, DM FW 0-1 Proxy OMS Syndis Lite Usługi terminalowe FW 1-2 DM OMS DBMS DBMS Strefa DMZ operacje mobilne Strefa urządzeń mobilnych Strefa dyspozytorska zapasowa Strefa dyspozytorska Serwer pośredniczący APN Tablety Strefa sieci biurowej Strefa DMZ raportowanie Terminale dyspozytorskie Terminale dyspozytorskie DBMS OMS R Kierunek strzałek oznacza sposób inicjowania komunikacji Rys. 5. Architektura bezpieczeństwa sieci SCADA. Warstwa sterowania to serce systemu SCADA. Zawiera te i tylko te elementy, które są niezbędne do prowadzenia ruchu. Od strony komunikacji ze sterownikami, każdy mechanizm bezpieczeństwa, zaimplementowany na interfejsach sterownika musi mieć swój odpowiednik po stronie serwera. Dla przypomnienia mówimy tu m.in. o wielopoziomowych mechanizmach szyfrowania transmisji i obsługą certyfikatów, zarządzaniu użytkownikami z uwierzytelnianiem on-line, zarządzaniu konfiguracją i firmware, monitorowaniu pracy urządzenia. Dodatkowo przygotowanie aplikacji Scada (np. Syndis RV) realizowane jest w oparciu o te same zasady co w przypadku urządzeń. Cały system podlega procesowi hardeningu, w którym następuje m.in.: usunięcie (ew. zablokowanie) nieużywanych usług, deaktywacja niepotrzebnych użytkowników, usunięcie nieużywanych modułów programowych, separacja funkcjonalnych komponentów, zabezpieczenie danych wrażliwych,

eliminacja protokołów jawnych na rzecz bezpiecznych. Sam system Syndis RV jako aplikacja Scada posiada kilka wbudowanych mechanizmów bezpieczeństwa, implementowanych na różnych warstwach samej aplikacji. Najważniejsze z nich to: wieloskładnikowe uwierzytelnianie użytkowników z możliwością integracji z domeną (LDAP / AD), rozbudowanej strukturze ról i uprawnień nadawanych poszczególnym użytkownikom. W tym zakresie od niedawna system umożliwia też dynamiczne nadawanie uprawnień do obiektów na podstawie modelu CIM. W skrócie chodzi o to, że dyspozytor w określonych sytuacjach (np. nagłego spiętrzenia ilości zdarzeń na nadzorowanym obszarze infrastruktury) może przekazać zarządzanie częścią tego obszaru innemu dyspozytorowi, który na co dzień nie ma uprawnień do tych obiektów. Pozostają oczywiście w użyciu mechanizmy autoryzacji uprawnień do sterowania na poziomie terminali oraz mechanizmy bezpieczeństwa samych aplikacji klienckich instalowanych na terminalach dyspozytorskich. Wszystkie inne usługi udostępniające dane, umożliwiające prowadzanie określonych danych realizowane są poza warstwą sterowania, z wykorzystaniem warstwy pośredniczącej i umieszczonych tam serwerów pośredniczących. W zależności od zastosowania są to serwery proxy, samodzielne serwery analityczno-raportujące pracujące na własnej replice podstawowej bazy danych. Mogą to być też dedykowane serwery aplikacyjne, które z jednej strony obsługują użytkowników w określonym zakresie, a z drugiej komunikują się z głównymi serwerami systemu. Pracownicy korzystający z danych systemu SCADA (np. działy handlowe, obsługa klienta) lub dostarczający do SCADY dane wsadowe (np. planiści, brygady eksploatacyjne) nie mają bezpośredniego dostępu do głównych serwerów systemu SCADA, a ich działania kontrolowane są przez dedykowane moduły w warstwie pośredniczącej. W przedstawionym modelu bardzo ważną funkcję spełniają firewalle oddzielające poszczególne warstwy i strefy od siebie. To tak naprawdę na tych urządzeniach spoczywa ciężar separacji stref i warstw czyli fundamentu bezpieczeństwa tej architektury. PODSUMOWANIE Dziś żyjemy w świecie wszechogarniających urządzeń, które bez energii elektrycznej nie są w stanie pracować kilkunastu godzin. Wysoki poziom ciągłości dostaw mediów i surowców energetycznych spowodował ograniczenie do minimum wszelkich zapasów, a w nowoczesnych budynkach nie włączymy światła czy ogrzewania bez sprawnego systemu sterującego. Taki stopień automatyzacji powoduje, że system sterowania musi być po prostu pewny. A pewny, to znaczy niezawodny, odporny na zakłócenia i próby ingerencji z zewnątrz i z wewnątrz. Systemy opracowane przez Mikronikę wychodzą wprost naprzeciw tym potrzebom. Każdy teraz sam musi sobie odpowiedzieć na pytanie jak długo jest w stanie wstrzymywać rozwój swojej organizacji izolując swoje systemy SCADA albo akceptować wysokie ryzyko związane z otwieraniem środowiska OT na świat. O trzeciej drodze, łączącej rozwój z bezpieczeństwem mówi ten artykuł. Pamiętajmy, że bezpieczeństwo systemów SCADA jest warunkiem koniecznym dla tego, aby społeczeństwo mogło czuć się bezpiecznie. I obyśmy nie musieli tego sprawdzać na własnej skórze. Autor artykułu: Tomasz Szała, Ekspert ds. bezpieczeństwa. MIKRONIKA ul. Wykopy 2/4, 60-001 Poznań tel. +48 61 665 56 00, fax +48 61 665 56 02 www.mikronika.pl