Sfida l’ Firewall: se un’infrastruttura critica non necessita di un percorso di ritorno, eliminatelo

Le infrastrutture critiche dipendono dalla connettività, ma ogni connessione crea un potenziale viale d’accesso per gli attacchi. Alla luce dei recenti attacchi, degli insegnamenti tratti dalla mia nuova docuserie *Into the Breach: Breaking the Firewall * e dell’evoluzione delle tecnologie di isolamento come i diodi di dati, dobbiamo ripensare il modo in cui sono progettati i nostri sistemi più critici ed esplorare il motivo per cui sia i governi che le industrie dovrebbero partire da una semplice domanda: questa connessione deve davvero esistere?

Questo fine settimana abbiamo pubblicato “Into the Breach: Breaking the Firewall ”, il primo episodio che ho prodotto con Cyber King Productions, condotto da Kari Byron di MythBusters.

Perché ho deciso di realizzare un programma sulla sicurezza informatica?

Da anni cerco di spiegare il concetto di sicurezza informatica delle infrastrutture critiche a clienti, funzionari governativi, giornalisti, partner, amici e, a volte, persino alla mia stessa famiglia.

Di solito non ci vuole molto prima che si inizi a parlare di firewall, air gap, PLC, IT, OT, segmentazione, Zero Trust, diodi di dati, malware e vulnerabilità.

E mi rendo conto quando comincio a perdere persone.

A un certo punto mi sono reso conto che forse il problema non era il pubblico.

Forse il settore della sicurezza informatica non è più in grado di raccontare la propria storia in modo efficace.

Pensate a ciò di cui si occupa questo settore: attacchi sferrati da Stati-nazione, centrali elettriche, reti idriche, satelliti, fabbriche, intelligenza artificiale, computer quantistici e attacchi in grado di provocare conseguenze fisiche concrete.

Eppure, in qualche modo, continuiamo a spiegare tutto questo con un’altra presentazione in PowerPoint.

Volevo fare qualcosa di diverso.

Prendete un argomento che la gente crede di capire. Costruite un vero e proprio esperimento attorno ad esso. Mettetelo alla prova. Verificatelo. Coinvolgete esperti che conoscono bene la tecnologia. Rendete il tutto visivo. Rendete il tutto divertente. E, soprattutto, mettete in discussione i preconcetti che il settore della sicurezza informatica ripete da anni senza metterli sufficientemente in discussione.

Il risultato è stato “Into the Breach”. La serie combina attacchi informatici reali, esperimenti pratici, interviste ad esperti e dimostrazioni per rendere la sicurezza informatica tangibile e comprensibile.

Per l'episodio n. 1, ho voluto partire da uno dei presupposti fondamentali:

«Basta metterlo dietro un firewall e sarà protetto.»

Poi, quasi in perfetta sincronia con l’uscita dell’episodio, gli avvenimenti in Minnesota hanno dominato l’attualità.

Il 26 e il 27 luglio, un attacco informatico coordinato ha preso di mira le tecnologie operative di oltre 30 reti idriche comunitarie del Minnesota. Lo Stato del Minnesota ha attivato il proprio sistema di risposta alla sicurezza informatica a livello statale per indagare sugli attacchi e fornire sostegno alle comunità colpite.

Due giorni dopo, l’FBI e l’EPA hanno diffuso un avviso più ampio. Dal 27 luglio, le aziende di servizi idrici e fognari di almeno sette stati avevano segnalato incidenti che coinvolgevano PLC collegati a Internet.

Gli autori dell'attacco hanno effettuato l'accesso remoto ai dispositivi, modificato indirizzi IP e password e causato la perdita di monitoraggio e controllo da parte degli operatori. L'FBI ha segnalato conseguenze operative quali la perdita di pressione e l'allagamento. Ha inoltre riscontrato configurazioni di rete di terze parti simili presso diverse vittime, che potrebbero aver consentito agli autori dell'attacco di ripetere lo stesso successo.

Fermati un attimo a rifletterci.

Stiamo parlando di computer che controllano l'acqua.

