Per compromettere uno dei velivoli di linea più diffusi al mondo non serve un attacco informatico sofisticato. Bastano un componente grande quanto una moneta, meno di 100 dollari di elettronica e 60 secondi di accesso fisico a un pannello privo di serratura. Lo ha dimostrato un gruppo di ricercatori dell’Università della California San Diego e dell’Oberlin College, che il 13 agosto ha presentato al Usenix Security Symposium di Baltimora un attacco capace di alterare i dati di rotta e di decollo di un Boeing 737.
Il paradosso è tutto qui. Un settore che ha costruito la propria cultura della sicurezza attorno a ridondanza, certificazioni e procedure ferree si scopre esposto da un componente da pochi dollari, non perché manchino i controlli digitali, ma perché nessuno aveva trattato l’accesso fisico come un fronte d’attacco.
Il Boeing 737 non è un aereo di nicchia per il settore: sono circa 8mila gli esemplari oggi in servizio, il 25% della flotta Delta, oltre il 60% di quella American, più della metà di quella United e la totalità della flotta Southwest. Per chi si occupa di sicurezza di infrastrutture critiche in Italia, dove convergenza IT/OT e obblighi NIS2 sono ormai temi quotidiani, il caso merita attenzione ben oltre l’aviazione.
Indice degli argomenti
Come funziona l’attacco “Bus Driver”
La squadra guidata da Stefan Savage e Aaron Schulman, con il dottorando Sam Crow, ha passato anni a ricostruire un banco di prova con componenti autentici di un 737, acquistati sul mercato dei ricambi aeronautici e cablati secondo gli schemi elettrici originali.
Studiando quegli schemi, Crow ha individuato un connettore esterno situato in un vano di apparecchiature elettroniche sotto il muso dell’aereo, raggiungibile da terra senza attrezzi specifici in una quindicina di secondi e chiuso da un semplice sportello privo di serratura. Quel connettore dà accesso a due bus ARINC 429, lo standard di comunicazione seriale introdotto nel 1977 e tuttora in uso su gran parte della flotta commerciale mondiale.
I bus ARINC 429 trasportano dati tramite variazioni di corrente su due fili e, per progettazione, non prevedono alcuna forma di autenticazione dei messaggi: ogni dispositivo collegato limita elettricamente la corrente che può immettere sulla linea, un meccanismo pensato per l’affidabilità, non per la sicurezza.
I ricercatori hanno costruito un dispositivo capace di inserirsi su quel bus e di sfruttare esattamente quel limite, imponendo le proprie istruzioni con una corrente più intensa di quella del trasmettitore legittimo, che viene di fatto sovrastato e sostituito. Una tecnica che hanno battezzato “Bus Driver” e che, secondo la definizione degli stessi autori, garantisce all’attaccante piena capacità di intercettazione e manipolazione delle comunicazioni, non un semplice ascolto passivo.
Il risultato è un controllo pressoché completo del canale tra il Flight Management Computer, che calcola la rotta e i parametri di decollo, e la Multipurpose Control Display Unit da cui i piloti leggono quei dati.
Nel banco di prova, l’impianto custom ha permesso di modificare il piano di volo e i dati di peso, bilanciamento e temperatura usati per stabilire se le condizioni di decollo siano sicure. Le versioni successive del prototipo hanno incluso anche un modulo Wi-Fi, pensato per verificare la possibilità teorica di un comando remoto attraverso i sistemi di connettività di bordo; una capacità che i ricercatori descrivono come parte della sola dimostrazione tecnica.
I piloti potrebbero accorgersi delle anomalie e correggere manualmente, ma solo se riescono a individuare la manomissione: gli stessi autori sottolineano che l’attacco più insidioso non è quello evidente, ma quello che devia la rotta di pochi gradi senza generare alcun allarme visibile.
I ricercatori sono stati per altro molto cauti nelle conclusioni. Hanno scritto esplicitamente di non ritenere l’attacco una minaccia imminente, e hanno omesso dalla pubblicazione i dettagli precisi sulla collocazione del connettore e sui protocolli proprietari coinvolti, proprio per non facilitare un’eventuale replica prima che le contromisure siano disponibili. T
ra le mitigazioni indicate compaiono soluzioni immediate come la rimozione o la sigillatura del connettore esposto, e soluzioni di più lungo periodo come un migliore isolamento elettrico, sistemi software capaci di riconoscere lo schema elettrico dell’attacco e un’autenticazione crittografica dei segnali sul bus.
Lo studio segnala anche che alcune architetture di bus alternative, basate su accoppiamento a trasformatore, risultano già più resistenti a questo tipo di sovrascrittura. Un dettaglio che dice molto su quanto la scelta di un protocollo fatta decenni fa continui a pesare sulla sicurezza attuale.
Sei anni per una risposta: cosa significa “mitigazione sufficiente”
Il dettaglio che più interessa chi lavora nella sicurezza aziendale non è tecnico, ma procedurale. I ricercatori hanno segnalato la vulnerabilità a Boeing nel 2020 e hanno successivamente validato i propri risultati in un laboratorio dell’azienda. Sono trascorsi sei anni prima della pubblicazione pubblica, e a oggi il team dichiara di non poter verificare se sia stata introdotta una correzione tecnica sulla flotta già in servizio.
Nel documento di analisi compare anche una dichiarazione ufficiale di Boeing, secondo cui gli strati di protezione già presenti nell’aereo, sia nella progettazione del sistema sia nell’ambiente operativo in cui l’aeromobile viene utilizzato, sarebbero sufficienti a limitare in modo significativo la probabilità e l’impatto di un attacco reale.
È una posizione legittima quanto ricorrente: la sicurezza fisica degli aeroporti, i controlli di accesso alle aree di manutenzione e la complessità organizzativa richiesta per sfruttare la vulnerabilità costituiscono, secondo l’azienda, una barriera già adeguata.
Non a caso, un ex consulente della Cybersecurity and Infrastructure Security Agency statunitense che ha collaborato con il consiglio tecnico di Boeing sulla cybersicurezza ha osservato come il rischio più concreto non sia l’attaccante esterno, ma l’insider capace di installare il dispositivo durante una normale sessione di manutenzione, quando l’accesso al velivolo è già autorizzato e quindi meno sorvegliato.
Il problema, per chi negozia contratti di fornitura tecnologica, è che questa risposta sposta l’onere della sicurezza da chi ha progettato il sistema a chi lo utilizza ogni giorno. Se la mitigazione è affidata ai processi organizzativi del cliente invece che a una modifica verificabile del prodotto, ogni compagnia aerea, ogni gestore aeroportuale, ogni ente di manutenzione eredita un rischio che non ha contribuito a creare e che non può risolvere da solo.
È esattamente lo schema che si ripete nei contratti di fornitura industriale italiani: clausole di sicurezza generiche, assenza di obblighi di notifica tempestiva delle vulnerabilità scoperte dal fornitore, patch la cui applicazione dipende dalla buona volontà del vendor più che da un obbligo contrattuale con scadenze e responsabilità definite.
Chi acquista tecnologia OT dovrebbe pretendere, fin dal capitolato di gara, evidenze verificabili di mitigazione e non semplici rassicurazioni, un diritto di audit sui componenti critici della fornitura, e clausole che vincolino il fornitore a comunicare tempi e modalità di correzione delle vulnerabilità note, non solo la loro esistenza.
Lo stesso schema nelle infrastrutture critiche italiane
Il caso Boeing è un esempio quasi didattico di un problema molto più ampio, quello dei sistemi a lungo ciclo di vita che convivono con superfici digitali cresciute attorno a loro molto dopo la loro progettazione originaria. In Italia questo schema è già misurabile.
Secondo il Rapporto Clusit 2026, il settore manifatturiero italiano ha subito una media di 1.694 attacchi informatici settimanali nel 2025, con quasi 6.000 incidenti gestiti su un totale nazionale di poco meno di 17.000, oltre un terzo del dato complessivo. L’Italia assorbe circa il 25% degli attacchi globali diretti al settore manifatturiero, una quota sproporzionata rispetto al peso economico del Paese, spiegabile in larga parte con la combinazione di impianti legacy e connettività crescente. A livello nazionale, le stime indicano che entro il 2026 saranno operativi oltre 200 milioni di dispositivi IoT, molti dei quali collegati proprio a infrastrutture critiche che non erano state progettate per gestire quel livello di esposizione digitale.
Il profilo di rischio è lo stesso individuato dai ricercatori di UC San Diego. Reti elettriche e sistemi SCADA di gestione della distribuzione energetica, impianti di trattamento delle acque, sistemi di segnalamento ferroviario, dispositivi medicali connessi in ambito ospedaliero, controllo di processo negli impianti manifatturieri e nelle infrastrutture portuali condividono la stessa architettura di fondo: protocolli progettati decenni fa per garantire affidabilità, non per resistere a un attacco deliberato, ai quali negli anni sono stati aggiunti sensori, connettività remota e interfacce IT senza rivedere il modello di sicurezza sottostante.
In questi ambienti la sicurezza fisica, l’accesso controllato a un armadio elettrico, a una cabina di controllo o a un locale tecnico, resta spesso l’unica barriera effettiva, proprio come lo sportello dell’E&E bay di un 737.
La differenza rispetto a un data center o a una rete IT aziendale è che qui il perimetro da difendere non è fatto di credenziali e firewall, ma di lucchetti, badge fisici e procedure di accesso per il personale di manutenzione, spesso trascurate proprio perché considerate un problema di sicurezza fisica e non di sicurezza informatica.
NIS2, Part-IS e gli obblighi di notifica
Se un incidente analogo colpisse un’infrastruttura critica italiana, il quadro normativo da applicare non sarebbe uno solo. La NIS2, recepita con il D.Lgs. 138/2024, classifica il settore dei trasporti tra quelli ad alta criticità elencati nell’Allegato I: vettori aerei, gestori aeroportuali e fornitori di servizi di navigazione aerea come ENAV rientrano tra i soggetti essenziali o importanti tenuti agli obblighi della norma, a seconda delle dimensioni dell’organizzazione.
Tra questi obblighi rientra la gestione del rischio prevista dall’articolo 24, che comprende esplicitamente la sicurezza della catena di approvvigionamento e quindi la valutazione dei fornitori di componenti critici, non solo la protezione dei propri sistemi interni. In caso di incidente significativo, la procedura di notifica prevede un preallarme al CSIRT Italia entro 24 ore dalla scoperta, una notifica completa entro 72 ore con una prima valutazione di gravità e impatto, e una relazione finale entro un mese.
Va detto con chiarezza che questi obblighi ricadrebbero sull’operatore che subisce l’incidente, non sul costruttore del velivolo: Boeing, in quanto produttore statunitense, resta fuori dal perimetro diretto della NIS2 italiana. È un vuoto che la sola normativa generale di cybersicurezza non colma, e che nel settore aereo viene affrontato da un quadro più specifico.
Dal 22 febbraio 2026 è pienamente applicabile il regolamento europeo noto come Part-IS, composto dal regolamento delegato UE 2022/1645, in vigore dall’ottobre 2025 per gestori aeroportuali e organizzazioni di progettazione, e dal regolamento di esecuzione UE 2023/203, che dalla stessa data di febbraio impone a vettori aerei, organizzazioni di manutenzione, enti di gestione della navigabilità continuata ed enti di formazione l’adozione di un sistema di gestione della sicurezza delle informazioni collegato esplicitamente alla sicurezza del volo.
A differenza della NIS2, che tratta la cybersicurezza come materia autonoma rispetto alla safety operativa, Part-IS nasce proprio per gestire situazioni come quella descritta dai ricercatori di San Diego, in cui una vulnerabilità informatica ha una conseguenza diretta sulla sicurezza del volo. Un’azienda italiana del settore aereo si troverebbe quindi a rispondere su due binari paralleli, la notifica generale alla NIS2 e la gestione del rischio specifica di Part-IS, con la stessa logica di doppio adempimento già vista tra NIS2 e GDPR quando un incidente coinvolge anche dati personali.
Progettare la sicurezza per trent’anni, non per un ciclo di prodotto
Il nodo di fondo che il caso Boeing mette a nudo riguarda il tempo. Un Boeing 737 resta in servizio per 30 o 40 anni, un impianto industriale altrettanto, una rete elettrica anche di più. I processi di sicurezza informatica, al contrario, ragionano per cicli di settimane o mesi: si scopre una vulnerabilità, si rilascia una patch, si aggiorna il sistema. Quando l’oggetto da proteggere è un bus elettrico cablato in un aereo o in un impianto e non un software, quel modello semplicemente non funziona. Non si aggiorna un bus ARINC 429 con un pacchetto software, così come non si aggiorna da remoto la logica di un PLC installato vent’anni fa in una centrale.
La conseguenza per chi progetta oggi tecnologia industriale destinata a durare decenni è che la sicurezza non può più essere trattata come un livello aggiunto in un secondo momento, ma deve entrare nella progettazione del protocollo di comunicazione fin dall’origine, con autenticazione dei messaggi, isolamento elettrico e capacità di rilevare segnali anomali incorporate nel bus stesso, non nel software che vi gira sopra.
È lo stesso principio su cui l’aviazione ha costruito la propria cultura della sicurezza del volo per decenni, quello della ridondanza progettata dall’inizio, che ora deve essere applicato anche alla componente informatica. Per la flotta già in servizio, che continuerà a volare per anni prima che una nuova generazione di velivoli sostituisca quella attuale, restano solo i correttivi fisici che gli stessi ricercatori hanno suggerito: sigillare o rimuovere i connettori esposti, isolare elettricamente i sistemi critici, introdurre controlli software capaci di riconoscere un tentativo di sovrascrittura del segnale.
Chi acquista o gestisce oggi infrastrutture critiche destinate a restare in funzione per decenni dovrebbe porsi la stessa domanda che il caso Boeing lascia aperta. Quanti degli asset OT su cui la propria organizzazione fa affidamento sono stati pensati per resistere non al prossimo audit, ma al trentesimo anno di servizio?
Partecipa alla community