Usługi cyberbezpieczeństwa

Organizacje budujące rzeczywistą cyber-dojrzałość sięgają po kilka różnych usług cyberbezpieczeństwa. Test penetracyjny szuka podatności w wyznaczonym zakresie systemów i pokazuje, co da się w nich zepsuć. Symulacja cyberataku odtwarza konkretny scenariusz działania napastnika, na przykład kampanię phishingową kończącą się szyfrowaniem plików, i sprawdza, czy zespół rozpozna manipulację socjotechniczną oraz czy potrafi reagować na incydenty. Red team otrzymuje cel biznesowy i samodzielnie dobiera do niego drogę, weryfikując technologię, ludzi i procedury.

Kolejność zamawiania tych usług ma większe znaczenie, niż zakłada większość zapytań ofertowych. Jeśli firma nigdy nie badała swoich aplikacji, symulacja ataku niewiele jej powie – wartościowe wnioski utoną w liczbie oczywistych błędów konfiguracyjnych. Zespół z własnym SOC i przetestowaną procedurą reakcji potrzebuje czegoś odwrotnego, bo kolejna lista podatności nie powie mu, jak ludzie zachowają się w trakcie rzeczywistego ataku. Dalej wyjaśniamy, czym te usługi różnią się w praktyce zamawiania i jak dopasować je do dojrzałości organizacji.

Pentest a symulacja cyberataku – czym różnią się te usługi?

Test penetracyjny odpowiada na pytanie, co w systemach jest podatne. Symulacja cyberataku odpowiada na pytanie, co się stanie, gdy ktoś taką podatność wykorzysta. Pierwsza usługa mierzy stan zabezpieczeń, druga mierzy reakcję organizacji, dlatego wyniki obu czyta się inaczej i wykorzystuje w innych decyzjach. Ale obie usługi dają CISO ważny obraz poziomu cyberodporności.

Na czym polega test penetracyjny i jaki jest jego zakres?

Test penetracyjny to kontrolowany atak na uzgodniony wcześniej zakres systemów, prowadzony za pisemną zgodą właściciela środowiska. Celem jest znalezienie i potwierdzenie luk w zabezpieczeniach oraz przygotowanie rekomendacji naprawczych.

Aby przeprowadzić w kontrolowanym środowisku symulację prawdziwego ataku na system, należy ustalić jej zakres. Obejmuje zwykle jeden z kilku obszarów:

infrastrukturę serwerowo-sieciową, czyli serwery, urządzenia sieciowe i zapory,
aplikacje webowe i API, badane pod kątem podatności z listy OWASP Top 10 oraz błędów logiki biznesowej,
aplikacje mobilne, wraz ze sposobem ich komunikacji z serwerami.

Wynikiem są potwierdzone podatności z oceną ryzyka i planem naprawczym, a nie ocena czujności zespołu. Zespół IT zwykle wie o trwających testach, bo w tym modelu nikt nie sprawdza, czy atak zostanie wykryty. Jeśli interesuje Cię przebieg badania od scopingu po retest, opisaliśmy osobno, jak krok po kroku przebiega test penetracyjny, natomiast szczegóły zamawiania usługi znajdziesz na stronie testy penetracyjne.

Jak przebiega symulacja ataku hakerskiego na przedsiębiorstwo?

Symulacja ataku hakerskiego odtwarza wybrany scenariusz działania napastnika w warunkach kontrolowanych przez zamawiającego. Punktem odniesienia jest zachowanie członków organizacji. Scenariusz opisuje się od strony celu napastnika, na przykład wyłudzenia danych dostępowych, uruchomienia złośliwego załącznika albo przejęcia kontroli.

Symulacja cyberataku mierzy rzeczy, których pentest nie sprawdza:

czy SIEM lub system XDR wygenerował alert i czy ktoś na niego zareagował,
ile czasu minęło od pierwszej podejrzanej aktywności sieciowej do jej wykrycia,
czy pracownik zgłosił próbę wyłudzania informacji, zamiast tylko ją zignorować,
czy procedury reakcji na incydent bezpieczeństwa zadziałały w praktyce, a nie tylko w dokumencie.

Najczęściej wykorzystywanym wektorem pozostają techniki inżynierii społecznej, ponieważ prowadzą do celu szybciej niż podatności techniczne. Kontrolowane kampanie tego typu funkcjonują jako symulacje phishingu, a mechanizmy psychologiczne, na których się opierają, omawiamy w artykule o tym, czy socjotechnika jest dobrą czy złą manipulacją.

Jednorazowa symulacja pokazuje natomiast stan z danego dnia, a trwała zmiana nawyków wymaga powtarzalnych ćwiczeń. Na tym opiera się Praktyczny Trening Antyphishingowy Secawa, czyli regularne symulacje cyberataków, przez które przeszło już ponad 120 000 pracowników. Przekonaj się, jak przebiega nasz trening i jak działa nasza autorska platforma, która pozwala prowadzić kampanie i zbierać z nich statystyki oraz generować raporty. Umów bezpłatne demo platformy.

Red teaming a testy penetracyjne – najważniejsze różnice

Test penetracyjny bada zakres, a red team realizuje cel. W red teamingu wystarczy jedna skuteczna ścieżka do celu, żeby uznać operację za udaną. Z tej jednej różnicy wynikają wszystkie pozostałe: długość projektu, poziom wiedzy zespołu obrony i sposób raportowania wyników.

