Zakres zlecenia pentestowego: przewodnik dla profesjonalistów

Zakres zlecenia to jeden z najczęściej niedocenianych elementów całego procesu testów penetracyjnych. Większość pentesterów wie, czym są testy penetracyjne w ogólnym sensie, ale traktuje scope jako prostą listę adresów IP do przeskanowania. To błąd, który kosztuje projekty czas, pieniądze i wiarygodność. Zakres zlecenia to formalny zapis granic testu, który definiuje aktywa, techniki oraz czas trwania testu. Bez precyzyjnego zakresu nawet najlepszy pentester działa w próżni, a klient otrzymuje raport, który nie odpowiada jego rzeczywistym potrzebom.

Spis treści

• Elementy składowe zakresu engagementu w pentestingu

• Jak model black/grey/white box wpływa na zakres i przebieg testów penetracyjnych

• Rola precyzyjnego określenia zakresu w bezpieczeństwie prawnym i jakości wyników testu

• Praktyczne wytyczne i przykłady ustalania zakresu w pentestach aplikacji webowych i API

• Koszty i zasoby w zależności od zakresu engagementu pentestowego

• Dlaczego precyzyjne definiowanie zakresu to największe wyzwanie i klucz do sukcesu pentestu

• Narzędzia i sprzęt pentesterski wspierający realizację zakresu engagementu

• Najczęściej zadawane pytania

Kluczowe Wnioski

Elementy składowe zakresu zlecenia w pentestingu

Przechodząc od ogólnego wprowadzenia, omówmy szczegółowo kluczowe składniki zakresu zlecenia. Zakres zlecenia pentestowego nie jest jednorodny. Składa się z trzech odrębnych wymiarów, z których każdy definiuje inne granice testu i wymaga osobnego uzgodnienia z klientem.

Zakres zlecenia rozbija się na scope targetów, scope technik oraz scope czasowy. To trójpodział, który warto stosować jako szablon podczas każdego spotkania otwierającego z klientem. Z naszego doświadczenia jako dostawcy sprzętu pentesterskiego wiemy, że klienci najczęściej wracają po dodatkowe narzędzia właśnie wtedy, gdy zakres zlecenia zmienia się w trakcie projektu - precyzyjne określenie scope’u na starcie oszczędza czas i budżet.

Zakres targetów określa, które systemy, sieci i aplikacje podlegają testom. Obejmuje:

• Konkretne adresy IP, zakresy CIDR lub nazwy domen

• Aplikacje webowe wskazane przez URL lub środowisko (produkcja, staging)

• Wyłączenia, czyli systemy, których tester nie może dotknąć, np. systemy produkcyjne podmiotów trzecich

• Urządzenia sieciowe: routery, firewalle, przełączniki

• Infrastrukturę chmurową z określeniem kont i regionów

Zakres technik definiuje, jakie metody ataku są dozwolone. To jeden z obszarów, gdzie najczęściej dochodzi do nieporozumień. Klient może oczekiwać pełnego testu, ale zakazać eksploatacji luk, bo boi się przestoju systemu. Zakres technik obejmuje decyzje dotyczące:

• Eksploatacji podatności (z payload’em lub bez)

• Ataków odmowy usługi (DoS), które zwykle są zakazane w środowiskach produkcyjnych

• Socjotechniki, phishingu i pretextingu

• Ataków fizycznych na infrastrukturę

• Metod eskalacji uprawnień i lateral movement

Zakres czasowy to okno, w którym testy mogą się odbywać. Definiuje godziny i dni dopuszczalnych działań testowych. Zawiera też blackouty, czyli okresy zakazu testów, np. w trakcie zamknięcia ksiąg rachunkowych lub aktualizacji systemów. Pominięcie tego elementu prowadzi do sytuacji, gdzie tester uruchamia skaner w piątek o 23:00, a monitoring klienta zgłasza alarm, którego nikt nie spodziewa się obsłużyć.

Warto zapoznać się z metodologiami testów penetracyjnych, które precyzują, jak te trzy wymiary są formalizowane w różnych frameworkach branżowych.

Jak model black/grey/white box wpływa na zakres i przebieg testów penetracyjnych

Znając elementy zakresu, przeanalizujmy jak różne modele testowania wpływają na definiowanie i realizację zakresu. Wybór modelu nie jest tylko kwestią metodologiczną. Bezpośrednio determinuje, co można sprawdzić, jak głęboko i jakim kosztem.

