Internet of Things : l’Internet degli Oggetti

Considerazioni generali e aspetti introduttivi di sicurezza

Il termine Internet of Things o IoT, spesso tradotto erroneamente con Internet delle Cose quando sarebbe più opportuna la traduzione Internet degli Oggetti, e’ ormai entrato a far parte del lessico comune di quanti si occupano di tecnologie ICT.

Nel corso di queste note mi sono riproposto di fare un po’ di chiarezza sulle tecnologie adottate, sui componenti e sulle possibili problematiche di sicurezza delle soluzioni IoT.

Inizio con affermare che le soluzioni IoT hanno delle caratteristiche particolari che le rendono uniche. L’elevato numero di dispositivi, che solitamente fanno parte di una soluzione IoT, impone delle caratteristiche di scalabilità basate non tanto sulle prestazioni quanto sulla necessità di gestire e manutenere un parco installato caratterizzato da una cardinalita’ estremamente rilevante (numeri estremamente elevati). Tutto ciò si riflette nella mole di dati da memorizzare e analizzare.

Il fine ultimo delle soluzioni IoT nei diversi ambiti applicativi e’ sempre quello di fornire degli strumenti che, a fronte di un fenomeno fisico naturale o artificiale, permettano di capire cosa sta succedendo, perché sta succedendo e potenzialmente cosa potrebbe avvenire. Sensori e attuatori sono quindi i mezzi che permettono di interagire con l’ ambiente i con il fenomeno fisico che si vuole controllare. Si tratta dunque di gestire e analizzare un grande numero di dati di natura diversa aggregandoli ed elaborandoli in modo da trarre da esse delle informazioni in base alla quale eseguire specifiche azioni (in inglese Actionable Information).

Proseguo con l’ affermare che nel corso degli ultimi 2 / 3 anni si e’ verificata la disponibilità di un insieme di catalizzatori che hanno favorito lo sviluppo delle tecnologie necessarie alla realizzazione di soluzioni IoT e conseguentemente l’attenzione dell’ industria verso questo tipo di tecnologie e’ cresciuto in proporzione. Ormai parlare di soluzioni IoT rappresenta non tanto una sperimentazione di frontiera, quanto la necessità di confrontarsi con le specifiche problematiche di implementazione.

Tra i catalizzatori che concorrono alla adozione di soluzioni IoT si possono citare :

• La disponibilità di sensori e attuatori di tipologia diversa e variegata

• L’ offerta da parte dei principali vendor di soluzioni Cloud di piattaforme dedicate a questo ambiente e dotate di primitive atte ad indirizzare alcune delle caratteristiche specifiche di questo tipo di applicazioni

• La disponibilità di protocolli di comunicazione specializzati in grado di supportare le peculiarità (cardinalita’, resilienza, affidabilità) necessarie in ambito IoT.

Prima di addentrarci nella analisi di una soluzione IoT e dei relativi componenti tecnologici conviene spendere qualche parola sul concetto di sensori e attuatori che rappresentano gli elementi fondamentali di una tale soluzione .

I sensori.

I sensori sono dei componenti hardware specializzati nella lettura di un parametro fisico (temperatura, pressione, umidità, intensità luminosa,…) e nella trasmissione del dato rilevato in forma digitale o analogica mediante un insieme di regole (protocollo) che permettono al ricevente di interpretarlo correttamente. Un esempio molto semplice puo’ essere un termometro per la temperatura : esso genera un valore espresso in gradi Celsius o Fahrenheit che viene solitamente rilevato mediante la lettura di una apposita scala graduata o di un piccolo display. Qualora il termometro sia dotato di un minimo di logica per la trasmissione di questo valore verso un altro componente, utilizzando un protocollo opportuno, avremo realizzato un sensore di temperatura. Naturalmente i sensori possono essere di tipologia diversa e molto complessi in grado di rilevare più grandezze fisiche contemporaneamente. Esistono oggi sensori in grado di rilevare il transito di una persona attraverso un Gate (cancello logico) e individuarne il senso (ingresso o uscita), sensori in grado di riconoscere codici a barre o impronte digitali, sensori in grado di misurare la distanza relativa tra due oggetti e cosi via. Tutti i dati raccolti dai sensori devono essere codificati opportunamente per l’ elaborazione successiva. Tornando all’ esempio del sensore di temperatura sara’ necessario anche prevedere l’ invio o la segnalazione dell’ unita’ di misura associata : Celsius o Fahrenheit. Il dato generato dal sensore deve quindi essere opportunamente formattato per l’ invio e la successiva elaborazione.

Gli attuatori.

Mentre i sensori si occupano di catturare un dato e inviarlo per l’elaborazione successiva, e’ necessario anche disporre della possibilità di eseguire delle azioni a seguito dell’ elaborazione eseguita a partire dai dati forniti dai sensori o da un sistema di controllo. Questo e’ il compito degli attuatori. Come in precedenza un semplice esempio può essere la chiusura o apertura di un circuito alla ricezione di uno specifico comando (banalissimo esempio : l’apriporta di casa). Analogamente a quanto affermato per i sensori anche gli attuatori possono essere complessi e multifunzione : si pensi, per esempio alla necessita’ di porre in rotazione un motore ad una specifica velocità o al posizionamento di un braccio meccanico per il rilascio di un contenuto (apertura di circuito). Anche in questo caso, gli attuatori devono essere dotati di funzioni primitive di comunicazione che permettono la ricezione di comandi e l’interpretazione del loro significato.

