PCI DSS (Fonte I Love heart Studio)
Confesso che ogni anno all’avvicinarsi della data dell’audit PCI DSS avverto un senso di ansia insieme con la mancanza di sicurezza circa la corretta esecuzione di tutte le attività richieste durante l’anno.
Innanzi tutto, sgombriamo il campo dalla falsa idea che gli audit siano tutti uguali. Non è così e, il solo fatto che l’audit PCI DSS duri minimo una settimana con incontri “face to face” con l’obbligo di fornire evidenze dei controlli mensili, trimestrali, semestrali e annuali eseguiti, dovrebbe farvi capire la differenza.
Per i non addetti ai lavori, la specifica PCI DSS ora arrivata alla release 3.2, rappresenta lo standard a cui tutte le aziende devono attenersi per poter trattare i dati relativi a transazioni di pagamento da parte dei clienti mediante carte di credito.
Il PCI Security Council (nel seguito PCI-SSC https://www.pcisecuritystandards.org/) è l’ente responsabile degli standard di protezione PCI e si occupa di sviluppo, gestione, informazione e diffusione degli standard di protezione PCI, non solo per la protezione dei dati (PCI DSS) ma anche per la protezione dei dati per le applicazioni di pagamento (PA-DSS) e per la sicurezza delle transazioni PIN (PTS).
I cinque membri fondatori (American Express, Discover Financial Services, JCB International, MasterCard e Visa) riconoscono la validità per la conformità a PCI DSS dei QSA e degli ASV certificati dall’Ente responsabile degli standard di protezione PCI.
Quindi per la certificazione entrano in gioco due tipi di società esterne:
– Qualified Security Assessor Company (QSAC) https://it.pcisecuritystandards.org/assessors_and_solutions/qualified_security_assessors
– Approved Scanning Vendor (ASV) https://www.pcisecuritystandards.org/assessors_and_solutions/approved_scanning_vendors
Le QSAC sono aziende che hanno deciso di operare nell’ambito della PCI-DSS e di certificare membri del proprio staff al fine di poter offrire il servizio di analisi di conformità e di certificazione ai Merchant, ai Service Provider e anche ad Acquirer ed Issuer.
Tutti gli IP esterni delle aziende soggette a PCI devono essere analizzati trimestralmente al fine di determinare la loro conformità ai livelli i sicurezza minimi richiesti dal PCI SSC. A tale scopo esistono delle aziende che vengono identificate come Approved Scanning Vendor (ASV).
Non mi sono mai certificato auditor o lead auditor per cui vi darò la visione del “controllato” e non del “controllore”. Il fatto che sia un evento importante si capisce dal numero di riunione organizzate durante l’anno con i vari risk manager presenti in azienda, con la sicurezza, il finance e le linee di business.
Relativamente alla rigorosità del framework nulla da eccepire; la salvaguardia dei dati relativi alla carta di credito è ottenuta mediante una checklist di circa 300 controlli suddivisi in 12 requisiti e molti dei quali da eseguire a cadenza prefissata (ad esempio penetration test ogni anno o scan esterni ogni tre mesi); tutti i controlli non applicabili devono essere giustificati e, spesso, si deve ricorrere all’implementazione di compensating control per sopperire ad eventuali carenze. Gli obblighi contrattuali con i service provider sono regolamentati in modo chiaro con precise assunzioni di responsabilità che ogni anno vanno rinnovate mediante un SAQ (Self Assessement Questionnaire).
Non voglio in questa sede entrare nel merito dei singoli controlli perché c’è molta letteratura su internet che potrebbe aiutarvi in tal senso. A tal proposito ho trovato molto utile il quaderno del CLUSIT http://www.clusit.it/download/Q08_ter.pdf .
Tuttavia vorrei fornire qualche spunto di riflessione per far capire che c’è ancora qualcosa da migliorare.
Sono quindi dell’idea che si potrebbe e si dovrebbe fare di meglio. Vediamo nel dettaglio su quale punti il PCI-SSC dovrebbe intervenire, a mio modestissimo parere, per rendere il framework più sicuro.
Supponete che vogliate gestire i servizi IT della vostra azienda mediante un forte ricorso all’outsourcing o al business sourcing. Ad esempio mediante l’outsourcing del servizio di call center, dei servizi IT di Application Support e di Gestione dei sistemi e magari con i vostri server in hosting presso un provider infrastrutturale. Oltretutto con i servizi di pagamento e di reperimento clienti gestiti mediante agenzie.
In questo scenario il QSA vi chiederà i vari SAQ firmati oltre al vostro SAQ-D (quello relativo al merchant) eseguirà un’analisi di copertura per verificare che tutti i controlli siano implementati o da voi o dai service provider.
Chiaramente i controlli relativi alle policy o alle procedure saranno sempre di vostra responsabilità ma gran parte dei controlli rimanenti non verrebbero mai verificati dal QSA che assume come vera l’autocertificazione dei service provider.
Quindi ad esempio tutti i controlli relativi alla sicurezza fisica (requisito numero 9) non saranno mai sottoposti ad audit perché non siete voi i gestori del datacenter e perché avete provveduto a trasferire la responsabilità all’outsourcer mediate opportune clausole contrattuali.
In questo contesto, credo che una qualche forma di garanzia ulteriore verso i service provider debba essere inserita. Magari un audit di seconda parte oppure una raccolta evidenze insieme al questionario SAQ di autovalutazione oppure aumentare lo scope dell’audit del QSA selezionado alcuni controlli dei service provider.
C’è un altro punto che non mi convince: la definizione dello scope da mettere sotto audit. Diciamo subito che la definizione dello scope è a carico dell’organizzazione e non del QSA. Se all’inizio dell’audit si dice al QSA di avere un solo server in scope questi si limiterà a verificare che sul server dichiarato siano stati eseguiti tutti i controlli necessari durante l’anno e che tutte le contromisure di sicurezza siano implementate alla data dell’audit.
Solo come esempio ricordo che su ogni asset inserito nello scope occorre implementare delle contromisure di sicurezza (antivirus, logs, file integrity monitor etc etc) ed eseguire dei controlli periodici durante l’anno (vulnerability assessment, penetration test, user review etc etc).
Non me ne voglia il PCI-SSC ma non credo che questo debba essere il giusto approccio. Io credo che il QSA debba imporre uno scope e non lasciare all’organizzazione questa scelta. Non importa come (ad esempio mediante un pre-audit oppure mediante una raccomandazione per l’anno successivo) ma questo deve essere un compito del QSA.
L’ azienda è un’organizzazione costituita da persone e beni che, attraverso una serie coordianata di operazioni, mira al conseguimento di un determinato fine economico o ad assicurare un servizio. Ad oggi il senior management non ha ancora capito che i requisiti di compliance stanno crescendo di anno in anno e che non è possibile fare fronte a questo effort aggiuntivo mantenendo invariati i costi ricorreneti o addirittura diminuendoli.
Le strutture di operation IT con cui spesso s’interfaccia il QSA sono il più delle volte strutture sottodimensionate, complesse e sotto stress dove la compliance è vista come una scocciatura che si inserisce in un calendario già riempito da obiettivi di business legati al suddetto conseguimento del fine economico. Queste strutture forniranno sempre lo scope minimo per limitare l’impatto sulle loro attività lavorative.
Una volta consegnato il data-flow al QSA questi dovrebbe imporre che tutti gli asset attraversati dal flusso dati debbano essere inclusi nello scope (firewall, router, personal computer, VPN, server di front end e di backend).
Aggiungo a quanto sopra le mie perplessità sulle modalità con cui viene controllato il penetration test. Diciamo subito che nelle multinazionali il penetration test non può essere fatto da chiunque ma solo da un team specializzato e che la qualità del penetration test non è sempre la stessa ma dipende dall’analista che viene coinvolto. Ho visto dei penetration test che erano in realtà dei vulnerability assessment e che avevano del penetration test solo il titolo. Il QSA non ha battuto ciglio e si è limitato a leggere le conclusioni.
E’ ora che il PCI-SSC imponga uno standard per il penetration test. In presenza di vulnerabilità si deve provare a sfruttarle per accedere al sistema, tuttavia vanno fatti altri tentativi di accesso ad esempio mediante “brute force” sulle utenze o mediante exploit di vulnerabilità applicative (i.e. sql injection o cross site scripting). Oltretutto il QSA deve verificare che tutti i passi siano stati eseguiti e non limitarsi a leggere le conclusioni. Non sono un esperto di penetration test ma avendone visto uno ben fatto mi limito ad osservare che c’è una scarsa consapevolezza tra gli addetti ai lavori su cosa sia un penetration test e quali siano i passi da eseguire per far si che il penetration test possa essere considerato completo.
Per chiudere un considerazione generale su questi framework complessi ed in generale sugli audit di terza parte (condotti da organizzazioni specializzate che al termine rilasciano un apposito certificato di conformità).
Credo che quando si chiede am auditor di verificare centinaia di controlli con crca 200 evidenze documentative non si stia limitando il rischio frodi ma si stia mettendo in difficoltà un auditor che, per quanto preparato non può tecnicamente entrare nel merito su tutto.
A quanto sopra aggiungiamo che, per la PCI DSS, il mancato adeguamento da parte degli esercenti a tutte le disposizioni dei circuiti internazionali comporta la revoca della convenzione di esercenti già convenzionati e l’addebito di eventuali multe imposte dai circuiti.
Il combinato disposto dei due paragrafi precedenti è che, a meno che non ci presenti all’audit da incoscienti con macchine aventi hardware, sistema operativo e database fuori supporto, senza patch e senza VA e e PT eseguiti, una soluzione verso la certificazione la si trovi magari con i compensating control e con una piano di implementazione.
A me sembra evidente che, se l’obiettivo da perseguire è la riduzione dei rischi IT ad un livello accettabile, serva un’inversione di tendenza cominciando a dare meno peso alle evidenze documentative (policy, procedure e standard) dando all’auditor un più ampio margine di manovra al fine di fare delle verifiche in loco sui sistemi per constatare la reale implementazione delle contromisure di sicurezza.