Model black/grey/white box determinuje poziom wiedzy i dostęp testera, co z kolei wpływa na to, jak szczegółowo należy sformułować zakres zlecenia w dokumentacji.

Kilka praktycznych obserwacji dotyczących każdego modelu:

• Black box wymaga rozbudowanego zakresu targetów, bo tester musi sam mapować infrastrukturę. Zakres technik jest tu zazwyczaj szerszy, ale ograniczony do działań zewnętrznych.

• Grey box to najczęściej wybierany model w komercyjnych usługach testów bezpieczeństwa. Zakres uwzględnia dostarczone przez klienta dane uwierzytelniające i ewentualne diagramy sieci.

• White box przenosi ciężar zakresu na dokumentację techniczną. Tester potrzebuje dostępu do repozytorium kodu, diagramów architektury i konfiguracji systemów. Scope musi precyzować, które repozytoria i środowiska są objęte testem.

Szczegółowe omówienie sprzętu wspierającego realizację różnych modeli black/grey/white box znajdziesz w dedykowanym artykule.

Rola precyzyjnego określenia zakresu w bezpieczeństwie prawnym i jakości wyników testu

Po omówieniu modeli testów skoncentrujmy się na konsekwencjach prawnych i jakościowych wynikających z zakresu. To obszar, który wielu pentesterów traktuje jako formalność. Nie jest nią.

Brak pisemnej zgody i precyzji naraża na odpowiedzialność prawną zarówno firmę testującą, jak i samego testera. W Polsce testy bez autoryzacji mogą być kwalifikowane jako naruszenie ustawy o cyberbezpieczeństwie lub Kodeksu karnego w zakresie nieuprawnionego dostępu do systemów informatycznych.

Dwa kluczowe dokumenty formalizujące zakres to SOW (Statement of Work) i ROE (Rules of Engagement). Różnica między nimi jest fundamentalna i często pomijana:

• SOW definiuje co jest testowane. Zawiera listę systemów, aplikacji, środowisk i wyłączeń.

• ROE określa jak test ma przebiegać. Reguluje dozwolone techniki, godziny testów, zasady eskalacji i warunki zatrzymania.

Rozdzielenie tych dokumentów ma praktyczne znaczenie. SOW podpisuje prawnik lub kierownik projektu po stronie klienta. ROE podpisuje osoba technicznie odpowiedzialna, np. CTO lub security manager. Podpis pod niewłaściwym dokumentem przez niewłaściwą osobę nie daje wymaganej autoryzacji.

Porada profesjonalisty: Zawsze weryfikuj, czy osoba podpisująca ROE ma faktyczne uprawnienia do udzielania zgody na testy. Podpis pracownika IT bez odpowiednich pełnomocnictw nie chroni cię prawnie w przypadku incydentu.

Kroki do prawidłowego ustalenia zakresu:

1. Zdefiniuj systemy objęte testem i sporządź listę wyłączeń

2. Ustal dozwolone metody i techniki, odnotuj zakazy

3. Określ okno czasowe i zaplanuj blackouty

4. Zdefiniuj warunki zatrzymania testu i procedury eskalacji

5. Zatwierdź dokumentację podpisami uprawnionych osób po obu stronach

Kompletną analizę wymogów formalnych znajdziesz w artykule dotyczącym metodologii i zasad prowadzenia testów penetracyjnych.

Praktyczne wytyczne i przykłady ustalania zakresu w pentestach aplikacji webowych i API

Mając na uwadze ogólne zasady i ryzyka, przejdźmy do praktycznych aspektów definiowania zakresu w testach aplikacji webowych. Ten rodzaj testów ma swoją specyfikę, która wymaga bardzo precyzyjnego podejścia do scopingu.

Zakres testu aplikacji web/API określa się na poziomie adresów URL, endpointów oraz ról dostępu. Konieczne jest precyzyjne określenie zasięgu testów uwierzytelnienia.

W praktyce zakres testu aplikacji webowej powinien zawierać:

• Listę URL i endpointów API: nie wystarczy podać domeny. Należy określić, czy testowane są wszystkie subdomeny, konkretne ścieżki, wersjonowane API (v1, v2) i środowiska (produkcja vs staging).

