Blog Zscaler

Ricevi gli ultimi aggiornamenti dal blog di Zscaler nella tua casella di posta

Prodotti e soluzioni

Sicurezza OT: Cosa cambia per le infrastrutture critiche con le linee guida "Prepare to Disconnect" di CI Fortify

image

In breve: CI Fortify è una guida congiunta pubblicata il 28 luglio 2026 dalla CISA, l'ACSC dell'Australian Signals Directorate, l'FBI, l'NCSC del Regno Unito e il Canadian Centre for Cyber Security. Richiede agli operatori di infrastrutture critiche di essere in grado di isolare i sistemi OT vitali da tutte le altre reti durante un incidente informatico per continuare a garantire i servizi essenziali anche se disconnessi. Per la maggior parte degli ambienti OT, il problema non è tanto il piano quanto l'architettura tecnica: le reti piatte non dispongono di punti di isolamento predisposti in anticipo che consentano di attuarlo.


Il 28 luglio 2026, la CISA, insieme all'ACSC dell'Australian Signals Directorate, all'FBI, al NCSC del Regno Unito e al Canadian Centre for Cyber Security, ha pubblicato una guida congiunta intitolata CI Fortify: Advice for Isolating Vital Systems (indicazioni per l'isolamento dei sistemi vitali). Il messaggio è chiaro: gli operatori delle infrastrutture critiche devono essere in grado di scollegare le tecnologie operative vitali dalla rete aziendale, da Internet e da terze parti durante una crisi informatica o geopolitica, e continuare a erogare i servizi essenziali anche se disconnessi.

Non si tratta di una preparazione astratta. Le agenzie indicano esplicitamente il contesto: attori malevoli supportati da Stati che cercano di infiltrarsi preventivamente nell'infrastruttura critica (Volt Typhoon è rimasto inosservato nelle reti delle vittime per almeno cinque anni) e gruppi ransomware che hanno imparato che produttori, ospedali e aziende di servizi essenziali pagano più rapidamente quando le operazioni si fermano.

La domanda a cui la guida costringe ogni operatore OT a rispondere è scomoda: se dovessi isolare la rete dell'impianto nei prossimi dieci minuti, saresti in grado di farlo? Sapresti dove intervenire, chi deve autorizzare l'isolamento e cosa smetterebbe di funzionare? Per la maggior parte delle organizzazioni, la risposta onesta è no. È proprio questo divario tra un piano teorico e una capacità di isolamento concretamente progettata e testata che CI Fortify mira a colmare.

Cosa richiede effettivamente CI Fortify?

Al di là del linguaggio del framework, la guida delinea un percorso in sei fasi:

  • Identificare i sistemi vitali: l'insieme minimo di sistemi OT e di supporto necessari per continuare a erogare il servizio essenziale
  • Identificare i clienti critici e le dipendenze a monte
  • Definire livelli di criticità e attendibilità tra reti e host
  • Mappare tutte le connessioni ai sistemi vitali: IT aziendale, accesso remoto dei fornitori, piattaforme cloud, servizi esposti a Internet e altri operatori
  • Creare punti di separazione e isolamento in anticipo, definendo i criteri di autorizzazione e di trigger prima dell'incidente
  • Creare e testare un piano di isolamento graduale: esercitazioni sull'intero sistema, non test parziali, perché questi ultimi non rilevano le dipendenze condivise, come servizi di identità, DNS, sistemi historian e sistemi di licensing, che possono smettere di funzionare nel momento in cui viene interrotta la connessione

La guida indica l'isolamento fisico come la forma di protezione più efficace, ma riconosce allo stesso tempo che una disconnessione fisica completa non è praticabile per le organizzazioni che dipendono da reti di operatori di telecomunicazioni, servizi cloud o strutture distribuite geograficamente. Questa è la realtà della maggior parte degli ambienti produttivi moderni. Per questi ambienti, le agenzie raccomandano di rafforzare i confini OT, eliminare le dipendenze aziendali superflue e mantenere la capacità di limitare progressivamente l'accesso con l'intensificarsi della minaccia.

Nella guida, questo modello di escalation viene definito isolamento graduale. Innanzitutto, si interrompe l'accesso di lavoratori e fornitori da remoto, poi la connettività aziendale, quindi i sistemi connessi e infine tutti i collegamenti esterni. I criteri di trigger per ciascuna fase vengono definiti in anticipo, con l'isolamento completo dei sistemi più vitali come stato finale.

Perché l'isolamento graduale fallisce su una rete piatta?

