Haker etyczny a skaner podatności: co wybrać

„Po co płacić za test penetracyjny, skoro nasz skaner pokazuje zero luk krytycznych?” — to pytanie słyszę od właścicieli firm niemal co tydzień. Ma sens: skaner rzeczywiście dostarcza raport, który wygląda jak dowód. Kłopot w tym, że raport „zero krytycznych” nie znaczy „brak ryzyka”, tylko „nie znaleziono niczego, co pasuje do znanych wzorców”.

Analogia, która najmocniej działa na zarządy: skaner to kontrola ortograficzna, a tester to redaktor. Kontrola wyłapie literówki i powtórzenia, ale nie zauważy, że cały rozdział przeczy sam sobie i wprowadza klienta w błąd. Poprawny składniowo tekst może być zupełnie nietrafiony. Tak samo działa aplikacja: może nie mieć ani jednej luki z bazy CVE, a mimo to pozwalać kupić telewizor za złotówkę.

Poniżej rozkładamy tę różnicę na części: co automaty robią dobrze i tanio, czego nie zrobią nigdy, jak wygląda podział pracy w praktyce oraz jak uzasadnić budżet, kiedy ktoś w firmie zapyta „a po co nam człowiek?”.

Co naprawdę robi skaner podatności

Skaner (Nessus, OpenVAS, Qualys, Rapid7 InsightVM) łączy się z hostami i porównuje to, co zastanie, z publicznymi bazami podatności CVE oraz zestawami reguł konfiguracyjnych. Wynik to lista pozycji z oceną CVSS i etykietą ważności — od krytycznej do niskiej.

Co wychodzi mu dobrze:

niezałatane oprogramowanie z opisanym CVE, na przykład Apache 2.4.49 i CVE-2021-41773,
usługi wystawione na świat bez potrzeby, domyślne dane logowania, anonimowy FTP, otwarte udziały SMB,
inwentaryzacja zasobów, w tym urządzeń, których nikt nie zgłosił do IT,
wymogi formalne, takie jak kwartalne skany zewnętrzne wymagane przez PCI DSS,
praca ciągła w potoku wdrożeniowym, która wyłapuje regresje po każdej zmianie.

Czego skaner nie zrobi:

nie zrozumie procesu biznesowego ani intencji użytkownika,
nie połączy trzech usterek oznaczonych jako „niskie” w jedną realną ścieżkę ataku,
nie sprawdzi, czy podatność da się faktycznie wykorzystać w tym wdrożeniu, dlatego generuje dużo fałszywych alarmów,
nie przetestuje socjotechniki, procesu rejestracji ani obsługi klienta,
nie oceni autoryzacji w głąb: czy klient A widzi dokumenty klienta B.

Co wnosi tester pracujący ręcznie

Test penetracyjny to symulacja ataku prowadzona przez człowieka, który ma jasny cel i podpisany zakres. Tester nie odhacza listy — podejmuje decyzje. Jedna obserwacja podpowiada następny krok, a kilka drobnych usterek składa się w scenariusz, którego automat nie zaplanuje.

W praktyce praca idzie po uprawnieniach: co widzi zwykły użytkownik, co widzi pracownik obsługi, co widać po podmianie identyfikatora w adresie, czy API sprawdza uprawnienia po stronie serwera, czy tylko ukrywa przycisk w interfejsie. To właśnie tam dochodzi do realnych wycieków — i prawie nigdy nie ma tam gotowego CVE.

Ślepa plamka logiki biznesowej

Najprostszy znany mi przykład: sklep internetowy przechodzi wszystkie skany czysto. Tester loguje się, dodaje produkt do koszyka, przechwytuje żądanie i zmienia cenę z 1 299 zł na 1 zł. Zamówienie przechodzi. Skaner milczy, bo kod działa dokładnie tak, jak został napisany — nie ma błędu składni, jest błąd reguły biznesowej.

Typowe znaleziska wymagające człowieka:

eskalacja uprawnień przez podmianę parametru, na przykład rola „user” zmieniona na „admin” w żądaniu, którego serwer nie weryfikuje,
IDOR, czyli podmiana identyfikatora w adresie i dostęp do dokumentów innego klienta,
iniekcje drugiego rzędu: dane bezpieczne przy zapisie, groźne przy późniejszym przetwarzaniu,
warunki wyścigu przy operacjach na saldzie, kodach rabatowych czy limitach wypłat,
łańcuchy: SSRF w usłudze o niskich uprawnieniach plus dostęp do metadanych chmury i poświadczenia.

Porównanie: skaner i tester obok siebie

Kryterium	Skaner automatyczny	Tester (test penetracyjny)
Czas	minuty do godzin	dni do tygodni
Częstotliwość	ciągle lub co tydzień	kwartalnie lub rocznie
Koszt	setki do kilku tysięcy USD rocznie	5 000–30 000 USD za zlecenie
Zakres	znane CVE, błędne konfiguracje	logika, łańcuchy, błędy autoryzacji
Fałszywe alarmy	dużo, wymagają weryfikacji	niewiele, znaleziska są potwierdzone
Logika biznesowa	nie	tak
Zgodność	podstawowe wymogi skanów	pełny raport pod SOC 2 i ISO 27001
Wynik	automatyczny raport	raport z dowodami, wpływem i naprawą

