Test penetracyjny (pentest) to kontrolowany cyberatak prowadzony za zgodą właściciela systemu po to, by znaleźć luki w zabezpieczeniach, określić podatności i przygotować rekomendacje działań naprawczych. Przebieg testu penetracyjnego opiera się na czterech fazach – planowaniu, rekonesansie, testowaniu oraz raporcie z weryfikacją poprawek – i ta kolejność nie zmienia się niezależnie od tego, czy badana jest aplikacja webowa, sieć wewnętrzna czy środowisko mobilne. Etapy testów penetracyjnych różnią się natomiast głębokością i czasem trwania, ponieważ zależą od uzgodnionego zakresu oraz poziomu wiedzy przekazanej testerom.
Organizacja zamawiająca testy penetracyjne podejmuje decyzje na każdym etapie – wyznacza granice zakresu i okna czasowe, zgadza się na konkretne próby eksploatacji, wskazuje osoby kontaktowe na wypadek incydentu, a po otrzymaniu wyników przypisuje właścicieli rekomendacji naprawczych.
Poniżej opisujemy, jak przebiega pentest od pierwszego spotkania scopingowego aż po retest, i po czym poznać, że usługa została wykonana rzetelnie.
Jak wygląda test penetracyjny na etapie przygotowania i scopingu?
Scoping to faza, w której obie strony ustalają granice badania i podpisują autoryzację – pisemną zgodę właściciela systemu na kontrolowane próby włamania. Od jej treści zależy przebieg wszystkich kolejnych etapów, ponieważ to zakres, lista dozwolonych technik i okna czasowe decydują o tym, czego pentester może dotknąć, a co pozostaje poza badaniem. Ta faza kończy się dokumentem wiążącym obie strony, dlatego traktuje się ją jako część usługi, a nie formalność poprzedzającą właściwą pracę.
Określenie zakresu, celów i zasad przeprowadzenia pentestu
Zakres opisuje konkretne systemy informatyczne objęte badaniem – wskazane adresami IP, domenami, nazwami aplikacji lub identyfikatorami wersji mobilnych. Precyzja ma tu wymiar praktyczny, ponieważ każdy zasób nieujęty w zakresie zostanie pominięty, nawet jeśli pentester zauważy w nim podatność. Najczęściej zamawiane obszary badania to:
- testy infrastruktury sieciowej – serwery, urządzenia sieciowe i zapory, wraz z usługami wystawionymi na zewnątrz organizacji,
- testy aplikacji webowych i testy API – podatności klasy RCE, XSS, SQL Injection oraz błędy logiki biznesowej, których nie wykryje żaden skaner,
- testy aplikacji mobilnych – architektura rozwiązań iOS i Android oraz sposób komunikacji aplikacji z serwerami backendowymi,
- obszary uzupełniające, takie jak testy chmurowe czy testy socjotechniczne, ustalane indywidualnie w zależności od profilu ryzyka organizacji.
Jedne organizacje zamawiają testy penetracyjne przed wdrożeniem nowej aplikacji produkcyjnej, inne cyklicznie, żeby udokumentować ocenę skuteczności zabezpieczeń wobec audytora. Ten drugi motyw wynika wprost z regulacji bezpieczeństwa – RODO w art. 32 ust. 1 lit. d wymaga regularnego testowania, mierzenia i oceniania skuteczności środków ochrony, a podobne oczekiwania stawiają DORA, ISO 27001 oraz PCI-DSS. Pentest bywa więc jednym z elementów szerszego audytu bezpieczeństwa, choć nie zastępuje go w całości.
Zakres ustalony na tym etapie przekłada się bezpośrednio na koszt projektu, dlatego warto sprawdzić, co wpływa na cenę testów penetracyjnych, zanim lista badanych zasobów zostanie zamknięta.
Ostatnim elementem scopingu są zasady przeprowadzenia testu, czyli ustalenia porządkowe obowiązujące przez cały czas badania. Zapisuje się w nich cztery rzeczy:
- okna czasowe – dni i godziny, w których testerzy mogą pracować, zwykle poza szczytem obciążenia systemów,
- osoby kontaktowe po obu stronach, wraz z numerami telefonów działającymi także poza godzinami pracy,
- procedurę przerwania testu, uruchamianą wtedy, gdy badanie zacznie wpływać na dostępność środowiska produkcyjnego,
- techniki wykluczone z badania, najczęściej ataki wolumetryczne typu DoS oraz operacje na prawdziwych danych klientów.
Osobną decyzją jest to, czy zespół monitorujący bezpieczeństwo (SOC) zostanie uprzedzony o teście. Jeśli wie o badaniu, nie zablokuje ruchu testerów i praca skupia się wyłącznie na szukaniu podatności. Jeśli nie wie, przy okazji sprawdzamy coś jeszcze – czy zauważy trwający atak i jak szybko na niego zareaguje.
Wybór metodyki testów penetracyjnych i przygotowanie środowiska
Metodyka testów penetracyjnych to ustandaryzowany zestaw procedur określający kolejność działań testera, zakres sprawdzanych kontroli i sposób dokumentowania wyników. Uznane metodyki testów penetracyjnych – OWASP, PTES, OSSTMM oraz NIST – pełnią funkcję punktu odniesienia, dzięki czemu wyniki dwóch różnych badań tego samego środowiska da się porównać. Metodologia przekłada się bezpośrednio na checklisty pentestera, czyli listy kontrolne odhaczane w trakcie pracy, co ogranicza ryzyko pominięcia całej klasy podatności.
Równolegle wybiera się jeden z trzech modeli testów penetracyjnych, różniących się poziomem wiedzy przekazanej testerom:
- black-box – tester nie otrzymuje żadnych informacji o środowisku i odtwarza perspektywę napastnika z zewnątrz,
- white-box – tester dysponuje pełną wiedzą o architekturze i kodzie źródłowym, co pozwala przeszukać środowisko najdokładniej,
- grey-box – tester dostaje wiedzę częściową, na przykład konta użytkowników o różnych uprawnieniach, będącą kompromisem między realizmem a głębokością badania.
Przygotowanie środowiska po stronie zamawiającego obejmuje kilka czynności technicznych, które warto wykonać przed startem: utworzenie kont testowych o ustalonych rolach, wpisanie adresów IP testerów na listy wyjątków w systemach ochrony (o ile model testu tego wymaga), wykonanie kopii zapasowych oraz udostępnienie dokumentacji API.
Część organizacji decyduje się na badanie środowiska preprodukcyjnego, jednak wtedy trzeba potwierdzić, że odzwierciedla ono produkcję pod względem wersji komponentów i konfiguracji – inaczej wyniki będą miały ograniczoną wartość.
Jak przebiega pentest podczas analizy podatności i prób eksploatacji?
Właściwe badanie składa się z czterech następujących po sobie kroków – rekonesansu, skanowania, analizy podatności i eksploatacji – a każdy kolejny zawęża pole obserwacji z całej powierzchni ataku do pojedynczych, potwierdzonych luk. Ta część procesu testu penetracyjnego zajmuje najwięcej czasu i to w niej rozstrzyga się wartość całej usługi, ponieważ różnica między raportem skanera a raportem pentestera bierze się z pracy manualnej wykonanej właśnie tutaj.
Rekonesans, skanowanie i identyfikacja potencjalnych luk bezpieczeństwa
Rekonesans to zbieranie informacji o organizacji i jej infrastrukturze przed pierwszą próbą kontaktu z zabezpieczeniami. Dzieli się na dwa tryby o różnym poziomie ingerencji:
- rekonesans pasywny – korzysta wyłącznie ze źródeł publicznych, takich jak rejestry WHOIS, rekordy DNS, certyfikaty czy media społecznościowe, i nie zostawia śladu w systemach celu,
- rekonesans aktywny – kieruje zapytania bezpośrednio do badanych systemów, dzięki czemu potwierdza, które z ustaleń teoretycznych faktycznie odpowiadają działającej infrastrukturze.
Na tym etapie pentester sięga po techniki, które w osobnej usłudze występują jako biały wywiad (OSINT) – z ogólnodostępnych danych odtwarza listę domen i subdomen, poznaje strukturę sieci oraz stosowane technologie. Ustalenia z rekonesansu wyznaczają kierunek dalszych prac, bo zapomniana subdomena testowa albo panel administracyjny wystawiony do internetu zwykle okazują się słabszym punktem niż główna aplikacja.
Skanowanie przekłada zebrane informacje na obraz techniczny środowiska. Skanowanie portów ujawnia aktywne hosty, otwarte porty oraz nasłuchujące usługi wraz z ich wersjami, a detekcja systemu operacyjnego pozwala dopasować dalsze techniki testowania do konkretnej platformy. Standardowe narzędzia pentesterskie w tym kroku to Nmap oraz Masscan przy dużych zakresach adresowych, natomiast samo wykrywanie znanych podatności opiera się na skanerach podatności pokroju Nessusa, OpenVAS czy Nexpose. Aplikacje webowe i API bada się dodatkowo przy użyciu Burp Suite i OWASP ZAP, które przechwytują ruch między przeglądarką a serwerem.
Wynik automatycznego skanu to lista hipotez, nie lista podatności. Skanery zgłaszają fałszywe alarmy, pomijają błędy logiki biznesowej i nie rozumieją kontekstu aplikacji, dlatego rzetelna identyfikacja słabych punktów wymaga ręcznego przejrzenia każdego zgłoszenia przez testera.
Weryfikacja podatności, eksploatacja i ocena możliwych skutków ataku
Eksploatacja to kontrolowane wykorzystanie znalezionej podatności po to, by potwierdzić jej realny wpływ na bezpieczeństwo systemu. Poprzedza ją weryfikacja manualna, w której tester odrzuca fałszywe alarmy ze skanów i sprawdza scenariusze niestandardowe – takie jak błędy kontroli dostępu między kontami, obejścia logiki płatności czy niedostateczne bezpieczeństwo komunikacji aplikacji mobilnej z backendem, badane przy pomocy Wiresharka.
Potwierdzenie podatności przyjmuje formę minimalnego dowodu wpływu, czyli najmniejszej możliwej ingerencji pokazującej, co napastnik osiągnąłby w realnym ataku. Najczęściej sprowadza się do jednego z kilku efektów:
- uzyskania dostępu do zasobu bez wymaganej autoryzacji,
- podniesienia uprawnień z konta zwykłego użytkownika do administracyjnego,
- odczytania fragmentu danych potwierdzającego zasięg wycieku,
- wykonania polecenia na serwerze przy podatnościach klasy RCE.
Praca odbywa się wyłącznie w granicach uzgodnionego zakresu, co odróżnia etyczne hakowanie od realnego ataku – tester zatrzymuje się w momencie potwierdzenia podatności i nie eskaluje działań dalej, żeby nie naruszyć stabilności środowiska produkcyjnego.
Każde potwierdzone znalezisko dostaje ocenę możliwych skutków, obejmującą wpływ na poufność, integralność i dostępność danych oraz warunki potrzebne do przeprowadzenia ataku. Podatności krytyczne zgłasza się zamawiającemu natychmiast, nie czekając na raport końcowy, ponieważ ryzyko incydentów istnieje przez cały czas trwania testu i nie znika tylko dlatego, że lukę znalazł tester, a nie napastnik.
Raport z testu penetracyjnego i retest – co dzieje się po zakończeniu badań?
Raport z testu penetracyjnego to główny produkt usługi i jedyny trwały ślad po całym badaniu, dlatego jego jakość decyduje o tym, czy organizacja faktycznie usunie znalezione podatności. Dokument powstaje w dwóch warstwach, ponieważ trafia do dwóch grup odbiorców o odmiennych potrzebach:
- zespołów technicznych, które będą wdrażać poprawki,
- decydentów odpowiadających za budżet i akceptację ryzyka.
Jakie informacje powinien zawierać raport z testu penetracyjnego?
Rzetelny raport z testu otwiera podsumowanie managerskie, czyli kilkustronicowe streszczenie bez żargonu technicznego, przedstawiające ogólny stan bezpieczeństwa badanego środowiska, liczbę i wagę znalezisk oraz priorytety działań. Druga warstwa to szczegółowy raport techniczny, w którym każda podatność ma osobny wpis. Tak zbudowany jest raport przygotowywany przez Secawa, gdzie część techniczna opisuje wszystkie wykryte podatności wraz z konkretnym planem naprawczym.
Pojedynczy wpis o podatności powinien zawierać komplet informacji pozwalających odtworzyć problem bez kontaktu z testerem:
- opis podatności wraz ze wskazaniem podatnego zasobu, parametru lub funkcji,
- kroki reprodukcji i dowód wykorzystania, na przykład zrzut ekranu albo fragment żądania HTTP,
- ocenę ryzyka wyrażoną w skali CVSS, uzupełnioną o kontekst biznesowy danego systemu,
- rekomendacje naprawcze opisane na poziomie konkretnej zmiany w konfiguracji, kodzie lub procesie,
- informację o zakresie i metodyce, dzięki której czytelnik wie, co zostało zbadane i czego raport nie obejmuje.
Wartość raportu poznaje się po rekomendacjach. Zapis „należy wdrożyć walidację danych wejściowych” nie prowadzi do żadnego działania, natomiast wskazanie konkretnego endpointu, typu walidacji i miejsca w architekturze, gdzie należy ją umieścić, można od razu przekształcić w zadanie dla zespołu deweloperskiego.
Retest podatności i potwierdzenie skuteczności wprowadzonych poprawek
Retest to powtórne badanie ograniczone wyłącznie do podatności wykrytych w pierwotnym teście, przeprowadzane po zakończeniu prac naprawczych. Jego celem jest ocena skuteczności zabezpieczeń wdrożonych przez organizację, a nie poszukiwanie nowych luk, dlatego zajmuje znacznie mniej czasu niż pełne badanie. W ofercie Secawa retest stanowi opcjonalny dodatek do pakietu podstawowego, więc warto zdecydować o nim już na etapie scopingu i uwzględnić w harmonogramie prac naprawczych.
Retest rozstrzyga trzy kwestie, których nie da się potwierdzić samą deklaracją zespołu IT:
- czy poprawka faktycznie eliminuje przyczynę podatności, a nie tylko blokuje jeden wektor jej wykorzystania,
- czy wdrożone mechanizmy ochronne nie zostały obejściem zamiast naprawą, na przykład regułą WAF ukrywającą wadliwy kod aplikacji,
- czy sama poprawka nie wprowadziła nowego błędu w powiązanej funkcjonalności.
Jeśli po retestach ta sama klasa podatności wraca w kolejnych wersjach aplikacji, źródłem problemu jest proces wytwarzania oprogramowania, a nie konkretna linia kodu, i wtedy trwałą poprawę przynosi dopiero wbudowanie kontroli bezpieczeństwa w cykl developmentu, czyli podejście SSDLC. Udokumentowany retest ma też wymiar formalny, ponieważ dostarcza audytorowi dowodu, że organizacja nie tylko wykryła luki, lecz również potwierdziła skuteczność wprowadzonych poprawek.
Zamów testy penetracyjne dla swojej organizacji
