NIST SP 800-115: cztery fazy testu, kategorie technik i Rules of Engagement

Czym jest NIST SP 800-115

Publikację wydał Computer Security Resource Center przy National Institute of Standards and Technology we wrześniu 2008 r. Napisali ją Karen Scarfone, Murugiah Souppaya, Amanda Cody i Angela Orebaugh; dokument liczy 80 stron i ma status Final, czyli obowiązującego wydania. Zastąpił wcześniejszą SP 800-42 poświęconą testom bezpieczeństwa sieci.^[1]

Przewodnik jest adresowany do dwóch grup naraz, i to tłumaczy jego ton. Z jednej strony pisano go dla testerów i audytorów, którym daje ramy procesu oraz katalog technik. Z drugiej - dla zamawiających test, którzy dzięki niemu wiedzą, czego mogą wymagać w umowie i po czym poznać rzetelnie wykonaną pracę. Dla zespołów utrzymujących systemy jest wreszcie źródłem wiedzy o tym, co dzieje się z ich infrastrukturą w trakcie testu.

Dokument realizuje cztery zadania: porządkuje proces w powtarzalne fazy, kataloguje techniki niezależnie od narzędzi, opisuje dobre praktyki prowadzenia testu i wskazuje najczęstsze pułapki. Ostatni punkt bywa niedoceniany, a to on odróżnia przewodnik od zbioru instrukcji do narzędzi.

Układ dokumentu

Osiem rozdziałów układa się w naturalną kolejność pracy. Po wprowadzeniu i omówieniu podejścia do testowania następuje klasyfikacja technik w trzy kategorie, a potem trzy rozdziały poświęcone kolejno przeglądom, identyfikacji i analizie celów oraz weryfikacji podatności. Dwa ostatnie rozdziały dotyczą planowania oceny i jej przeprowadzenia. Do tego dochodzą załączniki, w tym wzór Rules of Engagement w załączniku B.^[1]

Ta struktura ma praktyczną konsekwencję: numery rozdziałów są często cytowane w umowach i raportach, więc warto je znać.

Czy dokument z 2008 r. jest wciąż aktualny

Publikacja ma osiemnaście lat i nie doczekała się rewizji, co przy tempie zmian w technologii brzmi jak dyskwalifikacja. W praktyce jednak nadal działa, i to z dwóch powodów.

Po pierwsze, cztery fazy testu - planowanie, odkrywanie, atak i raportowanie - opisują sposób myślenia, a nie stan techniki. Kolejność, w której najpierw ustala się zakres, potem rozpoznaje środowisko, następnie weryfikuje możliwość wykorzystania podatności, a na końcu opisuje wynik, jest tak samo sensowna dla serwera z 2008 r. i dla klastra kontenerów.

Po drugie, przewodnik konsekwentnie mówi o kategoriach technik, a nie o narzędziach. Skanowanie portów pozostaje skanowaniem portów niezależnie od tego, czy używa się do niego nmapa, masscana czy czegokolwiek innego. Dokument, który nie wymienia wersji oprogramowania, nie ma jak się zdezaktualizować w tej warstwie.

Czego w nim nie ma

Ograniczenia są równie realne. Od 2008 r. pojawiły się całe obszary testowania, których przewodnik nie omawia: bezpieczeństwo chmury wraz z audytem konfiguracji i uprawnień, kontenery i orkiestracja, interfejsy programistyczne w wariantach REST, GraphQL i gRPC, aplikacje mobilne, urządzenia przemysłowe oraz - najświeższy obszar - bezpieczeństwo systemów uczących się. W każdym z tych przypadków fazy z SP 800-115 nadal się stosują, ale techniki trzeba wziąć skądinąd. Kierunek zmian dobrze pokazuje coroczny przegląd zagrożeń ENISA.^[14]

Lukę uzupełniają inne publikacje NIST, do których warto sięgać równolegle: SP 800-53 z katalogiem zabezpieczeń^[9], SP 800-53A z procedurami ich oceny, SP 800-30 z metodyką szacowania ryzyka^[10] oraz SP 800-218 opisująca bezpieczny cykl wytwarzania oprogramowania. Na poziomie strategicznym całość spina Cybersecurity Framework 2.0.^[12]

