JEEP, haker e soluzioni palliative

E' successo, alla fine è successo. Era inevitabile, del resto, che questo branco di dilettanti allo sbaraglio, questo pool di giovani fenomeni tutti tesi all'innovazione e mediamente ignoranti di quello che sta alla base delle cose prima o poi ci cascasse, ed il fenomeno si è manifestato per la prima volta proprio su una
Jeep. Ok, cos'è il mio, astio? Il gusto del "te l'avevo detto"? Una inutile critica distruttiva? Io non credo nessuno dei tre, semplicemente è che, dopo aver lavorato per trent'anni progettando hardware e scrivendo software dal quale, spesse volte, dipendono delle vite umane, mi secca molto vedere questi approcci "leggeri" all'argomento sicurezza. Succede, sempre più spesso, che nelle aziende comandino i numeri ed i direttori commerciali. Richieste impossibili come quella di aggiungere performanches senza alzare i costi o abbassare la sicurezza vengono iterate, cambiando progettisti e direttori tecnici, fino ad essere accolte e questo causa una sorta di involontaria selezione del personale tecnico che deve, per poter garantire quanto richiesto dal marketing, essere debole, sottomesso, superficiale e dilettantesco. Così, alla fine, abbiamo analisi dei rischi fatte male, argomentazioni capziose e così via che consentono, poi, di realizzare sistemi pericolosi e di farli passare per sicuri.

   Insomma, cosa è successo? 

Prima di tutto i fatti: un gruppo di hacker ha trovato una falla nel sistema di intrattenimento di un nuovo modello di jeep che gli ha consentito di prendere il controllo del sistema stesso. Niente di strano in tutto questo, anzi, inevitabile che prima o poi dovesse succedere, strano invece che il sistema di intrattenimento fosse collegato senza inibizioni in scrittura allo stesso CAN BUS dell'auto dove girano i messaggi relativi al servosterzo, al servofreno e così via. Insomma, attraverso questa falla ci si può impossessare del sistema elettronico di assistenza alla guida (spero solo di quello) e forzare, ad esempio, il gas al massimo, spegnere il servofreno e forzare il servosterzo a girare il volante da un lato, e magari fare questo solo quando l'auto procede ad alta velocità, in modo di non lasciare spazio per un intervento d'emergenza al guidatore.

In seguito alla pubblicazione di un video dove si dimostra la debolezza del sistema, la JEEP ha riconosciuto il difetto su un milione e quattrocentomila veicoli ed ha dichiarato la disponibilità di una patch del software del sistema di intrattenimento che dovrebbe risolvere il problema.

Ora, una piccola analisi dei fatti: prima di tutto c'è stato un pazzo, in altro modo non lo si può definire, che ha consentito ad un sistema potenzialmente insicuro (il sistema di intrattenimento, che è connesso con internet e che esegue per sua stessa natura software che sfugge ad ogni possibile analisi esaustiva di qualità) di accedere in scrittura allo stesso canale dove transitano le informazioni vitali del veicolo. Certo, probabilmente il sistema di intrattenimento ha bisogno di conoscere informazioni quali la velocità ed i giri del motore, per regolare di conseguenza il volume dell'autoradio, e magari il navigatore ha bisogno di conoscere i dati odometrici che si ricavano dalla posizione dello sterzo, dai sensori dell'ABS, dagli accelerometri e dei clinometri sicuramente già presenti a bordo per i vari automatismi di guida in modo da poter mantenere la posizione dell'auto anche quando il GPS non riceve informazioni dai satelliti. Bene, per ottenere questi dati però non c'è bisogno di poter "scrivere" sul bus. Limitare l'accesso alla lettura, su di un BUS CAN, è elettricamente fattibile e, se lo si fa, non esiste nessun baco software che consenta di interferire sui dati vitali della macchina. Perché non farlo, allora? Mi vengono in mente due possibilità: la prima, la più banale, semplicemente per ignoranza. Le nuove generazioni di progettisti spesso lavorano in modo talmente compartimentato che i softwaristi, ad esempio, ignorano completamente le reali implicazioni dell'hardware che stanno usando. La seconda, che implica anche una presa di responsabilità da parte di un asino che, per risparmiare qualche euro, ha deciso di seguire una strada rischiosa, è che il sistema di intrattenimento avesse bisogno effettivamente di agire in un qualche modo sul BUS perché, nel progetto del sistema, non si è provveduto a separare i dati vitali da quelli generali, cosa che si verifica tipicamente per risparmiare sui cablaggi o per aggiungere funzioni ad un sistema preesistente senza modifiche radicali.

Ecco, ho detto le parole magiche, asino e responsabilità. Come é possibile che, con le moderne procedure di certificazione, possa passare una cosa del genere? Per spiegarlo dovrò scendere un attimo sul tecnico:

A fronte di ogni decisione su un sistema potenzialmente pericoloso c'è la valutazione dei pericoli. Un pericolo è un qualsiasi evento nefasto che abbia una possibilità, per quanto remota, di manifestarsi. Per prima cosa si fa l'elenco dei pericoli. Giusto per restare in tema, identifichiamone uno: Pericolo che un malware presente sul sistema di intrattenimento possa inviare sul CAN BUS messaggi in grado di disturbare il sistema di assistenza alla guida. 

