Sicurezza a lungo termine dei dispositivi IoT

Molto spesso i dispositivi IoT utilizzati per applicazioni potenzialmente critiche, non sono dotati delle funzionalità e standard di sicurezza o protezione. Come predisporre in anticipo i dispositivi IoT per far fronte alle minacce future?

Le applicazioni IoT si stanno facendo sempre più strada nelle nostre vite quotidiane – dai robot industriali agli strumenti di precisione, alle auto a guida autonoma e ai droni che si pilotano autonomamente. Molte di queste applicazioni possono già avere un impatto sulla nostra privacy e sulla protezione e sicurezza dei loro utenti. Poiché in alcuni casi, i costi sostenuti in caso di guasto sarebbero elevati, è essenziale costruire i dispositivi conformi alle norme pertinenti. Nel mondo dello sviluppo dell’IoT, caratterizzato da agilità, i requisiti di conformità possono sorgere solo in un momento successivo, quando il codice è già stato scritto e verificato.

Senza dubbio, è meglio includere tutte le attività di conformità nella progettazione del software fin dall’inizio, ma come è noto, i rigorosi processi di sviluppo possono influire sul time to market, soprattutto se non si è in possesso di automatismi e strumenti avanzati. Non molti sviluppatori creano test esaustivi simulando e documentando ogni possibile situazione. Team di sviluppo agili e veloci spesso non possono permettersi di perdere lo slancio per integrare le funzioni di conformità che potrebbero essere necessarie in futuro. Il più delle volte si preferisce il motto: “rilascio versione preliminare ora e poi ampliamo “.
In questo modo si scoprirà nel modo più duro che i costi totali per sviluppare il prodotto a norma sono ordini di entità superiori rispetto all’esborso finanziario che si presenta se si sviluppa un prodotto conforme fin dall’inizio.

Quindi quali misure si possono adottare oggi con un piccolo sforzo aggiuntivo per prepararsi a soddisfare i severi requisiti di conformità di domani?

È importante capire dove si trova il progetto al momento. Il gap tecnico è il costo di potenziali rilavorazioni a causa della complessità del codice, combinato con eventuali violazioni degli standard di codifica e dei requisiti di sicurezza IoT che sono attualmente ancora nel codice. Questa mancanza deriva dalla successiva necessità di pulire, riparare e testare il codice. Un modo per ottenere informazioni sullo stato corrente di un progetto è l’analisi automatica del codice statico. Fornisce approfondimenti sulla qualità e la sicurezza di una base di codice e mostra eventuali violazioni degli standard di codifica.

Abbiamo scoperto che i team che seguivano solo una piccola serie di regole critiche e obbligatorie dovevano impiegare molto meno tempo a rielaborare il codice se si trovavano di fronte a audit di sicurezza IoT funzionale in una fase successiva del progetto. I sistemi sicuri e protetti possono essere creati da zero più facilmente se si considera fin dall’inizio l’aspetto della sicurezza (ad esempio osservando le Linee guida per la codifica sicura CERT C). Si inizia dal basso, grazie al un sofisticato sistema di definizione delle priorità di CERT. La severità, la probabilità e i costi di riparazione sono valutati in tre fasi, per un totale di 27 livelli. Quando si utilizzano strumenti moderni di provider esperti, è possibile leggere facilmente lo stato di conformità su una dashboard preconfigurata.

L’analisi statica aiuta anche le aziende a comprendere la propria “mancanza” tecnica. A tal fine, vengono raccolti punti dati che aiutano la gestione in termini di sicurezza e conformità alla sicurezza IoT. I manager possono facilmente ottenere risposte a domande importanti come queste:

Qual è lo stato attuale? Quante violazioni a standard di codifica non critica sono attualmente presenti nella mia base di codice?

Dati di tendenza: le violazioni nuove e risolte vengono segnalate in ogni build? Stiamo migliorando o peggiorando?

Quanto è complesso il mio codice attualmente? La complessità sta aumentando?

