Valutazioni dei rischi per il successo dell’IoT a lungo termine

Combinando sensori periferici, gateway e risorse cloud, le applicazioni Internet of Things (IoT) stanno diventando obiettivi senza precedenti a causa del numero di potenziali superfici di attacco e vulnerabilità di sicurezza che contengono. Una chiara comprensione di tali minacce, della loro probabilità e del loro impatto diventa più urgente man mano che le aziende legano più strettamente queste applicazioni alle infrastrutture aziendali. Utilizzando approcci metodici per la valutazione delle minacce e dei rischi, i team di sviluppo possono rafforzare la sicurezza laddove essenziale o prendere decisioni informate sui rischi accettabili.

L'ampia gamma di vulnerabilità della sicurezza nei sistemi connessi trova espressione fin troppo frequentemente nelle notizie. Anche un tuffo veloce nei titoli mostra una sorprendente ampiezza di attacchi, che vanno dai palesi attacchi massicci Distributed Denial-of-Service (DDoS) agli Advanced Persistent Threats (APT) estremamente nascosti che indugiano ed estraggono silenziosamente dati preziosi o preparano attacchi più estremi. Nonostante la natura sensazionalista di questi exploit, una delle lezioni più importanti apprese da questi attacchi è che l'uso di meccanismi di sicurezza e la creazione di un sistema sicuro non sono la stessa cosa. Gli hacker penetrano con successo in sistemi costruiti con tutti i tipi di meccanismi di sicurezza. Anche il team di sviluppo più attento alla sicurezza può inconsapevolmente lasciare superfici di attacco aperte nei propri progetti.
In effetti, la pura complessità dei progetti di oggi aumenta le possibilità di superfici di attacco aperte, in particolare con sistemi multistrato e connessi come le applicazioni IoT. Quando un gran numero di dispositivi programmabili di diverso tipo si connettono al cloud, la sicurezza end-to-end diventa più una probabilità statistica che una certezza assoluta. Ogni elemento in un tale sistema di sistemi interconnessi contribuisce non solo alla sua funzionalità specifica ma anche alla sua serie di vulnerabilità per l'equazione di sicurezza.
Comprendendo appieno come ogni vulnerabilità può diventare una minaccia per l'applicazione complessiva, un'impresa può decidere se il rischio associato di un exploit di successo di tale vulnerabilità aumenterà al di sopra della soglia di accettazione e alla fine richiederà mitigazione.

La capacità di ottenere questo livello di visibilità sulla natura di un rischio fornisce un valore strategico che non può essere sopravvalutato. Allo stesso tempo, intersecando le vulnerabilità della sicurezza con le valutazioni del rischio, un team di sviluppo può ideare una tabella di marcia tattica per sviluppare una risposta pratica al flusso quasi infinito di minacce a qualsiasi sistema connesso. In effetti, senza un livello più rigoroso di comprensione acquisita attraverso valutazioni delle minacce e dei rischi, anche il team di sviluppo più esperto sta scommettendo sulla sicurezza dei propri sistemi ed applicazioni. Acquisire questa conoscenza, tuttavia, inizia con una chiara comprensione delle potenziali minacce contro un sistema, ottenibile attraverso un modello di minaccia ben documentato.
I modelli di minaccia catturano le vulnerabilità di sicurezza specifiche associate alla progettazione di un sistema. La creazione di un modello di minaccia sembra concettualmente semplice: ad esempio, gli sviluppatori analizzano i loro progetti per identificare le vulnerabilità di sicurezza correlate a ciascun componente sottostante. Tuttavia, in pratica, la modellizzazione delle minacce può comportare molto più lavoro, ricerca e strategia di quanto questa semplice idea suggerisca e può produrre molto più di un elenco di problemi tecnici di sicurezza. Più ampiamente applicata, la modellazione delle minacce può anche identificare le vulnerabilità nei processi del ciclo di vita associati e politiche generali di sicurezza correlate ad un'applicazione IoT. In definitiva, ciò che costituisce un modello di minaccia accettabile può variare tanto quanto le applicazioni IoT e le organizzazioni che servono. Tuttavia, diversi modelli di minaccia condividono determinate caratteristiche e qualsiasi metodologia di modellazione delle minacce seguirà alcuni passaggi comuni.