NIST nie ogłosił harmonogramu rewizji SP 800-115. Historia dokumentu w katalogu NIST zawiera jeden wpis - publikację z 30 września 2008 r. - i żadnej zapowiedzi kolejnego wydania.

Cztery fazy testu

Przewodnik opisuje test penetracyjny jako sekwencję czterech faz (punkt 5.2.1), przy czym raportowanie nie jest wyłącznie etapem końcowym - dokumentowanie i komunikowanie istotnych ustaleń powinno towarzyszyć całemu badaniu.^[1]

Planowanie

Faza, w której zapadają wszystkie decyzje przesądzające o wartości testu, i zarazem ta, którą najczęściej się skraca. Trzeba ustalić cel - czy chodzi o wykazanie zgodności, o analizę luk, czy o symulację realnego przeciwnika - bo od tego zależy dobór technik. Następnie definiuje się zakres, wskazując wprost, co jest z niego wyłączone, wybiera metodykę, spisuje Rules of Engagement i uzyskuje pisemną autoryzację. Na koniec ustala się harmonogram, zasoby i kanały komunikacji wraz ze ścieżką eskalacji.

Zaniedbanie tej fazy widać potem w raporcie: bez jasnego celu znaleziska trudno uszeregować, a bez ustalonych kanałów komunikacji krytyczna podatność czeka w kolejce mailowej do poniedziałku.

Odkrywanie

Najobszerniejsza część techniczna. Zaczyna się od rozpoznania pasywnego, opartego na źródłach publicznych, a potem przechodzi w aktywne: identyfikację zakresów adresowych, skanowanie portów, rozpoznanie usług i ich wersji oraz systemów operacyjnych. Dla aplikacji internetowych dochodzi mapowanie punktów wejścia, parametrów i użytych technologii oraz rozpoznanie mechanizmów uwierzytelniania.

Efektem fazy jest zestawienie wykrytych usług ze znanymi podatnościami. To jeszcze nie dowód - dopiero hipoteza, którą trzeba zweryfikować w kolejnym kroku.

Atak

Najbardziej widowiskowa i zwykle najkrótsza faza. Obejmuje wykorzystanie podatności w celu uzyskania dostępu, podniesienie uprawnień, rozpoznanie zawartości systemu, utrzymanie dostępu oraz ruch boczny do kolejnych systemów. W środowiskach z Active Directory typowym celem jest przejście od zwykłego konta do uprawnień administratora domeny. Wyprowadzenie danych wykonuje się w formie symulowanej - chodzi o wykazanie możliwości, nie o faktyczne przeniesienie zbioru.

Faza kończy się porządkowaniem: usunięciem założonych kont, narzędzi i mechanizmów utrzymania dostępu. Pominięcie tego kroku zostawia w środowisku klienta furtki, o których nikt nie pamięta.

Raportowanie

Dokumentowanie trwa przez cały test, a nie zaczyna się po jego zakończeniu. Powód jest prozaiczny: dowód w postaci zrzutu ekranu albo zapisu żądania i odpowiedzi da się zebrać tylko w chwili, gdy podatność jeszcze istnieje. Poza tym znaleziska krytyczne zgłasza się natychmiast, nie czekając na raport końcowy.

Trzy kategorie technik

Przewodnik dzieli techniki na trzy grupy według tego, jak głęboko ingerują w badane środowisko. Podział jest przydatny przy negocjowaniu zakresu, bo pozwala rozmawiać o ryzyku testu, a nie o nazwach narzędzi.^[1]

Techniki przeglądowe często dają więcej niż skanowanie, bo pokazują zamierzony stan obok faktycznego. Rozróżnienie ma też bezpośrednie przełożenie na koszt i czas: test ograniczony do dwóch pierwszych kategorii jest tańszy i bezpieczniejszy, ale nie odpowiada na pytanie, czy wykryta podatność jest realnie wykorzystywalna.

