Jak przygotować się do testu penetracyjnego

Test penetracyjny to jedna z najskuteczniejszych metod sprawdzenia realnego bezpieczeństwa organizacji — pod warunkiem, że jest dobrze przygotowany. Z naszego doświadczenia różnica między testem, do którego firma podeszła świadomie, a testem „zamówionym, bo audytor kazał”, potrafi być ogromna: ten pierwszy kończy się listą konkretnych, naprawionych podatności, ten drugi — raportem, który ląduje w szufladzie. Poniżej przewodnik po całym procesie: od decyzji o teście po retest.

Po co właściwie robi się test penetracyjny

Test penetracyjny (pentest) to kontrolowany atak na wskazane systemy, prowadzony przez wykwalifikowanego specjalistę na podstawie pisemnej zgody. Cel jest prosty: znaleźć i udokumentować podatności zanim zrobi to prawdziwy napastnik — wraz z dowodem, że da się je faktycznie wykorzystać, i oceną, jakie miałoby to skutki dla biznesu.

Typowe powody zamówienia testu to:

wymóg kontraktowy lub regulacyjny — coraz więcej umów B2B, polis cyberubezpieczenia oraz regulacji (NIS2, DORA, ISO 27001) oczekuje regularnych testów,
wdrożenie nowej aplikacji lub usługi — test przed startem produkcyjnym jest wielokrotnie tańszy niż incydent po starcie,
weryfikacja po zmianach — migracja do chmury, fuzja, nowa infrastruktura,
świadoma decyzja zarządu, że warto poznać stan faktyczny, a nie deklarowany.

Warto od razu odróżnić pentest od skanu podatności. Skaner znajduje znane, skatalogowane słabości i generuje długą listę alertów — bez potwierdzenia, czy da się je wykorzystać. Pentester łączy narzędzia z ręczną analizą: weryfikuje znaleziska, łączy pozornie drobne błędy w łańcuchy ataku i pokazuje realny wpływ. Skan to badanie przesiewowe, pentest — diagnoza.

Rodzaje testów: co wybrać

Zakres i model testu powinny wynikać z tego, co chcesz sprawdzić:

Test aplikacji webowej lub API — najczęściej zamawiany. Sprawdza uwierzytelnianie, kontrolę dostępu, walidację danych i logikę biznesową, zwykle według metodyki OWASP (WSTG, ASVS).
Test infrastruktury zewnętrznej — wszystko, co wystawione do internetu: VPN-y, serwery pocztowe, panele logowania, zapomniane subdomeny.
Test infrastruktury wewnętrznej — scenariusz „atakujący jest już w sieci”: eskalacja uprawnień, ruch boczny, drogi do Active Directory.
Testy socjotechniczne — kontrolowany phishing, vishing; sprawdzają procesy i ludzi, nie technologię.
Red teaming — wielotygodniowa symulacja realnego przeciwnika z ustalonymi celami; dla organizacji, które mają już dojrzały program bezpieczeństwa.

Do tego dochodzi poziom wiedzy przekazanej testerowi: black box (tester wie tyle, co anonimowy napastnik), grey box (ma konto testowe i podstawową dokumentację) oraz white box (pełna dokumentacja, czasem kod źródłowy). Wbrew intuicji black box wcale nie jest „najbardziej realistyczny” w przeliczeniu na budżet — tester spędza czas na rozpoznaniu, które realny napastnik prowadziłby tygodniami. Dla większości firm najlepszy stosunek wartości do ceny daje grey box.

Przed testem: siedem rzeczy do ustalenia

Dobre przygotowanie to głównie decyzje i komunikacja. Przed startem ustal z wykonawcą:

Cel testu. „Chcemy sprawdzić, czy da się dostać do danych klientów” to lepszy cel niż „przetestujcie wszystko”. Cel określa scenariusze i priorytety.
Zakres (scope). Konkretne adresy, domeny, aplikacje i sieci — oraz to, co jest wyraźnie poza zakresem (np. środowisko produkcyjne partnera, systemy podtrzymania życia, infrastruktura dostawcy chmury).
Zasady zaangażowania (rules of engagement). Okna czasowe testów, dozwolone techniki, zasady dotyczące działań potencjalnie inwazyjnych (eksploatacja, ataki na hasła), kontakt awaryjny po obu stronach.
Środowisko. Produkcja czy staging? Test stagingu jest bezpieczniejszy, ale musi być zbliżony konfiguracją do produkcji, inaczej wyniki będą złudne.
Konta testowe i dostępy. Przy grey box przygotuj konta o różnych rolach (użytkownik, manager, admin) — testy kontroli dostępu tego wymagają.
Powiadomienia. Zdecyduj, kto w firmie wie o teście. Zespołu SOC/IT zwykle nie należy uprzedzać w pełni (test sprawdzi też wykrywanie), ale ktoś decyzyjny musi wiedzieć, żeby nie eskalować „incydentu” do organów ścigania.
Formalności. Umowa z klauzulą zgody na testy (tzw. get out of jail card), NDA, a jeśli w grę wchodzą dane osobowe — podstawa przetwarzania. Bez pisemnej zgody właściciela systemów test jest przestępstwem, dlatego profesjonalny wykonawca zawsze zaczyna od dokumentów.

Czego nie robić przed testem

