Gli incidenti di queste settimane a sistemi di refrigerazione hanno portato l’attenzione pubblica sulla vulnerabilità dei sistemi di controllo connessi ad Internet. L’attenzione dei tecnici a questi sistemi era già aumentata da tempo, come anche quella del legislatore, che li ha inclusi nelle nuove normative di settore.
Gli incidenti, come ormai è noto, sono stati causati principalmente dall’esposizione su Internet di sistemi non aggiornati o addirittura obsoleti, con vulnerabilità note che erano già state sfruttate per attacchi analoghi negli anni passati1 e di cui si conoscevano quindi le debolezze. Verrebbe da dire, quindi, che le soluzioni fossero semplici e note. In effetti, buona parte delle soluzioni sono note, e prese singolarmente sembrano semplici, ma non sono semplici nel complesso, nonostante la ricetta esista almeno da quarant’anni. Quando si parla di incidenti di sicurezza, se si dice che “non è questione di se, ma di quando”, è perché le difese sono sempre imperfette. Quando avviene l’incidente, c’è sempre una vulnerabilità, e c’è sempre qualcosa di più o di meglio che si sarebbe potuto fare per evitarla.
Quattro condizioni di rischio da verificare nei sistemi di refrigerazione connessi
| Condizione da verificare | Perché conta | Controllo operativo |
|---|---|---|
| Interfaccia di gestione esposta su Internet | Il pannello può essere raggiungibile da soggetti non autorizzati. | Mappare le esposizioni e limitare l’accesso remoto ai soli soggetti autorizzati. |
| Software non più supportato | Il produttore può non distribuire più correzioni per le nuove vulnerabilità. | Isolare il componente e pianificare sostituzione o mitigazioni compensative. |
| Patch disponibile ma non installata | Una vulnerabilità già corretta può restare sfruttabile nell’impianto. | Inventariare versioni e aggiornare secondo procedure compatibili con la continuità del servizio. |
| Accessi dei manutentori troppo ampi | Una credenziale sottratta può consentire operazioni o spostamenti non necessari. | Limitare privilegi e reti raggiungibili; utilizzare MFA e registrare gli accessi dove possibile. |
Schema di verifica generale, non attribuzione delle cause ai singoli incidenti. Fonti: NIST SP 800-82 Rev. 3 (2023); Danfoss Security Advisory DSA-2025-08-01.
Indice degli argomenti
Sistemi di controllo connessi ad Internet, il problema dell’obsolescenza
Parlando però di sistemi di controllo, è utile fare un’altra considerazione, vera anche per i sistemi IT in generale, ma molto più critica in questo contesto, e riguarda l’obsolescenza. Il termine ha una sua definizione nello standard ISO/IEC 62402, ma qui facciamo riferimento più informalmente ad una raggiunta inadeguatezza di un sistema a svolgere le proprie funzioni. Se guardiamo, prima di tutto, ai sistemi IT, succede di trovare sistemi obsoleti con una certa frequenza, persino sistemi Windows 2000 che ormai non sono supportati da più di quindici anni, o postazioni di lavoro Windows XP utilizzate per qualche attività specifica, magari per qualche piccola applicazione non supportata su altri sistemi.
Il punto è che spesso questi sistemi svolgono ancora il loro compito in modo soddisfacente: sono stabili, gli utenti sanno come utilizzarli, e non sono richieste evoluzioni funzionali, aumenti di prestazioni o altro. Il loro unico problema è la sicurezza, prima di tutto in termini di mancanza di aggiornamenti, ed è generalmente un motivo sufficiente per doverli, in generale, sostituire. Un costo, per non dire uno spreco, reso inevitabile sostanzialmente solo dalla necessità di proteggere i sistemi dagli attacchi. Certo, uno svecchiamento può essere occasione di semplificazioni nella gestione, o di evoluzione dei servizi, ma non è detto che fosse lì che l’azienda voleva investire le proprie risorse.
Quando la macchina dura più del software
Se passiamo ai sistemi di controllo, la situazione peggiora. Una macchina può avere, già per propria natura, una durata attesa di vita molto più lunga di quella dei normali sistemi IT, anche di diverse decine di anni. Non decine di anni di vita da strumento obsoleto, ma decine di anni di vita programmata. Questa durata di vita è difficilmente compatibile con quella dei componenti ICT integrati per gestire la connettività e le funzioni più avanzate.
Questi componenti, infatti, sono spesso derivati da componenti utilizzati anche in ambito IT (ad esempio, sistemi operativi) o ne seguono il ciclo di vita, che è invece di pochi anni come disponibilità del prodotto, e spesso di una decina di anni al più come supporto complessivo. A questo si aggiunge la complessità di macchine che comprendono componenti hardware, che a loro volta comprendono componenti software, che a loro volta utilizzano altri componenti software… in una catena di forniture in cui ciascun anello dovrebbe garantire aggiornamenti in caso di vulnerabilità che siano rilevanti per il prodotto finale. Ma proprio i componenti più rilevanti per la vulnerabilità del prodotto, quelli software, sono quelli con il ciclo di vita più breve. In queste condizioni, non è strano che un’azienda tenda a mantenere strumenti, la cui sostituzione sarebbe estremamente costosa, oltre il tempo di supporto dei relativi componenti software, accettando implicitamente il rischio di una possibile compromissione a fronte del risparmio su una spesa che sembra poco giustificabile.
Qui, naturalmente, entrano in gioco le valutazioni di rischio. Purtroppo, in molti casi sono le valutazioni che portano a dire: “Chi mai vorrebbe attaccare questi miei sistemi, e che vantaggio ne avrebbe?”. In effetti, molti commenti agli attacchi ai frigoriferi evidenziavano un certo stupore per attacchi che non portavano ad un vantaggio economico per l’attaccante, ma solo danno per il soggetto attaccato.
Qui le considerazioni che si potrebbero fare sono diverse: che ormai siamo in un contesto di “guerra ibrida” perenne, e che quindi il danno visibile è comunque interessante per alcuni attaccanti, ma anche che il semplice vandalismo, che è sempre esistito, o l’attacco semplicemente “perché si può fare” sono sempre stati un rischio, a partire da alcuni dei primissimi virus che cancellavano i dati senza portare vantaggio a nessuno. Il semplice vandalismo non è generalmente un buon motivo per grossi investimenti di risorse, ma quando le risorse richieste per l’attacco sono limitate, è sempre un’eventualità da considerare.
Il Cyber Resilience Act: cosa prevede
Come interviene in tutto questo il Cyber Resilience Act, la normativa europea sulla sicurezza dei prodotti con componenti digitali di cui si parla tanto? Il ruolo del CRA sarà sicuramente importante in relazione ai prodotti immessi sul mercato dell’Unione Europea a partire da dicembre 2027. Al di là dei requisiti funzionali di sicurezza che prevede, uno dei requisiti principali riguarda infatti la gestione delle vulnerabilità dei prodotti, assicurando che non siano immessi sul mercato con vulnerabilità sfruttabili note, e gestendo la distribuzione di aggiornamenti anche dopo che il prodotto è stato immesso sul mercato. Questi aggiornamenti devono essere prodotti per tutto il periodo di assistenza, che è di massima coerente con la durata di vita del prodotto.
Perché gli aggiornamenti non bastano
Il CRA è quindi la soluzione al problema? Purtroppo, no. Aiuta, sicuramente, e rappresenta un passo avanti importante. Ma avere disponibili gli aggiornamenti è solo una piccola parte della soluzione. Tanto è vero che alcuni dei frigoriferi compromessi non avevano un sistema di controllo obsoleto, lo avevano solo non aggiornato, nonostante gli aggiornamenti fossero disponibili. E non è una soluzione neanche velocizzare l’installazione delle patch, seppure anche questo sia sempre più necessario, perché comunque il patching in sé non è abbastanza veloce da evitare l’incidente2 .
Con l’utilizzo di strumenti di AI, la scoperta e lo sfruttamento di 0-day sta diventando sempre più veloce, e la protezione diventa sempre più difficile sia in termini di velocità che di capacità di rilevazione. E quindi, ecco che si torna alle vecchie ricette, più difficili ma più solide, prima fra tutte la security by design. Security by design, “sicurezza per progettazione”. Spesso tradotto come “sicurezza fin dalla progettazione”, rischiando di mettere l’accento solo sul “quando”, trascurando il “cosa”. I principi di base della progettazione sicura sono gli stessi da almeno quarant’anni, anche se ogni tanto vengono rinfrescati con prospettive diverse come “zero trust”.
Difesa in profondità e progettazione sicura sistemi di controllo connessi ad Internet
Un primo è ad esempio quello della ridondanza delle difese e di difesa in profondità. Un meccanismo di difesa, per quanto valido, prima o poi potrebbe essere aggirato: una vulnerabilità, un errore di configurazione, un comportamento poco attento possono portare a superarlo. Dietro, ci deve essere qualcos’altro che consenta non solo di opporre un’altra barriera valida, ma consenta anche di rilevare che la prima è stata superata. Per implementare correttamente questo principio, è necessario che i due (o più) meccanismi siano realmente alternativi, utilizzando logiche in modo indipendente. Se ad esempio si utilizzano strumenti antimalware sia a livello centralizzato che locale, ma questi strumenti utilizzano le stesse tecnologie, non saranno di fatto ridondanti: quello che non verrà rilevato dall’uno supererà anche l’altro.
Viceversa, se anche i due componenti, locale e centralizzato, sono dello stesso produttore, ma utilizzano tecnologie diverse, allora sarà effettivamente un caso di difesa ridondata e in profondità. Esporre direttamente un sistema di controllo su Internet per renderlo accessibile per manutenzione, fa sì che sia raggiungibile da chiunque, e che se la gestione delle vulnerabilità non è perfetta (e non lo sarà mai) prima o poi il prodotto sarà in condizioni di essere compromesso. Viceversa, se l’accesso avviene tramite VPN, allora dovranno essere compromesse sia la VPN che il prodotto perché un attacco possa avere successo.
Segregazione delle reti e privilegio minimo
Un secondo è quello della segregazione, che è un tema molto più di progettazione e configurazione che di tecnologie: sistemi e reti devono poter comunicare solo con sistemi e reti che hanno effettivamente bisogno di raggiungere, e sui canali che è previsto che utilizzino. Questo permette di limitare in modo radicale le conseguenze che la compromissione di un singolo sistema può avere sul sistema informatico aziendale complessivo.
Un terzo è quello del privilegio minimo e del default deny: anche questo permette di ridurre la superficie di attacco, come anche le conseguenze della compromissione di un sistema o di una credenziale utente.
1. Accesso remoto
2. Segmentazione tra reti
3. Privilegio minimo e aggiornamenti
4. Rilevazione e reazione
Monitoraggio e risposta all’incidente
E poi, naturalmente, è fondamentale il monitoraggio, che spesso le aziende non riescono a gestire in proprio anche fuori dagli orari d’ufficio, dovendo ricorrere a servizi esterni. Nel caso dei frigoriferi, dove sia stato immediatamente che la temperatura dei frigoriferi non era quella attesa, è stato possibile disconnetterli da Internet, disattivare lo sbrinamento, e così ridurre enormemente le conseguenze dell’attacco.
La responsabilità di imprese e istituzioni
Quindi, è tutto in carico alle aziende, che devono proteggersi? Perché questo è uno dei commenti che si sentono più spesso nei consigli di amministrazione che si devono formare sui rischi della cybersecurity secondo quanto previsto dalla normativa NIS. Naturalmente, non è tutto in carico alle aziende. Le norme, come il CRA, aiutano ad avere prodotti più affidabili. Le forze di polizia e di difesa, per quanto possibile, cercano di contrastare le azioni ostili, seppure in un contesto internazionale particolarmente difficile. L’ACN, ed in particolare lo CSIRT Italia, stanno dando un supporto concreto, ad esempio in termini di condivisione di informazioni.
Ma chiedersi se sia “tutto in carico alle aziende” è un po’ come chiedersi se l’impegno delle forze di polizia contro i furti possa essere sufficiente perché un’azienda non debba proteggere le proprie strutture con serrature, allarmi e guardiania. Solo con un’azione ed una cooperazione a tutti i livelli si può contrastare un fenomeno che è destinato solo ad aumentare, anche se le tensioni geopolitiche attuali si dovessero attenuare. Cooperazione che i governi europei stanno aumentando, spinti proprio dagli ultimi incidenti, ma che necessariamente coinvolge anche le aziende, sia quelle che sono soggette alle nuove normative di settore, che quelle che dovrebbero dedicare la stessa attenzione ai propri sistemi per propria tutela, e non perché lo richiede una legge.
Le priorità dei vertici aziendali
Detto tutto questo, rimane comunque un punto: perché la sicurezza sia gestita, deve comunque essere una delle priorità delle aziende. Molti problemi di sicurezza non derivano da scarsità di risorse, competenze o tecnologie: dipendono da poca attenzione al problema, prima di tutto ai vertici dell’azienda, oppure da una sottostima delle capacità degli attaccanti (o da una sovrastima delle proprie). In questi casi, l’incidente grave, prima o poi, è inevitabile.
NOTE
1 https://www.danfoss.com/en/service-and-support/articles/dcs/tech-insider-october-2025/ fra l’altro, anche nei confronti della Russia
2 https://security.googlecloudcommunity.com/google-threat-intelligence-3/announcing-m-trends-2026-data-insights-and-strategies-from-the-frontlines-7123 “M-Trends 2026 reveals that the mean time to exploit vulnerabilities dropped to an estimated -7 days, meaning exploitation is routinely occurring before a patch is even released”.
Partecipa alla community