Rules of Engagement i autoryzacja

Rules of Engagement to dokument uzgadniany przed rozpoczęciem testu, w którym zapisuje się wszystko, co ma być poza sporem. SP 800-115 omawia plan oceny i ROE w rozdziale 6, a wzór dokumentu zamieszcza w załączniku B; rozdział 7 zakłada już jego istnienie i wymaga, żeby odstępstwa uzyskiwały odrębną, zwykle pisemną zgodę.^[1]

Dobrze napisany ROE odpowiada na kilka pytań. Co wchodzi w zakres, a co jest z niego wprost wyłączone - i to wyłączenia są ważniejsze, bo to one chronią obie strony. Z jakich adresów prowadzony jest test i na jakie jest kierowany. W jakich godzinach można działać. Kogo i w jakim trybie powiadomić po znalezieniu czegoś krytycznego, jakimi kanałami i pod jakie numery. Czy zespół monitorujący wie o teście, czy ma go traktować jak rzeczywisty incydent.

Osobno wymienia się techniki zabronione. Zwykle są to ataki odmowy usługi, testy destrukcyjne, działania w określonych oknach czasowych oraz socjotechnika wobec wskazanych osób. Trzeba też ustalić z góry, co zrobić po natrafieniu na dane osobowe albo finansowe: czy wolno je zapisać jako dowód, w jakiej formie i na jak długo. Wreszcie warunki wstrzymania testu - kiedy tester ma przerwać pracę i zadzwonić.

Pisemna autoryzacja

Osobnym dokumentem, którego nie zastępuje ROE, jest pisemna autoryzacja. Bez niej działania testera mogą wypełniać znamiona przestępstw z Kodeksu karnego: nieuprawnionego uzyskania dostępu do informacji (art. 267), niszczenia lub zmiany zapisu informacji (art. 268 i 268a), zakłócenia pracy systemu lub sieci (art. 269 i 269a) oraz wytwarzania lub udostępniania narzędzi służących do popełniania tych czynów (art. 269b).

Autoryzacja powinna wskazywać osobę uprawnioną do reprezentowania organizacji, konkretnego wykonawcę, zakres, okres obowiązywania i ograniczenia, wraz z podpisem i datą. Warto ją mieć w formie, którą tester może okazać natychmiast - stąd branżowa nazwa get-out-of-jail-free letter. Praktyczna wskazówka: autoryzacja podpisana przez kierownika działu IT bywa niewystarczająca, jeżeli test obejmuje systemy innych jednostek organizacyjnych.

Black box, white box i wariant pośredni

Zakres wiedzy przekazanej testerowi przed startem jest osobną decyzją i wpływa na wynik silniej, niż się zwykle zakłada.

W wariancie black box tester dostaje minimum informacji i odtwarza sytuację napastnika z zewnątrz. Zaletą jest realizm, wadą - czas. Faza odkrywania pochłania większość budżetu, więc na właściwe testy zostaje go mniej, a raport bywa krótszy nie dlatego, że system jest bezpieczny.

W wariancie white box tester otrzymuje dokumentację, dane uwierzytelniające, schematy sieci, a niekiedy kod źródłowy. Rozpoznanie skraca się do minimum, więc niemal cały czas idzie na testowanie. To najefektywniejszy sposób znalezienia jak największej liczby podatności, ale nie mówi nic o tym, ile z nich znalazłby napastnik działający po omacku.

Wariant pośredni, gray box, daje testerowi częściową wiedzę - najczęściej konto zwykłego użytkownika i ogólny opis architektury. Odpowiada sytuacji napastnika, który zdobył już przyczółek, albo pracownika nadużywającego uprawnień. W praktyce jest wybierany najczęściej, bo daje rozsądny stosunek realizmu do liczby znalezisk.

Wybór zakresu wiedzy testera powinien wynikać z celu badania. Ocena kompletności zabezpieczeń może uzasadniać większy dostęp do informacji, a symulacja określonego przeciwnika - ograniczenie wiedzy zespołu ofensywnego. Żaden z tych wariantów nie wynika automatycznie z samego słowa "compliance" ani z faktu prowadzenia TLPT.

