Sicurezza IoT: Vi presento il nostro scudo “Zero Trust” basato sul rischio!

Ciao a tutti! Oggi voglio parlarvi di un argomento che mi sta particolarmente a cuore e che, credetemi, riguarda il futuro (e già il presente) di tutti noi: la sicurezza nell’Internet of Things (IoT).

Sapete, il mondo dell’IoT e delle reti di sensori wireless (WSN) è esploso negli ultimi anni. Frigoriferi che ordinano il latte, termostati intelligenti, sensori industriali… tutto connesso! Fantastico, vero? Sì, ma c’è un “ma” grande come una casa: la sicurezza. Più dispositivi connettiamo, più porte apriamo a potenziali attacchi. E quando parliamo di IoT, non si tratta solo di rubare dati, ma anche di compromettere la disponibilità e l’affidabilità di intere reti, magari bloccando un impianto industriale o manomettendo dati critici (i cosiddetti attacchi False Data Injection – FDI).

Il Problema: Perché la Sicurezza Tradizionale Arranca nell’IoT?

Le soluzioni di sicurezza tradizionali, come gli Intrusion Detection Systems (IDS), hanno i loro limiti. Gli IDS basati su firme (SIDS) sono bravi a riconoscere minacce note, ma faticano con gli attacchi “zero-day”, quelli nuovi di zecca. Quelli basati su anomalie (AIDS), invece, cercano comportamenti strani, ma possono generare molti falsi allarmi, richiedendo tempo e risorse per le verifiche. Certo, ci sono anche gli IDS potenziati dall’Intelligenza Artificiale, promettenti ma spesso “pesanti” in termini di risorse computazionali e dipendenti dalla qualità dei dati di addestramento.

E la crittografia? Fondamentale, per carità! Assicura confidenzialità e integrità, e con firme digitali o PUF (Physically Unclonable Functions) possiamo autenticare i dispositivi. Ma la crittografia protegge l’identità, non necessariamente il comportamento di un nodo una volta autenticato. Un nodo “legittimo” potrebbe comunque comportarsi male o essere compromesso.

Nel mondo delle reti di sensori, la fiducia è tutto. I nodi devono collaborare. Ma come fidarsi? Molti approcci si basano sulla valutazione della fiducia (Trust Evaluation), spesso combinando fiducia diretta (la mia esperienza con te) e indiretta (cosa dicono gli altri di te). Il problema è che la fiducia indiretta può essere “inquinata” da nodi già compromessi, diffondendo sfiducia a macchia d’olio. Inoltre, spesso queste soluzioni si concentrano su un solo tipo di attacco. Non basta!

La Nostra Soluzione: Un Motore di Controllo Accessi Basato sul Rischio in Architettura Zero Trust

Ecco dove entriamo in gioco noi. Abbiamo pensato: e se applicassimo la filosofia Zero Trust all’IoT? Il concetto è semplice ma potente: “mai fidarsi, verificare sempre”. Non importa se un nodo è dentro o fuori la rete presunta “sicura”, ogni sua azione, ogni richiesta di accesso deve essere valutata.

Per questo abbiamo sviluppato quello che chiamiamo RBACE (Risk-Based Access Control Engine), un motore di controllo accessi basato sul rischio, integrato in un’architettura Zero Trust pensata apposta per le reti IoT. L’idea è valutare continuamente la “fiducia” che possiamo riporre nei nodi vicini, non una volta per tutte, ma interazione dopo interazione.

Come Funziona? Scomponiamo la Magia

Il nostro sistema non si limita a dire “ok, sei chi dici di essere”. Va molto più a fondo. Valutiamo ogni interazione basandoci su diversi indicatori:

• Capacità (Capabilities): Quali sono le reali possibilità di un nodo? Ad esempio, il suo livello di energia residua (un nodo scarico è meno affidabile), la potenza del segnale ricevuto (RSSI), il numero previsto di trasmissioni per inviare un pacchetto con successo (ETX). Abbiamo creato delle tabelle specifiche per descrivere queste capacità.
• Caratteristiche (Features): Cosa osserviamo concretamente nel comportamento di un nodo? Ad esempio, il rapporto tra pacchetti inviati e risposte ricevute (Packet Sending Ratio), il rapporto di inoltro dei pacchetti (Packet Forwarding Ratio, osservato magari da un “nonno” nella rete), quanti pacchetti di controllo specifici (DIO, DAO, DIS nel protocollo RPL) invia o riceve, come varia il suo “rango” nella rete, la correttezza della versione del protocollo che annuncia. Anche qui, tabelle dedicate ci aiutano a tracciare tutto.
• Attività (Activities): Qual è il comportamento atteso in base al contesto? Ad esempio, se un nodo A deve inoltrare dati provenienti dal nodo B, ci aspettiamo di veder passare quei pacchetti. Usiamo queste aspettative per capire se un nodo sta facendo il suo “dovere” o se, ad esempio, sta scartando pacchetti (come in un attacco Blackhole).
• Contenuto dei Dati (Data Contents): Informazioni specifiche del sistema, come l’intervallo minimo di invio dei pacchetti DIO o l’intervallo atteso per gli aggiornamenti di versione, ci aiutano a definire soglie di normalità.