I protocolli di comunicazione

Sensori e attuatori devono quindi, per quanto detto, essere in grado di trasmettere e ricevere delle informazioni verso un sistema di più alto livello per una successiva elaborazione. Si noti che sia per i sensori che per gli attuatori, la comunicazione deve essere in genere bidirezionale e dunque devono essere gestite verso entrambi sia la trasmissione che la ricezione di dati e comandi. Per esempio in un sensore può essere possibile definire una stringa univoca che ne identifica il posizionamento, mentre un attuatore deve essere in grado di fornire un indicazione di errore qualora la funzione richiesta (posizione, velocità, apertura/chiusura di un contatto,…) non sia attuabile.

L’ insieme di regole e di formati con cui sensori e attuatori comunicano con un sistema di elaborazione (PLC, Gateway, Edge Computer,…) costituisce il protocollo di comunicazione utilizzato tra queste entità. Il protocollo di comunicazione deve indirizzare una serie di situazioni per essere efficace e supportare la implementazione della soluzione prevista.

Alcune tra le problematiche che devono essere risolte dal protocollo sono:

• Come indirizzare univocamente lo specifico sensore/attuatore in una installazione

• Come stabilire una priorità di accesso al mezzo trasmissivo (chi parla per primo)

• Cosa fare nel caso il mezzo trasmissivo sia occupato (chi sta parlando)

• Come segnalare eventuali errori

• Come formattare i dati trasmessi o ricevuti (p.es. quanti bit assegnare ad una specifica grandezza)

• Come assicurare che il dato trasmesso non venga corrotto nel corso della trasmissione

• Etc.

I requisiti che tali protocolli devono soddisfare includono sia la semplicità di implementazione vista la limitata capacita’ elaborativa che la necessita’ di ridurre il consumo di eventuali batterie dei sensori e attuatori. I protocolli vengono poi resi disponibili su mezzi trasmissivi diversi : dal classico doppino in rame fino alle connessioni Wireless su bande non soggette a licenza (bande ISM). Una caratteristica comune a questi protocolli e’ la limitata larghezza di banda richiesta per la trasmissione dei dati come conseguenza appunto della semplicità dei dati trasmessi.

In ambito IoT esistono svariati protocolli di comunicazione sia proprietari che standardizzati, tra questi possono essere ricordati IO-Link, ModBus, LoraWAN, En-Ocean, gli ultimi due su mezzo trasmissivo radio.

L’ architettura di una soluzione IoT

Una soluzione IoT non si esaurisce ovviamente con la sola disponibilità di sensori e attuatori ma richiede la presenza e la coordinazione di una serie di componenti che permettano di estrarre dai dati le informazioni decisionali (Actionable Information).

La figura seguente schematizza i vari componenti di una implementazione IoT.

Procedendo da sinistra verso destra si notano i sensori e attuatori responsabili della cattura del dato e della eventuale modifica dell’ ambiente controllato. I protocolli di trasmissione permettono di consolidare questi dati presso dispositivi intelligenti che si differenziano sostanzialmente per la capacita’ elaborativa necessaria in base alle caratteristiche del sistema che si vuole realizzare. Diciamo subito che qualora non sia necessaria una risposta del sistema complessivo in tempi molto ristretti (near real-time) i dati verranno consolidati da un Edge Gateway (¹) di capacita’ più limitate rispetto ad un Edge Computer in grado di fornire sofisticate elaborazioni locali. I dati cosi consolidati, normalizzati e opportunamente formattati vengono poi trasmessi ad un’applicazione Cloud che estrarra’ le informazioni di interesse. Anche in questo ulteriore passaggio trasmissivo risultano fondamentali le caratteristiche del protocollo di comunicazione utilizzato per inoltrare i dati verso l’ ambito applicativo in cloud. Rispetto al caso della trasmissione da sensore/attuatore da/per Edge device, c'è pero’ in questo caso una significativa e importante differenza : tutti i protocolli utilizzati (MQTT, AMPQ, OPC UA,…) si basano su di un unico comune denominatore rappresentato dal protocollo IP sul quale poi si appoggiano, a livello superiore, i protocolli prima identificati. In ambito applicativo, i server o i corrispondenti servizi Cloud forniranno le necessarie funzioni primitive per la memorizzazione, elaborazione e presentazione delle informazioni estratte dai dati catturati. Da considerare poi che i principali fornitori di servizi Cloud propongono oggi delle piattaforme specializzate per l’ambito IoT che offrono una serie di funzionalita’ primitive volte a semplificare il processo di implementazione e che indirizzano le necessità di installazione, configurazione e gestione dei dispositivi Edge sia Gateway che Computer.

Una necessaria precisazione va fatta in merito alle funzionalità di Edge Computing necessarie, come abbiamo affermato, alla realizzazione di implementazioni caratterizzate da requisiti temporali molto stringenti. E’ questo il caso di soluzioni di controllo di sistemi critici per i quali il ritardo (ed eventualmente la non disponibilità delle applicazioni Cloud) non e’ tollerabile ed e’ dunque necessario fornire una risposta (una azione) in tempi molto contenuti. L’elaborazione locale quindi si sostituisce all’elaborazione in cloud della quale e’ in grado di sfruttare algoritmi e dati storici.

Riassumendo dunque la catena tecnologica di una implementazione IoT e’ composta da un numero di componenti sicuramente elevato che possono pero’ essere aggregati in tre principali categorie :