Skanowanie podatności a test penetracyjny

To dwie różne usługi, które w ofertach bywają mylone, a różnią się nie stopniem szczegółowości, lecz pytaniem, na które odpowiadają.

Skanowanie podatności jest zautomatyzowane i porównuje wykryte wersje oprogramowania z bazą znanych podatności. Trwa godziny, można je powtarzać co kwartał lub częściej, a wynikiem jest lista pozycji z identyfikatorami CVE. Skaner nie sprawdza jednak, czy w danym środowisku podatność da się wykorzystać ani jakie miałoby to znaczenie. Skanowanie podatności opisuje punkt 4.3 przewodnika.^[1]

Test penetracyjny jest w dużej części pracą ręczną i polega na próbie wykorzystania znalezionych słabości. Trwa dni lub tygodnie, wykonuje się go rzadziej, a wynikiem jest opis realnych scenariuszy ataku wraz z dowodami. Testy penetracyjne opisuje punkt 5.2, a ich cztery fazy - punkt 5.2.1.

Obie usługi są komplementarne. Skanowanie utrzymuje bieżącą świadomość stanu, test penetracyjny weryfikuje, czy przyjęte zabezpieczenia rzeczywiście działają. Zastąpienie testu skanowaniem daje listę, której nikt nie zweryfikował; zastąpienie skanowania testem daje jednorazowy obraz środowiska, które zmienia się co tydzień.

Raport z testu

SP 800-115 omawia raportowanie w punkcie 8.2, w rozdziale poświęconym czynnościom po zakończeniu testów.^[1] Raport jest jedynym trwałym produktem całej pracy i to on decyduje, czy test cokolwiek zmieni.

Ustabilizowana struktura zaczyna się od streszczenia dla kierownictwa - jedna do dwóch stron bez żargonu, z zakresem, kilkoma najważniejszymi znaleziskami, ogólną oceną i rekomendacjami. Dalej idzie opis metodyki: zastosowany przewodnik, zakres, ramy czasowe, skład zespołu i narzędzia. Rdzeniem są szczegóły znalezisk, gdzie każda pozycja ma identyfikator, tytuł, ocenę istotności wraz z punktacją CVSS, listę systemów, opis, dowody, wpływ na działalność organizacji oraz rekomendację naprawy z odesłaniami do CVE, CWE lub OWASP.

Po znaleziskach zwykle następuje ich zestawienie według istotności oraz proponowana kolejność naprawy. Terminy przypisywane poszczególnym poziomom - na przykład siedem dni dla podatności krytycznych i trzydzieści dla wysokich - nie pochodzą z przewodnika; to konwencja branżowa, którą warto uzgodnić z klientem, a nie wpisać automatycznie. Całość zamykają załączniki z surowymi wynikami i dodatkowymi dowodami.

Objętość raportu zależy od zakresu i w naszej praktyce waha się od kilkudziesięciu stron dla pojedynczej aplikacji do kilkuset przy teście obejmującym całą organizację. Sama liczba stron nie jest jednak miarą jakości - dobry raport dla jednej aplikacji bywa krótszy niż zestawienie wyników skanera.

Sposób przekazania też ma znaczenie, bo raport jest dokumentem, którego wyciek szkodzi bardziej niż większość opisanych w nim podatności. Standardem jest plik zaszyfrowany lub przekazany kanałem zabezpieczonym, wraz z sumą kontrolną. Do tego zwykle dochodzi krótkie omówienie dla kierownictwa i dłuższe, techniczne, dla zespołów odpowiedzialnych za naprawę.

Retest i sprzątanie po teście

Projekt nie kończy się na wysłaniu raportu. Konta testowe, narzędzia, ładunki, wgrane pliki, mechanizmy utrzymania dostępu oraz tymczasowe wyjątki w zaporze lub aplikacji trzeba usunąć albo wyraźnie przekazać klientowi. Przy technikach post-exploitation i red team dowód sprzątania jest szczególnie ważny.

