PCI-DSS e gli Standard di Sicurezza in ambito Monetica

L’obiettivo di questo articolo è quello di collocare PCI-DSS nell’ambito più generale degli Standard di Sicurezza in ambito Monetica, evidenziando come il vero impatto sulle organizzazioni coinvolte sia in realtà una spinta verso una corretta gestione delle problematiche di compliance, e in genere verso un corretto posizionamento all’interno di scenari economici e politici in rapida evoluzione. L’articolo descrive inoltre brevemente le correlazioni tra i vari Standard esistenti e le loro possibili evoluzioni, nonchè l’attuale situazione del mercato italiano (in termini di punti di forza e punti di criticità) a quattro anni dall’introduzione di PCI-DSS.

Come è noto, il corpus tecnico di PCI-DSS è mantenuto dal PCI Security Stardards Council (PCI SSC).

“Il PCI Security Stardards Council è un forum mondiale aperto, nato a settembre 2006, che ha come obiettivo lo sviluppo continuo, il miglioramento, la conservazione, la distribuzione e l’implementazione degli standard di sicurezza per la protezione dei dati degli account.

La missione del PCI Security Standards Council è quella di innalzare la sicurezza dei dati relativi ai payment account, promuovendo la conoscenza degli Standard di Sicurezza PCI. L’organizzazione è stata fondata da American Express, Discover Financial Services, JCB International, MasterCard Worldwide, e Visa, Inc.”

Già questa definizione ufficiale evidenzia come l’oggetto sia un insieme di Standard, e non uno Standard unico. Attualmente gli Standard gestiti da PCI SSC sono:

· PCI-DSS (“Payment Card Industry Data Security Standard”)

· PA-DSS (“Payment Application Data Security Standard”)

· PCI EPP e PED (“Payment Card Industry Encrypting PIN Pad” e “POS PIN Entry Device”)

Tutti gli Standard sopra elencati sono passati da una precedente gestione separata da parte dei Card Brand (pricipalmente VISA e MasterCard) ad una gestione unificata sotto il PCI SSC. VISA mantiene a tutt’oggi la gestione di:

· PCI-PIN

il cui passaggio a PCI SSC è attuale oggetto di discussione.

Come detto, PCI SSC gestisce il corpus tecnico di questi Standard, ma non ha alcun coinvolgimento operativo nell’applicazione degli Standard stessi. Ciascun Card Brand mantiene a questo scopo un proprio programma operativo. Ad esempio, i programmi di applicazione di PCI-DSS da parte di VISA e di MasterCard si chiamano rispettivamente AIS (Account Information Security) e SDP (Site Data Protection). È nell’ambito di questi programmi che si attuano i meccanismi di introduzione (e di imposizione) dello Standard verso il mercato e si implementa la Catena di Responsabilità che ad esso è sottesa. A tal proposito, è importante evidenziare che le Banche Acquirer sono responsabili dei propri Service Provider, Merchant e Sviluppatori di Applicazioni nei confronti dei Card Brand, ai quali sono obbligati a fornire reportistica periodica circa lo stato di compliance di tutti i soggetti menzionati. Il mercato italiano comincia a mostrare i primi segni di introduzione di PCI-DSS all’interno dei contratti tra i soggetti coinvolti (per ribaltamento della responsabilità, gestione delle penali, diminuzione o aumento delle fee per transazione, requisiti applicativi ecc.).

La Figura seguente illustra schematicamente i soggetti coinvolti, i flussi fra essi, la presenza di contrattualistica influenzata dagli Standard qui descritti, e la catena di responsabilità PCI-DSS promossa dai Card Brand.


La Tabella seguente descrive sinteticamente gli Standard fino ad ora menzionati.


Altre importanti caratteristiche degli Standard elencati sono: · I Card Brand mantengono un sistema di Certificatori accreditati per PCI-DSS e PA-DSS, mentre le varie accezioni di PCI-PIN sono gestite direttamente da VISA, e spesso sono sottoposte ad Audit da parte di personale VISA.

· In particolare, PCI SSC e VISA gestiscono la certificazione dei device (EPP e PED) presso propri laboratori, mantenendo una lista pubblica dei device certificati.