Il cuore del sistema è il calcolo del valore di fiducia. Questo valore non è statico, ma dinamico. Considera sia le capacità (quanto è utile quel nodo?) sia il rischio (quanto è probabile che quel nodo causi danni?). Il rischio viene valutato proprio analizzando le Features, le Activities e i Data contents.

Ma c’è di più! Non guardiamo solo all’istante presente. Il valore di fiducia finale è una media pesata tra la valutazione attuale e lo storico del nodo. Se un nodo si è comportato male in passato, ci mettiamo più tempo a ridargli piena fiducia. Al contrario, se un nodo inizia a comportarsi male ora, il peso della valutazione corrente aumenta drasticamente per reagire subito. Usiamo soglie e pesi dinamici per rendere il sistema reattivo ma anche giusto, cercando di minimizzare i giudizi errati.

Una volta calcolato il valore di fiducia, il sistema prende decisioni: con chi interagire? Quale nodo scegliere come “genitore” per inoltrare i dati? Se la fiducia scende sotto una certa soglia, il nodo viene considerato malevolo e messo in “blacklist” temporaneamente. La durata del “ban” dipende da quanto è basso il valore di fiducia e da quante volte è stato segnalato: più grave e recidivo è il comportamento, più lungo sarà l’isolamento.

Mettere alla Prova il Sistema: Affrontare gli Attacchi più Comuni

Abbiamo testato il nostro RBACE in simulazioni ricreando alcuni degli attacchi più insidiosi per le reti IoT che usano il protocollo RPL (Routing Protocol for Low-Power and Lossy Network), molto comune in questo ambito:

• Attacco Blackhole: Il nodo malevolo si propone come ottimo “genitore” per l’inoltro dei dati, ma poi silenziosamente scarta tutti i pacchetti che riceve dai suoi “figli”. Il nostro sistema lo rileva confrontando il tasso di inoltro osservato (Feature F2, calcolato grazie alle Activities A1, A2, A3) con quello atteso in base alle capacità dichiarate (Capability C3).
• Attacchi Denial of Service (DoS): Questi mirano a rendere la rete inutilizzabile inondandola di pacchetti di controllo. Abbiamo considerato tre varianti:
  • DIO Flooding: Invio eccessivo di pacchetti DIO (DODAG Information Object). Rilevato monitorando il numero di DIO ricevuti (Feature F4) e il rapporto di risposte DAO-ACK (Feature F3), confrontandoli con soglie derivate dalle capacità (C3) e dai dati di sistema (D1).
  • DAO Flooding: Invio eccessivo di pacchetti DAO (Destination Advertisement Object). Rilevato monitorando i DAO ricevuti (Feature F5) rispetto a quanti DIO sono stati inviati dal nodo (Feature F7) e alle capacità (C3).
  • DIS Flooding: Invio eccessivo di pacchetti DIS (DODAG Information Solicitation), che scatenano risposte a catena (DIO, poi DAO). Rilevato monitorando i DIS ricevuti (Feature F6) rispetto ai DIO inviati (F7) e alle capacità (C3).
• Attacco di Rango (Rank Attack): L’attaccante mente sul suo “rango” (la sua distanza dalla radice della rete) per dirottare il traffico (Rank Decrease) o creare loop (Rank Increase). Lo individuiamo osservando la coerenza del rango annunciato (Feature F8) rispetto ai nodi vicini e la sua stabilità nel tempo (Feature F9).
• Attacco di Versione (Version Attack): L’attaccante annuncia un cambio di versione del protocollo fittizio, costringendo l’intera rete a una costosa “riparazione globale”. Lo contrastiamo verificando la correttezza della nuova versione (Feature F10) e ignorando aggiornamenti troppo frequenti (Feature F11 confrontato con Data D2).

I Risultati? Promettenti!

Le simulazioni, condotte con circa il 30% di nodi malevoli, hanno mostrato che il nostro approccio funziona!
Negli attacchi Blackhole, il Packet Delivery Ratio (PDR), cioè la percentuale di pacchetti che arrivano a destinazione, è passato da un misero 58.6% (senza difesa) a valori molto più alti, vicini a quelli di una rete senza attacchi, grazie alla capacità di identificare correttamente i nodi malevoli (sia genitori che figli).
Contro gli attacchi DoS, abbiamo visto una drastica riduzione dell’overhead dei pacchetti di controllo, segno che il sistema blocca efficacemente il “rumore” generato dagli attaccanti, preservando l’energia dei nodi.
Anche contro gli attacchi di Rango e di Versione, il PDR è migliorato significativamente (ad esempio, dal 76% all’89% per il Rank Attack e dal 30% all’82% per il Version Attack a fine simulazione), dimostrando che il sistema riesce a mantenere la topologia di rete più stabile e funzionale nonostante le azioni malevole.

In conclusione, combinare valutazione della fiducia, analisi delle capacità reali, osservazione dei comportamenti (Features) e confronto con le aspettative (Activities) in un’architettura Zero Trust ci permette di creare uno scudo molto più efficace per le nostre reti IoT. Non ci limitiamo a verificare l’identità, ma valutiamo continuamente l’affidabilità e la sicurezza di ogni nodo, rendendo le comunicazioni più efficienti, affidabili e, soprattutto, sicure. È un passo importante, secondo me, per costruire un futuro connesso di cui possiamo davvero fidarci.

Fonte: Springer