Jak red teaming sprawdza cyber-odporność technologii, ludzi i procedur?

Pentest przede wszystkim szuka podatności; red team sprawdza, czy przeciwnik może wykorzystać dostępne możliwości, aby osiągnąć określony cel, oraz jak przedsiębiorstwo wykryje i powstrzyma taką operację Zespół obrony zwykle nie wie o działaniach read teamu, bo ich zauważenie jest jednym z badanych elementów.

Badanie może obejmować trzy warstwy jednocześnie:

technologię – podatności, błędy konfiguracji oraz skuteczność mechanizmów detekcji,
ludzi – reakcję pracowników na kontakt telefoniczny, wiadomość czy próbę wejścia do budynku, sprawdzaną również jako osobna usługa w formie testów socjotechnicznych,
procedury – ścieżkę eskalacji, komunikację między zespołami i czas potrzebny na podjęcie decyzji.

Ten model odtwarza sposób działania zaawansowanych grup przestępczych, opisywanych jako Advanced Persistent Threat (APT), które łączą techniki techniczne z manipulacją ludźmi i działają cierpliwie przez tygodnie. Raport z takiej operacji wygląda inaczej niż raport z pentestu, ponieważ opisuje przebieg jednej lub kilku ścieżek ataku wraz z momentami, w których organizacja mogła je zatrzymać. Lista wszystkich podatności w środowisku nie jest tu produktem końcowym.

Symulacja ataków cybernetycznych w realistycznym scenariuszu zagrożenia

Abuy zaprojektować skuteczny scenariusz należy wyjść od profilu zagrożeń konkretnej organizacj. Firma produkcyjna dostaje scenariusz oparty na atakach ransomware wstrzymujących linię produkcyjną, a instytucja finansowa scenariusz kradzieży danych klientów. Inaczej wyglądają też cyberzagrożenia typowe dla instytucji rządowych i sektora edukacji, więc scenariusz zawsze buduje się od pytania, co w danej organizacji stanowi realny łup dla napastnika.

Symulacja ataków cybernetycznych zaczyna się od rozpoznania. Zespół zbiera informacje z ogólnodostępnych źródeł, korzystając z technik, które w osobnej usłudze występują jako biały wywiad (OSINT) – nazwiska i role pracowników, adresy e-mail, wykorzystywane technologie, wzory komunikacji firmowej. Im dokładniejsze rozpoznanie, tym trudniej odróżnić działania zespołu od prawdziwych hakerów, a to bezpośrednio wpływa na wiarygodność wyniku.

Realistyczny scenariusz nie oznacza braku hamulców. Zasady operacji ustala się na piśmie i obejmują one:

granice działania, na przykład zakaz faktycznego szyfrowania danych czy zatrzymywania procesów produkcyjnych,
sygnał przerwania operacji, gdy działania zaczynają zagrażać ciągłości biznesowej,
osoby wtajemniczone po stronie zamawiającego, zwykle dwie lub trzy, potwierdzające legalność działań w razie eskalacji,
sposób dokumentowania każdego kroku, potrzebny do późniejszego odtworzenia przebiegu ataku.

Tańszym wariantem sprawdzania systemów obronnych pozostają ćwiczenia sztabowe, rodzaj gry wojennej prowadzonej na papierze. Zespół omawia wtedy scenariusze obronne bez ingerencji w działające środowisko, co pozwala przetestować decyzje i komunikację, choć nie weryfikuje skuteczności zabezpieczeń technicznych.

Symulacja cyberataków, pentest czy red teaming – którą usługę cyberbezpieczeństwa wybrać?

Kiedy wystarczy pentest, a kiedy potrzebna jest symulacja prawdziwego ataku socjotechnicznego?

Pentest wystarcza wtedy, gdy pytanie dotyczy konkretnego systemu. Sprawdza się w sytuacjach, w których trzeba udokumentować stan zabezpieczeń albo zamknąć znane ryzyko techniczne:

przed wdrożeniem nowej aplikacji na produkcję,
po większej zmianie architektury lub migracji do nowego środowiska,
gdy audytor lub regulator wymaga dowodu oceny skuteczności zabezpieczeń,
gdy organizacja nigdy wcześniej nie badała danego obszaru,
przy cyklicznym sprawdzaniu bezpieczeństwa danych w systemach krytycznych.

Symulację ataku warto zamawiać niezależnie od dojrzałości środowiska, bo mierzy ryzyko, którego pentest nie widzi. Raport techniczny opisze stan systemów, natomiast reakcję ludzi da się poznać tylko wtedy, gdy ktoś naprawdę spróbuje ją wykorzystać. Jedna kampania pokazuje jednak wynik z konkretnego dnia, a nie poziom ryzyka ludzkiego w organizacji.

Wiarygodny obraz daje seria, nie pojedyncze badanie. Rezultat jednej symulacji zależy od tematu wiadomości, pory roku, obciążenia zespołu i tego, kto akurat był w pracy, więc wnioski wyciągnięte z niej potrafią być mylące w obie strony. Dopiero cykliczne symulacje prowadzone w stałym rytmie pokazują trend, czyli czy odsetek zgłoszeń rośnie, a klikalność spada, oraz które grupy pracowników potrzebują dodatkowego wsparcia.

