Penetration test e scansioni nel PCI DSS: i requisiti 11.3 e 11.4 della v4.0.1

Il PCI DSS v4.0.1, pubblicato dal PCI Security Standards Council a giugno 2024, è l'unica versione attiva dello standard: la v4.0 è stata ritirata il 31 dicembre 2024. Il PCI SSC definisce la v4.0.1 una revisione limitata, con correzioni e chiarimenti e nessun requisito aggiunto o eliminato; gli esempi di modifiche che evidenzia pubblicamente riguardano i requisiti 3, 6, 8 e 12 e le appendici. I 51 requisiti a data futura della v4.x sono diventati obbligatori il 31 marzo 2025. A giugno 2026 il PCI SSC ha aperto una consultazione sulla v4.0.1 per avviare la versione successiva, che non è ancora stata pubblicata.

Lo standard completo è gratuito, ma si scarica dalla Document Library del PCI SSC dopo aver accettato un contratto di licenza. Il testo dei requisiti riportato qui è stato letto nell'edizione v4.0 pubblicata dal PCI SSC a marzo 2022, e frequenze e condizioni corrispondono alle FAQ pubbliche del PCI SSC citate; verifica il testo v4.0.1 prima di citarlo in una policy.

Due premesse le fissa lo stesso PCI SSC. Non applica sanzioni né verifica la conformità: se un soggetto deve convalidare la conformità, come e presso chi lo decidono i circuiti di pagamento e gli acquirer (FAQ 1212). E un report di scansione ASV non attesta che siano soddisfatti altri requisiti PCI DSS (FAQ 1234).

Le scansioni interne (11.3.1) sono eseguite:

• almeno una volta ogni tre mesi;
• risolvendo le vulnerabilità alte e critiche secondo la classificazione del rischio definita al requisito 6.3.1;
• con nuove scansioni che confermano la risoluzione di tutte le vulnerabilità alte e critiche;
• con lo strumento di scansione aggiornato;
• da personale qualificato, con indipendenza organizzativa di chi esegue il test. Le note di applicabilità precisano che non serve un QSA o un ASV e che può scansionare il personale interno ragionevolmente indipendente dai sistemi scansionati: un amministratore di rete non dovrebbe scansionare la rete che gestisce.

L'11.3.1.1 riguarda tutte le altre vulnerabilità: vanno gestite in base al rischio definito nella targeted risk analysis (requisito 12.3.1), con nuove scansioni quando servono. L'11.3.1.2 richiede la scansione interna autenticata con privilegi sufficienti, un elenco documentato dei sistemi che non accettano credenziali e la gestione degli account di scansione che consentono il login interattivo. Entrambi erano a data futura e si applicano dal 31 marzo 2025. L'11.3.1.3 richiede scansioni interne dopo ogni modifica significativa, risolvendo le vulnerabilità alte e critiche.

Le scansioni esterne (11.3.2) sono eseguite almeno una volta ogni tre mesi da un Approved Scanning Vendor (ASV) del PCI SSC, risolvendo le vulnerabilità e rispettando i requisiti dell'ASV Program Guide per una scansione superata, con nuove scansioni quando servono. Questo requisito non ammette l'approccio personalizzato. L'11.3.2.1 richiede scansioni esterne dopo ogni modifica significativa, risolvendo le vulnerabilità con punteggio CVSS pari o superiore a 4.0; queste non devono essere eseguite da un ASV.

Le FAQ del PCI SSC aggiungono il dettaglio operativo. «Almeno una volta ogni tre mesi» significa non più di 90 giorni tra una scansione e l'altra, e le scansioni dopo una modifica significativa si aggiungono a quelle trimestrali (FAQ 1087). Servono quattro scansioni superate negli ultimi 12 mesi, anche se lo si può dimostrare con un insieme di scansioni e riscansioni; trimestri mancanti perché le scansioni non erano pianificate, erano incomplete o ritrovavano le stesse vulnerabilità non gestite significano requisito non soddisfatto (FAQ 1152). Una scansione esterna superata in genere non presenta condizioni di fallimento automatico né vulnerabilità con punteggio 4.0 o superiore. Con la v4.x anche gli esercenti SAQ A le cui pagine reindirizzano o incorporano una pagina di pagamento di terzi devono eseguire scansioni ASV.

