Edizioni B2B sabato 24 ottobre 2026 Newsletter
Tech B2B

Automazione, robotica e industria 4.0: la tecnologia in fabbrica.

ANALISI

Stuxnet, il virus che distrusse mille centrifughe insegna alle PMI italiane

Nel 2010 un worm ha sabotato le centrifughe nucleari di Natanz passando per una chiavetta USB, non per internet. Quindici anni dopo, la stessa via d'ingresso, reti industriali isolate ma non davvero protette, resta il punto debole delle fabbriche italiane.

Redazione Tech B2B · 12 settembre 2026

Un worm scoperto nel giugno 2010 ha danneggiato fino a mille centrifughe nucleari iraniane senza che nessuno premesse un grilletto: è passato da una chiavetta USB, non da internet, in un impianto che si credeva isolato dal mondo. Quella via d’ingresso, una rete industriale scollegata dalla rete aziendale ma non davvero protetta dagli oggetti che ci entrano fisicamente, è ancora oggi il punto debole più comune nelle fabbriche italiane.

Perché ti riguarda

Un impianto “air gapped”, fisicamente scollegato da internet, viene ancora considerato al sicuro da molti responsabili di produzione: Stuxnet dimostra che non basta, perché è arrivato dentro Natanz proprio così, senza una connessione di rete. La stessa dinamica vale per una PMI manifatturiera italiana quando un tecnico esterno collega un laptop di manutenzione a un PLC, o un operatore inserisce una chiavetta USB per aggiornare un programma macchina: il canale è lo stesso, cambia solo la scala del bersaglio. La direttiva NIS2, che riguarda ormai anche molte imprese manifatturiere di dimensione media (ne abbiamo scritto qui), chiede esplicitamente di gestire il rischio di terze parti e dei dispositivi rimovibili: Stuxnet è il caso di scuola che spiega perché quella richiesta non è burocrazia astratta.

Come ha funzionato Stuxnet contro le centrifughe di Natanz?

Il worm fu isolato per la prima volta a metà giugno 2010 dalla società di sicurezza bielorussa VirusBlokAda, dopo le prime segnalazioni di computer che si riavviavano in loop in diversi paesi. Symantec lo analizzò in dettaglio nei mesi successivi, arrivando a esaminare oltre 15.000 varianti e a pubblicare nel febbraio 2011 il “W32.Stuxnet Dossier”, tuttora il riferimento tecnico più citato sul caso. Il codice sfruttava quattro vulnerabilità zero-day di Windows insieme, tra cui quella dei collegamenti .LNK (CVE-2010-2568, censita dal National Vulnerability Database statunitense), che eseguiva codice appena una chiavetta USB infetta veniva sfogliata in Esplora risorse, senza bisogno di aprire alcun file. Nessun malware precedente aveva mai armato più di uno o due zero-day contemporaneamente. Una volta dentro, il worm cercava uno specifico software di ingegneria, Siemens Step7/WinCC, usato per programmare i controllori PLC S7-300 che a Natanz gestivano la velocità delle centrifughe di arricchimento: se non trovava quella configurazione esatta, restava inerte e non faceva nulla di visibile, il motivo per cui si diffuse su centinaia di migliaia di computer nel mondo senza che quasi nessuno se ne accorgesse.

Il danno vero restò per mesi un sospetto più che una certezza. Furono gli ispettori dell’Agenzia internazionale per l’energia atomica a notare per primi, nel 2010, un numero di centrifughe fuori uso superiore al normale a Natanz. L’Institute for Science and International Security, un centro studi statunitense sulla non proliferazione nucleare, stimò in un rapporto del dicembre 2010 che l’operazione avesse danneggiato fino a circa 1.000 centrifughe IR-1, circa il 10% del parco allora in funzione, tra novembre 2009 e gennaio 2010: la prima volta che un attacco informatico produceva un danno fisico documentato a un impianto industriale, non solo un blocco di sistemi informativi.

Perché un attacco del 2010 riguarda ancora le fabbriche italiane oggi?

Nel giugno 2012 il giornalista David Sanger del New York Times, sulla base di 18 mesi di interviste a funzionari americani e israeliani, ricostruì Stuxnet come parte di un programma congiunto tra Stati Uniti e Israele, nome in codice “Olympic Games”, avviato sotto l’amministrazione Bush e proseguito sotto Obama: una ricostruzione giornalistica ampiamente ripresa negli anni successivi, mai confermata ufficialmente né da Washington né da Tel Aviv. Il livello di risorse dietro Stuxnet, quattro zero-day, conoscenza dettagliata dell’impianto fisico, tempo per testarlo, resta fuori dalla portata di quasi ogni PMI. Ma il vettore d’ingresso no: la scheda tecnica pubblicata dalla statunitense CISA (Cybersecurity and Infrastructure Security Agency) sul caso resta oggi materiale di riferimento per chi si occupa di sicurezza dei sistemi di controllo industriale (ICS) proprio perché descrive un problema tuttora comune, non specifico del nucleare iraniano: reti operative (OT) considerate sicure per isolamento fisico, aggirate da un supporto rimovibile o da un portatile di un fornitore esterno.

In una fabbrica italiana il rischio più realistico non è un attacco di stato, è un PLC o un gestionale di produzione mai aggiornato da anni perché fermarlo per una patch significa fermare la linea, collegato via manutenzione remota a un fornitore che a sua volta usa la stessa password su dieci clienti diversi. Il principio che Stuxnet mise sotto i riflettori, e che la normativa europea ha messo nero su bianco solo più di dieci anni dopo con NIS2, è che la sicurezza di una rete industriale si valuta guardando chi e cosa può fisicamente collegarcisi, non solo se è collegata a internet.

Cosa può fare oggi una PMI manifatturiera per non ripetere l’errore di Natanz?

Tre misure concrete, alla portata di un’officina o di uno stabilimento medio, riducono lo stesso tipo di rischio che ha aperto la porta a Stuxnet: disabilitare l’esecuzione automatica delle porte USB sulle postazioni collegate a PLC e sistemi di controllo, così che un supporto rimovibile debba passare da un controllo esplicito prima di essere letto; segmentare la rete OT dalla rete IT aziendale con un firewall dedicato, invece di considerarle la stessa rete solo perché sono nello stesso stabilimento; e imporre ai fornitori di manutenzione remota l’uso di credenziali dedicate e temporanee, non un accesso permanente condiviso su più clienti. Nessuna delle tre richiede un budget da grande impresa: richiede solo di trattare il canale fisico di accesso a un PLC con lo stesso sospetto con cui, ormai, si tratta una email con un allegato inatteso.

Vai più a fondo

Fonti primarie di questo articolo: l’advisory tecnico della Cybersecurity and Infrastructure Security Agency statunitense sul caso Stuxnet, ICSA-10-272-01; la scheda della vulnerabilità CVE-2010-2568 sul National Vulnerability Database; il rapporto dell’Institute for Science and International Security del dicembre 2010 sui danni a Natanz, isis-online.org; la ricostruzione di David Sanger sul New York Times (giugno 2012) sull’operazione “Olympic Games”.

Tempo di lettura: 5 minuti

← Tutte le notizie di Tech B2B

Il brief di Tech B2B

Le notizie e i dati che contano per chi decide, direttamente nella tua casella. Gratis, una volta a settimana.

Iscriviti