Są momenty, w których pojedyncza symulacja daje szczególnie dużo:

po incydencie bezpieczeństwa, gdy trzeba sprawdzić, czy podobny atak zostanie tym razem zauważony,
po wdrożeniu nowego narzędzia monitorującego, żeby potwierdzić, że faktycznie generuje użyteczne alerty,
po zmianach kadrowych lub reorganizacji, które przetasowały uprawnienia i ścieżki komunikacji,
po zakończeniu szkolenia, jako pomiar jego skuteczności zamiast ankiety satysfakcji,
przed audytem, gdy potrzebny jest dowód, że procedury reakcji zostały przetestowane w praktyce.

Jak dopasować symulację ataków hakerskich do celów i dojrzałości organizacji?

Dojrzałość organizacji wyznacza górną granicę tego, co warto zamówić. NIST Cybersecurity Framework 2.0 definiuje Implementation Tiers, czyli cztery poziomy opisujące rygor zarządzania ryzykiem cyberbezpieczeństwa:

Tier 1, Partial – działania są doraźne i reaktywne, brakuje spójnych polityk, a decyzje o ryzyku podejmuje się nieformalnie, zwykle dopiero po incydencie,
Tier 2, Risk Informed – kierownictwo zatwierdziło praktyki bezpieczeństwa i prowadzone są oceny ryzyka, ale ich wyniki nie przekładają się konsekwentnie na decyzje w całej organizacji,
Tier 3, Repeatable – zarządzanie ryzykiem jest sformalizowane, udokumentowane i regularnie przeglądane, a polityki obowiązują spójnie w całej organizacji,
Tier 4, Adaptive – organizacja doskonali zabezpieczenia w sposób ciągły, opierając się na własnych danych i informacjach o zagrożeniach.

Skala przydaje się przy wyborze usługi, bo wynik badania jest wart tyle, ile organizacja potrafi z nim zrobić. Na dwóch pierwszych poziomach najwięcej zmienia pentest, który daje uporządkowaną listę podatności z oceną ryzyka, oraz cykliczne symulacje mierzące ryzyko ludzkie. Od poziomu Repeatable sens nabiera sprawdzanie procedur pod presją, bo jest już co sprawdzać, a red teaming staje się realną opcją tam, gdzie wykrywanie i reakcja działają na tyle sprawnie, że warto je zaskoczyć.

Wymagania regulacyjne przesuwają część tych decyzji z „warto” na „trzeba”. RODO nakazuje regularne testowanie i ocenianie skuteczności zabezpieczeń, a znowelizowana ustawa o krajowym systemie cyberbezpieczeństwa wdrażająca dyrektywę NIS2 dokłada obowiązki związane z zarządzaniem ryzykiem i raportowaniem incydentów. Co z tego wynika dla harmonogramu badań, opisaliśmy przy okazji wdrożenia UKSC i NIS2.

W praktyce zamawiania większość organizacji układa te usługi w plan roczny. Pentesty obejmują systemy krytyczne w stałym cyklu, symulacje ataków sprawdzają wykrywanie i reakcję raz albo dwa razy w roku, a red teaming pojawia się rzadziej, jako sprawdzenie całości po zamknięciu wcześniejszych luk.

Black box, white box i grey box to trzy modele testu bezpieczeństwa, które różnią się przede wszystkim zakresem wiedzy, jaką tester otrzymuje o testowanym środowisku przed rozpoczęciem pracy – od pełnej anonimowości napastnika z zewnątrz, przez częściowy dostęp do informacji, po pełny wgląd w architekturę i kod. Wybór modelu wpływa bezpośrednio na to, jaki rodzaj podatności zostanie wykryty, ile czasu zajmie test i jak realistycznie odwzoruje on rzeczywisty atak.

Decyzja o wyborze wariantu ma znaczenie praktyczne dla każdej organizacji zamawiającej testy penetracyjne – błędnie dobrany model może pominąć krytyczne luki albo niepotrzebnie wydłużyć projekt bez proporcjonalnej korzyści.

W tym artykule pokazujemy, czym różnią się black box, white box i grey box testing, czego każdy z nich nie wykrywa, oraz jakie kryteria – cel testu, dojrzałość zabezpieczeń, dostępny czas i wymagania regulacyjne takie jak RODO, DORA czy ISO 27001 – pozwalają dobrać model do konkretnej sytuacji.

Black box testing – na czym polega test bez wiedzy o systemie?

Black box testing, czyli test czarnej skrzynki, to model testu bezpieczeństwa, w którym tester nie ma żadnej wcześniejszej wiedzy o architekturze, kodzie ani infrastrukturze ocenianego środowiska – działa wyłącznie na podstawie tego, co widoczne jest z zewnątrz, tak jak zrobiłby to nieznający systemu napastnik. Architektura testowania czarnej skrzynki opiera się właśnie na tym ograniczeniu dostępu do informacji, dzięki czemu wynik testu odzwierciedla realne ryzyko, jakie organizacja ponosi wobec anonimowego atakującego z zewnątrz.

Test black box – co to jest i jak wygląda w praktyce?

Test black box wywodzi się z testowania oprogramowania (QA), gdzie od dekad służy do sprawdzania funkcjonalności aplikacji bez znajomości jej wewnętrznego kodu – stąd inna nazwa tego podejścia, testowanie behawioralne, skupione wyłącznie na tym, jak system testowany (SUT) reaguje na konkretne dane wejściowe. W testowaniu oprogramowania do projektowania przypadków testowych wykorzystuje się różne techniki testowania:

analizę wartości brzegowych (nazywaną też analizą wartości granicznych),
partycjonowanie ekwiwalentne (podział ekwiwalentny, czyli grupowanie danych wejściowych w klasy o podobnym zachowaniu),
testowanie tabeli decyzyjnej,
testowanie przejść stanów,
zgadywanie błędów oparte na doświadczeniu testera.

Każda z tych metod inaczej definiuje oczekiwany wynik, określany jako Test Oracle, względem którego porównuje się faktyczne odpowiedzi systemu i funkcjonalność aplikacji.

W testowaniu oprogramowania techniki te obejmują również walidację wejścia oraz walidację wejścia-wyjścia, a także walidację interfejsu użytkownika (UI), która sprawdza, czy warstwa wejściowa i warstwa wyjściowa aplikacji działają zgodnie ze specyfikacją z perspektywy użytkownika końcowego. Testowanie funkcjonalne, eksploracyjne i losowe pozwala dodatkowo wychwycić problemy z użytecznością, zanim aplikacja trafi do produkcji, choć to już zagadnienia z obszaru testowania aplikacji, a nie testów bezpieczeństwa.

W testach bezpieczeństwa ten sam model wygląda inaczej. Tester dysponuje minimalną wiedzą techniczną o organizacji – najwyżej nazwą firmy i adresem domeny – i musi samodzielnie zbudować obraz infrastruktury, zanim w ogóle przystąpi do prób ataku. Punktem wyjścia jest wtedy to, co o organizacji można ustalić z otwartych źródeł – ten sam materiał, na którym opiera się biały wywiad (OSINT). Dopiero na tej podstawie tester identyfikuje typy testowania czarnej skrzynki adekwatne do celu – od testów sieciowych po testy aplikacji webowych czy mobilnych.

Kiedy warto wybrać black box testing do oceny bezpieczeństwa?

Black box testing sprawdza się najlepiej wtedy, gdy organizacja chce poznać realny obraz swojego bezpieczeństwa z perspektywy zewnętrznego, nieuprzywilejowanego napastnika – bez założenia, że atakujący dysponuje jakąkolwiek wiedzą wewnętrzną. To naturalny wybór w kilku sytuacjach:

to pierwszy test penetracyjny w organizacji i celem jest ogólna ocena odporności na atak z zewnątrz,
priorytetem jest sprawdzenie, co realnie widać i co da się wykorzystać bez dostępu do dokumentacji czy kont testowych,
budżet lub termin nie pozwalają na głębszą analizę architektury, a wystarczający jest obraz ryzyka z perspektywy zewnętrznej.

Ograniczenia testowania czarnej skrzynki wynikają wprost z braku wiedzy testera – część czasu projektu pochłania sam rekonesans, przez co pokrycie testu bywa węższe niż w modelach z dostępem do kodu czy infrastruktury, a błędy logiczne ukryte głęboko w aplikacji mogą pozostać niewykryte. Black box, podobnie jak pozostałe modele testu technicznego, nie obejmuje też warstwy ludzkiej organizacji – nie sprawdza, czy pracownicy rozpoznają próbę manipulacji, dlatego wiele firm uzupełnia go Praktycznym Treningiem Antyphishingowym Secawa, który mierzy tę część ryzyka niezależnie od wyników testu technicznego.

White box testing – jak przebiega test z pełnym dostępem do systemu?

White box testing to model testu bezpieczeństwa, w którym tester otrzymuje pełny dostęp do dokumentacji architektury, kodu źródłowego oraz kont testowych ocenianego systemu, zanim rozpocznie właściwą analizę. Testowanie wewnętrzne tego typu pozwala ocenić bezpieczeństwo aplikacji znacznie głębiej niż z perspektywy zewnętrznego atakującego, bo tester nie musi odgadywać architektury metodą prób i błędów – a wybrany model wpływa na to, jak krok po kroku przebiega test penetracyjny, zwłaszcza na etapie rekonesansu, który w tym wariancie jest znacznie krótszy.

Jakie informacje i uprawnienia otrzymuje tester w modelu white box?

W modelu white box tester otrzymuje zestaw materiałów i uprawnień od klienta, które pozwalają ocenić bezpieczeństwo od wewnątrz, a nie tylko z perspektywy efektu końcowego widocznego na zewnątrz. Zakres udostępnianych informacji obejmuje zwykle:

dokumentację architektury systemu wraz z opisem integracji pomiędzy poszczególnymi komponentami,
dostęp do kodu źródłowego, co umożliwia code review i analizę tego, jak aplikacja obsługuje błędy oraz nietypowe dane wejściowe,
konta testowe o różnych poziomach uprawnień, dzięki czemu można sprawdzić, czy separacja ról rzeczywiście działa zgodnie z założeniami,
wymagania systemu i specyfikacje funkcjonalne, które pozwalają zweryfikować, czy zabezpieczenia odpowiadają realnym wymaganiom biznesowym, a nie tylko ogólnym dobrym praktykom.