L'11.4.1 richiede una metodologia di penetration test definita, documentata e applicata, che comprenda:

• approcci di penetration test accettati dal settore;
• copertura dell'intero perimetro del CDE e dei sistemi critici;
• test sia dall'interno sia dall'esterno della rete;
• test che convalidino ogni controllo di segmentazione e di riduzione del perimetro;
• test a livello applicativo che coprano almeno le vulnerabilità elencate al requisito 6.2.4;
• test a livello di rete su tutti i componenti che svolgono funzioni di rete e sui sistemi operativi;
• esame delle minacce e delle vulnerabilità degli ultimi 12 mesi;
• un approccio documentato per valutare e gestire il rischio delle vulnerabilità sfruttabili trovate;
• conservazione dei risultati dei test e delle attività di correzione per almeno 12 mesi.

Per test interno si intende il test dall'interno del CDE e verso il CDE da reti interne attendibili e non attendibili; per test esterno quello del perimetro esterno esposto delle reti attendibili e dei sistemi critici raggiungibili da reti pubbliche.

I penetration test interni (11.4.2) ed esterni (11.4.3) sono eseguiti ciascuno secondo la metodologia, almeno una volta ogni 12 mesi, dopo ogni aggiornamento o modifica significativa di infrastruttura o applicazioni, da una risorsa interna qualificata o da un soggetto esterno qualificato, con indipendenza organizzativa del tester (non deve essere un QSA o un ASV). L'11.4.4 richiede che vulnerabilità e debolezze sfruttabili siano corrette secondo la valutazione del rischio del requisito 6.3.1 e che il penetration test sia ripetuto per verificare le correzioni.

11.4.5: se usi la segmentazione per isolare il CDE, i penetration test sui controlli di segmentazione si eseguono almeno una volta ogni 12 mesi e dopo ogni modifica a quei controlli, coprono tutti i metodi di segmentazione in uso e confermano che il CDE è isolato da tutti i sistemi fuori perimetro, con un tester qualificato e indipendente. 11.4.6: i service provider fanno lo stesso almeno una volta ogni sei mesi, e la FAQ del PCI SSC sull'11.4.6 conferma che l'intervallo non può superare i sei mesi. 11.4.7: i service provider multi-tenant supportano i penetration test esterni dei propri clienti.

Diversi requisiti scattano con le modifiche significative oltre che a calendario. La FAQ del PCI SSC elenca cosa va valutato come minimo: nuovo hardware, software o apparato di rete nel CDE; sostituzioni o aggiornamenti importanti di hardware e software nel CDE; modifiche al flusso o alla conservazione dei dati di pagamento; modifiche al confine del CDE o al perimetro della valutazione; modifiche all'infrastruttura di supporto come directory, server di sincronizzazione oraria, logging e monitoraggio; modifiche a fornitori o service provider che supportano il CDE. Per ognuna serve una decisione registrata su scansioni e test da ripetere.

Lo standard non definisce «qualificato» con un elenco di certificazioni. La guida indica l'esperienza pregressa, per esempio gli anni di attività e il tipo e l'ampiezza degli incarichi svolti, come modo per verificare che il tester sia adatto all'incarico. Indipendenza organizzativa significa che il tester non fa parte del team che gestisce o modifica i sistemi testati. Gli assessor verificano entrambe esaminando perimetro e risultati del lavoro e intervistando il personale: scrivi qualifiche e linea di riporto del tester nel report del test.

Il PCI DSS non vieta gli strumenti: definisce che cos'è un penetration test e chi ne risponde.