Non si tratta di qualcuno che ruba il numero di una carta di credito. Non si tratta solo di un ransomware che crittografa il portatile di un dipendente.

Quando un malintenzionato è in grado di interferire con una pompa, una valvola, un interruttore elettrico, una conduttura, una linea di produzione o un altro processo fisico, la sicurezza informatica assume una portata ben più ampia.

Si tratta di una questione di sicurezza pubblica.

E il Minnesota non è il primo segnale d'allarme.

Volt Typhoon è uno degli esempi più evidenti.

Le agenzie statunitensi e alleate preposte alla sicurezza informatica hanno documentato come alcuni attori sostenuti dallo Stato cinese abbiano ottenuto un accesso persistente all’interno di organizzazioni che gestiscono infrastrutture critiche nei settori delle comunicazioni, dell’energia, dei trasporti, dell’approvvigionamento idrico e in altri settori.

In un caso confermato di violazione, gli autori dell'attacco hanno probabilmente ottenuto l'accesso iniziale sfruttando la vulnerabilità CVE-2022-42475 in un firewall perimetrale FortiGate 300D privo di patch.

Pensa a quello che è successo lì.

Il dispositivo installato per proteggere il perimetro è diventato il percorso che attraversa il perimetro.

Questa non è una critica a Fortinet.

Anche le piattaforme software più sofisticate possono, prima o poi, presentare delle vulnerabilità. I firewall necessitano di patch. Le VPN necessitano di patch. I sistemi operativi necessitano di patch. Le credenziali possono essere rubate. Le configurazioni possono essere errate. Gli amministratori commettono errori. Si verificano attacchi zero-day.

Questa è la realtà del software.

L’Ucraina ha messo in luce le conseguenze concrete in modo ancora più drammatico. Nel dicembre 2015, alcuni hacker hanno compromesso tre società di distribuzione dell’energia elettrica. Sono passati dai sistemi IT a quelli operativi, hanno avuto accesso all’ambiente ICS tramite l’infrastruttura VPN, hanno azionato gli interruttori elettrici e causato interruzioni di corrente che hanno interessato circa 225.000 clienti.

C'è una grande differenza tra il fatto che un hacker riesca ad accedere a uno dei tuoi computer e il fatto che riesca ad accedere al computer che controlla la tua rete elettrica.

Le conseguenze possono andare oltre lo schermo.

Vorrei chiarire bene questo punto.

Abbiamo bisogno di firewall.

OPSWAT Li utilizza. I nostri clienti li utilizzano. Quasi tutte le reti moderne dipendono da essi.

Quello che metto in discussione è il presupposto secondo cui un firewall equivalga all’isolamento.

Penso a un firewall come a una guardia di sicurezza molto intelligente in piedi davanti a una porta. La guardia conosce migliaia di regole. Controlla le credenziali. Esamina il traffico. Decide cosa può entrare e cosa può uscire.

Questo è estremamente prezioso.

Ma c'è ancora una via d'uscita.

Se qualcuno ruba le credenziali giuste, individua una vulnerabilità, sfrutta un errore di configurazione o compromette la tecnologia di sicurezza stessa, la via d’accesso rimane comunque aperta.

Così ho iniziato a pormi una domanda diversa:

E se in realtà nessuno avesse bisogno di varcare quella porta?

Perché spendere così tanti soldi per rendere la porta più “intelligente” se, in primo luogo, le esigenze aziendali non richiedono affatto una porta?

È proprio in questo che un diodo di dati si differenzia in modo sostanziale.

Un diodo dati non è un firewall più efficace.

Risolve un problema diverso.

Anziché affidarsi esclusivamente a regole software per stabilire quale traffico sia consentito, un diodo di dati è in grado di imporre la direzione della comunicazione a livello hardware.

Il NIST ha illustrato proprio questo tipo di architettura in un progetto di riferimento per il settore dell'energia elettrica. I dati di monitoraggio operativo vengono trasmessi verso l'esterno attraverso un gateway unidirezionale e l'architettura impedisce che i dati tornino indietro attraverso la stessa connessione verso l'ambiente industriale protetto.

Si tratta di una proprietà di sicurezza fondamentalmente diversa.