• i sensori/attuatori responsabili dell’interazione con l’ambiente che si vuole realizzare o controllare

• I dispositivi di edge che concentrano, normalizzano e trasmettono i dati verso i sistemi di elaborazione applicativa

• Le applicazioni che estraggono dai dati le informazioni fruibili e le rendono disponibili presentandole opportunamente.

Malgrado la apparente semplicità della soluzioni, gli aspetti critici che devono essere analizzati in dettaglio sono numerosi:, in particolare gli aspetti di sicurezza meritano una attenzione particolare.

La sicurezza nelle realizzazioni IoT

Come qualunque sistema. ICT anche nelle realizzazioni IoT la sicurezza gioca un ruolo fondamentale. Si tratta quindi di individuare le eventuali criticità e i componenti specifici che devono essere considerati nella pianificazione di una strategia di sicurezza in ambito IoT.

Seguendo la catena tecnologica individuata in precedenza si possono ipotizzare alcune considerazioni partendo da sensori e attuatori.

Si tratta solitamente di componenti relativamente semplici caratterizzati da limitate capacità elaborative in modo da ridurre il consumo di eventuali batterie di alimentazione. Le grandezze su cui sensori/attuatori devono intervenire sono rappresentate da un valore numerico (temperatura, pressione, rotazione di un motore passo-passo…) o digitale (on/off, aperto/chiuso, …) che assume un significato specifico nel contesto globale della soluzione considerata. Possiamo affermare che il valore del SINGOLO dato e’ dunque limitato e di poco interesse : la prospettiva e’ completamente diversa quando si tratta dell’ INSIEME dei dati che e’ poi possibile correlare. In ogni caso i sensori/attuatori sono dotati di un firmware relativamente semplice e molto spesso non aggiornabile. Una prima valutazione sulla sicurezza deve quindi essere svolta sul firmware del dispositivo e successivamente sul protocollo di comunicazione che permette l’inoltro dei dati verso il dispositivo edge. Si noti che in questo caso si tratta di protocolli specializzati, per certi versi proprietari, per i quali la disponibilità di tool di compromissione o di intercettazione e’ comunque limitata. Cio’ non toglie che eventuali rischi di compromissione di tali protocolli /mezzi trasmissivi debbano essere valutati.

Diverso è lo scenario relativo ai dispositivi edge : in questo caso le possibili compromissioni di sicurezza possono essere molteplici. Il firmware del dispositivo in questo caso e’ spesso basato o comunque include delle componenti Open Source che possono presentare vulnerabilità : e’ dunque necessario valutare sia l’ aspetto comportamentale del dispositivo, che la possibile presenza di “backdoor” dormienti che potrebbero essere presenti in qualche modulo software. L’ utilizzo di protocolli di comunicazione basati su IP apre poi la possibilità alle vulnerabilità tipiche degli ambienti basati su IP. Fortunatamente queste sono ben comprese e documentate nell’ambito tecnologico ed esistono strumenti sofisticati per minimizzare il rischio di compromissioni a questo livello.

Le principali soluzioni Cloud in abito IoT offrono oggi tutta una serie di strumenti per indirizzare le problematiche di una connessione sicura tra un edge device e la relativa applicazione Cloud : tali strumenti forniscono tra l’ altro la crittografia dei dati trasmessi, la mutua autenticazione tra applicazione e edge device, la verifica dell’ integrità del dato e la non replicabilità dello stesso. A completamento delle possibili vulnerabilità di una soluzione IoT vanno menzionate quelle relative all’ambiente Cloud e alle applicazioni e dati ivi installati, per le quali esistono dettagliate informazioni in letteratura.

Per concludere, le soluzioni IoT a fronte di una semplicità concettuale dovuta alla schematicità dell’ architettura di rete, presentano invece una serie di complessità derivanti dall’elevato numero di dispositivi in gioco, dalla conseguente necessità di disporre di efficaci strumenti di gestione e dalle problematiche di sicurezza che si possono concretizzare, con modalità diverse, in più punti della realizzazione richiedendo l’ applicazione, il coordinamento e la gestione di strumenti di difesa di natura differente. Questo comporta una conoscenza multidisciplinare di tecnologie e prodotti che può essere in parte mutuata da precedenti esperienze in ambito ICT quando associata alla necessaria padronanza dell’ ambiente fisico (degli Oggetti) che si vuole controllare e/o realizzare.

Giorgio Tosi

1 Edge Gateway : con questo termine viene identificato un dispositivo di comunicazione che è in grado di estrarre le informazioni ricevute tramite uno specifico protocollo di comunicazione e formattarle opportunamente per la trasmissione e l’ inoltro tramite un protocollo diverso. Ad esempio un Edge Gateway è in grado di rilevare lo stato di un contatto digitale (ON/OFF) e formattare questa informazione in modo opportuno in modo che possa essere trasmessa ad una applicazione residente su di un server mediante il protocollo TCP/IP.  

E quindi andiamo in cloud, ma con attenzione!

Per citare un famoso detto americano, il cloud è la migliore invenzione dal pane affettato ai giorni nostri!

È una di quelle invenzioni storiche che cambiano abitudini, paradigmi lavorativi, processi di business in modo morbido ma inesorabile, accettata da grandi e piccole realtà, in grado di portare continuità e al tempo stesso profonda innovazione.

Proprio queste ultime caratteristiche lo rendono potente, al punto che da tempo si dibatte sul tema del cloud ibrido – cioè quello che si compone di parti tradizionali e online, esperienze private e che si affidano a provider condivisi, costruite sul miglioramento di processi esistenti da tempo e di cui si conoscono le inefficienze rispetto a innovazioni profonde nei modi di fare business.