L'isolamento graduale presuppone l'esistenza di più livelli. Su una tipica rete OT brownfield, però, questi livelli non esistono. Sulla carta, molti impianti si descrivono secondo il modello Purdue, con livelli ben distinti e canali di comunicazione controllati tra l'uno e l'altro. Tuttavia, nella pratica, decenni di convergenza IT/OT hanno prodotto ambienti piatti, in cui interfacce HMI, sistemi historian, workstation di engineering, jump box dei fornitori e centinaia di dispositivi non gestiti condividono gli stessi domini di broadcast. I "punti di isolamento" richiesti dalla guida dovrebbero quindi essere improvvisati in caso di incidente: regole firewall di emergenza, riconfigurazioni delle VLAN, scollegamento fisico dei cavi. Il tutto, affidandosi a conoscenze informali, magari alle due di notte, mentre l'aggressore si sta già muovendo nella rete.

La guida stessa considera i controlli amministrativi, come VLAN e liste di controllo degli accessi, "poco efficaci", valutandoli come misure transitorie lungo il percorso verso un isolamento reale, non soluzioni su cui fare affidamento nel lungo periodo. E le ragioni sono quelle che ogni operatore già conosce: si tratta di controlli statici, soggetti a errori quando vengono applicati su larga scala e mai progettati per contenere una minaccia che si sta spostando attivamente all'interno della rete. Un piano di isolamento che richiede di modificare manualmente le liste di controllo degli accessi durante un'intrusione è un piano per scoprire a tue spese le dipendenze nascoste.

Dal punto di vista tecnico, il problema è questo: come dotare un ambiente OT di punti di isolamento reali, predisposti in anticipo e attivabili all'istante, senza dover riprogettare la rete da zero, installare agenti su dispositivi che non li supportano o avviare un progetto di segmentazione destinato a bloccarsi alla prima riunione di approvazione delle modifiche?

In che modo un kill switch contro il ransomware rende concretamente attuabile l'isolamento graduale?

È qui che la segmentazione dei dispositivi zero trust fa la differenza. Zscaler applica i controlli a livello del gateway locale: ogni dispositivo sulla rete OT è isolato in un segmento dedicato, e ogni flusso est-ovest viene valutato in base a policy fondate su identità e contesto, senza agenti, senza riprogettare l'architettura della rete dell'impianto e senza accumulare liste di controllo degli accessi statiche.

Su questo livello di enforcement risiede Ransomware Kill Switch, che riflette quasi perfettamente il modello di isolamento graduale di CI Fortify. Invece di improvvisare le misure di contenimento nel pieno di un incidente, gli operatori preconfigurano set di policy associati a livelli crescenti di gravità: a un livello di allerta elevato, possono bloccare in tutto il sito i protocolli di movimento laterale usati impropriamente; aumentando ulteriormente il livello, possono interrompere l'accesso remoto di fornitori e terze parti; al livello più critico, possono disabilitare con un'unica azione le comunicazioni verso interi segmenti di rete, per esempio una linea di produzione o un piano dello stabilimento, continuando al contempo a consentire i flussi critici autorizzati.

Image

Riletto alla luce della terminologia utilizzata nella guida:

  • I punti di isolamento cessano di essere posizioni fisiche da individuare e diventano costrutti di policy documentati, attivabili in pochi secondi
  • L'isolamento graduale non è più una sequenza di richieste di modifica d'emergenza e diventa un livello di severità regolabile, con conseguenze predefinite e già testate per ciascun livello
  • Autorizzazione e trigger diventano controlli dell'accesso e logiche di automazione anziché una catena di chiamate: il kill switch è richiamabile via API, così gli strumenti SIEM, SOAE ed EDR possono attivare il contenimento nel momento in cui il livello di affidabilità del rilevamento supera una soglia predefinita
  • Il testing smette di essere un'interruzione annuale e diventa una pratica di routine: dato che l'isolamento è definito da una policy, puoi testarlo, osservare ciò che non funziona, correggere la dipendenza e ripetere il test: esattamente il ciclo iterativo che, secondo la guida, i test parziali non possono garantire

Un punto va chiarito esplicitamente: CI Fortify richiede due capacità, ovvero isolare rapidamente i sistemi vitali e continuare a operare in quello stato di isolamento per un periodo prolungato. Un kill switch è una risposta decisiva alla prima esigenza, riducendo il contenimento da ore di improvvisazione ai pochi secondi necessari per eseguire la policy. E sono proprio quelle prime ore a determinare, nella maggior parte dei casi, se un incidente si tradurrà in un'interruzione operativa o in una catastrofe. Mantenere l'operatività in condizioni di completa disconnessione per un periodo prolungato è una questione di architettura e pianificazione operativa che nessun singolo controllo può risolvere. La possibilità di raggiungere questo obiettivo deve essere verificata da ogni operatore nel proprio ambiente, tenendo conto dei servizi di identità, dei sistemi historian e delle dipendenze di licensing che emergono solo quando si testa concretamente il perimetro, non sulla base di un'architettura di riferimento.

