Etyczny haker: kogo wynajmujesz i jak zweryfikować wykonawcę

„Wynajmę hakera” brzmi jak żart do momentu, w którym trzeba to kupić: wybrać wykonawcę, podpisać umowę i wpuścić obcych ludzi do systemu, w którym leżą dane klientów. Wtedy okazuje się, że rynek nie ma rejestru, licencji ani progu wejścia. Napisać na stronie „robimy pentesty” może każdy, a różnicę widać dopiero w raporcie – czyli po fakturze.

Poniżej rozkładamy tę transakcję na części: kogo właściwie wynajmujesz, po czym poznać, że wykonawca umie to, co deklaruje, co musi znaleźć się w umowie i jak wygląda raport, za który warto zapłacić. Samą usługę opisaliśmy osobno, w artykule co to jest test penetracyjny.

Kogo właściwie wynajmujesz

Codzienna praca niewiele ma wspólnego z postacią w kapturze ze zdjęć stockowych. W większości to czytanie, próbowanie i dokumentowanie.

• Mapowanie powierzchni ataku. Co w ogóle widać z internetu, jakie subdomeny istnieją, jakie technologie pod nimi stoją. Regularnie wychodzi z tego system testowy, o którym w firmie nikt już nie pamiętał.
• Uwierzytelnianie i autoryzacja. Czy da się podszyć pod innego użytkownika? Czy zwykłe konto widzi dane, do których nie ma prawa? Tu powstają najpoważniejsze znaleziska i żaden skaner ich nie wykryje.
• Logika biznesowa. Kupon rabatowy wykorzystany dwa razy, pominięty krok zamówienia, kwota ujemna w przelewie. Z punktu widzenia kodu nic się nie psuje, a pieniądze wychodzą.
• Łączenie podatności w łańcuch. Dwa drobiazgi, z których osobno nic nie wynika, razem dają przejęcie konta administratora. Właśnie ten łańcuch musi pokazać raport.
• Dowody. Znalezisko bez odtwarzalnego dowodu to opinia. Dowód odróżnia test od eksportu ze skanera.

Nazwa stanowiska bywa różna, praca ta sama. Na stronach i w ogłoszeniach spotkasz „etycznego hakera”, „pentestera” i „specjalistę ds. testów bezpieczeństwa”. Zamawiaj test penetracyjny – tylko ta nazwa niesie zakres, harmonogram i produkt na końcu. Oferty zatytułowanej „etyczny haking” nie da się porównać z żadną inną, bo nie mówi nic o rozmiarze prac.

Co odróżnia etycznego hakera od przestępcy

Nie technika. Technika jest ta sama. Różnica leży w trzech dokumentach.

• Upoważnienie na piśmie. Zgoda osoby uprawnionej, wydana przed rozpoczęciem prac. Musi pochodzić od tego, kto system faktycznie prowadzi – przy aplikacji w cudzej chmurze albo w modelu SaaS nie jest to automatycznie Twoja firma, a regulamin dostawcy potrafi ograniczać testy lub wymagać wcześniejszego zgłoszenia.
• Zakres. Dokładne wskazanie, co podlega testowi, a co nie. System spoza zakresu tester zostawia w spokoju, nawet jeśli widzi w nim błąd.
• Zasady prowadzenia testu. Okno czasowe, dopuszczone techniki, kontakty do eskalacji i czynności wymagające osobnej zgody. Zwykle należą do nich ataki na dostępność usługi, masowa wysyłka wiadomości i ingerencja w dane produkcyjne.

Bez tych trzech dokumentów ta sama czynność przestaje być usługą. Numerów przepisów tutaj nie cytujemy: kwalifikacja zależy od okoliczności, od tego, czyj system i czyje dane wchodzą w grę, i jest pytaniem do radcy prawnego, a nie do wykonawcy testu. Wykonawca ma w tym miejscu jedno zadanie – nie zaczynać bez zgody na piśmie.

Jakich zleceń nie przyjmujemy

Zapytanie „wynajmę hakera” łączy dwie zupełnie różne intencje, więc jednoznacznie: testujemy wyłącznie systemy, do których mamy pisemne upoważnienie osoby uprawnionej.

Nie przyjmujemy – niezależnie od uzasadnienia i od stawki:

• dostępu do cudzych kont, skrzynek, wiadomości i urządzeń, także należących do bliskich, wspólników czy pracowników;
• odzyskiwania dostępu do kont, których własności nie da się wykazać;
• testów systemów konkurenta, dostawcy albo klienta bez ich własnego zlecenia;
• śledzenia ludzi.

To nie jest formalność ani pole do negocjacji. Dostawca, który tę granicę negocjuje, przy Twoich danych też będzie ją negocjował.

Certyfikaty: co który naprawdę potwierdza

Certyfikaty to jedyny powszechnie dostępny miernik umiejętności, ale mierzą bardzo różne rzeczy. Linia podziału biegnie między egzaminem praktycznym, zdawanym na działającym systemie, a egzaminem testowym o zarządzaniu bezpieczeństwem.

