Jak przygotować test penetracyjny w organizacji

Dowiedz się, jak przygotować test penetracyjny: określić zakres, reguły działań i raportowanie, aby realnie ograniczyć ryzyko operacyjne w organizacji.

Test penetracyjny nie zaczyna się od skanowania adresów IP ani od próby przełamania mechanizmu MFA. Zaczyna się od decyzji, które systemy organizacja może bezpiecznie poddać kontrolowanej symulacji ataku i jaki efekt biznesowy ma przynieść badanie. Właściwie rozumiejąc, jak przygotować test penetracyjny, można uzyskać materiał do realnego obniżenia ryzyka, a nie jedynie raport z długą listą podatności.

W środowiskach przedsiębiorstw, samorządów i operatorów infrastruktury istotne jest zachowanie ciągłości działania. Test może obejmować systemy wspierające obsługę mieszkańców, komunikację, obieg dokumentów, dostęp zdalny, usługi chmurowe czy elementy środowiska OT. Dlatego przygotowanie wymaga współpracy właścicieli biznesowych, zespołów IT, bezpieczeństwa, prawnych oraz dostawców utrzymujących krytyczne usługi.

Jak przygotować test penetracyjny od strony biznesowej

Pierwszym krokiem jest zdefiniowanie pytania, na które test ma odpowiedzieć. Cel „sprawdzenie bezpieczeństwa” jest zbyt szeroki, aby na jego podstawie dobrać metodykę, zakres i priorytety. Inaczej planuje się badanie publicznego portalu, inaczej wewnętrznej sieci domenowej, a jeszcze inaczej procesów tożsamościowych opartych na Active Directory, Entra ID, VPN i PAM.

Dobrze sformułowany cel łączy perspektywę techniczną z ryzykiem operacyjnym. Może dotyczyć na przykład możliwości uzyskania nieuprawnionego dostępu do danych, eskalacji uprawnień po przejęciu konta użytkownika, obejścia kontroli dostępu administracyjnego albo przejścia z sieci biurowej do zasobów krytycznych. W organizacji korzystającej z modelu Zero Trust warto sprawdzić również, czy segmentacja, weryfikacja kontekstu i kontrola tożsamości działają spójnie w praktyce.

Na tym etapie należy określić właściciela testu po stronie organizacji. Powinien on mieć mandat do podejmowania decyzji, koordynowania zespołów i eskalowania incydentów. CISO lub dyrektor IT często pełni tę funkcję, jednak przy systemach o znaczeniu operacyjnym niezbędny jest także udział właściciela usługi oraz zespołu odpowiedzialnego za jej utrzymanie.

Zakres: co badać, a czego nie wolno dotykać

Zakres testu musi być jednoznaczny i możliwy do zweryfikowania. Powinien wskazywać adresy IP, domeny, aplikacje, interfejsy API, konta testowe, lokalizacje fizyczne - jeśli badanie obejmuje również ten obszar - oraz środowiska chmurowe. W przypadku większych organizacji warto powiązać zasoby z ich właścicielami oraz klasyfikacją krytyczności.

Równie ważne jest ustalenie wyłączeń. Produkcyjny system sterowania, urządzenia medyczne, infrastruktura transmisyjna, centrale telefoniczne czy usługi obsługujące płatności mogą wymagać odrębnego scenariusza lub całkowitego wyłączenia z testów aktywnych. Sam fakt, że system jest osiągalny z sieci, nie oznacza zgody na wykonywanie na nim agresywnych działań.

Warto zdecydować, jaki model badania najlepiej odpowiada celowi:

• test black box symuluje działania osoby z zewnątrz, która dysponuje minimalną wiedzą o środowisku;
• test grey box zakłada ograniczony dostęp i odzwierciedla częsty scenariusz nadużycia konta użytkownika lub dostawcy;
• test white box wykorzystuje dokumentację, konfiguracje i dostęp do kodu, dzięki czemu pozwala głębiej ocenić mechanizmy bezpieczeństwa;
• red team jest dłuższą, scenariuszową symulacją przeciwnika, ukierunkowaną na osiągnięcie konkretnego celu biznesowego.

Nie ma modelu uniwersalnie najlepszego. Black box nie zastąpi analizy uprawnień i konfiguracji, a white box nie zawsze pokaże, jak organizacja wykrywa działania napastnika. W dojrzałym programie bezpieczeństwa metody te powinny się uzupełniać.

Reguły działania chroniące ciągłość usług

Przed rozpoczęciem prac należy przygotować dokument reguł zaangażowania, często określany jako Rules of Engagement. To nie jest formalność. Dokument precyzuje granice prawne i operacyjne testu, a jednocześnie pozwala zespołom reagującym odróżnić autoryzowaną aktywność od rzeczywistego incydentu.

