Zapraszamy do lektury pierwszego wydania OTnośnika – cyklicznego biuletynu z komentarzami ekspertów Tekniska! Piotr Urbańczyk (SCADA Security Architect Tekniska) komentuje artykuł „Siemens, Motorola, Honeywell and more affected by 56 ‘ICEFALL’ vulnerabilities”.
Producenci systemów automatyki dość niechętnie podchodzą do cyberbezpieczeństwa i dość wolno – jeśli w ogóle – publikują aktualizacje. Z drugiej strony mamy właścicieli ICS, którzy borykają się ze swoimi problemami: brakiem specjalistów, przeciążeniem zespołów, względami ekonomicznymi czy procesowymi. Z trzeciej strony badanie pokazuje, że – pomimo problemów bezpieczeństwa – podatne na ataki urządzenia są wciąż certyfikowane przez różne standardy do pracy w przemyśle.
Argumentacje stron są zbieżne i wynikają z historycznego podejścia do automatyki, jako wydzielonego systemu. Argumenty, takie jak „musimy zapewnić kompatybilność ze wcześniejszą wersją rozwiązania” czy „nakładanie łatek na systemy ICS jest ryzykowne”, są podnoszone ze wszystkich stron i nawet my na szkoleniach je wykorzystujemy, wskazując je jako ograniczenia w procesie bezpieczeństwa. Oczywistym jest, że nikt przy zdrowych zmysłach nie będzie aktualizował oprogramowania sterownika podczas jego normalnej produkcyjnej pracy, bo wiąże się to ze sporym ryzykiem dla procesu, a przez to dla środowiska i ludzi mających styczność z procesem. Niemniej jednak prawdą jest, że ta argumentacja jest wygodna – a wiadomo, że wygoda jest wrogiem bezpieczeństwa.
Każdy system – nawet ten działający w trybie ciągłym – co jakiś czas musi być serwisowany. Elementy mechaniczne są przeglądane, wymieniane lub naprawiane. Zajmuje to czas i kosztuje pieniądze, jednak jest widziane jako niezbędne dla poprawnego działania procesu. Z elementami oprogramowania często się tak nie dzieje. Wiąże się to ze swoistym tabu, które można wyrazić maksymą „jeśli to działa, to nie dotykaj”. Prawdą jednak jest, że u podłoża tego problemu jest brak pewności po stronie producentów i użytkowników, czy aktualizacja bezpieczeństwa nie zaburzy poprawnej pracy systemu. Argumentem podnoszonym przez użytkowników końcowych i producentów jest również kwestia ekonomiczna. Urządzenia działające w sieciach przemysłowych działają od dziesiątek lat i wdrażanie nowego kodu na tych urządzeniach może wiązać się z koniecznością częstszej ich wymiany.
Badanie cytowane w artykule wskazuje na podatności rozwiązań sporej liczby producentów i robi to celnie. Głównym jego przesłaniem jest pokazanie łatwości ataku na sieci przemysłowe wykorzystujące te rozwiązania. Ma ono za zadanie wymusić działania po stronie producentów zapewniające tworzenie bezpiecznych produktów – w tym gwarantujące dostępność poprawek dla zarówno wskazanych w artykule, jak i nowych, jeszcze nieznanych podatności. Ma również zachęcić użytkowników końcowych do wyboru bezpiecznych rozwiązań do swoich sieci.
W świetle pojawiających się nowych zagrożeń dla sieci przemysłowych, takich jak nowe, złośliwe oprogramowanie celujące właśnie w ICS (Incontroller, Triton lub Industroyer2), wnioski i przesłanie artykułu oraz badania są jak najbardziej właściwe. Czas pokaże, czy ścieżka ta zostanie obrana teraz czy dopiero po skutecznych atakach na istotne gałęzie przemysłu.