Il PCI Security Standards Council ha rilasciato la versione 2.0 del Secure Software Standard e la relativa Guida al programma, che rappresenta la revisione più significativa dall'inizio del framework nel 2019. Questo aggiornamento ridisegna radicalmente il modo in cui il software di pagamento viene valutato e convalidato, introducendo una nuova terminologia, un campo di applicazione ampliato e processi semplificati che avranno un impatto su fornitori, valutatori e clienti in tutto l'ecosistema dei pagamenti.

Il fondamento: Un nuovo approccio all'ammissibilità e all'ambito di applicazione

Forse il cambiamento più fondamentale della versione 2.0 è la completa eliminazione del termine "software di pagamento" dallo standard. I criteri di idoneità sono ora interamente incentrati sul concetto di Sensitive Assets, definitocome qualsiasi elemento del prodotto software il cui accesso, uso, modifica o divulgazione non autorizzati possono compromettere le funzionalità o i dati relativi ai pagamenti del software.

Questa riformulazione concettuale è accompagnata da un nuovo documento obbligatorio, il Sensitive Asset Identification (SAID), che fornisce un contesto dettagliato ed esempi per l'identificazione di dati, funzionalità, risorse e modalità operative sensibili. Per i dati EMVCo 3DS, lo standard fa ora riferimento al documento PCI 3DS Data Matrix.

L'implicazione pratica è chiara: se il vostro software gestisce risorse sensibili secondo la definizione dello standard, rientra nell'ambito di applicazione, indipendentemente dal fatto che rientri nelle categorie tradizionali del software di pagamento.

Revisione della terminologia: Comprendere il nuovo linguaggio

La versione 2.0 introduce significativi aggiornamenti terminologici che valutatori e venditori devono interiorizzare:

Inoltre, il glossario è stato trasferito da un documento SSF esterno all'Appendice A dello standard stesso, e i termini definiti sono ora contrassegnati in tutti i requisiti di sicurezza per facilitarne il riconoscimento. È stato introdotto un nuovo termine, "Strong Authentication" e lo standard si basa ora sulla base di "Strong Cryptography" piuttosto che su specifici parametri di forza effettiva delle chiavi.

Riorganizzazione strutturale: Requisiti fondamentali e moduli

Lo standard v2.0 è stato interamente ristrutturato attorno a undici Obiettivi di sicurezza nella sezione Core, che si applica a tutto il software valutato nell'ambito del framework:

1. Architettura del software, composizione e versioning - Include nuovi requisiti per la distinta base (BOM) e il versioning wildcard.
2. Identificazione delle risorse sensibili - Stabilisce le basi per i requisiti successivi.
3. Archiviazione e conservazione delle risorse sensibili
4. Modalità operative sensibili - Contesto formalizzato per il controllo degli accessi e l'autenticazione forte
5. Protezione degli asset sensibili - Include il rilevamento di comportamenti anomali formalizzati.
6. Output di risorse sensibili - Con requisiti formalizzati di canale sicuro
7. Numeri casuali - Requisiti raffinati per l'utilizzo di RNG esterni o per l'implementazione interna.
8. Gestione delle chiavi
9. Crittografia - Un unico requisito che comprende le aree non coperte altrove.
10. Minacce e vulnerabilità
11. Implementazione e gestione sicure - Compresi i requisiti della guida all'implementazione

Evoluzione del modulo: Cosa è cambiato

Modulo A - Protezione dei dati dell'account

I requisiti sono stati rivisti per concentrarsi esclusivamente su PAN e SAD in relazione agli standard PCI DSS, con un contesto aggiuntivo fornito nel documento SAID.

Modulo B - Software per dispositivi POI

Rinominato da "Requisiti del software del terminale", questo modulo è stato notevolmente semplificato. Molti requisiti (B1.1, B1.2, B1.3, B3.x, B5.x) sono stati assorbiti nei requisiti Core e i requisiti SRED sono stati rivisti.

Modulo C - Software accessibile al pubblico

Rinominato da "Requisiti per il software web" per meglio cogliere il suo intento. Il chiarimento dell'ambito è significativo: questo modulo riguarda il software accessibile su reti pubbliche in cui essenzialmente chiunque abbia accesso alla rete può interagire con il software. È importante notare che il software non accessibile pubblicamente può comunque essere valutato in base a questo modulo a discrezione del fornitore, in quanto i requisiti contribuiscono a ridurre il rischio per qualsiasi implementazione.

Modulo D - Kit di sviluppo software (NUOVO)

Questo modulo completamente nuovo consente di valutare gli SDK, compresi gli SDK EMVCo 3DS. Lo standard afferma esplicitamente che la versione 2.0 sostituirà lo standard SDK PCI 3DS separato, offrendo ai fornitori una maggiore flessibilità grazie alla natura più oggettiva dello standard Secure Software.

Cambiamenti Delta: Il nuovo sistema di livelli

Le precedenti categorie di modifiche "a basso impatto" e "ad alto impatto" sono state sostituite da una struttura con modifiche Delta di livello 1 e 2 :

Modifiche delta di livello 1

• Modifiche non impattanti sulla sicurezza in cui i numeri di versione devono essere modificati ma non vengono utilizzati caratteri jolly.
• Vantaggi per i fornitori qualificati SSLC: le correzioni di bug/patch che hanno un impatto sulla sicurezza, anche se coinvolgono risorse sensibili, si qualificano come Tier 1 e possono essere presentate autonomamente senza il coinvolgimento del valutatore.