Reguły powinny określać przedział czasowy badania, dozwolone techniki, limity intensywności skanowania, sposób komunikacji oraz osoby uprawnione do wydania polecenia natychmiastowego wstrzymania działań. Należy z góry uzgodnić, czy dopuszczalne są próby socjotechniczne, testy odporności mechanizmów MFA, symulacja phishingu, testy Wi-Fi, sprawdzanie fizycznej kontroli dostępu czy działania poza godzinami pracy.

Szczególnej ostrożności wymagają operacje mogące wpłynąć na dostępność. Testowanie odporności na przeciążenie, blokowanie kont, masowe próby uwierzytelnienia czy skanowanie wrażliwych urządzeń powinno odbywać się wyłącznie po akceptacji właściciela usługi i z ustalonym planem wycofania. W wielu przypadkach bezpieczniej jest zweryfikować konfigurację oraz mechanizmy ochronne niż wykonywać pełną próbę eksploatacji na produkcji.

Autoryzacja musi być udzielona w formie pisemnej przez osoby uprawnione do reprezentowania organizacji i właścicieli objętych zasobów. Powinna obejmować także systemy utrzymywane przez podmioty trzecie. Brak takiej zgody nie jest luką procesową, którą można pominąć - jest granicą, której nie wolno przekraczać.

Przygotowanie techniczne i operacyjne środowiska

Zespół testujący potrzebuje aktualnych informacji, ale zakres przekazywanych danych powinien odpowiadać przyjętemu modelowi badania. Przy teście grey box przydatne będą schematy sieci, lista aplikacji, opis integracji z dostawcami tożsamości, konta o określonych rolach oraz informacje o wdrożonych mechanizmach EDR, SIEM, WAF i PAM.

Organizacja powinna także sprawdzić gotowość własnych procesów. Czy zespół SOC otrzyma informację o oknie testowym, ale bez szczegółów, które zniszczą wartość symulacji? Czy administratorzy wiedzą, do kogo eskalować alarm? Czy istnieje aktualny kontakt do dostawcy aplikacji, operatora chmury i zespołu sieciowego? W praktyce właśnie nieaktualna lista kontaktów bywa powodem niepotrzebnego ryzyka podczas testu.

Należy ustalić sposób traktowania danych pozyskanych w trakcie badania. Testerzy nie powinni pobierać większej ilości danych niż wymaga tego potwierdzenie wpływu podatności. Wystarczającym dowodem może być ograniczona próbka, zrzut ekranu lub kontrolowany zapis techniczny. Dane muszą być szyfrowane, dostępne wyłącznie dla uprawnionych osób i usunięte zgodnie z uzgodnionym harmonogramem.

W organizacjach z rozbudowaną architekturą tożsamości warto wyodrębnić scenariusze związane z przejęciem konta. Badanie powinno oceniać nie tylko siłę hasła, lecz także odporność procesu logowania, polityki dostępu warunkowego, rejestrację urządzeń, nadawanie uprawnień uprzywilejowanych oraz skuteczność MFA odpornego na phishing, takiego jak FIDO2. Samo wdrożenie technologii nie gwarantuje ochrony, jeśli wyjątki, konta serwisowe i ścieżki awaryjne pozostają poza kontrolą.

Raport, który prowadzi do decyzji

Dobry raport z testu penetracyjnego nie kończy się na ocenie CVSS. Powinien wyjaśniać, jaki scenariusz ataku został potwierdzony, jakie zasoby były dostępne, jakie mechanizmy nie zadziałały oraz jakie konsekwencje może mieć problem dla działalności organizacji. Kierownictwo potrzebuje jasnego obrazu ryzyka, a zespoły techniczne - precyzyjnych, odtwarzalnych zaleceń naprawczych.

Każde ustalenie warto opisać wraz z dowodami, poziomem ryzyka, właścicielem działania i rekomendowaną kolejnością usuwania. Priorytet nie zawsze powinien wynikać wyłącznie z technicznej krytyczności luki. Podatność o umiarkowanej ocenie może być pilniejsza, gdy umożliwia dostęp do systemu obsługującego usługi publiczne, dane wrażliwe lub konta administracyjne.

Ostatnim elementem jest retest. Bez niego organizacja nie ma pewności, czy wdrożona poprawka rzeczywiście zamknęła ścieżkę ataku i nie wprowadziła nowego problemu. Warto potraktować test jako punkt wejścia do szerszego cyklu doskonalenia: korekty segmentacji, uporządkowania uprawnień, wzmocnienia PAM, modernizacji MFA oraz poprawy monitorowania zdarzeń.

Największa wartość testu pojawia się wtedy, gdy jego wyniki trafiają do planu działań z terminami, właścicielami i wsparciem decyzyjnym. Kontrolowana symulacja ataku ma sens nie dlatego, że wykazuje błędy, lecz dlatego, że pozwala usunąć je zanim wykorzysta je rzeczywisty przeciwnik.