Dwie pokusy psują wartość testu. Pierwsza: wielkie sprzątanie tuż przed startem — wyłączanie usług, łatanie na szybko, ukrywanie testowych serwerów. Test ma pokazać stan faktyczny; sztucznie poprawiony obraz oznacza, że płacisz za badanie fikcji, a realne luki zostają. Druga: zawężanie zakresu do miejsc, o których wiesz, że są bezpieczne. Największe znaleziska niemal zawsze pochodzą z systemów, o których nikt nie pamiętał — starych paneli, zapomnianych subdomen, integracji „tymczasowych” sprzed trzech lat.

Jak wygląda sam test

Typowy przebieg testu aplikacji lub infrastruktury (1–3 tygodnie):

Rozpoznanie — mapowanie powierzchni ataku, identyfikacja technologii i punktów wejścia.
Skanowanie i analiza — automatyczne narzędzia plus ręczna weryfikacja; eliminacja fałszywych alarmów.
Eksploatacja — kontrolowane potwierdzenie, że podatność jest realna; zbieranie dowodów (PoC).
Poeksploatacja — sprawdzenie, jak daleko można zajść: eskalacja uprawnień, dostęp do danych, ruch boczny.
Raportowanie — opis każdego znaleziska z oceną ryzyka i rekomendacją naprawczą.

W trakcie testu dobry wykonawca komunikuje się na bieżąco: znaleziska krytyczne zgłasza natychmiast, nie czekając na raport końcowy. Jeśli tester znajdzie aktywne ślady wcześniejszego włamania — test zamienia się w reagowanie na incydent i to też powinno być ustalone zawczasu.

Jak czytać raport i co zrobić po teście

Raport powinien mieć dwie warstwy: streszczenie dla zarządu (co znaleziono, jakie to ryzyko biznesowe, co naprawić najpierw) oraz część techniczną (kroki odtworzenia, dowody, rekomendacje dla zespołu IT). Każde znalezisko powinno mieć ocenę ryzyka (np. CVSS z kontekstem biznesowym) i konkretny sposób naprawy.

Po otrzymaniu raportu:

Przejrzyj znaleziska z zespołem i wykonawcą — sesja omówienia raportu powinna być w cenie.
Zaplanuj naprawę według ryzyka, nie według łatwości. Krytyczne i wysokie — w dni, nie miesiące.
Szukaj przyczyn systemowych: jeśli test znalazł pięć błędów kontroli dostępu, problemem jest proces tworzenia oprogramowania, nie pięć linijek kodu.
Zamów retest. Weryfikacja poprawek to standardowy element — u nas jest częścią każdego projektu. Bez retestu nie wiesz, czy naprawa zadziałała.

Ile to kosztuje i jak często testować

Ceny zależą od zakresu: test pojedynczej aplikacji webowej to zwykle wydatek rzędu kilkunastu–kilkudziesięciu tysięcy złotych, kompleksowy test infrastruktury — odpowiednio więcej. Podejrzanie tanie oferty zwykle oznaczają raport ze skanera z logo na okładce — poznasz je po braku ręcznej weryfikacji i rekomendacjach kopiowanych z bazy CVE.

Rozsądny rytm dla większości firm: pełny test raz w roku oraz dodatkowo po każdej istotnej zmianie (nowa aplikacja, migracja, przebudowa sieci). Między testami lukę wypełnia cykliczne zarządzanie podatnościami i skanowanie.

Najczęstsze pytania (FAQ)

Czy test penetracyjny może coś zepsuć? Ryzyko istnieje, ale jest zarządzalne: profesjonalny tester uzgadnia działania inwazyjne przed ich wykonaniem, pracuje w ustalonych oknach czasowych i unika technik destrukcyjnych. W praktyce zdecydowana większość testów przebiega bez żadnego wpływu na działanie systemów — a scenariusze wysokiego ryzyka można przenieść na środowisko testowe.

Black box czy grey box — co wybrać na pierwszy test? Grey box. Za ten sam budżet dostaniesz znacznie głębsze pokrycie: tester nie spala dni na zgadywanie tego, co możesz mu po prostu dać (konta testowe, lista endpointów). Black box ma sens jako uzupełnienie — np. do sprawdzenia, ile realnie widać z zewnątrz.

Czy mała firma też potrzebuje pentestu? Jeśli przetwarzasz dane klientów, masz aplikację wystawioną do internetu albo kontrahenci pytają o bezpieczeństwo — tak, choć zakres może być mniejszy. Dla najmniejszych firm dobrym startem bywa audyt bezpieczeństwa z elementami testów zamiast pełnego pentestu.

Jak sprawdzić kompetencje wykonawcy? Pytaj o certyfikaty potwierdzające umiejętności praktyczne (OSCP, OSEP, PNPT, CRTO), przykładowy zzanonimizowany raport i metodykę (OWASP WSTG, PTES). Dobry wykonawca chętnie pokaże, jak wygląda jego raport — to najlepszy przedsmak jakości.

Co powinno się znaleźć w umowie? Zakres i harmonogram, pisemna zgoda na prowadzenie testów, zasady zaangażowania, NDA i zasady przetwarzania danych z projektu, ustalenia dotyczące raportu i retestu oraz kontakt awaryjny. U nas te elementy są standardem — umów konsultację, a przejdziemy przez nie wspólnie przed startem.

Podsumowanie

Wartość testu penetracyjnego w dużej mierze powstaje przed jego rozpoczęciem: jasny cel, dobrze dobrany zakres, przygotowane konta i ustalone zasady sprawiają, że tester spędza czas na szukaniu podatności, a nie na czekaniu na dostępy. Jeśli planujesz pierwszy test albo chcesz porównać podejście z dotychczasowym wykonawcą — zobacz nasze usługi lub po prostu napisz. Pomożemy dobrać zakres do ryzyka i budżetu.