Nella giornata in cui ha avuto inizio il “Click Day” per poter richiedere l’Indennità “COVID-19 Bonus 600 €” a sostegno del reddito a favore di i lavoratori autonomi, partite iva ed imprenditori, abbiamo assistito al più grande DATA BREACH della storia d’Italia.
Migliaia di utenti dopo aver inserito le proprie credenziali, sono stati “catapultati” all’interno dell’area riservata di altri ignari soggetti. Come se non bastasse, ad ogni click di consultazione delle varie sezione del portale, il sistema casualmente (o non proprio) restituiva la pagina riferita ad altre persone.
Continuando a fare click, è stato possibile accedere ai dati RISERVATI di decine di utenti.
Personalmente non mi occupo di scrivere una riga di codice da quasi un decennio, ma occupandomi di seguire alcuni team di sviluppo, prima in qualità di supervisore nello produzione di servizi web, ed oggi come consulente in ambito privacy, penso di poter affermare che il problema sia dovuto esclusivamente all’errata gestione della memoria cache del portale INPS.
Per i non addetti ai lavori: la cache (in ambito web) è un area della memoria del sistema estremamente rapida che viene utilizzata per velocizzare la risposta del server ad una determinata richiesta da parte degli utenti di un sito; su quest’area vengono memorizzate, come se fossero delle fotografie, le pagine già popolate dai dati e pronte alla lettura senza che si debba attendere una risposta dal server.
E’ probabile che, prevedendo un numero di richieste superiori a quelle che il server avrebbe potuto reggere, gli sviluppatori abbiano puntato ad un’esperienza di navigazione quanto più fluida possibile. In quest’ottica, però, il team di sviluppo potrebbe aver commesso un errore nel mantenere attiva la Cache anche per gli elementi variabili contenenti i dati personali dell’utente precedente, permettendo così, al successivo di navigare all’interno delle “istantanee” generate dal sistema di Cache.
E’ ragionevole pensare che siano stati violati soltanto i dati delle persone che sono riuscite ad accedere e non di tutti, dai video che ho visionato attentamente e che ormai spopolano online, è evidente che il comportamento sia legato ad un errore molto comune di programmazione. Mi chiedo però, come sia potuto passare inosservato.
- E’ Best Practices, testare adeguatamene qualsiasi sistema prima di metterlo in produzione
- E’ alla base della Cyber Security la creazione di una mappa delle minacce relative alla sicurezza informatica
- L’articolo 25 del GDPR obbliga tutti i titolari del trattamento a porre l’interessato al centro in modo che siano sempre tutelati i suoi diritti e salve le sue libertà
Le “Best Practices” nello sviluppo di Software
Per quanto l’emergenza sia tangibile e sotto gli occhi di tutti, per evitare danni, a volte irreparabili, è necessario che il Team di Sviluppo ed i suoi Supervisori seguano un decalogo di regole che determinano un modello che garantisca i requisiti di sicurezza necessari, riassumo in modo semplicistico le varie fasi che si dovrebbero seguire:
Raccolta delle esigenze — > Studio dei requisiti — > Progettazione — > Testing –> Collaudo –> Produzione
E’ evidente che il tracollo avuto dalla nuova features non ha tenuto conto di aspetti molto importanti ma permettetemi di dire, elementari.
Analisi dei rischi: Cyber Security
Il Presidente dell’INPS, Pasquale Tridico, durante l’intervista condotta dal giornalista Giuseppe Colombo dell’ Huffington Post ; parla del Server dell’INPS paragonandolo ad un Pronto Soccorso, scaricando addirittura la responsabilità agli utenti del sito. Queste affermazioni a me hanno fatto sorridere.
Un Pronto Soccorso è costruito e progettato in base all’utenza che si attende di dover servire in un determinato lasso di tempo, è ovvio che in caso di eventi particolari, una struttura sanitaria possa essere in affanno. Sono certo però, com’è stato dimostrato dalla macchina messa in moto per l’eccezionalità dell’evento COVID-19, che i dirigenti sanitari avessero un piano di gestione per risolvere eventuali eccezionalità, giacché le stesse sono quasi sempre imprevedibili per definizione.
Anche un server è progettato per “servire” un numero massimo di utenti ed in caso di un traffico anomalo, le risorse potrebbero non essere sufficienti. La differenza sta nella possibilità di gestire eventi del genere in sicurezza.
Era prevedibile che alla notizia della messa online della procedura per l’inoltro della richiesta del Bonus, milioni di cittadini, si sarebbero precipitati ad inoltrare la domanda mandando il server in tilt.
Tenendo in considerazione l’eventualità, per nulla eccezionale, lo specialist manager avrebbe dovuto implementare degli “stress test” simulando e saturando le risorse del server, per poter portare a compimento un collaudo così come le più semplici misure di buone pratiche dettano.
Nulla poi a che fare con la Cyber Security, le disposizioni di buona condotta da comunicare agli utenti, sarebbe bastato dividere gli accessi per iniziale del cognome.
Attacchi Hacker?
Al TG1 si parla di diversi attacchi hacker che avrebbero causato “delle disfunzioni”: queste affermazioni possono essere sufficienti per i non addetti ai lavori, ma sono sicuro che tutti i miei colleghi che hanno letto o sentito, abbiano pensato la stessa cosa: “Perchè prenderci in giro?” Non posso e non voglio pensare che l’INPS non abbia fatto un General Assessment sulle vulnerabilità del sistema e che le stesse non siano costantemente monitorate da chi si occupa della sicurezza informatica; ma parlare addirittura al plurale è ovviamente il segnale che non si ha la più pallida idea di cosa sia accaduto o è forte l’imbarazzo di dover ammettere l’errore.
Sono curioso di leggere il risultato degli accertamenti che il Garante della Privacy sta già provvedendo ad organizzare.
Privacy by Design
Come per moltissimi sistemi rilasciati in produzione durante l’emergenza CORONAVIRUS, anche per la nuova Features dell’INPS manca la fase di “privacy by design”:
Articolo 25 – Protezione dei dati fin dalla progettazione e protezione per impostazione predefinita
Art. 25 – Regolamento Europeo 2016/679
1.Tenendo conto dello stato dell’arte e dei costi di attuazione, nonché della natura, dell’ambito di applicazione, del contesto e delle finalità del trattamento, come anche dei rischi aventi probabilità e gravità diverse per i diritti e le libertà delle persone fisiche costituiti dal trattamento, sia al momento di determinare i mezzi del trattamento sia all’atto del trattamento stesso il titolare del trattamento mette in atto misure tecniche e organizzative adeguate, quali la pseudonimizzazione, volte ad attuare in modo efficace i principi di protezione dei dati, quali la minimizzazione, e a integrare nel trattamento le necessarie garanzie al fine di soddisfare i requisiti del presente regolamento e tutelare i diritti degli interessati.
2.Il titolare del trattamento mette in atto misure tecniche e organizzative adeguate per garantire che siano trattati, per impostazione predefinita, solo i dati personali necessari per ogni specifica finalità del trattamento. Tale obbligo vale per la quantità dei dati personali raccolti, la portata del trattamento, il periodo di conservazione e l’accessibilità. In particolare, dette misure garantiscono che, per impostazione predefinita, non siano resi accessibili dati personali a un numero indefinito di persone fisiche senza l’intervento della persona fisica.
3.Un meccanismo di certificazione approvato ai sensi dell’articolo 42 può essere utilizzato come elemento per dimostrare la conformità ai requisiti di cui ai paragrafi 1 e 2 del presente articolo.
L’impegno del Garante per la protezione dei dati personali e delle associazioni di categoria, insistono sull’importanza di mettere al centro in ogni fase di sviluppo l’utente, prevedendo in modo sostanziale e non soltanto formale le garanzie per proteggere i diritti e le libertà degli interessati; prevenendo prima di correggere problemi che devono essere valutati come impostazioni di default ed incorporati nel progetto per garantirne la sicurezza necessaria e prevista dal regolamento.