Credo che il principio sia talmente semplice da meritare un nome semplice:

Nessun percorso di ritorno superfluo

Un servizio idrico potrebbe dover inviare degli allarmi.

Una centrale elettrica potrebbe dover trasmettere dati telemetrici.

Un impianto potrebbe aver bisogno di esportare i dati storici.

Un gestore di condotte potrebbe aver bisogno di un sistema di monitoraggio centralizzato.

In un ambiente di difesa potrebbe essere necessario esportare i log.

Tutte queste informazioni possono uscire dalla rete protetta.

Ma se non vi è alcuna ragione operativa per cui la comunicazione debba tornare indietro attraverso lo stesso confine:

Perché creare il percorso di ritorno?

So bene che non tutti gli ambienti possono funzionare in questo modo. Esistono motivi validi per la manutenzione remota, il controllo remoto, gli aggiornamenti software, le conferme di ricezione e altri processi bidirezionali.

Se hai bisogno di quella connessione, difendila con tutte le tue forze.

Le ultime linee guida dell’FBI per il settore idrico invitano gli operatori a rimuovere i PLC dall’esposizione diretta a Internet, a gestire l’accesso remoto tramite gateway sicuri, a limitare l’accesso, a verificare i file di progetto dei PLC, a garantire la sicurezza della connettività cellulare e a mantenere la possibilità di operare manualmente in caso di incidente.

Sono d'accordo su tutto questo.

Ma credo che abbiamo invertito l'impostazione predefinita.

Oggi troppo spesso partiamo dalla connettività e poi chiediamo al team di sicurezza informatica di proteggerla.

Per i nostri sistemi più importanti, dovremmo partire dall'isolamento e chiederci:

Perché è necessario aprire il percorso?

C'è un aspetto importante di questa discussione che a volte viene trascurato.

Un diodo di dati risolve il problema della direzione.

Questo non risolve automaticamente il problema dei contenuti.

Se a un file dannoso viene consentito di spostarsi nella direzione consentita, esso rimane comunque dannoso.

Se un aggiornamento software compromesso supera il diodo, rimane comunque compromesso.

Se qualcuno introduce un documento compromesso in un ambiente isolato, il semplice fatto che l’ambiente sia isolato non rende il documento sicuro.

Ecco perché ritengo che la prossima generazione di questa architettura debba essere:

Solo andata e pulito

Utilizza il diodo per controllare la direzione.

Quindi controllare cosa è consentito far passare.

Ciò significa combinare una comunicazione unidirezionale garantita a livello hardware con tecnologie quali l’ Multiscanning, la sanificazione dei dati e la tecnologia Deep CDR™, il sandboxing, il DLP, l’ispezione dei contenuti basata sull’intelligenza artificiale, la convalida dei file e l’applicazione delle politiche.

OPSWATL'attuale architettura " MetaDefender " integra già la tecnologia Deep CDR™, Metascan™ Multiscanning, il sandboxing, Proactive DLP e l'ispezione basata sull'intelligenza artificiale in flussi di lavoro controllati relativi ai file, mentre i nostri prodotti cross-domain combinano queste tecnologie di prevenzione con architetture di trasferimento sicuro. MetaDefender™ Core è in grado di utilizzare in parallelo oltre 30 motori antimalware nell'ambito di tali flussi di lavoro.

L'obiettivo non dovrebbe essere semplicemente:

Questi dati possono essere trasferiti da A a B?

Le domande dovrebbero essere:

Ma dovrebbe davvero andare in questa direzione?

...o meglio ancora...

Questo contenuto dovrebbe essere pubblicato?

Questa è la differenza tra il semplice fatto di creare un “air gap” e quello di mettere a punto un processo sicuro per il trasferimento delle informazioni attraverso di esso.

Voglio mettere alla prova la CISA, ma voglio anche riconoscerle il merito che le spetta.

La situazione sta cambiando.