· Le Banche Acquirer e Issuer hanno obbligo di compliance verso PCI-DSS, ma non di validation formale da parte di QSA e ASV, come invece accade per gli altri soggetti coinvolti.

A quattro anni dalla prima introduzione e implementazione di PCI-DSS in Italia, il mercato ritorna alcuni feed-back positivi ed evidenzia l’esistenza di alcuni punti non completamente compresi o ancora di difficile implementazione:

· A differenza di altre Certificazioni (del presente e del passato), PCI-DSS è recepito, applicato, controllato e… forzato.

· PCI-DSS traina le altre problematiche di Monetica, altrimenti sconosciute o neglette.

· Ne viene percepito il valore aggiunto, e non solo l’obbligo.

· La percezione del ROI è molto più immediata rispetto alle consuete problematiche di Sicurezza ICT (penali, fee per transazione ecc.).

· PCI-DSS spinge a utili azioni di segmentazione e segregazione.

· Il focus sulla protezione dei dati collima con quanto accade nel mercato e nella Sicurezza ICT.

· PCI-DSS e i suoi Controlli sono formalmente molto ben definiti (idem per PCI-PIN), e quindi si prestano bene a:

o definizione e utilizzo di metriche

o link formale con gi Statement delle proprie Security Policy

o gestione check-list, post-elaborazioni, automatizzazioni, integrazione con sistemi di IT Management di vario tipo, ecc.

· PCI-DSS è uno Standard “misto” (tecnologico e di processo), e si presta bene ad essere una Linea Guida anche in altri ambiti.

· Spesso lo stesso glossario di base è poco conosciuto, anche in ambito bancario (Acquirer, Issuer, ecc.).

· Le banche spesso ritengono di non avere alcun obbligo e/o coinvolgimento, mentre (come detto sopra) hanno obbligo di compliance, anche se non di validation formale.

· Le Banche Acquirer sono lente nell’implementare PCI-DSS verso i soggetti dei quali sarebbero responsabili.

· Non sono comprese le differenze tra PCI-DSS e PA-DSS, e le implicazioni semplificative di PA-DSS in una Certificazione PCI-DSS.

· Non sono comprese le differenze tra PCI-DSS e le varie accezioni di PCI-PIN.

· Non sono chiare le correlazioni con i Programmi AIS (VISA) e SDP (MasterCard), o essi sono sconosciuti.

· Non sono chiare le correlazioni con le Specifiche ABI-CoGeBan (SPE-DEF).

· È spesso difficoltosa le definizione dello Scope in presenza di entità (non chiaramente) esterne (OutSourcer, Fornitori, Centri Servizi, Carrier, ecc.)

· Non sono chiare le implicazioni verso la Contrattualistica coinvolta (vedi Figura precedente). A questo proposito pesa non poco la sostanziale diversità del sistema giuridico italiano nei confronti di quelli anglosassoni. Questi ultimi privilegiano in ogni caso il contratto, rendendo molto più pressante e significativa l’adozione di novità quali PCI-DSS, mentre in Italia viene comunque privilegiato il Codice Civile.

· In soggetti di una certa dimensione sono quasi sempre critiche problematiche quali la varietà degli interlocutori interni e la mappatura vero i processi interni.

· L’assenza di un sistema di certificatori accreditati per PCI-PIN mette in secondo piano questo Standard.

· Non sono chiare le correlazioni con SEPA e EMV.

· Non sono chiare le correlazioni con ISO17799/27001.

Molti dei punti qui sopra elencati sono stati brevemente coperti in precedenza. Per quanto riguarda le correlazioni con EMV:

· EMV (gestito e mantenuto da EMVco) è uno Standard mirato alle cosiddette Integrated Circuit (IC) Card, alla loro interoperabilità e all’interoperabilità di POS e ATM IC-capable.

· PCI-PIN richiede esplicitamente che: “All cardholder PINs processed offline using IC Card technology must be protected in accordance with the requirements in Book 2 of the EMV IC Card Specifications for Payment Systems”. Si veda: “Payment Card Industry: PIN Security Requirements - Version 2.0 - January 2008”.

· PCI PED e EMV sono attualmente Standard separati, come pure lo sono i relativi meccanismi di certificazione. Come si legge in “PIN Entry Device Security Requirements: Frequently Asked Questions”: “PCI SSC recommends that, if applicable, the PED receive EMV Level 1 approval first. Then the vendor should apply for PCI PED approval. EMV Level 2 testing, if applicable, should occur next”.

