top space  top space  top space  top space  top space       Visualizza il sito in italiano Visualizza il sito in inglese

PCI DSS: requisiti documentali e attivita' periodiche


Nonostante la prossima uscita della versione 3.0 (novembre 2013), a quasi 10 anni dall’uscita della prima versione, intorno allo standard PCI DSS continuano a veleggiare dubbi e incertezze.

Ancora troppo spesso succede che i soggetti coinvolti dalla PCI DSS, in particolare i service provider, sottovalutino il percorso di conformità in rapporto allo standard, senza avere piena coscienza dei rischi, soprattutto a livello economico e d’immagine, che il mancato rispetto dei requisiti può comportare.

Purtroppo l’effort richiesto alle aziende, che memorizzano, elaborano o trasmettono dati dei titolari di carta,  per ottenere e anche per mantenere la conformità rispetto allo standard PCI DSS è piuttosto elevato: per essere conformi non è sufficiente ricordarsi una volta all’anno di compilare il questionario di autovalutazione (SAQ - Self Assessment Questionnaire) o utilizzare un tool certificato che effettua automaticamente le scansioni ASV con cadenza trimestrale. Le due attività appena citate non sono altro che un piccolo  sottoinsieme dei controlli e delle azioni che è necessario effettuare, secondo quanto stabilito dalla PCI DSS.

 

PCI DSS graphic

 

 

Per sua costruzione, lo standard  PCI DSS, è un mix piuttosto uniforme di aspetti tecnologici, organizzativi e procedurali.

 

 

PCI DSS

Proprio gli aspetti organizzativi e procedurali sono spesso i più tralasciati, in quanto “apparentemente” non vanno ad incidere sugli aspetti IT, e vengono frequentemente interpretati come degli ostacoli rispetto alla quotidiana operatività.

Andando ad esplorare in profondità la PCI DSS si scopre che i requisiti che richiedono documentazione a supporto non sono esclusivamente quelli afferenti al capitolo 12, ma che quasi ogni requisito richiede un supporto documentale: sono infatti 192 gli aspetti documentali richiesti dallo standard.

 

Dopo quanto appena affermato la domanda che è lecito porsi è: “Ma per essere conforme alla PCI DSS è necessario scrivere 192 documenti?” La risposta è ovviamente NO. Lo standard non definisce un numero minimo o massimo di documenti che è necessario produrre, richiede solo che tutti gli aspetti documentali siano formalmente documentati. Ciò implica che per realtà particolarmente semplici, ad esempio piccoli service provider, è sufficiente redigere un unico documento contenente tutte le parti procedurali e organizzative afferenti alla gestione delle carte di pagamento. Tale soluzione non è però facilmente praticabile da grosse realtà, quali ad esempio Merchant che gestiscono vendite online, in quanto i processi all’interno dell’azienda sono estremamente complessi e coinvolgono svariati reparti che interagiscono tra di loro. In questo specifico caso, la soluzione ottimale è quella di redigere una politica generale per la sicurezza dei dati delle carte di pagamento e costruire procedure specifiche, ad esempio per la gestione dei backup o dei log, che definiscano ruoli e responsabilità inerenti alle specifiche attività.

Nella redazione della documentazione inerente la gestione dei dati delle carte di pagamento, ci si scontra spesso con due falsi miti che andiamo di seguito ad analizzare.

 

Falsi miti nella redazione della documentazione

 

Il primo falso mito è quello inerente la stesura della documentazione in presenza di un Sistema di Gestione per la Sicurezza delle Informazioni (SGSI) certificato rispetto allo standard ISO/IEC 27001:2005. “Ho una certificazione 27001, quindi non devo scrivere nuova documentazione, quella che ho è sufficiente a garantire la sicurezza di tutte le informazioni, comprese quelle delle carte di pagamento”. L’affermazione purtroppo non è realistica. È ben vero che, avendo un SGSI certificato ISO 27001, molte politiche e procedure richieste dalla PCI DSS sono già sviluppate, ma quasi sempre è necessario adeguarle per includere in modo esplicito, cosi come richiesto dallo standard, gli aspetti relativi al trattamento delle carte di pagamento. Inoltre lo standard ISO suggerisce dei controlli che possono essere attivati o non attivati, giustificando opportunamente le scelte effettuate, mentre i requisiti della PCI DSS sono mandatori al fine di ottenere la conformità.

