Il caso Ferrovie Italiane e le nuove minacce alle infrastrutture critiche
Gli attacchi informatici che colpiscono grandi infrastrutture non iniziano quasi mai con scene da film. Niente hacker incappucciati che “bucano” i sistemi centrali. Nella maggior parte dei casi l’ingresso avviene attraverso software legittimi, fornitori fidati e strumenti quotidiani, trasformati in vettori d’attacco.
Il caso che ha coinvolto il gruppo Ferrovie dello Stato Italiane, tramite la compromissione di un fornitore IT strategico, è emblematico di questa evoluzione. Non si è trattato di un attacco diretto ai sistemi di controllo dei treni, ma di una violazione software a monte, capace di esporre grandi volumi di dati sensibili e informazioni operative.
Uno dei vettori più comuni in questi scenari è l’accesso non autorizzato a repository documentali e sistemi di gestione aziendale. Piattaforme di document management, portali di collaborazione o sistemi ERP contengono contratti, piani industriali, dati del personale e configurazioni operative. Se un account di servizio o un accesso privilegiato viene compromesso, l’attaccante non deve “forzare” nulla: può semplicemente scaricare dati in modo silenzioso e continuativo.
Un secondo esempio riguarda il software di assistenza e manutenzione remota. Molti fornitori utilizzano strumenti che permettono di intervenire da remoto sui sistemi dei clienti. Se questi tool non sono adeguatamente segmentati o se le credenziali vengono sottratte, diventano un ponte diretto verso reti interne normalmente protette. È una tecnica già vista in attacchi a ospedali, pubbliche amministrazioni e operatori energetici.
Altro vettore critico è rappresentato dalle applicazioni web interne, spesso sviluppate su misura. Portali per la gestione del personale, dashboard operative, sistemi di ticketing o workflow amministrativi vengono talvolta considerati a basso rischio. In realtà, una vulnerabilità software non aggiornata o una cattiva gestione dei permessi può consentire l’accesso a interi archivi. L’attacco non è rumoroso, non blocca i sistemi, ma produce un danno profondo e duraturo.
Nel caso delle infrastrutture critiche, il vero obiettivo non è sempre il sabotaggio immediato. Molto più spesso è la raccolta di informazioni. Dati organizzativi, mappe dei sistemi, nomi dei responsabili, procedure interne e flussi decisionali sono materiale prezioso per attacchi successivi: spear-phishing, estorsioni mirate, frodi finanziarie o operazioni di disinformazione.
Un aspetto spesso sottovalutato è il ruolo dei software di backup e archiviazione. Se l’attaccante riesce ad accedervi, ottiene una copia ordinata e completa del patrimonio informativo aziendale. In diversi casi documentati, l’esfiltrazione di dati è avvenuta proprio da ambienti di backup poco monitorati, considerati erroneamente “inermi”.
Ciò che emerge da episodi come quello di Ferrovie Italiane è una lezione chiara: la sicurezza non può più essere pensata come difesa del perimetro. Oggi l’attacco passa attraverso software legittimi, contratti regolari e processi quotidiani. La catena di fornitura digitale diventa parte integrante della superficie di attacco.
Per questo la risposta non può limitarsi a patch tecniche. Serve una governance del software che includa controllo degli accessi, segmentazione, audit continui sui fornitori, monitoraggio delle attività anomale e procedure di risposta rapide. Soprattutto, serve consapevolezza: ogni applicazione, ogni integrazione, ogni account di servizio è un possibile punto di ingresso.
Nel mondo delle infrastrutture critiche, il software non è solo uno strumento operativo. È un territorio strategico. E come ogni territorio strategico, va presidiato prima che venga occupato.
Dalla diagnosi al controllo dei fornitori
La catena di fornitura digitale si comprende partendo dalle dipendenze concrete. Quali applicazioni permettono di lavorare? Chi le aggiorna? Quali fornitori possono accedere ai sistemi e con quali privilegi? Un elenco dei contratti, da solo, non risponde a queste domande. Serve collegare ciascun servizio ai dati che tratta, agli account utilizzati e alle conseguenze di una sua indisponibilità.
Immaginiamo, come esempio illustrativo, un’impresa che affida la manutenzione del gestionale a un partner esterno. Il partner dispone di un accesso remoto e interviene su richiesta. Il controllo inizia verificando se l’account è individuale, se l’autenticazione è robusta, se gli accessi sono registrati e se i privilegi restano necessari dopo l’intervento. Una relazione commerciale affidabile non elimina la necessità di queste verifiche.
Ridurre l’ampiezza dell’incidente
Il principio del minimo privilegio aiuta a limitare ciò che un account può raggiungere. Un tecnico incaricato di una singola applicazione non dovrebbe ricevere automaticamente accesso a tutti gli archivi. La segmentazione aggiunge un altro confine: sistemi con funzioni diverse richiedono percorsi e autorizzazioni coerenti con il lavoro da svolgere.
Non basta definire i controlli una volta. Quando cambiano persone, strumenti o contratti, bisogna riesaminare gli accessi. Gli account non più utilizzati e le integrazioni dimenticate possono restare fuori dall’attenzione quotidiana. Una revisione periodica deve indicare un responsabile, una data e un esito verificabile, evitando che il controllo si riduca a una dichiarazione generica.
Le domande da porre prima dell’acquisto
Per un servizio importante, chiediamo come vengono gestiti aggiornamenti, vulnerabilità e incidenti. Quali informazioni riceveremo in caso di compromissione? Chi sarà il referente? Come potremo recuperare i dati o passare a una procedura alternativa? Le risposte devono essere valutate rispetto all’uso previsto, non soltanto alla reputazione del marchio.
Il NIST dedica alla gestione del rischio della filiera informatica la pubblicazione SP 800-161. Il punto operativo è integrare le dipendenze tecnologiche nel processo di gestione del rischio dell’organizzazione. Per un’impresa piccola questo può tradursi in un inventario essenziale, una classificazione dei servizi critici e controlli proporzionati ai possibili effetti di un incidente.
Una prova prima dell’emergenza
Una breve esercitazione può partire da una domanda: cosa facciamo se il fornitore comunica che un suo account è compromesso? Il gruppo deve sapere chi valuta gli accessi coinvolti, chi contatta il partner e chi decide eventuali limitazioni. La disponibilità di registrazioni utili e di una copia recuperabile dei dati rende la risposta più ordinata.
Il risultato dell’esercitazione non è una promessa di invulnerabilità. È un elenco di lacune da correggere: recapiti mancanti, privilegi eccessivi, backup non provati o responsabilità poco chiare. La sicurezza della filiera cresce quando queste lacune vengono affrontate prima che un’interruzione le renda urgenti.
Fonte di approfondimento: NIST SP 800-161: gestione del rischio nella filiera informatica.