Mantenere un inventario degli asset da proteggere o coinvolti nella gestione dei servizi è richiesto da tutte le migliori pratiche in materia di sicurezza delle informazioni e di gestione dei servizi, nonché di qualità.
La ragione del requisito è ovvia: non è possibile proteggere e controllare cose che non si conoscono. Purtroppo, però, anche l’eccesso di dati può portare ad avere informazioni non utili.
Indice degli argomenti
Inventario degli asset, CMDB e CMS: le differenze
Nell’ambito della sicurezza delle informazioni si è sempre parlato di “inventario degli asset”.
Esso, in origine (negli anni Ottanta e all’inizio degli anni Novanta del secolo scorso), permetteva di determinare cosa era necessario proteggere e come. Era sensato, considerando l’informatica dell’epoca, immaginare dei fogli di carta in cui erano scritti i sistemi hardware e le loro applicazioni.
Nell’ambito della gestione dei servizi informatici, in particolare in ITIL (Information Technology Infrastructure Library), è usato il termine Configuration management database o CMDB. Questo database deve raccogliere gli elementi che costituiscono il servizio erogato.
In ambito informatico, questi elementi possono essere: PC e altri dispositivi di informatica individuale, server, applicazioni informatiche, middleware, utenti e impianti.
La differenza fondamentale tra un inventario degli asset e un CMDB è che gli elementi di un CMDB devono essere tutti correlati ad uno o più servizi.
Nel 2007, la terza edizione di ITIL introdusse un nuovo termine: Configuration management system o CMS. Gli autori si resero conto, infatti, dell’impossibilità di poter disporre di un unico database, soprattutto in realtà grandi e complesse.
Inoltre, l’esperienza pratica li mise a confronto con le esigenze delle diverse aree di un’azienda e con la necessità di disporre di sistemi dedicati.
Ad esempio, è facile accorgersi che in un’azienda possono esserci un BMS (Building management system), uno di registrazione degli utenti (Directory), uno di gestione dell’informatica individuale (con la gestione degli assegnatari dei dispositivi) e uno per l’hardware e il software dei server e che questi sistemi hanno funzionalità specifiche e che non è efficiente (e neanche efficace) richiedere di duplicare le informazioni in un altro database.
Per questi motivi, ITILv3 proponeva l’esistenza di un CMS, ossia di un sistema federatore dei CMDB in uso presso le diverse aree aziendali. È facile immaginare la difficoltà di realizzazione anche di questo sistema e infatti nella realtà non è stato adottato, almeno nella sua interezza, da alcuna organizzazione.
In ambito qualità si è sempre preferito usare un altro termine: “tracciamento”. Esso può richiedere la realizzazione di diversi strumenti, come per esempio il fascicolo tecnico di un prodotto, la distinta base di ogni esemplare, il database degli esemplari prodotti (con i loro numeri seriali), eccetera.
Il livello di dettaglio nell’inventario degli asset
Nell’ambito della gestione dei servizi e della qualità, l’esperienza nell’uso di inventari e database ha portato a promuovere pratiche sempre più attente alla loro fattibilità.
Nell’ambito della sicurezza delle informazioni, invece, le esigenze di sicurezza hanno portato anche a suggerire elenchi molto dettagliati e statici. Purtroppo questo atteggiamento porta solo a sprecare risorse.
Il livello di dettaglio deve essere quello necessario agli obiettivi stabiliti. Dire che “è necessario alla loro sicurezza” non è sufficiente, in quanto si tratta di un obiettivo troppo generico. Obiettivi più significativi riguardano la rintracciabilità in caso di perdita o furto, il controllo degli aggiornamenti o il controllo degli accessi. Obiettivi generici rispondono ad esigenze di controllo senza fondamenta nella realtà e vanno quindi evitati, in quanto conducono alla distrazione di tempo e risorse da attività più utili.
L’esperienza insegna che, per proteggere realmente i beni, è necessario disporre di elenchi dinamici, in alcuni casi collegati a strumenti di discovery di quanto collegato alle reti.
È quindi possibile individuare:
- l’elenco dei dispositivi di informatica individuale assegnati al personale, in modo da gestirne l’assegnazione e il ritiro; solitamente questi elenchi sono su tabelle;
- l’elenco dei dispositivi di informatica individuale che possono avere accesso alla rete dell’organizzazione, in modo da assicurarne l’aggiornamento e la presenza di meccanismi di sicurezza (controllo accessi, antimalware, cancellazione in caso di perdita o furto, eccetera); per i dispositivi portatili, questi strumenti sono chiamati MDM o Mobile device management;
- l’elenco dei server fisici e virtuali e degli apparati di rete, in modo da assicurarne l’aggiornamento e la presenza di meccanismi di sicurezza; solitamente questo elenco è oggi disponibile tramite strumenti di monitoraggio della rete, di gestione delle macchine virtuali e di distribuzione degli aggiornamenti (patches);
- l’elenco del personale, sui sistemi di directory e su quelli di gestione dei ruoli, delle competenze e delle presenze (necessari per quadrare quanto presente sui sistemi di directory);
- l’elenco degli impianti, o su tabelle o su BMS.
Alcune organizzazioni possono avere ulteriori inventari, a seconda delle proprie esigenze.
È necessario verificare periodicamente la correttezza di tali inventari, soprattutto quelli statici, in modo da identificare possibili disallineamenti rispetto alla realtà. Spesso è infatti possibile trovare nelle directory persone uscite da tempo dall’organizzazione o dispositivi per cui non è stata registrata la dismissione.
La valutazione del rischio
Nell’ambito della sicurezza delle informazioni alcuni (sempre meno, per la verità) promuovono una valutazione del rischio per ogni asset.
Questo è un approccio che andava bene agli albori dell’informatica, quando i sistemi informatici erano pochi; oggi è ovviamente inapplicabile se non in pochissimi casi.
Quando si valuta il rischio relativo alla sicurezza delle informazioni di un’organizzazione è necessario ricordare che molti sistemi informatici sono controllati in modo tra loro omogeneo e sono sottoposti a minacce identiche, anche se tecnicamente diverse.
Infatti gli attacchi da esterni o interni malintenzionati, gli errori, il malware e gli eventi naturali non dipendono dallo specifico sistema informatico, ma da altri fattori quali l’immagine dell’organizzazione, la sua organizzazione, eccetera.
La valutazione del rischio, almeno in una fase iniziale, deve considerare il fatto che i sistemi informatici vanno controllati in modo tra loro simile. La mancanza stessa di omogeneità dovrebbe essere considerata un elemento da trattare.
Un’analisi del rischio “generale” è auspicabile agli inizi, in modo da avere elementi da cui partire per ridurre il rischio. Un’analisi di dettaglio a livello di singolo asset ha l’effetto di rallentare le attività (“blocco per eccesso di analisi”) o di fornire talmente tanti dati da essere inutili.
In un secondo tempo è possibile identificare i sistemi più esposti (ricordando che un sistema di bassa importanza, ma esposto agli attacchi, può essere usato da malintenzionati come punto di ingresso per attaccare sistemi più importanti) e valutarne le vulnerabilità. In questo caso, ovviamente, è necessario un livello di dettaglio maggiore, ma non per una valutazione del rischio, bensì per un’analisi delle vulnerabilità.
