Il rischio che nessuno possiede: regolatori di potenza e il vuoto di governance

Sotto il sistema operativo, sotto il radar del board, c'è un layer che può spegnere tutto — e oggi non ha un owner

L'infrastruttura invisibile che tiene accesi i server

Proteggi gli endpoint. Proteggi la rete. Proteggi il sistema operativo. Ma chi protegge la corrente che li alimenta? I regolatori di potenza DC, i componenti che stabilizzano la tensione elettrica per server, infrastrutture di telecomunicazione, data center, veicoli connessi, hanno smesso da tempo di essere dispositivi passivi. Oggi sono sistemi programmabili, governati da firmware, aggiornabili da remoto. E già presenti nel National Vulnerability Database con decine di CVE documentate. Il punto è che questi dispositivi operano sotto il livello del sistema operativo. Significa che nessun antimalware, nessun agent di monitoraggio, nessuna soluzione di endpoint detection li vede. Andy Davis, Global Research Director di NCC Group, ha osservato che molti attacchi a questo livello di infrastruttura vengono oggi classificati come guasti fisici inspiegabili, non come incidenti di sicurezza. Chad LeMaire, CISO di ExtraHop, conferma la stessa lettura: un regolatore compromesso può causare shutdown o danni hardware senza generare un singolo alert nei sistemi di monitoraggio tradizionali. Non è un rischio teorico. È un vettore emergente che si nasconde nell'angolo cieco più profondo dell'architettura.

Quando l'alimentazione diventa un vettore di attacco

Il rischio scala in due direzioni, ed entrambe riguardano il board, non il SOC. A livello locale, un singolo regolatore compromesso può colpire simultaneamente più server collegati alla stessa linea di alimentazione, generando un denial-of-service senza che venga trasmesso un solo pacchetto malevolo sulla rete. A livello data center, l'impatto diventa massivo: un'interruzione controllata dell'alimentazione equivale a un'interruzione totale del servizio. Per le organizzazioni che operano in settori ad alta dipendenza infrastrutturale, telecomunicazioni, finance, cloud, questo si traduce in un rischio di continuità operativa che oggi non compare in nessun threat model e non è assegnato a nessuna funzione. C'è poi la dimensione supply chain: il firmware embedded nei regolatori proviene da terze parti e ne eredita tutte le vulnerabilità, esattamente come qualsiasi altro codice nella catena di fornitura tecnologica. Gary Schwartz, SVP di NetRise, ha sottolineato come questa superficie d'attacco venga sistematicamente ignorata nelle valutazioni di rischio della supply chain software. Non è un problema tecnico confinato all'ingegneria elettrica. È un rischio strategico non presidiato.

La terra di nessuno organizzativa

Ecco la frizione reale. Il regolatore di potenza DC vive in un limbo organizzativo che nessuna matrice RACI ha mai mappato. Non rientra nel perimetro del responsabile della sicurezza informatica, perché opera sotto il sistema operativo, quindi è "fuori scope". Non è nel radar del facility management, che lo monitora per efficienza energetica e consumo, non per integrità del firmware. Non è nell'asset inventory di sicurezza. Non è nel threat model. Non è oggetto di penetration test, né di vulnerability assessment. È un componente critico per la continuità operativa dell'intera organizzazione, eppure nessuno ne possiede formalmente il rischio cyber. Questa è la patologia classica della governance a silos: quando un asset attraversa i confini di più funzioni senza appartenere a nessuna, la responsabilità si scopre solo dopo l'incidente. E dopo l'incidente, si scopre anche che nessuno aveva l'autorità per decidere investimenti, controlli o remediation su quel layer. Il problema non è tecnico. È strutturale. È un difetto di design organizzativo che nessun tool può compensare.

Il quadro normativo: un obbligo implicito, non ancora esplicito

Nessuna normativa europea cita esplicitamente i regolatori di potenza DC. Questo va detto con chiarezza. Tuttavia, i principi di governance del rischio contenuti nei framework regolatori più recenti creano un perimetro di responsabilità che è difficile ignorare. La Direttiva NIS2, all'articolo 21, impone ai soggetti essenziali e importanti misure di gestione del rischio che coprono la sicurezza della supply chain e la resilienza delle infrastrutture, e i regolatori firmware-driven sono a tutti gli effetti componenti della catena di fornitura tecnologica. DORA richiede alle entità finanziarie di garantire la resilienza operativa digitale, includendo l'infrastruttura fisica sottostante ai sistemi ICT. La Direttiva CER sulla resilienza delle entità critiche estende la copertura alla dimensione fisica e cyber delle infrastrutture digitali ed energetiche. Il collegamento è credibile come principio di accountability, anche se non ancora codificato come obbligo puntuale. Ma la direzione regolatoria è chiara: la responsabilità si estende verso il basso, verso i layer fisici, verso la supply chain embedded. Attendere una menzione esplicita prima di agire è una scelta di governance, non una scelta di compliance.

La domanda che il board non si è ancora posto

Se domani un regolatore di potenza compromesso spegnesse il vostro data center principale, chi ne risponderebbe? Il responsabile della sicurezza informatica, che non aveva quel componente nel proprio threat model? Il CTO, che lo considerava un dispositivo elettrico fuori dal proprio perimetro? Il facility manager, che lo monitorava solo per efficienza energetica? La risposta, oggi, è nessuno. E questa è esattamente la condizione che trasforma un rischio tecnico gestibile in una crisi di governance. Il vettore esiste. Le vulnerabilità sono documentate. Il layer è invisibile agli strumenti di sicurezza convenzionali. L'unica cosa che manca è un owner. Nelle organizzazioni mature, il rischio senza owner è il rischio più pericoloso, non perché sia il più probabile, ma perché quando si materializza nessuno ha l'autorità, il budget o il mandato per rispondere. La questione non è se questo rischio meriti attenzione. La questione è chi, nella vostra organizzazione, ha il mandato per decidere che non la merita.

Un componente che nessuno possiede, un rischio che nessuno modella, un layer che nessuno monitora. La governance si misura proprio lì, negli spazi che cadono tra le responsabilità di tutti.