Da dove dovrebbero iniziare gli operatori OT?

La sequenza prescritta da CI Fortify è quella corretta e la segmentazione moderna dei dispositivi accelera ogni fase: rilevamento e classificazione automatici per identificare i sistemi vitali e far emergere la mappa delle connessioni di cui non eri a conoscenza, policy basate sull'identità per definire i punti di isolamento senza riprogettare la rete, policy del kill switch basate sul livello di gravità per attuare l'isolamento graduale e test di routine a basso rischio per individuare le dipendenze prima che lo faccia un attaccante.

Le agenzie hanno comunicato chiaramente agli operatori la necessità di essere pronti a isolare i sistemi. Le organizzazioni che se la caveranno meglio non saranno quelle con il piano di isolamento più dettagliato. Saranno quelle in cui l'isolamento potrà essere attivato con un comando già testato.

Vuoi vedere come si presenta un isolamento preconfigurato nel tuo ambiente? Richiedi un workshop sull'architettura OT per mappare i tuoi sistemi vitali, le connessioni e i punti di isolamento rispetto al modello CI Fortify.

FAQs

CI Fortify è una guida congiunta pubblicata il 28 luglio 2026 dalla CISA, l'ACSC dell'Australian Signals Directorate, l'FBI, l'NCSC del Regno Unito e il Canadian Centre for Cyber Security. Offre agli operatori di infrastrutture critiche passaggi pratici per isolare le tecnologie operative vitali e i sistemi da tutte le altre reti durante un incidente informatico o una crisi geopolitica, continuando al contempo a garantire i servizi essenziali anche in condizioni di isolamento.

No. La guida descrive l'isolamento fisico come la protezione più efficace, ma riconosce che non è praticabile per le organizzazioni che dipendono da servizi cloud, reti degli operatori di telecomunicazioni o strutture distribuite geograficamente. Per questi ambienti, la guida raccomanda di rafforzare i confini OT, ridurre le dipendenze dai sistemi aziendali e predisporre una capacità di isolamento graduale, attivabile rapidamente con l'intensificarsi della minaccia.

L'isolamento graduale è il modello indicato dalla guida per limitare progressivamente la connettività con l'aumentare del livello di minaccia: prima si bloccano gli accessi di lavoratori da remoto e fornitori, poi la connettività con la rete aziendale, quindi i sistemi connessi e i collegamenti esterni. I criteri di attivazione e le autorizzazioni vengono definiti prima dell'incidente, con l'isolamento completo dei sistemi più vitali come stato finale.

Un ransomware kill switch è un controllo di contenimento preconfigurato in Zscaler Zero Trust Device Segmentation. Gli operatori selezionano livelli di gravità crescenti che limitano progressivamente protocolli e porte vulnerabili, interrompono l'accesso remoto e di terze parti e possono disabilitare all'istante le comunicazioni verso interi segmenti di rete, come una linea di produzione, bloccando il movimento laterale senza dover improvvisare modifiche al firewall. Può essere controllato tramite API per l'automazione guidata da SIEM/SOAR/EDR.

La segmentazione firewall e VLAN si basa su regole statiche, complesse da gestire, che tendono a degradarsi nel tempo e richiedono finestre di manutenzione per essere modificate: proprio le caratteristiche che la guida identifica come i limiti dei controlli amministrativi. La segmentazione dei dispositivi basata sull'identità isola ogni dispositivo in un segmento dedicato a livello del gateway locale, senza agente e senza riprogettare l'architettura di rete. In questo modo, i punti di isolamento esistono come policy che possono essere testate e modificate senza tempi di inattività.

form submtited
Grazie per aver letto

Questo post è stato utile?

Esclusione di responsabilità: questo articolo del blog è stato creato da Zscaler esclusivamente a scopo informativo ed è fornito "così com'è", senza alcuna garanzia circa l'accuratezza, la completezza o l'affidabilità dei contenuti. Zscaler declina ogni responsabilità per eventuali errori o omissioni, così come per le eventuali azioni intraprese sulla base delle informazioni fornite. Eventuali link a siti web o risorse di terze parti sono offerti unicamente per praticità, e Zscaler non è responsabile del relativo contenuto, né delle pratiche adottate. Tutti i contenuti sono soggetti a modifiche senza preavviso. Accedendo a questo blog, l'utente accetta le presenti condizioni e riconosce di essere l'unico responsabile della verifica e dell'uso delle informazioni secondo quanto appropriato per rispondere alle proprie esigenze.

Ricevi gli ultimi aggiornamenti dal blog di Zscaler nella tua casella di posta

Inviando il modulo, si accetta la nostra Informativa sulla privacy.