Qualora non fosse bastata la spinta – modaiola o meno – della trasformazione digitale, ecco che la recente situazione pandemica ha creato emergenze e modus operandi che hanno ulteriormente esacerbato la necessità di rendere fruibili in modo remoto ed onnipresente processi ed applicazioni ad utenti attivi in ogni momento e connessi da qualunque luogo.

Cosa che ha portato a reazioni spesso frettolose, percepite talvolta come semplificazioni con importante riduzione di costi, definite spesso “lift-and-shift” e caratterizzate dallo spostamento di server dai datacenter tradizionali aziendali in ambienti cloud amazoniani, microsoftesi o googlici.

I progetti con un approccio più strutturato però, hanno ipotizzato una reingegnerizzazione delle piattaforme applicative secondo i principi del Platform-as-a-Service (o PaaS).

Se dal punto di vista IT e sviluppo questo approccio moderno ed efficace ha richiesto una frammentazione del server nei suoi componenti fondamentali – come storage, liste di accesso, networking, database ed altro – in pochi hanno percepito la profonda differenza dal punto di vista della sicurezza, specialmente in relazione alla responsabilità condivisa.

Questo concetto è stato riassunto in modo eccellente da Amazon Web Services o AWS nella frase “questa differenziazione della responsabilità viene comunemente detta sicurezza del cloud rispetto a sicurezza nel cloud” e illustrata altrettanto efficacemente come segue.

Figure 1 - Cloud Responsibility Model (Fonte AWS - aws.amazon.com)

Questo schema, utilizzato molto spesso per educare le aziende ad una evoluzione consapevole dei propri processi e schemi di business per trarre vantaggio da piattaforme cloud, presenta una semplificazione talvolta eccessiva del concetto che cercherò di spiegare con un esempio.

Ipotizziamo che l’azienda fittizia ACME Ricambi Motoveicoli abbia completato la sua prima trasformazione digitale quattro anni fa, implementando un sistema di server esposti su Internet e ubicati nel proprio datacenter per realizzare un sistema mirato alla vendita online dei propri prodotti e servizi.

Nel caso in esame, supponiamo che la soluzione abbia avuto successo ma che si sia rivelata eccessivamente complessa e costosa da manutenere, a causa dell’infrastruttura richiesta.

Così nel 2019 il progetto è evoluto con lo spostamento dei server in cloud, con la speranza di una riduzione dei costi.

Complice la pandemia che ha causato un aumento dell’utenza, la necessità di scalare le risorse ha comportato costi per le repliche dei server superiori all’efficienza operativa, a causa della struttura monolitica dei server (la fretta aveva spinto ad optare per una soluzione veloce...).

A fine 2020 la nostra ACME Ricambi Motoveicoli ha quindi optato per una revisione completa del progetto che frammentasse le singole componenti dei server, istanziandole in modo bilanciato e scalabile in cloud. In sostanza  l'idea è di separare quello che normalmente definisce un server - ad esempio lo storage o spazio su disco, il database su cui vengono memorizzati i dati, le regole d'accesso ai servizi esposti e così via. Ogni frammento viene configurato in cloud singolarmente, con un sistema che ne moltiplica le istanze all'aumentare della domanda. Questo approccio è ideale perché replica solo le componenti del mosaico applicativo che ne hanno bisogno, ottimizzando il rapporto investimento/prestazioni.   

Se da un punto di vista applicativo ed operativo questa è la via corretta, dal punto di vista della sicurezza ciò richiede una profonda modifica delle strategie di protezione – proprio a causa della opacità tipica della responsabilità condivisa.

Per capire a cosa mi riferisco, approfondiamo un pezzo del grafico riportato sopra:

Ad una prima occhiata, volendo istanziare uno storage e un’istanza database, la responsabilità di mettere il tutto in sicurezza sembrerebbe in capo ad Amazon.

E lo è certamente per quanto riguarda la resilienza dello storage e/o dell’istanza database.

Ciò che lo schema semplificato non ci dice è che se guardiamo più da vicino questi due elementi nelle impostazioni di sicurezza, notiamo quanto segue.

La configurazione di un’istanza di storage, ad esempio Amazon S3 Bucket ha come impostazione predefinita in Permissions – Bucket Policy - Principal un valore predefinito pari a *, che permette a chiunque di accedere a uno storage esposto e raggiungibile.

Un’istanza Amazon >RDS – cioè database – presenta una configurazione predefinita il database senza alcuna protezione dalla cancellazione.
Una compromissione dell’ambiente cloud – ad esempio per furto di credenziali – permetterebbe agli attaccanti di cancellare l’istanza del database, magari dopo averne trasferito i dati.

Questi due esempi illustrano come l’intera concezione della sicurezza nel paradigma PaaS richieda conoscenze che normalmente non sono alla portata di tutti; questo significa la necessità di un aggiornamento delle competenze del team di security, elemento spesso non considerato nella pianificazione dei progetti cloud.

Sarebbe anche auspicabile dotarsi di soluzioni specializzate di inventario e analisi dinamica della configurazione, magari in grado di abbracciare più fornitori di servizi cloud. In questo modo  si arriva ad una presentazione unificata e organica della superficie vulnerabile, mappata direttamente sulla visibilità raggiunta dell'ambiente multi-cloud, capacità discusse nel precedente articolo "Dai dati grezzi alle informazioni fruibili: visibilità e osservabilità".

