I recenti Information Leakage in Italia: perché non è stato un hacking e perché avrebbe dovuto esserlo
L’ultimo scandalo informatico italiano è stato generato da un information leakage che ha coinvolto politici e altre persone esposte socialmente. Alcune organizzazioni pubbliche e private sono state bersaglio del leakage o ne hanno sfruttato i risultati, amplificando la portata del danno e portando alla luce debolezze strutturali nei sistemi di sicurezza, tanto che queste informazioni riservate hanno raggiunto ambienti al di fuori del contesto originale, generando un effetto domino di conseguenze negative che ha coinvolto diversi settori sociali e istituzionali, coinvolgendo persino lo Stato del Vaticano.
Dopo un primo periodo in cui si è invocata la classica ed abusata spiegazione di attaccanti sofisticati ed abilissimi, è emersa una realtà più triviale: l’information leakage è stato causato da alcune persone che, utilizzando i diritti di accesso concessi loro, hanno acceduto a informazioni su politici e personaggi della vita pubblica che poi hanno rivenduto ad altri.
Problemi Legati all’Information Leakage
Anche se non si tratta di una intrusione nei sistemi informatici, ma semplicemente dell’uso illegale dei propri diritti di accesso a delle basi di dati, vi sono diverse ragioni per considerare le vere cause informatiche del information leakage. Punto di partenza di un’analisi informatica del problema è l’uso illegale dei diritti.
Sul termine “illegale” si dovrebbe discutere molto, perché, di fondo, nessuna illegalità è stata commessa se per illegalità si intende l’acquisizione tramite una intrusione di diritti di accesso che la politica di sicurezza del sistema vieta ad un utente.
In questo caso, all’utente erano stati concessi i diritti in modo perfettamente legale; al massimo possiamo parlare di una violazione del “need to know”, ovvero dell’accesso a informazioni non necessarie per il compito assegnato. Un secondo problema è il mancato controllo: qualcuno avrebbe dovuto monitorare gli accessi effettuati e scoprire che erano non necessari e quindi sicuramente finalizzati a scopi diversi da quelli di servizio.
Assunto quindi che la violazione del need to know non ha richiesto nessun attacco informatico, né particolari abilità o competenze informatiche, quello che resta per spiegare la violazione sono i pesanti errori compiuti nella progettazione del sistema e, in particolare, nella definizione della politica di sicurezza che stabilisce i diritti dei singoli utenti e i compiti ad essi assegnati, oltre al monitoraggio della corretta applicazione della politica.
La root cause, ovvero la causa prima dei problemi della base di dati, è non aver impiegato il principio del privilegio minimo, che richiede di minimizzare i diritti di accesso di ogni utente al più piccolo insieme necessario per i compiti dell’utente. Da decenni, tutte le best practice di sicurezza informatica richiedono, direi quasi supplicano, i progettisti di usare questo principio, che permette di minimizzare i danni dovuti a furti di credenziali o ad utenti maliziosi.
Non si è nemmeno utilizzata una soluzione meno generale, nota come il role-based access control, ovvero il controllo dell’accesso alle risorse – nel nostro caso, il database – basato sul ruolo delle persone. Se chiunque può accedere a qualunque informazione nel database, è evidente che non stiamo considerando il ruolo che la persona occupa e i compiti ad essa assegnati.
Il monitoraggio degli accessi in un sistema in cui chiunque può accedere a qualunque informazione è una chimera, dato il numero di utenti, la quantità degli accessi e la mole dei dati. Questo non vuole essere una giustificazione, ma una semplice spiegazione.
Soluzioni per Prevenire Information Leakage
Ammesso che la condivisione di informazioni sia necessaria e fondamentale per le indagini di polizia giudiziaria, è possibile gestirla in modo più efficace e trasparente se si individuano specifici ruoli all’interno dell’organizzazione complessiva, che possono accedere a informazioni di altre indagini. L’esistenza di ruoli specifici permette di focalizzare il monitoraggio dei comportamenti su alcuni ruoli specifici e non su tutte le persone. Inoltre, è possibile anche utilizzare strumenti di intelligenza artificiale e big data che analizzino gli accessi delle persone ai dati per scoprire eventuali anomalie.
Un possibile esempio di anomalia è quello di una persona che acceda a molti dati in un periodo molto limitato o che concentri i propri accessi su singole persone o eventi. Strumenti del genere sono allo stato dell’arte da molti anni e vengono utilizzati in altri campi di applicazione. Un’anomalia segnalata dagli strumenti non corrisponde necessariamente a un comportamento scorretto, ma rappresenta solo un’indicazione di comportamenti che devono essere meglio analizzati. È anche possibile un tuning degli strumenti per migliorare il numero e il tipo di segnalazioni prodotte, riducendo nel tempo le segnalazioni di comportamenti che poi si rivelano corretti. Il punto centrale è che solo un’automazione dei controlli può garantire la loro efficacia e accuratezza.
Una ulteriore strategia che i progettisti della base di dati potevano applicare era la decomposizione del database in più database, ognuno contenente informazioni su una particolare zona del paese, una classe di indagini o sui settori commerciali delle organizzazioni coinvolte. Oltre a permettere di limitare meglio i diritti di accesso dei singoli utenti, una organizzazione modulare del database avrebbe permesso un miglior monitoraggio, automatico e/o manuale, degli accessi di utenti impiegati in una indagine in un’area del paese rispetto ai dati di indagini in altre aree o settori commerciali. Il tutto con l’obiettivo non di impedire la condivisione di informazioni, ma di verificare un corretto accesso alle informazioni.
Tecniche di decomposizione come quelle proposte sono già state applicate a dati sensibili per evitare, ad esempio, accessi da parte di personale amministrativo a informazioni sullo stato di salute di persone ricoverate in ospedali o altri centri di assistenza. La normativa sulla protezione dei dati personali e sensibili poteva fornire altre utili indicazioni ai progettisti, come quella di produrre ROPA (record of processing activities), come richiesto dall’articolo 30 del GDPR.
Un ulteriore vantaggio della decomposizione è che costringe eventuali intrusioni ad operare su database diversi, limitando l’impatto di singole intrusioni.
Conclusioni sull’Information Leakage Italiano
È evidente la maggiore robustezza e il miglior monitoraggio degli accessi offerti da una base di dati progettata con un maggior rispetto dei criteri del privilegio minimo e di gestione dei diritti basata sui ruoli. Ciò avrebbe costretto chi era interessato ai dati a condurre una vera intrusione, invece che semplicemente corrompere alcuni utenti.
Come informatico interessato alla sicurezza, avrei preferito la scoperta di una intrusione piuttosto che di un semplice caso di corruzione permesso da una politica di sicurezza progettata e implementata in modo non adeguato. Una domanda che mi pongo è, se ci sono state e quali intrusioni di organizzazioni criminali e stati esteri siano state permesse da questa inadeguatezza?
Articolo a cura di Fabrizio Baiardi
Full Professor, Università di Pisa
E' attualmente è professore ordinario di Informatica presso l'Università di Pisa dove coordina il gruppo di ricerca su ICT risk assessment and management. La sua attività di ricerca è focalizzata su strumenti e metodi formali l'automazione dell'analisi e la gestione del rischio.