• Role dostępu do uwzględnienia: anonimowy użytkownik, zarejestrowany użytkownik, moderator, administrator. Każda rola otwiera inny zestaw funkcjonalności i potencjalnych podatności.

• Zakres danych testowych: jakie konta testowe dostarcza klient, jakie dane można tworzyć i modyfikować podczas testu.

• Ograniczenia środowiskowe: czy testy mogą dotykać bazy danych produkcyjnych, czy tester pracuje wyłącznie na środowisku stagingowym.

• Specyficzne zagrożenia do zbadania: klient może priorytetyzować OWASP Top 10, logikę biznesową lub autoryzację między kontami.

Niedoprecyzowanie ról dostępu to jeden z najczęstszych błędów. Tester testuje wyłącznie jako użytkownik anonimowy, podczas gdy najpoważniejsze podatności leżą w panelu administratora. Raport końcowy nie pokrywa obszarów, na których klientowi zależy najbardziej, i zlecenie jest uznawane za nieudane. W rozmowach z pentesterami kupującymi u nas sprzęt ten scenariusz powtarza się regularnie - klient oczekiwał testu ‘panelu’ admina, ale nikt tego nie zapisał w scope.

Porada profesjonalisty: Uwzględnij w scope wszystkie kluczowe ścieżki uwierzytelniania i autoryzacji, w tym procesy resetowania hasła, OAuth, SSO i API keys. To właśnie te ścieżki są najczęściej pomijanym wektorem ataku.

Więcej technicznych aspektów scopingu testów web znajdziesz w przewodniku po zakresie pentestu aplikacji webowych i API.

Koszty i zasoby w zależności od zakresu zlecenia pentestowego

Na koniec przyjrzyjmy się pragmatycznym aspektom realizacji testów. Zakres bezpośrednio przekłada się na budżet i harmonogram projektu, a zrozumienie tej zależności pozwala uniknąć nieporozumień podczas wyceny.

Im większy i bardziej złożony zakres, tym wyższy koszt i dłuższy czas realizacji testu. To wydaje się oczywiste, ale szczegóły są mniej intuicyjne niż myślisz.

Kilka czynników, które mniej oczywiście wpływają na zasoby i koszty:

• Wyłączenia z zakresu: paradoksalnie, wiele wyłączeń może przedłużać test, bo tester musi stale weryfikować, które systemy może atakować, a których nie.

• Dostępność środowisk: testy na stagingu zamiast produkcji wymagają dodatkowej konfiguracji i często osobnych danych testowych.

• Raportowanie: szczegółowy raport z re-testami i sesjami debrief może dodać 20 do 30 procent do łącznego czasu realizacji zlecenia.

• Dostęp do specjalistycznych narzędzi: niektóre wektory testowe wymagają dedykowanego sprzętu, co wpływa na koszty po stronie firmy testującej.

Więcej o planowaniu czasu i zasobów pentestu znajdziesz w naszych materiałach dla specjalistów.

Dlaczego precyzyjne definiowanie zakresu to największe wyzwanie i klucz do sukcesu pentestu

Po omówieniu wszystkich praktycznych aspektów, czas na spojrzenie eksperckie. Zakres zlecenia jest tematem, w którym rynek popełnia te same błędy od lat, i nikt o tym głośno nie mówi.

Najczęstsza przyczyna rozminięcia się testu z oczekiwaniami klienta to błędny scoping i źle zdefiniowany ROE. Ale problem zwykle nie leży w technicznej niedbałości, leży w procesie komunikacji.

Klienci opisują zakres w języku biznesowym. Mówią “przetestuj nasze systemy” lub “sprawdź, czy jesteśmy bezpieczni”. Pentesterzy muszą to przetłumaczyć na listę hostów, endpointów i dozwolonych technik. Ta translacja jest miejscem, gdzie najczęściej gubi się informacja. Obserwujemy to w branży od lat - pentesterzy zamawiający u nas sprzęt do testów fizycznych często dopiero po rozpoczęciu zlecenia dowiadują się, że klient nie uwzględnił w scope fizycznego dostępu do serwerowni, mimo że oczekiwał “pełnego testu bezpieczeństwa”.