Alcuni standard misurano la complessità ciclomatica per mantenerlo al di sotto di una determinata soglia. Le metriche di complessità possono anche essere utilizzate per stimare una misura di prova. Ad esempio, il numero di casi di test richiesti per dimostrare una copertura a livello di ramo del 10 0% per la conformità con IEC 61508 SIL 2 può essere proporzionale alla complessità ciclomatica (McCabe) di una funzione.

Quindi si iniziare con cose molto semplici. Una volta che il team ha acquisito familiarità con gli errori più critici, è possibile ampliare la gamma di violazioni standard registrate. In nessun caso tutte le regole sono stabilite nella pietra, ma è importante decidere quali regole rientrano nello standard di codifica del progetto e quali no. Come soluzione minima, un insieme di regole obbligatorie da vari importanti standard di codifica (ad es. Norme MISRA Obbligatorie o CERT C) può garantire che i futuri argomenti di sicurezza e protezione per un dispositivo in rete siano semplificati.

La maggior parte degli sviluppatori pragmatici dovrebbe concordare con l’affermazione secondo cui è poco utile impostare ciecamente i test dei moduli per tutte le funzioni. Tuttavia, è un investimento ragionevole dare al team l’accesso a un framework di test dei moduli come parte della toolbox del progetto. I test dei moduli sono sempre utili se gli sviluppatori lo considerano utile per testare determinati algoritmi complessi o manipolazioni di dati in modo isolato. Inoltre, vi è un vantaggio decisivo nello sviluppo di test dei moduli. Come abbiamo sentito dalle aziende, scrivere ed eseguire test unitari da soli aiuta a rendere il codice più solido e migliore.

Se vi sono richieste di sicurezza o conformità, un’azienda può intensificare rapidamente le sue misure di test del modulo assumendo temporaneamente personale aggiuntivo per questo compito. Affinché questo lavoro possa essere ridimensionato rapidamente, il framework di test del modulo e il processo associato devono essere già compresi e documentati nel corso del progetto.
Un elenco di funzionalità comuni di un framework di test di moduli scalabili orientato alla conformità futura:

• Qualificazione per l’uso previsto per un determinato standard di sicurezza (ad es. Attraverso un certificato TÜV / Accredia)
• Integrazione in un sistema di compilazione automatizzato
• Documentazione della metrica di copertura del codice richiesta
• Registrazione dei risultati e copertura dei test eseguiti per ogni build nel tempo
• Idoneità per più progetti e team

Ci sono molti fattori da considerare quando si progettano sistemi embedded, come semplicità, portabilità, manutenibilità, scalabilità e affidabilità. Allo stesso tempo, è necessario trovare un equilibrio adeguato tra i requisiti di latenza, produttività, consumo energetico e spazio. Quando si tratta di progettare un sistema che può essere potenzialmente collegato in rete con un ampio ecosistema IoT, molti team non danno la priorità ai criteri di sicurezza rispetto a questi altri fattori di qualità.

Per semplificare la futura conformità alla sicurezza (e aderire alle buone pratiche di architettura), i singoli componenti possono essere separati nello spazio e nel tempo. Ad esempio, è possibile progettare un sistema in cui tutte le operazioni critiche vengono eseguite da una CPU speciale separata, mentre tutte le operazioni non critiche vengono eseguite su un’altra, in modo che vi sia una separazione spaziale. Un’altra opzione è l’uso di un hypervisor del kernel di separazione e l’uso di concetti di microkernel. Oltre a questi, ci sono altre opzioni, ma è fondamentale applicare la separazione, le preoccupazioni, la difesa in profondità e la separazione per principi di architettura a criticità mista il prima possibile.
Questi concetti non solo riducono la quantità di rilavorazione richiesta per conformarsi agli standard di sicurezza e protezione, ma aumentano anche la qualità e la resilienza dell’applicazione. Ecco alcuni modi per isolare il codice critico.

• file
• moduli
• directory (cartelle)
• librerie

A livello di esecuzione:

• Discussioni, attività RTOS, hypervisor
• Core CPU, CPU separate

La delimitazione delle funzioni critiche da funzioni non critiche riduce la portata delle future misure di verifica che saranno necessarie per dimostrare la conformità.