La compliance SWIFT, così chiamata perché proposta dalla Society for Worldwide Interbank Financial Telecomunication, ha a che fare con la sicurezza delle informazioni e comporta un notevole impatto sulle aziende del settore finanziario per quel che riguarda la protezione delle transazioni finanziarie internazionali.
SWIFT, infatti, è una società con sede a Bruxelles che fornisce alle istituzioni finanziarie un’infrastruttura che permette lo scambio di informazioni riguardanti le transazioni finanziarie internazionali in modo sicuro, standardizzato e affidabile.
La società offre, allo scopo, una rete (SWIFTNet) con relativi protocolli di comunicazione dei messaggi e un insieme di standard che definiscono la sintassi dei messaggi. Ogni istituzione finanziaria è identificata attraverso un codice univoco (BIC code, o SWIFT code o ISO 9362).
Seppure si tratti di un servizio fornito da una società privata, SWIFT è diventata lo standard de facto per quel che riguarda le transazioni finanziarie internazionali.
Oltre a ciò, SWIFT fornisce ai suoi clienti anche prodotti software da utilizzare all’interno della rete SWIFT (ma esiste anche software di terze parti certificato da SWIFT).
Indice degli argomenti
La compliance SWIFT e la sicurezza
È chiaro come un’infrastruttura del genere, sebbene gli standard e i protocolli utilizzati siano stati progettati anche con obiettivi di sicurezza, possa essere appetibile per il cyber crime e come possa prestarsi a frodi.
Basti pensare a cosa potrebbe succedere nel caso in cui cyber criminali venissero in possesso di credenziali di operatori SWIFT autorizzati. Questo è proprio quanto è avvenuto nel febbraio 2016, quando l’infrastruttura SWIFT è stata utilizzata per inviare 25 istruzioni di pagamento per un totale di 1 Miliardo di dollari utilizzando account di operatori della Banca del Bangladesh.
SWIFT si è quindi resa conto che, sebbene ogni suo cliente sia responsabile della sicurezza del proprio ambiente, la sicurezza di tutto il sistema finanziario è una responsabilità condivisa da parte di tutti i clienti e delle terze parti fornitori di servizi SWIFT (service bureaux).
Per questo motivo ha creato due specifici programmi:
- Customer Security Program (CSP): programma riservato ai clienti SWIFT che ha lo scopo di migliorare la condivisione delle informazioni in tutta la comunità, migliorare i tool relativi a SWIFT per i clienti e fornire ai clienti il “Customer Security Controls Framework”, il quale stabilisce una serie comune di controlli di sicurezza obbligatori e opzionali progettati per aiutare i clienti a proteggere i loro ambienti locali e promuovere un ecosistema finanziario più sicuro;
- Shared Infrastructure Program (SIP): definisce standard di sicurezza e operativi per i service bureau che offrono connettività SWIFT, garantendo qualità, sicurezza e affidabilità. È basato sul “Security and Operational Framework”.
Customer Security Controls Framework: obiettivi, principi e controlli
Il Customer Security Controls Framework elenca 29 tipi di controlli (di cui 19 obbligatori e 10 opzionali), che permettono di raggiungere 3 obiettivi:
- rendere sicuro l’ambiente;
- conoscere e controllare gli accessi;
- individuare e rispondere.
Tali obiettivi sono a loro volta supportati da 7 principi, secondo il seguente schema:
- l’infrastruttura locale SWIFT, intesa come tutto l’hardware e il software specifico per l’ambiente SWIFT, gli HSM, eventuali sistemi di virtualizzazione utilizzati per le macchine virtuali utilizzate per ospitare il software SWIFT, la secure zone, ovvero la rete segmentata che ha lo scopo di separare i componenti SWIFT dall’infrastruttura IT generale, compresi gli apparati di rete e di sicurezza utilizzati per la segmentazione e l’ambiente fisico dove sono ospitati;
- il flusso di scambio dati tra l’infrastruttura SWIFT locale e il software di background o di middleware;
- gli operatori che interagiscono direttamente con l’infrastruttura SWIFT (a livello di sistema operativo o di applicazione di management) e i PC da essi utilizzati per connettersi all’infrastruttura, siano essi PC dedicati, general purpose o jump server.
La versione 2020 del framework prevede che anche la componente server del middleware rientri nello scope di applicazione dei controlli di sicurezza.
Struttura dei controlli di sicurezza
Ogni controllo di sicurezza è strutturato in tre parti.
- Informazioni generali. Ogni controllo viene identificato da un numero e un titolo univoci; per ogni controllo viene indicato se si tratta di un controllo obbligatorio o opzionale e per quali tipologie di architettura SWIFT utilizzata dal cliente deve essere implementato.
- Definizione del controllo. Vengono indicati gli obiettivi del controllo, i componenti architetturali dell’infrastruttura SWIFT al quale si applica, i rischi che il controllo va ad indirizzare.
- Guida all’implementazione. Vengono indicati i mezzi generali con cui gli obiettivi del controllo possono essere raggiunti e una guida più di dettaglio all’implementazione del controllo.
I principi del framework
Illustriamo ora in maniera sintetica i 7 principi previsti dal framework e quali sono le soluzioni organizzative, amministrative e tecnologiche che il framework, attraverso la guida all’implementazione dei controlli, propone per soddisfarli.
- Restrict Internet Access and Protect Critical Systems from General IT environment. Viene richiesta la protezione dell’ambiente SWIFT mediante la creazione di una rete segregata e protetta dal resto dell’ambiente IT generale (la cosiddetta “secure zone”), con accesso limitato ad Internet, che conterrà i sistemi dell’infrastruttura locale SWIFT. Gli operatori dovranno accedere alla secure zone o attraverso una postazione di lavoro dedicata, senza accesso ad Internet e senza software general purpose installato, oppure attraverso un jump server. Gli accessi mediante account amministrativi ai sistemi della secure zone devono essere limitati al massimo e tracciati. Opzionalmente può essere protetta la piattaforma di virtualizzazione che ospita i server virtuali utilizzati dall’infrastruttura SWIFT.
- Reduce Attack Surface and Vulnerabilities. Viene richiesta la messa in sicurezza dei flussi di scambio dati da e verso la secure zone, sia applicativi che relativi alle sessioni degli operatori, l’applicazione delle patch di sicurezza, l’hardening dei sistemi, l’esecuzione almeno annuale di un vulnerability scanning con gestione delle vulnerabilità rilevate. Opzionalmente può essere effettuato l’hardening delle applicazioni utilizzate dall’infrastruttura SWIFT.
- Physically Secure the Environment. Viene richiesto di implementare la sicurezza fisica dei sistemi SWIFT, che vanno conservati in data center ad accesso controllato con tutte le protezioni ambientali. Anche le postazioni degli operatori devono posizionate in ambienti ad accesso controllato e gli accessi remoti devono essere regolamentati da un’apposita policy che indirizzi le problematiche di sicurezza.
- Prevent Compromise of Credentials. Per gli utenti SWIFT viene richiesta la presenza di una password policy; l’accesso ai sistemi SWIFT deve avvenire attraverso multi-factor authentication. I sistemi di autenticazione utilizzati per l’accesso ai sistemi SWIFT devono essere dedicati.
- Manage Identities and Segregate Privileges. Viene richiesto di effettuare un controllo degli accessi logici secondo i principi del “Need-to-know”, del “Least Privilege” e della “Segregation of Duties and 4-Eyes”, revisionando periodicamente gli account. I token di autenticazione e le password di emergenza devono essere conservati in luoghi sicuri e deve essere tenuta traccia del loro utilizzo. Le password conservate in formato digitale devono essere sempre cifrate. Opzionalmente può essere adottato un processo di verifica dell’adeguatezza del personale che fa parte dello staff SWIFT.
- Detect Anomalous Activity to Systems or Transaction Records. Viene richiesta la presenza e il constante aggiornamento di sistemi di protezione dal malware, di sistemi che permettano di verificare l’integrità del software utilizzato e dei database dove sono conservati le transazioni, di sistemi per il logging e il monitoraggio che permettano di rilevare eventuali anomalie. Opzionalmente può essere predisposto un sistema di Intrusion Detection.
- Plan for Incident Response and Information Sharing. Viene richiesta la presenza di un piano di risposta agli incidenti di sicurezza e un programma di formazione e awareness degli utenti ed operatori SWIFT sui temi della cybersecurity. Opzionalmente può essere effettuato un penetration test almeno ogni due anni e può essere predisposto un risk assessment basato su scenari.
Attestazione della compliance al CSP
Abbiamo visto che il framework di sicurezza contiene sia controlli obbligatori che opzionali. I controlli obbligatori costituiscono una baseline per l’intera comunità delle aziende del settore finanziario e devono essere quindi implementati da tutti i clienti SWIFT. I controlli opzionali rappresentano best practice che SWIFT raccomanda a tutti i suoi clienti.
La verifica della compliance rispetto ai controlli obbligatori (ed eventualmente a quelli opzionali) avviene attraverso una self-attestation annuale effettuata da tutti clienti e presentata a SWIFT entro il 31 dicembre di ogni anno. La self-attestation dovrà essere l’esito di un self-assessment svolto dal cliente stesso o, in alternativa, di un audit interno o di terza parte. Dal luglio 2020, tuttavia, il self-assessment non sarà più sufficiente, ma dovrà essere obbligatoriamente effettuato un assessment indipendente, interno oppure esterno. È chiaro che questo nuovo requisito richiederà di basare l’attestazione dell’effettiva implementazione del controllo su evidenze effettive.
La self-attestation richiede di dichiarare, almeno per tutti i controlli obbligatori per il tipo di architettura, se:
- la compliance è ottenuta implementando il controllo secondo le modalità descritte nella guida all’implementazione contenuta all’interno del framework di sicurezza;
- la compliance è ottenuta implementando il controllo in maniera alternativa, ottenendo gli stessi obiettivi;
- il controllo sarà implementato entro una certa data;
- il controllo non è applicato;
- il controllo non è applicabile.
Security and Operational Framework: operatività dei servizi
Il Security and Operational Framework si rivolge ai service bureaux che partecipano allo Shared Infrastructure Program.
Si tratta di un’estensione del Customer Security Framework, dal quale eredita obiettivi, principi e controlli, aggiungendo controlli che mirano a supportare la sicurezza dei clienti e due obiettivi che mirano a garantire l’operatività dei servizi: “Maintain SWIFT Services Availability” e “Limit Customer Business Disruption”.
Tutti i controlli ereditati dal Customer Security Framework sono obbligatori per la compliance allo Shared Infrastructure Program.
Il Security and Operational Framework (versione 2019) presenta quindi 57 controlli che permettono di raggiungere 5 obiettivi:
- rendere sicuro l’ambiente;
- conoscere e controllare gli accessi;
- individuare e rispondere;
- mantenere la disponibilità dei servizi SWIFT;
- limitare le interruzioni dell’attività dei clienti.
Tali obiettivi sono a loro volta supportati da 12 principi, secondo il seguente schema:
I principi del framework
Illustriamo ora in maniera sintetica i 5 principi aggiuntivi previsti dal framework e quali sono le soluzioni organizzative, amministrative e tecnologiche che il framework, attraverso la guida all’implementazione dei controlli, propone per soddisfarli.
- Set and Monitor Performance. Viene richiesta la definizione di Service Level Agreement compatibili con i requisiti SWIFT da concordare con i clienti, il loro monitoraggio, l’esistenza di un piano di capacity management.
- Ensure Availability through Resilience. L’infrastruttura SWIFT deve essere resiliente, in modo da rimanere disponibile anche in caso di malfunzionamenti e disastri. Per questo motivo i vari componenti dell’infrastruttura devono essere duplicati e deve essere presente un sito secondario che possa garantire i servizi in caso di disastro.
- Be Ready in Case of Disaster. Viene richiesta la presenza di un Business Continuity Plan che deve essere testato e rivisto almeno annualmente.
- Detect and Escalate Operational Malfunctions. Viene richiesto un monitoraggio continuo degli eventi, che attraverso un piano di escalation, permetta di gestire eventuali incidenti; gli incidenti devono essere notificati ai clienti. Il monitoraggio dei messaggi per conto dei clienti deve essere contrattualizzato. Infine, il service bureau deve supportare il cliente in caso di problemi.
- Ensure Knowledge is Available. Viene richiesta la certificazione SWIFT di alcuni dei membri del team SWIFT.
Attestazione della compliance al SIP
La compliance al SIP da parte dei service bureaux verrà dimostrata attraverso:
- self-attestation annuale;
- ispezione on-site da parte di SWIFT.
In aggiunta, potranno essere effettuate verifiche parziali remote da parte di SWIFT in qualsiasi momento.
La self-attestation annuale dovrà essere effettuata con modalità analoghe a quelle utilizzate dai clienti per attestare la compliance al CSP. Naturalmente in questo caso l’attestazione andrà fatta per tutti i controlli del Security and Operational Framework.
L’ispezione on-site verrà effettuata da SWIFT o da una società incaricata da SWIFT almeno ogni 3 anni attraverso un audit presso la sede del service bureau della durata di una settimana. Per ognuno dei controlli applicabili verranno raccolte tutte le evidenze disponibili dell’effettiva implementazione del controllo.
Al termine dell’ispezione, le non conformità rilevate dovranno essere risolte dal service bureau, con tempi diversi a seconda della gravità della non conformità.
L’elenco dei service bureaux che hanno ottenuto la compliance al SIP è pubblicato in un’apposita directory disponibile sul sito della SWIFT.
Conclusioni
I programmi SWIFT rivolti ai clienti (CSP) e ai service bureaux (SIP) sono molto ampi e coprono numerosi aspetti della sicurezza dell’ambiente IT dedicato a SWIFT, della rete, degli utenti, ma soprattutto delle procedure in essere.
Le misure di sicurezza organizzative, amministrative e tecnologiche da adottare per ottenere la compliance sono complesse e non possono essere improvvisate. Questo sarà vero a maggior ragione a partire dal 2020, quando la self-attestation dovrà essere supportata da un assessment indipendente.
Il consiglio è quindi quello di prepararsi per tempo, magari con il supporto di una società specializzata in sicurezza, partendo da una gap analysis che permetta di individuare i punti di non conformità, passando poi alla definizione di un remediation plan che definisca le misure da implementare con priorità, tempi e costi, arrivando infine all’implementazione delle misure previste dal piano.