Cybersecurity nell’internet delle cose: tutte le caratteristiche fondamentali

Alla metà degli anni ’90 gli estensori di questa nota, insieme a pochi altri amici, unirono forze e ingegno per dare una impostazione organica e consistente al nascente mondo della sicurezza dei grandi sistemi informatizzati.

Con un occhio ai pochi standard allora vigenti e l’altro alla sfida di concepire un processo di sicurezza dei dati effettivamente attuabile in azienda, furono introdotti alcuni concetti fondamentali, che erano prima di allora sostanzialmente estranei al mondo aziendale: concetti quali macrodati – cioè insiemi di informazioni omogenee per esigenza di protezione – e le loro qualità di riservatezza, integrità e disponibilità, i concetti di specifica funzionale e attuativa delle contromisure articolate in fisiche, logiche e organizzative, una metodologia di analisi dei rischi divenuta poi un classico, il concetto di perimetro d’intervento, articolato in componenti, e ancora di minacce, agenti e attacchi assieme ad altri concetti di base divenuti ormai parte integrante della cultura e della pratica della messa in sicurezza dei sistemi di gestione delle informazioni (brevemente, sistemi gestionali).

Veniva a definirsi nettamente la differenza tra il concetto di security (riguardante sostanzialmente le informazioni, bene sommo del mondo gestionale), finalizzato a conmbattere gli attacchi di attori malintenzionati, rispetto alla safety, che riguardava (e riguarda) la sicurezza delle persone e la protezione dei beni materiali tangibili.

Se a distanza di vent’anni tutto questo impianto, sia concettuale che concreto, ha trovato attuazione in numerose aziende, soprattutto le maggiori, nelle quali il processo si giova della attività professionale di decine e centinaia di addetti, la stessa cosa purtroppo non può dirsi, anche fatte le debite proporzioni, per le aziende di media e piccola dimensione in cui il problema di dotarsi di una infrastruttura che ne garantisca la security dal punto di vista gestionale è ancora presente.

La sfida della security (e safety) nei sistemi embedded

Mutatis mutandis, la medesima sfida – intesa come riordinamento di concetti e definizione di termini a tutt’ora di vago contenuto semantico e carenti per quanto riguarda una visione correlata delle entità in gioco – si rinnova oggi a proposito della messa in sicurezza dei cosiddetti sistemi embedded, vale a dire di quegli oggetti informatici che svolgono le piú varie funzioni, ma in genere specializzati, dotati di uno o piú “computer” interni dedicati, variamente denominati (control unit, PLC, ECU, etc.), tipicamente caratterizzati da unità periferiche specializzate nel rilevare una serie di grandezze ambientali – sensori – e relativi attuatori, isolati o collegati in rete (da cui l’Internet of Things).

Poiché crediamo che le analogie lascino il tempo che trovano e possano essere talvolta fuorvianti se prese troppo sul serio, troviamo interessante indicare oltre ad esse anche le differenze tra il mondo della sicurezza gestionale, ovvero relativo alla gestione delle informazioni, ed il mondo della sicurezza delle cose ovvero dei sistemi embedded. Ciò soprattutto al fine di strutturare e definire il processo complessivo di cybersecurity da attuare in azienda, o un processo di verifica laddove tale processo sia già esistente, derivando il tutto dalle positive esperienze maturate nell’ambito della sicurezza dei sistemi gestionali ed evidenziando le esistenti differenze.

Spendiamo due parole per il termine cyber security, che non ci piace come la maggior parte delle parole che iniziano con cyber. Questo termine, tuttavia, è entrato oramai in largo uso per indicare la sicurezza dei sistemi fisici in cui apparati di controllo digitali giocano un ruolo fondamentale, e ci sembra che inventarci un altro termine o iniziare una battaglia lessicale contro questa parola sia un po’ una lotta contro i mulini a vento.

La prima considerazione da fare è proprio sulla dicotomia security/safety. Se nel mondo gestionale si tratta di una distinzione abbastanza netta, nel mondo dei sistemi embedded si tratta invece di qualcosa di piú sfumato, in quanto una compromissione da parte di un agente malevolo di un tale sistema quasi inevitabilmente porta al danneggiamento (o addirittura ad esso è finalizzata) di strutture fisiche, e quindi a problemi che tipicamente rientravano nella safety. Quindi è la semplice presenza di un agente malevolo, causa dell’attacco, che ci permette di collocarci nettamente nell’ambito della cybersecurity.

