#CyberMagazyn: Bezpieczeństwo ICS/OT. Jak chronić infrastrukturę krytyczną?

Autor. Freepik.com
Bezpieczeństwo ICS/OT jest kluczowe dla naszego codziennego funkcjonowania. Dotyczy ono m.in. kolei, motoryzacji czy szeroko rozumianej energetyki. Podczas czwartej edycji CyberTek Tech Festival eksperci przytoczyli wiele ciekawych i ważnych kwestii związanych z automatyką przemysłową.
W dniach 27-29 maja w Katowicach odbyła się konferencja CyberTek Tech Festival. Wydarzenie jest szczególnie ważne dla osób związanych z przemysłowymi systemami sterowania. Muzeum Śląskie gościło wielu ekspertów oraz przedstawicieli biznesu.
Zakres tematyczny prelekcji był szeroki – na scenie omawiano m.in. cyberbezpieczeństwo na morzu, bezpieczeństwo farm wiatrowych, zabezpieczenia w sektorze kolejowym, rolę audytów czy tworzenie Security Operation Center (SOC) dla OT (technologii operacyjnej).

Autor. Rafał Paluszek
Czytaj też
Coś dla każdego
Każdy z nas ma różne zainteresowania oraz poziom umiejętności. Bardzo ciekawą prelekcję pod kątem zastosowań w prawdziwych środowiskach wygłosił Maciej Kosz, IT Security Officer w Vattenfall, który opisał rolę otwartoźródłowego oprogramowania (ang. open-source) w monitorowaniu bezpieczeństwa OT. Prezentacja zawierała m.in. praktyczne dema pokazujące możliwości szczegółowej analizy pakietów protokołów wykorzystywanych przez urządzenia automatyki przemysłowej (np. modbus).
Interesujący punkt widzenia przedstawił Łukasz „r02Id” Nowatkowski, który przybliżył m.in. skutki ataków na systemy rozliczeniowe. Na bazie prawdziwych incydentów wykazał, że fikcyjna zmiana odczytów urządzeń (np. IoT czy w systemach SCADA) może doprowadzić do realnych skutków dla użytkowników w postaci np. przestoju w tankowaniu paliwa. Opisał też najczęstsze wektory ataków.

Autor. Rafał Paluszek
Czytaj też
Kolej, czyli dualizm bezpieczeństwa
Ciekawą prelekcję pt. „Cyberbezpieczeństwo systemów kolejowych – niełatwa sztuka godzenia światów safety i security” wygłosili Marek Kuciński i Krystian Papiernik z voestalpine. Pomimo tego, że zarówno „safety” i „security” oznaczają bezpieczeństwo, ich znaczenie dla systemów kolejowych jest zgoła inne.
Eksperci podkreślili m.in. rolę wsparcia zarządu w procesach związanych z bezpieczeństwem. W rozmowie z nami Marek Kuciński przybliżył tematykę związaną z „safety” i „security”