Drugie często pomijane zagadnienie to warunki zatrzymania testu (stop conditions). ROE powinno precyzować, co tester robi, gdy odkryje podatność krytyczną, np. zdalną eksploatację bez uwierzytelnienia na systemie produkcyjnym. Czy kontynuuje, czy natychmiast raportuje klientowi i czeka na decyzję? Brak tych zasad prowadzi do sytuacji, gdzie tester albo zatrzymuje się zbyt wcześnie, albo eksploatuje podatność w sposób, który klient uznaje za przekroczenie granic.

Kolejny błąd to brak interesariuszy biznesowych w procesie definiowania zakresu. Technicy zazwyczaj skupiają się na infrastrukturze. Tymczasem to menedżer ryzyka lub dyrektor operacyjny wie, które procesy biznesowe są krytyczne i wymagają priorytetyzacji. Zakres zdefiniowany wyłącznie przez IT może pominąć aplikację obsługującą 80 procent przychodów firmy, bo “to stary system i wszyscy go znają”.

Porada profesjonalisty: Włączaj interesariuszy biznesowych do sesji scopingowej. Jedno spotkanie z osobą odpowiedzialną za procesy biznesowe może ujawnić zasoby, o których dział IT nie wspomniał, bo nie uznał ich za “IT”.

Skuteczna standaryzacja scopu i ROE wymaga szablonów, procesów i dyscypliny organizacyjnej. Firmy, które traktują scoping jako jednorazową rozmowę telefoniczną, regularnie dostarczają testy, które klient ocenia jako nieprzydatne.

Narzędzia i sprzęt pentesterski wspierający realizację zakresu zlecenia

Znając wyzwania i dobre praktyki, warto poznać narzędzia, które wspierają pentesterów w realizacji precyzyjnego zakresu zlecenia. Odpowiedni sprzęt pozwala działać szybciej, dokładniej i w pełnej zgodności z ustalonym scope.

W ofercie Sapsan znajdziesz sprzęt dedykowany do konkretnych wektorów testowych objętych zakresem zlecenia. Bash Bunny Hak5 to wszechstronne urządzenie do automatyzacji ataków HID i testów sieciowych, szczególnie przydatne w zleceniach obejmujących dostęp fizyczny lub punkty końcowe. Packet Squirrel Mark II sprawdza się w testach wewnętrznych i pivotingu w sieci klienta, gdzie zakres obejmuje infrastrukturę LAN. Dla zleceń skupionych na aplikacjach webowych i API dostępne są narzędzia do pentestu aplikacji webowych, które pokrywają pełen zakres testów zgodnych z OWASP. Sapsan realizuje wysyłkę na terenie całej UE i USA, zapewniając szybki dostęp do sprzętu bez względu na lokalizację projektu.

Najczęściej zadawane pytania

Co to jest zakres zlecenia pentestowego?

Zakres zlecenia to formalny zapis granic testu, dozwolone techniki i czas realizacji. Definiuje on, które systemy podlegają testom, jakie metody ataku są dozwolone i w jakim oknie czasowym testy mogą się odbywać.

Dlaczego precyzyjne ustalenie zakresu jest tak ważne?

Nieprecyzyjny zakres prowadzi do rozminięcia się oczekiwań i ryzyka prawnego. Dokładne określenie granic testu zapobiega incydentom prawnym i gwarantuje, że raport końcowy odpowiada faktycznym potrzebom klienta.

Jakie modele testowania wpływają na zakres pentestu?

Modele black/grey/white box definiują poziom dostępu testera i wpływają na zakres testów. Black box symuluje atakującego bez wiedzy o infrastrukturze, grey box zakłada częściowy dostęp, a white box daje pełny wgląd w architekturę i kod.

Co powinno zawierać określenie zakresu testów aplikacji webowych?

Zakres testu web/API określa się na poziomie endpointów i ról dostępu. Precyzyjny scope obejmuje konkretne adresy URL, wersje API, środowiska testowe oraz wszystkie role użytkowników, od anonimowego po administratora.

Jak wielkość zakresu wpływa na koszt i czas testów penetracyjnych?

Zakres przekłada się na czas i koszt: testy zewnętrzne trwają zazwyczaj od 3 do 7 dni, a rozbudowane zlecenia red team mogą zająć kilka tygodni. Im więcej systemów, ról i technik obejmuje scope, tym większe zapotrzebowanie na zasoby i budżet.