Cambiamenti Delta di livello 2

• Introduzione di nuovi tipi di asset sensibili
• Modifiche che richiedono la valutazione di requisiti precedentemente non valutati
• Modifiche che coinvolgono o impattano asset sensibili (ad eccezione delle modifiche ammissibili di livello 1 per i fornitori di SSLC)
• Modifiche al dispositivo PTS POI
• Modifica delle dipendenze richieste
• Rimozione di versioni specifiche dagli elenchi

Caratteri jolly: Formalizzati e reintrodotti

Il versioning dei caratteri jolly è stato formalmente reintrodotto con regole chiare:

• Definizione: Un carattere che può essere sostituito a un sottoinsieme definito di caratteri possibili in uno schema di versioning per tenere conto di modifiche non impattanti sulla sicurezza.
• I caratteri jolly devono comparire solo nella parte più a destra (meno significativa) dei numeri di versione.
• Caratteri jolly ammessi: minuscolo {x, y, z}, maiuscolo {X, Y, Z}, o asterisco (*)
• Un singolo carattere jolly rappresenta una sostituzione di una singola cifra {0-9}.
• I caratteri jolly non possono rappresentare modifiche che influiscono sulla sicurezza.

Questa formalizzazione consente ai fornitori di gestire le versioni minori senza presentare le modifiche a PCI SSC, a condizione che l'uso dei caratteri jolly sia convalidato durante la Valutazione completa.

Requisiti di valutazione: Il codice sorgente è obbligatorio

La versione 2.0 rende esplicito ciò che prima era implicito: lafornitura del codice sorgente di è obbligatoria. La Guida al programma afferma inequivocabilmente che:

"Il fornitore di software è tenuto a fornire il codice sorgente del proprio prodotto software da valutare, come ritenuto necessario dal valutatore che esegue la valutazione". Non è possibile far valutare un prodotto software secondo questo standard senza fornire il relativo codice sorgente".

I requisiti di prova sono stati completamente riscritti in base a tre metodi:

1. Revisione della documentazione
2. Analisi statica
3. Analisi dinamica

Ciclo di vita e processi amministrativi

Il ciclo di vita di convalida di 3 anni rimane intatto:

• Anno 1 e 2: è richiesta l'attestazione annuale del fornitore.
• Anno 3: è necessaria una nuova valutazione per mantenere l'elenco.

Chiarimenti chiave nella v2.0:

• Periodo di scadenza amministrativa: 45 giorni di calendario dopo la scadenza dell'attestazione non rispettata, indicati in arancione sugli elenchi.
• Scadenza dell'elenco: Dopo il periodo di grazia di 45 giorni, i prodotti diventano Prodotti software sicuri scaduti.
• I prodotti scaduti richiedono una nuova valutazione, non una nuova valutazione, per essere reinseriti nell'elenco.

Notifica di problemi di sicurezza: Nuova sezione dedicata

La versione 2.0 introduce una sezione dedicata Sezione 8 per la notifica dei problemi di sicurezza, formalizzando:

• Requisiti temporali di notifica secondo il VRA
• Formato di notifica richiesto (scritto, preceduto da e-mail)
• Dettagli minimi di notifica, compreso il punteggio CVSS
• Azioni di risposta di PCI SSC, compreso il potenziale ritiro dell'accettazione.

Implicazioni pratiche per le parti interessate

Per i fornitori di software

• Esaminare i propri prodotti in base alla nuova definizione di asset sensibile.
• Aggiornare le metodologie di versionamento per sfruttare i vantaggi delle wildcard.
• Preparare distinte base complete per la valutazione
• Considerare la qualifica SSLC per i vantaggi del Delta Change di livello 1
• Assicurare la disponibilità del codice sorgente per le valutazioni

Per le società di valutazione SSF

• Completare la formazione richiesta per la v2.x prima di eseguire le valutazioni.
• Familiarizzare con il nuovo documento SAID
• Aggiornare le metodologie di valutazione per la nuova struttura dei requisiti di test.
• Prepararsi per le valutazioni SDK nell'ambito del Modulo D

Per i clienti

• Verificare che i fornitori forniscano una guida all'implementazione coerente con i numeri di versione elencati.
• Comprendere che le dipendenze richieste fanno parte della convalida: l'uso di dipendenze non elencate invalida l'elenco.
• Monitorare le date di attestazione del fornitore e le tempistiche di rivalutazione.

Conclusione

PCI Secure Software Standard v2.0 rappresenta una maturazione del framework, passando da categorie prescrittive di software di pagamento a un approccio basato su principi incentrati sulla protezione delle risorse sensibili. L'inclusione di funzionalità di valutazione degli SDK, la formalizzazione delle versioni wildcard e il sistema di modifiche delta a livelli puntano a un programma di convalida più flessibile e sostenibile.

Per le organizzazioni attualmente in possesso di convalide v1.x o che stanno pianificando nuove valutazioni, è il momento di rivolgersi a società di valutazione SSF qualificate per comprendere il percorso di transizione e sfruttare la maggiore flessibilità offerta da questa importante revisione.

Lo Standard PCI Secure Software v2.0 e la Guida al programma v2.0 entrano in vigore a gennaio 2026. Le organizzazioni devono consultare la documentazione ufficiale di PCI SSC e i valutatori qualificati per ottenere indicazioni specifiche sulla conformità.