Cosmos 2612: co zrobił i czego nie da się osiągnąć samym zbliżeniem
Cosmos 2612 wystartował z Plesiecka w kwietniu jako jeden z sześciu rosyjskich satelitów wojskowych. Między 14 a 20 maja pięć z nich zmieniło kurs na płaszczyznę orbity ICEYE-X36. Na przełomie września i października Cosmos 2612 wykonał serię manewrów, które dopasowały go do parametrów X36. To nie był przypadkowy przelot. To była operacja rozłożona na pięć miesięcy.
Według LeoLabs zbliżanie zaczęło się 15 października, a dzień później dystans wynosił już 2–3 km. Chwilami spadał do około 500 metrów, a Orbital Radar podaje 26 metrów (!) 19 października. Między 18 a 19 października Cosmos 2612 zaczął się oddalać. ICEYE ograniczył się do komunikatu, że zna sytuację i ją monitoruje.
Bliski dystans daje atakującemu kilka opcji bezpośrednich: inspekcję optyczną, zbieranie sygnałów, potencjalne zakłócanie łączności z segmentem naziemnym. Każda z nich jest tym więcej warta, im więcej wiedzy ma atakujący. Które częstotliwości przenoszą jaki ruch. Jak wyglądają sekwencje telemetrii. Jak satelita reaguje na anomalie podzespołów.
Jest też opcja pośrednia — w białych rękawiczkach. Satelity nie trzeba niszczyć. Wystarczy go rozstroić: wywołać w mało istotnym podsystemie anomalię, która nie uruchomi alarmu, ale wymusi automatyczną reakcję. Grzałka, która pracuje odrobinę za długo, przyspiesza degradację baterii i elektroniki. Manewry korekcyjne wykonywane za często będą zużywały paliwo. Z zewnątrz wygląda to na naturalne starzenie się satelity. Tak działał Stuxnet w Iranie: wirówki do wzbogacania uranu w Natanz nie wybuchły od razu. Wirus komputerowy przez miesiące zmieniał prędkość ich obrotów, a operatorom pokazywał zapis normalnej pracy. Wirówki psuły się jedna po drugiej i nikt nie wiedział dlaczego. Do zakładu Stuxnet nie dostał się przez internet, tylko przez firmy, które z nim współpracowały. Bronią była automatyka samej ofiary. Warunkiem jest szczegółowa wiedza o tym, jak działa jej oprogramowanie.
Tej wiedzy nie zdobywa się na orbicie. Leży w firmware, dokumentacji projektowej, danych testowych i oprogramowaniu segmentu naziemnego — rozproszonych po łańcuchu dostaw złożonym, często, z dziesiątek firm. Nic w publicznych źródłach nie wskazuje, że w tym przypadku cokolwiek z tego zostało skompromitowane. Ale mechanizm jest czytelny: spotkanie na orbicie to finał procesu zbierania informacji, nie jego początek.
Pytanie o „grzałkę”, czyli rozmowa, do której zmusza A.8.28
Kilka miesięcy wcześniej uczestniczyłem w projekcie ISO/IEC 27001:2022 dla producenta systemów elektronicznych i kosmicznych. Charakter tej pracy zmieniła jedna kontrola: A.8.28, bezpieczne kodowanie. Pytanie „czy macie politykę bezpiecznego rozwoju oprogramowania” zastąpiło pytanie „pokażcie, jak piszecie i przeglądacie kod”. A to oznacza, że audytor siada i rozmawia z zespołem R&D, a nie z właścicielem polityki.
Satelita ma wiele podsystemów. Wiele — z tych wielu — podsystemów z perspektywy bezpieczeństwa wygląda na nieistotne: regulowanie temperatury, zarządzanie zasilaniem, telemetria. Każdy działa na własnym firmware, kilka komunikuje się z segmentem naziemnym.
Na jednej z sesji padło pytanie:
„Jeśli ktoś zbliży się do satelity — powiedzmy na kilkaset metrów — czy mógłby odczytać lub zakłócić pracę niskoenergetycznych interfejsów komunikacyjnych podsystemu grzewczego (czytaj, grzałki), a stamtąd dostać się do czegoś ważniejszego?”
To nie jest pytanie paranoika. To pytanie inżyniera systemów krytycznych, który rozumie attack surface własnego produktu. Najmniej efektowny podsystem ma zwykle najsłabiej przejrzany kod — i największe domyślne zaufanie reszty platformy.
Checklista do takiego pytania nie doprowadzi. Rozmowa z inżynierem tak.
Bezpieczne kodowanie w ISO 27001 chroni łańcuch dostaw, nie satelitę
ISO 27001:2013 dotykało bezpieczeństwa rozwoju oprogramowania przez politykę bezpiecznego rozwoju (A.14.2.1) i zasady bezpiecznej inżynierii systemów (A.14.2.5). Wersja 2022 wydzieliła bezpieczne kodowanie jako osobną kontrolę — A.8.28. Należy ona do grupy A.8.25–A.8.33: od bezpiecznego cyklu rozwoju, przez testy bezpieczeństwa i prace zlecane na zewnątrz, po rozdzielenie środowisk i ochronę danych testowych.
Oczywiście, kontrole z Załącznika A nie obowiązują z automatu każdej organizacji — o ich zastosowaniu decydują ocena ryzyka i uzasadnienie z deklaracji stosowania (SoA). Ale organizacja, która pisze firmware dla statku lecącego na orbitę i wyłącza A.8.28 — mówię w ciemno — będzie miała trudną rozmowę z audytorem. I słusznie zresztą.
Dla dostawcy z sektora kosmicznego pięć kontroli pokrywa się wprost ze ścieżką rozpoznania opisaną wyżej:
- A.8.4 Dostęp do kodu źródłowego — kto ma kod, łącznie z podmiotami zewnętrznymi, i jak szybko można mu ten dostęp odebrać.
- A.8.28 Bezpieczne kodowanie — jak firmware i oprogramowanie naziemne są pisane, przeglądane i testowane pod kątem znanych klas podatności.
- A.8.30 Prace rozwojowe zlecane na zewnątrz — do czego podwykonawca jest zobowiązany umownie i kto to sprawdza.
- A.8.31 Rozdzielenie środowisk — czy środowiska rozwojowe i testowe są oddzielone od produkcji, a zespoły deweloperskie i testowe, także zewnętrzne, nie mają niekontrolowanego dostępu do systemów produkcyjnych.
- A.8.33 Informacje testowe — czy dane produkcyjne trafiające do testów (także u podwykonawców) są chronione tak samo jak na produkcji i usuwane po zakończeniu testów.
Nawet system suwerenny to łańcuch dostaw. W programie POLSARIS segment kosmiczny dostarczył ICEYE, a segment naziemny i infrastrukturę mobilną — Wojskowe Zakłady Łączności nr 1. Co najmniej dwie organizacje, dwie bazy kodu, dwie grupy ludzi z uprzywilejowaną wiedzą.
ISO/IEC 27001:2022 nie chroni więc satelity per se. Chroni ludzi i systemy, które go projektują, programują i obsługują — bo to tam przeciwnik odrabia większość pracy domowej.
O co powinien pytać audyt bezpiecznego kodowania ISO 27001?
Audyt, który traktuje A.8.28 jako kontrolę produktową, a nie dokumentacyjną, zadaje inne pytania. Te ja zadałbym zespołom R&D jako pierwsze:
- Które podsystemy uważacie za nieistotne z punktu widzenia bezpieczeństwa — i dlaczego? Ta lista to punkt wyjścia do modelu zagrożeń, a nie powód, żeby coś z niego wyłączyć.
- Pokażcie ostatni przegląd kodu firmware dla podsystemu o niskim priorytecie. Kto go robił i według jakich kryteriów?
- Gdzie leży kod źródłowy, kto z zewnątrz ma do niego dostęp i kiedy ostatnio ktoś te uprawnienia przeglądał?
- Czego umowa z podwykonawcą wymaga w zakresie bezpiecznego kodowania? Jakie dowody na zgodność podwykonawca faktycznie dostarczył?
- Czy dane testowe i rzeczywiste konfiguracje satelity w środowisku integracyjnym są chronione tak samo jak w produkcji?
Takie pytania zajmują więcej czasu niż sprawdzenie, czy polityka istnieje. Wymagają obecności inżynierów przy stole. Ale tylko one dają ustalenia, które coś znaczą dla produktu — a nie wyłącznie dla utrzymania certyfikatu.
Co z tego wynika dla dostawcy z sektora kosmicznego i obronnego?
Otwórz deklarację stosowania i sprawdź, co stoi za A.8.28. Jeśli polityka i lista obecności ze szkolenia — kontrola daje zgodność na papierze, nie zabezpiecza realnie produktu. Jeśli zapisy z przeglądów kodu, threat modeling, w którym z nazwy pojawia się Twój najmniej efektowny podsystem, i zweryfikowane zrealizowane wymagania bezpieczeństwa po stronie podwykonawców — chronisz to, co faktycznie budujesz.
Cosmos 2612 odleciał po kilku dniach. Wiedza, z którą przyleciał, nie wzięła się z kosmosu. Najlepsze audyty i wsparcie, w jakich brałem udział, to te, w których ktoś zadał pytanie o przysłowiową grzałkę. Jeśli w Twoich nikt go nie zadaje — szukacie w złym miejscu. Albo brakuje Wam kogoś, kto je zada.
Źródła: LeoLabs (za Via Satellite), Orbital Radar oraz analiza Marco Langbroeka; szacunki odległości różnią się między źródłami. Numeracja kontrolek według ISO/IEC 27001:2022.