Progettare aeromobili non pilotati sicuri ed economici

• 
• Tweet
• Pin It
• Condividi per email

Lo spazio aereo commerciale sta diventando sempre più regolamentato: non alla quota di 35.000 piedi dove volano le compagnie aeree, ma nello spazio direttamente sopra le nostre teste. È la conseguenza dell’incredibile e tuttora crescente popolarità dei droni. Esiste ovviamente un’enorme differenza tra i droni che usiamo nel tempo libero e i sistemi a pilotaggio remoto (SAPR) adottati nei settori aerospaziale e della difesa, ma in entrambi i casi la loro diffusione è pressoché contagiosa. La riduzione dei prezzi dei droni a uso ricreativo ne ha favorito l’appeal; allo stesso modo, anche i costi per lo sviluppo e la manutenzione di aeromobili non Pilotati commerciali devono riuscire a scendere affinché questi sistemi possano concretizzare tutte le loro potenzialità.

Una strategia per poter ridurre i costi è quella di adottare una Open Systems Architecture (OSA), accorgimento che dà vita a uno scenario maggiormente competitivo modularizzando i sistemi per mezzo di framework hardware e software tra loro stratificati. L’intenzione è quella di scomporre sistemi complessi in servizi definiti in grado di interoperare tra loro, consentendo così a un maggior numero di fornitori di competere a parità di condizioni. Il Dipartimento statunitense della Difesa (DoD) supporta l’approccio OSA, non ultimo perché esso consente la rapida migrazione di tecnologia tra piattaforme SAPR differenti.

Sicurezza end-to-end

A differenza dei droni di fascia consumer, un SAPR commerciale ha bisogno di un’attenzione supplementare nei confronti della sicurezza in ciascun punto del sistema. Questo aspetto ruota intorno alle comunicazioni tra il velivolo, il suo controller (in genere remoto) e il payload (che può avere svariate funzioni mission-critical, come ad esempio la sorveglianza).

Poiché si tratta di un sistema distribuito connesso in rete, occorre inoltre proteggerlo da potenziali attaccanti che cerchino di ottenere accesso al controller e/o alle comunicazioni allo scopo di compromettere SAPR o payload.

Le stazioni di controllo a terra che si spostano verso l’approccio OSA utilizzano servizi pubblicati per i SAPR, contenenti dati operativi, insieme con quelli per il payload, comprensivi di dati ISR (intelligence, sorveglianza e ricognizione). La stazione di terra è connessa ad altri sistemi, potenzialmente basati su cloud, il che aumenta il livello di minaccia alla sicurezza in una topologia di rete che può vedere gli asset aggiunti o rimossi nel corso della propria vita utile operativa. Tutto questo non fa che aumentare la necessità di sicurezza end-to-end.

Figura 1: Sicurezza end-to-end in un SAPR.

Come mostra la Figura 2, la sicurezza inizia al momento del boot con una ‘root of trust’ che si estende per tutto il sistema in modo da assicurare che vengano eseguiti codice, payload e comunicazioni di natura fidata. Perché il software possa garantire la propria conformità a questa catena di fiducia e la rispetti, esso dovrebbe contenere diverse funzionalità dedicate.

La prima di queste è la verifica delle firme digitali, che normalmente avviene usando uno standard di crittografia a chiave pubblica come X.509 ITU-T, così da assicurare il funzionamento solo di codice autorizzato. La crittografia fornisce certificati e chiavi di root per l’autenticazione.

Il software dovrebbe quindi supportare la capacità di cifrare e decifrare dati, come Secure Socket Layer (SSL), utile per rilevare eventuale malware applicato a dati cifrati. Ulteriore supporto di interfacce come IPsec e Internet Key Exchange possono fornire una sicurezza avanzata alle comunicazioni di rete, mentre container cifrati mediante AES possono garantire protezione ai dati inattivi.

Dovrebbe essere presente anche un sistema centralizzato e unificato per la gestione degli utenti che tenga sotto controllo le attività di runtime limitando l’accesso alle aree del sistema solamente agli utenti autorizzati. Ciò dovrebbe essere completato da funzioni di logging e auditing che consentano agli amministratori di verificare a quali parti del sistema vi siano stati accessi, quando e da parte di chi. Infine, la capacità di integrare in modo sicuro ulteriori servizi forniti da terze parti può estendere le funzionalità di sicurezza in direzione di discipline come l’analisi dei contenuti o l’intelligence sulle minacce.

Un OS sicuro

Le tecnologie open source come Linux non sono inerentemente sicure contro il tipo di minacce presenti in un ambiente SAPR, ma offrono numerosi vantaggi allineati a una filosofia OSA. Tuttavia, è possibile affrontare la questione della sicurezza optando per una piattaforma dotata di kernel hardened.

