Minacce e sistemi di pagamento in evoluzione: rilasciata la v.4 dello standard PCI DSS

Il Payment Card Industry Data Security Standard evolve in data 31/03/2022 con il PCI DSS v4.0.

Tale aggiornamento si è reso necessario a causa dell’evoluzione delle minacce e dei rischi annessi, mutati negli ultimi anni, e l’avanzare delle recenti modalità di pagamento che hanno arricchito il panorama dei pagamenti elettronici, introducendo nuove sfide e nuovi rischi.

Mossi da questi cambiamenti e con l’obiettivo di innalzare ulteriormente il livello di sicurezza delle organizzazioni che operano in tali ambiti (memorizzando, elaborando o trasmettendo i dati delle carte di pagamento) e cercando di razionalizzare ed allineare ulteriormente i criteri con gli altri standard di settore, i brand che si occupano di trasferimento di denaro e i vari stakeholder coinvolti, hanno lavorato per definire una nuova versione.

Quindi, a nove anni dall’uscita della versione 3 (novembre 2013) e a quattro dall’ultima release attualmente in uso 3.2.1 (maggio 2018), viene pubblicata la nuova versione dello standard v.4 che introduce una serie di cambiamenti significativi.

Entrando maggiormente nel dettaglio, le modifiche introdotte sono riconducibili a tre macroaree:

• Evoluzione dei requisiti: modifiche per garantire che lo standard sia aggiornato con le minacce e le tecnologie emergenti e i cambiamenti nel settore dei pagamenti.
• Chiarimenti o linee guida: formulazione, spiegazione, definizione, guida aggiuntiva e/o istruzioni aggiornate per aumentare la comprensione o fornire ulteriori informazioni o indicazioni su un argomento particolare.
• Struttura o formato: riorganizzazione del contenuto, inclusa la combinazione, la separazione e la rinumerazione dei requisiti per allinearne il contenuto.

Particolare attenzione è da incentrare sulla evoluzione dei requisiti. In tale area, infatti, ricadono due ulteriori modifiche sostanziali, che hanno l’obiettivo di innalzare la sicurezza sia a livello di processo sia a livello tecnologico:

• Evoluzione di requisiti esistenti.
• Implementazione di nuovi requisiti.

All’interno della prima categoria, a titolo di esempio, possiamo identificare le seguenti modifiche:

• Definizioni di ruoli e responsabilità su molti ambiti tecnologici e di processo.
• Aumento della lunghezza della password e il numero di tentativi di autenticazione non validi.
• Formazione sulla sensibilizzazione alla security per includere la consapevolezza delle minacce e delle vulnerabilità che potrebbero influire sulla sicurezza del CDE.

Invece, per quanto riguarda l’implementazione si segnalano:

• Controlli tecnici per impedire la copia e/o il trasferimento di PAN quando si utilizzano tecnologie di accesso remoto.
• Revisione di tutti gli accessi per applicazione e account di sistema e relativi privilegi di accesso.
• Implementare l’autenticazione a più fattori (MFA) per tutti gli accessi al CDE.
• Eseguire scansioni di vulnerabilità interne tramite scansioni autenticate

Ulteriore cambiamento significativo introdotto dalla v.4 consiste nella modalità di valutazione che potrà essere utilizzata. Infatti, la grande variazione che viene introdotta è che, affiancato ad una valutazione tradizionale come previsto per le precedenti versioni, sarà possibile effettuare una valutazione mediante “approccio personalizzato”, ossia un approccio risk base, che definisce gli ambiti a cui applicare gli assessment partendo da un’attività di analisi dei rischi mirata sui target determinati.

Come per tutte le versioni, è stato previsto un periodo di transizione in cui lo standard v.4 e v.3.2.1 coesisteranno, e che potranno essere utilizzati per validare le entità oggetto di valutazione. La data di ritiro della v.3.2.1 è stata definita al 31 marzo 2024. Dopo tale data sarà obbligatorio effettuare validazioni PCI DSS esclusivamente sulla versione 4 dello standard.

È doveroso precisare che, pur se in un periodo iniziale sarà possibile validarsi sul vecchio schema di conformità, è importante per le entità soggette a PCI DSS iniziare sin da subito ad analizzare ed approcciare le richieste della versione 4. In questo modo, tali entità avranno il tempo per definire i corretti piani di intervento necessari a modificare e/o implementare tutti gli accorgimenti richiesti senza incorrere, al momento dello switch off della versione 3.2.1, a validazioni dei perimetri di analisi “non conformi”.

Articolo a cura di Paolo Sferlazza e Maurizio Priola