Una nuova guida del 2026 sull’isolamento delle infrastrutture critiche afferma che gli operatori dovrebbero essere in grado di isolare i sistemi OT vitali dalle altre reti, descrive l’isolamento fisico come la forma di protezione più efficace e riconosce specificatamente che i diodi di dati e le soluzioni cross-domain offrono una maggiore garanzia rispetto alle architetture standard dei gateway di rete, se implementati correttamente.

Si tratta di un progresso significativo.

My La sfida per la CISA è questa:

Non consideriamo l’isolamento solo come una misura da adottare in caso di crisi. Facciamo in modo che sia parte integrante della progettazione delle infrastrutture critiche fin dall’inizio.

Prima di chiedersi come garantire la sicurezza dell'accesso remoto, occorre chiedersi se tale accesso sia effettivamente necessario.

Se la risposta è sì, mettilo al sicuro.

Se la risposta è no:

Rimuovi il percorso.

Questa riflessione va oltre i confini degli Stati Uniti. Il quadro normativo europeo NIS2 definisce ora un quadro comune in materia di sicurezza informatica che abbraccia 18 settori critici, tra cui l’energia, i trasporti, la sanità, l’acqua potabile, le acque reflue, le infrastrutture digitali, l’industria manifatturiera, la pubblica amministrazione e il settore spaziale.

I governi di tutto il mondo stanno inasprendo i requisiti in materia di valutazione dei rischi, autenticazione, segnalazione degli incidenti, applicazione delle patch, monitoraggio, rilevamento e ripristino.

Tutto questo è importante.

Ma credo che le autorità di regolamentazione debbano porre ulteriori domande:

Perché esiste questo legame?

Come proteggi la connessione?

È proprio necessario che esista questa connessione?

Queste domande dovrebbero essere poste ovunque siano presenti infrastrutture critiche.

Detto questo, ritengo che gli Stati Uniti dovrebbero fare la prima mossa.

Chiedo che venga emanato un decreto presidenziale statunitense basato su un semplice principio:

Nessun percorso di ritorno superfluo.

Per le nostre infrastrutture più critiche, tutto si riduce a cinque concetti:

1. Nessun controller critico dovrebbe essere esposto direttamente a Internet.
2. Se i dati devono solo uscire, rendi la connessione unidirezionale e assicurati che i dati siano puliti. Utilizza una comunicazione unidirezionale imposta a livello hardware, insieme a misure di sicurezza dei contenuti, scansioni multiple, sanificazione dei dati e tecnologia Deep CDR™, in modo che le informazioni che attraversano il confine vengano ispezionate e sanificate.
3. Il controllo remoto dovrebbe rappresentare un'eccezione. Se è davvero necessario, occorre garantirne la sicurezza, limitarne l'accesso, monitorarlo, sottoporlo a verifiche e assicurarsi che gli operatori possano ripristinare la situazione in modo sicuro.
4. Aiutare le aziende di servizi pubblici di piccole dimensioni a modernizzarsi. Non ci si può aspettare che un piccolo sistema idrico riesca a difendersi da sofisticati attacchi informatici con le stesse risorse di un’azienda di servizi pubblici nazionale.
5. Sono i requisiti di sicurezza a dover essere definiti, non il fornitore. I governi dovrebbero stabilire l'obiettivo da raggiungere e lasciare che il settore si confronti per offrire la soluzione migliore.

Il principio è semplice:

Se il traffico non deve tornare indietro, rimuovi il percorso di ritorno. E tutto ciò che attraversa il confine deve essere pulito.

L'America può assumere un ruolo guida, ma vorrei incoraggiare i governi di tutto il mondo ad adottare lo stesso principio.

C'è un altro motivo per cui ritengo che dovremmo agire prima della prossima crisi.

Il 22 giugno 2026, la Casa Bianca ha emanato il decreto presidenziale n. 14412, intitolato “Proteggere la nazione dagli attacchi crittografici avanzati”. Il decreto riconosce la minaccia futura che i computer quantistici su larga scala rappresentano per la crittografia di uso comune, accelera la transizione a livello federale verso la crittografia post-quantistica approvata dal NIST e incarica le agenzie di aiutare i gestori delle infrastrutture critiche a prepararsi alla propria migrazione.

Mi piace questa logica.