Un kernel Linux hardened include caratteristiche come grsecurity e la patch PaX, oltre a misure come Address Space Layout Randomization (ASLR) e la sanitizzazione della memoria. Queste sono funzionalità importanti sulle quali vale la pena soffermarsi.

Grsecurity è un pacchetto sviluppato e mantenuto da Open Source Security Inc. che introduce miglioramenti alla sicurezza del kernel Linux. Questi miglioramenti implementano una difesa contro le minacce imponendo il controllo sugli accessi ed evitando che la memoria possa corrompersi. Il pacchetto comprende anche la patch PaX, che protegge dati e codice residenti in spazi di memoria etichettando principalmente i dati come non eseguibili e i programmi come non scrivibili.

ASLR, o Address Space Layout Randomization, è una soluzione creata dal progetto PaX sotto forma di patch per Linux e ora presente in molti dei principali sistemi operativi. Il suo scopo è quello di creare imprevedibilità negli spazi di indirizzamento così da rendere più difficile per un attaccante la possibilità di trovare specifici processi all’interno della memoria. Questo significa che il tentativo di eseguire un processo dall’indirizzo sbagliato porterà a un crash del sistema anziché all’esecuzione di codice spurio.

Anche l’aggiunta di opzioni per la sicurezza del core o della piattaforma che ricorrono alla protezione dagli eventi di buffer overflow in runtime può essere usata per bloccare, monitorare e verificare un sistema fornendo agli amministratori un superiore livello di controllo.

Tutte queste misure si trovano implementate all’interno di Wind River Linux.

Inoltre le funzionalità di sicurezza di VxWorks sono riepilogate nella Tabella 1 qui di seguito.

Tabella 1: Le funzionalità di sicurezza offerte da VxWorks.

Test per tutto il ciclo di vita

La ferocia degli attacchi sta aumentando, dal malware in generale fino all’utilizzo gratuito di vulnerabilità zero-day, culminando nella diffusione di minacce Advanced Persistent Threat. È dunque chiaro che il test continuativo delle misure di sicurezza presenti in un SAPR è tanto importante quanto la loro implementazione.

In genere i test valutano la capacità di un sistema nel resistere ad attacchi simulati, un processo che può fornire agli sviluppatori dati preziosissimi. Scalando il livello dei test su un intero team per coinvolgere sviluppatori, maintainer, tester e ricercatori, tali dati possono essere accumulati in modo rapido ed efficace. Un modo per far crescere questo processo è quello di utilizzare hardware virtualizzato per dare vita a un gemello digitale, anziché affidarsi alla disponibilità del sistema effettivo.

L’uso di un gemello digitale per simulare il SAPR fornisce un approccio metodico per identificare e comprendere le potenziali vulnerabilità a ogni livello, dal singolo processore fino all’intera rete.

Il sistema permette per esempio di richiamare e replicare le condizioni di guasto su molteplici piattaforme virtuali consentendo a un maggior numero di persone di lavorare contemporaneamente sul problema tutte le volte che occorre. Eseguire i test in un ambiente virtualizzato supporta anche l’impiego di tecniche approvate come l’esecuzione passo-passo, e dal momento che l’intero sistema è virtuale non vi sono aree inaccessibili: qualsiasi aspetto del sistema è disponibile all’esame e all’analisi. In qualsiasi momento è possibile simulare un guasto e introdurlo nel sistema, permettendo ai tecnici di eseguire i test con il minor numero di variabili possibile. Questo grado di visibilità fornisce anche maggiori insight nella fase dello sviluppo dedicata al debugging, il che è perfetto quando si scrive codice a basso livello, driver e altro firmware. Simics è il simulatore di sistema di Wind River che offre agli sviluppatori l’accesso a un ambiente virtuale contenente un intero sistema (Figura 2).

Figura 2: La simulazione di un intero sistema mediante Simics.

In conclusione

Lo sviluppo di sistemi a pilotaggio remoto richiede grande attenzione nei confronti della sicurezza, ma non si tratta semplicemente di una sfida tecnica: occorre infatti un approccio che sia soprattutto economico. Ciò sposta l’attenzione verso la Open Systems Architecture e gli standard aperti, che tuttavia potrebbero fornire in effetti maggiori mezzi, motivazioni e opportunità agli autori di potenziali minacce.

Riconciliare queste due forze opposte richiede soluzioni che tengano conto di entrambe costruendo un kernel software robusto e sicuro supportato dai tool necessari a sviluppare sistemi altamente sicuri. Wind River si trova nella posizione ideale per rispondere a questa esigenza.

Alex Wilson, Wind River (above picture)

• 
• Tweet
• Pin It
• Condividi per email