di Amedeo Lupinelli
Il 31 marzo scorso, sul filo di lana, il PCI Security Standards Council ha rilasciato la versione 4.0 dello Standard PCI DSS – era stato promesso il rilascio entro Q1 2022. Si tratta di una major release, l’ultima pubblicata era la versione 3.2.1.
Il percorso di gestazione della nuova release è stato decisamente lungo, la prima bozza che è stata inviata a noi certificatori risale al 2019, ne sono state poi rilasciate altre due intermedie, nel 2020 e nel 2021, per arrivare alla versione definitiva appena rilasciata. Durante questi tre anni, il PCI Council ha raccolto i feedback da parte degli addetti ai lavori (hanno dichiarato di aver ricevuto oltre seimila commenti), modificando i requisiti per adattare il più possibile lo Standard alle esigenze delle organizzazioni che sono chiamate o ad applicarlo o a verificarne la corretta applicazione.
La vecchia versione dello Standard continuerà ad essere applicabile ancora per due anni, il 31 marzo 2024 la v3.2.1 sarà ritirata e sarà possibile certificarsi soltanto con la v4.0. Questo periodo di convivenza delle due versioni è stato pensato proprio per dare il tempo a tutti di comprendere i cambiamenti e pianificare le eventuali implementazioni di nuovi controlli, o le modifiche ai controlli esistenti per adeguarli alle nuove richieste. A questo va aggiunto che la maggior parte dei nuovi requisiti sono considerati best practices nella prima fase: anche quando la v3.2.1 non sarà più considerata valida, quei requisiti saranno facoltativi, spostando di fatto l’obbligo al 31 marzo 2025.
Tra le principali novità introdotte dalla nuova versione della PCI DSS va sicuramente citata la flessibilità introdotta dal cosiddetto “Customized Approach”. Si tratta della possibilità di utilizzare un approccio custom per rispondere ad ogni requisito, che quindi non deve necessariamente seguire il metodo tradizionale, il “Defined Approach” suggerito dallo Standard e che fino alla versione 3.2.1 era l’unico approccio percorribile, ma può essere scelto dall’organizzazione in funzione delle sue esigenze. In sostanza viene offerta la possibilità di personalizzare i controlli di sicurezza da implementare focalizzandosi sull’obiettivo che ogni requisito si prefigge; sarà possibile, quindi, determinare quali controlli mettere in campo per raggiungere quell’obiettivo sulla base della tecnologia che si sta utilizzando o dei processi in essere. Nello scegliere l’approccio custom è necessario non solo definire e documentare i controlli utilizzati ma occorre anche procedere con una risk analysis specifica che conduca ad una gestione degli eventuali rischi associati oltre a definire le procedure di test per assicurarsi che i controlli stessi funzionino come dovrebbero.
L’approccio custom non è una scelta da fare a cuor leggero, sicuramente offre un grado di libertà in più soprattutto per chi utilizza tecnologie innovative, ma di certo richiede un effort maggiore rispetto all’approccio standard che offre un percorso ben definito e si adatta bene nella stragrande maggioranza dei casi. Potrebbe essere una scelta valida per realtà nelle quali i processi di valutazione del rischio sono maturi e i processi di gestione della sicurezza IT robusti. Va comunque osservato che l’approccio custom, per ogni requisito, deve essere validato dal certificatore (QSA) che deve confermare che i controlli custom implementati siano accettabili nell’ambito dell’obiettivo di sicurezza del requisito a cui si riferiscono.
I nuovi requisiti introdotti e le modifiche a quelli della versione precedente e non sono pochi, proveremo a fare un approfondimento in un prossimo articolo, ma credo sia opportuno evidenziare almeno due punti:
- Attenzione agli attacchi di tipo phishing
- Attività di verifica del perimetro
Il primo punto è una diretta conseguenza del fatto che la Sicurezza IT è una disciplina per sua natura dinamica, deve adeguarsi a come cambiano le minacce. Aver introdotto in due requisiti (5.4.1 e 12.6.3.1) il riferimento agli attacchi di tipo phishing (o social engineering in generale) mette l’enfasi su una minaccia che attualmente è molto diffusa e che sfrutta una debolezza della componente umana che, con una buona campagna di formazione, può essere di molto ridimensionata.
Il secondo introduce il concetto molto importante di verifica periodica del perimetro della certificazione PCI DSS. Con i nuovi requisiti (12.5.2 e 12.5.2.1) si vuole sensibilizzare le organizzazioni ad avere un maggiore controllo sui dati che i propri sistemi IT gestiscono. Lo Standard PCI DSS naturalmente si riferisce al dato carta, principalmente al PAN, ma il discorso andrebbe allargato anche ad altre tipologie di dati (es. quelli personali in ottica GDPR). Avere dei processi di verifica che consentano di intercettare il dato carta (o particolari tipologie di dati) all’interno del proprio parco IT, basandosi tipicamente su tool di data discovery, aiuta non solo a mantenere aggiornato il perimetro della certificazione, ma anche a fare emergere eventuali gestioni del PAN su sistemi che non si sospettava lo trattassero. Quest’ultimo punto è molto delicato in quanto comporta l’esposizione inconsapevole ad un rischio (si pensi ad un log applicativo lasciato in modalità verbosa che traccia il PAN in chiaro) che nessuna risk analisys ha mai analizzato e provato a gestire. Questi casi sono molto più frequenti di quanto si possa pensare, in particolar modo quando i sistemi sono datati e sui quali si sono stratificate nel tempo diverse gestioni sistemistiche e applicative.
