Il tuo CMDB è un asset per la sicurezza. Lo stai trattando come tale?

I Configuration Management Database (CMDB) sono stati sviluppati per gestire la configurazione dell’infrastruttura IT, comprendere le dipendenze tra gli asset, pianificare i cambiamenti e governare sistemi su larga scala.  Per anni sono stati considerati più che altro uno strumento al servizio dell’IT. Oggi, però, con la diffusione di forme di ransomware sempre più aggressive, con le frequenti compromissioni della catena di fornitura (supply chain) e di fronte a una superficie di attacco sempre più ampia, composta da ogni dispositivo, applicazione o connessione di rete attraverso cui un’organizzazione può essere violata,  il CMDB ha assunto un ruolo più strategico: è diventato una mappa aggiornata dei rischi a cui l’organizzazione è quotidianamente esposta.

Quando i dati di configurazione sono incompleti o obsoleti, si creano delle «zone cieche» – porzioni dell’infrastruttura che né l’IT né i responsabili della sicurezza riescono a vedere – che possono essere sfruttate nel corso di un attacco informatico. Si tratta di un tema che riguarda da vicino sia i responsabili IT sia quelli della cybersecurity, spesso abituati a osservare la stessa infrastruttura con differenti strumenti e usando dati diversi.

Da strumento IT a vera e propria mappa del rischio

Nella sua funzione tradizionale, un CMDB è la fonte unica e attendibile di informazioni sull’infrastruttura IT. 

Un CMDB registra ogni componente che deve essere gestito per l’erogazione di un servizio, il cosiddetto configuration item (CI) – server, applicazioni, dispositivi, servizi, contratti – e soprattutto ne mappa le relazioni e le dipendenze. È questa intelligenza relazionale, più del semplice elenco di risorse, a distinguere un CMDB da un inventario statico: quando un componente si guasta o cambia, il sistema mostra subito quali servizi sono coinvolti nel guasto o nel cambiamento. 

Vale la pena ricordare che il CMDB non coincide con la gestione degli asset IT: sono due discipline complementari ma distinte, e comprenderne a fondo la differenza è il presupposto per costruire un CMDB davvero affidabile. Gli stessi dati che permettono di pianificare un cambiamento consentono oggi al team di sicurezza di individuare quali asset sono esposti, dove si trovano e con quale livello di criticità.

Vale qui un principio elementare della sicurezza informatica: non si può proteggere ciò di cui si ignora l’esistenza. Un CMDB accurato fornisce esattamente quella visibilità sugli asset – la asset visibility, appunto – che rende efficace ogni misura di protezione successiva.

Le zone cieche: quando il CMDB non rispecchia la realtà

Il problema è che pochi CMDB sono davvero completi. Ogni informazione mancante o non aggiornata nel CMDB può tradursi, prima o poi, in un rischio concreto per la sicurezza. Gli scenari seguenti mostrano in che modo. 

Carenze che diventano rischi

Il primo scenario è quello degli endpoint non tracciati. Un dispositivo che non compare nel CMDB non riceve patch, non viene monitorato e resta fuori da ogni controllo di sicurezza: per l’organizzazione semplicemente non esiste, ma rappresenta un punto di accesso non presidiato alla rete aziendale.

Il secondo riguarda il software non autorizzato: applicazioni installate al di fuori delle procedure ufficiali e all’insaputa dell’IT, che nessuno aggiorna e che aumentano il numero di punti da cui un sistema può essere violato (aumentano cioè la «superficie di attacco», ovvero l’insieme dei possibili punti attraverso cui un’organizzazione può essere colpita ).

Il terzo riguarda le integrazioni non documentate: connessioni tra sistemi nate per necessità e mai registrate, che possono essere sfruttate per propagare un’intrusione da un sistema all’altro dopo aver superato le difese perimetrali (il cosiddetto «movimento laterale»).

Un caso emblematico riguarda poi l’applicazione urgente di una patch di sicurezza. Un Analista individua una vulnerabilità critica in un pacchetto software, identifica gli asset interessati e trasmette l’elenco al team IT perché intervenga. Ma se i dati nel CMDB non corrispondono alla realtà, l’IT non sa con certezza dove si trovino quei sistemi, e il flusso di lavoro si blocca proprio nell’intervallo più critico: quello in cui la vulnerabilità è già nota ma non ancora sanata. Un CMDB aggiornato rende questo intervento rapido e ordinato, mentre un CMDB obsoleto lo trasforma in un collo di bottiglia.

Perché i dati restano incompleti

Le carenze informative che abbiamo descritto hanno una causa ricorrente: una discovery rigida o eseguita solo a intervalli periodici. Con la diffusione del cloud, dei dispositivi mobili e dell’Internet of Things, un elenco aggiornato saltuariamente non basta più. Il rischio è che restino fuori dal CMDB gli asset esposti su internet ereditati da fusioni e società controllate, i dispositivi personali che si collegano alla rete e i dispositivi IoT e OT – le tecnologie operative degli impianti industriali sui quali non è possibile installare gli agenti software necessari al monitoraggio.

A questi si aggiunge il fenomeno dello Shadow IT, e soprattutto dello Shadow SaaS: servizi cloud sottoscritti dai singoli reparti senza alcuna supervisione, che creano zone d’ombra difficili da individuare e ancor più da mettere in sicurezza. In tutti questi casi a mancare è prima di tutto la visibilità sugli asset, e con essa la possibilità stessa di proteggerli.

