L’interesse e la preoccupazione per i rischi derivanti dall’esternalizzazione di processi aziendali o anche più semplicemente del ricorso a fornitori (in particolare in ambito ICT) è ormai all’attenzione di tutti gli stakeholder coinvolti.
Anche il legislatore e gli enti normatori in ambito standard nazionali e internazionale hanno prodotto un complesso insieme di norme e regolamenti.
Tuttavia, tali norme spesso non appaiono fra loro omogenee, con il rischio di creare qualche disallineamento sia per quanto attiene gli adempimenti in carico ai fornitori, sia per quelli in carico a quanti si avvalgono dei loro prodotti/servizi.
Gestione dei fornitori in ambito finanziario: come realizzare una strategia e un piano di uscita
Indice degli argomenti
Il Regolamento DORA e la sicurezza della catena di fornitura
Al riguardo, il Regolamento DORA cerca di fare un po’ di ordine fra le normative “settoriali” emesse dalle varie autorità di vigilanza che presiedono il mondo finanziario e assicurativo, due dei settori maggiormente regolamentati e nei quali il ricorso all’outsourcing è diventata una prassi consolidata.
In effetti, tutte e tre le autorità di vigilanza a cui fa riferimento DORA (EBA, ESMA, EIOPA) hanno emesso specifiche normative (linee guida e orientamenti) dedicati alla esternalizzazioni in generale, o più specificatamente all’ambiente cloud:
- EBA/GL/2019/02 – 25 febbraio 2019 – Orientamenti in materia di esternalizzazione;
- ESMA – Orientamenti in materia di esternalizzazione a fornitori di servizi cloud;
- EIOPA-BoS-20-002 – Orientamenti in materia di esternalizzazione a fornitori di servizi cloud.
In questo momento, tuttavia, le indicazioni di DORA sono di alto livello, in quanto il legislatore ha scelto di rimandare i dettagli ad una serie di documenti tecnici che dovranno essere emessi da qui al prossimo anno e pertanto un punto di riferimento autorevole è sicuramente rappresentato dagli orientamenti EBA, qui sopra citati.
Il fatto che tale normativa sia nata per il settore bancario è irrilevante, in quanto le indicazioni in essa riportate sono applicabili a qualunque settore.
Gli standard ISO e il framework del NIST
Relativamente agli standard, ISO rende disponibili diverse pubblicazioni; in particolare per quanto attiene gli aspetti di sicurezza della supply chain troviamo la famiglia delle ISO 28000 (28001, 28002…28005) mentre per quanto attiene più specificamente gli aspetti inerenti a resilienza e continuità operativa possiamo citare la ISO 22318.
Anche il NIST si è mosso e nonostante si tratti di un ente federale statunitense e non un organismo sovranazionale (quindi i suoi standard non hanno valenza internazionale), nondimeno il prestigio di cui gode rende di fatto le sue pubblicazioni un punto di riferimento per chiunque.
Riferimenti agli aspetti di sicurezza che interessano fornitori ed outsourcer sono compresi sia nello standard NIST SP 800-53 (revisione 5) che tratta dei controlli di sicurezza e privacy per sistemi informativi e le organizzazioni, sia nel NIST Cybersecurity Framework (compreso il suo derivato italiano, il Cybersecurity Framework Nazionale).
Esiste poi uno specifico documento dedicato alla supply chain, la NIST SP 800-161 – Supply Chain Risk Management Practices for Federal Informati/on Systems and Organizations, documento oltretutto non recente, essendo del 2015.
Il NIST regolamenta anche nel dettaglio forniture specifiche legate all’ICT, ad esempio quelle relative alla fornitura di software, in esecuzione dell’ordine esecutivo 14028[1] , prescrivendo una serie di controlli ai quali dovrebbero sottostare i fornitori.
Contratti stringenti per la fornitura di software
La semplice fornitura di software spesso non viene adeguatamente considerata in fase di valutazione delle misure di resilienza e di continuità operativa per individuare quelli che sono i fornitori potenzialmente critici.
Questo è un errore comune, ma in realtà se il software in questione supporta un processo che un’organizzazione ritiene critico è evidente che anche il semplice malfunzionamento dello stesso potrebbe portare ad interrompere il processo supportato.
Se il malfunzionamento si protrae per un tempo che si avvicina all’MTPD (maximum tolerable period of disruption) c’è il serio rischio che l’organizzazione possa incorrere in danni irreparabili.
Il malfunzionamento di un applicativo o di altre componenti del sistema informativo che supportano processi critici è infatti uno degli eventi più deleteri che possa inficiare la continuità operativa del sistema informativo e fra i più difficili da gestire in quanto è quasi impossibile predisporre soluzioni alternative.
Non vale in questo caso ovviamente il ricorso al disaster recovery, dove una copia della applicazione non funzionante a causa, ad esempio, di un errore di programmazione, si comporterà esattamente come quella presente nel sito primario.
Unica soluzione quindi, prevedere contratti stringenti con i fornitori di tali applicazioni, affinché intervengano in tempo reale in caso di malfunzionamento, ed una attenta analisi preventiva al fine di acquisire software ampiamente collaudato e di adeguata qualità.
Il rispetto normativo da parte dei fornitori
La presenza degli standard e delle normative prima citate regola sia gli adempimenti dei fornitori, sia del clienti.
Tuttavia, uno dei problemi che deve affrontare un’azienda che utilizza outsourcer e fornitori è verificare le loro reali capacità di rispettare tali adempimenti.
Le soluzioni possibili a tale riguardo sono molteplici e, anche se è contro deduttivo, le attività di audit svolte direttamente dal cliente non sono realisticamente al primo posto fra queste.
Problemi nell’effettuare verifiche presso i fornitori
Si pongono infatti al riguardo, una serie di problemi relativi alla effettiva possibilità di effettuare delle verifiche presso un fornitore, in particolare nell’ambito di servizi erogati in cloud.
Una di queste riguarda l’effettiva possibilità di recarsi presso i datacenter del fornitore, in particolare nell’ambito dei servizi cloud, in quanto questi potrebbero essere dislocati in varie parti del mondo se non si è avuta l’accortezza di selezionare (sempre che sia possibile) la loro localizzazione.
Un altro aspetto riguarda il carattere invasivo di un’attività di verifica.
Di fatto un fornitore di una certa dimensione potrebbe avere centinaia, se non migliaia di clienti che per contratto possono avere la possibilità di effettuare delle verifiche, anche in loco.
È evidente che una situazione di questo tipo potrebbe comportare la presenza contemporanea di diversi teams di audit che interferiscono con la normale produzione, considerando anche il fatto che le risorse utilizzate per erogare i servizi sono le medesime per i vari clienti.
Quali competenze richiedere al team di audit
Non banale è inoltre il tema delle competenze richieste ai componenti del team di audit.
Ad esempio, l’esecuzione di un’attività di audit in un ambiente cloud è diversa rispetto a quanto può essere fatto per altri ambienti più tradizionali.
Per questi motivi, non è da escludere la possibilità di avvalersi di soluzioni di verifica alternative che comprendono:
- l’esecuzione congiunta di un’attività di verifica da parte di un insieme di clienti che utilizzino lo stesso servizio;
- il ricorso a audit di terze parti commissionate dai clienti o dagli stessi fornitori;
- il ricorso a documentazione resa disponibile dallo stesso fornitore:
- check list compilate dallo stesso secondo schemi condivisi a livello di sistema (ad esempio quelli predisposti dalla CSA);
- audit di terze parti secondo standard consolidati, quali SOC[2] (AICPA Association of International Certified Professional Accountants) o C5 (BSI);
- certificazioni, quali ad esempio quelle ISO;
- certificazioni rilasciate da enti terzi, che hanno validato un certo servizio/fornitore, quali ad esempio FedRamp, e che rendono disponibile sul loro marketplace gli elenchi dei servizi/fornitori che sono stati validati
alle quali si possono aggiungere:
- l’uso di servizi di terzi che valutano nel continuo la postura di sicurezza di un’organizzazione;
- un’attività di intelligence diretta o tramite terzi, avvalendosi di fonti aperte.
Esternalizzazione a fornitori di servizi cloud
Riguardo quanto sopra gli stessi orientamenti in materia di esternalizzazione a fornitori di servizi cloud di ESMA recitano:
37. Ferma restando la loro responsabilità finale per quanto riguarda gli accordi di esternalizzazione nel cloud, al fine di utilizzare le risorse di audit in modo più efficiente e ridurre gli oneri organizzativi a carico del fornitore di servizi cloud e dei suoi clienti, le imprese potrebbero avvalersi di:
a) certificazioni di terzi e relazioni di audit esterno o interno messe a disposizione dal fornitore di servizi cloud;
b) serie di audit svolti congiuntamente con altri clienti dello stesso fornitore di servizi cloud o audit congiunti espletati da un revisore esterno designato da più clienti dello stesso fornitore di servizi cloud
Ponendo però un importante limite al ricorso delle certificazioni quale unico strumento di valutazione di un fornitore. Gli orientamenti prevedono infatti che tale fattispecie possa essere utilizzata solo in determinate circostanze:
39. In caso di esternalizzazione di funzioni essenziali o importanti, un’impresa dovrebbe avvalersi delle certificazioni di terzi e delle relazioni di audit esterno o interno di cui al paragrafo 37, lettera a), solo se:
a) ha accertato che l’ambito delle certificazioni o delle relazioni di audit comprende i sistemi principali del fornitore di servizi cloud (ad esempio, processi, applicazioni, infrastruttura, centri dati), i controlli fondamentali individuati dall’impresa e la conformità agli obblighi di legge pertinenti;
b) sottopone a valutazione accurata e periodica il contenuto delle certificazioni o relazioni di audit e verifica che non siano obsolete;
c) assicura che i controlli e i sistemi principali del fornitore siano compresi anche nelle versioni successive della certificazione o della relazione di audit;
d) è soddisfatta della parte incaricata della certificazione o dell’audit (ad esempio per quanto riguarda le qualifiche, le competenze, la ripetizione/verifica degli elementi concreti contenuti nel fascicolo di audit sottostante e la rotazione della società di certificazione o di audit);
e) si è sincerata che le certificazioni siano rilasciate e che gli audit siano espletati conformemente a norme pertinenti e che comprendano anche una verifica dell’efficacia dei controlli essenziali in atto;
f) ha il diritto contrattuale di chiedere l’ampliamento dell’ambito delle certificazioni o delle relazioni di audit per includervi taluni sistemi e controlli rilevanti del fornitore di servizi cloud; il numero e la frequenza di tali richieste di modifica dell’ambito dovrebbero essere ragionevoli e giustificati in un’ottica di gestione dei rischi;
g) conserva il diritto contrattuale di effettuare audit individuali in loco a sua discrezione in relazione alla funzione esternalizzata.
Conclusioni
Il Regolamento DORA, per ovviare al problema rappresentato da una corretta valutazione dei fornitori, ha introdotto il concetto che siano le stesse autorità di vigilanza ad effettuare tali attività di verifica, quantomeno su quelli che saranno considerati fornitori critici.
Tale possibilità si potrà estendere, su base volontaria, anche ad altri fornitori.
Un importante passo avanti per le organizzazioni e non solo quelle soggette a DORA.
Questa iniziativa consentirà infatti di risolvere uno dei maggiori problemi intrinsechi nel ricorso a determinate categorie di fornitori con cui sicuramente, direttamente o indirettamente (in particolare in caso di subfornitura è quasi certo che qualunque servizio un’azienda acquisisca utilizzi una infrastruttura in cloud fornita dai soliti big), qualunque azienda ha a che fare.
Il tipo di verifica da attuare è funzionale alla criticità del servizio/prodotto acquisito e quindi ogni cliente dovrà valutare quale delle soluzioni sopra citate sia da ritenere accettabile e percorribile per il proprio caso.
Non da ultimo, va ricordato, come evidenziato nel precedente articolo Gestione dei fornitori in ambito finanziario: come realizzare una strategia e un piano di uscita – Cyber Security 360 che la decisione di esternalizzare un’attività deve essere oggetto di un’attenta valutazione che prenda in considerazione tutti i rischi, anche economici, del caso.
NOTE
- Federal Register :: Improving the Nation’s Cybersecurity ↑
- Gli schemi di audit SOC sono stati realizzati dell’AICPA (Association of International Certified Professional Accountants)
Sono disponibili gli schemi:
• SOC 1®– SOC for Service Organization: ICFR, Type 2
• SOC 1®– SOC for Service Organization: ICFR, Type 1
• SOC 2® – SOC for Service Organizations: Trust Services Criteria
• SOC 3®– SOC per le organizzazioni di servizi: report sui criteri per i servizi fiduciari per l’uso generale
Sono pubblicamente disponibili e facilmente reperibili. ↑
NOTA BIBLIOGRAFICA
Parte del testo deriva da libro di G.Butti Manuale di resilienza – ITER.IT
