Passa al contenuto
Inovasense
IoT SecurityCybersecurityEmbedded SecurityIIoTCyber Resilience ActOWASP IoT

15 tipi di attacchi IoT: esempi e difese

Team di ingegneria Inovasense
Aggiornato: 3 min di lettura
15 tipi di attacchi IoT: esempi e difese

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.

Fonti e approfondimenti