La Cloud Security Alliance, istituzione per la divulgazione culturale della sicurezza in ambienti cloud, ha rilasciato due importanti pubblicazioni in merito di cui consiglio la lettura:

• The Treacherous Twelve (Gli Infidi Dodici), in cui elencava già nel 2016 dodici incidenti in cloud la cui causa era prevalentemente l’inosservanza di best practice nelle configurazioni.

• The Egregious Eleven (Gli Egregi Undici), in cui due anni fa presentava l’analisi di undici incidenti importanti di cui l’origine era ancora spesso la configurazione sbagliata o troppo permissiva delle risorse.

Il Cloud è certamente la via per una maggiore agilità di business e per un’economia di scala nel controllo dei costi IT. L’adozione di questa nuova tecnologia non può però prescindere dall' aggiornamento delle competenze di security e dal potenziamento delle capacità di visibilità, osservabilità, rilevamento e risposta adatte a questa nuova sfida.

Marco Rottigni

Per approfondire:

https://www.theinnovationgroup.it/ll-cloud-ibrido-leva-strategica-per-il-business/

https://aws.amazon.com/it/compliance/shared-responsibility-model/

https://www.qualys.com/apps/cloud-security-assessment/

DNS e sicurezza informatica

Le tecnologie intelligenti risolvono i problemi, 

le tecnologie efficaci li prevengono.

Cosa sono i DNS?

L’acronimo DNS (Domain Name System) indica il Sistema (di Nomi di Dominio) utilizzato su Internet, con il quale viene associata una stringa a un indirizzo IP (una “sequenza” di numeri che consente di raggiungere un dispositivo connesso alla rete). Tale stringa, è denominata FQDN (Fully-Qualified Domain Name) ed è, rispetto ad una sequenza numerica, più facilmente memorizzabile da parte degli utenti. Si tratta infatti (con buona approssimazione) della stringa che gli utenti inseriscono nella barra degli indirizzi del browser quando vogliono ad esempio raggiungere un sito web.

Per consentire all’utente di raggiungere il sito web, la stringa inserita (FQDN) deve essere tradotta in un indirizzo IP: questo è possibile grazie all’infrastruttura DNS, della quale i server DNS costituiscono una componente essenziale. Al fine di ottenere una buona esperienza di navigazione e navigare velocemente, è necessario che i server DNS offrano elevate prestazioni e tempi di risposta contenuti.

La navigazione veloce rappresenta uno dei motivi più diffusi per cui gli utenti Web decidono di cambiare le proprie impostazioni di navigazione, utilizzando DNS di terze parti. Ma accanto a questa motivazione, anche alcuni problemi relativi alla sicurezza informatica spingono ad impostare DNS differenti rispetto a quelli forniti dal proprio provider.

Numerosi malware abusano del servizio DNS per rendere difficile l’idenfiticazione dei server di C&C (Command-and-Control) direttamente sotto il controllo del botmaster. Le tecniche di Domain Fluxing e IP Fluxing sono esempi di metodi frequentemente utilizzati a questo scopo. Un'analisi dei domini generati dagli host può consentire dunque di identificare la presenza, all’interno della rete, di macchine infette da malware.

Nelle campagne di phishing o nei tentativi di frode, gli attaccanti sono soliti registrare domini Internet che l’utente può facilmente confondere con domini legittimi (perché simili, ad esempio, a quelli di un noto brand). Questo allo scopo di accrescere le probabilità di successo dell’attacco. Anche in questo caso, il monitoraggio del DNS consente di identificare tempestivamente i tentativi di attacco e, con delle azioni di blocco, ridurre significativamente le probabilità di successo dell'attacco stesso.

Tra i diversi servizi di hosting sul web che forniscono dei DNS per modificare le proprie impostazioni di navigazione, o migliorare le prestazioni, segnaliamo Pluribus One Internet Security® (internetsecurity.pluribus-one.it)

Questo servizio gratuito, operando direttamente sul DNS, agisce bloccando preventivamente domini e IP malevoli, proteggendo così da minacce di diversa natura come malware, phishing e scam.

Inoltre blocca e nasconde banner e pubblicità indesiderata che rallentano e appesantiscono le pagine web durante la navigazione supportata da browser, agendo perfino sulle sempre più numerose pubblicità inserite all’inizio dei contenuti video.

Per utilizzare questo servizio è sufficiente impostare sul proprio dispositivo i seguenti DNS:

• DNS Primario: 15.161.13.182;

• DNS Secondario: 15.161.200.219.

La procedura è sempre reversibile e si possono impostare in qualsiasi momento i DNS precedentemente utilizzati nel dispositivo.

Matteo Mauri

VERSO I SOFTWARE AD ORIGINE CONTROLLATA E GARANTITA. MA BASTERÀ DAVVERO PER RENDERCI PIU’ SICURI?

Il Presidente Biden ordina la etichettatura di sicurezza dei software e la comunicazione al consumatore della lista degli ingredienti di cui è composto. Lo scopo è quello di certificare provenienza, genuinità e sicurezza del prodotto. L’ordine esecutivo “Improving the Nation's Cybersecurity” è del maggio scorso e nelle scorse settimane sono iniziate ad arrivare le prime risposte tecnico-organizzative da parte delle agenzie federali e del mondo accademico ed industriale.

Finalmente, si direbbe. 