Retest weryfikuje naprawę i nie jest automatycznie powtórzeniem całego badania. Dla poprawionego znaleziska trzeba potwierdzić, że pierwotna ścieżka ataku już nie działa i że zmiana nie zasłoniła jedynie objawu, zostawiając słabość dostępną inną drogą. Znalezisko nie powinno być uznane za zamknięte tylko dlatego, że właściciel systemu deklaruje instalację poprawki.

Retest dostarcza również dowodów na potrzeby audytu i zarządzania ryzykiem. Rozdziela znaleziska naprawione, zaakceptowane, ograniczone zabezpieczeniami kompensującymi i nadal otwarte. Taki status jest dla kierownictwa wartościowszy niż statyczna lista z pierwotnego raportu.

Relacje z OWASP, OSSTMM, PTES i MITRE ATT&CK

SP 800-115 rzadko bywa stosowany samodzielnie. W praktyce pełni rolę ramy procesu, którą uzupełnia się bardziej szczegółowymi metodykami dobranymi do przedmiotu testu.

OWASP Web Security Testing Guide^[2] w stabilnym wydaniu 4.2 zawiera szczegółowe scenariusze testowania aplikacji internetowych. Tam, gdzie NIST mówi "przetestuj uwierzytelnianie", WSTG podaje konkretne przypadki testowe. To najczęstsze uzupełnienie przy testach aplikacji. Osobnym dokumentem OWASP jest lista Top 10^[3], która porządkuje kategorie podatności, ale nie jest metodyką testowania i nie zastępuje WSTG.

OSSTMM^[4] w wersji trzeciej wybiera odmienną drogę: proponuje własny model pomiaru bezpieczeństwa operacyjnego. Jest bardziej formalny i mniej rozpowszechniony, ale bywa użyteczny tam, gdzie potrzebna jest powtarzalna miara, a nie lista znalezisk.

PTES^[5] dzieli test na siedem etapów, od uzgodnień przedumownych, przez zbieranie informacji, modelowanie zagrożeń, analizę podatności, eksploatację i działania po uzyskaniu dostępu, aż po raportowanie. Osobne wytyczne techniczne schodzą do poziomu konkretnych narzędzi i poleceń, czego SP 800-115 świadomie unika.

MITRE ATT&CK^[11] nie jest metodyką testowania, tylko uporządkowanym opisem taktyk i technik obserwowanych u rzeczywistych napastników. W testach służy do opisania, co konkretnie zasymulowano, co pozwala zespołowi obrony sprawdzić, które z tych zachowań w ogóle wykrył.

TIBER-EU^[6] to z kolei ramy Europejskiego Banku Centralnego dla testów prowadzonych na podstawie analizy zagrożeń w sektorze finansowym. Po wejściu DORA stały się punktem odniesienia dla testów penetracyjnych opartych na scenariuszach zagrożeń u największych podmiotów finansowych.

Typowy stos wygląda więc tak: SP 800-115 jako proces, WSTG albo PTES jako warstwa techniczna, ATT&CK jako język opisu symulowanych zachowań, a przy testach regulowanych - TIBER-EU jako nadrzędne ramy organizacyjne. Po stronie zabezpieczeń odpowiednikiem tej warstwy praktycznej są CIS Controls^[13], do których często mapuje się rekomendacje z raportu.

Aspekty prawne w polskim kontekście

Test penetracyjny bez autoryzacji nie różni się technicznie od ataku, a przepisy karne nie zawierają wyłączenia dla dobrych intencji. Dlatego pisemna zgoda nie jest formalnością, tylko warunkiem legalności całego przedsięwzięcia.

Znaczenie mają przede wszystkim przepisy rozdziału XXXIII Kodeksu karnego. Art. 267 dotyczy nieuprawnionego uzyskania dostępu do informacji, w tym przełamania lub ominięcia zabezpieczenia. Art. 268 i 268a obejmują niszczenie, uszkadzanie lub zmianę zapisu istotnej informacji. Art. 269 i 269a odnoszą się do zakłócenia pracy systemu lub sieci teleinformatycznej. Art. 269b penalizuje wytwarzanie, pozyskiwanie i udostępnianie narzędzi przystosowanych do popełnienia tych czynów.

