Assessment di sicurezza su Ecosistemi IoT

IoT è un neologismo riferito all’estensione di Internet al mondo degli oggetti e dei luoghi concreti introdotto da Kevin Ashton, cofondatore e direttore esecutivo di Auto-ID Center (consorzio di ricerca con sede al MIT) durante una presentazione presso Procter & Gamble nel 1999.

Già… dal 1999 sembra passata un’era geologica e stiamo assistendo nell’ultimo periodo (ma già annunciato da tempo) ad un aumento dei servizi basati su IoT andando verso una logica di Smart City dove un ecosistema di sensori registra, processa e immagazzina dati localmente e interagisce in modo autonomo tramite internet e protocolli in radio frequenza.

L‘internet delle cose è in forte espansione (ad esempio oggi non esiste un comune che non abbia almeno un progetto IoT avviato) e a livello di verifiche di sicurezza siamo molto indietro. Occorre quindi un approccio metodologico di ICT Risk management completamente differente rispetto alle classiche infrastrutture ICT e definire nuovi modelli di Assessment con un approccio a servizio e non più su applicazioni monolitiche come fatto in passato.

Evoluzione tecnologica

I sistemi nel tempo si sono evoluti passando da tecnologie Mainframe a Client-server per abbracciare infrastrutture / ecosistemi distribuiti sempre più complessi. La Terza Piattaforma è un nuovo paradigma tecnologico costituito da ecosistemi di risorse e applicazioni che includono servizi cloud, infrastrutture mobili, Big Data, IoT, social media e altro ancora con un aumento vertiginoso degli utenti e dei dati e (di nostro particolare interesse) della superfici di rischio.

Senza entrare nel teorico (ma fatemelo fare), ogni azienda deve applicare rigidamente il primo requisito del NIST e del framework nazionale di sicurezza che stabilisce l’esigenza di inventory e catalogazione delle componenti ICT, che occorre un’impalcatura di norme a supporto della sicurezza, che occorrono campagne di awareness periodiche e mirate, che occorre limitare il numero di sistemi, ecc & ecc… in piena trasformazione, stiamo assistendo ad un forte cambiamento nello stile di vita quotidiano.

Viviamo una digital-experience sempre più connessa alla rete; basta pensare quanto tempo un italiano medio passa guardando il proprio telefono o i social network / chat sul proprio smartphone. Uno studio parla di 4,5 ore online delle quali 2,5 sui social. Una percentuale significativa del nostro tempo che ci porta a lasciare tracce “consistenti” sui nostri comportamenti, sulle nostre abitudini, sulle nostre preferenze e molto altro ancora.

Questi dati oggi sono di interesse strategico per molte forme di business (un esempio il caso Cambridge Analytica) e stiamo assistendo ad un inversione del paradigma sull’appetibilità dei dati passando da un paradigma “Business & Data Centric” in 1st & 2nd platform a “User Centric” in 3rd platform (come vediamo nella figura in calce) con nuovi tipi di sistemi e servizi.

Rischio e Minacce

Mentre stiamo progettando i nostri sistemi in 3rd Platform, cominciamo a diffondersi dai giornali le prime notizie sui sistemi violati e non sono per nulla rassicuranti:

• Akamai Finds Longtime Security Flaw in 2 Million Devices
• Hackers Remotely Kill a Jeep on the Highway
• TalkTalk Hack Data Was Unencrypted.
• Hacker Can Send Fatal Dose to Hospital Drug Pumps
• DDOS Botnet Mirai

Nuove forme di impatti si cominciano ad intravedere che vedono sempre più l’utente al centro contornato da una moltitudine di ecosistemi complessi; queste minacce introduco rischi fino ad oggi mai valutati.

Sappiamo inoltre che la sicurezza è una grandezza «inversamente proporzionale» alla complessità applicativa e mentre i sistemi cominciano ad essere sempre più complessi il Livello Massimo di confidenza (LMC) nelle attività di Assessment risulta in costante diminuzione oltre ad un aumento della richiesta di controllo e tempistiche sempre più stringenti anche in virtù delle nuove normative entrate in vigore come ad esempio il GDPR.

Possiamo quindi asserire che il rischio cambia forma e aspetto.

L’internet mobile oramai è storia passata (il nostro smartphone è diventato una protesi strutturale della nostra persona e ne siamo tutti consapevoli) ma altre nuove “utility” cominciano ad affacciarsi nel nostro mondo, ma tutto questo ottimismo, questa “esaltazione” rende le nostre vite più al sicuro? Una SmartCar a guida autonoma, quanto ci fa paura?

Occorre quindi coniugare nuove grandezze fino ad oggi mai pensate perché oltre al rischio privacy (sulla quale abbiamo costruito la Riservatezza, Integrità e Disponibilità del dato e misurato il rischio da diversi anni a questa parte) non basta più… Se viene violato un sistema biomedico che controlla da remoto la quantità di insulina da iniettare nel sangue di un paziente diabetico, questo rischio come si chiama?

