Penetration Testing as a Service
Ciągłe testy penetracyjne w modelu PTaaS
Jednorazowe testy penetracyjne opisują stan aplikacji z jednego tygodnia. Jeżeli Państwa zespół wdraża zmiany co kilka dni, raport traci aktualność szybciej, niż trafia do dokumentacji audytowej.
Ci sami pentesterzy przez cały rok. Retesty bez limitu i bez dodatkowej faktury.
Test roczny a testy ciągłe
Oba modele prowadzimy tak samo rzetelnie. Różnica dotyczy tego, jak długo wynik pozostaje aktualny.
| Pojedynczy test roczny | Ciągłe testy penetracyjne | |
|---|---|---|
| Aktualność wyniku | Opisuje stan z tygodnia, w którym prowadzono testy | Odzwierciedla bieżący stan aplikacji przez cały rok |
| Nowe funkcje | Pozostają nieprzetestowane do kolejnego cyklu | Trafiają do zakresu w najbliższej iteracji testów |
| Znajomość systemu | Budowana od nowa przy każdym projekcie | Ten sam zespół zna architekturę i historię znalezisk |
| Zgłaszanie podatności | Zbiorczo w raporcie końcowym | Na bieżąco, w miarę potwierdzania znalezisk |
| Dowód dla audytora | Jeden raport z datą, szybko się dezaktualizuje | Ciągła dokumentacja testów i retestów w całym okresie |
| Rozliczenie | Jednorazowa wycena projektu | Model abonamentowy z ustalonym rocznym zakresem |
Zakres usługi
Co obejmuje model ciągły
Zakres roczny ustalamy na starcie i korygujemy razem z rozwojem Państwa systemów, bez renegocjowania umowy przy każdej zmianie.
Powtarzalne cykle testowe
Zakres dzielimy na iteracje. W każdej z nich testujemy część systemu według ustalonego priorytetu, dzięki czemu w skali roku pokrycie jest pełne, a nie punktowe.
Testy po istotnych zmianach
Nowy moduł, zmiana modelu uprawnień, migracja do innego dostawcy chmury lub uruchomienie kanału płatności trafiają do zakresu bez konieczności zamawiania osobnego projektu.
Zespół, który zna Państwa system
Nad projektem pracują ci sami pentesterzy. Nie tracą Państwo czasu na wprowadzanie nowych osób w architekturę, a testy z każdą iteracją sięgają głębiej.
Bieżące zgłaszanie znalezisk
Potwierdzone podatności przekazujemy od razu, wraz z krokami odtworzenia i rekomendacją naprawczą. Deweloperzy nie czekają na zamknięcie iteracji.
Retesty w trybie ciągłym
Weryfikacja poprawek jest częścią usługi. Status każdego znaleziska pozostaje aktualny, co eliminuje spory o to, czy podatność została faktycznie usunięta.
Dokumentacja gotowa na audyt
W dowolnym momencie mogą Państwo pobrać aktualny raport wraz z historią testów i retestów — bez czekania na zakończenie kolejnego rocznego cyklu.
Przebieg
Jak działa współpraca w modelu ciągłym
Pierwsza iteracja jest najgłębsza, kolejne koncentrują się na zmianach i obszarach o najwyższym ryzyku.
- 01
Ustalenie zakresu rocznego
Definiujemy zasoby objęte usługą, priorytety oraz rytm iteracji dopasowany do Państwa cyklu wydawniczego.
- 02
Test bazowy
Pierwsza iteracja obejmuje pełny zakres i tworzy punkt odniesienia, wobec którego mierzymy postęp w kolejnych miesiącach.
- 03
Iteracje przyrostowe
Każdy kolejny cykl obejmuje nowe funkcje, obszary o podwyższonym ryzyku oraz weryfikację, czy wcześniejsze poprawki nie uległy regresji.
- 04
Bieżąca komunikacja
Znaleziska przekazujemy natychmiast po potwierdzeniu, uzgodnionym kanałem — bezpośrednio zespołowi odpowiedzialnemu za dany moduł.
- 05
Retesty bez limitu
Każdą poprawkę weryfikujemy bezpłatnie i aktualizujemy status znaleziska wraz z datą ponownego testu.
- 06
Przegląd okresowy
Cyklicznie podsumowujemy trend: jakie klasy błędów się powtarzają i gdzie warto wzmocnić proces wytwarzania, żeby przestały wracać.
Zgodność
Model ciągły a wymogi regulacyjne
Przepisy coraz rzadziej mówią o pojedynczym teście, a coraz częściej o ciągłym zarządzaniu ryzykiem.
KSC i NIS2 — ciągłe zarządzanie ryzykiem
Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa wdrażająca NIS2 wymaga utrzymywania i przeglądu środków zarządzania ryzykiem, a nie jednorazowego zdarzenia. Ciągła dokumentacja testów i retestów wprost odpowiada na oczekiwania dotyczące systematyczności.
RODO — regularne testowanie skuteczności
Artykuł 32 ustęp 1 litera d mówi o regularnym testowaniu, mierzeniu i ocenianiu skuteczności zabezpieczeń. Model ciągły daje dowód rozłożony w czasie, co przy kontroli UODO jest wyraźnie mocniejszym argumentem niż jeden raport sprzed dziesięciu miesięcy.
ISO 27001 — zabezpieczenie A.8.8
Zarządzanie podatnościami technicznymi jest procesem ciągłym, a audytorzy pytają o dowody z całego okresu nadzoru. Historia iteracji i retestów pokrywa ten wymóg bez konieczności dodatkowego raportowania po Państwa stronie.
PCI DSS — testy po istotnych zmianach
Standard wymaga testów penetracyjnych nie tylko corocznie, ale też po każdej znaczącej zmianie w środowisku przetwarzania danych kartowych. W modelu ciągłym taka zmiana trafia do najbliższej iteracji i nie wymaga osobnego postępowania zakupowego.
Najczęstsze pytania
Ciągłe testy penetracyjne — pytania klientów
Powiązane usługi
Niech raport nadąża za tempem Państwa wdrożeń
Prosimy o kontakt, aby omówić zakres roczny i rytm iteracji. Konsultacja wstępna jest bezpłatna i nie zobowiązuje do zamówienia usługi.
Prosimy o kontakt