Data breach Infocert, ecco gli errori che fanno ancora tutti (o quasi)

Il ruolo delle esercitazioni

I comunicati di InfoCert sono stati giustamente criticati per eccessiva reticenza, lo scaricabarile verso il fornitore, la minimizzazione degli impatti, l’assenza di dettagli su quali dati fossero compromessi e di quali siano i rischi per gli interessati. Purtroppo la reticenza è diffusa anche per il rischio di multe.

Su questo punto è però opportuno riflettere sul fatto che gli incidenti di questa portata, fortunatamente, sono rari e le persone spesso li gestiscono male perché mancano gli automatismi. Va poi aggiunto che forse il 27 dicembre non tutte le persone di InfoCert hanno potuto dare il loro migliore contributo per il testo e la sua diffusione.

La lezione è quindi quanto sono importanti le esercitazioni, perché potrebbero migliorare alcuni automatismi. Le procedure scritte possono aiutare, ma anche il loro utilizzo richiede pratica. Tutti sappiamo quanto le esercitazioni, soprattutto quelle non tecniche, siano trascurate perché ritenute inutili. Forse anche questo esempio potrebbe contribuire a una diversa percezione.

Il controllo dei fornitori

InfoCert ha dichiarato che i dati sono stati prelevati da sistemi usati da un fornitore.

Per quanto riguarda il controllo dei fornitori, la lezione è nota: vanno selezionati, anche con audit preventivi se il loro rischio è elevato, contrattualizzati, monitorati (anche con audit periodici, di processo e tecnologici, a seconda del livello di rischio) ed eventualmente cambiati.

Forse InfoCert ha seguito correttamente questi principi, ma qualcosa non ha funzionato correttamente (per esempio, InfoCert potrebbe aver verificato approfonditamente quel fornitore due mesi prima e rilevato processi ben controllati e tempestivi; quegli stessi processi potrebbero essere saltati un mese dopo per chissà quale motivo), oppure il fornitore fu valutato di basso rischio e quindi controllato superficialmente. Ecco quindi la possibilità di ripassare un’altra lezione: ciascun processo, in questo caso quello di controllo dei fornitori, ha i suoi rischi.

Altro rischio, per cui spesso il controllo dei fornitori è lacunoso, è che necessita l’intervento di troppe competenze e figure professionali che non riescono a trovare un giusto equilibrio: l’Ufficio acquisti che, senza competenze tecniche, deve rispettare vincoli economici, il manager di riferimento che deve rispettare vincoli funzionali e il responsabile della sicurezza che deve rispettare vincoli economici e la carenza di competenze in questo campo.

Va anche considerato che in questi anni si sta sempre più spostando l’attenzione verso la catena di fornitura, ma troppo spesso si tratta di “sicurezza di carta”, ossia basata su questionari e sull’illusione che questi portino a un buon controllo.

L’aggiornamento dei sistemi

Da un punto di vista tecnico, forse è stata sfruttata una vulnerabilità nota non corretta dei sistemi di un fornitore.

È banale ricordare quanto sia importante aggiornare i sistemi tempestivamente. Però questo si scontra con l’obsolescenza dei software e degli investimenti elevati che l’informatica richiede sempre più, con una crescita talmente elevata che i vertici aziendali, anche di aziende dedicate all’informatica, non sono spesso in grado di elaborare correttamente.

Il problema culturale che porta a scarsità di risorse per la sicurezza è noto: l’informatica è ancora vista come bene intangibile e poco significativa; la diffusione di sistemi informatici sempre più semplici ed economici dà l’illusione a molti che sia una materia semplice e quindi economica; la difficoltà nel capirne le caratteristiche e il suo ruolo spesso di supporto la rende non prioritaria (nel caso InfoCert, sarebbe stato compromesso proprio un sistema di supporto all’assistenza); l’importanza delle funzionalità va a discapito della sicurezza; i troppi annunci di incidenti all’estero fa ritenere a molti che non saranno vittime di attacchi.

