Zakres testu penetracyjnego
Elementrica
Dokument przykładowy, zanonimizowany. Fragment Statement of Work i Rules of Engagement.
O tym dokumencie. To fragment realnego dokumentu, oczyszczony z danych klienta i danych wrażliwych. Wszystkie nazwy, domeny i adresy IP są fikcyjne (domeny w strefie .example, adresacja zanonimizowana). Pokazujemy go po to, żeby było widać, jak wyznaczamy granicę testu i co świadomie umieszczamy w sekcji „poza zakresem". Warstwa handlowa (dokładna pracochłonność, wycena, harmonogram dzienny) ustalana jest indywidualnie.
1. Kontekst zlecenia
Profil klienta i cel testu wpływają na to, gdzie postawimy granicę. Dlatego zaczynamy od kontekstu, a nie od listy narzędzi.
2. Cele testu
Cele zapisujemy w języku ryzyka klienta, nie w języku techniki. To one decydują, co jest ważne, a co poboczne.
- Ustalić, czy z poziomu internetu da się uzyskać nieuprawniony dostęp do danych użytkowników platformy.
- Zweryfikować izolację danych między najemcami (broken access control, IDOR, błędy autoryzacji poziomej i pionowej).
- Sprawdzić odporność procesu logowania, resetu hasła i zarządzania sesją.
- Dostarczyć dowody i priorytety pod plan naprawczy oraz materiał do rozmowy z audytorem DORA.
3. Zakres testu (in scope)
Każdy zasób jest wskazany z nazwy. Nie ma pozycji typu „cała reszta" ani „pozostała infrastruktura". Jeśli czegoś nie ma na tej liście, nie jest testowane.
4. Typ testu i perspektywa
5. Metodyka i standardy
Metodyka jest po to, żeby wynik był powtarzalny i sprawdzalny, a nie zależny od tego, na co danego dnia miał ochotę konkretny tester.
- PTES jako proces prowadzenia testu.
- OWASP WSTG 4.x dla aplikacji webowej i portalu partnerskiego.
- OWASP API Security Top 10 dla API.
- OWASP MASTG dla aplikacji mobilnej.
- NIST SP 800-115 dla infrastruktury zewnętrznej.
- Klasyfikacja i priorytety ryzyka wg CVSS 4.0.
6. Reguły gry (Rules of Engagement)
7. Poza zakresem (out of scope)
To najważniejsza część tego dokumentu. Nie jest listą rzeczy, których nie umiemy zrobić. To lista świadomych decyzji, każda z powodem.
Co robimy, gdy znajdziemy coś poza granicą. Jeśli w trakcie rekonesansu natrafimy na istotny asset spoza zakresu (na przykład zapomnianą subdomenę z panelem administracyjnym), nie testujemy go bez rozszerzenia zlecenia. Zgłaszamy go osobno jako obserwację, z opisem ryzyka. Granica chroni obie strony, ale nie udajemy, że problem nie istnieje, tylko dlatego, że leży kilka metrów za linią.
8. Pracochłonność i produkty końcowe
Liczba osobodni to realny sufit głębokości testu. Podajemy ją wprost, bo zakres bez przypisanego czasu to intencja, nie plan. Poniższe wartości są przykładowe.
Co klient dostaje na końcu:
- Raport techniczny z dowodami: kroki reprodukcji, dowód działania, priorytety wg CVSS 4.0 i konkretna ścieżka naprawy dla każdej podatności.
- Podsumowanie dla kadry zarządzającej w języku ryzyka biznesowego, gotowe do rozmowy z zarządem i audytorem.
- Sesja omówienia wyników z zespołem klienta.
- Retest poprawek i pisemne potwierdzenie usunięcia podatności.
9. Założenia i warunki
- Klient zapewnia konta testowe, dostęp do środowisk i buildy mobilne przed startem prac.
- Klient oświadcza, że posiada prawo do zlecenia testu wskazanych assetów.
- Każda zmiana zakresu w trakcie wymaga pisemnego uzgodnienia (change request).
- Całość objęta NDA. Po zakończeniu dane testowe są usuwane zgodnie z uzgodnioną polityką retencji.
Umów bezpłatną, 30-minutową konsultację bez zobowiązań. Po rozmowie z konsultantem będziesz mieć pierwszy szkic sensownego zakresu.