Le piattaforme IoT sono basate sul paradigma “trigger-action” e permettono agli utenti di creare delle regole che vengono eseguite in automatico tramite la combinazione di servizi digitali disponibili on-line e risorse cyber-fisiche come i dispositivi IoT (Internet of Things): per questo motivo, è utile analizzare i problemi di sicurezza che questo tipo di piattaforme possono comportare sia relativi alla definizione ed esecuzione delle regole che ai meccanismi di autorizzazione che permettono l’integrazione di vari servizi on-line.
In particolare, discuteremo le implicazioni che tali problemi possono avere sia a livello digitale che fisico a causa dell’utilizzo di sensori ed attuatori IoT.
L’esposizione non si prefigge di essere esaustiva ma si concentra su alcuni aspetti che caratterizzano questo tipo di piattaforme.
Indice degli argomenti
API e struttura delle piattaforme IoT “trigger-action”
Esempi di piattaforme IoT basate sul paradigma “trigger-action” sono IFTT (If-This-Then-That), Zapier e Microsoft Flow solo per citarne alcune.
Due esempi di regole che le piattaforme basate sul paradigma “trigger-action” sono in grado di automatizzare sono le seguenti:
- “se viene attivato l’allarme antincendio, allora spegni il forno”;
- “se qualcuno nelle mie vicinanze ha pubblicato una foto su Instagram, allora fai lampeggiare lo smartwatch”.
Le piattaforme “trigger-action” permettono l’integrazione delle funzionalità offerte da vari servizi on-line offrendo la possibilità agli utenti di scrivere delle semplici regole condizionali, la cui struttura generale è del tipo seguente: se si verifica questo evento allora questa azione deve essere eseguita.
Tipicamente, le funzionalità vengono offerte dai servizi on-line tramite API (Application Programming Interface) che costituiscono lo standard de facto per costruire e connettere tra le loro applicazioni.
Uno degli obiettivi fondamentali nella progettazione delle API è il giusto bilanciamento tra sicurezza e facilità d’uso: alcune funzionalità possono dare accesso ad informazioni riservate e quindi solo gli utenti con gli opportuni privilegi devono essere in grado di invocarle.
Allo stesso tempo, la procedura che gli utenti usano per dimostrare il loro diritto ad invocare le funzionalità deve essere la più semplice possibile per fornire la flessibilità necessaria a svolgere le varie operazioni comodamente.
Queste due esigenze, ovvero di garantire un adeguato livello di sicurezza ed un’esperienza utente senza frizioni, sono difficili da conciliare e portano spesso a problemi di sicurezza come vedremo in seguito.
I componenti fondamentali di una piattaforma IoT “trigger-action”
I componenti fondamentali di una piattaforma “trigger-action” sono quattro: canali, trigger, azioni e regole.
- I canali specificano un sottoinsieme delle API di un servizio on-line che possono essere invocate da una regola della piattaforma. Gli utenti collegano i canali ai loro account sulla piattaforma. Questo collegamento richiede l’utilizzo di un processo di delega grazie al quale un utente autorizza il canale di un servizio on-line a comunicare con il proprio account precedentemente creato presso il servizio. Ad esempio, nel caso della regola (2) di cui sopra, l’utente dovrà autorizzare il canale Instagram definito, ad esempio, dalla piattaforma IFTT a comunicare con il proprio account Instagram. Nella stragrande maggioranza dei casi, il processo di delega viene implementato grazie all’utilizzo del protocollo OAuth.
- Un canale può definire una serie di trigger ovvero di eventi che possono accadere nel servizio on-line ad esso associato. Nel caso della regola (1), il trigger è costituito dal fatto che l’allarme antincendio è stato attivato. Dal punto di vista dei servizi on-line, i trigger sono associati ad una (o più) funzionalità offerte dall’API nel canale associato.
- Un canale può anche definire delle azioni ovvero delle funzioni che devono essere disponibili nell’API del servizio on-line. Nel caso della regola (1), l’azione è la funzionalità che permette di spegnere il forno.
- Una regola combina vari canali al fine di eseguire un determinato compito in maniera totalmente automatica. Una regola consiste in due parti: (a) il trigger che definisce la condizione (if) che deve essere soddisfatta per eseguire (b) una certa azione (then). Ad esempio, la regola (1) di cui sopra integra il canale relativo al servizio antincendio con quello della logica di controllo di un forno. A seconda della piattaforma, la complessità dei trigger e delle azioni può variare molto; ad esempio, IFTT permette trigger ed azioni singole mentre Zapier permette trigger multipli o, come nel caso di Microsoft Flow, azioni complesse.
Le implementazioni attualmente disponibili di piattaforme “trigger-action” sono costituite da servizi cloud centralizzati che permettono l’esecuzione di regole su vasta scala per milioni di utenti e decine di milioni di (istanze di) regole.
I servizi in cloud permettono agli utenti sia di utilizzare regole selezionate da un catalogo che di definirne di proprie. Gli utenti interagiscono con il servizio in cloud tramite un’applicazione che possono installare sul proprio smartphone.
Piattaforme IoT: sicurezza delle regole
La possibilità di utilizzare o definire regole ed eseguirle in maniera automatica può generare rischi sia di sicurezza che di privacy.
Ad esempio, si pensi ad un utente che voglia documentare fotograficamente un viaggio ed a tale scopo crei una regola che ogni fotografia scattata col suo smartphone venga pubblicata su Twitter.
Se l’utente, una volta ritornato dal viaggio, dimentica di disattivare tale regola, si possono immaginare moltissime situazioni in cui rendere di pubblico dominio alcune fotografie possa diventare imbarazzante e quindi porre rischi seri alla privacy dell’utente.
Per quanto riguarda, invece, i rischi legati alla sicurezza, possiamo esaminare due regole con conseguenze negative dal punto di vista digitale o fisico.
Al fine di gestire facilmente gli allegati nella posta elettronica, un utente potrebbe definire una regola che carica tutti gli allegati ricevuti in una cartella OneDrive.
Se l’utente sincronizza OneDrive su tutti i propri dispositivi, la probabilità di eseguire un allegato malevolo sarebbe molto maggiore e conseguentemente anche il rischio.
Infine, per quanto riguarda i rischi alla sicurezza fisica dell’utente, si immagini una regola che permette di aprire una finestra di un’abitazione nel caso in cui la temperatura superi un certo valore soglia.
Se un ladro avesse modo di manomettere il sistema di condizionamento (ad esempio, intervenendo su un quadro elettrico posto all’esterno dell’abitazione), potrebbe alzare la temperatura ed avere più facile accesso all’interno grazie alla finestra aperta.
Prevedere i rischi di sicurezza diventa ancora più complesso non appena si realizza che si possono formare delle catene di due o più regole attivate dallo stesso utente.
Tali catene si possono formare in maniera diretta poiché il canale dell’azione di una regola A e quello del trigger di un’altra regola B sono lo stesso e l’azione di A rende vera la condizione del trigger della regola B.
Ad esempio, l’azione di A potrebbe essere “invia una mail al mio account” ed il trigger di B “arrivo di una nuova mail” sul canale Gmail.
In maniera più subdola, tali catene si possono formare anche indirettamente quando sono coinvolti dispositivi IoT: l’azione di una regola A ha un effetto sull’ambiente fisico come una variazione della temperatura, nell’intensità di un suono o dell’illuminazione e questo, a sua volta, può rendere vera la condizione del trigger di un’azione B.
Si pensi, ad esempio, ad un attaccante che sia in grado di intercettare e modificare a piacimento i messaggi che un sensore di temperatura invia alla piattaforma e che quindi possa aumentare a piacimento la lettura della temperatura di un’abitazione.
La presenza della regola precedentemente considerata, che induce l’apertura di una finestra una volta superata una certa soglia, potrebbe implicare un serio problema alla sicurezza fisica.
Si noti come un’analisi di sicurezza di queste situazioni richieda capacità di modellare non solo la semantica della singola regola che può essere eseguita sulla piattaforma “trigger-action” ma anche la sua interazione con altre rispetto alla formazione di catene di regole e questo, a sua volta, necessiti la specifica di interazioni dirette e, soprattutto, indirette tra azioni ovvero prendere in considerazione gli effetti di queste sull’ambiente in modo tale da poter modellare le condizioni dipendenti dall’ambiente.
Per fare questo è necessario individuare vari scenari applicativi (ad esempio quelli relative alle smart home) ed all’interno di ognuno di questi varie configurazioni di sensori ed attuatori IoT così da permettere agli utenti di configurare facilmente l’analisi della sicurezza.
Questa dovrà essere eseguita in maniera automatica con opportune tecniche di Intelligenza Artificiale che permettono di enumerare tutte le possibili concatenazioni di regole.
Sicurezza del meccanismo di autorizzazione
Come discusso sopra, gli utenti di una piattaforma “trigger-action” utilizzano tipicamente il protocollo OAuth al fine di autorizzare il canale relativo ad un servizio on-line ad accedere alle risorse che appartengono all’utente sullo stesso servizio.
Vi sono una serie di rischi che l’adozione di OAuth comporta e che sono relativi alla protezione dei token OAuth.
Quali rischi
Una volta che l’utente ha dato il suo consenso a che il canale di un servizio possa accedere alle sue risorse sul servizio, il protocollo OAuth crea un token che codifica il consenso dato dall’utente affinché il canale acceda ad una o più risorse di quest’ultimo.
Tale token viene quindi presentato dalla piattaforma ogni volta che un canale abbia la necessità (per eseguire una certa regola) di invocare una funzionalità dell’API che permette di accedere alle risorse dell’utente sul servizio. Si noti che chiunque presenti un token valido può eseguire la funzionalità: si parla infatti di bearer token ovvero di token al portatore.
Le vulnerabilità delle piattaforme IoT “trigger-action”
Le piattaforme “trigger-action” possono essere vulnerabili a molti tipi di attacco che portano a comprometterne sia la riservatezza che l’integrità come testimoniano molti recenti incidenti di sicurezza occorsi a servizi in cloud (come, ad esempio, Target oppure Google Docs) dove molte di queste piattaforme sono ospitate.
Nel caso un attaccante sia in grado di prendere il controllo del servizio cloud che ospita la piattaforma, si troverebbe anche ad avere accesso ai token per accedere alle risorse di moltissimi (milioni) di utenti con pesanti conseguenze per la riservatezza e l’integrità delle informazioni memorizzate in tali risorse a seconda delle azioni che i token permettono.
Questo problema è il risultato di un approccio monolitico e centralizzato alla base della progettazione delle piattaforme IoT “trigger-action”.
Soluzioni per ridurre l’impatto di un incidente di sicurezza
Appare dunque evidente la necessità di sviluppare nuove architetture per questo tipo di piattaforme IoT che permettano la segmentazione del servizio in modo tale da ridurre l’impatto di un incidente di sicurezza alla piattaforma.
Attualmente, le piattaforme cercano di ridurre i rischi derivanti dall’abuso dei token di OAuth restringendo l’insieme delle possibili funzionalità delle API che possono essere invocate dietro presentazione del token.
Nel fare questo, come anticipato sopra, si deve trovare il giusto compromesso tra sicurezza ed usabilità al fine di ridurre al minimo necessario il numero di consensi che l’utente deve fornire per poter utilizzare le regole offerte dalla piattaforma “trigger-action”.
Ad esempio, alcune piattaforme possono escludere la possibilità di cancellare risorse dietro presentazione del token poiché tale operazione rappresenta un rischio molto elevato se il token cadesse nelle mani di un attaccante.
Tuttavia, altre operazioni sulle stesse risorse vengono permesse perché ritenute meno rischiose anche se non strettamente necessarie all’esecuzione delle regole attualmente disponibili all’utente.
In futuro, l’utente potrebbe averne bisogno per eseguire nuove regole e richiedere altri consensi renderebbe l’esperienza utente meno confortevole.
Di conseguenza, è pratica comune per le piattaforme “trigger-action” creare token con associati un numero maggiore di permessi rispetto a quelli strettamente richiesti.
Questa pratica risulta essere in contraddizione con uno dei principi fondamentali della sicurezza ovvero il Least Privilege Principle, che richiede di associare il minimo insieme di privilegi a utenti e programmi affinché questi siano in grado di raggiungere il proprio scopo.
Al fine di mitigare il problema dei token OAuth con permessi in eccesso è necessario sviluppare tecniche per meglio specificare la granularità dei diritti di accesso senza peggiorare l’esperienza utente.
A tale fine, si potrebbe sfruttare la possibilità di associare delle politiche di controllo degli accessi al token che potrebbero essere valutate prima di dare accesso alla risorsa in modo tale da raffinare la precisione del processo di delega.
