IoT security: come proteggere dispositivi connessi, reti e dati aziendali
In un magazzino la rete è piatta: il gestionale, le stampanti e la telecamera del corridoio stanno nella stessa VLAN. Quando la telecamera è stata installata, nessuno ha chiesto il firmware, nessuno ha cambiato la password di fabbrica e nessuno le ha detto dove può andare. Sei anni dopo il dispositivo è ancora lì, non riceve aggiornamenti dal 2021, e ha un indirizzo IP che risponde alle scansioni di tutta la rete interna. Chi entra in quel magazzino non ha bisogno di attaccare il gestionale: gli basta trovarsi un dispositivo accanto.
Questa non è una storia di "IoT insicuro". È una storia di delega mancata: quei dispositivi li ha comprati chi gestisce il magazzino, li ha installati chi ha fatto l'impianto elettrico, e non sono mai arrivati a chi gestisce la sicurezza. Il risultato è una classe di asset che nessuno patcha, inventaria o spegne.
Il dispositivo che nessuno ha comprato per l'IT
Un sensore di temperatura, un varco a badge, un misuratore di consumi industriali o un pannello di controllo remoto condividono quattro caratteristiche che rendono inutili le difese pensate per PC e server:
- Non si gestiscono come un endpoint. Nessun EDR, spesso nessuna shell, quasi mai un update automatico.
- Vivono più a lungo di chi li ha comprati. Dieci o quindici anni: tre stagioni di firewall, cinque team diversi, un solo firmware.
- Le credenziali sono condivise o fisse. L'integratore usa la stessa utenza di amministrazione su tutti i suoi clienti.
- Fanno esattamente una cosa. Ed è un vantaggio: se un sensore di temperatura inizia a parlare con un indirizzo in un altro continente, quella è la prova che serve.
L'ultimo punto spiega perché l'IoT si difende bene con la rete e male con l'antivirus: un dispositivo prevedibile ha un traffico prevedibile, e ogni scostamento è un allarme a costo quasi zero.
Quattro assi, un solo inventario
L'ordine conta. Senza inventario non sai cosa segmentare; senza segmentazione non hai dove mettere le regole; senza identità le regole si applicano a un indirizzo IP che cambia al primo rinnovo DHCP. Il ciclo di vita viene dopo perché dipende dai fornitori e raramente puoi risolverlo da solo.
Il NIST ha descritto le capacità attese da un dispositivo IoT consumer nel NIST IR 8425: identificazione degli asset, gestione della configurazione, protezione dei dati, controllo degli accessi alle interfacce, aggiornamento del software, consapevolezza dello stato di sicurezza. È una lista utile anche in azienda, perché dice quali domande fare al fornitore prima di firmare l'ordine, quando hai ancora potere contrattuale.
Inventario: prima di tutto sapere cosa c'è
Un inventario IoT fatto con Excel è vecchio al primo audit. Le fonti che funzionano sono tre, e conviene incrociarle:
- DHCP e ARP danno indirizzi, MAC e hostname annunciati. Il campo
vendordel MAC (il prefisso OUI) distingue già un sensore da un portatile. - Il controllo degli accessi alla rete (802.1X o MAC Authentication Bypass) dice quando e da quale porta un dispositivo si è collegato: è l'unica fonte che resiste a chi cambia indirizzo IP.
- Il traffico, per capire cosa il dispositivo fa davvero: destinazioni, porte, volumi.
Chi ha un firewall che esporta NetFlow ha già i dati: deve solo guardarli con la domanda giusta. Non "che dispositivi ci sono", ma "per ogni classe, quali comunicazioni sono legittime". Una telecamera parla con il suo NVR, un badge con il controller, un misuratore con la piattaforma di telemetria. Il resto è rumore da bloccare.
Da qui l'inventario diventa una tabella a tre colonne — dispositivo, proprietario, traffico ammesso — che è anche la prova che serve in un audit NIS2, dove il problema non è la norma ma la documentazione: ne parlo in NIS2: ruoli, responsabilità e competenze.
Segmentazione: la difesa che funziona anche con firmware vecchi
Se non puoi patchare il dispositivo, puoi decidere con chi parla: è l'unico controllo che non richiede di toccare il firmware, e per questo viene per primo. Servono tre tipi di regola.
Isolamento verso l'ufficio. Nessun dispositivo IoT raggiunge postazioni o server applicativi, salvo la coppia esplicita necessaria (il controller del varco che parla con l'AD).
Egress filtering. Un sensore che non deve uscire su internet non deve poter uscire; se serve un cloud del fornitore, si apre quella destinazione e solo quella.
Microsegmentazione per classe. Telecamere insieme, badge insieme, Building Management insieme: condividono fornitore e vulnerabilità, e un compromesso lì non deve propagarsi.
Il traffico est-ovest è il punto debole di quasi tutte le reti aziendali, e la logica è la stessa descritta in segmentazione di rete: come ridurre il movimento laterale. Per l'IoT c'è un dettaglio in più: la regola non la scrive chi guarda il dispositivo, ma chi guarda il fornitore.
Qui entra un'idea poco usata e molto utile: il RFC 8520 definisce il MUD, Manufacturer Usage Description. Il dispositivo annuncia un URL (via DHCP, certificato o LLDP), la rete scarica dal produttore un file firmato con le comunicazioni previste e ne ricava le ACL. Due dettagli contano: il MUD è negazione di default, con DNS e NTP locali come eccezione; e quelle regole sono suggerimenti, non direttive, perché l'amministratore locale resta responsabile di ciò che applica. Un MUD che chiede mezzo internet per una lampadina va letto, non eseguito.
Identità: chi parla con chi, e con quali credenziali
Su un PC l'identità è risolta: utente, dominio, MFA. Su un sensore no. Le pratiche che reggono:
Cambiare le credenziali prima del go-live. Sembra banale, eppure è la prima voce delle linee guida ENISA sulle baseline security recommendations for IoT e la prima che salta in un incidente reale.
Non condividere un account per tutti i dispositivi. Se il fornitore gestisce cinquanta impianti con la stessa password, un incidente da un altro cliente arriva da voi: chiedete credenziali diverse per installazione.
Autenticare il dispositivo sulla rete, non solo l'utente. 802.1X dove il dispositivo lo supporta, MAB dove non lo supporta, con la porta assegnata alla VLAN giusta in base a chi si presenta. È la differenza tra una rete che si adatta al dispositivo e una rete in cui chiunque si colleghi alla presa ottiene lo stesso accesso.
Mai esporre il dispositivo su internet. Le interfacce web di telecamere, pannelli e centraline sono il bersaglio preferito degli scanner automatici. Se serve accesso remoto, passare da VPN o da un accesso con mediazione, non da un port forwarding.
Ciclo di vita, aggiornamenti e il nuovo quadro europeo
Un dispositivo che non riceve aggiornamenti è un debito che cresce. Due domande da fare al fornitore per iscritto: per quanti anni garantisci aggiornamenti di sicurezza e come ti segnalo una vulnerabilità. Se non ci sono risposte, resta accettare il rischio o cambiare prodotto.
Queste domande stanno diventando meno facoltative. Il Cyber Resilience Act è in vigore dal 10 dicembre 2024 e impone requisiti di cybersicurezza ai prodotti con elementi digitali lungo tutto il ciclo di vita, gestione delle vulnerabilità inclusa. Due date: dall'11 settembre 2026 valgono gli obblighi di segnalazione delle vulnerabilità attivamente sfruttate, dall'11 dicembre 2027 gli obblighi principali.
Per chi compra e usa questi dispositivi, invece di produrli, cambiano due cose. I prodotti immessi sul mercato UE dovranno essere conformi e marcati CE, quindi "è a norma CRA?" diventa una domanda d'acquisto verificabile. E l'obbligo di segnalare le vulnerabilità sfruttate crea il canale che oggi manca, quando il fornitore dice che non c'è nulla da fare.
Nel frattempo la gestione è vostra, con tre regole: registro delle versioni firmware per ogni dispositivo, una finestra periodica per gli aggiornamenti (anche manuali) e un piano di dismissione per ciò che non è più supportato. L'end-of-life non è un evento: è una data che si conosce in anticipo.
I dati che escono
Un dispositivo IoT è quasi sempre un sensore che produce dati su persone: presenze, orari, immagini, consumi, badge. Sono dati personali nella maggior parte dei casi, e la domanda non è solo dove finiscono ma chi li vede.
Tre controlli che cambiano il rischio:
- Cifratura del trasporto verso la piattaforma di raccolta, con certificati verificati: un MQTT in chiaro è comodo e inservibile in un audit.
- Minimizzazione: la telecamera del corridoio trasmette i flussi necessari, con la retention che serve, non "tutto a tutti".
- Sapere dove finiscono i dati, incluse le telemetrie diagnostiche che molti dispositivi mandano al cloud del produttore. Se il contratto non lo dice, va chiesto.
Ammettere o no un dispositivo: il flowchart
Prima di collegare un nuovo dispositivo, cinque domande evitano quasi tutte le sorprese.
Il passaggio che salta più spesso è il secondo: il profilo di traffico. Chiedere al fornitore quali indirizzi e porte usa il dispositivo produce a volte risposte imbarazzanti ("tutte, verso tutto, perché non lo sappiamo"), ed è l'informazione che serve prima di collegarlo, non dopo.
Checklist per un impianto esistente
- Elencare i dispositivi per classe, con proprietario aziendale e data di fine supporto.
- Verificare le credenziali di fabbrica su tutti quelli già installati — oggi, non nel prossimo ciclo.
- Mettere ogni classe in una VLAN dedicata, con regole esplicite verso l'ufficio e verso internet.
- Registrare il profilo di traffico ammesso accanto al dispositivo nell'inventario.
- Verificare che nessuna interfaccia di amministrazione sia raggiungibile da internet.
- Definire la finestra di aggiornamento e chi la esegue.
- Attivare avvisi sui comportamenti anomali: nuovi domini, scansioni interne, volumi fuori scala.
- Scrivere il piano di dismissione per i dispositivi non più supportati.
Chi lavora in ambiente OT aggiunge un vincolo: lì una scansione di rete può fermare una linea, e la continuità produttiva viene prima. È lo stesso tema della crisi OT nella catena del freddo: quando i dispositivi non si possono toccare, la difesa si sposta su rete e monitoraggio.
Da dove cominciare
Se dovessi scegliere un solo intervento, sceglierei inventario più segmentazione: costa poche regole, non richiede di aggiornare un firmware che non si aggiorna e rende visibile ciò che oggi è invisibile. Identità, ciclo di vita e dati si appoggiano su quella base.
Su questi temi la differenza la fa chi sa leggere il traffico e configurare la rete, non chi compila una checklist. I percorsi Cybersecurity e network security di Digital Lab srl partono da segmentazione e controllo degli accessi e arrivano al ciclo di vita dei dispositivi, con laboratori su apparati reali.