Entro il 2025, le previsioni prevedono che ci saranno centinaia di milioni di veicoli connessi sulla strada. Il processo decisionale in macchina viene gradualmente trasferito all’apprendimento automatico e ad algoritmi basati su regole. Sempre più funzionalità computerizzate vengono integrate all’interno dei veicoli per massimizzare la nostra esperienza al volante.
Tuttavia, l’innovazione ha un costo: gli hacker sono costantemente alla ricerca di modi per sfruttare queste nuove tecnologie al fine di penetrare nei sistemi dei veicoli. Purtroppo le loro possibilità sono infinite. Dagli attacchi che si basano sull’accesso fisico agli attacchi remoti che utilizzano dispositivi esterni come smartphone e attacchi alla catena di fornitura o after-market. Queste minacce possono mettere a rischio un’intera flotta. In quanto tale, il panorama delle minacce informatiche automobilistiche sta diventando sempre più complesso poiché l’industria lotta per proteggere i sistemi dei veicoli e mantenere la sicurezza e la privacy una priorità assoluta.
In questo articolo, ci concentreremo sul campo dello sviluppo di software pensando agli attacchi informatici. Esamineremo lo sviluppo del software nel mondo automobilistico, elencheremo le vulnerabilità più comuni a disposizione dell’hacker e mostreremo esempi comprovati di sfruttamento basati sui test di penetrazione del team di ricerca di Argus Cyber Security. Infine, discuteremo l’importanza della sicurezza informatica nella riduzione significativa dei rischi.
Sviluppo Software nel mondo automobilistico – unicità e preoccupazioni per la sicurezza
Esistono molte somiglianze tra lo sviluppo di software per veicoli e altri sistemi. In quanto tale, anche il ciclo di vita dello sviluppo del software (“SDLC”) è simile. Comprende pianificazione, analisi, progettazione, sviluppo e implementazione, test e manutenzione. Detto questo, la natura complessa e regolamentata dell’industria automobilistica richiede che gli sviluppatori tengano conto di considerazioni critiche e uniche.
- Considerazioni tecniche : le ECU core critiche per la sicurezza possono essere basate su Classic AutoSAR, che comunica utilizzando i protocolli CAN bus, FlexRay o MOST ottimizzati per il settore automobilistico (ad eccezione delle ECU collegate che tipicamente girano su sistemi Linux, QNX o Android). Il classico AUTOSAR ha funzionalità limitate rispetto a Linux e ad altri sistemi operativi open source. Data la sua scarsa popolarità, molte vulnerabilità in Classic AutoSAR devono ancora essere scoperte e gli hacker potrebbero trovarle relativamente facili. A livello di rete, lo sviluppo di protocolli orientati all’auto comporta diversi problemi di sicurezza; l’utilizzo del CAN bus, ad esempio, consente a qualsiasi ECU di inviare comandi a un’altra senza essere autorizzato, consentendo agli hacker di controllare una ECU come se fossero una parte legittima;
- Considerazioni aziendali : gli OEM mirano a incorporare il maggior numero possibile di piattaforme di connettività al veicolo tramite Bluetooth, NFC e Wi-Fi ai nostri smartphone e protocolli dedicati ad altre auto della flotta e al suo ambiente. Tuttavia, i sistemi abilitati al wireless espongono l’auto e i suoi passeggeri a un mondo completamente nuovo di minacce: più il veicolo è connesso, maggiori sono i rischi. Gli esempi sono numerosi: ottenere informazioni su più flotte crea il rischio di essere attaccati tramite auto della stessa flotta o tramite il SOC automobilistico. La connettività ai principali standard wireless come Wi-Fi e Bluetooth può essere raggiunta tramite smartphone. In altre parole, ogni nuova tecnologia richiede una serie completamente nuova di considerazioni per prevenire lo sfruttamento da parte degli hacker;
- Impatto e complessità : possono esserci implicazioni di vasta portata e pericolose per la vita causate da una vulnerabilità trascurata nel processo di sviluppo del software. A differenza di molti altri settori, i rischi associati richiedono che gli sviluppatori non commettano errori. Inoltre, non è ancora semplice aggiornare facilmente il veicolo (ad esempio utilizzando aggiornamenti “Over-the-Air”) nelle auto connesse, e quindi ogni sviluppo deve soddisfare gli standard di sicurezza pianificati con qualche anno di anticipo.
Soprattutto, dato il ritmo rapido del mondo cibernetico insieme al mercato automobilistico sotto-studiato, è una questione di tempo dal momento in cui un hacker esperto decide di attaccare un veicolo fino a quando non trova una vulnerabilità da sfruttare.
Vulnerabilità comuni
Le vulnerabilità possono esistere nel software che gestisce il veicolo e sono spesso classificate in due tipi: di progettazione e di implementazione. È fondamentale prendere in considerazione almeno le vulnerabilità note dalle prime fasi dello sviluppo del software e fino alla fase di test.
Le vulnerabilità dell’architettura e del design sono difetti nella logica del sistema stesso. Sebbene il sistema funzioni come previsto, espone le risorse a causa della cattiva gestione di casi limite imprevisti.
Le vulnerabilità dell’implementazione sono causate da un’errata implementazione della logica di sistema. La corruzione dei dati fa sì che il programma si comporti in modi imprevisti, a seconda di come i dati vengono rappresentati e interpretati.
Il team di ricerca di Argus Cyber Security fornisce agli OEM e ai Tier 1 un’ampia gamma di servizi per supportare la sicurezza informatica delle loro flotte di veicoli per tutta la loro vita. I servizi includono analisi delle minacce e valutazione dei rischi, valutazioni delle vulnerabilità e test di penetrazione, che insieme aiutano a identificare le lacune di sicurezza il prima possibile.
Dopo aver completato dozzine di progetti, il team ha acquisito una vasta conoscenza delle minacce alla sicurezza informatica nel dominio automobilistico e ha identificato molti punti deboli comuni, CWE (Common Weakness Enumeration. A CWE descrive una vulnerabilità non correlata a un’applicazione specifica.
Di seguito sono riportati alcuni esempi di CWE che i malintenzionati possono sfruttare:
- Progettazione e implementazione CWE: limitazione impropria di un nome di percorso a una directory con restrizioni (“Path Traversal”) (“CWE-22”). L’input esterno al software è necessario per costruire un percorso relativo in una directory limitata. Poiché il software non neutralizza correttamente gli elementi speciali all’interno del percorso, il percorso risultante può puntare a risorse esterne alla directory limitata. Lo sfruttamento di questa debolezza consente a un utente malintenzionato di leggere qualsiasi file sul sistema, facendo trapelare efficacemente informazioni sui processi e altre informazioni sensibili memorizzate nel file system;
- Implementazione CWE: Information Exposure (“CWE-200”) è l’esposizione accidentale o dolosa di informazioni a una parte che non è esplicitamente autorizzata ad accedere a queste informazioni. Una preoccupazione significativa per quanto riguarda la sicurezza automobilistica è la privacy: ad esempio, la fuga di informazioni personali del conducente, informazioni sensibili OEM o un database di auto contenente i dettagli di dozzine di utenti. Un esempio noto per dimostrare questo CWE è CVE-2017-1000250, una vulnerabilità Bluetooth per i dispositivi Linux. Questo CVE fa parte di “BlueBorne”, un vettore di attacco trovato nelle connessioni Bluetooth. Lo sfruttamento di questa vulnerabilità può mettere a rischio qualsiasi sistema di infotainment Linux;
- Implementazione CWE: Integer Overflow o Wraparound (“CWE-190”) – un calcolo errato può produrre un intero overflow o un wraparound, dove il valore risultante è maggiore dello spazio predefinito. Integer Overflow si verifica in CVE-2016-6250, in libarchive (archivio multiformato e libreria di compressione) prima della 3.2.1. Questo CVE consente agli aggressori remoti di eseguire un Denial of Service (arresto anomalo dell’applicazione) o l’esecuzione di codice in modalità remota;
- Design CWE: Improper Authentication (“CWE-287”) : quando un hacker afferma di avere una determinata identità, il software non dimostrerà in modo sufficiente che l’affermazione è corretta. Un esempio di questo CWE è CVE-2018-13908, che porta a una mancanza di controllo nell’accesso per l’archiviazione di dati protetti. Lo sfruttamento di questa vulnerabilità è comune nei test di penetrazione nel settore automobilistico. Il potenziale danno può includere furto di dati, rischio per la privacy del cliente, danno alla reputazione dell’OEM, perdita finanziaria, perdita di vite umane e varie altre gravi conseguenze.
Best practice per la mitigazione
Un approccio efficace per mitigare i rischi è guardare oltre lo sviluppo del software e verso l’architettura più ampia del veicolo. Rispetto ad altri settori, il mondo automobilistico è estremamente complesso e stabilisce numerosi livelli di protezione, rafforzando il nucleo e i componenti collegati all’interno del veicolo, il backend, la connettività all’auto, le linee di produzione, la catena di fornitura e il prodotti after-market.
Per ridurre la motivazione degli hacker, dobbiamo creare più punti di resistenza. Nel settore automobilistico, ciò significa ridurre il rapporto costo-efficacia in termini finanziari, tecnologici e pratici.
Sicurezza in base alla progettazione
Il software deve essere progettato dalle fondamenta per essere impermeabile. Esempi sono:
- Architettura segmentata: posizionamento di un gateway e controller di dominio per separare le ECU critiche per la sicurezza dalle ECU collegate. Ciò limita la capacità degli hacker di eseguire movimenti laterali nel veicolo;
- Eseguire un’analisi delle minacce e una valutazione dei rischi (TARA): identificare potenziali lacune e vulnerabilità di sicurezza in una piattaforma, architettura o componente del veicolo durante la fase di progettazione del veicolo e costruire il concetto di sicurezza di conseguenza. Il fattore di rischio per ogni scenario di minaccia viene valutato in base alla probabilità che si verifichi e al potenziale impatto, con raccomandazioni per la mitigazione e requisiti di sicurezza;
- Progettare secondo gli standard, le normative e le migliori pratiche pubblicate dall’industria automobilistica.
Implementazione e prevenzione cyber-sicure
La standardizzazione dei protocolli di sicurezza all’interno di reti, componenti e server OEM per migliorare la sicurezza complessiva, nonché il rafforzamento di tutte le parti della produzione. Esempi sono:
- Formazione degli sviluppatori sulla codifica sicura – per avere un impatto già nelle fasi di sviluppo e per vedere la sicurezza informatica come una parte fondamentale dell’implementazione;
- Revisioni del codice: identificare potenziali lacune di sicurezza nel software applicativo, firmware del dispositivo, protocolli di comunicazione e implementare raccomandazioni per colmare le lacune;
- Distribuzione di firewall: firewall basati su Deep Packet Inspection per filtrare il campo del carico utile;
- Protezione della memoria: controllo dell’integrità del flusso per la convalida del software durante l’avvio e il runtime;
- Implementazione di sistemi di rilevamento delle minacce sui moduli host: soluzioni che rilevano anomalie sui singoli sistemi, registrano tali anomalie in modo che possano essere inviate agli analisti della sicurezza OEM per indagare e determinare la risposta applicabile;
- Implementazione di sistemi di rilevamento delle intrusioni di rete con prevenzione opzionale: i moduli di rilevamento e prevenzione delle intrusioni possono rilevare anomalie nella rete del veicolo, quindi avvisare, mitigare il rischio in tempo reale o controllare l’allerta;
- Penetration Testing: questi progetti aiutano il cliente a identificare le vulnerabilità sul componente di destinazione attraverso le sue interfacce e canali di comunicazione con il mondo esterno e convalidano che i requisiti di sicurezza siano stati implementati in modo efficace;
- Crittografia software: gli algoritmi e le operazioni crittografiche rendono difficile l’esecuzione di azioni dannose.
Gestione del ciclo di vita (post-produzione della sicurezza)
Il processo di gestione dell’intero ciclo di vita del sistema dal momento in cui il veicolo lascia la fabbrica fino alla messa fuori servizio. Esempi inclusi:
Gestire il ciclo di vita di una minaccia rilevata, con il supporto di un Security Operation Center automobilistico professionale, specializzato nella gestione degli incidenti, nell’indagine e nella risposta agli incidenti informatici che interessano veicoli e flotte
Monitora i registri dell’auto e della flotta: rileva le minacce dei servizi di auto connesse utilizzando i motori di rilevamento
Gestione delle vulnerabilità: utilizzo di strumenti di indagine e reportistica per analizzare le minacce e rendere il processo decisionale il più semplice possibile
Aggiornamenti continui del produttore e aggiornamenti della sicurezza dei criteri: per ridurre in modo significativo il tempo necessario a un hacker per trovare una vulnerabilità e sfruttarla aggiornando e aggiornando costantemente il software
Se si inseriscono livelli di protezione sufficienti su numerose piattaforme prima del software, il rischio di punti deboli sfruttati nel software sarà notevolmente inferiore – anche se è vulnerabile in base alla progettazione, sarà ugualmente più difficile da penetrare.
