Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Kategoria: Kamery IP / Alarmy / Automatyka Bram
Montersi
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Bezpieczeństwo sieci przemysłowych dla SCADA.

TechEkspert 24 Sie 2016 21:20 2031 4
  • Bezpieczeństwo sieci przemysłowych dla SCADA.
    SCADA (Supervisory Control And Data Acquisition) to w uproszczeniu system nadzorujący pracę parku maszynowego (m.in sterowników PLC w maszynach), co pozwala na zarządzanie i monitorowanie procesu produkcyjnego.
    Połączenie dwóch firm było okazją do zinwentaryzowania i uporządkowania zasobów SCADA. Jednym z założeń integracji było umożliwienie monitoringu rozproszonych systemów z jednego punktu. Tematyka związana ze SCADA była dla mnie czymś nowym, jestem ciekawy czy natrafiłem na typowe problemy z sieciami LAN i WAN, które przeznaczone są do obsługi SCADA?






    Zespół A i zespół I.
    W integracji brały udział dwa zespoły:
    A - (zespół automatyków)
    I - (zespół informatyków)
    Oba zespoły miały swoich kierowników, którzy podlegali szefowi firmy, niektóre zadania wydawały się rozmyte między zespołami.
    Subiektywnie można scharakteryzować zespoły następująco:

    Zespół A:
    Specjaliści w zakresie automatyki, dbają o ciągłość działania maszyn, dobrze znają problemy sprzętowe związane z zasilaniem i zakłóceniami.
    Niezbyt dobrze radzą sobie ze skomplikowanymi zagadnieniami IT, nie wnikają w protokoły sieciowe, konfigurację aplikacji i nowości na rynku IT.
    Zespół A czasami wspiera zespół I gdy potrzebne są prace przy infrastrukturze zasilania gwarantowanego infrastruktury IT.
    Zespół A traktuje sieć SCADA jako infrastrukturę wspierającą i monitorującą, główny nacisk kładziony jest na ciągłość funkcjonowania maszyn.

    Zespół I:
    Specjaliści od rozwiązań IT, dbają o bezpieczeństwo oraz niezawodność systemów, są na bieżąco z aktualnymi technologiami wykorzystywanymi w firmowym IT.
    Niezbyt dobrze czują się w obecności szynoprzewodów 3f 400V, nie wnikają w procesy technologiczne i sposób działania maszyn.
    Zespół I głównie realizuje zadania związane z firmowym IT, prace przy SCADA są dodatkowym wsparciem zespołu A.

    Działa nie ruszaj!
    Niestety na takim stanowisku stała duża liczba osób zajmująca się SCADA, były ku temu pewne racjonalne powody, mimo że brak chęci zmian mógł mieć także wiele negatywnych skutków.

    Uproszczony punkt widzenia zespołu A:
    Istotna jest ciągłość działania maszyn, brak środowiska testowego uniemożliwia określenie w 100% wpływu aktualizacji oprogramowania sterownika PLC lub zmiany konfiguracji systemu. Obecnie system działa prawidłowo i nie ma potrzeby podejmowania dodatkowych działań. Można wykonać aktualizacje i zmiany, pod warunkiem zapewnienia ciągłości działania, za ew. problemy odpowiedzialność poniesie zespół I.

    Uproszczony punkt widzenia zespołu I:
    Elementy systemu SCADA to dedykowane urządzenia zawierające oprogramowanie i interfejsy komunikacyjne, komputery wyposażone są w systemy operacyjne i oprogramowanie.
    Należy wykonywać aktualizacje firmware sterowników PLC, oprogramowania terminali, systemów operacyjnych, sprzętu sieciowego i reguł sieciowych aby zapewnić bezpieczeństwo.

    Niezawodne 15 letnie sterowniki.
    Niektóre maszyny zawierały sterowniki PLC, które zostały wyprodukowane ~10 a także ~15 lat temu.
    Systemy operacyjne starzeją się znacznie szybciej. Wiekowe systemy operacyjne i aplikacje (często bez aktualizacji) mogą być łatwym celem ataku, oraz jego eskalacji na pozostałą infrastrukturę. Uwagę zwracały komputery z aplikacjami nadzorującymi oraz panele operatorskie (HMI), które mimo że bazujące na typowych rozwiązaniach PC wykazywały się zaskakującą trwałością. Kluczem do trwałości było dobrej jakości zasilanie, chłodzenie, oraz dość przestarzałe i o małej pojemności dyski twarde (lub karty flash), a także dość powolne CPU (pobierające mniej prądu i otoczone przetwornicami z dobrej jakości kondensatorami). Podczas integracji na wszelki wypadek zostały wykonane obrazy dysków twardych komputerów zarządzających.

    Zdalny dostęp do aplikacji na Windows XP/98.
    W dwóch lokalizacjach do nadzorowania pracy urządzenia wykorzystywany był komputer PC z dość leciwym systemem operacyjnym, oraz aplikacja komunikująca się z wykorzystaniem interfejsu RS-232 oraz konwertera do CL/RS485.
    Jak zapewnić zdalny i bezpieczny dostęp?
    Nie udało się przeniesienie aplikacji na bardziej współczesny system, natomiast plany rozpracowania komunikacji przez RS-232 lub modernizacji sprzętu zostały odrzucone (planowana likwidacja lub kompleksowa modernizacja całej maszyny).
    Dostęp został zrealizowany przy pomocy KVM z możliwością kontroli poprzez sieć (KVM over IP). Urządzenie zostało podłączone do interfejsu klawiatury, myszy i złącza VGA komputera, pozostawiając także możliwość lokalnego dostępu z wykorzystaniem monitora, klawiatury i myszy. Klientem KVM była przeglądarka w centrali, ruch sieciowy został zamknięty w VPN. Tym sposobem system operacyjny komputera nie miał styku z siecią, nie nastąpiła żadna ingerencja w oryginalny system. Centrala firmy uzyskała zdalny monitor i klawiaturę do oddalonego komputera, w postaci aplikacji przeglądarkowej.

    Bezpieczna całkowicie izolowana sieć SCADA?
    Do tej pory sieć LAN dla SCADA uchodziła za odizolowaną od innych sieci a w szczególności od internetu. W zamysłach integracji miała być uruchomiona możliwość zdalnego dostępu do niektórych fragmentów obecnej sieci, celem zdalnego monitoringu.
    W istniejącej sieci bardzo często urządzenia posiadały domyślną konfigurację oraz hasła dostępowe. Usprawiedliwieniem tego stanu była wspomniana izolacja sieci LAN, a także chęć uniknięcia problemów z dostępem, gdy ktoś zgubi hasło lub nie będzie go pamiętać.
    Hasła zostały zmienione, oraz zapisane i zabezpieczone w siedzibie firmy.

    Sieć okazała się nie do końca izolowana... Istniały stacje zarządzające, które miały dostęp do fragmentów sieci SCADA, a także służyły do innych celów i miały dostęp do firmowej sieci biurowej a także internetu... Jak to możliwe? Okazało się, że część sieci SCADA i sieci biurowej znajduje się w tej samej domenie rozgłoszeniowej. Obie sieci posiadały inną adresację, natomiast na komputerach zarządzających zostały skonfigurowane dwa adresy IP.

    Bezpieczeństwo sieci przemysłowych dla SCADA.

    Burza rozgłoszeniowa w sieci biurowej mogła dotrzeć także do sieci SCADA, nie wspominając o możliwości wykonania ataku na SCADA z zainfekowanej stacji zarządzającej.

    Zostało zrealizowane rozdzielenie domen rozgłoszeniowych:
    Bezpieczeństwo sieci przemysłowych dla SCADA.

    Gdy charakterystyka ruchu zostanie dokładnie zbadana, stacje zarządzające SCADA docelowo zostaną umieszczone za routerem:
    Bezpieczeństwo sieci przemysłowych dla SCADA.

    Okazało się, że do nadzoru kilku odległych urządzeń uruchomiony jest obecnie dostęp zdalny z wykorzystaniem internetu. W przypadku jednej maszyny został wykorzystany konwerter RS-232 over Ethernet oraz modem/router GSM, w drugim przypadku urządzenie posiadało interfejs Ethernet połączony z modemem/routerem GSM.
    Poza ruchem istotnym do nadzoru maszyn, otwarte były także inne rodzaje ruchu sieciowego zbędne przy nadzorze lecz mogące być punktem ataku (telnet/FTP wykorzystywany np. przy aktualizacji firmware).
    Do łączenia z maszynami wykorzystywany był laptop wyposażony w modem 3G i aplikacje umożliwiające dostęp, a także zestaw przewodów i konwerterów umożliwiający podłączenie do różnych urządzeń. Takie rozwiązanie pozwalało na mobilność stanowiska serwisowego.
    Jeden z modemów/routerów został wymieniony (występujące problemy ze stabilnością i małe możliwości konfiguracji). Na obu urządzeniach zostały wprowadzone reguły blokujące dostęp do zbędnych portów, połączenia z laptopa do urządzeń zostały zamknięte w VPN. Dysk w laptopie został wymieniony na SSD (obecny miał podejrzane parametry SMART oraz spowalniał pracę komputera). Dysk laptopa serwisowego został zaszyfrowany (stacja mobilna, ryzyko utraty sprzętu a co ważniejsze danych).

    Sieć SCADA na przemysłowych przełącznikach.
    Sieć LAN dla SCADA powstawała stopniowo i zbudowana była w dużej części w oparciu o przemysłowe przełączniki 48V montowane na szynie. Z punktu widzenia trwałości i odporności na zakłócenia było to dobre rozwiązanie. Z punktu widzenia zarządzania ruchem i niezawodności sieci było to złe rozwiązanie.

    Problemy zgłaszane przez zespół A:
    Czasami podczas awarii zasilania część maszyn nie miała dostępu do sieci, zdarzyło się także wywołanie pętli w sieci podczas podłączania nowego urządzenia.

    Bezpieczeństwo sieci przemysłowych dla SCADA.

    Propozycja zespołu I:
    Dla zespołu I, większość przełączników przemysłowych miało możliwości najprostszego przełącznika SOHO o wartości 50zł...
    Dlatego zostało zaproponowane sprowadzenie przewodów LAN w jeden punkt dystrybucyjny i zainstalowanie zarządzalnego przełącznika RACK zamontowanego w odpowiedniej szafie zlokalizowanej w wybranym miejscu.

    Wdrożone rozwiązanie:
    Część okablowania była wykonana bardzo dobrze, budowanie wszystkiego od podstaw byłoby zbyt kosztowne i czasochłonne. Struktura sieci została uproszczona. Zostały wykorzystane dwa główne przełączniki zarządzalne (dostarczające także PoE+) połączone ze sobą redundantnie i redundatnie połączone do istniejącej infrastruktury IT (przełącznika z wykreowanymi VLANami i obsługą STP). W kanałach kablowych dostępne jest wolne miejsce i można zwiększyć ilość połączeń szkieletowych zwiększając przepustowość dzięki wsparciu LACP (np. w przyszłości do przenoszenia w osobnym VLAN danych z kamer IP CCTV).
    W miarę możliwości przełączniki przemysłowe, nie przenoszą ruchu do kolejnych przełączników. Niektóre przełączniki poza lokalnym zasilaczem mogły być zasilane z wykorzystaniem PoE z przełączników głównych. PoE na przełącznikach głównych wraz z możliwością wykreowania kolejnych VLAN-ów, może przydać się w przyszłości do np. zasilania kamer IP CCTV. Na przełącznikach głównych zostały włączone mechanizmy ograniczające ryzyko wystąpienia pętli w sieci.

    Bezpieczeństwo sieci przemysłowych dla SCADA.

    Planowany przestój prawie nie istnieje...
    Kolejną przeszkodą w pracach modernizacyjnych i aktualizacjach oprogramowania była chęć ograniczenia przestojów. Większym problemem niż przestój maszyny, było zgranie pracy kilku osób z różnych obszarów, tak aby byli dostępni w czasie prowadzenia prac. Problem z zasobami ludzkimi i koordynacją wyłączenia wielu elementów był trudny, jednak wspólny cel integracji systemów firm ułatwiał to zadanie.

    Co piszczy w sieci?
    Po rozdzieleniu domen rozgłoszeniowych oraz uproszczeniu topologii sieci i zwiększeniu jej niezawodności, przyszedł czas na dalsze dostrajanie LAN.
    Poważnym problemem był brak jednoznacznych odpowiedzi jaką jest charakterystyka ruchu w sieci SCADA. Zastosowane przełączniki pozwalały na wysyłanie statystyk flow z wybranych portów. Okazało się, że w infrastrukturze IT znajduje się kolektor, który pozwoli na zbieranie i analizę próbek wysyłanych przez mechanizmy flow na przełącznikach. W sytuacjach awaryjnych i podczas wdrożeń może przydać się dostępny na przełącznikach mechanizm port mirror, co pozwoli na dokładną analizę problemu sieciowego np. podłączając laptop z zainstalowanym oprogramowaniem (np. Wireshark).
    Dostęp do wybranego fragmentu sieci SCADA w celu monitoringu z centrali został zrealizowany z wykorzystaniem VPN.

    Co się udało?
    -zasoby SCADA zostały zinwentaryzowane, struktura uproszczona i ulepszona.
    -udało się zbudować centralny monitoring SCADA
    -zespół A otrzymał lepiej działającą sieć
    -zespół I otrzymał nowe zasoby do obsługi sieci LAN i WAN
    -zostały wytypowane osoby z zespołów A i I, które będą zapewniały komunikację i współdziałanie
    -planowane są szkolenia dla wybranych osób z zespołu A i I.

    Czy coś można było zrobić lepiej?
    Na pewno, ważne że proces został rozpoczęty i wewnętrzne zasoby firmy są w to zaangażowane, oraz rozwijają swoje kompetencje.

    Dla mnie SCADA była czymś zupełnie nowym, mimo że w procesie zmian uczestniczyłem przez ograniczony czas było to ciekawe wyzwanie. O ile sprawy z dziedziny IT nie były dla mnie zaskoczeniem, to obszar automatyki był poruszeniem wierzchołka góry lodowej.

    Czy mieliście podobne doświadczenia z sieciami dla SCADA, czy też trafiłem na ciężki a może przeciwnie bardzo łatwy przykład integracji sieci LAN dla SCADA?


    Fajne!
  • Ups
  • #2 25 Sie 2016 07:44
    __Maciek__
    Poziom 18  

    Na wstępie reprezentuję cześć "A"

    Zagadnienia IT w zakresie SCADA to oczko w głowie dzisiejszych specjalistów "A". Właściwie należało by podzielić specjalistów "A" na A-field i A-system.

    Wygląda mi to na chwalenie się piękną modernizacją infrastruktury z punktu widzenia "I". Ok można, ale ostrożnie. Brakuje mi tu opinii drugiej strony na temat modernizacji.

    W rzeczywistości miałem styczność z podobną modernizacją w dużej firmie przemysłu chemicznego i muszę powiedzieć że podejście inżynierów IT czasem to zupełna porażka.
    Przykład : Puszczanie komunikacji przez sieć VLAN pomiędzy 2 sterownikami, znajdującymi się obok siebie, sterujące współpracującymi instalacjami. Z tym że oba sterowniki były w osobnych podsieciach a translacja znajdowała się w biurach oddalonych o ok 1500m. Infrastruktura w opłakanym stanie.

    Dla mnie sytuacja włączenia instalacji do sieci zakładowej jest OK pod pewnymi warunkami / rygorami. Tworzenie sieci nawet na zarządzanych switchach i wpinanie "WSZYTSKIEGO" jak leci do najbliższego punktu to totalna porażka, ale dla dużej części inżynierów IT normalka bo oni zrobią sobie VLANY i wg. nich załatwia to wszystkie problemy.

    Najważniejsze jest obustronne zrozumienie, analiza korzyści i zagrożeń oraz opracowanie szczegółowego planu realizacji.

  • Ups
  • #3 25 Sie 2016 12:52
    TechEkspert
    Redaktor

    Dziękuję za głos z 'obozu' A :) W obecnych czasach nie ma możliwości aby pojedyncza osoba lub nawet zespół znał się na wszystkim, dlatego dobra współpraca to podstawa. W samych VLANach nie ma nic złego to po prostu optymalne wykorzystanie sprzętu (podobnie jak w przypadku wszechobecnej wirtualizacji). Gorzej gdy ktoś próbuje na siłę routować ruch, który mógłby (powinien) pozostać w ramach podsieci. W opisywanym przypadku, przełączniki 'na maszynach' w większości pozostały bez zmian, natomiast 'up linki' zostały sprowadzone z przełączników zarządzalnych. Moim zdaniem był to dobry krok i udało się uporządkować zastaną sieć.

  • Ups
  • #4 25 Sie 2016 13:30
    zolwik_rct
    Poziom 10  

    Głosu nie zabiorę, choć reprezentuję A :)

    czytałem już coś podobnego, tylko bardziej szczegółowo, ale przypuszczam, że o inny obiekt chodzi, dla zainteresowanych: Link

  • #5 25 Sie 2016 18:50
    TechEkspert
    Redaktor

    @zolwik_rct Ciekawy materiał: Synergia działów IT i automatyków , dodatkowo zostały poruszone tematy związane ze środowiskiem wirtualizacji i architekturą serwerów działających jako wirtualne maszyny. Wspomniany został też istotny temat QoS/CoS dla poszczególnych usług na określonych łączach.
    Wartym do "zaimportowania" mechanizmem jest kontrola pamięci USB podłączanych do stacji, aby ograniczyć ryzyko przenoszenia złośliwego oprogramowania.
    Kolejny temat to synchronizacja czasu wszystkich urządzeń, mamy wtedy m.in szansę uzyskać skorelowane w czasie logi co ułatwia ew. analizę zdarzeń. Drobny szczegół - przesyłanie informacji o czasie zawsze jako UTC i konwersji do czasu lokalnego na terminalu operatora, może być użyteczne w np. firmach międzynarodowych.

    Kolejny temat to kanały komunikacji przesyłające dane o istotnych problemach, wyjście poza e-maile i tablice informacyjne do np. SMS może przyspieszyć reakcję na niebezpieczne sytuacje.

    W materiale przewija się wiele znanych (poznanych) mi tematów, w szczególności widać też wzmiankę o dwóch 'obozach' UR i IT. W momencie gdy zespoły zaczynają ze sobą współpracować udaje się wytworzyć rozwiązanie, którym można się pochwalić.

 Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME