La diffusione su larga scala dei sistemi Internet of things offre numerose soluzioni innovative come le smart homes, l’e-healthcare, la smart surveillance, le smart industries, le smart cities e le smart grids. Ciò ha originato, conseguentemente, un significativo incremento delle minacce che sfruttano le vulnerabilità dei dispositivi IoT. Pertanto, è importante sviluppare soluzioni di cyber security che siano in grado di proteggere i dispositivi vulnerabili e creare modelli di digital forensics idonei a recuperare le prove di eventuali attacchi.
In genere, le soluzioni di digital forensics dell’IoT si rivolgono a domini applicativi specifici come gli smart wearables, gli smart surveillance systems e le smart homes. È, invece, opportuno avvalersi di un approccio olistico che copra i diversi domini applicativi ed elimini la proliferazione di modelli ad hoc. Questo articolo prospetta un modello di analisi forense per l’IoT basato sullo standard internazionale ISO/IEC 27043.
I rischi legati all’IoT
L’IoT è un’infrastruttura globale che offre servizi avanzati attraverso l’interconnessione di oggetti (fisici e virtuali) basati sulle tecnologie esistenti, in evoluzione e interoperabili, dell’informazione e della comunicazione. L’IoT collega oggetti elettronici, elettrici e non, per fornire comunicazione senza soluzione di continuità e servizi contestuali. La crescita esponenziale dei dispositivi IoT, la natura dei servizi forniti e i dati che gli stessi generano hanno contribuito all’aumento delle violazioni della sicurezza e della privacy, nonché ad altri tipi di usi illeciti. La necessità di indagare su questi nuovi incidenti ha visto la nascita di una nuova disciplina, denominata Internet of Things Forensics, che si concentra sull’identificazione, la raccolta, l’organizzazione e la presentazione delle evidenze riguardanti gli incidenti nell’infrastruttura dell’IoT. L’IoT si sviluppa su diversi livelli che comprendono: i dispositivi eterogenei, le reti interconnesse e i diversi protocolli di comunicazione e le applicazioni. La Figura 1 mostra una tipica architettura stratificata di Internet of Things.
Figura 1. Architettura stratificata di Internet of Things.
I tre livelli – Things layer, Edge layer e Applications layer – sono fisicamente e logicamente divisi in base alle loro funzionalità. Generalmente, il Things layer e l’Edge layer fanno parte della stessa rete e sono fisicamente vicini l’uno all’altro. Pertanto, la maggior parte degli approcci forensi all’IoT considera solo questi due livelli; mentre l’Applications layer è lasciato alla cloud forensics. Gran parte della ricerca in materia di digital forensics si è concentrata sulla computer forensics, la network forensics e la cloud forensics, mentre è stato dedicato poco lavoro al settore dell’informatica forense dell’IoT. Le principali ragioni sono dovute all’eterogeneità dei dispositivi e dei diversi protocolli di comunicazione e dei domini applicativi. Ciò rende molto difficile l’identificazione delle superfici di attacco comuni e la realizzazione di soluzioni globali di sicurezza e di analisi forense. Tuttavia, diversi ricercatori hanno proposto modelli o framework per analisi della sicurezza e per le indagini forensi specializzati in determinati ambienti dell’IoT.
Il modello
Il modello di IoT forensics proposto si basa sullo standard internazionale ISO/IEC 27043[1]. Lo standard rappresenta la digital forensics come una metodologia comprensiva di diversi processi, ognuno dei quali prevede una o più attività. I processi dell’ISO/IEC 27043 corrispondono alle fasi del modello proposto e le attività ai moduli. In Figura 2 è rappresentato il modello suddiviso in tre fasi: (1) la fase di Forensic Readiness (Proactive); (2) la fase di Forensic Initialization (Incident); e (3) la fase di Forensic Investigation (Reactive). Ogni fase è composta da un set di moduli. Sebbene tutti i moduli si concentrino su dispositivi dell’IoT, se necessario, lo stesso approccio può essere mappato anche all’Application layer.
Fase di Forensic Readiness (Proactive)
Durante la fase di Forensic Readiness (Proactive) vengono raccolte e memorizzate le evidenze digitali relative ad un ambiente di IoT. Ciò riduce i tempi, gli effetti ed i costi associati alle indagini sui successivi incidenti. La fase di Forensic Readiness prevede sei moduli.
- Modulo 1.1 (Readiness Configuration): questo modulo coordina tutte le attività di readiness. Fornisce servizi configurabili per la personalizzazione del modello nei diversi ambienti di IoT e lo rende olistico. La configurazione è eseguita dagli amministratori e/o esperti di sicurezza ed è funzionale all’impostazione delle specifiche dell’applicazione, del dispositivo e del contesto, al fine di realizzare il rilevamento degli eventi, la raccolta e la conservazione forense dei dati.
Il modulo di configurazione fornisce le seguenti funzionalità di base:
- Offre un meccanismo per inserire le informazioni dettagliate sui dispositivi in un ambiente IoT (ad esempio, aggiungere informazioni sugli smart devices in una smart home). Le informazioni di ciascun dispositivo includono il nome, il produttore, il tipo, l’ID, i dettagli del software, le funzionalità, le interazioni da registrare (in base agli scenari definiti) e la descrizione del dispositivo.
- Semplifica il modulo di configurazione del dispositivo nell’identificazione delle proprietà appropriate e nella configurazione di ciascun dispositivo per la raccolta delle evidenze.
- Facilita il modulo di rilevamento degli eventi nell’identificazione di fatti specifici che devono essere registrati.
- Favorisce il modulo di raccolta delle evidenze sui dati relativi agli eventi specifici che devono essere raccolti.
- Agevola il modulo di conservazione delle evidenze su come devono essere formattati e archiviati i dati raccolti per le indagini successive.
È importante notare la differenza tra un evento e un incidente. Un evento indica una o più interazioni con i dispositivi IoT che possono riguardare il cambio del loro stato (ad esempio, il cambiamento delle letture del sensore di un smart watch e una richiesta di dati del sensore inviata da un’applicazione mobile ad un smart watch); un evento non deve essere necessariamente sospetto. Al contrario, un incidente è una sequenza di eventi sospetti che interrompe il regolare funzionamento dei dispositivi Internet; un incidente ha, generalmente, un impatto sulla sicurezza e/o sulla privacy e/o sulla disponibilità.
- Modulo 1.2 (Scenario Definition): questo modulo definisce gli scenari come sequenze di eventi che sono forensically sensitive a specifiche applicazioni IoT (ad es. le interazioni anomale con un dispositivo e i tentativi di autorizzazione non riusciti durante l’accesso ad un servizio). Nel livello delle applicazioni, gli scenari sono definiti per capire come gestire i dati della configurazione e di business (ad esempio, chi può accedere o modificare i dati). Ogni scenario specifica gli eventi che cambiano gli stati dei dispositivi IoT. Le modifiche di stato sono identificate insieme alle proprietà dei dispositivi associati.
- Modulo 1.3 (Device Setup): questo modulo identifica ogni nuovo dispositivo aggiunto all’ambiente e le sue proprietà forensi prima che il dispositivo diventi operativo. Esso interroga il modulo di readiness configuration per conoscere le impostazioni specifiche del dispositivo e memorizza tutte le informazioni di configurazione in un database sicuro per condividerle con gli altri moduli. Inoltre, tiene traccia del momento in cui un dispositivo viene rimosso dall’ambiente.
- Modulo 1.4 (Event Detection): questo modulo identifica gli eventi forensically-sensitive in base agli scenari definiti nel modulo di definizione degli scenari. È possibile specificare le regole per la convalida delle interazioni dei dispositivi, del traffico di rete e per l’identificazione dei potenziali eventi. Nell’applications layer, è possibile progettare un modulo autonomo per monitorare gli aspetti di sicurezza delle configurazioni di sistema e delle richieste di autenticazione e di accesso ai dati. La Figura 3 mostra un esempio di evento in uno scenario con smart watch. Quando i dati del sensore sono aggiornati oppure è inviata una richiesta di tipo pull da un’applicazione mobile allo smartwatch, i dati associati vengono registrati come prova potenziale. I dati sono sincronizzati periodicamente con un’applicazione mobile e possono essere caricati su cloud storage per le successive elaborazioni.
- Modulo 1.5 (Evidence Collection): questo modulo si occupa della raccolta di potenziali evidenze dai dispositivi, dai controller e dai dispositivi di rete dell’IoT. Un esempio è la registrazione dei comandi emessi su un dispositivo IoT con i relativi timestamp. Vengono registrate l’origine dei comandi inviati ai dispositivi. La raccolta delle evidenze è più semplice se il sistema operativo del dispositivo supporta le richieste forensi per l’estrazione delle informazioni utili tramite chiamate di sistema. Altrimenti, è necessario creare un livello software autonomo, sopra il sistema operativo, dedicato alla raccolta delle evidenze dai dispositivi programmabili. In entrambi i casi, è necessario un controller perimetrale che invia i comandi al software del dispositivo per la raccolta e la conservazione delle evidenze. Per tutti gli altri dispositivi, è implementato un meccanismo di raccolta esterno nel nodo controller. Quando i dispositivi eseguono applicazioni in tempo reale, è importante conoscere il tipo di dati generati e il modo in cui vengono archiviati; ciò consente di sviluppare meccanismi avanzati di raccolta dei dati. Nell’application layer, le sorgenti di tutte le interazioni non riuscite (ad es. le modifiche alla configurazione, le richieste di autenticazione e di accesso e le chiamate API sospette) vengono registrate per le eventuali indagini. Tutte le evidenze raccolte devono essere formattate in base ai requisiti di archiviazione e di elaborazione.
- Modulo 1.6 (Evidence Preservation): questo modulo si occupa dell’archiviazione sicura delle evidenze per le indagini. Molti dispositivi IoT hanno una memoria flash integrata che memorizza il sistema operativo e i file eseguibili in tempo reale. Questa memoria può essere utilizzata per archiviare dati forensi, che potrebbero essere inviati periodicamente ad un server centrale per l’archiviazione a lungo termine e la successiva elaborazione. Un’archiviazione alternativa può essere fornita dai fog node. Le evidenze devono essere archiviate in modo sicuro e protette dalle modifiche accidentali e/o manomissioni intenzionali. Le potenziali evidenze dell’applications layer possono essere conservate in secure cloud storage.
Fase di Forensic Initialization (Incident)
La fase di Forensic Initialization (Incident) è composta di tre moduli: (2.1) Incident Detection; (2.2) First Response e (2.3) Investigation Preparation.
- Modulo 2.1 (Incident Detection): questo modulo si occupa del monitoraggio continuo dell’ambiente e rileva i comportamenti malevoli utilizzando tecniche e strumenti adeguati. Tutte le interazioni dell’utente sono convalidate in base a regole definite dagli amministratori o dagli esperti di sicurezza. A livello di dispositivo e di controller, le regole sono implementate tramite script intelligenti che identificano le interazioni pericolose (ad esempio, uno script rileverà un numero di richieste di autenticazione non riuscite da parte di un dispositivo IoT che supera una determinata soglia). A livello di rete, i sistemi di rilevamento delle intrusioni e gli altri strumenti di sicurezza vengono utilizzati per monitorare il traffico in tempo reale. Per rilevare incidenti a livello di applicazione sono utilizzate tecniche e strumenti di sicurezza del cloud. Quando viene rilevato un incidente, viene segnalato per le azioni successive.
- Modulo 2.2 (First Response): questo modulo si occupa della trasmissione degli avvisi prioritari agli utenti o agli amministratori per intraprendere un’azione immediata. In caso di incidente, viene inoltrato un avviso ad un digital forenser. Se è necessario, i dispositivi, i controller e i software possono essere sospesi per prevenire ulteriori danni all’ambiente. Tutti i componenti correlati devono essere scollegati dall’ambiente di produzione fino alla conclusione dell’indagine forense.
- Modulo 2.3 (Investigation Preparation): questo modulo si occupa delle attività di supporto al processo investigativo. Le attività comprendono:
- L’implementazione di un piano di gestione degli incidenti. Il piano specifica come deve essere svolta un’indagine. Comprende anche l’origine e la formattazione delle evidenze.
- L’attivazione di un incident response team in grado di implementare il piano di gestione degli incidenti. Ogni incidente è analizzato da un team dedicato.
- Al team deve essere fornito il supporto tecnico e di altro natura, compreso il supporto organizzativo e operativo.
- L’incident response team è informato e formato sulla gestione degli incidenti.
- Il piano di gestione degli incidenti è rivisto e migliorato periodicamente, usando tecniche come i test, le esercitazioni e le simulazioni.
- Il miglioramento del piano di gestione degli incidenti è documentato per consentire un’attuazione pratica.
Fase di Forensic Investigation (Reactive)
La fase di Forensic Investigation (Reactive) implementa il piano investigativo per ricostruire la sequenza degli eventi. Le potenziali evidenze raccolte durante la fase di readiness sono acquisite ed analizzate per dimostrare o confutare che si è verificato un attacco o una violazione e per identificare i dispositivi della vittima. Le conoscenze acquisite durante l’indagine sono utilizzate per migliorare la sicurezza, le tecniche e gli strumenti forensi utilizzati nell’ambiente. La fase di Forensic Investigation comprende i seguenti cinque moduli:
- Modulo 3.1 (Evidence Acquisition): questo modulo si occupa dell’identificazione delle evidenze relative all’incidente segnalato e alla sua acquisizione in un archivio sicuro. Potrebbe essere necessario recarsi nella posizione fisica dei dispositivi IoT in questione ed acquisire l’immagine forense. Per identificare i comportamenti avversi possono essere utilizzate varie tecniche che consentono di estrarre il firmware e le immagini di memoria. Nel livello applicazioni vengono raccolti gli artefatti relativi all’ambiente cloud come le virtual machine images ed i relativi logs, gli hypervisor logs, gli user activity logs, i database access logs e gli application logs.
- Modulo 3.2 (Evidence Examination and Analysis): questo modulo si occupa della formattazione delle evidenze acquisite per renderle idonee all’analisi. Per identificare i modelli di attacco nelle reti di IoT possono essere applicate le tecniche di machine learning. Le tecniche e gli strumenti devono essere periodicamente aggiornati o potenziati per identificare nuovi attacchi. Gli strumenti analitici possono essere utilizzati a livello di applicazioni per identificare comportamenti sospetti relativi a richieste di elaborazione, di archiviazione e di accesso ai dati.
- Modulo 3.3 (Incident Reconstruction): questo modulo si occupa della ricostruzione di un incidente sotto forma di una sequenza di eventi sospetti basata sui risultati dell’esame delle evidenze e del modulo di analisi. Il modulo comprende le seguenti due attività:
- L’attività di interpretazione delle evidenze: in grado di analizzare i risultati sulla base di schemi predefiniti per la ricostruzione di un incidente (ad esempio, identificare le sequenze di eventi nei dispositivi e nell’edge level e mapparli al livello delle applicazioni per capire cosa sia successo). Gli schemi possono essere adattati alle politiche di sicurezza standard o definiti dagli esperti di sicurezza per specifici scenari applicativi di IoT (ad esempio, una politica di sicurezza può essere definita per limitare il numero di autenticazione non riuscita o di richieste di accesso). Alcune politiche possono definire il comportamento standard dei dispositivi o dell’ambiente IoT per evitare le comunicazioni indesiderate con i dispositivi estranei.
- L’attività di reporting: genera un rapporto formale che comprende i risultati degli incidenti relativi agli attacchi, alle vittime e alle relative tempistiche.
- Modulo 3.4 (Evidence Presentation): questo modulo comprende la preparazione e la presentazione delle evidenze per conformarsi ai requisiti imposti dalle procedure legali. Il rapporto finale può includere immagini e animazioni per migliorare la chiarezza espositiva.
- Modulo 3.5 (Investigation Closure): questo modulo si occupa delle attività post-investigazione, in particolare fornisce il feedback e archivia le evidenze. Fornisce un feedback al modulo di esame e analisi delle evidenze e si occupa dell’archiviazione delle tracce e della registrazione delle evidenze. Possono essere creati casi di studio per migliorare le indagini future.
Le Tecnologie fog/edge computing e blockchain
In questa sezione sono indicate due tecnologie emergenti, il fog/edge computing e le blockchain, che possono migliorare i processi forensi dell’Internet of Things.
Fog/Edge Computing
I termini fog computing e edge computing sono usati, in modo interscambiabile, per descrivere il livello che sfrutta l’archiviazione e l’elaborazione dei dispositivi intermedi (fog nodes) tra i dispositivi terminali ed il cloud. Il fog computing può essere considerato un’implementazione dell’edge computing. L’edge computing porta i servizi dal cloud all’edge delle reti IoT. Poiché questi servizi includono l’autenticazione dei dispositivi, il controllo degli accessi e l’elaborazione e l’archiviazione dei dati, la maggior parte dei moduli di Forensic Readiness possono essere implementati utilizzando il fog computing.
Blockchain
Le caratteristiche distribuite e immutabili offerte dalle blockchain soddisfano le esigenze dell’IoT forensics. Nel Decision Model, le evidenze raccolte dai dispositivi, dai controller e dalle applicazioni cloud devono essere gestite come in un libro mastro. La soluzione ideale per l’IoT forensics è rappresentata da una blockchain, con autorizzazione privata, in cui il numero di nodi è limitato e l’accesso è fornito solo agli utenti selezionati. La natura distribuita di una blockchain si combina con il fog computing e fornisce i servizi di raccolta e di archiviazione delle evidenze. Queste possono essere raccolte da qualsiasi nodo e aggiornate sul libro mastro. L’immutabilità di una blockchain assicura che l’evidenza non venga manomessa e sia sempre valida. Una blockchain supporta anche la verifica della provenienza delle evidenze. Queste due proprietà consentono agli investigatori di accedere alle evidenze in maniera affidabile da qualsiasi nodo e in qualsiasi momento.
In sintesi, le blockchain possono essere utilizzate per il timestamp e l’archiviazione delle evidenze raccolte dai dispositivi IoT. La blockchain può tenere traccia delle modifiche apportate al firmware dei dispositivi IoT e ripristinare automaticamente il firmware originale in caso di manomissione. Approcci simili possono essere usati per mantenere l’integrità delle evidenze dell’IoT.
Le sfide future
L’IoT forensics è una sfida per i ricercatori a causa della complessità dei dispositivi e delle applicazioni connesse, della mancanza di standard uniformi tra i produttori dei dispositivi e gli sviluppatori dei sistemi. La maggior parte degli strumenti è progettata per funzionare unitamente ai sistemi convenzionali dotati di notevoli capacità di archiviazione e elaborazione, anziché con dispositivi piccoli e specializzati. Le sfide sono imposte anche dall’eterogeneità dei dispositivi, delle applicazioni e delle tecnologie di comunicazione. Di conseguenza, i dati memorizzati hanno diversi formati e richiedono metodi di acquisizione personalizzati.
Un’altra sfida è rappresentata dall’estrazione dei dati volatili dai dispositivi IoT prima che vengano sovrascritti. Sono necessari meccanismi sofisticati per la realizzazione di una raccolta rapida. La collezione può essere accelerata archiviando i dati sul dispositivo stesso, ma i dati devono essere spostati periodicamente in una memoria supplementare per liberare la memoria del dispositivo. I dati possono anche essere sincronizzati con i fog node o i cloud storage ad intervalli regolari. Questo approccio è più sicuro sul lungo termine perché i dispositivi IoT possono essere manomessi o addirittura distrutti. Il trasferimento e l’aggregazione delle evidenze rendono più complessa la gestione della catena di custodia; fortunatamente, questo aspetto può essere risolto utilizzando la tecnologia blockchain.
Alcune sfide sono specifiche per le fasi del modello proposto. La sfida principale della readiness phase è l’applicazione di processi forensi ai dispositivi. e al loro firmware, mentre sono in funzione. Potrebbe essere necessario sviluppare dispositivi hardware separati, con script forensi automatici, per supportare le attività di forensic readiness. Le sfide della incident phase includono il controllo dei dispositivi distribuiti in posizioni remote (la rete definita dal software potrebbe aiutare) e la comunicazione degli avvisi di incidenti. Le sfide durante la investigation phase includono la formattazione delle evidenze eterogenee in una struttura uniforme per l’esame e l’analisi e l’utilizzo di algoritmi di apprendimento automatico per rilevare nuovi attacchi (ad esempio, cross-layer attacks).
Conclusione
A causa della diversità dei dispositivi, delle reti e delle applicazioni, sono state sviluppate numerose soluzioni digital forensics dedicati a specifici ambienti IoT. Pertanto, è necessario un modello di digital forensics olistico in grado di coprire diversi ambienti di IoT e ridurre lo sforzo generale imposto dalle soluzioni ad hoc. Il modello proposto in questo articolo vuole essere olistico e coprire l’intero ciclo di vita della digital forensics. È basato sullo standard internazionale ISO/IEC 27043, è personalizzabile, configurabile e supporta molteplici applicazioni dell’Internet of Things. In futuro la ricerca si dovrà concentrare sull’implementazione ed il test del modello in domini applicativi selezionati, con l’obiettivo finale di creare un framework completo per la Internet of Things Forensics.
_
Note
- International Organization for Standardization and International Telecommunication Union, ISO/IEC 27043:2015: Information Technology– Security Techniques – Incident Investigation Principles and Processes, Geneva, Switzerland, 2015. ↑
