Non tutte le banche sono uguali. Questo non è (almeno non stavolta) uno slogan pubblicitario volto ad attrarre clienti verso una banca piuttosto che un’altra. L’espressione “non tutte le banche sono uguali”, nel contesto SWIFT (Society for Worldwide Interbank Financial Communication), si riferisce all’architettura di una banca rispetto ai sistemi SWIFT e alle corrispondenti transazione.
Più precisamente, i controlli di sicurezza proposti da SWIFT nel 2016 (di cui si è già parlato in un nostro precedente articolo) si rivolgono a determinati sistemi informatici che le banche possono delegare o meno a terzi.
Normalmente, le banche più piccole sono quelle che più spesso delegano il maggior numero di sistemi informatici coinvolti nello SWIFT ad aziende esterne specializzate (third-party outsourcing). Invece le banche più grandi sono quelle che hanno più risorse per implementare e gestire loro stessi tali sistemi.
A seconda dunque di che cosa viene delegato a terzi, la banca ha più o meno controlli di sicurezza del framework SWIFT (SWIFT Customer Security Controls Framework v2021 – Customer Security Programme) a cui essere conforme.
In questo articolo, in prima battuta presenteremo quali sono i componenti informatici bancari che rientrano nel framework SWIFT e, in seconda battuta, descriveremo i cinque possibili tipi di architettura che una banca può avere e i conseguenti controlli di sicurezza a cui la banca deve essere conforme.
Indice degli argomenti
Componenti informatici dell’architettura bancaria coperti da SWIFT
I controlli di sicurezza del framework SWIFT non si occupano di tutta l’infrastruttura di una banca, ma si focalizzano solamente su quelle componenti che sono coinvolte nelle transazioni SWIFT, come mostrato in Figura 1. Di seguito, descriveremo nel dettaglio tutte queste componenti.
Figura 1: Scopo dei controlli di sicurezza SWIFT (immagine presa dallo standard, nda).
Infrastruttura locale SWIFT
Anche se il termine potrebbe essere fuorviante, con “infrastruttura locale SWIFT” ci si riferisce sia alle componenti SWIFT on-premise che a quelle gestite (o delegate) da terzi, siano esse reti, applicazioni, o componenti hardware di qualsiasi tipo (inclusi i così detti removable media). Facenti parte dell’infrastruttura locale SWIFT troviamo:
- La secure zone, ovvero la rete segmentata che ha come scopo quello di separare i sistemi informatici SWIFT dal resto dell’infrastruttura bancaria. Questa zona non si limita all’infrastruttura locale SWIFT, ma si può espandere oltre e includere sistemi non strettamente SWIFT.
- L’interfaccia di messaggistica, ovvero quel software che permette di connettere le applicazioni business ai servizi di messaggistica SWIFT e che normalmente è collegato direttamente con l’interfaccia di comunicazione. Tale software può essere procurato da SWIFT stesso ma anche da terzi.
- L’interfaccia di comunicazione, ovvero il software che connette il network SWIFT e l’interfaccia di messaggistica. Tali interfacce apportano a un’integrazione centralizzata e automatizzata tra le varie applicazioni finanziarie proprietarie della banca stessa. Come nel caso precedente, questo software può essere procurato da SWIFT o da terzi.
- Connettore, ovvero quei software locali che facilitano la comunicazione con l’interfaccia di messaggistica e/o di comunicazione o con un service provider. Tra questi c’è anche il connettore SWIFT.
- Link al network SWIFT (SNL), ovvero il software obbligatorio che connette i servizi di messaggistica al network SWIFT tramite un IP sicuro.
- Network device, ovvero i firewall, i router, gli switch che sono all’interno o all’esterno dell’infrastruttura locale SWIFT, che possono essere dedicati alle transazioni SWIFT o meno.
- Graphic user interface (GUI), software che produce l’interfaccia grafica utente.
Operatori e operatori PC
Con il termine “operatori” si intendono le persone fisiche (end user) che interagiscono con l’infrastruttura SWIFT (sia a livello di sistema operativo che di applicazione di management). Gli operatori PC sono invece i computer utilizzati da tali operatori per connettersi per connettersi all’infrastruttura SWIFT non solo per operarci ma anche per eseguire delle procedure di maintenance. Gli operatori PC si suddividono come di seguito:
- PC dedicati, sono i PC localizzati nella secure zone e utilizzati esclusivamente per interagire con le componenti di tale secure zone.
- PC general purpose, sono i PC localizzati nell’infrastruttura IT generale della banca e utilizzati anche per le normali attività. Questi PC accedono all’infrastruttura SWIFT (remota o locale) o a un’applicazione delegata a terzi.
Data layer exchange e middleware server
Con il termine “data layer exchange” ci si riferisce al flusso di dati tra le componenti SWIFT (siano esse nell’infrastruttura locale o in seno a un service provider terzo) e il back office.
Il middleware server è stato aggiunto come componente in scopo solo nell’ultima versione del framework SWIFT e si riferisce al middleware locale usato per lo scambio di dati tra il back office utente e l’infrastruttura locale SWIFT (o la sua versione delegata a terzi).
Si noti come indicato in Figura 1 che il back office utente e l’infrastruttura IT più ambia della banca non rientrano nello scopo dello SWIFT CSP e quindi tali componenti non sono sottoposti ad alcun controllo di sicurezza nel contesto della conformità alle linee guida SWIFT.
Tipi di architettura della banca rispetto alle componenti SWIFT
Esistono cinque tipi di architettura che una banca può avere quando si parla delle componenti SWIFT descritte nella Sezione 1. A seconda del tipo di architettura, la banca dovrà rispettare o no alcuni controlli di sicurezza. Nel seguito verranno descritte le cinque architetture e i rispettivi controlli obbligatori per essere conformi allo standard SWIFT (ne esistono anche di facoltativi, che non verranno riportati in questo articolo).
Architettura di tipo A1, A2 e A3
Una banca presenta un’architettura di tipo A1 se gestisce ed è responsabile dell’interfaccia di comunicazione e dell’interfaccia di messaggistica dell’infrastruttura locale SWIFT, come mostrato in Figura 2.
Figura 2: Architettura di tipo A1.
Si parla di architettura di tipo A1 anche nel caso in cui la banca sia responsabile della gestione della sola interfaccia di comunicazione e non di quella di messaggistica. Inoltre, si parla ancora di architettura di tipo A1 quando la banca possiede la licenza per l’interfaccia di comunicazione che o gestisce per altri utenti o viene gestita in sua vece da terzi (anche nel caso in cui fosse delocalizzata in un ambiente esterno da quello utente).
Una banca presenta un’architettura di tipo A2 se gestisce l’interfaccia di messaggistica, ma non l’interfaccia di comunicazione. In particolare, è un service provider terzo che possiede la licenza dell’interfaccia di comunicazione, come mostrato in Figura 3.
Figura 3: Architettura di tipo A2.
Tale tipo di architettura include anche l’opzione in cui la banca possiede la licenza per l’interfaccia di messaggistica ma questa viene delegata a terze parti.
Una banca presenta un’architettura di tipo A3 nel caso in cui il connettore SWIFT si situi all’interno dell’ambiente utente al fine di facilitare la comunicazione tra applicazioni con un’interfaccia in seno a un service provider esterno o a un servizio SWIFT. Tale configurazione può essere utilizzata in combinazione con una soluzione GUI. Infine, si parla di architettura di tipo A3 anche nel caso in cui il connettore SWIFT sia gestito da terzi.
Figura 4: Architettura di tipo A3.
Di seguito, saranno riportati i controlli di sicurezza per ognuno dei sette domini del framework (come già spiegato in [1]) che le banche che presentano uno di questi tre tipi di architettura devono implementare in maniera esaustiva al fine di essere conformi con lo SWIFT CSP.
Per quanto riguarda il primo dominio, “Restrict internet access and protect critical systems from general IT environment”, le banche sono responsabili delle seguenti attività:
- protezione dell’ambiente SWIFT;
- controllo degli account privilegiati del sistema operativo;
- protezione della piattaforma di virtualizzazione;
- limitazioni dell’accesso a Internet.
Per quanto riguarda il secondo dominio, “Reduce attack surface and vulnerabilities”, le banche sono responsabili delle seguenti attività:
- sicurezza del flusso di dati interni;
- aggiornamenti di sicurezza;
- hardening del sistema;
- sicurezza del flusso di dati del back office;
- protezione della trasmissione dei dati esterni (facoltativo);
- confidenzialità e integrità della sessione operativa (facoltativo);
- scanning delle vulnerabilità;
- delega di operazioni critiche (facoltativo);
- controlli di transazioni di business (facoltativo);
- hardening di applicativi;
- controlli RMA (facoltativo).
Per quanto riguarda il terzo dominio, “Phisically secure the environment”, viene definita un’unica attività, detta appunto “sicurezza fisica” che ingloba tutta l’implementazione fisica dei sistemi SWIFT, che vanno fatti girare in data center con adeguati controlli sugli accessi fisici alla struttura.
Per quanto riguarda il quarto dominio, “Prevent compromise of credentials”, le banche sono responsabili delle seguenti attività:
- password policy;
- multi-factor authentication.
Per quanto riguarda il quinto dominio, “Manage identities and segregate privileges”, le banche sono responsabili delle seguenti attività:
- logical access control;
- token management;
- vetting process del personale (facoltativo);
- stoccaggio logico e fisico delle password.
Per quanto riguarda il sesto dominio, “Detect anomalous activity to systems or transaction records”, le banche sono responsabili delle seguenti attività:
- malware protection;
- integrità dei software,
- integrità dei database;
- logging e monitorazione;
- intrusion detection (facoltativo).
Per quanto riguarda il settimo dominio, “Plan for incident response and information sharing”, le banche sono responsabili delle seguenti attività:
- pianificazione della risposta agli incidenti cyber;
- educazione e sensibilizzazione sulla sicurezza;
- penetration testing (facoltativo);
- valutazione dei rischi (facoltativo).
Architettura di tipo A4 e B
Si parla di architettura di tipo A4 nel caso in cui il serve che fa girare il software di un’applicativo (ad esempio, l’applicativo per il trasferimento di file o il middleware) si situi all’interno dell’ambiente utente per facilitare la comunicazione tra applicazioni con un’interfaccia al service provider, come mostrato in Figura 5.
Figura 5: Architettura di tipo A4.
Si parla di architettura di tipo A4 anche nel caso in cui il connettore cliente sia un’applicazione proprietaria (sempre situata all’interno dell’ambiente utente) che implementi l’API SWIFT per connettere e trasmettere in maniera indipendente le transazioni ai servizi SWIFT.
Una banca presenta un’architettura di tipo B nel caso in cui nell’ambiente utente della banca stessa non siano presenti nessuna delle componenti specifiche dello SWIFT descritte in Sezione 1, come mostrato in Figura 6.
Figura 6: Architettura di tipo B.
Questo tipo di architettura copre due possibili configurazioni. Nel primo caso, gli utenti accedono ai servizi di messaggistica SWIFT tramite un’applicazione GUI in seno a un service provider. I PC usati dagli operatori sono da considerare general purpose in questo caso. Nel secondo caso, le applicazioni del back office utente comunicano direttamente con il service provider usando un’API del provider stesso senza connettersi e senza trasmettere indipendentemente transazioni all’ambiente SWIFT.
Di seguito, saranno riportati i controlli di sicurezza per ognuno dei sette domini del framework che le banche che presentano un’architettura di tipo A4 e di tipo B devono implementare in maniera esaustiva al fine di essere conformi con lo SWIFT CSP.
Per quanto riguarda il primo dominio, “Restrict internet access and protect critical systems from general IT environment”, le banche di architettura di tipo A4 sono responsabili delle stesse attività che le banche di tipo A1-A3 tranne che per la protezione dell’ambiente SWIFT, di cui non si devono occupare. Una banca di architettura di tipo B deve solo occuparsi delle limitazioni dell’accesso a Internet.
Per quanto riguarda il secondo dominio, “Reduce attack surface and vulnerabilities”, le banche sono responsabili delle stesse attività che le banche di tipo A1-A3 tranne che per la sicurezza del flusso di dati interno e l’hardening degli applicativi, di cui non si devono occupare. A una banca di architettura di tipo B non compete inoltre l’attività facoltativa di protezione di trasmissione esterna dei dati.
Per quanto riguarda il terzo dominio, “Phisically secure the environment” e il quarto dominio, “Prevent compromise of credentials”, anche le banche che presentano un’architettura di tipo A4 o B sono responsabili delle stesse attività in termini di sicurezza fisica delle banche di architettura di tipo A1-A3.
Per quanto riguarda il quinto dominio, “Manage identities and segregate privileges”, le banche di architettura di tipo B sono responsabili delle stesse attività che le banche di tipo A1-A3 tranne, mentre alle banche di tipo A4 non compete il token management.
Per quanto riguarda il sesto dominio, “Detect anomalous activity to systems or transaction records”, le banche con architettura di tipo A4 e B sono solo responsabili del malware protection e del logging e della monitorazione.
Per quanto riguarda il settimo dominio, “Plan for incident response and information sharing”, le banche di architettura di tipo A4 e di tipo B sono responsabili delle stesse attività che le banche con architettura di tipo A1-A3.
