Testy Penetracyjne i Audyty

SAST czyta kod źródłowy bez uruchamiania aplikacji, DAST bada działającą aplikację od zewnątrz, a IAST obserwuje ją od środka w trakcie działania. Każde podejście widzi co innego: SAST wskaże wadliwy fragment kodu, DAST potwierdzi zachowanie widoczne dla napastnika, IAST powiąże jedno z drugim. W audycie kodu zwykle łączy się je z ręczną analizą, bo same narzędzia nie odróżnią błędu logiki biznesowej od poprawnej funkcji.

O wycenie testu penetracyjnego decyduje liczba osobodni potrzebna na ręczne przejście zakresu, a nie sama nazwa usługi. Liczy się liczba aplikacji, ról i funkcji krytycznych, tryb pracy od black box do white box oraz to, czy test biegnie na produkcji, czy na kopii środowiska. Wątek socjotechniczny, testy poza godzinami pracy i szeroki retest dokładają pracy. Porównując oferty, zestawiaj opisany zakres i skład zespołu, bo stawka bez zakresu nic nie mówi.

Harmonogram testu aplikacji wynika z liczby ról, funkcji i ścieżek biznesowych, które trzeba przejść ręcznie, a nie z rozmiaru interfejsu. Do samego okna testowego doliczasz uzgodnienie zakresu, przygotowanie kont i środowiska po Twojej stronie oraz opracowanie raportu. Doświadczone zespoły planują prace z wyprzedzeniem, więc data startu bywa dłuższą częścią kalendarza niż testowanie. Retest po poprawkach planuje się osobno i obejmuje wyłącznie zgłoszone znaleziska.

Test penetracyjny może zakłócić działanie systemu, dlatego ryzyko uzgadnia się przed startem, zamiast zakładać, że prace przejdą niezauważone. Część technik, na przykład próby przeciążenia albo masowe wysyłanie zapytań, wyłącza się z zakresu lub przenosi na kopię środowiska. Dla pozostałych ustala się okno testowe, kontakt awaryjny po obu stronach i warunek natychmiastowego przerwania prac. Dział utrzymania trzeba uprzedzić, żeby alarmy z monitoringu nie uruchomiły procedury incydentu.

Test penetracyjny wymaga po stronie klienta trzech ról: osoby decyzyjnej, która podpisze zakres i zgodę, właściciela technicznego systemu oraz kontaktu awaryjnego dostępnego w oknie testowym. Właściciel techniczny przygotowuje konta o różnych poziomach uprawnień, dokumentację API i dostęp do środowiska. Jeśli platformę utrzymuje zewnętrzny hosting albo dostawca chmury, ich zgodę trzeba zebrać przed startem. Po raporcie dochodzi zespół deweloperski, bo to on wdraża poprawki.

Test penetracyjny opisuje stan wskazanego zakresu w konkretnym oknie czasu, a nie trwałą właściwość systemu. Raport bez znalezisk krytycznych mówi tylko tyle, że w tym zakresie i przy tej wiedzy zespół nie znalazł drogi wejścia. Nie jest to certyfikat, nie zastępuje audytu zgodności z normą ani red teamingu, który sprawdza również czujność obrony. Każda kolejna zmiana w kodzie, konfiguracji lub bibliotekach otwiera nowe pole do sprawdzenia.

Umowa na testy penetracyjne musi nieść pisemną autoryzację wraz z listą adresów, domen i aplikacji objętych zakresem, bo bez niej działanie pentestera nie różni się formalnie od ataku. Opisuje się w niej okno testowe, warunki przerwania prac, tryb zgłaszania znaleziska krytycznego jeszcze w trakcie testu oraz termin przekazania raportu. Osobno reguluje się prawa do raportu, w tym prawo pokazania go klientowi albo audytorowi, a także zakres odpowiedzialności dostawcy.

Dane zebrane w czasie testu, w tym zrzuty ekranu, próbki rekordów i przechwycone poświadczenia, są materiałem poufnym i ich obieg ustala się przed startem. Dobrą praktyką jest umowa o poufności, szyfrowany kanał przekazania raportu, ograniczona lista odbiorców po stronie dostawcy oraz zadeklarowany moment usunięcia kopii roboczych. Jeśli w zakresie są dane osobowe, potrzebna jest podstawa przetwarzania i powierzenie zgodne z RODO. Wiele zespołów pracuje na danych zmaskowanych albo na kontach testowych.

Produktem testu penetracyjnego jest raport z podsumowaniem dla zarządu, listą znalezisk uszeregowaną według ryzyka, dowodami wykorzystania i opisem naprawy dla każdej pozycji. Znaleziska przenosi się do rejestru zadań z właścicielem i terminem, zamiast zostawiać je w pliku PDF. Po wdrożeniu poprawek retest daje pisemne potwierdzenie, że ścieżki ataku zostały zamknięte. Raport wraz z tym potwierdzeniem służy potem jako dowód wobec klientów, audytorów i ubezpieczyciela.

Rytm testów penetracyjnych narzucają zmiany w systemie i wymagania, którym podlega organizacja, a nie sam kalendarz. Aplikacja rozwijana w krótkich wydaniach dostaje test przy większej zmianie architektury, uprawnień albo płatności, a między nimi automatyczne skanowanie i przegląd kodu. Programy zgodności, na przykład PCI DSS albo ISO/IEC 27001, oczekują regularnego cyklu i powtórzenia po istotnej zmianie. Migracja do chmury, zmiana hostingu i przejęcie cudzego systemu również otwierają nowy test.