Metriche OT per il board: come tradurre la sicurezza industriale in numeri decisionali

Il problema delle metriche di compliance nell'OT

Il responsabile OT o il CISO che deve presentare al consiglio di amministrazione o alla proprietà la postura di sicurezza degli impianti si trova spesso di fronte a un problema di traduzione. Le metriche che ha a disposizione sono tecniche: numero di vulnerabilità rilevate, versioni firmware obsolete, regole di firewall configurate. Il pubblico vuole sapere se è al sicuro, se sta investendo nel modo giusto, se può dormire tranquillo.

Il gap più comune è quello tra le metriche di compliance e le metriche di rischio. Una checklist NIS2 che segna "conforme" su dieci punti dà un'indicazione di processo, non di rischio reale. Un board che vede una lista di check verdi può ragionevolmente concludere che la situazione è sotto controllo, anche quando i dispositivi critici dell'impianto hanno vulnerabilità critiche non risolte da anni.

Il punto non è che la compliance sia irrilevante: è che da sola non risponde alla domanda che interessa davvero al management, ovvero "se succede qualcosa, quanto ci costa?". Le metriche utili per il board devono collegare la postura tecnica all'impatto operativo: downtime potenziale, linee di produzione a rischio, costo per ora di fermo.

KPI fondamentali: cosa misurare e come

Un set di KPI per la sicurezza OT deve essere limitato (il board non ha tempo per venti indicatori) e deve essere stabile nel tempo per permettere il confronto tra periodi diversi. Cinque o sei metriche, aggiornate mensilmente, valgono più di una dashboard affollata.

Percentuale di asset OT con vulnerabilità critiche non mitigate. Questo indicatore misura quanti dispositivi nell'inventario OT hanno almeno una CVE con punteggio critico (CVSS >= 9.0 o EPSS > 0.5) per cui non è stato implementato un compensating control documentato. Non conta le vulnerabilità in assoluto, ma quelle per cui non è stata presa una decisione esplicita. Un dispositivo con una CVE critica per cui il team ha documentato "impossibile patchare, isolato in VLAN dedicata con ACL" non è nella stessa categoria di un dispositivo vulnerabile e completamente ignorato.

Numero di asset OT non censiti nell'inventario. La differenza tra il numero di dispositivi che il monitoring passivo vede sulla rete e il numero di dispositivi nel registro ufficiale. Ogni dispositivo non censito è un punto cieco: non sappiamo se è autorizzato, non sappiamo la sua versione firmware, non sappiamo se ha vulnerabilità. Un delta positivo (vedo più dispositivi di quanti ne ho censiti) è un segnale di attenzione da investigare.

Copertura del monitoring per zona di rete OT. Quale percentuale delle zone OT definite nell'architettura ha copertura di monitoraggio passivo? Espresso per zona e per criticità: una zona critica senza copertura pesa diversamente da una zona periferica non monitorata. Questo KPI misura i punti ciechi noti: sappiamo che non vediamo, e sappiamo dove.

Mean Time to Detect (MTTD) per anomalie OT. Il tempo medio che passa tra il momento in cui un comportamento anomalo diventa rilevabile (un nuovo dispositivo appare in rete, una comunicazione fuori baseline inizia) e il momento in cui viene preso in carico da un analista. Nell'OT questo indicatore è particolarmente significativo perché gli attacchi più sofisticati si muovono lentamente: un MTTD di ore invece che di giorni cambia radicalmente la capacità di contenimento.

Percentuale di dispositivi OT con firmware nella versione supportata dal vendor. Distinto dal KPI sulle vulnerabilità critiche: questo misura quanti dispositivi sono fuori dal ciclo di supporto del vendor, ovvero non riceveranno nuove patch di sicurezza indipendentemente dalle CVE specifiche. I dispositivi end-of-life in ambiente OT tendono ad accumularsi silenziosamente per anni.

KRI: segnali anticipatori di deterioramento

I KPI misurano lo stato attuale. I KRI (Key Risk Indicator) segnalano tendenze che, se non corrette, porteranno a un peggioramento. Per il board, i KRI sono spesso più utili dei KPI perché permettono decisioni proattive invece che reattive.

Variazione mensile dell'inventario non spiegata. Quanti dispositivi nuovi sono apparsi in rete nel mese corrente rispetto alla baseline, esclusi quelli previsti da ordini di lavoro o progetti di ampliamento. Un aumento costante suggerisce che i processi di gestione del cambiamento non funzionano: i dispositivi vengono connessi senza passare per il processo di autorizzazione.

Trend delle vulnerabilità critiche non mitigate. Non il numero assoluto, ma la direzione: il numero di vulnerabilità critiche non mitigate sta crescendo, rimanendo stabile o diminuendo? Una crescita costante, anche partendo da numeri bassi, indica che il processo di remediation (o di valutazione e accettazione del rischio residuo) non sta tenendo il passo con la scoperta di nuove vulnerabilità.

