Bez widoczności nie ma bezpieczeństwa
W cyberbezpieczeństwie często najwięcej uwagi poświęca się atakom, podatnościom i nowym technologiom ochrony. W praktyce jednak wiele problemów zaczyna się dużo wcześniej od braku pełnej wiedzy o własnym środowisku.
Jeśli nie wiemy, jakie urządzenia pracują w sieci, jak są ze sobą połączone, jakie protokoły wykorzystują i jakie mają podatności, trudno mówić o realnym zarządzaniu ryzykiem. Jeszcze trudniej udowodnić zgodność z wymaganiami regulacyjnymi.
Wystarczy jedno zapomniane urządzenie: kamera, router, panel HMI, sterownik, stacja inżynierska albo czujnik podłączony do sieci. Jeśli nie ma go w dokumentacji, nie jest monitorowany i nikt nie wie, jak powinien się zachowywać, tym samym staje się potencjalną ścieżką dostępu do infrastruktury.
OT to nie IT
Środowiska przemysłowe rządzą się innymi zasadami niż klasyczne IT. W IT cykl życia sprzętu czy systemu operacyjnego często zamyka się w kilku latach. Aktualizacje są częste, łatki bezpieczeństwa wdrażane regularnie, a wymiana urządzenia zwykle nie oznacza zatrzymania produkcji.
W OT wygląda to inaczej. System SCADA, sterownik PLC, serwer OPC czy stacja operatorska mogą pracować przez 10, 15 albo 20 lat. Instalacja, która ma trzy lub pięć lat, często nadal jest traktowana jako relatywnie nowa lub jest wręcz na gwarancji. Aktualizacja systemu może oznaczać przerwę w procesie, testy, udział dostawcy technologii i ryzyko zatrzymania produkcji.
Co z tego wynika? Nie da się po prostu skopiować praktyk z IT. Nie każdą podatność można natychmiast załatać. Nie każde urządzenie pozwala na instalację agenta bezpieczeństwa. Dlatego tak duże znaczenie ma widoczność, monitoring zachowania urządzeń i świadome zarządzanie ryzykiem.
Czym właściwie jest IACS?
W kontekście normy IEC 62443 często pojawia się pojęcie IACS, czyli Industrial Automation and Control System. Warto zatrzymać się przy nim na chwilę, bo dobrze pokazuje, że bezpieczeństwo przemysłowe nie dotyczy wyłącznie sprzętu.
IACS to zbiór ludzi, procesów, sprzętu, oprogramowania oraz polityk związanych z prowadzeniem procesu przemysłowego. Wszystkie te elementy mogą wpływać na to, czy proces działa bezpiecznie, pewnie i niezawodnie.
System sterowania to więc nie tylko PLC i wizualizacja SCADA. To także operatorzy, utrzymanie ruchu, serwisanci, procedury dostępu, konfiguracje urządzeń, dokumentacja, polityki bezpieczeństwa i sieć przemysłowa. Dlatego inwentaryzacja w OT nie powinna ograniczać się do listy adresów IP. Potrzebny jest kontekst: co to za urządzenie, jaką pełni rolę, gdzie pracuje i jaki wpływ miałaby jego awaria.
KSC i IEC 62443 sprowadzają temat do praktyki
Wymagania wynikające z KSC oraz NIS2 coraz mocniej akcentują zarządzanie ryzykiem, obsługę incydentów, raportowanie i odpowiedzialność organizacji. W praktyce oznacza to konieczność uporządkowania obszarów, które wcześniej bywały traktowane fragmentarycznie.
Mówimy między innymi o ciągłym monitorowaniu systemów i infrastruktury, identyfikacji podatności, dokumentowaniu działań, raportowaniu incydentów, gotowości do audytu oraz współpracy z SOC lub innym zespołem odpowiedzialnym za bezpieczeństwo.
Norma IEC 62443 uzupełnia ten obraz od strony przemysłowej. Pokazuje, że bezpieczeństwo systemów automatyki powinno być projektowane i oceniane z uwzględnieniem specyfiki OT. Wprowadza między innymi poziomy bezpieczeństwa, wymagania dotyczące kontroli dostępu, integralności systemu, ograniczania przepływu danych, reakcji na zdarzenia i dostępności zasobów.
Inwentaryzacja jako punkt wyjścia
Nie da się skutecznie zarządzać ryzykiem, jeśli nie wiemy, czego to ryzyko dotyczy. Dlatego pełna inwentaryzacja zasobów jest jednym z fundamentów bezpieczeństwa OT.
Nie chodzi jednak o statyczny arkusz, który raz na jakiś czas ktoś aktualizuje ręcznie. W środowisku, w którym pojawiają się nowe urządzenia, zmieniają się połączenia, dochodzą dostawcy zewnętrzni, a część komunikacji odbywa się protokołami przemysłowymi, taka metoda bardzo szybko traci aktualność.
Dobra inwentaryzacja powinna odpowiadać na kilka praktycznych pytań: jakie urządzenia znajdują się w sieci, które należą do IT, OT, IoT albo systemów niezarządzanych, jakie mają podatności, z czym się komunikują, czy ich zachowanie jest typowe i gdzie znajdują się obszary, których wcześniej nie widzieliśmy.
W praktyce często okazuje się, że organizacja ma w sieci więcej urządzeń, niż zakładała. Pojawiają się elementy pozostawione po modernizacjach, urządzenia serwisowe, stare systemy albo dodatkowe interfejsy. I właśnie te „ciemne miejsca” są jednym z największych problemów.
Monitoring zmian konfiguracji
Sama wiedza o tym, co mamy, to dopiero początek. Równie ważne jest to, co się zmienia.
W środowisku SCADA/PLC zmiana konfiguracji może mieć bardzo różny charakter. Może być planowaną modyfikacją wykonaną przez automatyków. Może wynikać z prac serwisowych. Może być skutkiem błędu. Może też być sygnałem incydentu bezpieczeństwa.
Dlatego monitoring zmian powinien obejmować nie tylko pojawienie się nowego urządzenia w sieci, ale też zmiany w komunikacji, zachowaniu urządzeń, podatnościach, konfiguracji czy relacjach między zasobami.
W praktyce ma to znaczenie zarówno dla bezpieczeństwa, jak i dla utrzymania ruchu. Jeśli wiemy, kiedy pojawiła się zmiana, czego dotyczyła i jakie urządzenia mogła objąć, łatwiej zrozumieć przyczynę problemu. Łatwiej też odtworzyć przebieg zdarzeń podczas audytu lub analizy incydentu.
Ryzyko to nie sama podatność
W cyberbezpieczeństwie łatwo wpaść w pułapkę myślenia, że każda podatność oznacza taki sam poziom zagrożenia. W środowiskach OT to szczególnie niebezpieczne uproszczenie.
Ta sama podatność może mieć zupełnie inne znaczenie w zależności od tego, gdzie znajduje się urządzenie, jaką pełni funkcję i czy jest powiązane z krytycznym procesem. Inaczej oceniamy komputer biurowy, inaczej stację inżynierską, a jeszcze inaczej sterownik odpowiedzialny za fragment linii produkcyjnej.
Ryzyko nie jest więc tylko wynikiem skanowania podatności. Składa się z zagrożenia, podatności i wartości zasobu. Dopiero połączenie tych informacji pozwala odpowiedzieć na pytanie, co naprawdę wymaga pilnej reakcji.
Jedno środowisko, wiele źródeł danych
Współczesne środowiska przemysłowe generują ogromną ilość informacji. Dane mogą pochodzić z firewalli, IDS/IPS, systemów EDR, skanerów podatności, CMDB, systemów zarządzania dostępem, logów, urządzeń sieciowych i narzędzi SOC.
Problemem nie zawsze jest więc brak danych. Często problemem jest ich nadmiar i rozproszenie. Każdy system pokazuje fragment rzeczywistości: ruch sieciowy, podatności, logowania, konfigurację albo incydenty. Jeśli te informacje nie są połączone, administrator nadal nie ma pełnego kontekstu.
Dlatego coraz większe znaczenie mają rozwiązania, które potrafią agregować dane z wielu źródeł, deduplikować je, porządkować i pokazywać w kontekście biznesowym. Właśnie w tym obszarze pojawia się rola platform takich jak Armis.
Widoczność w praktyce na przykładzie Armis
W prezentowanym podejściu Armis pełni rolę platformy, która pomaga budować pełniejszy obraz środowiska. Nie chodzi tylko o wykrycie urządzeń, ale o zrozumienie, czym są, jak się zachowują, z czym się komunikują i jakie ryzyko generują.
System zbiera informacje z różnych źródeł, porządkuje je i wzbogaca o dodatkowy kontekst. Dzięki temu zamiast wielu oderwanych alertów organizacja może zobaczyć spójny obraz zasobów IT, OT, IoT, IIoT, systemów chmurowych czy BMS.
Co z tego wynika? Urządzenie przestaje być tylko adresem IP. Staje się elementem procesu. Można przypisać mu rolę, lokalizację, krytyczność, powiązania i podatności. Można też lepiej ocenić, czy jego zachowanie jest typowe, czy wymaga reakcji.
W środowisku OT ma to bardzo praktyczne znaczenie. Ten sam typ urządzenia może mieć zupełnie inną wagę w biurze i na produkcji. Komputer w sieci biurowej nie oznacza tego samego co stacja inżynierska mająca dostęp do sterowników. Kontekst decyduje o tym, jak interpretujemy ryzyko.
Ale! OT wymaga rozsądnego podejścia
Wdrażanie monitoringu w środowisku przemysłowym musi być dobrze przemyślane. Nie każde rozwiązanie można zastosować w taki sam sposób jak w IT. Nie wszędzie możliwa jest instalacja agentów. Nie wszędzie dopuszczalne jest aktywne skanowanie. Nie każde środowisko może korzystać z rozwiązań chmurowych w takim samym zakresie.
Dlatego przy projektowaniu widoczności OT trzeba uwzględnić ograniczenia procesu, wymagania dostępności, polityki bezpieczeństwa, architekturę sieci oraz akceptowalny poziom ryzyka.
Celem nie jest wdrożenie narzędzia dla samego narzędzia. Celem jest uzyskanie wiarygodnej odpowiedzi na pytania: co mamy, co się zmienia, gdzie jest ryzyko i co powinniśmy zrobić w pierwszej kolejności.
Wniosek?
Inwentaryzacja i monitoring zmian konfiguracji systemów SCADA/PLC to nie tylko techniczny obowiązek i nie tylko element przygotowania do audytu. To fundament realnego bezpieczeństwa środowiska OT.
Bez wiedzy o tym, co znajduje się w sieci, jak się zachowuje, jakie ma podatności i co się zmienia, trudno mówić o zgodności z KSC. Jeszcze trudniej mówić o świadomym zarządzaniu ryzykiem zgodnie z podejściem IEC 62443.
Skuteczne bezpieczeństwo OT zaczyna się od widoczności. Dopiero później przychodzą priorytety, decyzje, procedury, raporty i reakcja na incydenty. Bo nie da się chronić czegoś, o czym nie wiemy, że istnieje.