Per confermare quanto detto, riportiamo i risultati di una gap analysis relativa esclusivamente agli aspetti documentali, effettuata per un service provider con un SAQ compilato senza aver intrapreso un percorso specifico di conformità con il supporto di una QSA Company e un percorso di certificazione ISO/IEC 27001:2005 in corso.

 

Conformita requisiti fondamentali

Come è possibile vedere dal grafico, solo un quarto dei requisiti documentali è risultato pienamente conforme a quanto richiesto dalla PCI DSS (nonostante un SGSI attivo e un SAQ compilato). La maggior parte dei requisiti documentali non è pienamente aderente allo standard, mentre una parte significativa di aspetti documentali non è per nulla stata considerata.

Questo gap piuttosto rilevante è stato probabilmente conseguenza diretta di una cattiva interpretazione della norma e da un falso senso di sicurezza dovuto all’errata convinzione che il mondo ISO 27001 e quello PCI viaggino parallelamente. Per quanto i due standard abbiano alcuni aspetti in comune, i percorsi per il raggiungimento della certificazione / conformità sono estremamente differenti. In prima istanza la scelta di certificare un SGSI è volontaria, mentre la PCI DSS coinvolge in modo diretto “persone, processi e tecnologia che memorizzano, elaborano o trasmettono dati dei titolari di carta e/o dati sensibili di autenticazione”. Altro aspetto molto importante che distingue i due standard è quello relativo al perimetro: nel caso ISO il perimetro è a scelta ed è inerente a specifici processi, nel caso della PCI DSS, il perimetro coinvolte TUTTI i processi aziendali che coinvolgono le carte di pagamento e tutto ciò che ad essi è collegato. Per questo motivo un service provider non può decidere di effettuare il percorso di conformità per un particolare processo di gestione delle carte di pagamento, tralasciandone altri, in quanto la PCI DSS non permette questa suddivisione.

Ritornando ai falsi miti che coinvolgono la redazione della documentazione un’altra credenza  comune è la seguente: “Faccio parte di un gruppo multinazionale che gestisce dati delle carte di pagamento, la documentazione è redatta dalla capogruppo, non sta a me gestire gli aspetti documentali”. Anche questa affermazione, se analizzata rispetto a quanto definito nella PCI DSS, si rivela fortemente errata. In primo luogo, anche in caso di società afferenti allo stesso gruppo (ma con ragioni sociali differenti), la documentazione deve essere customizzata per ogni realtà specifica. Si pensi ad esempio alla procedura di reazione agli incidenti: non è pensabile definire world wide un unico documento che definisce ruoli, responsabilità e scenari d’incidente. Un altro problema inerente alla gestione della documentazione a livello corporate è quello relativo alla lingua: molto spesso infatti le politiche e procedure sono scritte nella lingua del luogo in cui la casa madre risiede. Non sempre TUTTO il personale delle aziende del gruppo, situate in altri Paesi, ha una piena conoscenza della lingua della capogruppo. Questo comporta il rischio che il personale non riesca a comprendere bene quali siano le pratiche da attuare per proteggere i dati delle carte di pagamento. Per questo motivo è necessario che ogni società, filiale osito abbia delle procedure costruite in funzione della realtà specifica.

 

PCI DSS – Attività periodiche

 

In precedenza sottolineavamo che per essere conformi alla PCI DSS non è sufficiente la compilazione annuale del SAQ e l’effettuazione delle verifiche ASV. Tra le tante attività periodiche previste, una è proprio quella relativa all’aggiornamento, con cadenza almeno annuale, di tutta la documentazione.

PCI DSS

Andando ad esplorare con attenzione la PCI DSS si rileva che un’altra delle attività molto spesso sottovalutate è quella inerente la formazione specifica del personale rispetto alle tematiche della gestione delle carte di pagamento così come richiesto dal requisito 12.6.1 “Formare il personale al momento dell'assunzione e almeno una volta all'anno”.

 

Altra attività annuale richiesta dalla PCI DSS è quella relativa allo svolgimento di un IT Risk Assessment del perimetro delle carte di pagamento. In questo caso specifico la PCI DSS si sovrappone ai requisiti dello standard ISO/IEC 27001:2005 in quanto il risk management effettuato su un SGSI può essere valido per assolvere il requisito PCI DSS, a condizione che all’interno del SGSI siano compresi tutti i flussi inerenti la gestione delle carte di pagamento.

