Nasze holistyczne rozwiązanie dla kwestii naruszeń bezpieczeństwa i błędów funkcjonalnych

Wiele organizacji przemysłowych nadal uważa bezpieczeństwo cybernetyczne firmowych systemów IT i OT (technologia operacyjna) za kwestię unikatową. Przedsiębiorstwa często zajmują się nią w izolacji. To prawda, że działy IT przedsiębiorstw strukturalnie i funkcjonalnie różnią się pomiędzy wydziałami ds. zabezpieczeń i systemów SCADA. Potrzeba konwergencji staje się więc jeszcze bardziej krytyczna. W nowej erze coraz większych i coraz powszechniejszych zagrożeń cybernetycznych, zmiany strukturalnej nie można już postrzegać w kategorii możliwości do rozważenia lub opcji. Przeciwnie: konwergencja pomiędzy dwiema sferami musi stać się celem o znaczeniu krytycznym.

Skuteczne środki bezpieczeństwa wymagają integracji specjalistów ds. bezpieczeństwa cybernetycznego, inżynierów systemów OT, a także personelu pomocniczego za pośrednictwem wspólnych celów szkoleniowych i wspólnej platformy pojęciowej.  

Nasze rozwiązanie StationGuard

Zespół OMICRON wziął konkretne procesy i priorytety rządzące środowiskiem OT i połączył je ze zdolnością do identyfikacji, przyswojenia i skorelowania danych zagrożenia i problemów funkcjonalnych, aby uzyskać centralny system zarządzania. Ten system zarządzania jest zbudowany zgodnie z wymaganiami zarówno informatyków, jak i energetyków.
 

„Nadszedł czas, aby przenieść zespoły IT i OT na znajome boisko”.

- Amro Mohamed, Regionalny specjalista ds. sprzedaży cyberbezpieczeństwa

Nasz system wykrywania nieautoryzowanego dostępu (IDS) StationGuard wykrywa cały zabroniony lub potencjalnie niebezpieczny ruch w systemie Twojej nastawni, stacji i elektrowni. Na przykład jest możliwość importu plików konfiguracyjnych w celu automatycznego nadania uprawnień komunikacyjnych i przypisania ról do urządzeń w oparciu o ich przeznaczenie. Następnie StationGuard generuje alert, który zawiera następujące informacje: kategoria, źródło i cel, zwięzły opis, a także przybliżony czas wystąpienia zdarzenia.
 
Aby lepiej zrozumieć alerty zdarzeń, specjaliści ds. bezpieczeństwa i energetycy muszą pracować razem. Wyłącznie inżynierowie odpowiedzialni za stację, zakład lub sterownię wiedzą, co powinno robić, a czego nie powinno robić każde urządzenie. Kluczowa różnica pomiędzy naszym rozwiązaniem a innymi tkwi w tym, jak dobrze te opisy odzwierciedlają rzeczywistą przyczynę problemu w sieci energetycznej. W efekcie, inżynierowie zajmujący się zabezpieczeniami i specjaliści ds. IT będą dobrze rozumieć się podczas rozmowy o problemie i urządzeniach, których problem dotyczy – komunikacja staje się bardziej efektywna.

Skorzystaj z tego łącza, aby poznać wszystkie korzyści płynące z naszego rozwiązania StationGuard i jego funkcji.

StationGuard

Przyjrzyjmy się bliżej wyróżniającym cechom naszego rozwiązania StationGuard. Rozważmy przykładowy scenariusz przejętego serwera archiwalnej bazy danych, który komunikuje się ze złośliwym oprogramowaniem w elektrowni lub stacji.

Nasze rozwiązanie potrafi odpowiedzieć na następujące pytania dotyczące każdego zdarzenia:

Do jakiego naruszenia bezpieczeństwa doszło w Twoim systemie?

Zaczynając od pulpitu alertów GridOps, zbadamy alert, który zgłosił czujnik systemu IDS StationGuard, znajdujący się w stacji o nazwie „Munich North”.

Integralną częścią naszego rozwiązania StationGuard jest pulpit alertów GridOps. Jego głównym celem jest podsumowanie informacji o tym, co dokładnie stało się w Twoim systemie.

Używamy widoku na poziomie czujników, aby dokładniej zbadać dany alert i jego otoczenie sieciowe w sposób pokazany poniżej.

W obrębie pulpitu możesz przejść z widoku ogólnego na poziomie sieci energetycznej do widoku sieci konkretnego zakładu, stacji lub sterowni. Zapewni Ci to przejrzysty obraz konkretnego alertu.

Każdy alert jest rozpatrywany w szerszym kontekście, co pomoże Ci zrozumieć charakter zdarzenia i zapobiec incydentowi.

