Redakcja
Co by się stało, gdyby następny atak ransomware na terytorium Stanów Zjednoczonych wiązał się z bronią jądrową? Jakie środki podejmowane są w celu zapewnienia, że ta przerażająca hipoteza nigdy nie stanie się rzeczywistością?
Broń znajdująca się w amerykańskich zasobach nuklearnych jest poddawana częstym testom w locie w ramach programu Stockpile Stewardship prowadzonego przez National Nuclear Security Administration. Ma to zapewnić bezpieczeństwo, ochronę i niezawodność. Konstrukcje broni ulegają jednak zmianom i zawierają coraz więcej elementów cyfrowych i komunikacyjnych. W starszych wersjach atomówek do większości operacji wykorzystywano sygnalizację analogową i przełączniki mechaniczne. Cyfrowo zmodernizowana broń opiera się na oprogramowaniu, a standardowe praktyki testowania oprogramowania są niewystarczającym zabezpieczeniem przed awariami, gdy kod stanowi podstawę mechanizmów "życie albo śmierć".
Standardowe testowanie oprogramowania nie jest w stanie sprostać wysokim standardom bezpieczeństwa i niezawodności broni - w szczególności kryteriom Walske'a, które wymagają, aby broń jądrowa miała nie więcej niż jedną na miliard szans na defekt w standardowych warunkach i nie więcej niż jedną na milion szans w nietypowych okolicznościach (na przykład podczas pożaru). Nowe zagrożenia wynikające z projektowania cyfrowego będą więc wymagały zmian w podstawowym podejściu zarówno do projektowania, jak i testowania broni. Wymaga to dwóch fundamentalnych zmian w obecnym podejściu. Po pierwsze, broń testowa i prawdziwa powinny być niemal identyczne - oznacza to projektowanie systemów broni tak, aby zawierały wyposażenie testowe. Po drugie, broń powinna być projektowana z matematycznie analizowalnym oprogramowaniem, które umożliwia przeprowadzenie bardziej rygorystycznych i wyczerpujących testów cyfrowych niż jest to możliwe obecnie. Te dwa zalecenia składają się na jedną, fundamentalną zmianę w podejściu do projektowania broni jądrowej: Programy muszą być "projektowane pod kątem testów". Broń z wbudowanym oprogramowaniem i firmware nie może spełnić kryteriów Walske'a bez podejścia opartego na projektowaniu testowym.
W jaki sposób projektowanie testowe wpływa na bezpieczeństwo i ochronę cyfrową? Inwestowanie w nowe podejścia sprawia, że testowanie architektury cyfrowej jest dokładniejsze, a wyniki bardziej wiarygodne. Na początek, musimy zrozumieć, dlaczego testowanie oprogramowania jest tak trudne. Dzieje się tak dlatego, że oprogramowanie jest złożone i składa się z ogromnej liczby stanów - liczby możliwych stanów, które program może osiągnąć lub w których może się znaleźć. Sam rozmiar tej przestrzeni sprawia, że niemożliwe jest wyczerpujące przetestowanie oprogramowania - to znaczy, przetestowanie każdego pojedynczego możliwego stanu, nawet dla bardzo małych programów. Bardzo prosty przykład tego ilustruje dr Beat Fluri w swoim seminarium online na temat testowania oprogramowania: program z czterema zmiennymi mającymi 2^32 możliwych kombinacji danych wejściowych z całkowitą liczbą 2^32 x 2^32 x 2^32 x 2^32 = 2^128 różnych wartości. Zbadanie tej przestrzeni wejściowej w tempie 1000 linii na sekundę zajęłoby 10^28 lat czyli 10 z 28 zerami po nim, czyli 10 oktylionów - więcej lat niż wiek wszechświata. Błędy w oprogramowaniu mogą pozostać nieodkryte tylko dlatego, że przetestowanie każdego możliwego stanu jest niewykonalne. Nie możemy spędzić całego życia wszechświata na testowaniu pojedynczego małego programu.
Przykładem nieoczekiwanego zachowania spowodowanego przez ukryty błąd może być "lepki akcelerator", który spowodował, że samochody Toyoty nadal przyspieszały, gdy kierowcy przestali wciskać pedał gazu. Spowodowało to wiele wypadków i ofiar śmiertelnych, i było początkowo zrzucane na problemy mechaniczne z pedałem i konstrukcją maty. W 2013 r. ława przysięgłych ustaliła na podstawie zeznań ekspertów, że ta wada konstrukcyjna wynikała z nieprzewidzianego stanu w oprogramowaniu elektronicznej kontroli przepustnicy. Eksperci zeznali, że kod źródłowy Toyoty zawierał błędy, które mogły spowodować niezamierzone przyspieszenie oraz że inżynierowie Toyoty wdrożyli złe praktyki kodowania architektury bezpieczeństwa. W projektach o krytycznym znaczeniu dla bezpieczeństwa, oprogramowanie opiera się na dobrych praktykach i architekturze, aby zapewnić bezpieczeństwo i niezawodność, ponieważ nie można oczekiwać, że nawet najszerzej zakrojone testy oprogramowania odkryją każdą unikalną kombinację stanów, która pozwala na ujawnienie się niebezpiecznych problemów.
Broń jądrowa jest najbardziej krytycznym systemem bezpieczeństwa i nie ma sposobu na sprawdzenie każdej linijki kodu i każdej możliwej kombinacji stanów, jakie może wytworzyć oprogramowanie jądrowe. Standardowe podejście do tworzenia i testowania oprogramowania jest w przypadku tych systemów niebezpiecznie nieodpowiednie.
"Czy to robi to, co powinno?" vs. "Czy to nie zrobi tego, czego nie powinno?"
Jest jednak pewna alternatywa. Najbardziej efektywne testowanie oprogramowania jest wykonywane jako część procesu projektowania, co eliminuje zarówno błędy w oprogramowaniu, jak i potencjał kosztownego przeprojektowywania, jeśli problemy zostaną odkryte w już stworzonym oprogramowaniu. Projektowanie pod testowanie może rozwiązać problem złożoności oprogramowania poprzez wymóg stosowania formalnych metod matematycznych we wszystkich programach używanych w broni jądrowej. Metody formalne są technikami używanymi do matematycznego modelowania złożonych systemów oprogramowania, aby umożliwić inżynierom "udowodnienie", że dany fragment kodu zachowuje się dokładnie tak, jak należy, podobnie jak matematycy udowadniają twierdzenia. Podczas gdy typowe cykle tworzenia oprogramowania skupiają się na głównym etapie pisania programu, a program jest poddawany testom jako późniejszy, oddzielny etap, podejście formalne tworzy kod, który jest specjalnie zaprojektowany od początku, aby poddać go formalnej ocenie. Aby metody formalne były naprawdę wydajne w weryfikacji, muszą być zastosowane na etapie projektowania, aby wytworzyć kod, który może być analizowany przy użyciu technik matematycznych. Poza sformalizowaniem procesu testowania i weryfikacji, projektowanie dla testowania z użyciem metod formalnych radykalnie zmniejsza się złożoność oprogramowania.
Aby zilustrować dlaczego, wyobraźmy sobie mały program, który wykonuje prostą funkcję, powiedzmy termostat, który odczytuje temperaturę, a następnie reguluje ogrzewanie lub chłodzenie w domu. Najpierw wyobraźmy sobie opisanie funkcji termostatu za pomocą zdań w języku naturalnym, a potem wyobraźmy sobie opisanie tej samej funkcji za pomocą równania. Równanie matematyczne zapewnia krótki, łatwy do określenia format do wyrażenia tej samej funkcjonalności, co stwierdzenie w języku mówionym lub - w oprogramowaniu - w języku programowania. Takie podejście eliminuje również błędy, które mogą być wynikiem poprawnej implementacji wadliwego projektu w oprogramowaniu (warunki wyścigu (ang. race conditions), w których wyniki programu zmieniają się w oparciu o niekontrolowane sekwencje zdarzeń, są czasami wynikiem złego projektu). Nuclear Threat Initiative zidentyfikowała potrzebę "sondowania poza granicami oczekiwanego zachowania, aby spróbować odkryć nieoczekiwane słabości" w systemach broni jądrowej. Testowanie modelu, technika w metodach formalnych, dostarcza sposobu, aby to zrobić. Urządzenia do sprawdzania modeli są używane do modelowania programu komputerowego i specyfikacji bezpieczeństwa (lub innych) w języku matematycznym, a następnie udowadniają, że oprogramowanie spełnia specyfikacje poprzez testowanie niepożądanych zachowań, takich jak naruszenie warunków bezpieczeństwa. Standardowe testowanie oprogramowania zazwyczaj zapewnia tylko, że pożądane warunki są spełnione - znacznie trudniej jest wykazać, że niepożądane warunki, takie jak naruszenie warunków bezpieczeństwa, nigdy nie są spełnione. Modele sprawdzające pomagają zapewnić, że sama specyfikacja oprogramowania jest poprawna i wytwarza pożądane zachowania, zanim zostanie napisana choćby linijka kodu. Formalne specyfikowanie oprogramowania jest wspierane przez inżynierów Amazona jako sposób na "zapobieganie poważnym, ale subtelnym błędom przed wdrożeniem na produkcję".
Tak zwane wymagania "Zawsze/Nigdy" nałożone na całą amerykańską broń jądrową - że broń będzie zawsze działać zgodnie z przeznaczeniem, gdy zostanie autoryzowana przez prezydenta i nigdy nie będzie działać inaczej - wymagają szerokiej zgody dla technik formalnych. Stosowanie starych standardów bezpieczeństwa, ochrony i niezawodności przy użyciu nowych technologii wymaga nowych standardów rozwoju i podejścia w całej swojej rozciągłości.
Upodobnij broń testową do prawdziwej broni
Kolejnym wyzwaniem dla systemów cyfrowych związanym ze złożonością oprogramowania jest podatność na ataki cybernetyczne. Podatności mogą powstawać i pozostawać nieodkryte jako konsekwencja złożoności oprogramowania - podatności różnią się od "błędów" w oprogramowaniu tylko tym, że mogą być celowo wykorzystane do wywołania w programie zachowań, które nie były zamierzone przez twórcę oprogramowania. Możliwość, że złośliwy podmiot mógłby przeprogramować działanie broni jądrowej poprzez zmianę oprogramowania, stwarza oczywiste obawy o bezpieczeństwo. Jeśli zaawansowane technologicznie wrogie państwa byłyby w stanie przeniknąć do cyfrowych systemów sterowania bronią jądrową, a zwłaszcza jeśli mogłyby to zrobić w sposób niewykryty, mogłoby to mieć poważne konsekwencje. Metody formalne mogą pomóc również w tym przypadku: Zostały one wykorzystane w programie High Assurance Cyber Military Systems Agencji Zaawansowanych Projektów Badawczych Obrony (Defense Advanced Research Projects Agency) do stworzenia pojazdów "nie do zhakowania" takich jak quadcoptery, helikoptery i samochody. Tworzenie systemów uzbrojenia, które są w stanie oprzeć się zagrożeniom cybernetycznym, wymaga jednak testowania zarówno pod kątem podatności na zagrożenia cybernetyczne, jak i złośliwego oprogramowania, które już zainfekowało system uzbrojenia w łańcuchu dostaw.
Projektowanie na potrzeby testów może również dotyczyć cyberbezpieczeństwa broni poprzez włączenie oprzyrządowania testowego, takiego jak czujniki wykrywające detonację broni, bezpośrednio do projektu głowicy bojowej lub korpusu bomby. Dlaczego miałoby to mieć jakikolwiek wpływ na bezpieczeństwo cybernetyczne broni?
Po pierwsze, broń jądrowa składa się z dwóch głównych elementów: bomby lub głowicy bojowej oraz platformy przenoszącej. Stany Zjednoczone testują niejądrowe funkcje swojej broni jądrowej - uzbrajanie, zapalanie i odpalanie - przy użyciu wersji testowej zwanej wspólnym zespołem testowym (znanym bardziej pod nazwą JTA). Wspólne zespoły testowe to korpusy broni jądrowej - bomby lub głowicy bojowej - z usuniętym jądrowym materiałem wybuchowym, wyposażone w czujniki i inne oprzyrządowanie wymagane do wykrywania ważnych parametrów zdarzeń charakteryzujących odpalanie i wystrzeliwanie testowanej broni. Lecą one na platformie przenoszącej broń, będącej własnością Departamentu Obrony (bombowiec taki jak B-2, pocisk manewrujący lub rakieta balistyczna) jako część wspólnego testu zarówno broni Departamentu Energii, jak i platformy przenoszącej Departamentu Obrony, stąd nazwa "wspólny zespół testowy". Umieszczenie oprzyrządowania testowego w głowicy jądrowej lub korpusie bomby wymaga zmian w ich wewnętrznej konfiguracji, w tym modyfikacji obwodów elektrycznych i cyfrowych. Ze względu na te zmiany testowane co roku wspólne zespoły testowe nie są identyczne z bronią jądrową znajdującą się w zapasach. Ponieważ projekt wspólnego zespołu testowego różni się od projektu magazynowego, Departament Obrony i Departament Energii przeprowadzają kilka dodatkowych testów w locie na projekcie o wysokiej wierności, czyli "hi-fi". Te bomby testowe nie zawierają wewnętrznych czujników zbierających dane, które posiada wspólny zespół testowy - latają one z bronią klasy rezerwy wojennej z usuniętym jądrowym materiałem wybuchowym. Testy hi-fi są przeprowadzane w celu zapewnienia, że broń leci zgodnie z przeznaczeniem i zostaje zdetonowana na końcu toru lotu, ale z powodu braku oprzyrządowania nie są zbierane żadne dane telemetryczne dotyczące działania głowicy lub bomby. Testy te, zarówno oprzyrządowane, jak i hi-fi, są bardzo kosztowne, a każdy z nich wymaga ponownego wykorzystania broni wartej wiele milionów dolarów, pozyskanej bezpośrednio z zapasów broni jądrowej. Można tego dokonać poprzez projektowanie na potrzeby testów, projektując oprzyrządowanie testowe bezpośrednio w korpusie bomby lub głowicy bojowej, dzięki czemu broń testowa i wojenna są identyczne.
Lekcja z WannaCry na poziomie nuklearnym
Powód, dla którego bezpośrednie włączenie oprzyrządowania testowego do projektu broni poprawia podstawę cyberbezpieczeństwa, można zilustrować na przykładzie wirusa ransomware WannaCry, który przeprowadził ogólnoświatowy cyberatak w 2017 roku. Wirus zaszyfrował dane użytkowników komputerów i zażądał zapłaty w kryptowalucie Bitcoin za ich odszyfrowanie. Złośliwe oprogramowanie podobne do WannaCry, gdyby zostało wprowadzone do łańcucha dostaw, nie zostałoby wykryte we wspólnym teście. Powód jest prosty: Wirus został zaprojektowany tak, aby był w stanie stwierdzić, kiedy znajduje się w środowisku maszyny wirtualnej i ukryć się - tj. nic nie robić - ponieważ maszyny wirtualne są miejscem, w którym odbywa się większość testów szkodliwego oprogramowania. Kiedy jednak znalazł się w prawdziwym środowisku, wyszedł z ukrycia i wykonał swoje zadanie. WannaCry sprytnie wyczuwał obecność środowiska testowego, pingując adres internetowy dla fałszywej, niezarejestrowanej nazwy domeny, którą wirtualne maszyny testowe uznawały za prawdziwą domenę (ponieważ maszyny wirtualne są zaprojektowane tak, aby nie zwracały uwagi na prawdziwość lub nierealność nazw domen). Prawdziwy Internet rozpoznałby tę samą nazwę domeny jako fałszywą - nie byłby w stanie jej rozwiązać. Wirus wykorzystywał rozwiązanie lub brak rozwiązania nazwy domeny jako sygnał do ukrycia się lub ożywienia. Kiedy ten sygnał został odkryty przez badaczy bezpieczeństwa, został on wykorzystany jako "wyłącznik" - zarejestrowali oni nazwę domeny, powodując uśpienie wirusa.
W podobny sposób, złośliwe oprogramowanie skierowane na system broni jądrowej może wyczuć różnicę między konfiguracją testową broni a konfiguracją używaną w czasie wojny, aby określić, czy ma się pojawić, czy pozostać uśpione, co pozwoli mu pozostać w ukryciu podczas testów. Złośliwe oprogramowanie uaktywniłoby się dopiero podczas prawdziwej misji, powodując uszkodzenie broni lub coś nawet gorszego.
Te obawy związane z bezpieczeństwem cybernetycznym można złagodzić, projektując broń testową i wojenną tak, aby były jednym i tym samym, poprzez podejście projektowania pod testy. Na przykład nowoczesną broń można zaprojektować z wbudowanym sprzętem testowym, który wykonuje typowe zadania testowe w locie, takie jak wykrywanie detonacji, ale który pozostaje na miejscu również w czasie wojny bez szkody dla misji.
Jeśli cyfrowe rozwiązania są tak ryzykowne, to po co je robić?
Dlaczego nie pozostać przy starszych, analogowych, cyberbezpiecznych konstrukcjach? Broń jądrowa przechodzi na technologię cyfrową z dwóch powodów. Pierwszym z nich jest to, że platformy nośne Departamentu Obrony, takie jak B-2 i nowy samolot B-21 Raider, nazywany "cudem cyfrowego rozwoju", komunikują się za pomocą cyfrowych interfejsów, a broń musi być zdolna do wysyłania i odbierania poleceń do i z tych platform cyfrowych. Innym powodem jest potrzeba mocy i elastyczności projektowania cyfrowego, zwłaszcza projektów, które zawierają procesory, w przeciwieństwie do niestandardowych komponentów, takich jak układy scalone specyficzne dla danej aplikacji. W przypadku projektu opartego na procesorze, zmiana kilku linijek kodu może rozwiązać problem z wydajnością i umożliwić natychmiastowe ponowne przetestowanie projektu. Ta sama zmiana może zająć miesiące w przypadku układu scalonego produkowanego w zabezpieczonym obiekcie. Jeśli zabezpieczony obiekt ma zaległości w pracy (co jest częstym problemem w przypadku tych poszukiwanych zasobów), może to potrwać jeszcze dłużej.
Wszystkie te warunki razem wzięte gwarantują, że oprogramowanie pozostanie częścią projektowania broni jądrowej. Zadaniem jest teraz zapewnienie, by broń jądrowa pozostała tak samo bezpieczna, pewna i niezawodna jak w minionych dekadach. Nowoczesne projekty broni cyfrowej stawiają nowe, znaczące wyzwania, ale wielu z nich można sprostać dzięki opisanemu powyżej podejściu "projektowanie dla testowania". Metody formalne zmniejszają złożoność i sprawiają, że oprogramowanie jest analizowalne i weryfikowalne, a także zapewniają pewną ochronę przed hakerami. Uczynienie broni testowej i rzeczywistej efektywnie taką samą poprawi dokładność testów, zmniejszy liczbę wielomilionowych testów, które muszą być przeprowadzane, i wyeliminuje przynajmniej jedną potencjalną lukę w bezpieczeństwie cybernetycznym spowodowaną przez złośliwe oprogramowanie, które potrafi rozpoznać, że znajduje się w środowisku testowym i pozostaje uśpione.
Te kroki będą wymagały radykalnych zmian w dotychczasowym podejściu oraz inwestycji w personel i programy, ale są ważne i konieczne, aby nowe cyfrowe projekty broni jądrowej były bezpieczne i niezawodne, zgodnie ze starymi, tradycyjnymi standardami. Wiemy, jak sprostać wyzwaniu, jakie stawia przed bronią jądrową technologia cyfrowa. Nadszedł czas, aby zainwestować w ludzi, narzędzia i zmiany niezbędne do sprostania temu wyzwaniu.