Per quanto riguarda le correlazioni con SEPA:

· SEPA (Single Euro Payments Area, promossa dall’European Payment Council o EPC) mira ad essere l’area dove cittadini, aziende e altre entità economico-finanziarie opereranno e riceveranno pagamenti in Euro sotto le medesime condizioni, siano essi all’interno dei confini nazionali come tra diverse nazioni dell’area stessa. Sul lungo termine, gli strumenti di pagamento unificati SEPA mirano a rimpiazzare i sistemi di pagamento in Euro (attualmente in essere) di ciascuna nazione dell’area. SEPA si concentra su:

o SEPA Credit Transfer

o SEPA Direct Debit

o SEPA for Cards

· Lo scopo dichiarato nella creazione di “SEPA for Cards” è quello di consentire ai Clienti Europei (Card Holder e Merchant) l’impiego di Carte general-purpose per operare e ricevere pagamenti e per prelevare contante in Euro all’interno dell’area con la stessa facilità e convenienza di quanto consentito nelle loro nazioni di origine.

· I Requisiti di Sicurezza per SEPA sono in corso di pubblicazione. PCI-DSS per ora non viene menzionato. “SEPA CARDS STANDARDISATION VOLUME - Version 3.2 - March 2009 – Chapter 5 Security Requirements” fa riferimento a PCI-PED 2.0 nell’ambito dei Requisiti di Sicurezza di base di un POI (Point of Interaction, una generalizzazione di POS, ATM ecc.), ma aggiunge ulteriori Requisiti di Sicurezza denominati “EPC Plus Requirement”. L’unione di entrambi gli insiemi di Requisiti formerà i cosiddetti “EPC Security Requirements”.

· Il riferimento per la valutazione delle Applicazioni sulle IC Cards sembra essere ISO15408 (Common Criteria). Si veda lo stesso documento citato al punto precedente.

· PCI SSC e EPC stanno dialogando a proposito della futura (sperabile) convergenza tra i due mondi.

Per quanto riguarda infine le correlazioni con ISO17799/27001, l’esperienza derivata dall’introduzione degli Standard PCI nei sistemi di gestione della sicurezza aziendale indica come sconsigliabile il tentativo di integrazione dei due mondi. D’altro canto è subito evidente come ISO17799/27001 sia per sua natura un modello quality-like di Gestione dei Processi di Sicurezza ICT del tutto generale, e che anzi il punto di contatto ovvio sia il Requisito 15 (“Compliance”). Ciò suggerisce una gestione “ortogonale” delle problematiche di compliance legate alla Monetica. La Figura illustra schematicamente un ipotetico scenario in cui vi sia una gestione “a cruscotto” della compliance verso i vari Requisiti ISO17799/27001, qui rappresentata per semplicità dalle barre verticali. In questo ambito ISO, la possibile metrica di interesse per quanto riguarda gli Standard assegnati al Requisito 15 è quella relativa allo stato generale di compliance. Gli Standard stessi saranno poi gestiti in maniera autonoma (ancorchè efficiente rispetto ad altre attività simili, ove possibile) per quanto riguarda i loro singoli Controlli e (soprattutto) per quanto riguarda gli Audit da parte degli enti competenti.

In conclusione, appare evidente come PCI-DSS sia forse attualmente l’elemento più visibile e più trainante in un vasto e complesso insieme di Standard di Sicurezza nel mercato della Monetica, a cui vanno aggiunti anche gli altri Standard esistenti (ad esempio ISO17799/27001 e ISO15408) e gli altri possibili riferimenti normativi (ad esempio il D.Lgs. 196/2003 per l’Italia). Il mercato della Monetica è di grande importanza economica e politica, ed è in forte espansione sotto spinte di tipologie e provenienze molto diverse (si pensi ad esempio a SEPA oppure all’integrazione delle modalità di Pagamento Elettronico con i mondi Triple Play / Quadruple Play). Esso ha la forza di imporre i propri Standard per l’innalzamento dei livelli di Sicurezza, rendendo quindi ancora più importanti le problematiche di gestione della compliance all’interno dei soggetti coinvolti e delle aziende in genere.