Modellazione delle minacce

La modellazione delle minacce inizia con una descrizione accurata del sistema, il cosiddetto Target Of Evaluation (TOE), associato ad un caso d'uso specifico, come il funzionamento di un contatore dell'acqua di servizio. Se un modello di minaccia dipinge un'immagine delle vulnerabilità del sistema, la descrizione del TOE è l'area di disegno. Allargando o restringendo l'ambito del TOE, un team di modellizzazione delle minacce può espandere o contrarre l'attenzione in un processo di identificazione delle minacce. Ad esempio, il modello di minaccia del contatore dell'acqua intelligente recentemente rilasciato da Arm limita drasticamente il suo TOE, concentrandosi solo sul nucleo del sistema (Figura 1).

Figura 1: il modello di minaccia del contatore per acqua di Arm limita il suo TOE al nucleo del sistema piuttosto che includere la gamma completa di sottosistemi tipicamente inclusi in questi sistemi, risultando in un ambito di analisi più gestibile. (Fonte: Arm)

Naturalmente, un TOE confinato all'interno di un singolo sottoinsieme di un sistema o un'applicazione più ampia e complessa, si traduce in una capacità più limitata di identificare le minacce, valutare i rischi e costruire un piano di mitigazione efficace. Per un sistema complesso di sistemi come un'applicazione IoT, i modellatori di minacce con esperienza potrebbero creare una serie di modelli di minaccia, passando da una descrizione abbastanza astratta del sistema completo a descrizioni sempre più dettagliate di sottosistemi di particolare importanza o preoccupazione per l'organizzazione.
Qualunque sia l'approccio, non vi è alcun requisito assoluto per il livello di dettaglio richiesto nella descrizione del TOE. Gli approcci di modellazione che intendono fornire i dettagli esaustivi di ciascun componente possono semplicemente esaurire i partecipanti al processo. D'altro canto, i modelli troppo astratti possono nascondere sottili vulnerabilità o impedire l'identificazione di vulnerabilità sepolte profondamente in una catena di dipendenze o librerie di software di terze parti.
Un'efficace via di mezzo raccoglie un livello di dettaglio in evoluzione fino al livello necessario per catturare tutte le interazioni che attraversano i "trust boundaries" tra le zone separate e uniche di un sistema (Figura 2).

Figura 2: I modelli di minaccia dovrebbero fornire dettagli sufficienti per identificare possibili transazioni che attraversano i confini di fiducia tra le diverse zone di un sistema. (Fonte: Microsoft)

Ad esempio, un'applicazione IoT può comprendere più zone collegate a risorse cloud, gateway, dispositivi terminali IoT ed utenti. Le transazioni che operano oltre i limiti di fiducia sono particolarmente vulnerabili a una serie eccezionale di attacchi a dati trasferiti, credenziali di sicurezza o protocolli. Anche i tentativi apparentemente innocui di comunicare oltre un limite di fiducia possono creare un percorso per un attacco di "fingerprinting", in cui gli hacker utilizzano indicatori noti contenuti nella risposta del sistema per determinare i componenti sottostanti del sistema in preparazione di attacchi più diretti.
Naturalmente, la comprensione delle interazioni tra i componenti sottostanti all'interno di ciascuna zona diventa particolarmente importante se alcuni di questi componenti provengono da terze parti. Ad esempio, un dispositivo IoT che utilizza un driver del sensore di terze parti potrebbe essere vulnerabile alle minacce al confine del driver (Figura 3).

Figura 3: Sebbene questo diagramma del flusso di dati sia stato progettato per illustrare le transazioni che attraversano i confini dei driver del software desktop, gli stessi principi si applicano alle transazioni che coinvolgono componenti hardware o software di terze parti in qualsiasi sistema collegato, compresi i dispositivi IoT. (Fonte: Microsoft)

