Negli ambienti industriali non è più realistico costruire la sicurezza sull’ipotesi che ogni attacco possa essere fermato. La cyber resilienza parte da un presupposto diverso: un incidente può verificarsi e l’organizzazione deve essere preparata a contenerne gli effetti, mantenere le funzioni essenziali e riportare gli impianti a condizioni operative sicure nel minor tempo possibile.
La questione diventa quindi non soltanto tecnica, ma di governance: occorre stabilire responsabilità, obiettivi e soprattutto metriche capaci di indicare quanto un’organizzazione sia realmente resiliente.
Per anni, la cyber security industriale ha concentrato una parte significativa delle proprie strategie sulla prevenzione: impedire a un attaccante di entrare nella rete, proteggere gli endpoint, separare gli ambienti IT e OT e ridurre le vulnerabilità.
Sono controlli ancora indispensabili. Ma non sono sufficienti.
La crescente interconnessione degli impianti, l’integrazione tra IT e OT, il ricorso a servizi remoti e la dipendenza dalla supply chain rendono impossibile considerare il perimetro aziendale come una barriera completamente impermeabile.
La cyber resilienza industriale introduce quindi una prospettiva complementare: progettare sistemi e processi affinché l’organizzazione possa continuare a svolgere le proprie funzioni critiche anche quando una parte delle difese viene superata.
Essere resilienti non significa semplicemente possedere backup o un piano di disaster recovery.
In un ambiente OT significa conoscere quali processi debbano continuare a funzionare, quali possano essere temporaneamente degradati e quali sistemi debbano essere ripristinati per primi affinché l’impianto possa tornare a operare in sicurezza.
Un attacco ransomware, per esempio, può compromettere i sistemi IT senza raggiungere direttamente PLC o sistemi di controllo. Ma se vengono colpiti servizi indispensabili alla produzione, come autenticazione, gestione degli ordini, sistemi MES, engineering workstation o piattaforme utilizzate per configurare gli apparati, l’effetto sulla fabbrica può comunque essere significativo.
La resilienza deve pertanto essere valutata a livello di processo industriale, non soltanto di singolo sistema informatico.
Ciò richiede di identificare le dipendenze tra componenti IT e OT e di stabilire quali siano le funzioni minime necessarie per mantenere condizioni operative e di sicurezza accettabili durante un incidente.
La sicurezza tradizionale tende a chiedersi: come impediamo all’attaccante di entrare?
La cyber resilienza aggiunge una seconda domanda: cosa accade se riesce comunque a entrare?
La differenza modifica profondamente le priorità.
Firewall, segmentazione, sistemi di rilevamento e controllo degli accessi riducono la probabilità che l’incidente avvenga o si propaghi. Procedure di recovery, ridondanza, backup verificati, disponibilità dei ricambi, configurazioni salvate e personale addestrato determinano, invece, la capacità di reagire quando l’incidente si verifica.
In ambito industriale, il ripristino presenta inoltre vincoli specifici: riaccendere un server non equivale necessariamente a riavviare una linea produttiva in quanto devono essere verificate configurazioni, condizioni fisiche dell’impianto, interdipendenze tra macchinari e requisiti di safety.
La velocità del recovery, quindi, non può essere separata dalla sua affidabilità e sicurezza operativa.
Se la resilienza riguarda la capacità dell’impresa di continuare a operare, non può essere considerata responsabilità esclusiva del reparto cyber security.
Un fermo impianto produce conseguenze finanziarie, contrattuali, operative e reputazionali. La cyber resilienza diventa perciò una componente della gestione del rischio aziendale e deve essere governata come tale.
È anche il naturale sviluppo della valutazione del rischio operativo: individuare una vulnerabilità è importante, ma la governance deve stabilire quanto quella debolezza possa compromettere il business e quale capacità di risposta sia necessaria per mantenerne accettabile l’impatto.
Una governance efficace parte dall’attribuzione delle responsabilità.
Il vertice aziendale deve definire il livello di rischio accettabile e assicurare che siano disponibili risorse adeguate. CISO e responsabili della cyber security devono tradurre questi obiettivi in controlli, capacità di rilevamento e risposta. I responsabili OT devono valutare gli effetti delle decisioni di sicurezza sui processi fisici e sulla produzione.
A questi soggetti si aggiungono business continuity, risk management, IT, manutenzione, safety e, quando necessario, fornitori e system integrator.
Il problema emerge quando tali responsabilità rimangono separate.
Un CISO può stabilire che un determinato sistema debba essere isolato, ma soltanto chi conosce il processo produttivo può valutare le conseguenze dell’isolamento. Allo stesso modo, il responsabile di stabilimento può conoscere il tempo necessario per riavviare una linea, ma deve confrontarsi con chi può verificare che i sistemi utilizzati per il riavvio siano affidabili e non ancora compromessi.
La resilienza richiede quindi decisioni condivise prima dell’incidente, non improvvisate durante l’emergenza.
La cyber resilienza deve entrare nei processi di Enterprise Risk Management attraverso scenari concreti.
Quanto costa un’ora di fermo di una determinata linea? Per quanto tempo l’organizzazione può operare in modalità degradata? Quali fornitori sono indispensabili per il recovery? Quanto tempo serve per ottenere un ricambio critico? Esistono procedure manuali alternative?
Rispondere a queste domande consente di collegare la cyber security alle conseguenze sul business.
La gestione del rischio dovrebbe quindi partire dai processi critici, ricostruirne le dipendenze tecnologiche e definire obiettivi di resilienza coerenti con la loro importanza.
In questo modo, gli investimenti possono essere prioritizzati sulla base dell’effettivo impatto operativo anziché esclusivamente sulla severità tecnica delle vulnerabilità.
Ciò che non viene misurato, difficilmente può essere governato.
Anche nella cyber resilienza servono quindi indicatori capaci di mostrare al management se le capacità di prevenzione, risposta e recovery stiano migliorando o peggiorando.
Le metriche IT tradizionali costituiscono un punto di partenza, ma negli ambienti industriali devono essere correlate alle conseguenze sul processo fisico.
Tra gli indicatori più utilizzabili figurano il Mean Time to Detect (MTTD) e il Mean Time to Respond (MTTR), che consentono di valutare quanto rapidamente un’organizzazione riesca a individuare e gestire un incidente.
Nell’OT, tuttavia, è particolarmente importante misurare anche il tempo necessario per recuperare realmente il processo produttivo.
Un sistema può risultare tecnicamente ripristinato mentre la linea non è ancora pronta a tornare in produzione. Per questo motivo il recovery dovrebbe essere misurato fino al raggiungimento di uno stato operativo definito e verificato.
Anche Recovery Time Objective (RTO) e Recovery Point Objective (RPO) devono essere adattati al contesto industriale. Per alcuni sistemi la perdita di dati può essere il problema principale; per altri sono soprattutto configurazioni, logiche di controllo e disponibilità dell’impianto a determinare la criticità.
L’indicatore realmente utile non è quindi soltanto quanto velocemente sia stato recuperato un server, ma quanto tempo sia necessario per riportare il processo industriale a uno stato sicuro e produttivo.
Le metriche tecniche acquistano maggiore valore quando vengono correlate a indicatori economici.
Ore di produzione perse, quantità di prodotto non realizzato, costi di fermo, penali contrattuali, interventi straordinari di manutenzione e tempo necessario al ritorno alla piena capacità permettono di trasformare un incidente cyber in un impatto comprensibile anche al management.
Si possono inoltre monitorare la percentuale di asset critici coperti da sistemi di rilevamento, la disponibilità di backup validati delle configurazioni, il numero di dipendenze critiche prive di ridondanza e la percentuale di sistemi per i quali esiste una procedura di recovery testata.
L’obiettivo non dovrebbe però essere accumulare KPI.
Una metrica di resilienza è utile quando permette di rispondere a una domanda decisionale: quanto siamo preparati a mantenere o ripristinare una funzione critica entro il tempo che il business considera sostenibile?
La cyber resilienza si costruisce prima dell’incidente.
Tecnologie, architetture e procedure devono essere progettate partendo dall’ipotesi che alcuni componenti possano diventare indisponibili o non affidabili e che l’organizzazione debba continuare a gestire in sicurezza il processo industriale.
La ridondanza riduce la dipendenza da singoli punti di guasto, ma deve essere progettata considerando anche il rischio cyber.
Due sistemi identici, connessi alla stessa rete e amministrati attraverso le stesse credenziali, possono essere compromessi dallo stesso attacco. La ridondanza puramente tecnologica non coincide quindi necessariamente con la resilienza.
La segmentazione consente, invece, di limitare la propagazione dell’incidente e isolare le aree compromesse mantenendo operative quelle non coinvolte. Negli ambienti industriali questo principio deve essere applicato rispettando le esigenze di disponibilità, latenza e comunicazione dei processi.
Particolare attenzione richiedono infine i backup.
Non basta sapere che esistono: devono essere protetti da modifiche non autorizzate, separati in maniera adeguata dall’ambiente operativo e soprattutto testati. Oltre ai dati, nell’OT può essere necessario conservare configurazioni di PLC, firmware, immagini dei sistemi, programmi applicativi, parametri e documentazione indispensabile alla ricostruzione dell’impianto.
Un incident response plan pensato esclusivamente per l’IT rischia di fallire in fabbrica.
Le procedure devono indicare chi possiede l’autorità per fermare un impianto, quali sistemi possono essere isolati, quali verifiche sono necessarie prima del riavvio e come coordinare cybersecurity, produzione, manutenzione e safety.
Devono, inoltre, prevedere scenari nei quali i normali strumenti digitali di comunicazione non siano disponibili.
Esercitazioni tabletop e simulazioni periodiche consentono di verificare se il piano sia realmente applicabile e fanno emergere dipendenze che difficilmente vengono individuate sulla carta: numeri di telefono non aggiornati, backup non recuperabili, fornitori non disponibili, procedure incomplete o personale che non conosce le proprie responsabilità.
Il test è, quindi, parte integrante della resilienza. Un piano di recovery mai provato descrive una capacità presunta, non una capacità dimostrata.
La resilienza sta diventando uno dei principi centrali della regolamentazione europea sulla cyber security.
Per le imprese industriali questo significa passare progressivamente da una logica basata sulla presenza di singoli controlli a una gestione strutturata e documentabile del rischio lungo l’intero ecosistema tecnologico.
La direttiva NIS2 rafforza questa impostazione richiedendo ai soggetti che rientrano nel suo campo di applicazione misure tecniche, operative e organizzative adeguate e proporzionate alla gestione dei rischi.
Tra gli ambiti previsti rientrano gestione degli incidenti, business continuity, disaster recovery, crisis management, sicurezza della supply chain, gestione delle vulnerabilità, controllo degli accessi e utilizzo di soluzioni di autenticazione appropriate.
Particolarmente rilevante sul piano della governance è il coinvolgimento degli organi di gestione, chiamati ad approvare le misure di gestione del rischio cyber e a supervisionarne l’attuazione. La resilienza diventa così anche una responsabilità manageriale.
Il Cyber Resilience Act (CRA) opera invece su un piano differente. Il regolamento europeo introduce requisiti di cybersecurity per i prodotti con elementi digitali lungo il loro ciclo di vita, imponendo obblighi principalmente a fabbricanti e altri operatori economici.
Per gli ambienti OT, le due normative non devono quindi essere sovrapposte: NIS2 riguarda la gestione del rischio delle organizzazioni comprese nel suo perimetro, mentre il CRA interviene sulla sicurezza dei prodotti digitali immessi sul mercato.
La convergenza dei due approcci contribuisce però a rafforzare un principio importante per la cyber resilienza industriale: organizzazioni resilienti richiedono anche tecnologie progettate, mantenute e aggiornate tenendo conto del rischio cyber.
Per tradurre questi principi nell’ambiente industriale, la serie di standard IEC 62443 rappresenta uno dei principali riferimenti internazionali per la cyber security dei sistemi di automazione e controllo industriale.
Il framework affronta il rischio attraverso un approccio che considera organizzazioni, processi, sistemi e componenti e attribuisce responsabilità ai diversi soggetti coinvolti nell’ecosistema industriale.
Particolarmente rilevanti sono i concetti di zone e conduits, attraverso i quali sistemi con requisiti di sicurezza analoghi possono essere raggruppati e le comunicazioni tra aree differenti controllate. L’approccio consente di applicare segmentazione e livelli di protezione coerenti con il rischio.
IEC 62443 permette inoltre di collegare requisiti organizzativi e tecnici, offrendo una base utile per definire target di sicurezza e percorsi di miglioramento misurabili.
Ma nessun framework, da solo, rende resiliente un impianto.
La cyber resilienza emerge dalla capacità dell’organizzazione di conoscere i propri processi critici, misurarne le dipendenze, prepararsi agli scenari di compromissione e verificare periodicamente che persone, tecnologie e procedure siano realmente in grado di reagire.
Il cambio di prospettiva è sostanziale: non chiedersi soltanto quante barriere siano state costruite contro un attacco, ma per quanto tempo l’impresa sia in grado di continuare a operare quando una di quelle barriere viene superata.
È questa capacità, misurabile attraverso indicatori tecnici e di business, che trasforma la resilienza da principio astratto a elemento concreto della governance industriale.