licenza http://creativecommons.org/licenses/by-nc/2.5/it; versione online[1] su www.compliance.normativa.it ; data di pubblicazione: 19 novembre 2010

Abstract

Il 24 settembre 2010 la Banca d’Italia ha pubblicato il documento “Consultazione pubblica sulle disposizioni attuative del d.lgs. 11/2010 in materia di servizi di pagamento”[2] http://www.bancaditalia.it/media/notizie/tit_II-DL-n-11 che riguarda l’attuazione della direttiva 2007/64/CE relativa ai servizi di pagamento per il mercato interno.

Riteniamo utile approfondire, tra i diversi aspetti presi in esame dal documento, quelli di sicurezza ed efficienza dei sistemi di pagamento.

Tali aspetti non dipendono solo dal comportamento diligente delle parti (prestatori ed utilizzatori) coinvolte in un contratto di tale natura, ma anche dal corretto funzionamento delle piattaforme tecniche, delle procedure e delle regole interne al sistema dei pagamenti su cui le autorità di vigilanza svolgono la propria azione di controllo.

Risulta inoltre fondamentale, per il prestatore del servizio, l’adozione di un “processo di gestione dei rischi” coerente e completo.

Nell’articolo riassumiamo i contenuti principali del documento in consultazione e proponiamo un approccio operativo basato sulla metodologia Risk IT http://www.isaca.org/Knowledge-Center/Risk-IT-IT-Risk-Management/Pages/Risk-IT1.aspx / COBIT di ISACA, framework che può essere utilizzato dalle società impegnate nella prestazione dei servizi di pagamento.

Parole chiave:Servizi di pagamento, risk assessment, Risk IT, COBIT, vulnerability assessment, penetration test, PCI-DSS

I prestatori

Cominciamo col dire che sono definiti “Prestatori di servizio di pagamento (PSP)”:

• banche, istituti di moneta elettronica, istituti di pagamento, Poste Italiane S.p.A,
• Banca Centrale Europea e banche centrali nazionali qualora non agiscano in veste di autorità monetarie e prestino servizi di pagamento in Italia,
• qualsiasi altra amministrazione statale, regionale e locale che offra servizi di pagamento non agendo in veste di autorità pubblica.

Le misure di sicurezza richieste ai prestatori

Al fine di garantire in ogni momento il regolare funzionamento del sistema dei pagamenti nonché la fiducia degli utilizzatori nel ricorso ai servizi compresi nell’ambito di applicazione del “Decreto”, i prestatori di servizi di pagamento devono assicurare che le soluzioni tecniche adottate per l’esercizio dell’attività siano presidiate da adeguati processi di gestione dei rischi associati alle tecnologie utilizzate; tra i rischi preventivamente individuati Banca d’Italia indica:

• malfunzionamenti nei sistemi e nei processi informatizzati interni;
• difetti delle procedure software e dei sistemi operativi;
• guasti dei componenti hardware;
• limitata capacità dei sistemi di elaborazione e trasmissione;
• vulnerabilità delle reti di telecomunicazione;
• debolezza del sistema dei controlli e delle misure di sicurezza;
• sabotaggi;
• attacchi da parte di soggetti esterni;
• tentativi di frode.

A tal fine i prestatori di servizi di pagamento si devono dotare di un adeguato e robusto processo di gestione dei rischi che permetta di identificare, valutare, misurare, monitorare e mitigare le minacce di natura tecnologica. Con l’obiettivo di mitigare i rischi individuati, tale processo deve identificare e/o predisporre un insieme di misure di sicurezza e di controlli appropriati, in grado di assicurare gli obiettivi di confidenzialità, integrità e disponibilità dei sistemi informativi e dei dati ad essi associati.

Il documento richiede esplicitamente che i vertici aziendali rafforzino i meccanismi di gestione e mitigazione del rischio attraverso la definizione di:

1. un adeguato insieme di presidi di sicurezza logica e fisica per i sistemi informativi;
2. un efficace processo di controllo interno;
3. un appropriato piano di continuità operativa;
4. una gestione dei rapporti contrattuali con i fornitori esterni coerente con i vincoli posti a carico dei prestatori di servizi di pagamento.

Il processo di gestione e mitigazione del rischio deve prevede infine l’esecuzione di fasi di verifica teoria e pratica della vulnerabilità dei presidi di sicurezza con relativa revisione periodica del processo stesso attraverso i cosiddetti “vulnerability assessment” e “penetration test”.

“I vertici aziendali assicurano che il processo di gestione dei rischi di natura tecnologica risulti parte integrante del processo più ampio di gestione del rischio aziendale attraverso cui sono presi in considerazione i rischi di varia natura (liquidità, credito, legale, reputazionale), così come richiesto dalle disposizioni di Vigilanza applicabili a ciascuna categoria di prestatori dei servizi di pagamento.”[3]

La diligenza richiesta all’utilizzatore

L’utilizzatore dei servizi di pagamento deve assumere un comportamento diligente quando utilizza i servizi ed i relativi strumenti di pagamento; ad esempio nell’utilizzo di PIN o password è fatto obbligo all’utilizzatore di garantirne la riservatezza.

Va sottolineato che il rispetto degli obblighi di condotta diligente da parte dell’utilizzatore lo esime da responsabilità per utilizzi non autorizzati dei servizi e degli strumenti di pagamento.

Strumenti ad elevata qualità sotto il profilo della sicurezza

Allo scopo di favorire la diffusione dei servizi e degli strumenti di più elevata qualità sotto il profilo della sicurezza la Banca d’Italia ha contemporaneamente pubblicato in consultazione un secondo documento, collegato al primo, denominato “Tipologie di strumenti di più elevata qualità sotto il profilo della sicurezza”[4].

Banca d’Italia considera strumenti in grado di garantire “presidi di sicurezza rafforzati” quelli specificamente orientati a:

• ridurre le frodi;
• inibire i furti di identità;
• prevenire i fenomeni di riciclaggio e di finanziamento del terrorismo;
• salvaguardare i dati dell’utilizzatore.

Questo secondo documento definisce in dettaglio proprio i requisiti tecnico-organizzativi che qualificano i presidi di sicurezza “rafforzati” e fornisce in allegato le principali metodologie utilizzate nell’implementazione dei fattori di autenticazione per una sicurezza elevata.

Si noti che la conformità a tali requisiti di sicurezza specifici deve essere dimostrata attraverso l’assessment di una terza parte indipendente rispetto al soggetto che opera e gestisce i servizi di pagamento offerti agli utilizzatori.

Strumenti di pagamento a “maggior sicurezza” – parte 1 –presidi di sicurezza

Per fregiarsi della denominazione “a maggiore sicurezza”, il processo di gestione dei rischi associati alle tecnologie utilizzate di cui sopra oltre ad essere adeguato deve dotarsi dei presidi di sicurezza specifici di seguito indicati:

a)      Autenticazione a 2 fattori (2FA): le metodologie di autenticazione degli utenti si basano su tre “fattori”:

-         qualcosa che l’utente conosce (es: password/PIN);

-         qualcosa che l’utente possiede (es: smart card, token, OTP, SIM cellulare);

-         qualcosa che l’utente è (es: caratteristiche biometriche);

L’autenticazione dell’utente deve avvenire utilizzando due o più fattori di autenticazione; tali fattori di autenticazione devono essere tra loro indipendenti in maniera che la compromissione dell’uno non comprometta anche l’altro fattore. Nel caso di One-Time-Password di tipo time-based, il tempo di validità della singola password non deve superare i 100 secondi. Nella scheda allegata al documento in consultazione è riportata una descrizione, a mero titolo indicativo, delle modalità di autenticazione prese in considerazione ai fini nel documento di Banca d’Italia.

