Audytor nie czyta raportu z testu penetracyjnego tak jak inżynier. Szuka zakresu i sprawdza, czy odpowiada on audytowanemu środowisku, szuka metody, dat, kwalifikacji i niezależności testerów oraz dowodu, że znaleziska zostały usunięte i objęte retestem.
Zakres testu ustalamy pod kątem wymagania, które ma spełnić, a raport układamy tak, by te odpowiedzi łatwo było znaleźć. Same testy nie są przy tym okrojone: test zaprojektowany wyłącznie po to, by przejść audyt, niczego nie chroni, a audytorzy coraz częściej rozpoznają taki test, gdy go widzą.
01Zakres
Co testujemy
PCI DSS v4.0.1: zewnętrzne i wewnętrzne testy penetracyjne zgodnie z wymaganiem 11.4
PCI DSS: testy segmentacji środowiska danych posiadaczy kart
SOC 2: testy jako dowód dla kryteriów dotyczących monitorowania i podatności
ISO/IEC 27001:2022: zabezpieczenia dotyczące zarządzania podatnościami technicznymi i testów bezpieczeństwa
DORA: testowanie operacyjnej odporności cyfrowej systemów ICT
NIS2: ocena skuteczności środków zarządzania ryzykiem
RODO, art. 32: regularne testowanie środków technicznych i organizacyjnych
Kwestionariusze bezpieczeństwa klientów i partnerów, które wymagają niedawnego testu
02Podejście
Jak przebiega praca
01
Przypisanie wymagań
Ustalamy, któremu wymaganiu służy test, czego to wymaganie oczekuje co do zakresu, częstotliwości i metody oraz co spodziewa się zobaczyć Twój audytor.
02
Dopasowanie zakresu
Zakres testu dopasowujemy do granic audytowanego środowiska. Różnice dokumentujemy i uzasadniamy.
03
Testy
Test przebiega według naszej standardowej metodyki dla danego typu systemu. Niczego nie pomijamy tylko dlatego, że standard tego nie wymienia.
04
Dowody
Raport podaje metodę, daty, kwalifikacje testerów i ich niezależność. Po reteście poświadczenie podsumowuje wynik dla podmiotów trzecich bez szczegółów technicznych.
Nie. O zgodności decyduje Twój audytor na podstawie wszystkich zabezpieczeń. Test dostarcza dowodów dla wymagań dotyczących testów bezpieczeństwa i pokazuje, co naprawić przed przyjściem audytora.
Czy SOC 2, ISO/IEC 27001, NIS2 lub RODO wymagają testu penetracyjnego?
Żaden z nich nie wymienia go dosłownie jako obowiązkowego zabezpieczenia. Wymagają identyfikowania podatności i regularnego testowania skuteczności środków. Test penetracyjny to dowód, którego audytorzy najczęściej oczekują dla tych wymagań. PCI DSS i DORA mówią o tym wprost.
Jak często trzeba powtarzać test?
PCI DSS wymaga testów penetracyjnych co najmniej raz na dwanaście miesięcy i po istotnych zmianach oraz testów segmentacji co najmniej raz na dwanaście miesięcy, a w przypadku dostawców usług co sześć miesięcy. DORA wymaga testowania krytycznych systemów co najmniej raz w roku. W innych standardach częstotliwość wynika z Twojej własnej oceny ryzyka; zwykle oczekuje się testów raz w roku.