La definizione da ultimo ricordata, (vale a dire quella di misura minima di sicurezza) facendo riferimento non solo all’elemento tecnologico, in senso stretto, ma, implicando anche, la valutazione di misure organizzative e procedurali,
rinvia ad una nozione ampia di sicurezza, nel senso che, evidenzia, la necessità di pensare (ed agire in merito) alla sicurezza dei dati personali, in termini architetturali, quale esito di un processo continuo di verifica, rimedio e monitoraggio (assess, remediate, report).Per le finalità che qui ci occupano, nell’ottica, ora, di determinare la sovrapponibilità (equipollenza) delle prescrizioni contenute in PCI-DSS, con le previsioni specifiche in materia di misure (anche minime) di sicurezza, previste dal codice in materia dei dati personali e dall’allegato B di detto codice, occorre prendere cognizione piena, per quanto possibile, in questa sede, con il contenuto specifico dello standard di sicurezza in questione.
A scanso di equivoci, è necessaria una precisazione, come anticipato, l’efficacia (i.e. la vincolatività) di PCI, per sua stessa origine, differisce profondamente da quella del Codice in materia di protezione dei dati personali, dato che, il primo è, come sopra ricordato, uno standard internazionale, convenzionale, contrattualmente imposto, tramite previsioni specifiche rese obbligatorie nei vari accordi di disciplina della catena delle responsabilità (fino al più piccolo dei Merchant) dai BRAND che gestiscono il circuito dei pagamenti con carte di credito/debito a tutti coloro che “processano” dati relativi a titolari di carte di credito/debito, il secondo, invece è atto legislativo dello Stato, come tale (in teoria) generale ed astratto, i cui precetti sono assistiti da sanzioni anche penali e la cui osservanza e sostanzialmente imposta dall’autorità.
Si noti, tuttavia, che PCI – DSS, naturalmente, lungi dall’essere uno standard chiuso, nel senso di essere insensibile, al progresso tecnico e tecnologico, ed anzi, recentemente, nel mese di febbraio, (con efficacia rilevante, secondo chi scrive, con riferimento al parametro corrispondente di cui al citato art. 31 del Codice Privacy italiano) sono stati divulgati due ulteriori documenti, molto utili, relativi a temi altrettanto attuali nello scenario tecnologico presente, indissolubilmente legati con le questioni derivanti, più in generale dalle corrispondenti operazioni di trattamento di dati personali, quali quelli del Mobile Payment (M- Payment) e del Cloud Computing, si tratta, dei documenti: “Mobile Payment Acceptance Security Guidelines for Merchant, V 1.0” e “PCI DSS 2.0 Cloud Computing Guidelines”.
Ciò detto, prima di intrattenerci, più approfonditamente, sull’applicabilità delle disposizioni contenute nello standard (tipologie e classificazione dei destinatari delle prescrizioni), conviene osservare che PCI-DSS e’, in realtà, costituito da un insieme di standard, che possono essere presi in considerazione, sia dal punto di vista delle tecnologie impiegate per l’effettuazione di transazioni elettroniche (EDI, Electronic Data Interchange), destinate ad assolvere funzioni di pagamento, sia dal punto di vista della individuazione dei soggetti (in alcuni casi quelli e solo quelli) abilitati a svolgere specifiche operazioni di verifica – secondo procedure determinate e formali – utili a “certificare” in circostanze, invero non infrequenti, l’aderenza di una entità, soggetta allo standard, alle previsioni dello standard medesimo.
Rilevano, sotto il primo profilo, quello afferente alla determinazione dei livelli di sicurezza da applicare, alle tecnologie impiegate nelle operazioni di pagamento, lo standard specifico realizzato per certificare, per esempio, la sicurezza delle applicazioni software impiegate nelle transazioni effettuate con carta di credito/debito, denominato PA-DSS (Payment Application Data Security Standard), nonché quello dedicato, alla certificazione dei c.d. POI (Point of Interaction) che prende il nome di PTS (Pin Transaction Security – “a set of modular evaluation requirements managed for PIN acceptance POI terminal”).
Sotto il secondo profilo, vale a dire quello della individuazione e della certificazione delle competenze di determinati soggetti, abilitati a svolgere specifiche funzioni di valutazione e certificazione dei requisiti (Requirements) di volta in volta richiesti dallo standard, sono da considerare, invece, le figure del QSA (Qualified Security Assessor), dell’ASV (Approved Scanning Vendor), dell’ISA (Internal Security Assessor) e del PFI (PCI – DSS Forensics Investigator) ed i relativi documenti di riferimento: vale a dire, rispettivamente, il documento “Validation Requirements for the Qualified Security Assessor”, il documento “Validation Requirements for Approved Scanning Vendor”, il documento “Validation Requirements for Internal Security Assessor”, ed infine, ma non per ultimo, il documento “PCI Forensics Investigator Program Guide”.
Quest’ultima figura, il PCI Forensic Investigator, riveste particolare importanza, in considerazione del fatto che, come nel seguito sarà specificato, e’ l’unica, in determinati casi, abilitata dallo standard (ai sensi dello standard) ad effettuare operazioni di investigazione digitale in caso di “data breach”.
Rilevano in questo specifico ambito, le definizioni di Compromised Entity, cioè “A merchant, service provider, financial institution, or other entity that: (a) processes, stores or transmits Cardholder Data; ((b) is required to comply with any PCI Standard; and (c) is, at the tme in question, required pursuant to Industry Rules to undergo a PFI Investigation of a specific Security Issue”, di, Security Issue, cioè “An actual or suspected compromise or other incident that, pursuant to applicable Industry Rules, require Forensic Investigation by a PFI” e, di PFI Investigation, cioè, “The forensic investigation of a Security Issue for a Compromised Entity pursuant to applicable Industry Rules”.
In buona sostanza, in alcune ipotesi contrattualmente determinate, in conseguenza di una violazione della sicurezza di una entità che deve ottemperare le prescrizioni dello standard, lo standard medesimo riconosce solo ad alcuni soggetti, i PFI, appunto, la capacità di svolgere attività di investigazione digitale che abbia una qualche rilevanza ai fini delle determinazione delle responsabilità e dell’applicazione delle sanzioni, pure previste, sotto forma di penali, come detto, dagli ISSUER che compongono i BRAND che hanno costituito lo standard.
Considerata la rilevanza strategica delle operazioni di investigazione digitale, effettuate in conseguenza di un “data breach” da questi soggetti, oltre a requisiti di imparzialità, lo standard prevede, da un lato, la sussistenza di livelli di professionalità e di preparazione particolarmente stringenti (testualmente: each individual who performs, manages or is otherwise involved in any technical aspect of any PFI investigation must meet all of the following requirements – active incident response certification, such sa SANs GIAC Certified Incident Handler (GCIH), GIAC Certified Forensics Analyst (GCFA), or equivalent certification satisfactory to the approving organization; or a minimum three years of Forensic investigation/incident handling experience”), e dall’altro, l’effettuazione di attività di indagine specificamente individuate (sia dal punto di vista strettamente tecnologico, sia dal punto di vista della formalizzazione dei risultati ottenuti in seguito all’esperimento delle procedure necessarie).
Naturalmente, la conformità con PCI DSS, che solo in alcuni casi determinati, può’ essere “autocertificata” direttamente dall’entita’ che effettua operazioni con carte di credito/debito, attraverso la sua organizzazione (uomini e mezzi), implica il fedele (e costante) rispetto dei requisiti da esso previsti per garantire la sicurezza delle transazioni effettuate.
Ne sono previsti, allo stato, ulteriormente declinati, sin negli specifici dettagli, sei; segnatamente: (a). Sviluppo e gestione di una rete sicura; (b). Protezione dei dati di titolari di carta; (c). Utilizzo di un programma per la gestione delle vulnerabilità; (d). Implementazione di rigide misure di controllo dell’accesso; (e). Monitoraggio e test delle reti regolari; (f). Gestione di un’analisi a di sicurezza delle informazioni.
Già ad una prima sommaria verifica comparativa dei contenuti di PCI, con le norme in materia di sicurezza da attuare durante le operazioni di trattamento di dati personali, di cui al menzionato Codice Privacy ed al relativo allegato B, non può che constatarsi un differente approccio metodologico che, se pure appare giustificato, sul piano della tecnica di redazione, con riferimento ai contenuti dell’art. 31 del Codice Privacy – posto che detta norma riveste un ruolo non espressamente percettivo specifico, avendo inteso il legislatore con essa, fornire un canone generale, cui deve ispirarsi l’attività del titolare del trattamento – tradisce, mai come in questo periodo (in conseguenza della abolizione delle regole da 19.3 a 19.8 dell’allegato B al Codice nonché della lettera g) dell’art.34 in materia di usure minime), una certa superficiale disaffezione del legislatore nei confronti di una materia, l’informatica, che, a parere di chi scrive, necessita, all’atto della sua disciplina, di essere “spiegata in dettaglio”, anche all’interprete per non rimanere lettera morta o, peggio ancora, trasformare i processi ad essa riferiti in processi puramente e semplicemente di periti.
Volendo comunque tentare una sovrapposizione dei due contenuti, seguiremo, in ossequio alla importanza della fonte, nella prossima parte, l’ordine di cui all’art 34 del Codice in materia di protezione dei dati personali.