A questo va aggiunto che gli sviluppatori troppo spesso non considerano la manutenibilità come essenziale. Si tratta quindi di questioni di ampio respiro, che dovrebbero venire costantemente affrontate per cambiare l’orientamento. Si può sperare che sia utile anche il requisito della NIS2 di includere i vertici aziendali nella formazione sulla sicurezza informatica.

Il nodo della normativa

Sono tante le iniziative del legislatore e di ACN: solo nell’ultimo anno possiamo citare il recepimento della NIS2 e la Legge 90. A essi si vanno ad aggiungere il PNSC (Perimetro nazionale di sicurezza cibernetica) e, per molti operatori in ambito informatico, le regole di qualifica dei fornitori cloud per la PA e le misure minime per la PA.

Tutti questi provvedimenti non rispettano un quadro comune di riferimento, le check list sono troppe e tra loro disallineate (alcune basate su schemi internazionali come la ISO/IEC 27001, altre su schemi proprietari come quelle del CIS, altre ancora su schemi nazionali italiani o USA, quando sarebbe essenziale andare verso un linguaggio comune almeno europeo).

Chissà quante risorse ha investito InfoCert, come molte aziende stanno facendo in questo periodo, per analizzare tutte queste normative e per districarsi dalla confusione creata, a discapito della sicurezza operativa. Su questo è necessario chiedere ad ACN e al Parlamento di fare ordine e di ripartire con schemi tra loro facilmente correlati.

La sicurezza di carta

I requisiti di sicurezza di normative e di check list promosse dalle normative e da ACN presentano troppi requisiti documentali. Questo richiede di investire in schemi e documenti e non in sicurezza operativa e, drammaticamente, dà la sensazione a molti che la sicurezza sia soprattutto questione di documenti.

Purtroppo questo è anche il risultato del mancato o scarso coinvolgimento di tecnici nella redazione di standard e linee guida. Sono state anche pubblicate linee guida con misure presentate in modo confuso o incoerente tra i vari paragrafi o requisiti che richiedono solo di documentare le misure di sicurezza, ma non di adottarle (anche se può essere sottinteso). Sarebbe meglio che venga richiesto di identificare, progettare, attuare e documentare le misure di sicurezza.

L’approccio “prima il documento e poi l’applicazione” è il risultato della scarsità di competenze tecniche sulla sicurezza e ancora oggi sono troppo pochi i corsi tecnici tenuti da tecnici, mentre sono numerosissimi i corsi non tecnici (di governance) tenuti da non tecnici. Gli stessi bandi di gara puntano a certificazioni di governo come Lead auditor ISO/IEC 27001, CISA o CISM. Andrebbero quindi promosse iniziative di formazione tecnica a tutti i livelli e a prezzi accessibili. Va infine richiesto a chi scrive normative, standard e linee guida di pensare prima alla sicurezza operativa e ai documenti come strumenti di supporto, non viceversa.

I rischi sulla privacy

Il Garante privacy ha chiesto informazioni a InfoCert in merito ai rapporti con il fornitore esterno e ai trattamenti di dati personali coinvolti nella violazione. Allo stato attuale possiamo chiederci perché fossero così numerosi i dati coinvolti e se è possibile ridurli. Questo va però fatto considerando che, tranne forse qualche rarissima eccezione, i sistemi informatici di supporto all’assistenza non hanno meccanismi di anonimizzazione, per esempio dopo qualche mese dalla chiusura del ticket.

Sicuramente un’azienda che offre assistenza deve mantenerne uno storico, per scopi statistici e per poter replicare o migliorare soluzioni già esperite; forse è possibile farlo senza conservare email e numeri di telefono (necessari in fase di trattamento per ricontattare il richiedente), ma questo richiede un’analisi delle abitudini consolidate e una modifica di quasi tutti i sistemi di supporto all’assistenza.

Da ricordare che un eventuale adeguamento richiederà parecchio tempo perché spesso i prodotti sono mantenuti da società estere.