Taki poziom dostępu ma znaczenie zwłaszcza tam, gdzie o bezpieczeństwie aplikacji decyduje nie tylko pojedyncza podatność, ale też integracja systemu z innymi usługami – błąd w miejscu łączenia dwóch komponentów bywa trudny do wykrycia bez wglądu w kod po obu stronach. Dlatego white box dobrze sprawdza się na etapie wytwarzania oprogramowania, zanim błędy trafią do środowiska produkcyjnego – to obszar, w którym pomocne bywają konsultacje SSDLC, pozwalające wychwycić podatności jeszcze przed wdrożeniem.

Black box a white box – różnice w zakresie, czasie i dokładności testów

Black box a white box różnice widać najwyraźniej w trzech wymiarach: ile tester wie na starcie, ile czasu zajmuje test i jak dokładne jest pokrycie testów. Poniższe zestawienie pokazuje to praktycznie:

Kryterium	Black box	White box
Wiedza wejściowa testera	Brak wiedzy o systemie	Pełna dokumentacja, kod, konta testowe
Perspektywa ataku	Zewnętrzny, nieuprzywilejowany napastnik	Osoba z dostępem wewnętrznym lub błędem w kodzie
Czas realizacji	Dłuższy rekonesans, krótsza faza analizy kodu	Krótszy rekonesans, dłuższa analiza architektury
Głębokość pokrycia	Ograniczone do tego, co widoczne z zewnątrz	Wysokie pokrycie testów, włącznie z logiką wewnętrzną
Typowe zastosowanie	Pierwszy test, ocena ryzyka zewnętrznego	Aplikacje krytyczne, systemy o wysokich wymaganiach zgodności
Główne ograniczenie	Może pominąć błędy ukryte głęboko w kodzie	Wyższy koszt i czas przygotowania dostępu dla testera

Wybór wariantu wpływa też na wycenę projektu, bo szerszy dostęp i głębsza analiza kodu wymagają więcej godzin pracy zespołu – co wpływa na cenę testów penetracyjnych opisujemy szerzej w osobnym artykule, tutaj warto jedynie zaznaczyć, że white box zwykle oznacza wyższy nakład pracy niż porównywalny zakresowo black box.

Głębsze pokrycie testów w modelu white box ma znaczenie zwłaszcza tam, gdzie liczy się nie tylko wykrycie luki, ale też ocena wydajności i niezawodności systemu pod obciążeniem błędnych danych, a niekiedy również testy niefunkcjonalne sprawdzające, czy aplikacja zachowuje się przewidywalnie w warunkach brzegowych. Ponieważ tester ma wgląd w kod, dostęp do niego bywa ograniczany dodatkowymi klauzulami poufności – ochrona własności intelektualnej klienta jest tu równie ważna jak sam wynik testu. Z perspektywy organizacji efektywność kosztowa całego projektu zależy więc od tego, czy głębsze pokrycie faktycznie odpowiada poziomowi ryzyka danego systemu, czy jest nadmiarowe względem realnych potrzeb.

Sam proces testu white box, mimo że dotyczy bezpieczeństwa, a nie jakości oprogramowania, korzysta z podobnej dyscypliny organizacyjnej. Zespół ustala plan testowania i zakres wraz z klientem, definiuje procedury testujące dla poszczególnych komponentów, dobierając przy tym narzędzia do testowania dostępne na rynku i dopasowane do konkretnej technologii. Wykonanie testów kończy się analizą wyników, weryfikacją wymagań funkcjonalnych pod kątem bezpieczeństwa oraz dokumentowaniem błędów w raporcie, który część organizacji integruje z własnymi systemami zarządzania błędami, by śledzić status poprawek razem z innymi zgłoszeniami technicznymi. Ocena obejmuje wtedy nie tylko pojedyncze podatności, ale też niezawodność systemu jako całości.

Grey box testing – kompromis między black box a white box

Grey box testing (gray box testing) to model testu bezpieczeństwa łączący cechy black box i white box – tester dysponuje częściową wiedzą o systemie, wystarczającą, by pracować efektywniej niż przy zerowym dostępie, ale bez pełnego wglądu w kod i architekturę, jaki zapewnia white box. To podejście najczęściej stanowi punkt wyjścia do rozmowy o zakresie testu, bo pozwala łączyć realizm ataku zewnętrznego z częścią korzyści płynących z wiedzy wewnętrznej.

Na czym polega grey box testing i czym różni się od pozostałych modeli?

Grey box testing, w testach bezpieczeństwa, oznacza sytuację, w której tester otrzymuje wiedzę częściową o testowanym środowisku – wystarczającą, by ograniczyć czas poświęcony na czysty rekonesans, ale nie na tyle szeroką, by mówić o pełnym dostępie do kodu czy dokumentacji. Może to oznaczać konto testowe o standardowych uprawnieniach użytkownika, ogólny schemat architektury bez szczegółów implementacyjnych albo wiedzę o tym, z jakich technologii korzysta aplikacja, bez wglądu w sam kod.

W odróżnieniu od black box, grey box nie wymaga od testera odgadywania całej architektury od zera, a w odróżnieniu od white box nie daje pełnego wglądu w logikę wewnętrzną każdego komponentu. Model ten sprawdza się szczególnie przy testowaniu systemów złożonych z wielu integracji, gdzie liczy się nie tylko pojedyncza podatność, ale też kompatybilność poszczególnych elementów – błędy i problemy ujawniają się często właśnie na styku dwóch usług, a nie wewnątrz jednej z nich.