W praktyce trzy sytuacje wymagają szczególnej uwagi. Pierwsza to test obejmujący systemy utrzymywane przez zewnętrznego dostawcę - zgoda zamawiającego nie obejmuje wtedy infrastruktury, która nie jest jego. Druga to środowiska współdzielone, gdzie skutki testu mogą dotknąć podmioty trzecie. Trzecia to natrafienie na dane osobowe: sposób postępowania powinien być ustalony w ROE zawczasu, bo w trakcie testu nie ma na to czasu, a przypadkowe utrwalenie takich danych rodzi własne obowiązki wynikające z RODO.

Warto też pamiętać o oczywistości, o której łatwo zapomnieć przy testach zewnętrznych: zgoda właściciela aplikacji nie obejmuje dostawcy hostingu ani operatora sieci, przez którą prowadzony jest test.

Typowe błędy w testach

Poniższe problemy powtarzają się niezależnie od tego, kto prowadzi test i jak dużej organizacji dotyczy.

• Zakres ustalony zbyt wąsko. Test ograniczony do jednej aplikacji pomija drogę, którą napastnik faktycznie wchodzi - najczęściej przez usługę wystawioną do internetu albo skradzione poświadczenia.
• Brak wyłączeń w Rules of Engagement. Dopóki nie zapisano, czego robić nie wolno, spór o to wybuchnie w najgorszym momencie, czyli po zatrzymaniu usługi produkcyjnej.
• Autoryzacja podpisana przez osobę bez umocowania. Zgoda kierownika działu nie chroni testera, jeżeli zakres obejmuje systemy innych jednostek.
• Raport bez dowodów. Znalezisko opisane bez zrzutu ekranu, zapisu żądania czy logu jest dla zespołu naprawczego twierdzeniem, nie faktem, i pierwsze zostaje zakwestionowane.
• Ocena istotności oderwana od kontekstu. Sama punktacja CVSS nie uwzględnia tego, czy podatny system przetwarza dane krytyczne, czy stoi w izolowanym segmencie testowym.
• Brak sprzątania po fazie ataku. Pozostawione konta, narzędzia i mechanizmy utrzymania dostępu stają się realną podatnością wprowadzoną przez sam test.
• Test jednorazowy traktowany jako stan trwały. Wynik opisuje środowisko z konkretnego tygodnia. Po wdrożeniu zmian trzeba go zweryfikować ponownie, przynajmniej w zakresie naprawionych znalezisk.
• Brak retestu. Bez sprawdzenia, czy naprawa zadziałała, organizacja ma jedynie deklarację zespołu utrzymania.

10 punktów przed zleceniem testu

Lista pytań, które warto zadać, zanim podpisze się umowę na test bezpieczeństwa.

1. Cel testu. Zgodność, analiza luk czy symulacja przeciwnika? Od tego zależy wszystko dalej.
2. Zakres i wyłączenia. Spisane wprost, z adresami i nazwami systemów.
3. Wariant wiedzy. Black, gray czy white box, wraz z uzasadnieniem wyboru.
4. Metodyka. Deklaracja stosowanego przewodnika i sposób, w jaki będzie widoczna w raporcie.
5. Rules of Engagement. Uzgodnione i podpisane przed rozpoczęciem prac.
6. Pisemna autoryzacja. Podpisana przez osobę uprawnioną do reprezentowania organizacji.
7. Kwalifikacje zespołu. Doświadczenie i certyfikaty osób, które faktycznie wykonają test, a nie firmy jako takiej.
8. Postępowanie z danymi. Ustalone zasady dla danych osobowych i innych informacji chronionych.
9. Forma raportu i przekazania. Struktura, kanał, szyfrowanie, omówienie wyników.
10. Retest. Zakres i termin weryfikacji napraw, uzgodnione w umowie, a nie po fakcie.