PCI DSS v4.0 wprowadza wzmocnione wymagania dotyczące testów penetracyjnych. Dla organizacji z rozległym CDE, koszty rocznych pen testów mogą być znaczące. Zrozumienie dokładnych wymagań i strategii ograniczenia zakresu jest kluczowe dla efektywnego zarządzania budżetem bezpieczeństwa. Tokenizacja pozostaje najskuteczniejszą metodą redukcji zakresu i kosztów.
Rodzaje testów penetracyjnych wymaganych przez PCI DSS v4.0
PCI DSS v4.0 wymaga następujących rodzajów testów penetracyjnych: testy zewnętrzne (external pen test) – z perspektywy atakującego zewnętrznego próbującego dostać się do CDE przez internet, testy wewnętrzne (internal pen test) – z perspektywy atakującego wewnątrz sieci organizacji, testy segmentacji – weryfikacja, że segmentacja sieciowa skutecznie izoluje CDE, testy aplikacji webowych – weryfikacja podatności aplikacji przyjmujących dane kart. Każdy typ testu ma własne wymagania metodologiczne.
Metodologia testów penetracyjnych PCI DSS v4.0
PCI DSS v4.0 Wymaganie 11.4.1 wymaga przyjęcia i stosowania udokumentowanej metodologii pen testów. Metodologia musi obejmować: rekonesans i zbieranie informacji (OSINT, skanowanie portów), identyfikację podatności (scanowanie automatyczne i manualne), eksploitację podatności z symulacją ataku zaawansowanego, weryfikację poprawności naprawionych podatności (re-test), raportowanie z kategoryzacją ryzyka. Popularne metodologie: OWASP Testing Guide, PTES (Penetration Testing Execution Standard), NIST SP 800-115.
Testy aplikacji webowych: OWASP Top 10 jako minimum
PCI DSS v4.0 wyraźnie wymienia OWASP Top 10 jako minimalne wymagania dla testów aplikacji webowych przetwarzających dane kart. OWASP Top 10 (2021) obejmuje: Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable and Outdated Components, Identification and Authentication Failures, Software and Data Integrity Failures, Security Logging and Monitoring Failures, Server-Side Request Forgery. Tester musi zweryfikować, że aplikacja jest odporna na każdą z tych kategorii ataków.
Dokumentacja i raportowanie testów penetracyjnych
Dokumentacja testów penetracyjnych musi zawierać: zakres testu (systemy, aplikacje, metody), metodologię stosowaną przez testera, wyniki: znalezione podatności z oceną ryzyka (CVSSv3), dowody eksploitacji (screenshots, logi), zalecenia naprawcze dla każdej podatności, status naprawy i wyniki re-testu, podpis testera i daty przeprowadzenia testu. Dokumentacja ta jest weryfikowana przez QSA podczas audytu Level 1 i może być żądana przez agenta rozliczeniowego.
Integracja testów penetracyjnych z cyklem SDLC
PCI DSS v4.0 kładzie nacisk na integrację bezpieczeństwa z cyklem życia oprogramowania. Wymaganie 6.2 wymaga uwzględniania bezpieczeństwa na każdym etapie SDLC. W praktyce oznacza to: code review pod kątem bezpieczeństwa (SAST – Static Application Security Testing), testy bezpieczeństwa aplikacji podczas QA (DAST – Dynamic Application Security Testing), testy penetracyjne przed każdym znaczącym release'em, formalne szkolenia dla deweloperów. Organizacje z dojrzałym DevSecOps zazwyczaj mają mniejszy zakres podatności w corocznych testach PCI DSS.
Wyeliminuj swoje systemy z zakresu pen testów PCI DSS
Sprzedawcy korzystający z tokenizacji PCI Proxy EU z SAQ A nie wymagają corocznych testów penetracyjnych.
Porozmawiaj z ekspertem