Grey box czy gray box testing – który model testu wybrać?

Grey box czy gray box testing – to pytanie o pisownię, nie o różne modele testu: „grey” to zapis brytyjski, „gray” to wariant amerykański, a oba określają dokładnie to samo podejście testowe, oparte na częściowej wiedzy testera o systemie. Wybór między black box, white box i grey box nie sprowadza się jednak do nazewnictwa, tylko do dopasowania modelu do sytuacji organizacji. Warto wziąć pod uwagę:

cel testu – czy priorytetem jest realistyczna symulacja ataku zewnętrznego, dogłębna analiza kodu, czy złoty środek między nimi,
dojrzałość zabezpieczeń – organizacje na wczesnym etapie budowania bezpieczeństwa zyskują więcej na testach z szerszym dostępem, bo łatwiej wskazać podstawowe luki,
dostępny czas i budżet – black box wymaga więcej czasu na rekonesans, white box więcej czasu na analizę kodu, grey box zwykle mieści się pomiędzy tymi wariantami,
wymagania regulacyjne – normy takie jak RODO (w tym art. 32 ust. 1 lit. d, nakładający obowiązek regularnego testowania i oceniania skuteczności zabezpieczeń), DORA, ISO 27001, NIS2 czy PCI-DSS nie narzucają jednego modelu, ale wpływają na zakres i częstotliwość testów,
etap testowania organizacji – pierwszy test w historii firmy często zaczyna się od black box lub grey box, a kolejne iteracje mogą przechodzić w stronę white box, jeśli poprzednie wyniki wskazują na potrzebę głębszej analizy.

Żaden z trzech modeli nie jest obiektywnie lepszy – to trzy różne narzędzia do różnych sytuacji, a dobór właściwego wariantu ma większe znaczenie dla jakości wyniku niż sama nazwa metodyki.

Wciąż wahasz się, jaki wariant testów penetracyjnych wybrać dla swoich systemów? Umów bezpłatną rozmowę z naszymi specjalistami i rozwiej wątpliwości!

Zapytaj o testy penetracyjne

Cena testów penetracyjnych wynika z nakładu pracy potrzebnego do zbadania konkretnego środowiska, dlatego żaden dostawca nie publikuje sztywnego cennika ani jednej stawki za usługę. Wycena powstaje dopiero po ustaleniu zakresu i sprowadza się do oszacowania, ile dni pracy certyfikowanych specjalistów pochłonie zbadanie wskazanych systemów. Dla pojedynczej aplikacji albo średniej wielkości sieci badanie zajmuje zwykle kilka do kilkunastu dni roboczych, a rozbudowane środowiska wymagają odpowiednio dłuższego planu. Ten sam zakres wyceniony przez dwóch dostawców może się różnić, ponieważ każdy z nich inaczej szacuje pracochłonność i głębokość analizy.

Pytanie o to, ile kosztuje test penetracyjny, ma sens dopiero wtedy, gdy wiadomo, co dokładnie ma zostać przetestowane i jak głęboko. Porównywanie samych cen bez porównania zakresów prowadzi do złych decyzji zakupowych. Poniżej znajdziesz czynniki, które realnie podbijają albo obniżają koszt testów penetracyjnych, modele rozliczeń stosowane na rynku oraz listę pytań, które warto zadać dostawcy przed podpisaniem umowy.

Testy penetracyjne – cena i najważniejsze czynniki wpływające na koszt

Na wycenę testów penetracyjnych wpływają przede wszytskim trzy czynniki: rozmiar zakresu, złożoność badanego środowiska oraz wymagany poziom szczegółowości analizy. Każdy z nich przekłada się na liczbę dni pracy zespołu, dlatego dwa środowiska o podobnej wielkości mogą zostać wycenione zupełnie inaczej. Poniżej rozkładamy te czynniki na konkretne parametry, które dostawca musi poznać, żeby przygotować wiążącą ofertę.

Zakres systemów, aplikacji i infrastruktury objętej testem

Zakres testów penetracyjnych najsilniej wpływa na cenę, ponieważ wyznacza liczbę zasobów do zbadania. W zapytaniu ofertowym warto więc podać:

liczbę publicznych adresów IP oraz hostów wchodzących w zakres,
liczbę domen i subdomen, łącznie z zapomnianymi środowiskami testowymi wystawionymi do internetu,
liczbę aplikacji i ról użytkowników w każdej z nich,
liczbę endpointów API przewidzianych do przetestowania,
rodzaj testowanych zasobów, czyli aplikacje webowe, API, aplikacje mobilne lub infrastruktura serwerowo-sieciowa,
perspektywę badania, ponieważ testy zewnętrzne obejmują zasoby dostępne z internetu, a testy z wnętrza sieci wymagają dostępu do infrastruktury wewnętrznej.

Każda z tych liczb mnoży pracę w sposób, którego nie widać na pierwszy rzut oka. Aplikacja z pięcioma rolami użytkowników wymaga sprawdzenia uprawnień w każdej kombinacji dostępu, dlatego kosztuje wielokrotnie więcej niż aplikacja z jednym typem konta, choć w zapytaniu obie występują jako „jedna aplikacja”. Podobnie działa liczba integracji zewnętrznych, bo zabezpieczenia systemów trzeba wtedy sprawdzić również na styku z partnerami.

