Le sfide della sicurezza nei velivoli e-enabled

WRA094(Fig3)

Gli aeromobili e-enabled offrono agli operatori numerosi vantaggi in termini di efficienza operativa, comodità dei passeggeri e attività di manutenzione, riparazione e revisione. I sistemi installati su questi velivoli trasmettono i propri dati via satellite o attraverso reti di comunicazione terrestri per farli giungere a servizi analitici che forniscono agli operatori aerei un'eccellente consapevolezza situazionale e, conseguentemente, la possibilità di creare numerosi servizi a valore aggiunto. Tuttavia, per poter approfittare di questi dati real-time IoT occorre risolvere significativi ostacoli in termini di bandwidth e sicurezza non appena si collegano i sistemi alla rete. La sicurezza è di particolare importanza dal momento che devono essere tenuti in considerazione lungo tutto il ciclo di vita della rete di comunicazione i rischi associati all'eventualità che i passeggeri possano manomettere o infiltrare accidentalmente dati e sistemi non protetti, incluse le questioni legali che possono scaturire dalla violazione di dati riservati. Inoltre occorre verificare e mitigare la portata, le minacce, la valutazione del rischio, l'architettura e i collaudi per ciascuna interazione interna ed esterna intrapresa dalla rete.


Comunicazioni
La configurazione attuale dei domini di rete e delle misure di sicurezza di un aeromobile comprende: Acd (Aircraft controls domain), Aisd (Aircraft information systems domain); Pies (Passenger information and entertainment systems); e dispositivi personali dei passeggeri. Il dominio Acd si trova nel cuore dell'avionica di un aereo e comprende i controlli di volo, i sistemi di navigazione e la gestione del volo, tutte funzioni che normalmente abbracciano una serie di sistemi Ima (Integrated modular avionics) dotati di un alto livello di certificazioni di safety. Questi sistemi Ima sono isolati dagli altri domini ma consentono determinati accessi in sola lettura da parte di altri domini che possono ottenere attraverso i bus Arinc informazioni comunemente visualizzate sui display di cabina, come l'altitudine e la direzione di rotta. Il dominio Aisd contiene i sistemi usati dall'equipaggio come i dispositivi Efb (Electronic flight bag), i sistemi per il monitoraggio dei guasti, la gestione dello stato di salute dei componenti e le comunicazioni aeroportuali a terra; tuttavia fornisce alcuni dati a sola lettura al dominio Pies, che comprende i sistemi Ife (In-flight entertainment), i sistemi di gestione della cabina, i sistemi per le carte di credito e altri sistemi rivolti ai passeggeri. Il dominio dedicato ai dispositivi personali di questi ultimi permette l'accesso a Internet e ai media prelevati dal sistema e dai servizi Ife. I sistemi Acd e Aisd sono isolati dalle informazioni relative ai passeggeri, dall'intrattenimento in volo e dai dispositivi personali in modo da evitare intrusioni nei sistemi da parte dei passeggeri. Per quanto riguarda i domini Pies e Aisd si prevede un crescente accesso a connettività wireless e cellulare (3G/4G) avanzata dalla bandwidth più ampia, mentre l'Acd resterà probabilmente disconnesso per garantire la safety e la protezione dei sistemi vitali.

Servizi e connettività
È difficile riuscire a implementare servizi dati e connettività a banda larga più ampia senza compromettere l’integrità di un velivolo, dal momento che il rispetto dei requisiti di sicurezza aumenta la complessità e i costi dello sviluppo. I sistemi di bordo sono generalmente isolati da Internet, ma con l'aumentare delle richieste di servizi a valore aggiunto e la sofisticazione delle minacce alla sicurezza questo approccio basato sul concetto di “air gap” deve essere aggiornato per mantenere la propria efficacia. Per rispondere al pericolo di interazioni elettroniche non autorizzate e inintenzionali sono state emanate le linee guida Rtca DO-326 (Eurocae ED-202A) per le procedure di certificazione aeronautica. Un elemento chiave di questo standard è l'Awsp (Airworthiness security process), che richiede essenzialmente che un velivolo rimanga in una condizione operativa sicura anche quando soggetto a un'interazione non autorizzata. L'Awsp stabilisce che un rischio alla sicurezza dell'aeromobile e dei suoi sistemi sia accettabile - secondo i criteri Awsp - e che la valutazione del rischio di sicurezza per l'aeronavigabilità debba essere completa e corretta. Questo significa che occorre stabilire un livello appropriato di sicurezza pertinente alla protezione di un velivolo e-enabled. Occorre compiere un costante lavoro di protezione dei dispositivi lungo tutto il ciclo di vita dell'aeromobile, dalla progettazione architetturale fino al deployment e al decommissionamento, ed è necessario pianificare e allocare budget per gli aggiornamenti di sicurezza oltre che per futuri metodi di protezione dalle minacce.