b)      Autenticazione PSP: lo strumento di pagamento deve essere in grado di autenticare in maniera sicura il dispositivo di pagamento del PSP con il quale interagisce al fine di evitare che l’utilizzatore consegni le proprie credenziali e i propri dati a dispositivi malevoli (es: autenticazione POS/ATM verso la carta, autenticazione Web server della banca verso il PC dell’utente).

c)      Transazioni on-line: per transazioni il cui importo sia superiore a 500 euro, la transazione deve essere sempre autorizzata on-line attraverso il server centrale del PSP.

d)      Crittografia end-to-end: la trasmissione delle credenziali di autenticazione dell’utilizzatore nonché dei suoi dati personali, dal proprio device fino al punto di verifica ad opera del PSP, deve essere effettuata attraverso canali con cifratura end-to-end. Nel caso la tecnologia scelta dal PSP richieda che tali dati siano rimessi in chiaro su dispositivi intermedi, ciò deve avvenire all’interno di dispositivi sicuri (es: tamper-resistant module, HSM).

e)      Autorizzazione singola transazione: nel caso lo strumento consenta di effettuare più transazioni dispositive nell’ambito della stessa sessione (es: Internet Banking), ogni transazione deve essere autorizzata singolarmente.

f)        Canale out-of-band: lo strumento di pagamento deve mettere a disposizione un canale, differente da quello usuale utilizzato per le transazioni, attraverso cui l’utilizzatore viene informato della transazione avvenuta (es: SMS, e-mail, pagine web riservate, etc.). Tale funzionalità deve essere resa disponibile all’utente e attivata a sua discrezione.

g)      Software download/upgrade: deve essere impedito lo scarico di aggiornamenti software (per lo strumento di pagamento in possesso dell’utilizzatore) via Internet o, in generale, attraverso reti non sicure, a meno che non siano previsti metodi sicuri[5] per la trasmissione del software dal server del PSP al terminale dell’utente.

h)      Apertura e Gestione Conto di pagamento: in caso di apertura on-line di uno strumento di pagamento nominativo, il PSP garantisce adeguati controlli per minimizzare il rischio che frodatori possano dare false generalità. Meccanismi di autenticazione affidabili e diversi da quelli utilizzati nelle transazioni dispositive, dovrebbero essere usati per le funzionalità di gestione dello strumento di pagamento (es: riemissione PIN/password, variazione indirizzo e generalità utilizzatore, variazione limiti di spesa, etc..). Il PSP garantisce che non sia possibile ottenere le credenziali di autenticazione dell’utilizzatore (sufficienti ad effettuare una transazione) dalla intercettazione delle comunicazioni periodiche tra PSP e utilizzatore (es: estratti conto via posta, e-mail o SMS).

i)        Monitoraggio transazioni inusuali: il titolare delle funzionalità di pagamento (il PSP o il circuito a cui aderisce) implementa efficaci meccanismi di sicurezza in grado di rilevare tempestivamente transazioni sospette o attività inusuali potenzialmente riconducibili ad attività illecite di frode o riciclaggio. In particolare, i suddetti meccanismi di monitoraggio devono essere in grado di rilevare situazioni come, ad esempio, le seguenti:

-         ripetute transazioni di trasferimento fondi sono eseguite entro un ristretto periodo di tempo[6] verso lo stesso beneficiario e per importi prossimi ai massimali consentiti;

-         cambio di indirizzo richiesto dell’utente, a cui fa seguito a stretto giro la richiesta di remissione di PIN/password da consegnare attraverso servizio postale;

-         innalzamento dei massimali richiesti dall’utente, a cui fa seguito una improvvisa movimentazione di fondi verso controparti inusuali. In tali casi il PSP verifica prontamente con l’utilizzatore la genuinità di tali transazioni inusuali.

Strumenti di pagamento a “maggior sicurezza” – parte 2 – assessment indipendente

La conformità ai requisiti di sicurezza specifici deve essere dimostrata attraverso lo svolgimento di un assessment sul servizio di pagamento.