Cosa dice il testo. L'obiettivo dell'approccio personalizzato per l'11.4.1 è una metodologia formale «per un test tecnico approfondito che tenta di sfruttare vulnerabilità e debolezze di sicurezza tramite metodi di attacco simulati da un attaccante manuale competente». La guida aggiunge che la sola scansione non è un penetration test, che un test non è adeguato se si limita a sfruttare i risultati dello scanner e che «il penetration test è un processo in larga parte manuale: si possono usare alcuni strumenti automatici, ma il tester usa la propria conoscenza dei sistemi per entrare in un ambiente», spesso concatenando più exploit.

Cosa l'automazione non può fare da sola:

• Essere la risorsa interna qualificata o il soggetto esterno previsti da 11.4.2, 11.4.3 e 11.4.5. Una piattaforma che nessuno guida non è un tester con qualifiche e indipendenza da mostrare all'assessor.
• Sostituire l'ASV per l'11.3.2. Solo un ASV in elenco, con la propria soluzione di scansione ASV, soddisfa quel requisito.
• Decidere se il test annuale è accettabile. Il giudizio spetta al tuo QSA o, in autovalutazione, a te e al tuo acquirer.

Cosa può fare bene:

• Dare al tester qualificato uno strumento che copre più in fretta e più spesso le prospettive interna ed esterna della metodologia, i percorsi a livello di rete e le verifiche di segmentazione, mentre il tester progetta, supervisiona e firma il test.
• Eseguire i test richiesti dopo le modifiche significative (11.3.1.3, 11.3.2.1, 11.4.2, 11.4.3, 11.4.5), che non aspettano il ciclo annuale e non richiedono un ASV o un QSA.
• Ritestare ogni correzione con la stessa prova che ha trovato la falla, come chiede l'11.4.4.
• Mantenere le evidenze semestrali di segmentazione per i service provider (11.4.6) e un registro continuo tra un test annuale e l'altro.

Se un team interno che usa una piattaforma autonoma valga come risorsa interna qualificata per il test annuale è una domanda per il tuo assessor, e la risposta dipende da qualifiche, indipendenza e metodologia del team, non dallo strumento. Per i limiti generali vedi il penetration test automatizzato.

Il test annuale è una soglia minima, e il resto del requisito 11 presuppone già evidenze più frequenti. Una struttura facile da difendere in una valutazione:

1. Ogni trimestre, e più spesso dove l'analisi del rischio lo indica: scansioni interne autenticate e scansioni esterne ASV, con riscansioni fino all'esito positivo. Il PCI SSC incoraggia a scansionare più spesso del minimo.
2. A ogni modifica significativa: scansioni interne ed esterne, più i penetration test interni, esterni e di segmentazione interessati dalla modifica, registrati sul ticket di change.
3. In continuo tra un test e l'altro: campagne autonome black box e gray box sul perimetro del CDE, sui sistemi critici e sui confini di segmentazione, così una regressione o una nuova esposizione emerge in pochi giorni e non al test annuale successivo. La guida del PCI SSC sui sistemi di AI di settembre 2026 insiste su monitoraggio e gestione delle vulnerabilità frequenti, se non continui.
4. Almeno una volta ogni 12 mesi: i penetration test interni ed esterni guidati da un tester qualificato e indipendente secondo la metodologia documentata, alimentati da ciò che il test continuo ha trovato nell'anno e dalle minacce degli ultimi 12 mesi, come chiede l'11.4.1.
5. Dopo ogni correzione: un retest che chiude il finding, con risultati conservati per almeno 12 mesi.

Per i requisiti 11.3 e 11.4 il fascicolo di solito comprende:

