Testy penetracyjne są standardowym elementem każdego poważnego programu bezpieczeństwa. W środowiskach komercyjnych jest to stosunkowo dobrze rozumiane ćwiczenie: zewnętrzny zespół otrzymuje zakres, dokument zasad zaangażowania i okno czasowe na znalezienie podatności, które można wykorzystać, zanim zrobią to prawdziwi atakujący. Wynikiem jest raport, a ścieżka remediacji stanowi problem zarządzania projektem.
W środowiskach obronnych żadna z tych ram nie ma pełnego zastosowania. Struktura upoważnień prawnych jest inna, model zagrożeń jest inny, ograniczenia dotyczące tego, czego testerzy mogą dotykać, są inne, a ścieżka od odkrycia do remediacji przebiega przez formalny proces akredytacji, który nie ma komercyjnego odpowiednika. Organizacje stosujące komercyjne konwencje testów penetracyjnych do systemów obronnych — lub zatrudniające komercyjne firmy testów penetracyjnych bez doświadczenia w obronności — rutynowo produkują oceny, które pomijają najbardziej istotne ryzyka, działają poza granicami prawnie uzasadnionych upoważnień lub generują wyniki, na których biuro programu nie może działać.
Ten artykuł analizuje, co faktycznie wyróżnia obronne testy penetracyjne, co to oznacza operacyjnie i jak ustrukturyzować ocenę, która przynosi wyniki, z których program wojskowy może skorzystać.
Podstawa prawna: fundament bez komercyjnego odpowiednika
W angażowaniach komercyjnych podstawą prawną testu penetracyjnego jest umowa i dokument zasad zaangażowania podpisany przez osobę z uprawnieniami do autoryzacji testowania systemów docelowych. Uprawnienia te są zazwyczaj proste — firma jest właścicielem systemów, a CISO lub CTO może udzielić zgody.
W środowiskach obronnych łańcuch uprawnień jest bardziej złożony, a stawki za pomyłkę są znacznie wyższe. Rządowe systemy informatyczne działają na podstawie Authorization to Operate (ATO) przyznanej przez Urzędnika Autoryzującego (AO). ATO definiuje poziom bezpieczeństwa, do którego system jest autoryzowany. Testy penetracyjne modyfikują ten poziom, przynajmniej tymczasowo, i muszą być wyraźnie autoryzowane przez AO — nie tylko przez kierownika programu lub ISSO systemu.
Dla systemów US DoD obowiązują Computer Fraud and Abuse Act (CFAA) i UCMJ. Osoba, która uzyskuje dostęp do rządowego systemu informatycznego bez właściwej autoryzacji — nawet w dobrej wierze, nawet w ramach pozornie autoryzowanego testu — popełniła przestępstwo federalne. Dokument autoryzacyjny nie jest formalnością: jest instrumentem, który przekształca to, co inaczej byłoby nieautoryzowanym dostępem, w legalne testowanie. Każdy tester wymieniony w autoryzacji musi być zidentyfikowany indywidualnie. Zakres autoryzowanego testowania musi być konkretny. Działania poza tym zakresem nie są chronione.
Wymóg podstawy prawnej: Nigdy nie rozpoczynaj obronnego testu penetracyjnego bez podpisanego, konkretnego dokumentu autoryzacyjnego od Urzędnika Autoryzującego systemu. Ogólne zatwierdzenia „oceny bezpieczeństwa" od kierowników programów lub głównych wykonawców nie zapewniają ochrony CFAA. Autoryzacja musi imiennie wskazywać testerów, określać systemy w zakresie, definiować okno testowe i wyliczać dozwolone metody.
Wymagania dotyczące poświadczeń bezpieczeństwa dodają kolejną warstwę. Testowanie niejawnego systemu wymaga, aby testerzy posiadali ważne poświadczenia bezpieczeństwa na odpowiednim poziomie klasyfikacji. Organizacja testująca musi posiadać poświadczenie obiektu (FCL) na tym poziomie. Wprowadzenie nieposiadającego poświadczenia personelu — nawet w rolach pomocniczych — do niejawnego środowiska testowego stanowi naruszenie bezpieczeństwa niezależnie od tego, co faktycznie widzą lub dotykają.
ITAR (International Traffic in Arms Regulations) wprowadza dalsze ograniczenia dla programów obejmujących kontrolowane artykuły obronne. Informacje o podatnościach w systemach kontrolowanych przez ITAR mogą same podlegać ograniczeniom kontroli eksportu, ograniczając to, co można dokumentować, przesyłać lub udostępniać przez granice międzynarodowe — w tym w ramach wielonarodowych programów sojuszniczych. Firmy testujące działające w ramach międzynarodowych umów podwykonawczych muszą uwzględniać to wprost.
Emulacja aktorów zagrożeń: TTPs podmiotów państwowych, nie ogólne exploity
Komercyjne testy penetracyjne często koncentrują się na znalezieniu jakiejkolwiek podatności, którą można wykorzystać — najczęstszych, najłatwiej dostępnych, najwyżej ocenianych przez CVSS problemów w powierzchni ataku celu. Dla sieci korporacyjnej jest to rozsądne podejście: oportunistyczny atakujący wykorzysta najłatwiejszą dostępną ścieżkę.
Systemy obronne stają naprzeciw zasadniczo innej populacji zagrożeń. Głównymi przeciwnikami dla wysoko wartościowych celów obronnych są podmioty państwowe dysponujące znacznymi zasobami, zaawansowanymi zdolnościami i długimi horyzontami czasowymi. Nie zostaną powstrzymane przez załatanie problemu OpenSSL z wynikiem CVSS-10, jeśli mogą przeniknąć przez zaufanego partnera łańcucha dostaw, starszy komponent osadzony lub błędną konfigurację rozwiązania cross-domain.
Skuteczne obronne testy penetracyjne wykorzystują emulację przeciwnika: zespół testowy replikuje taktyki, techniki i procedury (TTPs) konkretnych grup aktorów zagrożeń istotnych dla modelu zagrożeń programu. Framework MITRE ATT&CK zapewnia ustrukturyzowaną taksonomię do tego celu, z macierzami Enterprise i ICS obejmującymi techniki najczęściej stosowane przez grupy advanced persistent threat.
Dla systemów obronnych odpowiedni aktorzy zagrożeń zazwyczaj obejmują:
- APT28 (Fancy Bear / GRU Unit 26165) — rosyjski wywiad wojskowy, znany z spearphishingu, zbierania danych uwierzytelniających i utrzymania dostępu poprzez nadużywanie legalnych narzędzi. Taktyki istotne dla oprogramowania obronnego obejmują atakowanie stacji roboczych deweloperów i potoków budowania w celu wstrzyknięcia złośliwego kodu przed wdrożeniem.
- Lazarus Group (DPRK) — północnokoreański aktor państwowy z doświadczeniem w atakowaniu wykonawców obronnych i firm lotniczych, szczególnie poprzez ataki watering hole i uzbrojone przynęty z ofertami pracy skierowane do personelu posiadającego poświadczenia bezpieczeństwa.
- Volt Typhoon (PRC) — chiński aktor państwowy skupiony na technikach living-off-the-land w celu uzyskania trwałego, niskoszumowego dostępu do infrastruktury krytycznej i sieci obronnych. Znany z unikania niestandardowego złośliwego oprogramowania na rzecz wbudowanych narzędzi systemowych w celu unikania wykrycia.
Plan testów powinien określać, który profil przeciwnika jest emulowany i dlaczego, na podstawie oceny zagrożeń programu. Test emulujący podejście Volt Typhoon polegające na living-off-the-land będzie wyglądał bardzo inaczej niż test emulujący operacje APT28 skoncentrowane na danych uwierzytelniających — a oba będą różnić się od testu skupionego na scenariuszach zagrożeń wewnętrznych lub integralności łańcucha dostaw.
Uwaga dotycząca wyboru przeciwnika: Profil aktora zagrożeń powinien być napędzany przez opartą na wywiadzie ocenę zagrożeń programu, a nie preferencje testera ani ogólne etykiety „zaawansowanych". W przypadku programów z konkretnymi geograficznymi profilami zagrożeń lub historią ukierunkowanych ataków, ISSO powinien przeszkolic zespół testowy w zakresie bieżących raportów o zagrożeniach przed rozpoczęciem angażowania.
Zarządzanie zakresem: ograniczenia braku przestojów i izolowane środowiska testowe
Ograniczenia zakresu komercyjnych testów penetracyjnych dotyczą przede wszystkim ograniczenia odpowiedzialności i ukierunkowania wysiłków. Ograniczenia zakresu obronnego mają dodatkowe wymiary, które zasadniczo kształtują sposób przeprowadzenia testu.
Wiele systemów obronnych nie może akceptować żadnych przestojów podczas testowania. Systemy dowodzenia i kontroli, infrastruktura komunikacyjna i platformy fuzji danych czasu rzeczywistego mogą być operacyjnie aktywne podczas okna testowego. Próba eksploatacji powodująca przerwanie usługi — nawet krótkie — może mieć konsekwencje operacyjne, których żadne umowne odszkodowanie nie może zrekompensować. Standardowe komercyjne podejście testowania systemów produkcyjnych z zasadą „zatrzymaj się, gdy zobaczysz coś niestabilnego" jest niedopuszczalne dla tych środowisk.
Praktyczną konsekwencją jest to, że wiele obronnych testów penetracyjnych jest przeprowadzanych na dedykowanych środowiskach testowych: izolowanych segmentach sieci, środowiskach staging lub replikach laboratoryjnych możliwie jak najbardziej zbliżonych do produkcji. Wierność środowiska testowego ma ogromne znaczenie. Środowisko testowe korzystające z różnych wersji oprogramowania układowego, pozbawione produkcyjnych integracji lub działające ze złagodzonymi kontrolami dostępu w porównaniu z produkcją będzie generować wyniki, które nie odzwierciedlają rzeczywistej postawy ryzyka systemu operacyjnego. Wierność środowiska testowego jest inwestycją, do której biuro programu musi się zobowiązać — nie jest to problem do rozwiązania przez zespół testujący.
Naruszenia zakresu są traktowane poważniej w środowiskach obronnych niż w komercyjnych. Przypadkowe dotknięcie systemu poza autoryzowanym zakresem nie jest drobną kwestią proceduralną — może stanowić nieautoryzowany dostęp do rządowego systemu informatycznego. Testerzy muszą prowadzić szczegółowy dziennik aktywności przez cały czas trwania angażowania, dokumentując znaczące działania w czasie zbliżonym do rzeczywistego, tak aby wszelkie pytania o zakres pojawiające się podczas lub po teście można było rozwiązać za pomocą dowodów, a nie wspomnień.
Klasy podatności specyficzne dla obronności
Poza różnicami proceduralnymi systemy obronne prezentują klasy podatności niedostatecznie reprezentowane w komercyjnych metodykach testów penetracyjnych.
Starsze systemy osadzone. Platformy obronne rutynowo uruchamiają oprogramowanie na sprzęcie mającym 10–20 lat, z osadzonym oprogramowaniem układowym, które nie może być poprawiane przez normalne mechanizmy aktualizacji oprogramowania. Podatności w tych komponentach mogą być znane, ale nieusuwalne w cyklu życia systemu — wynik testu penetracyjnego stanie się stałym wpisem POAM z wnioskiem o odchylenie, a nie zgłoszeniem remediacji. Testerzy muszą rozumieć, co w tym kontekście oznacza „wynik": wartość polega na dokumentowaniu i kwantyfikowaniu ryzyka, niekoniecznie na napędzaniu natychmiastowej remediacji.
Rozwiązania cross-domain. Systemy obsługujące dane na wielu poziomach klasyfikacji używają rozwiązań cross-domain (CDS) do przenoszenia danych między domenami bezpieczeństwa. Są to cele wysokiej wartości: CDS, którym można manipulować w celu przekazywania informacji w niewłaściwym kierunku, podważa całą architekturę obsługi danych. Testowanie CDS wymaga specjalistycznej wiedzy i konkretnej autoryzacji — te komponenty są często traktowane jako oddzielne zakresy w ramach szerszej oceny programu.
Integralność łańcucha dostaw. Najbardziej znaczące ataki na łańcuch dostaw oprogramowania w ostatnich latach (SolarWinds, XZ Utils) atakowały potoki budowania i wstrzykiwanie zależności, a nie działające systemy. Programy obronne są celami wysokiej wartości dla tej klasy ataków. Testy penetracyjne powinny obejmować ocenę środowiska budowania: czy atakujący z dostępem do stacji roboczej dewelopera może wprowadzić złośliwy kod, który przetrwa do kompilacji produkcyjnej? Czy skompromitowana zależność może zostać wprowadzona bez uruchamiania istniejących kontroli?
Zarządzanie certyfikatami i kluczami. Systemy obronne są silnie uzależnione od infrastruktury PKI w zakresie uwierzytelniania i bezpieczeństwa komunikacji. Błędnie skonfigurowana walidacja certyfikatów, zbyt szerokie konfiguracje zakotwiczenia zaufania i słabe zarządzanie cyklem życia kluczy są konsekwentnie wynikami o wysokiej powadze. W odróżnieniu od podatności aplikacyjnych często są niewidoczne dla automatycznego skanowania i wymagają ręcznej weryfikacji architektury PKI względem projektu bezpieczeństwa systemu.
Cykl życia wyników: POAM, wpływ na ATO i wnioski o odchylenie
W angażowaniach komercyjnych raport z testu penetracyjnego trafia do CISO, wyniki są segregowane, część jest naprawiana, a reszta starzeje się w trackerze do następnej oceny. Proces jest napędzany apetytem na ryzyko i wydajnością inżynierską.
W środowiskach obronnych wyniki wchodzą w formalny cykl życia akredytacji z implikacjami prawnymi i umownymi. Kluczową koncepcją jest Plan of Action and Milestones (POAM): dokument śledzący każdą znana słabość w systemie, względem którego przyznano lub ubiega się o ATO. Każdy wynik testu penetracyjnego, który nie jest natychmiast naprawiony, musi zostać wprowadzony do POAM z planowaną datą remediacji, odpowiedzialnym właścicielem i środkiem tymczasowego łagodzenia.
POAM jest przeglądany przez Urzędnika Autoryzującego jako warunek utrzymania ATO. Otwarte pozycje o wysokiej powadze bez odpowiednich tymczasowych łagodzeń lub realistycznych harmonogramów remediacji mogą wywołać zawieszenie ATO — efektywnie wyłączając system do czasu poprawy postawy ryzyka. Dla biura programu ten wynik jest wystarczająco poważny, że niektóre programy opóźniają lub ograniczają zakres testów penetracyjnych, aby uniknąć generowania wyników mogących wywołać przegląd ATO. Jest to błąd zarządzania ryzykiem: podatności istnieją niezależnie od tego, czy są udokumentowane.
W przypadku wyników, których nie można naprawić — komponentów starszych bez dostępnych poprawek, ograniczeń architektonicznych wymagających pełnego przeprojektowania systemu — biuro programu może złożyć wniosek o odchylenie lub akceptację ryzyka do AO. Nie jest to przyznanie się do niepowodzenia; jest to formalny mechanizm działania ze znana resztkową ryzykiem pod wyraźną autoryzacją. Testerzy powinni rozumieć ten proces i formułować wyniki w sposób, który pomaga ISSO konstruować możliwe do obrony wpisy POAM i wnioski o odchylenie, a nie tylko w sposób maksymalizujący wyniki CVSS.
Formatowanie raportu dla programów obronnych: Raporty z obronnych testów penetracyjnych powinny zawierać dla każdego wyniku: oznaczenie klasyfikacyjne, ocenę powagi dostosowaną do kryteriów akceptacji ryzyka programu, ocenę możliwości eksploatacji biorąc pod uwagę rzeczywistych aktorów zagrożeń programu oraz zalecaną dyspozycję POAM. Raporty napisane w formacie komercyjnym — wyniki CVSS, ogólne zalecenia dotyczące remediacji, podsumowania wykonawcze skierowane do kierownictwa nieposiadającego wiedzy technicznej — wymagają znacznej przeróbki, zanim ISSO będzie mógł ich użyć.
Jak określić zakres i autoryzować obronny test penetracyjny
Poniższe kroki odzwierciedlają wymagania dla możliwego do obrony, legalnie autoryzowanego testu penetracyjnego systemu oprogramowania obronnego.
Krok 1: Ustanów podstawę prawną i pisemną autoryzację. Uzyskaj podpisany dokument autoryzacji testów od AO systemu. Dokument musi imiennie wskazywać testerów, określać systemy w zakresie, definiować okno testowe i wyliczać dozwolone metody. Nie jest to formalność — jest instrumentem, który czyni testowanie zgodnym z prawem.
Krok 2: Zweryfikuj poświadczenia dostępu i obiektu. Potwierdź, że wszyscy testerzy posiadają ważne poświadczenia bezpieczeństwa na poziomie klasyfikacji systemu docelowego, a organizacja testująca posiada FCL wymaganego poziomu. Przed dostępem do jakiegokolwiek środowiska niejawnego przeszkol wszystkich testerów w zakresie przewodnika klasyfikacji bezpieczeństwa programu.
Krok 3: Zdefiniuj zakres i granice środowiska testowego. Określ, które systemy, sieci i interfejsy znajdują się w zakresie. Tam, gdzie systemy operacyjne nie mogą akceptować przestojów, ustanów dedykowane środowisko testowe. Udokumentuj wyraźne wykluczenia i poinformuj testerów o prawnych konsekwencjach naruszenia zakresu.
Krok 4: Wybierz i zweryfikuj narzędzia testowe. Przejrzyj obowiązki ITAR i wymagania akredytacyjne programu, aby określić, które narzędzia są dozwolone. Wyeliminuj narzędzia z komponentami zagranicznego pochodzenia, licencjonowaniem opartym na chmurze lub wychodzącą telemetrią. Udokumentuj zestaw narzędzi w planie testów i przedłóż do przeglądu biura programu przed rozpoczęciem angażowania.
Krok 5: Przeprowadź emulację aktorów zagrożeń na podstawie modelu zagrożeń programu. Wybierz profil przeciwnika najbardziej odpowiedni dla systemu. Użyj MITRE ATT&CK dla ICS lub Enterprise stosownie do sytuacji, dostosowany do konkretnej architektury systemu i profilu misji. Nie zastępuj rzeczywistej emulacji przeciwnika ogólnymi testami „zaawansowanymi".
Krok 6: Dokumentuj aktywność i wyniki z oznaczeniami klasyfikacyjnymi. Prowadź szczegółowy dziennik aktywności przez cały czas trwania angażowania. Wszystkie wyniki muszą zawierać odpowiednie oznaczenia klasyfikacyjne i oceny powagi dostosowane do kryteriów akceptacji ryzyka programu.
Krok 7: Wprowadź wyniki do POAM i śledź remediację. Współpracuj z ISSO, aby wprowadzić wszystkie otwarte wyniki do POAM. Przypisz właścicieli remediacji, zaplanowane daty i tymczasowe łagodzenia dla każdej pozycji. Przedstaw bezpośrednio AO wyniki o wysokiej powadze — nie pozwól, aby krytyczne podatności czekały w kolejce bez wyraźnej akceptacji ryzyka lub aktywnej remediacji.