Il 24 giugno 2026, Jorge Aldegunde, Global Head of Railway Services di DNV, ha delineato in un'intervista a Help Net Security la trasformazione strutturale della cybersecurity ferroviaria. I sistemi che tradizionalmente si affidavano a SCADA vendor-specific e reti dedicate SDH-PDH sono migrati a stack IP open-standard, multi-vendor e costi inferiori. Questa transizione ha dissolto il confine IT/OT, trasformandolo da barriera statica in interfaccia da gestire attivamente. L'integrazione di cloud, app consumer e pipeline AI per la manutenzione predittiva ha moltiplicato le superfici di attacco, mentre i vincoli di safety e disponibilità impediscono le contromisure standard del settore IT.
- I sistemi ferroviari tradizionali basati su SCADA vendor-specific e SDH-PDH sono stati sostituiti da reti IP open-standard, trasformando architetture isolate in sistemi aperti con middleware e cloud pubblici/privati.
- L'AI ha moltiplicato attack surfaces e vectors: i dati operativi, archiviati in cloud per app utente e condition-based maintenance, trasformano asset precedentemente air-gapped in produttori continui di dati.
- Le patch in ambito OT ferroviario non possono seguire il ritmo IT: richiedono finestre di manutenzione pianificate o misure compensative, tra cui segmentazione, monitoraggio e restrizioni operative.
- La responsabilità cybersecurity è distribuita tra molti stakeholder a causa della complessità contrattuale del settore, mentre CRA e NIS2 mancano ancora di consenso su linee guida di implementazione specifiche.
Da SCADA chiusi a reti aperte: il meccanismo della dissoluzione
Le applicazioni ferroviarie si appoggiavano tradizionalmente a SCADA vendor-specific e sistemi di comunicazione dedicati SDH-PDH. I progetti hanno poi realizzato i vantaggi di impiegare reti IP-oriented, con open standards, multi-vendor capability e costi inferiori. Questa scelta ha rotto il paradigma isolazionista: gli open standards hanno presto generato open networks. I SCADA, chiusi per design, sono diventati aperti e connessi tramite middleware. I dati dei sistemi di trasporto pubblico, archiviati in cloud pubblici o privati, sono divenuti disponibili per il consumo di app utente. La manutenzione condition-based e i servizi data-driven hanno trasformato asset precedentemente air-gapped in produttori continui di dati con superficie di attacco moltiplicata.
L'arrivo dell'AI ha completato la concatenazione. Secondo Aldegunde, "attack surfaces and vectors multiplied". Le pipeline AI per predictive maintenance e data-driven services introducono nuovi layer di esposizione: data pipelines, model outputs, inference engines, API e connessioni cloud. In manufacturing OT, fonte corroborante, studi indicano che anche lo 0,001% di dati avvelenati può causare il comportamento errato di un modello. Questo meccanismo di poisoning è rilevante per il settore ferroviario, dove la predictive maintenance è in rapida adozione.
Il paradosso operativo: quando il treno non può fermarsi per patch
In IT, il downtime è inconvenient. In manufacturing, secondo Ejona Preçi, Group CISO di Lindal Group, "downtime paralyses the business, sometimes completely". Nel ferroviario, il vincolo è ancora più rigido: i sistemi di safety e la disponibilità del servizio impediscono l'applicazione di patch con il ritmo dei server email. Se una patch è disponibile, l'obiettivo è integrarla in finestre di manutenzione pianificate. Se non è disponibile, si devono considerare misure compensative, tra cui segmentazione di rete, monitoraggio o restrizioni operative.
Questa asimmetria tra velocità dell'attaccante e rigidità del difensore è il cuore del paradosso. Aldegunde la formula come principio di incertezza: "attackers' ability ≥ yours". La visibilità non equivale al controllo. La gestione del rischio si sposta quindi dalla perimetrazione all'architettura di resilienza. I sistemi devono essere in grado di operare in sicurezza anche in condizioni degradate o incerte. Questa è una transizione culturale, non solo tecnologica: l'ingegnere ferroviario con venti anni di esperienza RAMS (Reliability, Availability, Maintainability, Safety) deve ora internalizzare un threat model che prima era estraneo al suo dominio operativo.
Responsabilità diffusa e zone grigie normative
La vera sfida risiede nei layer di integrazione, all'interno di componenti, sottosistemi e sistemi gestiti da stakeholder diversi. La responsabilità è raramente concentrata in un'unica entità, a causa della complessità dei contratti ferroviari. Questa distribuzione della accountability crea interstizi che gli attaccanti possono sfruttare.
Sul fronte normativo, CRA e NIS2 sono in fase di adozione, ma manca consenso sulle linee guida di implementazione. Aldegunde cita esplicitamente l'"expert guidance on implementation of CRA" come punto di disaccordo. NIS2, essendo una direttiva, presenta implementazione differenziata tra stati membri EU. In Croazia, secondo Antonija Vojnović di Span, le prime audit sono ancora attese. L'attrito tra regolazione orizzontale (CRA/NIS2) e verticale ferroviaria (TSI, Technical Specifications for Interoperability) genera zone grigie di accountability.
Supply chain: il tallone d'Achille degli industrial SME
La supply chain industriale, specialmente le PMI, è identificata come vulnerabile per security by design, SBOM e gestione del lifecycle delle patch. Queste organizzazioni, secondo Aldegunde, "may struggle to find a business case to apply paradigms like 'security by design', 'SBOM' or a lifecycle view to patch management". Il problema è strutturale: i margini dei fornitori di componenti industriali non sostengono investimenti cybersecurity senza pressione downstream da parte degli integratori o dei regolatori.
Il dato correlato più prossimo è il 96% di organizzazioni financial services EMEA con data resilience insufficiente per i requisiti DORA, riportato da Vojnović. Questo dato, pur riferito a settore diverso, indica la diffusione di carenze di maturity cybersecurity nel contesto normativo europeo.
"The IT/OT boundary is no longer a boundary, it is an interface that must be actively managed" — Jorge Aldegunde, Global Head of Railway Services, DNV
Cosa fare adesso
Per le aziende ferroviarie, la skill engineering esistente — il corpus RAMS — è il veicolo per la transizione culturale, non la certificazione IT generica. Aldegunde raccomanda di "manage your risks. A risk-based approach is more than just a good start". Il principio di incertezza deve guidare la pianificazione: assumere che la capacità dell'attaccante sia almeno pari alla propria.
Per i policy maker, l'attrito normativo CRA/NIS2 vs. TSI richiede allineamento esplicito per evitare regulatory arbitrage. La mancanza di consenso sull'implementazione CRA va affrontata con guidance settoriali che traducano i requisiti orizzontali in specifiche ferroviarie.
Per i vendor industriali, la pressione su supply chain SME sta diventando un requisito di mercato. Gli integratori di sistemi ferroviari devono inserire nei contratti requisiti di security by design e SBOM, trasformando la pressione normativa in obbligo contrattuale downstream.
La risposta agli incidenti OT-specific e il recovery rapido sono la capability più importante da internalizzare, non outsourcere. Secondo Natalia Oropeza, Chief Cybersecurity Officer di Siemens, "when every minute of downtime might cost not only millions but also human lives, minimizing those minutes becomes crucial". Il settore ferroviario misura il tempo in secondi di ritardo percorrenza. La cybersecurity deve ora internalizzare quella stessa granularità di urgenza.
Il dossier documenta che la convergenza IT/OT è già realtà nei sistemi ferroviari, la superficie di attacco è già moltiplicata, i vincoli di patch sono già strutturali. La mancanza di incidenti pubblici non equivale a mancanza di rischio: la persistenza low-and-slow in ambienti industriali, descritta per il manufacturing tramite account stale e workstation compromesse, è difficile da rilevare perché le reti OT sono costruite per stabilità con pattern prevedibili. Il settore ferroviario condivide questa caratteristica architetturale. L'obiettivo è la resilienza: i sistemi devono operare in sicurezza anche in condizioni degradate o incerte.
Fonti
- https://www.helpnetsecurity.com/2026/06/24/jorge-aldegunde-dnv-railway-cybersecurity/
- https://www.helpnetsecurity.com/2026/03/12/ejona-preci-lindal-group-ot-cybersecurity-manufacturing/
- https://www.helpnetsecurity.com/2025/12/09/natalia-oropeza-siemens-industrial-cyber-capability-shift/
- https://www.helpnetsecurity.com/2026/06/01/antonija-vojnovic-span-cybersecurity-governance-challenges/
Le informazioni sono basate sulle fonti citate e aggiornate al momento della pubblicazione.
Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.
Fonti
- https://unit42.paloaltonetworks.com/microsoft-teams-phishing/
- https://www.darkreading.com/cybersecurity-operations/eu-6g-network-security
- https://unit42.paloaltonetworks.com/fifa-world-cup-attack-surface/
- https://www.securityweek.com/dragos-unveils-ai-for-ot-security/