Dwie rzeczy sprawdzisz w kwadrans. Po pierwsze, certyfikat ma człowiek, a nie firma – pytaj o nazwiska osób, które faktycznie wykonają test, a nie o zbiorczą listę na stronie wykonawcy. Po drugie, OffSec i ISC2 prowadzą publiczną weryfikację certyfikatów, więc poproś o numer albo link, nie o zrzut ekranu.

Co dostarczamy do audytu z art. 15 ustawy o KSC

Art. 15 ust. 1 ustawy o krajowym systemie cyberbezpieczeństwa nakłada na podmiot kluczowy obowiązek przeprowadzenia audytu bezpieczeństwa systemu informacyjnego na własny koszt, co najmniej raz na trzy lata. Ustawa wskazuje przy tym, kto może go przeprowadzić: akredytowana jednostka oceniająca zgodność, sektorowy zespół CSIRT albo co najmniej dwóch audytorów z certyfikatami z listy Ministra Cyfryzacji – CISA, CISM, CRISC, CISSP, CIA, audytor wiodący ISO/IEC 27001 lub ISO 22301, ISA/IEC 62443 Cybersecurity Expert.

Do takiego audytu dostarczamy testy i dokumentację, o którą audytor pyta. Podstawa jest wprost w przepisach: art. 8 ust. 1 pkt 2 lit. b tej samej ustawy wymaga, żeby system zarządzania bezpieczeństwem informacji obejmował „testowanie systemu informacyjnego”, a audytor weryfikuje, czy organizacja zleca testy, czy robi to regularnie i czy wyciąga z wyników wnioski. Dostajesz od nas podatności z odtwarzalnymi dowodami, oceny ryzyka, konkretne działania naprawcze i pisemne potwierdzenie z retestu, że poprawki zadziałały – w formie, którą audytor przyjmuje. Testy prowadzą u nas ludzie z certyfikatami klasy OSCP, zdobytymi na egzaminach praktycznych – nazwiska i certyfikaty czterech etycznych hakerów są na stronie o nas.

Co musi znaleźć się w umowie

Umowa na test penetracyjny to nie jedno zdanie o „przeprowadzeniu testów bezpieczeństwa”. Poniżej minimum, którego brak zauważysz dopiero wtedy, gdy coś pójdzie nie tak.

• Zakres. Lista adresów, domen, aplikacji, ról i kont testowych. Wyłączenia wpisuje się osobno i wprost, razem z systemami stron trzecich, do których nie ma zgody.
• Okno czasowe. Daty i godziny prac, w tym ustalenie, czy testy obciążające idą poza godzinami pracy. Bez tego pierwszy alert zamienia się w niepotrzebną akcję kryzysową.
• Kontakty i ścieżka eskalacji. Kto po obu stronach odbiera telefon w nocy, gdy test położy usługę albo gdy tester natrafi na ślady cudzego włamania. Ta druga sytuacja zdarza się częściej, niż wynikałoby z ofert.
• Postępowanie z danymi. Gdzie leżą dowody i dane pobrane w trakcie testu, kto ma do nich dostęp, jak długo są przechowywane i kiedy zostają usunięte. Jeśli w zakresie są dane osobowe, dochodzi umowa powierzenia przetwarzania.
• NDA. Podpisane przed rozmową o zakresie, nie po podpisaniu umowy głównej. Rozmowa o zakresie sama w sobie ujawnia architekturę.
• Ubezpieczenie OC. Suma gwarancyjna i zakres ochrony, wraz z odpowiedzią na pytanie, czy obejmuje szkody w środowisku produkcyjnym.
• Zasady publikacji. Czy wykonawca może wymienić firmę jako klienta, opisać przypadek na blogu i zgłosić znalezioną podatność producentowi oprogramowania – a jeśli tak, to w jakim terminie i po czyjej akceptacji.
• Retest. W umowie, z terminem i ceną albo w cenie testu. Warto pamiętać, że retest nie jest ponownym audytem: wykonawca sprawdza wskazane miejsca po poprawkach, a nie całą aplikację od nowa.
• Podwykonawcy. Kto fizycznie wykona pracę. Zdarza się, że nazwiska z oferty i osoby w projekcie to dwa różne zbiory.

Jak wygląda raport, za który warto zapłacić

Raport to jedyny trwały produkt testu. Za rok nikt nie będzie pamiętał rozmów, a audytor i tak poprosi o dokument. Polski rynek ma tu ustalone minimum:

• podsumowanie dla kadry zarządzającej;
• statystyki wykrytych podatności z podziałem na poziomy ryzyka;
• zestawienie podatności, a przy każdej z nich identyfikator i tytuł, poziom ryzyka, opis językiem biznesowo-technicznym, szczegóły techniczne z proof of concept (PoC) i krokami odtworzenia błędu, opcjonalnie lokalizacja oraz rekomendacja naprawcza.

Dwie rzeczy warto zrobić jeszcze przed decyzją. Poproś o zanonimizowany raport przykładowy – przed podpisem, nie po nim; raport jest produktem, a kto nie chce go pokazać, ma ku temu powód. I przeczytaj rekomendacje: „zaleca się wdrożenie dobrych praktyk” to zdanie, którego nie da się wykonać, a „zaleca się ustawienie nagłówka X o wartości Y w konfiguracji Z” to zadanie dla zespołu na jedno popołudnie.

Forma raportu przestaje być kwestią gustu w chwili, gdy staje się dowodem. Art. 8 ust. 1 pkt 2 lit. b ustawy o KSC wymaga, żeby system zarządzania bezpieczeństwem informacji obejmował bezpieczeństwo w procesie nabywania, rozwoju, utrzymania i eksploatacji systemu informacyjnego, „w tym testowanie systemu informacyjnego”. Jednostki realizujące zadania publiczne mają obowiązek starszy i częstszy – coroczny audyt bezpieczeństwa informacji z § 19 ust. 2 pkt 14 rozporządzenia w sprawie Krajowych Ram Interoperacyjności (Dz.U. 2024 poz. 773). Do tego dochodzi ryzyko z innej strony: Prezes UODO nakładał kary, wskazując w uzasadnieniu brak regularnego testowania skuteczności zabezpieczeń, na podstawie art. 32 ust. 1 lit. d RODO – tak było w decyzji dotyczącej Morele.net (DKN.5130.2484.2019).

Sygnały ostrzegawcze

• Skanowanie sprzedane jako test penetracyjny. Wynik skanera z przepisanym wstępem poznasz po tym, że każda podatność ma opis z bazy CVE, a żadna nie ma dowodu wykorzystania. Analiza podatności to osobna, tańsza i sensowna usługa – ale nie jest testem i nie powinna kosztować jak test.
• Wycena bez rozmowy o zakresie. Kto podaje cenę przed ustaleniem liczby aplikacji, ról i integracji, ten albo zgaduje, albo sprzeda skan. Od czego naprawdę zależy wycena, rozpisaliśmy w artykule ile kosztuje test penetracyjny.
• Brak retestu w ofercie. Test bez sprawdzenia poprawek kończy się listą zadań, których nikt nie odbierze.
• Brak nazwisk. „Zespół certyfikowanych ekspertów” bez ani jednego nazwiska i bez możliwości weryfikacji certyfikatu to marketing, nie referencja.
• Ten sam wykonawca znajduje i naprawia. Kto wykrywa podatności, a potem za dopłatą sam je usuwa, traci dokładnie tę niezależność, dla której audytor uznaje jego raport.
• Zgodność z Rekomendacją D w ofercie z 2026 roku. Uchwałą nr 6/2025 z 10 stycznia 2025 r. KNF uchyliła Rekomendację D, Rekomendację D-SKOK oraz komunikat chmurowy z 2020 r., ze skutkiem od 17 stycznia 2025 r., bo zastąpiło je rozporządzenie DORA. Dostawca, który wciąż sprzedaje zgodność z uchylonym dokumentem, nie śledzi regulacji, na których zarabia.

Pięć pytań przed podpisaniem umowy

1. Kto konkretnie testuje, z imienia i nazwiska, i z jakimi certyfikatami? Znaczenie mają certyfikaty praktyczne z egzaminem na działającym systemie. CISSP i CISA są cenne w zespole, ale nie są dowodem umiejętności testowania.
2. Czy przed decyzją dostanę zanonimizowany raport przykładowy? Przed podpisem, nie po nim.
3. Zgodnie z jaką metodyką prowadzicie testy? OWASP WSTG, ASVS i pozostałe standardy sprawiają, że pokrycie testu daje się sprawdzić, a raporty z kolejnych lat i od różnych wykonawców porównać.
4. Co dzieje się z danymi z testu? Miejsce przechowywania, czas, moment usunięcia, dostęp – i czy wykonawca ma ubezpieczenie OC.
5. Czy retest jest w cenie, a jeśli nie, to ile kosztuje i do kiedy przysługuje? Odpowiedź „ustalimy później” oznacza, że nie ustalicie.

Pytanie szóste jest najmniej techniczne i mówi najwięcej: czy wykonawca powie również, kiedy testu nie potrzebujesz? Kto na każde zapytanie odpowiada tą samą ofertą, nie zrozumiał zakresu. Bywa, że sensowniejszym pierwszym krokiem są testy socjotechniczne, gdy ryzyko siedzi po stronie ludzi, albo red teaming, gdy pytanie brzmi nie „czy da się wejść”, lecz „czy ktokolwiek to zauważy”.

Etyczny haker – najczęstsze pytania

Powiązane usługi Haxoris: testy penetracyjne aplikacji i infrastruktury · Red Teaming – symulacja realnego ataku na organizację · testy socjotechniczne i symulacje phishingowe