Agisci prima che si verifichi la crisi.

Questa è prevenzione.

Credo che la stessa filosofia debba valere anche per l'architettura delle infrastrutture critiche.

Esiste inoltre un interessante legame tra i diodi di dati e l'era quantistica.

Per essere chiari, un diodo di dati non rende la crittografia odierna resistente alla crittografia quantistica. È la crittografia post-quantistica a risolvere quel problema matematico.

Ma le chiavi di crittografia sono pur sempre conservate da qualche parte.

Vengono generati da qualche parte. Archiviati da qualche parte. Utilizzati da qualche parte.

Gli HSM, i sistemi di gestione delle chiavi, le infrastrutture di calcolo quantistico e le future reti quantistiche continueranno a coinvolgere hardware, software, operatori e connessioni di rete.

Continueranno comunque a presentare punti vulnerabili.

Immaginate un ambiente crittografico altamente sensibile che debba trasmettere all’esterno dati di telemetria, informazioni di audit, eventi di sicurezza o risultati di calcolo approvati, ma per il quale non vi sia alcun motivo per cui una normale rete aziendale debba avviare una comunicazione in senso inverso verso i sistemi che proteggono tali chiavi.

Ritengo che questa sia un’importante applicazione futura dell’isolamento garantito dall’hardware. Si tratta di un’inferenza architettonica, non di un’alternativa alla crittografia post-quantistica. Le architetture unidirezionali del NIST dimostrano come i percorsi a senso unico possano ridurre la raggiungibilità della rete, mentre la nuova politica federale in materia di quantistica evidenzia quanto stia diventando importante proteggere i futuri sistemi crittografici.

My Il concetto è semplice:

La crittografia post-quantistica protegge i principi matematici.

Hardware- L'isolamento forzato può proteggere il percorso verso le macchine salvaguardando i principi matematici.

Per i nostri ambienti più sensibili, credo che avremo bisogno di entrambi.

È opportuno che chiarisca una cosa ovvia.

OPSWAT vende diodi di dati.

Ma non abbiamo scoperto all’improvviso questa architettura perché il Minnesota è stato attaccato il mese scorso, e non siamo entrati nel mercato perché ho deciso di realizzare un programma sulla sicurezza informatica.

Abbiamo fatto questa scommessa anni fa.

Per anni, OPSWAT ha integrato le nostre tecnologie con quelle dei fornitori di diodi in contesti sensibili quali il settore governativo, della difesa, dell’energia e industriale. Più tempo trascorrevo con questi clienti, più mi convincevo che, se la nostra missione era davvero quella di proteggere le infrastrutture critiche mondiali, dovevamo acquisire una maggiore autonomia in questa tecnologia.

Abbiamo fatto qualcosa che non era scontato per un’azienda storicamente nota per il software.

Abbiamo acquisito due aziende del settore hardware.

Nel 2021, OPSWAT ha acquisito le attività di Bayshore Networks, integrando nell'azienda competenze nei settori della sicurezza industriale, dell'OT, dell'ICS e del trasferimento sicuro dei dati.

Nel 2024 abbiamo acquisito Fend, ampliando così le nostre capacità nel campo dei diodi di dati e dotandoci di un’altra architettura particolarmente adatta alle infrastrutture distribuite e remote, come quelle dei servizi idrici.

E l'acquisizione di quelle società era solo l'inizio.

Abbiamo triplicato le risorse destinate alla ricerca e sviluppo in questo settore.

Abbiamo anche preso un’altra decisione.

Se dobbiamo realizzare hardware da cui dipendono i governi e gli operatori delle infrastrutture critiche, voglio sapere da dove proviene quell’hardware, chi lo ha assemblato, quali componenti sono stati utilizzati, come è stato testato e in che modo ne controlliamo la qualità.

Così, abbiamo avvicinato notevolmente la produzione a noi.

Nel novembre 2025, OPSWAT ha inaugurato uno stabilimento produttivo a Tampa, in Florida, internalizzando la produzione di componenti hardware e rafforzando il nostro controllo su qualità, conformità, sviluppo dei prodotti e integrità della catena di approvvigionamento.