System IDS StationGuard wykrył anormalną aktywność i zgłosił ten fakt. Interfejs HMI nadał nieoczekiwany ruch sieciowy typu „Socks” do zewnętrznego serwera archiwalnej bazy danych przez router w stacji. Z perspektywy stacji widzimy komunikację pomiędzy interfejsem HMI i routerem z siecią WAN. Archiwalna baza danych znajduje się za routerem. Z tej perspektywy, router jest więc aktorem.

Możesz badać problemy z zabezpieczeniami i problemy funkcjonalne w czasie rzeczywistym, wyświetlając pulpit czujników systemu IDS na poziomie sieci i naszą unikatową wizualizację sieci przydatną zarówno dla ekspertów w dziedzinie IT, jak i OT. Szczegóły wiadomości w dzienniku zdarzeń dostarczają dalszych informacji, na przykład, o zaangażowanych urządzeniach, adresach MAC/IP, użytych aplikacjach, protokołach itp.

Uwaga: utrzymywanie połączenia pomiędzy interfejsem HMI a zewnętrzną archiwalną bazą danych jest dość powszechne. W tym systemie to połączenie oparto na systemie MySQL, dlatego też połączenie MySQL umieszczono na białej liście dla interfejsu HMI. Zezwolenie to zostało teraz naruszone, ponieważ komunikację zmieniono na połączenie Socks wykorzystujące te same numery portów. Przyczyną tego zdarzenia mogła być złośliwa aplikacja zainstalowana w interfejsie HMI i/lub w zewnętrznej archiwalnej bazie danych.  
Zawsze, gdy StationGuard wyświetla w alercie informacje o aktorze (router) lub ofierze (HMI), jest pokazywana aktualna nazwa urządzenia, a w komunikacie alarmowym jest wyświetlana najwyższa zidentyfikowana warstwa modelu OSI. W tym przypadku zidentyfikowano aplikację „Socks”. „Socks” to aplikacja proxy, która służy do przekierowywania komunikacji poprzez urządzenie strony trzeciej w celu ułatwienia komunikacji przez zaporę sieciową. Może być to przydatne w środowisku IT, ale aplikacja ta jest również wykorzystywana przez osobę atakującą do tworzenia tuneli eksfiltracji danych lub do nawiązywania połączenia z serwerem Command & Control. Ta technika została najprawdopodobniej użyta w 2016 roku podczas ataku cybernetycznego „Industroyer” na Ukrainie.

Kiedy miało miejsce naruszenie bezpieczeństwa? 

Każdy alert zawiera przybliżony czas wystąpienia zdarzenia, a także czas ostatniej aktualizacji z dodanymi informacjami o aktywności. Ostatni znacznik czasowy najczęściej odzwierciedla więc czas trwania aktywności. Może on wahać się od kilku mikrosekund w przypadku komunikacji wewnątrz urządzenia do kilkudziesięciu sekund, na przykład w przypadku poleceń rozdzielni.

Alert w naszym systemie pojawił się 2022-05-10 19:43:01.607 UTC, przesunięcie +03:00.  

Alerty są często wyzwalane, gdy na miejscu są obecni inżynierowie przeprowadzający konserwację lub badania okresowe. W szczegółach można również znaleźć informacje o tym, czy alert wykryto podczas normalnej pracy, czy podczas konserwacji.
  
W tym przypadku aktywność wystąpiła podczas normalnej pracy. Gdy doszło do zdarzenia, na miejscu nie był obecny żaden zespół inżynierów. Stąd pozycja „Occurred during maintenance” (Wydarzyło się podczas konserwacji) przyjmuje wartość „No” (Nie).

Gdzie w Twojej sieci miało miejsce to zdarzenie?

GridOps przede wszystkim zapewnia nam pulpit z listą urządzeń, który maksymalizuje widoczność w sieci energetycznej. Na schemacie sieci są pokazane zarówno aktor, jak i ofiara, które znaleziono na poziomie sterowania stacją, odpowiadające poziomowi 2 na modelu Purdue, co widać na poniższym mapowaniu.

Dzięki opieraniu się na spisie urządzeń i mapowaniu topologii w czasie rzeczywistym, każdy alert wyświetlany na pulpicie alertów GridOps będzie zawierał informacje na temat źródła zdarzenia i zakładu, w którym doszło do zdarzenia.

Kto miał udział w zdarzeniu?

StationGuard wykorzystuje podejście oparte na białej liście, aby wykrywać podejrzany lub zabroniony ruch, więc pierwotnie zdefiniowaliśmy i zatwierdziliśmy każdą komunikację pomiędzy wszystkimi urządzeniami w stacji.
  