Troppe falle di sicurezza, troppi attori malevoli che hanno avuto vita facile in questi anni. Da qui a non molto, infatti, bisognerà mettere in piedi comprovate procedure di tracciamento per dimostrare che il software è stato realizzato in un ambiente sicuro, secondo buone pratiche di sviluppo e test; e si dovrà rendere conto della provenienza dei codici sorgente, dandone riscontro con artefatti standardizzati. Ed infine si dovrà dare atto all’utenza non più solo delle condizioni d’uso, ma aggiungere una etichettatura di sicurezza ed una SBOM (Software Bill Of Materials): la distinta base che ne elenca le componenti e la provenienza.

Insomma, andare a comprar software finirà con l’essere molto simile a quando dobbiamo acquistare la nuova lavatrice, attenti a verificare l’etichettatura energetica per verificare i consumi di corrente elettrica o l’inquinamento acustico; oppure analogamente a quando ci aggiriamo tra le corsie dei supermercati, intenti a verificare la tabella degli ingredienti dei biscotti alla ricerca di quelli più sani, genuini, a chilometro zero, con meno calorie e senza allergeni. Oppure ancora quando al ristorante siamo alla ricerca della bottiglia di vino di qualità, richiedendo quella DOC piuttosto che che quella contrassegnata da una Denominazione di Origine Controllata e Garantita.

Ma andiamo con ordine e proviamo a capire cosa sta accadendo. E soprattutto se sarà davvero sufficiente.

Negli ultimi mesi sono stati avviate due iniziative strutturali da parte del Governo americano: la prima, finalizzata a mettere in sicurezza la catena di fornitura dei software; la seconda, quella diretta a portare l’ambiente tecnologico dei sistemi di controllo industriale ad un livello di cybersicurezza almeno pari a quello che si è oggi raggiunto nei sistemi IT.

La catena di fornitura dei software è oramai molto sviluppata e capillarmente distribuita, tanto che oramai può dirsi che “chiunque fa software”. E nel concetto di “chiunque” vi è quello - correlato - di “indeterminato”, che oggi costituisce la principale vulnerabilità alla base della maggior parte degli incidenti informatici: non solo non sappiamo infatti di chi sia con esattezza la paternità dei software che utilizziamo, al quale eventualmente far risalire responsabilità civili, penali ed amministrative per danno arrecato o per l’avvenuta esposizione a pericoli; ma non sappiamo neanche se questo qualcuno, anche quando abbia agito in buona fede, si sia dotato di risorse, strutture e tecniche operative per sviluppare e provare in sicurezza il prodotto, nonché adeguati controlli che ne impediscano la manomissione.

E tutto ciò, se vale genericamente per tutti i software, assume una valenza decisiva per la categoria dei cosiddetti software critici, cioè quelli che eseguono funzioni di garanzia e di sicurezza, come ad esempio quelli necessari per gestire e verificare i privilegi degli amministratori del sistema o che consentono l’accesso diretto alle risorse di macchina o di rete.

La strategia che si sta mettendo in campo proverà dunque a garantire, con processi ripetibili e comprovabili, queste tre dimensioni: paternità, sicurezza e genuinità. Vediamo come.

Si inizierà a pretendere che i software vengano realizzati in ambienti di sviluppo compartimentati rispetto a quelli in cui verranno successivamente testati, nonché da quelli in cui verranno - a regime - utilizzati; e le informazioni al consumatore dovranno dare evidenza delle procedure di sicurezza utilizzate per assicurare tale segregazione ambientale. Poi, bisognerà impiegare automatismi che permettano sia la verifica della provenienza e dell’integrità dei codici sorgente utilizzati per sviluppare il software, che una costante ricerca delle vulnerabilità e dei relativi rimedi. Ed anche di questo si dovrà dare atto nelle informazioni all’utenza, non mancando di indicare la descrizione sommaria dei rischi valutati e mitigati. Sarà da tenere anche un inventario puntuale dei dati relativi alla provenienza dei codici sorgente o dei componenti dei software non sviluppati in casa, nonché dei controlli implementati e degli audit eseguiti sulle componenti software, sui servizi e sugli strumenti di sviluppo, sia interni che di terze parti. Per quanto possibile, sarà obbligatorio certificare l'integrità e la provenienza del software open source utilizzato all'interno di qualsiasi porzione di un prodotto. Infine si dovrà dimostrare di avere in piedi un sistema di controllo interno che sia in grado di divulgare per tempo le vulnerabilità rilevate nei software prodotti.

All’esito o a complemento delle azioni sopra indicate, bisognerà creare le etichette di sicurezza e le distinte base per i consumatori.

E’ da attendersi che tutto ciò migliorerà sensibilmente la tracciatura della provenienza, dell’integrità e della sicurezza dei software, ma determinerà anche un aumento significativo dei costi di realizzazione e dunque dei prezzi al pubblico.

Ma l’uomo comune, con il divario digitale che caratterizza la cultura di massa attuale, abituato com’è a scaricare software “craccato” a costo zero dal web, sarà disposto a spendere cifre sensibilmente diverse per acquistare tal fatta di software sicuro? Abbiamo bisogno di agire in parallelo affinché, di pari passo con la messa in sicurezza della supply chain dei software, si agisca per creare nuove consapevolezze di igiene digitale tra chi, di quei software, dovrà avvertire la necessità.

Orazio Danilo Russo e Carlo Mauceli

Per approfondire:

https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity

https://www.whitehouse.gov/briefing-room/statements-releases/2021/07/28/national-security-memorandum-on-improving-cybersecurity-for-critical-infrastructure-control-systems/