• La metodologia di penetration test con tutti gli elementi dell'11.4.1, le date di approvazione e di revisione.
• I report dei penetration test interni ed esterni degli ultimi 12 mesi: perimetro del lavoro, risultati, qualifiche e indipendenza organizzativa del tester.
• I risultati dei test di segmentazione con la cadenza richiesta (12 mesi, o sei per i service provider), su tutti i metodi di segmentazione.
• I registri di correzione e retest, che mostrano ogni finding sfruttabile corretto secondo la classificazione del rischio del requisito 6.3.1 e verificato ripetendo il test.
• Quattro trimestri di report di scansione ASV sui modelli ufficiali, con le riscansioni, e quattro trimestri di scansioni interne con le riscansioni per le vulnerabilità alte e critiche.
• La targeted risk analysis per le vulnerabilità di livello inferiore (11.3.1.1) e l'elenco dei sistemi che non accettano credenziali per la scansione autenticata (11.3.1.2).
• I registri delle modifiche, che mostrano quali modifiche significative hanno fatto scattare scansioni e test, e con quali risultati.
• Risultati ed evidenze di correzione conservati per almeno 12 mesi.

Un red team AI autonomo per reti e infrastrutture non è un ASV, non è un QSA e non sostituisce il tester qualificato e indipendente previsto dal PCI DSS. Dà a quel tester, e al team di sicurezza, più evidenze tra un test annuale e l'altro.

• Interno ed esterno, a calendario e dopo le modifiche. Campagne black box sul perimetro esterno e gray box con privilegi di utente standard all'interno della rete, eseguite una volta, ogni giorno, ogni settimana, ogni mese o con una pianificazione personalizzata, e avviabili per una modifica significativa.
• Prima la prova, poi il retest. I finding registrano se una vulnerabilità è stata effettivamente sfruttata, e ogni correzione si ritesta con la stessa prova: è il registro che chiede l'11.4.4.
• Mappatura sul requisito 11. Il framework PCI DSS 4.0.1 del motore, uno dei 34 supportati, include controlli per le scansioni interne trimestrali e la loro risoluzione, la scansione autenticata, le scansioni esterne ASV, i penetration test interni ed esterni, il retest delle correzioni e i test di segmentazione, ed esporta report di conformità. La scansione ASV vera e propria deve comunque arrivare da un ASV.
• Approvazione umana dei passi rischiosi. Cinque livelli di autonomia stabiliscono cosa deve attendere una persona, e i proof of concept di exploit possono restare in attesa della revisione dell'operatore: i test vicino ai sistemi di pagamento in produzione restano sotto controllo. Vedi human in the loop.
• Registri che reggono. Ogni tentativo di attacco è una voce firmata Ed25519 in una catena di hash SHA-256, e i report esportati sono firmati ECDSA.
• Nessun dato del cliente lascia l'appliance. I modelli girano sull'appliance, senza servizi AI esterni: i dati di pagamento toccati da un test e la mappa dei sistemi del CDE sfruttabili non finiscono su un'altra piattaforma cloud da inserire e gestire come third-party service provider ai sensi del requisito 12.8. Vedi red team AI on-premise.

• PCI Data Security Standard: panoramica e accesso ai documenti (PCI SSC)
• Document Library del PCI SSC: PCI DSS v4.0.1 e information supplement Penetration Testing Guidance
• Just Published: PCI DSS v4.0.1, 11 giugno 2024 (blog PCI SSC)
• FAQ: cosa significa «quarterly» o «at least once every three months» (PCI SSC)
• FAQ: le quattro scansioni superate (PCI SSC)
• FAQ: una scansione ASV non equivale alla conformità PCI DSS (PCI SSC)
• FAQ: classificazione del rischio e risoluzione delle vulnerabilità (PCI SSC)
• FAQ: cosa si intende per «significant change» (PCI SSC)
• FAQ: test di segmentazione dei service provider secondo l'11.4.6 (PCI SSC)
• FAQ: il ruolo del PCI SSC nella convalida della conformità (PCI SSC)
• Resource Guide: Vulnerability Scans and Approved Scanning Vendors, luglio 2024 (blog PCI SSC)
• Consultazione sul PCI DSS v4.0.1, giugno 2026 (blog PCI SSC)
• Just Published: Security Considerations for AI Systems, settembre 2026 (blog PCI SSC)