NIST CSF 2.0 applicato all'OT: come usarlo come roadmap per le PMI italiane

NIST CSF 2.0: cosa cambia rispetto alla versione precedente

Il NIST Cybersecurity Framework ha avuto un ruolo importante nel dare struttura alla conversazione sulla sicurezza informatica anche al di fuori degli Stati Uniti. La versione 2.0, pubblicata nel 2024, introduce alcune novità significative rispetto alla versione 1.1.

La più rilevante è l'aggiunta di una sesta funzione: Govern. Le cinque funzioni originali (Identify, Protect, Detect, Respond, Recover) descrivevano capacità tecniche e operative. Govern riconosce che la cybersecurity non è solo un problema tecnico: richiede governance, accountability, policy, ruoli definiti, integrazione con la strategia aziendale. Una capacità tecnica di detection eccellente in un'organizzazione senza governance è fragile: dipende dalle persone giuste al posto giusto, non da processi stabili.

Altre novità di rilievo: il CSF 2.0 espande esplicitamente la copertura ai sistemi OT e alle tecnologie operative, che nella versione 1.1 erano menzionate marginalmente. La versione 2.0 include profili specifici per settori, tra cui esempi per infrastrutture critiche e ambienti industriali. Questo non è un framework pensato solo per l'IT enterprise.

Una cosa che non cambia: NIST CSF non è uno standard cogente. Non è obbligatorio per legge in Italia (a differenza della NIS2). E' uno strumento volontario di self-assessment e pianificazione. Questa caratteristica è un punto di forza: si può usare come bussola per prioritizzare investimenti senza dover dimostrare conformità a un auditor esterno.

Govern: costruire la governance OT prima delle tecnologie

La funzione Govern è trasversale alle altre cinque: definisce il contesto organizzativo in cui le capacità di sicurezza operano. Per un ambiente OT manifatturiero, Govern include:

Definizione dei ruoli e delle responsabilità: chi è responsabile della sicurezza OT? Non necessariamente un CISO dedicato (molte PMI non ne hanno uno), ma una persona o un team che ha la responsabilità esplicita di gestire il rischio cyber nell'impianto. Senza questa chiarezza, le decisioni di sicurezza OT vengono rimandate indefinitamente o delegate a chi non ha il mandato per prenderle.

Risk management strategy: qual è la propensione al rischio dell'organizzazione? Quanto è disposta a investire per ridurre il rischio cyber rispetto ad altri investimenti operativi? Questa non è una decisione tecnica: è una decisione di business che deve coinvolgere il management. La funzione Govern di NIST CSF 2.0 chiede che questa strategia sia esplicita e documentata.

Policy e procedure: regole scritte su come si gestisce la sicurezza OT. Non volumi normativi: poche pagine chiare su accessi, gestione vulnerabilità, incident reporting. Il valore delle policy non è burocratico: è dare un riferimento esplicito che permette di verificare se il comportamento reale è allineato.

Oversight e revisione: la governance richiede meccanismi di verifica periodica. Il management sa come sta andando la sicurezza OT? Ci sono metriche che vengono portate in riunione periodicamente? La funzione Govern chiede che la sicurezza cyber sia integrata nella gestione ordinaria dell'organizzazione, non relegata a un'attività tecnica invisibile.

Identify: sapere cosa si ha