https://www.nist.gov/itl/executive-order-improving-nations-cybersecurity/critical-software-definition

PEBKAC: il problema del livello 8

PEBKAC.

Mai sentita questa parola, di origine nerd ma che rappresenta una delle piaghe maggiori e più difficilmente risolvibili della sicurezza informatica?

È un acronimo, significa Problem Exists Between Keyboard And Chair – cioè che il problema si trova tra la tastiera e la sedia.

Altri lo chiamano HF ad indicare lo Human Factor – il fattore umano; altri ancora usano affettuosamente il nome Dave, in base ad una nota vignetta del 2006 sulla sicurezza dei dati, disegnata dal cartoonist John Klossner:

Tutto ad indicare qualcosa di pericoloso, all’apparenza innocuo, ma che non si può – o quanto meno è sconveniente – eliminare: l’utente inconsapevole.

Questo articolo ha quindi l’ambizioso obiettivo di descrivere i rischi di questa inconsapevolezza, sperando di stimolare in ogni lettore una riflessione che aumenti la coscienza del rischio.

Immaginate quindi il nostro Dave – impiegato nelle risorse umane della Acme Farmaceutici SpA – mentre controlla la mail la mattina e gli arriva una richiesta di contatto LinkedIN da una certa Fiammetta Canestrelli, che dice: “Dave, quanti anni sono passati dalle superiori? Io certo ti ricordo bene e mi piacerebbe averti nella mia rete professionale.”

Dave non ricorda bene Fiammetta – strano perché con un nome così particolare – però se lei si ricorda di lui perché non riavvicinarsi?
Dave trova quindi irresistibile quell’invito – complice forse l’immagine della brunetta dagli occhi azzurri che campeggia sulla pagina del profilo a cui – cliccato sul link della mail – accede per confermare il contatto… non facendo certamente caso al sito intermedio da cui la connessione passa in seguito al click sul link.

Sito il cui URL è stato visualizzato per meno di un secondo nella barra di stato del browser, ma che è servito a un sistema per intercettare moltissime informazioni sulla connessione, prima di redirigerla sul sito ufficiale di LinkedIN.

Se Dave avesse provato a cercare quel bel paio di occhioni azzurri in un motore di ricerca immagini avrebbe trovato decine di risultati oltre al profilo professionale di Fiammetta: pubblicità di eye-liner, agenzie di casting per modelle, tutorial di fotoritocco online… nessuna delle quali menzionava Fiammetta.

Invece visitando il profilo, scopre che la sua presunta ex-compagna di scuola ha un’esperienza di tutto rispetto nel campo della sicurezza informatica, con anni spesi nelle aziende più importanti e due master universitari negli Stati Uniti; è quasi contento di essere stato suo compagno di scuola.

Felicità che ritrova qualche giorno dopo quando vede le richieste via Facebook ed Instagram, grazie a cui le foto di Fiammetta si moltiplicano in altri contesti: serate in locali in, ritratti in costume al mare, c’è anche la foto in tailleur a corpo intero da cui deve aver preso quella del profilo professionale… davvero una bella ragazza, pensa Dave.

Così quando via Messenger riceve il link a visitare il blog di Fiammetta con tanti articoli su come fare il pane e i grandi lievitati, ci clicca su senza pensarci due volte.

Quello che Dave non sa è che l’insieme delle sue azioni ha portato un altro paio di occhi, non azzurri tantomeno appartenenti alla ragazza, ad avere una visibilità eccellente sul suo PC aziendale connesso in remoto – causa pandemia – ai sistemi delle risorse umane della Acme Farmaceutici SpA.

Grazie a un componente software scaricato in modo totalmente ignaro e trasparente dal blog, due mani abili corrono su una tastiera – guidate da un cervello allenato alle compromissioni informatiche. Una connessione che parte dall’Est Europa si infila in reti non tracciabili fino ad arrivare al laptop di Dave, da qui via VPN atterra sull’applicazione con cui ACME gestisce i dati dei dipendenti. Operazione non immediata grazie all’uso di password complesse che ACME impone ai propri impiegati delle risorse umane… diverse da quelle che usano per uso personale come ad esempio i social network.

Ma resa enormemente più semplice da Dave, che detesta questa prassi ed ha memorizzato la password per accedere al sistema direttamente nel browser, così non deve ricordarsi e digitare quella sequenza complessa di 15 caratteri tutte le volte.

E meno male che accedendo in VPN l’IT della ACME non richiede la one-time password, perché il canale è sicuro!

Il mese successivo, il CISO della ACME riceve una delle peggiori mail della sua carriera. “Abbiamo il database completo dei dipendenti: dati personali, stato di salute, storia lavorativa e dettagli di stipendi, premi e familiari da contattare in caso di emergenza.
Tra 48 ore queste informazioni saranno rese pubbliche, se non riceveremo la somma di 20BTC (al momento più di 666mila euro, NdA)”

Dopo essersi ripreso dallo shock, il CISO convoca l’unità di crisi dell’azienda e si prepara a spiegare come diavolo sia potuto accadere un incidente di questa gravità nonostante l’esorbitante investimento in tecnologia di sicurezza che l’azienda ha effettuato negli anni.

Investimento che ha previsto il rinforzo della protezione sulle mail aziendali, anti-malware all’avanguardia, sistemi di protezione dell’autenticazione, VPN per la connessione di dipendenti da remoto (messi a durissima prova dalla pandemia), persino servizi di penetration testing e di verifica dell’assenza di compromissioni in corso eseguiti due volte l’anno – l’ultimo il mese scorso.