Sebbene una descrizione adeguatamente dettagliata sia essenziale per la modellizzazione delle minacce, il vantaggio è l'identificazione di minacce specifiche che si collegano a tali dettagli. Nel caso del modello di minaccia del contatore per acqua di Arm, i modellatori forniscono un elenco in linguaggio semplice delle minacce associate a ciascuna risorsa, come firmware, dati di misurazione e interazioni con entità esterne (come utenti, amministratori e attaccanti), che potrebbero intaccare il TOE.
Per il firmware, il modello descrive minacce specifiche tra cui l'installazione di firmware compromesso, le modifiche dei certificati di sicurezza associati utilizzati per autenticare gli aggiornamenti del firmware, la clonazione ed altro ancora. Sulla base dell'elenco delle risorse e delle vulnerabilità identificate, i team di sviluppo possono sviluppare una serie di obiettivi di sicurezza e metodi di mitigazione corrispondenti. Ad esempio, il modello di contatore per acqua di Arm si conclude con un elenco di requisiti di sicurezza, inclusi quelli per il firmware, come la necessità di un avvio sicuro, l'autenticazione del firmware, una risposta a un'autenticazione fallita ed altri.

Risorse disponibili

Nell'individuare potenziali minacce, poche (se presenti) organizzazioni di sviluppo possono eventualmente rimanere aggiornate su ogni possibile minaccia che potrebbe applicarsi alle attività e ai processi dettagliati inclusi nelle loro descrizioni TOE. La buona notizia è che gli ingegneri possono trovare diverse fonti pubblicate che possono aiutare in questa parte del processo. Gli sviluppatori possono utilizzare risorse pubbliche come l'elenco CAPEC (Common Attack Pattern Enumeration and Classification) per esaminare dall'alto in basso i tipi più probabili di attacchi. Quindi, possono lavorare, dal basso verso l'alto, per identificare i probabili obiettivi di attacco elencati nell'elenco Common Weakness Enumeration (CWE), che descrive i difetti intrinseci negli approcci di progettazione del sistema, come l'uso di credenziali codificate. Quando i progettisti identificano componenti hardware o software specifici utilizzati nei loro progetti, possono passare all'elenco CVE (Common Vulnerabilities and Exposures), che elenca specifici difetti del software o potenziali exploit nei componenti hardware o software disponibili.
Per le valutazioni dei rischi, risorse come il Common Vulnerability Scoring System (CVSS) forniscono un approccio coerente per la valutazione dei rischi associati a specifiche vulnerabilità. Sebbene un rischio si riferisca alla natura di una specifica vulnerabilità, include anche altri fattori come la via (vettore) utilizzato per eseguire l'attacco, la complessità dell'attacco richiesta per sfruttare la vulnerabilità ed altri. Ad esempio, un attacco che può essere eseguito attraverso una rete comporta un rischio considerevolmente maggiore rispetto a uno che richiede l'accesso fisico. Allo stesso modo, un attacco semplice da eseguire comporta un rischio significativamente maggiore rispetto a un attacco di natura estremamente complessa. Utilizzando un calcolatore CVSS, gli ingegneri possono rapidamente tenere conto di questi vari fattori che contribuiscono, arrivando a un punteggio numerico per il livello di rischio associato a una particolare minaccia o classe di minacce. Per il contatore dell'acqua di Arm, il calcolatore CVSS rileva che la combinazione di fattori coinvolti in un attacco del firmware rappresenta un punteggio di rischio critico di 9.0 (Figura 4).

Figura 4: Utilizzando il calcolatore CVSS, i team di sviluppo possono assegnare livelli di rischio specifici correlati a diverse vulnerabilità per gli asset TOE, come il firmware nel modello di minaccia del contatore dell'acqua di Arm. (Fonte: FIRST.org)