Descrivendo la granularità con cui i documenti devono essere sviluppati facevamo l’esempio della procedura di reazione agli incidenti. Anche in questo caso la PCI DSS richiede una attività specifica: è infatti previsto che tutti i soggetti coinvolti dallo standard effettuino, con cadenza almeno annuale, un test del piano di risposta agli incidenti. I risultati dei test devono essere adeguatamente documentati e il piano costantemente aggiornato (come tutta la documentazione, come già precedentemente evidenziato).

 

Anche le attività periodiche relative alle verifiche tecnologiche non si limitano alle sole scansioni esterne ASV. La PCI DSS infatti richiede che con cadenza trimestrale venga eseguito un vulnerability assessment della rete interna attraverso l’ausilio di strumenti di rilevazione delle vulnerabilità semiautomatici, e almeno annualmente venga effettuato, da personale non direttamente coinvolto nella gestione dei sistemi delle carte di pagamento, un penetration test sia dalla rete interna che dalla rete esterna. Sempre trimestralmente, lo standard prevede inoltre che venga effettuato un test per verificare la presenza di reti wireless non autorizzate. In merito a questo requisito specifico sorgono sovente alcuni dubbi, in quanto si pensa che se non ci sono dati delle carte di pagamento che transitano su sistemi wireless il requisito risulti non applicabile. Andando però a leggere con attenzione quanto disposto dalla PCI DSS si evince che in nessun caso questo requisito può essere definito non applicabile in quanto si richiede che trimestralmente venga verificata la presenza di access point non autorizzati e non si fa riferimento in nessun modo alla tipologia di informazione che vi transitano o alle reti a cui l’access point è collegato.

 

Altra attività piuttosto onerosa e molte volte sottovalutata è la verifica degli outsourcer e dei fornitori che deve essere effettuata con cadenza almeno annuale. In pratica il Merchant / Service Provider deve verificare il rispetto dei requisiti della PCI DSS da parte degli outsourcer e dei fornitori con cui condivide dati, sistemi e linee di connettività su cui transitano, vengono elaborati o memorizzati dati delle carte di pagamento.

È possibile assolvere a questo requisito in un duplice modo: chiedendo annualmente l’AoC (Attestation of Compliance) oppure effettuando un audit al fine di verificare che il fornitore / outsourcer rispetti i requisiti della PCI DSS.

Come ampiamente evidenziato nel presente articolo, oltre a tutte le attività di tipo tecnologico è necessario assolvere a molti aspetti organizzativi / documentali per essere conformi allo standard PCI DSS.

Per arrivare quindi alla compilazione annuale del SAQ è necessario, oltre ad attuare tutti i controlli tecnologici e di gestione dei sistemi IT, assolvere alle attività periodiche tecnico/organizzative previste dallo standard (riassunte nella tabella 1). Solo a quel punto sarà possibile compilare il SAQ dichiarando, in maniera giustificata, la propria conformità rispetto alla PCI DSS; in caso contrario si effettua una autodichiarazione non in linea con i requisiti dello standard.

 

PCI DSS doh

È quindi necessario prestare massima attenzione a ciò che si dichiara, le attività di verifica da parte del PCI Council sono in costante aumento, multe ed esclusioni dal circuito sono in agguato… facendo sempre ben attenzione a non superare i limiti di transazioni (in termini di numerosità) fissati dai Brand per essere definiti Service Provider o Merchant di livello 1!... In quel caso non è più sufficiente l’autodichiarazione fatta con il SAQ ma è necessario un audit ispettivo annuale da parte di una QSA Company per la certificazione del perimetro delle carte di pagamento attraverso la compilazione del ROC (Report on Compliance).

 


Attività

Frequenza

Risk Analysis

annuale

Riesame della conformità degli outsourcer

annuale

Scansioni interne

trimestrale

Scansioni esterne ASV

trimestrale

Penetration Test, interni ed esterni

annuale

Verifica della presenza di reti wireless

trimestrale

Test del piano di risposta agli incidenti

annuale

Aggiornamento delle politiche e delle procedure

annuale

Formazione

annuale

Emissione SAQ / ROC

annuale

 
Tabella 1 - Attività periodiche PCI DSS

 



16/09/2013 - Paolo Sferlazza, Security Advisory Team @ Mediaservice.net