Per lo svolgimento di tale attività i vertici aziendali del PSP devono designare un soggetto terzo indipendente e qualificato (assessor).

L’assessor[7] deve essere in grado di

1. dimostrare il necessario expertise nel settore per poter eseguire la valutazione;
2. assicurare la necessaria imparzialità, risultando indipendente dai soggetti che sviluppano o operano i servizi di pagamento.

I rapporti di valutazione devono attestare la conformità ai requisiti di sicurezza specifici di cui ai paragrafi precedenti; in particolare:

1. l’esistenza di un efficace processo di risk management;
2. l’adeguatezza dei presidi di sicurezza (tra cui quelli specifici) implementati;
3. il numero e la tipologia delle violazioni di sicurezza perpetrate nel periodo di riferimento della analisi.

Il rapporto di valutazione indipendente deve prevedere almeno i contenuti di seguito indicati.

-         Periodo: deve essere indicato il periodo di riferimento dell’assessment e quali fasi del progetto ha interessato (progettazione, implementazione, testing, messa in produzione, revisione periodica).

-         Contesto: deve essere descritto il perimetro della valutazione effettuata, indicando quali componenti (sistemi, reti, apparati, dispositivi, strutture organizzative) sono state oggetto della valutazione. Tale perimetro deve obbligatoriamente interessare tutte le componenti tecnologiche e organizzative afferenti il servizio di pagamento in oggetto.

-         Metodologia: deve essere indicato l’approccio seguito nel percorso di valutazione (analisi documentale, interviste, test di laboratorio, ispezioni). Il rapporto deve inoltre prevedere specifici approfondimenti sulle aree a maggior rischio (es: vulnerability assessment e penetration test per i servizi via Internet, test sulla resistenza alla effrazione per i POS, verifica delle caratteristiche di qualità dei token). Tali approfondimenti possono essere documentati facendo riferimento anche a rapporti di valutazione o certificazioni emessi da altri laboratori (assessors) specializzati su specifiche tematiche.

-         Oggetto: deve essere valutata la presenza di un robusto processo di Risk Management supportato dal Vertice Aziendale e da un’adeguata struttura organizzativa. Tale processo deve prevedere presidi di sicurezza adeguati rispetto ai rischi da fronteggiare; tali presidi di sicurezza devono obbligatoriamente includere quelli a valenza specifica sopra elencati.

-         Risultati: devono essere chiaramente esposti i risultati della valutazione, evidenziando le relative implicazioni sulla sicurezza del servizio di pagamento offerto dal PSP; in tale ambito dovrebbero essere stimati i livelli di rischio residuo;

-         Raccomandazioni: devono essere riportate eventuali raccomandazioni del valutatore sviluppate sulla base dei risultati ottenuti e volte a sanare non conformità o aree con livelli di sicurezza sub-ottimali.

Si sottolinea infine che il rapporto di valutazione deve essere:

1. rivisto periodicamente in caso di sostanziali variazioni[8];
2. rivisto in presenza di significativi aggiornamenti della struttura tecnico-organizzativa del servizio di pagamento.

EnterpriseRisk: identify, govern and manage IT Risk

Il Risk IT Framework (Risk IT) http://www.isaca.org/Knowledge-Center/Risk-IT-IT-Risk-Management/Pages/Risk-IT1.aspx  è l’approccio metodologico di ISACA http://www.isaca.org, l’associazione internazionale degli IS Auditor e Security Manager, dedicato alla gestione dei rischi informatici d’impresa in un’ottica orientata non tanto all’esperto informatico quanto piuttosto a chi deve fare audit ed in particolare al regulatory compliance assessment.

Risk IT è complementare a COBIT http://www.isaca.org/Knowledge-Center/cobit/Pages/Overview.aspx , altro framework molto diffuso e anch’esso sviluppato da ISACA, che fornisce un approccio completo e coerente per il governo e la gestione dei “servizi” di Information Technology.

