Ile trwa test penetracyjny w małej firmie?

Test penetracyjny ma wykryć realne drogi ataku, zanim wykorzysta je przestępca. Dlatego pytanie „ile trwa test penetracyjny” nie ma jednej uczciwej odpowiedzi. W małej firmie badanie może zająć kilka dni roboczych, ale przy większej liczbie systemów, aplikacji, lokalizacji lub kont chmurowych cały proces często trwa od dwóch do czterech tygodni – łącznie z przygotowaniem i raportem.

Największym błędem jest ocenianie czasu wyłącznie po liczbie dni pracy testera. Dobrze przeprowadzony test obejmuje nie tylko techniczną próbę znalezienia podatności, lecz także ustalenie zasad działania, analizę wyników, weryfikację ryzyka i omówienie priorytetów naprawczych. Dla zarządu liczy się przecież nie sama lista błędów, ale odpowiedź na pytanie: co może zatrzymać firmę, ujawnić dane albo pozwolić przejąć konto pracownika?

Ile trwa test penetracyjny krok po kroku?

W praktyce czas badania warto rozpatrywać w kilku etapach. Pierwszy to ustalenie zakresu. Firma i zespół realizujący test określają, jakie systemy będą sprawdzane, czy badanie obejmuje infrastrukturę zewnętrzną, sieć wewnętrzną, aplikację webową, środowisko Microsoft 365 lub Google Workspace oraz czy testujący dysponuje kontem zwykłego użytkownika.

Ten etap trwa zwykle od kilku dni do około tygodnia, zwłaszcza gdy trzeba ustalić właścicieli systemów, okna serwisowe i osoby kontaktowe. Nie jest to formalność. Zakres zbyt wąski może pominąć istotny wektor ataku, a zbyt szeroki wydłuży badanie i utrudni koncentrację na najważniejszych ryzykach.

Drugi etap to właściwe testy techniczne. W przypadku niewielkiej infrastruktury dostępnej z internetu mogą potrwać 2-5 dni roboczych. Test sieci wewnętrznej, w którym sprawdza się między innymi możliwość przemieszczania się atakującego między komputerami i serwerami, zwykle zajmuje od kilku dni do dwóch tygodni. Aplikacje internetowe wymagają osobnego podejścia: czas zależy głównie od liczby funkcji, ról użytkowników, integracji i mechanizmów logowania.

Po zakończeniu prac technicznych następuje analiza rezultatów i przygotowanie raportu. Zazwyczaj zajmuje to od 3 do 7 dni roboczych. Tester musi odróżnić sygnały wymagające działania od problemów o ograniczonym znaczeniu, potwierdzić sposób wykorzystania podatności i opisać skutki w języku zrozumiałym dla osób biznesowych oraz IT.

Ostatnim elementem powinno być omówienie wyników. Spotkanie z osobami odpowiedzialnymi za IT i zarządzanie pozwala ustalić kolejność działań. Krytyczna podatność w systemie wystawionym do internetu wymaga innej reakcji niż błąd konfiguracyjny w środowisku odseparowanym od sieci firmowej.

Co najbardziej wpływa na czas testu?

Nie liczba pracowników jest najważniejsza, ale złożoność środowiska. Firma zatrudniająca 30 osób może korzystać z kilkunastu systemów SaaS, serwerów lokalnych, magazynu danych, zdalnego dostępu i kilku aplikacji obsługujących klientów. Taki zakres wymaga więcej pracy niż większa organizacja z prostą, dobrze uporządkowaną infrastrukturą.

Znaczenie ma również typ testu. Badanie zewnętrzne odpowiada na pytanie, co może zrobić osoba atakująca bez dostępu do sieci firmy. Badanie wewnętrzne symuluje sytuację, w której przestępca uzyskał już dostęp, na przykład przez phishing, zainfekowany komputer lub przejęte dane logowania. Często właśnie wtedy ujawniają się problemy z nadmiernymi uprawnieniami, segmentacją sieci i zabezpieczeniami kont administracyjnych.

Czas wydłużają także aplikacje stworzone na zamówienie. Trzeba sprawdzić nie tylko stronę logowania, ale też uprawnienia użytkowników, przesyłanie plików, interfejsy API, formularze, procesy płatnicze lub integracje z systemami zewnętrznymi. W przypadku systemu obsługującego księgowość, produkcję czy logistykę test powinien uwzględniać ryzyko zakłócenia pracy, dlatego jego harmonogram musi być uzgodniony szczególnie uważnie.

Inny ważny czynnik to model działania testu. W teście typu black box tester ma ograniczoną wiedzę o środowisku, co bardziej przypomina perspektywę zewnętrznego napastnika, ale wymaga czasu na rozpoznanie. W modelu white box otrzymuje dokumentację, architekturę lub dane dostępowe, dzięki czemu może dokładniej i szybciej zweryfikować wybrane obszary. Istnieje też wariant pośredni, gdy tester otrzymuje część informacji.