La funzione Identify è il punto di partenza logico per qualsiasi programma di sicurezza OT. NIST CSF 2.0 la suddivide in: asset management, risk assessment, improvement (quest'ultima è nuova nella 2.0).

Asset management OT: costruire e mantenere un inventario degli asset di controllo industriale. Chi sono i dispositivi sulla rete OT? PLC, HMI, SCADA server, historian, dispositivi di campo intelligenti, workstation degli ingegneri. Per ogni asset: modello, versione firmware, criticità operativa, responsabile. Senza questo inventario, le decisioni di sicurezza successive non hanno base.

Mappatura delle dipendenze: non basta sapere che gli asset esistono. Serve capire le relazioni tra di essi: quale PLC dipende da quale server di configurazione? Quale processo si ferma se va offline un certo historian? Le dipendenze critiche devono essere mappate per capire dove concentrare le misure di protezione prioritarie.

Risk assessment: una valutazione del rischio OT non è la stessa cosa di una valutazione del rischio IT. Le conseguenze di un incidente in un impianto produttivo includono fermi linea, danni fisici, rischi per la sicurezza degli operatori, impatto ambientale. La valutazione del rischio deve tenere conto di queste conseguenze specifiche, non limitarsi alla confidenzialità e all'integrità dei dati.

Un self-assessment Identify ben condotto risponde a: "Se dovesse accadere un attacco informatico al nostro impianto, dove colpisce di più? Quali asset critici sono più vulnerabili?"

Protect: ridurre la superficie di attacco

La funzione Protect copre le misure preventive per limitare l'impatto di un potenziale incidente. In un ambiente OT, le categorie principali sono:

Controllo degli accessi: chi può accedere ai sistemi OT, come, da dove. Accessi fisici ai quadri di controllo, accessi remoti dei vendor, credenziali di amministrazione dei PLC. Un controllo degli accessi efficace in OT richiede di uscire dalla logica delle password condivise e degli account generici, verso account nominali con accessi minimi necessari.

Segmentazione della rete: separare fisicamente o logicamente le reti OT dalla rete IT e da internet. Non solo firewall tra IT e OT: anche segmentazione interna tra zone OT con livelli di criticità diversi. Un dispositivo di campo non dovrebbe poter comunicare direttamente con una workstation di ingegneria senza passare per un punto di controllo.

Hardening dei sistemi: disabilitare servizi non necessari, cambiare le credenziali di default, applicare le patch disponibili dove possibile. Su sistemi legacy dove il patching non è praticabile, documentare le misure compensative adottate.

Gestione dei media rimovibili: le chiavette USB sono ancora uno dei vettori di attacco più comuni nelle reti OT air-gapped o parzialmente segmentate. Policy e controlli tecnici per la gestione dei dispositivi rimovibili che entrano in contatto con i sistemi OT sono una misura di protezione fondamentale.

Awareness e formazione: le persone che interagiscono con i sistemi OT (operatori, tecnici di manutenzione, integratori esterni) devono avere una consapevolezza minima delle pratiche di sicurezza. Non serve un corso di ethical hacking: basta capire perché non si collega una chiavetta trovata nel parcheggio a una workstation SCADA.

Detect: vedere prima che sia troppo tardi

La funzione Detect è dove molte PMI manifatturiere italiane hanno il gap più evidente. Protect e Identify vengono trattati, con qualità variabile. Detect viene spesso ignorato del tutto: si installa il firewall, si segmenta la rete, e ci si aspetta che questo basti.

Il problema è che le misure preventive falliscono. Sempre. La domanda non è se un attaccante riuscirà a bypassare le difese: è quando lo farà, e quanto velocemente verrà rilevato.

Continuous monitoring della rete OT: sensori passivi che catturano il traffico di rete OT e lo analizzano per rilevare anomalie. Nuovi dispositivi apparsi sulla rete, comunicazioni verso destinazioni insolite, modifiche alla configurazione dei PLC fuori dalle finestre di manutenzione, comportamenti di protocollo inusuali.

Anomaly detection basata su baseline: stabilire il profilo normale di comportamento per ogni asset OT (con chi comunica, su quali protocolli, con quale frequenza) e rilevare le deviazioni. Questa è la logica fondamentale del monitoring OT passivo.

Gestione degli alert: rilevare non basta. Gli alert devono essere esaminati da qualcuno con il contesto per interpretarli. Un processo di triage degli alert OT, anche semplice, è necessario per trasformare la detection in risposta.

Threat intelligence OT: conoscere le minacce rilevanti per il proprio settore e aggiornare le regole di detection di conseguenza. Le campagne APT verso il manifatturiero europeo lasciano indicatori di compromissione documentati; usarli per configurare le regole di alerting è un modo per aumentare la probabilità di detection precoce.

Respond e Recover: prepararsi prima che succeda

Le funzioni Respond e Recover sono spesso trascurate in favore di Protect, con il ragionamento implicito che se le difese tengono non ci sarà nulla da gestire. Questo ragionamento è pericoloso.

Incident response OT: avere un piano di risposta agli incidenti specifico per gli scenari OT. La risposta a un incidente in un impianto produttivo è diversa dalla risposta IT: il "spegni e isola" può causare danni fisici o fermare la produzione in modo non controllato. Il piano deve definire chi decide di fermare un processo produttivo durante un incidente, con quale autorità, e come.

Recovery dei sistemi OT: avere backup delle configurazioni dei PLC e dei sistemi SCADA, testati periodicamente. Il ripristino di un PLC da un backup è un'operazione tecnica che richiede competenze specifiche: è meglio scoprirlo in un test pianificato che durante un'emergenza.

Comunicazione durante l'incidente: chi viene informato internamente (management, operations, produzione), chi viene informato esternamente (clienti, autorità come ACN per la notifica NIS2, vendor OT). Le comunicazioni durante un incidente devono essere gestite in modo coordinato per evitare informazioni contraddittorie e danni reputazionali.

Post-incident review: dopo ogni incidente, anche quelli minori, condurre una revisione per capire cosa ha funzionato e cosa no. Le lezioni apprese devono aggiornare i piani e le procedure.

CSF 2.0 come strumento di roadmap

Il modo più pratico di usare NIST CSF 2.0 come roadmap è il profile: creare un "profilo corrente" che descrive lo stato attuale delle capacità per ogni funzione, e un "profilo target" che descrive dove si vuole arrivare in un orizzonte temporale definito (12-24 mesi).

Il gap tra profilo corrente e profilo target diventa la roadmap di investimento: cosa fare prima, cosa può aspettare, dove concentrare le risorse limitate. Le PMI con budget limitati devono prioritizzare, e NIST CSF 2.0 fornisce una struttura per farlo in modo ragionato invece che reattivo.

Un approccio pratico per iniziare: un workshop di mezza giornata con il responsabile tecnico e il management, usando le sei funzioni come guida, per rispondere onestamente alla domanda "dove siamo?" per ogni area. Il risultato non deve essere perfetto: deve essere onesto e condiviso. Da lì si costruisce un piano di miglioramento realistico, con priorità basate sul rischio effettivo e sulle risorse disponibili.

---

NIST CSF 2.0 non è uno strumento di compliance nel senso tradizionale: non esiste un audit che certifica la conformità al framework. E' uno strumento di gestione del rischio che aiuta a strutturare il pensiero e a comunicare la postura di sicurezza in modo comprensibile al management. Per le PMI manifatturiere italiane che stanno cercando un punto di partenza per affrontare la sicurezza OT in modo sistematico, questo è il suo valore principale.

L'angolo MON5

Le funzioni del CSF 2.0 si mappano in modo naturale sul percorso MON5: Identify corrisponde alla fase DISCOVER (asset discovery passiva, topologia, dipendenze) e ad ANALYZE (inventario continuo, correlazione delle CVE con EPSS ed esposizione reale); Detect corrisponde a PROTECT, con monitoraggio continuo e anomaly detection ML sui protocolli OT nativi. Il gap su Detect, che l'articolo indica come il più diffuso nelle PMI italiane, si può quindi colmare per fasi, senza un progetto monolitico.

Anche il profilo corrente del framework richiede dati: sapere davvero cosa c'è in rete. Un buon modo per costruirlo su misure reali è partire da un assessment OT.