Mentre COBIT individua le “buone prassi” anche servendosi del risk management, il framework Risk IT si concentra sull’obiettivo di identificare, governare e gestire i rischi IT dell’impresa.

I framework Risk IT e COBIT sono liberamente scaricabili dal sito ISACA; di COBIT esistono anche numerose traduzioni in italiano a cura dei capitoli “italiani” di ISACA (IsacaRoma http://www.isacaroma.it/  e AIEA http://www.aiea.it/ ); di Risk IT è disponibile la traduzione in italiano dei primi cinque capitoli della prima versione (in bozza), traduzione curata da Agatino Grillo http://www.compliancenet.it/content/risk-it-gestione-dei-rischi-informatici-traduzione-in-italiano-dei-primi-cinque-capitoli.

Il Risk IT framework si basa su principi, standard e framework generalmente riconosciuti per l’enterprise risk management quali COSO, ERM[9] e AS/NZS 4360[10] e fornisce le linee guida su come applicare tali principi all’IT.

L’approccio proposto da Risk IT per la definizione ed il governo di un “processo di gestione dei rischi” consiste nei seguenti passi:

• definizione delle responsabilità per la gestione dei rischi informatici;
• definizione degli obiettivi, della tolleranza e della predisposizione al rischio (risk appetite);
• identificazione, analisi e descrizione dei rischi;
• monitoraggio dell’esposizione al rischio;
• gestione dei rischi informatici;
• correlazione  e coerenza con le linee guida già esistenti di gestione del rischio.

Intorno a questi “building blocks” è stato definito un modello di processo per i rischi informatici che apparirà familiare a chi già conosce COBIT e Val IT[11]: sono infatti fornite linee guida complete e coerenti sulle attività chiave per ciascun processo come le responsabilità, i flussi informativi e la gestione della performance.

I processi sono divisi in tre domini  - Risk Governance, Risk Evaluation e Risk response – ciascuno dei quali contiene a sua volta tre processi, come sintetizzato di seguito:

• Risk Governance:
  • stabilire e mantenere una visione comune del rischio,
  • integrazione con l’Enterprise Risk Management,
  • prendere decisioni di business avendo coscienza dei rischi implicati;
• Risk Evaluation:
  • raccogliere i dati,
  • analizzare i rischi,
  • gestire i profili di rischio;
• Risk Response:
  • suddividere, articolare il rischio,
  • gestire il rischio,
  • rispondere agli eventi.

Come COBIT e Val IT, Risk IT è un framework, non uno standard. Ciò significa che le aziende possono e devono personalizzare le componenti fornite nel framework per adattarle alle caratteristiche proprie della loro organizzazione e del loro contesto.

Vulnerability assessment e penetration test

Come accennato, con Risk IT è possibile istituire e governare il processo di gestione dei rischi.

Tuttavia il framework va “tarato” attraverso la rilevazione e misurazione dei presidi di sicurezza effettivamente esistenti; così operando è possibile valutare non solo il rischio potenziale (o inerente) che viene proposto da Risk IT ma anche il rischio effettivo (o residuo), grazie appunto alla valutazione dell’adeguatezza dei presidi stessi.

Nel caso dei “prestatori di servizio di pagamento“ la misurazione deve consistere, tra l’altro, nell’effettuazione di specifici test di vulnerability assessment e penetration test, come richiesto dal documento in consultazione di Banca d’Italia.

Per questo tipo di test si può far riferimento a quanto indicato dal Payment Card Industry Data Security Standard (PCI DSS)  http://en.wikipedia.org/wiki/PCI_DSS uno standard de facto adottato dalle principali compagnie di carte di credito tra cui VISA e Mastercard.

PCI-DSS fornisce una vera e propria “check list” orientata ad ottenere un “compliance report” relativamente ai presidi di sicurezza da adottare proprio per i fornitori di servizio di sistemi di pagamento ed affini.