Una protezione che ha coperto tutti i sette livelli del modello di riferimento ISO/OSI per l’interconnessione e la comunicazione tra sistemi eterogenei: fisico, data-link, network, trasporto, sessione, presentazione ed applicazione.

Tutto!

Tranne una piccola, ma importante falla al livello 8: Dave.

Marco Rottigni

Intelligenza Artificiale e Difesa

Già attivo da alcuni anni il Centro Innovazione della Difesa (CID), del III° Reparto dello Stato Maggiore della Difesa, sta diventando sempre più protagonista nel panorama della Difesa italiana. Il CID ha il compito di garantire lo sviluppo e l'aggiornamento di un adeguato quadro concettuale e dottrinale, allo scopo di supportare il processo di trasformazione dello Strumento Militare nazionale ed in questo senso sta operando in relazione all'Intelligenza Artificiale. 

Nell'anno in corso, in particolare, ha dato seguito all'iniziativa INNOV@DIFESA, hub di riferimento della Difesa per l’innovazione che abbracciando il paradigma dell’Open Innovation (ricorrendo cioè alle idee interne ed esterne alla Difesa, attraverso il pensiero critico accademico, la pragmaticità della realtà industriale e l’intuizione del contesto della ricerca), sta realizzando un network di esperti volto a cogliere l’innovazione aperta nei settori civili, privati ed istituzionali attraverso un’azione di raccordo a guida del CID. Proprio in tale contesto il CID ha promosso due workshop tenutisi nei mesi di aprile e di luglio.

Nel corso del primo workshop, "Intelligenza Artificiale, Difesa & Sostenibilità: implicazioni etiche, legali e psicologiche", con la collaborazione dell’European Institute for Innovation and Sustainability (EIIS), sono stati analizzati gli aspetti etici, legali e psicologici relativi all'introduzione dell'Intelligenza Artificiale nel mondo della Difesa. Nel corso dei lavori è intervenuto padre BENANTI, francescano, teologo, che ha trattato l'argomento dal punto di vista etico e ha guidato l'esame degli aspetti etici legati al rapporto tra Essere Umano e Intelligenza Artificiale.

Nel secondo panel è intervenuto il Professor Andrea CASTIELLO D’ANTONIO, psicologo, già Professore Straordinario di psicologia clinica e del lavoro presso l’Università Europea di Roma, che ha messo in evidenza come l'AI risulti sempre più utile in diversi settori della società ma come allo stesso tempo si registra una crescita dei problemi di "interfacciamento" tra Uomo e Macchina.

Nel terzo panel è intervenuto l'Avvocato Marco PROVVIDERA, docente di International Law (Law of Armed Conflict), National Security, Law of the Intelligence, Comparate Counter-terrorism e Law of the Emerging Technologies, che ha analizzato la situazione negli Stati Uniti e nell'Unione Europea, evidenziando come sia sempre più urgente normare il settore, anche per evitare che concorrenti e avversari strategici e geopolitici dell’Occidente, possano sfruttare a proprio vantaggio le norme che regolano jus ad bellum e jus in bello.

A luglio, con il secondo, "Intelligenza Artificiale, Difesa e Sostenibilità: Nuove esigenze formative, e-Leadership ed evoluzione dei processi decisionali", si è visto crescere l'interesse del pubblico, delle università e dell'industria nazionale attorno ad un argomento che diventa sempre più importante per lo sviluppo delle Forze Armate e del pensiero strategico nazionale.

Il primo dei due panel organizzati in questo secondo incontro, ha visto, tra gli altri, l’intervento della Prof.ssa D.M. ROMAN, esperta nella gestione dei conflitti derivanti dall'implementazione di Nuove Tecnologie e del Dott. E. CACCIATORE, Senior Director Industry Strategy & Transformation EMEA – Oracle. Nel corso del panel sono stati introdotti da vari punti di vista gli aspetti relativi alle nuove competenze digitali e alle nuove esigenze formative del personale, con particolare attenzione agli aspetti connessi alle criticità legate al senso di responsabilità sociale, all’analisi in chiave economica dell’IA quale tecnologia esponenziale (il valore delle competenze complementari) e alle possibili applicazioni dell’IA per lo sviluppo della divergenza. Il panel è stato quindi arricchito dall’esperienza acquisita dalla Difesa con il progetto Sfida-Amelia, applicazione pratica di impiego della IA per soddisfare la crescente esigenza di adeguare la formazione della classe dirigente militare.

Il secondo e conclusivo panel, che ha visto gli interventi della Prof.ssa M. RUGGIERI, Professore ordinario di telecomunicazioni presso l’Università di Roma “Tor Vergata”, dell’Ing. A. COSTAGLIOLI, Chief Innovation Officer di INPECO Group, e del Prof. A. CASTIELLO D’ANTONIO, ha posto l’accento sugli aspetti connessi al teaming uomo-macchina, sulla qualità dei dati e dell’algoritmo per una implementazione efficace dell’IA, sui nuovi modelli di leadership e sulla figura del nuovo e-leader.

Attualmente è in preparazione il terzo workshop, che si terrà presumibilmente all'inizio del mese di ottobre e di cui avremo modo di parlare più avanti.

Alessandro Rugolo e Fabrizio Benigni

Per approfondire:

Centro Innovazione della Difesa - Difesa.it