E Tampa non è il punto di arrivo di questa strategia.

Stiamo potenziando le nostre capacità regionali e creando nuovi hub in Europa e in Asia, poiché i governi prestano sempre maggiore attenzione non solo alle funzionalità delle tecnologie di sicurezza informatica, ma anche al luogo in cui vengono sviluppate e a chi controlla la catena di approvvigionamento.

Questo non è un progetto secondario.

Si tratta di una scommessa a lungo termine su quella che, a nostro avviso, deve essere la direzione da seguire in materia di sicurezza delle infrastrutture critiche.

Tutto ciò ci riporta alla tesi che ho esposto nel mio libro, Cybersecurity Upside Down.

Il nostro settore è diventato incredibilmente efficiente nell'individuare i problemi solo dopo aver permesso a tali problemi di diffondersi nell'ambiente.

Abbiamo assolutamente bisogno di sistemi di rilevamento. Abbiamo bisogno di SOC, intelligence sulle minacce, monitoraggio e risposta agli incidenti.

Ma la prevenzione dovrebbe avere la priorità.

Se è possibile rimuovere il contenuto dannoso prima che venga eseguito, è opportuno farlo.

Se puoi eliminare un privilegio superfluo, eliminalo.

Se è possibile isolare l'ambiente critico, isolatelo.

E se un sistema critico non necessita di un percorso di rete in entrata:

Rimuovi il percorso.

Questa è la sicurezza informatica che mette la prevenzione al primo posto.

E questo mi riporta al punto in cui è iniziata questa storia.

"Into the Breach " non è solo l'ennesimo video promozionale di " OPSWAT ".

Ho fondato Cyber King Productions perché ritengo che la sicurezza informatica abbia bisogno di un modo completamente diverso di comunicare con il mondo.

Non voglio realizzare spot pubblicitari per le aziende.

Voglio raccontare storie sulla sicurezza informatica che la gente abbia davvero voglia di guardare.

Prendi qualcosa che tutti credono di capire. Individua il presupposto che sta alla base. Costruisci un esperimento attorno a esso. Mettilo alla prova. Mettilo in discussione. Magari smontalo. Magari fai saltare in aria qualcosa. Poi coinvolgi degli esperti e spiega cosa è successo realmente.

È proprio quello che abbiamo cercato di fare con il primo episodio di *Into the Breach*, intitolato “Breaking the Firewall ”.

Prima dell'uscita ufficiale, l'episodio è stato trasmesso sui voli della United Airlines. Poi, al Black Hat, è successo qualcosa che mi ha reso particolarmente felice: alcune persone sono venute allo stand di OPSWAT dopo aver visto l'episodio durante il volo, e alcune volevano parlare con noi dei diodi di dati.

Riflettici un attimo.

Una persona ha guardato un programma sulla sicurezza informatica in aereo, è arrivata al Black Hat, è venuta al nostro stand e voleva capire come proteggere al meglio una rete critica.

È proprio quello che speravo che Cyber King potesse fare.

Avere un'idea è facile. Realizzarla non lo è.

Sono l'ideatore e il produttore esecutivo, ma ho avuto la fortuna di poter contare su un team straordinario per la realizzazione del primo episodio:

• Kari Byron è stata conduttrice e produttrice esecutiva

• Berry Blanton è stato regista e produttore

• Jason Richard è stato produttore e montatore

• Linda Wolkovitch era la produttrice

• Erik Weinbrecht era uno scrittore

• Joanna Shemesh era produttrice associata

• Scott Sorensen è stato direttore della fotografia

• Shannon Wilkerson si è occupata della grafica 3D e del motion design

• Christopher Gore Gammon era vicedirettore

• Del team di produzione facevano parte anche Jesus “Chuy” Valadez, Mahlik Hailu, Jan Reichle, Christina Robles, Jesus Ocejo e Roman Molla.

...e, ovviamente, Maxx, il cane robot, ha interpretato se stesso.

Un ringraziamento davvero speciale a Kari, Berry, Jason, Erik e a tutti coloro che hanno contribuito a trasformare questa idea in realtà.