Autor. Oskar Klimczuk / CyberDefence24 / CyberTek Tech Festival
Oskar Klimczuk, CyberDefence24: Czym różni się security od safety w kontekście kolei?
Marek Kuciński, Product Security Manager w voestalpine Signaling Poland: Zacznijmy od definicji. Z góry przepraszam za angielszczyznę, ale w języku polskim mamy tylko „bezpieczeństwo”, a tak naprawdę potrzebne są nam dwa słowa: safety i security.
Safety to stan systemu, w którym jest on wolny od nieakceptowalnego ryzyka. W security jest bardzo podobnie, lecz dotyczy to nieakceptowalnych zagrożeń. Same definicje brzmią bardzo podobnie, natomiast trzeba powiedzieć, czym różni się ryzyko (ang. risk) od zagrożenia (ang. threat).
Mówiąc najprościej i bezpośrednio – w ramach safety to my chronimy ludzi, świat, środowisko przed naszym systemem. Chodzi o to, aby w razie jego awarii nikomu nic się nie stało; żeby nie doszło do skażenia środowiska, strat finansowych czy wizerunkowych.
Można powiedzieć, że w security odwracamy tę logikę, czyli chronimy nasz system przed celowym, złośliwym działaniem ludzi. Mimo tego, że definicje wyglądają bardzo podobnie, cele „safety” i „security” bywają przeciwstawne. Dlatego ich pogodzenie w jednym systemie jest sporym wyzwaniem.
Pamiętajmy, że na przysłowiowy koniec dnia chodzi o to, aby systemy działały przede wszystkim bezpiecznie, a zarazem nieprzerwanie i efektywnie.
Jak te dwa zagadnienia na siebie bezpośrednio oddziałują?
W wielu prezentacjach mówi się, że safety to jądro obliczeniowe, które ma mieć zapewniony „spokój” do zgodnej z oczekiwaniami, zaufanej i nieprzerwanej pracy. Security to są te „ściany budynku”, schron, który chroni safety przed zewnętrznym wpływem.
U podstaw konstruowania systemów safety leżało założenie, że nie są one poddawane celowemu złośliwemu działaniu z zewnątrz. Tak długo jak pracują w warunkach przewidzianych przy projektowaniu i w dokumentacji, zapewniają stabilny poziom bezpieczeństwa przez cały cykl życia. Można powiedzieć, że system będzie wykonywał swoje zadania dopóki nikt mu w tym nie będzie przeszkadzał. Dopiero kilka lat temu dostrzeżono, że warunkiem koniecznym do działania systemów safety jest ich ochrona przed tymi zewnętrznymi, złośliwymi wpływami.
W dobie obecnej sytuacji geopolitycznej i znaczenia zagrożeń security - musimy dołożyć dodatkową warstwę ochronną. To już nie czas na myślenie „być może warto”. Temat stał się pilny i ważny. Zagrożenia z zewnątrz, czy to sieciowe czy bardziej fizyczne, zawsze powiązane z celowym, złośliwym działaniem człowieka, nie mogą wpływać na safety – na jądro, które nadal może zakładać, że jest odizolowane od świata zewnętrznego.
Sztuką jest tak dokładać te warstwy zabezpieczeń aby nie wprowadzić jednocześnie utrudnień dla integratorów i użytkowników – zarówno operacyjnych, proceduralnych czy technicznych. Warto zaznaczyć, że przy odpowiednio wczesnym uwzględnieniu potrzeb z zakresu security - już na etapie wymagań czy projektowania - może się to odbyć z kontrolowanym i przewidywalnym wpływem na koszty czy terminy dostaw. Podejście to promuje tak popularne ostatnio hasło „shift left security”.
Jaka jest rola analizy ryzyka oraz norm i procedur w kontekście security oraz safety?
Uważam, że analiza ryzyka jest początkiem wszystkiego. Tak naprawdę to od niej zaczyna się szukanie najsłabszych ogniw. Pozwala też systematycznie podejść do całego tematu, czyli interfejs po interfejsie, system po systemie, zagrożenie po zagrożeniu.
Dokładnie tak zrobiliśmy w trakcie naszego projektu. Zdefiniowaliśmy granice naszego systemu, spisaliśmy wszystkie interfejsy, katalog zagrożeń - m.in. spoofing (podszywanie się – przyp. red.) czy tampering (manipulowanie wartościami sensorów – przyp. red.) itd. Zadaliśmy sobie pytanie: „Co by się stało jakby na tym interfejsie doszło do spoofingu?”.
Ze względu na specyfikę naszych produktów (sterowanie ruchem kolejowym – przyp. red.), często w wynikach analizy pojawiał się efekt „katastrofa kolejowa” – od razu na czerwono w analizie, trzeba przeciwdziałać. Jeden po drugim identyfikowaliśmy słabe punkty systemu, stosowaliśmy najbardziej adekwatne znane metody ich ograniczenia. Trudno o kompromisy, jeśli mówimy o bezpieczeństwie ludzi.
Tak naprawdę gdyby nie kompleksowa analiza ryzyka, moglibyśmy się chwalić jakie mamy np. certyfikaty, klucze prywatne, algorytmy szyfrowania „post-quantum” a na koniec ktoś powiedziałby: „A ten guzik to do czego służy?”. Usłyszałby tylko: „Tego w analizie nie zawarliśmy. Poza tym tego nie wolno robić!”. Nie tędy droga. Systematyczność podejścia, podparta procedurami i procesami, daje nadzieję, że nie zostawiliśmy żadnych „otwartych wrót” dla adwersarzy.
W tym kontekście normy i standardy pozwalają metodycznie do podejść do wyzwania. Nie trzeba się zastanawiać jakie dokumenty należy opracować czy jakie analizy wykonać – to wszystko jest opisane, można powiedzieć, że podane na tacy. W naszej branży IEC62443, TS50701 (za chwilę jako IEC63452) czy System Pillars są świetną podstawą do wykonania tych zadań. Czas wykorzystany na ich poznanie i wdrożenie powinniśmy traktować jako inwestycję w spokojny sen w przyszłości.
Dziękuję za rozmowę.
Czytaj też
Ważna debata
Holistycznie o bezpieczeństwie ICS/OT rozmawiano pod koniec drugiego dnia wydarzenia. W panelu dyskusjnym „Zdrowy rozsądek w natarciu, czyli cyberbezpieczeństwo przemysłu w praktyce” uczestniczyło jedenastu ekspertów, pochodzących z wielu różnych sektorów.

Autor. Oskar Klimczuk / CyberDefence24
Wśród poruszonych zagadnień znajdowały się m.in.:
- unikanie spełniania regulacji NIS2 przez przedsiębiorstwa;
- brak możliwości aktualizowania firmware'u w niektórych urządzeniach;
- rola producenta w publikowaniu aktualizacji oprogramowania na przestrzeni kilku – kilkunastu lat;
- nieustanne zmiany regulacji oraz chęć przedsiębiorstw do partnerstwa organów państwa zamiast jedynie karania;
- podkreślenie dłuższego cyklu życia sprzętów OT niż IT;
- zdalny dostęp – aktualizacje oraz możliwe zagrożenia;
- konieczność ponownej certyfikacji przy zmianie firmware'u – np. w pociągach;
- bezpieczeństwo łańcucha dostaw;
- testowanie planu ciągłości działania w praktyce na przykładzie ewakuacji z budynku;
- regulacje (m.in. RODO, NIS2) jako segregatory, nie realne zmiany;
- kwestia braku „właścicieli ryzyka".
Pomimo pojawiania się czasem rozbieżnych stanowisk, rozmowa była owocna.
Czytaj też
Czytaj też
Serwis CyberDefence24.pl otrzymał tytuł #DigitalEUAmbassador (Ambasadora polityki cyfrowej UE). Jeśli są sprawy, które Was nurtują; pytania, na które nie znacie odpowiedzi; tematy, o których trzeba napisać – zapraszamy do kontaktu. Piszcie do nas na: [email protected].
Operacje Wojska Polskiego. Żołnierze do zadań dużej wagi
Materiał sponsorowany