"Myślałem, że od czasów Stuxnet świat wyciągnął wnioski. "
@sprae czytający o stanie bezpieczeństwa urządzeń przemysłowych. 2024, drozdowane:
“Że jak chcesz coś zmienić musisz przełączyć urządzenie w odpowiedni tryb, co pociąga za sobą przełączenie infrastruktury i powiadomienia odpowiednich osób.”
Urządzenia Schneidera miały/mają coś takiego. Jak chcesz coś zmienić w urządzeniu, to musisz podejść do niego i takim fizycznym kluczem przestawić w tryb programowania. Tylko jest mały problem. Dopóki takie sterowniki są np na terenie jednego zakładu przemysłowego to możesz się przejść albo poprosić kogoś o przestawienie w tryb programowania. Problem jest wtedy gdy urządzeń jest wiele i są rozsiane po dużym terenie. No więc personel zarządzający tymi sterownikami po prostu cały czas używał ich w trybie programowania. Wykorzystał to malware Triton. Oto poszlaki https://cloud.google.com/blog/topics/threat-intelligence/attackers-deploy-new-ics-attack-framework-triton/
Wygląda jak stare komputery z panelem czołowym do programowania i debugowania.
Temat jest fajną inspiracją do przemyśleń o tym jak sam bym to próbował rozwiązać. Dużo się zastanawiałem nad tym. Jak odcinać komunikację do zmiany parametrów? Jak weryfikować firmware? Jak rozgłaszać zmianę stanu? Gdzie powinien być kompromis wygody? Myślałem raczej o urządzeniach do których musisz podejść jako technik. Bo ich zmiana może być niebezpieczna. Wywoływać straty na dużą skalę.
Na końcu wyszło mi, że miałeś rację i taniej rozwiązują to pewnie dalsze urządzenia, które niezależnie weryfikują pracę i parametry.
Ale ta rozkmina zawsze może się przydać w innych dziedzinach.
"Myślałem, że od czasów Stuxnet świat wyciągnął wnioski. "
@sprae czytający o stanie bezpieczeństwa urządzeń przemysłowych. 2024, drozdowane:
“Że jak chcesz coś zmienić musisz przełączyć urządzenie w odpowiedni tryb, co pociąga za sobą przełączenie infrastruktury i powiadomienia odpowiednich osób.”
Urządzenia Schneidera miały/mają coś takiego. Jak chcesz coś zmienić w urządzeniu, to musisz podejść do niego i takim fizycznym kluczem przestawić w tryb programowania. Tylko jest mały problem. Dopóki takie sterowniki są np na terenie jednego zakładu przemysłowego to możesz się przejść albo poprosić kogoś o przestawienie w tryb programowania. Problem jest wtedy gdy urządzeń jest wiele i są rozsiane po dużym terenie. No więc personel zarządzający tymi sterownikami po prostu cały czas używał ich w trybie programowania. Wykorzystał to malware Triton. Oto poszlaki https://cloud.google.com/blog/topics/threat-intelligence/attackers-deploy-new-ics-attack-framework-triton/
Wygląda jak stare komputery z panelem czołowym do programowania i debugowania.
Temat jest fajną inspiracją do przemyśleń o tym jak sam bym to próbował rozwiązać. Dużo się zastanawiałem nad tym. Jak odcinać komunikację do zmiany parametrów? Jak weryfikować firmware? Jak rozgłaszać zmianę stanu? Gdzie powinien być kompromis wygody? Myślałem raczej o urządzeniach do których musisz podejść jako technik. Bo ich zmiana może być niebezpieczna. Wywoływać straty na dużą skalę.
Na końcu wyszło mi, że miałeś rację i taniej rozwiązują to pewnie dalsze urządzenia, które niezależnie weryfikują pracę i parametry.
Ale ta rozkmina zawsze może się przydać w innych dziedzinach.