Una volta identificati tutti i pericoli, per ogni singolo pericolo si determina la "pericolosità", ovvero il danno possibile, che può variare da "niente di grave" (Negligible) fino a "Distruzione dell'universo o quanto meno della vita come noi la conosciamo" (Catastrophic) e la probabilità dell'evento che può variare da "frequente" a "impossibile" e, usando una tabella simile a quella riportata in figura, si determina se il pericolo sia accettabile o meno. 

Fatto questo si agisce, a seconda del fatto che il pericolo identificato sia Negligible, Undesiderable, Severe o Unaccettable come indicato nella seguente tabella.

La prima cosa che si può notare, osservando le due tabelle precedenti che sono comuni con modifiche non rilevanti alla maggior parte delle procedure di analisi dei rischi, sia che si tratti di centrali nucleari sia che si tratti di automobili, strumenti medicali o, nel caso. tostapane, è l'assenza di numeri. Nella maggior parte dei casi è chi effettua l'analisi dei rischi che decide, ad esempio, se per definire occasionale un evento è necessario che la sua frequenza media sia di uno ogni anno o uno ogni 1000 anni. Questo, ovviamente, deve essere stabilito in primis ed i numeri devono esser "credibili". Analogamente cosa significhi, ad esempio, "critical", lo decide sempre chi compila l'analisi dei rischi. E' critical la possibilità che il sistema di guida abbia comportamenti "anomali" che costringano il guidatore a prendere provvedimenti attivi per evitare un incidente, restando per altro funzionanti i comandi dell'auto, è catastrofico o magari è solo marginale? Certo, una classificazione non realistica dei rischi è contestabile, ma da chi? Avendo lavorato in ambito nucleare, medicale e ferroviario posso dire che in questi ambiti a volte (non per tutte le tipologie di oggetto) l'analisi dei rischi è sottoposta alla revisione di un ente certificatore. Non credo però che questo sia vero in ambiti diversi e, sicuramente, non è vero per tutte le categorie di oggetto.

A prescindere da questo, però, ammettiamo pure che il pericolo precedentemente identificato sia stato classificato correttamente come "critical" e che "Remote" indichi una frequenza che ragionevolmente potrebbe essere al massimo di un evento ogni diecimila anni e che "Improbable" indichi una frequenza massima di un evento ogni centomila anni.

Adesso vene il bello. Prima di tutto, l'introduzione di un sistema di intrattenimento è un "improvement" tale da rendere accettabile il passaggio da Negligible a Undesiderable? Io direi assolutamente di no, ma la cosa è discutibile. Se prendiamo per buona la mia opinione, allora dobbiamo mantenere il rischio al di sotto di un evento ogni centomila anni. E come facciamo ad analizzare le probabilità di un evento software (una falla che consenta ad un malintenzionato di impossessarsi del sistema) su di un sistema la cui complessità sfugge da ogni possibile analisi? Semplice, basandoci sui pregressi. Se, ad esempio, ci sono già più di un milione di sistemi che funzionano da un anno senza che nessun malintenzionato sia riuscito ad identificare questa falla, ci sentiamo autorizzati a dichiarare che il fenomeno, storicamente, non si è verificato un un milione di anni di funzionamento, e qui casca l'asino. Certo, possiamo dichiararlo e, di fatto, è quello che necessariamente hanno dovuto fare i progettisti della JEEP per completare l'analisi dei rischi, ma è lecito farlo? No, in questo caso io credo di no, perché stiamo facendo considerazioni su un sistema che comprende anche un mondo esterno in evoluzione ed abbiamo giusta tralasciato un milione di anni di evoluzione del mondo esterno stesso. Tradotto in altre parole, ipotizzando ad esempio che al mondo ci siano un centinaio di persone di talento che impiegano il loro tempo nel tentativo di forare questo sistema, un milione di sistemi funzionanti ininterrottamente per un anno provano solamente che cento anni di tentativi non hanno identificato falle nel sistema. Cento milioni di sistemi funzionanti in un anno proverebbero esattamente la stessa cosa.

Ed infine due parole sulla soluzione: Mettere una toppa al software del sistema di intrattenimento per chiudere la falla trovata dagli hacker non risolve assolutamente il problema di una analisi dei rischi fallace che è stato evidenziato dai fatti. L'unica soluzione possibile è di natura hardware. Ogni altra soluzione è solo in palliativo, il rischio dovuto ad un calcolo delle probabilità capzioso rimane ed è inaccettabile. La Jeep dovrebbe prenderne atto e modificare l'hardware di tutte le auto vendute (o al limite disattivare il sistema di intrattenimento ed indennizzare gli acquirenti). Se questo non può essere fatto senza rischiare il fallimento, ebbene, che fallisca. Io non sentirei certo la mancanza di una azienda che affida un progetto così delicato a dei dilettanti o a dei maneggioni.