Te informacje można importować do systemu StationGuard, z pliku SCD (opis konfiguracji stacji) wg IEC 61850, który można wyeksportować z narzędzi inżynierskich lub z arkuszy kalkulacyjnych, które dokumentują konfigurację sieci.

Alert pokazuje, że ruch jest niezatwierdzony. Znaleźliśmy aktora wewnętrznego, który jest powiązany z incydentem. Adres IP aktora to 192.168.1.123, a adres IP celu to 192.168.1.200.

Aby umożliwić efektywną komunikację pomiędzy specjalistami ds. bezpieczeństwa a inżynierami zajmującymi się systemami SCADA, GridOps wyświetla nazwy techniczne wszystkich urządzeń, a nie tylko adresy IP. Nazwy te można importować z plików technicznych i arkuszy kalkulacyjnych.
 
W każdym alercie generowanym przez StationGuard są wyróżnione jednostki, które stanowią przyczynę lub mają swój udział w zdarzeniu, typy urządzeń, których dotyczy zdarzenie, kto jest aktorem i kto został zidentyfikowany jako cel.
  
Teraz możemy z łatwością odczytać poziom napięcia, pole i nazwy urządzeń, które miały swój udział w zdarzeniu.

W jaki sposób dokonano naruszenia bezpieczeństwa?

Odkryliśmy, że osoba atakująca próbowała nawiązać połączenie proxy Socks na tym samym porcie, który jest używany przez połączenie MySQL (port TCP 3306).

Każdy alert generowany przez StationGuard będzie zawierać wgląd w charakter czynności, sposób przeprowadzenia czynności, a także to, co aktor zrobił, aby spowodować dany skutek. Incydent jest powodowany przez co najmniej jedną czynność, ale większość z nich będzie obejmować wiele czynności.

Dlaczego system IDS w ogóle wygenerował alert?

Pozostaje kilka pytań:  

  • Dlaczego system IDS wygenerował alert w tej sytuacji? 
  • Które zezwolenia na komunikację lub zasady postępowania zostały naruszone? Dlaczego zezwolenia na komunikację ustawiono w ten sposób? 
  • Dlaczego nie była to uzasadniona komunikacja urządzenia źródłowego?
  •  

StationGuard wizualizuje, która komunikacja jest dozwolona; wszystko inne jest domyślnie zabronione. Widzimy, że znajduje się tu dozwolone połączenie, poprzez ruter, pomiędzy interfejsem HMI a serwerem archiwalnej bazy danych. Dodatkowo aplikacja „MySQL” została umieszczona na białej liście dla tego połączenia; alert został wygenerowany, ponieważ nie była to już aplikacja MySQL. 
 
Na końcu Pomoc systemu StationGuard podpowiada nam problemy, które mogły spowodować ten incydent. Pomoc zawiera wytyczne krok po kroku, odnoszące się do wszystkich wymienionych wcześniej pytań typu dlaczego. Punktem wyjściowym naszego śledztwa jest alert. W tym momencie najbardziej interesują nas następujące pytania: 
Pytanie: Czy jest to inne połączenie z usługą na nowym numerze portu (po stronie serwera), czy też zmieniła się aplikacja operująca na tym samym połączeniu?  
Odpowiedź: Odkryliśmy, że zachodzi ten drugi przypadek. Numer portu docelowego był ten sam, ale warstwa aplikacji zmieniła się z MySQL na Socks. Ta czynność wydaje się podejrzana.
Pytanie: Czy do wszystkich odpowiednich urządzeń są przypisane właściwe role? Czy istnieje funkcja tego urządzenia, która wcześniej nie była używana?  
Odpowiedź: To pytanie wymaga wiedzy z zakresu OT dotyczącej urządzenia i jego przeznaczenia. Zaangażowani inżynierowie zajmujący się systemami OT potwierdzili, że od interfejsu HMI nie oczekiwali żadnego połączenia wychodzącego oprócz połączenia z bazą danych.

Podtrzymuje to teraz podejrzenie, że takie zachowanie mogło być spowodowane przez złośliwe oprogramowanie w interfejsie HMI. StationGuard rejestruje zapisy każdego zdarzenia w sieci. Zapisujemy ten dowód i kontaktujemy się z dostawcą interfejsu HMI. 

Kontekst alertu pomoże Ci precyzyjnie określić, dlaczego incydent był w ogóle możliwy. Takie informacje są pomocne na wielu poziomach – na przykład dla oceny niedoskonałości sterowania bezpieczeństwem i wrażliwości urządzeń, a także przy określaniu strategii łagodzących.