Quanto costano gli asset non gestiti

I numeri confermano la portata del problema. Una ricerca condotta da Sapio Research per Trend Micro ha rilevato che il 74% degli oltre 2.000 responsabili IT e di sicurezza intervistati ha subito incidenti causati da asset sconosciuti o non gestiti. Quanto agli effetti, il Cost of a Data Breach Report di IBM ha rilevato che più di un terzo delle violazioni coinvolge «shadow data», ovvero dati conservati in sistemi non gestiti: violazioni che risultano più lente da individuare e contenere e, in media, più costose. Infine, l’indagine di TeamViewer sul digital friction ricorda quanto siano frequenti le condizioni che alimentano questi rischi: il 66% dei lavoratori, nell’ultimo anno, ha avuto a che fare con aggiornamenti forzati o con veri e propri attacchi informatici, come malware e ransomware.

Che cosa serve perché un CMDB sia orientato alla sicurezza?

Perché il CMDB possa contribuire alla sicurezza dell’organizzazione devono essere soddisfatti alcuni requisiti operativi, gli stessi che distinguono un CMDB affidabile da un semplice elenco statico, destinato a invecchiare. 

I requisiti tecnici

Il primo è la discovery continua. Non una fotografia periodica, ma una scansione costante dell’ambiente IT grazie alla quale è possibile individuare in tempo quasi reale nuovi dispositivi, software e modifiche alla configurazione. È l’unico modo per restare allineati a un’infrastruttura che cambia di continuo e per mantenere una visibilità sugli asset (asset visibility) che corrisponda davvero alla situazione reale.

Il secondo è la riconciliazione automatizzata. Quello che la discovery rileva va confrontato di continuo con quello che il CMDB ha registrato, segnalando ogni scostamento. Senza questo confronto sistematico, gli scostamenti tra ciò che è effettivamente presente nell’infrastruttura e ciò che il CMDB ha registrato si accumulano, e in pochi mesi i dati smettono di essere affidabili.

Il terzo è l’integrazione con il vulnerability management. Collegare il CMDB agli strumenti che rilevano le vulnerabilità consente di sapere subito quali asset sono effettivamente colpiti. E permette di decidere che cosa correggere per primo non in base a un punteggio tecnico astratto, ma all’importanza reale dell’asset: quanto è rilevante per l’operatività, chi ne è responsabile, quali servizi dipendono da esso. È qui che il CMDB smette di essere un semplice archivio IT e diventa uno strumento operativo di cybersecurity.

Il quarto requisito, spesso il più trascurato, riguarda l’assegnazione di una responsabilità chiara sulla proprietà dei dati.  A ogni tipo di configuration item va associato un responsabile che ne garantisca la qualità nel tempo.

Un investimento comune per IT e sicurezza

Modernizzare l’ITSM, e in particolare il CMDB, vuol dire, allo stesso tempo, sviluppare un progetto di efficienza operativa e investire direttamente nella sicurezza dell’organizzazione. È un argomento che riguarda allo stesso modo i responsabili IT e quelli della cybersecurity, perché entrambi traggono valore dallo stesso patrimonio di dati.

Quando IT e security condividono un’unica fonte di verità, smettono di lavorare su rappresentazioni diverse della stessa infrastruttura. Il team di sicurezza dispone così del contesto necessario (quali asset esistono, quanto sono critici, chi ne risponde) per valutare il rischio e definire le priorità in modo efficace. L’IT, dal canto suo, interviene con certezza sui sistemi effettivamente interessati. E in entrambi i casi si riducono le aree non monitorate in cui gli incidenti possono svilupparsi inosservati. 

In conclusione, l’accuratezza del CMDB è una misura concreta della maturità della cybersecurity. Un CMDB aggiornato e completo non migliora soltanto l’erogazione dei servizi: indica quanto bene un’organizzazione conosce – e quindi può proteggere – tutti i dispositivi, le applicazioni e le connessioni che potrebbero esporla a un possibile attacco. La visibilità sugli asset garantita da un buon CMDB resta una delle difese più sottovalutate. Trattarlo come un semplice adempimento tecnico significa rinunciare a una capacità di protezione già presente nell’organizzazione, ma che deve essere resa più accurata, continua e condivisa. 

FAQs

1. Perché un CMDB è rilevante per la cybersecurity?
Perché fornisce la mappa aggiornata di tutti gli asset e delle loro dipendenze. Senza questa visibilità, i team della sicurezza non possono sapere con certezza cosa proteggere né dove applicare le patch. Gli asset non tracciati finiscono per restare esposti.

2. Quali carenze del CMDB creano rischi per la sicurezza?
Soprattutto endpoint non tracciati, software non autorizzato e integrazioni non documentate. Ogni elemento assente dal CMDB sfugge a monitoraggio, aggiornamenti e controlli, ampliando in silenzio la superficie di attacco.

3. Cosa distingue un CMDB «di livello security»?
Quattro requisiti: discovery continua anziché periodica, riconciliazione automatizzata tra stato rilevato e dati registrati, integrazione con il vulnerability management e una responsabilità chiara sulla proprietà dei dati.

4. CMDB e asset visibility: che relazione esiste tra i due?
La asset visibility è la capacità di sapere quali asset esistono e in che stato si trovano. Un CMDB accurato e continuamente aggiornato è lo strumento che rende possibile la asset visibility, ed è per questo un pilastro sia dell’ITSM sia della cybersecurity.