A causa dell'ampia gamma di requisiti e tecniche, esistono strumenti automatizzati come il Threat Dragon Project di   Open Web Application Security Project (OWASP), SeaSponge di Mozilla ed il Threat Modeling Tool di Microsoft per aiutare gli sviluppatori a lavorare nel processo di modellizzazione. Ciascuno utilizza una diversa metodologia di modellizzazione delle minacce, che va dalla creazione di diagrammi di sistema nel Threat Dragon Project e SeaSponge all'approccio dettagliato STRIDE di Microsoft (tradotto come  “Spoofing,” “Tampering,” “Repudiation,” “Information disclosure,” “Denial of service,” ed “Elevation of privilege”). Sebbene questi strumenti siano vecchi di molti anni e generalmente costruiti per i sistemi software aziendali, la modellizzazione delle minacce è un processo evergreen ampiamente applicabile che dipende più dagli attuali elenchi di vettori di attacco, debolezze e vulnerabilità che da metodologie specifiche. Tuttavia, stanno emergendo strumenti più recenti che promettono un legame più stretto tra una descrizione del sistema e l'identificazione delle minacce. Nonostante il rapido emergere delle tecnologie di deep learning in altre aree, permangono sfide significative nell'applicazione di queste tecnologie alle valutazioni automatizzate di minacce e rischi. Comunque la disponibilità di modelli intelligenti e strumenti di valutazione è probabile che arriverà presto.

Nel frattempo, gli sviluppatori possono trovare una varietà di raccolte che elencano i punti deboli della sicurezza, le vulnerabilità ed i modelli di attacco, al punto che tutti i dettagli disponibili possono sembrare travolgenti, in particolare per quelli che hanno appena iniziato a impegnarsi nella modellizzazione delle minacce. In effetti, una delle scuse comunemente usate per evitare la modellizzazione delle minacce è che è semplicemente troppo complicato. Piuttosto che saltare nella profondità dei dettagli, gli ingegneri possono iniziare con un approccio più modesto che si concentra solo sulle minacce più comuni. Al momento della stesura di questo articolo, OWASP sta ancora rivedendo le sue prime dieci minacce alla sicurezza IoT per il 2018, ma la lista delle top ten IoT di OWASP fornisce ancora un utile punto di partenza. In effetti, gli sviluppatori non devono andare oltre i loro siti di notizie preferiti per trovare un catalogo pronto delle principali vulnerabilità ed exploit.
Per le organizzazioni in grado di superare rapidamente le nozioni di base, tuttavia, questi stessi metodi possono rivelarsi preziosi per affrontare aspetti altrettanto critici della progettazione IoT. Ad esempio, i sistemi utilizzati nei circuiti di controllo macchina devono generalmente soddisfare i requisiti mission-critical associati, per la sicurezza funzionale. In questi sistemi, la sicurezza e la sicurezza funzionale sono così intrecciate che i modelli di minaccia adeguati per questi sistemi dovranno probabilmente includere scenari in cui la debolezza della sicurezza può comportare rischi fisici. Allo stesso modo, la sicurezza e la privacy si sovrappongono sotto molti aspetti, ma i punti deboli in entrambe le aree possono portare allo stesso risultato di una divulgazione di informazioni di identificazione personale.

Conclusioni

L'applicazione efficace della modellizzazione delle minacce e delle valutazioni dei rischi in sistemi complessi va ben oltre qualsiasi semplice elenco di opzioni e tecniche disponibili. Come ogni sistema specifico, ciascuna organizzazione di sviluppo si occupa unicamente dei propri vincoli e capacità. I requisiti di un sistema o di un'organizzazione potrebbero perdere completamente il marchio per un altro. Quale potrebbe essere l'unico requisito comune, è la necessità di eseguire in primo luogo le valutazioni delle minacce e dei rischi. Anche così, un'impresa dovrebbe tentare di creare un modello di minaccia "completo" e una valutazione del rischio? La risposta breve è no. In effetti, un tentativo di farlo non sarebbe all'altezza di questo obiettivo perfetto.
Non è possibile prevedere perfettamente i risultati. I processi naturalmente caotici nel mondo ed il flusso e riflusso tra le mitigazioni del sistema e gli exploit degli hacker alla fine fanno deragliare qualsiasi tentativo di perfezione. Allo stesso tempo, senza creare il tipo di tabella di marcia per la sicurezza fornita da un modello di minaccia e dalla valutazione del rischio, è ugualmente impossibile evitare almeno alcune delle insidie ​​e deviazioni che portano a inevitabili violazioni della sicurezza.

Articolo pubblicato da Stephen Evanczuk per Mouser Electronics - versione originale in inglese sul sito Mouser.

 

 

 

 

 

 

 

Scarica subito una copia gratis

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend