Esiste un certificato per indicare il livello di sicurezza dei dispositivi IoT?


11

Esiste un certificato affidabile per i dispositivi IoT, che può essere utilizzato per confrontare la sicurezza fornita di questi dispositivi? 1

Attualmente, il panorama IoT è completamente sparso con protocolli, standard e soluzioni proprietarie differenti. D'altra parte i dispositivi IoT cadono su botnet come mosche . Esiste uno standard là fuori in cui i clienti possono fidarsi che il dispositivo rispetti un determinato livello di sicurezza? Forse anche un certificato che garantisce la sicurezza fornita?

Se non esiste uno standard attuale, ci sono iniziative promettenti per creare tale standard?


1: Dichiarazione di non responsabilità: si basa su questa domanda dell'Area 51 di un utente che apparentemente non si è impegnato nel sito in fase di impegno. Voglio pubblicarlo per aiutare a definire l'ambito del sito.

Risposte:


10

UL (ex Underwriters Laboratories) fornisce il programma di sicurezza informatica per certificare che un dispositivo Internet of Things è, a loro avviso, sicuro dalla maggior parte delle minacce principali.

UL sembra essere molto rispettato nei suoi processi di certificazione, secondo Ars Technica :

UL, l'organizzazione di standard di sicurezza di 122 anni i cui vari marchi (UL, ENEC, ecc.) Certificano standard minimi di sicurezza in campi diversi come il cablaggio elettrico, i prodotti per la pulizia e persino gli integratori alimentari, sta ora affrontando la sicurezza informatica di Internet di Dispositivi Things (IoT) con la sua nuova certificazione UL 2900.

UL descrive la propria certificazione come coinvolgente:

  • Test Fuzz di prodotti per identificare le vulnerabilità zero day su tutte le interfacce
  • Valutazione delle vulnerabilità note su prodotti che non sono stati sottoposti a patch utilizzando lo schema CVE (Common Vulnerability Enumerations)
  • Identificazione di malware noto sui prodotti
  • Analisi del codice sorgente statico per le debolezze del software identificate da Common Weakness Enumerations (CWE)
  • Analisi binaria statica per debolezze software identificate da Common Weakness Enumerations (CWE), software open source e librerie di terze parti
  • Controlli di sicurezza specifici identificati per l'uso in prodotti che riducono il rischio per la sicurezza [...]
  • Test di penetrazione strutturata di prodotti basati su difetti identificati in altri test
  • Valutazione del rischio di mitigazione della sicurezza dei prodotti progettata nei prodotti.

Tuttavia, il processo esatto in cui i dispositivi di controllo UL sono poco chiari (a meno che non si paghi per acquistare l'intero set di specifiche), come nota Ars Technica (e criticare):

Quando Ars ha richiesto una copia dei documenti UL 2900 per dare un'occhiata più da vicino allo standard, UL (precedentemente noto come Underwriters Laboratories) ha rifiutato, indicando che se volessimo acquistare una copia - prezzo al dettaglio, circa £ 600 / $ 800 per l'intero set - siamo stati invitati a farlo. Anche ricercatori della sicurezza indipendenti sono, dobbiamo supporre, benvenuti a diventare clienti al dettaglio UL.

Sebbene UL sia rispettato, non possiamo supporre che la sua certificazione sia particolarmente solida in termini di sicurezza senza ulteriore controllo, sebbene soddisfi la domanda originale.

Sfortunatamente, non sono riuscito a trovare standard / certificazioni aperte per la sicurezza, sebbene ciò sia probabilmente dovuto al fatto che le risorse richieste sarebbero troppo grandi per un'associazione senza scopo di lucro.


3

Voglio aggiungere alla risposta di Aurora0001 che possiamo proteggere solo dalle minacce conosciute.

Di recente, abbiamo visto gli attacchi Spectre e Meltdown contro l' hardware . Sebbene le CPU Intel non vengano comunemente utilizzate nei dispositivi IoT, probabilmente troveremo problemi di sicurezza con l'hardware IoT in futuro. In precedenza abbiamo visto Rowhammer e Heartbleed , come bug di classe generale del sistema, che influivano su un numero enorme di sistemi. Man mano che l'IoT cresce, credo che sarà più comune vedere tali vulnerabilità.

Quindi mi concentrerei meno sulle certificazioni di sicurezza e di più su:

  • Apertura, in modo che terze parti possano valutare il software.
  • Durata dell'assistenza dichiarata, in cui il produttore garantisce aggiornamenti di sicurezza
  • Aggiornabilità, compresi gli aggiornamenti automatici come impostazione predefinita.

Se si dichiara che un dispositivo è supportato da molto tempo e, per impostazione predefinita, l'aggiornamento automatico del software avviene quando si verificano nuove versioni, l' impatto dei problemi di sicurezza verrà ridotto. La certificazione ti dirà che non c'erano bug di sicurezza noti quando il prodotto è stato spedito.


Heartbleed può essere un bug di classe di sistema dal punto di vista della distribuzione del sistema, ma è ancora un bug in un determinato software che deve solo essere aggiornato. Esempi migliori sarebbero l'attacco al protocollo stesso, come BEAST e CRIME.
Gilles 'SO- smetti di essere malvagio' il

Il punto è che i bug possono essere trovati in luoghi improbabili (CPU) e in software ben noti (Heartbleed), quindi abbiamo bisogno di patch e aggiornamento del software. Ma sì, c'è una miriade di bug tra cui scegliere.
vidarlo,

Le certificazioni potrebbero benissimo includere la durata del supporto o la possibilità di aggiornamenti del firmware, anche l'apertura. Quindi, anche se hai ragione sul fatto che questi sono punti molto importanti, non capisco perché siano incompatibili con le certificazioni in generale.
Helmar

2
@Helmar Sfortunatamente, le certificazioni serie sono praticamente intrinsecamente un processo pesante. Certificare la versione iniziale e il processo di aggiornamento è una cosa, ma certificare ogni aggiornamento prima che venga distribuito aggiunge un notevole sovraccarico, il che rende difficile stabilire un buon processo di certificazione (in cui gli aggiornamenti di sicurezza dovrebbero essere certificati dopo il fatto - il che va contro il grano della certificazione, poiché significa che il dispositivo eseguirà versioni non certificate).
Gilles 'SO- smetti di essere malvagio' il

@Gilles Sono d'accordo che si potrebbe solo certificare i processi di qualità dello sviluppo del software o qualcosa del genere. Certificare ogni versione del software non è un'opzione.
Helmar
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.