Molte aziende valutano l’opzione di certificarsi secondo alcuni standard per poter acquisire nuovi clienti.
Alcuni manager presumono che la conformità a leggi, linee guida (come ad esempio ITIL) o standard industriali di qualità sia da sola sufficiente per garantire la sicurezza del sistema informativo.
In realtà l’introduzione delle procedure e dei comportamenti previsti da leggi, standard o best practice è il punto di partenza per arrivare ad una sicurezza informatica accettabile.
In una qualsiasi organizzazione l’adozione di uno standard industriale codificato comporta sicuramente un notevole sforzo economico in termini di corsi di aggiornamento, consulenze, documentazione, eccetera. A disponibilità di danaro costante, è ovvio che l’azienda che “si certifica” deve deviare il budget verso l’obbiettivo della certificazione, tralasciando altri aspetti di miglioramento aziendale.
Il raggiungimento dell’obbiettivo della conformità, spesso certificato da un istituto terzo, dà ad un’organizzazione un senso di aver raggiunto un traguardo, come il conseguimento di un diploma. Ma in realtà è solamente l’inizio.
A parte alcune certificazioni specifiche per la sicurezza, gli standard di qualità e le linee guida da soli non garantiscono la sicurezza dei sistemi informativi. In nessun corso di certificazione di qualità vi spiegheranno quali sono i rischi più comuni (e, quindi, più recenti in termini di giorni o settimane) che si corrono utilizzando un sistema informativo. In altre parole, oggi nessun consulente ISO o ITIL vi parlerà di heartbleed o di CVE-2014-1776, eppure sono due dei rischi più concreti che potrebbero minare la qualità del sistema informativo. Mettere le password di 8 caratteri che devono essere cambiate ogni 180 giorni è una buona regola, ma da sola non serve ad impedire la compromissione di un account.
Sia chiaro: in alcuni contesti confrontarsi con degli standard di qualità o delle linee guida aiuta moltissimo in quanto impone un’autoanalisi che spesso non si vuole fare proprio perché si conoscono fin da subito i risultati (negativi). Un chiaro esempio è la prima legge italiana sulla privacy, il cui allegato B conteneva delle linee guida per i sistemi informativi che erano state evidentemente scritte da un tecnico. L’allegato B non conteneva idiozia, come il salvataggio dei log su supporti immutabili, ma conteneva delle linee guida oneste, arrivabili e sensate. L’allegato B ha avuto il pregio di costringere molte realtà (incluse le PA) a confrontarsi con la loro struttura informatica e ad adeguarla. Ma una legge non può fare quello per cui non è concepita: io ti posso obbligare a fare almeno un backup la settimana, ma se poi metti il NAS sopra al server c’è il rischio che un ladro rubi server e backup (in questo caso un ladro coscienzioso perché conosce l’importanza del backup).
Se la certificazione non avrà portato solamente della burocrazia inutile, un’azienda potrebbe giovare di alcune norme per rinforzare la sicurezza. Un esempio banale potrebbe essere il blocco delle installazioni di software arbitrario da parte degli utenti per motivi di tracciabilità che comporta allo stesso tempo una riduzione della probabilità che un utente installi del malware senza volerlo. Ma bisogna sempre tenere presente che la sicurezza informatica è un lavoro costante di ogni giorno, non uno sforzo per ottenere un bollino blu e poi dimenticarsi tutto.
Lascia un commento