Quali sono i principali tipi di attacco ai dispositivi IoT?
La guida tratta quindici categorie: Malware, Ransomware, Man-in-the-middle, DDoS, Manomissione fisica, Canali laterali, Spoofing del dispositivo, Injection, Replay, Sostituzione firmware, Intercettazione, Divulgazione di informazioni, Errore di autorizzazione API, Attacchi alle credenziali, Cryptojacking. Queste quindici categorie si sovrappongono. Gli scenari seguenti sono esempi tecnici illustrativi, non affermazioni su incidenti nominati. I controlli riducono rischi specifici; nessun chip o meccanismo di avvio impedisce ogni attacco. Un incidente documentato è indicato separatamente con la fonte.
1. Malware
Un servizio compromesso esegue codice indesiderato su un gateway.
Correggere software, limitare privilegi e monitorare l’esecuzione.
2. Ransomware
Un attaccante cifra la memoria o disabilita un servizio.
Limitare accessi, preparare backup offline e provare il recupero.
3. Man-in-the-middle
Un falso endpoint modifica comandi o aggiornamenti.
Verificare controparti e autenticare comandi e aggiornamenti.
4. DDoS
Un dispositivo compromesso esaurisce risorse con traffico.
Limitare servizi, segmentare reti e monitorare traffico.
5. Manomissione fisica
Qualcuno accede a debug o memoria esterna.
Controllare debug e valutare protezioni fisiche.
6. Canali laterali
Tempi o consumi rivelano informazioni su un segreto.
Usare crittografia adeguata e valutare perdite dell’implementazione.
7. Spoofing del dispositivo
Un endpoint falso presenta l’identità di un altro.
Usare credenziali univoche, provisioning e revoca sicuri.
8. Injection
Input non fidato diventa comando o operazione pericolosa.
Validare input, evitare interpreti insicuri e provare parser.
9. Replay
Un attaccante reinvia un comando precedentemente valido.
Verificare freschezza e rifiutare transazioni duplicate.
10. Sostituzione firmware
Un’immagine non autorizzata sostituisce quella approvata.
Autenticare immagini e proteggere avvio e recupero.
11. Intercettazione
Una parte non autorizzata riceve dati privati dei sensori.
Proteggere accessi, minimizzare raccolta e comunicare in sicurezza.
12. Divulgazione di informazioni
Log o API diagnostiche espongono credenziali o dati sensibili.
Limitare diagnostica, rimuovere segreti e proteggere memoria.
13. Errore di autorizzazione API
Un utente valido controlla il dispositivo di un altro cliente.
Verificare autorizzazioni sull’oggetto a ogni richiesta.
14. Attacchi alle credenziali
Password predefinite o riutilizzate consentono accessi.
Eliminare default condivisi, limitare tentativi e proteggere accesso remoto.
15. Cryptojacking
Mining indesiderato consuma risorse del computer edge.
Correggere servizi, limitare carichi eseguibili e monitorare utilizzo.
Esempio documentato: Mirai
L’FBI descrive Mirai che nel 2016 infettava dispositivi IoT esposti a internet con credenziali predefinite comuni, usandoli per DDoS. Resoconto FBI. Illustra rischi di credenziali ed esposizione; non dimostra che una radice hardware avrebbe impedito ogni fase.
Date e ambito CRA
Il CRA è entrato in vigore il 10 dicembre 2024. Le segnalazioni dell’articolo 14 si applicano dall’11 settembre 2026; i requisiti principali dall’11 dicembre 2027. L’articolo 69 contiene regole transitorie per prodotti già immessi sul mercato. I prodotti soggetti a MDR o IVDR sono esclusi dall’articolo 2(2); verificare anche altre esclusioni e il software libero/open-source non commerciale.
CRA e scelte tecnologiche
I requisiti CRA sono orientati ai risultati e tecnologicamente neutrali, in base alla valutazione dei rischi e all’applicabilità. Secure boot, radice hardware di fiducia, TPM, TrustZone e OTA wireless possono essere misure opportune; non sono obblighi universali per ogni prodotto. Documentare perché i controlli scelti soddisfano i requisiti, senza equiparare una singola architettura alla conformità.
Domande frequenti
Il CRA richiede sempre secure boot?
I requisiti CRA sono orientati ai risultati e tecnologicamente neutrali, in base alla valutazione dei rischi e all’applicabilità. Secure boot, radice hardware di fiducia, TPM, TrustZone e OTA wireless possono essere misure opportune; non sono obblighi universali per ogni prodotto. Documentare perché i controlli scelti soddisfano i requisiti, senza equiparare una singola architettura alla conformità.
Un secure element garantisce conformità?
No. Può proteggere chiavi e operazioni specifiche; la conformità riguarda prodotto completo, requisiti, processi ed evidenze.