PCI-DSS Pentest Italia: Requisito 11.3 e Test di Penetrazione del Cardholder Data Environment
Lo standard PCI DSS (Payment Card Industry Data Security Standard), giunto alla versione 4.0 (marzo 2022) e alla versione 4.0.1 (giugno 2024) con applicazione obbligatoria dal 31 marzo 2025, è il riferimento mondiale per la sicurezza dei dati delle carte di pagamento. Il Requisito 11.3 impone test di penetrazione annuali del Cardholder Data Environment (CDE) e delle sue interfacce con le reti esterne, oltre a test dopo ogni modifica significativa all'infrastruttura. In Italia, il circuito Bancomat/PagoBancomat, i processori di pagamento e tutti i soggetti che gestiscono dati delle carte di pagamento devono conformarsi a PCI DSS — la supervisione è esercitata dai brand delle carte (Visa, Mastercard, American Express) tramite l'obbligo di validazione annuale. La presente guida analizza i requisiti PCI DSS v4.0 per i test di penetrazione, la struttura del CDE, le differenze tra livelli di merchant e come ottenere un report conforme QSA.
PCI DSS v4.0 Requisito 11.3: obbligo di penetration testing annuale
PCI DSS v4.0 ha reso i requisiti di penetration testing più stringenti rispetto alla versione 3.2.1. Il Requisito 11.3 è articolato in due sotto-requisiti principali: 11.3.1 (pentest esterno) e 11.3.2 (pentest interno). Entrambi richiedono: copertura di tutti i componenti del CDE (sistemi che memorizzano, elaborano o trasmettono dati del titolare della carta); metodologia di test definita e documentata; test condotto da personale qualificato indipendente (internal o external tester con certificazione OSCP, CREST, o equivalente); test effettuato almeno annualmente e dopo ogni modifica significativa; report con evidenza di sfruttamento, severità e stato di remediation. La novità rilevante di PCI DSS v4.0 è l'aggiunta del Requisito 11.3.3 (pentest per la segmentazione): quando si utilizza la segmentazione di rete per ridurre il perimetro PCI DSS, la segmentazione deve essere verificata con un test di penetrazione almeno ogni sei mesi. La violazione della segmentazione è una delle modalità di compromissione più comuni nei breach legati alle carte di pagamento. In Italia, i principali brand delle carte (Visa, Mastercard) richiedono la validazione annuale PCI DSS tramite QSA (Qualified Security Assessor) per i Merchant Level 1-2 e tramite SAQ (Self-Assessment Questionnaire) per i livelli inferiori — ma in tutti i casi, il report di penetration testing è un elemento richiesto.
- PCI DSS v4.0 Requisito 11.3.1 (pentest esterno): test di penetrazione del perimetro esterno del CDE — tutti i componenti raggiungibili da reti esterne; condotto almeno annualmente e dopo ogni modifica significativa; include sfruttamento reale delle vulnerabilità, non solo identificazione.
- PCI DSS v4.0 Requisito 11.3.2 (pentest interno): test di penetrazione dall'interno del CDE — verifica dei controlli di accesso interni, segmentazione tra sistemi CDE e non-CDE, escalation dei privilegi; metodologia deve coprire i Requisiti 6 (sicurezza applicazioni) e 8 (controllo accessi).
- PCI DSS v4.0 Requisito 11.3.3 (pentest segmentazione): se si utilizza la segmentazione per ridurre il perimetro PCI DSS, la segmentazione deve essere testata almeno ogni 6 mesi e dopo ogni modifica ai controlli di segmentazione — specifico per ambienti che usano la segmentazione come riduzione di scope.
- PCI DSS v4.0 Requisito 11.3.2.1 (per service provider): i service provider PCI DSS devono effettuare test di penetrazione sui controlli di segmentazione almeno ogni 6 mesi (in aggiunta al pentest annuale) — requisito più stringente rispetto ai merchant.
- PCI DSS v4.0 Requisito 6.4.1 (pentest applicazioni web): le applicazioni web esposte a Internet nel CDE devono essere testate contro le vulnerabilità OWASP Top 10; come alternativa al pentest manual, è accettabile una WAF (Web Application Firewall) configurata correttamente.
- Qualificazione del tester (PCI DSS v4.0 Req. 11.3.1 e 11.3.2): il pentest deve essere condotto da «personale qualificato indipendente» — PCI SSC non prescrive certificazioni specifiche, ma OSCP (Offensive Security Certified Professional), CREST CPSA/CRT, CEH sono ampiamente accettati dai QSA.
- Circuito Bancomat/PagoBancomat e PCI DSS in Italia: i partecipanti al circuito Bancomat SpA (banche, istituti di pagamento, esercenti) che gestiscono dati PAN sono soggetti a PCI DSS; Bancomat SpA impone requisiti di conformità PCI DSS ai propri partecipanti tramite le regole di circuito.
Cosa deve coprire un pentest PCI DSS v4.0 conforme
- Perimetro esterno del CDE (Req. 11.3.1): tutti i componenti CDE raggiungibili da Internet — web application, API di pagamento, componenti di e-commerce, gateway di pagamento; identificazione e sfruttamento delle vulnerabilità con evidenza.
- Autenticazione e controllo accessi nel CDE (Req. 8): implementazione MFA per tutti gli accessi non console al CDE; politiche di password; account condivisi (non consentiti da PCI DSS); sessioni inattive; CVE-2023-32409 (Apple WebKit RCE) come esempio di vulnerabilità nei sistemi di pagamento mobile.
- Sicurezza delle applicazioni web di pagamento (Req. 6.4.1): OWASP Top 10 (2021) con focus su A01 Broken Access Control, A02 Cryptographic Failures (TLS 1.0/1.1 ancora in uso), A03 Injection — verifica della protezione dei numeri PAN in transito.
- Segmentazione di rete CDE (Req. 11.3.3): verifica che i sistemi non-CDE non possano accedere ai sistemi CDE — test di attraversamento della segmentazione, verifica delle regole firewall, CVE-2024-21762 (Fortinet FortiOS SSL-VPN RCE) come vettore potenziale.
- Cifratura dei dati del titolare della carta (Req. 3 e 4): verifica che i PAN siano cifrati ovunque (a riposo e in transito); TLS 1.3 sui canali di trasmissione; nessuna memorizzazione non autorizzata dei dati di autenticazione sensibili (CVV2, PIN).
- Gestione delle patch (Req. 6.3.3): tutti i componenti del CDE devono avere le patch critiche entro un mese — verifica della presenza di CVE critici senza patch; CVE-2023-34362 (MOVEit Transfer SQL injection) come esempio di CVE critico che ha portato a breach di dati pagamento.
- Logging e monitoraggio (Req. 10): verifica che tutte le attività nel CDE vengano registrate; log degli accessi a tutti i PAN; integrità dei log (nessuna modifica o cancellazione non autorizzata); conservazione dei log per almeno 12 mesi.
- Sicurezza fisica e logica dei terminali POS (Req. 9): per i merchant con terminali fisici — verifica dell'assenza di skimmer fisici, protezione contro la manomissione, inventario aggiornato dei terminali POS.
Esempio di finding
SQL Injection nel modulo di ricerca ordini dell'applicazione e-commerce — accesso ai PAN cifrati (CVE-OWASP A03:2021)
Il modulo di ricerca ordini dell'applicazione e-commerce contiene una vulnerabilità di SQL injection (error-based) nel parametro «order_id». L'input utente non viene sanitizzato prima dell'inserimento nella query SQL: il test ha confermato l'injection in modalità di rilevamento, senza leggere dati dal database. Richiesta e risposta sono allegate come prova. Un attaccante potrebbe sfruttare la vulnerabilità per leggere la tabella «transactions», che contiene i PAN cifrati e gli identificatori delle chiavi, e poi attaccare il sistema di gestione delle chiavi per ottenere le chiavi di cifratura. La vulnerabilità è sfruttabile da un utente non autenticato. PCI DSS Requisito 6.3.2 richiede l'identificazione e la protezione di tutte le vulnerabilità di sicurezza nei componenti del CDE prima del deployment.
Correzione: Implementare immediatamente query parametrizzate (prepared statements) per tutti i punti di accesso al database nell'applicazione e-commerce — nessun input utente deve essere concatenato direttamente nelle query SQL. Implementare un WAF (Web Application Firewall) davanti all'applicazione con regole di rilevamento SQL injection come misura di difesa in profondità. Effettuare code review completo di tutti i moduli che accedono al database. Verificare i log di accesso al database per evidenze di sfruttamento precedente al test. Documentare la remediation nel report QSA PCI DSS come richiesto dal Requisito 11.3.1 e presentare prova di ri-test dopo la correzione.
Riferimento: OWASP A03:2021 Injection · CWE-89 SQL Injection · CVE-2023-34362 (MOVEit Transfer SQL Injection, CVSS 9.8, come benchmark severity) · PCI DSS v4.0 Req. 6.3.2 (patch management) · PCI DSS v4.0 Req. 11.3.1 (pentest esterno CDE) · PCI DSS v4.0 Req. 6.4.1 (test applicazioni web)
Pentest PCI DSS: confronto delle opzioni
| — | Scan gratuito | Matproof Sentinel | Consulenza tradizionale |
|---|---|---|---|
| Motore di scansione automatizzato | ✓ (anteprima 3 min) | ✓ Scansione completa | ✗ Solo manuale |
| Copertura OWASP Top 10 | Parziale | ✓ Completa | ✓ Completa |
| Prova di exploit | ✗ | ✓ Finding confermati (richiesta/risposta) | ✓ Per finding |
| Mapping normativo (DORA/NIS2/ISO 27001) | ✗ | ✓ Automatizzato | ✓ Manuale |
| Report PDF come evidenza per l'audit | ✗ | ✓ Immediato | ✓ Consegna 2–4 settimane |
| Scansioni continue / ricorrenti | ✗ | ✓ Per deploy | ✗ Impegno annuale |
| Tempo al primo risultato | ~3 min | ~30 min scansione completa | 2–4 settimane |
| Prezzo | €0 | Da €149 | €8.000–€25.000 |
| Revisione codice sorgente (SAST) | ✗ | ✓ Piano Growth | ✓ In scope |
| Test API (REST/GraphQL) | ✗ | ✓ Automatizzato | ✓ Manuale |
Offerte di pentest per PCI DSS v4.0
- 1 scansione pentest completa
- Risultati prioritizzati da AI con CVSS 3.1
- Finding ri-testati con richiesta/risposta come prova
- Report PDF (evidenza per l'audit)
- Mapping normativo (DORA, NIS2, ISO 27001)
- 3 pentest Sentinel completi al mese
- Monitoraggio continuo
- Integrazione CI/CD (GitHub, GitLab)
- Tutti i mapping normativi
- Supporto prioritario
- 10 pentest Sentinel al mese
- Scansioni aggiuntive a €149 ciascuna
- Tutti i 10 agenti, inclusi Cloud (Prowler) e Mobile (MobSF)
- Pianificazioni continue: oraria, giornaliera o settimanale
- Scansione autenticata (cookie di sessione, token bearer)
- Consegna via webhook e supporto prioritario
Domande frequenti sul test di penetrazione PCI DSS in Italia
Tutti i merchant e service provider italiani con PCI DSS devono effettuare un pentest?
I requisiti di penetration testing PCI DSS si applicano a tutti i livelli di merchant e service provider, ma con modalità diverse: Merchant Level 1 (oltre 6 milioni di transazioni/anno): validazione tramite QSA onsite e pentest annuale obbligatorio. Merchant Level 2-3 (tra 20.000 e 6 milioni di transazioni): SAQ + pentest annuale (dipende dal SAQ type). Merchant Level 4 (sotto 20.000 transazioni e-commerce o sotto 1 milione per altri canali): SAQ senza obbligo esplicito di pentest esterno, ma Req. 11.3 si applica comunque ai sistemi CDE. I service provider Level 1 (oltre 300.000 transazioni/anno) hanno requisiti ancora più stringenti, incluso il test della segmentazione ogni 6 mesi.
Qual è la differenza tra un ASV scan PCI DSS e un penetration test?
PCI DSS Req. 11.2 richiede scansioni trimestrali delle vulnerabilità esterne da parte di un ASV (Approved Scanning Vendor). Si tratta di scansioni automatizzate non intrusive che identificano le vulnerabilità presenti senza tentare lo sfruttamento. PCI DSS Req. 11.3 richiede invece un penetration test annuale che va oltre: il tester tenta attivamente di sfruttare le vulnerabilità per dimostrare che portano a un accesso non autorizzato. L'ASV scan non sostituisce il penetration test; entrambi sono obbligatori. Matproof Sentinel non sostituisce né la scansione ASV né il penetration test annuale. Fornisce evidenze per i test tra un pentest e l'altro.
PCI DSS v4.0 ha cambiato qualcosa rispetto a v3.2.1 per i test di penetrazione?
Sì — PCI DSS v4.0 ha introdotto cambiamenti significativi ai requisiti di test: Req. 11.3.3 (pentest segmentazione ogni 6 mesi) è un nuovo requisito esplicito; Req. 11.3.2.1 (pentest segmentazione ogni 6 mesi per i service provider) è stato formalizzato; la metodologia di pentest deve ora essere più esplicitamente documentata con copertura dei Req. 6 e 8; i tester devono essere «qualificati» con definizione più precisa. Tutti i nuovi requisiti PCI DSS v4.0 sono diventati obbligatori dal 31 marzo 2025.
Cosa deve contenere il report di penetration testing PCI DSS per soddisfare il QSA?
Un report di penetration testing PCI DSS conforme deve contenere: metodologia utilizzata (PTES, OWASP Testing Guide, ecc.); qualifiche del tester; perimetro testato con documentazione del CDE e dei sistemi testati; vulnerabilità identificate con CVSS score, descrizione e evidenza di sfruttamento; stato di remediation per ogni finding; data del test e periodo coperto; nel caso del Req. 11.3.3, mappa della segmentazione testata e risultato. Il report Matproof Sentinel contiene metodologia, perimetro testato, vulnerabilità con CVSS score e stato di remediation. Ogni risultato viene ritestato. I risultati confermati includono richiesta e risposta come prova. I risultati non confermati sono segnalati. Non sostituisce il pentest annuale di un tester qualificato.
Come si gestisce un breach di dati di carte di pagamento in Italia?
In caso di breach dei dati delle carte di pagamento, le obbligazioni includono: notifica immediata al processore di pagamento e ai brand delle carte (Visa, Mastercard) — di solito entro 24-72 ore; notifica al Garante Privacy entro 72 ore ai sensi dell'Art. 33 GDPR se coinvolti dati personali; coinvolgimento di un PFI (PCI Forensic Investigator) per le indagini forensi; potenziale audit PCI DSS post-breach. Le penali dei brand delle carte possono essere molto significative: Visa e Mastercard impongono multas da 5.000 € a 100.000 € al mese fino al raggiungimento della conformità, oltre alle spese di sostituzione delle carte compromesse.
PCI DSS si applica anche alle app di pagamento mobile in Italia (es. Satispay, Nexi)?
Sì — qualsiasi applicazione mobile che gestisce dati delle carte di pagamento (memorizza, elabora o trasmette PAN, CVV, dati di traccia) è soggetta a PCI DSS. Per le applicazioni mobile, si applica anche lo standard PA-DSS (Payment Application DSS) per i vendor di applicazioni di pagamento, ora evoluto in PCI Software Security Framework (SSF). In Italia, circuiti come Nexi, SIA e Bancomat impongono ai loro partner tecnologici la conformità PCI DSS come requisito contrattuale.
Quanto dura e quanto costa un pentest PCI DSS in Italia?
Un penetration test PCI DSS conforme per un ambiente di medie dimensioni richiede tipicamente: 1-3 giorni di test per un CDE standard con 10-50 sistemi; 1-2 giorni per la redazione del report QSA-ready. Il costo con un fornitore manuale tradizionale è generalmente tra 5.000 € e 20.000 € per un engagement PCI DSS standard. Matproof Sentinel riduce significativamente i costi con il penetration testing assistito dall'IA: il report PCI DSS-ready è generato automaticamente, con un costo a partire da 149 € per una valutazione iniziale.
Il pentest PCI DSS deve essere condotto da un QSA o da un tester qualificato diverso?
PCI DSS non richiede che il penetration test sia condotto da un QSA (Qualified Security Assessor) — il QSA valuta il report del pentest, non deve necessariamente condurlo. Il tester deve essere «qualificato e indipendente» (Req. 11.3.1): qualificato significa che ha le competenze tecniche dimostrabili (certificazioni OSCP, CREST, CEH, o equivalente, o esperienza documentabile); indipendente significa che non è responsabile dei sistemi testati (può essere interno all'azienda se in un team separato, o esterno). Il QSA valuta poi se il report è sufficientemente completo e se la metodologia soddisfa i requisiti PCI DSS.
Approfondisci — articoli correlati dal blog
Avvii i Suoi test PCI DSS tra un pentest e l'altro
Matproof Sentinel fornisce evidenze per i test del Requisito 11.3 PCI DSS v4.0 tra un pentest e l'altro: metodologia documentata, risultati ritestati con prova richiesta/risposta, stato di remediation. Non sostituisce il pentest annuale di un tester interno o esterno qualificato. La prima valutazione è disponibile in 3 minuti, senza registrazione.
Avvia il pentest PCI DSS