Kilka dni testów nie oznacza kilku dni ryzyka operacyjnego

Dobrze zaplanowany test penetracyjny nie powinien powodować przestojów. Nie oznacza to jednak, że można go realizować bez uzgodnień. Przed rozpoczęciem należy jasno ustalić zasady: systemy objęte badaniem, dozwolone techniki, godziny działania, procedurę zgłoszenia problemu oraz kontakt alarmowy po stronie firmy.

Szczególnej ostrożności wymagają systemy produkcyjne, urządzenia przemysłowe, systemy magazynowe i aplikacje, od których zależy bieżąca obsługa klientów. W takich przypadkach niektóre testy wykonuje się w ograniczonych godzinach albo zastępuje bezpieczniejszą weryfikacją konfiguracji. Celem nie jest sprawdzenie, czy system da się przeciążyć, lecz ustalenie, czy istnieje realna ścieżka nadużycia.

Warto również uprzedzić zespół odpowiedzialny za monitoring bezpieczeństwa. Aktywność testera może przypominać próbę włamania: nietypowe skanowanie, wielokrotne próby logowania lub dostęp do nieużywanych usług. Jeżeli firma korzysta z SOC as a Service, MDR lub centralnej analizy logów w SIEM, test może być wartościową okazją do sprawdzenia, czy alerty są właściwie wykrywane, analizowane i eskalowane. Trzeba przy tym zachować rozdział między zakresem testu a codziennym reagowaniem na rzeczywiste incydenty.

Jak przygotować firmę, aby nie wydłużać badania?

Najbardziej pomaga aktualna i prosta mapa środowiska. Nie musi to być rozbudowana dokumentacja architektoniczna. Wystarczą rzetelne informacje o systemach, adresach publicznych, aplikacjach, usługach chmurowych, osobach odpowiedzialnych oraz planowanych zmianach technicznych. Jeśli w trakcie testu wdrażana jest nowa zapora sieciowa lub migracja poczty, wyniki mogą szybko stracić aktualność.

Warto też określić cel biznesowy. Dla kancelarii kluczowa będzie ochrona dokumentów i kont pocztowych. Firma logistyczna może chcieć sprawdzić systemy dostępne dla kierowców, partnerów i klientów. Przedsiębiorstwo produkcyjne będzie szczególnie chronić ciągłość pracy systemów wspierających produkcję. Cel pozwala skoncentrować czas testu tam, gdzie ewentualny incydent miałby największe konsekwencje.

Nie należy ukrywać znanych problemów ani zakładać, że tester ma je wykryć od zera. Informacja o starym serwerze, nietypowej integracji czy koncie technicznym może przyspieszyć badanie i zwiększyć jego wartość. Test penetracyjny nie służy ocenie pracy administratora. Ma pomóc ograniczyć ryzyko, zanim podatność zostanie wykorzystana.

Kiedy zaplanować ponowny test?

Jednorazowy test pokazuje stan środowiska w konkretnym momencie. Po wdrożeniu poprawek warto wykonać retest najistotniejszych podatności, aby sprawdzić, czy zostały faktycznie usunięte i czy zmiana nie spowodowała nowego problemu. Taka weryfikacja jest zazwyczaj znacznie krótsza niż pełne badanie.

Pełny test warto rozważyć po większej zmianie: wdrożeniu nowej aplikacji dla klientów, migracji do chmury, uruchomieniu zdalnego dostępu, połączeniu sieci po przejęciu firmy lub istotnej zmianie sposobu uwierzytelniania. Regularność ma znaczenie także dla organizacji przygotowujących się do wymagań NIS2, ISO 27001 czy RODO, ale częstotliwość i zakres powinny wynikać z analizy konkretnego ryzyka, a nie z mechanicznego kalendarza.

Test penetracyjny nie zastępuje stałej ochrony. Wykrywa słabe punkty w określonym czasie, natomiast monitoring bezpieczeństwa IT 24/7 pomaga zauważyć podejrzane logowania, przejęcia kont, nietypową aktywność i próby wykorzystania błędów już po zakończeniu badania. Dla MŚP połączenie okresowych testów z bieżącym wykrywaniem zagrożeń jest zwykle bardziej praktyczne niż poleganie wyłącznie na jednorazowym audycie.

Najlepiej traktować harmonogram testu jako element planu ciągłości działania, a nie projekt techniczny do odhaczenia. Kilka dodatkowych dni poświęconych na właściwy zakres, analizę wyników i priorytety naprawcze może przynieść firmie znacznie większą wartość niż szybki raport, który nie odpowiada na jej rzeczywiste ryzyka.

Dyrektor ds. Technologii (CTO). Ze względów bezpieczeństwa nie publikujemy imion i nazwisk autorów – artykuły podpisywane są wyłącznie stanowiskiem, bez danych identyfikujących konkretną osobę.