Un modo leggermente piú formale per caratterizzare questa situazione potrebbe essere il seguente. Mentre nel mondo gestionale le entità da proteggere sono le informazioni (nei loro aspetti di integrità, disponibilità e riservatezza), nel mondo embedded si tratta di proteggere le funzioni (correttezza), limitandosi i dati a qualche log circa, ad esempio, i percorsi di un’autovettura o il comportamento del suo guidatore, o i dati dell’infotainment, tutti dati che pongono al massimo problemi di gestione della privacy.

Ovviamente un altro insieme di dati nel mondo embedded sono i parametri necessari al funzionamento del sistema sensori-attuatori che esercita nel mondo fisico la funzione del sistema embedded; ma anche in questo caso si tratta di poche cose, e dal punto di vista concettuale possiamo considerarli parte del codice.

Nel mondo embedded, invece, si potrebbe ipotizzare che un’azione malevola capace di avere conseguenze fisiche (come sterzare indebitamente un’auto o interferire con il suo sistema di guida assistita) possa avvenire solo modificando il codice esistente o iniettandone di nuovo, oppure interferendo con i dati provenienti dai sensori: si tratta di dati di natura, mole e gestione totalmente diversa dal dato aziendale tipico. Per farla breve, nel mondo embedded il rischio di furto delle informazioni sembrerebbe essere del tutto secondario rispetto a quanto accade nel mondo gestionale.

Un’ulteriore considerazione riguarda la resilienza delle due tipologie di sistema. In ambito gestionale, per varî motivi, le contromisure di tipo logico sono nella maggior parte dei casi applicate successivamente non solo alla progettazione del codice applicativo, ma anche della sua realizzazione, rilascio e messa in funzione. È il caso dei grandi sistemi legacy, ancora tanto diffusi in ambito aziendale e caratterizzati dall’ampiezza delle loro superfici di attacco (componenti di reti, molteplicità dei server interconnessi, infinità di cliente periferiche di vario tipo, etc.). Nel caso dei sistemi embedded la superficie di attacco risulta essere assai piú limitata, il codice piú compatto e dedicato, di progettazione e realizzazione recente. Di conseguenza, tramite adeguate prassi di software engineering, è possibile dotare il codice di un elevato livello di resilienza (ricordiamo che per resilienza di un sistema si intende la sua intrinseca capacità di consentire un adeguato grado di funzionalità e protezione dei dati anche in caso di esito positivo di un attacco).

Infine, last but not least, si è già accennato poco sopra alla circostanza che nei sistemi gestionali la superficie di attacco risulti assai piú ampia ed articolata (si pensi, ad esempio, agli aspetti di social engineering, peculiari del mondo gestionale). Questo ovviamente è un fattore molto importante.

Quanto sopra può essere sintetizzato nella tabella che segue.

Contromisure cybersecurity nei sistemi embedded

Diamo ora uno sguardo alla tipologia delle contromisure adottabili nei due campi, con particolare riferimento a quelle di natura logica. Per quanto riguarda infatti le contromisure di natura organizzativa e fisica ci riproponiamo di trattare l’argomento in seguito (leggi anche le tecnologie per la sicurezza nell’internet delle cose).

Nella maggioranza dei casi i sistemi embedded sono sistemi complessi, in cui tipicamente dei dati vengono acquisiti dall’ambiente, elaborati da diversi sistemi di trattamento dell’informazione, e le conseguenze di questa elaborazione dei dati si trasformano in qualche azione fisica. Facendo eccezione ai casi in cui è presente una connessione in rete, la superficie di attacco consiste tipicamente in ogni canale che permette di far entrare dati nel sistema: ad esempio, nel caso del sistema informatico a bordo di un veicolo tradizionale, costituito anche da decine di ECU (Electronic Control Unit, e cioè il sistema embedded che controlla uno specifico sottosistema del veicolo) i possibili canali d’accesso sono la porta OBD (On Board Diagnostic), tipicamente posta sotto il cruscotto, e qualche sensore che potrebbe essere accessibile in modo relativamente facile dall’esterno (key fob, sensori wireless di pressione delle gomme, etc.), ed eventualmente qualche interfaccia Bluetooth per qualche ragione attiva, oltre che la USB collegata al sistema di on board entertainment.

In un veicolo del prossimo futuro, in cui la guida assistita o autonoma gioca un ruolo importante, possiamo immaginare di avere una connettività Internet via 4G, di avere una WiFi a bordo, etc. e la superficie di attacco si allarga abbastanza.

Ma tutto questo si deve paragonare all’immensa superficie di attacco costituita dal sistema informatico gestionale di un’azienda: decine, centinaia o migliaia di computer client – desktop o notebook – accessibili a dipendenti non necessariamente fedeli o anche solo consapevoli dei rischi che possono far correre all’azienda, connessioni Internet a larga banda ridondanti, telefoni VOIP, dischi rimuovibili e chiavette USB che possono circolare portando in giro documenti sensibili, etc., il tutto a fronte di un “ventre molle” costituito da computer per uso generale e relativamente potenti, in grado di essere trasformati in rampe di lancio per ulteriori e piú potenti attacchi (vs. la potenza di calcolo estremamente limitata di un’ECU).

Inoltre le procedure standard per la valutazione della sicurezza di un sistema informatico (Vulnerability Assessment, in cui viene verificata la presenza delle vulnerabilità del sistema senza effettivamente andare a sfruttarle, e Penetration Testing, in cui le vulnerabilità riscontrate o supposte sono sfruttate per determinarne in concreto la pericolosità) assumono nel mondo embedded un significato diverso.

Innanzitutto, un’operazione di valutazione della sicurezza di un sistema gestionale pone il valutatore di fronte ad un sistema tipicamente molto ampio (centinaia o migliaia di client, decine o centinaia di server) nondimeno uniforme (tipicamente Windows, nell’azienda tipica, ed eventualmente Linux/Unix per i server e qualche client MacOS), nel mondo embedded si va tipicamente “in verticale”, avendo la necessità di approfondire la valutazione della sicurezza di un singolo elemento o di un numero limitato di elementi, che però presentano una variabilità molto maggiore dal punto di vista dell’hardware e degli OS. Inoltre, mentre nel mondo gestionale una vera e propria operazione di Penetration Testing è compiuta di rado, in quanto mette potenzialmente a rischio la quotidiana funzionalità del sistema, nel mondo embedded è molto spesso facile avere a disposizione dispositivi di prova identici all’originale su cui fare tutti i test del caso, anche con effetti potenzialmente dirompenti.

La difficoltà, semmai, nel mondo embedded, è appunto la straordinaria variabilità delle architetture hardware e software. Quasi tutto il settore automotive, ad esempio, si basa su un protocollo di networking layer 1 e 2 noto come CAN (Controller Area Network) Bus, e con protocolli di livello superiore diversi. Altri settori utilizzano ancora altri protocolli di rete. La varietà nell’hardware è impressionante, e per quanto riguarda i sistemi operativi si va da dispositivi talmente elementari che non hanno nemmeno bisogno di un vero e proprio sistema operativo, con software che gira sul bare metal, a dispositivi con sopra una qualche tipologia di Linux – quando va bene – o con OS proprietari. Questa frammentazione del panorama dell’hardware e del software nel mondo embedded, probabilmente destinata a ridursi con l’aumento dell’utilizzo di componenti hardware e software standard (ad es. Ethernet e TCP/IP per il networking), è comunque una caratteristica che resterà in quanto ogni specifico settore applicativo mantiene i suoi specifici requisiti.

A conclusione di questa analisi intesa a evidenziare similitudini e soprattutto differenze tra i due mondi – potremmo definirli – “gestionale” da un lato e “ingegneristico” dall’altro concludiamo con una considerazione che può fungere da stimolo per chi, come noi, si occupa di “messa in sicurezza” di scenari informatizzati. Lo sviluppo tecnologico, in termini di innovazioni ma anche di investimenti, sembra gradualmente polarizzarsi verso l’Internet delle Cose, trasferendo alle macchine, tra loro interconnesse, funzioni e decisioni fino a un tempo assai recente proprie dell’essere umano.

Garantire un adeguato livello di sicurezza a questo scenario, condizione necessaria e abilitante perché la tecnologia, nel suo continuo progresso innovativo, possa continuare a rivestire un ruolo praticabile e vincente.