Dobrze przygotowany projekt zaczyna się od testów pierwszego dnia. Źle przygotowany zaczyna się od tygodnia rozpoznania, które i tak obciąża budżet zamawiającego.
Część ustaleń jest wspólna dla każdego typu testu, część zależy od tego, co konkretnie badamy. Poniżej jedno i drugie.
Ustalenia wspólne
Scope i Rules of Engagement
Scope mówi, co wchodzi do testu. ROE opisuje, jak wolno się w nim poruszać. Trzy kwestie wymagają rozstrzygnięcia przed startem.
Przedmiot testu. Co dokładnie wchodzi: same systemy produkcyjne czy również testowe, aplikacja z backendem czy sama aplikacja, jedna lokalizacja czy wszystkie.
Wyłączenia. Dane rzeczywistych klientów, infrastruktura dostawców zewnętrznych, ataki DoS oraz systemy, których właścicielem jest ktoś inny, wymagają wyraźnego stanowiska.
Postępowanie przy poważnym znalezisku. Ustalenie, kto odbiera zgłoszenie, jeżeli drugiego dnia ujawni się nieuwierzytelnione RCE, zajmuje kilka minut i bywa decydujące dla przebiegu projektu.
Strona formalna
- Zgoda na testy wystawiona przez właściciela systemu, z zakresem i terminem. Przy zasobach w chmurze bywa potrzebne też zgłoszenie do dostawcy.
- NDA, jeżeli dokumentacja obejmuje informacje wrażliwe.
- Ustalenie, czy raport trafi do klienta końcowego, audytora lub jednostki notyfikowanej. Wpływa to na sposób jego przygotowania.
Kontakt
Osoba techniczna z zadeklarowanym czasem odpowiedzi. Punkt bywa niedoceniany, a jedno pytanie pozostawione bez odpowiedzi potrafi zablokować dzień pracy.
Aplikacja webowa lub API
- Adresy środowiska testowego, odseparowanego od produkcji
- Konta dla każdej roli w systemie, po dwa na rolę
- Dokumentacja API: OpenAPI, Postman albo choćby lista punktów końcowych
- Informacja o mechanizmach blokujących: WAF, rate limiting, blokada konta
- Dane testowe pozwalające przejść pełną ścieżkę biznesową
Dwa konta na rolę są istotne. Bez nich nie da się sprawdzić, czy jeden użytkownik widzi dane drugiego, a to jedna z najczęściej występujących i najdotkliwszych klas błędów.
Jeżeli WAF ma zostać włączony, warto rozważyć regułę przepuszczającą adres wykonawcy. Inaczej znaczna część budżetu idzie na omijanie własnego zabezpieczenia zamiast na testowanie aplikacji.
Aplikacja mobilna
- Pliki instalacyjne dla obu platform, w wersji zbliżonej do produkcyjnej
- Konta testowe oraz dostęp do backendu aplikacji
- Informacja o zabezpieczeniach: certificate pinning, wykrywanie roota
- Urządzenie testowe, jeżeli aplikacja wymaga konkretnego sprzętu
Sieć wewnętrzna i infrastruktura
- Zakres adresacji wraz z listą wyłączeń
- Dostęp do sieci: VPN albo stanowisko w lokalizacji
- Konto domenowe zwykłego użytkownika, jeżeli test zakłada perspektywę pracownika
- Informacja o systemach krytycznych, których nie wolno wyłączyć
- Kontakt do administratora na czas testów
Przy sieci wewnętrznej szczególnie ważne są okna czasowe. Skanowanie starszych urządzeń w godzinach pracy potrafi zakłócić ich działanie i lepiej ustalić to zawczasu niż tłumaczyć po fakcie.
Urządzenie IoT lub embedded
- Dwa egzemplarze wraz z zasilaniem i kablami
- Schemat blokowy i lista komponentów: układ główny, moduły radiowe, pamięci
- Opis interfejsów UART, JTAG, SPI i USB, również zadeklarowanych jako wyłączone
- Dokumentacja protokołu komunikacji z częścią chmurową
- Opis procesu aktualizacji wraz ze sposobem podpisywania i weryfikacji
- Konta testowe w aplikacji mobilnej i panelu
Dwa egzemplarze to nie nadmiar. Pierwszy służy testom nieinwazyjnym, drugi tym, po których urządzenie może nie wrócić do sprawności: wylutowaniu pamięci, wgraniu zmodyfikowanego firmware'u czy wymuszeniu trybu serwisowego. Przy jednym egzemplarzu zakres trzeba zaplanować ostrożniej, co zwykle podnosi nakład.
Systemy OT i ICS
- Inwentaryzacja: sterowniki, panele, wersje oprogramowania
- Schemat sieci z zaznaczonymi punktami styku IT i OT
- Okna serwisowe albo stanowisko bliźniacze do testów aktywnych
- Lista systemów, przy których dopuszczalne jest wyłącznie nasłuchiwanie
- Obecność automatyka znającego instalację
Ostatni punkt jest w OT ważniejszy niż cała reszta dokumentacji. Osoba, która wie, co dana szafa faktycznie steruje, zamienia ryzykowny test w bezpieczny.
Czego nie robić
Systemu nie należy przygotowywać pod kątem testu. Wyłączanie interfejsów diagnostycznych na czas projektu, sprzątanie kont serwisowych, podmiana konfiguracji na wzorcową czy wgranie świeżego firmware'u zaburzają obraz stanu faktycznego.
Test ma odwzorować sytuację, w jakiej system działa naprawdę. Raport opisujący środowisko przygotowane na potrzeby badania nie ma wartości praktycznej i nie obroni się przed audytorem.
Efekt
Skompletowanie właściwej listy skraca projekt zwykle o kilka dni, co przekłada się bezpośrednio na koszt. Sposób wyceny opisałem w tekście ile kosztuje pentest.
Planujesz test? Napisz, a odeślę listę dopasowaną do konkretnego przedmiotu badania. Zakres prac opisałem w sekcji usług.