W powyższym fikcyjnym przykładzie udokumentowaliśmy możliwy łańcuch reakcji: od wykrycia podejrzanego zachowania interfejsu HMI w stacji, do wyśledzenia infekcji złośliwym oprogramowaniem na tym urządzeniu HMI. Pojedyncze zastosowanie posłużyło nam do zilustrowania sposobu, w jaki system StationGuard, w połączeniu z komponentem GridOps, umożliwia wykrywanie, śledzenie, wizualizację i analizę podejrzanych zachowań w sieciach OT systemu elektroenergetycznego. Gdy przychodzi do odpowiadania na pytania co, kiedy, gdzie, kto, dlaczego i jak dotyczących incydentów bezpieczeństwa, nasz ujednolicony interfejs pozwala na skuteczną współpracę pomiędzy informatykami i ekspertami ds. systemów OT – dzięki temu można w pełni wykorzystać ich połączone zdolności.

 

Powiązane zrzuty ekranu

Co się stało – Pulpit alertów GridOps
Co się stało – Widok schematu sieci na poziomie czujników pokazujący sieć stacji
Kiedy to się stało – Szczegóły alertu
Gdzie to się stało – Schematy mapowania sieci stacji na architekturę referencyjną Purdue
Kto miał w tym udział – Szczegóły dotyczące urządzeń źródłowych i docelowych, których dotyczy alert
Jak to się stało – Szczegóły dotyczące wykrytej aplikacji i numerów portów tego połączenia
Dlaczego to się stało – Biała lista zezwoleń na komunikację dla połączenia z bazą danych

Rozbuduj swój system StationGuard o nasz komponent GridOps

Komponent GridOps do systemu StationGuard to rozwiązanie centralne, zapewniające podejście holistyczne do wielu zadań operacyjnych w cyfrowej sieci energetycznej, zaczynając, w pierwszym etapie, od operacji w zakresie bezpieczeństwa i funkcji spisu urządzeń. Od analizy alertów bezpieczeństwa do spisu urządzeń i zarządzania podatnościami GridOps jednoczy inżynierów zajmujących się zabezpieczeniami i specjalistów w dziedzinie IT w aplikacji dla pojedynczego zespołu. Pozwala on ekspertom ds. bezpieczeństwa informatycznego poszerzyć spojrzenie na kwestię bezpieczeństwa cybernetycznego sieci o wiedzę z zakresu OT, a inżynierom systemów OT umożliwia uczestnictwo w operacjach związanych z bezpieczeństwem cybernetycznym sieci w środowisku, które dobrze znają.

Główne funkcje GridOps
GridOps oferuje funkcje o szerokich możliwościach, które pomagają w operacjach związanych z bezpieczeństwem systemu elektroenergetycznego. Możesz... 

  • centralnie zarządzać wszystkimi czujnikami systemu IDS StationGuard i sprawdzać bieżący stan zagrożenia; 
  • korzystać z zaawansowanych analiz i statystyk alertów; 
  • globalnie zarządzać swoim spisem urządzeń i otrzymywać powiadomienia o wykrywanych urządzeniach; 
  • korzystać z cennego wykrywania słabych punktów i wspomagać swoje przebiegi pracy związane z zarządzaniem ryzykiem oraz 
  •  

Globalny spis urządzeń  
Z łatwością śledź wszystkie wykryte urządzenia i zmiany konfiguracji oraz utrzymuj aktualną listę urządzeń publikowaną przez czujniki StationGuard rozmieszczone w całej sieci.

Pulpit alertów
Przeglądaj stany wszystkich alertów we wszystkich zakładach i wizualizuj stan swoich zabezpieczeń.

Widok sieci na poziomie czujników  
Przechodź od ogólnego przeglądu na poziomie sieci energetycznej do widoku konkretnych sieci sterowni, elektrowni lub stacji, aby uzyskać przegląd alertów.


Kliknij link i odkryj wszystkie zalety naszego komponentu GridOps, który oferuje dwie dodatkowe korzyści: spis urządzeńzarządzanie podatnościami.

Odkryj więcej artykułów OMICRON

Posłuchaj naszych podcastów

września 22, 2022

CIGRE 2022 Impressions ǀ Part 2

with Aby-Gael Meyet, Iris Fischer and lots of experts in the industry

Episode 40 - Energy Talks

września 13, 2022

CIGRE 2022 Impressions ǀ Part 1 with Philippe Adam

with Philippe Adam, Secretary General CIGRE

Episode 39 - Energy Talks

sierpnia 23, 2022

Monitoring Partial Discharge – On a Temporary Basis

with Bogdan Gorgan & Patrick Zander

Episode 38 - Energy Talks

You are using an outdated browser version.
Please upgrade your browser or use another browser to view this page correctly.
×