Co realnie sprawdzają audyty

PCI DSS wymaga kwartalnych skanów zewnętrznych wykonanych przez ASV oraz corocznego testu penetracyjnego przeprowadzonego przez wykwalifikowanego assessora. Raport ze skanu nie zastępuje testu.

SOC 2 w raporcie typu II oczekuje dowodów na test penetracyjny wykonany przez niezależną stronę trzecią. Audytorzy nie przyjmą w tej roli wydruku ze skanera.

ISO 27001, kontrola 8.8 z Załącznika A, wymaga testowania podatności technicznych. W praktyce dla systemów wystawionych do internetu oczekuje się testu ręcznego, a nie tylko skanu.

NIS2 i RODO nie narzucają konkretnej metody, ale wymagają zarządzania ryzykiem i adekwatnych środków technicznych. Po incydencie brak jakichkolwiek testów bywa podstawą zarzutu o zaniedbanie.

Jeśli budujesz zgodność wyłącznie na skanach, audyt najprawdopodobniej zakończy się pytaniem: gdzie jest raport z testu?

Jak połączyć jedno z drugim

To nie jest wybór „albo”. Warstwy się uzupełniają:

Skanowanie cykliczne, co miesiąc lub kwartał — higiena: łatki, konfiguracja, inwentarz. Pozycje krytyczne i wysokie zamykane w ustalonych terminach.
Test penetracyjny raz w roku — ręcznie, na aplikacjach i obwodzie sieci, zawsze po większej zmianie architektury albo wdrożeniu nowej wersji.
Test socjotechniczny przy okazji testu rocznego — sprawdza, czy zespół rozpoznaje i zgłasza próby wyłudzenia.

Firmy o podwyższonym ryzyku, na przykład fintech, medtech i operatorzy infrastruktury krytycznej, dokładają drugi test w roku, ciągłe skanowanie oraz program bug bounty, który daje badaczom zewnętrznym stały powód, by patrzeć na ich systemy.

Ile to kosztuje i jak policzyć sensowność

Ceny testów bywają szokiem, dopóki nie porówna się ich z kosztem incydentu:

aplikacja internetowa o średniej złożoności: zwykle 5 000–15 000 USD, czyli 3–5 dni pracy doświadczonego testera,
mała sieć, około 50 hostów: 5 000–12 000 USD,
wyciek bazy klientów: kary, koszty prawne, powiadomienia, utrata zaufania i przerwa w działaniu — suma zwykle wielokrotnie przewyższa roczny budżet na testy.

Pytanie nie brzmi „czy nas stać na test”, tylko „czy stać nas na incydent, którego byśmy uniknęli”.

Jak wybrać wykonawcę i zabezpieczyć siebie

Podpisany zakres i pisemne upoważnienie to warunek startu, nie formalność. W umowie powinny znaleźć się: lista systemów i adresów objętych testem, wyraźne wyłączenie infrastruktury osób trzecich oraz usług w chmurze bez zgody dostawcy, okno czasowe, sposób raportowania krytycznych znalezisk w trakcie prac, NDA, ubezpieczenie OC i zasada, że tester nie kontynuuje eksploatacji, jeśli grozi to przerwą w działaniu.

Warto też ustalić z góry: raport z dowodami (zrzuty, żądania, logi), opis wpływu biznesowego przy każdym znalezisku, priorytety napraw oraz retest w cenie. Certyfikaty pokroju OSCP, CREST czy CEH są sygnałem jakości, ale nie zastąpią próbki raportu i rozmowy o metodzie.

Najczęstsze pytania

Ile trwa test penetracyjny? Aplikacja internetowa o średniej złożoności to zwykle 3–5 dni roboczych, mała sieć 3–7 dni. Na raport trzeba doliczyć kilka dni.

Czy test może wyłączyć system? Prawidłowo poprowadzony test ma być nieniszczący, a zakres określa, co wolno. Mimo to przed startem warto mieć sprawdzoną kopię zapasową i uzgodnione okno serwisowe.

Jak często powtarzać? Minimum raz w roku oraz po każdej istotnej zmianie architektury lub większym wdrożeniu. Przy danych wrażliwych i wymogach regulacyjnych — co pół roku.

Chcesz wiedzieć, czy ktoś realnie może przejąć dane Twoich klientów, a nie tylko czy brakuje łatki? Skontaktuj się z zespołem Cyberlord, aby zaplanować test penetracyjny w uzgodnionym zakresie i z pisemnym upoważnieniem. Pracujemy tymi samymi technikami co realni napastnicy — po to, żebyś zamknął luki przed nimi.

Haker etyczny czy automatyczny skaner: co wybrać?