Ecosystem Security Assessment

L’approccio nelle attività di controllo dovrà essere totalmente rivisto per misurare il rischio sull’ecosistema (il servizio) e non effettuare più controlli monolitici su una singola Applicazione (ad es. solo sull’APP Mobile).

Ecco l’avvento degli Ecosystem Security Assessment (ESA) che consentono di misurare il livello di rischio su un ecosistema complesso composto da una eterogeneità di apparati come ad es. Classic-ICT, Reti Zegbee, WiFi Network, App Mobile, web application e backand misti on-premise/Cloud perché questi sono i sistemi di oggi e nella loro interezza devono essere valutati.

Modello di Verifica

In logica ESA 3rd platform, l’approccio all’attività di controllo dovrà cambiare. Introdurremo 4 direttrici di verifica che consentiranno di analizzare, in modo parametrico, tutte le infrastrutture del sistema e quindi Software, Hardware (physical) e Network Assessment.
Viste le tempistiche limitate di controllo, l’information gathering consentirà di individuare con buoni margini di confidenza le corrette percentuali di verifica da dedicare ad ogni direttrice. Non esiste quindi una metodologia standard, ma uno modello di verifica modulare che cambierà di volta in volta in relazione alla tipologia di sistema che andremo ad analizzare.

Si evolvono di conseguenza le tecniche aumentando la loro pervasività, evolverà il classico penetration test e si introdurranno verifiche documentali sugli standard e certificazioni Cloud (dove non è possibile praticare verifica in campo) e soprattutto vede la luce una nuova forma di controllo quale l’Hardware Security (in letteratura Physical Security) e gli assessment di Orchestration Application Management per analizzare la gestione dei device qualora presenti.

Tenete in considerazione che una web-application fino a ieri aveva il server nei nostri datacenter ma oggi un device IoT è a casa degli utenti. Occorre prestare massima attenzione a questo concetto in quanto (faccio un esempio pratico) un certificato digitale cablata nel firmware di un device che risulta lo stesso attivo su tutti i device a casa degli utenti apre scenari di attacco inimmaginabili verso i nostri clienti.

Dobbiamo quindi valutare firmware, reti wifi (ad es. protocollo Zigbee), Component Analysis ecc… attrverso tecniche fino ad oggi mai utilizzate sui sistemi “Classic ICT” ma che risultano fondamentali per garantire una sicurezza sulle nostre applicazioni. In Hardware Security nasce l’esigenza di disporre di un laboratorio per queste particolari tecniche che non verranno condotte solo con software ma con strumenti mai utilizzati in questo ambito di verifica come ad es. l’oscilloscopio, il tester, le stazioni saldanti, i radio jammer, le connessioni jtag e molto altro ancora…

Da tener in considerazione che in IoT esiste molta meno “consapevolezza” al rischio da parte dei costruttori (soprattutto su soluzioni off the shelf), pertanto non è difficile trovare problematiche di chiavi condivise tra device o password predicibili (principale direttrice di attacco della botnet MIRAI).

Security By Design

Sempre di rilevanza strategica rimane il concetto di «Security By Design» ovvero quella fase nella quale identificare i requisiti di sicurezza da implementare in maniera nativa e quindi scegliere il giusto device prima della messa in catena. Tale verifica consentirà di identificare il device a minor rischio in modo da poter sviluppare su questo il nostro ecosistema evitando di procedere ad effettuare tale verifica in fase di roll-out.

Conclusioni

Per chi si occupa di sistemi occorre una vera riflessione su come la sicurezza in passato veniva implementata (valore accessorio) e quanto la sicurezza diventa oggi un elemento “abilitante” che non può essere più sottovalutato. La sicurezza nasce dalla Progettazione di un sistema e dal suo sviluppo; errori fatti in queste fasi (molto prima dell’avvio in produzione di un servizio) possono compromettere completamente la sicurezza di un ecosistema. Questi aspetti non possono essere più sottovalutati.

Chi produce applicazioni di 3rd platform deve prevedere all’interno dei team esperti di sicurezza che valutino le architetture, seguano il programma e gli sviluppi (sviluppo sicuro del software), forniscano linee guida per il collaudo e l’esercizio del sistema. Tutto questo per applicare la “Security By Design” che non è l’headline di un prodotto di bellezza, ma è la chiave di volta per realizzare sistemi sicuri.

Purtroppo in ambito IoT vale ancor di più il concetto che la sicurezza se non applicata è una tassa non pagata. Dopo cinque anni può andare in prescrizione, ma se contestata occorre pagare more e more rimpiangendo di non averci pensato quando era il momento.

A cura di: Massimiliano Brolli