Accessi remoti fuori orario o fuori procedura. Il numero di sessioni di accesso remoto ai sistemi OT che avvengono fuori dalle finestre di manutenzione autorizzate o senza ticket associato. Nell'OT, l'accesso remoto non autorizzato è uno dei vettori di compromissione più frequenti; monitorarne il trend nel tempo rivela se i controlli sugli accessi remoti stanno funzionando.

Alert OT chiusi senza investigation. Quanti alert generati dal sistema di monitoring vengono chiusi automaticamente o con una risoluzione "rumore" senza che ci sia una vera analisi? Un tasso crescente può indicare due cose: le regole di detection stanno generando troppi falsi positivi (e vanno riviste) oppure gli analisti sono sovraccarichi e chiudono alert senza esaminarli (e vanno aggiunte risorse). Entrambe sono situazioni di rischio.

Come presentare le metriche al board

Il formato conta quanto i numeri. Alcune indicazioni pratiche per rendere le metriche OT accessibili a un pubblico non tecnico.

Collega ogni metrica a un impatto operativo concreto. Non "il 30% degli asset ha CVE critiche non mitigate" ma "il 30% degli asset include quattro PLC sulle linee A, B e C: un attacco su questi dispositivi potrebbe fermare la produzione per un tempo stimato di X ore, con un costo di X euro". Il collegamento al rischio operativo richiede un lavoro di assessment preliminare con il team operations, ma trasforma la metrica da tecnica a decisionale.

Usa il confronto temporale. Una metrica in isolamento non dice niente. La stessa metrica a tre mesi di distanza dice se la situazione sta migliorando o peggiorando. Il trend è il dato più utile per il board: non "siamo al 30%" ma "eravamo al 45% tre mesi fa, siamo al 30% oggi, l'obiettivo entro fine anno è il 15%".

Semaforizza con soglie esplicite. Definire preventivamente le soglie di verde, giallo e rosso per ogni KPI elimina l'ambiguità interpretativa e riduce la tendenza a presentare sempre tutto come "sotto controllo". Le soglie devono essere discusse e approvate dal management: quando il MTTD supera X ore, si è in giallo; quando supera Y ore, si è in rosso e si attiva una procedura specifica.

Separa il reporting operativo da quello strategico. Il SOC o il team OT ha bisogno di metriche granulari e frequenti. Il board ha bisogno di quattro o cinque indicatori sintetici, una volta al trimestre, con un'interpretazione chiara di cosa significano e cosa si sta facendo. Non portare al board la lista dei 200 CVE aperti: porta la percentuale di asset critici coperti da remediation plan con scadenza.

Errori comuni da evitare

Metriche che crescono sempre verso il bene. Se ogni metrica che si presenta al board mostra un miglioramento trimestrale dopo trimestrale, il board dovrebbe fare domande. Una postura di sicurezza reale in un ambiente reale ha periodi di peggioramento, picchi durante cambiamenti di impianto, regressioni. Un cruscotto che mostra solo progresso costante è probabilmente mal calibrato o selettivo.

Metriche senza denominatore. "Abbiamo rilevato 150 anomalie questo mese" non dice niente senza sapere quante anomalie sono state investigate, quante erano reali minacce, quante erano falsi positivi. Le metriche assolute senza contesto creano aspettative sbagliate.

KPI di compliance come surrogato di rischio. Aver completato il questionario di autovalutazione NIS2, aver prodotto il registro degli asset richiesto da IEC 62443, aver aggiornato le procedure scritte: tutto questo è necessario ma non misura il rischio reale. Un'organizzazione può essere formalmente conforme e sostanzialmente esposta. Il board deve capire la differenza.

Ignorare il rischio residuo documentato. Se il team ha documentato che dieci dispositivi hanno vulnerabilità critiche non mitigabili e ha adottato compensating controls, queste vulnerabilità non devono sparire dalle metriche come se non esistessero. Devono essere visibili come "rischio residuo consapevolmente accettato con misure compensative". La differenza tra rischio accettato e rischio ignorato è cruciale per una governance responsabile.

L'angolo MON5

Asset non censiti, vulnerabilità critiche non mitigate, copertura del monitoring, MTTD: i KPI e i KRI di questo articolo esistono solo se qualcosa li misura in modo continuo. MON5 li produce come sottoprodotto del suo funzionamento: l'inventario asset continuo evidenzia il delta tra dispositivi visti in rete e dispositivi censiti, la correlazione delle CVE con score EPSS ed esposizione reale distingue il rischio gestito da quello ignorato.

Il percorso modulare permette di partire in piccolo e ampliare le metriche per fasi, dal singolo sito al gruppo multi-stabilimento. Per stabilire la baseline del primo cruscotto da portare al board, comincia con un assessment OT.