Rodzaj zasobu zmienia też skład zespołu i użyte techniki testowania. Testy penetracyjne aplikacji mobilnych wymagają analizy dwóch platform i sposobu komunikacji aplikacji z backendem, co oznacza inny nakład pracy niż zbadanie tej samej funkcjonalności w wersji przeglądarkowej. Wycena rośnie więc nie tylko wraz z liczbą zasobów, ale też z ich różnorodnością technologiczną.

Stopień złożoności środowiska oraz wymagany poziom analizy

Złożoność architektury decyduje o tym, ile czasu zajmuje zrozumienie środowiska przed rozpoczęciem właściwej pracy. Monolityczna aplikacja na standardowym stosie technologicznym jest przewidywalna, natomiast środowisko rozproszone wymaga zmapowania zależności między komponentami, zanim tester zacznie szukać podatności. Na ten czas wpływają przede wszystkim:

liczba integracji z systemami zewnętrznymi i wewnętrznymi,
architektura mikroserwisowa zamiast pojedynczej aplikacji,
mechanizmy uwierzytelniania, w szczególności SSO i federacja tożsamości,
niestandardowa technologia lub autorskie rozwiązania bez publicznej dokumentacji,
poziom udostępnionego dostępu, czyli obecność kont testowych o wszystkich rolach,
decyzja o testowaniu na środowisku produkcyjnym, która wymaga ostrożniejszego tempa pracy.

Osobnym parametrem jest wymagany poziom szczegółowości:

black-box ogranicza wiedzę testera do informacji zdobytych samodzielnie,
grey-box daje wybrane dane dostępowe i kontakt z administratorami,
white-box zakłada wgląd w kod, konfigurację i dokumentację.

Ostatni z tych wariantów jest najbardziej czasochłonny, ponieważ pozwala wykryć subtelne podatności wymagające szczegółowej wiedzy o celu, i to przekłada się bezpośrednio na wycenę.

Wymagania regulacyjne działają w tę samą stronę. RODO w art. 32 ust. 1 lit. d nakazuje regularne testowanie, mierzenie i ocenianie skuteczności zabezpieczeń, a DORA, ISO 27001, NIS2 oraz PCI-DSS dodają własne oczekiwania co do zakresu i udokumentowania badania. Organizacja podlegająca kilku regulacjom jednocześnie potrzebuje głębszej analizy podatności i obszerniejszej dokumentacji, co oznacza więcej dni pracy niż w przypadku testu zamówionego wyłącznie na potrzeby wewnętrzne.

Ile kosztuje test penetracyjny i jak wygląda jego wycena?

Wycena testów penetracyjnych powstaje na podstawie oszacowanego nakładu pracy, wyrażonego w dniach roboczych zespołu. Dostawca przelicza zakres i złożoność środowiska na czas potrzebny do zbadania każdego zasobu, dlatego wiążącą ofertę może przygotować dopiero po poznaniu szczegółów. Forma rozliczenia bywa natomiast różna i to ona rozstrzyga, kto ponosi ryzyko przekroczenia zaplanowanego czasu.

Modele rozliczeń stosowane przy wycenie testów penetracyjnych

Model rozliczenia określa sposób zapłaty za czas pracy zespołu, nie zaś zakres samego badania. Na rynku usług bezpieczeństwa spotyka się trzy podstawowe warianty:

stała cena za projekt (fixed price) – kwota ustalona z góry dla zdefiniowanego zakresu, wymaga dokładnego scopingu przed podpisaniem umowy,
rozliczenie za czas pracy (time & material) – płatność za faktycznie przepracowane dni, stosowana wtedy, gdy zakresu nie da się zamknąć na starcie,
pakiet dni w cyklu (retainer) – z góry zarezerwowana dostępność zespołu, wykorzystywana przy badaniach powtarzanych regularnie.

Stała cena daje przewidywalny budżet i przenosi ryzyko niedoszacowania na dostawcę, dlatego wybierają ją organizacje rozliczające bezpieczeństwo w ramach zamkniętego budżetu projektowego. Rozliczenie za czas pracy bywa korzystniejsze przy środowiskach słabo udokumentowanych, gdzie żadna ze stron nie potrafi z góry przewidzieć pracochłonności. Trzeci wariant sprawdza się przy cyklicznym harmonogramie testów, bo skraca czas oczekiwania na dostępność zespołu.

Budżet na testy warto planować razem z pozostałymi wydatkami na bezpieczeństwo. Organizacje, które rozkładają badania na cały rok, częściej powierzają priorytetyzację takich wydatków modelowi CISO as a Service, ponieważ kolejność testowania systemów wynika wtedy z oceny ryzyka, a nie z przypadkowej dostępności środków.

Dlaczego cena pentestu jest ustalana indywidualnie dla każdego projektu?

Cena pentestu jest ustalana indywidualnie, bo nie ma dwóch identycznych środowisk IT. Ta sama liczba aplikacji może oznaczać kilka dni pracy albo kilka tygodni, w zależności od technologii, liczby ról i wymaganej głębokości analizy. Sztywny cennik prowadziłby więc do jednego z dwóch skutków: przepłacania przy prostych zakresach albo powierzchownego badania przy złożonych.

Na indywidualny charakter wyceny wpływa kilka czynników po stronie dostawcy:

skład zespołu dobierany do technologii, ponieważ inne kompetencje wymaga badanie API, a inne aplikacji mobilnej,
kwalifikacje testerów, czyli certyfikowani specjaliści z uprawnieniami OSCP, OSWE, OSED, OSWP czy GXPN,
przyjęte standardy pracy – OWASP, PTES, OSSTMM i NIST, wyznaczające minimalny zakres kontroli do wykonania,
ocena ryzyka uzgodniona z klientem, wskazująca systemy krytyczne wymagające najdokładniejszego zbadania,
termin realizacji, bo harmonogram zespołu planowany jest z wyprzedzeniem, a pilne zlecenia trudniej wpasować w kalendarz.

Aby rzetlenie porównać oferty, warto zapytać o liczbę dni roboczych przewidzianych na badanie, wariant testu, udział pracy manualnej w stosunku do skanów automatycznych, język i strukturę raportu oraz o to, czy retest wchodzi w cenę podstawową.

Cennik testów penetracyjnych – co obejmuje koszt usługi?

Koszt usługi obejmuje trzy bloki pracy: przygotowanie badania, testy właściwe oraz opracowanie raportu. Pozycje takie jak retest, prezentacja wyników czy warsztaty wyceniane są osobno, dlatego przy porównywaniu ofert trzeba sprawdzić, co mieści się w cenie podstawowej. Ta różnica potrafi zdecydować o tym, która oferta okaże się tańsza po zamknięciu projektu.

Prace przygotowawcze, testy bezpieczeństwa i raport końcowy

Prace przygotowawcze pochłaniają czas jeszcze przed pierwszym testem. Ustalenie zakresu, uzgodnienie zasad, konfiguracja dostępów i weryfikacja kont testowych wymagają udziału obu stron, a im mniej dokumentacji dostarczy zamawiający, tym więcej godzin zespół poświęci na samodzielne rozpoznanie środowiska. Ten blok bywa niewidoczny w ofercie, choć wpływa na jej wysokość.

Testy właściwe to największa pozycja w wycenie, ponieważ obejmują pracę manualną. Analiza podatności oparta wyłącznie na skanerach automatycznych kosztuje niewiele i daje listę hipotez zamiast potwierdzonych błędów, natomiast ręczna weryfikacja każdego zgłoszenia i testowanie scenariuszy specyficznych dla danej aplikacji zajmuje dni pracy. Proporcja między jednym a drugim to najważniejsza informacja przy ocenie, czy oferta jest tania, czy tylko pozornie korzystna. Jeśli chcesz zobaczyć, jaka praca stoi za każdym z tych bloków, opisaliśmy osobno, jak krok po kroku przebiega test penetracyjny.

Raport końcowy odpowiada za spory udział w końcowej cenie, choć zamawiający rzadko to zakładają. Opracowanie podsumowania managerskiego i szczegółowej części technicznej z planem naprawczym wymaga osobnych dni pracy, a wycena rośnie wraz z wymaganiami dotyczącymi jego formy. Na koszt wpływają tu:

język raportu, w wersji polskiej albo angielskiej, lub w obu,
liczba odbiorców dokumentu, ponieważ część zarządcza i część techniczna pisane są innym językiem,
poziom szczegółowości rekomendacji, od ogólnych wskazań po konkretne zmiany w konfiguracji i kodzie,
wymagania audytora, jeśli raport ma stanowić dowód zgodności w procesie certyfikacji.

Retest podatności oraz dodatkowe usługi wpływające na końcową cenę

Retest podnosi końcową cenę, bo stanowi opcjonalny dodatek do pakietu podstawowego. Warto zdecydować o nim już przy ustalaniu zakresu, ponieważ dopisanie tej pozycji po zakończeniu projektu oznacza ponowne planowanie dostępności zespołu. Brak retestu obniża fakturę, ale zostawia organizację bez potwierdzenia, że wdrożone poprawki faktycznie usunęły podatności.

Poza retestem wycenę zwiększają pozycje zamawiane najczęściej przez organizacje raportujące wyniki poza działem IT:

prezentacja wyników dla zarządu lub komitetu ryzyka,
warsztaty z zespołem deweloperskim omawiające znalezione błędy,
code review i testy w wariancie white-box tam, gdzie zwiększają wartość badania,
cykliczne powtarzanie testów w ustalonym harmonogramie rocznym.

Koszt naprawy podatności rośnie wraz z etapem, na którym zostaje wykryta. Błąd znaleziony w gotowej, wdrożonej aplikacji wymaga zmiany kodu, testów regresyjnych i ponownego wdrożenia, dlatego organizacje wytwarzające oprogramowanie własnymi zespołami ograniczają te wydatki, wbudowując kontrole bezpieczeństwa w cykl developmentu w ramach Konsultacji SSDLC.

Część wydatków warto skierować poza warstwę techniczną. Testy penetracyjne sprawdzają zabezpieczenia systemów, natomiast nie zmieniają zachowań pracowników, którzy pozostają najczęstszym punktem wejścia do organizacji, dlatego naturalnym uzupełnieniem budżetu jest Praktyczny Trening Antyphishingowy Secawa, przez którego platformę przeszło już ponad 150 000 pracowników.

Uzyskaj wycenę testów penetracyjnych dla Twoich systemów

Wypełnij formularz

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

Testy penetracyjne SECAWA