Mentre tutti discutono su quale modello scriva il codice migliore, un problema molto più vecchio e molto meno glamour sta crescendo silenziosamente insieme a ogni nuovo datacenter di IA: il controller di gestione della scheda madre, o BMC. Questa settimana i ricercatori di sicurezza hanno presentato risultati secondo cui migliaia di server connessi a Internet, prodotti dai principali produttori, possono essere compromessi da remoto attraverso vulnerabilità presenti in questi controller — alcune delle quali hanno più di dieci anni. Non è affatto una storia sull’IA. È una storia sull’hardware su cui gira l’IA, e vale la pena capirla se stai pensando da dove arriverà la prossima ondata di posti di lavoro nella sicurezza legata all’IA.

Che cos’è davvero un BMC e perché fa paura

Un BMC è un piccolo computer separato, saldato praticamente sulla scheda madre di ogni server aziendale. Esegue un proprio sistema operativo, un proprio stack di rete e ha un proprio indirizzo IP — del tutto indipendente dal sistema operativo e dalle applicazioni in esecuzione sul server principale. Gli amministratori usano i BMC per la gestione «lights-out» o «fuori banda»: riavviare una macchina, riscrivere il firmware, reinstallare un sistema operativo, tutto da remoto e, cosa fondamentale, anche quando il server principale è spento o completamente non reattivo.

Ed è esattamente questo a rendere così pericoloso un BMC compromesso. Un attaccante che riesce a entrarvi non ha bisogno che il sistema operativo host sia in esecuzione, non deve aggirare gli eventuali sistemi di sicurezza degli endpoint installati su di esso e può mantenere la persistenza anche dopo la reinstallazione del sistema operativo, perché il BMC si trova al di sotto e al di fuori del livello monitorato dai normali strumenti di sicurezza IT. Secondo la ricerca esaminata questa settimana, il protocollo più spesso coinvolto è IPMI e i ricercatori di sicurezza segnalano questa classe di rischio almeno dal 2013. In altre parole: non si tratta di un bug nuovo, ma di una categoria di bug vecchia, nota e strutturalmente difficile da correggere, che il settore ha tollerato per ben più di un decennio.

Perché ora è ancora più importante, non meno

La costruzione dell’infrastruttura per l’IA è, fisicamente, una delle più grandi ondate di acquisto di server della storia — rack su rack di server GPU installati nei datacenter nuovi o ampliati alla massima velocità con cui i fornitori riescono a consegnarli. Ogni singolo server viene fornito con un BMC, perché i BMC sono il modo in cui gli operatori dei datacenter gestiscono le flotte su larga scala; non si può entrare in un edificio grande quanto un magazzino e riavviare manualmente diecimila macchine. Il boom dell’IA quindi non sta acquistando solo capacità di calcolo: sta acquistando, per necessità, una flotta di dimensioni equivalenti composta da piccoli computer fuori banda, sottoposti a monitoraggio insufficiente e con una storia documentata di vulnerabilità critiche che dura da oltre un decennio.

Questo è il debito tecnico: la velocità di realizzazione è ottimizzata per installare i rack con le GPU e avviare i cicli di addestramento, non per verificare il firmware di gestione integrato in ogni scheda madre sottostante. Secondo quanto riferito, i ricercatori alla base della divulgazione di questa settimana hanno descritto i BMC come una «superficie d’attacco parallela pervasiva, sottoposta a monitoraggio e applicazione di patch insufficienti» — una descrizione precedente al boom dei datacenter per l’IA, ma è quel boom a moltiplicare proprio ora il numero di BMC in produzione.

La nicchia che si apre

Se stai delineando la direzione delle carriere nella sicurezza insieme all’infrastruttura per l’IA, la maggior parte degli ambiti più ovvi — red teaming dei modelli, difesa dagli attacchi di prompt injection, governance degli agenti — è già affollata e già ampiamente coperta altrove. La sicurezza dell’hardware e gli audit della sicurezza fuori banda, invece, no. È un angolo poco glamour e poco sexy della sicurezza delle infrastrutture, che non compare nei keynote sull’IA, ed è proprio qui il divario: la domanda cresce con ogni nuovo datacenter e l’offerta di persone che comprendono le superfici d’attacco a livello firmware e fuori banda è ridotta, perché si tratta davvero di un insieme di competenze diverso da quello della sicurezza delle applicazioni o del cloud.

In termini concreti, ecco in cosa consiste davvero il lavoro:

  • Conoscenza di firmware e protocolli. Comprendere IPMI (e i suoi punti deboli noti — come la suite di cifratura 0, deprecata da tempo, che alcuni dispositivi vengono ancora forniti con attiva) abbastanza bene da valutare se una determinata flotta di server è esposta, non soltanto vulnerabile in teoria.
  • Audit della segmentazione di rete. Verificare se le interfacce BMC/di gestione sono effettivamente isolate su una rete di gestione dedicata oppure se sono raggiungibili dalla produzione o da Internet in generale — un controllo di base che, sul campo, si rivela ripetutamente assente.
  • Verifiche di igiene delle credenziali e delle patch. I BMC vengono spesso forniti con credenziali predefinite o impostate dal fornitore e con firmware che non rientra nel normale ciclo di patch del sistema operativo del datacenter, perché non è il sistema operativo: è facile che finisca al di fuori delle competenze di chiunque sia responsabile del «patching».
  • Consapevolezza dei fornitori e della catena di approvvigionamento. Il firmware dei BMC è solitamente scritto da un numero ridotto di fornitori specializzati e concesso in licenza ai produttori di server, quindi una falla nel codice di un fornitore può propagarsi contemporaneamente a molti marchi hardware — è esattamente lo schema emerso nella divulgazione di questa settimana. Sapere quale stack firmware si trova sotto quale marchio di server fa parte del lavoro.

Come posizionarsi concretamente

Si tratta davvero di un settore di nicchia ed è giusto essere scettici sul numero di posizioni dedicate che verranno aperte, invece di rimanere una specializzazione all’interno dei team esistenti di infrastruttura o sicurezza — sii onesto con te stesso: «auditor della sicurezza BMC» potrebbe finire per essere una competenza da aggiungere a un ruolo più ampio nella sicurezza dell’hardware o dei datacenter, anziché un titolo professionale autonomo. Tuttavia, indipendentemente da questo, alcune iniziative concrete e verificabili hanno senso: fai esperienza pratica con IPMI e gli strumenti di gestione fuori banda, se hai accesso a server aziendali o anche a hardware di seconda mano su cui fare test in laboratorio; leggi gli avvisi di sicurezza dei fornitori relativi al firmware BMC dei principali produttori di server e firmware BMC, perché pubblicano divulgazioni reali di vulnerabilità che puoi studiare; e se lavori già nella sicurezza del cloud o delle infrastrutture, inizia a porre al team della tua organizzazione che si occupa del data center o degli acquisti hardware una domanda semplice e verificabile: la nostra rete di gestione BMC/IPMI è isolata e chi è responsabile dell’applicazione delle patch? Se nessuno sa dare una risposta sicura, non è soltanto un rilievo: è la dimostrazione esatta del tipo di competenza di cui questa nicchia ha bisogno.