Cyber-resilienza nei trasporti: proteggere il servizio minimo

ENISA Threat Landscape 2025, pubblicato il 1° ottobre 2025, analizza 4.875 incidenti osservati fra luglio 2024 e giugno 2025. Il trasporto rappresenta il 7,5% degli incidenti classificati nel periodo, con una distribuzione interna molto disomogenea fra modalità: il trasporto aereo pesa per il 58,4% degli incidenti del settore, la logistica per il 20,8%, il trasporto per vie navigabili per il 12,9%, quello su strada per il 5,9% e quello ferroviario per il 2,0%. All'interno del settore, gli attacchi hacktivisti di tipo DDoS — spesso innescati da schieramenti geopolitici legati al conflitto in Ucraina — hanno rappresentato l'87,6% degli incidenti, un dato che segnala un rischio prevalentemente di disponibilità del servizio più che di sottrazione o cifratura dei dati.

Un riferimento operativo recente è l'esercitazione Cyber Europe 2026, che ENISA ha condotto il 10 e 11 giugno 2026 su trasporto ferroviario e marittimo. Secondo ENISA hanno partecipato oltre 5.000 persone e lo scenario simulava un attacco coordinato a sistemi logistici portuali, navigazione, reti ferroviarie transfrontaliere e servizi di ticketing, con interruzioni operative gravi. Fra gli obiettivi dichiarati c'erano il test del Cyber Blueprint dell'UE, che chiarisce ruoli e responsabilità in una crisi, e per la prima volta della Riserva di cibersicurezza dell'UE. Le fonti consultate descrivono scenario e obiettivi; la valutazione e i rapporti sulle lezioni apprese sono indicati come passi successivi, e i loro esiti non sono usati in questo articolo.

Un operatore di trasporto non gestisce soltanto sistemi informatici. Garantisce mobilità, sicurezza e informazione al pubblico in condizioni sia normali sia degradate. La domanda che il board dovrebbe porsi non è quanti controlli tecnici sono installati, ma quale sia il servizio minimo che deve restare erogabile anche quando una componente del sistema smette di funzionare correttamente.

Le applicazioni moderne di un operatore convivono con tecnologia operativa (OT), apparati legacy ancora in esercizio, connettività di rete diffusa e servizi cloud di terze parti. Un singolo processo — la vendita di un biglietto, l'aggiornamento di un orario, l'apertura di un varco — può dipendere contemporaneamente da più provider esterni e da un sistema di identità centralizzato. Se la mappa delle dipendenze si ferma al perimetro IT tradizionale, non mostra le conseguenze reali di una credenziale compromessa, di un aggiornamento bloccato a metà o di un fornitore improvvisamente indisponibile.

La criticità andrebbe quindi misurata per catena di servizio, non per singolo sistema: vendita, validazione, controllo, esercizio, assistenza al pubblico e rendicontazione sono catene distinte, ciascuna con dipendenze proprie. Ogni catena dovrebbe avere documentati esplicitamente i propri single point of failure e le modalità operative manuali disponibili quando il sistema digitale non è utilizzabile — non presunte, ma verificate con un'esercitazione reale.

La resilienza non significa mantenere tutto acceso a ogni costo. Significa sapere in anticipo quali funzioni sospendere per prime, quali dati accettare con un controllo differito nel tempo, e quali decisioni riportare temporaneamente a procedure manuali senza che il servizio si interrompa del tutto. Un minimum viable service definisce esplicitamente le priorità, i livelli di sicurezza accettabili in modalità degradata e le condizioni necessarie per il ritorno alla normalità operativa.

I fallback devono essere esercitati regolarmente, non solo documentati. Procedure mai testate, account di emergenza scaduti da mesi o dati di recovery incoerenti con lo stato reale dei sistemi esistono solo sulla carta, e lo si scopre sistematicamente nel momento peggiore possibile — durante l'incidente reale, non durante l'esercitazione. Le esercitazioni dovrebbero coinvolgere operations, comunicazione, fornitori esterni e, dove pertinente, le autorità competenti — non restare confinate al solo team di sicurezza informatica.

Time-to-isolate, RTO (recovery time objective) per singolo servizio critico, quota di recovery effettivamente testata con successo, dipendenze prive di un'alternativa nota e tempo reale di attivazione del fallback sono metriche molto più utili al board del semplice numero di alert generati dai sistemi di monitoraggio. Mostrano concretamente la distanza fra controllo tecnico installato e continuità reale del servizio, che è la domanda a cui il board deve saper rispondere, non il numero di strumenti acquistati.