L’ambito di sicurezza
Il primo passo è quello di definire la portata del problema relativo alla sicurezza, cosa che richiede l'identificazione degli asset specifici presenti nel sistema, l'identificazione del perimetro di sicurezza e la documentazione dell'ambiente di sicurezza. Ciò significa essenzialmente compiere una verifica diretta di quanto è presente nel sistema, dei punti in cui esso entra a contatto col mondo esterno e delle caratteristiche dell'ambiente operativo. Gli asset possono essere suddivisi in hardware e software, quindi in classi ancora più specifiche - come database di navigazione o aggiornamenti software - analizzabili in termini di valore e impatto. Tutti i punti di contatto verso il mondo esterno devono essere considerati come costituenti il perimetro di sicurezza: tra essi vi sono le interfacce per la manutenzione, le interfacce digitali come i dispositivi dei passeggeri, i sistemi per l'equipaggio, le connessioni tra i sistemi avionici e i meccanismi di sicurezza esistenti all'interno dei vari sistemi. Bisogna quindi definire e analizzare l'ambiente, incluso qualunque altro sistema che possa entrarvi in contatto come quelli per la prenotazione passeggeri o il traffico aereo. Questi sistemi esterni devono essere identificati, e l'analisi delle minacce deve coprire le potenziali minacce provenienti da queste fonti. Non ci si deve poi dimenticare di prevedere l'aggiornamento periodico di quanto costituisce l'ambito interessato dalla sicurezza lungo tutto il ciclo di vita di sistemi in costante evoluzione, per esempio per rispondere all'introduzione di nuove tecnologie come una nuova generazione di connettività cellulare, il cloud computing o nuovi sistemi installati all'interno dell'ambiente.

Minacce e valutazioni
Il passo successivo richiede la valutazione delle minacce cui è esposto il sistema e identificare le condizioni nelle quali potrebbero concretizzarsi: per esempio, permettere ai passeggeri di collegare i propri dispositivi all'IFE per consultare informazioni aumenta il rischio che possano essere iniettati attacchi nel sistema. Dovrebbero essere documentati anche i requisiti di sicurezza relativi alle fonti esterne, identificati i “livelli di fiducia” Rtca DO-356 per designare ad esempio le terze parti considerate sicure, e stabilito il grado con cui utilizzare i livelli di sicurezza dello standard DO-178C ‘Software Considerations in Airborne Systems and Equipment Certification’. Occorre eseguire una valutazione del rischio per mappare gli scenari delle minacce sul sistema di sicurezza in modo da evidenziare le potenziali vulnerabilità. Questa valutazione mappa le vulnerabilità rispetto alle condizioni di guasto definite dalle certificazioni CFR 25.1209 ed Easa CS-25 35.1309 in termini di analisi della sicurezza valutandole da ‘Nessun effetto’ fino a ‘Catastrofico’. L'analisi identifica anche i rischi associati a ciascuna minaccia rilevata, in modo da poter giudicare quale sia il livello di protezione necessario.

Architettura di sicurezza
A questo punto si può implementare l'architettura di sicurezza per mitigare i rischi identificati e proteggere gli asset nell'ambito definito a monte. Concetti come difesa in profondità e meccanismi di protezione a strati aumentano la sicurezza dal momento che una qualsiasi minaccia si troverebbe costretta a superare molteplici misure difensive. La stratificazione della protezione dovrebbe coprire il design di sistema, l'avvio, la fase di runtime e lo spegnimento; e per ciascuno di questi elementi, i sistemi dovrebbero allineare l'architettura di sicurezza rispetto alle minacce identificate. Come accade con lo standard DO-178C, il design coinvolge il processo di sviluppo del codice. Più alto il grado di protezione richiesto, maggiore l'investimento nel processo di sviluppo del codice. Un modo per ridurre i rischi in fase di scrittura del codice è quello di ricorrere a componenti Cots (Commercial-off-the-shelf) ovunque abbia senso farlo, come nel caso del sistema operativo. Per fare un esempio, i sistemi operativi Wind River VxWorks e Wind River Linux sono dotati di funzionalità di sicurezza complete definite all'interno di profili utilizzabili nello sviluppo di architetture per la sicurezza di sistema. Per implementare una protezione stratificata occorre che le misure di sicurezza vengano attivate immediatamente al momento dell'accensione. Gli attacchi di più difficile eliminazione negli ambienti IT sono quelli che colpiscono le fasi di boot e di inizializzazione. Nel momento in cui l'hardware esegue il suo firmware, il sistema deve garantire che quest'ultimo non sia stato compromesso e che l'avvio si concluda nell'ambiente sicuro previsto. Dal momento che tutto questo è collegato all'hardware, occorrono customizzazione e tecnologia secure boot da parte dei componenti Cots. Scegliere un sistema operativo Cots che supporti meccanismi di sicurezza e protezione ha senso anche per l'architettura di runtime. L'analisi delle minacce deve essere svolta sufficientemente in profondità all'interno dell'architettura di sistema per garantire che le funzionalità richieste all'OS siano abilitate e configurate conseguentemente, come ad esempio la protezione via password. A sistema spento, la protezione dei dati può assumere la forma di una memoria storage cifrata o di una più sofisticata tecnologia anti-manomissione implementata sia in hardware che in software.

Collaudi di sicurezza
In ultimo, i collaudi di sicurezza devono ricercare specifiche vulnerabilità sia nel codice del sistema operativo che nel middleware (come il codice incaricato del networking) e nelle applicazioni. I test dovrebbero coprire numerosi aspetti associati alle vulnerabilità come riservatezza, integrità, autenticazione, disponibilità, autorizzazione e non ripudio. Il livello dei test necessari dovrebbe essere identificato durante la determinazione dell'ambito di sicurezza e delle minacce, e comprendere anche un piano per ulteriori collaudi da eseguire lungo il ciclo di vita del dispositivo per verificare sia la soluzione esistente che le minacce emergenti.

Pubblica i tuoi commenti